From william.polk@nist.gov Mon Nov 1 08:11:29 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EA8B3A6A0F for ; Mon, 1 Nov 2010 08:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9TePFNyTWbZ4 for ; Mon, 1 Nov 2010 08:11:28 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 849A13A69FF for ; Mon, 1 Nov 2010 08:11:28 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (WSXGHUB1.xchange.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id oA1FBBN5022910 for ; Mon, 1 Nov 2010 11:11:11 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Mon, 1 Nov 2010 11:11:11 -0400 From: "Polk, William T." To: "saag@ietf.org" Date: Mon, 1 Nov 2010 11:11:09 -0400 Thread-Topic: Public Review: NIST draft publication on extraction-then-expansion key derivation Thread-Index: Act51wNFA9HkRxfftEibhXcOm5KfXw== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: william.polk@nist.gov Subject: [saag] Public Review: NIST draft publication on extraction-then-expansion key derivation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 15:11:30 -0000 Folks, I apparently black-holed an important NIST email last September. NIST has published a draft specification covering key derivation functions based on the extraction-then-expansion model we standardized in RFC 5869. Unfortunately, I failed to forward the request for feedback on the draft to this list. =20 The official comment period closed October 30, but the authors were hoping for more feedback from IETF participants, and have asked me (a second time) to send the call to the community. The authors have assured me that comments submitted before November 30 will be received in plenty of time fo= r the revision process. Thanks, Tim Polk > Call for Comments: > =20 > This is a reminder that the comment period for draft SP 800-56C, > Recommendation for Key Derivation through Extraction-then-Expansion will = close > on October 30, 2010. The announcement and draft can be found at > http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-56-C > =20 > Please submit comments to 800-56Ccomments@nist.gov with "Comments on SP > 800-56C" in the subject line. From hugokraw@gmail.com Mon Nov 1 09:08:17 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB8843A6A1D for ; Mon, 1 Nov 2010 09:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5tly+sKmoboD for ; Mon, 1 Nov 2010 09:08:16 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 208363A6988 for ; Mon, 1 Nov 2010 09:08:15 -0700 (PDT) Received: by wyb28 with SMTP id 28so5632862wyb.31 for ; Mon, 01 Nov 2010 09:08:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=CtHUSahlldVfHTJDEE8L3uNtuzii9yMobN1RnhIrqfc=; b=fV/vyjBLETyv2xTiw4dvnCM2kLHy38PIIoUCOh9aA21GrXtJfnxxzQwQ2J4I3Xf7H6 WKY/QKQPrwDTqLKplqsS/Tbip2fkyugOxT/jx01FObgnjGKijcIFrX9Yb9i5b5TPzc6m 5716rnTC87qHEPxTgl8kiMwBLBadpoZTHyjVw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=U0Q30naA8w+Gm/1M8CtKX0TIR1HZc9SO/AnTWVP4LWf5ybySRtS/iaYzsY5zEG0t7I n1vy7giPCWTD0Ku/lf+cf1Y89S49l+ftHJYHdmhGC59UO9JekZhvsrrrDuVAeFuBVkyp TKAHJUkPw6UDkJW4Yczr7dKJcV5UnXfoEtHLU= Received: by 10.216.1.6 with SMTP id 6mr2014538wec.24.1288627697111; Mon, 01 Nov 2010 09:08:17 -0700 (PDT) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.216.70.196 with HTTP; Mon, 1 Nov 2010 09:07:56 -0700 (PDT) In-Reply-To: References: From: Hugo Krawczyk Date: Mon, 1 Nov 2010 12:07:56 -0400 X-Google-Sender-Auth: N0Rr1GF7hCUv5gUzB_mlvXougmw Message-ID: To: "Polk, William T." Content-Type: multipart/alternative; boundary=0016364d29bf22514704940004c7 Cc: "saag@ietf.org" Subject: Re: [saag] Public Review: NIST draft publication on extraction-then-expansion key derivation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 16:08:17 -0000 --0016364d29bf22514704940004c7 Content-Type: text/plain; charset=UTF-8 Hi Tim, I included the following point in comments I submitted to NIST, yet it may be worth repeating it here. SP 800-56C SEEMS to allow for the use of the technique standardized in RFC 5869. However, to arrive to that conclusion one has to carefully parse SP 800-56C as well as 800-108 and navigate the optional parts of these schemes. To avoid confusion and many questions in the future, I recommend that SP 800-56C (and preferably also the recent draft SP 800-135) EXPLICITLY mention the specific HKDF scheme from RFC 5869 as an instance allowed by these NIST documents. Thanks, Hugo On Mon, Nov 1, 2010 at 11:11 AM, Polk, William T. wrote: > Folks, > > I apparently black-holed an important NIST email last September. NIST has > published a draft specification covering key derivation functions based on > the extraction-then-expansion model we standardized in RFC 5869. > Unfortunately, I failed to forward the request for feedback on the draft to > this list. > > The official comment period closed October 30, but the authors were hoping > for more feedback from IETF participants, and have asked me (a second time) > to send the call to the community. The authors have assured me that > comments submitted before November 30 will be received in plenty of time > for > the revision process. > > Thanks, > > Tim Polk > > > > Call for Comments: > > > > This is a reminder that the comment period for draft SP 800-56C, > > Recommendation for Key Derivation through Extraction-then-Expansion will > close > > on October 30, 2010. The announcement and draft can be found at > > http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-56-C > > > > Please submit comments to 800-56Ccomments@nist.gov with "Comments on SP > > 800-56C" in the subject line. > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --0016364d29bf22514704940004c7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Tim,

I included the following point in comments I submitted to NI= ST, yet it may be worth repeating it here. SP 800-56C SEEMS to allow for th= e use of the technique standardized in RFC 5869. However, to arrive to that= conclusion one has to carefully parse SP 800-56C as well as 800-108 and na= vigate the optional parts of these schemes. To avoid confusion and many que= stions in the future, I recommend that SP 800-56C (and preferably also the = recent draft SP 800-135) EXPLICITLY mention the specific HKDF scheme from R= FC 5869 as an instance allowed by these NIST documents.

Thanks,

Hugo

On Mon, Nov 1, 20= 10 at 11:11 AM, Polk, William T. <william.polk@nist.gov> wrote:
Folks,

I apparently black-holed an important NIST email last September. =C2=A0NIST= has
published a draft specification covering key derivation functions based on<= br> the extraction-then-expansion model we standardized in RFC 5869.
Unfortunately, I failed to forward the request for feedback on the draft to=
this list.

The official comment period closed October 30, but the authors were hoping<= br> for more feedback from IETF participants, and have asked me (a second time)=
to send the call to the community. =C2=A0The authors have assured me that comments submitted before November 30 will be received in plenty of time fo= r
the revision process.

Thanks,

Tim Polk


> Call for Comments:
>
> This is a reminder that the comment period for draft SP 800-56C,
> Recommendation for Key Derivation through Extraction-then-Expansion wi= ll close
> on October 30, 2010. =C2=A0The announcement and draft can be found at<= br> > http://csrc.nist.gov/publications/PubsDrafts.html#SP-= 800-56-C
>
> Please submit comments to = 800-56Ccomments@nist.gov with "Comments on SP
> 800-56C" in the subject line.

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

--0016364d29bf22514704940004c7-- From hotz@jpl.nasa.gov Mon Nov 8 13:22:17 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6532628C0E7; Mon, 8 Nov 2010 13:22:17 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKYVwjp+d0vH; Mon, 8 Nov 2010 13:22:15 -0800 (PST) Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.106]) by core3.amsl.com (Postfix) with ESMTP id E19A128C0E4; Mon, 8 Nov 2010 13:22:15 -0800 (PST) Received: from dhcp-128-149-94-041.jpl.nasa.gov (dhcp-128-149-94-041.jpl.nasa.gov [128.149.94.41]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.3) with ESMTP id oA8LMZFH029508 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Mon, 8 Nov 2010 13:22:36 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) From: "Henry B. Hotz" In-Reply-To: <20101108200139.697823A697A@core3.amsl.com> Date: Mon, 8 Nov 2010 13:22:35 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <93F20DE1-6C96-4C45-82CE-F295C967F876@jpl.nasa.gov> References: <20101108200139.697823A697A@core3.amsl.com> To: saag@ietf.org, pkix@ietf.org, "ietf-krb-wg@anl.gov Group" X-Mailer: Apple Mail (2.1081) X-Source-IP: dhcp-128-149-94-041.jpl.nasa.gov [128.149.94.41] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Subject: Re: [saag] New Version Notification for draft-hotz-kx509-01 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 21:22:17 -0000 I think I've incorporated all the suggested changes, except the ones = that would create a new incompatible protocol. I intend to start discussion of a new version to fix the warts, but = let's take care of this baseline first. On Nov 8, 2010, at 12:01 PM, IETF I-D Submission Tool wrote: >=20 > A new version of I-D, draft-hotz-kx509-01.txt has been successfully = submitted by Henry Hotz and posted to the IETF repository. >=20 > Filename: draft-hotz-kx509 > Revision: 01 > Title: KX509 Kerberized Certificate Issuance Protocol > Creation_date: 2010-11-08 > WG ID: Independent Submission > Number_of_pages: 10 >=20 > Abstract: > This rfc describes a protocol, called kx509, for using Kerberos > tickets to acquire X.509 certificates. >=20 > While not (previously) standardized, this protocol is already in use > at several large organizations, and certificates issued with this > protocol are recognized by TAGPMA (The Americas Grid Policy > Management Authority). >=20 >=20 >=20 > The IETF Secretariat. ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From shawn.emery@oracle.com Mon Nov 8 23:41:10 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57D543A6862 for ; Mon, 8 Nov 2010 23:41:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.514 X-Spam-Level: X-Spam-Status: No, score=-6.514 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N+u7Ioos82En for ; Mon, 8 Nov 2010 23:41:09 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 83F513A6832 for ; Mon, 8 Nov 2010 23:41:09 -0800 (PST) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id oA97fUmf011243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 9 Nov 2010 07:41:32 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id oA96GOLl010948 for ; Tue, 9 Nov 2010 07:41:28 GMT Received: from abhmt002.oracle.com by acsmt355.oracle.com with ESMTP id 759947391289288383; Mon, 08 Nov 2010 23:39:43 -0800 Received: from dhcp-718e.meeting.ietf.org (/130.129.113.142) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 08 Nov 2010 23:39:42 -0800 Message-ID: <4CD8FABC.5000009@oracle.com> Date: Tue, 09 Nov 2010 00:39:40 -0700 From: Shawn M Emery User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: saag@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [saag] Kitten Working Group Summary - IETF 79 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 07:41:10 -0000 The kitten WG met Tuesday, 11/9/10, during the first morning session for two hours. Co-chairs: Shawn Emery, Tom Yu The goals of the meeting were to review the state of the active WG items, discuss implementing kitten technologies, SASL-SAML vs SASL-SAML-EC, and the SASL-OAuth draft. gssapi-extensions-iana ---------------------------- Consensus on the list was to standardize a per programming language register. Co-chairs will ask the editor again to update the draft with per programming language registry text. draft-ietf-kitten-digest-to-historic ---------------------------------------- Tom Yu has agreed to perform the PROTO write-up for this draft. gssapi-naming-exts ------------------------ Current state is: Revised ID needed. Sam Hartman has volunteered to provide text to resolve issues that he has presented at the last IETF meeting. He has also agreed to create a separate SAML mechanism implementation draft for naming extensions. draft-ietf-kitten-sasl-openid --------------------------------- Still looking for review and comments. draft-ietf-kitten-sasl-saml ------------------------------- New version submitted to clarify security considerations section to include a secure channel for the mechanism. The draft was updated to use a URI redirect instead of an HTTP. Looking for review and comments. Presentations ---------------- Implementation Feed-back of Kitten Technologies by Sam Hartman Sam discussed some positive feed-back in implementing a GSS-API mechanism besides Kerberos, GSS-EAP. There were some limitations and some complimentary libraries required to perform mappings, for example. SASL-SAML and SASL-SAML-EC by Klaas Wierenga There was confusion on the list between the differences between SASL-SAML and SASL-SAML-EC mechanisms. Klaas discussed the infrastructure and protocol differences between the two mechanisms. SASL-OAuth by Hannes Tschofenig There will be a consensus call on the list to decide whether to adopt the SASL-SAML-EC and SASL-OAuth drafts in the WG and to discuss how to address the security issues associated with these and the SASL OpenID and SAML drafts currently in the WG charter. Charter Discussion ----------------------- Still looking for volunteers for the following work items initialization/new credentials listing/iterating credentials exporting/importing credentials error message reporting asynchronous calls security strength reporting programmer friendliness There has been greater interest in initial credentials and asynchronous calls. The WG should pursue these fairly soon. Shawn kitten co-chair -- From barryleiba.mailing.lists@gmail.com Tue Nov 9 00:01:04 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2DE53A6928 for ; Tue, 9 Nov 2010 00:01:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.896 X-Spam-Level: X-Spam-Status: No, score=-101.896 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S03s-wZ2-iWG for ; Tue, 9 Nov 2010 00:01:03 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 3250B3A690A for ; Tue, 9 Nov 2010 00:01:03 -0800 (PST) Received: by vws3 with SMTP id 3so3044951vws.31 for ; Tue, 09 Nov 2010 00:01:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=PLZztKAxCt2u07OaIlFY4ZqRooXgH7QgH5UzW4WjW24=; b=v6H3ai8+fTYMoYiC7+3hDnb9e2ulqrwtfbF3pFf79yHaxyS4JCzV+7q8mDtkUu9rm8 5nCJhBURHgnYaImZ7umfBSH2YQY28HeGKXIdrCzC/nIBPIZ0BblsLW3owawlu6KZ8y+e igHBf0zA5V1yDdgT2GTZ8IDE1B5FULIJ8FNRA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=grf4KkO9Q8kB45WkUnfDe60LIxBnVhIYyqy1MTmpnoR4Ony3p4oUl94AT0UjPSO96p yiZNObAbAgh5z5WmQdY+SYqRBE1uZx0sCawXZaR5PNA2JlWnhlv0cHcYCiLnMYmBsH7c VA9Zne8Ap4C5npzuPadAcEUoBWsEnIdacjBUU= MIME-Version: 1.0 Received: by 10.224.176.66 with SMTP id bd2mr4989652qab.199.1289289685952; Tue, 09 Nov 2010 00:01:25 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.220.181.67 with HTTP; Tue, 9 Nov 2010 00:01:25 -0800 (PST) Date: Tue, 9 Nov 2010 16:01:25 +0800 X-Google-Sender-Auth: vtipymgtsMq0co2QI8x_xNniVyk Message-ID: From: Barry Leiba To: saag Content-Type: text/plain; charset=ISO-8859-1 Subject: [saag] DKIM working group summary for IETF 79 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 08:01:04 -0000 DKIM is not meeting at IETF 79. We are working on finishing up 4871bis (taking DKIM base to Draft Standard), aiming to get it to the IESG in December -- the interoperability report is done and ready. Following that, we will finish up the "mailing lists" informational document, aiming to get that to the IESG by February. We will then evaluate the energy and likelihood of progress on other items, and consider the future of the working group. Barry (and Stephen), DKIM chair(s) From kent@bbn.com Tue Nov 9 23:00:42 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5959A3A69D6 for ; Tue, 9 Nov 2010 23:00:42 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id elVgotG9t+5V for ; Tue, 9 Nov 2010 23:00:35 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id E13CA3A69D5 for ; Tue, 9 Nov 2010 23:00:24 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:47597 helo=[130.129.35.119]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PG4fq-000F1Q-Sl for saag@ietf.org; Wed, 10 Nov 2010 02:00:51 -0500 Mime-Version: 1.0 Message-Id: Date: Wed, 10 Nov 2010 02:00:47 -0500 To: saag@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [saag] PKIX report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 07:00:42 -0000 PKIX met for about an hour, on Wednesday morning, with about out 30 attendees. A quick doc status review: - 3 new RFCs: 5934, 6024, & 6025 - 2 in IESG (1 about to begin IETF LC) - 4 in the WG: CMC Updates, 5280 clarifications, OCSP update and transport protocols for CMP The OCSP update doc is essentially done, and we elected to defer a couple of issues until we begin work on OCSP-bis. We decided to issue a new doc defining SMIME Capabilities for signature alg parameters, to address an OCSP alg agility requirement. We also had a presentation on an I-D from the SIDR WG, which describes another approach to local management of trust anchors. The mechanism described here is somewhat complex, because of the need to accommodate the path validation rules of RFC 3779. (The Resoure PKI, developed in the SIDR WG, makes use of 3779 extensions, and thus the complexity is needed in that context). However, the basic notion of re-issuing proffered TAs under an RP-controlled TA, may of general utility. From tobias.gondrom@gondrom.org Wed Nov 10 01:06:56 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 215933A6A60 for ; Wed, 10 Nov 2010 01:06:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.815 X-Spam-Level: X-Spam-Status: No, score=-94.815 tagged_above=-999 required=5 tests=[AWL=0.547, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0QOCco5cRq2 for ; Wed, 10 Nov 2010 01:06:54 -0800 (PST) Received: from lvps83-169-7-107.dedicated.hosteurope.de (lvps83-169-7-107.dedicated.hosteurope.de [83.169.7.107]) by core3.amsl.com (Postfix) with ESMTP id 611D73A6A5E for ; Wed, 10 Nov 2010 01:06:53 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=boxtYTzDTXF2V7llkLjxd98kTW9fuDjJp+Ov8euto039HsYMlDytkPnCFpDnFt5AUWhM8gdBOjTfMcZr1HdMD5kT5QtBX9qqTYbdwXlGziB5Rz5kYLbJSdC0jRKS5E+n; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; Received: (qmail 13530 invoked from network); 10 Nov 2010 10:05:52 +0100 Received: from dhcp-45ee.meeting.ietf.org (HELO seraphim.heaven) (130.129.69.238) by lvps83-169-7-107.dedicated.hosteurope.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 10 Nov 2010 10:05:52 +0100 Message-ID: <4CDA606F.3060700@gondrom.org> Date: Wed, 10 Nov 2010 09:05:51 +0000 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101026 SUSE/3.1.6 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: saag@ietf.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [saag] LTANS report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 09:06:56 -0000 LTANS did not meet in Beijing. ltans status: WG in final phase and should be closed very soon. One last document draft-ietf-ltans-xmlers-07.txt received some late (after close of WGLC) comments, which are currently answered by the authors. Draft will go to IESG afterwards. Two other drafts: ari and validate will (as agreed in Maastricht) be proceeded outside of WG as individual and indepedent submissions. Tobias From stevehanna.travel@gmail.com Wed Nov 10 01:39:39 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59AC83A69EF for ; Wed, 10 Nov 2010 01:39:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.397 X-Spam-Level: X-Spam-Status: No, score=-2.397 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlJ7rmSBM++s for ; Wed, 10 Nov 2010 01:39:38 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 336493A691E for ; Wed, 10 Nov 2010 01:39:38 -0800 (PST) Received: by qwb7 with SMTP id 7so476324qwb.31 for ; Wed, 10 Nov 2010 01:40:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=H/bVlmV4uVFOm8Mj7eVzOWwshJ5TDqhe+y3tsOXbcmg=; b=nMd5QB20HkoCCcU4+NCejzsJI4xi29bHfGY/yjg55ahvP0J97zdUTWY6ndI5zdXS7v WM2bJXt0Szj+h7tyqnny9diaWegXHAgpEv/h7QXdMIB7278Pm+zBkCqIiciWwbKCYYSu gdiVFjJWPNkpF5KmstdzsyO4A4VOKOZz+StFA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=k9cgMrjtwwjLaLlCLbmmzpuM+Edfb9nN+VYolCj3j9li0iV42oyX1BOEgKKuFhlqTU dXvw8Wnv0GfDZF+l0qF3ZmXc6yv7Tp/UYC3mOiH+SxmUpWrLdZhnc9DdSQgRtIcXKzrk Abe1TtWxHDRBcGy88OgtGH+2LGgJwfFYBB8dk= MIME-Version: 1.0 Received: by 10.224.179.19 with SMTP id bo19mr1562041qab.387.1289382004604; Wed, 10 Nov 2010 01:40:04 -0800 (PST) Received: by 10.229.250.21 with HTTP; Wed, 10 Nov 2010 01:40:04 -0800 (PST) Date: Wed, 10 Nov 2010 17:40:04 +0800 Message-ID: From: Steve Hanna To: saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [saag] SCAP BOF Report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 09:39:39 -0000 The SCAP BOF met on Tuesday, November 9 from 1520 to 1810. This was an exploratory BOF devoted to exploring the possible ways in which the IETF and SCAP communities can work together. After an SCAP Overview and several presentations that looked at SCAP from several perspectives (Network Management, NEA, and ITU CYBEX), there was an extensive Q&A and a discussion of the possibilities for collaboration. The group agreed to write up an Internet Draft with collaboration ideas, focusing especially on network protocols that the SCAP community needs: reporting on SCAP compliance within a NEA assessment, provisioning XCCDF and OVAL content to an endpoint, etc. This draft can stimulate more concrete discussions about whether a WG should be formed. From yaronf.ietf@gmail.com Wed Nov 10 02:41:15 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51BB83A69C2 for ; Wed, 10 Nov 2010 02:41:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.312 X-Spam-Level: X-Spam-Status: No, score=-102.312 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id As9X5BxaYtnR for ; Wed, 10 Nov 2010 02:41:08 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id AF6663A69FC for ; Wed, 10 Nov 2010 02:41:03 -0800 (PST) Received: by wwb39 with SMTP id 39so562063wwb.13 for ; Wed, 10 Nov 2010 02:39:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=NJ3tEf18yUCX4o7b2VW9DnPS6zIh/Ul8wAUTV/efsp0=; b=jbvoMqGayUELR225fDAj7srND4yI+MgyBjh3NNDQ4QkcE5gcEV7cvn2unxI3cHVMjT GJQVecaLeMHHIqCw59jEpfZhpm/cisqEUUt42ZyxwvRKFQJ+ZVLscildTdepmJyRBxNs rdT0jY6S6Ud0+cH76oarp2nZ4MoAuepFdi6sA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=GueVCNFzYmSlS8LzCbMGYauxP/lDT92yYWKrlnwCeeovQyiZ55y1C/FBt64VplRIqn 53TVexBwJ8RxN305ofDvVpaVfJ9NTSpG+YE7n3ZN0wjEZwaZybqlmvSJNMtpIWzYJluc rvNYvppCEK7N454k/PYHBo+OU2+L4FFVUAnfs= Received: by 10.227.157.205 with SMTP id c13mr8203803wbx.97.1289385546305; Wed, 10 Nov 2010 02:39:06 -0800 (PST) Received: from [10.0.0.2] (bzq-79-181-26-165.red.bezeqint.net [79.181.26.165]) by mx.google.com with ESMTPS id ga16sm463136wbb.7.2010.11.10.02.39.04 (version=SSLv3 cipher=RC4-MD5); Wed, 10 Nov 2010 02:39:05 -0800 (PST) Message-ID: <4CDA7646.4000007@gmail.com> Date: Wed, 10 Nov 2010 12:39:02 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Paul Hoffman , saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [saag] ipsecme meeting report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 10:41:15 -0000 IPsecME met Wednesday afternoon. We reviewed document status: IKEv2-bis was published (RFC 5996), as well as Mutual EAP Authentication (RFC 5998) and the High Availability Problem Statement (RFC 6207). IPsec Roadmap is an in RFC Editor queue. There was a long discussion of the failure detection draft, where the focus was on exactly which deployment scenarios we want this mechanism to support. A new revision of the HA protocol was presented. It resolves the main issues that were raised in Maastricht, but still has a few open issues that we should aim to close within the next few weeks. It is our goal to have both these draft through WGLC before Prague. Three other non-WG items were discussed: - A stripped down version of the IKEv2 document - somewhere between a tutorial and a minimal profile. - An implementation of IKEv2 authentication using IPv6 CGAs. - A draft on optimized IKEv2 reauthetication, where you don't have to restart the whole IKE SA plus its dependent IPsec SAs. From stevehanna.travel@gmail.com Wed Nov 10 06:04:57 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3D743A696E for ; Wed, 10 Nov 2010 06:04:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzHQoRsY8Zrc for ; Wed, 10 Nov 2010 06:04:57 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id EB0D63A6965 for ; Wed, 10 Nov 2010 06:04:56 -0800 (PST) Received: by qwb7 with SMTP id 7so681719qwb.31 for ; Wed, 10 Nov 2010 06:05:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=bevQv/C3ieWqL5QhHkOnZr5IquIsxqQhlv9MFNdWPFk=; b=CxfkN7K8y+LrcRKrw0e7DeZcnY8hGTyIqWI8C1P9WCjXw2NEVL3BGk5nyHK3IvSYB5 FsYz091q3Cwhqj+qYPBGEhtSFEBwVIph6E9FATWTWfhTMJ1oOIpK0WqwGOK2V2WQ61xy ceSg53crvVmZIgmel/kFOEiEX81ABCTu+pP7I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=VeAAsEXA6al/YgsiYv7chb4/4YVDs6RxOmLLM/cUGC5HhnFP+ydXSD5kx+rk1FfePj d3tHU48UGbXMAprLhOz7v1YJy2/x6l2I9uY8DeA8LyHxbI923bAquMiTBiEGwxMgdqF9 VVkx7KfCDcIh7hf4zvfmjAEPABOCNdEQr5T0c= MIME-Version: 1.0 Received: by 10.229.222.65 with SMTP id if1mr7662345qcb.159.1289397923125; Wed, 10 Nov 2010 06:05:23 -0800 (PST) Received: by 10.229.250.21 with HTTP; Wed, 10 Nov 2010 06:05:22 -0800 (PST) Date: Wed, 10 Nov 2010 22:05:22 +0800 Message-ID: From: Steve Hanna To: saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [saag] NEA report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 14:04:57 -0000 The NEA WG met on Monday, November 8 from 1300 to 1500. We heard a report from the NEA Asokan Attack Mitigation Design Team that we started up after the last IETF meeting. They recommended using the tls-unique channel bindings to address the NEA Asokan attack by binding the Posture Transport protocol (PT) to a PA protocol message exchange with an External Measurement Agent (EMA), as described in draft-salowey-nea-asokan-00.txt. There was complete consensus in the room to take this approach. Assuming this consensus is confirmed on the email list, the next step is to update the PT proposals to reflect it and to create an informational document with guidance for EMA implementors. We plan to hold a virtual interim meeting in January to decide which PT proposals will go forward. By IETF 80, we should have WG drafts for PT and we hope to complete work on those by August 2011. From j.schoenwaelder@jacobs-university.de Wed Nov 10 07:35:17 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB0F03A6A26 for ; Wed, 10 Nov 2010 07:35:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.115 X-Spam-Level: X-Spam-Status: No, score=-103.115 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSkw1LAiRMuA for ; Wed, 10 Nov 2010 07:35:12 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 8A4633A698E for ; Wed, 10 Nov 2010 07:35:03 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 71D79C000B for ; Wed, 10 Nov 2010 16:35:30 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id gPYRs0LYAiju; Wed, 10 Nov 2010 16:35:29 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C5FCEC0019; Wed, 10 Nov 2010 16:35:26 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id B8F58159E480; Wed, 10 Nov 2010 16:35:26 +0100 (CET) Date: Wed, 10 Nov 2010 16:35:26 +0100 From: Juergen Schoenwaelder To: saag@ietf.org Message-ID: <20101110153526.GB61099@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [saag] ISMS report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 15:35:18 -0000 The ISMS working group met in a one hour session on Wednesday at 15:10 to discuss a proposal for a Kerberos security model. The discussion centered around the question of whether or not a Kerberos security model should be added to the existing set of security models. At the end of the meeting, which was attended by a relatively small number of people, there was no consensus in the room as to whether or not the WG should take on the work to develop a Kerberos security model. The chairs have to address the need and adoption issue with the mailing list. For the (D)TLS transport of SNMP and related specifications, interoperability testing is ongoing with the goal to advance the specifications to Draft Standard. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From jsalowey@cisco.com Wed Nov 10 17:37:29 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 558293A6895 for ; Wed, 10 Nov 2010 17:37:28 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KBWoqPYoyHng for ; Wed, 10 Nov 2010 17:37:24 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 094013A68C6 for ; Wed, 10 Nov 2010 17:37:22 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqwFAMfX2kxAZnwN/2dsb2JhbACUQ417caRLm0iFSgSEWoV9 X-IronPort-AV: E=Sophos;i="4.59,180,1288569600"; d="scan'208";a="180632670" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 11 Nov 2010 01:37:51 +0000 Received: from dhcp-2252.meeting.ietf.org (rtp-vpn4-863.cisco.com [10.82.211.95]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oAB1bo6p012473 for ; Thu, 11 Nov 2010 01:37:50 GMT From: Joe Salowey Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Nov 2010 17:37:53 -0800 Message-Id: <24933755-2FB3-40CF-8C40-C3E841C65DE5@cisco.com> To: saag@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [saag] IETF-79 Summary X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 01:37:29 -0000 TLS did not meet at IETF-79. We have several documents making their way = through the publication process. Extension revisions (4366-bis) is in = the RFC editor queue. SSL2-Must-Not is in WGLC. DTLS 1.2 will be = submitted to the IESG next week. =20 Cheers, Joe= From jsalowey@cisco.com Wed Nov 10 17:48:29 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B40DC3A68FF for ; Wed, 10 Nov 2010 17:48:29 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajvQXVuSeWxY for ; Wed, 10 Nov 2010 17:48:28 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 9B1BE3A68FE for ; Wed, 10 Nov 2010 17:48:28 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqwFAJfa2kxAZnwN/2dsb2JhbACUQo17caQ/m0iDEYI5BIRahX0 X-IronPort-AV: E=Sophos;i="4.59,180,1288569600"; d="scan'208";a="180850200" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 11 Nov 2010 01:48:56 +0000 Received: from dhcp-2252.meeting.ietf.org (rtp-vpn4-863.cisco.com [10.82.211.95]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oAB1mtBx014295 for ; Thu, 11 Nov 2010 01:48:56 GMT From: Joe Salowey Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Nov 2010 17:48:58 -0800 Message-Id: <7AB4CD33-6C5F-4709-895B-815E52E55CB9@cisco.com> To: saag@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [saag] IETF-79 EMU summary X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 01:48:29 -0000 EMU met on Wednesday afternoon. We had a short discussion channel = bindings with the main topic of which AAA attribute namespace, RADIUS = or Diameter, to use for channel binding attributes. We put together an = updated set of milestones for the remaining EMU work items of Channel = Bindings and tunnel/password method draft. We had a presentation on a = tunnel method based on PEAP called EAP-TEAM. The tunnel method = requirements draft is in IETF last call. =20 Cheers, Joe From bew@cisco.com Wed Nov 10 19:18:40 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD9D728C117 for ; Wed, 10 Nov 2010 19:18:40 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2eg-PaxrPc78 for ; Wed, 10 Nov 2010 19:18:40 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 0D00528C111 for ; Wed, 10 Nov 2010 19:18:40 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqwFAOrv2kxAaMHG/2dsb2JhbACUQo17caQjmzeFSgSEWIV/ X-IronPort-AV: E=Sophos;i="4.59,181,1288569600"; d="scan'208";a="617974907" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-6.cisco.com with ESMTP; 11 Nov 2010 03:19:08 +0000 Received: from dhcp-7599.meeting.ietf.org (hkidc-vpn-client-234-67.cisco.com [10.75.234.67]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oAB3J42F017094 for ; Thu, 11 Nov 2010 03:19:06 GMT Message-Id: From: Brian Weis To: saag@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 11 Nov 2010 11:19:02 +0800 X-Mailer: Apple Mail (2.936) Subject: [saag] IETF-79 MSEC report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 03:18:40 -0000 MSEC met for 1 hour on Monday afternoon. Two presentations were made: - Brian Weis presented a description of changes to the GDOI Update document, plus open issues yet to be resolved. It will go though another short working group last call once the open issues have been resolved. - Sam Hartman presented the Multicast Router Key Management Protocol (MRKMP), a work in progress addressing key agreement for OSPF, ISIS, and other multi-party routing protocols. MRKMP takes concepts from IKEv2 and GDOI. Although it's targeted at the KARP WG, MRKMP may be related to a proposed MSEC work item that also applies GDOI protocol definitions as an IKEv2 excnahge, solving a more general group security problem. As both efforts mature, we'll determine if there is any protocol definition synergy. Brian From leifj@mnt.se Wed Nov 10 19:38:31 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69AF63A67B8 for ; Wed, 10 Nov 2010 19:38:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gj7vCbSrSh4h for ; Wed, 10 Nov 2010 19:38:25 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by core3.amsl.com (Postfix) with ESMTP id 404793A6998 for ; Wed, 10 Nov 2010 19:38:25 -0800 (PST) Received: from [130.129.39.42] (dhcp-272a.meeting.ietf.org [130.129.39.42]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id oAB3ckkX020441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 11 Nov 2010 04:38:52 +0100 (CET) Message-ID: <4CDB6545.6070706@mnt.se> Date: Thu, 11 Nov 2010 04:38:45 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: "saag@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [saag] abfab wg status X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 03:38:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The abfab wg met at 9am this morning. This was the first wg meeting and we had a couple of introductory presentations for context. There has been significant initial progress on the core documents and we are getting some new volunteers to do work. The following drafts were covered during the wg session: draft-ietf-abfab-gss-eap-0 draft-ietf-abfab-gss-eap-naming-00 draft-ietf-abfab-aaa-saml-00 draft-lear-abfab-architecture-00 Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzbZUUACgkQ8Jx8FtbMZnfumQCgyJIb4nlj2mteG/4pKdGBLcxA 1uMAoLgPRCUOm4xpAsDWyhXy4kP8Ri9V =L+Il -----END PGP SIGNATURE----- From hannes.tschofenig@gmx.net Wed Nov 10 21:27:11 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B67233A67E2 for ; Wed, 10 Nov 2010 21:27:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AznnFEnwjnLu for ; Wed, 10 Nov 2010 21:27:11 -0800 (PST) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 2B1593A6889 for ; Wed, 10 Nov 2010 21:27:08 -0800 (PST) Received: (qmail invoked by alias); 11 Nov 2010 05:27:36 -0000 Received: from dhcp-7730.meeting.ietf.org (EHLO dhcp-7730.meeting.ietf.org) [130.129.119.48] by mail.gmx.net (mp011) with SMTP; 11 Nov 2010 06:27:36 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/33moMR6v3FijvjVlTRmDayP7AwEFGCSOS+qxGF5 0LNJYAVCWLIchd From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Nov 2010 13:27:32 +0800 Message-Id: To: saag@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) X-Y-GMX-Trusted: 0 Subject: [saag] OAuth WG status X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 05:27:11 -0000 The OAuth WG does not meet at this IETF meeting.=20 Interested participants got together to chat about security.=20 The presentations given during the week include:=20 1) OAuth Tutorial http://www.ietf.org/proceedings/79/slides/saag-4.ppt 2) OAuth Security http://www.ietf.org/proceedings/79/slides/saag-5.pptx 3) OAuth SAAG presentation http://www.ietf.org/proceedings/79/slides/saag-3.ppt In the working group we are currently working hard to complete the work = on the OAuth 2.0 specification and are dealing with the writeup for the = security consideration section. We plan to re-schedule the group soon! Ciao Hannes From prvs=09314cdfe5=alan.ford@roke.co.uk Thu Nov 11 00:05:01 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 263603A6882; Thu, 11 Nov 2010 00:05:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id noD4jACSUBLh; Thu, 11 Nov 2010 00:05:00 -0800 (PST) Received: from gse-mta-29.emailfiltering.com (gse-mta-29-tx.emailfiltering.com [194.116.198.160]) by core3.amsl.com (Postfix) with ESMTP id 959F13A67E3; Thu, 11 Nov 2010 00:04:59 -0800 (PST) Received: from salt-ext.roke.co.uk ([109.207.29.2]) by gse-mta-29.emailfiltering.com with emfmta (version 4.6.0.72) vanilla id 207555440 for saag@ietf.org;d282a826e9176604; Thu, 11 Nov 2010 08:05:28 +0000 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, 11 Nov 2010 08:05:14 -0000 Message-ID: <2181C5F19DD0254692452BFF3EAF1D680B82C60F@rsys005a.comm.ad.roke.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Multipath TCP Security Thread-Index: AcuBdyo1HiDV8IOYQXesk2E/cS+rWQ== From: "Ford, Alan" To: Cc: multipathtcp@ietf.org Subject: [saag] Multipath TCP Security X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 08:05:01 -0000 Hi all, Thank you for your time today in the SAAG session (http://www.ietf.org/proceedings/79/slides/saag-1.ppt). For further information about our Multipath TCP developments, the key documents are: * The MPTCP threat analysis: http://tools.ietf.org/html/draft-ietf-mptcp-threat-03 * The MPTCP protocol, which includes the documentation of the -02 security proposal as I presented today: http://tools.ietf.org/html/draft-ietf-mptcp-multiaddressed-02 To reiterate, MPTCP combined multiple TCP connections ("subflows") on the network into a single MPTCP connection, which is indistinguishable from standard TCP for the application. MPTCP uses TCP options to convey signaling information (maximum length of 40 bytes, although many are already used for other options such as Timestamp or SACK). This signaling information is used primarily for the exchange of identifying information at the start of a new subflow to indicate to which MPTCP connection it belongs, and for indicating what sequence numbers at the MPTCP connection-level ("Data Sequence Number") map to what sequence numbers on the subflow. We recognise the inherent insecurity in a clear-text key exchange at the start of the connection, but believe that this is closer to our "no worse than TCP" goal than the previous (-01) proposal of single tokens always exchanged in the clear. There are additional protections in the protocol (Data Sequence Number Window; subflow liveness tests) in order to reduce the chances of a successful attack. Thanks to those who provided feedback in today's session: One possibility may be to document a Diffie-Hellman exchange as an extension via a flag in the SYN exchange that they encodes the exchange in the first two packets of the payload; another may be to drip-feed a DH exchange via options during the initial connection (possibly after a timer in order to see if the connection is long-lived enough to justify the use of MPTCP). However, we are also concerned about MPTCP being too heavyweight to implement, and we would very much welcome any input and suggestions you may have for a sufficiently lightweight solution to our problem. Many thanks, Alan From shore@arsc.edu Thu Nov 11 15:24:18 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF6B63A6452 for ; Thu, 11 Nov 2010 15:24:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abB9DOM6IMwT for ; Thu, 11 Nov 2010 15:24:17 -0800 (PST) Received: from arsc.edu (mail1.arsc.edu [IPv6:2001:480:150:75::229]) by core3.amsl.com (Postfix) with ESMTP id 1AEE73A635F for ; Thu, 11 Nov 2010 15:24:14 -0800 (PST) Received: from viking-e0.arsc.edu (viking-e0.arsc.edu [IPv6:2001:480:150:75:223:32ff:feda:4a52]) by arsc.edu (20090828.ARSC) with ESMTP id oABNOfKT027037 for ; Thu, 11 Nov 2010 14:24:41 -0900 (AKST) From: Melinda Shore Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 11 Nov 2010 14:24:40 -0900 Message-Id: <942D89A1-69D9-44E4-8FA8-6A28ABC5EC5F@arsc.edu> To: saag@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) X-CanIt-Geo: No geolocation information available for 2001:480:150:75:223:32ff:feda:4a52 X-CanItPRO-Stream: default X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on IPv6:2001:480:150:75::167 Subject: [saag] Scoping the HARD problem X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 23:24:18 -0000 The audio during the saag session wasn't great, so there's an excellent chance I missed a great deal, but I'm unclear on the intended scope of the "HARD" problem. There's a similar problem in HTTP redirects, or even just in HTTP handoffs from one site to another. These cases seem very ill-suited for the DNS-based solution described in draft-barnes-hard-problem (you're probably not going to go out to get an SRV record for an HTTP URI). Is the intent to focus on the XMPP/some-other-service case, or to be more general? Thanks, Melinda From rbarnes@bbn.com Thu Nov 11 15:46:43 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 909B83A6781 for ; Thu, 11 Nov 2010 15:46:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.608 X-Spam-Level: X-Spam-Status: No, score=-102.608 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVLqBQiippuV for ; Thu, 11 Nov 2010 15:46:42 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 88B0D3A635F for ; Thu, 11 Nov 2010 15:46:42 -0800 (PST) Received: from [128.89.253.93] (port=49975 helo=richards-MacBook-Pro.local) by smtp.bbn.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PGgrI-000MME-SZ; Thu, 11 Nov 2010 18:47:13 -0500 Message-ID: <4CDC807A.1090801@bbn.com> Date: Fri, 12 Nov 2010 07:47:06 +0800 From: "Richard L. Barnes" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Melinda Shore References: <942D89A1-69D9-44E4-8FA8-6A28ABC5EC5F@arsc.edu> In-Reply-To: <942D89A1-69D9-44E4-8FA8-6A28ABC5EC5F@arsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: saag@ietf.org Subject: Re: [saag] Scoping the HARD problem X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 23:46:43 -0000 Hey Melinda, The presentation in SAAG was an attempt to generalize out from a conversation that started in the XMPP community, which has SRV-based outsourcing as a particular pain point. But I think the idea of presenting to the broader community was to see if there was interest in a more general solution, or even if that's something that people thought might be feasible. --Richard On 11/12/10 7:24 AM, Melinda Shore wrote: > The audio during the saag session wasn't great, so > there's an excellent chance I missed a great deal, > but I'm unclear on the intended scope of the "HARD" > problem. There's a similar problem in HTTP > redirects, or even just in HTTP handoffs from one site > to another. These cases seem very ill-suited for the > DNS-based solution described in draft-barnes-hard-problem > (you're probably not going to go out to get an SRV > record for an HTTP URI). Is the intent to focus on > the XMPP/some-other-service case, or to be more general? > > Thanks, > > Melinda > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From shore@arsc.edu Thu Nov 11 16:20:47 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D496C3A67AD for ; Thu, 11 Nov 2010 16:20:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dyfOFOc7LSGU for ; Thu, 11 Nov 2010 16:20:47 -0800 (PST) Received: from arsc.edu (mail1.arsc.edu [IPv6:2001:480:150:75::229]) by core3.amsl.com (Postfix) with ESMTP id DB9D03A679F for ; Thu, 11 Nov 2010 16:20:44 -0800 (PST) Received: from viking-e0.arsc.edu (viking-e0.arsc.edu [IPv6:2001:480:150:75:223:32ff:feda:4a52]) by arsc.edu (20090828.ARSC) with ESMTP id oAC0Iqg5029872; Thu, 11 Nov 2010 15:18:52 -0900 (AKST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Melinda Shore In-Reply-To: <4CDC807A.1090801@bbn.com> Date: Thu, 11 Nov 2010 15:18:52 -0900 Content-Transfer-Encoding: quoted-printable Message-Id: <8BE1E30A-CBC4-4370-87BB-83B6CE1B6B88@arsc.edu> References: <942D89A1-69D9-44E4-8FA8-6A28ABC5EC5F@arsc.edu> <4CDC807A.1090801@bbn.com> To: "Richard L. Barnes" X-Mailer: Apple Mail (2.1081) X-CanIt-Geo: No geolocation information available for 2001:480:150:75:223:32ff:feda:4a52 X-CanItPRO-Stream: default X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on IPv6:2001:480:150:75::167 Cc: saag@ietf.org Subject: Re: [saag] Scoping the HARD problem X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 00:20:48 -0000 On Nov 11, 2010, at 2:47 PM, Richard L. Barnes wrote: > The presentation in SAAG was an attempt to generalize out from a = conversation that started in the XMPP community, which has SRV-based = outsourcing as a particular pain point. But I think the idea of = presenting to the broader community was to see if there was interest in = a more general solution, or even if that's something that people thought = might be feasible. I've been interested in the more general problem from a=20 somewhat different perspective: Vendor A sends you off to someone who appears to be Payment Agency B - how do you know that they're authorized to collect funds on behalf of=20 Vendor A?=20 Melinda From turners@ieca.com Sun Nov 14 05:55:32 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAC803A68F2 for ; Sun, 14 Nov 2010 05:55:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SaEfTEjYnyAd for ; Sun, 14 Nov 2010 05:55:26 -0800 (PST) Received: from nm17-vm0.bullet.mail.ne1.yahoo.com (nm17-vm0.bullet.mail.ne1.yahoo.com [98.138.91.58]) by core3.amsl.com (Postfix) with SMTP id 61D413A6A2B for ; Sun, 14 Nov 2010 05:55:24 -0800 (PST) Received: from [98.138.90.52] by nm17.bullet.mail.ne1.yahoo.com with NNFMP; 14 Nov 2010 13:56:00 -0000 Received: from [98.138.89.246] by tm5.bullet.mail.ne1.yahoo.com with NNFMP; 14 Nov 2010 13:56:00 -0000 Received: from [127.0.0.1] by omp1060.mail.ne1.yahoo.com with NNFMP; 14 Nov 2010 13:56:00 -0000 X-Yahoo-Newman-Id: 272898.57330.bm@omp1060.mail.ne1.yahoo.com Received: (qmail 42910 invoked from network); 14 Nov 2010 13:55:59 -0000 Received: from thunderfish.local (turners@96.241.1.242 with plain) by smtp113.biz.mail.mud.yahoo.com with SMTP; 14 Nov 2010 05:55:59 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: 6qO1JSkVM1ktfroLDuGMrhevAKhVqxQIGDN3s5atNnw65_Q nksU5uWSCtHJci3mjSUu4sAxEfn3hJIARPPI0IAeDTEiAi84Jz3.etWi9zdl lmKnNrEUrmhMsJgIipgvp5vgs40gwts.ROP32mCc59NL6TKoKhHqrl9iaTbE q4aVzA.TVgasQnMYyGPvys6s8Zk.abLkO2t9.nHFHu9zGUveCzg0GNjnz662 6iTYGsLauR_za7Nsdt8Spy5bwelQ0MwndFI0e2VyquqzTalh9oCMT4oGW6.H SXq2aa2z2BXDWMAsSH0ZayPkCHLbAX7L0OYs9KU5dJzRfkA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4CDFEA6F.7050100@ieca.com> Date: Sun, 14 Nov 2010 08:55:59 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: cfrg@ietf.org Subject: [saag] draft-turner-sha0-sha1-seccon-01.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Nov 2010 13:55:33 -0000 I submitted a new version, but I can't find the I-D Action email. Here's the link: http://tools.ietf.org/id/draft-turner-sha0-sha1-seccon-01.txt Changes include: - Removing 2119 language - Adding Paul Hoffman as author - Reworked the pre-image and second pre-image text - (significantly) reworked the guidance section Comments are welcome. Please use the saag@ietf.org list. Cheers, spt From hallam@gmail.com Wed Nov 10 14:48:17 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80DAB3A67B1 for ; Wed, 10 Nov 2010 14:48:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id on-G0-CVxPqy for ; Wed, 10 Nov 2010 14:48:13 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 8C7D03A677C for ; Wed, 10 Nov 2010 14:48:13 -0800 (PST) Received: by gyh20 with SMTP id 20so490028gyh.31 for ; Wed, 10 Nov 2010 14:48:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=cLgGHXyVLKAgPKqSfjXZ7isZE8aR79GQO7Ct3fLHUK0=; b=A/rjqcZou49L1t6mbC8PwRfNhs95ot+bTwZjrw6d351D3jucC9IlfbbWPvDZQOLCr4 L60g6eySQKiH0yb5I11nDa6/xkfzdYAcsxFgAF7486oiZBGsod4npXWbmgArqz72+yYy +I8oC55YHZTuddDuAEQSez6mVk/lcbZMJX5fI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=vBwkbMENJeA4DOMgX6Kh+l+nVprN2uzosXmaeI4JXBt8rzKLUwBj7AxrBIgCD5QnMT 17t9wacp4/JqEjOtpVVIwii/u79nGfdJyy/tAHMAj9Q0h56zcUR6Ba39UEB/Z9/Fbh4/ mf3sRvt4QXd25lyXPCoIsVSQyOk0u32tQjRKc= MIME-Version: 1.0 Received: by 10.100.138.16 with SMTP id l16mr1507797and.0.1289429320912; Wed, 10 Nov 2010 14:48:40 -0800 (PST) Received: by 10.100.41.14 with HTTP; Wed, 10 Nov 2010 14:48:40 -0800 (PST) Date: Wed, 10 Nov 2010 17:48:40 -0500 Message-ID: From: Phillip Hallam-Baker To: saag@ietf.org Content-Type: multipart/alternative; boundary=0016e6434ae8a2ea7e0494baa8c0 X-Mailman-Approved-At: Mon, 15 Nov 2010 07:28:51 -0800 Subject: [saag] KEYPROV WG Summary X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 22:48:18 -0000 --0016e6434ae8a2ea7e0494baa8c0 Content-Type: text/plain; charset=ISO-8859-1 KEYPROV Working Group Summary All current WG documents are either published as RFCs or in the RFC editor queue. -- Website: http://hallambaker.com/ --0016e6434ae8a2ea7e0494baa8c0 Content-Type: text/html; charset=ISO-8859-1
KEYPROV Working Group Summary

