From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Jun 12 18:42:03 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyF3r-00086n-K8 for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 12 Jun 2007 18:42:03 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyF3p-0000G7-Sq for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 12 Jun 2007 18:42:03 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 989EA63B223; Tue, 12 Jun 2007 22:41:57 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from natsu.mindrot.org (natsu.mindrot.org [203.209.195.154]) by mail.netbsd.org (Postfix) with ESMTP id A870B63B17B for ; Tue, 12 Jun 2007 22:41:55 +0000 (UTC) Received: by natsu.mindrot.org (Postfix, from userid 1002) id D67A769BB9; Wed, 13 Jun 2007 07:23:29 +1000 (EST) X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on natsu.mindrot.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from fuyu.mindrot.org (fuyu.mindrot.org [203.217.30.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "fuyu.mindrot.org", Issuer "StartCom Class 1 Primary Intermediate Free CA" (not verified)) by natsu.mindrot.org (Postfix) with ESMTP id D460D69B5E for ; Wed, 13 Jun 2007 07:23:23 +1000 (EST) Received: by fuyu.mindrot.org (Postfix, from userid 1000) id 3B40D3C67C; Wed, 13 Jun 2007 07:23:23 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by fuyu.mindrot.org (Postfix) with ESMTP id 35C863C67B for ; Wed, 13 Jun 2007 07:23:23 +1000 (EST) Date: Wed, 13 Jun 2007 07:23:23 +1000 (EST) From: Damien Miller To: ietf-ssh@netbsd.org Subject: draft-miller-secsh-umac-00.txt Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-733381464-1181683403=:13880" Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-733381464-1181683403=:13880 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, Attached is a draft for the use of Ted Krovetz' UMAC (RFC4418) as a SSH MAC. OpenSSH -current implements the umac-64 method described in the draft under the name "umac-64@openssh.com". We'd be interested in hearing from anyone else who wants to implement it. -d --0-733381464-1181683403=:13880 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=draft-miller-secsh-umac-00.txt Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=draft-miller-secsh-umac-00.txt DQoNCg0KTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgRC4gTWlsbGVyDQpJbnRlcm5ldC1E cmFmdCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFAuIFZhbGNoZXYNCkludGVuZGVkIHN0YXR1czogU3RhbmRhcmRz IFRyYWNrICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgT3BlblNT SA0KRXhwaXJlczogRGVjZW1iZXIgMTMsIDIwMDcgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBKdW5lIDExLCAyMDA3DQoNCg0KICAgICAgICAg IFRoZSB1c2Ugb2YgVU1BQyBpbiB0aGUgU1NIIFRyYW5zcG9ydCBMYXllciBQ cm90b2NvbA0KICAgICAgICAgICAgICAgICAgICAgZHJhZnQtbWlsbGVyLXNl Y3NoLXVtYWMtMDAudHh0DQoNClN0YXR1cyBvZiB0aGlzIE1lbW8NCg0KICAg Qnkgc3VibWl0dGluZyB0aGlzIEludGVybmV0LURyYWZ0LCBlYWNoIGF1dGhv ciByZXByZXNlbnRzIHRoYXQgYW55DQogICBhcHBsaWNhYmxlIHBhdGVudCBv ciBvdGhlciBJUFIgY2xhaW1zIG9mIHdoaWNoIGhlIG9yIHNoZSBpcyBhd2Fy ZQ0KICAgaGF2ZSBiZWVuIG9yIHdpbGwgYmUgZGlzY2xvc2VkLCBhbmQgYW55 IG9mIHdoaWNoIGhlIG9yIHNoZSBiZWNvbWVzDQogICBhd2FyZSB3aWxsIGJl IGRpc2Nsb3NlZCwgaW4gYWNjb3JkYW5jZSB3aXRoIFNlY3Rpb24gNiBvZiBC Q1AgNzkuDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1 bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nDQogICBUYXNrIEZv cmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBz LiAgTm90ZSB0aGF0DQogICBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJp YnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC0NCiAgIERyYWZ0 cy4NCg0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMg dmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzDQogICBhbmQgbWF5 IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIg ZG9jdW1lbnRzIGF0IGFueQ0KICAgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlh dGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UNCiAgIG1h dGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGlu IHByb2dyZXNzLiINCg0KICAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5l dC1EcmFmdHMgY2FuIGJlIGFjY2Vzc2VkIGF0DQogICBodHRwOi8vd3d3Lmll dGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQuDQoNCiAgIFRoZSBsaXN0 IG9mIEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUg YWNjZXNzZWQgYXQNCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0 bWwuDQoNCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24g RGVjZW1iZXIgMTMsIDIwMDcuDQoNCkNvcHlyaWdodCBOb3RpY2UNCg0KICAg Q29weXJpZ2h0IChDKSBUaGUgSUVURiBUcnVzdCAoMjAwNykuDQoNCkFic3Ry YWN0DQoNCiAgIFRoaXMgbWVtbyBkZXNjcmliZXMgdGhlIHVzZSBvZiB0aGUg VU1BQyBNZXNzYWdlIEF1dGhlbnRpY2F0aW9uIENvZGUNCiAgIGluIHRoZSBT U0ggdHJhbnNwb3J0IHByb3RvY29sLg0KDQoNCg0KDQoNCg0KDQoNCg0KTWls bGVyICYgVmFsY2hldiAgICAgICAgRXhwaXJlcyBEZWNlbWJlciAxMywgMjAw NyAgICAgICAgICAgICAgIFtQYWdlIDFdDQoMDQpJbnRlcm5ldC1EcmFmdCAg ICAgVU1BQyBtZXNzYWdlIGF1dGhlbnRpY2F0aW9uIGZvciBTU0ggICAgICAg ICBKdW5lIDIwMDcNCg0KDQpUYWJsZSBvZiBDb250ZW50cw0KDQogICAxLiAg UmVxdWlyZW1lbnRzIG5vdGF0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDMNCiAgIDIuICBPdmVydmlldyAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gMw0KICAgMy4gIE1BQyBjYWxjdWxhdGlvbiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzDQogICA0LiAgTmV3 IE1BQyBtZXRob2RzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDQNCiAgICAgNC4xLiAgdW1hYy0zMiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g NA0KICAgICA0LjIuICB1bWFjLTY0IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0DQogICAgIDQuMy4gIHVt YWMtOTYgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDQNCiAgICAgNC40LiAgdW1hYy0xMjggIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNA0K ICAgNS4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0DQogICA2LiAgTm9ybWF0aXZl IFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDUNCiAgIEF1dGhvcnMnIEFkZHJlc3NlcyAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNQ0KICAg SW50ZWxsZWN0dWFsIFByb3BlcnR5IGFuZCBDb3B5cmlnaHQgU3RhdGVtZW50 cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiA2DQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCk1pbGxlciAmIFZhbGNoZXYgICAgICAgIEV4cGlyZXMgRGVj ZW1iZXIgMTMsIDIwMDcgICAgICAgICAgICAgICBbUGFnZSAyXQ0KDA0KSW50 ZXJuZXQtRHJhZnQgICAgIFVNQUMgbWVzc2FnZSBhdXRoZW50aWNhdGlvbiBm b3IgU1NIICAgICAgICAgSnVuZSAyMDA3DQoNCg0KMS4gIFJlcXVpcmVtZW50 cyBub3RhdGlvbg0KDQogICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1Qg Tk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsDQogICAi U0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwg YW5kICJPUFRJT05BTCIgaW4gdGhpcw0KICAgZG9jdW1lbnQgYXJlIHRvIGJl IGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBbUkZDMjExOV0uDQoNCg0K Mi4gIE92ZXJ2aWV3DQoNCiAgIFNTSCBbUkZDNDI1MV0gaXMgYSBwb3B1bGFy IHByb3RvY29sIGZvciBzZWN1cmUgcmVtb3RlIGxvZ2luIGFuZCBkYXRhDQog ICB0cmFuc2ZlciBvbiB0aGUgSW50ZXJuZXQuICBBbW9uZyB0aGUgc2VjdXJp dHkgcHJvcGVydGllcyB0aGF0IFNTSA0KICAgb2ZmZXJzIGlzIGludGVncml0 eSBvZiBjb21tdW5pY2F0aW9uIGFnYWluc3QgYWN0aXZlIGFkdmVyc2FyaWVz Lg0KICAgVGhpcyBpbnRlZ3JpdHkgaXMgcHJvdmlkZWQgaW4gdGhlIFNTSCB0 cmFuc3BvcnQgcHJvdG9jb2wgW1JGQzQyNTNdDQogICB0aHJvdWdoIHRoZSB1 c2Ugb2YgYSBwZXItcGFja2V0IE1lc3NhZ2UgQXV0aGVudGljYXRpb24gQ29k ZSAoTUFDKS4NCg0KICAgVGhpcyBtZW1vIGRlc2NyaWJlcyB0aGUgdXNlIG9m IHRoZSBVTUFDIE1lc3NhZ2UgQXV0aGVudGljYXRpb24gQ29kZQ0KICAgW1JG QzQ0MThdIGluIHRoZSBTU0ggdHJhbnNwb3J0IHByb3RvY29sLiAgVU1BQyBv ZmZlcnMgaW1wcm92ZWQNCiAgIHBlcmZvcm1hbmNlIG92ZXIgdGhlIGN1cnJl bnQgSE1BQy1iYXNlZCBNQUNzIHN1cHBvcnRlZCBieSBTU0guDQogICBGdXJ0 aGVybW9yZSwgVU1BQyByZXByZXNlbnRzIGEgZGlmZmVyZW50IGNyeXB0b2dy YXBoaWMgYXBwcm9hY2ggdG8NCiAgIG1lc3NhZ2UgYXV0aGVudGljYXRpb24g dG8gdGhhdCBvZiBITUFDLCBhbmQgaXRzIHVzZSBpbiBTU0ggd291bGQNCiAg IHByb3ZpZGUgYSBkaXZlcnNpdHkgdGhhdCBtYXkgYmUgb2YgYmVuZWZpdCBp ZiBITUFDIG9yIG9uZSBvZiBpdHMNCiAgIHVuZGVybHlpbmcgaGFzaCBhbGdv cml0aG1zIGlzIGZvdW5kIHRvIGJlIHZ1bG5lcmFibGUgdG8gYSBuZXcgYXR0 YWNrLg0KDQogICBVTUFDIG9mZmVycyBhIGNob2ljZSBvZiBmb3VyIGF1dGhl bnRpY2F0aW9uIHRhZyBzaXplczogMzIsIDY0LCA5NiBhbmQNCiAgIDEyOCBi aXRzLiAgVGhpcyBhbGxvd3MgdXNlcnMgdG8gdHJhZGUgYmV0d2VlbiBmYXN0 LCBjb21wYWN0IHRhZ3MgYW5kDQogICBsb25nZXIgdGFncyB0aGF0IGFyZSBz bG93ZXIgdG8gZ2VuZXJhdGUgYnV0IG9mZmVyIGJldHRlciBzZWN1cml0eS4N CiAgIFRoZXNlIGZvdXIgdGFnIHNpemVzIGFyZSByZXByZXNlbnRlZCBpbiB0 aGUgbmV3IE1BQyBtZXRob2RzDQogICBpbnRyb2R1Y2VkIGluIHRoaXMgbWVt bzogInVtYWMtMzIiLCAidW1hYy02NCIsICJ1bWFjLTk2IiBhbmQgInVtYWMt DQogICAxMjgiLg0KDQoNCjMuICBNQUMgY2FsY3VsYXRpb24NCg0KICAgTWVz c2FnZSBhdXRoZW50aWNhdGlvbiB0YWdzIGluIHRoZSBTU0ggdHJhbnNwb3J0 IHByb3RvY29sIGFyZQ0KICAgc3BlY2lmaWVkIHRvIGJlIGNhbGN1bGF0ZWQg b3ZlciB0aGUgcGFja2V0IHNlcXVlbmNlIG51bWJlciBmb2xsb3dlZA0KICAg YnkgdGhlIGVudGlyZSB1bmVuY3J5cHRlZCBwYWNrZXQ6DQoNCiAgICAgICAg ICAgbWFjID0gTUFDKGtleSwgc2VxdWVuY2VfbnVtYmVyIHx8IHVuZW5jcnlw dGVkX3BhY2tldCkNCg0KICAgSG93ZXZlciwgVU1BQyBhY2NlcHRzIGEgNjQg Yml0IG5vbmNlIGFzIGFuIGV4cGxpY2l0IGlucHV0IHRvIE1BQw0KICAgY2Fs Y3VsYXRpb24uICBJbiBvcmRlciBmb3IgdGhlIHNlY3VyaXR5IHByb29mcyB0 aGF0IGFjY29tcGFueSBVTUFDIHRvDQogICBhcHBseSwgdGhpcyBub25jZSBt dXN0IG5ldmVyIGJlIHJlcGVhdGVkIHVuZGVyIGEgZ2l2ZW4ga2V5LiAgSW4g dGhlDQogICBjb250ZXh0IG9mIHRoZSBTU0ggcHJvdG9jb2wsIHRoaXMgbWF5 IGJlIGFjaGlldmVkIGJ5IHVzaW5nIHRoZSBwYWNrZXQNCiAgIHNlcXVlbmNl IG51bWJlciBhcyB0aGUgbm9uY2UuICBUaGUgc2VxdWVuY2UgbnVtYmVyIGlz IGd1YXJhbnRlZWQgdG8NCiAgIGJlIHVuaXF1ZSBvdmVyIHRoZSBsaWZlIG9m IHRoZSBNQUMga2V5IGJ5IHRoZSByZXF1aXJlbWVudCB0aGF0DQogICBpbXBs ZW1lbnRhdGlvbnMgcGVyZm9ybSBhIGtleSByZS1leGNoYW5nZSBiZWZvcmUg dGhlIHNlcXVlbmNlIG51bWJlcg0KICAgd3JhcHMgKHNlY3Rpb24gOS4zLjMg b2YgW1JGQzQyNTFdKS4NCg0KDQoNCg0KTWlsbGVyICYgVmFsY2hldiAgICAg ICAgRXhwaXJlcyBEZWNlbWJlciAxMywgMjAwNyAgICAgICAgICAgICAgIFtQ YWdlIDNdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgVU1BQyBtZXNzYWdlIGF1 dGhlbnRpY2F0aW9uIGZvciBTU0ggICAgICAgICBKdW5lIDIwMDcNCg0KDQog ICBUbyB1c2UgdGhlIHNlcXVlbmNlIG51bWJlciBhcyB0aGUgTUFDIG5vbmNl LCBpdCBpcyBlbmNvZGVkIGludG8gYSBTU0gNCiAgIHByb3RvY29sIHVpbnQ2 NCAoYXMgZGVzY3JpYmVkIGluIHNlY3Rpb24gNSBvZiBbUkZDNDI1MV0pIGFu ZCBpdCBpcw0KICAgc3VwcGxpZWQgdG8gdGhlIFVNQUMgYWxnb3JpdGhtIGlu c3RlYWQgb2YgcHJlcGVuZGluZyBpdCB0byB0aGUgcGFja2V0DQogICB0byBi ZSBhdXRoZW50aWNhdGVkOg0KDQogICAgICAgICAgIG1hYyA9IFVNQUMoa2V5 LCBzZXF1ZW5jZV9udW1iZXIsIHVuZW5jcnlwdGVkX3BhY2tldCkNCg0KICAg Tm90ZSB0aGF0LCBiZWNhdXNlIHRoZSBzZXF1ZW5jZSBudW1iZXIgaXMgYSAz MiBiaXQgcXVhbnRpdHksIHRoZQ0KICAgaW5pdGlhbCAzMiBiaXRzIG9mIHRo ZSBub25jZSB3aWxsIGFsd2F5cyBiZSB6ZXJvLg0KDQoNCjQuICBOZXcgTUFD IG1ldGhvZHMNCg0KICAgVGhpcyBtZW1vIGludHJvZHVjZXMgZm91ciBuZXcg TUFDIG1ldGhvZHMsIG9uZSBmb3IgZWFjaCBVTUFDDQogICBhdXRoZW50aWNh dGlvbiB0YWcgbGVuZ3RoIHNwZWNpZmllZCBpbiBbUkZDNDQxOF06ICJ1bWFj LTMyIiwNCiAgICJ1bWFjLTY0IiwgInVtYWMtOTYiIGFuZCAidW1hYy0xMjgi Lg0KDQo0LjEuICB1bWFjLTMyDQoNCiAgIENhbGN1bGF0ZSBtZXNzYWdlIGF1 dGhlbnRpY2F0aW9uIHRhZ3MgdXNpbmcgdGhlIFVNQUMtMzIgYWxnb3JpdGht DQogICBzcGVjaWZpZWQgaW4gW1JGQzQ0MThdLCBzZWN0aW9uIDQuMi4NCg0K NC4yLiAgdW1hYy02NA0KDQogICBDYWxjdWxhdGUgbWVzc2FnZSBhdXRoZW50 aWNhdGlvbiB0YWdzIHVzaW5nIHRoZSBVTUFDLTY0IGFsZ29yaXRobQ0KICAg c3BlY2lmaWVkIGluIFtSRkM0NDE4XSwgc2VjdGlvbiA0LjIuDQoNCjQuMy4g IHVtYWMtOTYNCg0KICAgQ2FsY3VsYXRlIG1lc3NhZ2UgYXV0aGVudGljYXRp b24gdGFncyB1c2luZyB0aGUgVU1BQy05NiBhbGdvcml0aG0NCiAgIHNwZWNp ZmllZCBpbiBbUkZDNDQxOF0sIHNlY3Rpb24gNC4yLg0KDQo0LjQuICB1bWFj LTEyOA0KDQogICBDYWxjdWxhdGUgbWVzc2FnZSBhdXRoZW50aWNhdGlvbiB0 YWdzIHVzaW5nIHRoZSBVTUFDLTEyOCBhbGdvcml0aG0NCiAgIHNwZWNpZmll ZCBpbiBbUkZDNDQxOF0sIHNlY3Rpb24gNC4yLg0KDQoNCjUuICBTZWN1cml0 eSBDb25zaWRlcmF0aW9ucw0KDQogICBBcyBtZW50aW9uZWQgYWJvdmUsIGl0 IGlzIGltcGVyYXRpdmUgdGhhdCBpbXBsZW1lbnRhdGlvbnMgcGVyZm9ybSBh DQogICByZS1rZXlpbmcgb3BlcmF0aW9uIGJlZm9yZSByZXVzaW5nIGEgcGFj a2V0IHNlcXVlbmNlIG51bWJlciBhcyBhIFVNQUMNCiAgIG5vbmNlLiAgSW1w bGVtZW50YXRpb25zIGNvbmZvcm1pbmcgdG8gW1JGQzQyNTFdIGFyZSBhbHJl YWR5IHJlcXVpcmVkDQogICB0byBkbyB0aGlzLg0KDQoNCg0KDQoNCg0KDQpN aWxsZXIgJiBWYWxjaGV2ICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDEzLCAy MDA3ICAgICAgICAgICAgICAgW1BhZ2UgNF0NCgwNCkludGVybmV0LURyYWZ0 ICAgICBVTUFDIG1lc3NhZ2UgYXV0aGVudGljYXRpb24gZm9yIFNTSCAgICAg ICAgIEp1bmUgMjAwNw0KDQoNCjYuICBOb3JtYXRpdmUgUmVmZXJlbmNlcw0K DQogICBbUkZDMjExOV0gIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1 c2UgaW4gUkZDcyB0byBJbmRpY2F0ZQ0KICAgICAgICAgICAgICBSZXF1aXJl bWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LCBNYXJjaCAxOTk3Lg0K DQogICBbUkZDNDI1MV0gIFlsb25lbiwgVC4gYW5kIEMuIExvbnZpY2ssICJU aGUgU2VjdXJlIFNoZWxsIChTU0gpDQogICAgICAgICAgICAgIFByb3RvY29s IEFyY2hpdGVjdHVyZSIsIFJGQyA0MjUxLCBKYW51YXJ5IDIwMDYuDQoNCiAg IFtSRkM0MjUzXSAgWWxvbmVuLCBULiBhbmQgQy4gTG9udmljaywgIlRoZSBT ZWN1cmUgU2hlbGwgKFNTSCkNCiAgICAgICAgICAgICAgVHJhbnNwb3J0IExh eWVyIFByb3RvY29sIiwgUkZDIDQyNTMsIEphbnVhcnkgMjAwNi4NCg0KICAg W1JGQzQ0MThdICBLcm92ZXR6LCBULiwgIlVNQUM6IE1lc3NhZ2UgQXV0aGVu dGljYXRpb24gQ29kZSB1c2luZw0KICAgICAgICAgICAgICBVbml2ZXJzYWwg SGFzaGluZyIsIFJGQyA0NDE4LCBNYXJjaCAyMDA2Lg0KDQoNCkF1dGhvcnMn IEFkZHJlc3Nlcw0KDQogICBEYW1pZW4gTWlsbGVyDQogICBPcGVuU1NIDQoN CiAgIEVtYWlsOiBkam1Ab3BlbnNzaC5jb20NCg0KDQogICBQZXRlciBWYWxj aGV2DQogICBPcGVuU1NIDQoNCiAgIEVtYWlsOiBwdmFsQG9wZW5zc2guY29t DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQpNaWxsZXIgJiBWYWxjaGV2ICAgICAgICBFeHBpcmVzIERlY2VtYmVy IDEzLCAyMDA3ICAgICAgICAgICAgICAgW1BhZ2UgNV0NCgwNCkludGVybmV0 LURyYWZ0ICAgICBVTUFDIG1lc3NhZ2UgYXV0aGVudGljYXRpb24gZm9yIFNT SCAgICAgICAgIEp1bmUgMjAwNw0KDQoNCkZ1bGwgQ29weXJpZ2h0IFN0YXRl bWVudA0KDQogICBDb3B5cmlnaHQgKEMpIFRoZSBJRVRGIFRydXN0ICgyMDA3 KS4NCg0KICAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIHRoZSByaWdo dHMsIGxpY2Vuc2VzIGFuZCByZXN0cmljdGlvbnMNCiAgIGNvbnRhaW5lZCBp biBCQ1AgNzgsIGFuZCBleGNlcHQgYXMgc2V0IGZvcnRoIHRoZXJlaW4sIHRo ZSBhdXRob3JzDQogICByZXRhaW4gYWxsIHRoZWlyIHJpZ2h0cy4NCg0KICAg VGhpcyBkb2N1bWVudCBhbmQgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBo ZXJlaW4gYXJlIHByb3ZpZGVkIG9uIGFuDQogICAiQVMgSVMiIGJhc2lzIGFu ZCBUSEUgQ09OVFJJQlVUT1IsIFRIRSBPUkdBTklaQVRJT04gSEUvU0hFIFJF UFJFU0VOVFMNCiAgIE9SIElTIFNQT05TT1JFRCBCWSAoSUYgQU5ZKSwgVEhF IElOVEVSTkVUIFNPQ0lFVFksIFRIRSBJRVRGIFRSVVNUIEFORA0KICAgVEhF IElOVEVSTkVUIEVOR0lORUVSSU5HIFRBU0sgRk9SQ0UgRElTQ0xBSU0gQUxM IFdBUlJBTlRJRVMsIEVYUFJFU1MNCiAgIE9SIElNUExJRUQsIElOQ0xVRElO RyBCVVQgTk9UIExJTUlURUQgVE8gQU5ZIFdBUlJBTlRZIFRIQVQgVEhFIFVT RSBPRg0KICAgVEhFIElORk9STUFUSU9OIEhFUkVJTiBXSUxMIE5PVCBJTkZS SU5HRSBBTlkgUklHSFRTIE9SIEFOWSBJTVBMSUVEDQogICBXQVJSQU5USUVT IE9GIE1FUkNIQU5UQUJJTElUWSBPUiBGSVRORVNTIEZPUiBBIFBBUlRJQ1VM QVIgUFVSUE9TRS4NCg0KDQpJbnRlbGxlY3R1YWwgUHJvcGVydHkNCg0KICAg VGhlIElFVEYgdGFrZXMgbm8gcG9zaXRpb24gcmVnYXJkaW5nIHRoZSB2YWxp ZGl0eSBvciBzY29wZSBvZiBhbnkNCiAgIEludGVsbGVjdHVhbCBQcm9wZXJ0 eSBSaWdodHMgb3Igb3RoZXIgcmlnaHRzIHRoYXQgbWlnaHQgYmUgY2xhaW1l ZCB0bw0KICAgcGVydGFpbiB0byB0aGUgaW1wbGVtZW50YXRpb24gb3IgdXNl IG9mIHRoZSB0ZWNobm9sb2d5IGRlc2NyaWJlZCBpbg0KICAgdGhpcyBkb2N1 bWVudCBvciB0aGUgZXh0ZW50IHRvIHdoaWNoIGFueSBsaWNlbnNlIHVuZGVy IHN1Y2ggcmlnaHRzDQogICBtaWdodCBvciBtaWdodCBub3QgYmUgYXZhaWxh YmxlOyBub3IgZG9lcyBpdCByZXByZXNlbnQgdGhhdCBpdCBoYXMNCiAgIG1h ZGUgYW55IGluZGVwZW5kZW50IGVmZm9ydCB0byBpZGVudGlmeSBhbnkgc3Vj aCByaWdodHMuICBJbmZvcm1hdGlvbg0KICAgb24gdGhlIHByb2NlZHVyZXMg d2l0aCByZXNwZWN0IHRvIHJpZ2h0cyBpbiBSRkMgZG9jdW1lbnRzIGNhbiBi ZQ0KICAgZm91bmQgaW4gQkNQIDc4IGFuZCBCQ1AgNzkuDQoNCiAgIENvcGll cyBvZiBJUFIgZGlzY2xvc3VyZXMgbWFkZSB0byB0aGUgSUVURiBTZWNyZXRh cmlhdCBhbmQgYW55DQogICBhc3N1cmFuY2VzIG9mIGxpY2Vuc2VzIHRvIGJl IG1hZGUgYXZhaWxhYmxlLCBvciB0aGUgcmVzdWx0IG9mIGFuDQogICBhdHRl bXB0IG1hZGUgdG8gb2J0YWluIGEgZ2VuZXJhbCBsaWNlbnNlIG9yIHBlcm1p c3Npb24gZm9yIHRoZSB1c2Ugb2YNCiAgIHN1Y2ggcHJvcHJpZXRhcnkgcmln aHRzIGJ5IGltcGxlbWVudGVycyBvciB1c2VycyBvZiB0aGlzDQogICBzcGVj aWZpY2F0aW9uIGNhbiBiZSBvYnRhaW5lZCBmcm9tIHRoZSBJRVRGIG9uLWxp bmUgSVBSIHJlcG9zaXRvcnkgYXQNCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcv aXByLg0KDQogICBUaGUgSUVURiBpbnZpdGVzIGFueSBpbnRlcmVzdGVkIHBh cnR5IHRvIGJyaW5nIHRvIGl0cyBhdHRlbnRpb24gYW55DQogICBjb3B5cmln aHRzLCBwYXRlbnRzIG9yIHBhdGVudCBhcHBsaWNhdGlvbnMsIG9yIG90aGVy IHByb3ByaWV0YXJ5DQogICByaWdodHMgdGhhdCBtYXkgY292ZXIgdGVjaG5v bG9neSB0aGF0IG1heSBiZSByZXF1aXJlZCB0byBpbXBsZW1lbnQNCiAgIHRo aXMgc3RhbmRhcmQuICBQbGVhc2UgYWRkcmVzcyB0aGUgaW5mb3JtYXRpb24g dG8gdGhlIElFVEYgYXQNCiAgIGlldGYtaXByQGlldGYub3JnLg0KDQoNCkFj a25vd2xlZGdtZW50DQoNCiAgIEZ1bmRpbmcgZm9yIHRoZSBSRkMgRWRpdG9y IGZ1bmN0aW9uIGlzIHByb3ZpZGVkIGJ5IHRoZSBJRVRGDQogICBBZG1pbmlz dHJhdGl2ZSBTdXBwb3J0IEFjdGl2aXR5IChJQVNBKS4NCg0KDQoNCg0KDQpN aWxsZXIgJiBWYWxjaGV2ICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDEzLCAy MDA3ICAgICAgICAgICAgICAgW1BhZ2UgNl0NCgwNCg0K --0-733381464-1181683403=:13880-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Jun 13 09:38:34 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyT3S-0006om-Gw for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 13 Jun 2007 09:38:34 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyT3R-0002PD-8Y for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 13 Jun 2007 09:38:34 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 6036F63B1B8; Wed, 13 Jun 2007 13:38:28 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id 75F8A63B16E for ; Wed, 13 Jun 2007 13:38:27 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.36 #1) with local (return-path bjharris@chiark.greenend.org.uk) id 1HyS1p-0001Su-00; Wed, 13 Jun 2007 13:32:49 +0100 From: Ben Harris To: djm@mindrot.org Subject: Re: draft-miller-secsh-umac-00.txt In-Reply-To: References: Organization: Linux Unlimited Cc: ietf-ssh@NetBSD.org Message-Id: Date: Wed, 13 Jun 2007 13:32:49 +0100 Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.5 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f In article you write: >Attached is a draft for the use of Ted Krovetz' UMAC (RFC4418) as >a SSH MAC. OpenSSH -current implements the umac-64 method described >in the draft under the name "umac-64@openssh.com". > >We'd be interested in hearing from anyone else who wants to implement it. I haven't tried implementing this yet, but I notice one thing that could be simplified. The sequence number in SSH MACs is usually represented as a uint32, and UMAC only requires that the nonce be a string of length 1 to BLOCKLEN bytes, so it seems a little strange to insist on padding the sequence number to 8 bytes. Why not just pass the 4-byte version of the sequence number as the nonce? On a more mundane note, you've forgotten your IANA Considerations. -- Ben Harris From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Jun 13 10:58:28 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyUIm-0005Te-3d for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 13 Jun 2007 10:58:28 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyUIZ-0004rB-M4 for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 13 Jun 2007 10:58:28 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id B95AA63B257; Wed, 13 Jun 2007 14:58:13 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ixion.tartarus.org (ixion.tartarus.org [82.211.108.121]) by mail.netbsd.org (Postfix) with ESMTP id A6FEC63B24A for ; Wed, 13 Jun 2007 14:58:12 +0000 (UTC) Received: from simon by ixion.tartarus.org with local (Exim 3.36 #1 (Debian)) id 1HyTJa-0007ON-00; Wed, 13 Jun 2007 14:55:14 +0100 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@netbsd.org In-Reply-To: Subject: Re: draft-miller-secsh-umac-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: Date: Wed, 13 Jun 2007 14:55:14 +0100 Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Damien Miller wrote: > Attached is a draft for the use of Ted Krovetz' UMAC (RFC4418) as > a SSH MAC. OpenSSH -current implements the umac-64 method described > in the draft under the name "umac-64@openssh.com". Since you don't specify what block cipher is used by your UMAC methods, I presume it's AES-128, since RFC4418 says that's the default if not otherwise explicitly stated. So an obvious question is: is it sensible to mandate a fixed block cipher, when UMAC helpfully provides flexibility in this area? Is that flexibility not potentially an advantage? Have you considered alternative options such as (a) calling it umac-64-aes128 and thereby leaving open an obvious avenue to introduce UMAC over other ciphers if necessary? (b) defining UMAC to use whatever block cipher is chosen by the normal key exchange process? (Though I suppose you'd at the very least have to introduce a special case to preserve MAC functionality when the kex process settles on the `none' cipher.) I think that at the very least I'd be marginally more comfortable if this draft specifically stated that the default AES-128 was in use. I note in passing that UMAC might be less useful than HMAC in crypto-hostile jurisdictions, since you can't implement it without first implementing a block cipher and so literal-minded crypto laws which forbid code which implements a block cipher might also forbid UMAC while being not too unhappy with MDx- or SHA-based HMAC which are only (in practice) used for integrity protection. Not that that should be an argument against its _optional_ adoption, of course. -- Simon Tatham "You may call that a cheap shot. I prefer to think of it as good value." From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Jun 13 15:44:14 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyYlJ-0000WS-1F for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 13 Jun 2007 15:44:14 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyYlG-0001cS-IW for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 13 Jun 2007 15:44:13 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 3CADB63B287; Wed, 13 Jun 2007 19:44:06 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from metalab.unc.edu (mail.metalab.unc.edu [152.46.7.112]) by mail.netbsd.org (Postfix) with ESMTP id 7357A63B1D6 for ; Wed, 13 Jun 2007 19:44:05 +0000 (UTC) Received: from weidaim1 (unknown [152.46.7.122]) by metalab.unc.edu (Postfix) with SMTP id 744624877E; Wed, 13 Jun 2007 13:41:38 -0400 (EDT) Message-ID: <01a601c7ade2$140a9340$0300a8c0@weidai.com> From: "Wei Dai" To: "Damien Miller" , References: Subject: Re: draft-miller-secsh-umac-00.txt Date: Wed, 13 Jun 2007 10:41:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 > Attached is a draft for the use of Ted Krovetz' UMAC (RFC4418) as > a SSH MAC. OpenSSH -current implements the umac-64 method described > in the draft under the name "umac-64@openssh.com". Have you also looked at Ted's new VMAC algorithm? It's still in Internet Draft stage, but it's simpler than UMAC and is also significantly faster on many platforms, especially 64-bit platforms. Public domain implementations are available from http://www.fastcrypto.org/vmac/ and http://www.cryptopp.com. (Disclosure: I contributed several ideas to the current VMAC design and am a co-author of the VMAC draft.) Both UMAC and VMAC require unique nonces. Using the sequence number as the nonce as in your draft may cause nonces to be reused if someone takes a snapshot of an active SSH connection running an a virtual machine, and when that snapshot is restored, the SSH program sends out new packets before realizing that the connection is no longer valid. Unless there is a good reason to believe this can't occur, it would be safer to use random nonces instead. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Jun 13 17:14:04 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyaAG-0000OC-Pi for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 13 Jun 2007 17:14:04 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyaAF-0000wg-Hd for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 13 Jun 2007 17:14:04 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 70F8263B284; Wed, 13 Jun 2007 21:13:58 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id A5E6863B345 for ; Wed, 13 Jun 2007 21:13:48 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.36 #1) with local (return-path bjharris@chiark.greenend.org.uk) id 1HyaA0-00052a-00; Wed, 13 Jun 2007 22:13:48 +0100 From: Ben Harris To: anakin@pobox.com Subject: Re: draft-miller-secsh-umac-00.txt In-Reply-To: References: Organization: Linux Unlimited Cc: ietf-ssh@NetBSD.org Message-Id: Date: Wed, 13 Jun 2007 22:13:48 +0100 Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.5 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 [This time _with_ the mailing list] In article you write: > (b) defining UMAC to use whatever block cipher is chosen by the > normal key exchange process? (Though I suppose you'd at the > very least have to introduce a special case to preserve MAC > functionality when the kex process settles on the `none' > cipher.) Please, no! I suppose there might be some small gain from this, but nothing like enough to outweigh the horribleness of the idea. >I think that at the very least I'd be marginally more comfortable if >this draft specifically stated that the default AES-128 was in use. That might be nice, but I think RFC 4418 is clear enough that AES-128 is implied. -- Ben Harris From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Jun 13 17:30:29 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyaQ9-0007Kc-7m for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 13 Jun 2007 17:30:29 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyaQ7-0005as-UI for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 13 Jun 2007 17:30:29 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 4579563B2C8; Wed, 13 Jun 2007 21:30:23 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id 65D9963B2C7 for ; Wed, 13 Jun 2007 21:30:22 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.36 #1) with local (return-path bjharris@chiark.greenend.org.uk) id 1HyaQ1-0007G2-00; Wed, 13 Jun 2007 22:30:21 +0100 From: Ben Harris To: weidai@weidai.com Subject: Re: draft-miller-secsh-umac-00.txt In-Reply-To: <01a601c7ade2$140a9340$0300a8c0@weidai.com> References: <01a601c7ade2$140a9340$0300a8c0@weidai.com> Organization: Linux Unlimited Cc: ietf-ssh@NetBSD.org Message-Id: Date: Wed, 13 Jun 2007 22:30:21 +0100 Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.5 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 [Today is a bad day for forgetting to Cc the list.] In article <01a601c7ade2$140a9340$0300a8c0@weidai.com> you write: >Both UMAC and VMAC require unique nonces. Using the sequence number as the >nonce as in your draft may cause nonces to be reused if someone takes a >snapshot of an active SSH connection running an a virtual machine, and when >that snapshot is restored, the SSH program sends out new packets before >realizing that the connection is no longer valid. Many of the SSH algorithms break in those circumstances. For instance, any stream cipher (including block ciphers in SDCTR mode) will leak hugely if the keystream gets reused. >Unless there is a good reason to believe this can't occur, it would be safer >to use random nonces instead. Would that help? I'd expect the restored PRNG to at least start in sync with its former self. In general, I think SSH assumes that time is linear, and isn't designed to work in the presence of forking time-streams. This should probably have been mentioned in its Security Considerations. -- Ben Harris From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Jun 13 17:51:26 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyakQ-0006aB-1t for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 13 Jun 2007 17:51:26 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyakO-000247-PQ for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 13 Jun 2007 17:51:26 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id EF98F63B2B2; Wed, 13 Jun 2007 21:51:18 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 8465B63B297 for ; Wed, 13 Jun 2007 21:51:15 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id RAA17900; Wed, 13 Jun 2007 17:51:14 -0400 (EDT) From: der Mouse Message-Id: <200706132151.RAA17900@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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. Date: Wed, 13 Jun 2007 17:47:20 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: draft-miller-secsh-umac-00.txt In-Reply-To: References: <01a601c7ade2$140a9340$0300a8c0@weidai.com> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 >> [...save and restore virtual machine state...] > Many of the SSH algorithms break in those circumstances. For > instance, any stream cipher (including block ciphers in SDCTR mode) > will leak hugely if the keystream gets reused. Only if the datastream isn't. (Perhaps fortunately, the data stream is likely to be identical to the original in such a case...at least long enough for the connection to be torn down.) > In general, I think SSH assumes that time is linear, and isn't > designed to work in the presence of forking time-streams. This > should probably have been mentioned in its Security Considerations. "Security considerations: this program assumes it is operating in a space-time continuum with only one time dimension." :-) /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Jun 13 18:10:23 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyb2l-0001Kw-7l for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 13 Jun 2007 18:10:23 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyb2j-0007Um-T3 for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 13 Jun 2007 18:10:23 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 585D863B2A3; Wed, 13 Jun 2007 22:10:19 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by mail.netbsd.org (Postfix) with ESMTP id 6053E63B24A for ; Wed, 13 Jun 2007 22:10:15 +0000 (UTC) Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5DMAEBY003286 for ; Wed, 13 Jun 2007 22:10:15 GMT Received: from localhost.Central.Sun.COM (dhcp-uaus08-128-213.Central.Sun.COM [129.153.128.213]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l5DMAE4o024236 for ; Wed, 13 Jun 2007 16:10:14 -0600 (MDT) Received: from localhost.Central.Sun.COM (localhost [127.0.0.1]) by localhost.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l5DM9LIk017861; Wed, 13 Jun 2007 17:09:21 -0500 (CDT) Received: (from nw141292@localhost) by localhost.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l5DM9KSl017860; Wed, 13 Jun 2007 17:09:20 -0500 (CDT) X-Authentication-Warning: localhost.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 13 Jun 2007 17:09:20 -0500 From: Nicolas Williams To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: draft-miller-secsh-umac-00.txt Message-ID: <20070613220920.GV16317@Sun.COM> Mail-Followup-To: Nicolas Williams , der Mouse , ietf-ssh@NetBSD.org References: <01a601c7ade2$140a9340$0300a8c0@weidai.com> <200706132151.RAA17900@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200706132151.RAA17900@Sparkle.Rodents.Montreal.QC.CA> User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 On Wed, Jun 13, 2007 at 05:47:20PM -0400, der Mouse wrote: > >> [...save and restore virtual machine state...] > > Many of the SSH algorithms break in those circumstances. For > > instance, any stream cipher (including block ciphers in SDCTR mode) > > will leak hugely if the keystream gets reused. > > Only if the datastream isn't. (Perhaps fortunately, the data stream is > likely to be identical to the original in such a case...at least long > enough for the connection to be torn down.) > > > In general, I think SSH assumes that time is linear, and isn't > > designed to work in the presence of forking time-streams. This > > should probably have been mentioned in its Security Considerations. > > "Security considerations: this program assumes it is operating in a > space-time continuum with only one time dimension." :-) And with time running only in one direction (hereinafter: "forward" ;) I don't think there's a dependence on time being monotonic and non-discrete at a quantum level, just that it not go backward. :) But note that even in a VM save/restore case time goes forward (well, from our p.o.v. anyways. So we may need a more precise description of the problem. I propose that we say that SSHv2 (and probably most cryptographic protocols) is not continuation reentrance safe ('continuation reentrance' meaning, here, calling a Scheme-like continuation function of indefinite extent more than once). Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Jun 13 21:15:52 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HydwG-0007lD-CA for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 13 Jun 2007 21:15:52 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HydwD-0003G0-TI for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 13 Jun 2007 21:15:52 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 0428B63B286; Thu, 14 Jun 2007 01:15:44 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from natsu.mindrot.org (natsu.mindrot.org [203.209.195.154]) by mail.netbsd.org (Postfix) with ESMTP id 80AEB63B1D6 for ; Thu, 14 Jun 2007 01:15:42 +0000 (UTC) Received: by natsu.mindrot.org (Postfix, from userid 1002) id D955269B66; Thu, 14 Jun 2007 11:15:40 +1000 (EST) X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on natsu.mindrot.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from fuyu.mindrot.org (fuyu.mindrot.org [203.217.30.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "fuyu.mindrot.org", Issuer "StartCom Class 1 Primary Intermediate Free CA" (not verified)) by natsu.mindrot.org (Postfix) with ESMTP id BB1F069B44; Thu, 14 Jun 2007 11:15:35 +1000 (EST) Received: by fuyu.mindrot.org (Postfix, from userid 1000) id 0E4763C67C; Thu, 14 Jun 2007 11:15:35 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by fuyu.mindrot.org (Postfix) with ESMTP id 097AA3C67B; Thu, 14 Jun 2007 11:15:35 +1000 (EST) Date: Thu, 14 Jun 2007 11:15:34 +1000 (EST) From: Damien Miller To: Wei Dai cc: ietf-ssh@netbsd.org Subject: Re: draft-miller-secsh-umac-00.txt In-Reply-To: <01a601c7ade2$140a9340$0300a8c0@weidai.com> Message-ID: References: <01a601c7ade2$140a9340$0300a8c0@weidai.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 On Wed, 13 Jun 2007, Wei Dai wrote: > > Attached is a draft for the use of Ted Krovetz' UMAC (RFC4418) as > > a SSH MAC. OpenSSH -current implements the umac-64 method described > > in the draft under the name "umac-64@openssh.com". > > Have you also looked at Ted's new VMAC algorithm? It's still > in Internet Draft stage, but it's simpler than UMAC and is > also significantly faster on many platforms, especially 64-bit > platforms. Public domain implementations are available from > http://www.fastcrypto.org/vmac/ and http://www.cryptopp.com. > (Disclosure: I contributed several ideas to the current VMAC design > and am a co-author of the VMAC draft.) I had noticed it when we first started looking at UMAC, but it seems to have progressed quite a bit since then - thanks for the pointer. > Both UMAC and VMAC require unique nonces. Using the sequence number as > the nonce as in your draft may cause nonces to be reused if someone > takes a snapshot of an active SSH connection running an a virtual > machine, and when that snapshot is restored, the SSH program sends out > new packets before realizing that the connection is no longer valid. > > Unless there is a good reason to believe this can't occur, it would be > safer to use random nonces instead. I don't think that this is a very likely attack for the SSH protocol. The attacker would need: 1. The ability to snapshot the SSH sender and resume it at will. 2. The ability to inject different data into the SSH sender once it has resumed, so that MAC nonces are reused with different data. 3. The ability to circumvent the symmetric crypto in SSH. If all these came together, *and* the attacker was able to completely break UMAC with the resulting data, then they could spoof the remote end back to the local sender. The attacker would need to be able to do this before the remote end gave up and, unless they are prepared to spoof TCP at the sender, would get <= 1 TCP window of data from the SSH sender to work with. Such a scenario doesn't seem very likely: apart from needing to cirvumvent the symmetric crypto in order to make the MAC match the decrypted packet, the ability to snapshot and resume a VM is very likely to imply access to the memory contents of the SSH sender, from which they could read the MAC keys out directly. If the attacker doesn't have any magic way around the symmetric crypto, then they would have to guess, using their captive VM'd process as an oracle. The smallest useful packet they could guess at would be a SSH_MSG_CHANNEL_DATA packet: packet_len | padding_len | type | channel_id | data_len | data | padding u32 u8 u8 u32 u32 The smallest such packet would be for a single byte of channel data, so the overall padded length would be 16 bytes, of which 1 byte would be padding. Even if we assume that the attacker's success criteria is injection of *any* data into an open channel, then the only non-critical fields in the packet are the data and the padding (2 bytes). If they got packet_len, padding_len, type, or data_len wrong, then the packet would not parse successfully. If they got channel_id wrong, then the implementation would either disconnect or ignore the data, and most sessions would have only a small number of channels open (OpenSSH's default limit is 10). So there would be only around 2^16 correct guesses in a space of 2^128. On the other hand, using random nonces has two downsides: first, they would either need to be added to the packet (overhead) or generated by some agreed PRF (more protocol complexity). Secondly, UMAC performs best when the nonces are monotonically increasing counters and so using a per-packet random nonce would slow it down. -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Jun 17 19:50:23 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I04Vj-0004eq-5c for secsh-tyoxbijeg7-archive@lists.ietf.org; Sun, 17 Jun 2007 19:50:23 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I04Vh-0002Qf-Ry for secsh-tyoxbijeg7-archive@lists.ietf.org; Sun, 17 Jun 2007 19:50:23 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id C117863B1E2; Sun, 17 Jun 2007 23:50:15 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from natsu.mindrot.org (natsu.mindrot.org [203.209.195.154]) by mail.netbsd.org (Postfix) with ESMTP id B84E963B1D2 for ; Sun, 17 Jun 2007 23:50:14 +0000 (UTC) Received: by natsu.mindrot.org (Postfix, from userid 1002) id A26E869B24; Mon, 18 Jun 2007 09:50:12 +1000 (EST) X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on natsu.mindrot.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from fuyu.mindrot.org (fuyu.mindrot.org [203.217.30.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "fuyu.mindrot.org", Issuer "StartCom Class 1 Primary Intermediate Free CA" (not verified)) by natsu.mindrot.org (Postfix) with ESMTP id 51F6069AF8; Mon, 18 Jun 2007 09:50:10 +1000 (EST) Received: by fuyu.mindrot.org (Postfix, from userid 1000) id AF5343C67C; Mon, 18 Jun 2007 09:50:09 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by fuyu.mindrot.org (Postfix) with ESMTP id AAAA83C67B; Mon, 18 Jun 2007 09:50:09 +1000 (EST) Date: Mon, 18 Jun 2007 09:50:09 +1000 (EST) From: Damien Miller To: Wei Dai cc: ietf-ssh@netbsd.org Subject: Re: draft-miller-secsh-umac-00.txt In-Reply-To: Message-ID: References: <01a601c7ade2$140a9340$0300a8c0@weidai.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a On Thu, 14 Jun 2007, Damien Miller wrote: > On Wed, 13 Jun 2007, Wei Dai wrote: > > > Both UMAC and VMAC require unique nonces. Using the sequence number > > as the nonce as in your draft may cause nonces to be reused if > > someone takes a snapshot of an active SSH connection running an a > > virtual machine, and when that snapshot is restored, the SSH program > > sends out new packets before realizing that the connection is no > > longer valid. > > > > Unless there is a good reason to believe this can't occur, it would > > be safer to use random nonces instead. Markus Friedl suggested a good compromise: use the KEX PRF to extract 192 bits of MAC key, give the first 128 to UMAC and use the remaining 64 bits as a "nonce seed". The nonce that is supplied to UMAC can be nonce_seed + sequence_number. The seed would be private like the other keying material and, while the nonces would still be reused under this attack, the actual nonce values would be not be known to the attacker. This tweak does not need any new PRF, and it preserves UMACs optimisation when the nonce is a monotonic big endian counter. Thoughts? -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Jun 18 09:23:32 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0HCe-0000z3-8X for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 18 Jun 2007 09:23:32 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0HCc-0002wp-Vm for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 18 Jun 2007 09:23:32 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 266CA63B192; Mon, 18 Jun 2007 13:23:05 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id 154AF63B18C for ; Mon, 18 Jun 2007 13:23:03 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.36 #1) with local (return-path bjharris@chiark.greenend.org.uk) id 1I0HCA-0001Sz-00; Mon, 18 Jun 2007 14:23:02 +0100 From: Ben Harris To: djm@mindrot.org Subject: Re: draft-miller-secsh-umac-00.txt In-Reply-To: References: Organization: Linux Unlimited Cc: ietf-ssh@NetBSD.org Message-Id: Date: Mon, 18 Jun 2007 14:23:02 +0100 Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.5 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 In article you write: >On Thu, 14 Jun 2007, Damien Miller wrote: > >> On Wed, 13 Jun 2007, Wei Dai wrote: >> >> > Both UMAC and VMAC require unique nonces. Using the sequence number >> > as the nonce as in your draft may cause nonces to be reused if >> > someone takes a snapshot of an active SSH connection running an a >> > virtual machine, and when that snapshot is restored, the SSH program >> > sends out new packets before realizing that the connection is no >> > longer valid. >> > >> > Unless there is a good reason to believe this can't occur, it would >> > be safer to use random nonces instead. > >Markus Friedl suggested a good compromise: use the KEX PRF to extract >192 bits of MAC key, give the first 128 to UMAC and use the remaining 64 >bits as a "nonce seed". > >The nonce that is supplied to UMAC can be nonce_seed + sequence_number. >The seed would be private like the other keying material and, while the >nonces would still be reused under this attack, the actual nonce values >would be not be known to the attacker. Does that help? RFC 4418 certainly doesn't suggest that it does -- it says that repeated nonces break the security guarantee, with no suggestion that the secrecy or otherwise of the nonce makes a difference. In any case, isn't 64 bits too short to be a useful secret? -- Ben Harris From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Jun 22 08:53:03 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1idL-00058z-PO for secsh-tyoxbijeg7-archive@lists.ietf.org; Fri, 22 Jun 2007 08:53:03 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1idK-0005US-Fo for secsh-tyoxbijeg7-archive@lists.ietf.org; Fri, 22 Jun 2007 08:53:03 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 7028463B115; Fri, 22 Jun 2007 12:52:55 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from ppsw-4.csi.cam.ac.uk (ppsw-4.csi.cam.ac.uk [131.111.8.134]) by mail.netbsd.org (Postfix) with ESMTP id AB85663B118 for ; Fri, 22 Jun 2007 12:52:54 +0000 (UTC) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from smaug.linux.pwf.cam.ac.uk ([193.60.95.72]:56335) by ppsw-4.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.134]:25) with esmtp id 1I1hbP-0005Xu-E8 (Exim 4.63) for ietf-ssh@NetBSD.org (return-path ); Fri, 22 Jun 2007 12:46:59 +0100 Received: from bjh21 (helo=localhost) by smaug.linux.pwf.cam.ac.uk with local-esmtp (Exim 4.22) id 1I1hbP-0005oP-9Y for ietf-ssh@NetBSD.org; Fri, 22 Jun 2007 12:46:59 +0100 Date: Fri, 22 Jun 2007 12:46:59 +0100 (BST) From: Ben Harris To: ietf-ssh@NetBSD.org Subject: draft-bjh21-ssh-transport-extension-02 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 1.6 (+) X-Scan-Signature: 08e48e05374109708c00c6208b534009 I've uploaded a new version of transport-extension. It's mostly the same as the last one, and I plan to send it to the IESG soon, so now is your penultimate chance to comment on it. -- Ben Harris From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Jun 23 03:41:53 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I20Fl-0003Rj-Sq for secsh-tyoxbijeg7-archive@lists.ietf.org; Sat, 23 Jun 2007 03:41:53 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I20Fk-0005xg-G0 for secsh-tyoxbijeg7-archive@lists.ietf.org; Sat, 23 Jun 2007 03:41:53 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 74AB463B232; Sat, 23 Jun 2007 07:41:46 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 1F64A63B123 for ; Sat, 23 Jun 2007 07:41:40 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id DAA27040; Sat, 23 Jun 2007 03:41:39 -0400 (EDT) From: der Mouse Message-Id: <200706230741.DAA27040@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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. Date: Sat, 23 Jun 2007 03:39:13 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: draft-bjh21-ssh-transport-extension-02 In-Reply-To: References: Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.1 (+) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad > I've uploaded a new version of transport-extension. It's mostly the > same as the last one, and I plan to send it to the IESG soon, so now > is your penultimate chance to comment on it. This (draft-bjh21-ssh-transport-extension-02.txt) looks good to me; modulo possible problems like typos in RFC numbers (I haven't checked that kind of detail), I support this in its current form. (Not that I really expect anyone to care whether I support it. :-) /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B