From y.oiwa@aist.go.jp Tue Jul 5 07:10:42 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2808221F8575; Tue, 5 Jul 2011 07:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0eoV0qEBJGZ; Tue, 5 Jul 2011 07:10:38 -0700 (PDT) Received: from mx1.aist.go.jp (mx1.aist.go.jp [150.29.246.133]) by ietfa.amsl.com (Postfix) with ESMTP id B4FB721F8579; Tue, 5 Jul 2011 07:10:36 -0700 (PDT) Received: from rqsmtp1.aist.go.jp (rqsmtp1.aist.go.jp [150.29.254.115]) by mx1.aist.go.jp with ESMTP id p65EAXhe028839; Tue, 5 Jul 2011 23:10:33 +0900 (JST) env-from (y.oiwa@aist.go.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=aist.go.jp; s=aist; t=1309875034; bh=lWQopefAxXp1v8Gj10NThaRecdYPKaMpSBH//1Hj9CY=; h=From:Date:Message-ID; b=cv2SwYkrx+yiZFi+986DQbzMET2zsmeWCM1veVLdoZ0hQDC6fnA3RvDfipROq3SJo aVQ0QOPv/7n1Hz2EWGohSmuXFC2qcaEq/l1Jzn507NhTBbw3BSk3NRnvOTJ5ISn8UQ tFyQxXMK/khr8pqF/NHcxf2kbc6AI6aw45Y3KAJ8= Received: from smtp3.aist.go.jp by rqsmtp1.aist.go.jp with ESMTP id p65EAXhS002618; Tue, 5 Jul 2011 23:10:33 +0900 (JST) env-from (y.oiwa@aist.go.jp) Received: by smtp3.aist.go.jp with ESMTP id p65EAWg1014010; Tue, 5 Jul 2011 23:10:32 +0900 (JST) env-from (y.oiwa@aist.go.jp) To: IETF HTTP-auth Mailing List From: Yutaka OIWA Date: Tue, 05 Jul 2011 23:10:32 +0900 Message-ID: <87box824yv.fsf@bluewind.rcis.aist.go.jp> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: saag , apps-discuss Subject: [saag] http-auth problem statement draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: IETF HTTP-auth Mailing List List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 14:10:42 -0000 Dear all, I have just reformatted the problem statement document (previously put on IETF Wiki) to the I-D format. The draft is now available from: http://tools.ietf.org/html/draft-oiwa-http-auth-problem-statement-00 I've added categorization of use-cases to three groups (Section 4). I also added several references and other minor improvements. I'd like to add more topics and use cases here. Yutaka -- Yutaka OIWA, Ph.D. Research Scientist Research Center for Information Security (RCIS) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] From y.oiwa@aist.go.jp Tue Jul 5 07:17:53 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5392911E80AB; Tue, 5 Jul 2011 07:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wiwgka5xyqtU; Tue, 5 Jul 2011 07:17:52 -0700 (PDT) Received: from mx1.aist.go.jp (mx1.aist.go.jp [150.29.246.133]) by ietfa.amsl.com (Postfix) with ESMTP id 44BA221F858D; Tue, 5 Jul 2011 07:17:52 -0700 (PDT) Received: from rqsmtp1.aist.go.jp (rqsmtp1.aist.go.jp [150.29.254.115]) by mx1.aist.go.jp with ESMTP id p65EHowH000254; Tue, 5 Jul 2011 23:17:50 +0900 (JST) env-from (y.oiwa@aist.go.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=aist.go.jp; s=aist; t=1309875470; bh=oGEyCnG3lyoDz1cydQMKppf/N7+0bxcT6RXYlSRAlQk=; h=From:Date:Message-ID; b=RZV9ehmEFqApeDSxnRRKhyH4XdahyyF6mXUzo2rRB24GHFmOsz0I8noEZ+WMIEUZ+ UEBwNBPs1qIIph+O5uOVGxNeWJ+kkh3p9f4+e3mmqwKhe3IKu6f0W0nSzgnZHDiskw cxmgqZMMKZphXqNB2LtM0nE3M1I+mpbD/sVYSqoE= Received: from smtp3.aist.go.jp by rqsmtp1.aist.go.jp with ESMTP id p65EHoYa003048; Tue, 5 Jul 2011 23:17:50 +0900 (JST) env-from (y.oiwa@aist.go.jp) Received: by smtp3.aist.go.jp with ESMTP id p65EHnVF015625; Tue, 5 Jul 2011 23:17:49 +0900 (JST) env-from (y.oiwa@aist.go.jp) To: IETF HTTP-auth Mailing List From: Yutaka OIWA Date: Tue, 05 Jul 2011 23:17:49 +0900 Message-ID: <877h7w24mq.fsf@bluewind.rcis.aist.go.jp> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: saag , apps-discuss Subject: [saag] Updated HTTP Mutual authentication draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: IETF HTTP-auth Mailing List List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 14:17:53 -0000 I've updated the http Mutual authentication proposal draft. As suggested at Prague Bar-BoF, now I split out the cryptography part from the core protocol part. Current status of separation is a bit technical and sloppy, I will improve some non-technical sections such as introduction to make it more natural in the future. In the next stage I'd also like to re-examine the http-auth extension (optional auth and detailed auth control) part and separate it to another draft, possibly after Quebec. The drafts are now available at http://tools.ietf.org/html/draft-oiwa-http-mutualauth-09 http://tools.ietf.org/html/draft-oiwa-http-mutualauth-algo-00 Yutaka -- Yutaka OIWA, Ph.D. Research Scientist Research Center for Information Security (RCIS) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] From kathleen.moriarty@emc.com Wed Jun 29 15:21:04 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB6421F859D; Wed, 29 Jun 2011 15:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61S+nrCkHx5a; Wed, 29 Jun 2011 15:21:03 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 77B0121F858F; Wed, 29 Jun 2011 15:21:03 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p5TML2St010592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Jun 2011 18:21:02 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Wed, 29 Jun 2011 18:20:53 -0400 Received: from mxhub25.corp.emc.com (mxhub25.corp.emc.com [10.254.110.181]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p5TMKpdF032341; Wed, 29 Jun 2011 18:20:52 -0400 Received: from mx06a.corp.emc.com ([169.254.1.199]) by mxhub25.corp.emc.com ([10.254.110.181]) with mapi; Wed, 29 Jun 2011 18:20:24 -0400 From: To: , Date: Wed, 29 Jun 2011 18:20:49 -0400 Thread-Topic: MILE 'side meeting' Monday night July 25th Thread-Index: Acw2qs0JHh8mbHuURqqcTPxt3owf0A== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 X-Mailman-Approved-At: Tue, 05 Jul 2011 08:27:46 -0700 Subject: [saag] MILE 'side meeting' Monday night July 25th X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 22:21:04 -0000 Hello, This email is to announce that we will be holding a side meeting for a pre-= working group to review the proposed charter and some of the work to be com= pleted in the proposed group. The side meeting will take place Monday, Jul= y 25th following the Technical Plenary, at 19:30 PM. Thank you, Kathleen & Brian Managed Incident Lightweight Exchange (mile) -------------------------------------------- Proposed Working Group Charter Chairs: Kathleen Moriarty > Brian Trammell > Security Area Directors: Stephen Farrell > Sean Turner > Security Area Advisor: Sean Turner > Mailing Lists: General Discussion: mile@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/mile Archive: http://www.ietf.org/mail-archive/web/mile Description of Working Group: The Managed Incident Lightweight Exchange (MILE) pre-working group will dev= elop standards and extensions for the purpose of improving incident informa= tion sharing and handling capabilities based on the work developed in the I= ETF Extended INCident Handling (INCH) working group. The Incident Object D= escription Exchange Format (IODEF) in RFC5070 and Real-time Inter-network D= efense (RID) in RFC6045 were developed in the INCH working group by interna= tional Computer Security Incident Response Teams (CSIRTs) and industry to m= eet the needs of a global community interested in sharing, handling, and ex= changing incident information. The extensions and guidance created by the = MILE working group assists with the daily operations of CSIRTs at an organi= zation, service provider, law enforcement, and at the country level. The a= pplication of IODEF and RID to interdomain incident information cooperative= exchange and sharing has recently expanded and the need for extensions has= become more important. Efforts continue to deploy IODEF and RID, as well a= s to extend them to support specific use cases covering reporting and mitig= ation of current threats such as anti-phishing extensions. An incident could be a benign configuration issue, IT incident, an infracti= on to a service level agreement (SLA), a system compromise, socially engine= ered phishing attack, or a denial-of-service (DoS) attack, etc.. When an i= ncident is detected, the response may include simply filing a report, notif= ication to the source of the incident, a request to a third party for resol= ution/mitigation, or a request to locate the source. IODEF defines a data = representation that provides a standard format for sharing information comm= only exchanged about computer security incidents. RID enables the secure e= xchange of incident related information in an IODEF format providing option= s for security, privacy, and policy setting. MILE leverages collaboration and sharing experiences with the work develope= d in the INCH working group which includes the data model detailed in the I= ODEF, existing extensions to the IODEF for Anti-phishing (RFC5901), and RID= (RFC6045, RFC6046) for the secure exchange of information. MILE will also= leverage the experience gained in using IODEF and RID in operational conte= xts. Related work, drafted outside of INCH will also be reviewed and includ= es RFC5941, Sharing Transaction Fraud Data. The MILE working group provides coordination for these various extension ef= forts to improve the capabilities for exchanging incident information. MIL= E has several objectives with the first being a description a subset of IOD= EF focused on ease of deployment and applicability to current information s= ecurity data sharing use cases. MILE also describes a generalization of RI= D for secure exchange of other security-relevant XML formats. MILE produce= s additional guidance needed for the successful exchange of incident inform= ation for new use cases according to policy, security, and privacy requirem= ents. Finally, MILE produces a document template with guidance for definin= g IODEF extensions to be followed when producing extensions to IODEF as app= ropriate, for: * labeling incident reports with data protection, data retention, and oth= er policies, regulations, and laws restricting the handling of those reports * reporting on mail service abuse incidents * reporting forensic data generated during incident investigation * reporting indicators of compromise in incident reports * reporting on financial fraud incidents * reporting incidents involving virtualized environments * referencing SCAP enumerations from within incident reports * profiling and reporting on characteristics of malware suspected or conf= irmed to be involved in an incident * profiling and reporting on characteristics of actors (persons or groups= ) suspected or confirmed to be involved in an incident * reporting on misuse incidents From kwatsen@juniper.net Tue Jul 5 15:32:59 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8987F21F876D for ; Tue, 5 Jul 2011 15:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4PUl0KFxLLG for ; Tue, 5 Jul 2011 15:32:58 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 0371B21F8761 for ; Tue, 5 Jul 2011 15:32:57 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKThORF3KruAVFcVtyvP/0AeSOvP9OOmle@postini.com; Tue, 05 Jul 2011 15:32:58 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Tue, 5 Jul 2011 15:32:14 -0700 From: Kent Watsen To: "ietf-ssh@NetBSD.org" , "saag@ietf.org" Date: Tue, 5 Jul 2011 15:32:09 -0700 Thread-Topic: [saag] draft-kwatsen-reverse-ssh-01 submission for review Thread-Index: AcwmUDMylkY2FD/lRWGPlPpb3vcEuAApMekwBRaDDvA= Message-ID: <84600D05C20FF943918238042D7670FD3E83C429A6@EMBX01-HQ.jnpr.net> References: <965_1307576669_p58NiSYT016404_84600D05C20FF943918238042D7670FD3E81EA1164@EMBX01-HQ.jnpr.net> <1307587911.7092.331.camel@destiny> <84600D05C20FF943918238042D7670FD3E82122E54@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD3E82122E54@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [saag] draft-kwatsen-reverse-ssh-01 submission for review X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 22:32:59 -0000 DQpBbGxvd2luZyB0aGUgU1NIIHNlcnZlciBvcGVuIGNoYW5uZWxzIG9uIHRoZSBjbGllbnQgaGFz IGEgbG90IG9mIG1lcml0Lg0KDQpJbiB0cnlpbmcgdG8gZXh0ZW5kIHRoZSBnZW5lcmljIFNTSCBz ZXJ2ZXIgKGxpc3RlbmluZyB0byBwb3J0IDIyKSwgd291bGQgdGhlIGNsaWVudCBzdGFydCBhbiBh cHBsaWNhdGlvbi1zcGVjaWZpYyBzdWJzeXN0ZW0gaGF2aW5nIHRoZSBidXNpbmVzcyBsb2dpYyBr bm93aW5nLCBmb3IgaW5zdGFuY2UsIGhvdyBtYW55IGNoYW5uZWxzIHRvIG9wZW4sIGV0Yz8gIFRo aXMgc29sdXRpb24gd291bGQgbGlrZWx5IHJlcXVpcmUgYSBQQU0gbW9kdWxlIGF1dGggdGhlIGNs aWVudCAoaS5lLiB0aGUgZGV2aWNlKSBpbiB0aGUgYXBwJ3MgZGF0YWJhc2UsIHNpbmNlIGl0cyBz dXJlbHkgbm90IGEgc3lzdGVtLWxldmVsIHVzZXIuICBUaGlzIHNvbHV0aW9uIHdvdWxkIHVzZSBt b3JlIHN5c3RlbSByZXNvdXJjZXMgKHByb2Nlc3NlcywgZG9tYWluIHNvY2tldHMsIGV0Yy4pIHRo YW4gb3VyIGN1cnJlbnQgaW1wbGVtZW50YXRpb24uDQoNCkEgbGVzcyByZXNvdXJjZSBpbnRlbnNp dmUgb3B0aW9uIHdvdWxkIGJlIGZvciB0aGUgInNlcnZlciIgdG8gYmUgdGhlIGFwcGxpY2F0aW9u IGl0c2VsZiwgbGlua2VkIHRvIGEgU1NIIHNlcnZlciBsaWJyYXJ5LiAgIE9mIGNvdXJzZSwgdGhp cyBzZXJ2ZXIgd291bGRuJ3QgYmUgYWJsZSB0byBsaXN0ZW4gb24gcG9ydCAyMiwgc2luY2UgaXQg d291bGRuJ3QgYmUgZ2VuZXJpYy4gIFdvdWxkIG5vdCBiZWluZyBnZW5lcmljIGRlZmVhdCB0aGUg cHVycG9zZSBvZiB0cnlpbmcgdG8gZG8gdGhpcyBpbnNpZGUgdGhlIFNTSCBwcm90b2NvbD8NCg0K SW4gYm90aCBjYXNlcywgdGhlIHNvbHV0aW9uIHdvdWxkIHJlbHkgb24gdGhlIGRldmVsb3BlcnMg b2YgdGhlIHZhcmlvdXMgU1NIIGFwcHMgYW5kIGxpYnJhcmllcyB0byBzdXBwb3J0IHRoaXMgYWJp bGl0eS4gIFRoaXMgbWlnaHQgYmUgZGlmZmljdWx0IHNlbGwgZ2l2ZW4gdGhlIHVzZS1jYXNlIGlz IHNvbWV3aGF0IGxpbWl0ZWQgdG8gbmV0d29yayBtYW5hZ2VtZW50OyBub3QgdGhhdCBpdCBjb3Vs ZG4ndCBiZSB1c2VkIGZvciBvdGhlciBwdXJwb3NlcywgSSBqdXN0IGNhbiB0aGluayBvZiBhbnkg b3RoZXIuICBBc3N1bWluZyB3ZSdyZSBhYmxlIHRvIHVwZGF0ZSB0aGUgU1NIIGltcGxlbWVudGF0 aW9ucywgd2UnZCB0aGVuIGhhdmUgdG8gY29udmluY2UgYWxsIHRoZSBkZXZpY2VzIHRvIHVzZSB0 aGlzIG5ldyB2ZXJzaW9uIG9mIHRoZSBTU0ggY2xpZW50IC0gdGhlIHJvbGUtb3V0IGNvdWxkIHRh a2UgYXdoaWxlLi4uDQoNCkknbSBzdGlsbCBhIGJpdCBwYXJ0aWFsIHRvIG15IG9yaWdpbmFsIHBy b3Bvc2FsLCBib290c3RyYXBwaW5nIHRoZSBzdGFuZGFyZCBTU0ggcHJvdG9jb2wsIHNvIHRoZSBk ZXZpY2UgaXMgYWx3YXlzIHJ1bm5pbmcgYHNzaGRgLiAgVGhpcyBzb2x1dGlvbiBpcyBlYXN5IHRv IGltcGxlbWVudCBhbmQgd29ya3Mgd2l0aCBhbGwgZXhpc3RpbmcgU1NIIGFwcHMgYW5kIGxpYnJh cmllcy4gIElmIHRoZXJlIGlzIGFueSBpbnRlcmVzdCBpbiBnb2luZyBiYWNrIHRvIHRoaXMgYXBw cm9hY2gsIHdlIGNvdWxkIGdyZWF0bHkgaW1wcm92ZSB0aGUgLTAwIGRyYWZ0IGJ5IGVuYWJsaW5n IHRoZSBNQUMgYW5kIGhvc3Qta2V5IGFsZ29yaXRobXMgdG8gYmUgbmVnb3RpYXRlZCwgZXhhY3Rs eSBsaWtlIFNTSCwgaW5zdGVhZCBvZiBtYW5kYXRpbmcgdGhlIHVzZSBvZiBobWFjLXNoYTI1Ni4g IEFueSBpbnRlcmVzdCBpbiBnb2luZyBiYWNrIHRvIHRoaXMgYXBwcm9hY2g/IA0KDQpUaGFua3Ms DQpLZW50DQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogc2FhZy1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86c2FhZy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg S2VudCBXYXRzZW4NClNlbnQ6IE1vbmRheSwgSnVuZSAxMywgMjAxMSA2OjAwIFBNDQpUbzogSmVm ZnJleSBIdXR6ZWxtYW4NCkNjOiBpZXRmLXNzaEBOZXRCU0Qub3JnOyBzYWFnQGlldGYub3JnDQpT dWJqZWN0OiBSZTogW3NhYWddIGRyYWZ0LWt3YXRzZW4tcmV2ZXJzZS1zc2gtMDEgc3VibWlzc2lv biBmb3IgcmV2aWV3DQoNCg0KSGkgSmVmZiwNCg0KVGhhbmsgeW91IGZvciBzZW5kaW5nIG91dCB5 b3VyIGNvbW1lbnRzIQ0KDQoNCj4gU28sIGxldCdzIG1ha2Ugc3VyZSBJIGhhdmUgdGhpcyByaWdo dC4gIEEgZGV2aWNlICJjYWxsaW5nIGhvbWUiIGlzIGdvaW5nDQo+IHRvIGNvbm5lY3QgdG8gc29t ZSBzZXJ2ZXIgb24gcG9ydCAyMiwgYW5kIGV4cGVjdCB0aGUgc2VydmVyIHRvDQo+IGltbWVkaWF0 ZWx5IHBpY2sgdXAgdGhlIHJvbGUgb2YgYmVpbmcgYW4gU1NIIGNsaWVudD8NCg0KWWVzLCB0aGlz IGlzIHRoZSBwcm9wb3NhbA0KDQoNCj4gSG93IGlzIHRoZSBzZXJ2ZXIgdG8gZGlzdGluZ3Vpc2gg YmV0d2VlbiBzdWNoIGEgZGV2aWNlIGFuZCBhIG5vcm1hbCBzc2gNCj4gY2xpZW50IGJlaW5nIHVz ZWQgYnkgYW4gYWRtaW4gd2hvIHdhbnRzIHRvIGxvZyBpbiB0byB0aGUgc2VydmVyPyAgT3IgYnkN Cj4gc29tZSBvdGhlciBwcm90b2NvbCB0aGF0IHJ1bnMgb3ZlciBzc2g/DQoNCkl0IGNhbid0LCB0 aGUgc2VydmVyIGhhcyB0byAqa25vdyogdGhhdCBpdCdzIGhhdmluZyB0aGlzIHB1cnBvc2UuICBB cyBtZW50aW9uZWQgYmVmb3JlLCB0aGUgZGV2aWNlcyBjYW4ndCBjb25uZWN0IHRvIGEgZ2VuZXJp YyBTU0ggc2VydmVyLCBzaW5jZSBhcHBsaWNhdGlvbi1sZXZlbCBidXNpbmVzcyBsb2dpYyBuZWVk cyB0byBiZSBsaW5rZWQtaW4gdG8gb3BlbiBjaGFubmVscyB0byB0aGUgZGV2aWNlIGFuZCB3aGF0 IG5vdC4gIFRoaXMgaXMgd2h5IGlzIGNhbid0IGJlIGEgZ2VuZXJpYyBTU0ggc2VydmVyLiAgSXQn cyBhbHNvIHdoeSBhIGRpc3RpbmN0IElBTkEtYXNzaWduZWQgcG9ydCBtaWdodCBiZSBnb29kLCBz byBhcyB0byBkaXNjb3VyYWdlIHN0YW5kYXJkIFNTSCBjbGllbnRzIGZyb20gdHJ5aW5nIHRvIGNv bm5lY3QgdG8gaXQuDQoNCg0KDQo+IEknbSBwcmV0dHkgc3VyZSBJIHJlY2FsbCB0aGUgZGlzY3Vz c2lvbiBvbiB0aGlzIHBvaW50IGludm9sdmluZyBzb21lDQo+IHNvcnQgb2YgbmVnb3RpYXRpb24s IHJhdGhlciB0aGFuIGEgcmVxdWlyZW1lbnQgdGhhdCBib3RoIHNpZGVzIGtub3cgYQ0KPiBwcmlv cmkgd2hpY2ggcHJvdG9jb2wgdmFyaWFudCB0aGV5J3JlIGdvaW5nIHRvIHNwZWFrLiAgSW4gZmFj dCwgSSBzZWVtDQo+IHRvIHJlY2FsbCBkZXIgTW91c2Ugc3VnZ2VzdGluZyB1c2Ugb2YgYSBwcmUt a2V4IGV4dGVuc2lvbiBwYWNrZXQgdG8NCj4gaW5kaWNhdGUgdGhpcy4NCg0KVHJ1ZS4gIE5vdCB0 aGF0IGl0J3MgYSBnb29kIGV4Y3VzZSwgYnV0IGl0IEkgY291bGRuJ3QgZmluZCBhIHdheSB0byBo YXZlIGEgcHJlLWtleCBleHRlbnNpb24gcGFja2V0IHRoYXQgd291bGRu4oCZdCBhbHNvIG5lY2Vz c2l0YXRlIHZlcnNpb25pbmcgdGhlIFNTSCBUcmFuc3BvcnQgTGF5ZXIgcHJvdG9jb2wgKFNTSCAy LjEpLiAgSSB3YXNuJ3Qgc3VyZSBpZiB0aGlzIHdhcyBnb2luZyB0byBiZSBPSy4gIEkgbmVnbGVj dGVkIHRvIG1lbnRpb24gYW55dGhpbmcgYWJvdXQgdGhpcyB3aGVuIEkgc2VudCBvdXQgdGhlIHVw ZGF0ZSAtIHRoYW5rcyBmb3IgY2F0Y2hpbmcgaXQhICBJZiBkZXNpcmVkLCBJJ2xsIGNlcnRhaW5s eSB1cGRhdGUgdGhlIGRyYWZ0IHRvIGNvbXBsZXRlIHRoaXMgaXRlbS4uLiAgW1BTOiBJIGxpa2Ug bW9yZSB5b3VyIGlkZWEgdG8gbGV0IHRoZSBTU0ggc2VydmVyIG9wZW4gY2hhbm5lbHMgb24gdGhl IFNTSCBjbGllbnQsIG1vcmUgb24gdGhhdCBiZWxvd10NCg0KDQoNCj4gVGhpcyBpcyBub3QgdGhl IHdheSB0byBhY2hpZXZlIHdoYXQgeW91J3JlIHRyeWluZyB0byBkby4gIE5vciBpcw0KPiBzcGVj aWZ5aW5nIHVzZSBvZiBvbmx5IHBhcnRpY3VsYXIgaG9zdCBrZXkgYWxnb3JpdGhtcywgd2hpY2gg cmF0aGVyDQo+IGJhZGx5IGJyZWFrcyBtb2R1bGFyaXR5LiAgRnVydGhlciwgd2hhdCB5b3UndmUg ZG9uZSBkb2Vzbid0IGFjdHVhbGx5IGJ1eQ0KPiBhbnl0aGluZy4gIElmIHRoZSBITUFDIGlzIHBy ZWNvbXB1dGVkIGJlZm9yZSB0aGUgZGV2aWNlIHRoYXQgd2lsbCBhY3QgYXMNCj4gU1NIIHNlcnZl ciBpcyBkZXBsb3llZCwgdGhlbiB0aGVyZSBpcyBubyBvcGVyYXRpb25hbCBhZHZhbnRhZ2Ugb3Zl cg0KPiBYLjUwOSBjZXJ0aWZpY2F0ZXMuICBPbiB0aGUgb3RoZXIgaGFuZCwgaWYgdGhlIEhNQUMg aXMgY29tcHV0ZWQgYXQgdGhlDQo+IHRpbWUgb2YgdGhlIGNvbm5lY3Rpb24sIHRoZW4gYm90aCB0 aGUgY2xpZW50IGFuZCBzZXJ2ZXIgbXVzdCBrbm93IHRoZQ0KPiBrZXkgX2FuZF8gdGhlcmUgbXVz dCBiZSBhIGRpZmZlcmVudCBrZXkgZm9yIGVhY2ggY2xpZW50L3NlcnZlciBwYWlyIChzbw0KPiBv bmUgZGV2aWNlIGNhbm5vdCBpbXBlcnNvbmF0ZSBhbm90aGVyKS4gIEluIHdoaWNoIGNhc2UsIHlv dSBtYXkgYXMgd2VsbA0KPiBwcmVzaGFyZSBwZXItZGV2aWNlIFJTQSBrZXlzIGluc3RlYWQgb2Yg cGVyLWRldmljZSBITUFDIGtleXMuDQo+DQo+IEV4Y2VwdCBpbiBjYXNlcyBsaWtlIFguNTA5ICh3 aGVyZSBhIGhvc3Qga2V5IGlzIGFzc29jaWF0ZWQgd2l0aCBhDQo+IGxvbmctdGVybSBzaWduYXR1 cmUgYnkgc29tZSB0cnVzdGVkIHRoaXJkIHBhcnR5KSwgU1NIIHByb3ZlcyBzZXJ2ZXINCj4gaWRl bnRpdHkgYW5kIGF1dGhlbnRpY2F0ZXMgaG9zdCBrZXlzIGFzIHBhcnQgb2Yga2V5IGV4Y2hhbmdl LiAgSWYgbm9uZQ0KPiBvZiB0aGUgYWxyZWFkeS1kZWZpbmVkIEtFWCBtZXRob2RzIGFyZSBzdWl0 YWJsZSBmb3IgeW91ciBuZWVkcywgdGhlbiBpdA0KPiBtaWdodCBiZSBwb3NzaWJsZSB0byBkZWZp bmUgYSBuZXcgb25lIGFsb25nIHRoZSBsaW5lcyBvZiB3aGF0IHlvdSd2ZQ0KPiBkZXNjcmliZWQu ICBIb3dldmVyLCBJIHNlcmlvdXNseSBkb3VidCBpdHMgdXRpbGl0eSwgZm9yIHRoZSByZWFzb25z DQo+IGRlc2NyaWJlZCBhYm92ZS4NCg0KSSBleHBlY3RlZCB0aGlzIHRvIGJlIGNoYWxsZW5nZWQs IGFzIGl0J3MgcXVpdGUgdW5pcXVlLiAgIExldCBtZSBzdGFydCBieSBzdGF0aW5nIHRoYXQgd2Ug KEp1bmlwZXIpIGhhdmUgYmVlbiB1c2luZyBhbiBITUFDIHRvIHNlY3VyZSByZXZlcnNlLXNzaCBj b25uZWN0aW9ucyBmb3IgYSBmZXcgeWVhcnMgbm93LiAgV2UgdXNlIHRoZSBITUFDIGluIGEgYm9v dHN0cmFwcGluZyBtZXNzYWdlIHNpbWlsYXIgdG8gdGhhdCBkZXNjcmliZWQgYnkgdGhlIC0wMCB2 ZXJzaW9uIG9mIHRoaXMgZHJhZnQuICBDcmVhdGluZyB0aGUgImhtYWMtKiIgZmFtaWx5IG9mIGFs Z29yaXRobXMgd2FzIG9ubHkgdG8gcHJlc2VydmUgdGhpcyBmdW5jdGlvbmFsaXR5IGluIHRoZSBT U0ggcHJvdG9jb2wgaXRzZWxmLg0KDQpUaGUgd2F5IGl0IHdvcmtzIGlzIGFzIGZvbGxvd3MuICBU aGUgTk1TIGNyZWF0ZXMgYW4gZW50cnkgaW4gaXRzIGRhdGFiYXNlIGZvciB0aGUgZGV2aWNlIGl0 IGV4cGVjdHMgd2lsbCBjb25uZWN0IHNvbWV0aW1lIGxhdGVyLiAgVGhlIGVudHJ5IGlzIGtleWVk IGJ5IGEgImRldmljZS1pZCIgYW5kIGEgdW5pcXVlIEhNQUMgdmFsdWUgaXMgc3RvcmVkIGZvciBp dC4gIExhdGVyLCBKdW5pcGVyIHdpbGwgZHJvcC1zaGlwIHRoZSBkZXZpY2UgKHdpdGggZmFjdG9y eS1kZWZhdWx0IGltYWdlKSBkaXJlY3RseSB0byBpdHMgZGVzdGluYXRpb24gKGkuZS4gYSByZXRh aWwgb3V0bGV0IHN0b3JlKSwgd2hlcmUgaXQgaXMgZXhwZWN0ZWQgdGhhdCB0aGUgKnN0b3JlIG1h bmFnZXIqIHdpbGwgYmUgYWJsZSB0byBnZXQgaXQgdXAgYW5kIHJ1bm5pbmcuICBCZWluZyBub3Qg dmVyeSB0ZWNobmljYWwsIHRoZSBzdG9yZSBtYW5hZ2VyIGZvbGxvd3Mgc2ltcGxlIGluc3RydWN0 aW9ucyBzZW50IGZyb20gSFEgKHBsdWcgcGhvbmUgY2FibGUgaGVyZSwgcGx1ZyBwb3dlciBjYWJs ZSBoZXJlLCB3YWl0IGZvciBsaWdodCB0byBibGluaywgY2FsbCB0aGlzIG51bWJlciwgZXRjLiku ICBVbHRpbWF0ZWx5LCB0aGUgZGV2aWNlIG5lZWRzIHRvIGdldCBlbm91Z2ggY29uZmlnIHRvIGlu aXRpYWxpemUgaXRzIG5ldHdvcmsgc3RhY2sgYW5kIHNlY3VyZWx5ICJjYWxsIGhvbWUiIHRvIGl0 cyBOTVMuICBUaGUgZGV2aWNlIE1BWSBnZXQgdGhpcyBpbmZvcm1hdGlvbiBmcm9tIGEgREhDUCBz ZXJ2ZXIgYW5kL29yIFVTQiBwZW4tZHJpdmUgcGx1Z2dlZCBpbnRvIGl0IGFuZC9vciB2aWEgaXRz IHdlYi9jbGkgaW50ZXJmYWNlcy4gIEZvciBhbiBITUFDLCB3ZSdkIG5ldmVyIHB1dCB0aGUgSE1B Qy1rZXkgb24gYSBESENQIHNlcnZlciB0byBiZSByZXRyaWV2ZWQgdmlhIG9wdGlvbiA0MyAoYXMg dGhhdCB3b3VsZCBiZSBpbnNlY3VyZSksIHdlIGVpdGhlciBleHBlY3QgdGhlIEhNQUMta2V5IHRv IGJlIHJlYWQgb2ZmIGEgVVNCIGRyaXZlIG9yIG1hbnVhbGx5IGtleWVkIGluIGJ5IHRoZSBzdG9y ZSBtYW5hZ2VyLg0KDQpJJ20gbm90IHN1cmUgd2hhdCB5b3UgbWVhbiBieSBtb2R1bGFyaXR5LCBi dXQgcmVnYXJkaW5nIG9wZXJhdGlvbmFsIGFkdmFudGFnZSBvdmVyIHguNTA5IGNlcnRpZmljYXRl cywgY29uc2lkZXIgdGhlIGZvbGxvd2luZzogMSkgdGhlcmUncyBubyBvcHBvcnR1bml0eSBpbiB0 aGUgYWJvdmUgZGVzY3JpcHRpb24gZm9yIHRoZSBzdG9yZSBtYW5hZ2VyIHRvIGdldCBhIHguNTA5 IGNlcnRpZmljYXRlIGZvciB0aGUgZGV2aWNlJ3MgZHluYW1pY2FsbHktZ2VuZXJhdGVkIHByaXZh dGUta2V5LCAyKSB0aGUgSE1BQyBpcyBtdWNoIHNpbXBsZXIgdG8ga2V5IGluIHRoYW4gYSBQRU0g ZmlsZSAoZm9yIHdoZW4gY2xpL3dlYiBpbnRlcmZhY2UgaXMgdXNlZCB0byBkbyB0aGF0KQ0KDQoN Cg0KDQo+IEl0IHNvdW5kcyB0byBtZSBsaWtlIHlvdSByZWFsbHkgX2Rvbid0XyB3YW50IHRoZSBk ZXZpY2UgdG8gYmUgdGhlIFNTSA0KPiBzZXJ2ZXIgYXQgYWxsOyB5b3Ugb25seSB0aGluayB5b3Ug ZG8uICBJIHN1c3BlY3QgeW91IHJlYWxseSB3YW50IHRoZQ0KPiBkZXZpY2UgdG8gYmUgdGhlIFNT SCBfY2xpZW50XywgZXhjZXB0IHRoYXQgb25jZSB0aGUgY29ubmVjdGlvbiBpcyB1cCwNCj4geW91 IHdhbnQgdGhlIHNlcnZlciB0byBvcGVuIHNvbWUgc29ydCBvZiBzZXNzaW9uIHRvIHRoZSBjbGll bnQgdG8NCj4gZXhlY3V0ZSBjb21tYW5kcywgdHJhbnNmZXIgZmlsZXMsIHJ1biBuZXRjb25mIG9y IFNOTVAsIG9yIHdoYXRldmVyLg0KPg0KPiBJbnRlcmVzdGluZ2x5LCB0aGlzIHJvbGUgcmV2ZXJz YWwgLS0gYWxsb3dpbmcgdGhlIFNTSCBzZXJ2ZXIgdG8gb3Blbg0KPiBzZXNzaW9ucyBhbmQgcnVu IGNvbW1hbmRzIG9uIHRoZSBTU0ggY2xpZW50LCByZXF1aXJlcyBubyBjaGFuZ2UgdG8gdGhlDQo+ IFNTSCBwcm90b2NvbCBhdCBhbGwuICBJdCBzaW1wbHkgcmVxdWlyZXMgdGhhdCB0aGUgY2xpZW50 IHNpdCBhcm91bmQNCj4gd2FpdGluZyBmb3IgYSBjaGFubmVsLW9wZW4gcmVxdWVzdCBmcm9tIHRo ZSBzZXJ2ZXIgYW5kIGFjY2VwdCBpdCB3aGVuIGl0DQo+IGNvbWVzIGFyb3VuZC4gIFRoaXMgaXMg ZXhhY3RseSB0aGUgc29ydCBvZiBzaXR1YXRpb24gaW4gd2hpY2ggaXQgaXMNCj4gYXBwcm9wcmlh dGUgdG8gYmVoYXZlIGNvbnRyYXJ5IHRvIHRoZSBTSE9VTEQgaW4gUkZDNDI1NCBzZWN0aW9uIDYu MS4NCg0KVGhpcyBpcyBhIHZlcnkgaW50ZXJlc3RpbmcgaWRlYTsgaXQgd291bGQgYmUgKm11Y2gq IHNpbXBsZXIgdG8gYWxsb3cgdGhlIHNlcnZlciB0byBvcGVuIGNoYW5uZWxzIG9uIHRoZSBjbGll bnQuICBQcmVzdW1hYmx5IHRoZSBjbGllbnQgd291bGQgaGF2ZSB0byBiZSBjb25maWd1cmVkIHRv IGluZGljYXRlIHdoaWNoIHN1YnN5c3RlbXMgYXJlIGFsbG93ZWQgKHR0eSwgc2Z0cCwgbmV0Y29u ZikuDQoNCk9mIGNvdXJzZSwgYXMgbWVudGlvbmVkIGFib3ZlLCB3ZSBzdGlsbCBjb3VsZG4ndCB1 c2UgYSBnZW5lcmljIFNTSCBzZXJ2ZXIuICBJbnN0ZWFkLCBpdCB3b3VsZCBoYXZlIHRvIGJlIGEg U1NIIHNlcnZlciBsaW5rZWQgdG8gc29tZSBhcHBsaWNhdGlvbiBjb2RlIHRvIGRvIHRoZSBkb21h aW4tc3BlY2lmaWMgYnVzaW5lc3MgbG9naWMuICBGb3IgdGhpcyByZWFzb24sIGl0IHdvdWxkIGJl IGdvb2QgdG8gcnVuIGl0IG9uIGFub3RoZXIgcG9ydCwgYnV0IG5vdyBpdCdkIGJlIGhhcmQgdG8g anVzdGlmeSBmb3IgYW4gSUFOQS1hc3NpZ25lZCBwb3J0LCBzaW5jZSBpdCByZWFsbHkgaXMgdGhl IFNTSCBwcm90b2NvbCBhbmQgdGhlcmUgYWxyZWFkeSBpcyBhIHBvcnQgZm9yIHRoYXQuICBJbnN0 ZWFkLCBhcHBsaWNhdGlvbnMgd291bGQgbGlrZWx5IG5lZWQgdG8gdXNlIHRoZSBkeW5hbWljL3By aXZhdGUgcG9ydCByYW5nZS4NCg0KVGhpbmtpbmcgdGhpcyB0aHJvdWdoLCB1c2luZyB0aGUgc3Rv cmUtbWFuYWdlciBleGFtcGxlIGZyb20gYWJvdmUsIGxldCdzIHNheSB0aGUgZGV2aWNlIFNTSCdz IHRvIHRoZSBhcHBsaWNhdGlvbi4gIFRoZSBkZXZpY2UgYXV0aGVudGljYXRlcyB0aGUgc2VydmVy J3MgU1NIIGhvc3Qga2V5LCB3aGljaCBjb3VsZCBlaXRoZXIgYmUgYSB4LjUwOSBjZXJ0IG9yIGFu IEhNQUMtKiBrZXkuICBUaGVuIHRoZSBkZXZpY2UgbG9ncyBpbnRvIHRoZSBhcHBsaWNhdGlvbiAo dXNlcmF1dGgpIGFnYWluIHVzaW5nIGVpdGhlciB4LjUwOSBjZXJ0aWZpY2F0ZSBvciBITUFDLSog a2V5LiAgVGhlbiB0aGUgYXBwbGljYXRpb24gKHRoZSBTU0ggc2VydmVyKSBvcGVucyBjaGFubmVs cyBvbiB0aGUgZGV2aWNlICh0aGUgU1NIIGNsaWVudCkuICANCg0KQSBjb3VwbGUgdGhvdWdodHMg YWJvdXQgaG93IGlkZW50aXRpZXMgY2FuIGJlIGRldGVybWluZWQ6DQoNCjEuIHRoZSBkZXZpY2Ug Y2FuIGJlIGNvbmZpZ3VyZWQgdG8ga25vdyB3aGljaCB1c2VyIGl0IHNob3VsZCBydW4gdGhlIFNT SCBjbGllbnQgYXMuICBXZSBuZWVkIHRvIGVuc3VyZSBhIHVzZXIgaXMgc3BlY2lmaWVkIHNpbmNl IENvbW1vbiBDcml0ZXJpYSByZXF1aXJlcyB0aGUgZGV2aWNlIHRvIGlkZW50aWZ5IGEgInVzZXIi IGZvciBlYWNoIGF1ZGl0YWJsZSBldmVudC4gIE5vdGUgdGhhdCB3ZSBjYW4ndCBsZXZlcmFnZSBS RkMgNjEyNSAoU2VydmljZSBJZGVudGl0eSksIHNpbmNlIHNlY3Rpb24gMS43LjIgc3BlY2lmaWNh bGx5IGxlZnQgY2xpZW50IG9yIGVuZC11c2VyIGlkZW50aXRpZXMgb3V0IG9mIHNjb3BlLg0KDQoy LiB0aGUgYXBwbGljYXRpb24gY2FuIHVzZSB0aGUgdXNlcm5hbWUgdGhlIGRldmljZSBwYXNzZXMg YXMgdGhlICJkZXZpY2UtaWQiIHZhbHVlLiAgIFRoaXMgc2VlbXMgb2J2aW91cywgYnV0IGl0J3Mg ZGlmZmVyZW50IHRoZW4gYmVmb3JlIGFuZCBoZW5jZSB3b3J0aCBzdGF0aW5nIGV4cGxpY2l0bHku ICBBbHNvLCBzaW5jZSB0aGUgdXNlcm5hbWUgdmFsdWUgaXMgcGFzc2VkIGluc2lkZSB0aGUgU1NI IHR1bm5lbCwgaXQgd291bGQgYmUgT0sgdG8gcGFzcyBhIHNlcmlhbC1udW1iZXIsIHNvbWV0aGlu ZyB0aGUgb3RoZXIgc29sdXRpb25zIGNvdWxkbid0IHJlY29tbWVuZCBmb3Igc2VjdXJpdHkgcmVh c29ucy4NCg0KSXQgd291bGQgYmUgaW50ZXJlc3RpbmcgdG8gcmV2aWV3IGEgZmV3IFNTSCBTZXJ2 ZXIgbGlicmFyeSBpbXBsZW1lbnRhdGlvbnMgKGkuZS4gbGlic3NoKSB0byBzZWUgaWYgdGhleSBw cm92aWRlIHRoZSBob29rcyBhbiBhcHBsaWNhdGlvbiB3b3VsZCBuZWVkIHRvIGltcGxlbWVudCBp dHMgYnVzaW5lc3MgbG9naWMuLi4NCg0KDQoNCj4gRldJVywgSSdtIGZhaXJseSBjb25jZXJuZWQg YWJvdXQgdGhlIGhtYWMtKiBhbGdvcml0aG1zIGRlc2NyaWJlZCBpbiB0aGlzDQo+IGRvY3VtZW50 LCB3aGljaCBkb24ndCBzZWVtIHRvIHByb3ZpZGUgYW55IGd1YXJhbnRlZSBvZiBmcmVzaG5lc3Mu DQoNCkkgYWdyZWUgdGhhdCBpdCdzIG5vdCBpbiB0aGUgZHJhZnQuICBJIHRoaW5rIHRoYXQgYSAi U2VjdXJpdHkgQ29uc2lkZXJhdGlvbiIgd291bGQgc3VmZmljZSB0aG91Z2guICBPdXIgTk1TIGRv ZXMgcmVwbGFjZSB0aGUgSE1BQyBvbiBkZXZpY2VzLCB1c2luZyBhIGNyeXB0b2dyYXBoaWMgUFJO Ry4gIFRoYXQgc2FpZCwgSSBkb24ndCBiZWxpZXZlIGVudHJvcHkgaXMgbG9zdCBvdmVyIHRpbWUs IHNpbmNlIHRoZSBtZXNzYWdlIHRoYXQgaXMgc2lnbmVkIGNoYW5nZXMgb25seSB3aGVuIHRoZSBo b3N0LWtleSBjaGFuZ2VzLi4uDQoNCg0KPiBJJ20gY29uY2VybmVkIHRoYXQgdGhlcmUgaXMgbm8g ZGVzY3JpcHRpb24gaW4gdGhpcyBkb2N1bWVudCBhcyB0byBob3cNCj4gdGhlIFNTSCBjbGllbnQg aXMgZXhwZWN0ZWQgdG8gYXV0aGVudGljYXRlIGl0c2VsZiB0byB0aGUgZGV2aWNlLiAgVGhpcw0K PiBpcyBmYWlybHkgaW1wb3J0YW50LCBwYXJ0aWN1bGFybHkgc2luY2UgaW4gdGhlIGRlc2NyaWJl ZCBkZXBsb3ltZW50DQo+IHNjZW5hcmlvLCB0aGUgZGV2aWNlIGlzIGxpa2VseSBhYm91dCB0byBn aXZlIG5lYXJseSB1bmxpbWl0ZWQgcG93ZXIgdG8NCj4gdGhlIFNTSCBjbGllbnQuDQoNClRydWUs IGFuZCBpdCBhbHNvIGxlZnQgb3V0IGhvdyB0aGUgZGV2aWNlJ3MgbmV0d29ya2luZyBzdGFjayB3 b3VsZCBiZSBjb25maWd1cmVkLiAgIEZXSVcsIHNlY3Rpb24gNiBzYXlzOg0KDQogICJUaGlzIFJG QyBkb2VzIG5vdCBhdHRlbXB0IHRvIGRlZmluZSBhbnkgc3RyYXRlZ3kgZm9yIGhvdyBhbiBpbml0 aWFsDQogICBkZXBsb3ltZW50IG1pZ2h0IG9idGFpbiBpdHMgYm9vdHN0cmFwcGluZyAiY2FsbCBo b21lIiBjb25maWd1cmF0aW9uDQogICAoYWRkcmVzcyB0byBjb25uZWN0IHRvLCBzaWduYXR1cmUg YWxnb3JpdGhtIHRvIHVzZSwgYXV0aGVudGljYXRpb24NCiAgIGNyZWRlbnRpYWxzIHRvIHVzZSwg ZXRjLikuICBUaGF0IHNhaWQsIGltcGxlbWVudGF0aW9ucyBtYXkgY29uc2lkZXINCiAgIHVzZSBv ZiBhIERIQ1Agc2VydmVyIG9yIGEgVVNCIHBlbiBkcml2ZSBhcyB2aWFibGUgb3B0aW9ucyBmb3Ig dGhlc2UNCiAgIGtpbmRzIG9mIGRlcGxveW1lbnRzLiINCg0KV2UgcHJpbWFyaWx5IHVzZSBhIFVT QiBkcml2ZSwgZm9yIHRoZSBkZXZpY2UgdG8gcmVhZCBvbiBpdHMgZmlyc3QgYm9vdC4gIFRoZSBV U0IgZHJpdmUgY2FuIGNvbnRhaW4gZXZlcnl0aGluZyB0aGUgZGV2aWNlIG5lZWRzIHRvICJjYWxs IGhvbWUiIGZyb20gYSBmYWN0b3J5LWRlZmF1bHQgY29uZmlndXJhdGlvbi4gIEkgZGlkbid0IHRo aW5rIGl0IHdhcyBpbXBvcnRhbnQgdG8gdGhlIHByb3RvY29sIGNoYW5nZSBiZWluZyBkaXNjdXNz ZWQsIHRob3VnaCBpdCdzIGNsZWFybHkgaW1wb3J0YW50IHRvIHRoZSBvdmVyYWxsIHNvbHV0aW9u Lg0KDQoNCg0KPiBGaW5hbGx5LCBJJ20gdmVyeSBjb25jZXJuZWQgYWJvdXQgdGhlIHN0YXRlbWVu dHMgaW4gdGhlIGZpcnN0IHBhcmFncmFwaA0KPiBvZiBzZWN0aW9uIDcsIHdoaWNoIGFzc2VydCB0 aGF0IHRoZSBwcm9wb3NlZCByb2xlIHJldmVyc2FsIGRvZXMgbm90DQo+IGludHJvZHVjZSBhbnkg bmV3IHNlY3VyaXR5IGNvbmNlcm5zLiAgT24gdGhlIGNvbnRyYXJ5LCB0aGUgcHJvcG9zZWQNCj4g cHJvdG9jb2wgaXMgdmVyeSBuZWFybHkgYWtpbiB0byBjYWxsaW5nIHNvbWVvbmUgdXAgYW5kIHNh eWluZyAiR2l2ZSBtZQ0KPiB5b3VyIHBhc3N3b3JkIiwgbGF0ZXIgZm9sbG93ZWQgYnkgImJ5IHRo ZSB3YXksIEkgbWlnaHQgYmUgeW91ciBiYW5rIi4NCg0KVGhhdCdzIG5vdCB0cnVlLiAgU2VjdGlv biA0IHN0YXRlczoNCg0KICAiaW4gb3JkZXIgdG8gZW5hYmxlIHRoZSBSZXZlcnNlIFNTSCBzZXJ2 ZXIgdG8gaWRlbnRpZnkgdGhlDQogICBSZXZlcnNlIFNTSCBjbGllbnQgYW5kIGF1dG9tYXRpY2Fs bHkgYXV0aGVudGljYXRlIGl0cyBTU0ggaG9zdCBrZXksDQogICBlYWNoIHBlZXIgU0hPVUxEIG9u bHkgYWR2ZXJ0aXNlIHN1cHBvcnQgZm9yIG9uZSBvZiB0aGUgZm9sbG93aW5nIGhvc3QNCiAgIGtl eSBhbGdvcml0aG1zOiINCg0KYW5kIHRoZW4gZ29lcyBvbiB0byBsaXN0IGp1c3QgdGhlIHguNTA5 IGFuZCB0aGUgaG1hYy0qIGFsZ29yaXRobXMsIGJvdGggb2Ygd2hpY2ggZW1waGFzaXplIGFzc29j aWF0aW5nIGFuIGlkZW50aXR5IHdpdGggdGhlIHB1YmxpYyBrZXkuICBTbyBpdCdzIG5vdCAiSSBt aWdodCBiZSB5b3VyIGJhbmsiLCBpdCdzICJ5b3Uga25vdyBJJ20geW91ciBiYW5rIGJlY2F1c2Ug bXkgaWRlbnRpdHkgaXMgc2lnbmVkIGJ5IHNvbWV0aGluZyB5b3UgdHJ1c3QiIChlaXRoZXIgYSBD QSBvciBhbiBITUFDLWtleSkuDQoNCg0KPiBXZSd2ZSBkaXNjdXNzZWQgInJldmVyc2UgU1NIIiBp ZGVhcyBiZWZvcmUqLCBhbmQgdGhleSBoYXZlbid0IGdhaW5lZCBhbnkNCj4gdHJhY3Rpb24uICBQ YXJ0IG9mIHRoZSBwcm9ibGVtIGlzIHRoYXQgc2VydmVyIGFuZCBjbGllbnQgYXV0aGVudGljYXRp b24NCj4gaXMgbm90IHN5bW1ldHJpYyBpbiB0aGUgU1NIIHByb3RvY29sLCBhbmQgdGhlcmUgaXMg YSBiYXNpYyBhc3N1bXB0aW9uDQo+IHRoYXQgYSBjbGllbnQga25vd3MgYSBwcmlvcmkgd2hhdCBz ZXJ2ZXIgaXQgaW50ZW5kcyB0byB0YWxrIHRvLCB3aGlsZQ0KPiB0aGUgc2VydmVyIGRvZXMgbm90 IGtub3cgd2hhdCBjbGllbnQgd2lsbCBiZSB0YWxraW5nIHRvIGl0LiAgQXR0ZW1wdGluZw0KPiB0 byBmYWxzaWZ5IHRoaXMgYXNzdW1wdGlvbiBhbmQgc3RpbGwgaGF2ZSB0aGluZ3Mgd29yayB0eXBp Y2FsbHkgcmVzdWx0cw0KPiBpbiB3YXJwaW5nIHRoZSBwcm90b2NvbCByYXRoZXIgYmFkbHkuDQoN CkV4YWN0bHkuICBUaGlzIGlzIHdoeSBteSBvcmlnaW5hbCBkcmFmdCBzdHJlc3NlZCB0aGF0IHRo ZSBkZXZpY2Ugd291bGQgKmFsd2F5cyogYmUgdGhlIFNTSCBzZXJ2ZXIsIHJlZ2FyZGxlc3Mgd2hp Y2ggcGVlciBpbml0aWF0ZWQgdGhlIHVuZGVybHlpbmcgVENQIGNvbm5lY3Rpb24uICBJIHdhc24n dCB0cnlpbmcgdG8gImZhbHNpZnkgdGhpcyBhc3N1bXB0aW9uIiwgYnV0IG1lcmVseSBlbmFibGUg dG8gZGV2aWNlIHRvIGluaXRpYXRlIHRoZSB1bmRlcmx5aW5nIFRDUCBjb25uZWN0aW9uLCBldmVy eXRoaW5nIGVsc2UgcmVtYWlucyBzdGFuZGFyZCBTU0ggcHJvdG9jb2wsIHdpdGggdGhlIGRldmlj ZSBhcyB0aGUgU1NIIHNlcnZlci4NCg0KDQoNCj4gSSdtIG5vdCBzYXlpbmcgYSByZXZlcnNlIFNT SCBpcyBub3QgcG9zc2libGUsIGFuZCB3aXRoIGEgZmV3IG1vcmUNCj4gaXRlcmF0aW9ucyB0aGlz IGRvY3VtZW50IG1pZ2h0IHdlbGwgYmVjb21lIG9uZS4gIEhvd2V2ZXIsIGFzIG1lbnRpb25lZA0K PiBhYm92ZSwgSSB0aGluayBpdCdzIHByb2JhYmx5IG5vdCB0aGUgcmlnaHQgYXBwcm9hY2ggdG8g c29sdmluZyB0aGUNCj4gc3RhdGVkIHByb2JsZW0uDQoNCkknbSBtb3RpdmF0ZWQgdG8gZG8gd2hh dGV2ZXIgaXQgdGFrZXMgdG8gZ2V0IGEgc29sdXRpb24gc3RhbmRhcmRpemVkLiAgSnVuaXBlciBk b2VzbuKAmXQgd2FudCB0byBoYXZlIGEgcHJvcHJpZXRhcnkgc29sdXRpb24gYW5kIG90aGVyIE5F VENPTkcgV0cgbWVtYmVycyBoYXZlIGFza2VkIGZvciBpdCBhcyB3ZWxsLiAgIEkgdGhpbmsgdGhh dCwgd2l0aCB0aGlzIHJvdW5kIG9mIFEmQSwgdGhhdCB3ZSd2ZSBnb3R0ZW4gZG93biB0byB0aGUg Y29yZSBvZiB0aGUgaXNzdWUuICBIb3BlZnVsbHkgd2UnbGwgaXRlcmF0ZSB0byBzb21ldGhpbmcg c29vbiBub3cuIA0KDQoNClRoYW5rcyBhZ2FpbiwNCktlbnQNCg0KDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzYWFnIG1haWxpbmcgbGlzdA0Kc2Fh Z0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zYWFnDQo= From jhutz@cmu.edu Thu Jul 7 11:51:30 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 503A61F0C8D for ; Thu, 7 Jul 2011 11:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTbeFCLop3Zc for ; Thu, 7 Jul 2011 11:51:29 -0700 (PDT) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by ietfa.amsl.com (Postfix) with ESMTP id 975911F0C69 for ; Thu, 7 Jul 2011 11:51:29 -0700 (PDT) Received: from [66.233.146.161] (66-233-146-161.pit.clearwire-wmx.net [66.233.146.161] (may be forged)) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id p67IpPd6011013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Jul 2011 14:51:27 -0400 (EDT) From: Jeffrey Hutzelman To: Kent Watsen In-Reply-To: <84600D05C20FF943918238042D7670FD3E83C429A6@EMBX01-HQ.jnpr.net> References: <965_1307576669_p58NiSYT016404_84600D05C20FF943918238042D7670FD3E81EA1164@EMBX01-HQ.jnpr.net> <1307587911.7092.331.camel@destiny> <84600D05C20FF943918238042D7670FD3E82122E54@EMBX01-HQ.jnpr.net> <84600D05C20FF943918238042D7670FD3E83C429A6@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset="UTF-8" Date: Thu, 07 Jul 2011 14:51:23 -0400 Message-ID: <1310064683.3597.2199.camel@destiny> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Cc: "ietf-ssh@NetBSD.org" , "saag@ietf.org" Subject: Re: [saag] draft-kwatsen-reverse-ssh-01 submission for review X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 18:51:30 -0000 On Tue, 2011-07-05 at 15:32 -0700, Kent Watsen wrote: > Allowing the SSH server open channels on the client has a lot of merit. > > In trying to extend the generic SSH server (listening to port 22), > would the client start an application-specific subsystem having the > business logic knowing, for instance, how many channels to open, etc? Either the client would have to do something explicit, like starting a shell or a subsystem, or the server would have to recognize that client (say, based on the username it sent or how it authenticated or both) and do something appropriate. > This solution would likely require a PAM module auth the client (i.e. > the device) in the app's database, since its surely not a system-level > user. This solution would use more system resources (processes, > domain sockets, etc.) than our current implementation. Now you're talking about implementation details. The SSH protocol doesn't know anything about PAM or "system users" or such things. > A less resource intensive option would be for the "server" to be the > application itself, linked to a SSH server library. Of course, this > server wouldn't be able to listen on port 22, since it wouldn't be > generic. You could do that, too. > Would not being generic defeat the purpose of trying to do > this inside the SSH protocol? You mean, as opposed to trying to make the SSH protocol turn around and operate in reverse halfway through, wedge authentication mechanisms into the wrong role, etc? No, I don't think so. Even if you run the application on its own port, you still have a much cleaner protocol this way. > In both cases, the solution would rely on the developers of the various > SSH apps and libraries to support this ability. This might be > difficult sell given the use-case is somewhat limited to network > management; not that it couldn't be used for other purposes, Frankly, you will probably have a hard time getting upstream OpenSSH to accept patches to implement this or any other approach. They're _very_ conservative about changes. On the other hand, I would expect an SSH server library already to provide most of what you need. Servers already have to be able to open channels for things like TCP port forwarding. Incidentally, if you're a little bit less picky about how much flexibility you allow, there may be approaches you can implement today without any changes to client or server software. For example: 1) The client (device) connects to the SSH server in the usual fashion. It then starts a subsystem which is your field setup application. On the client side, the subsystem's channel is connected to a shell: ssh -s fieldsvc | sh ... except that you need to connect both the shell's stdin and stdout 2) On the client, start something that listens on some local port ( loopback interface only) and connects each new client to a shell. Start an SSH connection with port forwarding back to that port, and run the provisioning app on the server as a command or subsystem: ssh -R 0:127.0.0.1:rawshell -s fieldsvc again, it's a little more complicated, because you need to collect the port number allocated by the server and somehow feed it to the fieldsvc subsystem (perhaps on stdin?) > I just > can think of any other. Assuming we're able to update the SSH > implementations, we'd then have to convince all the devices to use > this new version of the SSH client - the role-out could take awhile... Well, obviously if you have things in the field already using the "reverse SSH" approach, you'll have to support them for a while. That's going to be true no matter how this ends up, and is simply part of the cost of shipping something before relevant standards work is finished. -- Jeff From dhc2@dcrocker.net Fri Jul 8 16:31:38 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 747A421F8CB0 for ; Fri, 8 Jul 2011 16:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DI2KLa6dTssv for ; Fri, 8 Jul 2011 16:31:37 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF0221F8ABC for ; Fri, 8 Jul 2011 16:31:37 -0700 (PDT) Received: from [192.168.1.156] (adsl-67-124-149-98.dsl.pltn13.pacbell.net [67.124.149.98]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p68NVVwQ018051 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 8 Jul 2011 16:31:37 -0700 Message-ID: <4E17934C.8070905@dcrocker.net> Date: Fri, 08 Jul 2011 16:31:24 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "saag@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 08 Jul 2011 16:31:37 -0700 (PDT) Subject: [saag] The meaning of a signature X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 23:31:38 -0000 Folks, A minor debate has arisen that is best resolved with a query to an august body of experts, even though it's only july: Simply put: What is the meaning of a signature on a bag of bits? The question is meant as a matter of official semantics. For OpenPGP: 1. What does its signature on a mesage mean? 2. If "authentication" is claimed, what exactly is authenticated and by whom? 3. Where are these signature semantics defined precisely? For S/MIME: 4. What does its signature on a mesage mean? 5. If "authentication" is claimed, what exactly is authenticated and by whom? 6. Where are these signature semantics defined precisely? These are not meant as trick questions. I think there is less accuracy and precision about this topic than folks realize. My spontaneous survey is meant either to demonstrate that or to correct my own misunderstanding. Thanks! d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From pgut001@login01.cs.auckland.ac.nz Fri Jul 8 23:05:33 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF3D21F8776 for ; Fri, 8 Jul 2011 23:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTG9IWPtY-1z for ; Fri, 8 Jul 2011 23:05:32 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 7EECF21F8761 for ; Fri, 8 Jul 2011 23:05:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1310191533; x=1341727533; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20dcrocker@bbiw.net|Subject:=20Re:=20[saag]=20The=20 meaning=20of=20a=20signature|Cc:=20saag@ietf.org |In-Reply-To:=20<4E17934C.8070905@dcrocker.net> |Message-Id:=20|Date:=20Sat,=2009=20Jul=202011=2018:05:31=20+1200; bh=8vaAmQauCW1oYBsuib7Q4SfgySCzrVuakFqyJA2H5kI=; b=f0fV6sLCZtra41xFDH5ESeF0+77UqcESc/EBotrOC0KSxaQhhdFNKcWZ mk6f0ZBs5LLnYGopQ97G08jAIrFP/nubzCKC++CFaZ1R+WyplCgD9GZ11 Yy3VvX259VzB0OKGOyocmcq9AvYQMHrFXYQfUhN2/ddG04AQH9suNBklx I=; X-IronPort-AV: E=Sophos;i="4.65,502,1304251200"; d="scan'208";a="70919050" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 09 Jul 2011 18:05:31 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QfQfT-0006Pa-Hj; Sat, 09 Jul 2011 18:05:31 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QfQfT-00060x-Er; Sat, 09 Jul 2011 18:05:31 +1200 From: Peter Gutmann To: dcrocker@bbiw.net In-Reply-To: <4E17934C.8070905@dcrocker.net> Message-Id: Date: Sat, 09 Jul 2011 18:05:31 +1200 Cc: saag@ietf.org Subject: Re: [saag] The meaning of a signature X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 06:05:33 -0000 Dave CROCKER writes: >Simply put: What is the meaning of a signature on a bag of bits? It means that at some point in time, some device somewhere, possibly with the knowledge of a key holder, performed a mathematical operation like a modexp on the bag of bits usig a key that may or may not be held solely by the purported own, and the bag was possibly the same bag of bits that the keyholder is aware of. Nothing more, nothing less. >These are not meant as trick questions. That was not meant as a trick answer :-). Peter. From ynir@checkpoint.com Fri Jul 8 23:29:32 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6B1921F869B for ; Fri, 8 Jul 2011 23:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.599 X-Spam-Level: X-Spam-Status: No, score=-11.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5Xos3947FzC for ; Fri, 8 Jul 2011 23:29:32 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id D43FD21F867D for ; Fri, 8 Jul 2011 23:29:31 -0700 (PDT) X-CheckPoint: {4E180307-2-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p696TFMd020960; Sat, 9 Jul 2011 09:29:15 +0300 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Sat, 9 Jul 2011 09:29:15 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Sat, 9 Jul 2011 09:29:15 +0300 From: Yoav Nir To: Peter Gutmann Date: Sat, 9 Jul 2011 09:29:14 +0300 Thread-Topic: [saag] The meaning of a signature Thread-Index: Acw+AYXsbVg4uMZ/RRGy+Z6zN4vxHw== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dcrocker@bbiw.net" , "saag@ietf.org" Subject: Re: [saag] The meaning of a signature X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 06:29:33 -0000 On Jul 9, 2011, at 9:05 AM, Peter Gutmann wrote: > Dave CROCKER writes: >=20 >> Simply put: What is the meaning of a signature on a bag of bits? >=20 > It means that at some point in time, some device somewhere, possibly with= the > knowledge of a key holder, performed a mathematical operation like a mode= xp on > the bag of bits usig a key that may or may not be held solely by the purp= orted > own, and the bag was possibly the same bag of bits that the keyholder is = aware > of. Nothing more, nothing less. >=20 >> These are not meant as trick questions.=20 >=20 > That was not meant as a trick answer :-). Well, yeah, and a pen-based signature means that at some point in time, som= eone used a pen or some other device with ink to scribble something remotel= y resembling letters on a page.=20 And yet we assign meaning to these signatures. We take them as evidence tha= t someone is willing to be bound by the text on the page. Similarly, S/Mime= signatures are taken as evidence that the one who composed the letter is t= he entity named in the certificate. Both kinds of signatures might be forge= d, although by different means. From mouse@Sparkle.Rodents-Montreal.ORG Sat Jul 9 01:04:48 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9179221F856B for ; Sat, 9 Jul 2011 01:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.988 X-Spam-Level: X-Spam-Status: No, score=-9.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJvnmulXaRud for ; Sat, 9 Jul 2011 01:04:48 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by ietfa.amsl.com (Postfix) with ESMTP id 9A68221F8568 for ; Sat, 9 Jul 2011 01:04:47 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id EAA03152; Sat, 9 Jul 2011 04:04:43 -0400 (EDT) Date: Sat, 9 Jul 2011 04:04:43 -0400 (EDT) From: Mouse Message-Id: <201107090804.EAA03152@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Sat, 9 Jul 2011 03:47:57 -0400 (EDT) To: saag@ietf.org In-Reply-To: <4E17934C.8070905@dcrocker.net> References: <4E17934C.8070905@dcrocker.net> Subject: Re: [saag] The meaning of a signature X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 08:04:48 -0000 > Simply put: What is the meaning of a signature on a bag of bits? > The question is meant as a matter of official semantics. Well, first, I assume the signature verifies. If not, it means that either someone corrupted either the signature or the bag-of-bits, or someone attached a bogus signature. (Throughout this discussion, "someone" really means software agents, whether acting on the behalf of the human they appear to have been acting on the behalf of or not.) Otherwise, it means that either someone has broken the crypto in question (unlikely enough to be ignored in most cases) or gotten incredibly lucky (unlikely enough to be ignored in damn near all cases) or that someone in possession of the secret key data in question computed the signature over the bag of bits in question. Note that in many cases, the signature is actually computed over a hash of the overt bag of bits. This offers more leeway for trouble, especially if the hash used is known to be weak (eg, simple MD5), but is fairly necessary in most cases. Note also that the "someone" may not be the purported holder of the secret key data; there are various failure modes that can lead to that, such as the secret key data having been illicitly copied or some system having been subverted to the point that the data the user thought was being signed over isn't the data which actually got signed over. > For OpenPGP: > For S/MIME: I don't know enough to answer any of these, except to remark that the "where are these signature semantics defined precisely?" questions are, I would hope, answered in the specs for the protocol in question. Not that know that much about the specs for either. > These are not meant as trick questions. I think there is less > accuracy and precision about this topic than folks realize. Probably, I'd say. To the extent that "folks" in general know anything at all about digital signatures, I suspect they are mostly taken as "this really is from whom it says it's from". This is a workable approximation in many cases, but far from all - especially for the cases where signatures are most necessary/appropriate. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From pgut001@login01.cs.auckland.ac.nz Sat Jul 9 01:20:59 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5E521F865C for ; Sat, 9 Jul 2011 01:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPGqluhlW5vQ for ; Sat, 9 Jul 2011 01:20:58 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 5E9F121F8655 for ; Sat, 9 Jul 2011 01:20:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1310199659; x=1341735659; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20pgut001@cs.auckland.ac.nz,=20ynir@checkpoint.com |Subject:=20Re:=20[saag]=20The=20meaning=20of=20a=20signa ture|Cc:=20dcrocker@bbiw.net,=20saag@ietf.org |In-Reply-To:=20|Message-Id:=20|Date:=20Sat,=2009=20Jul=202011=2020:20:5 6=20+1200; bh=mXA/0nkPnxBBxkabkzdsR6rZFjqKducz7m3+M9nbCgI=; b=kkPClO0BCUN28YENogutH20C4ZM2nj4EyKHjHwaeXAj9fq5TUsduJccX u5GVzZDDCb+Rvf/+sZqg+JG8gYpvdZZZmPWlnyQLTVcXSaMungCOZyDKJ hpLwRpTVZIEraoukRpOriavr9c5ldTuPzsKV47fFz0rdpkwpLY5D4ubmy 0=; X-IronPort-AV: E=Sophos;i="4.65,503,1304251200"; d="scan'208";a="70923868" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 09 Jul 2011 20:20:57 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QfSmW-0001Wv-Ha; Sat, 09 Jul 2011 20:20:56 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QfSmW-0004bi-DD; Sat, 09 Jul 2011 20:20:56 +1200 From: Peter Gutmann To: pgut001@cs.auckland.ac.nz, ynir@checkpoint.com In-Reply-To: Message-Id: Date: Sat, 09 Jul 2011 20:20:56 +1200 Cc: dcrocker@bbiw.net, saag@ietf.org Subject: Re: [saag] The meaning of a signature X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 08:20:59 -0000 Yoav Nir writes: >Well, yeah, and a pen-based signature means that at some point in time, >someone used a pen or some other device with ink to scribble something >remotely resembling letters on a page. No, the two are very, very different. My signature and/or initials on a contract indicate my active participation in the contract-signing process (and if I really want to dispute it there's the standard questioned-documents process and tons of legal precedent). My digital "signature" on a document doesn't necessarily indicate any participation in the process, even with the best possible intentions the fact that my PDF reader and your PDF reader display different information means that we could end up signing different documents. With pen and paper there's no way for someone to create an absolutely perfect signature in my actual handwriting on a document without my knowledge. With a digital "signature" it's not that hard to do. We already have widespread banker trojans that do exactly this (although without using digital "sigs", but adding "sigs" wouldn't change anything). (Note that I've used the word "signature" in quotes above because it's really quite some way removed from a standard pen-and-paper signature. Like "nonrepudiation", it's another case of crypto guys hijacking a term with a well-established meaning for something with rather different semantics). I would feel quite comfortable going to court to defend a disputed pen-and-paper signature. I wouldn't ever want to become the test case for defending a disputed digital "signature" (unless I was one of the lawyers). Peter. From Josh.Howlett@ja.net Sat Jul 9 04:41:58 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED1D21F862B for ; Sat, 9 Jul 2011 04:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sQ3eGHSSHLw for ; Sat, 9 Jul 2011 04:41:57 -0700 (PDT) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by ietfa.amsl.com (Postfix) with ESMTP id C87F821F8620 for ; Sat, 9 Jul 2011 04:41:57 -0700 (PDT) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id EB2734A6B60_E183E83B; Sat, 9 Jul 2011 11:41:55 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id D0BFA4A6B47_E183E83F; Sat, 9 Jul 2011 11:41:55 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0289.001; Sat, 9 Jul 2011 12:41:51 +0100 From: Josh Howlett To: Peter Gutmann , "dcrocker@bbiw.net" Thread-Topic: [saag] The meaning of a signature Thread-Index: AQHMPcc6fxwI8knxa0e5XfPd6wbxa5TjcBiAgABuvQA= Date: Sat, 9 Jul 2011 11:41:51 +0000 Message-ID: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset=UTF-8 Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "saag@ietf.org" Subject: Re: [saag] The meaning of a signature X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 11:41:58 -0000 > >>These are not meant as trick questions. > >That was not meant as a trick answer :-). "I don=C2=B9t know what you mean by 'glory,' " Alice said. Humpty Dumpty smiled contemptuously. "Of course you don't =E2=80=B9 till = I tell you. I meant 'there=C2=B9s a nice knock-down argument for you!' " "But 'glory' doesn=C2=B9t mean 'a nice knock-down argument'," Alice objec= ted. "When I use a word," Humpty Dumpty said, in a rather a scornful tone, "it means just what I choose it to mean =E2=80=B9 neither more nor less." "The question is," said Alice, "whether you can make words mean so many different things." "The question is," said Humpty Dumpty, "which is to be master - that=C2= =B9s all." Alice was too much puzzled to say anything, so after a minute Humpty Dumpty began again. "They=C2=B9ve a temper, some of them =E2=80=B9 particul= arly verbs, they=C2=B9re the proudest - adjectives you can do anything with, but not ve= rbs - however, I can manage the whole lot! Impenetrability! That=C2=B9s what I = say!=C2=B2 [Through the Looking-Glass, Lewis Carroll] Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From dhc2@dcrocker.net Sat Jul 9 07:14:48 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E63121F87A5 for ; Sat, 9 Jul 2011 07:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3rJ4HzIEjcp for ; Sat, 9 Jul 2011 07:14:48 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id F1DF121F8656 for ; Sat, 9 Jul 2011 07:14:47 -0700 (PDT) Received: from [192.168.1.156] (adsl-67-124-149-98.dsl.pltn13.pacbell.net [67.124.149.98]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p69EEgK7030829 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Sat, 9 Jul 2011 07:14:47 -0700 Message-ID: <4E186249.2060707@dcrocker.net> Date: Sat, 09 Jul 2011 07:14:33 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "saag@ietf.org" References: <4E17934C.8070905@dcrocker.net> <20110709022538.GA4308@mit.edu> In-Reply-To: <20110709022538.GA4308@mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sat, 09 Jul 2011 07:14:47 -0700 (PDT) Subject: Re: [saag] The meaning of a signature (mid-course correction) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 14:14:48 -0000 Folks, First, MANY thanks for the quick followup, including the offline notes. Second, this thread is unfortunately a good demonstration of why survey research is difficult. In spite of trying to ask the questions carefully, the nature of what I am asking appears to have been interpreted a bit differently than I intended. Most folk read the questions in very narrow terms. For example: On 7/8/2011 11:05 PM, Peter Gutmann wrote: > It means that at some point in time, some device somewhere, possibly with the > knowledge of a key holder, performed a mathematical operation like a modexp on > the bag of bits usig a key that may or may not be held solely by the purported > own, and the bag was possibly the same bag of bits that the keyholder is aware > of. Nothing more, nothing less. The core of the answer presents the narrowest possible meaning of signature, by casting it in term of the pure mechanics of data integrity. More than one response focused on this. The issues of a signature's basic mechanics and validity are, of course, essential, but I really meant to take all of that as a given and, instead, ask more about the "why" (or the policy) of different signatures. Signatures often have a context beyond protecting the bits from manipulation. The "Nothing more, nothing less" suggests that my question might have had a larger scope, as indeed I had meant. The narrow definition really casts the purpose of a signature as only for ensuring data integrity between signing and verify. However... On 7/8/2011 7:25 PM, Jeffrey I. Schiller wrote: > The complications arise when we attempt to associate control of the > private key with a person or process AND with how we know that the > associated public key represents the entity that it claims to AND who > or what says so! ... > In particular if I make a commitment in a signed message, how > enforceable is that commitment. Is it as enforceable as a legal > contract? Does adding a signature to a statement make it a signed > legal document? I am not a lawyer... and On 7/9/2011 1:20 AM, Peter Gutmann wrote: > No, the two are very, very different. My signature and/or initials on a > contract indicate my active participation in the contract-signing process (and > if I really want to dispute it there's the standard questioned-documents > process and tons of legal precedent). My digital "signature" on a document > doesn't necessarily indicate any participation in the process, ... These point into the larger scope I am looking for. OpenPGP and S/MIME don't really define the meaning of their signatures. For example, S/MIME repeatedly uses the word 'authentication' but never defines what it is that is authenticated. The term I've recently seen used, to describe the statement of "meaning" for a signature is "claims". For example, when I sign a contract, the meaning of the signature is commitment to the contract's terms and conditions. On the average, folk who see a signature on an email believe that the signature is validating either or both of the author or the content -- but then there are multiple possible meanings to "validating content"...) These larger meanings are certainly the typical beliefs about OpenPGP and S/MIME signatures. However note that it is definitely NOT the correct interpretation for DKIM. Yet the specs for S/MIME and OpenPGP imply, rather than define, their meanings: S/MIME (rfc5751): > but that a careful attacker could have changed > the unauthenticated portions of the encrypted message and > id-aa is the arc with all new authenticated and unauthenticated > attributes But what does it mean to be authenticated? It doesn't say. OpenPGP: > If the verification is successful, the message is accepted as > authentic. and > Thus, if Alice is authenticating herself to Bob with a signature, it > makes sense for her to use a hash algorithm that Bob's software uses. Hmmm. "authenticating herself" certainly means more than the narrow, data integrity interpretation. But, again, it's not explained. So my survey is meant to ask after these broader semantics that are commonly imparted to a signature for these two, popular message-signing mechanisms. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc2@dcrocker.net Sat Jul 9 07:26:20 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1CD921F87C9 for ; Sat, 9 Jul 2011 07:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.599 X-Spam-Level: X-Spam-Status: No, score=-7.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u80X+4l94zjY for ; Sat, 9 Jul 2011 07:26:20 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3007321F87C8 for ; Sat, 9 Jul 2011 07:26:20 -0700 (PDT) Received: from [192.168.1.156] (adsl-67-124-149-98.dsl.pltn13.pacbell.net [67.124.149.98]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p69EQEAl030949 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Sat, 9 Jul 2011 07:26:19 -0700 Message-ID: <4E1864FE.5080403@dcrocker.net> Date: Sat, 09 Jul 2011 07:26:06 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: saag@ietf.org References: <4E17934C.8070905@dcrocker.net> <20110709022538.GA4308@mit.edu> <4E186249.2060707@dcrocker.net> In-Reply-To: <4E186249.2060707@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sat, 09 Jul 2011 07:26:20 -0700 (PDT) Subject: Re: [saag] The meaning of a signature (mid-course correction) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 14:26:20 -0000 Folks, Sorry. Meant to include a reference to a short commentary I wrote for a recent workshop that touched on this: Tailored Signatures with DOSETA Introduction What does a signature mean? In the paper world, it might mean authorization for a charge on a credit card, or acknowledgment that a letter has been received, or the sale of a house. The language surrounding the signature defines its meaning. In the digital world, existing signature mechanisms typically are not as flexible. The meaning is built into the specification for a particular signature and the effort to create a new type of signature is typically quite high. Consequently, there is a very small range of digital signatures performed on the Internet today. What if it were easy to define a new type of signature with new semantics? This is not an issue of basic algorithms, but of defining the semantics and the packaging, along with a small matter of a certificate authority, to start the trust hierarchy, and of deployment and use effort. DOmain SEcurity TAgging [DOSETA] provides this flexibility and ease. It is based on the core mechanisms from [DKIM], extracted into a library of protocol components that minimize the incremental effort to develop a purpose-built data signature mechanism. This protocol design library is used by a signature protocol designer to provide a high point of specification departure, primarily limited to definition of semantics and mapping from a template to the specifics of the environment for the new signature. -- Dave Crocker Brandenburg InternetWorking bbiw.net From d3e3e3@gmail.com Sat Jul 9 08:04:29 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D00421F87C8 for ; Sat, 9 Jul 2011 08:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.679 X-Spam-Level: X-Spam-Status: No, score=-105.679 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbO47LCrpX8s for ; Sat, 9 Jul 2011 08:04:28 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id C3DEE21F8799 for ; Sat, 9 Jul 2011 08:04:28 -0700 (PDT) Received: by yie30 with SMTP id 30so1308545yie.31 for ; Sat, 09 Jul 2011 08:04:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=/7ivzryRIb5ygPNMkXF4I6yyrJJTcdMzZMDeDmV9DBk=; b=b1EfmfqaJpv7tdkqISpF9bdtrrnSmojvggVjs8mPQq8HGh96e/2iWfCRF1lkN2KbUE Aq1RXiAfLr0zJNqqtRlkqNe9MW5ItMW2wntH3d/G5H1jSoV6B5OPb2WnKoAlVl8K68iq ufLW73piXczhnrYQSX5nFc0O7hg+Zr5vx719w= Received: by 10.150.59.12 with SMTP id h12mr2615450yba.92.1310223868179; Sat, 09 Jul 2011 08:04:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.83.3 with HTTP; Sat, 9 Jul 2011 08:04:07 -0700 (PDT) In-Reply-To: References: From: Donald Eastlake Date: Sat, 9 Jul 2011 11:04:07 -0400 Message-ID: To: Peter Gutmann , dcrocker@bbiw.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: saag@ietf.org Subject: Re: [saag] The meaning of a signature X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 15:04:29 -0000 Hi, On Sat, Jul 9, 2011 at 4:20 AM, Peter Gutmann w= rote: > Yoav Nir writes: > >>Well, yeah, and a pen-based signature means that at some point in time, >>someone used a pen or some other device with ink to scribble something >>remotely resembling letters on a page. > > No, the two are very, very different. =A0My signature and/or initials on = a > contract indicate my active participation in the contract-signing process= (and > if I really want to dispute it there's the standard questioned-documents > process and tons of legal precedent). I dunno. Seems to me that a digital signature can be almost exactly like your pen and ink signature on a document written in some language you didn't understand at all... > My digital "signature" on a document > doesn't necessarily indicate any participation in the process, even with = the > best possible intentions the fact that my PDF reader and your PDF reader > display different information means that we could end up signing differen= t > documents. =A0With pen and paper there's no way for someone to create an > absolutely perfect signature in my actual handwriting on a document witho= ut my > knowledge. =A0With a digital "signature" it's not that hard to do. =A0We = already > have widespread banker trojans that do exactly this (although without usi= ng > digital "sigs", but adding "sigs" wouldn't change anything). Well, the duplicability is about like sealing a document with your signet ring or, in many oriental countries, stamping it with you chop. And really, it is quite easy to produce a good visual forgery of a pen and ink signature. As has been noted in the case of FAX signatures, much of the security for real world transactions is very dependent on confirmation by other paths and the whole context in which the "signing" occurs. What about people who authorize others to sign for them or use rubber stamp signatures? Legally, in order to bind the signer, I believe that what you are thinking of as an elaborate, personal, and unique exercise of the signers muscles with pen and ink need only be *any mark* by which the signer intended to be legally bound. For example, if I were illiterate and made a very simple X mark intending to be bound, I would be legally bound thereby. Or if I were to authorize you to sign my signature, I would be bound thereby regardless of how similar or different it looks from when I sign it. Of course, proof might depend on witnesses, etc., but dependence on other factors to support or attack the credibility of a signature is always possible and sometimes necessary. > (Note that I've used the word "signature" in quotes above because it's re= ally > quite some way removed from a standard pen-and-paper signature. =A0Like > "nonrepudiation", it's another case of crypto guys hijacking a term with = a > well-established meaning for something with rather different semantics). > > I would feel quite comfortable going to court to defend a disputed > pen-and-paper signature. =A0I wouldn't ever want to become the test case = for > defending a disputed digital "signature" (unless I was one of the lawyers= ). Going back to the original question of a signatures meaning, it has essentially none unless it is within some system where the bits signed have a defined structure and a field giving the semantics. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street =A0Milford, MA 01757 USA =A0d3e3e3@gmail.com > Peter. > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From mouse@Sparkle.Rodents-Montreal.ORG Sat Jul 9 08:13:07 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 193CF21F861E for ; Sat, 9 Jul 2011 08:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.645 X-Spam-Level: X-Spam-Status: No, score=-10.645 tagged_above=-999 required=5 tests=[AWL=0.657, BAYES_00=-2.599, FUZZY_VPILL=0.687, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XT9SjR3eXf-9 for ; Sat, 9 Jul 2011 08:13:06 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE7D21F8610 for ; Sat, 9 Jul 2011 08:13:05 -0700 (PDT) Received: from localhost (localhost [[UNIX: localhost]]) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id LAA05229; Sat, 9 Jul 2011 11:13:03 -0400 (EDT) Date: Sat, 9 Jul 2011 11:13:03 -0400 (EDT) From: Mouse Message-Id: <201107091513.LAA05229@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Sat, 9 Jul 2011 10:52:24 -0400 (EDT) To: saag@ietf.org In-Reply-To: <4E186249.2060707@dcrocker.net> References: <4E17934C.8070905@dcrocker.net> <20110709022538.GA4308@mit.edu> <4E186249.2060707@dcrocker.net> Subject: Re: [saag] The meaning of a signature (mid-course correction) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 15:13:07 -0000 > Second, this thread is unfortunately a good demonstration of why > survey research is difficult. In spite of trying to ask the > questions carefully, the nature of what I am asking appears to have > been interpreted a bit differently than I intended. > [...] The issues of a signature's basic mechanics and validity are, > of course, essential, but I really meant to take all of that as a > given and, instead, ask more about the "why" (or the policy) of > different signatures. [...] > For example, when I sign a contract, the meaning of the signature is > commitment to the contract's terms and conditions. Yes, but that's because that's the nature of contracts, not the nature of (pen-and-paper) signatures. Digital signatures are no different. My take on it is that my digital signature on a bag-o'-bits has - at least roughly - the same meaning as my ink signature on a printed copy of that same bag-o'-bits. Depending on the content of those bits, it could mean assent to a contract, authentication and non-repudiation of a letter, or any of the various other things physical signatures mean. (The legal force of it, of course, remains to be determined; statute law has not caught up and case law *definitely* has not caught up.) > On the average, folk who see a signature on an email believe that the > signature is validating either or both of the author or the content > -- but then there are multiple possible meanings to "validating > content"...) These larger meanings are certainly the typical beliefs > about OpenPGP and S/MIME signatures. However note that it is > definitely NOT the correct interpretation for DKIM. Yeah. That's more like - to stretch an analogical point - the local postmaster's signature on an envelope saying (perhaps explicitly, perhaps by convention) that it really was sent by the person whose address appears in the return-address spot. (I think. I don't really know DKIM, but I don't think it signs over content, just headers.) The digital world is different; we shouldn't expect to find close meatspace analogies for everything digital signatures are good for, any more than we should expect to find digital analogies for everything physical signatures are good for (autographs might be an exmaple). > Yet the specs for S/MIME and OpenPGP imply, rather than define, their > meanings: >> but that a careful attacker could have changed the unauthenticated >> portions of the encrypted message >> id-aa is the arc with all new authenticated and unauthenticated >> attributes > But what does it mean to be authenticated? It doesn't say. No. It also doesn't say what it means to be "changed". "Authenticated" has a well-established meaning, both in normal English and a very closely related one as a technical term in cryptography; I see no need for the specs to quote those definitions any more than I see a need to define "attacker" or "portion". > So my survey is meant to ask after these broader semantics that are > commonly imparted to a signature for these two, popular > message-signing mechanisms. I don't use either, but I do occasionally use (pre-"Open") PGP. The meaning I usually intend, and expect others to understand, when I PGP-sign an email is "this really did come from me"; further meaning, if any, depends on the content of the email. I don't sign things other than email often enough to have any established conventions for them; the one time I can recall when I had occasion to do something of the sort, I didn't sign the other blob; rather, I embedded its hash as text in a signed email which explicitly stated what the meaning of the signature was ("By signing this email, I certify that..."). /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From d3e3e3@gmail.com Sat Jul 9 08:14:20 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE2F221F8783 for ; Sat, 9 Jul 2011 08:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.666 X-Spam-Level: X-Spam-Status: No, score=-104.666 tagged_above=-999 required=5 tests=[AWL=-1.067, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1dShohXx3hr for ; Sat, 9 Jul 2011 08:14:20 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB2221F8656 for ; Sat, 9 Jul 2011 08:14:20 -0700 (PDT) Received: by ywp31 with SMTP id 31so544308ywp.31 for ; Sat, 09 Jul 2011 08:14:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=UYwLzEIlhsBWAc6rstD1GnnRbqvpwgRm7Te9pZjaL5A=; b=Erfporq+vk9CsqubGG+CdXqIaTZh9Azlkzr0dKH1tsr4T7DEC1T6ebw2Wh9Baj1R0p YWop8vHk+wMXmCUN378OCXA3gJPZx2UFScN2sh+9hHDgKokSpk1I0ppDodha7/8WSFTQ F7T1pfLMDptRLVqNROlP/+xr4w03DtffhHIDE= Received: by 10.151.47.1 with SMTP id z1mr2860687ybj.35.1310224458082; Sat, 09 Jul 2011 08:14:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.83.3 with HTTP; Sat, 9 Jul 2011 08:13:58 -0700 (PDT) In-Reply-To: <4E186249.2060707@dcrocker.net> References: <4E17934C.8070905@dcrocker.net> <20110709022538.GA4308@mit.edu> <4E186249.2060707@dcrocker.net> From: Donald Eastlake Date: Sat, 9 Jul 2011 11:13:58 -0400 Message-ID: To: dcrocker@bbiw.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "saag@ietf.org" Subject: Re: [saag] The meaning of a signature (mid-course correction) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 15:14:21 -0000 On Sat, Jul 9, 2011 at 10:14 AM, Dave CROCKER wrote: > Folks, > > > ... > > For example, when I sign a contract, the meaning > of the signature is commitment to the contract's terms and conditions. Really? What if you write the word "Witness" above your signature? Or put it in a box with a date and time and the words "Time Certification"? What if the contract is clearly between named parties and your signature is at right angles in the margin, clearly legible, and corresponds to none of the parties in the contract? What if your signature is accompanied by words that appear to be written in a language other than the contract and of which the interpreter is ignorant? What if your signature is preceded by the words "Signed under protest" or words that purport to change some detail of the contract? What if ... Donald > > ... > > d/ > -- > > =A0Dave Crocker > =A0Brandenburg InternetWorking > =A0bbiw.net > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From mouse@Sparkle.Rodents-Montreal.ORG Sat Jul 9 08:20:47 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47FB621F87ED for ; Sat, 9 Jul 2011 08:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.316 X-Spam-Level: X-Spam-Status: No, score=-10.316 tagged_above=-999 required=5 tests=[AWL=-0.328, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTtfE8wERHDC for ; Sat, 9 Jul 2011 08:20:46 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC6321F87D5 for ; Sat, 9 Jul 2011 08:20:46 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id LAA05282; Sat, 9 Jul 2011 11:20:45 -0400 (EDT) Date: Sat, 9 Jul 2011 11:20:45 -0400 (EDT) From: Mouse Message-Id: <201107091520.LAA05282@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Sat, 9 Jul 2011 11:15:11 -0400 (EDT) To: saag@ietf.org In-Reply-To: <4E1864FE.5080403@dcrocker.net> References: <4E17934C.8070905@dcrocker.net> <20110709022538.GA4308@mit.edu> <4E186249.2060707@dcrocker.net> <4E1864FE.5080403@dcrocker.net> Subject: Re: [saag] The meaning of a signature (mid-course correction) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 15:20:47 -0000 > What if it were easy to define a new type of signature with new > semantics? This is not an issue of basic algorithms, but of defining > the semantics and the packaging, along with a small matter of a > certificate authority, to start the trust hierarchy, CA? Trust hierarchy?? To think that every signature needs to involve a CA and hierarchical trust is to severely restrict the idea already. I trust CAs and other hiearchical mechanisms substantially less than I trust non-hierarchical mechanisms such a PGP signatures or ssh identities. (ssh identities are actually an interesting case, often (usually?) depending on signatures in the cryptographic-technical sense but not in the wider sense you seem to be talking about here.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From dhc2@dcrocker.net Sat Jul 9 10:15:39 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A93621F88AC for ; Sat, 9 Jul 2011 10:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NXxCxKbsipOh for ; Sat, 9 Jul 2011 10:15:39 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1621C21F88AB for ; Sat, 9 Jul 2011 10:15:39 -0700 (PDT) Received: from [192.168.1.156] (adsl-67-124-149-98.dsl.pltn13.pacbell.net [67.124.149.98]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p69HFVIV001382 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sat, 9 Jul 2011 10:15:36 -0700 Message-ID: <4E188CAB.1010302@dcrocker.net> Date: Sat, 09 Jul 2011 10:15:23 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Donald Eastlake References: <4E17934C.8070905@dcrocker.net> <20110709022538.GA4308@mit.edu> <4E186249.2060707@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sat, 09 Jul 2011 10:15:37 -0700 (PDT) Cc: "saag@ietf.org" Subject: Re: [saag] The meaning of a signature (mid-course correction) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 17:15:39 -0000 On 7/9/2011 8:13 AM, Donald Eastlake wrote: > On Sat, Jul 9, 2011 at 10:14 AM, Dave CROCKER wrote: >> Folks, >> >> >> ... >> >> For example, when I sign a contract, the meaning >> of the signature is commitment to the contract's terms and conditions. > > Really? What if you write the word "Witness" above your signature? Or > put it in a box with a date and time and the words "Time > Certification"? What I particularly like about your response is that while it correctly demonstrates the problem with my loose phrasing, it also demonstrates the correctness of the issue I am asking about. What you highlighted are different meanings. If alternate phrasing will help, folks should try this: What is the intended meaning of a duly authorized actor when they affix a signature? So, take it as a given that all of the basics of proper and robust digital signature mechanics have been performed and that, for example, non-repudiation of originator is not an issue. Besides knowing that you can trust the bits weren't changed between signing and verifying, WHY did that duly authorized agent sign the thing? I believe that most recipients of an email signed with OpenPGP or S/MIME believe that verification means that the signer was the author of the message or that the signer has vetted the authenticity of the From: field. By contrast, DKIM states an entirely different meaning. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nico@cryptonector.com Sat Jul 9 11:42:23 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 999D421F8901 for ; Sat, 9 Jul 2011 11:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.783 X-Spam-Level: X-Spam-Status: No, score=-2.783 tagged_above=-999 required=5 tests=[AWL=-0.806, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZIjflTFd+5C for ; Sat, 9 Jul 2011 11:42:23 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 1C45B21F8702 for ; Sat, 9 Jul 2011 11:42:23 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTP id C381B77805B for ; Sat, 9 Jul 2011 11:42:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=fTTq8oeID4xIzCgTsovNw Eio/JqxVeWRxBFk4XzU94hLz+eDc0qKOZP0fUm5TYtHN2uNrTgx1Yy6sYXvpK4a5 AQ84TMOEtLFux0/5TBwfTWjAX+j3hyEsbMm0RTR3hdp9wN9R29s0EsSY2ompXuLZ ZdJ15g7wniatXAjStYGJxI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=8253U8/K2KP0Jh537Fbm cITGMGY=; b=VkTWPU1VfjESMTvERik92tbZDr3EMR9armRW67sH9HJO0VwNvtHA JzrG1l4SZqcq2Njb0mcfwwz4kZgY0jSckmkoP1BeM7E6e4/B93yqtuBhwh9J+ICy qGC0S7ojydXn7Nl6NTEfNVC+ViL0nSlm8p1bc+f0WlYXQXty/qen+dc= Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTPSA id A613A778057 for ; Sat, 9 Jul 2011 11:42:21 -0700 (PDT) Received: by pwj5 with SMTP id 5so1382544pwj.31 for ; Sat, 09 Jul 2011 11:42:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.66.130 with SMTP id f2mr3303814pbt.521.1310236941215; Sat, 09 Jul 2011 11:42:21 -0700 (PDT) Received: by 10.68.50.231 with HTTP; Sat, 9 Jul 2011 11:42:21 -0700 (PDT) In-Reply-To: <4E186249.2060707@dcrocker.net> References: <4E17934C.8070905@dcrocker.net> <20110709022538.GA4308@mit.edu> <4E186249.2060707@dcrocker.net> Date: Sat, 9 Jul 2011 13:42:21 -0500 Message-ID: From: Nico Williams To: dcrocker@bbiw.net Content-Type: text/plain; charset=UTF-8 Cc: "saag@ietf.org" Subject: Re: [saag] The meaning of a signature (mid-course correction) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 18:42:23 -0000 The semantics of a digital signature on a blob of bits is what we say it is. Specifically it depends on a) the semantics of the bits being signed, b) the semantics of the signer's public key (i.e., how we associate a private/public key pair with some entity that we agree can sign things, and what we allow that that key pair to be used for). (a) is relevant whether the blob of bits is signed or not, though we might ascribe different semantics to that blob depending on whether it is signed, and by what key (e.g., a piece of legislation has different meaning when it is signed by the relevant executive officer versus when it's awaiting the executive's signature or veto, and not just anyone could sign it and transform it into law). Being able to recognize what type of blob of bits that blob is is critical to understanding its semantics. Sometimes the context matters, but when the meaning of a digitally signed blob depends on context then you have to worry about the context changing. Now throw in everything else that's been said (e.g., about how weak hashes are often used) :) I do see significant parallels to meatspace. It is always important to define the semantics of these things. We don't necessarily have to be rigorous (so PGP and S/MIME say little about who is authenticated and what that means? but if most people derive a good enough meaning from the words themselves, that's probably good enough) but it probably helps to be. Nico -- From sommerfeld@alum.mit.edu Sat Jul 9 13:45:55 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD2421F8A54 for ; Sat, 9 Jul 2011 13:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G6FBcUPrmMGN for ; Sat, 9 Jul 2011 13:45:55 -0700 (PDT) Received: from portal.hamachi.org (portal.hamachi.org [69.25.196.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9578B21F8A0D for ; Sat, 9 Jul 2011 13:45:52 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by portal.hamachi.org (Postfix) with ESMTP id 97A0D17936; Sat, 9 Jul 2011 16:45:50 -0400 (EDT) Message-ID: <4E18BDFD.4000100@alum.mit.edu> Date: Sat, 09 Jul 2011 13:45:49 -0700 From: Bill Sommerfeld User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.4) Gecko/20100719 Lightning/1.0b2 Thunderbird/3.1 MIME-Version: 1.0 To: saag@ietf.org References: <4E17934C.8070905@dcrocker.net> <20110709022538.GA4308@mit.edu> <4E186249.2060707@dcrocker.net> <4E188CAB.1010302@dcrocker.net> In-Reply-To: <4E188CAB.1010302@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [saag] The meaning of a signature (mid-course correction) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 20:45:55 -0000 On 07/09/11 10:15, Dave CROCKER wrote: > What is the intended meaning of a duly authorized actor > when they affix a [digital] signature? Short answer: It depends. Longer answer: It depends on what the key-holder (or someone authorized to act on their behalf) has previously said about the meaning of signatures with that key. IMHO the "extended key usage" x.509 attribute touches on this question; see, for instance, http://tools.ietf.org/html/rfc5280#section-4.2.1.12 If an entity wants to distinguish two different reasons for signing something, it's best if it uses separate keys for these two purposes. My quick feedback on: http://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_1.pdf is that I disagree with your advice to use the same key for multiple purposes. - Bill From touch@isi.edu Sat Jul 9 17:59:13 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1757721F8A0B for ; Sat, 9 Jul 2011 17:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.202 X-Spam-Level: X-Spam-Status: No, score=-102.202 tagged_above=-999 required=5 tests=[AWL=-0.999, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIH08CYqiOR6 for ; Sat, 9 Jul 2011 17:59:12 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id A632721F8A13 for ; Sat, 9 Jul 2011 17:59:12 -0700 (PDT) Received: from [192.168.1.90] (pool-71-105-81-169.lsanca.dsl-w.verizon.net [71.105.81.169]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id p6A0wa39009006 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 9 Jul 2011 17:58:40 -0700 (PDT) References: <4E17934C.8070905@dcrocker.net> <20110709022538.GA4308@mit.edu> <4E186249.2060707@dcrocker.net> <4E188CAB.1010302@dcrocker.net> In-Reply-To: <4E188CAB.1010302@dcrocker.net> Mime-Version: 1.0 (iPhone Mail 8J2) Content-Type: text/plain; charset=us-ascii Message-Id: <8B83C2A2-DBE9-4C68-9827-723D6C2A36A9@isi.edu> Content-Transfer-Encoding: quoted-printable X-Mailer: iPhone Mail (8J2) From: Joe Touch Date: Sat, 9 Jul 2011 17:58:34 -0700 To: "dcrocker@bbiw.net" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "saag@ietf.org" Subject: Re: [saag] The meaning of a signature (mid-course correction) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 00:59:13 -0000 On Jul 9, 2011, at 10:15 AM, Dave CROCKER wrote: >=20 >=20 > On 7/9/2011 8:13 AM, Donald Eastlake wrote: >> On Sat, Jul 9, 2011 at 10:14 AM, Dave CROCKER wrote: >>> Folks, >>>=20 >>>=20 >>> ... >>>=20 >>> For example, when I sign a contract, the meaning >>> of the signature is commitment to the contract's terms and conditions. >>=20 >> Really? What if you write the word "Witness" above your signature? Or >> put it in a box with a date and time and the words "Time >> Certification"? >=20 > What I particularly like about your response is that while it correctly de= monstrates the problem with my loose phrasing, it also demonstrates the corr= ectness of the issue I am asking about. >=20 > What you highlighted are different meanings. >=20 > If alternate phrasing will help, folks should try this: >=20 > What is the intended meaning of a duly authorized actor > when they affix a signature? That is usually specified *inside* the doc being signed.=20 I've recently signed legal docs digitally, where the method included "type t= his number in to confirm the terms". It's all about the contract itself, as w= ith a pen and ink dignature.=20 Joe= From touch@isi.edu Sat Jul 9 22:55:18 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F61421F8A2F for ; Sat, 9 Jul 2011 22:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.937 X-Spam-Level: X-Spam-Status: No, score=-103.937 tagged_above=-999 required=5 tests=[AWL=-1.338, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id humhXNqlkevR for ; Sat, 9 Jul 2011 22:55:17 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 1946C21F8A1B for ; Sat, 9 Jul 2011 22:55:17 -0700 (PDT) Received: from [128.9.176.29] (c1-vpn3.isi.edu [128.9.176.29]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id p6A5sseH004460 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Sat, 9 Jul 2011 22:54:55 -0700 (PDT) Message-ID: <4E193EAE.1010803@isi.edu> Date: Sat, 09 Jul 2011 22:54:54 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "dcrocker@bbiw.net" References: <4E17934C.8070905@dcrocker.net> <20110709022538.GA4308@mit.edu> <4E186249.2060707@dcrocker.net> <4E188CAB.1010302@dcrocker.net> <8B83C2A2-DBE9-4C68-9827-723D6C2A36A9@isi.edu> In-Reply-To: <8B83C2A2-DBE9-4C68-9827-723D6C2A36A9@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "saag@ietf.org" Subject: Re: [saag] The meaning of a signature (mid-course correction) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 05:55:18 -0000 Hi, all, To summarize my view: 1) a digital signature's meaning regarding the doc is determined by the doc, as with *any* signature i.e., the doc typically says "the undersigned agrees to..." or "by signing I, (name), affirm that...", or somesuch. When it's not stated explicitly, it's implicit in the type of document. A lawyer would provide more context on the specifics of explicit and implicit meaning like this. 2) the signature itself represents a capability against forgery, just like any other signature; the extent of that capability depends on the nature of the signature itself - just like with pen-and-ink signatures. I.e., an "X" suffices in some contexts where the "CA" is known or assumed (e.g., a witness, or in the presence of an executor, etc.); in other cases, the CA needs to be further authenticated (e.g., a notary). Sometimes self-asserted times are sufficient; other times, events are printed as notice (e.g., legal notices in newspapers) None of this seems to be particularly interesting or new for digital signatures, AFAICT. Joe On 7/9/2011 5:58 PM, Joe Touch wrote: > > > On Jul 9, 2011, at 10:15 AM, Dave CROCKER wrote: > >> >> >> On 7/9/2011 8:13 AM, Donald Eastlake wrote: >>> On Sat, Jul 9, 2011 at 10:14 AM, Dave CROCKER wrote: >>>> Folks, >>>> >>>> >>>> ... >>>> >>>> For example, when I sign a contract, the meaning >>>> of the signature is commitment to the contract's terms and conditions. >>> >>> Really? What if you write the word "Witness" above your signature? Or >>> put it in a box with a date and time and the words "Time >>> Certification"? >> >> What I particularly like about your response is that while it correctly demonstrates the problem with my loose phrasing, it also demonstrates the correctness of the issue I am asking about. >> >> What you highlighted are different meanings. >> >> If alternate phrasing will help, folks should try this: >> >> What is the intended meaning of a duly authorized actor >> when they affix a signature? > > That is usually specified *inside* the doc being signed. > > I've recently signed legal docs digitally, where the method included "type this number in to confirm the terms". It's all about the contract itself, as with a pen and ink dignature. > > Joe From jon@callas.org Sat Jul 9 23:00:21 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0964521F8AB8 for ; Sat, 9 Jul 2011 23:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.589 X-Spam-Level: * X-Spam-Status: No, score=1.589 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FUZZY_VPILL=0.687, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YaIOkkJ3Ibth for ; Sat, 9 Jul 2011 23:00:20 -0700 (PDT) Received: from merrymeet.com (unknown [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id 3D14F21F86ED for ; Sat, 9 Jul 2011 23:00:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by merrymeet.com (Postfix) with ESMTP id 3DF922E0B1; Sat, 9 Jul 2011 23:01:21 -0700 (PDT) Received: from merrymeet.com ([127.0.0.1]) by localhost (host.domain.tld [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 74976-01; Sat, 9 Jul 2011 23:01:17 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTPA id 9B81F2E071; Sat, 9 Jul 2011 23:01:17 -0700 (PDT) Received: from [10.0.137.2] ([208.73.12.228]) by keys.merrymeet.com (PGP Universal service); Sat, 09 Jul 2011 23:00:16 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Sat, 09 Jul 2011 23:00:16 -0700 References: <4E17934C.8070905@dcrocker.net> <20110709022538.GA4308@mit.edu> <4E186249.2060707@dcrocker.net> In-Reply-To: <4E186249.2060707@dcrocker.net> Mime-Version: 1.0 (iPad Mail 8J3) Message-Id: <6E28ED3F-A0E1-4A4F-B680-92D44A158A42@callas.org> X-Mailer: iPad Mail (8J3) From: Jon Callas Date: Sat, 9 Jul 2011 23:01:58 -0700 To: "dcrocker@bbiw.net" Content-Type: multipart/alternative; boundary=Apple-Mail-4--889444501 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard Cc: "saag@ietf.org" Subject: Re: [saag] The meaning of a signature (mid-course correction) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 06:00:21 -0000 --Apple-Mail-4--889444501 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dave, I a bit late to the party, but here are a few comments.=20 Over a decade ago, Bruce Schneier and I wrote an article called "Why digital= signatures are not signatures" for The Industry Standard. I know there is a= version of that article on Bruce's web site still. Many of the points we ma= de in it have been made by Peter Gutmann and others, but I both refer you to= that article and want to say some more.=20 First, a digital signature and an ink signature are not the same thing at al= l. A digital signature is a thing, an ink signature is an act. If I sign (wi= th ink) a contract or credit card receipt, it is the act that makes it legal= , not the ink. It doesn't matter what you sign, it is the fact that you sign= ed it. An "X" at the bottom, properly authenticated is completely legal and b= inding. I commonly sign those touch screen, so-called electronic signature t= hings with the word "Signature". That is completely legal and binding. Agai= n, it doesn't matter what you sign, it matters that *you* sign it.=20 In contrast, a digital signature is a thing, more akin to a seal than a sign= ature, and the world would be a better place if digital signatures had been c= alled seals rather than signatures.=20 Everyone intuitively knows that if you put an ink image exactly like a signa= ture on a document, the person whose signature that is did not sign the docu= ment. Yet, us techie types would say that if you produce a document that col= lides with another, then they are both digitally signed.=20 We all know that there is no danger in lending someone your pen, but we all k= now that there is danger in letting someone else use your private key.=20 If we consider a signed contract, what makes it important is not that it is s= igned, it is that it is a contract. If you write a contract on a page with a= n autograph, it is not suddenly valid. But if you find bits that hash to the= right thing, then the digital signature is valid. Or is it? The real question you are asking is about symantics and the standards you qu= ote are all about syntax. I know that OpenPGP intentionally punted the seman= tic question. That is why "authenticated" and related terms are not defined.= What they mean depends on semantics, not on syntax.=20 The person who quoted Humpty Dumpty from Alice probably has the best answer.= A signature means what it is agreed upon to mean, nothing more and nothing l= ess. These is a very real sense in which trying to add meaning to a digital s= ignature is fraud in the very same way that writing a contract around a page= with an autograph is fraud. Of course, fraud itself is a semantic thing, be= cause it is a term that we use to describe an abuse of signatures and authen= tication and so on.=20 DKIM differs from other signature standards in that it at least tries to add= ress the semantic issue. It may be a bit squishy, but it doesn't punt the is= sue.=20 It is entirely possible that this message is signed in OpenPGP format with m= y key. In fact, I will go so far as to say that it probably is signed. My PG= P Universal server is set up to sign lots of my messages. I think it will si= gn this one. Let us just assume it is signed.=20 What does the signature mean? Does it mean that I wrote it? Does it mean I b= elieve what is in this message? Does it mean I am somehow bound by its conte= nt? Something else? The answer depends completely on the semantic content of= this message as well as the constellation of human events surrounding it.=20= Perhaps belaboring the point, if I sign a card that reads "all the best to y= ou in the joyful holiday season" I'm really only sending a card. It resemble= s what DKIM means more than any discussion of contract law. The signed card m= eans whatever it means because there is no semantic social context surroundi= ng what cards mean. A card is not a contract because a card is not a contrac= t. This signed email means whatever a signed email means.=20 Jon Sent from my iPad --Apple-Mail-4--889444501 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Dave,

I a= bit late to the party, but here are a few comments. 

Over a decade ago, Bruce Schneier and I wrote an article called "Why= digital signatures are not signatures" for The Industry Standard. I know th= ere is a version of that article on Bruce's web site still. Many of the poin= ts we made in it have been made by Peter Gutmann and others, but I both refe= r you to that article and want to say some more. 

<= div>First, a digital signature and an ink signature are not the same thing a= t all. A digital signature is a thing, an ink signature is an act. If I sign= (with ink) a contract or credit card receipt, it is the act that makes it l= egal, not the ink. It doesn't matter what you sign, it is the fact that you s= igned it. An "X" at the bottom, properly authenticated is completely legal a= nd binding. I commonly sign those touch screen, so-called electronic signatu= re things with the word "Signature".  That is completely legal and bind= ing. Again, it doesn't matter what you sign, it matters that *you* sign it.&= nbsp;

In contrast, a digital signature is a thing, m= ore akin to a seal than a signature, and the world would be a better place i= f digital signatures had been called seals rather than signatures. 

Everyone intuitively knows that if you put an ink imag= e exactly like a signature on a document, the person whose signature that is= did not sign the document. Yet, us techie types would say that if you produ= ce a document that collides with another, then they are both digitally signe= d. 

We all know that there is no danger in len= ding someone your pen, but we all know that there is danger in letting someo= ne else use your private key. 

If we consider a signe= d contract, what makes it important is not that it is signed, it is that it i= s a contract. If you write a contract on a page with an autograph, it is not= suddenly valid. But if you find bits that hash to the right thing, then the= digital signature is valid. Or is it?

The real que= stion you are asking is about symantics and the standards you quote are all a= bout syntax. I know that OpenPGP intentionally punted the semantic question.= That is why "authenticated" and related terms are not defined. What they me= an depends on semantics, not on syntax. 

The p= erson who quoted Humpty Dumpty from Alice probably has the best answer. A si= gnature means what it is agreed upon to mean, nothing more and nothing less.= These is a very real sense in which trying to add meaning to a digital sign= ature is fraud in the very same way that writing a contract around a page wi= th an autograph is fraud. Of course, fraud itself is a semantic thing, becau= se it is a term that we use to describe an abuse of signatures and authentic= ation and so on. 

DKIM differs from other sign= ature standards in that it at least tries to address the semantic issue. It m= ay be a bit squishy, but it doesn't punt the issue. 

It is entirely possible that this message is signed in OpenPGP format= with my key. In fact, I will go so far as to say that it probably is signed= . My PGP Universal server is set up to sign lots of my messages. I think it w= ill sign this one. Let us just assume it is signed. 

What does the signature mean? Does it mean that I wrote it? Does it m= ean I believe what is in this message? Does it mean I am somehow bound by it= s content? Something else? The answer depends completely on the semantic con= tent of this message as well as the constellation of human events surroundin= g it. 

Perhaps belaboring the point, if I sign= a card that reads "all the best to you in the joyful holiday season" I'm re= ally only sending a card. It resembles what DKIM means more than any discuss= ion of contract law. The signed card means whatever it means because there i= s no semantic social context surrounding what cards mean. A card is not a co= ntract because a card is not a contract. This signed email means whatever a s= igned email means. 

Jon

Sent fro= m my iPad

=
= --Apple-Mail-4--889444501-- From pgut001@login01.cs.auckland.ac.nz Sat Jul 9 23:29:13 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DDC721F8959 for ; Sat, 9 Jul 2011 23:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.71 X-Spam-Level: X-Spam-Status: No, score=-3.71 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JrXv7iIxzIJF for ; Sat, 9 Jul 2011 23:29:12 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA7D21F892E for ; Sat, 9 Jul 2011 23:29:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1310279353; x=1341815353; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20dcrocker@bbiw.net,=20jon@callas.org|Subject:=20Re: =20[saag]=20The=20meaning=20of=20a=20signature=20=20(mid- course=20correction)|Cc:=20saag@ietf.org|In-Reply-To:=20< 6E28ED3F-A0E1-4A4F-B680-92D44A158A42@callas.org> |Message-Id:=20|Date:=20Sun,=2010=20Jul=202011=2018:29:01=20+1200; bh=xQsemQsy/TT5VYdGrAH+6ArWBTBBiD7LUqsnoSt4aI4=; b=H3+1k4n6qW+BTI2TEHyxcxztRnmdVThtRpRzw6iI9flnbiQDGIKE0RJZ VqjQdVfA9sR8UtIuEvzHQZFIpmgF6z55ft4tpryScHQyU014scDa9+vRV d4O5Hpuz83qhjXigF2FF32N7K44fbKlXNvwBbtlQKdmiHqmePv4eEPt01 8=; X-IronPort-AV: E=Sophos;i="4.65,507,1304251200"; d="scan'208";a="70985708" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 10 Jul 2011 18:29:02 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QfnVl-0002fb-HI; Sun, 10 Jul 2011 18:29:01 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QfnVl-0001EP-AN; Sun, 10 Jul 2011 18:29:01 +1200 From: Peter Gutmann To: dcrocker@bbiw.net, jon@callas.org In-Reply-To: <6E28ED3F-A0E1-4A4F-B680-92D44A158A42@callas.org> Message-Id: Date: Sun, 10 Jul 2011 18:29:01 +1200 Cc: saag@ietf.org Subject: Re: [saag] The meaning of a signature (mid-course correction) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 06:29:13 -0000 Jon Callas writes: >In contrast, a digital signature is a thing, more akin to a seal than a >signature, and the world would be a better place if digital signatures had >been called seals rather than signatures. I would call what's discussed in crypto texts and standards "assertions" rather than "seals": "Bob presents the signature to the judge and the judge says 'Clearly Alice is guilty'", when what'll really happen is that the 60- year-old judge with the liberal arts degree will peer at Bob through his tri- focals and say "Huh?". Just as a general question (not specifically addressed to Jon), hasn't all this material been done to death 10-15 years ago? I'm kinda surprised to see it all coming up again now, rather than people just referring to the huge amount of stuff that's been written about this in the past (including quite a bit by real, live lawyers who actually know how this works under law rather than on a whiteboard) >A signature means what it is agreed upon to mean, nothing more and nothing >less. Exactly. The original question was far too vague, like asking how long is a piece of string. For what purposes are you signing, who are the relying parties, what do they expect from a signature, how much is at stake, under what conditions are the sigs generated and verified, does it need to stand up in court (the acid test that differentiates a real "signature" from a mere assertion) in which case you need to ask lawyers and not security geeks, etc. Peter. From ynir@checkpoint.com Sat Jul 9 23:49:31 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30CEF21F887C for ; Sat, 9 Jul 2011 23:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.589 X-Spam-Level: X-Spam-Status: No, score=-10.589 tagged_above=-999 required=5 tests=[AWL=-0.677, BAYES_00=-2.599, FUZZY_VPILL=0.687, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtz5p5wgENs4 for ; Sat, 9 Jul 2011 23:49:30 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id AB6D121F87C2 for ; Sat, 9 Jul 2011 23:49:24 -0700 (PDT) X-CheckPoint: {4E19592D-6-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p6A6mtnP009604; Sun, 10 Jul 2011 09:48:55 +0300 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Sun, 10 Jul 2011 09:48:55 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Sun, 10 Jul 2011 09:48:54 +0300 From: Yoav Nir To: Jon Callas Date: Sun, 10 Jul 2011 09:48:52 +0300 Thread-Topic: [saag] The meaning of a signature (mid-course correction) Thread-Index: Acw+zW9oSlghiUqyTYiUNOtNIRe7HA== Message-ID: <62599540-BE9A-4305-8EDC-1DF852DE03B4@checkpoint.com> References: <4E17934C.8070905@dcrocker.net> <20110709022538.GA4308@mit.edu> <4E186249.2060707@dcrocker.net> <6E28ED3F-A0E1-4A4F-B680-92D44A158A42@callas.org> In-Reply-To: <6E28ED3F-A0E1-4A4F-B680-92D44A158A42@callas.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dcrocker@bbiw.net" , "saag@ietf.org" Subject: Re: [saag] The meaning of a signature (mid-course correction) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 06:49:31 -0000 On Jul 10, 2011, at 9:01 AM, Jon Callas wrote: > Dave, >=20 > I a bit late to the party, but here are a few comments.=20 >=20 > Over a decade ago, Bruce Schneier and I wrote an article called "Why digi= tal signatures are not signatures" for The Industry Standard. I know there = is a version of that article on Bruce's web site still. Many of the points = we made in it have been made by Peter Gutmann and others, but I both refer = you to that article and want to say some more.=20 >=20 > First, a digital signature and an ink signature are not the same thing at= all. A digital signature is a thing, an ink signature is an act. If I sign= (with ink) a contract or credit card receipt, it is the act that makes it = legal, not the ink. It doesn't matter what you sign, it is the fact that yo= u signed it. An "X" at the bottom, properly authenticated is completely leg= al and binding. I commonly sign those touch screen, so-called electronic si= gnature things with the word "Signature". That is completely legal and bin= ding. Again, it doesn't matter what you sign, it matters that *you* sign it= .=20 >=20 > In contrast, a digital signature is a thing, more akin to a seal than a s= ignature, and the world would be a better place if digital signatures had b= een called seals rather than signatures.=20 That depends. A digital signature on a bag-o-bits is a thing. An ink signat= ure on a page you have received through the mail, the fax machine or a scan= ned image sent in email is just as much a thing as a digital signature. If = I see you applying a digital signature to a bag-o-bits, it becomes an act a= s well, although that's not the usual way of using digital signatures. >=20 > Everyone intuitively knows that if you put an ink image exactly like a si= gnature on a document, the person whose signature that is did not sign the = document. Yet, us techie types would say that if you produce a document tha= t collides with another, then they are both digitally signed.=20 No, they're not. The "MD5 Collisions Inc." was not a properly signed certif= icate. It was just a perfect forgery. > We all know that there is no danger in lending someone your pen, but we a= ll know that there is danger in letting someone else use your private key.= =20 You can't generate a signature identical to mine with my pen. You need my h= and (or is it the wrist). That's a technological difference, not an essenti= al one.=20 >=20 > If we consider a signed contract, what makes it important is not that it = is signed, it is that it is a contract. If you write a contract on a page w= ith an autograph, it is not suddenly valid. But if you find bits that hash = to the right thing, then the digital signature is valid. Or is it? No. You're just a clever cryptographer, similar to people who can forge any= body's signature. > The real question you are asking is about symantics and the standards you= quote are all about syntax. I know that OpenPGP intentionally punted the s= emantic question. That is why "authenticated" and related terms are not def= ined. What they mean depends on semantics, not on syntax.=20 >=20 > The person who quoted Humpty Dumpty from Alice probably has the best answ= er. A signature means what it is agreed upon to mean, nothing more and noth= ing less. These is a very real sense in which trying to add meaning to a di= gital signature is fraud in the very same way that writing a contract aroun= d a page with an autograph is fraud. Of course, fraud itself is a semantic = thing, because it is a term that we use to describe an abuse of signatures = and authentication and so on.=20 >=20 > DKIM differs from other signature standards in that it at least tries to = address the semantic issue. It may be a bit squishy, but it doesn't punt th= e issue.=20 >=20 > It is entirely possible that this message is signed in OpenPGP format wit= h my key. In fact, I will go so far as to say that it probably is signed. M= y PGP Universal server is set up to sign lots of my messages. I think it wi= ll sign this one. Let us just assume it is signed.=20 >=20 > What does the signature mean? Does it mean that I wrote it? Does it mean = I believe what is in this message? Does it mean I am somehow bound by its c= ontent? Something else? The answer depends completely on the semantic conte= nt of this message as well as the constellation of human events surrounding= it.=20 >=20 > Perhaps belaboring the point, if I sign a card that reads "all the best t= o you in the joyful holiday season" I'm really only sending a card. It rese= mbles what DKIM means more than any discussion of contract law. The signed = card means whatever it means because there is no semantic social context su= rrounding what cards mean. A card is not a contract because a card is not a= contract. This signed email means whatever a signed email means.=20 Isn't it binding? I wonder is somebody has ever tried to sue a card sender= if their holiday season was not joyful. From ynir@checkpoint.com Sun Jul 10 00:08:33 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6EF21F89B6 for ; Sun, 10 Jul 2011 00:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.763 X-Spam-Level: X-Spam-Status: No, score=-10.763 tagged_above=-999 required=5 tests=[AWL=-0.164, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G0H5ZtCs-M0N for ; Sun, 10 Jul 2011 00:08:31 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 0963421F89AC for ; Sun, 10 Jul 2011 00:08:30 -0700 (PDT) X-CheckPoint: {4E195DA8-2-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p6A77r8G012334; Sun, 10 Jul 2011 10:07:53 +0300 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Sun, 10 Jul 2011 10:07:53 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Sun, 10 Jul 2011 10:07:52 +0300 From: Yoav Nir To: Peter Gutmann Date: Sun, 10 Jul 2011 10:07:50 +0300 Thread-Topic: [saag] The meaning of a signature (mid-course correction) Thread-Index: Acw+0BVIra1VIZNrRHqynjymh3lW0Q== Message-ID: <2914347B-8681-4E41-868D-DF6EF6A1D1E0@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "saag@ietf.org" , "dcrocker@bbiw.net" Subject: Re: [saag] The meaning of a signature (mid-course correction) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 07:08:33 -0000 On Jul 10, 2011, at 9:29 AM, Peter Gutmann wrote: > Jon Callas writes: >=20 >> In contrast, a digital signature is a thing, more akin to a seal than a >> signature, and the world would be a better place if digital signatures h= ad >> been called seals rather than signatures. >=20 > I would call what's discussed in crypto texts and standards "assertions" > rather than "seals": "Bob presents the signature to the judge and the jud= ge > says 'Clearly Alice is guilty'", when what'll really happen is that the 6= 0- > year-old judge with the liberal arts degree will peer at Bob through his = tri- > focals and say "Huh?". Bob doesn't present ink-based signatures either. If there's an actual case = where Bob has a signed document and Alice claims she never signed it, then = either Bob has to testify that he saw Alice sign the document, or he has to= bring in an expert witness. This is true regardless of whether the expert = witness is a handwriting expert or a crypto expert. The judge will not cons= ider himself an expert on either. In practice this kind of court case is rare. The cases are usually about th= e semantics of the contract rather than the history of the signature. >=20 > Just as a general question (not specifically addressed to Jon), hasn't al= l > this material been done to death 10-15 years ago? I'm kinda surprised to= see > it all coming up again now, rather than people just referring to the huge > amount of stuff that's been written about this in the past (including qui= te a > bit by real, live lawyers who actually know how this works under law rath= er > than on a whiteboard) Yes, it's been done to death, but no, there hasn't been a good answer from = all this doing to death. We know that digital signatures are merely an anti= -counterfeiting measure, much like seals. We know that courts have ruled th= at clicking a button (with zero bits of security) is equivalent to a signat= ure ("the software is installed --> the user clicked the EULA --> the user = agreed to all the terms in the EULA --> The user must hand over his firstbo= rn son to us. QED"). Similarly, clicking a button that says "proceed to ch= eckout" is good enough for online stores to take money from me. Yes, I can = deny I made the transaction and get the money back, but that just means tha= t it's easy to make it seem like I entered the agreement when I didn't. It = doesn't mean that clicking that button is not equivalent to a signature. Si= milar things exist with mail-order catalog orders, where the signatures are= all pen-based. It could be that in some jurisdiction (or maybe in the future) it would be = harder to deny a signature made with a private key than it would be to deny= a signature made by clicking a button. But that is just because of the rel= ative ease of forging one vs forging the other. All three are valid ways to= sign contracts. From pgut001@login01.cs.auckland.ac.nz Sun Jul 10 09:00:28 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C39421F86D0 for ; Sun, 10 Jul 2011 09:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.699 X-Spam-Level: X-Spam-Status: No, score=-3.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9BkmskFcX9iA for ; Sun, 10 Jul 2011 09:00:26 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id A4F2221F86C6 for ; Sun, 10 Jul 2011 09:00:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1310313627; x=1341849627; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20pgut001@cs.auckland.ac.nz,=20ynir@checkpoint.com |Subject:=20Re:=20[saag]=20The=20meaning=20of=20a=20signa ture=20=20(mid-course=20correction)|Cc:=20dcrocker@bbiw.n et,=20jon@callas.org,=20saag@ietf.org|In-Reply-To:=20<291 4347B-8681-4E41-868D-DF6EF6A1D1E0@checkpoint.com> |Message-Id:=20|Date:=20Mon,=2011=20Jul=202011=2004:00:23=20+1200; bh=lBxVRYBxnNJ4VTbbjlZJRsLB7OeDv3DG2YTl9AeJmBI=; b=fiP/07lKj7PcKcFQHKwNapjdDEoPqVS37ENNhGdqu7A3V9g1lYPry1CB +4mWmS0VjLKr7tVZIIV3N4lYnoJncKoMGbct2DT251o2hk/M/EcaE5+1F 34af+cQGytWQwEEhq/Qs+kZCYZrOz8UI54os5OyLWGpohehfqo6dOPRtH k=; X-IronPort-AV: E=Sophos;i="4.65,509,1304251200"; d="scan'208";a="71008008" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 11 Jul 2011 04:00:24 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QfwQi-0000ks-GF; Mon, 11 Jul 2011 04:00:24 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QfwQh-0003GR-W4; Mon, 11 Jul 2011 04:00:24 +1200 From: Peter Gutmann To: pgut001@cs.auckland.ac.nz, ynir@checkpoint.com In-Reply-To: <2914347B-8681-4E41-868D-DF6EF6A1D1E0@checkpoint.com> Message-Id: Date: Mon, 11 Jul 2011 04:00:23 +1200 Cc: saag@ietf.org, dcrocker@bbiw.net Subject: Re: [saag] The meaning of a signature (mid-course correction) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 16:00:28 -0000 Yoav Nir writes: >Yes, it's been done to death, but no, there hasn't been a good answer from >all this doing to death. I would call that a pretty conclusive answer then. Peter. From turners@ieca.com Sun Jul 10 09:38:13 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF9621F869E for ; Sun, 10 Jul 2011 09:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.398 X-Spam-Level: X-Spam-Status: No, score=-102.398 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lve4trsspwqk for ; Sun, 10 Jul 2011 09:38:12 -0700 (PDT) Received: from nm28-vm0.access.bullet.mail.mud.yahoo.com (nm28-vm0.access.bullet.mail.mud.yahoo.com [66.94.236.229]) by ietfa.amsl.com (Postfix) with SMTP id A3FB121F8634 for ; Sun, 10 Jul 2011 09:38:12 -0700 (PDT) Received: from [66.94.237.198] by nm28.access.bullet.mail.mud.yahoo.com with NNFMP; 10 Jul 2011 16:38:12 -0000 Received: from [98.139.221.61] by tm9.access.bullet.mail.mud.yahoo.com with NNFMP; 10 Jul 2011 16:38:12 -0000 Received: from [127.0.0.1] by smtp102.biz.mail.bf1.yahoo.com with NNFMP; 10 Jul 2011 16:38:12 -0000 X-Yahoo-Newman-Id: 277209.42390.bm@smtp102.biz.mail.bf1.yahoo.com Received: from thunderfish.westell.com (turners@96.231.118.14 with plain) by smtp102.biz.mail.bf1.yahoo.com with SMTP; 10 Jul 2011 09:38:10 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: rIQAEGQVM1kiImhORAuOGwXDyf6Qj1JMQWSR2a79RCL6YGw ArQ8jkY6VrQJ2s1ZarL5Qk2FfyPhlTdhtAjVStlYNzdWxBkd7VdA8EtmFr_Z KiUytW3LKEzRcrRYjHcelqigKayakvDRrYDJB.mase5dJTNlYmk8gnjiquVl zyKiUfbH8GYJN9skgtlIBh_Dp.PsGrcQx3jYvMqjvZZt3eC3ZJD7ud3bF7O. PKE8y0yEggdakzUjFbrnJEEAYZ85AsOPPcyEniHpsemYi1nFSqVDRoJluj8K by5VgSi1JJM8yqGrvLeH1NS6zLwRa0bGzd4qvS1ztprXgdPD.O_67tOMZjh1 3j1JrGxgajWprCBXPg.G.Ukr. X-Yahoo-Newman-Property: ymail-3 Message-ID: <4E19D571.60405@ieca.com> Date: Sun, 10 Jul 2011 12:38:09 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: dcrocker@bbiw.net References: <4E17934C.8070905@dcrocker.net> <20110709022538.GA4308@mit.edu> <4E186249.2060707@dcrocker.net> In-Reply-To: <4E186249.2060707@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "saag@ietf.org" Subject: Re: [saag] The meaning of a signature (mid-course correction) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 16:38:13 -0000 On 7/9/11 10:14 AM, Dave CROCKER wrote: > Folks, > > First, MANY thanks for the quick followup, including the offline notes. > > Second, this thread is unfortunately a good demonstration of why survey > research is difficult. In spite of trying to ask the questions > carefully, the nature of what I am asking appears to have been > interpreted a bit differently than I intended. > > Most folk read the questions in very narrow terms. For example: > > On 7/8/2011 11:05 PM, Peter Gutmann wrote: > > It means that at some point in time, some device somewhere, possibly > with the > > knowledge of a key holder, performed a mathematical operation like a > modexp on > > the bag of bits usig a key that may or may not be held solely by the > purported > > own, and the bag was possibly the same bag of bits that the keyholder > is aware > > of. Nothing more, nothing less. There is a definition in RFC 4949 (The Internet Security Glossary) for digital signature, electronic signature, and digitized signature. I guess it doesn't talk about "meaning", but I don't think the definition for digital signature is too far off from what Peter wrote. I'll include it here to save everybody running it down ((I) - means it's the RECOMMENDED definition): $ digital signature 1. (I) A value computed with a cryptographic algorithm and associated with a data object in such a way that any recipient of the data can use the signature to verify the data's origin and integrity. (See: data origin authentication service, data integrity service, signer. Compare: digitized signature, electronic signature.) > The core of the answer presents the narrowest possible meaning of > signature, by casting it in term of the pure mechanics of data > integrity. More than one response focused on this. The issues of a > signature's basic mechanics and validity are, of course, essential, but > I really meant to take all of that as a given and, instead, ask more > about the "why" (or the policy) of different signatures. Signatures > often have a context beyond protecting the bits from manipulation. I think a digital signature is a mechanism and that's it. What you derive from the outcome of validating that signature and examining the contents (claims) of the thing that was signed is something else. I guess that's the "meaning" you're looking for. > The "Nothing more, nothing less" suggests that my question might have > had a larger scope, as indeed I had meant. The narrow definition really > casts the purpose of a signature as only for ensuring data integrity > between signing and verify. See above. > However... > > On 7/8/2011 7:25 PM, Jeffrey I. Schiller wrote: >> The complications arise when we attempt to associate control of the >> private key with a person or process AND with how we know that the >> associated public key represents the entity that it claims to AND who >> or what says so! > ... >> In particular if I make a commitment in a signed message, how >> enforceable is that commitment. Is it as enforceable as a legal >> contract? Does adding a signature to a statement make it a signed >> legal document? I am not a lawyer... > > and > > On 7/9/2011 1:20 AM, Peter Gutmann wrote: >> No, the two are very, very different. My signature and/or initials on a >> contract indicate my active participation in the contract-signing >> process (and >> if I really want to dispute it there's the standard questioned-documents >> process and tons of legal precedent). My digital "signature" on a >> document >> doesn't necessarily indicate any participation in the process, > ... > > > These point into the larger scope I am looking for. OpenPGP and S/MIME > don't really define the meaning of their signatures. For example, S/MIME > repeatedly uses the word 'authentication' but never defines what it is > that is authenticated. I'm not sure that they should. S/MIME is a general purpose profile of CMS for email. So, all it needs to say is what is signed. In CMS it talks about the use of signed-data: The typical application of the signed-data content type represents one signer's digital signature on content of the data content type. It later goes on to talk about what are steps to involved to get a signed-data. It also later goes on to talk about the signature field (where the actual signature goes): signature is the result of digital signature generation, using the message digest and the signer's private key. The details of the signature depend on the signature algorithm employed. For authentication, assuming the digital signature verifies you'd know the private key holder is the entity that composed the contents of the message and it's contents were not modified. > The term I've recently seen used, to describe the statement of "meaning" > for a signature is "claims". For example, when I sign a contract, the > meaning of the signature is commitment to the contract's terms and > conditions. I've heard that too, but I think that you've got think about the contents of the thing that is signed - that's the claim. Actually, the definition of authenticate and authentication in RFC 4949 include the term "claim". > On the average, folk who see a signature on an email believe that the > signature is validating either or both of the author or the content -- > but then there are multiple possible meanings to "validating > content"...) These larger meanings are certainly the typical beliefs > about OpenPGP and S/MIME signatures. However note that it is definitely > NOT the correct interpretation for DKIM. Yep that's right because in S/MIME and OpenPGP the key holder is almost always tied to a person while DKIM is for domains. Don't forget for S/MIME there's also RFC 5750 (Certificate Handling) and it in states: Sending agents SHOULD make the address in the From or Sender header in a mail message match an Internet mail address in the signer's certificate. Receiving agents MUST check that the address in the From or Sender header of a mail message matches an Internet mail address, if present, in the signer's certificate, if mail addresses are present in the certificate. A receiving agent SHOULD provide some explicit alternate processing of the message if this comparison fails, which may be to display a message that shows the recipient the addresses in the certificate or other certificate details. So I can see why somebody might believe that both are validated. > Yet the specs for S/MIME and OpenPGP imply, rather than define, their > meanings: > > S/MIME (rfc5751): > >> but that a careful attacker could have changed >> the unauthenticated portions of the encrypted message This comes from the section that discusses why you'd want to encapsulate an EnvelopedData with a SignedData. EncryptedData doesn't provide any kind of authentication; hence, why you'd wrap it in a SignedData - and not the other way around. > and > >> id-aa is the arc with all new authenticated and unauthenticated >> attributes > > But what does it mean to be authenticated? It doesn't say. This is talking about two fields: authenticated attributes (authAttrs) and unauthenticated attributes (unAuthAttrs). The attributes are either included as part of the signature process (authenticated attributes) or not (unauthenticated attributes). spt From jon@callas.org Sun Jul 10 10:12:10 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B81521F859C for ; Sun, 10 Jul 2011 10:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.588 X-Spam-Level: * X-Spam-Status: No, score=1.588 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FUZZY_VPILL=0.687, HELO_MISMATCH_COM=0.553, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYvmeex4J-hn for ; Sun, 10 Jul 2011 10:12:09 -0700 (PDT) Received: from merrymeet.com (unknown [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id 4614C21F8577 for ; Sun, 10 Jul 2011 10:12:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by merrymeet.com (Postfix) with ESMTP id 980C62E071; Sun, 10 Jul 2011 10:13:11 -0700 (PDT) Received: from merrymeet.com ([127.0.0.1]) by localhost (host.domain.tld [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 82056-05; Sun, 10 Jul 2011 10:13:07 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTPA id 778532E041; Sun, 10 Jul 2011 10:13:07 -0700 (PDT) Received: from [10.0.137.2] ([208.73.12.228]) by keys.merrymeet.com (PGP Universal service); Sun, 10 Jul 2011 10:12:04 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Sun, 10 Jul 2011 10:12:04 -0700 References: <4E17934C.8070905@dcrocker.net> <20110709022538.GA4308@mit.edu> <4E186249.2060707@dcrocker.net> <6E28ED3F-A0E1-4A4F-B680-92D44A158A42@callas.org> <62599540-BE9A-4305-8EDC-1DF852DE03B4@checkpoint.com> In-Reply-To: <62599540-BE9A-4305-8EDC-1DF852DE03B4@checkpoint.com> Mime-Version: 1.0 (iPad Mail 8J3) Message-Id: X-Mailer: iPad Mail (8J3) From: Jon Callas Date: Sun, 10 Jul 2011 10:13:48 -0700 To: Yoav Nir Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Maia Mailguard Cc: "dcrocker@bbiw.net" , "saag@ietf.org" Subject: Re: [saag] The meaning of a signature (mid-course correction) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 17:12:10 -0000 On Jul 9, 2011, at 23:48, Yoav Nir wrote: >=20 > On Jul 10, 2011, at 9:01 AM, Jon Callas wrote: >=20 >> Dave, >>=20 >> I a bit late to the party, but here are a few comments.=20 >>=20 >> Over a decade ago, Bruce Schneier and I wrote an article called "Why digi= tal signatures are not signatures" for The Industry Standard. I know there i= s a version of that article on Bruce's web site still. Many of the points we= made in it have been made by Peter Gutmann and others, but I both refer you= to that article and want to say some more.=20 >>=20 >> First, a digital signature and an ink signature are not the same thing at= all. A digital signature is a thing, an ink signature is an act. If I sign (= with ink) a contract or credit card receipt, it is the act that makes it leg= al, not the ink. It doesn't matter what you sign, it is the fact that you si= gned it. An "X" at the bottom, properly authenticated is completely legal an= d binding. I commonly sign those touch screen, so-called electronic signatur= e things with the word "Signature". That is completely legal and binding. A= gain, it doesn't matter what you sign, it matters that *you* sign it.=20 >>=20 >> In contrast, a digital signature is a thing, more akin to a seal than a s= ignature, and the world would be a better place if digital signatures had be= en called seals rather than signatures.=20 >=20 > That depends. A digital signature on a bag-o-bits is a thing. An ink signa= ture on a page you have received through the mail, the fax machine or a scan= ned image sent in email is just as much a thing as a digital signature. If I= see you applying a digital signature to a bag-o-bits, it becomes an act as w= ell, although that's not the usual way of using digital signatures. Which is precisely that particular point. These days, the cool kids are all d= oing contracts by send each other PDFs of documents. The ink and the bits th= at are the scan of the ink are representations of the act that is the contra= ct.=20 >=20 >>=20 >> Everyone intuitively knows that if you put an ink image exactly like a si= gnature on a document, the person whose signature that is did not sign the d= ocument. Yet, us techie types would say that if you produce a document that c= ollides with another, then they are both digitally signed.=20 >=20 > No, they're not. The "MD5 Collisions Inc." was not a properly signed certi= ficate. It was just a perfect forgery. Okay, that's great. That's how it should be.=20 >=20 >> We all know that there is no danger in lending someone your pen, but we a= ll know that there is danger in letting someone else use your private key.=20= >=20 > You can't generate a signature identical to mine with my pen. You need my h= and (or is it the wrist). That's a technological difference, not an essentia= l one.=20 Are you *really* saying that if I just had technology good enough, then the c= ontract I signed you up for is valid? Not only does that disagree with what I= understand contract law to be, it disagrees with what you said above. Thank= you for the Aristotelian language here -- the signature is *essential*, not= technological. >>=20 >> If we consider a signed contract, what makes it important is not that it i= s signed, it is that it is a contract. If you write a contract on a page wit= h an autograph, it is not suddenly valid. But if you find bits that hash to t= he right thing, then the digital signature is valid. Or is it? >=20 > No. You're just a clever cryptographer, similar to people who can forge an= ybody's signature. >=20 >> The real question you are asking is about symantics and the standards you= quote are all about syntax. I know that OpenPGP intentionally punted the se= mantic question. That is why "authenticated" and related terms are not defin= ed. What they mean depends on semantics, not on syntax.=20 >>=20 >> The person who quoted Humpty Dumpty from Alice probably has the best answ= er. A signature means what it is agreed upon to mean, nothing more and nothi= ng less. These is a very real sense in which trying to add meaning to a digi= tal signature is fraud in the very same way that writing a contract around a= page with an autograph is fraud. Of course, fraud itself is a semantic thin= g, because it is a term that we use to describe an abuse of signatures and a= uthentication and so on.=20 >>=20 >> DKIM differs from other signature standards in that it at least tries to a= ddress the semantic issue. It may be a bit squishy, but it doesn't punt the i= ssue.=20 >>=20 >> It is entirely possible that this message is signed in OpenPGP format wit= h my key. In fact, I will go so far as to say that it probably is signed. My= PGP Universal server is set up to sign lots of my messages. I think it will= sign this one. Let us just assume it is signed.=20 >>=20 >> What does the signature mean? Does it mean that I wrote it? Does it mean I= believe what is in this message? Does it mean I am somehow bound by its con= tent? Something else? The answer depends completely on the semantic content o= f this message as well as the constellation of human events surrounding it.=20= >>=20 >> Perhaps belaboring the point, if I sign a card that reads "all the best t= o you in the joyful holiday season" I'm really only sending a card. It resem= bles what DKIM means more than any discussion of contract law. The signed ca= rd means whatever it means because there is no semantic social context surro= unding what cards mean. A card is not a contract because a card is not a con= tract. This signed email means whatever a signed email means.=20 >=20 > Isn't it binding? I wonder is somebody has ever tried to sue a card sende= r if their holiday season was not joyful. >=20 People have made jokes about that very thing; no, it's not binding because i= t isn't actually a statement of intent, it is merely protocol.=20 Similarly, consider this exchange: Alice: Good morning, Bob, how are you? Bob: I'm fine, Alice, how are you? Alice: I'm fine as well.=20 This is not a discussion about health. It's exactly the same thing as SYN, A= CK, SYN. It establishes a conversation similarly to the way a TCP connection= is opened up. Its surface structure might look like that, but that's not wh= at it means. The essence is mere protocol. Five minutes from now, when Bob m= entions that his sciatica is flaring up again, he's not confessing to a lie,= he's performing selective disclosure.=20 We could sort all this human protocol stuff out in the digital signatures, b= ut it would require intent flags and other stuff that it is hard to get cons= ensus on. We will probably get the sarcasm bits into Unicode first.=20 Jon From sm@resistor.net Sun Jul 10 10:18:07 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6B921F8754 for ; Sun, 10 Jul 2011 10:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwFqms7uGI1B for ; Sun, 10 Jul 2011 10:18:06 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C11221F86C2 for ; Sun, 10 Jul 2011 10:18:05 -0700 (PDT) Received: from subman.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5.Beta0) with ESMTP id p6AHHsWS017773; Sun, 10 Jul 2011 10:17:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1310318282; bh=UXXk+F62lJtu3+mkVfjtY/ocgeTP9PeDse3+wMwjipw=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=fbAbylZo8mqNQ82oS1J9g2m8WiO1sOeVamLK3Kzfgzjy7Iur3kEWOdAXMhKKThpqH l06uCqc3cCC7+99pNyGxwMTgiUHF/bgWZO2Knb6JiVOcvfO8r4OItY7em9C3xF+2Py xFzwo5+aM3uRpEsp5LQqw5kZm8TidGHgmAcVHGtw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1310318282; bh=UXXk+F62lJtu3+mkVfjtY/ocgeTP9PeDse3+wMwjipw=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=HlZNjye5nGuWTR+ox+C+yXM2BgjpfGJXJV7RNXM4RcCY6TTOitpDrlJNDuhwESfzS AGOzs8kLqKRJsH8Bv521bet1uCyGQFk7IcopbnKuRzpirCVCVeCVTm7vyq6sUuPLn4 gW4ACw+ZOoE7zY3ZVbxNj+JIk0WR4Dvm9RNe9Cy4= Message-Id: <6.2.5.6.2.20110710101035.047c9030@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 10 Jul 2011 10:17:36 -0700 To: Jon Callas From: SM In-Reply-To: <6E28ED3F-A0E1-4A4F-B680-92D44A158A42@callas.org> References: <4E17934C.8070905@dcrocker.net> <20110709022538.GA4308@mit.edu> <4E186249.2060707@dcrocker.net> <6E28ED3F-A0E1-4A4F-B680-92D44A158A42@callas.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: saag@ietf.org Subject: Re: [saag] The meaning of a signature (mid-course correction) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 17:18:07 -0000 Hi Jon, At 23:01 09-07-2011, Jon Callas wrote: >First, a digital signature and an ink signature are not the same >thing at all. A digital signature is a thing, an ink signature is an >act. If I sign (with ink) a contract or credit card receipt, it is >the act that makes it legal, not the ink. It doesn't matter what you >sign, it is the fact that you signed it. An "X" at the bottom, >properly authenticated is completely legal and binding. I commonly >sign those touch screen, so-called electronic signature things with >the word "Signature". That is completely legal and binding. Again, >it doesn't matter what you sign, it matters that *you* sign it. Would an ink signature be a mark that denotes informed consent? >The person who quoted Humpty Dumpty from Alice probably has the best >answer. A signature means what it is agreed upon to mean, nothing >more and nothing less. These is a very real I liked that answer. Regards, -sm From rbarnes@bbn.com Sun Jul 10 11:24:29 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F07E21F87A8 for ; Sun, 10 Jul 2011 11:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWFStE9xJ6jQ for ; Sun, 10 Jul 2011 11:24:29 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 0A5CD21F87A5 for ; Sun, 10 Jul 2011 11:24:28 -0700 (PDT) Received: from ros-dhcp192-1-51-56.bbn.com ([192.1.51.56]:55729) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Qfyg6-000Fq3-9S; Sun, 10 Jul 2011 14:24:26 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <4E188CAB.1010302@dcrocker.net> Date: Sun, 10 Jul 2011 14:24:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2537AFAF-1417-4D7B-81A9-9BA6E5E2C167@bbn.com> References: <4E17934C.8070905@dcrocker.net> <20110709022538.GA4308@mit.edu> <4E186249.2060707@dcrocker.net> <4E188CAB.1010302@dcrocker.net> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.1082) Cc: "saag@ietf.org" Subject: Re: [saag] The meaning of a signature (mid-course correction) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 18:24:29 -0000 > I believe that most recipients of an email signed with OpenPGP or = S/MIME believe that verification means that the signer was the author of = the message or that the signer has vetted the authenticity of the From: = field. >=20 > By contrast, DKIM states an entirely different meaning. I think this is exactly the point that Peter and Jeff were making: The = semantic associated with a signer and signature depend on the = application. S/MIME / OpenPGP: signer ~ From, signature ~ "message is from me" DKIM: signer ~ domain, signature ~ "message is from my domain" It's natural for signatures to mean different things in S/MIME vs. = OpenPGP vs. DKIM, because they are defined to mean different things. = You'll note that signatures in TLS, IPsec, PKIX, and DNSSEC also mean = rather different things that the above. --Richard= From dcrocker@bbiw.net Sat Jul 9 10:13:08 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84DD821F8663 for ; Sat, 9 Jul 2011 10:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6JtHGRe8qbcZ for ; Sat, 9 Jul 2011 10:13:07 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id CD80921F87B9 for ; Sat, 9 Jul 2011 10:13:07 -0700 (PDT) Received: from [192.168.1.156] (adsl-67-124-149-98.dsl.pltn13.pacbell.net [67.124.149.98]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p69HD0qK001297 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sat, 9 Jul 2011 10:13:05 -0700 Message-ID: <4E188C14.9000604@bbiw.net> Date: Sat, 09 Jul 2011 10:12:52 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Donald Eastlake References: <4E17934C.8070905@dcrocker.net> <20110709022538.GA4308@mit.edu> <4E186249.2060707@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sat, 09 Jul 2011 10:13:05 -0700 (PDT) X-Mailman-Approved-At: Mon, 11 Jul 2011 08:01:41 -0700 Cc: "saag@ietf.org" Subject: Re: [saag] The meaning of a signature (mid-course correction) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 17:13:08 -0000 On 7/9/2011 8:13 AM, Donald Eastlake wrote: > On Sat, Jul 9, 2011 at 10:14 AM, Dave CROCKER wrote: >> Folks, >> >> >> ... >> >> For example, when I sign a contract, the meaning >> of the signature is commitment to the contract's terms and conditions. > > Really? What if you write the word "Witness" above your signature? Or > put it in a box with a date and time and the words "Time > Certification"? What I particularly like about your response is that while it correctly demonstrates the problem with my loose phrasing, it also demonstrates the correctness of the issue I am asking about. What you highlighted are different meanings. If alternate phrasing will help, folks should try this: What is the intended meaning of a duly authorized actor when they affix a signature? So, take it as a given that all of the basics of proper and robust digital signature mechanics have been performed and that, for example, non-repudiation of originator is not an issue. Besides knowing that you can trust the bits weren't changed between signing and verifying, WHY did that duly authorized agent sign the thing? I believe that most recipients of an email signed with OpenPGP or S/MIME believe that verification means that the signer was the author of the message or that the signer has vetted the authenticity of the From: field. By contrast, DKIM states an entirely different meaning. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From trammell@tik.ee.ethz.ch Mon Jul 11 07:30:25 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E381221F8C41; Mon, 11 Jul 2011 07:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sL9sRGdlLsYx; Mon, 11 Jul 2011 07:30:25 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id A6F5821F8C40; Mon, 11 Jul 2011 07:30:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 1EF7ED9321; Mon, 11 Jul 2011 16:30:23 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id mWl1U5ymYGjw; Mon, 11 Jul 2011 16:30:22 +0200 (MEST) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id BDDFBD930E; Mon, 11 Jul 2011 16:30:22 +0200 (MEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Brian Trammell Date: Mon, 11 Jul 2011 16:30:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: ietf@ietf.org, saag@ietf.org X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Mon, 11 Jul 2011 08:01:41 -0700 Cc: mile@ietf.org Subject: [saag] MILE side meeting, IETF81 in Quebec, Monday night July 25th X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 14:30:26 -0000 Greetings, all, To help us plan a bit for the (previously-announced) MILE pre-WG side = meeting in Quebec, 19:30 Monday 25 July, after the technical plenary = meeting, please let us know if you are interested in attending by = filling out the doodle at: http://www.doodle.com/e2w494tce6knmq6m The working proposed charter is attached below for reference. Further = details will be announced later. Many thanks, and best regards, Brian and Kathleen Managed Incident Lightweight Exchange (mile) -------------------------------------------- Proposed Working Group Charter Chairs: Kathleen Moriarty Brian Trammell Security Area Directors: Stephen Farrell = > Sean Turner > Security Area Advisor: Sean Turner Mailing Lists: General Discussion: mile@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/mile Archive: http://www.ietf.org/mail-archive/web/mile Description: The Managed Incident Lightweight Exchange (MILE) pre-working group will = develop standards and extensions for the purpose of improving incident = information sharing and handling capabilities based on the work = developed in the IETF Extended INCident Handling (INCH) working group. = The Incident Object Description Exchange Format (IODEF) in RFC5070 and = Real-time Inter-network Defense (RID) in RFC6045 were developed in the = INCH working group by international Computer Security Incident Response = Teams (CSIRTs) and industry to meet the needs of a global community = interested in sharing, handling, and exchanging incident information. = The extensions and guidance created by the MILE working group assists = with the daily operations of CSIRTs at an organization, service = provider, law enforcement, and at the country level. The application of = IODEF and RID to interdomain incident information cooperative exchange = and sharing has recently expanded and the need for extensions has become = more im portant. Efforts continue to deploy IODEF and RID, as well as to extend = them to support specific use cases covering reporting and mitigation of = current threats such as anti-phishing extensions. An incident could be a benign configuration issue, IT incident, an = infraction to a service level agreement (SLA), a system compromise, = socially engineered phishing attack, or a denial-of-service (DoS) = attack, etc.. When an incident is detected, the response may include = simply filing a report, notification to the source of the incident, a = request to a third party for resolution/mitigation, or a request to = locate the source. IODEF defines a data representation that provides a = standard format for sharing information commonly exchanged about = computer security incidents. RID enables the secure exchange of = incident related information in an IODEF format providing options for = security, privacy, and policy setting. MILE leverages collaboration and sharing experiences with the work = developed in the INCH working group which includes the data model = detailed in the IODEF, existing extensions to the IODEF for = Anti-phishing (RFC5901), and RID (RFC6045, RFC6046) for the secure = exchange of information. MILE will also leverage the experience gained = in using IODEF and RID in operational contexts. Related work, drafted = outside of INCH will also be reviewed and includes RFC5941, Sharing = Transaction Fraud Data. The MILE working group provides coordination for these various extension = efforts to improve the capabilities for exchanging incident information. = MILE has several objectives with the first being a description a subset = of IODEF focused on ease of deployment and applicability to current = information security data sharing use cases. MILE also describes a = generalization of RID for secure exchange of other security-relevant XML = formats. MILE produces additional guidance needed for the successful = exchange of incident information for new use cases according to policy, = security, and privacy requirements. Finally, MILE produces a document = template with guidance for defining IODEF extensions to be followed when = producing extensions to IODEF as appropriate, for: * labeling incident reports with data protection, data retention, and = other policies, regulations, and laws restricting the handling of those reports * reporting on mail service abuse incidents * reporting forensic data generated during incident investigation * reporting indicators of compromise in incident reports * reporting on financial fraud incidents * reporting incidents involving virtualized environments * referencing SCAP enumerations from within incident reports * profiling and reporting on characteristics of malware suspected or = confirmed to be involved in an incident * profiling and reporting on characteristics of actors (persons or = groups) suspected or confirmed to be involved in an incident * reporting on misuse incidents From mouse@Sparkle.Rodents-Montreal.ORG Mon Jul 11 08:15:49 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13C7D21F8D4A for ; Mon, 11 Jul 2011 08:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.207 X-Spam-Level: X-Spam-Status: No, score=-10.207 tagged_above=-999 required=5 tests=[AWL=-0.219, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h+wGkIHCvGQF for ; Mon, 11 Jul 2011 08:15:48 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by ietfa.amsl.com (Postfix) with ESMTP id 26AFB21F8CD9 for ; Mon, 11 Jul 2011 08:15:42 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id LAA21709; Mon, 11 Jul 2011 11:15:40 -0400 (EDT) Date: Mon, 11 Jul 2011 11:15:40 -0400 (EDT) From: Mouse Message-Id: <201107111515.LAA21709@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Mon, 11 Jul 2011 11:11:26 -0400 (EDT) To: saag@ietf.org In-Reply-To: <4E188C14.9000604@bbiw.net> References: <4E17934C.8070905@dcrocker.net> <20110709022538.GA4308@mit.edu> <4E186249.2060707@dcrocker.net> <4E188C14.9000604@bbiw.net> Subject: Re: [saag] The meaning of a signature (mid-course correction) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 15:15:49 -0000 > If alternate phrasing will help, folks should try this: > What is the intended meaning of a duly authorized actor when > they affix a signature? "That depends." Like a paper signature, I would say it depends on the thing being signed, in general - though there are special cases (like DKIM) where other, contextual, information provides that meaning. (The meaning of a DKIM signature cannot be inferred from the content signed over; it comes from the way the signature is encapsulated.) > So, take it as a given that all of the basics of proper and robust > digital signature mechanics have been performed and that, for > example, non-repudiation of originator is not an issue. Um, at least sometimes, non-repudiation of originator *is* the intended meaning and thus is at issue even if there are no forgeries (then!) in sight. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From dhc2@dcrocker.net Mon Jul 11 08:29:06 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC7721F8D74 for ; Mon, 11 Jul 2011 08:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.71 X-Spam-Level: X-Spam-Status: No, score=-6.71 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7RgGpX0rhBx3 for ; Mon, 11 Jul 2011 08:29:05 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 66AB121F8D76 for ; Mon, 11 Jul 2011 08:29:05 -0700 (PDT) Received: from [192.168.1.156] (adsl-67-124-149-98.dsl.pltn13.pacbell.net [67.124.149.98]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p6BFT0vh024907 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Mon, 11 Jul 2011 08:29:05 -0700 Message-ID: <4E1B16B0.50304@dcrocker.net> Date: Mon, 11 Jul 2011 08:28:48 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: saag@ietf.org References: <4E17934C.8070905@dcrocker.net> <20110709022538.GA4308@mit.edu> <4E186249.2060707@dcrocker.net> <4E188C14.9000604@bbiw.net> <201107111515.LAA21709@Sparkle.Rodents-Montreal.ORG> In-Reply-To: <201107111515.LAA21709@Sparkle.Rodents-Montreal.ORG> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 11 Jul 2011 08:29:05 -0700 (PDT) Subject: Re: [saag] The meaning of a signature (mid-course correction) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 15:29:06 -0000 On 7/11/2011 8:15 AM, Mouse wrote: >> If alternate phrasing will help, folks should try this: > >> What is the intended meaning of a duly authorized actor when >> they affix a signature? > > "That depends." Like a paper signature, I would say it depends on the > thing being signed, in general - though there are special cases (like > DKIM) where other, contextual, information provides that meaning. (The > meaning of a DKIM signature cannot be inferred from the content signed > over; it comes from the way the signature is encapsulated.) I believe that most uses of OpenPGP and S/MIME for signing email are not contingent on the message content or even the recipient list. Yet the signature has some meaning. What does the signer intend to mean and what does the recipient take it to mean? (These could be different.) >> So, take it as a given that all of the basics of proper and robust >> digital signature mechanics have been performed and that, for >> example, non-repudiation of originator is not an issue. > > Um, at least sometimes, non-repudiation of originator *is* the intended > meaning and thus is at issue even if there are no forgeries (then!) in > sight. ack. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc2@dcrocker.net Mon Jul 11 08:32:52 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 685A421F8D85 for ; Mon, 11 Jul 2011 08:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.699 X-Spam-Level: X-Spam-Status: No, score=-6.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3hDuuDYI7NG for ; Mon, 11 Jul 2011 08:32:51 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 743A621F8CE5 for ; Mon, 11 Jul 2011 08:32:51 -0700 (PDT) Received: from [192.168.1.156] (adsl-67-124-149-98.dsl.pltn13.pacbell.net [67.124.149.98]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p6BFWfw4025031 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 11 Jul 2011 08:32:46 -0700 Message-ID: <4E1B178E.7040503@dcrocker.net> Date: Mon, 11 Jul 2011 08:32:30 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "Richard L. Barnes" References: <4E17934C.8070905@dcrocker.net> <20110709022538.GA4308@mit.edu> <4E186249.2060707@dcrocker.net> <4E188CAB.1010302@dcrocker.net> <2537AFAF-1417-4D7B-81A9-9BA6E5E2C167@bbn.com> In-Reply-To: <2537AFAF-1417-4D7B-81A9-9BA6E5E2C167@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 11 Jul 2011 08:32:46 -0700 (PDT) Cc: "saag@ietf.org" Subject: Re: [saag] The meaning of a signature (mid-course correction) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 15:32:52 -0000 On 7/10/2011 11:24 AM, Richard L. Barnes wrote: > I think this is exactly the point that Peter and Jeff were making: The > semantic associated with a signer and signature depend on the application. > > S/MIME / OpenPGP: signer ~ From, signature ~ "message is from me" ack. just to be picky, does the 'me' refer to the name and/or address in the rfc5322.From field? > DKIM: signer ~ domain, signature ~ "message is from my domain" DKIM is a transit-signing mechanism. Any entity that touches the message along the way might sign it. Hence 'from' means 'along the path' rather than 'originator'. In fact, a DKIM signature might be made by an entity that is NOT part of transit, such as with a third-party vetting service. For example, an originator could hand the message to the vetting service, get back a signature, affix it to the message, and send it on. A receiver could validate the sig and use it for assessment. (This was, in fact, exactly how the Goodmail model worked.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From rbarnes@bbn.com Mon Jul 11 08:45:18 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2709121F8DC5 for ; Mon, 11 Jul 2011 08:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZ1X3jPjEmno for ; Mon, 11 Jul 2011 08:45:17 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 12AC221F8854 for ; Mon, 11 Jul 2011 08:45:16 -0700 (PDT) Received: from [192.1.255.156] (port=58368 helo=col-dhcp-192-1-255-156.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QgIfc-0001WW-Gt; Mon, 11 Jul 2011 11:45:16 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <4E1B178E.7040503@dcrocker.net> Date: Mon, 11 Jul 2011 11:45:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <91A3A359-3E7D-447E-9348-1B341331F345@bbn.com> References: <4E17934C.8070905@dcrocker.net> <20110709022538.GA4308@mit.edu> <4E186249.2060707@dcrocker.net> <4E188CAB.1010302@dcrocker.net> <2537AFAF-1417-4D7B-81A9-9BA6E5E2C167@bbn.com> <4E1B178E.7040503@dcrocker.net> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.1082) Cc: "saag@ietf.org" Subject: Re: [saag] The meaning of a signature (mid-course correction) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 15:45:18 -0000 >> DKIM: signer ~ domain, signature ~ "message is from my domain" >=20 > DKIM is a transit-signing mechanism. Any entity that touches the = message along > the way might sign it. Hence 'from' means 'along the path' rather = than > 'originator'. >=20 > In fact, a DKIM signature might be made by an entity that is NOT part = of > transit, such as with a third-party vetting service. For example, an = originator > could hand the message to the vetting service, get back a signature, = affix it to > the message, and send it on. A receiver could validate the sig and = use it for > assessment. (This was, in fact, exactly how the Goodmail model = worked.) Well, either way, the message passed through the signer. So you could = say something like: signature ~ "message passed through my domain" That statement could of course be overloaded with statements like "I = wouldn't have allowed this to pass through my domain without a virus = scan." But that starts to get layer-9-ish. --Richard= From dhc2@dcrocker.net Mon Jul 11 08:49:22 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38FAA21F8E20 for ; Mon, 11 Jul 2011 08:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.69 X-Spam-Level: X-Spam-Status: No, score=-6.69 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjTIFIdv+BDo for ; Mon, 11 Jul 2011 08:49:21 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id AB55A21F8E1E for ; Mon, 11 Jul 2011 08:49:11 -0700 (PDT) Received: from [192.168.1.156] (adsl-67-124-149-98.dsl.pltn13.pacbell.net [67.124.149.98]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p6BFn2DX025678 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 11 Jul 2011 08:49:07 -0700 Message-ID: <4E1B1B63.3000505@dcrocker.net> Date: Mon, 11 Jul 2011 08:48:51 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "Richard L. Barnes" References: <4E17934C.8070905@dcrocker.net> <20110709022538.GA4308@mit.edu> <4E186249.2060707@dcrocker.net> <4E188CAB.1010302@dcrocker.net> <2537AFAF-1417-4D7B-81A9-9BA6E5E2C167@bbn.com> <4E1B178E.7040503@dcrocker.net> <91A3A359-3E7D-447E-9348-1B341331F345@bbn.com> In-Reply-To: <91A3A359-3E7D-447E-9348-1B341331F345@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 11 Jul 2011 08:49:07 -0700 (PDT) Cc: "saag@ietf.org" Subject: Re: [saag] The meaning of a signature (mid-course correction) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 15:49:22 -0000 On 7/11/2011 8:45 AM, Richard L. Barnes wrote: > Well, either way, the message passed through the signer. So you could say > something like: signature ~ "message passed through my domain" +1 > That statement could of course be overloaded with statements like "I wouldn't > have allowed this to pass through my domain without a virus scan." But that > starts to get layer-9-ish. possibly not that low in the stack... more seriously: all sorts of policies might apply for a particular signer, but the basic DKIM standard communicates none of them. ADSP is an example of attempting to communicate a specific, additional policy. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From barryleiba.mailing.lists@gmail.com Mon Jul 11 19:06:07 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D28311E83FE for ; Mon, 11 Jul 2011 19:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.114 X-Spam-Level: X-Spam-Status: No, score=-103.114 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id akaf0jeextXb for ; Mon, 11 Jul 2011 19:06:07 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id ECD8E11E831F for ; Mon, 11 Jul 2011 19:06:06 -0700 (PDT) Received: by ywp31 with SMTP id 31so1366711ywp.31 for ; Mon, 11 Jul 2011 19:06:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=XeCHDlTgTv2VQ7mMX+OLVkEXkhRXEZ2/+c4PjXLpSvY=; b=uWe4LWiJOfO4G6q+7JDEUqDEQRjRbMSl45kYpydHh4yYj6tPCiv5e/ikafD2LxK9/H tha0Nggnab2SJ/1Y038M5U9TvoTIVNnHyrOC9PfDCTBjhMVjTYgemQdW6VIMLZixowez ar3cg/Gr2zmGKeRyVD7G9TJdJw4uxV6CvJM1E= MIME-Version: 1.0 Received: by 10.147.152.3 with SMTP id e3mr3064038yao.9.1310436366347; Mon, 11 Jul 2011 19:06:06 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.169.18 with HTTP; Mon, 11 Jul 2011 19:06:06 -0700 (PDT) In-Reply-To: <4E1B1B63.3000505@dcrocker.net> References: <4E17934C.8070905@dcrocker.net> <20110709022538.GA4308@mit.edu> <4E186249.2060707@dcrocker.net> <4E188CAB.1010302@dcrocker.net> <2537AFAF-1417-4D7B-81A9-9BA6E5E2C167@bbn.com> <4E1B178E.7040503@dcrocker.net> <91A3A359-3E7D-447E-9348-1B341331F345@bbn.com> <4E1B1B63.3000505@dcrocker.net> Date: Mon, 11 Jul 2011 22:06:06 -0400 X-Google-Sender-Auth: b2ywA0b16VkHSgbElvlXHzs_0c8 Message-ID: From: Barry Leiba To: "saag@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [saag] The meaning of a signature (mid-course correction) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 02:06:07 -0000 >> That statement could of course be overloaded with statements like "I >> wouldn't >> have allowed this to pass through my domain without a virus scan." =A0Bu= t >> that >> starts to get layer-9-ish. ... > more seriously: =A0all sorts of policies might apply for a particular sig= ner, > but the basic DKIM standard communicates none of them. =A0ADSP is an exam= ple > of attempting to communicate a specific, additional policy. I want to stress that this is a core point of Dave's line of questioning here: separating what the signing protocol does, what the semantics of the signature are (as defined in the protocol), and what extra inferences one might make, or what extra assurances one might give out of band. A key point is that those extras might be useful and sensible, but they're not part of the protocol. Barry From nico@cryptonector.com Mon Jul 11 19:15:02 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7076811E8423 for ; Mon, 11 Jul 2011 19:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[AWL=-0.654, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2vdt6Wois0h for ; Mon, 11 Jul 2011 19:15:01 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 26C7111E841F for ; Mon, 11 Jul 2011 19:15:01 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id 9BC7B5405B for ; Mon, 11 Jul 2011 19:14:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=A18G7v/8c4TGvR5A5MbnN 6ibR/yBuvuGsCNNGhh/htEFTbijatL1DIsWmATx9cKNQqJebO5dMZElITBzuX5pE /cWjsUU28Zbt0b/OMAL3GRI3zD1pz6PITqxn3c1Y8zxqH6pDeLHP1XtXkrsIPqs0 jZCqthLHQPCx9jWHF/RV44= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=1JTHsnN98xrnQL50hrK3 /x8lXbk=; b=nLvAxF0IB0R8N9YVdrgWK/886g51cc5Wzst4ZHUqGJHqgRBsK7bP coNS9tcxmjjyY1ZcTriRq/WVdouBDKgqNqnYTzucTHyANRsOdLl+h0AAi2Bo5Fjj Iht90EBM238wbLZi2vAbpvlVFR3YRRoBj/UGk2UaG+mUw5vChnpoemI= Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id 7F3C754057 for ; Mon, 11 Jul 2011 19:14:56 -0700 (PDT) Received: by pvh18 with SMTP id 18so4742039pvh.31 for ; Mon, 11 Jul 2011 19:14:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.52.197 with SMTP id v5mr8093231pbo.387.1310436895922; Mon, 11 Jul 2011 19:14:55 -0700 (PDT) Received: by 10.68.41.103 with HTTP; Mon, 11 Jul 2011 19:14:55 -0700 (PDT) In-Reply-To: References: <4E17934C.8070905@dcrocker.net> <20110709022538.GA4308@mit.edu> <4E186249.2060707@dcrocker.net> <4E188CAB.1010302@dcrocker.net> <2537AFAF-1417-4D7B-81A9-9BA6E5E2C167@bbn.com> <4E1B178E.7040503@dcrocker.net> <91A3A359-3E7D-447E-9348-1B341331F345@bbn.com> <4E1B1B63.3000505@dcrocker.net> Date: Mon, 11 Jul 2011 21:14:55 -0500 Message-ID: From: Nico Williams To: Barry Leiba Content-Type: text/plain; charset=UTF-8 Cc: "saag@ietf.org" Subject: Re: [saag] The meaning of a signature (mid-course correction) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 02:15:02 -0000 On Mon, Jul 11, 2011 at 9:06 PM, Barry Leiba wrote: > I want to stress that this is a core point of Dave's line of > questioning here: separating what the signing protocol does, what the > semantics of the signature are (as defined in the protocol), and what > extra inferences one might make, or what extra assurances one might > give out of band. > > A key point is that those extras might be useful and sensible, but > they're not part of the protocol. The premise behind DOSETA, IIUC is that digitally signed documents are a better analog of meatspace signatures than electronic signatures (i.e., clicking on a button) POSTed over secure channels. If meatspace signatures are an action, and there is no specific need for sealing documents, then arguably electronic signatures over a secure channel (we already have both) are the better analog. Now, perhaps things are so hopeless that digitally signed documents would be better, but even granting that, when you consider the time and cost to switch to the DOSETA model, are we really better off than making the current tech we have work better? Nico -- From touch@isi.edu Tue Jul 12 08:59:03 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8B3521F8DC5 for ; Tue, 12 Jul 2011 08:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.842 X-Spam-Level: X-Spam-Status: No, score=-103.842 tagged_above=-999 required=5 tests=[AWL=-1.243, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WnuKhKfWGC5B for ; Tue, 12 Jul 2011 08:59:03 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5C821F8D6C for ; Tue, 12 Jul 2011 08:59:03 -0700 (PDT) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p6CFwQsv000535 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 12 Jul 2011 08:58:26 -0700 (PDT) Message-ID: <4E1C6F22.1030401@isi.edu> Date: Tue, 12 Jul 2011 08:58:26 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Nico Williams References: <4E17934C.8070905@dcrocker.net> <20110709022538.GA4308@mit.edu> <4E186249.2060707@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: dcrocker@bbiw.net, "saag@ietf.org" Subject: Re: [saag] The meaning of a signature (mid-course correction) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 15:59:04 -0000 On 7/9/2011 11:42 AM, Nico Williams wrote: > The semantics of a digital signature on a blob of bits is what we say > it is. Specifically it depends on a) the semantics of the bits being > signed, b) the semantics of the signer's public key (i.e., how we > associate a private/public key pair with some entity that we agree can > sign things, and what we allow that that key pair to be used for). I agree with (a). As I said before, the meaning of a mark on a doc is defined by the doc, either explicitly (the undersigned agrees to...) or implicitly (e.g., on a bill of sale). I disagree with (b). (b) isn't about semantics; it's about how trusted the resulting signature is, i.e., the value applied to the signature's properties. The properties themselves can limit that trust, but don't define it. E.g., within USC, email from my account is often sufficient to assign a grade. As others have noted, a mark ("X") can suffice for a handwritten signature. This is all well-established elsewhere (e.g., in law); there's no significant difference here except in the level of trust and challenge. Joe From dhc2@dcrocker.net Tue Jul 12 09:14:49 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E89B321F8C61 for ; Tue, 12 Jul 2011 09:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.682 X-Spam-Level: X-Spam-Status: No, score=-6.682 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYAzW-yQTfIY for ; Tue, 12 Jul 2011 09:14:45 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id EFFFB21F8C2F for ; Tue, 12 Jul 2011 09:14:42 -0700 (PDT) Received: from [192.168.1.156] (adsl-67-124-149-98.dsl.pltn13.pacbell.net [67.124.149.98]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p6CGEbHt029855 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 12 Jul 2011 09:14:42 -0700 Message-ID: <4E1C72E0.2010005@dcrocker.net> Date: Tue, 12 Jul 2011 09:14:24 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "saag@ietf.org" References: <4E17934C.8070905@dcrocker.net> <20110709022538.GA4308@mit.edu> <4E186249.2060707@dcrocker.net> <4E1C6F22.1030401@isi.edu> In-Reply-To: <4E1C6F22.1030401@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 12 Jul 2011 09:14:42 -0700 (PDT) Subject: Re: [saag] The meaning of a signature (mid-course correction) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 16:14:50 -0000 >> The semantics of a digital signature on a blob of bits is what we say >> it is. Specifically it depends on a) the semantics of the bits being >> signed, b) the semantics of the signer's public key (i.e., how we >> associate a private/public key pair with some entity that we agree can >> sign things, and what we allow that that key pair to be used for). > > I agree with (a). As I said before, the meaning of a mark on a doc is defined by > the doc, either explicitly (the undersigned agrees to...) or implicitly (e.g., > on a bill of sale). Folks, Apparently I was not sufficiently clear about the nature of the survey. It is not intended to query the meaning of digital signatures in general. The survey was meant to refer to a particular type of scenario that uses digital signatures. Although not really in mass-scale use, OpenPGP and S/MIME are regularly used to sign messages. Their use often is entirely automated, so that every message sent by the user is signed. Nothing about such a mechanism depends upon the content of the message. Every email gets a signature. So the intended 'meaning' of putting a signature there cannot be based on the content of the message. So a rephrasing of the questions: 1. When a user's mail agent is configured to sign every outgoing message, what is the (intended) "meaning" of that signature? 2. For such mail, what meaning should a receiver attribute to a validated signature of this type. Please note that validating a signature and imparting/deriving meaning to it are entirely separate from the next phase of processing, which assesses the trustworthiness/goodness of the agent responsible for the signature. So, for example, there is a fundamental difference between a 'meaning' such as "the owner of the identity responsible for signing this message claims that the author From: field is valid", versus an assessment which says "the identity responsible for signing this message is a Good Actor and I can trust what they put into their email." d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From touch@isi.edu Tue Jul 12 09:29:03 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB4A021F8D4D for ; Tue, 12 Jul 2011 09:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.759 X-Spam-Level: X-Spam-Status: No, score=-105.759 tagged_above=-999 required=5 tests=[AWL=0.840, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9h2Keco18qsC for ; Tue, 12 Jul 2011 09:29:03 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 50E1E21F8D4C for ; Tue, 12 Jul 2011 09:29:03 -0700 (PDT) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p6CGSDb7013370 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 12 Jul 2011 09:28:13 -0700 (PDT) Message-ID: <4E1C761D.6010409@isi.edu> Date: Tue, 12 Jul 2011 09:28:13 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: dcrocker@bbiw.net References: <4E17934C.8070905@dcrocker.net> <20110709022538.GA4308@mit.edu> <4E186249.2060707@dcrocker.net> <4E1C6F22.1030401@isi.edu> <4E1C72E0.2010005@dcrocker.net> In-Reply-To: <4E1C72E0.2010005@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "saag@ietf.org" Subject: Re: [saag] The meaning of a signature (mid-course correction) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 16:29:03 -0000 Hi, Dave, On 7/12/2011 9:14 AM, Dave CROCKER wrote: > >>> The semantics of a digital signature on a blob of bits is what we say >>> it is. Specifically it depends on a) the semantics of the bits being >>> signed, b) the semantics of the signer's public key (i.e., how we >>> associate a private/public key pair with some entity that we agree can >>> sign things, and what we allow that that key pair to be used for). >> >> I agree with (a). As I said before, the meaning of a mark on a doc is >> defined by >> the doc, either explicitly (the undersigned agrees to...) or >> implicitly (e.g., >> on a bill of sale). > > > Folks, > > Apparently I was not sufficiently clear about the nature of the survey. > It is not intended to query the meaning of digital signatures in > general. The survey was meant to refer to a particular type of scenario > that uses digital signatures. > > Although not really in mass-scale use, OpenPGP and S/MIME are regularly > used to sign messages. Their use often is entirely automated, so that > every message sent by the user is signed. > > Nothing about such a mechanism depends upon the content of the message. > Every email gets a signature. So the intended 'meaning' of putting a > signature there cannot be based on the content of the message. In that case it's defined by the signer. For one signer, it can mean "I read and agree to the terms in the email". To another signer, it can mean "I assure that this came from me". However, if the doc itself says "if this is signed, it means X", then AFAICT you'd be in a courtroom needing to argue why you blindly signed everything without reading it. > So a rephrasing of the questions: > > 1. When a user's mail agent is configured to sign every outgoing > message, what is the (intended) "meaning" of that signature? IMO, that's (at best) determined by the signer, not the signature itself. And, as above, it can be determined by the content when explicit (even if not intended that way by the signer). > 2. For such mail, what meaning should a receiver attribute to a > validated signature of this type. I generally assume it means "I assure that this message came from me intact", i.e., it was not forged or altered, unless told otherwise. > Please note that validating a signature and imparting/deriving meaning > to it are entirely separate from the next phase of processing, which > assesses the trustworthiness/goodness of the agent responsible for the > signature. Agreed - a doc signed with a key I haven't validated means nothing to me. Joe From dhc2@dcrocker.net Tue Jul 12 09:49:48 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A53BD21F8E3A for ; Tue, 12 Jul 2011 09:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.676 X-Spam-Level: X-Spam-Status: No, score=-6.676 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKUaNv6c7lq7 for ; Tue, 12 Jul 2011 09:49:44 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6345521F8E30 for ; Tue, 12 Jul 2011 09:49:44 -0700 (PDT) Received: from [192.168.1.156] (adsl-67-124-149-98.dsl.pltn13.pacbell.net [67.124.149.98]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p6CGncpP030634 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 12 Jul 2011 09:49:43 -0700 Message-ID: <4E1C7B16.7010600@dcrocker.net> Date: Tue, 12 Jul 2011 09:49:26 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Joe Touch References: <4E17934C.8070905@dcrocker.net> <20110709022538.GA4308@mit.edu> <4E186249.2060707@dcrocker.net> <4E1C6F22.1030401@isi.edu> <4E1C72E0.2010005@dcrocker.net> <4E1C761D.6010409@isi.edu> In-Reply-To: <4E1C761D.6010409@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 12 Jul 2011 09:49:44 -0700 (PDT) Cc: "saag@ietf.org" Subject: Re: [saag] The meaning of a signature (mid-course correction) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 16:49:48 -0000 On 7/12/2011 9:28 AM, Joe Touch wrote: > In that case it's defined by the signer. How is the verifier to know the intended meaning? > For one signer, it can mean "I read and agree to the terms in the email". I don't know what that means. What "terms in the email"? Remember that this mechanism applies to /all/ email from the user. Notes to their grandmother, reports to their boss and replies to a mailing list. > To another signer, it can mean "I assure that this came from me". > > However, if the doc itself says "if this is signed, it means X", then AFAICT > you'd be in a courtroom needing to argue why you blindly signed everything > without reading it. Perhaps your mailstream is different from mine, but I believe I've never seen /any/ message with language like that in it and certainly none from a stray user with an automated S/MIME or OpenPGP signature. Consequently, the offered example doesn't resolve much of the real-world use of S/MIME or OpenPGP... >> So a rephrasing of the questions: >> >> 1. When a user's mail agent is configured to sign every outgoing >> message, what is the (intended) "meaning" of that signature? > > IMO, that's (at best) determined by the signer, not the signature itself. And, > as above, it can be determined by the content when explicit (even if not > intended that way by the signer). Protocols work poorly when there is no shared meaning in the exchange. Both ends of the exchange MUST make the same interpretation. Absent a means by which the verifier can know precisely the intended meaning of the signature, the "authentication" mechanism is not a useful protocol. >> 2. For such mail, what meaning should a receiver attribute to a >> validated signature of this type. > > I generally assume it means "I assure that this message came from me intact", > i.e., it was not forged or altered, unless told otherwise. I suspect that your use of the "me" refers to the person indicated in the rfc5322.From field and that the email address in that From: field matches the identifier in the signature...? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From mouse@Sparkle.Rodents-Montreal.ORG Tue Jul 12 09:50:05 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 271EA21F8E43 for ; Tue, 12 Jul 2011 09:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[AWL=-0.164, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1vHuKDwhj1X for ; Tue, 12 Jul 2011 09:50:04 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by ietfa.amsl.com (Postfix) with ESMTP id C7C0D21F8E40 for ; Tue, 12 Jul 2011 09:50:03 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id MAA00657; Tue, 12 Jul 2011 12:50:01 -0400 (EDT) Date: Tue, 12 Jul 2011 12:50:01 -0400 (EDT) From: Mouse Message-Id: <201107121650.MAA00657@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Tue, 12 Jul 2011 12:25:30 -0400 (EDT) To: saag@ietf.org In-Reply-To: <4E1C72E0.2010005@dcrocker.net> References: <4E17934C.8070905@dcrocker.net> <20110709022538.GA4308@mit.edu> <4E186249.2060707@dcrocker.net> <4E1C6F22.1030401@isi.edu> <4E1C72E0.2010005@dcrocker.net> Subject: Re: [saag] The meaning of a signature (mid-course correction) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 16:50:05 -0000 > [[T]he survey] is not intended to query the meaning of digital > signatures in general. The survey was meant to refer to a particular > type of scenario that uses digital signatures. > Although not really in mass-scale use, OpenPGP and S/MIME are > regularly used to sign messages. Their use often is entirely > automated, so that every message sent by the user is signed. > Nothing about such a mechanism depends upon the content of the > message. Every email gets a signature. So the intended 'meaning' of > putting a signature there cannot be based on the content of the > message. I think I probably disagree with that last. I don't have such a setup and can't really speak for those who do, so the AA bit is clear on this email, but I rather suspect that the automated signatures are intended for only certain types of content and applying them uniformly is done because it avoids needing to either mechanically detect that type of content or count on a human to remember. (In some cases it may also be done in an attempt to avoid leaking information, to avoid indicating to unrelated third parties which messages contain the relevant kind(s) of content.) > So a rephrasing of the questions: > 1. When a user's mail agent is configured to sign every outgoing > message, what is the (intended) "meaning" of that signature? See above. > 2. For such mail, what meaning should a receiver attribute to a > validated signature of this type. "This mail passed through the auto-signer" is really about the only meaning I can justify attributing to it. In most cases this is probably operationally very close to "this mail is from whom it says it is and didn't get corrupted in transit", but that, particularly the part before the "and", depends on the details of the auto-signer setup. (I suspect the latter is approximately what most people _do_ interpret such signatures to mean. Personally, I can't recall the last time I even bothered to verify any kind of signature on an email; I don't do very much emailing for which strong signatures are relevant.) > So, for example, there is a fundamental difference between a > 'meaning' such as "the owner of the identity responsible for signing > this message claims that the author From: field is valid", versus an > assessment which says "the identity responsible for signing this > message is a Good Actor and I can trust what they put into their > email." I suspect the latter interpretation may be statistically defensible, in that I suspect use of such a setup correlates positively with being honest and competent. (I also suspect the correlation is weak enough that I wouldn't count on it in any particular case. And, of course, I could very well be wrong in my suspicions.) There's also the problem - from the recipient's point of view - of distinguishing auto-signer signatures such as you describe from delibrately affixed one-off signatures. In isolation (ie, given nothing but a single email to examine), there's no way to tell the difference in general, after all. Since you seem to be ignoring this issue, I am too, but depending on why you're asking it may need at least thinking about. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From paul.hoffman@vpnc.org Tue Jul 12 09:54:16 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD0721F8CF1 for ; Tue, 12 Jul 2011 09:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.703 X-Spam-Level: X-Spam-Status: No, score=-102.703 tagged_above=-999 required=5 tests=[AWL=-0.104, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65sLaTkxAbwX for ; Tue, 12 Jul 2011 09:54:16 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id B044A21F8CEC for ; Tue, 12 Jul 2011 09:54:15 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6CGs5e5060245 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 12 Jul 2011 09:54:05 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Paul Hoffman In-Reply-To: <4E1C761D.6010409@isi.edu> Date: Tue, 12 Jul 2011 09:54:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E17934C.8070905@dcrocker.net> <20110709022538.GA4308@mit.edu> <4E186249.2060707@dcrocker.net> <4E1C6F22.1030401@isi.edu> <4E1C72E0.2010005@dcrocker.net> <4E1C761D.6010409@isi.edu> To: saag@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [saag] The meaning of a signature (mid-course correction) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 16:54:16 -0000 On Jul 12, 2011, at 9:28 AM, Joe Touch wrote: >> So a rephrasing of the questions: >>=20 >> 1. When a user's mail agent is configured to sign every outgoing >> message, what is the (intended) "meaning" of that signature? >=20 > IMO, that's (at best) determined by the signer, not the signature = itself. And, as above, it can be determined by the content when explicit = (even if not intended that way by the signer). >=20 >> 2. For such mail, what meaning should a receiver attribute to a >> validated signature of this type. >=20 > I generally assume it means "I assure that this message came from me = intact", i.e., it was not forged or altered, unless told otherwise. Those look correct. In fact, the first one is correct even for a mail = agent that is configured for non-automatic signing. There are no = concrete, well-accepted semantics for signing email, although there is = at least one reasonably-well accepted semantic for a signature on a = transmitted message whose signature validates. --Paul Hoffman From mouse@Sparkle.Rodents-Montreal.ORG Tue Jul 12 10:01:01 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 383DF21F8E43 for ; Tue, 12 Jul 2011 10:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.119 X-Spam-Level: X-Spam-Status: No, score=-10.119 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id webCencGhsLs for ; Tue, 12 Jul 2011 10:01:00 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by ietfa.amsl.com (Postfix) with ESMTP id 5F25521F8E2F for ; Tue, 12 Jul 2011 10:01:00 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id NAA00752; Tue, 12 Jul 2011 13:00:59 -0400 (EDT) Date: Tue, 12 Jul 2011 13:00:59 -0400 (EDT) From: Mouse Message-Id: <201107121700.NAA00752@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Tue, 12 Jul 2011 12:54:38 -0400 (EDT) To: saag@ietf.org In-Reply-To: <4E1C761D.6010409@isi.edu> References: <4E17934C.8070905@dcrocker.net> <20110709022538.GA4308@mit.edu> <4E186249.2060707@dcrocker.net> <4E1C6F22.1030401@isi.edu> <4E1C72E0.2010005@dcrocker.net> <4E1C761D.6010409@isi.edu> Subject: Re: [saag] The meaning of a signature (mid-course correction) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 17:01:01 -0000 > However, if the doc itself says "if this is signed, it means X", then > AFAICT you'd be in a courtroom needing to argue why you blindly > signed everything without reading it. But, given a history of signing everything, especially if that is known to the actual sender, and a reason for doing so, I doubt it would stand up, any more than it would if I were to send a message to this list saying "If handled by mail.ietf.org, this mail means ...". >> 1. When a user's mail agent is configured to sign every outgoing >> message, what is the (intended) "meaning" of that signature? > [...]. And, as above, it can be determined by the content when > explicit (even if not intended that way by the signer). Um, I don't think the intended meaning of a signature can be one not intended by the signer. > Agreed - a doc signed with a key I haven't validated means nothing to > me. I do attribute meaning to such a signature, though it's a fairly weak meaning and bears more on the sender's psychology and attitudes than it does on the content of the particular message in question. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From mouse@Sparkle.Rodents-Montreal.ORG Tue Jul 12 10:33:26 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5028021F8CF7 for ; Tue, 12 Jul 2011 10:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.097 X-Spam-Level: X-Spam-Status: No, score=-10.097 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pm097kpPQbtO for ; Tue, 12 Jul 2011 10:33:25 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by ietfa.amsl.com (Postfix) with ESMTP id 804A121F8CF6 for ; Tue, 12 Jul 2011 10:33:25 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id NAA00955; Tue, 12 Jul 2011 13:33:20 -0400 (EDT) Date: Tue, 12 Jul 2011 13:33:20 -0400 (EDT) From: Mouse Message-Id: <201107121733.NAA00955@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Tue, 12 Jul 2011 13:04:04 -0400 (EDT) To: saag@ietf.org In-Reply-To: <4E1C7B16.7010600@dcrocker.net> References: <4E17934C.8070905@dcrocker.net> <20110709022538.GA4308@mit.edu> <4E186249.2060707@dcrocker.net> <4E1C6F22.1030401@isi.edu> <4E1C72E0.2010005@dcrocker.net> <4E1C761D.6010409@isi.edu> <4E1C7B16.7010600@dcrocker.net> Subject: Re: [saag] The meaning of a signature (mid-course correction) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 17:33:26 -0000 >> For one signer, it can mean "I read and agree to the terms in the >> email". > I don't know what that means. What "terms in the email"? > Remember that this mechanism applies to /all/ email from the user. > Notes to their grandmother, reports to their boss and replies to a > mailing list. Some senders don't send notes to grandmothers, reports to bosses, and replies to mailing lists. If the only things that user - that email identity, perhaps even that human - sends is things for which "terms in the email" makes sense, then this may be entirely correct. >> However, if the doc itself says "if this is signed, it means X", > Perhaps your mailstream is different from mine, but I believe I've > never seen /any/ message with language like that in it I wrote one. One. Once. It was for a new NetbSD developer; I think the language I used was something like "By signing this email, I certify that this data blob was presented to me by someone who showed me $DOCUMENT identifying him as $NAME.". (The data blob in question was a PGP key or an ssh identity or something of that general ilk.) > and certainly none from a stray user with an automated S/MIME or > OpenPGP signature. Well, there is that. I use neither S/MIME nor OpenPGP; the signature in the example above was a pre-"Open" PGP signature, and I neither then nor now auto-sign(ed) any mail. > Protocols work poorly when there is no shared meaning in the > exchange. This is true. That's one reason I think auto-signing mail is generally a bad idea: because the signer's intended meaning often matches up discouragingly poorly with recipients' interpretation of the signature. > Absent a means by which the verifier can know precisely the intended > meaning of the signature, the "authentication" mechanism is not a > useful protocol. I disagree. In the human layer (and, so far, crypto signatures on email are largely in the human layer), full precision is not necessary for a protocol to be useful. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From nico@cryptonector.com Tue Jul 12 10:46:25 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8200C21F8DA3 for ; Tue, 12 Jul 2011 10:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.915 X-Spam-Level: X-Spam-Status: No, score=-2.915 tagged_above=-999 required=5 tests=[AWL=-0.938, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pq9T69JwJfdD for ; Tue, 12 Jul 2011 10:46:21 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 79B0221F8D6D for ; Tue, 12 Jul 2011 10:46:21 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id 3B2FB54073 for ; Tue, 12 Jul 2011 10:46:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=bA/J6AbohOOognJTDjtvWkr0gr0kt08yEO97VL6IWpOI eTQubPMMRIRxWv2gNu4dWicVXa1WVWjnsQmr+ef79AY/30sVQJ3A5X2Y4nn+GNWn +TyhqwIj4sS78j2FaixXpc3xRdpcNDllCUdJjU0NrwShp/ydli+MsHCgJceHIMY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=OdyfpqRQjNZYwMW14Wvd6nVrFuU=; b=rrXUGxYmR2V A1yqwZ7QteJs0zaoYYXGsa77DOyNUOStNSpDN3v6Fq8MoVoA2Y22oQgEdnzDzqvA FFhHBS9EC4G3WmdK4kN13qPmesEZXCoGhg4fr3hzGM+C1yroVWmXxpeAd7PU2bp0 qSO3DxSy4zj45+cxRL90o9jGFN+bc3lM= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id 1901E5405B for ; Tue, 12 Jul 2011 10:46:21 -0700 (PDT) Received: by pzk5 with SMTP id 5so5786201pzk.31 for ; Tue, 12 Jul 2011 10:46:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.22.74 with SMTP id b10mr169190pbf.454.1310492780644; Tue, 12 Jul 2011 10:46:20 -0700 (PDT) Received: by 10.68.41.103 with HTTP; Tue, 12 Jul 2011 10:46:20 -0700 (PDT) In-Reply-To: <201107121733.NAA00955@Sparkle.Rodents-Montreal.ORG> References: <4E17934C.8070905@dcrocker.net> <20110709022538.GA4308@mit.edu> <4E186249.2060707@dcrocker.net> <4E1C6F22.1030401@isi.edu> <4E1C72E0.2010005@dcrocker.net> <4E1C761D.6010409@isi.edu> <4E1C7B16.7010600@dcrocker.net> <201107121733.NAA00955@Sparkle.Rodents-Montreal.ORG> Date: Tue, 12 Jul 2011 12:46:20 -0500 Message-ID: From: Nico Williams To: Mouse Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: saag@ietf.org Subject: Re: [saag] The meaning of a signature (mid-course correction) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 17:46:25 -0000 On Tue, Jul 12, 2011 at 12:33 PM, Mouse wrote: >> Absent a means by which the verifier can know precisely the intended >> meaning of the signature, the "authentication" mechanism is not a >> useful protocol. > > I disagree. =C2=A0In the human layer (and, so far, crypto signatures on > email are largely in the human layer), full precision is not necessary > for a protocol to be useful. Precisely so! (irony intended) What's the meaning of a signature on an e-mail? The meaning is agreed upon by convention among the senders and receivers. If I see a signed e-mail, and the signature validates, and there's a trust path for validating the sender's public key and the binding of it to the sender's name then I "know" that the person in question ("the sender") sent it. What more could I want? Would I ever want a signature on an e-mail to possibly denote something contractual? Maybe! But if so it will be by agreed-upon convention between myself and my correspondents, and most likely we'd agree to use different keys for different purposes (because I believe in keeping good key hygiene). Nico -- From touch@isi.edu Tue Jul 12 10:52:11 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5CE21F8B3D for ; Tue, 12 Jul 2011 10:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.812 X-Spam-Level: X-Spam-Status: No, score=-103.812 tagged_above=-999 required=5 tests=[AWL=-1.212, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Du-AAy4LrZEM for ; Tue, 12 Jul 2011 10:52:11 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id CD2C721F8B3B for ; Tue, 12 Jul 2011 10:52:10 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id p6CHpw4f019833 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 12 Jul 2011 10:51:58 -0700 (PDT) Message-ID: <4E1C89BE.10205@isi.edu> Date: Tue, 12 Jul 2011 10:51:58 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Mouse References: <4E17934C.8070905@dcrocker.net> <20110709022538.GA4308@mit.edu> <4E186249.2060707@dcrocker.net> <4E1C6F22.1030401@isi.edu> <4E1C72E0.2010005@dcrocker.net> <4E1C761D.6010409@isi.edu> <201107121700.NAA00752@Sparkle.Rodents-Montreal.ORG> In-Reply-To: <201107121700.NAA00752@Sparkle.Rodents-Montreal.ORG> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: saag@ietf.org Subject: Re: [saag] The meaning of a signature (mid-course correction) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 17:52:11 -0000 On 7/12/2011 10:00 AM, Mouse wrote: >> However, if the doc itself says "if this is signed, it means X", then >> AFAICT you'd be in a courtroom needing to argue why you blindly >> signed everything without reading it. > > But, given a history of signing everything, especially if that is known > to the actual sender, and a reason for doing so, I doubt it would stand > up, any more than it would if I were to send a message to this list > saying "If handled by mail.ietf.org, this mail means ...". It depends - that's exactly how the loan docs I just digitally signed are worded, FWIW (they used a 'type these numbers and it means you agree to the terms'). >>> 1. When a user's mail agent is configured to sign every outgoing >>> message, what is the (intended) "meaning" of that signature? >> [...]. And, as above, it can be determined by the content when >> explicit (even if not intended that way by the signer). > > Um, I don't think the intended meaning of a signature can be one not > intended by the signer. AFAICT, IANAL, but that's determined by a court, so all bets are off. I'm not saying that's what *should* happen, but AFAICT it can. Joe From touch@isi.edu Tue Jul 12 11:04:42 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03EA321F8E1B for ; Tue, 12 Jul 2011 11:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.74 X-Spam-Level: X-Spam-Status: No, score=-103.74 tagged_above=-999 required=5 tests=[AWL=-1.141, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B00tmC3thz00 for ; Tue, 12 Jul 2011 11:04:41 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA8D21F8CA5 for ; Tue, 12 Jul 2011 11:04:41 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p6CI3g0i024324 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 12 Jul 2011 11:03:42 -0700 (PDT) Message-ID: <4E1C8C7E.1070700@isi.edu> Date: Tue, 12 Jul 2011 11:03:42 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: dcrocker@bbiw.net References: <4E17934C.8070905@dcrocker.net> <20110709022538.GA4308@mit.edu> <4E186249.2060707@dcrocker.net> <4E1C6F22.1030401@isi.edu> <4E1C72E0.2010005@dcrocker.net> <4E1C761D.6010409@isi.edu> <4E1C7B16.7010600@dcrocker.net> In-Reply-To: <4E1C7B16.7010600@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "saag@ietf.org" Subject: Re: [saag] The meaning of a signature (mid-course correction) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 18:04:42 -0000 On 7/12/2011 9:49 AM, Dave CROCKER wrote: > > > On 7/12/2011 9:28 AM, Joe Touch wrote: >> In that case it's defined by the signer. > > How is the verifier to know the intended meaning? a) by assuming the meaning b) by asking the signer Both, FWIW, just as with a paper signature. >> For one signer, it can mean "I read and agree to the terms in the email". > > I don't know what that means. What "terms in the email"? Some emails say "reply to this to confirm...". I've signed loan docs that say "if confirmed by entering the following code into the following link". *any* action specified in a doc *can* be taken as having meaning. How enforceable that is depends on a court decision. > Remember that this mechanism applies to /all/ email from the user. Notes > to their grandmother, reports to their boss and replies to a mailing list. Sure. And if you take a pen and ink and blindly automatically sign the bottom of every paper that passes over your desk, you *can* be bound by the consequences there too. It's all a question of the expectation of the meaning of the signature, but that's defined by convention (that sets assumptions), the signer (when made explicit), the person trying to enforce the interpretation, and a court (when there is disagreement). I simply don't see this as different from a written signature. Consider that: - a handwritten pen-and-ink takes deliberate action so a simple digital signature might not be taken as having that weight, regardless; it might be that it "must" include some other info, like "by entering this 10-digit number, you agree to...", something that requires document-specific deliberate action - automatic signatures - including by machine, and with a stamp - exist for ink signatures too and can carry as much (e.g., on some receipts I just received for a doctor's visit) or as little weight as the legal system will bear >> To another signer, it can mean "I assure that this came from me". >> >> However, if the doc itself says "if this is signed, it means X", then >> AFAICT >> you'd be in a courtroom needing to argue why you blindly signed >> everything >> without reading it. > > Perhaps your mailstream is different from mine, but I believe I've never > seen /any/ message with language like that in it and certainly none from > a stray user with an automated S/MIME or OpenPGP signature. I've noted cases in the past few days in my mailstream that had that property. They did depend on more explicit per-document action than just an external digital signature, though. > Consequently, the offered example doesn't resolve much of the real-world > use of S/MIME or OpenPGP... There's no resolution of the meaning of a signature in pen-and-ink. Why should the digital world be different? >>> So a rephrasing of the questions: >>> >>> 1. When a user's mail agent is configured to sign every outgoing >>> message, what is the (intended) "meaning" of that signature? >> >> IMO, that's (at best) determined by the signer, not the signature >> itself. And, >> as above, it can be determined by the content when explicit (even if not >> intended that way by the signer). > > Protocols work poorly when there is no shared meaning in the exchange. > Both ends of the exchange MUST make the same interpretation. That's often by assumption, not by explicit exchange. > Absent a means by which the verifier can know precisely the intended > meaning of the signature, the "authentication" mechanism is not a useful > protocol. Sure. If you want to be picky about it, then a digital signature means nothing unless the signer tells you in advance what they intended it to mean: - they wrote the message - they saw the message - their system touched the message - something else Strictly speaking, you *know* nothing. But then, the same is true for most human transactions. We get by with a lot of assumptions, ultimately. >>> 2. For such mail, what meaning should a receiver attribute to a >>> validated signature of this type. >> >> I generally assume it means "I assure that this message came from me >> intact", >> i.e., it was not forged or altered, unless told otherwise. > > I suspect that your use of the "me" refers to the person indicated in > the rfc5322.From field and that the email address in that From: field > matches the identifier in the signature...? Above I intended "me" as the owner of the signature, not the contents of what's signed. Joe From nico@cryptonector.com Tue Jul 12 11:36:18 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09FED21F8E2D for ; Tue, 12 Jul 2011 11:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.872 X-Spam-Level: X-Spam-Status: No, score=-2.872 tagged_above=-999 required=5 tests=[AWL=-0.896, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vO5Jq5bo61ac for ; Tue, 12 Jul 2011 11:36:14 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 008DA21F8E2F for ; Tue, 12 Jul 2011 11:36:13 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id A0CE42C807A for ; Tue, 12 Jul 2011 11:36:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=aO3qKeRrRkUig+iT4vOT2 PfHnJKJNwdCiUx2hwdu8qUWnw+2DV4s/Zp+teaNFf3KhR6b5RjJowsBD2BYknD4q jXJUJpxVs8T+6Tsl7L+t90SwoYskxDHFv0fuJH8aGAIR7uyjYvGS8GbME3pB/VV+ uKSCbV3UnbiaPqc8SF4ccs= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=IsxR+KZFuNEMxt+6DP6d /lpcwMM=; b=G0OUOhrigy26/F0Aq2Exr30sM4rVk9B7g19joAkN1XRaMGPgis0c 00R5xDsz+O/mxQJFDPqDK36GXqgYqb8bc6NUAgHr8cRNivauMdRheBX/j1c4C5oa PpC0NZFp/mVCdUy9Knk+p6X/96fSqk1+2MJmGBYrxFNc01xTXEuaRl4= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPSA id 8456F2C806C for ; Tue, 12 Jul 2011 11:36:13 -0700 (PDT) Received: by pzk5 with SMTP id 5so5837218pzk.31 for ; Tue, 12 Jul 2011 11:36:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.52.197 with SMTP id v5mr258199pbo.387.1310495773112; Tue, 12 Jul 2011 11:36:13 -0700 (PDT) Received: by 10.68.41.103 with HTTP; Tue, 12 Jul 2011 11:36:12 -0700 (PDT) Received: by 10.68.41.103 with HTTP; Tue, 12 Jul 2011 11:36:12 -0700 (PDT) In-Reply-To: References: <4E17934C.8070905@dcrocker.net> <20110709022538.GA4308@mit.edu> <4E186249.2060707@dcrocker.net> <4E1C6F22.1030401@isi.edu> <4E1C72E0.2010005@dcrocker.net> <4E1C761D.6010409@isi.edu> <4E1C7B16.7010600@dcrocker.net> <201107121733.NAA00955@Sparkle.Rodents-Montreal.ORG> Date: Tue, 12 Jul 2011 13:36:12 -0500 Message-ID: From: Nico Williams To: Nico Williams Content-Type: multipart/alternative; boundary=bcaec54307e609376a04a7e39381 Cc: saag@ietf.org Subject: Re: [saag] The meaning of a signature (mid-course correction) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 18:36:18 -0000 --bcaec54307e609376a04a7e39381 Content-Type: text/plain; charset=UTF-8 On Jul 12, 2011 12:46 PM, "Nico Williams" wrote: > What more could I want? Would I ever want a signature on an e-mail to > possibly denote something contractual? Maybe! But if so it will be > by agreed-upon convention between myself and my correspondents, and > most likely we'd agree to use different keys for different purposes > (because I believe in keeping good key hygiene). Actually, I'd not want to bother with digital signatures for contractual purposes unless my counterparties did too. --bcaec54307e609376a04a7e39381 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Jul 12, 2011 12:46 PM, "Nico Williams" <nico@cryptonector.com> wrote:
> What more could I want? =C2=A0Would I ever want a signature on an e-ma= il to
> possibly denote something contractual? =C2=A0Maybe! =C2=A0But if so it= will be
> by agreed-upon convention between myself and my correspondents, and > most likely we'd agree to use different keys for different purpose= s
> (because I believe in keeping good key hygiene).

Actually, I'd not want to bother with digital signatures for contrac= tual purposes unless my counterparties did too.

--bcaec54307e609376a04a7e39381-- From hilarie@purplestreak.com Tue Jul 12 17:06:04 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A86211E80C6 for ; Tue, 12 Jul 2011 17:06:02 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJbPd6JNsadv for ; Tue, 12 Jul 2011 17:06:01 -0700 (PDT) Received: from out02.mta.xmission.com (out02.mta.xmission.com [166.70.13.232]) by ietfa.amsl.com (Postfix) with ESMTP id 750A911E80C4 for ; Tue, 12 Jul 2011 17:06:01 -0700 (PDT) Received: from mx01.mta.xmission.com ([166.70.13.211]) by out02.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Qgmxk-0008B7-NB; Tue, 12 Jul 2011 18:06:00 -0600 Received: from 166-70-57-249.ip.xmission.com ([166.70.57.249] helo=sylvester.rhmr.com) by mx01.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Qgmxj-0001x6-84; Tue, 12 Jul 2011 18:06:00 -0600 Received: from sylvester.rhmr.com (localhost [127.0.0.1]) by sylvester.rhmr.com (8.14.4/8.14.3/Debian-9.1ubuntu1) with ESMTP id p6D05koi020476; Tue, 12 Jul 2011 18:05:46 -0600 Received: (from hilarie@localhost) by sylvester.rhmr.com (8.14.4/8.14.4/Submit) id p6D05kPN020475; Tue, 12 Jul 2011 18:05:46 -0600 Date: Tue, 12 Jul 2011 18:05:46 -0600 Message-Id: <201107130005.p6D05kPN020475@sylvester.rhmr.com> From: "Hilarie Orman" To: nico@cryptonector.com In-reply-to: Yourmessage X-XM-SPF: eid=; ; ; mid=; ; ; hst=mx01.mta.xmission.com; ; ; ip=166.70.57.249; ; ; frm=hilarie@purplestreak.com; ; ; spf=none X-XM-DomainKey: sender_domain=alum.mit.edu; ; ; sender=ho@alum.mit.edu; ; ; status=error X-SA-Exim-Connect-IP: 166.70.57.249 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa05 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;nico@cryptonector.com X-Spam-Relay-Country: X-SA-Exim-Version: 4.2.1 (built Fri, 06 Aug 2010 16:31:04 -0600) X-SA-Exim-Scanned: Yes (on mx01.mta.xmission.com) Cc: saag@ietf.org Subject: Re: [saag] The meaning of a signature (mid-course correction) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Hilarie Orman List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 00:06:04 -0000 > From: Nico Williams > To: Mouse > Cc: saag@ietf.org > Subject: Re: [saag] The meaning of a signature (mid-course correction) > On Tue, Jul 12, 2011 at 12:33 PM, Mouse wrote: > >> Absent a means by which the verifier can know precisely the intended > >> meaning of the signature, the "authentication" mechanism is not a > >> useful protocol. > > > > I disagree.  In the human layer (and, so far, crypto signatures on > > email are largely in the human layer), full precision is not necessary > > for a protocol to be useful. > Precisely so! (irony intended) > What's the meaning of a signature on an e-mail? The meaning is agreed > upon by convention among the senders and receivers. > If I see a signed e-mail, and the signature validates, and there's a > trust path for validating the sender's public key and the binding of > it to the sender's name then I "know" that the person in question > ("the sender") sent it. Many email accounts are shared. I think that the most you can hope for is that the key used to sign the message is "owned" by a person who might know or care about the content. Or that person knows someone who does. Maybe. Hilarie From warren@kumari.net Tue Jul 12 17:43:33 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FCCF11E80B8 for ; Tue, 12 Jul 2011 17:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id utWzGAzDxySI for ; Tue, 12 Jul 2011 17:43:32 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id A201311E807D for ; Tue, 12 Jul 2011 17:43:32 -0700 (PDT) Received: from [192.168.0.235] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id EBBD71B40AAB; Tue, 12 Jul 2011 20:43:31 -0400 (EDT) References: <201107130005.p6D05kPN020475@sylvester.rhmr.com> In-Reply-To: <201107130005.p6D05kPN020475@sylvester.rhmr.com> Mime-Version: 1.0 (iPhone Mail 8C148) Content-Type: text/plain; charset=utf-8 Message-Id: <12E81818-D107-4923-B0CC-A467D2A889F1@kumari.net> Content-Transfer-Encoding: quoted-printable X-Mailer: iPhone Mail (8C148) From: Warren Kumari Date: Tue, 12 Jul 2011 20:43:28 -0400 To: Hilarie Orman Cc: "saag@ietf.org" Subject: Re: [saag] The meaning of a signature (mid-course correction) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 00:43:33 -0000 Warren Kumari ------ Please excuse typing, etc -- This was sent from a device with a tiny keyboar= d. On Jul 12, 2011, at 8:05 PM, "Hilarie Orman" wrote: >> From: Nico Williams >> To: Mouse >> Cc: saag@ietf.org >> Subject: Re: [saag] The meaning of a signature (mid-course correction) >=20 >> On Tue, Jul 12, 2011 at 12:33 PM, Mouse wrot= e: >>>> Absent a means by which the verifier can know precisely the intended >>>> meaning of the signature, the "authentication" mechanism is not a >>>> useful protocol. >>>=20 >>> I disagree. =C3=82 In the human layer (and, so far, crypto signatures on= >>> email are largely in the human layer), full precision is not necessary >>> for a protocol to be useful. >=20 >> Precisely so! (irony intended) >=20 >> What's the meaning of a signature on an e-mail? The meaning is agreed >> upon by convention among the senders and receivers. >=20 >> If I see a signed e-mail, and the signature validates, and there's a >> trust path for validating the sender's public key and the binding of >> it to the sender's name then I "know" that the person in question >> ("the sender") sent it. >=20 > Many email accounts are shared. I think that the most you can hope > for is that the key used to sign the message is "owned" by a person > who might know or care about the content. Or that person knows > someone who does. Maybe. >=20 It "feels" to me that there should be some difference here between automated= signers and systems where I have to perform an act (like entering a passphr= ase to unlock my pgp secret). No, I don't know how the recipient knows that I did this (and things get mur= ky with gpg-agent type thing that cache this), but it feels like entering a p= assphrase is much more like physically signing a document / contract. This is a surprisingly interesting thread... W > Hilarie >=20 >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nico@cryptonector.com Tue Jul 12 17:56:47 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2BA211E80C7 for ; Tue, 12 Jul 2011 17:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.834 X-Spam-Level: X-Spam-Status: No, score=-2.834 tagged_above=-999 required=5 tests=[AWL=-0.857, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trM9dP0uGgV0 for ; Tue, 12 Jul 2011 17:56:43 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9E94C11E80D6 for ; Tue, 12 Jul 2011 17:56:43 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id 5F1F22F4060 for ; Tue, 12 Jul 2011 17:56:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=dz0XJJ8b5YAHd9JuAVCZ3 /WftLozaEBGdcByi99y+AJhwedw9hlXqNA6kLGdiEOYH+G5gWao4YPvsztH10y46 HkoMJ2aCi0qCtggsgEubRWx4FCkVbde3yfo5rIn8iDKHKY04y65GwhNWK5e+Yxt1 bZsZvwTIoXj9RTccr9sjNM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=rnYdA2/QJQR2/WjS9H4P A4Af9IQ=; b=VjsdS0HI2Kg24nBtN3OoJKeHDIs76wfsn7sgqDgNVM6knoD3Dj8c y55ggCWbfywVviP/pAlpkScihawZUEEaeOUNe1WsXundmnxgIkyiDUI0lbgpi2TV rzyPYjsC6rv+xagnIvIeJrNzMtzOsRQEenavYC/fnqh5VInF2oI68qU= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPSA id 463AD2F4055 for ; Tue, 12 Jul 2011 17:56:43 -0700 (PDT) Received: by pzk5 with SMTP id 5so6154650pzk.31 for ; Tue, 12 Jul 2011 17:56:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.66.130 with SMTP id f2mr533300pbt.521.1310518602938; Tue, 12 Jul 2011 17:56:42 -0700 (PDT) Received: by 10.68.41.103 with HTTP; Tue, 12 Jul 2011 17:56:42 -0700 (PDT) In-Reply-To: <12E81818-D107-4923-B0CC-A467D2A889F1@kumari.net> References: <201107130005.p6D05kPN020475@sylvester.rhmr.com> <12E81818-D107-4923-B0CC-A467D2A889F1@kumari.net> Date: Tue, 12 Jul 2011 19:56:42 -0500 Message-ID: From: Nico Williams To: Warren Kumari Content-Type: text/plain; charset=UTF-8 Cc: "saag@ietf.org" Subject: Re: [saag] The meaning of a signature (mid-course correction) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 00:56:47 -0000 On Tue, Jul 12, 2011 at 7:43 PM, Warren Kumari wrote: > It "feels" to me that there should be some difference here between automated signers and systems where I have to perform an act (like entering a passphrase to unlock my pgp secret). > > No, I don't know how the recipient knows that I did this (and things get murky with gpg-agent type thing that cache this), but it feels like entering a passphrase is much more like physically signing a document / contract. But since there's no way for your correspondents to verify that you did enter a passphrase (or that it and your keys haven't been stolen or abused by malware)... This gives you some degree of plausible deniability should you want to take some e-mail back. When we sign important documents in meatspace we get the signatures notarized, and, by implication, witnessed. It is the act of signing, and the fact that witnesses can testify to that act, that matters, not what is actually written. Therefore I would say that digital e-mail signatures are mostly uninteresting. (Using PGP to sign and encrypt e-mail for things like security vulnerability disclosure *is* interesting. Using PGP to sign one's every e-mail is mostly not.) Is it uninteresting to digitally sign documents? Well, software signatures are much more interesting that document signatures. Is there demand for and use of digital signature features in office productivity tools? > This is a surprisingly interesting thread... As others have pointed out, it is a bit of a rehash of old arguments. But yes, it's quite interesting. Nico -- From hallam@gmail.com Wed Jul 13 13:44:24 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E078D11E814A for ; Wed, 13 Jul 2011 13:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.517 X-Spam-Level: X-Spam-Status: No, score=-3.517 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQzhJGeKtVs6 for ; Wed, 13 Jul 2011 13:44:20 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id E5D7121F8AD3 for ; Wed, 13 Jul 2011 13:44:11 -0700 (PDT) Received: by yxp4 with SMTP id 4so3209743yxp.31 for ; Wed, 13 Jul 2011 13:44:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=Gal/dEzjqsBldqBoE2vq2xayAmxOUQJHAvwNzjeijQo=; b=v2LHOVpFAVTsOJay4YYqaE0NyZoH1a1h5W/kCh6e3xSBsSmE7tJllO2eErEIM9BMcY acaMfrEN9+fHScZCwrN9s/abeRfAAg9EihAaSKU0hqa2KpJlhSJ8j0L4RR/1e1sf/GUt Fb/atQ1QiZ8aYBsjgduYC4LQrP0kSQB3O7YfM= MIME-Version: 1.0 Received: by 10.101.179.7 with SMTP id g7mr1516245anp.102.1310589850991; Wed, 13 Jul 2011 13:44:10 -0700 (PDT) Received: by 10.100.93.12 with HTTP; Wed, 13 Jul 2011 13:44:10 -0700 (PDT) Date: Wed, 13 Jul 2011 16:44:10 -0400 Message-ID: From: Phillip Hallam-Baker To: saag@ietf.org Content-Type: multipart/alternative; boundary=001636c9266483bd7504a7f97a65 Subject: [saag] Harber and Stornetta Expiry X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 20:44:25 -0000 --001636c9266483bd7504a7f97a65 Content-Type: text/plain; charset=ISO-8859-1 Is anyone interested in getting together to discuss possibilities for IETF activities in the wake of the expiry (in at least some jurisdictions) of the above patent? Harber and Stornatta is the chained digest patent that provides a means of proving that a document was digested after date X and before date Y. In brief each has is chained into the next and the result periodically published in the classified section of the NYT. This allows a proof that the digest was performed in the interval between two successive hashes. The reason this is of immediate practical interest is the problem of 'unhistory'. As a lot of the primary collection and storage mechanisms for historical data become digital there is more and more scope for falsifying them. With an ordinary time stamp authority the question 'can we trust Alice not to modify the document' becomes 'can we trust the TSA not to collude with Alice'. There is an improvement but it is still a thin chain of trust. I would like to see the task of falsification be made much harder. When only one TSA had the technology there was no particular advantage to using it over a regular notary service either. The NYT will probably stop being printed in a few years time, libraries will certainly stop keeping paper copies (many have already) so the claim of permanency is being undermined in any case. Now there is an opportunity to do something more interesting. The technology is one thing, but to make it useful we need a social infrastructure to support it. The value of this approach above and beyond an ordinary TSA comes from having hundreds of independent agencies all providing services and auditing/hashing each other. So imagine a situation where there is a 'tier1' of providers which all undertake to provide a daily digest value that is fed into the digests of each of the others. It is now impossible for any individual provider to default without that default being seen globally. -- Website: http://hallambaker.com/ --001636c9266483bd7504a7f97a65 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Is anyone interested in getting together to discuss possibilities for IETF = activities in the wake of the expiry (in at least some jurisdictions) of th= e above patent?

Harber and Stornatta is the chained dige= st patent that provides a means of proving that a document was digested aft= er date X and before date Y. In brief each has is chained into the next and= the result periodically published in the classified section of the NYT. Th= is allows a proof that the digest was performed in the interval between two= successive hashes.

The reason this is of immediate practical interest is t= he problem of 'unhistory'. As a lot of the primary collection and s= torage mechanisms for historical data become digital there is more and more= scope for falsifying them.

With an ordinary time stamp authority the question '= ;can we trust Alice not to modify the document' becomes 'can we tru= st the TSA not to collude with Alice'. There is an improvement but it i= s still a thin chain of trust. I would like to see the task of falsificatio= n be made much harder.

When only one TSA had the technology there was no parti= cular advantage to using it over a regular notary service either. The NYT w= ill probably stop being printed in a few years time, libraries will certain= ly stop keeping paper copies (many have already) so the claim of permanency= is being undermined in any case. Now there is an opportunity to do somethi= ng more interesting.


The technology is one thing, but to make= it useful we need a social infrastructure to support it. The value of this= approach above and beyond an ordinary TSA comes from having hundreds of in= dependent agencies all providing services and auditing/hashing each other.= =A0

So imagine a situation where there is a 'tier1' of p= roviders which all undertake to provide a daily digest value that is fed in= to the digests of each of the others. It is now impossible for any individu= al provider to default without that default being seen globally.

--001636c9266483bd7504a7f97a65-- From stpeter@stpeter.im Tue Jul 19 11:52:42 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32BE611E8088; Tue, 19 Jul 2011 11:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.736 X-Spam-Level: X-Spam-Status: No, score=-102.736 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGyLcrZxoSYz; Tue, 19 Jul 2011 11:52:41 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2A29211E807A; Tue, 19 Jul 2011 11:52:20 -0700 (PDT) Received: from dhcp-64-101-72-201.cisco.com (unknown [64.101.72.201]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0146A4005A; Tue, 19 Jul 2011 12:52:59 -0600 (MDT) Message-ID: <4E25D262.3060401@stpeter.im> Date: Tue, 19 Jul 2011 12:52:18 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "kitten@ietf.org" , IETF Security Area Advisory Group Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [saag] Fwd: [apps-discuss] i18n intro, Sunday 14:00-16:00 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 18:52:42 -0000 This might be of interest given the use of stringprep in SASL... -------- Original Message -------- Subject: [apps-discuss] i18n intro, Sunday 14:00-16:00 Date: Tue, 19 Jul 2011 12:48:39 -0600 From: Peter Saint-Andre To: apps-discuss@ietf.org You might have noticed a curious item on the agenda at 14:00 on Sunday: "Apps Area Preparatory Meeting for Internationalization Working Groups". At that time, I will present an introduction to internationalization, assisted by Pete Resnick (who will correct me where I go wrong). The intent of this session is to help apps-area folks learn more about internationalization, especially in preparation for the PRECIS WG meeting on Thursday. The room we've been assigned (2103) holds up to 60 people so we should have plenty of space, and there is no need to sign up if you want to attend. If this session goes well, Pete and I might offer a more general tutorial at a future IETF meeting. Consider Sunday's session a dry run. See you in Quebec City! Peter -- Peter Saint-Andre https://stpeter.im/ _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From stephen.farrell@cs.tcd.ie Sun Jul 24 08:24:07 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73DF121F85F7; Sun, 24 Jul 2011 08:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9TlOWk-FTdUN; Sun, 24 Jul 2011 08:24:06 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 93A5721F89BE; Sun, 24 Jul 2011 08:24:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id F1C51171C73; Sun, 24 Jul 2011 16:23:58 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1311521036; bh=AWw0B9KhlJqbbS 4GKM5UtHo3hB9+W+F/AL7FGEmC4hA=; b=v2yUsJyqjVT4J8gNH5RuVx6ntuFD2y LAQt+M4kcubRwgk4afW0eLhghzW3inlGexn3XL5ml2pd3Eocrs8zzwVwCUYwf3mt 2yjBrQRB8UBTYh5w1hs7blx4AIxI/i3iiQZZlceqBEaWlPsapiC3UKyyYpjSBUnc /plLxaPdKZ9EtHDVI0d4CfaZNfRTkoyQGtNUGEFopL2ARVAY00NhE9NrhiPXxwd0 64QdooKHKFoEcibMKbBG1Yb66+YDn0twFJ+M26syqOtIe6IU7XIGeTHHkWV4Mx/N uc1GOGqXaUn0n1WlA2vuoV0yI0rGK0/YHFMZjDLuKGII5Zn0vXHqK3uA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id XRws5YROZAuN; Sun, 24 Jul 2011 16:23:56 +0100 (IST) Received: from [130.129.39.94] (unknown [130.129.39.94]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 991C1171BFE; Sun, 24 Jul 2011 16:23:56 +0100 (IST) Message-ID: <4E2C38F5.4090004@cs.tcd.ie> Date: Sun, 24 Jul 2011 16:23:33 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: "saag@ietf.org" , smime@ietf.org References: <20101201161335.3154FE070E@rfc-editor.org> In-Reply-To: <20101201161335.3154FE070E@rfc-editor.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [saag] Fwd: [Technical Errata Reported] RFC5958 (2653) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2011 15:24:07 -0000 Just in case anyone cares I plan to mark this verified tomorrow unless I hear something to the contrary. The only reason to send it around is that Sean submitted it, I'll be verifying it and there's no current WG to shout stop, so this is really just a transparency thing. If you read the erratum, I think it'll be crystal clear that verify is the right thing. S. -------- Original Message -------- Subject: [Technical Errata Reported] RFC5958 (2653) Date: Wed, 1 Dec 2010 08:13:35 -0800 (PST) From: RFC Errata System To: turners@ieca.com, iesg@iesg.org CC: turners@ieca.com, rfc-editor@rfc-editor.org The following errata report has been submitted for RFC5958, "Asymmetric Key Packages". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5958&eid=2653 -------------------------------------- Type: Technical Reported by: Sean Turner Section: 2 and App A Original Text ------------- ct-asymmetric-key-package CONTENT-TYPE ::= { AsymmetricKeyPackage IDENTIFIED BY id-ct-KP-aKeyPackage } Corrected Text -------------- ct-asymmetric-key-package CONTENT-TYPE ::= { TYPE AsymmetricKeyPackage IDENTIFIED BY id-ct-KP-aKeyPackage } Notes ----- With the approval of errata 2612 (http://www.rfc-editor.org/errata_search.php?eid=2612), the asymmetric key package content type definition also needs to be updated to add "TYPE" to the CONTENT-TYPE definition. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5958 (draft-turner-asymmetrickeyformat-05) -------------------------------------- Title : Asymmetric Key Packages Publication Date : August 2010 Author(s) : S. Turner Category : PROPOSED STANDARD Source : IETF - NON WORKING GROUP Area : N/A Stream : IETF Verifying Party : IESG From turners@ieca.com Sun Jul 24 10:17:54 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0210121F88DD for ; Sun, 24 Jul 2011 10:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.206 X-Spam-Level: X-Spam-Status: No, score=-102.206 tagged_above=-999 required=5 tests=[AWL=0.392, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6OelpdmXw3U for ; Sun, 24 Jul 2011 10:17:53 -0700 (PDT) Received: from nm12.bullet.mail.sp2.yahoo.com (nm12.bullet.mail.sp2.yahoo.com [98.139.91.82]) by ietfa.amsl.com (Postfix) with SMTP id 6792B21F85B2 for ; Sun, 24 Jul 2011 10:17:53 -0700 (PDT) Received: from [98.139.91.64] by nm12.bullet.mail.sp2.yahoo.com with NNFMP; 24 Jul 2011 17:17:53 -0000 Received: from [98.139.91.29] by tm4.bullet.mail.sp2.yahoo.com with NNFMP; 24 Jul 2011 17:17:53 -0000 Received: from [127.0.0.1] by omp1029.mail.sp2.yahoo.com with NNFMP; 24 Jul 2011 17:17:53 -0000 X-Yahoo-Newman-Id: 354711.20642.bm@omp1029.mail.sp2.yahoo.com Received: (qmail 96528 invoked from network); 24 Jul 2011 17:17:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1311527873; bh=+0ocqBPRC36rpkwXRqzebg6hcsNOQvSOsNSCNAq3FzY=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=WqduyCsFQRCDW77BDAoeX1247L8+vWscWLwAukknmiRkXOzyah+4BDQdxN4onnqC41b60IcuJo7IKe8peai/GfMzvzH4OqNXoWSrVBXDiUxCYw36HWPpyh/lMv3ovOOqNjlx98VpBTQKq4uoxXUaYLugByyBE418ZhVob9WC528= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: .FcQr.wVM1kcZ6sCYtDdwxZrYxOHEIE._U4EqAd3q.X8Gp4 kaU0xi4yIkUtZmsiShm5_tW36pNHV9m_vtHe1_0LUkdwk7HQnE5Z1WEbd__0 fQdJm6mfqlqLcgF4pzd02HAlkfl.hqO8lFRwDD6rQNlf6lVmm7_a0SQ2NZfm EYp8iYuJ4aZ9qWgQkq7VMHDwQOkblMQyFMmIw_lrd3Bnc2tpkPVzhr6PaR1A kdiaf2AXFbBy8FyhSluH7J9iQGuyFl1kwnH9_8BRwdeKuYGyBHFa3uS5CtCk K_PNsRaT19vkxKz3.7umG2yAbz.E8COPjILM90uIZATRaNumcMUnFLAcIgqd ufy9NL9xNKPZP5ymTAeBHHGQHS2dDt6SRVO5gQAiaN7G8NiboT52zv_EeQR9 ZE9TXvfKAck5nzVp075Y0EdWFkCwBXkub80dV5OkRZr2nQQEniw-- X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ Received: from dhcp-1598.meeting.ietf.org (turners@198.180.150.230 with plain) by smtp113.biz.mail.sp1.yahoo.com with SMTP; 24 Jul 2011 10:17:53 -0700 PDT Message-ID: <4E2C53BF.70103@ieca.com> Date: Sun, 24 Jul 2011 13:17:51 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: saag@ietf.org References: <4DC6C56D.6040709@ieca.com> In-Reply-To: <4DC6C56D.6040709@ieca.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [saag] fyi: tcpcrypt draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2011 17:17:54 -0000 This draft is being presented at the TSVAREA meeting Thursday morning (room:205ABC). Both Stephen and I have other engagements, but if you're not headed to another session at that time then it would be great if some of you would head there to interact with the presenter(s). spt On 5/8/11 12:31 PM, Sean Turner wrote: > The authors of the following draft have asked that I forward this to > saag for comment: > > https://datatracker.ietf.org/doc/draft-bittau-tcp-crypt/ > > They also noted that there's a Usenix Security paper and video: > http://tcpcrypt.org/docs.php > > Please direct discussion to tsv-area@ietf.org. > > Cheers, > > spt > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From mark.j.handley@gmail.com Sun Jul 24 10:56:37 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CCCD21F874C for ; Sun, 24 Jul 2011 10:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69tB1YwEQump for ; Sun, 24 Jul 2011 10:56:36 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 80BA621F86D8 for ; Sun, 24 Jul 2011 10:56:36 -0700 (PDT) Received: by ywp31 with SMTP id 31so2203086ywp.31 for ; Sun, 24 Jul 2011 10:56:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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 :content-transfer-encoding; bh=V15zPzAV2KE3BxrLDPNY6MmJgeTtruoEzhLLtOUgJyY=; b=XQR7SWG2D7b4dSclN0zdTBP0HGtPA7ZNeTHm3o1OZug6JXXqWJwNu/kAZKFJmeh1to gD6yukq5hlTLENxGevaZJNwLo3T3caAC/jGkflxWomGHbFtjNijIpBD/i20sTQ6mrFYO 6NkljsN/jYMY3WuD0vQvIGgPjJKXiRIleSxBk= Received: by 10.236.157.67 with SMTP id n43mr4380475yhk.95.1311530195156; Sun, 24 Jul 2011 10:56:35 -0700 (PDT) MIME-Version: 1.0 Sender: mark.j.handley@gmail.com Received: by 10.236.102.166 with HTTP; Sun, 24 Jul 2011 10:56:15 -0700 (PDT) In-Reply-To: <4E2C53BF.70103@ieca.com> References: <4DC6C56D.6040709@ieca.com> <4E2C53BF.70103@ieca.com> From: Mark Handley Date: Sun, 24 Jul 2011 18:56:15 +0100 X-Google-Sender-Auth: ASr6pmfU3QkPrwFv-RdcOQjs39w Message-ID: To: Sean Turner Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: saag@ietf.org Subject: Re: [saag] fyi: tcpcrypt draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2011 17:56:37 -0000 Just a brief update: - We conducted a pretty extensive study into whether extending TCP in this way would be deployable, or whether we've missed something, and we've done more testing. The draft paper is here: http://nrg.cs.ucl.ac.uk/mjh/tmp/mboxes.pdf The one thing that came out of this is that you cannot reliably MAC TCP sequence numbers in today's Internet. Far too many paths rewrite them, even if they don't do anything else odd to TCP flows. There'll be a new draft right after the IETF that reflects this - we now MAC the offset from the initial sequence number instead. - We're looking at a library that provides a shim authentication layer over tcpcrypt at the moment. In part, this is to let tcpcrypt play nicely with DANE - this seems a good match. Early days on this at the moment though. Cheers, Mark On 24 July 2011 18:17, Sean Turner wrote: > This draft is being presented at the TSVAREA meeting Thursday morning > (room:205ABC). =A0Both Stephen and I have other engagements, but if you'r= e not > headed to another session at that time then it would be great if some of = you > would head there to interact with the presenter(s). > > spt > > On 5/8/11 12:31 PM, Sean Turner wrote: >> >> The authors of the following draft have asked that I forward this to >> saag for comment: >> >> https://datatracker.ietf.org/doc/draft-bittau-tcp-crypt/ >> >> They also noted that there's a Usenix Security paper and video: >> http://tcpcrypt.org/docs.php >> >> Please direct discussion to tsv-area@ietf.org. >> >> Cheers, >> >> spt >> >> >> >> _______________________________________________ >> 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 > From mcgrew@cisco.com Mon Jul 25 13:48:50 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3CED11E809A for ; Mon, 25 Jul 2011 13:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.369 X-Spam-Level: X-Spam-Status: No, score=-103.369 tagged_above=-999 required=5 tests=[AWL=-0.770, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHc9NSH4yTEy for ; Mon, 25 Jul 2011 13:48:49 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id A984D11E8093 for ; Mon, 25 Jul 2011 13:48:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=2379; q=dns/txt; s=iport; t=1311626929; x=1312836529; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=2owUAbXoTJdVajb1lxQ7IcB9B5YudKhjCdnCFE8vouE=; b=h9TTGW5lnT5R2vgETjfFkPV4aSh6TbSpzbZHKaTMvtmmqcXo3yDVXoT5 J5TJCUJ30g06LyzhRfnVGSrOxjhPjkodEQIuSb3nr6Vk1l1js5efvGJc8 k0r7jKG0CaNwkFN8iFiRB1b+27SYqe1w2a2lGyqjrridhZzjNTPxI8Nr1 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFzWLU6rRDoG/2dsb2JhbAA0AQEBAQEBAQEBAQgJASkCOgsFDAwOCjoUGDkFAhcnpzR3iHwEI6EznjSFYF8Eh1WHZoM1hQeEY4Y/Vw X-IronPort-AV: E=Sophos;i="4.67,264,1309737600"; d="scan'208";a="6256585" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-6.cisco.com with ESMTP; 25 Jul 2011 20:48:49 +0000 Received: from [130.129.23.131] ([10.86.245.213]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6PKmlbC026425; Mon, 25 Jul 2011 20:48:48 GMT Message-Id: From: David McGrew To: Mark Handley In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 25 Jul 2011 13:48:48 -0700 References: <4DC6C56D.6040709@ieca.com> <4E2C53BF.70103@ieca.com> X-Mailer: Apple Mail (2.936) Cc: saag@ietf.org Subject: Re: [saag] fyi: tcpcrypt draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 20:48:50 -0000 Hi Mark, I asked a bunch of questions on tcpcrypt back in May, on this mail thread. Would it be possible for you or the other authors to respond before the presentation on Thurs? David On Jul 24, 2011, at 10:56 AM, Mark Handley wrote: > Just a brief update: > > - We conducted a pretty extensive study into whether extending TCP in > this way would be deployable, or whether we've missed something, and > we've done more testing. The draft paper is here: > > http://nrg.cs.ucl.ac.uk/mjh/tmp/mboxes.pdf > > The one thing that came out of this is that you cannot reliably MAC > TCP sequence numbers in today's Internet. Far too many paths rewrite > them, even if they don't do anything else odd to TCP flows. There'll > be a new draft right after the IETF that reflects this - we now MAC > the offset from the initial sequence number instead. > > - We're looking at a library that provides a shim authentication layer > over tcpcrypt at the moment. In part, this is to let tcpcrypt play > nicely with DANE - this seems a good match. Early days on this at the > moment though. > > Cheers, > Mark > > > On 24 July 2011 18:17, Sean Turner wrote: >> This draft is being presented at the TSVAREA meeting Thursday morning >> (room:205ABC). Both Stephen and I have other engagements, but if >> you're not >> headed to another session at that time then it would be great if >> some of you >> would head there to interact with the presenter(s). >> >> spt >> >> On 5/8/11 12:31 PM, Sean Turner wrote: >>> >>> The authors of the following draft have asked that I forward this to >>> saag for comment: >>> >>> https://datatracker.ietf.org/doc/draft-bittau-tcp-crypt/ >>> >>> They also noted that there's a Usenix Security paper and video: >>> http://tcpcrypt.org/docs.php >>> >>> Please direct discussion to tsv-area@ietf.org. >>> >>> Cheers, >>> >>> spt >>> >>> >>> >>> _______________________________________________ >>> 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 >> > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From barryleiba.mailing.lists@gmail.com Mon Jul 25 15:11:44 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFD8621F8BB4 for ; Mon, 25 Jul 2011 15:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.07 X-Spam-Level: X-Spam-Status: No, score=-103.07 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJPoAH7baVn6 for ; Mon, 25 Jul 2011 15:11:43 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 03F9521F8A70 for ; Mon, 25 Jul 2011 15:11:39 -0700 (PDT) Received: by yie30 with SMTP id 30so2940403yie.31 for ; Mon, 25 Jul 2011 15:11:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=VjKFqxBRTS7+k1xXraGV75mK6MGiOXEwTHRf4Lf1/IY=; b=NUozEopG90LmfSQ8T4oxYqRL7qc7FjDnXgNf2KCqUYJhYoO/BXmLNFs9n2x55wIPwB 36nW+XUFcPkqlEGe25/QA0SUGB11SBCqzWnxWrjYQivqSU7mAjDhJ8qITS5oczPzSZw3 4nVeP+3hWMIEt4uwXTQHAbq/BqwgYwGorTgq0= MIME-Version: 1.0 Received: by 10.146.134.18 with SMTP id h18mr4535065yad.8.1311631899284; Mon, 25 Jul 2011 15:11:39 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.99.7 with HTTP; Mon, 25 Jul 2011 15:11:37 -0700 (PDT) Date: Mon, 25 Jul 2011 18:11:37 -0400 X-Google-Sender-Auth: d4bYIoQC5Ht3Eli0cSUkb0WtHsk Message-ID: From: Barry Leiba To: saag Content-Type: text/plain; charset=ISO-8859-1 Subject: [saag] DKIM summary for IETF 81 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 22:11:45 -0000 DKIM is not meeting at IETF 81. We've finished all our documents, and the last two are in the RFC Editor queue. The WG will shut down once the RFCs are published. Barry, DKIM chair From dhc2@dcrocker.net Mon Jul 25 15:36:54 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71D0411E80CF for ; Mon, 25 Jul 2011 15:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbe8Dm5UrJT0 for ; Mon, 25 Jul 2011 15:36:53 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id E4BBA11E80B1 for ; Mon, 25 Jul 2011 15:36:53 -0700 (PDT) Received: from [130.129.85.251] ([130.129.85.251]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p6PMalsU017249 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Mon, 25 Jul 2011 15:36:53 -0700 Message-ID: <4E2DEFFE.6000408@dcrocker.net> Date: Mon, 25 Jul 2011 18:36:46 -0400 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: saag@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 25 Jul 2011 15:36:53 -0700 (PDT) Subject: Re: [saag] DKIM summary for IETF 81 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 22:36:54 -0000 I think it worth noting, based on today's announcement from IETF staff, that Barry's report ate the wg's dogfood; it was signed with DKIM... d/ On 7/25/2011 6:11 PM, Barry Leiba wrote: > DKIM is not meeting at IETF 81. We've finished all our documents, and > the last two are in the RFC Editor queue. The WG will shut down once > the RFCs are published. -- Dave Crocker Brandenburg InternetWorking bbiw.net From kathleen.moriarty@emc.com Mon Jul 25 09:16:23 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F02CA21F8C60; Mon, 25 Jul 2011 09:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IEcAe+9Hb3nJ; Mon, 25 Jul 2011 09:16:21 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 8533A21F8B2C; Mon, 25 Jul 2011 09:05:14 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p6PG5CFt006749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Jul 2011 12:05:12 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Mon, 25 Jul 2011 12:04:58 -0400 Received: from mxhub05.corp.emc.com (mxhub05.corp.emc.com [128.221.46.113]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p6PG4tS6032529; Mon, 25 Jul 2011 12:04:56 -0400 Received: from mx06a.corp.emc.com ([169.254.1.199]) by mxhub05.corp.emc.com ([128.221.46.113]) with mapi; Mon, 25 Jul 2011 12:04:56 -0400 From: To: , , , Date: Mon, 25 Jul 2011 12:03:01 -0400 Thread-Topic: [mile] MILE side meeting, IETF81 in Quebec, Monday night July 25th Thread-Index: Acw/1zHu8XSL9OlJSqS/YBLsoFS60QLDSImh Message-ID: References: , 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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 X-Mailman-Approved-At: Mon, 25 Jul 2011 16:21:35 -0700 Subject: Re: [saag] [mile] MILE side meeting, IETF81 in Quebec, Monday night July 25th X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 16:16:23 -0000 Hello, Tonight's side meeting for MILE will be held in Room 301A, starting right a= fter the plenary at 19:30 EST. We plan to use the following bridge number = for those who could not be here in person: Dial-in: 857.207.4204, 1, 60363236# Global access numbers are listed at the end of this message. Thank you, Kathleen & Brian ________________________________________ From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Brian Tram= mell [trammell@tik.ee.ethz.ch] Sent: Monday, July 11, 2011 10:30 AM To: ietf@ietf.org; saag@ietf.org Cc: mile@ietf.org Subject: [mile] MILE side meeting, IETF81 in Quebec, Monday night July 25th Greetings, all, To help us plan a bit for the (previously-announced) MILE pre-WG side meeti= ng in Quebec, 19:30 Monday 25 July, after the technical plenary meeting, pl= ease let us know if you are interested in attending by filling out the dood= le at: http://www.doodle.com/e2w494tce6knmq6m The working proposed charter is attached below for reference. Further detai= ls will be announced later. Many thanks, and best regards, Brian and Kathleen Managed Incident Lightweight Exchange (mile) -------------------------------------------- Proposed Working Group Charter Chairs: Kathleen Moriarty Brian Trammell Security Area Directors: Stephen Farrell > Sean Turner > Security Area Advisor: Sean Turner Mailing Lists: General Discussion: mile@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/mile Archive: http://www.ietf.org/mail-archive/web/mile Description: The Managed Incident Lightweight Exchange (MILE) pre-working group will dev= elop standards and extensions for the purpose of improving incident informa= tion sharing and handling capabilities based on the work developed in the I= ETF Extended INCident Handling (INCH) working group. The Incident Object D= escription Exchange Format (IODEF) in RFC5070 and Real-time Inter-network D= efense (RID) in RFC6045 were developed in the INCH working group by interna= tional Computer Security Incident Response Teams (CSIRTs) and industry to m= eet the needs of a global community interested in sharing, handling, and ex= changing incident information. The extensions and guidance created by the = MILE working group assists with the daily operations of CSIRTs at an organi= zation, service provider, law enforcement, and at the country level. The a= pplication of IODEF and RID to interdomain incident information cooperative= exchange and sharing has recently expanded and the need for extensions has= become more im portant. Efforts continue to deploy IODEF and RID, as well as to extend the= m to support specific use cases covering reporting and mitigation of curren= t threats such as anti-phishing extensions. An incident could be a benign configuration issue, IT incident, an infracti= on to a service level agreement (SLA), a system compromise, socially engine= ered phishing attack, or a denial-of-service (DoS) attack, etc.. When an i= ncident is detected, the response may include simply filing a report, notif= ication to the source of the incident, a request to a third party for resol= ution/mitigation, or a request to locate the source. IODEF defines a data = representation that provides a standard format for sharing information comm= only exchanged about computer security incidents. RID enables the secure e= xchange of incident related information in an IODEF format providing option= s for security, privacy, and policy setting. MILE leverages collaboration and sharing experiences with the work develope= d in the INCH working group which includes the data model detailed in the I= ODEF, existing extensions to the IODEF for Anti-phishing (RFC5901), and RID= (RFC6045, RFC6046) for the secure exchange of information. MILE will also= leverage the experience gained in using IODEF and RID in operational conte= xts. Related work, drafted outside of INCH will also be reviewed and includ= es RFC5941, Sharing Transaction Fraud Data. The MILE working group provides coordination for these various extension ef= forts to improve the capabilities for exchanging incident information. MIL= E has several objectives with the first being a description a subset of IOD= EF focused on ease of deployment and applicability to current information s= ecurity data sharing use cases. MILE also describes a generalization of RI= D for secure exchange of other security-relevant XML formats. MILE produce= s additional guidance needed for the successful exchange of incident inform= ation for new use cases according to policy, security, and privacy requirem= ents. Finally, MILE produces a document template with guidance for definin= g IODEF extensions to be followed when producing extensions to IODEF as app= ropriate, for: * labeling incident reports with data protection, data retention, and othe= r policies, regulations, and laws restricting the handling of those reports * reporting on mail service abuse incidents * reporting forensic data generated during incident investigation * reporting indicators of compromise in incident reports * reporting on financial fraud incidents * reporting incidents involving virtualized environments * referencing SCAP enumerations from within incident reports * profiling and reporting on characteristics of malware suspected or confi= rmed to be involved in an incident * profiling and reporting on characteristics of actors (persons or groups)= suspected or confirmed to be involved in an incident * reporting on misuse incidents _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile Global Access Numbers =95 Toll-free number Freefone number that participants can use to dial in to your call and will = not be charged. =95 International toll dial-in number Toll number available globally. Use when neither toll-free nor local toll i= s listed for your country. =95 Local toll dial-in number Local, in-country numbers that incur a local call charge. Use when no toll-= free number is listed for your country. If your country isn't listed below, please use +1 857 207 4204 Note (as of 6/30/11): There are new toll free dial-in numbers for Mexico an= d Brazil. The new Mexico toll free dial-in number is listed below. For the = new Brazil toll free dial-in number, please contact the help desk. Please b= e sure to use these numbers for all future meetings, as the prior numbers (= not listed) will be disconnected on July 31. If you are dialing from Ecuador, Egypt, Ghana, Honduras, India, Jordan or T= urkey, please click here for additional dialing instructions For Philippines dial-in number, please contact the Help desk Country Toll-free # Local toll dial-in # Int'l toll dial-in # Antigua 18009881093 =20 Argentina 08006663580 053541170 +54 53541170 Australia 1800107895 =20 Australia 1800097161 01280238327 +61 1280238327 Austria 0800293883 01206091042 +43 1206091042 Bahamas 18009887511 =20 Bahrain 80004370 =20 Belgium 080080799 022006492 +32 22006492 Bolivia 800100617 =20 Chile 12300200430 =20 China 108007121934 (Netcom only) =20 China 108001201934 (Telecom only) 4008811625 (Netcom, Telecom and all mobile acce= ss) +86 4008811625 (Netcom, Telecom and all mobile access) China 4001200029 (Netcom, Telecom and China Mobile) +86 4001200029 (Netcom, Tel= ecom and China Mobile) Colombia 018009440105 =20 Costa Rica 08000440080 =20 Cyprus 80092424 =20 Czech Republic 800142864 239014112 +420 239014112 Denmark 80889478 43682063 +45 43682063 Dominican Republic 18888038749 =20 Ecuador 8009887511 (Click here for access code to dial before dialing numbe= r) =20 Egypt 08000000271 =20 Egypt 8885409783 (Click here for access code to dial before dialing number) =20 Estonia 8000044320 =20 Finland 0800919478 0972519186 +358 972519186 France 0805540147 0157323313 +33 157323313 Germany 08006646745 06950985552 +49 6950985552 Ghana 217013261 +233 217013261 Greece 0080044145248 =20 Grenada 18009881111 =20 Honduras 8009887511 (Click here for access code to dial before dialing numb= er) =20 Hong Kong 800930871 30114650 +852 30114650 Hungary 0680016578 0617779141 +36 17779141 Iceland 8008880 =20 India 0008004401562 =20 India 8006981070 (Click here for access code to dial before dialing number) =20 Indonesia 001803441067 =20 Ireland 1800882434 012420715 +353 12420715 Israel 1809440999 =20 Italy 800871598 0291483215 +39 0291483215 Jamaica 18009881120 =20 Japan 0120925830 0357679520 +81 357679520 Jordan 8009887511 (Click here for access code to dial before dialing number= ) =20 Latvia 80002944 =20 Lithuania 880030687 =20 Luxembourg 80024059 24871035 +352 24871035 Malaysia 1800814162 0362074117 +60 362074117 Mexico 018005630627 =20 Netherlands 08000201642 0202008462 +31 202008462 New Zealand 0800991168 099164905 +64 99164905 Norway 80010740 24159766 +47 24159766 Panama 008000441121 =20 Peru 080053571 =20 Poland 008004421075 0223060053 +48 223060053 Portugal 800844676 217616089 +351 217616089 Romania 0800894796 =20 Russia 81080022381044 84992722055 +7 4992722055 Saudi Arabia 8008444687 =20 Singapore 8004481568 66221240 +65 66221240 South Africa 0800166372 =20 South Korea 007984420995 0234837092 +82 234837092 Spain 900811826 912754650 +34 912754650 Sweden 020790087 0851761388 +46 851761388 Switzerland 0800562306 0445118108 +41 445118108 Taiwan 00801444395 0221621838 +886 221621838 Thailand 0018004411019 =20 Turkey 00800448829160 =20 Turkey 8885409783 (Click here for access code to dial before dialing number= ) =20 United Arab Emirates 80004414961 =20 United Kingdom 08001214662 02030249140 +44 2030249140 United States 8886433084 18572074204 +1 8572074204 Venezuela 08001766485 =20 From yaronf.ietf@gmail.com Tue Jul 26 06:47:09 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3BDB21F874E for ; Tue, 26 Jul 2011 06:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.234 X-Spam-Level: X-Spam-Status: No, score=-103.234 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFiL17u3e9ey for ; Tue, 26 Jul 2011 06:47:09 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id DFEFA21F86EA for ; Tue, 26 Jul 2011 06:47:08 -0700 (PDT) Received: by wwe5 with SMTP id 5so355781wwe.13 for ; Tue, 26 Jul 2011 06:47:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-forwarded-message-id:content-type :content-transfer-encoding; bh=ly6YS6cFxaoft8bgAlaWkAgvRWGA+roRuHmZCRhHtPI=; b=vy71DBbCMX0AFn4ga8loXX3UKi14HDB5tBtqVld2YStLY+iHqgzcdZDKMIzqV5WwYj yrPL0c1y+c8cuPW9ZezpxxcFjKp54pMYMoj3UVR8YJFn/Rh4AacgEEJHBc/j1DYqslbQ 1KqUku76IvhhJy2juN3Xs5Aq7dhYUS4Q/XdU8= Received: by 10.227.135.9 with SMTP id l9mr4930557wbt.34.1311688028003; Tue, 26 Jul 2011 06:47:08 -0700 (PDT) Received: from [10.0.0.6] (93-173-6-225.bb.netvision.net.il [93.173.6.225]) by mx.google.com with ESMTPS id o19sm445462wbh.43.2011.07.26.06.47.06 (version=SSLv3 cipher=OTHER); Tue, 26 Jul 2011 06:47:07 -0700 (PDT) Message-ID: <4E2EC559.3060705@gmail.com> Date: Tue, 26 Jul 2011 16:47:05 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110627 Thunderbird/5.0 MIME-Version: 1.0 To: "saag@ietf.org" References: <4E2EC467.2010108@gmail.com> In-Reply-To: <4E2EC467.2010108@gmail.com> X-Forwarded-Message-Id: <4E2EC467.2010108@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: [saag] IPsecme WG update X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 13:47:09 -0000 We just posted this update to the ipsecme mailing list. This is where we're at right now... --- Hi, The working group recently published its last chartered deliverable, RFC 6311 (HA Protocol). We would like to use this opportunity to thank the authors. The group has not met for the last few IETF meetings, and will not meet this week in Quebec City. The current charter (http://tools.ietf.org/wg/ipsecme/charters) is set to auto-expire by 2/2012, which means the group is now officially going into hibernation, and will disband in February unless we have a new charter before that date. If you have a work item that you believe will be of interest to multiple WG participants, you will need to raise it on the mailing list and to get enough group support to explicitly add it to the charter. You will need to convince the chairs and ADs that several people with different affiliations are committed to contribute to the work item. Otherwise, the alternative document streams (Independent or Individual) are your best bet. We are open to suggestions for new work items, but are not actively trying to keep the WG open. Any proposals would need to come with commitments from more than just one or two people to work on them. Thanks, Paul and Yaron From william.polk@nist.gov Wed Jul 27 11:03:21 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB2211E80DF for ; Wed, 27 Jul 2011 11:03:21 -0700 (PDT) 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=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHYfM8XaCabN for ; Wed, 27 Jul 2011 11:03:20 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 3E15C11E8075 for ; Wed, 27 Jul 2011 11:03:20 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.323.0; Wed, 27 Jul 2011 14:03:05 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Wed, 27 Jul 2011 14:02:49 -0400 From: "Polk, William T." To: "saag@ietf.org" Date: Wed, 27 Jul 2011 14:02:49 -0400 Thread-Topic: Draft 800-56C is posted for the second public comments Thread-Index: AQHMTIdkyDqsK7vzoEeVgpkStDtodw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Subject: [saag] Draft 800-56C is posted for the second public comments X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 18:03:21 -0000 A new draft NIST publication is available that may be of interest to the IETF. This document is related to, and inspired in part by, RFC 5869 "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)". Since I failed to forward the announcement of the first public comment period (sorry folks!) I wanted to be sure people were aware of the second public comment period. The NIST announcement follows: Second draft of 800-56C: Recommendation for Key Derivation through Extraction-then-Expansion is posted for public comments. The initial draft was released in September 2010. This second version incorporates resolutions to the comments received during the first comment period. This Recommendation specifies techniques for the derivation of keying material from a shared secret established during a key establishment scheme defined in NIST Special Publications 800-56A or 800-56B through an extraction-then-expansion procedure. NIST is in the process of modifying SP 800-56A and SP 800-56B to include the extraction-then-expansion key derivation procedure specified in this draft Recommendation (800-56C). You can find the second draft of NIST SP 800-56C 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. The comment period closes on August 11, 2011. Your comments would certainly be appreciated! Thanks, Tim Polk From mark.j.handley@gmail.com Wed Jul 27 13:34:01 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D82FD11E8104 for ; Wed, 27 Jul 2011 13:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkikmI71OqHE for ; Wed, 27 Jul 2011 13:34:00 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id A262E11E812F for ; Wed, 27 Jul 2011 13:34:00 -0700 (PDT) Received: by yxp4 with SMTP id 4so1346874yxp.31 for ; Wed, 27 Jul 2011 13:34:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type :content-transfer-encoding; bh=JFjxmFSs6l96Cb36YqRqzoftgkS9uL57H51HOmco4vQ=; b=YwekPCFN8WfauWz/M+AbNp5QfBTWptddjVbA2xDlBctlsr5hIFwzO68kMf4MSTLF9I DF3ejV3UdbCo+p16hxIrId88TOPf2V6eCPwG7Cy9MYU4FsgA3NXm0xgOLSyRUri3ZR1N j+kvxPBgXuIoN4hL1/+77cgh0uOCMuHaFfYho= Received: by 10.236.80.71 with SMTP id j47mr272850yhe.497.1311798840139; Wed, 27 Jul 2011 13:34:00 -0700 (PDT) MIME-Version: 1.0 Sender: mark.j.handley@gmail.com Received: by 10.236.102.166 with HTTP; Wed, 27 Jul 2011 13:33:40 -0700 (PDT) In-Reply-To: <20110727184256.GA3690@shorty> References: <4DC6C56D.6040709@ieca.com> <20110727184256.GA3690@shorty> From: Mark Handley Date: Wed, 27 Jul 2011 16:33:40 -0400 X-Google-Sender-Auth: eyj1SEZ3TwMBiRM2a64fz5SUFq0 Message-ID: To: saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [saag] Fwd: fyi: tcpcrypt draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 20:34:02 -0000 Forwarding, because I don't think Andrea's on the saag list... ---------- Forwarded message ---------- From: Andrea Bittau Date: 27 July 2011 14:42 Subject: Re: [saag] fyi: tcpcrypt draft To: David McGrew Cc: saag@ietf.org, Sean Turner , tsv-area@ietf.org, tcpcrypt@scs.stanford.edu Sorry for the late reply! =A0Comments inline. On Tue, May 10, 2011 at 04:03:58PM -0700, David McGrew wrote: > Hello Tcpcrypt authors, > > I have skimmed the internet draft and the USENIX Security paper on > tcpcrypt, and while it is interesting and thought-provoking work, I > have a hard time understanding what the goals of the I-D are > relative to the TCP standard. =A0The draft says "Standards Track"; > would Experimental be more appropriate? =A0It mentions the following > objectives: We don't have a strong opinion about a standard's track vs. experimental categorization, so experimental is fine. =A0We'll be happy to reevaluate in the future. > "Tcpcrypt maintains the confidentiality of data transmitted in TCP > segments against a passive eavesdropper. =A0It can be used to protect > already established TCP connections against denial-of-service > attacks involving injection of forged RST segments or > desynchronizing of sequence numbers." =A0Yes, but TLS and IPsec > perform the former function, and IPsec and TCP-AO perform the > latter. =A0In addition, running TCP over DTLS would also accomplishes > the latter function; this practice is done in some (so-called) > SSLVPNs. Yes, tcpcrypt immediately offers confidentiality of data against a passive eavesdropper, which is better than the status quo, but this is not our ideal situation. =A0Our ideal situation is to provide strong secrecy and integrity protected by mutual authentication of the two endpoints. =A0The benefit of tcpcrypt is that it immediately provides this protection against passive eavesdroppers, while also making it as easy and efficient as possible to achieve the stronger security when applications can make use of appropriate authentication credentials. While IPSec is capable of providing opportunistic encryption, it does not do so "immediately". =A0In particular, plenty of machines run operating systems that support IPSec, yet do not use IPSec for security. Tcpcrypt, by contrast, is designed to be "on by default." It therefore has to require less configuration and provide better interoperability than IPSec with middleboxes such as NATs. =A0IPSec, because it is at the network layer, is also harder to integrate with application-level notions of authentication, which are typically tied to a particular TCP connection rather than a pair of machines. =A0(E.g., it is reasonable to run two different browsers on the same client, and use those two browsers to log into the same web site with two different accounts.) TLS is closer to tcpcrypt. =A0It could also be used for opportunistic encryption. =A0However, compared to tcpcrypt, TLS still requires more configuration, is not compatible with all TCP applications, and has a heavier impact on server performance. =A0All of these factors make it harder to enable TLS by default. =A0The combination of TLS and TCP-AO (the latter requiring setting up a pre-shared key between endpoints) would be harder still to make on by default. =A0Finally, the fact that TLS does not always provide forward secrecy is a disadvantage compared to tcpcrypt. Being a single, integrated, zero-configuration (once kernels support it) solution that can be incrementally deployed puts tcpcrypt at an advantage compared to other solutions that need to be used in tandem for more complete security, each coming with their own configuration requirements. > "Finally, applications that perform authentication can obtain > end-to-end confidentiality and integrity guarantees by tying > authentication to tcpcrypt Session ID values." =A0This seems like a > potentially useful feature, though it seems similar to channel > binding (RFCs 5056 and 5929). Yes it's the same concept and we implemented in tcpcrypt's core to allow briding to app-level authentication. =A0We also use the same mechanism to name sessions for session caching. > "Tcpcrypt is designed to require relatively low overhead, > particularly at servers, so as to be useful even in the case of > servers accepting many TCP connections per second." =A0The idea of > batching signatures seems like a useful contribution that could be > put to good use by servers that are under heavy loads. =A0But why not > implement this idea in a way that could be used by multiple > applications and protocols? =A0 It should not be hard to define a > format for digital signatures that carries a few extra hash values, > and allows a verifying party to check the signature on the message > that they care about, while ignoring the rest. =A0The idea of > reversing the client/server association between RSA > encryption/decryption is a pragmatic way to help out servers, though > it is tied to a specific algorithm (the results would be quite > different for ECDH or ECDSA, say). =A0Both of those performance > optimizations are definitely interesting, but I don't understand why > the best way utilize those ideas would be through a new > cryptographic protocol within the TCP layer. The optimization is independent of tcpcrypt. =A0In fact, tcpcrypt's standard doesn't mandate nor specify any authentication mechanisms - it's left to the application. =A0Batch signing is just an example of how one might authentication tcpcrypt sessions. =A0It can be done with other protocols if they permit it. Note that this optimization cannot be used in stock SSL because of SSL's design. =A0SSL requires the server to perform an (expensive) private key operation per client because each client sends over a unique encrypted pre-master secret which the server decrypts to prove its identity (i.e., that it knows the private key for the certificate it advertised to the client). =A0So to leverage batch signing we need to design protocols that allow for it, hence why we created tcpcrypt clean-slate. We do have a drop-in replacement for OpenSSL that attempts to use tcpcrypt+batch signing if able otherwise reverting to SSL. =A0This can be used by many existing SSL applications without modifying them but just replacing the system's SSL library. > I also have some comments on some other points. =A0The USENIX Security > paper mentions the goal of ubiquitous encryption (though the draft > does not). =A0Requiring changes to the TCP stack would hinder > deployment and work against the goal of ubiquity. The protocol is designed with incremental deployment in mind which hopefully will lead to ubiquitous encryption. =A0Specifically: * It tries tcpcrypt and falls back to TCP gracefully. =A0The app doesn't * have to know anything about tcpcrypt. Sure, modifying the TCP stack hinders deployment. =A0So would modifying all applications (which is potentially even more difficult). =A0We need to modify something to get encryption, and for the reasons just mentioned about incremental deployment we think TCP is the right place to do it. > The draft describes the RSA public keys as "ephemeral", and the > companion paper says that the protocol achieves forward secrecy. > However, if it was really the case that a new RSA keypair was > generated for each exchange, then the performance would be > significantly worse than what is shown in the paper, because the > cost of that operation is significantly higher than that of RSA > decryption. =A0 I think the claims and/or guidance to implementers > needs to be clarified. It's not perfect forward secrecy (i.e., one key per connection). =A0More like one key per 10 minute window or whatever the system is configured to. > The Security Considerations section looks like boilerplate, while it > seems that there is a lot to be discussed, such as the security > properties of Session IDs. Yes, we agree - this is just a first draft. =A0Well work on improving that. =A0If this is taken on by the IETF, no doubt things we haven't thought of will be pointed out. > Is it possible to relate the protocol to a previously analyzed > protocol? =A0 It is similar to ISO/IEC 11770-3, in that it relies on > public key encryption of nonces, without signatures. =A0Perhaps there > is some analysis of that protocol, or of a protocol with cryptosuite > negotiation, that could be leveraged. =A0The companion paper does have > a brief analysis of the security of the protocol, but it would be > good if it were possible to benefit from detailed analyses of all > aspects of protocol security. =A0(I do realize that the analysis is > made easier by the relative simplicity of the protocol; that's a > good thing.) We agree, and we'll work on this. > The security analysis defines the parameter "k ~ 256 is the minimum > of the min-entropy of a public key". =A0Surely that doesn't match the > 2048-bit RSA examples in the paper? The paper says: "where k ~ 256 is the minimum of the min-entropy of a public key, or the length in bits of NS or NC." NS and NC are random 256-bit values, so their min entropy is 256. =A0The public key is a product of two 1,024-bit primes, so its min entropy is much higher than 256. The min entropy is just the probability of running the key generation function twice and getting the same public key out the second time. This has nothing to do with the difficulty of breaking RSA (which for 2,048-bit keys would be sort of equivalent to a 112-bit symmetric key). The difficulty of breaking RSA is irrelevant to our reduction. =A0We are saying that if you can break tcpcrypt, we can break the public key algorithm or one of the other cryptographic functions in a "black box" way, without regard to what the algorithms actually are. > As a side note, I am surprised to see a proposal to add so much > cryptographic functionality into the TCP standard, considering that > not many years have passed since the transport area declined to add > (much simpler) key transport functionality into TCP in support of > TCP-AO. =A0Perhaps "Experimental" was intended, or perhaps I have > missed or misunderstood some aspect of this work. We think the perceived use case for TCP-AO was a replacement for TCP-MD5 in BGP sessions. =A0Of course TCP-AO is broader than that, but the perceived use case may have influenced the previous decision. From touch@isi.edu Wed Jul 27 15:00:26 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD3C25E8002; Wed, 27 Jul 2011 15:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[AWL=-1.950, BAYES_00=-2.599, MANGLED_MARKET=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXmVQb6QTQS2; Wed, 27 Jul 2011 15:00:26 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 5628C5E8001; Wed, 27 Jul 2011 15:00:26 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id p6RLxd24000317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 27 Jul 2011 14:59:39 -0700 (PDT) Message-ID: <4E308A4B.4090702@isi.edu> Date: Wed, 27 Jul 2011 14:59:39 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Mark Handley References: <4DC6C56D.6040709@ieca.com> <20110727184256.GA3690@shorty> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: saag@ietf.org, tsvwg Subject: Re: [saag] Fwd: fyi: tcpcrypt draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 22:00:26 -0000 Hi, Mark (et al.), I'm cc-ing this to the TSVWG mailing list for the benefit of those attending TSVAREA, where the presentation will occur tomorrow AM. Since this is the second IETF transport presentation (the first was in TCPM at IETF 80), I hope this presentation will clarify how the current tcpcrypt code uses the existing TCP option space. In specific, it appears to use *two* unassigned TCP option codepoints (69 and 70), rather than experimental codepoints (and, IMO, it should use the latter instead). I hope the presentation this time will address the plans to correct the currently deployed code to appropriately use the experimental codepoints. Joe From dharkins@lounge.org Thu Jul 28 06:16:31 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33A5F21F8C1F for ; Thu, 28 Jul 2011 06:16:31 -0700 (PDT) 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=[AWL=-0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bgUaC3OuSA1L for ; Thu, 28 Jul 2011 06:16:30 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id D22DD21F8C1E for ; Thu, 28 Jul 2011 06:16:30 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 80F5BA88810C for ; Thu, 28 Jul 2011 06:16:30 -0700 (PDT) Received: from 130.129.103.10 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 28 Jul 2011 06:16:30 -0700 (PDT) Message-ID: <93751ac83acf8ce4f175bec746d5d190.squirrel@www.trepanning.net> Date: Thu, 28 Jul 2011 06:16:30 -0700 (PDT) From: "Dan Harkins" To: "saag@ietf.org" 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 Subject: [saag] CICM BOF update X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 13:16:31 -0000 Hello, A BOF was held on Wednesday afternoon on a Common Interface to Cryptographic Modules (CICM). There were about 40 people in the room. There was a healthy amount of discussion and many constructive comments were received but there was no consensus on forming a WG. Proponents of the BOF will work to develop a more mature charter and incorporate comments received into their documents. This was the 1st CICM BOF and there will probably be another in a future IETF. regards, Dan (H) and Dan (L). From william.polk@nist.gov Thu Jul 28 06:44:47 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B16B821F8A96 for ; Thu, 28 Jul 2011 06:44:47 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDmLYgoqGjZo for ; Thu, 28 Jul 2011 06:44:47 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id C458B21F8828 for ; Thu, 28 Jul 2011 06:44:46 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.323.0; Thu, 28 Jul 2011 09:44:28 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Thu, 28 Jul 2011 09:44:13 -0400 From: "Polk, William T." To: "saag@ietf.org" Date: Thu, 28 Jul 2011 09:41:45 -0400 Thread-Topic: Request for public comments on NIST TDEA specification Thread-Index: AQHMTSxb07NZjuEMNECA71cwAalhsQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Subject: [saag] Request for public comments on NIST TDEA specification X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 13:44:47 -0000 NIST has another specification out for comment that may be of interest. This specification covers the Triple Data Encryption Algorithm (TDEA) [aka Triple DES]. Thanks, Tim Polk ________________________________________ From: Barker, Elaine B. Sent: Thursday, July 28, 2011 6:40 AM To: Caswell, Sara J.; Polk, William T. Subject: Request for public comments Could you please send the following to your mailing lists? Thanks. Elaine NIST requests comments on a revision of Special Publication (SP) 800-67, Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher. This revision includes an update of references appropriate for the publication, and an identification of requirements that are not tested by NIST's Cryptographic Algorithm Validation Program and Cryptographic Module Validation Program, but are required for secure use. The changes are highlighted in yellow for easy review. Please provide comments by August 31st, 2011 to ebarker@nist.gov, with "Comments on SP 800-67 (TDEA)" in the subject line. From barryleiba@gmail.com Thu Jul 28 09:08:42 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26A6811E808F for ; Thu, 28 Jul 2011 09:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.059 X-Spam-Level: X-Spam-Status: No, score=-103.059 tagged_above=-999 required=5 tests=[AWL=-0.082, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0E4QvBHSVIPb for ; Thu, 28 Jul 2011 09:08:41 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 94F4211E808D for ; Thu, 28 Jul 2011 09:08:41 -0700 (PDT) Received: by yie30 with SMTP id 30so2348438yie.31 for ; Thu, 28 Jul 2011 09:08:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=VF1W86jAopAbEEhgVwsGqkO4nlZqZ+bn0NHhfuKkj24=; b=L/h+uxs90dGYbU77MdNyDHR3R1sYqGRe17L7ZfLbljDWwqJCAkSLSVFsV5aYf5dgKC njWHB62y8mNshy1XpWskSnxi0Z6HPX/i/E/1mnm9HDLyBSqbopfvQLgUtg3dQ7MGdycY LK6YylleXFeEjKi6OX1qboimBBCf24wiNBR1g= MIME-Version: 1.0 Received: by 10.236.80.67 with SMTP id j43mr257424yhe.57.1311869321093; Thu, 28 Jul 2011 09:08:41 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.236.207.132 with HTTP; Thu, 28 Jul 2011 09:08:41 -0700 (PDT) Date: Thu, 28 Jul 2011 12:08:41 -0400 X-Google-Sender-Auth: nFIrd8wJyS9LqQ-Zt8T_HrqBjps Message-ID: From: Barry Leiba To: saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [saag] OAuth summary for IETF 81 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 16:08:42 -0000 The OAuth base protocol and the bearer token documents began working-group last call as of the Wednesday morning session, ending on 12 August. The SAML document has been split into a general "assertions" document and SAML-specific items; the former seems ready, and the latter now has to be trimmed. That's due on 12 August. The threat-model document needs one more revision before working-group last call. We discussed a recent liaison statement from OMA that asks the OAuth WG for a response. The chairs will draft a response, and have already received input for that. Phil Hunt presented a summary of an issue on "sidejacking" the OAuth exchange, if it's not properly secured (TLS in every part). The current version of the base protocol draft has tightened the language acceptably. Thomas Hardjono gave a presentation on UMA, with a plan to ask the WG to consider this when we recharter (currently planned around October or so). -- Barry, OAuth chair From aland@deployingradius.com Thu Jul 28 09:11:16 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B646311E8074 for ; Thu, 28 Jul 2011 09:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5jnMy3K4QaAL for ; Thu, 28 Jul 2011 09:11:16 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7D521F8B0C for ; Thu, 28 Jul 2011 09:11:16 -0700 (PDT) Received: from dhcp-12d2.meeting.ietf.org (dhcp-12d2.meeting.ietf.org [130.129.18.210]) by liberty.deployingradius.com (Postfix) with ESMTPSA id A9C4812340D7 for ; Thu, 28 Jul 2011 18:11:02 +0200 (CEST) Message-ID: <4E318A15.7080008@deployingradius.com> Date: Thu, 28 Jul 2011 12:11:01 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "saag@ietf.org" X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [saag] Report from EMU X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 16:11:16 -0000 We had a discussion on the channel bindings document. There are some small updates pending, but the document has WG consensus, and should be in WG last call soon. The new EAP tunneled method was discussed. There was no consensus on the name of the method. The document authors were tasked with choosing a name. Dan Harkins proposed some requirements for anonymous cipher suites, followed by strong authentication. The consensus of the WG was to update the text of the tunneled method document to allow this. Alan DeKok. From sethomso@cisco.com Thu Jul 28 09:23:12 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC61121F8C09 for ; Thu, 28 Jul 2011 09:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ow1P0ra-Lt6l for ; Thu, 28 Jul 2011 09:23:11 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id DD6E021F8C08 for ; Thu, 28 Jul 2011 09:23:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sethomso@cisco.com; l=971; q=dns/txt; s=iport; t=1311870191; x=1313079791; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=nzfB64pSAgFpWCgixGmizgxDUFyc3pxhDS0yjyRuerc=; b=UnsL2x6PBjEqXfgTHU5G972GoDZsSwFIbTn8+t7ys97dEXS6+YCcir3P 3aQVj76PS0KS3FdJJ/zSqaUltTD0T2H+CZCvfRx/TfGVKm5gh5rVKmEia cjTZjJsxwZxqQzUdE8FcSH8F+fkbDrBBs9xb0X8V9Lwsr7o9yriJCnhvu 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AusIAPKLMU6tJXHA/2dsb2JhbAA2AQEDFAEhCjMHHgErBiQHE1IBBSMbmC6PC3erXIEjnliFYl8Eh1mQMIty X-IronPort-AV: E=Sophos;i="4.67,283,1309737600"; d="scan'208";a="7439532" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 28 Jul 2011 16:23:10 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p6SGNAqP026411 for ; Thu, 28 Jul 2011 16:23:10 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Jul 2011 11:23:09 -0500 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, 28 Jul 2011 11:23:13 -0500 Message-ID: <6065F7697E427240893C1B5CF4182896727658@XMB-RCD-111.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NEA meeting summary for IETF81 Thread-Index: AcxNQqW9IRrq1IWHSJuZs75GbMXdVg== From: "Susan Thomson (sethomso)" To: X-OriginalArrivalTime: 28 Jul 2011 16:23:09.0991 (UTC) FILETIME=[A3E70B70:01CC4D42] Subject: [saag] NEA meeting summary for IETF81 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 16:23:12 -0000 The NEA meeting reviewed two protocols for posture transport: TLS-based transport and EAP-based transport. The TLS-based transport is a WG document, which will be updated based on comments received, and then move to WG Last Call prior to the next IETF. There are 2 individual submissions for the EAP-Based transport, one based on an EAP method carried within a tunnel EAP method, and one based on a TLV carried within a tunnel EAP method. The architectural differences between these proposals were summarized at the meeting. Based on a consensus check taken at this meeting, there is no WG consensus as to which one which to choose. The next steps are to perform the same consensus check on the mailing list. If there still is no consensus, the AD and WG chairs have agreed that the AD will make a decision. The working group has been informed of this resolution plan by email and at the F2F meeting and no objections have been received. Thanks Susan From mark.j.handley@gmail.com Thu Jul 28 10:16:09 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 587F511E80D0; Thu, 28 Jul 2011 10:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Utx5QxOqH4VP; Thu, 28 Jul 2011 10:16:08 -0700 (PDT) Received: from mail-gw0-f43.google.com (mail-gw0-f43.google.com [74.125.83.43]) by ietfa.amsl.com (Postfix) with ESMTP id B92B811E8078; Thu, 28 Jul 2011 10:16:08 -0700 (PDT) Received: by gwm11 with SMTP id 11so3434453gwm.16 for ; Thu, 28 Jul 2011 10:16:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=jqav7fPVens+K7dQ+SrYaw+6JvZOfaq7cDgSUPF8WDw=; b=dyup/B6pIlr7Lq3lWDmMh0EBD2yeSe8hUK/hC5p11l2HoTIIwjB3fAiPo35c5unHdE a0NAehAeBuHGkj7ebcJHHyFZjwsCDjAOZZEGbJ4Fc9aDBin4K3NB9s1shVcMV4KC4GQV yUiMq/dwaxkFB/2u6iyzEyxtDQQoUaz3EtFbE= Received: by 10.236.115.230 with SMTP id e66mr334317yhh.28.1311873368258; Thu, 28 Jul 2011 10:16:08 -0700 (PDT) MIME-Version: 1.0 Sender: mark.j.handley@gmail.com Received: by 10.236.102.166 with HTTP; Thu, 28 Jul 2011 10:15:48 -0700 (PDT) In-Reply-To: <4E308A4B.4090702@isi.edu> References: <4DC6C56D.6040709@ieca.com> <20110727184256.GA3690@shorty> <4E308A4B.4090702@isi.edu> From: Mark Handley Date: Thu, 28 Jul 2011 13:15:48 -0400 X-Google-Sender-Auth: o57SNIWC6PTa_G54AutTByJkM8Q Message-ID: To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Cc: tcpcrypt@scs.stanford.edu, saag@ietf.org, tsvwg Subject: Re: [saag] Fwd: fyi: tcpcrypt draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 17:16:09 -0000 On 27 July 2011 17:59, Joe Touch wrote: > Since this is the second IETF transport presentation (the first was in TCPM > at IETF 80), I hope this presentation will clarify how the current tcpcrypt > code uses the existing TCP option space. > > In specific, it appears to use *two* unassigned TCP option codepoints (69 > and 70), rather than experimental codepoints (and, IMO, it should use the > latter instead). Hi Joe, You're correct that our code is currently using two unassigned codepoints, and we should not be doing so. I've looked into what we should do, and the problem is that there are deployed products using the two experimental options. We don't wish them to interfere with our experiments, nor do we wish to interfere with their experiments. But using unassigned ports is bad too. I've talked with Wes and David, and we're working on figuring out the least bad solution. Wes will raise the issue with the IESG, and we'll implement whatever they decide is best. - Mark From hannes.tschofenig@gmx.net Thu Jul 28 10:35:28 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE26A21F88A5 for ; Thu, 28 Jul 2011 10:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTzCVlnZ6Qiz for ; Thu, 28 Jul 2011 10:35:27 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id B55B521F8C30 for ; Thu, 28 Jul 2011 10:35:26 -0700 (PDT) Received: (qmail invoked by alias); 28 Jul 2011 17:35:24 -0000 Received: from dhcp-172b.meeting.ietf.org (EHLO dhcp-172b.meeting.ietf.org) [130.129.23.43] by mail.gmx.net (mp069) with SMTP; 28 Jul 2011 19:35:24 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19ykBFWa1RydMCySE/CCOSB5pPBde+1Gr5N4uuYsi j7w4K0voDoopsl Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <4DC6C56D.6040709@ieca.com> Date: Thu, 28 Jul 2011 13:35:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <63DF7987-31B9-47CA-89FC-9DF7856C0C7D@gmx.net> References: <4DC6C56D.6040709@ieca.com> To: Sean Turner , Mark Handley X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: saag@ietf.org Subject: Re: [saag] fyi: tcpcrypt draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 17:35:28 -0000 I was not able to be at today's meeting. So, apologies if my question = has been discussed during the meeting already.=20 It is definitely a desirable goal to have more end-to-end security being = used.=20 There are obviously lots of details questions on how to get there, both = from the technical side but also from the incentive side.=20 Various mechanisms exist already today offering e2e security but what I = do not get is how this mechanism will get us to the desired state.=20 How is this mechanism going to help with companies who do not want to = deploy TLS beyond their initial authentication step?=20 For many of them it would be super-easy to just apply the already = established TLS session up and protect further message exchange as well.=20= Ciao Hannes On May 8, 2011, at 12:31 PM, Sean Turner wrote: > The authors of the following draft have asked that I forward this to = saag for comment: >=20 > https://datatracker.ietf.org/doc/draft-bittau-tcp-crypt/ >=20 > They also noted that there's a Usenix Security paper and video: > http://tcpcrypt.org/docs.php >=20 > Please direct discussion to tsv-area@ietf.org. >=20 > Cheers, >=20 > spt >=20 >=20 >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From marshall.eubanks@gmail.com Thu Jul 28 10:53:56 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 666DC11E80C9 for ; Thu, 28 Jul 2011 10:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.417 X-Spam-Level: X-Spam-Status: No, score=-103.417 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I03hMgsCxwn8 for ; Thu, 28 Jul 2011 10:53:55 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 67CA211E8083 for ; Thu, 28 Jul 2011 10:53:55 -0700 (PDT) Received: by yie30 with SMTP id 30so2445493yie.31 for ; Thu, 28 Jul 2011 10:53:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=srl7vwJOWMyAR03fYtzRlV2BtpKDuRpzC2jpLuzFZzU=; b=gvTUmc0vE/O6LkDKMjtnZZxPo+zBervCP8cPBLoVZsNk316TMO1WGb+TToZ1dXJO8c UFh83mj/zus0F7mOYkDPhmNZuUYrfJz/945ZyHwZ7Am0BplRx7n1NUigLDXwWvEjrPBk 5bqbg00GXuqLvqHTRVFuNbaLRJKs0Uk1d5h+U= MIME-Version: 1.0 Received: by 10.150.48.28 with SMTP id v28mr475824ybv.38.1311875633915; Thu, 28 Jul 2011 10:53:53 -0700 (PDT) Received: by 10.151.12.20 with HTTP; Thu, 28 Jul 2011 10:53:53 -0700 (PDT) Date: Thu, 28 Jul 2011 13:53:53 -0400 Message-ID: From: Marshall Eubanks To: saag@ietf.org Content-Type: multipart/alternative; boundary=000e0cd7055e26295804a924d932 Subject: [saag] NIST Hash Forum X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 17:53:56 -0000 --000e0cd7055e26295804a924d932 Content-Type: text/plain; charset=ISO-8859-1 http://csrc.nist.gov/groups/ST/hash/email_list.html --000e0cd7055e26295804a924d932 Content-Type: text/html; charset=ISO-8859-1 http://csrc.nist.gov/groups/ST/hash/email_list.html --000e0cd7055e26295804a924d932-- From william.polk@nist.gov Thu Jul 28 11:02:44 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAB5121F8B6B for ; Thu, 28 Jul 2011 11:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, SUBJECT_FUZZY_TION=0.156] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-RxZKM5Drhm for ; Thu, 28 Jul 2011 11:02:43 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id B059821F8B46 for ; Thu, 28 Jul 2011 11:02:43 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.323.0; Thu, 28 Jul 2011 14:02:04 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Thu, 28 Jul 2011 14:02:18 -0400 From: "Polk, William T." To: Marshall Eubanks , "saag@ietf.org" Date: Thu, 28 Jul 2011 13:57:33 -0400 Thread-Topic: URLs for NIST hash competition info (was RE: [saag] NIST Hash Forum) Thread-Index: AQHMTVBr+iOJ3MzqsEaEL/yZgCTdQA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [saag] URLs for NIST hash competition info (was RE: NIST Hash Forum) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 18:02:44 -0000 VGhhbmtzIE1hcnNoYWxsIQ0KDQpIZXJlIGFyZSBhIGZldyBVUkxzIHRoYXQgbWlnaHQgYWxzbyBi ZSBvZiBpbnRlcmVzdC4uLg0KDQpOSVNUIEhhc2ggY29tcGV0aXRpb24gcGFnZTog4oCoaHR0cDov L3d3dy5uaXN0Lmdvdi9oYXNoLWNvbXBldGl0aW9uDQplQkFTSCBiZW5jaG1hcmtpbmcgb2YgaGFz aCBmdW5jdGlvbnM6IGh0dHA6Ly9iZW5jaC5jci55cC50by9lYmFzaC5odG1sDQpFQ1JZUFQgSUkg 4oCTIFRoZSBTSEEtMyBab286IGh0dHA6Ly9laGFzaC5pYWlrLnR1Z3Jhei5hdC93aWtpL1RoZV9T SEEtM19ab28NCkNsYXNzaWZpY2F0aW9uIG9mIHRoZSBTSEEtMyBDYW5kaWRhdGVzOuKAqGh0dHA6 Ly9lcHJpbnQuaWFjci5vcmcvMjAwOC81MTEucGRmDQpBVEhFTmEgLSBBdXRvbWF0ZWQgVG9vbCBm b3IgSGFyZHdhcmUgRXZhbHVhdGlvTjogaHR0cDovL2NyeXB0b2dyYXBoeS5nbXUuZWR1L2F0aGVu YS8gDQoNCg0KVGltDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpG cm9tOiBzYWFnLWJvdW5jZXNAaWV0Zi5vcmcgW3NhYWctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIE1hcnNoYWxsIEV1YmFua3MgW21hcnNoYWxsLmV1YmFua3NAZ21haWwuY29tXQ0KU2Vu dDogVGh1cnNkYXksIEp1bHkgMjgsIDIwMTEgMTo1MyBQTQ0KVG86IHNhYWdAaWV0Zi5vcmcNClN1 YmplY3Q6IFtzYWFnXSBOSVNUIEhhc2ggRm9ydW0NCg0KaHR0cDovL2NzcmMubmlzdC5nb3YvZ3Jv dXBzL1NUL2hhc2gvZW1haWxfbGlzdC5odG1sDQo= From touch@isi.edu Thu Jul 28 11:05:18 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB0A811E80E9; Thu, 28 Jul 2011 11:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.356 X-Spam-Level: X-Spam-Status: No, score=-105.356 tagged_above=-999 required=5 tests=[AWL=1.243, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDYOteDPPCuk; Thu, 28 Jul 2011 11:05:18 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 4181911E807B; Thu, 28 Jul 2011 11:05:18 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p6SI4dR6017376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 28 Jul 2011 11:04:39 -0700 (PDT) Message-ID: <4E31A4B7.6010900@isi.edu> Date: Thu, 28 Jul 2011 11:04:39 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Mark Handley References: <4DC6C56D.6040709@ieca.com> <20110727184256.GA3690@shorty> <4E308A4B.4090702@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpcrypt@scs.stanford.edu, saag@ietf.org, tsvwg Subject: Re: [saag] Fwd: fyi: tcpcrypt draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 18:05:18 -0000 On 7/28/2011 10:15 AM, Mark Handley wrote: > On 27 July 2011 17:59, Joe Touch wrote: >> Since this is the second IETF transport presentation (the first was in TCPM >> at IETF 80), I hope this presentation will clarify how the current tcpcrypt >> code uses the existing TCP option space. >> >> In specific, it appears to use *two* unassigned TCP option codepoints (69 >> and 70), rather than experimental codepoints (and, IMO, it should use the >> latter instead). > > Hi Joe, > > You're correct that our code is currently using two unassigned > codepoints, and we should not be doing so. I've looked into what we > should do, and the problem is that there are deployed products using > the two experimental options. We don't wish them to interfere with > our experiments, nor do we wish to interfere with their experiments. Hi, Mark, It's hard to understand how these could interfere, since experiments are not supposed to be widely deployed. The only interference would be if theirs were widely deployed *and* yours were too, which means you're both using those codepoints inappropriately. > But using unassigned ports is bad too. I've talked with Wes and > David, and we're working on figuring out the least bad solution. Wes > will raise the issue with the IESG, and we'll implement whatever they > decide is best. AOK. It'd be useful to note this in your talk, IMO. Thanks, Joe From mark.j.handley@gmail.com Thu Jul 28 11:18:30 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0F911E80F0 for ; Thu, 28 Jul 2011 11:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWTqEzIWvc5U for ; Thu, 28 Jul 2011 11:18:29 -0700 (PDT) Received: from mail-gw0-f43.google.com (mail-gw0-f43.google.com [74.125.83.43]) by ietfa.amsl.com (Postfix) with ESMTP id 895F211E80D7 for ; Thu, 28 Jul 2011 11:18:29 -0700 (PDT) Received: by gwm11 with SMTP id 11so3528607gwm.16 for ; Thu, 28 Jul 2011 11:18:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=7cnZzhPFVv0XxTbERGClkDUgqN6mZa2RwR4b9E4HhJw=; b=LNtCfw5QKmXa4OdyTg8sAViJQP4oZz9rgAxhkWgZwSpXnmJaXDSegghqP1QVOXEWda 1NEKfFcCTd9HM21gCrQFlbpQ/OPOh5YIkCDEceDPCzUlFTFgSMY4PruRp8oGTFPZzLW0 HctgiNQaCewfZTt5asMQysxdFp8P0sCu/SWB0= Received: by 10.236.115.230 with SMTP id e66mr411754yhh.28.1311877109099; Thu, 28 Jul 2011 11:18:29 -0700 (PDT) MIME-Version: 1.0 Sender: mark.j.handley@gmail.com Received: by 10.236.102.166 with HTTP; Thu, 28 Jul 2011 11:18:09 -0700 (PDT) In-Reply-To: <63DF7987-31B9-47CA-89FC-9DF7856C0C7D@gmx.net> References: <4DC6C56D.6040709@ieca.com> <63DF7987-31B9-47CA-89FC-9DF7856C0C7D@gmx.net> From: Mark Handley Date: Thu, 28 Jul 2011 14:18:09 -0400 X-Google-Sender-Auth: pPGRSVRVJ9RERBa1t0ieWjPCtfQ Message-ID: To: Hannes Tschofenig Content-Type: text/plain; charset=ISO-8859-1 Cc: saag@ietf.org Subject: Re: [saag] fyi: tcpcrypt draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 18:18:30 -0000 On 28 July 2011 13:35, Hannes Tschofenig wrote: > How is this mechanism going to help with companies who do not want to deploy TLS beyond their initial authentication step? > For many of them it would be super-easy to just apply the already established TLS session up and protect further message exchange as well. Hi Hannes, Can I just clarify what you're asking? Are you referring to companies that use TLS to secure the initial login to their site, and after that do unencrypted TCP? The other tcpcrypt folks may want to chime in, as they're better qualified than I am, but from my point of view, I don't view tcpcrypt as being a replacement to TLS in this scenario. It might go something like this: 1. Both client and server deploy an SSL library like our one that also supports tcpcrypt. WIthout changes to the apps, the SSL library probes using the getsockopt(SESSION_ID) to see if tcpcrypt enabled itself and whether the remote end signalled tcpcrypt-based auth support. * If so, the server signs the session ID and sends it to the client. Batch signing can speed this up if necessary. The channel now provides TLS-equivalent security, except that the connection is also protected against RST and other TCP desynchronization attacks. * If not, tcpcrypt is not enabled, and the SSL library does regular SSL, exactly as it does right now. 2. After the initial login, with tcpcrypt-enabled clients, the TCP connections are encrypted and protected against passive eavesdropping and blind RST or data insertion attacks. If these sessions are to the same server, they'll use cached keying material, so be faster. Also the client knows the server is tcpcrypt-capable, it could optionally could insist tcpcrypt succeeds for these, which might protect against more than passive attacks. With non-tcpcrypt-enabled clients, the TCP sessions are in the clear, as they are now. Depending on the application, different auth can be used for TCP sessions after the original one, even if they're to a different one of the company's servers. For example, if tcpcrypt was used for the initial session, the tcpcrypt-auth library can pass a session cookie on the initial session, and then use that for cheap CMAC-based authentication. Of course there's nothing to stop the company using SSL for these, but as they don't, presumably they have a performance concern? Would be good to know what their concern really is. But I'm not sure this was your question. Anyway, the main thing I took away from today's meeting is that we really need to write a usage cases document, to make it clear how we envisage tcpcrypt might be used. - Mark From touch@isi.edu Thu Jul 28 11:52:54 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92CFC11E80E0; Thu, 28 Jul 2011 11:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.389 X-Spam-Level: X-Spam-Status: No, score=-103.389 tagged_above=-999 required=5 tests=[AWL=-0.790, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8bNmGx-Zuyu; Thu, 28 Jul 2011 11:52:54 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 3F17A5E801D; Thu, 28 Jul 2011 11:52:50 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id p6SIqJxL026804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 28 Jul 2011 11:52:19 -0700 (PDT) Message-ID: <4E31AFE3.8090706@isi.edu> Date: Thu, 28 Jul 2011 11:52:19 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" References: <4DC6C56D.6040709@ieca.com><20110727184256.GA3690@shorty><4E308A4B.4090702@isi.edu> <4E31A4B7.6010900@isi.edu> <0C53DCFB700D144284A584F54711EC580D482D56@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC580D482D56@xmb-sjc-21c.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpcrypt@scs.stanford.edu, saag@ietf.org, tsvwg Subject: Re: [saag] Fwd: fyi: tcpcrypt draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 18:52:54 -0000 Hi, Anantha, On 7/28/2011 11:41 AM, Anantha Ramaiah (ananth) wrote: > Is there any consideration to allocate more code points for TCP > experimental usage? With the increasing number of experimental TCP > drafts (some of which uses TCP options), it would be useful thing to > extend the experimental TCP option space. Wondering whether this has > been brought up before? It has. In principle, the entire space can be used of the code is *ensured* to never leave the lab; these codepoints were assigned for safety. IMO, nobody should EVER use an experimental codepoint without including a nonce that can be used to identify their use of that codepoint; that would prevent interference if (when) accidental deployment occurs. Systems that intend to be widely deployed should get assigned codepoints, period. I personally think that posting code on a website for public use that includes experimental codepoints MUST NOT be tolerated (yes, that means that tcpcrypt code *needs* be taken down until this is resolved). Joe >> -----Original Message----- >> From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf >> Of Joe Touch >> Sent: Thursday, July 28, 2011 11:05 AM >> To: Mark Handley >> Cc: tcpcrypt@scs.stanford.edu; saag@ietf.org; tsvwg >> Subject: Re: [saag] Fwd: fyi: tcpcrypt draft >> >> >> >> On 7/28/2011 10:15 AM, Mark Handley wrote: >>> On 27 July 2011 17:59, Joe Touch wrote: >>>> Since this is the second IETF transport presentation (the first was >> in TCPM >>>> at IETF 80), I hope this presentation will clarify how the current >> tcpcrypt >>>> code uses the existing TCP option space. >>>> >>>> In specific, it appears to use *two* unassigned TCP option >> codepoints (69 >>>> and 70), rather than experimental codepoints (and, IMO, it should >> use the >>>> latter instead). >>> >>> Hi Joe, >>> >>> You're correct that our code is currently using two unassigned >>> codepoints, and we should not be doing so. I've looked into what we >>> should do, and the problem is that there are deployed products using >>> the two experimental options. We don't wish them to interfere with >>> our experiments, nor do we wish to interfere with their experiments. >> >> Hi, Mark, >> >> It's hard to understand how these could interfere, since experiments >> are >> not supposed to be widely deployed. The only interference would be if >> theirs were widely deployed *and* yours were too, which means you're >> both using those codepoints inappropriately. >> >>> But using unassigned ports is bad too. I've talked with Wes and >>> David, and we're working on figuring out the least bad solution. > Wes >>> will raise the issue with the IESG, and we'll implement whatever > they >>> decide is best. >> >> AOK. It'd be useful to note this in your talk, IMO. >> >> Thanks, >> >> Joe From pgut001@login01.cs.auckland.ac.nz Thu Jul 28 22:52:08 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66E495E8005 for ; Thu, 28 Jul 2011 22:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.618 X-Spam-Level: X-Spam-Status: No, score=-3.618 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IBnVHjWsJe-R for ; Thu, 28 Jul 2011 22:52:06 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 7B81F5E8004 for ; Thu, 28 Jul 2011 22:52:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1311918727; x=1343454727; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20M.Handley@cs.ucl.ac.uk,=20mcgrew@cisco.com |Subject:=20Re:=20[saag]=20fyi:=20tcpcrypt=20draft|Cc:=20 saag@ietf.org|In-Reply-To:=20|Message-Id:=20|Date:=20Fri,=2029=20Jul=202011 =2017:51:58=20+1200; bh=0C/8sPePuQ0ntjGhC3QcB7i6lEi0ZPJdmEkvYSNHnR0=; b=Pp/TgY+KofUXNIW6MLTJ0r4wMhLCgHzLFdfa4xDS2oIn4AOjsg7PCEHq 4X0+gFO0Dj5Z4THnC4HghRjvEXp+H3q2Y4orfNomJut8JyBvsCUzJ/szl sAPs4obC7h++pPZAtiA1QL1hW8d1QhTPK1pTWc4te+6AJKNHEaSGLlroi A=; X-IronPort-AV: E=Sophos;i="4.67,286,1309694400"; d="scan'208";a="74800045" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 29 Jul 2011 17:51:58 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QmfzK-0007Xd-H0; Fri, 29 Jul 2011 17:51:58 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QmfzK-0005ka-7J; Fri, 29 Jul 2011 17:51:58 +1200 From: Peter Gutmann To: M.Handley@cs.ucl.ac.uk, mcgrew@cisco.com In-Reply-To: Message-Id: Date: Fri, 29 Jul 2011 17:51:58 +1200 Cc: saag@ietf.org Subject: Re: [saag] fyi: tcpcrypt draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 05:52:08 -0000 Mark Handley writes: > - We conducted a pretty extensive study into whether extending TCP in > this way would be deployable, or whether we've missed something, and > we've done more testing. The draft paper is here: > > http://nrg.cs.ucl.ac.uk/mjh/tmp/mboxes.pdf This is a really interesting paper that affects a rather large number of other things (the whole end-to-end argument, IPv6 deployment, network neutrality, and so on), any chance of making this publicly available for others to read? The 'tmp' in the path implies that it's not for public consumption... Peter. From turners@ieca.com Fri Jul 29 05:11:12 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3299021F87BC for ; Fri, 29 Jul 2011 05:11:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.181 X-Spam-Level: X-Spam-Status: No, score=-102.181 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZLkfkvChlPA for ; Fri, 29 Jul 2011 05:11:11 -0700 (PDT) Received: from nm19-vm0.access.bullet.mail.mud.yahoo.com (nm19-vm0.access.bullet.mail.mud.yahoo.com [66.94.236.25]) by ietfa.amsl.com (Postfix) with SMTP id A50CC21F8777 for ; Fri, 29 Jul 2011 05:11:11 -0700 (PDT) Received: from [66.94.237.198] by nm19.access.bullet.mail.mud.yahoo.com with NNFMP; 29 Jul 2011 12:11:06 -0000 Received: from [98.139.221.63] by tm9.access.bullet.mail.mud.yahoo.com with NNFMP; 29 Jul 2011 12:11:06 -0000 Received: from [127.0.0.1] by smtp104.biz.mail.bf1.yahoo.com with NNFMP; 29 Jul 2011 12:11:06 -0000 X-Yahoo-Newman-Id: 304560.28245.bm@smtp104.biz.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: ciqEL7AVM1kJdWxcpJygqwTjMUhv.XTWv5cEM8GtqTogsUu KaSlTR.Tjm08G7EwYY4Rqm6ejwscpCKsPnsTgas4nlgujedjNASvxo9NoWwK _y5TA.bealqyZgdPIjw0QvAVR0sggdTGpRwR7INpuuO2R04UKtLp4ozoIRMn BAmZTfgHcu8XAmQ1q5O6oWcv7HdE.oP8FbeVgvFotIA2.Yptogaf.TYjZjo4 I5GhYm5qBWCZ4Cl.EobdB.hftlAZcJZb_UNZbBt.14K8h2H.UmLuofCC4V5R CdxWAdY9DtChPzxF9ckzAM.jhhOnxj9c0lPzUtzwIglcpdl6mDe_Q8VB.hwe 4nyP12RU22x7OUMRG.BLrsCMk0tOaqjTpAbARA.64Q2hPCW6ByLLQ14rvMAp aR4GFZhxLHYSEMkTrpc.7lSqhSXmGNmVZebje6P.BNFMN1S13.9rggPcd1g- - X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ Received: from thunderfish.local (turners@130.129.21.152 with plain) by smtp104.biz.mail.bf1.yahoo.com with SMTP; 29 Jul 2011 05:11:06 -0700 PDT Message-ID: <4E32A359.2040400@ieca.com> Date: Fri, 29 Jul 2011 08:11:05 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [saag] IETF 81 SAAG minutes X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 12:11:12 -0000 Minutes have been uploaded: http://www.ietf.org/proceedings/81/minutes/saag.txt spt From bittau@gmail.com Wed Jul 27 11:44:31 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9486B11E8143; Wed, 27 Jul 2011 11:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wcTEgjSeKmbt; Wed, 27 Jul 2011 11:44:30 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5715611E813F; Wed, 27 Jul 2011 11:44:30 -0700 (PDT) Received: by gwb20 with SMTP id 20so1543665gwb.31 for ; Wed, 27 Jul 2011 11:44:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-echelon:user-agent; bh=HDs6k0Bpd0mqByBrGrQ5vH1S5Q1d0svGWm/yyEKUeyU=; b=J6fNgk2Xg74GnrbRLZ+4hOmf0BXGsEhFYQNeyjIvzM40I4S+6RhA9a8+wEz5n6YbC6 BDYnF+GHFZ3x8KVP9Du1BuppB2Dh3hAYYEa0sOe2iI7jvlhWaI2fucI7/YNYor2k9PKp 8Tif4WvCajJJqL8mJ6RVjvWqqyNAyQ6N/ucyA= Received: by 10.142.248.34 with SMTP id v34mr92493wfh.107.1311792269305; Wed, 27 Jul 2011 11:44:29 -0700 (PDT) Received: from tapir.cs.ucl.ac.uk (sorbo.scs.stanford.edu [171.66.3.100]) by mx.google.com with ESMTPS id k3sm136397pbj.29.2011.07.27.11.44.27 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Jul 2011 11:44:27 -0700 (PDT) Sender: Andrea Bittau Received: by tapir.cs.ucl.ac.uk (Postfix, from userid 0) id D0B1E4810172; Wed, 27 Jul 2011 11:42:58 -0700 (PDT) Date: Wed, 27 Jul 2011 11:42:57 -0700 From: Andrea Bittau To: David McGrew Message-ID: <20110727184256.GA3690@shorty> References: <4DC6C56D.6040709@ieca.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Echelon: Bush Bomb War KGB User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Fri, 29 Jul 2011 08:01:00 -0700 Cc: tcpcrypt@scs.stanford.edu, tsv-area@ietf.org, saag@ietf.org Subject: Re: [saag] fyi: tcpcrypt draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 18:48:54 -0000 Sorry for the late reply! Comments inline. On Tue, May 10, 2011 at 04:03:58PM -0700, David McGrew wrote: > Hello Tcpcrypt authors, > > I have skimmed the internet draft and the USENIX Security paper on > tcpcrypt, and while it is interesting and thought-provoking work, I > have a hard time understanding what the goals of the I-D are > relative to the TCP standard. The draft says "Standards Track"; > would Experimental be more appropriate? It mentions the following > objectives: We don't have a strong opinion about a standard's track vs. experimental categorization, so experimental is fine. We'll be happy to reevaluate in the future. > "Tcpcrypt maintains the confidentiality of data transmitted in TCP > segments against a passive eavesdropper. It can be used to protect > already established TCP connections against denial-of-service > attacks involving injection of forged RST segments or > desynchronizing of sequence numbers." Yes, but TLS and IPsec > perform the former function, and IPsec and TCP-AO perform the > latter. In addition, running TCP over DTLS would also accomplishes > the latter function; this practice is done in some (so-called) > SSLVPNs. Yes, tcpcrypt immediately offers confidentiality of data against a passive eavesdropper, which is better than the status quo, but this is not our ideal situation. Our ideal situation is to provide strong secrecy and integrity protected by mutual authentication of the two endpoints. The benefit of tcpcrypt is that it immediately provides this protection against passive eavesdroppers, while also making it as easy and efficient as possible to achieve the stronger security when applications can make use of appropriate authentication credentials. While IPSec is capable of providing opportunistic encryption, it does not do so "immediately". In particular, plenty of machines run operating systems that support IPSec, yet do not use IPSec for security. Tcpcrypt, by contrast, is designed to be "on by default." It therefore has to require less configuration and provide better interoperability than IPSec with middleboxes such as NATs. IPSec, because it is at the network layer, is also harder to integrate with application-level notions of authentication, which are typically tied to a particular TCP connection rather than a pair of machines. (E.g., it is reasonable to run two different browsers on the same client, and use those two browsers to log into the same web site with two different accounts.) TLS is closer to tcpcrypt. It could also be used for opportunistic encryption. However, compared to tcpcrypt, TLS still requires more configuration, is not compatible with all TCP applications, and has a heavier impact on server performance. All of these factors make it harder to enable TLS by default. The combination of TLS and TCP-AO (the latter requiring setting up a pre-shared key between endpoints) would be harder still to make on by default. Finally, the fact that TLS does not always provide forward secrecy is a disadvantage compared to tcpcrypt. Being a single, integrated, zero-configuration (once kernels support it) solution that can be incrementally deployed puts tcpcrypt at an advantage compared to other solutions that need to be used in tandem for more complete security, each coming with their own configuration requirements. > "Finally, applications that perform authentication can obtain > end-to-end confidentiality and integrity guarantees by tying > authentication to tcpcrypt Session ID values." This seems like a > potentially useful feature, though it seems similar to channel > binding (RFCs 5056 and 5929). Yes it's the same concept and we implemented in tcpcrypt's core to allow briding to app-level authentication. We also use the same mechanism to name sessions for session caching. > "Tcpcrypt is designed to require relatively low overhead, > particularly at servers, so as to be useful even in the case of > servers accepting many TCP connections per second." The idea of > batching signatures seems like a useful contribution that could be > put to good use by servers that are under heavy loads. But why not > implement this idea in a way that could be used by multiple > applications and protocols? It should not be hard to define a > format for digital signatures that carries a few extra hash values, > and allows a verifying party to check the signature on the message > that they care about, while ignoring the rest. The idea of > reversing the client/server association between RSA > encryption/decryption is a pragmatic way to help out servers, though > it is tied to a specific algorithm (the results would be quite > different for ECDH or ECDSA, say). Both of those performance > optimizations are definitely interesting, but I don't understand why > the best way utilize those ideas would be through a new > cryptographic protocol within the TCP layer. The optimization is independent of tcpcrypt. In fact, tcpcrypt's standard doesn't mandate nor specify any authentication mechanisms - it's left to the application. Batch signing is just an example of how one might authentication tcpcrypt sessions. It can be done with other protocols if they permit it. Note that this optimization cannot be used in stock SSL because of SSL's design. SSL requires the server to perform an (expensive) private key operation per client because each client sends over a unique encrypted pre-master secret which the server decrypts to prove its identity (i.e., that it knows the private key for the certificate it advertised to the client). So to leverage batch signing we need to design protocols that allow for it, hence why we created tcpcrypt clean-slate. We do have a drop-in replacement for OpenSSL that attempts to use tcpcrypt+batch signing if able otherwise reverting to SSL. This can be used by many existing SSL applications without modifying them but just replacing the system's SSL library. > I also have some comments on some other points. The USENIX Security > paper mentions the goal of ubiquitous encryption (though the draft > does not). Requiring changes to the TCP stack would hinder > deployment and work against the goal of ubiquity. The protocol is designed with incremental deployment in mind which hopefully will lead to ubiquitous encryption. Specifically: * It tries tcpcrypt and falls back to TCP gracefully. The app doesn't * have to know anything about tcpcrypt. Sure, modifying the TCP stack hinders deployment. So would modifying all applications (which is potentially even more difficult). We need to modify something to get encryption, and for the reasons just mentioned about incremental deployment we think TCP is the right place to do it. > The draft describes the RSA public keys as "ephemeral", and the > companion paper says that the protocol achieves forward secrecy. > However, if it was really the case that a new RSA keypair was > generated for each exchange, then the performance would be > significantly worse than what is shown in the paper, because the > cost of that operation is significantly higher than that of RSA > decryption. I think the claims and/or guidance to implementers > needs to be clarified. It's not perfect forward secrecy (i.e., one key per connection). More like one key per 10 minute window or whatever the system is configured to. > The Security Considerations section looks like boilerplate, while it > seems that there is a lot to be discussed, such as the security > properties of Session IDs. Yes, we agree - this is just a first draft. Well work on improving that. If this is taken on by the IETF, no doubt things we haven't thought of will be pointed out. > Is it possible to relate the protocol to a previously analyzed > protocol? It is similar to ISO/IEC 11770-3, in that it relies on > public key encryption of nonces, without signatures. Perhaps there > is some analysis of that protocol, or of a protocol with cryptosuite > negotiation, that could be leveraged. The companion paper does have > a brief analysis of the security of the protocol, but it would be > good if it were possible to benefit from detailed analyses of all > aspects of protocol security. (I do realize that the analysis is > made easier by the relative simplicity of the protocol; that's a > good thing.) We agree, and we'll work on this. > The security analysis defines the parameter "k ~ 256 is the minimum > of the min-entropy of a public key". Surely that doesn't match the > 2048-bit RSA examples in the paper? The paper says: "where k ~ 256 is the minimum of the min-entropy of a public key, or the length in bits of NS or NC." NS and NC are random 256-bit values, so their min entropy is 256. The public key is a product of two 1,024-bit primes, so its min entropy is much higher than 256. The min entropy is just the probability of running the key generation function twice and getting the same public key out the second time. This has nothing to do with the difficulty of breaking RSA (which for 2,048-bit keys would be sort of equivalent to a 112-bit symmetric key). The difficulty of breaking RSA is irrelevant to our reduction. We are saying that if you can break tcpcrypt, we can break the public key algorithm or one of the other cryptographic functions in a "black box" way, without regard to what the algorithms actually are. > As a side note, I am surprised to see a proposal to add so much > cryptographic functionality into the TCP standard, considering that > not many years have passed since the transport area declined to add > (much simpler) key transport functionality into TCP in support of > TCP-AO. Perhaps "Experimental" was intended, or perhaps I have > missed or misunderstood some aspect of this work. We think the perceived use case for TCP-AO was a replacement for TCP-MD5 in BGP sessions. Of course TCP-AO is broader than that, but the perceived use case may have influenced the previous decision. From kathleen.moriarty@emc.com Thu Jul 28 08:42:54 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED1D221F8C88 for ; Thu, 28 Jul 2011 08:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-bxZcSqwjR5 for ; Thu, 28 Jul 2011 08:42:54 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 4002021F8C71 for ; Thu, 28 Jul 2011 08:42:53 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p6SFgpeY030085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 28 Jul 2011 11:42:51 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor) for ; Thu, 28 Jul 2011 11:39:32 -0400 Received: from mxhub04.corp.emc.com (mxhub04.corp.emc.com [10.254.141.106]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p6SFdVrZ005749 for ; Thu, 28 Jul 2011 11:39:31 -0400 Received: from mx06a.corp.emc.com ([169.254.1.199]) by mxhub04.corp.emc.com ([10.254.141.106]) with mapi; Thu, 28 Jul 2011 11:39:30 -0400 From: To: Date: Thu, 28 Jul 2011 11:39:30 -0400 Thread-Topic: MILE Side Meeting Summary Thread-Index: AQHMTTyKAk2Mw71mnEesDOpwXsZ6ig== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 X-Mailman-Approved-At: Fri, 29 Jul 2011 08:01:00 -0700 Subject: [saag] MILE Side Meeting Summary X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 15:42:55 -0000 Hello, Thank you to those of you that were able to attend or dial into the MILE si= de meeting on Monday night. During the meeting, we provided an overview of= prior work and discussed the planned direction for future work, specifical= ly: o the extension template (review provided by Brian),=20 o the list of extensions in which interest in development was expressed,= and=20 o the generalization of RID for use outside of the incident space. Dr. Katherine Goodier also presented on further research into the data mark= ings and privacy options for IODEF/RID as a result of work she has done in = coordination with NATO and others. The presentation was sent to the list a= nd is a very nice review of the considerations for privacy in this space, w= here regulations from over a hundred countries were considered. Please tak= e a look at her slides and provide comments/questions to the list if you ha= ve any. Katherine and Guas will be working to develop a draft in this spac= e to the list with the goal of having it out well in advance of the next me= eting so that review can occur on the mailing list. Thank you and best regards, Kathleen From ananth@cisco.com Thu Jul 28 11:41:53 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 864535E801B; Thu, 28 Jul 2011 11:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.024 X-Spam-Level: X-Spam-Status: No, score=-6.024 tagged_above=-999 required=5 tests=[AWL=-3.425, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmhxHxDzxswO; Thu, 28 Jul 2011 11:41:52 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id B20F15E801A; Thu, 28 Jul 2011 11:41:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=2157; q=dns/txt; s=iport; t=1311878513; x=1313088113; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=j3m8ZFQYIFJkxo4Zy66jOTOW0fSqOoI+V5g5V2BG8E8=; b=WLlCeMCEBYlI60nZTZREiPM9Q30b2YYf+LCYekHOSGeTMNgO5tmsdU57 ylJeJPovf8c57XhW1nqvJkpjIf4psv2Q1VogIp9Eow7v5KHeII3BqrY3S 2j9YRzGSbDJ6FYs1hdwz2Vspjz8yrPg5QuG5klnpQdJAupQO/1EnoThe5 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuUAANmsMU6rRDoH/2dsb2JhbAA0AQEBAQMUASEKRQwFAgEJEQQBAQEKBiMBBgETOw4IAQEDAgEWDBQHl2uPT3etdJ4/hWJfBIdZkDCLHVc X-IronPort-AV: E=Sophos;i="4.67,283,1309737600"; d="scan'208";a="7491411" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-9.cisco.com with ESMTP; 28 Jul 2011 18:41:51 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6SIfmKL006187; Thu, 28 Jul 2011 18:41:51 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Jul 2011 11:41:46 -0700 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, 28 Jul 2011 11:41:45 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC580D482D56@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <4E31A4B7.6010900@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Fwd: fyi: tcpcrypt draft Thread-Index: AcxNUPlP6zUQn3zuSZWdt6KFh754WQABKVbg References: <4DC6C56D.6040709@ieca.com><20110727184256.GA3690@shorty><4E308A4B.4090702@isi.edu> <4E31A4B7.6010900@isi.edu> From: "Anantha Ramaiah (ananth)" To: "Joe Touch" , "Mark Handley" X-OriginalArrivalTime: 28 Jul 2011 18:41:46.0252 (UTC) FILETIME=[00C7C4C0:01CC4D56] X-Mailman-Approved-At: Fri, 29 Jul 2011 08:01:00 -0700 Cc: tcpcrypt@scs.stanford.edu, saag@ietf.org, tsvwg Subject: Re: [saag] Fwd: fyi: tcpcrypt draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 18:41:53 -0000 Is there any consideration to allocate more code points for TCP experimental usage? With the increasing number of experimental TCP drafts (some of which uses TCP options), it would be useful thing to extend the experimental TCP option space. Wondering whether this has been brought up before? -Anantha > -----Original Message----- > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf > Of Joe Touch > Sent: Thursday, July 28, 2011 11:05 AM > To: Mark Handley > Cc: tcpcrypt@scs.stanford.edu; saag@ietf.org; tsvwg > Subject: Re: [saag] Fwd: fyi: tcpcrypt draft >=20 >=20 >=20 > On 7/28/2011 10:15 AM, Mark Handley wrote: > > On 27 July 2011 17:59, Joe Touch wrote: > >> Since this is the second IETF transport presentation (the first was > in TCPM > >> at IETF 80), I hope this presentation will clarify how the current > tcpcrypt > >> code uses the existing TCP option space. > >> > >> In specific, it appears to use *two* unassigned TCP option > codepoints (69 > >> and 70), rather than experimental codepoints (and, IMO, it should > use the > >> latter instead). > > > > Hi Joe, > > > > You're correct that our code is currently using two unassigned > > codepoints, and we should not be doing so. I've looked into what we > > should do, and the problem is that there are deployed products using > > the two experimental options. We don't wish them to interfere with > > our experiments, nor do we wish to interfere with their experiments. >=20 > Hi, Mark, >=20 > It's hard to understand how these could interfere, since experiments > are > not supposed to be widely deployed. The only interference would be if > theirs were widely deployed *and* yours were too, which means you're > both using those codepoints inappropriately. >=20 > > But using unassigned ports is bad too. I've talked with Wes and > > David, and we're working on figuring out the least bad solution. Wes > > will raise the issue with the IESG, and we'll implement whatever they > > decide is best. >=20 > AOK. It'd be useful to note this in your talk, IMO. >=20 > Thanks, >=20 > Joe From Tina.Tsou.Zouting@huawei.com Thu Jul 28 15:59:29 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C68B11E80A1; Thu, 28 Jul 2011 15:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.844 X-Spam-Level: X-Spam-Status: No, score=-4.844 tagged_above=-999 required=5 tests=[AWL=-0.464, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GvbYnQOwHYNW; Thu, 28 Jul 2011 15:59:28 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 6E35C11E8097; Thu, 28 Jul 2011 15:59:28 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP200ERPFV1O8@szxga03-in.huawei.com>; Fri, 29 Jul 2011 06:59:26 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP2002XGFV0MN@szxga03-in.huawei.com>; Fri, 29 Jul 2011 06:59:25 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml206-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACR48000; Fri, 29 Jul 2011 06:59:25 +0800 (CST) Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 29 Jul 2011 06:59:18 +0800 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.19]) by szxeml410-hub.china.huawei.com ([169.254.101.122]) with mapi id 14.01.0270.001; Fri, 29 Jul 2011 06:59:22 +0800 Date: Thu, 28 Jul 2011 22:59:22 +0000 From: Tina TSOU X-Originating-IP: [10.212.246.185] To: "hokey@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: Hokey-81 meeting minutes Thread-index: AcxNefgHbkDXOvy6T66+swagazq6bA== X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AtZZ Az5P Brf8 CU+H L7d3 N6Nv OBxO OJiM QX/8 Qqs4 SABk TwDW UMf6 UNF2 VTPD VnJ+; 2; aABvAGsAZQB5AEAAaQBlAHQAZgAuAG8AcgBnADsAcwBhAGEAZwBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {29F29AD3-86FE-42E5-96CF-5DA5FE73BB9E}; dABpAG4AYQAuAHQAcwBvAHUALgB6AG8AdQB0AGkAbgBnAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Thu, 28 Jul 2011 22:59:15 GMT;SABvAGsAZQB5AC0AOAAxACAAbQBlAGUAdABpAG4AZwAgAG0AaQBuAHUAdABlAHMA x-cr-puzzleid: {29F29AD3-86FE-42E5-96CF-5DA5FE73BB9E} X-CFilter-Loop: Reflected X-Mailman-Approved-At: Fri, 29 Jul 2011 08:01:00 -0700 Cc: "saag@ietf.org" Subject: [saag] Hokey-81 meeting minutes X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 22:59:29 -0000 http://www.ietf.org/proceedings/81/minutes/hokey.txt Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html From mark.j.handley@gmail.com Fri Jul 29 02:44:50 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7538E21F8747 for ; Fri, 29 Jul 2011 02:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8IyktZIfatF for ; Fri, 29 Jul 2011 02:44:49 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA8721F8B3D for ; Fri, 29 Jul 2011 02:44:49 -0700 (PDT) Received: by wyj26 with SMTP id 26so420474wyj.31 for ; Fri, 29 Jul 2011 02:44:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=60M2jJkZeODviuyjYUzfQVvwWLYReSEEU1rGXcywDeE=; b=q7oSbKNXNSAjRBztuLVDdDXO5qkeNn4xZMCCA9Lg32tCyxXljSeYAI4qnQ3Coixi6o c3xkFkKRKzVa4RjAzsZlLQyQNCUbxeKxSUhM03EiLlTxVENp9DBgX43qbmPriJsW+WmL UI8Ea5AdSGX9I6sm9Hh6nIQc+AfDxKWGCwdRU= Received: by 10.227.19.194 with SMTP id c2mr1462254wbb.65.1311932688337; Fri, 29 Jul 2011 02:44:48 -0700 (PDT) Received: from [10.71.33.133] ([82.132.211.57]) by mx.google.com with ESMTPS id 20sm1594224wbw.36.2011.07.29.02.44.14 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Jul 2011 02:44:15 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8C148) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <3061F3CF-1CFA-4D07-8906-A6542D632270@gmail.com> X-Mailer: iPhone Mail (8C148) From: Mark Handley Date: Fri, 29 Jul 2011 05:44:00 -0400 To: Peter Gutmann X-Mailman-Approved-At: Fri, 29 Jul 2011 08:01:00 -0700 Cc: "saag@ietf.org" Subject: Re: [saag] fyi: tcpcrypt draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 09:44:50 -0000 Thanks Peter - the paper has been accepted for publication in IMC, but it wi= ll be revised a little for final publication - in part because Michio has co= ntinued gathering data. That's why this version is at a tmp URL. I'm fine w= ith you circulating this version further though if it's useful. - Mark On 29 Jul 2011, at 01:51, Peter Gutmann wrote: > Mark Handley writes: >=20 >> - We conducted a pretty extensive study into whether extending TCP in >> this way would be deployable, or whether we've missed something, and >> we've done more testing. The draft paper is here: >>=20 >> http://nrg.cs.ucl.ac.uk/mjh/tmp/mboxes.pdf >=20 > This is a really interesting paper that affects a rather large number of o= ther=20 > things (the whole end-to-end argument, IPv6 deployment, network neutrality= ,=20 > and so on), any chance of making this publicly available for others to rea= d? =20 > The 'tmp' in the path implies that it's not for public consumption... >=20 > Peter. From bittau@gmail.com Fri Jul 29 18:47:36 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3ED711E8073; Fri, 29 Jul 2011 18:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[AWL=-2.107, BAYES_00=-2.599, FRT_STOCK2=3.988, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KrUPTcfg+YAc; Fri, 29 Jul 2011 18:47:36 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id EE6675E8020; Fri, 29 Jul 2011 18:47:35 -0700 (PDT) Received: by iye7 with SMTP id 7so5545578iye.31 for ; Fri, 29 Jul 2011 18:47:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-echelon:user-agent; bh=CwB/EvwkzDFnGaTSioC+hbuUUczMqx4xM5kUNFKcP94=; b=m2BTsVz7u3BO5RJqDXD8jLmKcxOIkf/yIK+eJ/MrgiAx25Qy+bxZKMTYhqOA+lErGj aet6bozrfZ3p4yzcPc7gf6XdZflUJv9QWqtFpIi+pb41R3GUt5DkivIpIStwRF+bVTtk /lgQoFpqb796w+k9SPmci30eCNgVWjmztwuxU= Received: by 10.42.97.68 with SMTP id m4mr1521367icn.292.1311990455386; Fri, 29 Jul 2011 18:47:35 -0700 (PDT) Received: from tapir.cs.ucl.ac.uk (sorbox.scs.stanford.edu [171.66.3.197]) by mx.google.com with ESMTPS id s2sm3530668icw.5.2011.07.29.18.47.31 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Jul 2011 18:47:32 -0700 (PDT) Sender: Andrea Bittau Received: by tapir.cs.ucl.ac.uk (Postfix, from userid 0) id 1FE634810172; Fri, 29 Jul 2011 18:45:44 -0700 (PDT) Date: Fri, 29 Jul 2011 18:45:44 -0700 From: Andrea Bittau To: "David A. McGrew" Message-ID: <20110730014544.GM3751@shorty> References: <4DC6C56D.6040709@ieca.com> <20110727184256.GA3690@shorty> <8A00B447-53C3-44D0-8238-8DAAE44688CB@mindspring.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8A00B447-53C3-44D0-8238-8DAAE44688CB@mindspring.com> X-Echelon: Bush Bomb War KGB User-Agent: Mutt/1.5.21 (2010-09-15) Cc: tcpcrypt@scs.stanford.edu, tsv-area@ietf.org, saag@ietf.org Subject: Re: [saag] fyi: tcpcrypt draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2011 01:47:37 -0000 On Thu, Jul 28, 2011 at 07:33:05AM -0700, David A. McGrew wrote: > A lot of work has been done on using IPsec to solve these problems, > and it is important to explain in detail how tcpcrypt improves on > this work. Besides the opportunistic encryption effort, there is > BTNS (draft-ietf-btns-channel-binding-api-00 defines channel > bindings for IPsec, for instance), RFC 3947 for running IPsec over > NAT. (Half joking: would the configuration of > draft-ietf-ipsec-internet-key-00 with NAT-T solve all or most these > problems?) tcpcrypt makes incremental deployment easier because probing is built into existing packets and fallback comes at no extrea cost. When a SYN packet is sent out and tcpcrypt is not supported at the other end, we can fallback to regular tcpcrypt at no extra cost - just carry on with a vanilla TCP handshake. How would this work with BTNS or IPSec? Do you probe for IPSec (and then probe for NAT-T), wait for a timeout, and then send a TCP SYN? If so, it adds network overhead (extra packets) and latency (probe timeout). tcpcrypt also has less protocol (space) overhead. NAT-T requires encapsulating IP in UDP, and NAT seems like a common deployment scenario. It also requires opening more ports on a firewall and configuring additional services (NAT-T). > What TCP applications can't use TLS? Do you mean that some apps > don't use TLS in current implementations, or that there is some > basic incompatibility? There's a bootstrap problem. If I have SMTP on TCP/25 I have to assume it's clear-text (I can't send an SSL handshake packet). Thankfully, SMTP is an extensible protocol and I can send STARTTLS and then go on with SSL. If the protocol didn't permit any "options" / commands, I'd be stuck to plain-text. I'd have to allocate a new port. That makes incremental deployment harder - do I send two SYNs? > What about running TCP on top of DTLS? That would protect the TCP > session, while keeping the crypto separate from the TCP stack. Same answer as per BTNS and NAT-T - we can efficiently incrementally deploy and have less protocol overhead. > 1. How easy to configure will tcpcrypt be once it supports mutual > authentication, the enforcement of configurable security policies, > and crypto algorithm agility (e.g. ECDH and ECDSA)? Authentication is left to the application, so tcpcrypt will support authentication only if the application supports it. If the application supports it, then a mechanism is already in place, e.g., htpasswd in Apache for passwords. So in the case of Apache, it'll include tcpcrypt's session id when doing http digest authentication, for example. We're also working on an authentication library that attempts to authenticate tcpcrypt using DNSSEC+DANE that can be used by all apps if DANE is deployed. The configuration will require storing a certificate fingerprint in DNS. We expect that most applications (e.g., the ones running clear-text today) won't care about the crypto algorithms used in tcpcrypt's handshake. So the security policy will be set system-wide (e.g., allow only RSA, SHA1 or whatever). For security concious applications it'll be a setsockopt and presumably those applications already have a configuration file for whatever the already use today for crypto. > 2. The comparison of tcpcrypt to TLS is only considering the RSA > ciphersuites in the latter protocol. The efficiency and security > properties of other ciphersuites are quite different. Yes, but we expect tcpcrypt to be no worse (or better) than TLS. tcpcrypt fundamentally does however have lower latency for conncection establishment compared to TLS due to fewer RTTs needed in negotiating a key (we leverage the 3-way handshake and add only an extra leg), especially when session caching. > 3. Reversing the client and server public/private key operations in > tcpcrypt, which is used to make the protocol more scalable, is > applicable only to the RSA algorithm. In particular, the situation > with elliptic curve cryptography is quite different. This raises > some questions: how does tcpcrypt with RSA compare to an ECDH/ECDSA > TLS ciphersuite, say, at security levels of 128, 192, or 256 bits? > How does tcpcrypt perform with other algorithms? Given the > interest in ECC as a future direction for cryptography, these > questions deserve some thought. Yes, we'll implement those but we do not expect tcpcrypt's performance to be much different from a TLS implementation - we both do the same thing (e.g., ECDH). > What you are describing here is true for the RSA ciphersuites in > SSL, but is not true for the Diffie-Hellman ciphersuites, or the > ECDH ones (see Section 7.4.2 of RFC 5246 for instance). tcpcrypyt's main goal is to be deployed ubiquitously. Improved performance in one case is only a bonus. It has a bunch of other advantages (single integrated mechanism, incrementally deployable) apart from RSA performance. > Why is graceful fallback easier at the TCP layer than at another > layer? And if there is some mechanism within TCP that facilitates > fallback, would it be possible to use that mechanism in conjunction > with a cryptographic protocol external to TCP? That last option > would minimize the impact to TCP implementations, meaning less new > code inside kernels, and fewer states, and so on. Gracefully, and efficient, I should add. The problem is detecting whether the other end supports crypto mechanism X. At a below-transport layer, we'd have to send our IP packet, wait for a timeout, and then send a SYN. At a transport layer we're sending out a SYN so we can easily piggyback options (perfect!). At an application layer what's the first thing we send? STARTTLS? Does the application-layer protocol allow such new commands or will it drop the command? The minimum TCP mechanism needed for a graceful and efficient fallback is a TCP option in the SYN. So, tcpcrypt-lite would modify a kernel with a setsockopt(CRYPTO_OPTION) to include the CRYPTO option in a SYN and getsockopt(CRYPTO_OPTION) to see if the CRYPTO option was echoed in the SYN-ACK. At that point SSL_accept() can be called. But we lose all TCP header MACing - e.g., someone can RST our connection. TCP AO suggests that MACing TCP headers is important so crypto protocols should do that (hence why we live in the transport layer). Also, we can leverage the existing 3-way handshake to get a head start on crypto negotiations. Sesison caching completes within the three way handshake. > If the RSA keypair is generated using a pseudorandom process (and > there are standards for doing that), the min entropy could be lower. > > But if it is adequate to have the entropy show up in the nonces, the > min-entropy of the key would be a moot point. The pseudo-random generator has to have enough state to generate prime numbers with min entropy 256. Depending on the prime number generator, this might, for instance, require something on the order of 256 + ceil (log_2 (log_e (2 ^ 1024))) or 266 bits. We assume most RSA implementations would have more random state than that. From shawn.emery@oracle.com Fri Jul 29 21:09:06 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46B9321F8CAA for ; Fri, 29 Jul 2011 21:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.734 X-Spam-Level: X-Spam-Status: No, score=-2.734 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1D43osPTrV6 for ; Fri, 29 Jul 2011 21:09:05 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 9057721F8CA6 for ; Fri, 29 Jul 2011 21:09:01 -0700 (PDT) Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p6U48wsp019280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 30 Jul 2011 04:09:00 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p6U48vAV020892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 30 Jul 2011 04:08:58 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p6U48pIZ027902 for ; Fri, 29 Jul 2011 23:08:52 -0500 Received: from shawn-emerys-computer.local (/69.70.155.252) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 29 Jul 2011 21:08:24 -0700 USER-AGENT: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 Message-ID: <4E3383B8.5040403@oracle.com> Date: Fri, 29 Jul 2011 21:08:24 -0700 (PDT) From: Shawn M Emery To: saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090202.4E3383DC.006F,ss=1,re=0.000,fgs=0 Subject: [saag] kitten Summary for IETF 81 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2011 04:09:06 -0000 Co-chairs: Tom Yu, Shawn Emery, Alexey Melnikov The WG met in the 3rd afternoon session on Thursday (7.28.11). There were three presentations on two new work items and GSS-APIv2u1 issues: Replay cache avoidance -------------------- Replay caches are problematic; slow, clustering difficult, etc. There were a number of possible solutions including an implicit 3rd leg or explicit 3rd leg GSS security context establishment. The consensus in the room was in support of implicit 3rd leg context tokens. Of course all consensus calls made here will be brought to the list. Exporting partially established security context ---------------------------------------- There is a need to export partially established security context for processes that restart. There were a couple of solutions proposed including a new utility function or just allow this, possibly with a new major status code. Consensus in the room was that there was support for providing a utility function to do this and form a design team to spec the interface and token format. GSS-APIv2u1 issues ----------------- A number of issues were raised with the existing API, including buffer management, hacks to extend API features (e.g. set context and credentials options), minor status, and layering limitations. A number of proposals were made as solutions, but consensus in the room was to start a design team to explore possible interfaces before deciding on a particular solution. Shawn. -- From ondrej.sury@nic.cz Sat Jul 30 17:54:58 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 085EF21F85A4 for ; Sat, 30 Jul 2011 17:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[AWL=-0.601, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_81=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8xOqRWIRwVk4 for ; Sat, 30 Jul 2011 17:54:47 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id A853721F85A3 for ; Sat, 30 Jul 2011 17:54:43 -0700 (PDT) Received: from [192.168.230.135] (unknown [69.70.28.74]) by mail.nic.cz (Postfix) with ESMTPSA id 04D652A00BA; Sun, 31 Jul 2011 02:54:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1312073684; bh=y5mGK9W9E2wAbBA6SWOdY4kKYcwV2Qp3jYrwbooIbek=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=hLlHnzJPPNlIhzQdvvehBnWZRAcCr0fRL4GfLcFAx37CyGai/ge5lW38KVRZFVHqY vUCA2sW5770U7aYyRcm7FqWU+8FtJ8hDgCtltJCqDdyWGAYHIolM9le/gyC7YffsTA VyuipEFzWnWt7UMcK20kgkhw9718CQ9MpGtykS6c= Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: Date: Sat, 30 Jul 2011 20:54:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0F1A09E5-42E0-4B66-A317-155BB94BC5C2@nic.cz> To: Damien Miller X-Mailer: Apple Mail (2.1244.3) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: jakob@openbsd.org, openssh-unix-dev@mindrot.org, saag@ietf.org Subject: Re: [saag] Support for ECDSA and SHA-2 (SHA-256) in the SSHFP record X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2011 00:54:58 -0000 Hi Damien, On 30. 7. 2011, at 14:21, Damien Miller wrote: > Thanks for starting work on this - SSHFP records for ECDSA keys were = on > my TODO list, but I haven't yet got around to them. > I briefly skimmed your draft - one question I have is whether it is > better to roll up all the ECDSA key types under one SSHFP RR type. > It would be quite ugly to have to allocate SSHFP RR type numbers for > each possible ECDSA curve type, but using a single one might make > exploitation of SHA256 preimage attacks easier. My knowledge of cryptography is not so strong, so that's probably good = question for security area advisory group as well. > The latter is a theoretical concern, so I think a single RR type is > probably correct. I'll be happy to accept any changes to the draft. I already had the = different ECDSA curves in the draft, but it was suggested by my fellow = AD that one is probably enough. > It would probably be best to continue discussion of this on the IETF = SSH > list. I thought that secsh was concluded, but it seems that the mailing list = is still up. Ccing there as well. Anyone who responds please get rid of openssh-unix-dev list when = replying, so we don't spam them with ietf flames :) O. > On Thu, 28 Jul 2011, Ond?ej Sur? wrote: >=20 >> Hi, >>=20 >> I was sure I sent this to openssh@openssh.com, but cannot find that = email now in my Sent mailbox, so I am sending it to the developers list. >>=20 >> I took a liberty and wrote an I-D with accompanying patch (with = contributions from Ondrej Caletka) to support ECDSA in the SSHFP DNS = resource record. >>=20 >> The I-D is here: = https://tools.ietf.org/html/draft-os-ietf-sshfp-ecdsa-sha2 (and the = source XML here: = https://git.nic.cz/redmine/projects/ietf/repository/revisions/master/chang= es/draft-os-ietf-sshfp-ecdsa-sha2-00.xml) >>=20 >> The patch to vanilla 5.8 here: = https://git.nic.cz/redmine/projects/ietf/repository/revisions/master/chang= es/ssh-sshfp-ecdsa.patch >>=20 >> Please Cc: me as I am not (and don't intend to be) subscribed to the = list. I will check the archives occasionally, but Cc: would be = appreciated. >>=20 >> Thanks, >> O. >> -- >> Ond?ej Sur? >> vedouc? v?zkumu/Head of R&D department >> ------------------------------------------- >> CZ.NIC, z.s.p.o. -- Laborato?e CZ.NIC >> Americka 23, 120 00 Praha 2, Czech Republic >> mailto:ondrej.sury@nic.cz http://nic.cz/ >> tel:+420.222745110 fax:+420.222745112 >> ------------------------------------------- >>=20 >> _______________________________________________ >> openssh-unix-dev mailing list >> openssh-unix-dev@mindrot.org >> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >>=20 -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 -------------------------------------------