All current WG documents are either published as RFCs or in the RFC editor queue.



--
Website: http://hallambaker.com/

--0016e6434ae8a2ea7e0494baa8c0-- From hallam@gmail.com Thu Nov 11 18:12:29 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C2C028C14B for ; Thu, 11 Nov 2010 18:12:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lz-sh6tKc17H for ; Thu, 11 Nov 2010 18:12:27 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 8F6D828C10B for ; Thu, 11 Nov 2010 18:12:27 -0800 (PST) Received: by gyh20 with SMTP id 20so1487978gyh.31 for ; Thu, 11 Nov 2010 18:12:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=s0dsn++r53m7oUI37414e22NZSznpqWBh/PSJRzQMYc=; b=kq+wCc9gGEfeRRq6vZfv425tNlMQkSyDZAyLaYLTCslgNA5lKEhsh6cli1yHtuNjFi JicKIu3yKDDDkNfZ3OrM8twMOiSnD7+6eaVQWftWp9eMnprIaET0AmSw7JBNCRnjiSUS k1DqIRQf+GVSorxd6ZSTAtmiLik+kaAnWjVOg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=hemzRVzgPEQbUMBggtjFcgyXWqIujxptWgZQlin0dLPms8/zznJnQEfezqFH56fIkF DiMwGrmUbo9FCqJGzhqY8KVtZIGP3R9VoIAwlB8N1Pg8e2Sue1KOKJiKheObm0xW8s46 duTHtbAbaN8tYtLTxmrtCXWBNgaVw0y45X84c= MIME-Version: 1.0 Received: by 10.100.138.16 with SMTP id l16mr1052426and.0.1289527978021; Thu, 11 Nov 2010 18:12:58 -0800 (PST) Received: by 10.100.41.14 with HTTP; Thu, 11 Nov 2010 18:12:57 -0800 (PST) In-Reply-To: <8BE1E30A-CBC4-4370-87BB-83B6CE1B6B88@arsc.edu> References: <942D89A1-69D9-44E4-8FA8-6A28ABC5EC5F@arsc.edu> <4CDC807A.1090801@bbn.com> <8BE1E30A-CBC4-4370-87BB-83B6CE1B6B88@arsc.edu> Date: Thu, 11 Nov 2010 21:12:57 -0500 Message-ID: From: Phillip Hallam-Baker To: Melinda Shore Content-Type: multipart/alternative; boundary=0016e6434ae80ed7ee0494d1a100 X-Mailman-Approved-At: Mon, 15 Nov 2010 07:28:51 -0800 Cc: saag@ietf.org Subject: Re: [saag] Scoping the HARD problem X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 02:12:29 -0000 --0016e6434ae80ed7ee0494d1a100 Content-Type: text/plain; charset=ISO-8859-1 I think it depends on the level of assurance you require here as to which approach approaches are going to give an acceptable cost/benefit tradeoff. There is an option in TLS that allows a client to tell the server which domain it is attempting to connect to. So one principled approach to this problem would be to say that the client presents the domain name that it used at the start of the resolution chain. For example, client attempts to connect for alice@example.com _service.example.com SRV 1 1 443 host.outsource.com Client presents example.com as the domain to host.outsource.com. This means that there is an end-to-end security context that is independent of the DNS redirects. So DNSSEC is not required. I would be comfortable with this approach presenting EV type chrome to the user if the EE cert was EV. The user is clearly being serviced by Example Corp that owns example.com. One disadvantage that people might see in this is that outsource.com has a cert to pretend to be example.com. But that does not bother me much for an application that does not offer non-repudiation. The other approach would be to allow the client to present the cert for host.outsource.com. The question here is what are you going to be telling the user? If the application is OK sending the messages plaintext, and the user is not going to be told that the connection is 'secure' then the criteria for accepting a certificate can be negligible. A TLS session with a completely bogus certificate is still more secure than a plaintext session. At least if you are using Mallet's cert, only mallet can attack you. In an Internet where 99% of traffic is not secure, the threshold for turning on cryptography should be really low. The question is where the threshold should be for giving a padlock icon. And that is much harder. I don't think that we should be giving the padlock icon interface for DV certs used in Web browsers. Checking a domain name is not a sufficient degree of validation for accepting credit cards. What should be the criteria for XMPP? I don't know. If you want to tell the user that the connection is 'secure' then you probably want to have some sort of authentication of the referral. And then you get into the question of how strong you need that binding to be. A DNSSEC signature on an SRV record produces a strong cryptographic basis for a referral. But it is only as strong as the signing key. The ICANN chain can only give us what we expect from DV security at best. But imagine that we have an EV cert for the DNSSSEC KSK at example.com. What is the strength of the resulting chain? Omitting the KSK/ZSK thing we have: example.com DNSKEY is signed by CA-EV SRV -> host.outsource.com is signed by example.com DNSKEY host.outsource.com is signed by CA-? Even if CA-? is an EV CA there are two different administrative zones here and we don't know that they are necessarily in sync. On Thu, Nov 11, 2010 at 7:18 PM, Melinda Shore wrote: > On Nov 11, 2010, at 2:47 PM, Richard L. Barnes wrote: > > The presentation in SAAG was an attempt to generalize out from a > conversation that started in the XMPP community, which has SRV-based > outsourcing as a particular pain point. But I think the idea of presenting > to the broader community was to see if there was interest in a more general > solution, or even if that's something that people thought might be feasible. > > I've been interested in the more general problem from a > somewhat different perspective: Vendor A sends you off to > someone who appears to be Payment Agency B - how do you > know that they're authorized to collect funds on behalf of > Vendor A? > > Melinda > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > -- Website: http://hallambaker.com/ --0016e6434ae80ed7ee0494d1a100 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think it depends on the level of assurance you require here as to which a= pproach approaches are going to give an acceptable cost/benefit tradeoff.

