From stephen.farrell@cs.tcd.ie Wed May 9 07:40:09 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D07211E8080 for ; Wed, 9 May 2012 07:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4MZhoynDEE4E for ; Wed, 9 May 2012 07:40:08 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id B007111E8072 for ; Wed, 9 May 2012 07:40:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id F337C171536 for ; Wed, 9 May 2012 15:40:07 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1336574407; bh=C8XhGUx+/O2dTfGGGItQOKNi SrKf8X5B29nwlOzWoz8=; b=2nbYGkFukvQjiVX/1CneMXkSQn/iKlhUkGzQbyr7 LdYwgSoZzKi/mLMGrDeR0S5iatYQAYJLyVspy8BZKh4cTbTM0orbBay0PrW0tlke R9BKLAh9UwWfCcE2QBiWK5eC2SIVsZ97iYQCVn03aiSKmIXLCGzR2BwbucDM9s4n uc3pE4DASLmEtlBeTbHTBDgAFrsMlLLPlRrrDFRBC+qozWeNkrwefNqbhx5E05Dl w3PKDvrQrJKY6eJGec+w1MjjzwzOyd0aWRWQjji6gIx8orBW6zA+F2QxSFKu1vJw j1zhphmkJMBSi5sPfiRTjUT5U0Jpoa5Pl63/INCvRWgczQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id VD7TvncDV5vl for ; Wed, 9 May 2012 15:40:07 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id A0C26171512 for ; Wed, 9 May 2012 15:40:07 +0100 (IST) Message-ID: <4FAA81C8.7040206@cs.tcd.ie> Date: Wed, 09 May 2012 15:40:08 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "saag@ietf.org" X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [saag] Paris saag meeting notes X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 14:40:09 -0000 Folks, Sorry, I thought I'd posted the meeting notes until Sean reminded me that they were sitting idly on my hard disk;-) Fixed now. [1] If there are any corrections needed, please let Sean and I know before May 15th. Sorry again for the short notice there. Cheers, S. [1] http://www.ietf.org/proceedings/83/minutes/minutes-83-saag.txt From mnot@mnot.net Sun May 6 16:52:10 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 841C421F856A for ; Sun, 6 May 2012 16:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgMMijBCLCVC for ; Sun, 6 May 2012 16:52:10 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA0421F8567 for ; Sun, 6 May 2012 16:52:10 -0700 (PDT) Received: from [192.168.0.100] (unknown [110.151.123.191]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 11D8B509B4 for ; Sun, 6 May 2012 19:52:08 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 7 May 2012 09:52:12 +1000 References: <14A09626-8397-4656-A042-FEFDDD017C9F@mnot.net> To: saag@ietf.org Message-Id: <4DAC6FBC-3E6D-4CD1-9B5C-0CA5986169A5@mnot.net> Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-Mailman-Approved-At: Tue, 15 May 2012 08:04:51 -0700 Subject: [saag] Fwd: Reminder: Call for Proposals - HTTP/2.0 and HTTP Authentication X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 23:52:10 -0000 FYI; see in particular #2. Begin forwarded message: > Resent-From: ietf-http-wg@w3.org > From: Mark Nottingham > Subject: Reminder: Call for Proposals - HTTP/2.0 and HTTP = Authentication > Date: 27 April 2012 3:28:06 PM AEST > To: HTTP Working Group > Archived-At: = >=20 > Just a reminder that we're still accepting proposals for: >=20 > 1. HTTP/2.0 > 2. New HTTP authentication schemes >=20 > As per our charter . >=20 > So far, we've received the following proposals applicable to HTTP/2.0: > >=20 > But none yet for authentication schemes: > >=20 > As communicated in Paris, the deadline for proposals is 15 June, 2012. = It's fine if your proposal isn't complete, but we do need to have a = good sense of it by then, for discussion. >=20 > Regards, >=20 -- Mark Nottingham http://www.mnot.net/ From paul.hoffman@vpnc.org Tue May 15 08:40:34 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC0D421F8953 for ; Tue, 15 May 2012 08:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0HAyKEfIEbDz for ; Tue, 15 May 2012 08:40: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 E431E21F889D for ; Tue, 15 May 2012 08:40:33 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q4FFeWqQ099666 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 15 May 2012 08:40:33 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1278) From: Paul Hoffman In-Reply-To: <4DAC6FBC-3E6D-4CD1-9B5C-0CA5986169A5@mnot.net> Date: Tue, 15 May 2012 08:40:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <14A09626-8397-4656-A042-FEFDDD017C9F@mnot.net> <4DAC6FBC-3E6D-4CD1-9B5C-0CA5986169A5@mnot.net> To: IETF Security Area Advisory Group X-Mailer: Apple Mail (2.1278) Subject: Re: [saag] Reminder: Call for Proposals - HTTP/2.0 and HTTP Authentication X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 15:40:35 -0000 Given the number of HTTP authentication proposals we have seen in the = past 10 years, it's weird that *no one* has sent any of them to the = HTTPbis WG. This is an opportunity to get the improvements we have = wanted. --Paul Hoffman From nico@cryptonector.com Tue May 15 08:54:52 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D71F21F88D0 for ; Tue, 15 May 2012 08:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.814 X-Spam-Level: X-Spam-Status: No, score=-1.814 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aj16Vns7TTQw for ; Tue, 15 May 2012 08:54:52 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 069AB21F88AD for ; Tue, 15 May 2012 08:54:51 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id 7A3B9438079 for ; Tue, 15 May 2012 08:54:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=nONFSZ+Jf4yu9+OMGwXQE gfebvC0sljiZom2dYY4bTdXyzcjsn2EabpXc+ccQi1h0Z0KQ7+xIbj+jZEry/BCx NXttOmDZ3PEoDxPXJngAYBnzTOP6seUNjg4gn0Vq945g1qXWeENxFISd3U8Oc6cE Xz6pKT760Tgh63qnTMKnXM= 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=oE3qhZFQ2k/ZL5k9uQUN WjPNUcM=; b=XjgRQhxFm9X69JbfVvuIJmwshXzQipI5b6EVdMhogMbADL2WpgVg 5fAVn/vUCksaeIvqwV0ZSiTP6WNWI6GfDfxTHnvaL+lskWE3bomeljDPYu8Q51Yk ZxUJsvHc1f6OsYyJouxoCjmKkGIDvDVs96mFcpzGQEHMC9V1vispID8= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPSA id 5AA2F43806C for ; Tue, 15 May 2012 08:54:51 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so7946173pbc.31 for ; Tue, 15 May 2012 08:54:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.190.137 with SMTP id gq9mr6813437pbc.34.1337097289678; Tue, 15 May 2012 08:54:49 -0700 (PDT) Received: by 10.68.5.99 with HTTP; Tue, 15 May 2012 08:54:49 -0700 (PDT) In-Reply-To: References: <14A09626-8397-4656-A042-FEFDDD017C9F@mnot.net> <4DAC6FBC-3E6D-4CD1-9B5C-0CA5986169A5@mnot.net> Date: Tue, 15 May 2012 10:54:49 -0500 Message-ID: From: Nico Williams To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Cc: IETF Security Area Advisory Group Subject: Re: [saag] Reminder: Call for Proposals - HTTP/2.0 and HTTP Authentication X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 15:54:52 -0000 On Tue, May 15, 2012 at 10:40 AM, Paul Hoffman wrote: > Given the number of HTTP authentication proposals we have seen in the past 10 years, it's weird that *no one* has sent any of them to the HTTPbis WG. This is an opportunity to get the improvements we have wanted. I'm working on an I-D that's not so much a proposal as a set of classification / analysis criteria and a list of imagined proposals. I've made a proposal in the past (REST-GSS) which I'll also update. I may be a little late with the actual proposal. Nico -- From paul.hoffman@vpnc.org Tue May 15 09:16:19 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10AD721F8966 for ; Tue, 15 May 2012 09:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEgYdsZvn9DC for ; Tue, 15 May 2012 09:16:18 -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 70C2821F893D for ; Tue, 15 May 2012 09:16:18 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q4FGGGJd002040 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 15 May 2012 09:16:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Tue, 15 May 2012 09:16:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <14A09626-8397-4656-A042-FEFDDD017C9F@mnot.net> <4DAC6FBC-3E6D-4CD1-9B5C-0CA5986169A5@mnot.net> To: Nico Williams X-Mailer: Apple Mail (2.1278) Cc: IETF Security Area Advisory Group Subject: Re: [saag] Reminder: Call for Proposals - HTTP/2.0 and HTTP Authentication X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 16:16:19 -0000 On May 15, 2012, at 8:54 AM, Nico Williams wrote: > On Tue, May 15, 2012 at 10:40 AM, Paul Hoffman = wrote: >> Given the number of HTTP authentication proposals we have seen in the = past 10 years, it's weird that *no one* has sent any of them to the = HTTPbis WG. This is an opportunity to get the improvements we have = wanted. >=20 > I'm working on an I-D that's not so much a proposal as a set of > classification / analysis criteria and a list of imagined proposals. > I've made a proposal in the past (REST-GSS) which I'll also update. I > may be a little late with the actual proposal. I'm pretty sure that a pointer to draft-williams-rest-gss-00 (or any = other expired draft in this area) is all the httpbis WG needs; they = don't need an up-to-date draft. Having said that, I bet that they would very much like to see a = classification / analysis document to help them! --Paul Hoffman From nico@cryptonector.com Tue May 15 09:33:08 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5C521F8808 for ; Tue, 15 May 2012 09:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.817 X-Spam-Level: X-Spam-Status: No, score=-1.817 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 54vOFnHCFPkx for ; Tue, 15 May 2012 09:33:07 -0700 (PDT) Received: from homiemail-a65.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2ED21F87D6 for ; Tue, 15 May 2012 09:33:07 -0700 (PDT) Received: from homiemail-a65.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTP id 41BF47E4065 for ; Tue, 15 May 2012 09:33:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=fPWBO9Mb/H2ud7NMOe5Jn BlucrX2OyvoXqqvd013HGDJMIQkJbQc2jRPIxv+nUvfANDnk6NRnUO+sAnbrSgPz JEDlIOxIjDSd53fFIwSDtoPd3iUatffCelH6aeX6Fk7s71ptQHBXQUS2p76/BKaS GRDJ3banXpFl5t1enVqkq8= 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=oQsHbKLWLX8RuAlonb++ a4funBE=; b=FS/os7xF8xyRH2xZJzEIev0dw+aXQ/9oUjl+Rmn5TFa5n06oCJQ7 plHRg9hno+5mGdhgFD+UTONTw2mKJH0YzscqVloZgg4uN361ryhB8e5RCNd2NtwJ ffJbC29ES3O0TFgsR3eypmeZoFzqtrR2yufTO0iO+F47IG6BIY8xS8M= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTPSA id 23F5A7E405D for ; Tue, 15 May 2012 09:33:07 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so7989188pbc.31 for ; Tue, 15 May 2012 09:33:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.204.2 with SMTP id ku2mr7124872pbc.55.1337099586787; Tue, 15 May 2012 09:33:06 -0700 (PDT) Received: by 10.68.5.99 with HTTP; Tue, 15 May 2012 09:33:06 -0700 (PDT) In-Reply-To: References: <14A09626-8397-4656-A042-FEFDDD017C9F@mnot.net> <4DAC6FBC-3E6D-4CD1-9B5C-0CA5986169A5@mnot.net> Date: Tue, 15 May 2012 11:33:06 -0500 Message-ID: From: Nico Williams To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Cc: IETF Security Area Advisory Group Subject: Re: [saag] Reminder: Call for Proposals - HTTP/2.0 and HTTP Authentication X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 16:33:08 -0000 On Tue, May 15, 2012 at 11:16 AM, Paul Hoffman wrote: > I'm pretty sure that a pointer to draft-williams-rest-gss-00 (or any other expired draft in this area) is all the httpbis WG needs; they don't need an up-to-date draft. Good point. But working on the classification document is making me think of possible enhancements to my proposal anyways :) > Having said that, I bet that they would very much like to see a classification / analysis document to help them! Right. Assuming they get lots of proposals it will be necessary to figure out how to analyze them. Even if they get no proposals it'd be useful to have such a document to guide any design team. Personally I continue to believe that there will not be a single authentication mechanism that satisfies all users' needs, so I will continue to argue for pluggable frameworks. However, I'm less interested in this than I am in the analysis at this point. As for the dearth of proposals... I suspect part of it is not knowing what HTTP 2.0 will look like, and part of it is weariness: web auth has been a resisting solutions for many years now. Perhaps no one really expects HTTPbis WG to be able to crack that nut? Nico -- From paul.hoffman@vpnc.org Tue May 15 09:41:33 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E67521F8745 for ; Tue, 15 May 2012 09:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cy5hwzyG-vkS for ; Tue, 15 May 2012 09:41:32 -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 89BE421F8731 for ; Tue, 15 May 2012 09:41:32 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q4FGfThJ003481 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 15 May 2012 09:41:30 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Tue, 15 May 2012 09:41:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <410AB643-F18B-47F1-926E-9D34A1EE24DD@vpnc.org> References: <14A09626-8397-4656-A042-FEFDDD017C9F@mnot.net> <4DAC6FBC-3E6D-4CD1-9B5C-0CA5986169A5@mnot.net> To: Nico Williams X-Mailer: Apple Mail (2.1278) Cc: IETF Security Area Advisory Group Subject: Re: [saag] Reminder: Call for Proposals - HTTP/2.0 and HTTP Authentication X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 16:41:33 -0000 On May 15, 2012, at 9:33 AM, Nico Williams wrote: > On Tue, May 15, 2012 at 11:16 AM, Paul Hoffman = wrote: >> I'm pretty sure that a pointer to draft-williams-rest-gss-00 (or any = other expired draft in this area) is all the httpbis WG needs; they = don't need an up-to-date draft. >=20 > Good point. But working on the classification document is making me > think of possible enhancements to my proposal anyways :) >=20 >> Having said that, I bet that they would very much like to see a = classification / analysis document to help them! >=20 > Right. Assuming they get lots of proposals it will be necessary to > figure out how to analyze them. Even if they get no proposals it'd be > useful to have such a document to guide any design team. At this point they have zero proposals, but I'm hoping to change that by = nudging here (not by writing a proposal myself). > Personally I continue to believe that there will not be a single > authentication mechanism that satisfies all users' needs, so I will > continue to argue for pluggable frameworks. However, I'm less > interested in this than I am in the analysis at this point. We already have a pluggable framework; if it needs changes, letting the = httpbis WG know that early would be important. > As for the dearth of proposals... I suspect part of it is not knowing > what HTTP 2.0 will look like, and part of it is weariness: web auth > has been a resisting solutions for many years now. Perhaps no one > really expects HTTPbis WG to be able to crack that nut? The IESG expects them to not only crack the nut, but to show that the = inside is edible. This was made very clear in the rechartering = discussion (well, without the food analogy). --Paul Hoffman From alexey.melnikov@isode.com Tue May 15 09:44:30 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59B6A21F87E3 for ; Tue, 15 May 2012 09:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.701 X-Spam-Level: X-Spam-Status: No, score=-102.701 tagged_above=-999 required=5 tests=[AWL=-0.102, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8txeh7VKnWaw for ; Tue, 15 May 2012 09:44:29 -0700 (PDT) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2F91221F87D2 for ; Tue, 15 May 2012 09:44:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1337100268; d=isode.com; s=selector; i=@isode.com; bh=t38qYCd6yFVFMisoSdmgWfWsfwm4+rWrLsDTKaJkAdw=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=Wp9UcbO7iRNZNLInfJpVkcca6p0UYq9LecSeVK9f2P6GzBW21xI29P/8yLnVZs626DkmR2 oBxjiilz4iMeBIUW8a3CIeAp1vTx0e/9td159d5YBI0jACSzeQ14gUhb4L+BNnu1FbGwE9 6Pbaaj09OSJTOrurtfYgmE3ZzGxnKBk=; Received: from [172.16.11.4] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 15 May 2012 17:44:27 +0100 Message-ID: <4FB28842.1090503@isode.com> Date: Tue, 15 May 2012 17:45:54 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 To: Paul Hoffman References: <14A09626-8397-4656-A042-FEFDDD017C9F@mnot.net> <4DAC6FBC-3E6D-4CD1-9B5C-0CA5986169A5@mnot.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF Security Area Advisory Group Subject: Re: [saag] Reminder: Call for Proposals - HTTP/2.0 and HTTP Authentication X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 16:44:30 -0000 On 15/05/2012 16:40, Paul Hoffman wrote: > Given the number of HTTP authentication proposals we have seen in the past 10 years, it's weird that *no one* has sent any of them to the HTTPbis WG. This is an opportunity to get the improvements we have wanted. I think Simon Josefsson and I will write a proposal based on SCRAM (RFC 5802). From jhutz@cmu.edu Tue May 15 10:07:00 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9930B21F89BC for ; Tue, 15 May 2012 10:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x+dEjCSz3WOi for ; Tue, 15 May 2012 10:07:00 -0700 (PDT) Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) by ietfa.amsl.com (Postfix) with ESMTP id 0700521F89BA for ; Tue, 15 May 2012 10:06:59 -0700 (PDT) Received: from [192.168.33.124] (c-67-165-85-247.hsd1.pa.comcast.net [67.165.85.247]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id q4FH6uBY016434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 May 2012 13:06:56 -0400 (EDT) From: Jeffrey Hutzelman To: Paul Hoffman In-Reply-To: <15942_1337100095_q4FGfYs7026806_410AB643-F18B-47F1-926E-9D34A1EE24DD@vpnc.org> References: <14A09626-8397-4656-A042-FEFDDD017C9F@mnot.net> <4DAC6FBC-3E6D-4CD1-9B5C-0CA5986169A5@mnot.net> <15942_1337100095_q4FGfYs7026806_410AB643-F18B-47F1-926E-9D34A1EE24DD@vpnc.org> Content-Type: text/plain; charset="UTF-8" Date: Tue, 15 May 2012 13:06:56 -0400 Message-ID: <1337101616.3244.206.camel@destiny.pc.cs.cmu.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.196 Cc: IETF Security Area Advisory Group , jhutz@cmu.edu Subject: Re: [saag] Reminder: Call for Proposals - HTTP/2.0 and HTTP Authentication X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 17:07:00 -0000 On Tue, 2012-05-15 at 09:41 -0700, Paul Hoffman wrote: > On May 15, 2012, at 9:33 AM, Nico Williams wrote: > > Personally I continue to believe that there will not be a single > > authentication mechanism that satisfies all users' needs, so I will > > continue to argue for pluggable frameworks. However, I'm less > > interested in this than I am in the analysis at this point. > > We already have a pluggable framework; if it needs changes, letting the > httpbis WG know that early would be important. Yeah; this is kind of poor. Instead of inventing a new framework, why not reuse an existing one? The whole point of frameworks like SASL is to _avoid_ having every application protocol have its own framework and its own set of mechanisms. From simon@josefsson.org Tue May 15 11:25:37 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3829521F8881 for ; Tue, 15 May 2012 11:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.828 X-Spam-Level: X-Spam-Status: No, score=-99.828 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ChsRi+SeP9Py for ; Tue, 15 May 2012 11:25:36 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 7273F21F8858 for ; Tue, 15 May 2012 11:25:36 -0700 (PDT) Received: from latte (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q4FIPMDv022077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 15 May 2012 20:25:24 +0200 From: Simon Josefsson To: Jeffrey Hutzelman References: <14A09626-8397-4656-A042-FEFDDD017C9F@mnot.net> <4DAC6FBC-3E6D-4CD1-9B5C-0CA5986169A5@mnot.net> <15942_1337100095_q4FGfYs7026806_410AB643-F18B-47F1-926E-9D34A1EE24DD@vpnc.org> <1337101616.3244.206.camel@destiny.pc.cs.cmu.edu> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120515:jhutz@cmu.edu::xFqQyJDgdw5sR9VP:MHYL X-Hashcash: 1:22:120515:saag@ietf.org::7m/HR99TDj+wGNln:ZIF3 X-Hashcash: 1:22:120515:paul.hoffman@vpnc.org::asmg/h3ZojMgtHcw:ZlV6 Date: Tue, 15 May 2012 20:25:22 +0200 In-Reply-To: <1337101616.3244.206.camel@destiny.pc.cs.cmu.edu> (Jeffrey Hutzelman's message of "Tue, 15 May 2012 13:06:56 -0400") Message-ID: <87likt714d.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: Paul Hoffman , IETF Security Area Advisory Group Subject: Re: [saag] Reminder: Call for Proposals - HTTP/2.0 and HTTP Authentication X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 18:25:37 -0000 Jeffrey Hutzelman writes: > On Tue, 2012-05-15 at 09:41 -0700, Paul Hoffman wrote: >> On May 15, 2012, at 9:33 AM, Nico Williams wrote: >> > Personally I continue to believe that there will not be a single >> > authentication mechanism that satisfies all users' needs, so I will >> > continue to argue for pluggable frameworks. However, I'm less >> > interested in this than I am in the analysis at this point. >> >> We already have a pluggable framework; if it needs changes, letting the >> httpbis WG know that early would be important. > > Yeah; this is kind of poor. Instead of inventing a new framework, why > not reuse an existing one? The whole point of frameworks like SASL is > to _avoid_ having every application protocol have its own framework and > its own set of mechanisms. I think Paul meant the HTTP authentication framework (401), whereas you and Nico seems to think of SASL and GSS-API. Indeed, if there is something in core HTTP that doesn't lend itself to adding a generic SASL or GSS-API negotiation on top of it, that is something that could be worked on. However, such an HTTP update could be done independently of a simple replacement for Basic/Digest like SCRAM. /Simon From hartmans@mit.edu Tue May 15 12:16:15 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7A921F8836 for ; Tue, 15 May 2012 12:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.696 X-Spam-Level: X-Spam-Status: No, score=-102.696 tagged_above=-999 required=5 tests=[AWL=-0.431, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87LwukHMo4yl for ; Tue, 15 May 2012 12:16:14 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 72E2B21F8830 for ; Tue, 15 May 2012 12:16:14 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 1E25B20383; Tue, 15 May 2012 15:11:54 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id BED1A44B4; Tue, 15 May 2012 15:15:51 -0400 (EDT) From: Sam Hartman To: Simon Josefsson References: <14A09626-8397-4656-A042-FEFDDD017C9F@mnot.net> <4DAC6FBC-3E6D-4CD1-9B5C-0CA5986169A5@mnot.net> <15942_1337100095_q4FGfYs7026806_410AB643-F18B-47F1-926E-9D34A1EE24DD@vpnc.org> <1337101616.3244.206.camel@destiny.pc.cs.cmu.edu> <87likt714d.fsf@latte.josefsson.org> Date: Tue, 15 May 2012 15:15:51 -0400 In-Reply-To: <87likt714d.fsf@latte.josefsson.org> (Simon Josefsson's message of "Tue, 15 May 2012 20:25:22 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: IETF Security Area Advisory Group , Paul Hoffman , Jeffrey Hutzelman Subject: Re: [saag] Reminder: Call for Proposals - HTTP/2.0 and HTTP Authentication X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 19:16:15 -0000 >Indeed, if there is something in core HTTP that doesn't lend itself to >adding a generic SASL or GSS-API negotiation on top of it, that is >something that could be worked on. However, such an HTTP update could >be done independently of a simple replacement for Basic/Digest like >SCRAM. Yes. HTTP tends to deal fairly poorly with multi-round-trip authentication exchanges. It tends to deal poorly with authentication prior to disclosing the URI you want to access. From jhutz@cmu.edu Tue May 15 12:21:50 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03CBB21F88BA for ; Tue, 15 May 2012 12:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRCXUvDK7QxG for ; Tue, 15 May 2012 12:21:49 -0700 (PDT) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by ietfa.amsl.com (Postfix) with ESMTP id 5372421F88B9 for ; Tue, 15 May 2012 12:21:49 -0700 (PDT) Received: from [192.168.33.124] (c-67-165-85-247.hsd1.pa.comcast.net [67.165.85.247]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id q4FJLlZu003390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 May 2012 15:21:48 -0400 (EDT) From: Jeffrey Hutzelman To: Simon Josefsson In-Reply-To: <87likt714d.fsf@latte.josefsson.org> References: <14A09626-8397-4656-A042-FEFDDD017C9F@mnot.net> <4DAC6FBC-3E6D-4CD1-9B5C-0CA5986169A5@mnot.net> <15942_1337100095_q4FGfYs7026806_410AB643-F18B-47F1-926E-9D34A1EE24DD@vpnc.org> <1337101616.3244.206.camel@destiny.pc.cs.cmu.edu> <87likt714d.fsf@latte.josefsson.org> Content-Type: text/plain; charset="UTF-8" Date: Tue, 15 May 2012 15:21:49 -0400 Message-ID: <1337109709.3244.209.camel@destiny.pc.cs.cmu.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Cc: IETF Security Area Advisory Group , Paul Hoffman , jhutz@cmu.edu Subject: Re: [saag] Reminder: Call for Proposals - HTTP/2.0 and HTTP Authentication X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 19:21:50 -0000 On Tue, 2012-05-15 at 20:25 +0200, Simon Josefsson wrote: > Jeffrey Hutzelman writes: > > > On Tue, 2012-05-15 at 09:41 -0700, Paul Hoffman wrote: > >> On May 15, 2012, at 9:33 AM, Nico Williams wrote: > >> > Personally I continue to believe that there will not be a single > >> > authentication mechanism that satisfies all users' needs, so I will > >> > continue to argue for pluggable frameworks. However, I'm less > >> > interested in this than I am in the analysis at this point. > >> > >> We already have a pluggable framework; if it needs changes, letting the > >> httpbis WG know that early would be important. > > > > Yeah; this is kind of poor. Instead of inventing a new framework, why > > not reuse an existing one? The whole point of frameworks like SASL is > > to _avoid_ having every application protocol have its own framework and > > its own set of mechanisms. > > I think Paul meant the HTTP authentication framework (401), whereas you > and Nico seems to think of SASL and GSS-API. No; I think all three of us are talking about what HTTP/2.0 should look like, since that's the topic of this thread. -- Jeff From paul.hoffman@vpnc.org Tue May 15 12:35:33 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35B4721F8895 for ; Tue, 15 May 2012 12:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sLai+qL0uhqc for ; Tue, 15 May 2012 12:35:32 -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 9880F21F882D for ; Tue, 15 May 2012 12:35:32 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q4FJZRZX010422 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 15 May 2012 12:35:28 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <1337109709.3244.209.camel@destiny.pc.cs.cmu.edu> Date: Tue, 15 May 2012 12:35:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5A45EDCD-1A34-4F6C-BE59-532045796509@vpnc.org> References: <14A09626-8397-4656-A042-FEFDDD017C9F@mnot.net> <4DAC6FBC-3E6D-4CD1-9B5C-0CA5986169A5@mnot.net> <15942_1337100095_q4FGfYs7026806_410AB643-F18B-47F1-926E-9D34A1EE24DD@vpnc.org> <1337101616.3244.206.camel@destiny.pc.cs.cmu.edu> <87likt714d.fsf@latte.josefsson.org> <1337109709.3244.209.camel@destiny.pc.cs.cmu.edu> To: Jeffrey Hutzelman X-Mailer: Apple Mail (2.1278) Cc: Simon Josefsson , IETF Security Area Advisory Group Subject: Re: [saag] Reminder: Call for Proposals - HTTP/2.0 and HTTP Authentication X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 19:35:33 -0000 On May 15, 2012, at 12:21 PM, Jeffrey Hutzelman wrote: > On Tue, 2012-05-15 at 20:25 +0200, Simon Josefsson wrote: >> Jeffrey Hutzelman writes: >>=20 >>> On Tue, 2012-05-15 at 09:41 -0700, Paul Hoffman wrote: >>>> On May 15, 2012, at 9:33 AM, Nico Williams wrote: >>>>> Personally I continue to believe that there will not be a single >>>>> authentication mechanism that satisfies all users' needs, so I = will >>>>> continue to argue for pluggable frameworks. However, I'm less >>>>> interested in this than I am in the analysis at this point. >>>>=20 >>>> We already have a pluggable framework; if it needs changes, letting = the >>>> httpbis WG know that early would be important. >>>=20 >>> Yeah; this is kind of poor. Instead of inventing a new framework, = why >>> not reuse an existing one? The whole point of frameworks like SASL = is >>> to _avoid_ having every application protocol have its own framework = and >>> its own set of mechanisms. >>=20 >> I think Paul meant the HTTP authentication framework (401), whereas = you >> and Nico seems to think of SASL and GSS-API. >=20 > No; I think all three of us are talking about what HTTP/2.0 should = look > like, since that's the topic of this thread. Simon is correct. There is already a pluggable HTTP authentication = framework in HTTP 1.1. Is there any need to update that framework for = the kinds of things that we would want to plug into HTTP 2.0? --Paul Hoffman From nico@cryptonector.com Tue May 15 12:37:48 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42C9411E8072 for ; Tue, 15 May 2012 12:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YikwOHD46Ax8 for ; Tue, 15 May 2012 12:37:47 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id BC3B821F885C for ; Tue, 15 May 2012 12:37:47 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 635A56B007E for ; Tue, 15 May 2012 12:37:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=ffRSvE6oJ8JqcFg4TiG0o 2pPc4FDtPDcjaJ0B9T+UvVeBLvcoNY5LLR9Bw7B+omyI+AkkYl+qzf1YEPG0fSu2 gUw4cCxY4mQph8pzDhbZkeRC6A6+nsAHKXS0tp06sGWYrnJJ5znLdue+J+4vna1j iNq2d7f7i4y4d12Ayl2zW8= 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=1qLcedt+/QfqVnVI9Aay nCbSfWw=; b=tcDXpbk6yv5qVlsumX4HDOaWWIlErJVAVHKBKl0bBrpgxmoArn5N EJE1FAJZef7ZJkLl5TDDkoIRqdEGlCQpQ993lRpaormW9O8S6z6qLAmNxnMVn7r+ 3al8wGMmPokvkAKX5AhkRKrFWLztUTGnfpZUBWCbWk8BArcGMovcIz4= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id 3E32E6B007C for ; Tue, 15 May 2012 12:37:47 -0700 (PDT) Received: by dacx6 with SMTP id x6so8006111dac.31 for ; Tue, 15 May 2012 12:37:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.237.166 with SMTP id vd6mr8394748pbc.139.1337110666795; Tue, 15 May 2012 12:37:46 -0700 (PDT) Received: by 10.68.5.99 with HTTP; Tue, 15 May 2012 12:37:46 -0700 (PDT) In-Reply-To: <5A45EDCD-1A34-4F6C-BE59-532045796509@vpnc.org> References: <14A09626-8397-4656-A042-FEFDDD017C9F@mnot.net> <4DAC6FBC-3E6D-4CD1-9B5C-0CA5986169A5@mnot.net> <15942_1337100095_q4FGfYs7026806_410AB643-F18B-47F1-926E-9D34A1EE24DD@vpnc.org> <1337101616.3244.206.camel@destiny.pc.cs.cmu.edu> <87likt714d.fsf@latte.josefsson.org> <1337109709.3244.209.camel@destiny.pc.cs.cmu.edu> <5A45EDCD-1A34-4F6C-BE59-532045796509@vpnc.org> Date: Tue, 15 May 2012 14:37:46 -0500 Message-ID: From: Nico Williams To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Cc: Simon Josefsson , IETF Security Area Advisory Group , Jeffrey Hutzelman Subject: Re: [saag] Reminder: Call for Proposals - HTTP/2.0 and HTTP Authentication X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 19:37:48 -0000 On Tue, May 15, 2012 at 2:35 PM, Paul Hoffman wrote: > Simon is correct. There is already a pluggable HTTP authentication framework in HTTP 1.1. Is there any need to update that framework for the kinds of things that we would want to plug into HTTP 2.0? See Sam's response. I'll go further and argue that HTTP is the wrong layer for user authentication. I'm not prepared to argue that today, but I will in my submissions (I do, too, in REST-GSS, though I need to strengthen the arguments presented there). Nico -- From simon@josefsson.org Tue May 15 12:52:58 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAEE011E80A5 for ; Tue, 15 May 2012 12:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.831 X-Spam-Level: X-Spam-Status: No, score=-99.831 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VazY4dCQn9cy for ; Tue, 15 May 2012 12:52:58 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 863C111E8072 for ; Tue, 15 May 2012 12:52:57 -0700 (PDT) Received: from latte (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q4FJqUlp025805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 15 May 2012 21:52:31 +0200 From: Simon Josefsson To: Nico Williams References: <14A09626-8397-4656-A042-FEFDDD017C9F@mnot.net> <4DAC6FBC-3E6D-4CD1-9B5C-0CA5986169A5@mnot.net> <15942_1337100095_q4FGfYs7026806_410AB643-F18B-47F1-926E-9D34A1EE24DD@vpnc.org> <1337101616.3244.206.camel@destiny.pc.cs.cmu.edu> <87likt714d.fsf@latte.josefsson.org> <1337109709.3244.209.camel@destiny.pc.cs.cmu.edu> <5A45EDCD-1A34-4F6C-BE59-532045796509@vpnc.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120515:saag@ietf.org::8Z0VtfMON238TEYG:0z7h X-Hashcash: 1:22:120515:paul.hoffman@vpnc.org::CR7BYWFpZdo0jjly:0AqJ X-Hashcash: 1:22:120515:nico@cryptonector.com::lBTl7XGB7rPbf7fH:0sXK X-Hashcash: 1:22:120515:jhutz@cmu.edu::baLSVrbnFQenAETl:91wk Date: Tue, 15 May 2012 21:52:29 +0200 In-Reply-To: (Nico Williams's message of "Tue, 15 May 2012 14:37:46 -0500") Message-ID: <87y5ot5iiq.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: Jeffrey Hutzelman , Paul Hoffman , IETF Security Area Advisory Group Subject: Re: [saag] Reminder: Call for Proposals - HTTP/2.0 and HTTP Authentication X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 19:52:58 -0000 Nico Williams writes: > On Tue, May 15, 2012 at 2:35 PM, Paul Hoffman wrote: >> Simon is correct. There is already a pluggable HTTP authentication >> framework in HTTP 1.1. Is there any need to update that framework >> for the kinds of things that we would want to plug into HTTP 2.0? > > See Sam's response. I'll go further and argue that HTTP is the wrong > layer for user authentication. I'm not prepared to argue that today, > but I will in my submissions (I do, too, in REST-GSS, though I need to > strengthen the arguments presented there). I agree that HTTP is the wrong layer for user authentication in most common use cases -- I have seen people from different backgrounds come to that conclusion after trying to get it to work and eventually failing, sometimes a couple of times. It would be useful to have a good writeup to point at to explain the issue. For that matter, authentication via TLS (i.e., HTTPS) is also often the wrong layer for user authentication. However, and this is important, the HTTP authentication framework is still useful for some use-cases (e.g., device authentication, non-web protocols layered on top off HTTP, simple websites), and further, it is so widely used, that I believe a simple drop-in update for HTTP-Digest is warranted and will be useful during a transition to something better. /Simon From nico@cryptonector.com Tue May 15 12:59:11 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99FFD21F86AD for ; Tue, 15 May 2012 12:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.822 X-Spam-Level: X-Spam-Status: No, score=-1.822 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sKvWQB228G52 for ; Tue, 15 May 2012 12:59:11 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 10BE821F867F for ; Tue, 15 May 2012 12:59:11 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id CF0BE58406A for ; Tue, 15 May 2012 12:59:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=xd0P1/Cd9xOGUQybg5zdFWP49Uc6KKlkjwSnZQyKNSFU lq5jdw2hXhq+cQF2iziJyIAJlyXxebjHJl5b3oH8eG0+VHuus3mPD2TVuphVm/ed Tn/FYXERAuxNZyBB4WDAcOZkEw7bC2ZznRrbPcGuT+rdX+vaVYsAA/qVbjinLN4= 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:content-transfer-encoding; s= cryptonector.com; bh=KA8/pygSKhZWC/t/Hu6VirokTEI=; b=pc+eAL6WUto Z/pf+s8KH5Of3SleWy/AdHO8da0QYwYOvqwxjj+wmBLHwZqIRZGxfnNF8YpSxzAf cMo6KdwMLRenqzCGA9Qf/ZuCUulDFNw4n7df+pMFWMCTeopDZHQLYf6pye5e1t3v wNl5IEFNGKAK3wo78B+l2zxbhNAzn+Pk= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTPSA id BE463584065 for ; Tue, 15 May 2012 12:59:10 -0700 (PDT) Received: by dacx6 with SMTP id x6so8030829dac.31 for ; Tue, 15 May 2012 12:59:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.231.164 with SMTP id th4mr8656896pbc.97.1337111950430; Tue, 15 May 2012 12:59:10 -0700 (PDT) Received: by 10.68.5.99 with HTTP; Tue, 15 May 2012 12:59:10 -0700 (PDT) In-Reply-To: <87y5ot5iiq.fsf@latte.josefsson.org> References: <14A09626-8397-4656-A042-FEFDDD017C9F@mnot.net> <4DAC6FBC-3E6D-4CD1-9B5C-0CA5986169A5@mnot.net> <15942_1337100095_q4FGfYs7026806_410AB643-F18B-47F1-926E-9D34A1EE24DD@vpnc.org> <1337101616.3244.206.camel@destiny.pc.cs.cmu.edu> <87likt714d.fsf@latte.josefsson.org> <1337109709.3244.209.camel@destiny.pc.cs.cmu.edu> <5A45EDCD-1A34-4F6C-BE59-532045796509@vpnc.org> <87y5ot5iiq.fsf@latte.josefsson.org> Date: Tue, 15 May 2012 14:59:10 -0500 Message-ID: From: Nico Williams To: Simon Josefsson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Jeffrey Hutzelman , Paul Hoffman , IETF Security Area Advisory Group Subject: Re: [saag] Reminder: Call for Proposals - HTTP/2.0 and HTTP Authentication X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 19:59:11 -0000 On Tue, May 15, 2012 at 2:52 PM, Simon Josefsson wrot= e: > I agree that HTTP is the wrong layer for user authentication in most > common use cases -- I have seen people from different backgrounds come > to that conclusion after trying to get it to work and eventually > failing, sometimes a couple of times. =C2=A0It would be useful to have a = good > writeup to point at to explain the issue. =C2=A0For that matter, > authentication via TLS (i.e., HTTPS) is also often the wrong layer for > user authentication. Yes, TLS is also the wrong layer. I think the truth is that the transport layer (TLS or HTTP in this case) is always the best layer for cryptographic session protection (and since TLS does this well enough, TLS is it), but the application layer is almost always the best layer for user authentication. This is not safe to do without either a) strong enough server authentication in the transport (TLS) or b) channel binding (with mutual authentication at the app layer). > However, and this is important, the HTTP authentication framework is > still useful for some use-cases (e.g., device authentication, non-web > protocols layered on top off HTTP, simple websites), and further, it is > so widely used, that I believe a simple drop-in update for HTTP-Digest > is warranted and will be useful during a transition to something better. I don't agree. I believe that a standard pattern of application-layer authentication can address all those use cases too. Nico -- From hartmans@mit.edu Tue May 15 13:03:07 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A14321F871A for ; Tue, 15 May 2012 13:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.687 X-Spam-Level: X-Spam-Status: No, score=-102.687 tagged_above=-999 required=5 tests=[AWL=-0.422, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynEvXofo2Pgy for ; Tue, 15 May 2012 13:03:06 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id A814F21F8715 for ; Tue, 15 May 2012 13:03:06 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id CA16A203C0; Tue, 15 May 2012 15:58:48 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6D21644B1; Tue, 15 May 2012 16:02:47 -0400 (EDT) From: Sam Hartman To: Nico Williams References: <14A09626-8397-4656-A042-FEFDDD017C9F@mnot.net> <4DAC6FBC-3E6D-4CD1-9B5C-0CA5986169A5@mnot.net> <15942_1337100095_q4FGfYs7026806_410AB643-F18B-47F1-926E-9D34A1EE24DD@vpnc.org> <1337101616.3244.206.camel@destiny.pc.cs.cmu.edu> <87likt714d.fsf@latte.josefsson.org> <1337109709.3244.209.camel@destiny.pc.cs.cmu.edu> <5A45EDCD-1A34-4F6C-BE59-532045796509@vpnc.org> <87y5ot5iiq.fsf@latte.josefsson.org> Date: Tue, 15 May 2012 16:02:47 -0400 In-Reply-To: (Nico Williams's message of "Tue, 15 May 2012 14:59:10 -0500") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Simon Josefsson , Paul Hoffman , IETF Security Area Advisory Group , Jeffrey Hutzelman Subject: Re: [saag] Reminder: Call for Proposals - HTTP/2.0 and HTTP Authentication X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 20:03:07 -0000 >>>>> "Nico" == Nico Williams writes: >> However, and this is important, the HTTP authentication framework >> is still useful for some use-cases (e.g., device authentication, >> non-web protocols layered on top off HTTP, simple websites), and >> further, it is so widely used, that I believe a simple drop-in >> update for HTTP-Digest is warranted and will be useful during a >> transition to something better. Nico> I don't agree. I believe that a standard pattern of Nico> application-layer authentication can address all those use Nico> cases too. Nico and I disagree here. I think that http authentication is more or less the right layer for webdav, atompub, and some HTTP-based RPC layer authentications. I don't care about digest, but I do care about getting the HTTP framework right for these use cases. From nico@cryptonector.com Tue May 15 13:04:21 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0C2021F8815 for ; Tue, 15 May 2012 13:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.825 X-Spam-Level: X-Spam-Status: No, score=-1.825 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1aC1pfniU3h7 for ; Tue, 15 May 2012 13:04:21 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 09AE721F871C for ; Tue, 15 May 2012 13:04:21 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id CFDD159405E for ; Tue, 15 May 2012 13:04:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=sEge62/s6r6+dRAM3BTZZw9NOf7NBhMz4yImGUH4zsVR l6x4rA/lVUemVBvEsOCwmKxFnyLSkyKGjrx6Sltk+4J4qShutxuia0ltPJQU0o5h bkzdyJWWnUXjGGE1XZZDyOIZsdi+Wd+yeguNLhDrrmCmj1QoJCUDE/oDvRy+agQ= 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:content-transfer-encoding; s= cryptonector.com; bh=STWpoKc/ehH5emO/YEck6oIzaAg=; b=fL60gv4xHM8 R2DITvlbLjCxCa0gv8YK5G7YbfVw3lqW5dFct0AEkrk5pWXLH64Jqe077pRwBWyV jMtxYmZdhU42Cg/3IUGvGUOTQItWUfW5GSVCDMA8u4jNQwNvTE4Mau39LFsY4LBN wQcBXyWSz1DxlohMbAsp+Tqye7TKyKVo= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPSA id ADEF4594062 for ; Tue, 15 May 2012 13:04:20 -0700 (PDT) Received: by dacx6 with SMTP id x6so8037149dac.31 for ; Tue, 15 May 2012 13:04:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.231.164 with SMTP id th4mr8703354pbc.97.1337112260163; Tue, 15 May 2012 13:04:20 -0700 (PDT) Received: by 10.68.5.99 with HTTP; Tue, 15 May 2012 13:04:20 -0700 (PDT) In-Reply-To: References: <14A09626-8397-4656-A042-FEFDDD017C9F@mnot.net> <4DAC6FBC-3E6D-4CD1-9B5C-0CA5986169A5@mnot.net> <15942_1337100095_q4FGfYs7026806_410AB643-F18B-47F1-926E-9D34A1EE24DD@vpnc.org> <1337101616.3244.206.camel@destiny.pc.cs.cmu.edu> <87likt714d.fsf@latte.josefsson.org> <1337109709.3244.209.camel@destiny.pc.cs.cmu.edu> <5A45EDCD-1A34-4F6C-BE59-532045796509@vpnc.org> <87y5ot5iiq.fsf@latte.josefsson.org> Date: Tue, 15 May 2012 15:04:20 -0500 Message-ID: From: Nico Williams To: Simon Josefsson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Jeffrey Hutzelman , Paul Hoffman , IETF Security Area Advisory Group Subject: Re: [saag] Reminder: Call for Proposals - HTTP/2.0 and HTTP Authentication X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 20:04:21 -0000 On Tue, May 15, 2012 at 2:59 PM, Nico Williams wrot= e: > On Tue, May 15, 2012 at 2:52 PM, Simon Josefsson wr= ote: >> However, and this is important, the HTTP authentication framework is >> still useful for some use-cases (e.g., device authentication, non-web >> protocols layered on top off HTTP, simple websites), and further, it is >> so widely used, that I believe a simple drop-in update for HTTP-Digest >> is warranted and will be useful during a transition to something better. > > I don't agree. =C2=A0I believe that a standard pattern of application-lay= er > authentication can address all those use cases too. I should add that if that's true (that we can have a standard app-layer pattern) then it's a useful simplification to just not have any user authentication in HTTP/2.0. Simple is usually better. From smb@cs.columbia.edu Tue May 15 13:04:33 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2BF011E808C for ; Tue, 15 May 2012 13:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.932 X-Spam-Level: X-Spam-Status: No, score=-5.932 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kEkD4PPoFVg for ; Tue, 15 May 2012 13:04:33 -0700 (PDT) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by ietfa.amsl.com (Postfix) with ESMTP id DB04F11E8089 for ; Tue, 15 May 2012 13:04:32 -0700 (PDT) Received: from [192.168.2.166] (74-92-112-54-Philadelphia.hfc.comcastbusiness.net [74.92.112.54]) (user=smb2132 mech=PLAIN bits=0) by tarap.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id q4FK4RbF024595 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 15 May 2012 16:04:28 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Steven Bellovin In-Reply-To: Date: Tue, 15 May 2012 16:04:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <914C5C50-3D86-49AD-8670-7235A1E7F4AE@cs.columbia.edu> References: <14A09626-8397-4656-A042-FEFDDD017C9F@mnot.net> <4DAC6FBC-3E6D-4CD1-9B5C-0CA5986169A5@mnot.net> <15942_1337100095_q4FGfYs7026806_410AB643-F18B-47F1-926E-9D34A1EE24DD@vpnc.org> <1337101616.3244.206.camel@destiny.pc.cs.cmu.edu> <87likt714d.fsf@latte.josefsson.org> <1337109709.3244.209.camel@destiny.pc.cs.cmu.edu> <5A45EDCD-1A34-4F6C-BE59-532045796509@vpnc.org> To: Nico Williams X-Mailer: Apple Mail (2.1278) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7 Cc: Simon Josefsson , Jeffrey Hutzelman , Paul Hoffman , IETF Security Area Advisory Group Subject: Re: [saag] Reminder: Call for Proposals - HTTP/2.0 and HTTP Authentication X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 20:04:33 -0000 On May 15, 2012, at 3:37 46PM, Nico Williams wrote: > On Tue, May 15, 2012 at 2:35 PM, Paul Hoffman = wrote: >> Simon is correct. There is already a pluggable HTTP authentication = framework in HTTP 1.1. Is there any need to update that framework for = the kinds of things that we would want to plug into HTTP 2.0? >=20 > See Sam's response. I'll go further and argue that HTTP is the wrong > layer for user authentication.=20 Yup. *No* major site uses it; everyone some roll-your-own scheme that provides for (a) passwords; (b) password recovery/reset, and (c) a *pretty* login screen. This last is probably the most important issue. Any schemes that do not satisfy all three needs will fail in the marketplace. I conclude from this that the correct solution probably involves some interaction between HTML and HTTP, with the security area goo hidden underneath a very large rock that very few sites will bother to lift -- they're more or less happy with passwords... --Steve Bellovin, https://www.cs.columbia.edu/~smb From nico@cryptonector.com Tue May 15 13:05:45 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4900421F886F for ; Tue, 15 May 2012 13:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.827 X-Spam-Level: X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kA4ROEc0YDcn for ; Tue, 15 May 2012 13:05:44 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id CE17521F8849 for ; Tue, 15 May 2012 13:05:44 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id 9D94467C06E for ; Tue, 15 May 2012 13:05:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=kB7uTggebfWaOhxYuTwSW05o3r8ZVt3ZHyUdyPaWHfVe VgQd9n6fmzftv+gYHt/T67CEZERMY5wfr9BipZNQ7EhVAiAd8ch78kLhhGoc8RVE +qstvdfi07FV/nl1L2tKs2b0OFORInXh6OS5qicwZvAuuI/4AAIfwn2EyXmdUPU= 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:content-transfer-encoding; s= cryptonector.com; bh=1kQaPtirEhVbBdJiJq2adJxq/js=; b=INJjVzSwkgf 0qwz4mhYBcZ7CZwYAmHI43eh97DNsz/jvBM6JTJ0cMBFnm6v4Q1hu+t76jnE55hM Wi0BpYUVUjJ07o1sqEQvuyCU7D3jgdGwqIUADFzoTA0iR3z024cXr3fv6NLTXXA6 BU5t1+j4zPaVY2eM6nbLX5duPDd/G4d0= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPSA id 822BF67C06D for ; Tue, 15 May 2012 13:05:44 -0700 (PDT) Received: by dacx6 with SMTP id x6so8038754dac.31 for ; Tue, 15 May 2012 13:05:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.132.201 with SMTP id ow9mr8581665pbb.160.1337112344171; Tue, 15 May 2012 13:05:44 -0700 (PDT) Received: by 10.68.5.99 with HTTP; Tue, 15 May 2012 13:05:44 -0700 (PDT) In-Reply-To: References: <14A09626-8397-4656-A042-FEFDDD017C9F@mnot.net> <4DAC6FBC-3E6D-4CD1-9B5C-0CA5986169A5@mnot.net> <15942_1337100095_q4FGfYs7026806_410AB643-F18B-47F1-926E-9D34A1EE24DD@vpnc.org> <1337101616.3244.206.camel@destiny.pc.cs.cmu.edu> <87likt714d.fsf@latte.josefsson.org> <1337109709.3244.209.camel@destiny.pc.cs.cmu.edu> <5A45EDCD-1A34-4F6C-BE59-532045796509@vpnc.org> <87y5ot5iiq.fsf@latte.josefsson.org> Date: Tue, 15 May 2012 15:05:44 -0500 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Simon Josefsson , Paul Hoffman , IETF Security Area Advisory Group , Jeffrey Hutzelman Subject: Re: [saag] Reminder: Call for Proposals - HTTP/2.0 and HTTP Authentication X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 20:05:45 -0000 On Tue, May 15, 2012 at 3:02 PM, Sam Hartman wrote: > =C2=A0 =C2=A0Nico> I don't agree. =C2=A0I believe that a standard pattern= of > =C2=A0 =C2=A0Nico> application-layer authentication can address all those= use > =C2=A0 =C2=A0Nico> cases too. > > Nico and I disagree here. > I think that http authentication is more or less the right layer for > webdav, atompub, and some HTTP-based RPC layer authentications. It's not that HTTP-layer user authentication is not appropriate. Rather, app-layer user authentication would work just as well for these apps. Given that I'd rather not have to design and implement user authentication at two layers. Nico -- From hartmans@mit.edu Tue May 15 13:08:44 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E219C21F8873 for ; Tue, 15 May 2012 13:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.677 X-Spam-Level: X-Spam-Status: No, score=-102.677 tagged_above=-999 required=5 tests=[AWL=-0.412, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RDjYcWSo9c+C for ; Tue, 15 May 2012 13:08:44 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 77F2E21F8872 for ; Tue, 15 May 2012 13:08:44 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 4A70120383; Tue, 15 May 2012 16:04:26 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 46C4844B1; Tue, 15 May 2012 16:08:25 -0400 (EDT) From: Sam Hartman To: Nico Williams References: <14A09626-8397-4656-A042-FEFDDD017C9F@mnot.net> <4DAC6FBC-3E6D-4CD1-9B5C-0CA5986169A5@mnot.net> <15942_1337100095_q4FGfYs7026806_410AB643-F18B-47F1-926E-9D34A1EE24DD@vpnc.org> <1337101616.3244.206.camel@destiny.pc.cs.cmu.edu> <87likt714d.fsf@latte.josefsson.org> <1337109709.3244.209.camel@destiny.pc.cs.cmu.edu> <5A45EDCD-1A34-4F6C-BE59-532045796509@vpnc.org> <87y5ot5iiq.fsf@latte.josefsson.org> Date: Tue, 15 May 2012 16:08:25 -0400 In-Reply-To: (Nico Williams's message of "Tue, 15 May 2012 15:05:44 -0500") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Simon Josefsson , Sam Hartman , Paul Hoffman , IETF Security Area Advisory Group , Jeffrey Hutzelman Subject: Re: [saag] Reminder: Call for Proposals - HTTP/2.0 and HTTP Authentication X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 20:08:45 -0000 >>>>> "Nico" == Nico Williams writes: Nico> On Tue, May 15, 2012 at 3:02 PM, Sam Hartman wrote: >>    Nico> I don't agree.  I believe that a >> standard pattern of    Nico> application-layer >> authentication can address all those use    Nico> >> cases too. >> >> Nico and I disagree here. I think that http authentication is >> more or less the right layer for webdav, atompub, and some >> HTTP-based RPC layer authentications. Nico> It's not that HTTP-layer user authentication is not Nico> appropriate. Rather, app-layer user authentication would work Nico> just as well for these apps. Given that I'd rather not have Nico> to design and implement user authentication at two layers. The problem is that these app protocols do not currently support authentication. Including authentication in an app-protocol well does take work. And I believe that fixing the deficiencies in the HTTP framework is easier than adding app layer authentication to all of these protocols. From nico@cryptonector.com Tue May 15 13:11:37 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73A3021F8881 for ; Tue, 15 May 2012 13:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.829 X-Spam-Level: X-Spam-Status: No, score=-1.829 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LRi2Tt39JJq2 for ; Tue, 15 May 2012 13:11:31 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 07C3121F8873 for ; Tue, 15 May 2012 13:11:31 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTP id C714A3B8076 for ; Tue, 15 May 2012 13:11:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=ioyTJZ6ptoSjbIeJYHv6s4JRWNlNPGn3nH5uxrJzeh8X Vc1XejeflZcYhoPSBRnyxJau/ItqOdSmsPWzlx2UMfz7Owkvo7nOBN5SvkOj4KoR DnRhVt3jn+PWcLzp+e8RVbR3wgMgEuMqc1ipuSoMWteHClCvuHxTRrhhGST7pzk= 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:content-transfer-encoding; s= cryptonector.com; bh=b1j0sQa21zoNk+avMd+o48R+NEE=; b=E+wZHeGzsnw OlFkWgypyqesTsLfai2KyRbpiUHGCjL6scSzQMK7nnXWeGwMm8HbwTfkVdhEjqVW zYdJ7MSoKfN+vM/ZatLFMJ1jvE7WfROQbLH8NKCByjHp/0UxgIZqP//yTeuygdhK fYTJcvCmsyCUxOJlg0DZpVu93tjE5crI= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTPSA id B29783B8072 for ; Tue, 15 May 2012 13:11:30 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so90683pbc.31 for ; Tue, 15 May 2012 13:11:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.231.164 with SMTP id th4mr8765088pbc.97.1337112690375; Tue, 15 May 2012 13:11:30 -0700 (PDT) Received: by 10.68.5.99 with HTTP; Tue, 15 May 2012 13:11:30 -0700 (PDT) In-Reply-To: References: <14A09626-8397-4656-A042-FEFDDD017C9F@mnot.net> <4DAC6FBC-3E6D-4CD1-9B5C-0CA5986169A5@mnot.net> <15942_1337100095_q4FGfYs7026806_410AB643-F18B-47F1-926E-9D34A1EE24DD@vpnc.org> <1337101616.3244.206.camel@destiny.pc.cs.cmu.edu> <87likt714d.fsf@latte.josefsson.org> <1337109709.3244.209.camel@destiny.pc.cs.cmu.edu> <5A45EDCD-1A34-4F6C-BE59-532045796509@vpnc.org> <87y5ot5iiq.fsf@latte.josefsson.org> Date: Tue, 15 May 2012 15:11:30 -0500 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Simon Josefsson , Paul Hoffman , IETF Security Area Advisory Group , Jeffrey Hutzelman Subject: Re: [saag] Reminder: Call for Proposals - HTTP/2.0 and HTTP Authentication X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 20:11:37 -0000 On Tue, May 15, 2012 at 3:08 PM, Sam Hartman wrote: >>>>>> "Nico" =3D=3D Nico Williams writes: > =C2=A0 =C2=A0Nico> It's not that HTTP-layer user authentication is not > =C2=A0 =C2=A0Nico> appropriate. =C2=A0Rather, app-layer user authenticati= on would work > =C2=A0 =C2=A0Nico> just as well for these apps. =C2=A0Given that I'd rath= er not have > =C2=A0 =C2=A0Nico> to design and implement user authentication at two lay= ers. > > The problem is that these app protocols do not currently support > authentication. > Including authentication in an app-protocol well does take work. > And I believe that fixing the deficiencies in the HTTP framework is > easier than adding app layer authentication to all of these protocols. I grant this, but I think the solution is to implement a common HTTP app-layer authentication facility as a library that all these apps can easily implement. Note that for most non-web HTTP apps there's really very little difference between HTTP-layer and app-layer user authentication. In all cases developers will want the user authentication abstracted by a nice API. It's the web applications where the difference between the two layers becomes stark. Nico -- From nico@cryptonector.com Tue May 15 13:13:04 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9758221F87F8 for ; Tue, 15 May 2012 13:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.832 X-Spam-Level: X-Spam-Status: No, score=-1.832 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FoS60ZkOHWzz for ; Tue, 15 May 2012 13:13:03 -0700 (PDT) Received: from homiemail-a65.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id BCB1721F8836 for ; Tue, 15 May 2012 13:13:03 -0700 (PDT) Received: from homiemail-a65.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTP id 5A21C7E4073 for ; Tue, 15 May 2012 13:13:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=cHexMltyXjG2g3zwJNp2Up3OVdNmndmT7PbOtuXhfbIS 86JZajqKhP5ljcHYH3/+9XOmWr+NjtAMCfvWA3NTBlU1TYzHoe4651mSuKxRGMct sqRTW+gm4cCh0SgAaWBoXzwefs5/pr/cPLvOx3b/R0jBUvOasQMZMkQauckHFvk= 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:content-transfer-encoding; s= cryptonector.com; bh=Ekh0rUUaJ7T+5BkSSA2zZZ9MxOA=; b=I9puiG+1ivB E38Cp5KnZOVX06sixifmTDGLC/ghaMmJrs5pn3XTFckeuLGkNqNEY0VCDd1QyTCS ntdv3zr11V6qoKBBuSJMhhFmqpQHdJjKV3d1lFqLvJz7E2k+2OlXVhaUDe782mYt MDRaO1KZnDIKqO7Tr65yqkP5X8qtomxE= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTPSA id 34FD57E4065 for ; Tue, 15 May 2012 13:13:03 -0700 (PDT) Received: by dacx6 with SMTP id x6so8046802dac.31 for ; Tue, 15 May 2012 13:13:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.231.164 with SMTP id th4mr8778364pbc.97.1337112782805; Tue, 15 May 2012 13:13:02 -0700 (PDT) Received: by 10.68.5.99 with HTTP; Tue, 15 May 2012 13:13:02 -0700 (PDT) In-Reply-To: <914C5C50-3D86-49AD-8670-7235A1E7F4AE@cs.columbia.edu> References: <14A09626-8397-4656-A042-FEFDDD017C9F@mnot.net> <4DAC6FBC-3E6D-4CD1-9B5C-0CA5986169A5@mnot.net> <15942_1337100095_q4FGfYs7026806_410AB643-F18B-47F1-926E-9D34A1EE24DD@vpnc.org> <1337101616.3244.206.camel@destiny.pc.cs.cmu.edu> <87likt714d.fsf@latte.josefsson.org> <1337109709.3244.209.camel@destiny.pc.cs.cmu.edu> <5A45EDCD-1A34-4F6C-BE59-532045796509@vpnc.org> <914C5C50-3D86-49AD-8670-7235A1E7F4AE@cs.columbia.edu> Date: Tue, 15 May 2012 15:13:02 -0500 Message-ID: From: Nico Williams To: Steven Bellovin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Simon Josefsson , Jeffrey Hutzelman , Paul Hoffman , IETF Security Area Advisory Group Subject: Re: [saag] Reminder: Call for Proposals - HTTP/2.0 and HTTP Authentication X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 20:13:04 -0000 On Tue, May 15, 2012 at 3:04 PM, Steven Bellovin wrot= e: >> See Sam's response. =C2=A0I'll go further and argue that HTTP is the wro= ng >> layer for user authentication. > > Yup. =C2=A0*No* major site uses it; everyone some roll-your-own scheme > that provides for (a) passwords; (b) password recovery/reset, and > (c) a *pretty* login screen. =C2=A0This last is probably the most importa= nt > issue. [...] Note that this means that today apps already do app-layer user authentication. Given the complete disconnect between the transport crypto layer (TLS) and what web apps can manage for app-layer authentication the result is utterly dependent on the TLS server PKI for security. This is true whether the app uses forms with passwords or OAuth, or SAML, or... > [...] Any schemes that do not satisfy all three needs will fail > in the marketplace. =C2=A0I conclude from this that the correct solution > probably involves some interaction between HTML and HTTP, with the > security area goo hidden underneath a very large rock that very > few sites will bother to lift -- they're more or less happy with > passwords... I agree that HTML and/or ECMAScript, and through them the browser user-agent, must play a role in web app-layer user authentication. I'd rather HTTP have no role to play though, except as a transport. Nico -- From simon@josefsson.org Tue May 15 13:14:49 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C563121F8836 for ; Tue, 15 May 2012 13:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.835 X-Spam-Level: X-Spam-Status: No, score=-99.835 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUUcY1-f31f6 for ; Tue, 15 May 2012 13:14:48 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 92F6621F88AD for ; Tue, 15 May 2012 13:14:47 -0700 (PDT) Received: from latte (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q4FKERgF026757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 15 May 2012 22:14:29 +0200 From: Simon Josefsson To: Nico Williams References: <14A09626-8397-4656-A042-FEFDDD017C9F@mnot.net> <4DAC6FBC-3E6D-4CD1-9B5C-0CA5986169A5@mnot.net> <15942_1337100095_q4FGfYs7026806_410AB643-F18B-47F1-926E-9D34A1EE24DD@vpnc.org> <1337101616.3244.206.camel@destiny.pc.cs.cmu.edu> <87likt714d.fsf@latte.josefsson.org> <1337109709.3244.209.camel@destiny.pc.cs.cmu.edu> <5A45EDCD-1A34-4F6C-BE59-532045796509@vpnc.org> <87y5ot5iiq.fsf@latte.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120515:paul.hoffman@vpnc.org::GCG+ssSyrGXYXzsH:5WT X-Hashcash: 1:22:120515:jhutz@cmu.edu::2gDD7BMejQYNii+M:2l/I X-Hashcash: 1:22:120515:saag@ietf.org::KAXgVFY66hxWxL7j:6C8N X-Hashcash: 1:22:120515:nico@cryptonector.com::s8NQrX2aacl0InHB:cPaS Date: Tue, 15 May 2012 22:14:22 +0200 In-Reply-To: (Nico Williams's message of "Tue, 15 May 2012 15:04:20 -0500") Message-ID: <87havh42xt.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: Jeffrey Hutzelman , Paul Hoffman , IETF Security Area Advisory Group Subject: Re: [saag] Reminder: Call for Proposals - HTTP/2.0 and HTTP Authentication X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 20:14:49 -0000 Nico Williams writes: > On Tue, May 15, 2012 at 2:59 PM, Nico Williams wrote: >> On Tue, May 15, 2012 at 2:52 PM, Simon Josefsson wrote: >>> However, and this is important, the HTTP authentication framework is >>> still useful for some use-cases (e.g., device authentication, non-web >>> protocols layered on top off HTTP, simple websites), and further, it is >>> so widely used, that I believe a simple drop-in update for HTTP-Digest >>> is warranted and will be useful during a transition to something better. >> >> I don't agree.  I believe that a standard pattern of application-layer >> authentication can address all those use cases too. > > I should add that if that's true (that we can have a standard > app-layer pattern) then it's a useful simplification to just not have > any user authentication in HTTP/2.0. Simple is usually better. I think that HTTP/2.0 without user authentication makes sense too, although I'm willing to be surprised. The work that I perceive is useful right now would include: a) improvements to HTTP/1.1 authentication framework for the many protocols and applications out there that uses HTTP/1.1 already. (e.g., replace HTTP-Digest with something stronger, either SCRAM natively in HTTP, or SCRAM indirectly via HTTP-GSS) b) recommendations/guidelines on how to do user authentication at the web application layer that enables stronger mechanisms than username/passwords. /Simon From stephen.farrell@cs.tcd.ie Tue May 15 13:19:22 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE9911E808C for ; Tue, 15 May 2012 13:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWfJ8SCN+Pqc for ; Tue, 15 May 2012 13:19:21 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id B3BE711E8073 for ; Tue, 15 May 2012 13:19:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 1EA1C171476; Tue, 15 May 2012 21:19:21 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1337113160; bh=I4wpU9iU7MQmNY ffP0xw0QIr+ZO1VQTVlKPcYGrH2OQ=; b=ICF6hw8TeB/hHbT4p33vX87JLaMzTj llp2ErEu51l7OLmRRjn54Ory0/r5d5JL7IMzUafy2L+qSYtmjx76MHP/0F2scHPS 8PNyNZXSkPgctZXkuVH9ZwIF/rxZGwF436KuveuFpUHWNk5Qxic7EyoSV1X2C0HH VgsggcDTHfzXLy43U9bDvdSPxkkFAIbnd4kbuhw4a2i8lzsLrUhp6uSZHgcg/zzB WPjKsLwe08vTmPv1ZyJUqL2eLKGshkidCXK1cUk8gwptRTaaV+ZF1zd7hNG+lhhH BmeFmA1XglL7HrDkh0tAA0b2jofFRBi2hAqVfRB/pWITeawZJN2yjawQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id bEaXDY-HvuZY; Tue, 15 May 2012 21:19:20 +0100 (IST) Received: from [10.87.48.9] (unknown [86.41.12.219]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 5AA1C171475; Tue, 15 May 2012 21:19:17 +0100 (IST) Message-ID: <4FB2BA45.5070300@cs.tcd.ie> Date: Tue, 15 May 2012 21:19:17 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Nico Williams References: <14A09626-8397-4656-A042-FEFDDD017C9F@mnot.net> <4DAC6FBC-3E6D-4CD1-9B5C-0CA5986169A5@mnot.net> <15942_1337100095_q4FGfYs7026806_410AB643-F18B-47F1-926E-9D34A1EE24DD@vpnc.org> <1337101616.3244.206.camel@destiny.pc.cs.cmu.edu> <87likt714d.fsf@latte.josefsson.org> <1337109709.3244.209.camel@destiny.pc.cs.cmu.edu> <5A45EDCD-1A34-4F6C-BE59-532045796509@vpnc.org> <914C5C50-3D86-49AD-8670-7235A1E7F4AE@cs.columbia.edu> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Simon Josefsson , Jeffrey Hutzelman , Paul Hoffman , IETF Security Area Advisory Group Subject: Re: [saag] Reminder: Call for Proposals - HTTP/2.0 and HTTP Authentication X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 20:19:22 -0000 Just a small reminder of the subject line:-) I'd really like to see some good proposals produced rather than only discuss whether that's perfection or not. (I might even make a proposal of my own if only to flush out better ones:-) If people have additional things they think are also worthwhile, then they can propose those too, on this list or as an I-D. Sean and I are very open to seeing work happen on such things, but that's not the same as the work the httpbis WG are doing now. Cheers, S. From nico@cryptonector.com Tue May 15 13:24:40 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9289C11E80AB for ; Tue, 15 May 2012 13:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.834 X-Spam-Level: X-Spam-Status: No, score=-1.834 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffsUyATi6alV for ; Tue, 15 May 2012 13:24:40 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 161E611E809C for ; Tue, 15 May 2012 13:24:40 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id D5C4C9406D for ; Tue, 15 May 2012 13:24:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=WBfJuQ0L7sCVtGZqsLNFh 92sHxpn/3PuZb1r9mSdWlTOMAOSZkH0fOjTTwMsuVvAxXwgHLsgb3oaqXHqnuGUq S0BtKP+BxscUJriKuQ2ffrPZpq/gKd/B8yBQzA8KXmQO9puyi0p+yQV/6BRRlMeV if8cI8VVuA2IHy43y6HOMY= 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=4GQlki106vhFvnNzLOYC NhkUxJM=; b=na4Xkou8XQFWBKrSzIgZxD9RFd+N0LzOg+n4T2TmUeo0Xr2vM441 gKH+S3Snp1jSg3QP3Aw/ZqRtB57hhwKOOBgVbYPCHHmQso+yMqT1cSFQjfejQVGN dNXEMYwaepmhPUbp/WfftZ7v6HESP3XiyYazLVVTKT71pKDMC8ds0hQ= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPSA id ADA4B94065 for ; Tue, 15 May 2012 13:24:39 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so104893pbc.31 for ; Tue, 15 May 2012 13:24:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.190.137 with SMTP id gq9mr42573pbc.34.1337113479205; Tue, 15 May 2012 13:24:39 -0700 (PDT) Received: by 10.68.5.99 with HTTP; Tue, 15 May 2012 13:24:39 -0700 (PDT) In-Reply-To: <4FB2BA45.5070300@cs.tcd.ie> References: <14A09626-8397-4656-A042-FEFDDD017C9F@mnot.net> <4DAC6FBC-3E6D-4CD1-9B5C-0CA5986169A5@mnot.net> <15942_1337100095_q4FGfYs7026806_410AB643-F18B-47F1-926E-9D34A1EE24DD@vpnc.org> <1337101616.3244.206.camel@destiny.pc.cs.cmu.edu> <87likt714d.fsf@latte.josefsson.org> <1337109709.3244.209.camel@destiny.pc.cs.cmu.edu> <5A45EDCD-1A34-4F6C-BE59-532045796509@vpnc.org> <914C5C50-3D86-49AD-8670-7235A1E7F4AE@cs.columbia.edu> <4FB2BA45.5070300@cs.tcd.ie> Date: Tue, 15 May 2012 15:24:39 -0500 Message-ID: From: Nico Williams To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Cc: Simon Josefsson , Jeffrey Hutzelman , Paul Hoffman , IETF Security Area Advisory Group Subject: Re: [saag] Reminder: Call for Proposals - HTTP/2.0 and HTTP Authentication X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 20:24:40 -0000 On Tue, May 15, 2012 at 3:19 PM, Stephen Farrell wrote: > Just a small reminder of the subject line:-) So you're saying that we should change the subject line? Surely you're not complaining about the sudden interest where there had been none in spite of begging for it! ;) But yes, I agree that it'd be nice to have some I-Ds to discuss. Matters like which layer is best for user authentication don't really have an impact on which authentication mechanisms can be used, so specific proposals for, say, using ZKPPs or whatever, can be made and debated regardless. But the question of which layer to do this in is actually fascinating, critical even. Nico -- From stephen.farrell@cs.tcd.ie Tue May 15 13:26:34 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2DBB11E80B7 for ; Tue, 15 May 2012 13:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QC+bRkJFq76n for ; Tue, 15 May 2012 13:26:34 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 1F80011E80B6 for ; Tue, 15 May 2012 13:26:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 83834171476; Tue, 15 May 2012 21:26:33 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1337113593; bh=dk0lmygdGbwqpa ta1tg4Xx23Dkq12diEPj9EpAq3d4Y=; b=4otwInyv0kYttJ5zjRGvZj+X8rI2uo SyF77aFKBWoIzCEktyv7GiOqEnnWhiCPDcVpYSyJe9TkDEH77Kqhwqvg/LXoE1YY dZscV9/7DnG8P0pScJjsA6TKbgc5YMG0XS8xzXLWAS6zkICG72cpvsm5gIPQbISM aUnU5DEpIwSV2qHv3fL0Z2sOWNfCLMAHygLvzDoeEs+kLfi63o/BXSWfhQQV+xNg jSlxGxKfvSC4VSA+FcvhzEPJ2guTwiUNxRTV7XjQRKZsQ6/jb+XoT8gqw/oAgSy4 qVqp4197YH+rp0XuZ+QltzIXbXIkAd5A/bBzVC1nqT+QXkNoN4CqGDCA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id iJN8cx-Kclcz; Tue, 15 May 2012 21:26:33 +0100 (IST) Received: from [10.87.48.9] (unknown [86.41.12.219]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id D7E54171475; Tue, 15 May 2012 21:26:32 +0100 (IST) Message-ID: <4FB2BBF8.7010607@cs.tcd.ie> Date: Tue, 15 May 2012 21:26:32 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Nico Williams References: <14A09626-8397-4656-A042-FEFDDD017C9F@mnot.net> <4DAC6FBC-3E6D-4CD1-9B5C-0CA5986169A5@mnot.net> <15942_1337100095_q4FGfYs7026806_410AB643-F18B-47F1-926E-9D34A1EE24DD@vpnc.org> <1337101616.3244.206.camel@destiny.pc.cs.cmu.edu> <87likt714d.fsf@latte.josefsson.org> <1337109709.3244.209.camel@destiny.pc.cs.cmu.edu> <5A45EDCD-1A34-4F6C-BE59-532045796509@vpnc.org> <914C5C50-3D86-49AD-8670-7235A1E7F4AE@cs.columbia.edu> <4FB2BA45.5070300@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Simon Josefsson , Jeffrey Hutzelman , Paul Hoffman , IETF Security Area Advisory Group Subject: Re: [saag] Reminder: Call for Proposals - HTTP/2.0 and HTTP Authentication X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 20:26:34 -0000 On 05/15/2012 09:24 PM, Nico Williams wrote: > On Tue, May 15, 2012 at 3:19 PM, Stephen Farrell > wrote: >> Just a small reminder of the subject line:-) > > So you're saying that we should change the subject line? Surely > you're not complaining about the sudden interest where there had been > none in spite of begging for it! ;) :-) > > But yes, I agree that it'd be nice to have some I-Ds to discuss. > Matters like which layer is best for user authentication don't really > have an impact on which authentication mechanisms can be used, so > specific proposals for, say, using ZKPPs or whatever, can be made and > debated regardless. But the question of which layer to do this in is > actually fascinating, critical even. I agree, but am just concerned lest we spend too much effort on that and miss what is a relatively short window during which its likely we might be able to improve HTTP security. S. > > Nico > -- > > From hartmans@mit.edu Tue May 15 13:28:14 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8C5B21F885C for ; Tue, 15 May 2012 13:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.668 X-Spam-Level: X-Spam-Status: No, score=-102.668 tagged_above=-999 required=5 tests=[AWL=-0.403, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QsfdF4RyYVb for ; Tue, 15 May 2012 13:28:14 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 4710421F8850 for ; Tue, 15 May 2012 13:28:14 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 62F7C20383; Tue, 15 May 2012 16:23:56 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 41EE144B1; Tue, 15 May 2012 16:27:54 -0400 (EDT) From: Sam Hartman To: Nico Williams References: <14A09626-8397-4656-A042-FEFDDD017C9F@mnot.net> <4DAC6FBC-3E6D-4CD1-9B5C-0CA5986169A5@mnot.net> <15942_1337100095_q4FGfYs7026806_410AB643-F18B-47F1-926E-9D34A1EE24DD@vpnc.org> <1337101616.3244.206.camel@destiny.pc.cs.cmu.edu> <87likt714d.fsf@latte.josefsson.org> <1337109709.3244.209.camel@destiny.pc.cs.cmu.edu> <5A45EDCD-1A34-4F6C-BE59-532045796509@vpnc.org> <87y5ot5iiq.fsf@latte.josefsson.org> Date: Tue, 15 May 2012 16:27:54 -0400 In-Reply-To: (Nico Williams's message of "Tue, 15 May 2012 15:11:30 -0500") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Simon Josefsson , Sam Hartman , Paul Hoffman , IETF Security Area Advisory Group , Jeffrey Hutzelman Subject: Re: [saag] Reminder: Call for Proposals - HTTP/2.0 and HTTP Authentication X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 20:28:14 -0000 >>>>> "Nico" == Nico Williams writes: Nico> I grant this, but I think the solution is to implement a Nico> common HTTP app-layer authentication facility as a library Nico> that all these apps can easily implement. Nico> Note that for most non-web HTTP apps there's really very Nico> little difference between HTTP-layer and app-layer user Nico> authentication. In all cases developers will want the user Nico> authentication abstracted by a nice API. It's not obvious to me at all why this is true. To me, a webdav app-layer authentication would look different than a atompub app-layer authentication. And both of those seem like they would involve more damage to the app's state machine than http-layer. I'd expect the webdav layer to probably use http headers for a lot of the work. I'd expect the atompub layer to want to put everything into the xml document. I'd expect the atompub layer to get really unhappy at the idea of adding challeng/response into the state machine of the app layer but to be fine with this in the http layer. From mouse@Sparkle.Rodents-Montreal.ORG Tue May 15 13:29:06 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1357921F8896 for ; Tue, 15 May 2012 13:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.058 X-Spam-Level: X-Spam-Status: No, score=-9.058 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SfZ6Sd-BEj+Q for ; Tue, 15 May 2012 13:29:05 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by ietfa.amsl.com (Postfix) with ESMTP id 36FC421F8881 for ; Tue, 15 May 2012 13:29:05 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id QAA04997; Tue, 15 May 2012 16:29:03 -0400 (EDT) Date: Tue, 15 May 2012 16:29:03 -0400 (EDT) From: Mouse Message-Id: <201205152029.QAA04997@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Tue, 15 May 2012 16:23:50 -0400 (EDT) To: saag@ietf.org In-Reply-To: <914C5C50-3D86-49AD-8670-7235A1E7F4AE@cs.columbia.edu> References: <14A09626-8397-4656-A042-FEFDDD017C9F@mnot.net> <4DAC6FBC-3E6D-4CD1-9B5C-0CA5986169A5@mnot.net> <15942_1337100095_q4FGfYs7026806_410AB643-F18B-47F1-926E-9D34A1EE24DD@vpnc.org> <1337101616.3244.206.camel@destiny.pc.cs.cmu.edu> <87likt714d.fsf@latte.josefsson.org> <1337109709.3244.209.camel@destiny.pc.cs.cmu.edu> <5A45EDCD-1A34-4F6C-BE59-532045796509@vpnc.org> <914C5C50-3D86-49AD-8670-7235A1E7F4AE@cs.columbia.edu> Subject: Re: [saag] Reminder: Call for Proposals - HTTP/2.0 and HTTP Authentication X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 20:29:06 -0000 > [E]veryone some roll-your-own scheme that provides for (a) passwords; > (b) password recovery/reset, and (c) a *pretty* login screen. This > last is probably the most important issue. Actually, I think it's not. What I suspect most of those content providers care about more is a *branded* login screen. Indeed, many of them are pretty hideous - though of course that's a judgement call on which reasonable people will disagree. Of course, this brings us right back to the tension between the desires of the content provider and presentation imposer and the desires of the content consumer. (Personally I'd prefer to see peer-to-peer, but there's less and less of that left these days.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From smb@cs.columbia.edu Tue May 15 13:33:52 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8CDE11E809F for ; Tue, 15 May 2012 13:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.028 X-Spam-Level: X-Spam-Status: No, score=-4.028 tagged_above=-999 required=5 tests=[AWL=-1.429, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQoEuMpxnFLX for ; Tue, 15 May 2012 13:33:52 -0700 (PDT) Received: from rambutan.cc.columbia.edu (rambutan.cc.columbia.edu [128.59.29.5]) by ietfa.amsl.com (Postfix) with ESMTP id D8AA311E8083 for ; Tue, 15 May 2012 13:33:51 -0700 (PDT) Received: from [192.168.2.166] (74-92-112-54-Philadelphia.hfc.comcastbusiness.net [74.92.112.54]) (user=smb2132 mech=PLAIN bits=0) by rambutan.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id q4FKXjmT027526 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 15 May 2012 16:33:45 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Steven Bellovin In-Reply-To: <4FB2BA45.5070300@cs.tcd.ie> Date: Tue, 15 May 2012 16:33:44 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <14A09626-8397-4656-A042-FEFDDD017C9F@mnot.net> <4DAC6FBC-3E6D-4CD1-9B5C-0CA5986169A5@mnot.net> <15942_1337100095_q4FGfYs7026806_410AB643-F18B-47F1-926E-9D34A1EE24DD@vpnc.org> <1337101616.3244.206.camel@destiny.pc.cs.cmu.edu> <87likt714d.fsf@latte.josefsson.org> <1337109709.3244.209.camel@destiny.pc.cs.cmu.edu> <5A45EDCD-1A34-4F6C-BE59-532045796509@vpnc.org> <914C5C50-3D86-49AD-8670-7235A1E7F4AE@cs.columbia.edu> <4FB2BA45.5070300@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1278) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.5 Cc: Jeffrey Hutzelman , Paul Hoffman , IETF Security Area Advisory Group , Simon Josefsson Subject: Re: [saag] Reminder: Call for Proposals - HTTP/2.0 and HTTP Authentication X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 20:33:52 -0000 On May 15, 2012, at 4:19 17PM, Stephen Farrell wrote: > > Just a small reminder of the subject line:-) > > I'd really like to see some good proposals produced > rather than only discuss whether that's perfection > or not. (I might even make a proposal of my own if > only to flush out better ones:-) > > If people have additional things they think are also > worthwhile, then they can propose those too, on this > list or as an I-D. Sean and I are very open to seeing > work happen on such things, but that's not the same > as the work the httpbis WG are doing now. > I'm saying something slightly different: I'm saying that effort spent on http security is probably wasted unless there's a plausible way to link it to my other points. We can't bolt on authentication here; the market isn't interested. We need an integrated design, even if that means talking to other standards bodies and (shudder) web site designers. --Steve Bellovin, https://www.cs.columbia.edu/~smb From nico@cryptonector.com Tue May 15 13:48:11 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4289411E80BC for ; Tue, 15 May 2012 13:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.836 X-Spam-Level: X-Spam-Status: No, score=-1.836 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lj11kY4tsu6b for ; Tue, 15 May 2012 13:48:10 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 2B65221F85A2 for ; Tue, 15 May 2012 13:48:03 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id C9A8E43807F for ; Tue, 15 May 2012 13:48:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=De8XzMzNcNRgdu3AI+81KHKJNq7npVExamDILr8y0ub+ QJZW3ip0aZEirct2LTSWBBAYunbTVIlbS2xZuUsqUPwB26auJ7tFV4ZSxu7rlc9M A8JQI04flSy4ijTG1KOC27m14U9dRcK4KAZDZu5t42OCSocgN76gn55JxlsVi90= 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:content-transfer-encoding; s= cryptonector.com; bh=mR+iX62Y/5CJa1xc1CGa2+V3GOI=; b=MITeKoXo9Q7 O7awzLdIDOgtxFRv4TUPeZPwRLPq6F4sc2MBGK4iG8BaCCivaSxat/22Ieawn0i4 1j/oA9BvknKDFJU3POcMAYqsZXqav69JNOmU4YfAh/9S5zjmwFt6zjYxWjqL5srX 09dkkzw3B6NHGSB9dvKCMqxNDeKn2M1E= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPSA id A980F43807E for ; Tue, 15 May 2012 13:48:02 -0700 (PDT) Received: by dacx6 with SMTP id x6so15974dac.31 for ; Tue, 15 May 2012 13:48:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.204.2 with SMTP id ku2mr9172308pbc.55.1337114882330; Tue, 15 May 2012 13:48:02 -0700 (PDT) Received: by 10.68.5.99 with HTTP; Tue, 15 May 2012 13:48:02 -0700 (PDT) In-Reply-To: References: <14A09626-8397-4656-A042-FEFDDD017C9F@mnot.net> <4DAC6FBC-3E6D-4CD1-9B5C-0CA5986169A5@mnot.net> <15942_1337100095_q4FGfYs7026806_410AB643-F18B-47F1-926E-9D34A1EE24DD@vpnc.org> <1337101616.3244.206.camel@destiny.pc.cs.cmu.edu> <87likt714d.fsf@latte.josefsson.org> <1337109709.3244.209.camel@destiny.pc.cs.cmu.edu> <5A45EDCD-1A34-4F6C-BE59-532045796509@vpnc.org> <914C5C50-3D86-49AD-8670-7235A1E7F4AE@cs.columbia.edu> <4FB2BA45.5070300@cs.tcd.ie> Date: Tue, 15 May 2012 15:48:02 -0500 Message-ID: From: Nico Williams To: Steven Bellovin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Simon Josefsson , Jeffrey Hutzelman , Paul Hoffman , IETF Security Area Advisory Group Subject: Re: [saag] Reminder: Call for Proposals - HTTP/2.0 and HTTP Authentication X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 20:48:11 -0000 On Tue, May 15, 2012 at 3:33 PM, Steven Bellovin wrot= e: > On May 15, 2012, at 4:19 17PM, Stephen Farrell wrote: >> If people have additional things they think are also >> worthwhile, then they can propose those too, on this >> list or as an I-D. Sean and I are very open to seeing >> work happen on such things, but that's not the same >> as the work the httpbis WG are doing now. >> > I'm saying something slightly different: I'm saying that effort > spent on http security is probably wasted unless there's a > plausible way to link it to my other points. =C2=A0We can't bolt > on authentication here; the market isn't interested. =C2=A0We > need an integrated design, even if that means talking to > other standards bodies and (shudder) web site designers. I'm assuming that the WG will entertain your arguments (and mine) and that the scope is not strictly HTTP authentication. The WG charter says this: With regard to security requirements, in the initial phase of work on HTTP/2.0, new proposals for authentication schemes can be made. The WG will have a a goal of choosing at least one scheme that is better than those available for HTTP/1.x. However, the WG might select zero schemes. In addition, non-selected schemes might be discussed with the IETF Security Area for further work there. To me this says that our arguments are in scope and that it's possible that the WG will decide to not pursue HTTP-layer solutions. I'd also argue that the charter does not rule out app-layer authentication systems specifically intended for running over HTTP -- the charter's language is not sufficiently specific as to layering. Lastly, if the charter text were to presecriptive we could argue to re-charter (I would). Nico -- From hallam@gmail.com Wed May 16 23:38:34 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5216721F85CD; Wed, 16 May 2012 23:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Heuw1u2wPDu; Wed, 16 May 2012 23:38:33 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B814C21F85BE; Wed, 16 May 2012 23:38:32 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so2524219obb.31 for ; Wed, 16 May 2012 23:38:32 -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=u8/sCIPi5QuW+yTnfU2NSAXtM9YjFLDh+jiQV2igsmc=; b=syhdvgUVRL0Fv41+jDfyzsesi530upPhs3KG8fkCy6EdYoe4cIDFfFvVZbDLWZ+ut1 WICfvd4HvalTXHN9i4RnAetXY6ZnM/QdWMeO+LJ7Nuh4wqLTu5vfexZ2S+qh7s4Tz9SD noYApyUuBqy1+l95izsVkZsaqXqXspP7Iw5luSmhlH0vuEdhdbyengLDLzqwrIL2Iofh vR3/BrwhcTo9+Y7YljngBV9R4BTdH8u+NIN/T1mZFPIxU5cOHE85p8weEHwCCpxeHlbU 5fnCG1YUJYT2JsS+1pkk1oWOIx+OCFDBzziqCnS1P3A+sRsrDDa12jhA8CNkCVxcU2ZD ZFAA== MIME-Version: 1.0 Received: by 10.182.245.17 with SMTP id xk17mr5310676obc.66.1337236712316; Wed, 16 May 2012 23:38:32 -0700 (PDT) Received: by 10.182.227.34 with HTTP; Wed, 16 May 2012 23:38:32 -0700 (PDT) In-Reply-To: References: <4F72C59A.90900@KingsMountain.com> Date: Thu, 17 May 2012 16:38:32 +1000 Message-ID: From: Phillip Hallam-Baker To: Ben Laurie Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF PKIX WG , IETF Security Area Advisory Group Subject: Re: [saag] [pkix] fyi: CA/Browser Forum (CABF) reform deliberations + Revocation and TLS/SSL Replacements/Enhancements X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 06:38:34 -0000 SK is a TTP system as the notaries are still trusted to provide availability even if the other aspects of operation are cryptographically constrained against default. A group of notaries could collude to establish a cartel and extract functional pricing for their services if there was a sufficiently large number of relying parties. Alternatively they can simply publish a key for party X and then ransom it to the legitimate owner of the domain. SK is a silly, silly scheme that should be laughed off the stage. It punts on all the hard problems of PKI by asserting an administrative model that is ludicrous. 'google.com' must be worth a couple of billion dollars at least. I cannot see anyone with a valuable domain name risking it to a scheme that has revocation mechanism in case of administrative error. 'Don't make mistakes' is not a viable administrative approach. On Wed, Mar 28, 2012 at 6:10 PM, Ben Laurie wrote: > > > On Wed, Mar 28, 2012 at 8:02 AM, =JeffH > wrote: >> >> The CA/Browser Forum (CABF) was mentioned a few times during this very >> interesting presentation in the PKIX session at IETF-83 Paris yesterday... >> >> Trust-Related Activities: >> Internet Certification Authorities >> Revocation and SSL Replacements/Enhancements >> https://www.ietf.org/proceedings/83/slides/slides-83-pkix-10.pdf > > > Hmmm... > > a) Doesn't mention Certificate Transparency. > > b) Thinks Sovereign Keys (and presumably, had they mentioned it, CT) is a > TTP, which is incorrect. > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > -- Website: http://hallambaker.com/ From smb@cs.columbia.edu Fri May 18 19:31:45 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E084121F866A for ; Fri, 18 May 2012 19:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7U3LMJhIFpRv for ; Fri, 18 May 2012 19:31:45 -0700 (PDT) Received: from rambutan.cc.columbia.edu (rambutan.cc.columbia.edu [128.59.29.5]) by ietfa.amsl.com (Postfix) with ESMTP id 4166921F8661 for ; Fri, 18 May 2012 19:31:42 -0700 (PDT) Received: from [192.168.2.180] (74-92-112-54-Philadelphia.hfc.comcastbusiness.net [74.92.112.54]) (user=smb2132 mech=PLAIN bits=0) by rambutan.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id q4J2Vdgn028161 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 18 May 2012 22:31:40 -0400 (EDT) From: Steven Bellovin Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 18 May 2012 22:31:39 -0400 Message-Id: <300A2E9F-E99B-46FA-A101-E3611BD0D197@cs.columbia.edu> To: IETF Security Area Advisory Group Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.5 Subject: [saag] Additions to RFC 3631? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2012 02:31:46 -0000 Does anyone have any suggestions for additions or corrections to RFC 3631? It looks to me like it's held up pretty well, save for newer versions of some of the protocols. --Steve Bellovin, https://www.cs.columbia.edu/~smb From mouse@Sparkle.Rodents-Montreal.ORG Fri May 18 20:32:01 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A5CE9E802A for ; Fri, 18 May 2012 20:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.388 X-Spam-Level: X-Spam-Status: No, score=-7.388 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FO3M6cMCWUuY for ; Fri, 18 May 2012 20:32:00 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by ietfa.amsl.com (Postfix) with ESMTP id 3889B9E8025 for ; Fri, 18 May 2012 20:32:00 -0700 (PDT) Received: from localhost (localhost [[UNIX: localhost]]) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id XAA28531; Fri, 18 May 2012 23:31:58 -0400 (EDT) Date: Fri, 18 May 2012 23:31:58 -0400 (EDT) From: Mouse Message-Id: <201205190331.XAA28531@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Fri, 18 May 2012 22:52:03 -0400 (EDT) To: saag@ietf.org In-Reply-To: <300A2E9F-E99B-46FA-A101-E3611BD0D197@cs.columbia.edu> References: <300A2E9F-E99B-46FA-A101-E3611BD0D197@cs.columbia.edu> Subject: Re: [saag] Additions to RFC 3631? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2012 03:32:01 -0000 > Does anyone have any suggestions for additions or corrections to RFC > 3631? Yes. I, at least, do. > 2.2. A Word about Mandatory Mechanisms > We have evolved in the IETF the notion of "mandatory to implement" > mechanisms. [...blather about interoperability...] > It is important to understand that mandatory mechanisms are mandatory > to *implement*. [...] > Particularly with security > mechanisms, just because a mechanism is mandatory to implement does > not imply that it should be the default mechanism or that it may not > be disabled by configuration. If a mandatory to implement algorithm > is old and weak, it is better to disable it when a stronger algorithm > is available. If the point of a mandatory-to-implement mechanism is interoperability, allowing it to be disabled is a bad idea; it has pretty much the same effect on interoperability as not having it there in the first place: peers cannot count on its availability when speaking with peers they have no particular knowledge of. > 3.1. One-Time Passwords > One-time password schemes, such as that described in [RFC2289], are > very much stronger than conventional passwords. The host need not > store a copy of the user's password, This is true of only some OTP schemes (and those schemes are the weaker for it; any algorithmic relation between the passwords at all is a potential point of attack). Other OTP schemes require the host to store the user's password to exactly the same extent that reusable password schemes require the host to store their passwords. > nor is it ever transmitted over the network. Again, this depends on the OTP scheme; indeed, most OTP schemes I am aware of do indeed transmit the passwords used for authentication. If this discussion is really supposed to be restricted to RFC2289 designs, the punctuation in the introductory sentence is misleading; as quoted above, it says it's talking about OTP schemes in general, with RFC2289-style schemes cited as an illustrative example, not as a restrictive narrowing of the set of schemes being described. > 3.3. IPsec > The key management for IPsec can use either certificates or shared > secrets. For all the obvious reasons, certificates are preferred; > however, they may present more of a headache for the system manager. The statement that certificates "are preferred" is either false or incomplete, because certs are preferred only for certain classes of uses. For others, a shared secret is better - different uses, different tradeoffs. > 3.4. TLS > It's an unfortunate > reality that even server side authentication it not as secure in > practice as the cryptography would imply because most implementations > allow users to ignore authentication failures [...] If you want to cite "unfortunate realit[ies]", how about the one that it really is not all that difficult to get a cert for someone else's domain? I recall, for example, hearing about the number of certs for microsoft.com that had been issued to entities having nothing to do with Microsoft. > 3.8. Security/Multipart > Security/Multiparts [RFC1847] are the preferred mechanism for > protecting email. Again, asserting that a particular alternative is preferred is either false or incomplete. I, for example, have various reasons for preferring other tools for securing email in many cases. > The Digital Signature Standard [DSS] and RSA [RSA] are both good > choices; each has its advantages. [...] > [...]. DSS has much better performance than RSA for generating > new private keys, This runs counter to my experience with them within the context of ssh, for what little that may be worth. > 4.1. Plaintext Passwords > Plaintext passwords are the most common security mechanism in use > today. Unfortunately, they are also the weakest. When not protected > by an encryption layer, they are completely unacceptable. Again, this is either false or incomplete. There is a system I have been using since early 1992, and co-adminning since late 1992, that routinely uses reusable plaintext passwords over unsecured TCP connections over the open Internet (indeed, I don't think we have any other authentication mechanism available). For our purposes, that's entirely suitable, and I don't think it is for the IETF to tell us otherwise. Perhaps 3631 is writing strictly from the perspective of security mechanisms in new protocols being considered for IETF approval; my comments on 3.3, 3.8, and 4.1 do not apply then, but in that case I think the introductory text needs to be a good deal clearer. It's titled "Security Mechanisms for the Internet", not "Security Mechanisms for New IETF Protocols", after all. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From simon@josefsson.org Sun May 20 23:33:02 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C93FF21F8473 for ; Sun, 20 May 2012 23:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.309 X-Spam-Level: X-Spam-Status: No, score=-97.309 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWT6YmIqQFYh for ; Sun, 20 May 2012 23:33:02 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id B0B4921F850F for ; Sun, 20 May 2012 23:33:00 -0700 (PDT) Received: from latte (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q4L6WkCV009076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 21 May 2012 08:32:48 +0200 From: Simon Josefsson To: Steven Bellovin References: <300A2E9F-E99B-46FA-A101-E3611BD0D197@cs.columbia.edu> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120521:saag@ietf.org::W2dwtGhzLGCMsf2n:4qR/ X-Hashcash: 1:22:120521:smb@cs.columbia.edu::J79Y5Ko6pLsygylg:8TeW Date: Mon, 21 May 2012 08:32:46 +0200 In-Reply-To: <300A2E9F-E99B-46FA-A101-E3611BD0D197@cs.columbia.edu> (Steven Bellovin's message of "Fri, 18 May 2012 22:31:39 -0400") Message-ID: <877gw69h81.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: IETF Security Area Advisory Group Subject: Re: [saag] Additions to RFC 3631? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 06:33:02 -0000 Steven Bellovin writes: > Does anyone have any suggestions for additions or corrections to RFC 3631? > It looks to me like it's held up pretty well, save for newer versions of > some of the protocols. I think channel bindings ought to be discussed, as a simple way to bind different layers together to avoid certain attacks. It could be discussed in the SASL or GSS-API section. Further, I think EAP as a protocol should be included in the list of standard security mechanisms. /Simon From yaronf.ietf@gmail.com Mon May 21 00:20:12 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA92421F848C for ; Mon, 21 May 2012 00:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJPJGaDDWCh5 for ; Mon, 21 May 2012 00:20:12 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0438D21F848A for ; Mon, 21 May 2012 00:20:11 -0700 (PDT) Received: by bkty8 with SMTP id y8so4404709bkt.31 for ; Mon, 21 May 2012 00:20:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=C8KOAs3iI7+oWZ0CYKgyrCnDu1Lcyx8Es6a5OoDJPJE=; b=SQAulb2WPXnUvAFt21KQksWdkTCX3Wa8eQ79v5bZdowsHi4//f4kjhZclEy8hV32aQ 9/9oPj2oVO7yauEF28gLShnAy3uvq8x5Xq8fdme8EUmbt1bT+p09nJTg+RoPEriRDpT+ ffu+K86VgMEd5nJkrcwm2XX8/h72OYY783hlAhz3QG3NYOtX7jys2hHDvqdPBMOaKOyp nA8E7uaKoR3o8/XOPtwl/c7wY7FV/WzE7+GYsl8e3lQQJVF999JuAHr6Us9EhjaU6HW1 qaA4sTUxB0wyAphZ2IQE4DmscN2JmZEz72+BNV2T1bhRoEVBE2FRkW09i0ANmdN/yQkZ pZwQ== Received: by 10.205.133.7 with SMTP id hw7mr7607853bkc.123.1337584808481; Mon, 21 May 2012 00:20:08 -0700 (PDT) Received: from [192.168.7.200] (109-186-123-111.bb.netvision.net.il. [109.186.123.111]) by mx.google.com with ESMTPS id z14sm25361391bky.15.2012.05.21.00.20.05 (version=SSLv3 cipher=OTHER); Mon, 21 May 2012 00:20:06 -0700 (PDT) Message-ID: <4FB9ECA4.3010904@gmail.com> Date: Mon, 21 May 2012 10:20:04 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Simon Josefsson References: <300A2E9F-E99B-46FA-A101-E3611BD0D197@cs.columbia.edu> <877gw69h81.fsf@latte.josefsson.org> In-Reply-To: <877gw69h81.fsf@latte.josefsson.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF Security Area Advisory Group Subject: Re: [saag] Additions to RFC 3631? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 07:20:13 -0000 And a short section on crypto-grade random number generation. I would be glad to contribute it. Yaron On 05/21/2012 09:32 AM, Simon Josefsson wrote: > Steven Bellovin writes: > >> Does anyone have any suggestions for additions or corrections to RFC 3631? >> It looks to me like it's held up pretty well, save for newer versions of >> some of the protocols. > > I think channel bindings ought to be discussed, as a simple way to bind > different layers together to avoid certain attacks. It could be > discussed in the SASL or GSS-API section. Further, I think EAP as a > protocol should be included in the list of standard security mechanisms. > > /Simon > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From lear@cisco.com Mon May 21 01:26:56 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 810F221F85A8 for ; Mon, 21 May 2012 01:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qCOXLYrFG0Bs for ; Mon, 21 May 2012 01:26:56 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id B95F521F8599 for ; Mon, 21 May 2012 01:26:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=626; q=dns/txt; s=iport; t=1337588815; x=1338798415; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=dFFLvrMKKpauPPs3hj+DKsq79vIQw6h5a7Mc2ePmWxU=; b=gAmi8r+ZTcvxsib87fD2RCF5592KG9w7NikLQIOEwSqpZG/AZMFk9DEe La5i5xn8d7CtvbD4HCuqi4r+pgkEFu5GkgXjERQoaD9cGQIHzLnGSpQaB /b+Y8akP6eXjByDQpov81i/TktwWKl9qvfDyuVKaIJlATQUQidPWTKVtq U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAIb7uU+Q/khN/2dsb2JhbABEhS2uZoEHghUBAQEEEgEQVQEQCxgCAgUWCwICCQMCAQIBRQYNAQcBAR6HbJ9BjRSSG4EmjhiBFAOVG44MgWSCaw X-IronPort-AV: E=Sophos;i="4.75,629,1330905600"; d="scan'208";a="138222951" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 21 May 2012 08:26:53 +0000 Received: from dhcp-10-61-99-170.cisco.com (dhcp-10-61-99-170.cisco.com [10.61.99.170]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q4L8QqfX024695; Mon, 21 May 2012 08:26:52 GMT Message-ID: <4FB9FC4C.9010107@cisco.com> Date: Mon, 21 May 2012 10:26:52 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Mouse References: <300A2E9F-E99B-46FA-A101-E3611BD0D197@cs.columbia.edu> <201205190331.XAA28531@Sparkle.Rodents-Montreal.ORG> In-Reply-To: <201205190331.XAA28531@Sparkle.Rodents-Montreal.ORG> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: saag@ietf.org Subject: Re: [saag] Additions to RFC 3631? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 08:26:56 -0000 Hi Mouse, On 5/19/12 5:31 AM, Mouse wrote: > If the point of a mandatory-to-implement mechanism is interoperability, > allowing it to be disabled is a bad idea; it has pretty much the same > effect on interoperability as not having it there in the first place: > peers cannot count on its availability when speaking with peers they > have no particular knowledge of. How would you propose to handle the situation where an MTI algorithm is found to be vulnerable? Isn't it the operator's choice between running vulnerable code and turning off MTI (yes, there is middle ground but it's wildly complex)? Eliot From mouse@Sparkle.Rodents-Montreal.ORG Mon May 21 02:52:43 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 892D221F8573 for ; Mon, 21 May 2012 02:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.758 X-Spam-Level: X-Spam-Status: No, score=-7.758 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_20=-0.74, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LbfaQJNkvK4J for ; Mon, 21 May 2012 02:52:43 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by ietfa.amsl.com (Postfix) with ESMTP id C29D721F854D for ; Mon, 21 May 2012 02:52:42 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id FAA14303; Mon, 21 May 2012 05:52:41 -0400 (EDT) Date: Mon, 21 May 2012 05:52:41 -0400 (EDT) From: Mouse Message-Id: <201205210952.FAA14303@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Mon, 21 May 2012 05:42:10 -0400 (EDT) To: saag@ietf.org In-Reply-To: <4FB9FC4C.9010107@cisco.com> References: <300A2E9F-E99B-46FA-A101-E3611BD0D197@cs.columbia.edu> <201205190331.XAA28531@Sparkle.Rodents-Montreal.ORG> <4FB9FC4C.9010107@cisco.com> Subject: Re: [saag] Additions to RFC 3631? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 09:52:43 -0000 >> If the point of a mandatory-to-implement mechanism is >> interoperability, allowing it to be disabled is a bad idea; it has >> pretty much the same effect on interoperability as not having it >> there in the first place: peers cannot count on its availability >> when speaking with peers they have no particular knowledge of. > How would you propose to handle the situation where an MTI algorithm > is found to be vulnerable? Disable it. That is to say, I would scrap the mandatory-to-implement part, not the allow-disabling part. Besides, after technology has marched on for five - or ten, or twenty - years, today's best is likely to look utterly ludicrous. Time was, crypt(1) - a one-rotor Enigma machine, basically - actually provided a useful level of security. Today, it's what Schneier calls `kid sister' crypto, at best. Mandatory-to-offer algorithms lead to forcing people to choose between ignoring the spec and running grossly insecure algorithms, while allowing disabling of mandatory-to-implement algorithms breaks most of the point of mandatory-to-implement. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From simon@josefsson.org Mon May 21 03:07:12 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9BE21F853D for ; Mon, 21 May 2012 03:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.402 X-Spam-Level: X-Spam-Status: No, score=-97.402 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ON39c8Yu+eDz for ; Mon, 21 May 2012 03:07:11 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 2346D21F8528 for ; Mon, 21 May 2012 03:07:10 -0700 (PDT) Received: from latte (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q4LA75Jn018704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 21 May 2012 12:07:06 +0200 From: Simon Josefsson To: Yaron Sheffer References: <300A2E9F-E99B-46FA-A101-E3611BD0D197@cs.columbia.edu> <877gw69h81.fsf@latte.josefsson.org> <4FB9ECA4.3010904@gmail.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120521:yaronf.ietf@gmail.com::CN8FulDLL05+cqdZ:9pHQ X-Hashcash: 1:22:120521:saag@ietf.org::njH6m2DLUNba5tvH:QT1g Date: Mon, 21 May 2012 12:07:04 +0200 In-Reply-To: <4FB9ECA4.3010904@gmail.com> (Yaron Sheffer's message of "Mon, 21 May 2012 10:20:04 +0300") Message-ID: <87wr454zlj.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: IETF Security Area Advisory Group Subject: Re: [saag] Additions to RFC 3631? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 10:07:12 -0000 Yaron Sheffer writes: > And a short section on crypto-grade random number generation. I would > be glad to contribute it. I believe that is more for an update of RFC 1750 than RFC 3631. RFC 1750 is in need for an update with modern recommendations. It should point to at least AES, Yarrow and the approved NIST RNGs. The references of weak ciphers (DES, MD4, etc) should be removed. Given that RFC 1750 is often cited by crypto protocol specifications, it would be nice if RFC 1750 could be (more) useful to implementers. /Simon From stephen.farrell@cs.tcd.ie Mon May 21 03:15:57 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A89821F854A for ; Mon, 21 May 2012 03:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vpODAcjUh4Bq for ; Mon, 21 May 2012 03:15:56 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 4716A21F8589 for ; Mon, 21 May 2012 03:15:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id DD5D2171472; Mon, 21 May 2012 11:15:54 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1337595354; bh=ches+XnPm0mZdR PxEGBFozA0Ze+CIPokZ78Gxx4raoA=; b=SqV1eiabyMRAhoiOdYwpxlqsKocPQV 32P6d8BaLRskKWf1ZFpZAcpGm/sO8D/dXwm4nwmrmWW+uMeHh5ztYh2syaNTdlUl YCLnz4OApMR0cyKZ5YJzZ4ZuXEw0vi0SCYDoPojw/ElV4NHH+PBLxs9fP0NDRp1N PAXa8o7vFs5OGYUa0eYNThbnymtE6iiIJmYRWGZuxWlL2eZBbzgvMeEdX5shtqFv JprX01z5x4YGSpfG0jabtDxenJnnq4Yy0XNrRrcmChhjh0kpLm7DapMMNUbdxDfa xBUHYaHiN1AOLPXD7+bCGfj1oeBeBzoUqYpyGLrbTTQxDv6cH4DpJQ4Q== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id FgTA2-YbE42H; Mon, 21 May 2012 11:15:54 +0100 (IST) Received: from [IPv6:2001:770:10:203:9883:a0df:9a1e:f31e] (unknown [IPv6:2001:770:10:203:9883:a0df:9a1e:f31e]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 4619115396C; Mon, 21 May 2012 11:15:54 +0100 (IST) Message-ID: <4FBA15DA.7000306@cs.tcd.ie> Date: Mon, 21 May 2012 11:15:54 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Simon Josefsson References: <300A2E9F-E99B-46FA-A101-E3611BD0D197@cs.columbia.edu> <877gw69h81.fsf@latte.josefsson.org> <4FB9ECA4.3010904@gmail.com> <87wr454zlj.fsf@latte.josefsson.org> In-Reply-To: <87wr454zlj.fsf@latte.josefsson.org> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF Security Area Advisory Group Subject: Re: [saag] Additions to RFC 3631? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 10:15:57 -0000 On 05/21/2012 11:07 AM, Simon Josefsson wrote: > Yaron Sheffer writes: > >> And a short section on crypto-grade random number generation. I would >> be glad to contribute it. > > I believe that is more for an update of RFC 1750 than RFC 3631. > > RFC 1750 is in need for an update with modern recommendations. It > should point to at least AES, Yarrow and the approved NIST RNGs. The > references of weak ciphers (DES, MD4, etc) should be removed. Given > that RFC 1750 is often cited by crypto protocol specifications, it would > be nice if RFC 1750 could be (more) useful to implementers. RFC 1750 was obsoleted by RFC 4086 in 2005. That's still a while back so maybe improvements to that could be made, Cheers, S > > /Simon > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > From yaronf.ietf@gmail.com Mon May 21 04:28:23 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC8D221F8623 for ; Mon, 21 May 2012 04:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjKVtlhum+SG for ; Mon, 21 May 2012 04:28:23 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id E3E1B21F861F for ; Mon, 21 May 2012 04:28:22 -0700 (PDT) Received: by lagv3 with SMTP id v3so3907394lag.31 for ; Mon, 21 May 2012 04:28:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=cj2DWfVvrnV6C/XhTrgNAFag95sKDLIffALDSXvS+Ko=; b=xqps/NpVkRE1u8oyXoIoJkPU7NdOBz+ywBaDNID2BwEiJiZyoumFsIFY4DmqhPBTfC iN7efNU5W782zypdfCCwRjwKydSEmnf0nL3kzSBXVxcY+wO7VKu4otv7vErXCQPnGjmT hJZwmgMujYMeOiYxnNgFTD/G4oIETWmjPQLrPHrVgjRXlYkx4gX3Lj2j4zW28oTlYw5f SpaIOrscFuju78nXf9iRoOf+6lSjblDpZjzT1109gKD1uYSGtaOFJS6fy1ysUGDVvmU9 IX6Ja1IK0FSpZY4Kp7MGP6wmg36P/aIluYeryYUqEiMgyYsu0Ws33yAUqOClz133HK3Y r9Bg== Received: by 10.152.46.232 with SMTP id y8mr19418934lam.18.1337599701777; Mon, 21 May 2012 04:28:21 -0700 (PDT) Received: from [192.168.7.200] (109-186-123-111.bb.netvision.net.il. [109.186.123.111]) by mx.google.com with ESMTPS id sm7sm12442690lab.5.2012.05.21.04.28.18 (version=SSLv3 cipher=OTHER); Mon, 21 May 2012 04:28:20 -0700 (PDT) Message-ID: <4FBA26D1.1060707@gmail.com> Date: Mon, 21 May 2012 14:28:17 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Stephen Farrell References: <300A2E9F-E99B-46FA-A101-E3611BD0D197@cs.columbia.edu> <877gw69h81.fsf@latte.josefsson.org> <4FB9ECA4.3010904@gmail.com> <87wr454zlj.fsf@latte.josefsson.org> <4FBA15DA.7000306@cs.tcd.ie> In-Reply-To: <4FBA15DA.7000306@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Simon Josefsson , IETF Security Area Advisory Group Subject: Re: [saag] Additions to RFC 3631? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 11:28:23 -0000 Whether or not RFC 4086 is in need of an update (and I agree it is), randomness is important enough as a security mechanism, and often enough forgotten, to be worth a section in 3631bis. Thanks, Yaron On 05/21/2012 01:15 PM, Stephen Farrell wrote: > > > On 05/21/2012 11:07 AM, Simon Josefsson wrote: >> Yaron Sheffer writes: >> >>> And a short section on crypto-grade random number generation. I would >>> be glad to contribute it. >> >> I believe that is more for an update of RFC 1750 than RFC 3631. >> >> RFC 1750 is in need for an update with modern recommendations. It >> should point to at least AES, Yarrow and the approved NIST RNGs. The >> references of weak ciphers (DES, MD4, etc) should be removed. Given >> that RFC 1750 is often cited by crypto protocol specifications, it would >> be nice if RFC 1750 could be (more) useful to implementers. > > RFC 1750 was obsoleted by RFC 4086 in 2005. That's still a while > back so maybe improvements to that could be made, > > Cheers, > S > >> >> /Simon >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >> >> From lear@cisco.com Mon May 21 05:53:36 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D88021F8620 for ; Mon, 21 May 2012 05:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3JyuZ6o19PV for ; Mon, 21 May 2012 05:53:35 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 74AA721F8613 for ; Mon, 21 May 2012 05:53:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=1242; q=dns/txt; s=iport; t=1337604815; x=1338814415; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=R+4ANtftbR8NzU8/WGuwqDtwQYTXp2jXhMdbwi0q5vw=; b=aedEGNHEJ3CJLYhk2qpbVY8Azk7AE+jqeQevB8+zLWb7zFpDznkkDzD7 tGEZbu7yE2hZHaCmQBaR3hYVSNGoLTnRjjPWL/4FtCtrVJ7+/sRq6mNpn RHCAH6OcpVFaHtUlgGzqIyRv6WNXrfDRpEA6HBlSUs8gH8/BYId8yq6P+ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFACk6uk+Q/khM/2dsb2JhbABEhS2uU4EHghUBAQEEEgEQVQEQCxgCAgUWCwICCQMCAQIBRQYNAQcBAR6HbJ88jRSSSoEmjhiBFAOVG44MgWSCaw X-IronPort-AV: E=Sophos;i="4.75,631,1330905600"; d="scan'208";a="4762369" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-3.cisco.com with ESMTP; 21 May 2012 12:53:31 +0000 Received: from dhcp-10-61-99-170.cisco.com (dhcp-10-61-99-170.cisco.com [10.61.99.170]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q4LCrVfd009452; Mon, 21 May 2012 12:53:31 GMT Message-ID: <4FBA3ACB.9030805@cisco.com> Date: Mon, 21 May 2012 14:53:31 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Mouse References: <300A2E9F-E99B-46FA-A101-E3611BD0D197@cs.columbia.edu> <201205190331.XAA28531@Sparkle.Rodents-Montreal.ORG> <4FB9FC4C.9010107@cisco.com> <201205210952.FAA14303@Sparkle.Rodents-Montreal.ORG> In-Reply-To: <201205210952.FAA14303@Sparkle.Rodents-Montreal.ORG> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: saag@ietf.org Subject: Re: [saag] Additions to RFC 3631? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 12:53:36 -0000 On 5/21/12 11:52 AM, Mouse wrote: >> How would you propose to handle the situation where an MTI algorithm >> is found to be vulnerable? > Disable it. > > That is to say, I would scrap the mandatory-to-implement part, not the > allow-disabling part. Besides, after technology has marched on for > five - or ten, or twenty - years, today's best is likely to look > utterly ludicrous. Time was, crypt(1) - a one-rotor Enigma machine, > basically - actually provided a useful level of security. Today, it's > what Schneier calls `kid sister' crypto, at best. Mandatory-to-offer > algorithms lead to forcing people to choose between ignoring the spec > and running grossly insecure algorithms, while allowing disabling of > mandatory-to-implement algorithms breaks most of the point of > mandatory-to-implement. > Thanks for this explanation. I wonder if there is a more nuanced way in which this could be handled. For instance, would it be possible for the IETF to keep a simple list of algorithms in order of preference, and deal with algorithm agility in that way? This presupposes that there is some uniformity in application requirements, or at least classes of applications that can be grouped... Eliot From smb@cs.columbia.edu Mon May 21 07:01:23 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC6E021F8673 for ; Mon, 21 May 2012 07:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 644LG1vAo4rT for ; Mon, 21 May 2012 07:01:23 -0700 (PDT) Received: from rambutan.cc.columbia.edu (rambutan.cc.columbia.edu [128.59.29.5]) by ietfa.amsl.com (Postfix) with ESMTP id DECA821F8681 for ; Mon, 21 May 2012 07:01:22 -0700 (PDT) Received: from [192.168.2.166] (74-92-112-54-Philadelphia.hfc.comcastbusiness.net [74.92.112.54]) (user=smb2132 mech=PLAIN bits=0) by rambutan.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id q4LE0rdX005191 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 21 May 2012 10:01:20 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Steven Bellovin In-Reply-To: <4FB9ECA4.3010904@gmail.com> Date: Mon, 21 May 2012 10:01:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <300A2E9F-E99B-46FA-A101-E3611BD0D197@cs.columbia.edu> <877gw69h81.fsf@latte.josefsson.org> <4FB9ECA4.3010904@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.1278) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.5 Cc: Simon Josefsson , IETF Security Area Advisory Group Subject: Re: [saag] Additions to RFC 3631? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 14:01:23 -0000 As noted by others, RFC 4086 covers that. It may also need improving; I = haven't reread it recently. However, even a pointer to it is out of = place in 3631bis. 3631 is about protocol mechanisms; 4086 is about = implementations. Mouse Mouse's suggestions are more in the domain of = 3365, which is security design philosophy. 3631 says "if you want to = put security into a protocol, here are the best choices we have today". = My question is whether or not that list should be changed. On May 21, 2012, at 3:20 04AM, Yaron Sheffer wrote: > And a short section on crypto-grade random number generation. I would = be glad to contribute it. >=20 > Yaron >=20 > On 05/21/2012 09:32 AM, Simon Josefsson wrote: >> Steven Bellovin writes: >>=20 >>> Does anyone have any suggestions for additions or corrections to RFC = 3631? >>> It looks to me like it's held up pretty well, save for newer = versions of >>> some of the protocols. >>=20 >> I think channel bindings ought to be discussed, as a simple way to = bind >> different layers together to avoid certain attacks. It could be >> discussed in the SASL or GSS-API section. Further, I think EAP as a >> protocol should be included in the list of standard security = mechanisms. >>=20 >> /Simon >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >=20 --Steve Bellovin, https://www.cs.columbia.edu/~smb From paul.hoffman@vpnc.org Mon May 21 09:43:01 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA6F21F855B for ; Mon, 21 May 2012 09:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ez1PkXh3abN for ; Mon, 21 May 2012 09:43:01 -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 0430B21F854D for ; Mon, 21 May 2012 09:43:00 -0700 (PDT) Received: from [172.19.131.151] ([12.130.118.39]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q4LGgfR6079910 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 21 May 2012 09:42:44 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Mon, 21 May 2012 12:42:39 -0400 Content-Transfer-Encoding: 7bit Message-Id: <78F24BEE-DD3B-474D-9E0B-1AC73CBE373A@vpnc.org> References: <300A2E9F-E99B-46FA-A101-E3611BD0D197@cs.columbia.edu> <877gw69h81.fsf@latte.josefsson.org> <4FB9ECA4.3010904@gmail.com> To: Steven Bellovin X-Mailer: Apple Mail (2.1278) Cc: IETF Security Area Advisory Group Subject: Re: [saag] Additions to RFC 3631? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 16:43:01 -0000 +1 to adding EAP as a mechanism. +/-0 to adding channel bindings, given how few people understand them. --Paul Hoffman From nico@cryptonector.com Mon May 21 10:06:51 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0252921F856C for ; Mon, 21 May 2012 10:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3pMWkkxkEJC for ; Mon, 21 May 2012 10:06:50 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 8773921F8562 for ; Mon, 21 May 2012 10:06:50 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id 33CD021DE71 for ; Mon, 21 May 2012 10:06:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=nXKbf7sFsoq/+wVITZhVp KbJ3ZgUL+ggXW64Fpf6CQfHoRhWDwheFGISCyslsMStyHuNeh3hQRpOM4WItAOWF xnfAW30fFy1YzVFt9AbS5Bc+PWPUNeSAH7x1rAE0SFeMMlIU6eUnhs4Emw+jKlvE CWEV9Hx7EcIij15M1tVGWU= 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=n70XWtsnqR1HW8wwbavj hpsZQEI=; b=eFWE83TZ5w3DQiGO+Qq8uII2AVVkvT8kBEopjL92jTvxnUb7Rg/n 8ZEuxQUOpNlHkfmaL2IQrqRQ2DVc0aLoB1hxssMSoMvqDWWZv5WN/pKQAjsp2pMO iEheDnExJ1LARtUWWVzgbE0DNa7d+RtVUmGE3GobQZWv8Hye9dHv2N0= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id 104EC21DE6F for ; Mon, 21 May 2012 10:06:50 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so7345616pbc.31 for ; Mon, 21 May 2012 10:06:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.192.5 with SMTP id hc5mr2329005pbc.49.1337620009597; Mon, 21 May 2012 10:06:49 -0700 (PDT) Received: by 10.68.5.99 with HTTP; Mon, 21 May 2012 10:06:49 -0700 (PDT) In-Reply-To: <78F24BEE-DD3B-474D-9E0B-1AC73CBE373A@vpnc.org> References: <300A2E9F-E99B-46FA-A101-E3611BD0D197@cs.columbia.edu> <877gw69h81.fsf@latte.josefsson.org> <4FB9ECA4.3010904@gmail.com> <78F24BEE-DD3B-474D-9E0B-1AC73CBE373A@vpnc.org> Date: Mon, 21 May 2012 12:06:49 -0500 Message-ID: From: Nico Williams To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Cc: IETF Security Area Advisory Group Subject: Re: [saag] Additions to RFC 3631? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 17:06:51 -0000 On Mon, May 21, 2012 at 11:42 AM, Paul Hoffman wrote: > +1 to adding EAP as a mechanism. > > +/-0 to adding channel bindings, given how few people understand them. EIther it's important/useful or not. If it is then having some text in this RFC would help those people who don't understand CB. Nico -- From touch@isi.edu Mon May 21 10:15:21 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEF3421F8566 for ; Mon, 21 May 2012 10:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZDwUDlTOfT2 for ; Mon, 21 May 2012 10:15:20 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 20F8A21F8562 for ; Mon, 21 May 2012 10:15:20 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q4LHElI2025131 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 21 May 2012 10:14:47 -0700 (PDT) Message-ID: <4FBA7807.5080207@isi.edu> Date: Mon, 21 May 2012 10:14:47 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Nico Williams References: <300A2E9F-E99B-46FA-A101-E3611BD0D197@cs.columbia.edu> <877gw69h81.fsf@latte.josefsson.org> <4FB9ECA4.3010904@gmail.com> <78F24BEE-DD3B-474D-9E0B-1AC73CBE373A@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Paul Hoffman , IETF Security Area Advisory Group Subject: Re: [saag] Additions to RFC 3631? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 17:15:21 -0000 On 5/21/2012 10:06 AM, Nico Williams wrote: > On Mon, May 21, 2012 at 11:42 AM, Paul Hoffman wrote: >> +1 to adding EAP as a mechanism. >> >> +/-0 to adding channel bindings, given how few people understand them. > > EIther it's important/useful or not. If it is then having some text > in this RFC would help those people who don't understand CB. I'd add it - in fact, I would add both BTNS and TCP-AO, since neither are covered and both serve different purposes than the mechanisms listed. I also feel that Sec 2.4 should be expanded to explain in more detail how different levels of protection are used. Joe From nico@cryptonector.com Mon May 21 10:20:23 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B2DB21F858A for ; Mon, 21 May 2012 10:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GvYoMDzv0dR5 for ; Mon, 21 May 2012 10:20:23 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id E891D21F854E for ; Mon, 21 May 2012 10:20:22 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTP id B3E761F0085 for ; Mon, 21 May 2012 10:20:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=OMMvomkt5gZMNKkAtu9pr CBODv4o8TwFAQapwYGTaZ5qHjRcoiWS6HTLM0n5bIuTH6OBvzKdV66RJCo51f2jp I3dICl02oKxfkrtpLohH/rrDFAqhoUuwcX+FvZnO4ECnRJT9uYCIVV7Na9kzCvNb Lr3sYBbGgLOYVJhFFM9x60= 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=tyrjqCPhjI1EfbDbIxAt K9WFuH8=; b=YP4lF31JxQ6VOMAQyuvWRdXk2eWBmGB+ZXZ707S7lr5hPKi1Oaex A/ea40lX4GHSgAmrvlownYbg9eoSWbwuys/1DmHJRNm+DmdzUrFCxgFNrYzXKYyO Z3Qe+JPbs/YEHnx8JOLhoGnMMf+tkyF7XkHR+irYwPE39hQqscnK2n4= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTPSA id 8B1601F0083 for ; Mon, 21 May 2012 10:20:22 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so7362023pbc.31 for ; Mon, 21 May 2012 10:20:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.216.33 with SMTP id on1mr70305750pbc.105.1337620822208; Mon, 21 May 2012 10:20:22 -0700 (PDT) Received: by 10.68.5.99 with HTTP; Mon, 21 May 2012 10:20:22 -0700 (PDT) In-Reply-To: <4FBA7807.5080207@isi.edu> References: <300A2E9F-E99B-46FA-A101-E3611BD0D197@cs.columbia.edu> <877gw69h81.fsf@latte.josefsson.org> <4FB9ECA4.3010904@gmail.com> <78F24BEE-DD3B-474D-9E0B-1AC73CBE373A@vpnc.org> <4FBA7807.5080207@isi.edu> Date: Mon, 21 May 2012 12:20:22 -0500 Message-ID: From: Nico Williams To: Joe Touch Content-Type: text/plain; charset=UTF-8 Cc: Paul Hoffman , IETF Security Area Advisory Group Subject: Re: [saag] Additions to RFC 3631? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 17:20:23 -0000 On Mon, May 21, 2012 at 12:14 PM, Joe Touch wrote: > I'd add it - in fact, I would add both BTNS and TCP-AO, since neither are > covered and both serve different purposes than the mechanisms listed. And RFC5660. The problem with that is that BTNS and RFC5660 have not been implemented, to my knowledge. Whereas at least CB have been implemented in SASL and GSS. Microsoft has implemented and deployed CB. Nico -- From nico@cryptonector.com Mon May 21 10:23:11 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 101FD21F85E4 for ; Mon, 21 May 2012 10:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KRVfgRNaPFA for ; Mon, 21 May 2012 10:23:09 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE4B21F85C7 for ; Mon, 21 May 2012 10:23:09 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id 3F4AE350072 for ; Mon, 21 May 2012 10:23:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=E9vxnfTUqqSVdvZ/EiKOo MoshYPTYkOQfYkBpMz7NkmV3RgEyC44KJ0FfrJusIwJo5WjAGAFCU9wG2SctAW5g 0lC7YgkZA44k3Js9A0h47V8hTKGp0ptDXz71PM2VoFI0BAdcPGO1cn99gITIZ3B1 6Xs2zH7sMV5fstJePE0LmA= 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=hmaAGVP7tQaCLMETokJB PnAIEzE=; b=NTA+pd425ltf29uLRmSS2VxSkGm5fPxvAhsm7pqvOKlOsvLe/P9Y drqnZm1yz/lzC4KHexXWYm6EVFD+aOrM3nbUaupWShd62qY0k2RGYjayam33/CPx tTG2Vfb1awfW81v//+3+OCcbRfB3bFR/AOCeAsFqUAYz+ceMat1L/Rw= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id 25E43350058 for ; Mon, 21 May 2012 10:23:09 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so7365331pbc.31 for ; Mon, 21 May 2012 10:23:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.204.2 with SMTP id ku2mr70502064pbc.55.1337620988806; Mon, 21 May 2012 10:23:08 -0700 (PDT) Received: by 10.68.5.99 with HTTP; Mon, 21 May 2012 10:23:08 -0700 (PDT) In-Reply-To: <201205190331.XAA28531@Sparkle.Rodents-Montreal.ORG> References: <300A2E9F-E99B-46FA-A101-E3611BD0D197@cs.columbia.edu> <201205190331.XAA28531@Sparkle.Rodents-Montreal.ORG> Date: Mon, 21 May 2012 12:23:08 -0500 Message-ID: From: Nico Williams To: Mouse Content-Type: text/plain; charset=UTF-8 Cc: saag@ietf.org Subject: Re: [saag] Additions to RFC 3631? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 17:23:13 -0000 On Fri, May 18, 2012 at 10:31 PM, Mouse wrote: > If the point of a mandatory-to-implement mechanism is interoperability, > allowing it to be disabled is a bad idea; it has pretty much the same > effect on interoperability as not having it there in the first place: > peers cannot count on its availability when speaking with peers they > have no particular knowledge of. Mileage varies. You're happy with some passwords-in-the-clear use cases but you're not fine with MTI algorithms in case they become too weak -- not quite a contradiciton in terms, but still strange. IMO we need several MTI algorithms, not just one and certainly not just zero. Nico -- From smb@cs.columbia.edu Mon May 21 10:59:43 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E87D721F85FF for ; Mon, 21 May 2012 10:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0PCATeLyNjY for ; Mon, 21 May 2012 10:59:42 -0700 (PDT) Received: from paneer.cc.columbia.edu (paneer.cc.columbia.edu [128.59.29.4]) by ietfa.amsl.com (Postfix) with ESMTP id 3052321F85E7 for ; Mon, 21 May 2012 10:59:42 -0700 (PDT) Received: from [192.168.2.166] (74-92-112-54-Philadelphia.hfc.comcastbusiness.net [74.92.112.54]) (user=smb2132 mech=PLAIN bits=0) by paneer.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id q4LHxdRC013087 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 21 May 2012 13:59:39 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Steven Bellovin In-Reply-To: Date: Mon, 21 May 2012 13:59:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <416327B2-6E60-4D09-B3E7-D314F4FDD4E1@cs.columbia.edu> References: <300A2E9F-E99B-46FA-A101-E3611BD0D197@cs.columbia.edu> <877gw69h81.fsf@latte.josefsson.org> <4FB9ECA4.3010904@gmail.com> <78F24BEE-DD3B-474D-9E0B-1AC73CBE373A@vpnc.org> To: Nico Williams X-Mailer: Apple Mail (2.1278) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.4 Cc: Paul Hoffman , IETF Security Area Advisory Group Subject: Re: [saag] Additions to RFC 3631? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 17:59:43 -0000 On May 21, 2012, at 1:06 49PM, Nico Williams wrote: > On Mon, May 21, 2012 at 11:42 AM, Paul Hoffman = wrote: >> +1 to adding EAP as a mechanism. >>=20 >> +/-0 to adding channel bindings, given how few people understand = them. >=20 > EIther it's important/useful or not. If it is then having some text > in this RFC would help those people who don't understand CB. >=20 I agree. --Steve Bellovin, https://www.cs.columbia.edu/~smb From nico@cryptonector.com Mon May 21 11:07:04 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C71FE21F8611 for ; Mon, 21 May 2012 11:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nA8MXzU7i8-L for ; Mon, 21 May 2012 11:07:04 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 7C99621F85DF for ; Mon, 21 May 2012 11:07:03 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id 3917894065 for ; Mon, 21 May 2012 11:07:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=dDKeULUI0FmMocZprOlgaw3jWwoNjALdj1VG3cTTG7NE 6gStkCnnAQGKuHabnOIQtYpYvaecTFd7PQ6O5vvYiixZaIZaFAwlwU6FSCO2Uo/M qTIkNmEAXv2JihFLQjajgoRSkoReExOohZ0rFFyTdEbXl7hF7YjKjrR3er5HFKo= 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:content-transfer-encoding; s= cryptonector.com; bh=aqJ+7j6jGpDdmljTEI/INoWQnlw=; b=NUZNzcTs6iU xWjr84sue4zaBtGeqVb4ZjiuuoiVqk9/gJwNoLdN8if+KizzTmFyjTw1ffVJcQmo dEBBYDJ7I+pNdjzXIz+oD+dIZVYK0mcqcedSWpESMKRjMdklsGZ37L0KZBsZeBDz LHHWPZKOA8DOFL1BN1GLNrjo8MkZAxb4= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPSA id 18ECD94064 for ; Mon, 21 May 2012 11:07:03 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so7416791pbc.31 for ; Mon, 21 May 2012 11:07:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.226.73 with SMTP id rq9mr18029122pbc.145.1337623622765; Mon, 21 May 2012 11:07:02 -0700 (PDT) Received: by 10.68.5.99 with HTTP; Mon, 21 May 2012 11:07:02 -0700 (PDT) In-Reply-To: <416327B2-6E60-4D09-B3E7-D314F4FDD4E1@cs.columbia.edu> References: <300A2E9F-E99B-46FA-A101-E3611BD0D197@cs.columbia.edu> <877gw69h81.fsf@latte.josefsson.org> <4FB9ECA4.3010904@gmail.com> <78F24BEE-DD3B-474D-9E0B-1AC73CBE373A@vpnc.org> <416327B2-6E60-4D09-B3E7-D314F4FDD4E1@cs.columbia.edu> Date: Mon, 21 May 2012 13:07:02 -0500 Message-ID: From: Nico Williams To: Steven Bellovin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Paul Hoffman , IETF Security Area Advisory Group Subject: Re: [saag] Additions to RFC 3631? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 18:07:04 -0000 On Mon, May 21, 2012 at 12:59 PM, Steven Bellovin wro= te: > On May 21, 2012, at 1:06 49PM, Nico Williams wrote: >> On Mon, May 21, 2012 at 11:42 AM, Paul Hoffman w= rote:>>> +1 to adding EAP as a mechanism. >>> >>> +/-0 to adding channel bindings, given how few people understand them. >> >> EIther it's important/useful or not. =C2=A0If it is then having some tex= t >> in this RFC would help those people who don't understand CB. >> > I agree. But is it important/useful? Given that MSFT has implemented and deployed it I think it's at least usefu= l. I do think CB is important -- certainly as a protocol design/analysis tool. I also think it should be used more often. You'd think I would think that, given that I'm the author of RFC5056, but I like to think that I'm objective enough on this topic... enough so that I can tell you what the biggest problem with CB is: the fact that it's one more thing that the application developer has to know about and do. It'd be nice if more of the protocol stack up to and including application-layer authentication (where there is the option to do that) were abstracted. Still, CB is relatively simple: extract the CB from the channel, feed it to authentication. Nico -- From smb@cs.columbia.edu Mon May 21 11:09:40 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55B7821F8611 for ; Mon, 21 May 2012 11:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syOkFy5EFB9M for ; Mon, 21 May 2012 11:09:39 -0700 (PDT) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by ietfa.amsl.com (Postfix) with ESMTP id 9141021F85DF for ; Mon, 21 May 2012 11:09:39 -0700 (PDT) Received: from [192.168.2.166] (74-92-112-54-Philadelphia.hfc.comcastbusiness.net [74.92.112.54]) (user=smb2132 mech=PLAIN bits=0) by tarap.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id q4LI9XXh015915 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 21 May 2012 14:09:34 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Steven Bellovin In-Reply-To: Date: Mon, 21 May 2012 14:09:33 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <89DF3552-70F5-4110-8FDB-70C642610776@cs.columbia.edu> References: <300A2E9F-E99B-46FA-A101-E3611BD0D197@cs.columbia.edu> <877gw69h81.fsf@latte.josefsson.org> <4FB9ECA4.3010904@gmail.com> <78F24BEE-DD3B-474D-9E0B-1AC73CBE373A@vpnc.org> <416327B2-6E60-4D09-B3E7-D314F4FDD4E1@cs.columbia.edu> To: Nico Williams X-Mailer: Apple Mail (2.1278) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7 Cc: Paul Hoffman , IETF Security Area Advisory Group Subject: Re: [saag] Additions to RFC 3631? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 18:09:40 -0000 On May 21, 2012, at 2:07 02PM, Nico Williams wrote: > On Mon, May 21, 2012 at 12:59 PM, Steven Bellovin = wrote: >> On May 21, 2012, at 1:06 49PM, Nico Williams wrote: >>> On Mon, May 21, 2012 at 11:42 AM, Paul Hoffman = wrote:>>> +1 to adding EAP as a mechanism. >>>>=20 >>>> +/-0 to adding channel bindings, given how few people understand = them. >>>=20 >>> EIther it's important/useful or not. If it is then having some text >>> in this RFC would help those people who don't understand CB. >>>=20 >> I agree. >=20 > But is it important/useful? >=20 > Given that MSFT has implemented and deployed it I think it's at least = useful. >=20 > I do think CB is important -- certainly as a protocol design/analysis > tool. I also think it should be used more often. You'd think I would > think that, given that I'm the author of RFC5056, but I like to think > that I'm objective enough on this topic... enough so that I can tell > you what the biggest problem with CB is: the fact that it's one more > thing that the application developer has to know about and do. It'd > be nice if more of the protocol stack up to and including > application-layer authentication (where there is the option to do > that) were abstracted. Still, CB is relatively simple: extract the CB > from the channel, feed it to authentication. Thinking further, I'm not sure how much text should be in 3631bis, as = opposed to just having a pointer to 5056. But that's a minor point. --Steve Bellovin, https://www.cs.columbia.edu/~smb From yaronf.ietf@gmail.com Mon May 21 11:23:32 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF92921F864C for ; Mon, 21 May 2012 11:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.421 X-Spam-Level: X-Spam-Status: No, score=-102.421 tagged_above=-999 required=5 tests=[AWL=1.179, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9BTwQY+E+X+1 for ; Mon, 21 May 2012 11:23:31 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9106921F85FF for ; Mon, 21 May 2012 11:23:31 -0700 (PDT) Received: by bkty8 with SMTP id y8so5122032bkt.31 for ; Mon, 21 May 2012 11:23:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=pM1jKd8/ijcmDKDBaf/No/XxjZO4Dd+r0gOWmhMhUhA=; b=PWfTHIfxbKis4sFo51jpL6JITCpN8k+y9SfGtLFn7y5f6j1rxPdD7y66DOhUYqTOs7 eBI1vTg+tBj099qP/FBlLXMCrhCnu3xfeIY8lA9hBLhr+iSAVgs7WsH5BSHBFKnKAGZj 4v4bAug9ZSFLWJCXRJ9CJP3fP+RfweoJc+swIec2wDDfATHG4YsBXgLGzp/94QK4JsM/ nB8ZnawdC3/vr/Gga69VeXlFn8KzQUhYT/7MSlu5C3wMKroMX5W+A3llXLeg3zHk/vjk i9cp2qcAhvs9LOc/Lfd4CJ7N3TUpeb5oRNKBKgiBi3y9YiJV+DBFyOnT/vXwWOWyGjRc hVJA== Received: by 10.205.120.17 with SMTP id fw17mr8540035bkc.20.1337624610647; Mon, 21 May 2012 11:23:30 -0700 (PDT) Received: from [10.0.0.3] ([109.64.171.110]) by mx.google.com with ESMTPS id fu14sm2445586bkc.13.2012.05.21.11.23.29 (version=SSLv3 cipher=OTHER); Mon, 21 May 2012 11:23:29 -0700 (PDT) Message-ID: <4FBA8820.2030702@gmail.com> Date: Mon, 21 May 2012 21:23:28 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Joe Touch References: <300A2E9F-E99B-46FA-A101-E3611BD0D197@cs.columbia.edu> <877gw69h81.fsf@latte.josefsson.org> <4FB9ECA4.3010904@gmail.com> <78F24BEE-DD3B-474D-9E0B-1AC73CBE373A@vpnc.org> <4FBA7807.5080207@isi.edu> In-Reply-To: <4FBA7807.5080207@isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Paul Hoffman , IETF Security Area Advisory Group Subject: Re: [saag] Additions to RFC 3631? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 18:23:32 -0000 Trying my best to be unpopular: Much as I like the concept of BTNS, it hasn't caught on. I see this RFC as providing useful guidance to practitioners, and non-existent technology doesn't cut it. On the other hand, SSH "leap of faith" is very close to BTNS, and should in fact be mentioned in the paragraph that discusses SSH. In the context of SSH, "leap of faith" is much more innovative than what the current text focuses on. Email security takes up a significant part of the document (Sec. 3.10). We might wish otherwise (I do), but none of these mechanisms has been a real-world success. And very few people write new Email software anyway. So I would eliminate this section altogether or fold it into a paragraph or two in "Security/Multipart". Thanks, Yaron On 05/21/2012 08:14 PM, Joe Touch wrote: > > > On 5/21/2012 10:06 AM, Nico Williams wrote: >> On Mon, May 21, 2012 at 11:42 AM, Paul Hoffman >> wrote: >>> +1 to adding EAP as a mechanism. >>> >>> +/-0 to adding channel bindings, given how few people understand them. >> >> EIther it's important/useful or not. If it is then having some text >> in this RFC would help those people who don't understand CB. > > I'd add it - in fact, I would add both BTNS and TCP-AO, since neither > are covered and both serve different purposes than the mechanisms listed. > > I also feel that Sec 2.4 should be expanded to explain in more detail > how different levels of protection are used. > > Joe > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nico@cryptonector.com Mon May 21 11:27:22 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A32721F863F for ; Mon, 21 May 2012 11:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFcJY6NglQQL for ; Mon, 21 May 2012 11:27:22 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 1655E21F8611 for ; Mon, 21 May 2012 11:27:22 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id BFB3959805F for ; Mon, 21 May 2012 11:27:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=ZmjCuZqnwrhkPoQCoZ197 qFt804P34Yjm14D9BlvulA2fe8h9JJxIzrxpMJWpuBX7RTgnyVKghcDv9/K5bsxo nG/q1hjIKJGfuzLN6LWcGjDHLbAnIjJt8jtDWIKvmAPANkFaWdnfJyDBBKiNjA8U HvCB+GJJfbcNgzvXZHPNLU= 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=jaEN4kQ84/9pq7dxKR0Z R5j3ejI=; b=K/dvbHY5S//XA5NpbaHLqKYtwD4omh42Elk24oZzRStZvdV1TwDg 4GRnuzO6nVtNUr/kbu+UGQa0XnFxFlW3YlwT9S8Plk/OBmG3pGwN+p6IraFNe/aS Afjbv43JfbQvWjVhtjDWZjAGt/u4cfDUjoeWXW9NQBWeAj0Zoqhscks= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPSA id A3F9F598055 for ; Mon, 21 May 2012 11:27:21 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so7439073pbc.31 for ; Mon, 21 May 2012 11:27:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.218.72 with SMTP id pe8mr71596157pbc.45.1337624841336; Mon, 21 May 2012 11:27:21 -0700 (PDT) Received: by 10.68.5.99 with HTTP; Mon, 21 May 2012 11:27:21 -0700 (PDT) In-Reply-To: <4FBA8820.2030702@gmail.com> References: <300A2E9F-E99B-46FA-A101-E3611BD0D197@cs.columbia.edu> <877gw69h81.fsf@latte.josefsson.org> <4FB9ECA4.3010904@gmail.com> <78F24BEE-DD3B-474D-9E0B-1AC73CBE373A@vpnc.org> <4FBA7807.5080207@isi.edu> <4FBA8820.2030702@gmail.com> Date: Mon, 21 May 2012 13:27:21 -0500 Message-ID: From: Nico Williams To: Yaron Sheffer Content-Type: text/plain; charset=UTF-8 Cc: IETF Security Area Advisory Group , Paul Hoffman Subject: Re: [saag] Additions to RFC 3631? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 18:27:22 -0000 On Mon, May 21, 2012 at 1:23 PM, Yaron Sheffer wrote: > Trying my best to be unpopular: > > Much as I like the concept of BTNS, it hasn't caught on. I see this RFC as > providing useful guidance to practitioners, and non-existent technology > doesn't cut it. Hey, I said it too. > On the other hand, SSH "leap of faith" is very close to BTNS, and should in > fact be mentioned in the paragraph that discusses SSH. In the context of > SSH, "leap of faith" is much more innovative than what the current text > focuses on. Right. But note that for me BTNS was not about leap-of-faith, though that was a key selling point for some. For me BTNS was about anon-anon channels that could be bound into app-layer authentication. > Email security takes up a significant part of the document (Sec. 3.10). We > might wish otherwise (I do), but none of these mechanisms has been a > real-world success. And very few people write new Email software anyway. So > I would eliminate this section altogether or fold it into a paragraph or two > in "Security/Multipart". I assume e-mail is not secure. Secure e-mail that doesn't scale well is easy enough to do (PGP, S/MIME), but it has lots of issues beyond scalability. If you want secure e-mail use IM w/ OTR. (Hmmm, shouldn't OTR be an Internet protocol?) Nico -- From jhutz@cmu.edu Mon May 21 11:31:14 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDC2121F8687 for ; Mon, 21 May 2012 11:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.11 X-Spam-Level: X-Spam-Status: No, score=-105.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5BUn+Bcuo5BP for ; Mon, 21 May 2012 11:31:14 -0700 (PDT) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by ietfa.amsl.com (Postfix) with ESMTP id 3F50921F8681 for ; Mon, 21 May 2012 11:31:14 -0700 (PDT) Received: from [192.168.33.124] (c-67-165-85-247.hsd1.pa.comcast.net [67.165.85.247]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id q4LIVCTA027465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 May 2012 14:31:12 -0400 (EDT) From: Jeffrey Hutzelman To: Mouse In-Reply-To: <14199_1337398324_q4J3W3Uu015671_201205190331.XAA28531@Sparkle.Rodents-Montreal.ORG> References: <300A2E9F-E99B-46FA-A101-E3611BD0D197@cs.columbia.edu> <14199_1337398324_q4J3W3Uu015671_201205190331.XAA28531@Sparkle.Rodents-Montreal.ORG> Content-Type: text/plain; charset="UTF-8" Date: Mon, 21 May 2012 14:31:02 -0400 Message-ID: <1337625062.2813.60.camel@destiny.pc.cs.cmu.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Cc: saag@ietf.org, jhutz@cmu.edu Subject: Re: [saag] Additions to RFC 3631? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 18:31:14 -0000 On Fri, 2012-05-18 at 23:31 -0400, Mouse wrote: > > nor is it ever transmitted over the network. > > Again, this depends on the OTP scheme; indeed, most OTP schemes I am > aware of do indeed transmit the passwords used for authentication. In fact, IMHO this has always been one of the main advantages of OTP schemes -- passwords can be disclosed during authentication, because they cannot be reused. > > 3.3. IPsec > > > The key management for IPsec can use either certificates or shared > > secrets. For all the obvious reasons, certificates are preferred; > > however, they may present more of a headache for the system manager. > > The statement that certificates "are preferred" is either false or > incomplete, because certs are preferred only for certain classes of > uses. For others, a shared secret is better - different uses, > different tradeoffs. Agreed. And in fact, the statement that certificates or preshared secrets are the only available options is also false. Last I checked, it was also possible to use Kerberos (KINK, RFC4430) or any EAP method (IKEv2, RFC5996). -- Jeff From touch@isi.edu Tue May 22 10:00:35 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D71021F8630 for ; Tue, 22 May 2012 10:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2K7kUpwlBmpt for ; Tue, 22 May 2012 10:00:34 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9FC21F8606 for ; Tue, 22 May 2012 10:00:34 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q4MGxZ1g013014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 22 May 2012 09:59:35 -0700 (PDT) Message-ID: <4FBBC5F7.3030008@isi.edu> Date: Tue, 22 May 2012 09:59:35 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Nico Williams References: <300A2E9F-E99B-46FA-A101-E3611BD0D197@cs.columbia.edu> <877gw69h81.fsf@latte.josefsson.org> <4FB9ECA4.3010904@gmail.com> <78F24BEE-DD3B-474D-9E0B-1AC73CBE373A@vpnc.org> <4FBA7807.5080207@isi.edu> <4FBA8820.2030702@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Paul Hoffman , IETF Security Area Advisory Group Subject: Re: [saag] Additions to RFC 3631? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 17:00:35 -0000 On 5/21/2012 11:27 AM, Nico Williams wrote: > On Mon, May 21, 2012 at 1:23 PM, Yaron Sheffer wrote: >> Trying my best to be unpopular: >> >> Much as I like the concept of BTNS, it hasn't caught on. I see this RFC as >> providing useful guidance to practitioners, and non-existent technology >> doesn't cut it. > > Hey, I said it too. > >> On the other hand, SSH "leap of faith" is very close to BTNS, and should in >> fact be mentioned in the paragraph that discusses SSH. In the context of >> SSH, "leap of faith" is much more innovative than what the current text >> focuses on. > > Right. But note that for me BTNS was not about leap-of-faith, though > that was a key selling point for some. For me BTNS was about > anon-anon channels that could be bound into app-layer authentication. Or useful even without further authentication - by raising the effort of an attacker -- i.e., attacks need to do the work of a flash-crowd; merely tossing RSTs at TCP connections wouldn't work under BTNS, even without tying security at that connection to another layer. And that sort of protection is possible without *any* KMI. Joe From Hannes.Tschofenig@gmx.net Wed May 23 05:42:04 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E5B21F86E5 for ; Wed, 23 May 2012 05:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nu29qyYCrbpZ for ; Wed, 23 May 2012 05:42:03 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 645EF21F86EA for ; Wed, 23 May 2012 05:42:02 -0700 (PDT) Received: (qmail 23548 invoked by uid 0); 23 May 2012 12:42:01 -0000 Received: from 62.159.77.165 by www051.gmx.net with HTTP; Wed, 23 May 2012 14:42:00 +0200 (CEST) Content-Type: text/plain; charset="utf-8" Date: Wed, 23 May 2012 14:42:00 +0200 From: "Hannes Tschofenig" In-Reply-To: <300A2E9F-E99B-46FA-A101-E3611BD0D197@cs.columbia.edu> Message-ID: <20120523124200.17700@gmx.net> MIME-Version: 1.0 References: <300A2E9F-E99B-46FA-A101-E3611BD0D197@cs.columbia.edu> To: Steven Bellovin , saag@ietf.org X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX18oO6Ur168os8gxh+jvowAFGzd39LSJ6S7bHuk3D3 Gma178jb0eKqQWaYk4m1Qc+3mMTvPEcwMcoQ== Content-Transfer-Encoding: 8bit X-GMX-UID: T77Ob45neSEqNpIAqXUhnVV+IGRvb8AJ Subject: Re: [saag] Additions to RFC 3631? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 12:42:05 -0000 Hi Steve, to me it is not clear who the target audience of the document is and what purpose it serves. The early part of the document contains a threat model discussion. That's good but I believe that the writeup in BCP 72 is more useful. There is a laundry list of security mechanisms in Section 3. Do you expect that someone who does not know these mechanisms already to go through this list and pick one for their new protocol design? Then, Section 4 talks about things one shouldn't do. Those are great suggestions but we actively do them today in the IETF. For example, I have been complaining about the work in the INTAREA were folks are define new ways to do IP address-based authentication in light of the widespread NAT deployments (see my comments to the list last year http://permalink.gmane.org/gmane.ietf.int/3016). As you stated on the mailing list: > 3631 says "if you want to put security into a protocol, > here are the best choices we have today". Is this really how we approach protocol design today? I don't think so. There are two classes of protocol designs: 1) Extensions to existing protocols (DNS, email, routing protocols, etc.) There you have to work with what is available already and your choices are impacted by the deployment. The improvements tend to be minor and speed of deployment is slow. 2) For new protocol designs, many focus on using HTTP/HTTPS as a starting point. Almost all protocols I have seen have the need for offering the classical communication security features and TLS is the main building block. Everything beyond that is typically tough and quite difficult to describe in a generic fashion. On top of that I am not even sure that the process we have for tackling security in the IETF is actually as successful as we would like it to be. We typically consider the security consideration section writeup as the crucial part but I am wondering whether others had looked at the broader picture on where things went well and where they didn't. In fact, I would be far more interested to hear where the problems really are rather than producing another hitchhiker's guide to IETF security protocols. In any case, I will not stop you from shipping an update (which I am not sure you can even do that given it is an IAB document) but I doubt that it will have the desired impact. Ciao Hannes -------- Original-Nachricht -------- > Datum: Fri, 18 May 2012 22:31:39 -0400 > Von: Steven Bellovin > An: IETF Security Area Advisory Group > Betreff: [saag] Additions to RFC 3631? > Does anyone have any suggestions for additions or corrections to RFC 3631? > It looks to me like it's held up pretty well, save for newer versions of > some of the protocols. > > --Steve Bellovin, https://www.cs.columbia.edu/~smb > > > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nico@cryptonector.com Wed May 23 07:13:39 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE83321F8694 for ; Wed, 23 May 2012 07:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1tRJBKHK4Ed for ; Wed, 23 May 2012 07:13:39 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 7947E21F86F7 for ; Wed, 23 May 2012 07:13:39 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id 8A20E508082 for ; Wed, 23 May 2012 07:13:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=oJXc8MyZGAQoXZLzOgwO1 73pnyDH/aIjLorLEj3afie3XxrbrkP0Aw9S1vY48D4JZeRTUGdU/F9HgxPeyoTar 3rBrlEKyr6egi7Yxmb7ODOcpmfrkSXvxZajuUbxdQ/GjOXlYPm090A0KqnfYGehq uFZO5mvujvP5bpLhMLFEQM= 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=6zMfVa5TDd9MGw3qMI7m MvdZybw=; b=qBt6INilZYCApkJxUgjv9wKaXUyK5BMYVsJWTDayd6mMVad9Jtc4 szYF+PKd4Qrqu5GHzRsn/dT3FWVYJM25itLcQoHna7m/mQQnzgz0Vj3nE4ai8pPU +uYN1xMPCBws46kM3oKTD2Yx3jmDGXMfeaIjkp2UnVftYfYfB/a7arE= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id 3521950807D for ; Wed, 23 May 2012 07:13:38 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so10185558pbc.31 for ; Wed, 23 May 2012 07:13:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.213.71 with SMTP id nq7mr1201847pbc.7.1337782417095; Wed, 23 May 2012 07:13:37 -0700 (PDT) Received: by 10.68.15.134 with HTTP; Wed, 23 May 2012 07:13:37 -0700 (PDT) In-Reply-To: <20120523124200.17700@gmx.net> References: <300A2E9F-E99B-46FA-A101-E3611BD0D197@cs.columbia.edu> <20120523124200.17700@gmx.net> Date: Wed, 23 May 2012 09:13:37 -0500 Message-ID: From: Nico Williams To: Hannes Tschofenig Content-Type: text/plain; charset=UTF-8 Cc: saag@ietf.org Subject: Re: [saag] Additions to RFC 3631? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 14:13:40 -0000 On Wed, May 23, 2012 at 7:42 AM, Hannes Tschofenig wrote: > to me it is not clear who the target audience of the document is and what purpose it serves. One target audience would clearly be those who don't wallow in the security area. There's probably an unstated purpose of simple advertising, and maybe to have a tool to beat others with (ISTR someone trying to argue from absence of some definition in the security glossary, that is, using the security glossary as an authority). Perhaps this document can serve as a summary applicability statement, say. There is a risk is that we'll all just argue endlessly about various details, possibly leading to a bloated document. But it does seem like a nice idea: to have a guide to an entire area's past output. Nico -- From smb@cs.columbia.edu Wed May 23 07:34:17 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9B5721F86E5 for ; Wed, 23 May 2012 07:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Hi0ZjKB+Oal for ; Wed, 23 May 2012 07:34:17 -0700 (PDT) Received: from paneer.cc.columbia.edu (paneer.cc.columbia.edu [128.59.29.4]) by ietfa.amsl.com (Postfix) with ESMTP id D3CA621F8736 for ; Wed, 23 May 2012 07:34:16 -0700 (PDT) Received: from [192.168.2.166] (74-92-112-54-Philadelphia.hfc.comcastbusiness.net [74.92.112.54]) (user=smb2132 mech=PLAIN bits=0) by paneer.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id q4NEY96A010977 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 23 May 2012 10:34:09 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Steven Bellovin X-Priority: 3 In-Reply-To: <20120523124200.17700@gmx.net> Date: Wed, 23 May 2012 10:34:08 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3A61C9D8-1584-4A8C-95D8-A52963BB4A80@cs.columbia.edu> References: <300A2E9F-E99B-46FA-A101-E3611BD0D197@cs.columbia.edu> <20120523124200.17700@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1278) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.4 Cc: saag@ietf.org Subject: Re: [saag] Additions to RFC 3631? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 14:34:18 -0000 Thanks for your comments. I don't agree with all of them (more inline), = but I should note that I have no plans to update 3631 myself. I'm = working on another project; it occurred to me that this laundry list of = protocols -- it's a fine characterization -- was a good starting point = for my recommendations. On May 23, 2012, at 8:42 00AM, Hannes Tschofenig wrote: > Hi Steve,=20 >=20 > to me it is not clear who the target audience of the document is and = what purpose it serves.=20 >=20 > The early part of the document contains a threat model discussion. = That's good but I believe that the writeup in BCP 72 is more useful.=20 >=20 > There is a laundry list of security mechanisms in Section 3. Do you = expect that someone who does not know these mechanisms already to go = through this list and pick one for their new protocol design? Up to a point, yes. It's not useful for people who know nothing of = security, and it's redundant for folks who do security for a living. = It's useful, though, for people who know something of these mechanisms = but are not sure which to use. >=20 > Then, Section 4 talks about things one shouldn't do. Those are great = suggestions but we actively do them today in the IETF. For example, I = have been complaining about the work in the INTAREA were folks are = define new ways to do IP address-based authentication in light of the = widespread NAT deployments (see my comments to the list last year = http://permalink.gmane.org/gmane.ietf.int/3016). The fact that folks are still doing them doesn't mean that we were wrong = when we wrote 3631, merely that folks haven't paid enough attention to = it. In retrospect, I suspect we should have tried publishing it as BCP; = were I still an AD or on the IAB, I'd suggest that for any updated = version. >=20 > As you stated on the mailing list:=20 >> 3631 says "if you want to put security into a protocol,=20 >> here are the best choices we have today". >=20 > Is this really how we approach protocol design today? I don't think = so. >=20 > There are two classes of protocol designs:=20 >=20 > 1) Extensions to existing protocols (DNS, email, routing protocols, = etc.) > There you have to work with what is available already and your choices = are impacted by the deployment. The improvements tend to be minor and = speed of deployment is slow.=20 Retrofitting security to an existing system is one of the hardest tasks = out there. It's not even the deployment, it's the design choices = already made that constrain things. DNSSEC is a classic example. No = one loves it or even likes it, I suspect, but I don't know that it could = have been better, given the basic structure and assumptions that date to = the earl 1980s. >=20 > 2) For new protocol designs, many focus on using HTTP/HTTPS as a = starting point. Almost all protocols I have seen have the need for = offering the classical communication security features and TLS is the = main building block. Everything beyond that is typically tough and quite = difficult to describe in a generic fashion.=20 That HTTP[S] is a basic building block is a separate problem; it's the = new waist of the hourglass... >=20 > On top of that I am not even sure that the process we have for = tackling security in the IETF is actually as successful as we would like = it to be. We typically consider the security consideration section = writeup as the crucial part but I am wondering whether others had looked = at the broader picture on where things went well and where they didn't. = In fact, I would be far more interested to hear where the problems = really are rather than producing another hitchhiker's guide to IETF = security protocols.=20 Is it perfect? Of course not. I do think it's significantly better = than it was 10-15 years ago. 3631 and BCP 72 (which my email archives show was initiated no later = than 1999) were part of a process to improve the security of IETF = protocols. Another part was retargeting the security directorate to = review all documents, and get at least some involvement early on in = protocol design. That part didn't work as well as I had hoped, at least = back when I was AD, but it was far better than we'd had before. That = effort, though, was a fair number of years ago. I've been rather = disconnected from the IETF since 2005; I don't know what the current = real issues are. I'll leave it to the current IESG to figure out what = to do next. A more systematic study would indeed be a good idea. (I = know from private conversations that the Security ADs have at least some = thoughts on the subject.) >=20 > In any case, I will not stop you from shipping an update (which I am = not sure you can even do that given it is an IAB document) but I doubt = that it will have the desired impact.=20 >=20 > Ciao > Hannes >=20 > -------- Original-Nachricht -------- >> Datum: Fri, 18 May 2012 22:31:39 -0400 >> Von: Steven Bellovin >> An: IETF Security Area Advisory Group >> Betreff: [saag] Additions to RFC 3631? >=20 >> Does anyone have any suggestions for additions or corrections to RFC = 3631? >> It looks to me like it's held up pretty well, save for newer versions = of >> some of the protocols. >>=20 >> --Steve Bellovin, https://www.cs.columbia.edu/~smb >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >=20 --Steve Bellovin, https://www.cs.columbia.edu/~smb From stephen.farrell@cs.tcd.ie Wed May 23 15:53:47 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E16411E80A4 for ; Wed, 23 May 2012 15:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nlK8E2RIsq5g for ; Wed, 23 May 2012 15:53:46 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 3B18721F84E1 for ; Wed, 23 May 2012 15:53:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 7B989171F2D; Wed, 23 May 2012 23:53:45 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1337813625; bh=Nz0Zl8GbOw75oe630C2pURM+ BjnbbcG9ARM86OZoqFc=; b=6XcseFiir0dv3fUz5GmgParvA/IgmiQKJlNqnQrG UANBiKHfQ6zb9yocahtzhZ+1jE/TWKERj6x3KWLoGaXsp3p8iQuikzx6FH47l62o VubrcRl+iwOwfNixQVpbol+cACrbR1hD1myfDL8dn/L/qxXoYbvP/+AkDfIqAZ/b ugoulj6zgt2AMT/3R9kkvC/UtQ6wV4HKI+zjILEJPZTR9YIwwLy+cLap+SKj/6s5 4QeCUoiu6N2nJ2JdAlcpvcrOh1nfMLuep80NerZHQSn8MjNsMArCXWMlMfrYBfGf ykgSvvH9R/VBCcxY24eX8C8ItT3QEnucja+WRK7pZmtRFA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 7dJ6y6ulxrpl; Wed, 23 May 2012 23:53:45 +0100 (IST) Received: from [10.87.48.8] (unknown [86.45.50.128]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id E19C6171C65; Wed, 23 May 2012 23:53:44 +0100 (IST) Message-ID: <4FBD6A78.2070204@cs.tcd.ie> Date: Wed, 23 May 2012 23:53:44 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "saag@ietf.org" X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [saag] should we revise rfc 3365? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 22:53:47 -0000 Hi all, Short version: go read the RFC and say if you think it needs an update. Long version: We've been talking about RFC 3261 but Sean and I have independently been thinking about whether there's work to be done on RFC 3365 [1] from 2002 which is the one that basically says you "MUST implement strong security in all protocols" and for very good reasons. First, we are *not* proposing to back off from that general position. (We'll say that again in a minute in case you missed it:-) Since 2002 however, we've seen some cases where this might end up being a bit counter-productive or where its not clear if or how 3365 applies. DHCP AUTH [2] is frequently cited in DHCP security considerations. However, this is pure fiction, nobody uses it at all, and I'm not sure if anybody even implements it. SIP e2e security [3] is well defined and has been implemented, but is ubiquitously unused, even though other SIP specifications tend(ed) to refer to it as if it solves their problems. FLUTE [4] is a uni-directional protocol, that RECOMMENDS transport mode ESP, but where its not clear that you could sensibly do automated key management, if you really only have one-way connectivity. (Just including this one to show not all of 'em are as obvious as the above.) In the purely fictional cases, there is a cost for developers clearly, but also a potential security downside, if there's a bunch of relatively untested code being deployed, or if some but not all people know which things are fictional and which not. In these cases the trade-off seems to be between specifying MTI security vs. truth-in-advertising. Some of these are easy, (dhcp maybe), others are less easy (flute). Truth-in-advertising seems like its a good thing, but its hard to see how to get that without also creating a future where lots of drafts say "we don't do security because nobody would use it." I'm sure there are more existing cases along those lines. Separately, we're seeing a number of cases where something that is like, but is not, e2e security is being proposed. For example, for inserting adverts in IPTV [5], for supporting SSL accelerators [6] and perhaps in the near future, for so-called "tusted proxies" in HTTP/2.0 [7]. Again, there are probably more cases of this, but here the trade-off seems mainly to be between what are real use cases (sometimes already widely deployed) and e2e security. Our question to you: is it time that we revised RFC 3365 to say something about these issues, or more generally? If so, then how? (Bearing in mind that we are *not* open to a revision that neuters the position taken in 3365.) If you think RFC 3365 is still just fine and we should not try revise it, then saying that would also be good. If a substantive discussion emerges we'd hope to talk about that in Vancouver in July, so nothing precipitous will happen. If this is greeted by silence, then we'll take it that you all like RFC 3365 and don't want us to do anything (except keep on pushing back when people don't specify mandatory-to-implement security:-) but that will continue to be problematic in cases like those mentioned above, so we may not be getting the best outcomes at the moment in such cases. Thanks, Stephen and Sean. [1] http://tools.ietf.org/html/bcp61 [2] http://tools.ietf.org/html/rfc3118 [3] http://tools.ietf.org/html/rfc3261 [4] https://datatracker.ietf.org/doc/draft-ietf-rmt-flute-revised/ [5] https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-for-rtp/ [6] https://datatracker.ietf.org/doc/draft-ietf-appsawg-http-forwarded/ [7] http://lists.w3.org/Archives/Public/ietf-http-wg/2012AprJun/0085.html From mouse@Sparkle.Rodents-Montreal.ORG Wed May 23 16:51:03 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B544821F86E1 for ; Wed, 23 May 2012 16:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.873 X-Spam-Level: X-Spam-Status: No, score=-8.873 tagged_above=-999 required=5 tests=[AWL=1.115, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5359fhpVVHQr for ; Wed, 23 May 2012 16:51:03 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by ietfa.amsl.com (Postfix) with ESMTP id 0549E21F86DC for ; Wed, 23 May 2012 16:51:02 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id TAA23415; Wed, 23 May 2012 19:51:01 -0400 (EDT) Date: Wed, 23 May 2012 19:51:01 -0400 (EDT) From: Mouse Message-Id: <201205232351.TAA23415@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Wed, 23 May 2012 19:26:34 -0400 (EDT) To: saag@ietf.org In-Reply-To: <4FBD6A78.2070204@cs.tcd.ie> References: <4FBD6A78.2070204@cs.tcd.ie> Subject: Re: [saag] should we revise rfc 3365? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 23:51:03 -0000 > Short version: go read [RFC 3365] and say if you think it needs an > update. Yes, but I believe it's not one you're willing to accept. > "MUST implement strong security in all protocols" I believe this is too dogmatic a position, and will simply lead to IETF process being ignored in those cases where strong security is unnecessary or undeisrable. Consider, for example, the number of useful protocols we have today that could not be standardized under this policy: whois, SMTP, and DHCP come to mind. Based on a quick skim of the specs, NFS is another one (even v4 doesn't seem to have MTI security, only an MTI framework within which security can optionally be done - but that's just a quick skim; I could easily have missed something). I know that, as an occasional protocol designer, if I believe a protocol has no need for security, I would sooner ignore the IETF than I would bother with shoehorning enough security to satisfy the IETF into it. Aside from this excessively (I believe) dogmatic position, I see nothing wrong with 3365. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From smb@cs.columbia.edu Wed May 23 17:08:52 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9404221F8736 for ; Wed, 23 May 2012 17:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12EbmDfltJak for ; Wed, 23 May 2012 17:08:51 -0700 (PDT) Received: from salak.cc.columbia.edu (salak.cc.columbia.edu [128.59.29.6]) by ietfa.amsl.com (Postfix) with ESMTP id 857F821F86F0 for ; Wed, 23 May 2012 17:08:51 -0700 (PDT) Received: from [192.168.2.166] (74-92-112-54-Philadelphia.hfc.comcastbusiness.net [74.92.112.54]) (user=smb2132 mech=PLAIN bits=0) by salak.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id q4O08l5l018068 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 23 May 2012 20:08:48 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Steven Bellovin In-Reply-To: <4FBD6A78.2070204@cs.tcd.ie> Date: Wed, 23 May 2012 20:08:47 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <4FBD6A78.2070204@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1278) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.6 Cc: "saag@ietf.org" Subject: Re: [saag] should we revise rfc 3365? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 00:08:52 -0000 I'm very much in favor of security realism. If something doesn't work, it doesn't work. One reason I wrote RFC 5406 is that protocols were specifying it as their security solution, when (a) it was never implemented, and (b) it probably couldn't work anyway. DHCP AUTH is a good example -- the whole point is minimal or no configuration. I suspect that the proper security spec there is "buy a switch that blocks rogue DHCP (and IPv6 RA) packets)." The specific changes, though, are a lot more difficult. For example, I'd leave the SIP stuff alone; I think there's a disaster there waiting to happen, and I suspect that we will see security implemented and deployed in a very big hurry. On May 23, 2012, at 6:53 44PM, Stephen Farrell wrote: > > Hi all, > > Short version: go read the RFC and say if you think > it needs an update. > > Long version: > > We've been talking about RFC 3261 but Sean and I > have independently been thinking about whether > there's work to be done on RFC 3365 [1] from > 2002 which is the one that basically says you > "MUST implement strong security in all protocols" > and for very good reasons. > > First, we are *not* proposing to back off from that > general position. (We'll say that again in a > minute in case you missed it:-) > > Since 2002 however, we've seen some cases where > this might end up being a bit counter-productive > or where its not clear if or how 3365 applies. > > DHCP AUTH [2] is frequently cited in DHCP > security considerations. However, this is pure > fiction, nobody uses it at all, and I'm not > sure if anybody even implements it. > > SIP e2e security [3] is well defined and has > been implemented, but is ubiquitously unused, > even though other SIP specifications tend(ed) > to refer to it as if it solves their problems. > > FLUTE [4] is a uni-directional protocol, that > RECOMMENDS transport mode ESP, but where its not > clear that you could sensibly do automated key > management, if you really only have one-way > connectivity. (Just including this one to show > not all of 'em are as obvious as the above.) > > In the purely fictional cases, there is a cost > for developers clearly, but also a potential > security downside, if there's a bunch of relatively > untested code being deployed, or if some but not > all people know which things are fictional and > which not. > > In these cases the trade-off seems to be between > specifying MTI security vs. truth-in-advertising. > Some of these are easy, (dhcp maybe), others are > less easy (flute). > > Truth-in-advertising seems like its a good thing, > but its hard to see how to get that without also > creating a future where lots of drafts say "we > don't do security because nobody would use it." > > I'm sure there are more existing cases along > those lines. > > > Separately, we're seeing a number of cases where > something that is like, but is not, e2e security is > being proposed. For example, for inserting adverts > in IPTV [5], for supporting SSL accelerators [6] > and perhaps in the near future, for so-called > "tusted proxies" in HTTP/2.0 [7]. > > Again, there are probably more cases of this, but > here the trade-off seems mainly to be between what > are real use cases (sometimes already widely > deployed) and e2e security. > > > Our question to you: is it time that we revised > RFC 3365 to say something about these issues, or > more generally? > > If so, then how? (Bearing in mind that we are *not* > open to a revision that neuters the position taken > in 3365.) > > If you think RFC 3365 is still just fine and we > should not try revise it, then saying that would > also be good. > > If a substantive discussion emerges we'd hope to > talk about that in Vancouver in July, so nothing > precipitous will happen. If this is greeted by > silence, then we'll take it that you all like > RFC 3365 and don't want us to do anything (except > keep on pushing back when people don't specify > mandatory-to-implement security:-) but that > will continue to be problematic in cases like those > mentioned above, so we may not be getting the > best outcomes at the moment in such cases. > > Thanks, > Stephen and Sean. > > [1] http://tools.ietf.org/html/bcp61 > [2] http://tools.ietf.org/html/rfc3118 > [3] http://tools.ietf.org/html/rfc3261 > [4] https://datatracker.ietf.org/doc/draft-ietf-rmt-flute-revised/ > [5] https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-for-rtp/ > [6] https://datatracker.ietf.org/doc/draft-ietf-appsawg-http-forwarded/ > [7] http://lists.w3.org/Archives/Public/ietf-http-wg/2012AprJun/0085.html > > > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --Steve Bellovin, https://www.cs.columbia.edu/~smb From touch@isi.edu Wed May 23 17:57:09 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 161FB11E809B for ; Wed, 23 May 2012 17:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qj3D+UB9enBF for ; Wed, 23 May 2012 17:57:08 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id A9FDD11E8088 for ; Wed, 23 May 2012 17:57:08 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q4O0uTpN016957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 23 May 2012 17:56:29 -0700 (PDT) Message-ID: <4FBD873D.3090802@isi.edu> Date: Wed, 23 May 2012 17:56:29 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Mouse References: <4FBD6A78.2070204@cs.tcd.ie> <201205232351.TAA23415@Sparkle.Rodents-Montreal.ORG> In-Reply-To: <201205232351.TAA23415@Sparkle.Rodents-Montreal.ORG> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: saag@ietf.org Subject: Re: [saag] should we revise rfc 3365? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 00:57:09 -0000 On 5/23/2012 4:51 PM, Mouse wrote: >> Short version: go read [RFC 3365] and say if you think it needs an >> update. > > Yes, but I believe it's not one you're willing to accept. > >> "MUST implement strong security in all protocols" To open a can of worms, this would also be a good doc in which to discuss the need for secure ports, and whether (or not) to ever assign meaning to the difference between system and user ports... I was hoping to potentially open those discussions on TSVWG regarding the user-ports draft, but it might also be relevant here. I'm not sure if either will come to conclusion, but a round of discussion seems in order. Joe From mouse@Sparkle.Rodents-Montreal.ORG Wed May 23 20:39:45 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C52F611E80B6 for ; Wed, 23 May 2012 20:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.945 X-Spam-Level: X-Spam-Status: No, score=-8.945 tagged_above=-999 required=5 tests=[AWL=0.443, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVwU5xsmBYLE for ; Wed, 23 May 2012 20:39:45 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by ietfa.amsl.com (Postfix) with ESMTP id CDBA811E8091 for ; Wed, 23 May 2012 20:39:44 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id XAA25498; Wed, 23 May 2012 23:39:43 -0400 (EDT) Date: Wed, 23 May 2012 23:39:43 -0400 (EDT) From: Mouse Message-Id: <201205240339.XAA25498@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Wed, 23 May 2012 23:31:54 -0400 (EDT) To: saag@ietf.org In-Reply-To: <4FBD873D.3090802@isi.edu> References: <4FBD6A78.2070204@cs.tcd.ie> <201205232351.TAA23415@Sparkle.Rodents-Montreal.ORG> <4FBD873D.3090802@isi.edu> Subject: Re: [saag] should we revise rfc 3365? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 03:39:45 -0000 >> [RFC 3365] > To open a can of worms, this would also be a good doc in which to > discuss the need for secure ports, and whether (or not) to ever > assign meaning to the difference between system and user ports... I submit that attempting to make such a distinction is effectively meaningless, and has been ever since single-user machines - machines owned personally by individuals who are their administrators - became even moderately common. It meant something (though even then not much) in the days of large multi-user machines whose administrators could reasonably be treated by the rest of the net as more trusted than the bulk of their users. Those days are long past; between personal machines and pwn3d windows boxen, I think it is now pointless. To look at it another way, there can be no distinction between system and user ports from the point of view of network-observable behaviour, since the "system"-vs-"user" distinction, to the extent that it exists at all, is entirely private to each host; it is, therefore, pointless to try to mandate any such difference. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From hannes.tschofenig@nsn.com Thu May 24 00:08:20 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63FC911E809A for ; Thu, 24 May 2012 00:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bzs4XPIWcfrQ for ; Thu, 24 May 2012 00:08:19 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 8B56311E80A6 for ; Thu, 24 May 2012 00:08:18 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q4O78A2Z021744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 24 May 2012 09:08:10 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q4O786X3016119; Thu, 24 May 2012 09:08:10 +0200 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 May 2012 09:07:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 24 May 2012 10:07:48 +0300 Message-ID: <999913AB42CC9341B05A99BBF358718D017BA190@FIESEXC035.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Additions to RFC 3631? Thread-Index: Ac047kTkBlQZy6m5SA+ycOnDU/n4uQAjGzPA References: <300A2E9F-E99B-46FA-A101-E3611BD0D197@cs.columbia.edu><20120523124200.17700@gmx.net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Nico Williams" , "Hannes Tschofenig" X-OriginalArrivalTime: 24 May 2012 07:07:50.0378 (UTC) FILETIME=[EE3454A0:01CD397B] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 2366 X-purgate-ID: 151667::1337843290-00005945-E46C3426/0-0/0-0 Cc: saag@ietf.org Subject: Re: [saag] Additions to RFC 3631? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 07:08:20 -0000 Hi Nico,=20 > On Wed, May 23, 2012 at 7:42 AM, Hannes Tschofenig > wrote: > > to me it is not clear who the target audience of the document is and > what purpose it serves. >=20 > One target audience would clearly be those who don't wallow in the > security area. There's probably an unstated purpose of simple > advertising, and maybe to have a tool to beat others with (ISTR > someone trying to argue from absence of some definition in the > security glossary, that is, using the security glossary as an > authority). Perhaps this document can serve as a summary > applicability statement, say. There is a risk is that we'll all just > argue endlessly about various details, possibly leading to a bloated > document. But it does seem like a nice idea: to have a guide to an > entire area's past output. >=20 > Nico I would like to have a more precise target audience and purpose.=20 For example, I make a differentiation between someone who actively participates in the IETF (but in groups outside the security area) and wants to address security in his or her favorite protocol design vs. someone who does not even participate in the IETF. For the former group we have http://tools.ietf.org/html/rfc3552, also the Sunday IETF education session, potentially the SAAG meeting, various other IETF related publications about ongoing security activities (e.g., IPJ). Now, we also have some privacy related guidance they can look at http://tools.ietf.org/html/draft-iab-privacy-considerations-02.=20 In general, the difficulty is to keep the list of protocols and recommended best current practice up-to-date.=20 If we are, however, talking about engineers outside the IETF who should also be given guidance about security (since they are supposed to use IETF protocols as well) then things get a bit more complicated. Typically, that has not been the audience of our documents. There are, however, exceptions. Consider for example http://tools.ietf.org/html/rfc6272 where Fred tried to provide guidance for those working on smart grids/smart meters and it also includes a list of protocols that he thought would be relevant for that specific domain. The writing style is obviously quite different and assumes far less knowledge about the IETF process and procedures.=20 Ciao Hannes From hannes.tschofenig@nsn.com Thu May 24 00:23:36 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 616B211E80AB for ; Thu, 24 May 2012 00:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stdVp6VB2lG2 for ; Thu, 24 May 2012 00:23:35 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id E4AF411E8076 for ; Thu, 24 May 2012 00:23:34 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q4O7NKHr029255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 24 May 2012 09:23:20 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q4O7NGqc006052; Thu, 24 May 2012 09:23:20 +0200 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 May 2012 09:23:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 24 May 2012 10:23:13 +0300 Message-ID: <999913AB42CC9341B05A99BBF358718D017BA1B8@FIESEXC035.nsn-intra.net> In-Reply-To: <3A61C9D8-1584-4A8C-95D8-A52963BB4A80@cs.columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Additions to RFC 3631? Thread-Index: Ac048SYMnPwJKXJSTl2YmMjpGHggLAAisx1Q References: <300A2E9F-E99B-46FA-A101-E3611BD0D197@cs.columbia.edu><20120523124200.17700@gmx.net> <3A61C9D8-1584-4A8C-95D8-A52963BB4A80@cs.columbia.edu> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Steven Bellovin" , "Hannes Tschofenig" X-OriginalArrivalTime: 24 May 2012 07:23:16.0899 (UTC) FILETIME=[16743730:01CD397E] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 7780 X-purgate-ID: 151667::1337844201-00005945-457BBB7D/0-0/0-0 Cc: saag@ietf.org Subject: Re: [saag] Additions to RFC 3631? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 07:23:36 -0000 Hi Steve,=20 Thanks for your quick response. A few remarks inline:=20 > Thanks for your comments. I don't agree with all of them (more > inline), but I should note that I have no plans to update 3631 myself. > I'm working on another project; it occurred to me that this laundry > list of protocols -- it's a fine characterization -- was a good > starting point for my recommendations. >=20 > On May 23, 2012, at 8:42 00AM, Hannes Tschofenig wrote: >=20 > > Hi Steve, > > > > to me it is not clear who the target audience of the document is and > what purpose it serves. > > > > The early part of the document contains a threat model discussion. > That's good but I believe that the writeup in BCP 72 is more useful. > > > > There is a laundry list of security mechanisms in Section 3. Do you > expect that someone who does not know these mechanisms already to go > through this list and pick one for their new protocol design? >=20 > Up to a point, yes. It's not useful for people who know nothing of > security, and it's redundant for folks who do security for a living. > It's useful, though, for people who know something of these mechanisms > but are not sure which to use. To give someone a suggestion who does not know anything about security I would actually point them to http://tools.ietf.org/html/rfc4101 instead of letting them look at security protocols.=20 > > > > Then, Section 4 talks about things one shouldn't do. Those are great > suggestions but we actively do them today in the IETF. For example, I > have been complaining about the work in the INTAREA were folks are > define new ways to do IP address-based authentication in light of the > widespread NAT deployments (see my comments to the list last year > http://permalink.gmane.org/gmane.ietf.int/3016). >=20 > The fact that folks are still doing them doesn't mean that we were > wrong when we wrote 3631, merely that folks haven't paid enough > attention to it. In retrospect, I suspect we should have tried > publishing it as BCP; were I still an AD or on the IAB, I'd suggest > that for any updated version. You definitely have not been wrong but it would be nice if the documents lead to some changed behavior as well.=20 > > > > As you stated on the mailing list: > >> 3631 says "if you want to put security into a protocol, > >> here are the best choices we have today". > > > > Is this really how we approach protocol design today? I don't think > so. > > > > There are two classes of protocol designs: > > > > 1) Extensions to existing protocols (DNS, email, routing protocols, > etc.) > > There you have to work with what is available already and your > choices are impacted by the deployment. The improvements tend to be > minor and speed of deployment is slow. >=20 > Retrofitting security to an existing system is one of the hardest tasks > out there. It's not even the deployment, it's the design choices > already made that constrain things. DNSSEC is a classic example. No > one loves it or even likes it, I suspect, but I don't know that it > could have been better, given the basic structure and assumptions that > date to the earl 1980s. The problem is that you essentially have to "retrofit" various components (not only security) into the system all the time since a successful system evolves and there is no way to consider everything in the first try. If you consider everything in the initial design then it will not be successful since it is too complex for everyone to use. Furthermore, in many cases we make assumptions about the main use cases for our technology and it turns out that we are often wrong. Either the development is not as exciting as we had planned or the work gets used for something entirely different. I will comment on that issue more in the mail to Stephen. =20 > > > > 2) For new protocol designs, many focus on using HTTP/HTTPS as a > starting point. Almost all protocols I have seen have the need for > offering the classical communication security features and TLS is the > main building block. Everything beyond that is typically tough and > quite difficult to describe in a generic fashion. >=20 > That HTTP[S] is a basic building block is a separate problem; it's the > new waist of the hourglass... Interesting that you mention that and it would probably warrant a separate discussion.=20 (see http://tools.ietf.org/html/draft-tschofenig-post-standardization-02).=20 > > > > On top of that I am not even sure that the process we have for > tackling security in the IETF is actually as successful as we would > like it to be. We typically consider the security consideration section > writeup as the crucial part but I am wondering whether others had > looked at the broader picture on where things went well and where they > didn't. In fact, I would be far more interested to hear where the > problems really are rather than producing another hitchhiker's guide to > IETF security protocols. >=20 > Is it perfect? Of course not. I do think it's significantly better > than it was 10-15 years ago. Definitely.=20 > 3631 and BCP 72 (which my email archives show was initiated no later > than 1999) were part of a process to improve the security of IETF > protocols. Another part was retargeting the security directorate to > review all documents, and get at least some involvement early on in > protocol design. That part didn't work as well as I had hoped, at > least back when I was AD, but it was far better than we'd had before. > That effort, though, was a fair number of years ago. I've been rather > disconnected from the IETF since 2005; I don't know what the current > real issues are. I'll leave it to the current IESG to figure out what > to do next. A more systematic study would indeed be a good idea. (I > know from private conversations that the Security ADs have at least > some thoughts on the subject.) I certainly agree that the chosen path has lead to a significant improvement and the combination of guidance combined with the process and training has shown good results.=20 We should probably open another discussion thread on this topic to hear the feedback from others about their experience in various working groups.=20 Just one tiny remark: If you look at the HTTP authentication and TLS security work in the IETF one could get the impression that everything is great with Web authentication. A short write-up is here: http://tools.ietf.org/id/draft-tschofenig-secure-the-web-01.txt Ciao Hannes > > > > In any case, I will not stop you from shipping an update (which I am > not sure you can even do that given it is an IAB document) but I doubt > that it will have the desired impact. > > > > Ciao > > Hannes > > > > -------- Original-Nachricht -------- > >> Datum: Fri, 18 May 2012 22:31:39 -0400 > >> Von: Steven Bellovin > >> An: IETF Security Area Advisory Group > >> Betreff: [saag] Additions to RFC 3631? > > > >> Does anyone have any suggestions for additions or corrections to RFC > 3631? > >> It looks to me like it's held up pretty well, save for newer > versions of > >> some of the protocols. > >> > >> --Steve Bellovin, https://www.cs.columbia.edu/~smb > >> > >> > >> > >> > >> > >> _______________________________________________ > >> saag mailing list > >> saag@ietf.org > >> https://www.ietf.org/mailman/listinfo/saag > > >=20 >=20 > --Steve Bellovin, https://www.cs.columbia.edu/~smb >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From hannes.tschofenig@nsn.com Thu May 24 00:25:25 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8E7721F849A for ; Thu, 24 May 2012 00:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpQvL3KAFKOw for ; Thu, 24 May 2012 00:25:25 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id CB93421F8484 for ; Thu, 24 May 2012 00:25:24 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q4O7PMaN002171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 24 May 2012 09:25:22 +0200 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q4O7PMh9018842; Thu, 24 May 2012 09:25:22 +0200 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 May 2012 09:25:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 24 May 2012 10:25:09 +0300 Message-ID: <999913AB42CC9341B05A99BBF358718D017BA1BE@FIESEXC035.nsn-intra.net> In-Reply-To: <201205240339.XAA25498@Sparkle.Rodents-Montreal.ORG> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] should we revise rfc 3365? Thread-Index: Ac05Xuls++QT4Po0SN+L2aZHZ8xoWAAHz8OA References: <4FBD6A78.2070204@cs.tcd.ie><201205232351.TAA23415@Sparkle.Rodents-Montreal.ORG><4FBD873D.3090802@isi.edu> <201205240339.XAA25498@Sparkle.Rodents-Montreal.ORG> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Mouse" , X-OriginalArrivalTime: 24 May 2012 07:25:10.0540 (UTC) FILETIME=[5A3074C0:01CD397E] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1970 X-purgate-ID: 151667::1337844323-00005945-D7DAEF0B/0-0/0-0 Subject: Re: [saag] should we revise rfc 3365? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 07:25:25 -0000 Hi,=20 I see this argument quite often that we should not impose strong security requirements on protocols because there may be this use case where no security is needed.=20 I am wondering what protocols you are thinking about that need no security.=20 Ciao Hannes > -----Original Message----- > From: saag-bounces@ietf.org [mailto:saag-bounces@ietf.org] On Behalf Of > ext Mouse > Sent: Thursday, May 24, 2012 6:40 AM > To: saag@ietf.org > Subject: Re: [saag] should we revise rfc 3365? >=20 > >> [RFC 3365] > > To open a can of worms, this would also be a good doc in which to > > discuss the need for secure ports, and whether (or not) to ever > > assign meaning to the difference between system and user ports... >=20 > I submit that attempting to make such a distinction is effectively > meaningless, and has been ever since single-user machines - machines > owned personally by individuals who are their administrators - became > even moderately common. It meant something (though even then not much) > in the days of large multi-user machines whose administrators could > reasonably be treated by the rest of the net as more trusted than the > bulk of their users. Those days are long past; between personal > machines and pwn3d windows boxen, I think it is now pointless. >=20 > To look at it another way, there can be no distinction between system > and user ports from the point of view of network-observable behaviour, > since the "system"-vs-"user" distinction, to the extent that it exists > at all, is entirely private to each host; it is, therefore, pointless > to try to mandate any such difference. >=20 > /~\ The ASCII Mouse > \ / Ribbon Campaign > X Against HTML mouse@rodents-montreal.org > / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From hannes.tschofenig@nsn.com Thu May 24 00:47:16 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D42E21F85C9 for ; Thu, 24 May 2012 00:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.499 X-Spam-Level: X-Spam-Status: No, score=-106.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JwcBlldHgI1K for ; Thu, 24 May 2012 00:47:12 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 22A3F21F85C4 for ; Thu, 24 May 2012 00:47:11 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q4O7l5Ce024882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 24 May 2012 09:47:06 +0200 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q4O7l3GK014559; Thu, 24 May 2012 09:47:05 +0200 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 May 2012 09:47:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 24 May 2012 10:47:03 +0300 Message-ID: <999913AB42CC9341B05A99BBF358718D017BA225@FIESEXC035.nsn-intra.net> In-Reply-To: <4FBD6A78.2070204@cs.tcd.ie> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] should we revise rfc 3365? Thread-Index: Ac05Nu3C8XJCX7ScRrWqCmWPXyKf+wAR4TLg References: <4FBD6A78.2070204@cs.tcd.ie> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Stephen Farrell" , X-OriginalArrivalTime: 24 May 2012 07:47:05.0463 (UTC) FILETIME=[69F1C870:01CD3981] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 6242 X-purgate-ID: 151667::1337845627-00005945-6271A03C/0-0/0-0 Subject: Re: [saag] should we revise rfc 3365? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 07:47:16 -0000 Hi Stephen,=20 This is a good discussion question. On the MTI issue: As someone who had been arguing with you in OAuth about the MTI topic I am obviously interested to get a resolution on this one.=20 For others who had skipped the discussions in OAuth here is a pointer to my summary: http://www.ietf.org/mail-archive/web/oauth/current/msg08019.html I also noticed that some protocols do not necessarily have a realistic security solution. The reasons are, however, often complex.=20 SIP, for example, has taken quite a different deployment route than many of us had thought and consequently security had been impacted by this development as well. I don't even know where to start when talking about the challenges for SIP security. There is a huge mixture of business models (e.g., SBCs, interconnection models), technical & user interface challenges, the attempt to replicate the PSTN (with all it the features) and the rise of the Web.=20 It is difficult to say what the right time is to conclude that something had gone wrong and needs to be fixed or whether the time for a specific protocol just had not come yet. I have this discussions periodically with the mobility guys (and there is plenty of exciting security work had been done with essentially zero deployment). Mobile IP is a particularly interesting case since the security components are the heaviest part in the protocol and the question arises whether the choice of security technology has actually lead to the lack of deployment.=20 On DHCP security: I have myself used the pointer to the DHCP security document knowing that it is not implemented nor deployed. The good thing about many DHCP extensions is that they do not get deployed and so there isn't a lot of harm after all.=20 Ciao Hannes > -----Original Message----- > From: saag-bounces@ietf.org [mailto:saag-bounces@ietf.org] On Behalf Of > ext Stephen Farrell > Sent: Thursday, May 24, 2012 1:54 AM > To: saag@ietf.org > Subject: [saag] should we revise rfc 3365? >=20 >=20 > Hi all, >=20 > Short version: go read the RFC and say if you think > it needs an update. >=20 > Long version: >=20 > We've been talking about RFC 3261 but Sean and I > have independently been thinking about whether > there's work to be done on RFC 3365 [1] from > 2002 which is the one that basically says you > "MUST implement strong security in all protocols" > and for very good reasons. >=20 > First, we are *not* proposing to back off from that > general position. (We'll say that again in a > minute in case you missed it:-) >=20 > Since 2002 however, we've seen some cases where > this might end up being a bit counter-productive > or where its not clear if or how 3365 applies. >=20 > DHCP AUTH [2] is frequently cited in DHCP > security considerations. However, this is pure > fiction, nobody uses it at all, and I'm not > sure if anybody even implements it. >=20 > SIP e2e security [3] is well defined and has > been implemented, but is ubiquitously unused, > even though other SIP specifications tend(ed) > to refer to it as if it solves their problems. >=20 > FLUTE [4] is a uni-directional protocol, that > RECOMMENDS transport mode ESP, but where its not > clear that you could sensibly do automated key > management, if you really only have one-way > connectivity. (Just including this one to show > not all of 'em are as obvious as the above.) >=20 > In the purely fictional cases, there is a cost > for developers clearly, but also a potential > security downside, if there's a bunch of relatively > untested code being deployed, or if some but not > all people know which things are fictional and > which not. >=20 > In these cases the trade-off seems to be between > specifying MTI security vs. truth-in-advertising. > Some of these are easy, (dhcp maybe), others are > less easy (flute). >=20 > Truth-in-advertising seems like its a good thing, > but its hard to see how to get that without also > creating a future where lots of drafts say "we > don't do security because nobody would use it." >=20 > I'm sure there are more existing cases along > those lines. >=20 >=20 > Separately, we're seeing a number of cases where > something that is like, but is not, e2e security is > being proposed. For example, for inserting adverts > in IPTV [5], for supporting SSL accelerators [6] > and perhaps in the near future, for so-called > "tusted proxies" in HTTP/2.0 [7]. >=20 > Again, there are probably more cases of this, but > here the trade-off seems mainly to be between what > are real use cases (sometimes already widely > deployed) and e2e security. >=20 >=20 > Our question to you: is it time that we revised > RFC 3365 to say something about these issues, or > more generally? >=20 > If so, then how? (Bearing in mind that we are *not* > open to a revision that neuters the position taken > in 3365.) >=20 > If you think RFC 3365 is still just fine and we > should not try revise it, then saying that would > also be good. >=20 > If a substantive discussion emerges we'd hope to > talk about that in Vancouver in July, so nothing > precipitous will happen. If this is greeted by > silence, then we'll take it that you all like > RFC 3365 and don't want us to do anything (except > keep on pushing back when people don't specify > mandatory-to-implement security:-) but that > will continue to be problematic in cases like those > mentioned above, so we may not be getting the > best outcomes at the moment in such cases. >=20 > Thanks, > Stephen and Sean. >=20 > [1] http://tools.ietf.org/html/bcp61 > [2] http://tools.ietf.org/html/rfc3118 > [3] http://tools.ietf.org/html/rfc3261 > [4] https://datatracker.ietf.org/doc/draft-ietf-rmt-flute-revised/ > [5] https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-for- > rtp/ > [6] https://datatracker.ietf.org/doc/draft-ietf-appsawg-http-forwarded/ > [7] http://lists.w3.org/Archives/Public/ietf-http- > wg/2012AprJun/0085.html >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From mouse@Sparkle.Rodents-Montreal.ORG Thu May 24 06:16:31 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C3A321F8570 for ; Thu, 24 May 2012 06:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.356 X-Spam-Level: X-Spam-Status: No, score=-9.356 tagged_above=-999 required=5 tests=[AWL=0.632, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGdFJifuYjru for ; Thu, 24 May 2012 06:16:31 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by ietfa.amsl.com (Postfix) with ESMTP id A49CC21F853D for ; Thu, 24 May 2012 06:16:30 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id JAA02463; Thu, 24 May 2012 09:16:29 -0400 (EDT) Date: Thu, 24 May 2012 09:16:29 -0400 (EDT) From: Mouse Message-Id: <201205241316.JAA02463@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Thu, 24 May 2012 09:11:59 -0400 (EDT) To: saag@ietf.org In-Reply-To: <999913AB42CC9341B05A99BBF358718D017BA1BE@FIESEXC035.nsn-intra.net> References: <4FBD6A78.2070204@cs.tcd.ie><201205232351.TAA23415@Sparkle.Rodents-Montreal.ORG><4FBD873D.3090802@isi.edu> <201205240339.XAA25498@Sparkle.Rodents-Montreal.ORG> <999913AB42CC9341B05A99BBF358718D017BA1BE@FIESEXC035.nsn-intra.net> Subject: Re: [saag] should we revise rfc 3365? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 13:16:31 -0000 >>> [...] the difference between system and user ports... >> I submit that attempting to make such a distinction is effectively >> meaningless, and has been ever since [...] > I see this argument quite often that we should not impose strong > security requirements on protocols because there may be this use case > where no security is needed. That wasn't my argument here. My argument is that "system port" versus "user port" is not a useful distinction. This is not to say that security is unnecessary or a bad idea, just that as far as I can see privileged ports are not a useful way to get any security for general-purpose use, neither today nor in the foreseeable future. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From nico@cryptonector.com Thu May 24 07:12:35 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA1FA21F86A0 for ; Thu, 24 May 2012 07:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-L65gPV339K for ; Thu, 24 May 2012 07:12:35 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA5921F8675 for ; Thu, 24 May 2012 07:12:35 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTP id D142B1E08E for ; Thu, 24 May 2012 07:12:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=c8GYfL+V29Pwg993AutlW DxH2J66I7XGIG1iuT675p8GWYhKlt2uYekWKkrHhy7xJeUBxJ6KLmT0BdkSzfR1n 8BY+tuA/5m5Uiwt67FrPPhISJgxCdLqfk3HiMR1TqETbthrxpaVQQW3Fth72kQ03 UUtPMYcHfHcO7tX/1lr55k= 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=3HGqlrYwswR14GltEkmO eJsIk2o=; b=gmMXo7/0VMuDBGA65cPEM4nCiEdhdjUVrCI/rzqQKpY//4lPqWIr Lxr6AXby/zNG2FdsODWTQp3MiYY38aM4zBsRBGl+u9CxoCUGFzb4FArXGOYevknK Y8vKR5CuaDtnjaXtUtkfVT1Gh7ftNNzaTLiyRC73jKVtHAKUptiOB6M= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTPSA id 9F64F1E087 for ; Thu, 24 May 2012 07:12:34 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so313925pbc.31 for ; Thu, 24 May 2012 07:12:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.203.7 with SMTP id km7mr10540156pbc.7.1337868754331; Thu, 24 May 2012 07:12:34 -0700 (PDT) Received: by 10.68.15.134 with HTTP; Thu, 24 May 2012 07:12:34 -0700 (PDT) In-Reply-To: <4FBD6A78.2070204@cs.tcd.ie> References: <4FBD6A78.2070204@cs.tcd.ie> Date: Thu, 24 May 2012 09:12:34 -0500 Message-ID: From: Nico Williams To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Cc: "saag@ietf.org" Subject: Re: [saag] should we revise rfc 3365? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 14:12:36 -0000 I think we should say "should specify a MTI security feature" with guidance as to when not to make it MTI or when not to bother specifying the thing at all. I-D authors should be required to address this in the security considerations section. Perhaps we should stop at "tell us what you're doing about security and the rationale for having or not having an MTI security feature". The IETF and IESG can review this and decide whether to insist that a protocol have/not have a security feature. Then DHCP could lack an explicit security feature on account of DHCP being best secured by the link layer (the router/switch). And so on. Nico -- From turners@ieca.com Fri May 25 05:52:33 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85C7221F8604 for ; Fri, 25 May 2012 05:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.856 X-Spam-Level: X-Spam-Status: No, score=-101.856 tagged_above=-999 required=5 tests=[AWL=-0.390, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n41elcO+s6K2 for ; Fri, 25 May 2012 05:52:32 -0700 (PDT) Received: from gateway01.websitewelcome.com (gateway01.websitewelcome.com [69.56.216.19]) by ietfa.amsl.com (Postfix) with ESMTP id 942C821F85E4 for ; Fri, 25 May 2012 05:52:29 -0700 (PDT) Received: by gateway01.websitewelcome.com (Postfix, from userid 5007) id 30D086F0AAA8C; Fri, 25 May 2012 07:52:29 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway01.websitewelcome.com (Postfix) with ESMTP id 260F76F0AAA6C for ; Fri, 25 May 2012 07:52:29 -0500 (CDT) Received: from [96.231.123.235] (port=48384 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SXu0K-0003J0-Lc for Saag@ietf.org; Fri, 25 May 2012 07:52:29 -0500 Message-ID: <4FBF808C.9090503@ieca.com> Date: Fri, 25 May 2012 08:52:28 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Saag@ietf.org References: <02be01cd390c$2d43a0d0$87cae270$@iab.org> In-Reply-To: <02be01cd390c$2d43a0d0$87cae270$@iab.org> X-Forwarded-Message-Id: <02be01cd390c$2d43a0d0$87cae270$@iab.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [96.231.123.235]:48384 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 3 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [saag] Fwd: Call for Papers: IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication, July 28, 2012 Vancouver, Canada X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 12:52:33 -0000 FYI ... spt -------- Original Message -------- Subject: Call for Papers: IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication, July 28, 2012 Vancouver, Canada Date: Wed, 23 May 2012 10:47:49 -0700 From: IAB Chair Reply-To: iab@iab.org Organization: Internet Architecture Board To: CC: iab@iab.org IAB / IRTF Workshop on Congestion Control for Interactive Real-Time Communication July 28, 2012 Vancouver, Canada The IAB and IRTF will hold a workshop on Congestion Control for Interactive Real-Time Communication" in Vancouver, Canada on Saturday, July 28th, 2012 prior to the IETF-84 meeting (see http://www.ietf.org/meeting/84/index.html ). Participation at the workshop is free of charge. There is no requirement to either register with or attend the IETF-84 meeting that follows the workshop. The workshop organizers would like to foster a discussion on: 1. What are appropriate congestion signals to use for interactive media and data? 2. What existing congestion control algorithms are appropriate for interactive media and data? What properties would be desirable in new congestion control algorithms? 3. Measurement and/or simulations of new congestion signals (e.g., delay-based) and their interaction with existing congestion control mechanisms. 4. What are good available techniques for adjusting sending rates for interactive media and data? What are the limits of those techniques? What properties would be desirable in new techniques? 5. What application-specific considerations have to be taken into account? 6. How can we ensure that real-time communications are well-behaved with respect to other Internet applications while still providing good quality? 7. What should the IETF and/or IRTF do? The organizers seek position papers on any or all of these topics, as well as other topics related to congestion control for interactive realtime media. Every prospective workshop participant must submit a position paper containing a name and an email address. Authors of accepted papers will be invited to the workshop. Papers up to 3 pages, formatted in HTML, PDF, or plain text (for example, as a submitted Internet-Draft) are ideal. Accepted position papers will be published. Additional details about the meeting venue will be provided to authors of accepted papers. Important Dates Position paper submission deadline: June 23, 2012 Notification to paper authors: June 30, 2012 Workshop date: July 28, 2012 Additional Details Additional details on the workshop as well as the submission process is available at http://www.iab.org/cc-workshop/ Contact To sponsors: If you are interested to help us working towards better interactive media congestion control mechanisms on the Internet (such as by making a contribution towards catering costs and room rental), please contact us! In case of questions please send email to mary.ietf.barnes at gmail.com. From stephen.farrell@cs.tcd.ie Tue May 29 08:30:53 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97AB121F85CF for ; Tue, 29 May 2012 08:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.707 X-Spam-Level: X-Spam-Status: No, score=-101.707 tagged_above=-999 required=5 tests=[AWL=0.892, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVW9y0QEKQQA for ; Tue, 29 May 2012 08:30:52 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0EE21F85CE for ; Tue, 29 May 2012 08:30:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 8B22915396B; Tue, 29 May 2012 16:30:50 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1338305448; bh=Kkna9fvGPlCCog blYQ0Qx3H0u7YiNFkuBQBTXNGQy8E=; b=S5ezPHofThwIVzmyGaGYM+IjU2SvM5 bCy0nJOTk4uTJTtLiJaTdqPOLlj+i0IUmMCLBbXq18Cy61Bf2+qMdE52C/8cVKDK XHiwgEkSSOkPdS7dK1aH6lOBl8pzEuXIOiqKkYvHsypkBqRoT1ExVCJnl1kP/zwm 7fu7d56I32dgS5bAXp4yoSH4f0lWJJR7f9T3T7t/Ly5qyYTVjH6VY4P9GCpTEaaY UvjQ6pYOybiza4EUCw5xrs6tbdrj70JPCRfrKiItdZTtK9XF3ej8qye5fOwERYVC eRs/ZcuIrCbpOz78GrqSYYENp2SFvgiQjoEkmkYcNVVZUnDKk3LyVXNw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id vSh0dl8wId1h; Tue, 29 May 2012 16:30:48 +0100 (IST) Received: from [IPv6:2001:770:10:203:746a:67db:b7ac:1c60] (unknown [IPv6:2001:770:10:203:746a:67db:b7ac:1c60]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 6B0B6153947; Tue, 29 May 2012 16:30:47 +0100 (IST) Message-ID: <4FC4EBA7.9070106@cs.tcd.ie> Date: Tue, 29 May 2012 16:30:47 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Mouse References: <4FBD6A78.2070204@cs.tcd.ie> <201205232351.TAA23415@Sparkle.Rodents-Montreal.ORG> In-Reply-To: <201205232351.TAA23415@Sparkle.Rodents-Montreal.ORG> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: saag@ietf.org Subject: Re: [saag] should we revise rfc 3365? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 15:30:53 -0000 Hiya, On 05/24/2012 12:51 AM, Mouse wrote: >> Short version: go read [RFC 3365] and say if you think it needs an >> update. > > Yes, but I believe it's not one you're willing to accept. > >> "MUST implement strong security in all protocols" > > I believe this is too dogmatic a position, and will simply lead to IETF > process being ignored in those cases where strong security is > unnecessary or undeisrable. Consider, for example, the number of > useful protocols we have today that could not be standardized under > this policy: whois, SMTP, and DHCP come to mind. Based on a quick skim > of the specs, NFS is another one (even v4 doesn't seem to have MTI > security, only an MTI framework within which security can optionally be > done - but that's just a quick skim; I could easily have missed > something). > > I know that, as an occasional protocol designer, if I believe a > protocol has no need for security, I would sooner ignore the IETF than > I would bother with shoehorning enough security to satisfy the IETF > into it. > > Aside from this excessively (I believe) dogmatic position, I see > nothing wrong with 3365. So how would you phrase it so that we do get security mechanisms defined in most all cases but not when they're really really not needed (or fictional)? Cheers, S. > > /~\ The ASCII Mouse > \ / Ribbon Campaign > X Against HTML mouse@rodents-montreal.org > / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > From stephen.farrell@cs.tcd.ie Tue May 29 08:44:57 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BABA821F8535 for ; Tue, 29 May 2012 08:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.835 X-Spam-Level: X-Spam-Status: No, score=-101.835 tagged_above=-999 required=5 tests=[AWL=0.764, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gclg9jmZlne3 for ; Tue, 29 May 2012 08:44:56 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2C821F8522 for ; Tue, 29 May 2012 08:44:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 0194B15396B; Tue, 29 May 2012 16:44:56 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1338306293; bh=ix1Pe7jJ9ZPXz8 WxtBfimr2VDOkD0EVsSxGxUx8exd0=; b=SgK+dXcOS8Q2nVDTLkO1jEJLtxlhgR oY0vNzCh1vwdEosCXFd8UNxy4jTdDlTn7yW9HRzKZcreR1/WOEz4VSTd+Jm8gDpp H0pTfCvJcOuDGI27sMDuCiWM4PWUt2bHbvYqLcSJwynujNLz3uawODaZqtVimkzc FefrOWbooaUasSjf1+X7K0D4oaxzNxVCMic3TpNrPQSybRDa7ZEuFGFcEEf3v3Ai 9ZG7TufR1/Z4JEk7gvw/yjL/3sY47vhUiFwHMSA15qsL8QRZsHibczzSg+qULTIf ECr/u8QH3PzExozcVai5/Du//TH5pthB/xaGdGRwBe94gbVhbU3QRrYQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id fSz6FIlSbNOQ; Tue, 29 May 2012 16:44:53 +0100 (IST) Received: from [IPv6:2001:770:10:203:746a:67db:b7ac:1c60] (unknown [IPv6:2001:770:10:203:746a:67db:b7ac:1c60]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 9E909153947; Tue, 29 May 2012 16:44:52 +0100 (IST) Message-ID: <4FC4EEF4.2030309@cs.tcd.ie> Date: Tue, 29 May 2012 16:44:52 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Steven Bellovin References: <4FBD6A78.2070204@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "saag@ietf.org" Subject: Re: [saag] should we revise rfc 3365? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 15:44:57 -0000 On 05/24/2012 01:08 AM, Steven Bellovin wrote: > I'm very much in favor of security realism. If something > doesn't work, it doesn't work. One reason I wrote RFC 5406 > is that protocols were specifying it as their security solution, > when (a) it was never implemented, and (b) it probably couldn't > work anyway. DHCP AUTH is a good example -- the whole point > is minimal or no configuration. I suspect that the proper > security spec there is "buy a switch that blocks rogue DHCP > (and IPv6 RA) packets)." Agreed. Hard to figure how to state that well though in the general case. > The specific changes, though, are a lot more difficult. For > example, I'd leave the SIP stuff alone; I think there's a > disaster there waiting to happen, and I suspect that we will > see security implemented and deployed in a very big hurry. I can well imagine that happening and tend to agree that e2e security for VoIP signalling really should be well defined. But, if it is needed in a hurry, I'd wonder if its likely they could do it well based on their current specs. I guess the s/mime-like approach they have might not be so easy to deploy in a rush given that they have no real experience of its use. Perhaps that implies that for protocols where the proponents don't want to bother with e2e security we ought push back on them, but put more focus on getting them to adopt something easy to deploy if needed, rather than focusing on the high-security aspect? Again, even if that's correct (and I'm not sure it is), I don't know how to state a general principle. Maybe something like "even if (you claim) you really don't need to use e2e security now, you still need to define something equivalent to an SSH leap-of-faith as a way to enable e2e security for your protocol, just in case you need it later in a hurry"? I guess that might be seen as a conflict with BCP107 though? Cheers, S. > > > On May 23, 2012, at 6:53 44PM, Stephen Farrell wrote: > >> >> Hi all, >> >> Short version: go read the RFC and say if you think >> it needs an update. >> >> Long version: >> >> We've been talking about RFC 3261 but Sean and I >> have independently been thinking about whether >> there's work to be done on RFC 3365 [1] from >> 2002 which is the one that basically says you >> "MUST implement strong security in all protocols" >> and for very good reasons. >> >> First, we are *not* proposing to back off from that >> general position. (We'll say that again in a >> minute in case you missed it:-) >> >> Since 2002 however, we've seen some cases where >> this might end up being a bit counter-productive >> or where its not clear if or how 3365 applies. >> >> DHCP AUTH [2] is frequently cited in DHCP >> security considerations. However, this is pure >> fiction, nobody uses it at all, and I'm not >> sure if anybody even implements it. >> >> SIP e2e security [3] is well defined and has >> been implemented, but is ubiquitously unused, >> even though other SIP specifications tend(ed) >> to refer to it as if it solves their problems. >> >> FLUTE [4] is a uni-directional protocol, that >> RECOMMENDS transport mode ESP, but where its not >> clear that you could sensibly do automated key >> management, if you really only have one-way >> connectivity. (Just including this one to show >> not all of 'em are as obvious as the above.) >> >> In the purely fictional cases, there is a cost >> for developers clearly, but also a potential >> security downside, if there's a bunch of relatively >> untested code being deployed, or if some but not >> all people know which things are fictional and >> which not. >> >> In these cases the trade-off seems to be between >> specifying MTI security vs. truth-in-advertising. >> Some of these are easy, (dhcp maybe), others are >> less easy (flute). >> >> Truth-in-advertising seems like its a good thing, >> but its hard to see how to get that without also >> creating a future where lots of drafts say "we >> don't do security because nobody would use it." >> >> I'm sure there are more existing cases along >> those lines. >> >> >> Separately, we're seeing a number of cases where >> something that is like, but is not, e2e security is >> being proposed. For example, for inserting adverts >> in IPTV [5], for supporting SSL accelerators [6] >> and perhaps in the near future, for so-called >> "tusted proxies" in HTTP/2.0 [7]. >> >> Again, there are probably more cases of this, but >> here the trade-off seems mainly to be between what >> are real use cases (sometimes already widely >> deployed) and e2e security. >> >> >> Our question to you: is it time that we revised >> RFC 3365 to say something about these issues, or >> more generally? >> >> If so, then how? (Bearing in mind that we are *not* >> open to a revision that neuters the position taken >> in 3365.) >> >> If you think RFC 3365 is still just fine and we >> should not try revise it, then saying that would >> also be good. >> >> If a substantive discussion emerges we'd hope to >> talk about that in Vancouver in July, so nothing >> precipitous will happen. If this is greeted by >> silence, then we'll take it that you all like >> RFC 3365 and don't want us to do anything (except >> keep on pushing back when people don't specify >> mandatory-to-implement security:-) but that >> will continue to be problematic in cases like those >> mentioned above, so we may not be getting the >> best outcomes at the moment in such cases. >> >> Thanks, >> Stephen and Sean. >> >> [1] http://tools.ietf.org/html/bcp61 >> [2] http://tools.ietf.org/html/rfc3118 >> [3] http://tools.ietf.org/html/rfc3261 >> [4] https://datatracker.ietf.org/doc/draft-ietf-rmt-flute-revised/ >> [5] https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-for-rtp/ >> [6] https://datatracker.ietf.org/doc/draft-ietf-appsawg-http-forwarded/ >> [7] http://lists.w3.org/Archives/Public/ietf-http-wg/2012AprJun/0085.html >> >> >> >> >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >> > > > --Steve Bellovin, https://www.cs.columbia.edu/~smb > > > > > > > From stephen.farrell@cs.tcd.ie Tue May 29 08:50:57 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B11D21F86DD for ; Tue, 29 May 2012 08:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.93 X-Spam-Level: X-Spam-Status: No, score=-101.93 tagged_above=-999 required=5 tests=[AWL=0.669, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4HywdWFhaB6U for ; Tue, 29 May 2012 08:50:56 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id C791321F86D8 for ; Tue, 29 May 2012 08:50:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id B962C15396B; Tue, 29 May 2012 16:50:53 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1338306652; bh=byqSDoBbuGO011 OCRuWhUx1m6KSMFc5Jw1oyFtg+VU8=; b=yrjBKXpy781qbHE3GUNp+FCAvzVB+L GtPA6iw1ZAcCzvSedZdMD/U8NZu8OlxvDIZAAOqEWuAxSuMrb8lNXYGQ/82YhNFF ZW9dKrkx+kH/BmKTzUQu5OCfDcf6ZAo6cEfZW+m+UIhBtm7U8n16oyv68qbOWMhv +8WAP3o1v71rff84NQvZetaZc5cxiv5yx45yxfsmSMQLEsUh+IxzzP5P11BKFV52 25y9bTYMrD42hTIhncvO8gh+/XZ0U7u8E78YmxPDktLDcq4WvPy4gIHpSFVFx1in Gd6q5WdwgV9zV4qzuM9aqZ5DyDYAx1YFl8ar8p6GgwKC4GpogMIk7XHg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id iCDKU9RE--em; Tue, 29 May 2012 16:50:52 +0100 (IST) Received: from [IPv6:2001:770:10:203:746a:67db:b7ac:1c60] (unknown [IPv6:2001:770:10:203:746a:67db:b7ac:1c60]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 0CA40153947; Tue, 29 May 2012 16:50:51 +0100 (IST) Message-ID: <4FC4F05B.2090907@cs.tcd.ie> Date: Tue, 29 May 2012 16:50:51 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Tschofenig, Hannes (NSN - FI/Espoo)" References: <4FBD6A78.2070204@cs.tcd.ie> <999913AB42CC9341B05A99BBF358718D017BA225@FIESEXC035.nsn-intra.net> In-Reply-To: <999913AB42CC9341B05A99BBF358718D017BA225@FIESEXC035.nsn-intra.net> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: saag@ietf.org Subject: Re: [saag] should we revise rfc 3365? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 15:50:57 -0000 On 05/24/2012 08:47 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Hi Stephen, > > This is a good discussion question. But isn't lighting up the list. That's ok. If folks don't find this pressing, then I guess we continue as usual. > On the MTI issue: As someone who had been arguing with you in OAuth > about the MTI topic I am obviously interested to get a resolution on > this one. > For others who had skipped the discussions in OAuth here is a pointer to > my summary: > http://www.ietf.org/mail-archive/web/oauth/current/msg08019.html Right. I ended up in the rough there but of course still think I was right and the WG were wrong:-) > I also noticed that some protocols do not necessarily have a realistic > security solution. The reasons are, however, often complex. > > SIP, for example, has taken quite a different deployment route than many > of us had thought and consequently security had been impacted by this > development as well. I don't even know where to start when talking about > the challenges for SIP security. There is a huge mixture of business > models (e.g., SBCs, interconnection models), technical & user interface > challenges, the attempt to replicate the PSTN (with all it the features) > and the rise of the Web. > > It is difficult to say what the right time is to conclude that something > had gone wrong and needs to be fixed or whether the time for a specific > protocol just had not come yet. I have this discussions periodically > with the mobility guys (and there is plenty of exciting security work > had been done with essentially zero deployment). Mobile IP is a > particularly interesting case since the security components are the > heaviest part in the protocol and the question arises whether the choice > of security technology has actually lead to the lack of deployment. So are you arguing that we ought stage "compliance" with 3365 somehow? Even for standards track specs? I think I'd push back against that on the basis that it'd be hard to believe a load of WGs would properly consider security but not produce the goods until after their main work is done. It'd also be bolt-on security as well I guess, which often turns out badly. (Though fictional security is also maybe just as bad.) > > On DHCP security: I have myself used the pointer to the DHCP security > document knowing that it is not implemented nor deployed. The good thing > about many DHCP extensions is that they do not get deployed and so there > isn't a lot of harm after all. Nice! I may use that quote later, when you're not expecting it:-) S > > Ciao > Hannes > >> -----Original Message----- >> From: saag-bounces@ietf.org [mailto:saag-bounces@ietf.org] On Behalf > Of >> ext Stephen Farrell >> Sent: Thursday, May 24, 2012 1:54 AM >> To: saag@ietf.org >> Subject: [saag] should we revise rfc 3365? >> >> >> Hi all, >> >> Short version: go read the RFC and say if you think >> it needs an update. >> >> Long version: >> >> We've been talking about RFC 3261 but Sean and I >> have independently been thinking about whether >> there's work to be done on RFC 3365 [1] from >> 2002 which is the one that basically says you >> "MUST implement strong security in all protocols" >> and for very good reasons. >> >> First, we are *not* proposing to back off from that >> general position. (We'll say that again in a >> minute in case you missed it:-) >> >> Since 2002 however, we've seen some cases where >> this might end up being a bit counter-productive >> or where its not clear if or how 3365 applies. >> >> DHCP AUTH [2] is frequently cited in DHCP >> security considerations. However, this is pure >> fiction, nobody uses it at all, and I'm not >> sure if anybody even implements it. >> >> SIP e2e security [3] is well defined and has >> been implemented, but is ubiquitously unused, >> even though other SIP specifications tend(ed) >> to refer to it as if it solves their problems. >> >> FLUTE [4] is a uni-directional protocol, that >> RECOMMENDS transport mode ESP, but where its not >> clear that you could sensibly do automated key >> management, if you really only have one-way >> connectivity. (Just including this one to show >> not all of 'em are as obvious as the above.) >> >> In the purely fictional cases, there is a cost >> for developers clearly, but also a potential >> security downside, if there's a bunch of relatively >> untested code being deployed, or if some but not >> all people know which things are fictional and >> which not. >> >> In these cases the trade-off seems to be between >> specifying MTI security vs. truth-in-advertising. >> Some of these are easy, (dhcp maybe), others are >> less easy (flute). >> >> Truth-in-advertising seems like its a good thing, >> but its hard to see how to get that without also >> creating a future where lots of drafts say "we >> don't do security because nobody would use it." >> >> I'm sure there are more existing cases along >> those lines. >> >> >> Separately, we're seeing a number of cases where >> something that is like, but is not, e2e security is >> being proposed. For example, for inserting adverts >> in IPTV [5], for supporting SSL accelerators [6] >> and perhaps in the near future, for so-called >> "tusted proxies" in HTTP/2.0 [7]. >> >> Again, there are probably more cases of this, but >> here the trade-off seems mainly to be between what >> are real use cases (sometimes already widely >> deployed) and e2e security. >> >> >> Our question to you: is it time that we revised >> RFC 3365 to say something about these issues, or >> more generally? >> >> If so, then how? (Bearing in mind that we are *not* >> open to a revision that neuters the position taken >> in 3365.) >> >> If you think RFC 3365 is still just fine and we >> should not try revise it, then saying that would >> also be good. >> >> If a substantive discussion emerges we'd hope to >> talk about that in Vancouver in July, so nothing >> precipitous will happen. If this is greeted by >> silence, then we'll take it that you all like >> RFC 3365 and don't want us to do anything (except >> keep on pushing back when people don't specify >> mandatory-to-implement security:-) but that >> will continue to be problematic in cases like those >> mentioned above, so we may not be getting the >> best outcomes at the moment in such cases. >> >> Thanks, >> Stephen and Sean. >> >> [1] http://tools.ietf.org/html/bcp61 >> [2] http://tools.ietf.org/html/rfc3118 >> [3] http://tools.ietf.org/html/rfc3261 >> [4] https://datatracker.ietf.org/doc/draft-ietf-rmt-flute-revised/ >> [5] https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-for- >> rtp/ >> [6] > https://datatracker.ietf.org/doc/draft-ietf-appsawg-http-forwarded/ >> [7] http://lists.w3.org/Archives/Public/ietf-http- >> wg/2012AprJun/0085.html >> >> >> >> >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag > > From mouse@Sparkle.Rodents-Montreal.ORG Tue May 29 09:13:56 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6BD521F8712 for ; Tue, 29 May 2012 09:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.381 X-Spam-Level: X-Spam-Status: No, score=-9.381 tagged_above=-999 required=5 tests=[AWL=0.606, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQsIQWKZwFlB for ; Tue, 29 May 2012 09:13:56 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by ietfa.amsl.com (Postfix) with ESMTP id 059B721F86C1 for ; Tue, 29 May 2012 09:13:55 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id MAA05874; Tue, 29 May 2012 12:13:54 -0400 (EDT) Date: Tue, 29 May 2012 12:13:54 -0400 (EDT) From: Mouse Message-Id: <201205291613.MAA05874@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Tue, 29 May 2012 11:46:13 -0400 (EDT) To: saag@ietf.org In-Reply-To: <4FC4EBA7.9070106@cs.tcd.ie> References: <4FBD6A78.2070204@cs.tcd.ie> <201205232351.TAA23415@Sparkle.Rodents-Montreal.ORG> <4FC4EBA7.9070106@cs.tcd.ie> Subject: Re: [saag] should we revise rfc 3365? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 16:13:56 -0000 >>> "MUST implement strong security in all protocols" >> I believe this is too dogmatic a position, and will simply lead to >> IETF process being ignored in [some cases]. > So how would you phrase it so that we do get security mechanisms > defined in most all cases but not when they're really really not > needed (or fictional)? I don't think that can be done by drawing a hard line in the sand, as 3365 tries to do, regardless of where that line is drawn. Whether strong security is appropriate is a judgement call, as is how much security constitutes `strong' for a particular purpose. And judgement calls have this annoying property that they require, well, judgement, that they can't be made by unambiguous algorithms. It's possible I'm just missing something, but I can't see any way to do this that doesn't mean involving real humans. 3365 appears to be trying to do it in a way that avoids needing to involve humans; I believe that's possible only with a relatively high error rate. In the case of 3365, the errors take the form of imposing strong security on protocols that don't need/want it; drawing the line other places will distribute the errors differently, but I doubt it's possible to eliminate them. If this just resulted in unnecessary security, it wouldn't be so bad. But I suspect it will, instead, result in IETF process being ignored and protocols defined by rough consensus and running code _without_ IETF oversight, until/unless the IETF is more or less forced to either violate its own process and standardize a protocol in its widely-deployed form or blatantly ignore a popular and useful protocol because it doesn't wear 3365's (or 3365bis's) straitjacket. Of course, this is all my opinions and guesses. I could be wrong. Wouldn't be the first time, nor the last.... /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From hannes.tschofenig@nsn.com Tue May 29 09:35:41 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 603C621F86DA for ; Tue, 29 May 2012 09:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.549 X-Spam-Level: X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-MMFM8dlNsS for ; Tue, 29 May 2012 09:35:40 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 913C121F86D1 for ; Tue, 29 May 2012 09:35:40 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q4TGZWW8023221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 May 2012 18:35:32 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q4TGZVZF003998; Tue, 29 May 2012 18:35:31 +0200 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 May 2012 18:35:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 29 May 2012 19:37:30 +0300 Message-ID: <999913AB42CC9341B05A99BBF358718D017FDDDE@FIESEXC035.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] should we revise rfc 3365? Thread-Index: Ac07ObDwN05UUhEjTMO7Dayj6xy/3QCfx2qg References: <999913AB42CC9341B05A99BBF358718D017BA1BE@FIESEXC035.nsn-intra.net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Peter Gutmann" , , X-OriginalArrivalTime: 29 May 2012 16:35:31.0806 (UTC) FILETIME=[107687E0:01CD3DB9] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 2175 X-purgate-ID: 151667::1338309332-00005945-859490B4/0-0/0-0 Subject: Re: [saag] should we revise rfc 3365? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 16:35:41 -0000 Hi Peter,=20 when we develop protocols in the IETF they are meant to be used for the Internet and you have to make the design according to the toughest requirements and not the simplest. In many cases, protocol designers do not really know how exactly their protocols will be used and so you cannot just make some simplifying assumptions.=20 For smart objects (you call them low-power devices) the approach is still to provide security or otherwise not connect them to the Internet. I think that this approach of providing a version of the protocol that is completely insecure (in case we have a really convenient deployment environment is really dangerous) as the usage of the protocol can quickly be used in different contexts and then the user is in trouble.=20 So, I think you are on the wrong track.=20 Ciao Hannes > -----Original Message----- > From: ext Peter Gutmann [mailto:pgut001@cs.auckland.ac.nz] > Sent: Saturday, May 26, 2012 3:18 PM > To: Tschofenig, Hannes (NSN - FI/Espoo); mouse@Rodents-Montreal.ORG; > saag@ietf.org > Subject: Re: [saag] should we revise rfc 3365? >=20 > "Tschofenig, Hannes (NSN - FI/Espoo)" writes: >=20 > >I see this argument quite often that we should not impose strong > security > >requirements on protocols because there may be this use case where no > >security is needed. > > > >I am wondering what protocols you are thinking about that need no > security. >=20 > It's not protocols that may or may not require security, it's uses of > protocols. Something on an internal LAN probably doesn't require it. > Something on a CAN (where 'C' is for 'controller') almost certainly > doesn't > require it. Low-power embedded devices (where the options are no-so- > strong > security or none at all) don't require it. Systems where throughput > and/or > low latency are critical and you "secure" them by running a cable from > box A > to box B don't need it. And so on and so on. >=20 > It's fair enough to say "if you require strong security then you can do > X", > but saying "the protocol MUST include X" is inappropriate. >=20 > Peter. From steve@shinkuro.com Mon May 21 07:11:48 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2919821F859A for ; Mon, 21 May 2012 07:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.47 X-Spam-Level: X-Spam-Status: No, score=-1.47 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DSL=1.129] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RR+zs4qcDB97 for ; Mon, 21 May 2012 07:11:44 -0700 (PDT) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD2B21F854B for ; Mon, 21 May 2012 07:11:44 -0700 (PDT) Received: from [64.61.115.26] (account steve@shinkuro.com HELO [172.17.159.186]) by execdsl.com (CommuniGate Pro SMTP 5.1.16) with ESMTPSA id 20547602; Mon, 21 May 2012 14:13:15 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Steve Crocker In-Reply-To: Date: Mon, 21 May 2012 10:11:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1FD05DC1-A041-40B3-96B0-8C5EE944A108@shinkuro.com> References: <300A2E9F-E99B-46FA-A101-E3611BD0D197@cs.columbia.edu> <877gw69h81.fsf@latte.josefsson.org> <4FB9ECA4.3010904@gmail.com> To: IETF Security Area Advisory Group X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Tue, 29 May 2012 09:46:00 -0700 Cc: Steve Crocker Subject: Re: [saag] Additions to RFC 3631? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 14:11:48 -0000 I've been lurking and only following loosely, so I apologize in advance = if the following is off the mark. I was pleased to see mention of RFC 4086 on proper implementation of = random number generation -- I am proud to be one of the co-authors -- = but I thought the issue at hand is transition of crypto algorithms when = current algorithms become obsolete. This is a problem that occurs in = all protocols that use crypto algorithms, and in my opinion we have = underplayed this in our designs. Every protocol that uses crypto should = be designed with transition mechanisms built in -- and tested! -- on the = assumption the protocol will outlive the current set of crypto = algorithms. Whether we adopt a generic way of doing this across protocols or a = specific way for each protocol is a matter of discussion. If we can't = come up with a way to do it in a uniform way, then it's ok with me to = have a separate way for each protocol. In any case, I think it's = important -- no, that's not strong enough -- essential to have a way of = transitioning from current algorithms to future algorithms without = disrupting service. These transitions will usually take a fairly long = time, five to ten years I think, so the process can be somewhat relaxed. = Relaxed does not mean undefined or vacuous. Steve On May 21, 2012, at 10:01 AM, Steven Bellovin wrote: > As noted by others, RFC 4086 covers that. It may also need improving; = I haven't reread it recently. However, even a pointer to it is out of = place in 3631bis. 3631 is about protocol mechanisms; 4086 is about = implementations. Mouse Mouse's suggestions are more in the domain of = 3365, which is security design philosophy. 3631 says "if you want to = put security into a protocol, here are the best choices we have today". = My question is whether or not that list should be changed. >=20 > On May 21, 2012, at 3:20 04AM, Yaron Sheffer wrote: >=20 >> And a short section on crypto-grade random number generation. I would = be glad to contribute it. >>=20 >> Yaron >>=20 >> On 05/21/2012 09:32 AM, Simon Josefsson wrote: >>> Steven Bellovin writes: >>>=20 >>>> Does anyone have any suggestions for additions or corrections to = RFC 3631? >>>> It looks to me like it's held up pretty well, save for newer = versions of >>>> some of the protocols. >>>=20 >>> I think channel bindings ought to be discussed, as a simple way to = bind >>> different layers together to avoid certain attacks. It could be >>> discussed in the SASL or GSS-API section. Further, I think EAP as a >>> protocol should be included in the list of standard security = mechanisms. >>>=20 >>> /Simon >>> _______________________________________________ >>> saag mailing list >>> saag@ietf.org >>> https://www.ietf.org/mailman/listinfo/saag >>=20 >=20 >=20 > --Steve Bellovin, https://www.cs.columbia.edu/~smb >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From hannes.tschofenig@nsn.com Tue May 29 09:48:04 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD1D011E80B5 for ; Tue, 29 May 2012 09:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.556 X-Spam-Level: X-Spam-Status: No, score=-106.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lvi3+X65+c7q for ; Tue, 29 May 2012 09:48:04 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id B8A8B11E80B0 for ; Tue, 29 May 2012 09:48:03 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q4TGm2dp032354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 May 2012 18:48:02 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q4TGm2uX007138; Tue, 29 May 2012 18:48:02 +0200 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 May 2012 18:48:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 29 May 2012 19:50:00 +0300 Message-ID: <999913AB42CC9341B05A99BBF358718D017FDDE4@FIESEXC035.nsn-intra.net> In-Reply-To: <201205291613.MAA05874@Sparkle.Rodents-Montreal.ORG> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] should we revise rfc 3365? Thread-Index: Ac09thChqpBpMNPqQ+CfR+UiGOA7pQAA+YHQ References: <4FBD6A78.2070204@cs.tcd.ie><201205232351.TAA23415@Sparkle.Rodents-Montreal.ORG><4FC4EBA7.9070106@cs.tcd.ie> <201205291613.MAA05874@Sparkle.Rodents-Montreal.ORG> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Mouse" , X-OriginalArrivalTime: 29 May 2012 16:48:02.0357 (UTC) FILETIME=[CFD38650:01CD3DBA] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 2865 X-purgate-ID: 151667::1338310082-00001F01-472233C9/0-0/0-0 Subject: Re: [saag] should we revise rfc 3365? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 16:48:04 -0000 I have a few clarifying questions regarding your mail.=20 > >>> "MUST implement strong security in all protocols" > >> I believe this is too dogmatic a position, and will simply lead to > >> IETF process being ignored in [some cases]. > > So how would you phrase it so that we do get security mechanisms > > defined in most all cases but not when they're really really not > > needed (or fictional)? >=20 > I don't think that can be done by drawing a hard line in the sand, as > 3365 tries to do, regardless of where that line is drawn. Whether > strong security is appropriate is a judgement call, as is how much > security constitutes `strong' for a particular purpose. And judgement > calls have this annoying property that they require, well, judgement, > that they can't be made by unambiguous algorithms. I wonder whether you could provide some specific examples of where the IETF provided too strong security solutions for a protocol.=20 > It's possible I'm just missing something, but I can't see any way to do > this that doesn't mean involving real humans. 3365 appears to be > trying to do it in a way that avoids needing to involve humans; I > believe that's possible only with a relatively high error rate. In the > case of 3365, the errors take the form of imposing strong security on > protocols that don't need/want it; drawing the line other places will > distribute the errors differently, but I doubt it's possible to > eliminate them. Could you point to specific parts in RFC 3365 since it mentions users a couple of times (with different meaning) and I did not see an obvious problem with it. >=20 > If this just resulted in unnecessary security, it wouldn't be so bad. > But I suspect it will, instead, result in IETF process being ignored > and protocols defined by rough consensus and running code _without_ > IETF oversight, until/unless the IETF is more or less forced to either > violate its own process and standardize a protocol in its > widely-deployed form or blatantly ignore a popular and useful protocol > because it doesn't wear 3365's (or 3365bis's) straitjacket. Are you saying that people ignore IETF security recommendations or that the entire protocols are being ignored or what? I think we have to pick specific cases to provide enough context. In the abstract such a discussion quickly becomes meaningless.=20 >=20 > Of course, this is all my opinions and guesses. I could be wrong. > Wouldn't be the first time, nor the last.... Ciao Hannes >=20 > /~\ The ASCII Mouse > \ / Ribbon Campaign > X Against HTML mouse@rodents-montreal.org > / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From hannes.tschofenig@nsn.com Tue May 29 09:52:09 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30B7D21F86BA for ; Tue, 29 May 2012 09:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.561 X-Spam-Level: X-Spam-Status: No, score=-106.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LmKh4GI2nsV0 for ; Tue, 29 May 2012 09:52:08 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 5126321F8503 for ; Tue, 29 May 2012 09:52:08 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q4TGq67J007325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 May 2012 18:52:06 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q4TGq522032288; Tue, 29 May 2012 18:52:05 +0200 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 May 2012 18:52:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 29 May 2012 19:53:59 +0300 Message-ID: <999913AB42CC9341B05A99BBF358718D017FDDE6@FIESEXC035.nsn-intra.net> In-Reply-To: <4FC4F05B.2090907@cs.tcd.ie> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] should we revise rfc 3365? Thread-Index: Ac09stmUqcfCAK3FSHacGv5Ra4qEyQABsgUg References: <4FBD6A78.2070204@cs.tcd.ie> <999913AB42CC9341B05A99BBF358718D017BA225@FIESEXC035.nsn-intra.net> <4FC4F05B.2090907@cs.tcd.ie> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Stephen Farrell" X-OriginalArrivalTime: 29 May 2012 16:52:05.0833 (UTC) FILETIME=[60F30390:01CD3DBB] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 2424 X-purgate-ID: 151667::1338310326-00001F01-DA554308/0-0/0-0 Cc: saag@ietf.org Subject: Re: [saag] should we revise rfc 3365? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 16:52:09 -0000 Regarding the text below I believe I am suggesting to investigate the cases where the security deployment did not happen as planned. We are jumping to conclusions far too quickly and the reasons for why things did not work out as planned may have many reasons - many of them may not be so obvious. For some reason we often believe another document will fix the problem. In the IAB, for example, we did some reviews of protocols (with respect to privacy) and got some interesting insights as to what the problems were with the way we approached privacy in the past. I would be surprised if nobody had ever looked at the details of how the work on security evolved for specific protocols.=20 > > I also noticed that some protocols do not necessarily have a realistic > > security solution. The reasons are, however, often complex. > > > > SIP, for example, has taken quite a different deployment route than > many > > of us had thought and consequently security had been impacted by this > > development as well. I don't even know where to start when talking > about > > the challenges for SIP security. There is a huge mixture of business > > models (e.g., SBCs, interconnection models), technical & user > interface > > challenges, the attempt to replicate the PSTN (with all it the > features) > > and the rise of the Web. > > > > It is difficult to say what the right time is to conclude that > something > > had gone wrong and needs to be fixed or whether the time for a > specific > > protocol just had not come yet. I have this discussions periodically > > with the mobility guys (and there is plenty of exciting security work > > had been done with essentially zero deployment). Mobile IP is a > > particularly interesting case since the security components are the > > heaviest part in the protocol and the question arises whether the > choice > > of security technology has actually lead to the lack of deployment. >=20 > So are you arguing that we ought stage "compliance" with > 3365 somehow? Even for standards track specs? I think I'd > push back against that on the basis that it'd be hard to > believe a load of WGs would properly consider security > but not produce the goods until after their main work is > done. It'd also be bolt-on security as well I guess, which > often turns out badly. (Though fictional security is also > maybe just as bad.) From hannes.tschofenig@nsn.com Tue May 29 09:58:01 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB9F421F8655 for ; Tue, 29 May 2012 09:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.566 X-Spam-Level: X-Spam-Status: No, score=-106.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wGJNcWA0hQQ4 for ; Tue, 29 May 2012 09:58:01 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id B515321F864C for ; Tue, 29 May 2012 09:58:00 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q4TGvxmq017057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 May 2012 18:57:59 +0200 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q4TGvuoE023790; Tue, 29 May 2012 18:57:59 +0200 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 May 2012 18:57:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 29 May 2012 19:59:56 +0300 Message-ID: <999913AB42CC9341B05A99BBF358718D017FDDE9@FIESEXC035.nsn-intra.net> In-Reply-To: <1FD05DC1-A041-40B3-96B0-8C5EE944A108@shinkuro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Additions to RFC 3631? Thread-Index: Ac09uorQA842oDRqRQu2gYB9BeKxYQAAT12g References: <300A2E9F-E99B-46FA-A101-E3611BD0D197@cs.columbia.edu><877gw69h81.fsf@latte.josefsson.org> <4FB9ECA4.3010904@gmail.com> <1FD05DC1-A041-40B3-96B0-8C5EE944A108@shinkuro.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Steve Crocker" , "IETF Security Area Advisory Group" X-OriginalArrivalTime: 29 May 2012 16:57:59.0087 (UTC) FILETIME=[33814BF0:01CD3DBC] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 4393 X-purgate-ID: 151667::1338310679-00001F01-1D2D4B5D/0-0/0-0 Subject: Re: [saag] Additions to RFC 3631? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 16:58:02 -0000 The transition from one security solution to another one was already mentioned at the Paris IAB technical plenary as a tough issue. (Looking at IPv6 it seems that transition is in general a problem -- not only for security.) What surprised me with the presentations of the panel members was that there are even new security problems introduced with the roll-out of new solution solutions that interfere badly with existing deployments. Chris Weber provided the example of CORS.=20 Here is the pointer to the slides and the meeting minutes (in case someone wasn't listening to the plenary): http://www.ietf.org/proceedings/83/technical-plenary.html In a nutshell, I agree with what you state below, Steve. I would just extend it beyond cryptographic algorithms. > -----Original Message----- > From: saag-bounces@ietf.org [mailto:saag-bounces@ietf.org] On Behalf Of > ext Steve Crocker > Sent: Monday, May 21, 2012 5:12 PM > To: IETF Security Area Advisory Group > Cc: Steve Crocker > Subject: Re: [saag] Additions to RFC 3631? >=20 > I've been lurking and only following loosely, so I apologize in advance > if the following is off the mark. >=20 > I was pleased to see mention of RFC 4086 on proper implementation of > random number generation -- I am proud to be one of the co-authors -- > but I thought the issue at hand is transition of crypto algorithms when > current algorithms become obsolete. This is a problem that occurs in > all protocols that use crypto algorithms, and in my opinion we have > underplayed this in our designs. Every protocol that uses crypto should > be designed with transition mechanisms built in -- and tested! -- on the > assumption the protocol will outlive the current set of crypto > algorithms. >=20 > Whether we adopt a generic way of doing this across protocols or a > specific way for each protocol is a matter of discussion. If we can't > come up with a way to do it in a uniform way, then it's ok with me to > have a separate way for each protocol. In any case, I think it's > important -- no, that's not strong enough -- essential to have a way of > transitioning from current algorithms to future algorithms without > disrupting service. These transitions will usually take a fairly long > time, five to ten years I think, so the process can be somewhat relaxed. > Relaxed does not mean undefined or vacuous. >=20 > Steve >=20 > On May 21, 2012, at 10:01 AM, Steven Bellovin wrote: >=20 > > As noted by others, RFC 4086 covers that. It may also need improving; > I haven't reread it recently. However, even a pointer to it is out of > place in 3631bis. 3631 is about protocol mechanisms; 4086 is about > implementations. Mouse Mouse's suggestions are more in the domain of > 3365, which is security design philosophy. 3631 says "if you want to > put security into a protocol, here are the best choices we have today". > My question is whether or not that list should be changed. > > > > On May 21, 2012, at 3:20 04AM, Yaron Sheffer wrote: > > > >> And a short section on crypto-grade random number generation. I would > be glad to contribute it. > >> > >> Yaron > >> > >> On 05/21/2012 09:32 AM, Simon Josefsson wrote: > >>> Steven Bellovin writes: > >>> > >>>> Does anyone have any suggestions for additions or corrections to > RFC 3631? > >>>> It looks to me like it's held up pretty well, save for newer > versions of > >>>> some of the protocols. > >>> > >>> I think channel bindings ought to be discussed, as a simple way to > bind > >>> different layers together to avoid certain attacks. It could be > >>> discussed in the SASL or GSS-API section. Further, I think EAP as a > >>> protocol should be included in the list of standard security > mechanisms. > >>> > >>> /Simon > >>> _______________________________________________ > >>> saag mailing list > >>> saag@ietf.org > >>> https://www.ietf.org/mailman/listinfo/saag > >> > > > > > > --Steve Bellovin, https://www.cs.columbia.edu/~smb > > > > > > > > > > > > _______________________________________________ > > saag mailing list > > saag@ietf.org > > https://www.ietf.org/mailman/listinfo/saag >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From mouse@Sparkle.Rodents-Montreal.ORG Tue May 29 11:08:11 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4306811E8122 for ; Tue, 29 May 2012 11:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.468 X-Spam-Level: X-Spam-Status: No, score=-9.468 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cae-6lY58ezv for ; Tue, 29 May 2012 11:08:10 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by ietfa.amsl.com (Postfix) with ESMTP id 556E511E8102 for ; Tue, 29 May 2012 11:08:10 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id OAA06971; Tue, 29 May 2012 14:08:09 -0400 (EDT) Date: Tue, 29 May 2012 14:08:09 -0400 (EDT) From: Mouse Message-Id: <201205291808.OAA06971@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Tue, 29 May 2012 13:25:45 -0400 (EDT) To: saag@ietf.org In-Reply-To: <999913AB42CC9341B05A99BBF358718D017FDDE4@FIESEXC035.nsn-intra.net> References: <4FBD6A78.2070204@cs.tcd.ie><201205232351.TAA23415@Sparkle.Rodents-Montreal.ORG><4FC4EBA7.9070106@cs.tcd.ie> <201205291613.MAA05874@Sparkle.Rodents-Montreal.ORG> <999913AB42CC9341B05A99BBF358718D017FDDE4@FIESEXC035.nsn-intra.net> Subject: Re: [saag] should we revise rfc 3365? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 18:08:11 -0000 > I wonder whether you could provide some specific examples of where > the IETF provided too strong security solutions for a protocol. Where a protocol was standardized with more security than appropriate? No specific examples come to mind. But, upthread, I cited three (four, I think) examples of protocols which are useful in their current form, but that current form could not be standardized under 3365's restrictions: whois, SMTP, DHCP, and (I think - see below) NFS. >> 3365 appears to be trying to do it in a way that avoids needing to >> involve humans; [...] > Could you point to specific parts in RFC 3365 since it mentions users > a couple of times (with different meaning) and I did not see an > obvious problem with it. No, the humans I was talking about are not users of protocols, not the users 3365 speaks of. The sense in which I see 3365 as trying to avoid involving humans is that it appears to be trying to lay out a policy that can be applied by anyone without requiring any judgement calls. >> I suspect it will [...] result in IETF process being ignored and >> protocols defined by rough consensus and running code _without_ IETF >> oversight, [...] > Are you saying that people ignore IETF security recommendations or > that the entire protocols are being ignored or what? What I suspect will happen - and this is just a guess - is that people designing new protocols will look at 3365 (or 3365bis) and effectively say "if the IETF requires that we put strong security in this protocol then we'll just build it the way we want it and the IETF can go hang". If I'm right, and such a protocol becomes popular, this will put the IETF in the uncomfortable position of having to either (a) ignore a popular protocol because it doesn't fit the IETF's policy dogma or (b) ignore its own process and standardize a protocol that doesn't fit the dogma. I could be wrong. But I've seen protocols developed independent of the IETF adopted into the IETF framework (NFS is an example) often enough that I think it's reasonably likely. (Note that, unless I missed something in my skim of the spec, NFS is also an example of a protocol that violates 3365 - even in v4, it has m-t-i security infrastructure but I didn't see any m-t-i use of it.) And it probably bears repeating that: >> Of course, this is all my opinions and guesses. I could be wrong. >> Wouldn't be the first time, nor the last.... /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From mouse@Sparkle.Rodents-Montreal.ORG Tue May 29 11:12:56 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF5B611E8128 for ; Tue, 29 May 2012 11:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.533 X-Spam-Level: X-Spam-Status: No, score=-9.533 tagged_above=-999 required=5 tests=[AWL=0.455, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fUJ850Q1eZ-S for ; Tue, 29 May 2012 11:12:56 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by ietfa.amsl.com (Postfix) with ESMTP id E3A0511E8102 for ; Tue, 29 May 2012 11:12:55 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id OAA07055; Tue, 29 May 2012 14:12:54 -0400 (EDT) Date: Tue, 29 May 2012 14:12:54 -0400 (EDT) From: Mouse Message-Id: <201205291812.OAA07055@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Tue, 29 May 2012 14:10:04 -0400 (EDT) To: saag@ietf.org In-Reply-To: <999913AB42CC9341B05A99BBF358718D017FDDDE@FIESEXC035.nsn-intra.net> References: <999913AB42CC9341B05A99BBF358718D017BA1BE@FIESEXC035.nsn-intra.net> <999913AB42CC9341B05A99BBF358718D017FDDDE@FIESEXC035.nsn-intra.net> Subject: Re: [saag] should we revise rfc 3365? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 18:12:56 -0000 > For smart objects (you call them low-power devices) the approach is > still to provide security or otherwise not connect them to the > Internet. That may be the approach the IETF would prefer, but the IETF is not in a position to do that, to prevent people from connecting devices to the Internet based on whether they speak protocols the IETF doesn't like. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B