There is an option in TLS that allows a cl= ient to tell the server which domain it is attempting to connect to. So one= principled approach to this problem would be to say that the client presen= ts the domain name that it used at the start of the resolution chain.

For example, client attempts to connect for alice@example.com

_<= a href=3D"http://service.example.com">service.example.com =A0SRV 1 1 44= 3 host.outsource.com

Client presents example.= com as the domain to host.outsour= ce.com. This means that there is an end-to-end security context that is= independent of the DNS redirects. So DNSSEC is not required.

I would be comfortable with this approach presenting EV= type chrome to the user if the EE cert was EV. The user is clearly being s= erviced by Example Corp that owns example.co= m.=A0

One disadvantage that people might see in this is that outsource.com has a cert to pretend to be example.com. But that does not bother me much f= or an application that does not offer non-repudiation.

=A0
The other approach would be to allow the = client to present the cert for host.o= utsource.com.

The question here is what are yo= u going to be telling the user?

If the application is OK sending the messages plaintext= , and the user is not going to be told that the connection is 'secure&#= 39; then the criteria for accepting a certificate can be negligible. A TLS = session with a completely bogus certificate is still more secure than a pla= intext session. At least if you are using Mallet's cert, only mallet ca= n attack you.

In an Internet where 99% of traffic is not secure, the = threshold for turning on cryptography should be really low. The question is= where the threshold should be for giving a padlock icon. And that is much = harder. I don't think that we should be giving the padlock icon interfa= ce for DV certs used in Web browsers. Checking a domain name is not a suffi= cient degree of validation for accepting credit cards.=A0

What should be the criteria for XMPP? I don't know.=

If you want to tell the user that the connection = is 'secure' then you probably want to have some sort of authenticat= ion of the referral. And then you get into the question of how strong you n= eed that binding to be.

A DNSSEC signature on an SRV record produces a strong c= ryptographic basis for a referral. But it is only as strong as the signing = key.

The ICANN chain can only give us what we expe= ct from DV security at best. But imagine that we have an EV cert for the DN= SSSEC KSK at example.com. What is the st= rength of the resulting chain?

Omitting the KSK/ZSK thing we have:

example.com DNSKEY =A0is signed by= CA-EV
SRV -> host.outso= urce.com =A0is signed by example.com= DNSKEY
host.outsource.com is signed= by CA-?


Even if CA-? is an EV CA t= here are two different administrative zones here and we don't know that= they are necessarily in sync.


On Thu, Nov 1= 1, 2010 at 7:18 PM, Melinda Shore <shore@arsc.edu> wrote:
On Nov 11, 2010, at 2:47 PM, Richard L. Barnes wrote:
> The presentation in SAAG was an attempt to generalize out from a conve= rsation that started in the XMPP community, which has SRV-based outsourcing= as a particular pain point. =A0But I think the idea of presenting to the b= roader community was to see if there was interest in a more general solutio= n, or even if that's something that people thought might be feasible.
I've been interested in the more general problem from a
somewhat different perspective: Vendor A sends you off to
someone who appears to be Payment Agency B - how do you
know that they're authorized to collect funds on behalf of
Vendor A?

Melinda

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



--
Website: http://hallambaker.com/

--0016e6434ae80ed7ee0494d1a100-- From paul.hoffman@vpnc.org Tue Nov 16 08:12:16 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A55A3A6D16 for ; Tue, 16 Nov 2010 08:12:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.936 X-Spam-Level: X-Spam-Status: No, score=-99.936 tagged_above=-999 required=5 tests=[AWL=-0.490, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUv2-eW2wPNA for ; Tue, 16 Nov 2010 08:12:15 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 5D46C3A6CCA for ; Tue, 16 Nov 2010 08:12:15 -0800 (PST) Received: from [75.101.18.87] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id oAGGCvCi039811 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 16 Nov 2010 09:12:58 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Tue, 16 Nov 2010 08:12:56 -0800 To: saag@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [saag] How to reference ECDSA? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 16:12:16 -0000 Greetings again. When a draft references ECDSA, there are three choices: - FIPS 186-3 - X9.62 - SECG SEC 1 What do people think are the relative advantages and disadvantages of each? --Paul Hoffman, Director --VPN Consortium From dharkins@lounge.org Tue Nov 16 11:14:26 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE77D3A6E19 for ; Tue, 16 Nov 2010 11:14:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KuN4D3liHf6z for ; Tue, 16 Nov 2010 11:14:26 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 63A4B3A6BC6 for ; Tue, 16 Nov 2010 11:14:26 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 7F26AA888008; Tue, 16 Nov 2010 11:15:10 -0800 (PST) Received: from 216.31.249.246 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 16 Nov 2010 11:15:10 -0800 (PST) Message-ID: <6fda2372ac865e63f79f2b6c0f1711bb.squirrel@www.trepanning.net> In-Reply-To: References: Date: Tue, 16 Nov 2010 11:15:10 -0800 (PST) From: "Dan Harkins" To: "Paul Hoffman" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: saag@ietf.org Subject: Re: [saag] How to reference ECDSA? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 19:14:27 -0000 On Tue, November 16, 2010 8:12 am, Paul Hoffman wrote: > Greetings again. When a draft references ECDSA, there are three choices: > - FIPS 186-3 > - X9.62 > - SECG SEC 1 > What do people think are the relative advantages and disadvantages of > each? Implementations written according to one or the other are all inter- operable so in that sense it doesn't matter but you have to purchase X9.62 so that's a big disadvantage in my opinion. Dan. From jon@callas.org Tue Nov 16 11:59:06 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59B733A6DA7 for ; Tue, 16 Nov 2010 11:59:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZvGRM0G2gRU for ; Tue, 16 Nov 2010 11:59:05 -0800 (PST) Received: from merrymeet.com (merrymeet.com [66.93.68.160]) by core3.amsl.com (Postfix) with ESMTP id 8253F3A6C89 for ; Tue, 16 Nov 2010 11:59:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by merrymeet.com (Postfix) with ESMTP id 184542E119; Tue, 16 Nov 2010 12:00:57 -0800 (PST) Received: from merrymeet.com ([127.0.0.1]) by localhost (host.domain.tld [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 70185-09; Tue, 16 Nov 2010 12:00:47 -0800 (PST) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTPA id 3C9532E0D7; Tue, 16 Nov 2010 12:00:47 -0800 (PST) Received: from ba0301b-dhcp195.apple.com ([17.193.15.195]) by keys.merrymeet.com (PGP Universal service); Tue, 16 Nov 2010 11:55:31 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Tue, 16 Nov 2010 11:55:31 -0800 Mime-Version: 1.0 (Apple Message framework v1082) From: Jon Callas In-Reply-To: Date: Tue, 16 Nov 2010 11:59:36 -0800 Message-Id: <24CF5802-5F91-48C5-B0F8-65429AA12D92@callas.org> References: To: Paul Hoffman X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Maia Mailguard Cc: saag@ietf.org Subject: Re: [saag] How to reference ECDSA? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 19:59:06 -0000 On Nov 16, 2010, at 8:12 AM, Paul Hoffman wrote: > Greetings again. When a draft references ECDSA, there are three = choices: > - FIPS 186-3 > - X9.62 > - SECG SEC 1 > What do people think are the relative advantages and disadvantages of = each? The disadvantage of X9.62 is that the more important it is that someone = read the actual document, the less likely they will. There's a distinct = unwillingness for people to pay for standards documents. That means that = once someone learns that X9.62 is the same thing as FIPS 186-3, they'll = go to that one because they can pull it up in their web browser. The disadvantage of FIPS is that it's from the USG, and there are people = with histamine reactions to that, as well. The disadvantage of SECG is most people haven't heard of them, so you = won't get someone's attention the way that you would with either ANSI or = NIST. Also, you run into the whole EC patent morass, and will have to = fight the inevitable patent-fear problem. The SECG statement on patents = will do everything to intensify that fear. I would say you're best off going with FIPS 186-3. Jon From eronenp@gmail.com Wed Nov 17 08:50:49 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B64743A692A for ; Wed, 17 Nov 2010 08:50:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id di3QXnaEKTZy for ; Wed, 17 Nov 2010 08:50:48 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 7707A3A6908 for ; Wed, 17 Nov 2010 08:50:48 -0800 (PST) Received: by wyb29 with SMTP id 29so2124473wyb.31 for ; Wed, 17 Nov 2010 08:51:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=iAV0hfyCBLaZwvZSl25qQKpYW7emlMLjf+kVncJAdjY=; b=MIEtTuZSzdk82IRs8EbXGMmbTCCzrmRhHYV14wHkxCYlWDYFxQvD0PO1oq8coe9149 tdH1ub1j3HBrvk9DDSyisZfRUh/s/MpKiva55xAV5y4l6I7tEMqtvFvjurBw+1r4/LzS k5yPzlnJ0/LR8+EVGfs4Hwuv+EkPPnxHEvdk4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=cJIfvE4PAkvXSft1q2u4PhMWs6aVxuOWleOYlTm1s5+sXRzhzn0YGWmQ8aHIsA++el n3EiYHQc0Pp6gSt3AkZy5y+gt4BVe2Drh8Lm/yFozq+avbGvNbO+UEf4+FjuewrF2r46 KY/UB+GHwO0zWoIPFwbWr9uO1Wp0/a2/vOg9E= MIME-Version: 1.0 Received: by 10.227.133.2 with SMTP id d2mr9629703wbt.92.1290012692641; Wed, 17 Nov 2010 08:51:32 -0800 (PST) Sender: eronenp@gmail.com Received: by 10.227.30.98 with HTTP; Wed, 17 Nov 2010 08:51:32 -0800 (PST) In-Reply-To: References: Date: Wed, 17 Nov 2010 18:51:32 +0200 X-Google-Sender-Auth: rIsRtpL-Smjrnz_6CU0A5dMgW8k Message-ID: From: Pasi Eronen To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 Cc: saag@ietf.org Subject: Re: [saag] How to reference ECDSA? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2010 16:50:49 -0000 I don't think one can actually implement ECDSA based on only FIPS 186-3. For e.g. ECDSA signature verification, FIPS 186-3 Section 6.4 simply says "ECDSA digital signature shall be verified as specified in ANS X9.62". SECG SEC 1 looks like it has all the details, but the details are not exactly the same as in X9.62. For example, the point-to-octet-string conversion are not 100% compatible, as was noted here: http://www.ietf.org/mail-archive/web/ipsec/current/msg02510.html I agree with Dan and Jon that having to pay for X9.62 is a big disadvantage, though. Best regards, Pasi On Tue, Nov 16, 2010 at 18:12, Paul Hoffman wrote: > Greetings again. When a draft references ECDSA, there are three choices: > - FIPS 186-3 > - X9.62 > - SECG SEC 1 > What do people think are the relative advantages and disadvantages of each? > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From dbrown@certicom.com Wed Nov 17 09:50:20 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CA943A6953 for ; Wed, 17 Nov 2010 09:50:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFVdep-SXHYy for ; Wed, 17 Nov 2010 09:50:18 -0800 (PST) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id 9B1643A6971 for ; Wed, 17 Nov 2010 09:50:06 -0800 (PST) X-AuditID: 0a666446-b7b5bae0000034fd-0c-4ce415fbf942 Received: from XHT101CNC.rim.net ( [10.65.12.214]) by mhs04ykf.rim.net (RIM Mail) with SMTP id E2.63.13565.BF514EC4; Wed, 17 Nov 2010 12:50:51 -0500 (EST) Received: from XCH117CNC.rim.net ([fe80::b8df:541f:9d85:9909]) by XHT101CNC.rim.net ([fe80::cd26:db3b:81e6:46eb%11]) with mapi; Wed, 17 Nov 2010 12:50:52 -0500 From: Dan Brown To: "'saag@ietf.org'" Date: Wed, 17 Nov 2010 12:50:51 -0500 Thread-Topic: Re: [saag] How to reference ECDSA? Thread-Index: AcuGf/lol5A2WDb2Q0uaJB6Zhm4N/A== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D8DB0F308C10F349BE8FADE31B9A809F052E4159XCH117CNCrimnet_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAABAAAAZEWsEA0FrD1UhaxFmU= Subject: Re: [saag] How to reference ECDSA? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2010 17:50:20 -0000 --_000_D8DB0F308C10F349BE8FADE31B9A809F052E4159XCH117CNCrimnet_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable > Greetings again. When a draft references ECDSA, there are three choices: > - FIPS 186-3 > - X9.62 > - SECG SEC 1 > What do people think are the relative advantages and disadvantages of each= ? > > --Paul Hoffman, Director > --VPN Consortium FIPS 186-3 does not fully specify ECDSA signature generation and verificatio= n, but rather refers to ANS X9.62. So, FIPS 186-3 is less direct than ANS X= 9.62, which is a possible disadvantage. Not only do X9.62 & SEC 1 fully specify ECDSA signature generation and verif= ication, but they also specify encoding of ECDSA signatures in ASN.1, which= is used in other IETF groups such as PKIX. Such a specified encoding may b= e an advantage. By contrast, FIPS 186-3 does not specify an encoding for ECDSA. But it does= have a means to represent integers as bit string (Section C.2) which could= be used to build a bit string representation of an ECDSA signature if uniqu= e parsing is ensured. An alternative is IEEE 1363, which specifies ECDSA (under the name ECSSA wit= h primitives ECSP-DSA and ECVP-DSA), and, like FIPS 196-3, has integer to bi= t conversions, which could be used to build representations of ECDSA signatu= res. Some other possible minor advantages of the SEC 1 specification are that it= is free, it is a hyperlinked PDF, it currently provides more extensive and= up-to-date security considerations (than the alternative standards), and it= is focused on ECC (some users of ECDSA are likely to want to other ECC algo= rithms). Best regards, Dan ---------------------------------------------------------------------=0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. --_000_D8DB0F308C10F349BE8FADE31B9A809F052E4159XCH117CNCrimnet_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

> Greetings again. When a draft references ECDSA, there are three choices:

> - FIPS 186-3

> - X9.62

> - SECG SEC 1

> What do people think are the relative advantages and disadvantages of each?<= o:p>

>

> --Paul Hoffman, Director

> --VPN Consortium

 

FIPS 186-3 does not fully specify ECDSA signature generation and verification, bu= t rather refers to ANS X9.62.  So, FIPS 186-3 is less direct than ANS X9.= 62, which is a possible disadvantage. 

 

Not only do X9.62 & SEC 1 fully specify ECDSA signature generation and verification, but they also specify encoding of ECDSA signatures in ASN.1, w= hich is used in other IETF groups such as PKIX.  Such a specified encoding m= ay be an advantage. 

 

By contrast, FIPS 186-3 does not specify an encoding for ECDSA.  But it do= es have a means to represent integers as bit string (Section C.2) which could be use= d to build a bit string representation of an ECDSA signature if unique parsing= is ensured.

 

An alternative is IEEE 1363, which specifies ECDSA (under the name ECSSA with p= rimitives ECSP-DSA and ECVP-DSA), and, like FIPS 196-3, has integer to bit conversions= , which could be used to build representations of ECDSA signatures.=

 

Some other possible minor advantages of the SEC 1 specification are that it is fr= ee, it is a hyperlinked PDF, it currently provides more extensive and up-to-date security considerations (than the alternative standards), and it is focused= on ECC (some users of ECDSA are likely to want to other ECC algorithms).

 

Best regards,

 

        Dan

 

---------------------------------------------------------------------
= =0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. --_000_D8DB0F308C10F349BE8FADE31B9A809F052E4159XCH117CNCrimnet_-- From paul.hoffman@vpnc.org Wed Nov 17 10:20:53 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A956B3A695F for ; Wed, 17 Nov 2010 10:20:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.984 X-Spam-Level: X-Spam-Status: No, score=-99.984 tagged_above=-999 required=5 tests=[AWL=-0.538, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94daiZECeRUk for ; Wed, 17 Nov 2010 10:20:51 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 3791C3A696C for ; Wed, 17 Nov 2010 10:20:50 -0800 (PST) Received: from [75.101.18.87] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id oAHILGrY011982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Nov 2010 11:21:17 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 17 Nov 2010 10:21:14 -0800 To: Dan Brown , "'saag@ietf.org'" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [saag] How to reference ECDSA? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2010 18:20:53 -0000 At 12:50 PM -0500 11/17/10, Dan Brown wrote: >Some other possible minor advantages of the SEC 1 specification are that it is free, it is a hyperlinked PDF, it currently provides more extensive and up-to-date security considerations (than the alternative standards), and it is focused on ECC (some users of ECDSA are likely to want to other ECC algorithms). These do sound like good advantages. Could you respond to Pasi's note about incompatibilities between SEGG and X9.62? --Paul Hoffman, Director --VPN Consortium From dbrown@certicom.com Thu Nov 18 08:47:13 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 056AF28C0F0 for ; Thu, 18 Nov 2010 08:47:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QtAfwmAFaAh4 for ; Thu, 18 Nov 2010 08:47:12 -0800 (PST) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id 7170628C0F9 for ; Thu, 18 Nov 2010 08:47:11 -0800 (PST) X-AuditID: 0a666446-b7b74ae00000630d-08-4ce558a93c45 Received: from XHT109CNC.rim.net ( [10.65.12.218]) by mhs04ykf.rim.net (RIM Mail) with SMTP id 1B.22.25357.9A855EC4; Thu, 18 Nov 2010 11:47:37 -0500 (EST) Received: from XCH117CNC.rim.net ([fe80::b8df:541f:9d85:9909]) by XHT109CNC.rim.net ([fe80::8412:4d9e:eb55:2c7b%11]) with mapi; Thu, 18 Nov 2010 11:47:36 -0500 From: Dan Brown To: "'pe@iki.fi'" , "'paul.hoffman@vpnc.org'" Date: Thu, 18 Nov 2010 11:47:35 -0500 Thread-Topic: [saag] How to reference ECDSA? Thread-Index: AcuGd7Ql8pvVr3iNS8C7KOJUFmxEYwAyJkie Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAwAAAZEWsPVSFrEWZQ== Cc: "'saag@ietf.org'" Subject: Re: [saag] How to reference ECDSA? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2010 16:47:13 -0000 Regarding hybrid representation of EC points. More generally, a goal of SECG has been to reduce the number of options, com= pared to, say, ANSI or ISO or IEEE, because this goal may promote interop. = So, a SEC1 version of algorithm XYZ should comply with other specifications= of algorithm XYZ. In the case of octet string reps of EC points, this goal is met, when compar= ed to ANSI or IEEE. ECDSA signatures do not depend on point to octet string reps, but ECC public= keys generally do. Certified ECC key formats are already covered in PKIX, but certainly other I= ETF may still need their own formats, such as for ephemeral keys in ECDH. Anyway, the ANSI hybrid format octet string for an EC point differs only by= some bits from the SEC1 formats. With some guidance such bits could be ign= ored by generous receiving implementations that do not understand them. Indeed, SEC1 Section 2.3.3 could probably be amended to accept headers 06 an= d 07 the same way as header 04. Best regards, Dan ----- Original Message ----- From: Pasi Eronen [mailto:pe@iki.fi] Sent: Wednesday, November 17, 2010 11:51 AM=0A= To: Paul Hoffman Cc: saag@ietf.org Subject: Re: [saag] How to reference ECDSA? I don't think one can actually implement ECDSA based on only FIPS 186-3. For e.g. ECDSA signature verification, FIPS 186-3 Section 6.4 simply says "ECDSA digital signature shall be verified as specified in ANS X9.62". SECG SEC 1 looks like it has all the details, but the details are not exactl= y the same as in X9.62. For example, the point-to-octet-string conversion are not 100% compatible, as was noted here: http://www.ietf.org/mail-archive/web/ipsec/current/msg02510.html I agree with Dan and Jon that having to pay for X9.62 is a big disadvantage, though. Best regards, Pasi On Tue, Nov 16, 2010 at 18:12, Paul Hoffman wrote: > Greetings again. When a draft references ECDSA, there are three choices: > - FIPS 186-3 > - X9.62 > - SECG SEC 1 > What do people think are the relative advantages and disadvantages of each= ? > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag ---------------------------------------------------------------------=0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From philip.eardley@bt.com Fri Nov 19 01:40:02 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2FCF3A67C2; Fri, 19 Nov 2010 01:40:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.945 X-Spam-Level: X-Spam-Status: No, score=-101.945 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUAOwNq4btef; Fri, 19 Nov 2010 01:39:59 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.COM [62.239.224.234]) by core3.amsl.com (Postfix) with ESMTP id E82C83A67D3; Fri, 19 Nov 2010 01:39:58 -0800 (PST) Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 19 Nov 2010 09:40:47 +0000 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.60]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Fri, 19 Nov 2010 09:40:47 +0000 From: To: , Date: Fri, 19 Nov 2010 09:40:46 +0000 Thread-Topic: Multipath TCP Interim meeting on Security for MPTCP Thread-Index: AcuHzddKvBrXTYN7Rpeq8rp4DpFubw== Message-ID: <4C22FF8FA5626046BF68899C06A0C9F71135CE4946@EMV67-UKRD.domain1.systemhost.net> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_4C22FF8FA5626046BF68899C06A0C9F71135CE4946EMV67UKRDdoma_" MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 19 Nov 2010 10:31:32 -0800 Subject: [saag] Multipath TCP Interim meeting on Security for MPTCP X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 09:40:02 -0000 --_000_4C22FF8FA5626046BF68899C06A0C9F71135CE4946EMV67UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi We would like to have an interim Multipath TCP meeting (by audio) to discus= s security. There has been quite a bit of discussion recently on the list a= nd at the Beijing meeting, and we'd like to try to converge on a solution. We're cc-ing SAAG, as SAAG kindly spent some of their Beijing meeting time = discussing MPTCP, and we'd very much like to continue getting your input an= d advice. Please indicate your availability at http://www.doodle.com/44yhussdesgn6a33 Nov 29 /30, Dec 1/2/13/14/15 We have assumed a start time of 4pm GMT (since this proved the most popular= time for a previous interim audio) Thanks Best wishes, Phil & Yoshifumi --_000_4C22FF8FA5626046BF68899C06A0C9F71135CE4946EMV67UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi

 

We would like to have an interim Multipath TCP meeting= (by audio) to discuss security. There has been quite a bit of discussion recent= ly on the list and at the Beijing meeting, and we’d like to try to conve= rge on a solution.

 

We’re cc-ing SAAG, as SAAG kindly spent some of = their Beijing meeting time discussing MPTCP, and we’d very much like to continue getting your input and advice.

 

Please indicate your availability at http://www.doodle.com/44yhu= ssdesgn6a33

Nov 29 /30, Dec  1/2/13/14/15

 

We have assumed a start time of 4pm GMT (since this pr= oved the most popular time for a previous interim audio)

 

Thanks

Best wishes,

Phil & Yoshifumi

--_000_4C22FF8FA5626046BF68899C06A0C9F71135CE4946EMV67UKRDdoma_-- From john@jlc.net Fri Nov 19 06:28:10 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2795E3A67E1; Fri, 19 Nov 2010 06:28:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.482 X-Spam-Level: X-Spam-Status: No, score=-106.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPku18iA5Ywt; Fri, 19 Nov 2010 06:28:09 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by core3.amsl.com (Postfix) with ESMTP id 16E373A67DB; Fri, 19 Nov 2010 06:28:09 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id C28C233C57; Fri, 19 Nov 2010 09:28:58 -0500 (EST) Date: Fri, 19 Nov 2010 09:28:58 -0500 From: John Leslie To: philip.eardley@bt.com Message-ID: <20101119142858.GB91157@verdi> References: <4C22FF8FA5626046BF68899C06A0C9F71135CE4946@EMV67-UKRD.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C22FF8FA5626046BF68899C06A0C9F71135CE4946@EMV67-UKRD.domain1.systemhost.net> User-Agent: Mutt/1.4.1i X-Mailman-Approved-At: Fri, 19 Nov 2010 10:31:33 -0800 Cc: multipathtcp@ietf.org, saag@ietf.org Subject: Re: [saag] [multipathtcp] Multipath TCP Interim meeting on Security for MPTCP X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 14:28:10 -0000 philip.eardley@bt.com wrote: > > We would like to have an interim Multipath TCP meeting (by audio) > to discuss security... > > Please indicate your availability at http://www.doodle.com/44yhussdesgn6a33 > Nov 29 /30, Dec 1/2/13/14/15 Nov 29 is a conflict with PFLDNeT (and ICCRG), probably worth avoiding (PFLDNeT covers Transport topics). http://pfld.net/2010/ (PFLD expands to Protocols for Future, Large-Scale & Diverse Network Transports.) -- John Leslie From philip.eardley@bt.com Tue Nov 23 02:30:55 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD2E13A68B3; Tue, 23 Nov 2010 02:30:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.97 X-Spam-Level: X-Spam-Status: No, score=-101.97 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1n3StT0ZxTE; Tue, 23 Nov 2010 02:30:51 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.COM [62.239.224.235]) by core3.amsl.com (Postfix) with ESMTP id 73C473A686C; Tue, 23 Nov 2010 02:30:51 -0800 (PST) Received: from EVMHT61-UKRD.domain1.systemhost.net (10.36.3.127) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 23 Nov 2010 10:31:48 +0000 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.242]) by EVMHT61-UKRD.domain1.systemhost.net ([10.36.3.127]) with mapi; Tue, 23 Nov 2010 10:31:48 +0000 From: To: , Date: Tue, 23 Nov 2010 10:31:47 +0000 Thread-Topic: Wed Dec 1st, 4pm GMT: Multipath TCP Interim meeting on Security for MPTCP Thread-Index: AcuHzddKvBrXTYN7Rpeq8rp4DpFubwDK3vww Message-ID: <9510D26531EF184D9017DF24659BB87F324E3F92E9@EMV65-UKRD.domain1.systemhost.net> References: <4C22FF8FA5626046BF68899C06A0C9F71135CE4946@EMV67-UKRD.domain1.systemhost.net> In-Reply-To: <4C22FF8FA5626046BF68899C06A0C9F71135CE4946@EMV67-UKRD.domain1.systemhost.net> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_9510D26531EF184D9017DF24659BB87F324E3F92E9EMV65UKRDdoma_" MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 23 Nov 2010 08:13:49 -0800 Subject: [saag] Wed Dec 1st, 4pm GMT: Multipath TCP Interim meeting on Security for MPTCP X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 10:30:55 -0000 --_000_9510D26531EF184D9017DF24659BB87F324E3F92E9EMV65UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The best date seems to be Wed Dec 1st. Start 4pm GMT. Max 1.5 hours. Please send agenda requests as soon as possible. We'll organise audio, webex etc Thanks Phil & Yoshifumi From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] = On Behalf Of philip.eardley@bt.com Sent: 19 November 2010 09:41 To: multipathtcp@ietf.org; saag@ietf.org Subject: [multipathtcp] Multipath TCP Interim meeting on Security for MPTCP Hi We would like to have an interim Multipath TCP meeting (by audio) to discus= s security. There has been quite a bit of discussion recently on the list a= nd at the Beijing meeting, and we'd like to try to converge on a solution. We're cc-ing SAAG, as SAAG kindly spent some of their Beijing meeting time = discussing MPTCP, and we'd very much like to continue getting your input an= d advice. Please indicate your availability at http://www.doodle.com/44yhussdesgn6a33 Nov 29 /30, Dec 1/2/13/14/15 We have assumed a start time of 4pm GMT (since this proved the most popular= time for a previous interim audio) Thanks Best wishes, Phil & Yoshifumi --_000_9510D26531EF184D9017DF24659BB87F324E3F92E9EMV65UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The best date seems to b= e Wed Dec 1st. Start 4pm GMT. Max 1.5 hours.

 =

Please send agenda reque= sts as soon as possible.

 =

We’ll organise aud= io, webex etc

 =

Thanks=

Phil & Yoshifumi

 =

From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] On Behalf Of philip.eardley@b= t.com
Sent: 19 November 2010 09:41
To: multipathtcp@ietf.org; saag@ietf.org
Subject: [multipathtcp] Multipath TCP Interim meeting on Security fo= r MPTCP

 

Hi

 

We would like to have an interim Multipath TCP meeting= (by audio) to discuss security. There has been quite a bit of discussion recent= ly on the list and at the Beijing meeting, and we’d like to try to conve= rge on a solution.

 

We’re cc-ing SAAG, as SAAG kindly spent some of = their Beijing meeting time discussing MPTCP, and we’d very much like to con= tinue getting your input and advice.

 

Please indicate your availability at http://www.doodle.com/44yhu= ssdesgn6a33

Nov 29 /30, Dec  1/2/13/14/15

 

We have assumed a start time of 4pm GMT (since this pr= oved the most popular time for a previous interim audio)

 

Thanks

Best wishes,

Phil & Yoshifumi

--_000_9510D26531EF184D9017DF24659BB87F324E3F92E9EMV65UKRDdoma_-- From philip.eardley@bt.com Wed Nov 24 01:55:17 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44E7C3A681E; Wed, 24 Nov 2010 01:55:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.995 X-Spam-Level: X-Spam-Status: No, score=-101.995 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x279Q-FTGEHQ; Wed, 24 Nov 2010 01:55:12 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.COM [62.239.224.234]) by core3.amsl.com (Postfix) with ESMTP id 5A41928C0F7; Wed, 24 Nov 2010 01:55:12 -0800 (PST) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 24 Nov 2010 09:56:11 +0000 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.242]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Wed, 24 Nov 2010 09:56:10 +0000 From: To: , Date: Wed, 24 Nov 2010 09:56:09 +0000 Thread-Topic: CHANGE OF DATE: Tuesday Dec 14th, 4pm GMT: Multipath TCP Interim meeting on Security for MPTCP Thread-Index: AcuHzddKvBrXTYN7Rpeq8rp4DpFubwDK3vwwAC/99EA= Message-ID: <9510D26531EF184D9017DF24659BB87F324E505CAF@EMV65-UKRD.domain1.systemhost.net> References: <4C22FF8FA5626046BF68899C06A0C9F71135CE4946@EMV67-UKRD.domain1.systemhost.net> <9510D26531EF184D9017DF24659BB87F324E3F92E9@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F324E3F92E9@EMV65-UKRD.domain1.systemhost.net> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_9510D26531EF184D9017DF24659BB87F324E505CAFEMV65UKRDdoma_" MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 24 Nov 2010 08:16:22 -0800 Subject: [saag] CHANGE OF DATE: Tuesday Dec 14th, 4pm GMT: Multipath TCP Interim meeting on Security for MPTCP X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2010 09:55:17 -0000 --_000_9510D26531EF184D9017DF24659BB87F324E505CAFEMV65UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Apologies, we have to move the date (in order to give > 2 weeks notice) The revised date is Tues Dec 14th, 4pm GMT Best wishes Phil & Yoshifumi. http://trac.tools.ietf.org/wg/mptcp/trac/wiki/Interim_Dec_2010 we need to finalise the agenda at least 1 week before. Please send agenda r= equests. From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] = On Behalf Of philip.eardley@bt.com Sent: 23 November 2010 10:32 To: multipathtcp@ietf.org; saag@ietf.org Subject: [multipathtcp] Wed Dec 1st, 4pm GMT: Multipath TCP Interim meeting= on Security for MPTCP The best date seems to be Wed Dec 1st. Start 4pm GMT. Max 1.5 hours. Please send agenda requests as soon as possible. We'll organise audio, webex etc Thanks Phil & Yoshifumi From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] = On Behalf Of philip.eardley@bt.com Sent: 19 November 2010 09:41 To: multipathtcp@ietf.org; saag@ietf.org Subject: [multipathtcp] Multipath TCP Interim meeting on Security for MPTCP Hi We would like to have an interim Multipath TCP meeting (by audio) to discus= s security. There has been quite a bit of discussion recently on the list a= nd at the Beijing meeting, and we'd like to try to converge on a solution. We're cc-ing SAAG, as SAAG kindly spent some of their Beijing meeting time = discussing MPTCP, and we'd very much like to continue getting your input an= d advice. Please indicate your availability at http://www.doodle.com/44yhussdesgn6a33 Nov 29 /30, Dec 1/2/13/14/15 We have assumed a start time of 4pm GMT (since this proved the most popular= time for a previous interim audio) Thanks Best wishes, Phil & Yoshifumi --_000_9510D26531EF184D9017DF24659BB87F324E505CAFEMV65UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Apologies, we have to mo= ve the date (in order to give > 2 weeks notice)

 =

The revised date is Tues= Dec 14th, 4pm GMT

 =

Best wishes

Phil & Yoshifumi.

 =

htt= p://trac.tools.ietf.org/wg/mptcp/trac/wiki/Interim_Dec_2010

 =

we need to finalise the = agenda at least 1 week before. Please send agenda requests.

 =

From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] On Behalf Of philip.eardley@b= t.com
Sent: 23 November 2010 10:32
To: multipathtcp@ietf.org; saag@ietf.org
Subject: [multipathtcp] Wed Dec 1st, 4pm GMT: Multipath TCP Interim meeting on Security for MPTCP

 

The best date seems to b= e Wed Dec 1st. Start 4pm GMT. Max 1.5 hours.

 =

Please send agenda reque= sts as soon as possible.

 =

We’ll organise aud= io, webex etc

 =

Thanks=

Phil & Yoshifumi

 =

From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] On Behalf Of philip.eardley@b= t.com
Sent: 19 November 2010 09:41
To: multipathtcp@ietf.org; saag@ietf.org
Subject: [multipathtcp] Multipath TCP Interim meeting on Security fo= r MPTCP

 

Hi

 

We would like to have an interim Multipath TCP meeting= (by audio) to discuss security. There has been quite a bit of discussion recent= ly on the list and at the Beijing meeting, and we’d like to try to conve= rge on a solution.

 

We’re cc-ing SAAG, as SAAG kindly spent some of = their Beijing meeting time discussing MPTCP, and we’d very much like to continue getting your input and advice.

 

Please indicate your availability at http://www.doodle.com/44yhu= ssdesgn6a33

Nov 29 /30, Dec  1/2/13/14/15

 

We have assumed a start time of 4pm GMT (since this pr= oved the most popular time for a previous interim audio)

 

Thanks

Best wishes,

Phil & Yoshifumi

--_000_9510D26531EF184D9017DF24659BB87F324E505CAFEMV65UKRDdoma_-- From housley@vigilsec.com Thu Nov 25 08:03:22 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 162EE28C0F6 for ; Thu, 25 Nov 2010 08:03:22 -0800 (PST) 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=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AnwrjpQa8KuB for ; Thu, 25 Nov 2010 08:03:21 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id DF57A3A696D for ; Thu, 25 Nov 2010 08:03:20 -0800 (PST) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 99E9AF2407E for ; Thu, 25 Nov 2010 11:04:42 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id 6ctRkWwvFCHx for ; Thu, 25 Nov 2010 11:04:14 -0500 (EST) Received: from [184.49.154.133] (dhcp184-49-154-133.fvs.nyc.wayport.net [184.49.154.133]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 48AF3F24076 for ; Thu, 25 Nov 2010 11:04:36 -0500 (EST) Message-ID: <4CEE88FE.7010408@vigilsec.com> Date: Thu, 25 Nov 2010 11:04:14 -0500 From: Russ Housley User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: IETF SAAG X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [saag] Fwd: NSF Trustworthy Computing Program Announcements X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Nov 2010 16:03:22 -0000 I thought this would be of interest to this mail list ... Russ -------- Original Message -------- Subject: NSF Trustworthy Computing Program Announcements Date: Wed, 24 Nov 2010 17:18:33 -0500 From: Landwehr, Carl To: Landwehr, Carl You are receiving this message either because you have submitted a proposal to NSF's Trustworthy Computing Program or this e-mail address has been on the Cyber Trust or Trustworthy Computing e-mail lists. 1. The Trustworthy Computing program convened an invitational workshop on the Future of Trustworthy Computing in late October this year. A major purpose of the workshop was to create a publicly accessible record of the history and context of the Trustworthy Computing program, so that any researcher interested in preparing a research proposal could better understand the program and its relationship to other research programs, both at NSF and at other government agencies. The video content of the workshop is still being edited, but the slides presented are now all available on the conference website at: http://tc2010.cse.psu.edu/program.html If you plan to submit a proposal to the Trustworthy Computing program, I encourage you to review the proceedings of the workshop. Please check back for the video content; it should be posted soon. 2. Also, if you would like to continue receiving public announcements related to the Trustworthy Computing program, please subscribe to the new mailing list: trustworthy-computing-announce To subscribe, just send an e-mail from the address where you wish to receive messages to: join-trustworthy-computing-announce@lists.nsf.gov No subject or body is required. An e-mail confirmation will be requested automatically. Instructions to unsubscribe from the list will be included in each message sent to list members. I expect that no more than a dozen messages per year, and probably only two or three per year, will be sent to this list. 3. Other workshops convened by the Trustworthy Computing program in the past 18 months include: - Usable Verification: http://fm.csl.sri.com/UV10/ - Fundamental Research Challenges for Trustworthy Biometrics: http://moodle.clarkson.edu/course/view.php?id=1852 - Secure Programming Summit: http://www.gwu.edu/csl/sess.html (more information soon) - Workshop on Cyber Security Data for Experimentation (CSDE): http://www.gtisc.gatech.edu/nsf_workshop10 - Inco-Trust Workshop on International Collaboration in Security and Privacy: http://www.cs.rutgers.edu/~rebecca.wright/INCO-TRUST/program.html - Designing a Secure System Engineering Competition (DESSEC): report available soon - Security-Driven Architectures: report available soon 3. My apologies if you receive multiple copies of this announcement. Regards (and Happy Thanksgiving!) --Carl Carl Landwehr Director, Trustworthy Computing Program National Science Foundation From mcr@sandelman.ca Sat Nov 27 06:16:54 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C06E28C137 for ; Sat, 27 Nov 2010 06:16:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.459 X-Spam-Level: X-Spam-Status: No, score=0.459 tagged_above=-999 required=5 tests=[AWL=-0.187, BAYES_50=0.001, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KahpW5sS5aZo for ; Sat, 27 Nov 2010 06:16:52 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id C0AC428C134 for ; Sat, 27 Nov 2010 06:16:51 -0800 (PST) Received: from marajade.sandelman.ca (wlan202.sandelman.ca [209.87.252.202]) by relay.sandelman.ca (Postfix) with ESMTPS id 975AA3444C for ; Sat, 27 Nov 2010 09:23:35 -0500 (EST) Received: from marajade.sandelman.ca (marajade.sandelman.ca [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 3147F98B1D for ; Sat, 27 Nov 2010 09:17:56 -0500 (EST) From: Michael Richardson To: saag@ietf.org In-Reply-To: References: X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Sat, 27 Nov 2010 09:17:56 -0500 Message-ID: <26591.1290867476@marajade.sandelman.ca> Sender: mcr@sandelman.ca X-Mailman-Approved-At: Mon, 29 Nov 2010 05:45:27 -0800 Subject: [saag] Harald Welte's blog. A5/2 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Nov 2010 14:16:54 -0000 Bruce Schneier blogged about Harald Welte's research about A5/2's withdrawal: http://laforge.gnumonks.org/weblog/2010/11/12/ A brief history on the withdrawal of the A5/2 ciphering algorithm in GSM Recently, I wanted to investigate when and how A5/2 has been withdrawn from both GSM networks and GSM phones alike. Unfortunately there was no existing article discussing this history online, so I went through dozens of meeting reports and other documents that I could find online to recover what had happened. If you don't know what this is all about: It is about the A5/2 air-interface encryption algorithm that was used in certain GSM networks until about 2005-2007. A5/2 was specified as a security by obscurity algorithm behind closed doors in the late 1980ies. It was intentionally made weaker than it's (already weak) brother A5/1. The idea was to sell only equipment with A5/2 to the countries of the eastern block, while the less-weak A5/1 encryption was to be used by the western European countries. I know that I am preaching to the choir here -- but sometimes it's good when you talk to crytographic muggles to have real life examples of the downfalls. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From yoshifumi.nishida@gmail.com Mon Nov 29 23:07:47 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18AB23A6C6B; Mon, 29 Nov 2010 23:07:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.389 X-Spam-Level: X-Spam-Status: No, score=-101.389 tagged_above=-999 required=5 tests=[AWL=0.589, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id viuJkkATJ687; Mon, 29 Nov 2010 23:07:45 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 6921E3A6BFC; Mon, 29 Nov 2010 23:07:44 -0800 (PST) Received: by wwa36 with SMTP id 36so5587057wwa.13 for ; Mon, 29 Nov 2010 23:08:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=ZgKya2cz24XDMvIYPVukbjgNGuoSjSJbqbiB6jIOLF0=; b=dSf6MyhpihCJJmke7rb6f4b8cCWVh2QO7pAYATpQh6yGumWprGuelMeqI7XNW1GS9j mfDgHcgnzSMxFGuJ3feSUKkWo4meR/TzVUpOIynPd93zSauoVyeFaZ7j7krkMpzk+bbR CTzuA0u6G/A5gnwA7dqiBXPidfB2JzoteJP20= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=twlKUhXf+d35Kr3dghOBuxYVMgEAb2MaXok7xgLbmKNOiGaZB57yQ7fW2ESxz5k3+x VkMjGnygs9IbH2OJbth4sy1RMkjxC0908emII/9Eb+skph4Wjgclctbhd/aL78rBOw+z ZY5H/ICVchS5bRwjODBkndldj/7Idz/3E0B04= MIME-Version: 1.0 Received: by 10.216.35.74 with SMTP id t52mr51839wea.76.1291100933933; Mon, 29 Nov 2010 23:08:53 -0800 (PST) Sender: yoshifumi.nishida@gmail.com Received: by 10.216.170.199 with HTTP; Mon, 29 Nov 2010 23:08:53 -0800 (PST) Date: Mon, 29 Nov 2010 23:08:53 -0800 X-Google-Sender-Auth: kibX20fMfhA9Cguge-1lNN4W1jA Message-ID: From: Yoshifumi Nishida To: multipathtcp , saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Tue, 30 Nov 2010 12:02:50 -0800 Subject: [saag] instruction for joining MPTCP virtual interim meeting X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2010 07:07:48 -0000 Hello, Please take a look if you're interested in joining the mptcp interim meeting. -- Yoshifumi & Phil -------------------------------------------------------------------------- IETF Secretariat invites you to attend this online meeting. Topic: MPTCP Date: Tuesday, December 14, 2010 Time: 8:00 am, Pacific Standard Time (San Francisco, GMT-08:00) Meeting Number: 964 830 977 Meeting Password: (This meeting does not require a password.) ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://workgreen.webex.com/workgreen/j.php?ED=149135862&UID=1194293802&RT=MiM0 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: (This meeting does not require a password.) 4. Click "Join". To view in other time zones or languages, please click the link: https://workgreen.webex.com/workgreen/j.php?ED=149135862&UID=1194293802&ORT=MiM0 ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting, or call the number below and enter the access code. Call-in toll number (US/Canada): 1-408-792-6300 Global call-in numbers: https://workgreen.webex.com/workgreen/globalcallin.php?serviceType=MC&ED=149135862&tollFree=0 Access code:964 830 977 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://workgreen.webex.com/workgreen/mc 2. On the left navigation bar, click "Support". You can contact me at: amorris@amsl.com 1-510-492-4081 To add this meeting to your calendar program (for example Microsoft Outlook), click this link: https://workgreen.webex.com/workgreen/j.php?ED=149135862&UID=1194293802&ICS=MI&LD=1&RD=2&ST=1&SHA2=GjVrW3H4Ev-BJ9Wc75OS2DYhzYH8u3yA/PxemwTHg/s=&RT=MiM0 The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://workgreen.webex.com/workgreen/systemdiagnosis.php Sign up for a free trial of WebEx http://www.webex.com/go/mcemfreetrial http://www.webex.com CCP:+14087926300x964830977# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation.