From Pasi.Eronen@nokia.com Thu Oct 1 08:32:10 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 865943A6974; Thu, 1 Oct 2009 08:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.46 X-Spam-Level: X-Spam-Status: No, score=-6.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnREWR5yop6T; Thu, 1 Oct 2009 08:32:09 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 62E203A6853; Thu, 1 Oct 2009 08:32:09 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n91FW5EH010610; Thu, 1 Oct 2009 10:32:41 -0500 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Oct 2009 18:33:27 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Oct 2009 18:33:22 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Thu, 1 Oct 2009 17:33:22 +0200 From: To: , Date: Thu, 1 Oct 2009 17:33:21 +0200 Thread-Topic: Pasi's AD Notes for September 2009 Thread-Index: AcpCrIHz8bpAJvzbR4+2Umq6pFXwIw== Message-ID: <808FD6E27AD4884E94820BC333B2DB773C098395C0@NOK-EUMSG-01.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 01 Oct 2009 15:33:22.0747 (UTC) FILETIME=[82AA08B0:01CA42AC] X-Nokia-AV: Clean Subject: [saag] Pasi's AD Notes for September 2009 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 15:32:10 -0000 Here's again a short status update about what things are going on from my point-of-view. If you notice anything that doesn't look right, let me know -- miscommunication and mix-ups do happen. Best regards, Pasi MISC NOTES - Sent a liaison statement reply to ITU-T regarding identity=20 management. - Informed NomCom that I'm not running for a second term (see http://www.ietf.org/mail-archive/web/secdir/current/msg00994.html) - Reviewed ROHCoIPsec drafts again for IETF last call. - (not wearing AD hat): Errata #1628 (for RFC 4742): IANA has now =20 fixed the registry and Dan verified the errata.=20 - Tools work: test suite improvements, Django 1.x transition, tools authentication model, IESG agenda-related tools, etc. - Requested room/slot for SAAG and SecDir lunch at IETF76. - Some discussions about SIDR algorithm agility. WORKING GROUPS DKIM - Waiting for Stephen and Barry for new charter text (noting that=20 current work items are completed and adding 4871bis) - I still need to review what to do about errata 1385, 1532, and 1596 - Talked about the mailing list with Tim/chairs/Dave; decided to keep the current list (and not move it to ietf.org) for the time being, since it's DKIM-signing the emails (and=20 EMU IPSECME - A virtual interim meeting was held on 2009-09-22. - Still working on fixing the IANA registrations of RFC 4543;=20 currently waiting for IANA [since 2009-07-31; pinged several times since then] - draft-ietf-ipsecme-ikev2-resumption: went through IETF last call;=20 now in IESG evaluation and on agenda of the 2009-10-08 telechat. - draft-ietf-ipsecme-ikev2-redirect (not wearing AD hat; Tim is=20 handling this one): was approved by IESG, now in RFC editor queue. - draft-ietf-ipsecme-traffic-visibility: waiting for the WG to=20 discuss my AD evaluation comments and eventually submit a revised ID [since 2009-09-17] (there are also some emails I haven't read yet, and may need to reply to) - draft-ietf-ipsecme-ikev2-ipv6-config (not wearing AD hat): went through IETF last call; on agenda of the 2009-10-08 telechat. - draft-kanno-ipsecme-camellia-xcbc (not WG item): the authors have asked if I would sponsor this as individual submission; currently waiting for me to take a look and reply [since 2009-09-29] ISMS - Some emails I haven't read yet... KEYPROV - Some emails I haven't read yet... PKIX - draft-ietf-pkix-sha2-dsa-ecdsa: in IETF last call until 2009-10-05. - draft-ietf-pkix-rfc4055-update: in RFC Editor queue, waiting for draft-ietf-pkix-sha2-dsa-ecdsa. SASL - draft-ietf-sasl-scram: went through IETF Last Call; waiting for me to read all the emails and figure out next steps [since 2009-09-28] - (not WG item) draft-melnikov-sasl-scram-ldap: I am sponsoring this=20 as individual submission; currently in IETF last call until 2009-10-26. - (not WG item) draft-altman-tls-channel-bindings: I've promised to sponsor this as individual submission; currently waiting for=20 Nico to prepare the write-up before starting IETF Last Call=20 [since 2009-08-31] SYSLOG - Rechartering was approved by IESG. - draft-ietf-syslog-sign: went through IETF last call; waiting for the authors to reply to last call comments and submit a revised ID [since 2009-09-17] TLS - draft-ietf-tls-rfc4366-bis: went through IETF last call; waiting for Donald to reply to the last call comments and submit a=20 revised ID [since 2009-09-09] - Looking into errata #117 (for RFC 4346) - (not WG item) see SASL WG for draft-altman-tls-channel-bindings - draft-ietf-tls-extractor: was approved by IESG; now in RFC editor queue.=20 OTHER DOCUMENTS DISCUSSES (active -- something happened within last month) - draft-cain-post-inch-phishingextns: waiting for authors to submit a revised ID [since 2009-09-04] - draft-harkins-emu-eap-pwd: waiting for authors to reply to my comments [since 2009-09-25] - draft-housley-tls-authz-extns: waiting for authors to submit a revised ID [since 2009-09-22] - draft-solinas-rfc4753bis: waiting for authors to reply to my comments [since 2009-09-24] DISCUSSES (stalled -- I haven't heard anything from the authors or document shepherd for over one month) - draft-freed-sieve-in-xml: waiting for authors to propose changes or submit a revised ID [since 2009-08-13] - draft-ietf-netconf-partial-lock: waiting for authors to=20 propose text or submit a revised ID [since 2009-08-13] - draft-ietf-ntp-autokey: waiting for Ralph to get more information from WG [since 2009-08-20] - draft-ietf-vrrp-unified-spec: waiting for authors to propose text [since 2008-07-26] DISCUSSES (presumed dead -- I haven't heard anything from the authors or document shepherd for over three months) - draft-cheshire-dnsext-nbp: waiting for authors to reply to my comments [since 2008-12-03] (pinged again on 2009-04-30 and 2009-06-09) - draft-ietf-bfd-base: text agreed, waiting for authors to submit=20 a revised ID [since 2009-03-19] (pinged again on 2009-04-30 and 2009-06-09) - draft-ietf-dime-diameter-api: waiting for Dan to get WG's opinion=20 on whether this will be useful and if yes, why [since 2009-06-18] - draft-ietf-ntp-ntpv4-proto: waiting for authors to reply to my email or submit a revised ID [since 2009-04-16] - draft-ietf-sipping-policy-package: waiting for draft-ietf-sipping- media-policy-dataset to progress (or more information from Robert) [since 2008-10-28] --end-- From Pasi.Eronen@nokia.com Mon Oct 5 23:49:16 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45D763A679F for ; Mon, 5 Oct 2009 23:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.465 X-Spam-Level: X-Spam-Status: No, score=-6.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t5iZcC2PTuqR for ; Mon, 5 Oct 2009 23:49:15 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 837EC3A6860 for ; Mon, 5 Oct 2009 23:49:15 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n966oJPa008389 for ; Tue, 6 Oct 2009 01:50:51 -0500 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Oct 2009 09:50:26 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Oct 2009 09:50:21 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Oct 2009 09:50:16 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Tue, 6 Oct 2009 08:50:14 +0200 From: To: Date: Tue, 6 Oct 2009 08:50:13 +0200 Thread-Topic: Request for SAAG agenda items Thread-Index: AcpGUUEcQdHHF/HuS+Wz0izb5JQVyg== Message-ID: <808FD6E27AD4884E94820BC333B2DB773C098E467E@NOK-EUMSG-01.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 06 Oct 2009 06:50:16.0653 (UTC) FILETIME=[4328E7D0:01CA4651] X-Nokia-AV: Clean Subject: [saag] Request for SAAG agenda items X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 06:49:16 -0000 Folks, Tim and I are working on the agenda for SAAG at IETF76. =20 We would appreciate any suggestions! Thanks, Pasi From John.Border@hughes.com Thu Oct 15 12:57:00 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28D613A69FC for ; Thu, 15 Oct 2009 12:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.108 X-Spam-Level: X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSpps3dVz8Uo for ; Thu, 15 Oct 2009 12:56:57 -0700 (PDT) Received: from hnse2.hns.com (hnse2.hns.com [208.236.67.201]) by core3.amsl.com (Postfix) with ESMTP id B1FD13A68ED for ; Thu, 15 Oct 2009 12:56:57 -0700 (PDT) Received: from mail.hughes.com (expexchub.hughes.com [139.85.54.35]) by hnse2.hns.com (Switch-3.3.3/Switch-3.3.1) with ESMTP id n9FJuafC010067 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Thu, 15 Oct 2009 15:56:59 -0400 (EDT) Received: from EXPEXCVS1.hughes.com ([139.85.54.30]) by expexchub2.hughes.com ([139.85.54.35]) with mapi; Thu, 15 Oct 2009 15:56:51 -0400 From: John Border To: "saag@ietf.org" Date: Thu, 15 Oct 2009 15:56:54 -0400 Thread-Topic: A question about AES properties... Thread-Index: AcpN0aUWScNt4j0eQYyHP3z7De61iA== Message-ID: <982B8F9A4E5BDC4B89FF7586464DD2190184D042032B@EXPEXCVS1.hughes.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_982B8F9A4E5BDC4B89FF7586464DD2190184D042032BEXPEXCVS1hu_" MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 19 Oct 2009 00:42:43 -0700 Cc: John Border Subject: [saag] A question about AES properties... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 19:57:00 -0000 --_000_982B8F9A4E5BDC4B89FF7586464DD2190184D042032BEXPEXCVS1hu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have what I thought was a simple question about the properties of AES= . But, I have not been able to find an answer. Possibly that means the qu= estion itself is flawed (but I haven't been able to figure that out either)= ... With AES, does the order of the functions matter, i.e. does EK(DK(P)) = =3D DK(EK(P))? John Border --_000_982B8F9A4E5BDC4B89FF7586464DD2190184D042032BEXPEXCVS1hu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

    I have what I thought was a simple question about the properties of AES.  But, I have not been able to fi= nd an answer.  Possibly that means the question itself is flawed (but I h= aven’t been able to figure that out either)…

 

   With AES, does the order of the functions matter, i.e. does EK(DK(P)) =3D DK(EK= (P))?

 

 

 

John Border

 

 

--_000_982B8F9A4E5BDC4B89FF7586464DD2190184D042032BEXPEXCVS1hu_-- From raeburn@MIT.EDU Mon Oct 19 09:51:51 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66F853A6954 for ; Mon, 19 Oct 2009 09:51:51 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MEkHYGivxnFJ for ; Mon, 19 Oct 2009 09:51:50 -0700 (PDT) Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by core3.amsl.com (Postfix) with ESMTP id 8984A3A6853 for ; Mon, 19 Oct 2009 09:51:50 -0700 (PDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id n9JGpide002281; Mon, 19 Oct 2009 12:51:44 -0400 (EDT) Received: from [10.0.0.158] ([76.119.237.235]) (authenticated bits=0) (User authenticated as raeburn@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id n9JGppIV024994 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 19 Oct 2009 12:51:52 -0400 (EDT) From: Ken Raeburn To: John Border In-Reply-To: <982B8F9A4E5BDC4B89FF7586464DD2190184D042032B@EXPEXCVS1.hughes.com> References: <982B8F9A4E5BDC4B89FF7586464DD2190184D042032B@EXPEXCVS1.hughes.com> Message-Id: <53A72A85-26F8-4AB3-A8E5-B0EBEC53961E@mit.edu> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 19 Oct 2009 12:51:49 -0400 X-Mailer: Apple Mail (2.936) X-Scanned-By: MIMEDefang 2.42 Cc: "saag@ietf.org" Subject: Re: [saag] A question about AES properties... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 16:51:51 -0000 On Oct 15, 2009, at 15:56, John Border wrote: > I have what I thought was a simple question about the properties =20= > of AES. But, I have not been able to find an answer. Possibly that =20= > means the question itself is flawed (but I haven=92t been able to =20 > figure that out either)=85 > > With AES, does the order of the functions matter, i.e. does =20 > EK(DK(P)) =3D DK(EK(P))? AES block encryption with a specific key is a permutation of 2^128 =20 values -- a bijection from the set to itself. Decryption with the =20 same key is just the inverse of that permutation. Both E(D(P)) and =20 D(E(P)) perform some permutation and then reverse it, giving you back =20= the starting value. The same argument applies to block cipher modes of encryption that =20 operate on multiple blocks, in cases that don't do any message =20 expansion. They're still reversible permutations, just over larger =20 sets. But, for example, if your encryption mode is "CBC encryption =20 with padding", and P isn't a multiple of the block size, then D(E(P)) =20= =3D P' where P' has padding added, and E(D(P)) just doesn't work because = =20 D requires its input to be a multiple of the block size. Ken= From bcn@ISI.EDU Mon Oct 19 13:51:04 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F15753A698B for ; Mon, 19 Oct 2009 13:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lghTajsFiT0g for ; Mon, 19 Oct 2009 13:51:04 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 4533A3A692E for ; Mon, 19 Oct 2009 13:51:04 -0700 (PDT) Received: from webmail.isi.edu (webmail.isi.edu [128.9.152.28]) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id n9JKncs1029300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 19 Oct 2009 13:49:39 -0700 (PDT) Received: (from apache@localhost) by webmail.isi.edu (8.12.8/8.12.7) id n9JKnbfU011500; Mon, 19 Oct 2009 13:49:37 -0700 X-Authentication-Warning: webmail.isi.edu: apache set sender to bcn@isi.edu using -f Received: from cayman-islands.isi.edu (cayman-islands.isi.edu [128.9.160.140]) by webmail.isi.edu (IMP) with HTTP for ; Mon, 19 Oct 2009 13:49:37 -0700 Message-ID: <1255985377.4adcd0e19f8af@webmail.isi.edu> Date: Mon, 19 Oct 2009 13:49:37 -0700 From: bcn@ISI.EDU To: Ken Raeburn References: <982B8F9A4E5BDC4B89FF7586464DD2190184D042032B@EXPEXCVS1.hughes.com> <53A72A85-26F8-4AB3-A8E5-B0EBEC53961E@mit.edu> In-Reply-To: <53A72A85-26F8-4AB3-A8E5-B0EBEC53961E@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.2 X-Originating-IP: 128.9.160.140 X-MailScanner-ID: n9JKncs1029300 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: bcn@isi.edu Cc: John Border , "saag@ietf.org" Subject: Re: [saag] A question about AES properties... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 20:51:05 -0000 Quoting Ken Raeburn : > On Oct 15, 2009, at 15:56, John Border wrote: > > I have what I thought was a simple question about the properties > > of AES. But, I have not been able to find an answer. Possibly that > > means the question itself is flawed (but I haven’t been able to > > figure that out either)… > > > > With AES, does the order of the functions matter, i.e. does > > EK(DK(P)) = DK(EK(P))? > As Ken responded, if the plaintext is a multiple of the block size, because EK and DK are inverses, the result is the identity function, so the answer to the above is that the order does not make a difference. BUT, I expect what you might have been trying to ask is whether EK1(DK2(P)) = DK2(EK1(P)), i.e. your question above, but using two different keys. In this case, the analyses is not as simple, and I would guess that the answer is that no they are not the same. But I could be wrong. You should be able to verify the "NO" answer with a simple experiment. Clifford Neuman From dbernard@ozonline.com.au Wed Oct 21 14:41:47 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0825D3A68C2 for ; Wed, 21 Oct 2009 14:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.259 X-Spam-Level: * X-Spam-Status: No, score=1.259 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_05=-1.11, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_51=0.6, RELAY_IS_203=0.994, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9+tEIjgaQn5 for ; Wed, 21 Oct 2009 14:41:46 -0700 (PDT) Received: from smtp.ozonline.com.au (smtp.ozonline.com.au [203.4.248.46]) by core3.amsl.com (Postfix) with ESMTP id 69F283A685E for ; Wed, 21 Oct 2009 14:41:45 -0700 (PDT) Received: from DanielPC (adsl-syd-4-240.ozonline.com.au [210.4.231.240]) by smtp.ozonline.com.au (8.13.7/8.13.7) with SMTP id n9LLfnD7006744 for ; Thu, 22 Oct 2009 08:41:52 +1100 Message-ID: <6170EA1191E548A7A712B0D5002D85D5@DanielPC> From: "DB" To: References: In-Reply-To: Date: Thu, 22 Oct 2009 08:41:29 +1100 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 Windows Mail 6.0.6000.16480 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669 Subject: [saag] for your comments Internet draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 21:41:47 -0000 I dont know how this works, but could this be included in your next agenda? I need your inputs and comments, http://tools.ietf.org/html/draft-d-sec-udt-00 ----- Original Message ----- From: To: Sent: Wednesday, October 21, 2009 6:00 AM Subject: saag Digest, Vol 16, Issue 4 > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to > > https://www.ietf.org/mailman/listinfo/saag > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. > > > > Send saag mailing list submissions to > saag@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/saag > or, via email, send a message with subject or body 'help' to > saag-request@ietf.org > > You can reach the person managing the list at > saag-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of saag digest..." > > > Today's Topics: > > 1. Re: A question about AES properties... (bcn@ISI.EDU) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 19 Oct 2009 13:49:37 -0700 > From: bcn@ISI.EDU > Subject: Re: [saag] A question about AES properties... > To: Ken Raeburn > Cc: John Border , "saag@ietf.org" > > Message-ID: <1255985377.4adcd0e19f8af@webmail.isi.edu> > Content-Type: text/plain; charset=ISO-8859-1 > > Quoting Ken Raeburn : > >> On Oct 15, 2009, at 15:56, John Border wrote: >> > I have what I thought was a simple question about the properties >> > of AES. But, I have not been able to find an answer. Possibly that >> > means the question itself is flawed (but I haven?t been able to >> > figure that out either)? >> > >> > With AES, does the order of the functions matter, i.e. does >> > EK(DK(P)) = DK(EK(P))? >> > > As Ken responded, if the plaintext is a multiple of the block size, > because EK > and DK are inverses, the result is the identity function, so the answer to > the > above is that the order does not make a difference. > > BUT, I expect what you might have been trying to ask is whether > EK1(DK2(P)) = > DK2(EK1(P)), i.e. your question above, but using two different keys. In > this > case, the analyses is not as simple, and I would guess that the answer is > that > no they are not the same. But I could be wrong. You should be able to > verify > the "NO" answer with a simple experiment. > > Clifford Neuman > > > ------------------------------ > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > > End of saag Digest, Vol 16, Issue 4 > *********************************** > > _____________________________________________________ > This mail has been virus scanned by Australia On Line > see http://www.australiaonline.net.au/mailscanning > From Nicolas.Williams@sun.com Wed Oct 21 14:56:23 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA00D3A6A19 for ; Wed, 21 Oct 2009 14:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.693 X-Spam-Level: X-Spam-Status: No, score=-5.693 tagged_above=-999 required=5 tests=[AWL=0.353, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzXWSctARGyW for ; Wed, 21 Oct 2009 14:56:23 -0700 (PDT) Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by core3.amsl.com (Postfix) with ESMTP id EB03D3A6A18 for ; Wed, 21 Oct 2009 14:56:22 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n9LLuTuJ026134 for ; Wed, 21 Oct 2009 21:56:29 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n9LLuTec051977 for ; Wed, 21 Oct 2009 15:56:29 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n9LLj6IR005511; Wed, 21 Oct 2009 16:45:06 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n9LLj6eS005510; Wed, 21 Oct 2009 16:45:06 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 21 Oct 2009 16:45:06 -0500 From: Nicolas Williams To: DB Message-ID: <20091021214505.GX892@Sun.COM> References: <6170EA1191E548A7A712B0D5002D85D5@DanielPC> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6170EA1191E548A7A712B0D5002D85D5@DanielPC> User-Agent: Mutt/1.5.7i Cc: saag@ietf.org Subject: Re: [saag] for your comments Internet draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 21:56:23 -0000 On Thu, Oct 22, 2009 at 08:41:29AM +1100, DB wrote: > I dont know how this works, but could this be included in your next agenda? > I need your inputs and comments, > > http://tools.ietf.org/html/draft-d-sec-udt-00 UDT itself belongs in the Transport Area, either in TSVWG or in a new WG or as an individual submission. UDT security docs probably belong there as well, but should be reviewed by the security area. Now, from the looks of your document, it's early enough that you're really just asking for advice on how to add end-to-end security to UDT. SAAG is the right place to seek such advice. This mailing list is good enough to start, but if you want you can ask for time to make a short presentation on UDT at the Hiroshima meeting (in which case it's the Security Area Directors who would be giving you a time slot). Nico -- From Nicolas.Williams@sun.com Thu Oct 22 14:21:14 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 617C53A680F for ; Thu, 22 Oct 2009 14:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.787 X-Spam-Level: X-Spam-Status: No, score=-5.787 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lTfFJMlRfBbw for ; Thu, 22 Oct 2009 14:21:13 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id 683D43A67C0 for ; Thu, 22 Oct 2009 14:21:05 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n9MLLFqL013278 for ; Thu, 22 Oct 2009 21:21:15 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n9MLLEEJ051725 for ; Thu, 22 Oct 2009 15:21:15 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n9ML9owe006416; Thu, 22 Oct 2009 16:09:50 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n9ML9oNd006415; Thu, 22 Oct 2009 16:09:50 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 22 Oct 2009 16:09:50 -0500 From: Nicolas Williams To: DB Message-ID: <20091022210949.GE892@Sun.COM> References: <6170EA1191E548A7A712B0D5002D85D5@DanielPC> <20091021214505.GX892@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091021214505.GX892@Sun.COM> User-Agent: Mutt/1.5.7i Cc: saag@ietf.org Subject: Re: [saag] for your comments Internet draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 21:21:14 -0000 On Wed, Oct 21, 2009 at 04:45:06PM -0500, Nicolas Williams wrote: > Now, from the looks of your document, it's early enough that you're > really just asking for advice on how to add end-to-end security to UDT. > SAAG is the right place to seek such advice. This mailing list is good > enough to start, ... I see three options for authentication and end-to-end security: a) GSS-API b) DTLS c) IPsec d) SASL/GSS-API for authentication + channel binding to DTLS, DTLS for data integrity/confidentiality protection e) SASL/GSS-API for authentication + channel binding to IPsec, IPsec for data integrity/confidentiality protection (a) is probably the easiest to implement, followed closely by (b), for the simple reason that these are easy to use and there exist multiple implementations. DTLS is newer, and TLS has lots of options, so it's probably a bit harder to use than the GSS-API. (The GSS-API is a rather large API, but for applications like this one, one need only use a small subset of that API. Don't let the size of the API intimidate you.) (c) is very hard to use. Right now you can't really drive the use of IPsec from applications, which means that you'd have to rely on the sender and receiver to be configured properly. That won't work for Internet-scale deployments. BTNS WG work on IPsec APIs would help, but it will be a long time before those are widely available. In other words, (c) is not a very realistic option. (OTOH, if you have a no-security option for UDT, then (c) can be done by the sysadmin if they want, without even having to tell the UDT app.) (d) is only useful if you're interested in the sum of user/host authentication options available with SASL, GSS-API and DTLS. It's worth considering, though mostly because of the very unfortunate reality that authentication mechanisms are not equally available in all these authentication frameworks :( (e) is like (d), but using IPsec; see (c) for why (e) not a realistic option. Of these I'd say the best choice is to do (a), (b) and leave room for adding (d) later. The protocol would look roughly like: - First authenticate (exchange opaque GSS context / DTLS handshake messages until authenticated) (for (d) you'd do both... we can discuss that later). - Then use per-message token functions (GSS-API) or DTLS record layer (DTLS) to protect UDT messages. Interleaving could be an issue. You might need a separate security context per-channel. Nico -- From dbernard@ozonline.com.au Fri Oct 23 23:46:29 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C7DD28C124 for ; Fri, 23 Oct 2009 23:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.082 X-Spam-Level: X-Spam-Status: No, score=-0.082 tagged_above=-999 required=5 tests=[AWL=0.818, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVWyVMAeE7AT for ; Fri, 23 Oct 2009 23:46:28 -0700 (PDT) Received: from smtp.ozonline.com.au (smtp.ozonline.com.au [203.4.248.46]) by core3.amsl.com (Postfix) with ESMTP id CBE373A68BF for ; Fri, 23 Oct 2009 23:46:27 -0700 (PDT) Received: from DanielPC (adsl-syd-4-181.ozonline.com.au [210.4.231.181]) by smtp.ozonline.com.au (8.13.7/8.13.7) with SMTP id n9O6kVrO013987 for ; Sat, 24 Oct 2009 17:46:33 +1100 Message-ID: From: "DB" To: References: In-Reply-To: Date: Sat, 24 Oct 2009 17:45:56 +1100 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 Windows Mail 6.0.6000.16480 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669 Subject: Re: [saag] Contents of saag digest..."> 1. Re: for your comments Internet draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Oct 2009 06:46:29 -0000 > Today's Topics: > > 1. Re: for your comments Internet draft (Nicolas Williams) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 22 Oct 2009 16:09:50 -0500 > From: Nicolas Williams > Subject: Re: [saag] for your comments Internet draft > To: DB > Cc: saag@ietf.org > Message-ID: <20091022210949.GE892@Sun.COM> > Content-Type: text/plain; charset=us-ascii > > On Wed, Oct 21, 2009 at 04:45:06PM -0500, Nicolas Williams wrote: >> Now, from the looks of your document, it's early enough that you're >> really just asking for advice on how to add end-to-end security to UDT. >> SAAG is the right place to seek such advice. This mailing list is good >> enough to start, ... > > I see three options for authentication and end-to-end security: > > a) GSS-API > b) DTLS > c) IPsec > > d) SASL/GSS-API for authentication + channel binding to DTLS, DTLS for > data integrity/confidentiality protection > > e) SASL/GSS-API for authentication + channel binding to IPsec, IPsec for > data integrity/confidentiality protection > > (a) is probably the easiest to implement, followed closely by (b), for > the simple reason that these are easy to use and there exist multiple > implementations. DTLS is newer, and TLS has lots of options, so it's > probably a bit harder to use than the GSS-API. > > (The GSS-API is a rather large API, but for applications like this one, > one need only use a small subset of that API. Don't let the size of the > API intimidate you.) what are the existing implementations? > (c) is very hard to use. Right now you can't really drive the use of > IPsec from applications, which means that you'd have to rely on the > sender and receiver to be configured properly. That won't work for > Internet-scale deployments. BTNS WG work on IPsec APIs would help, but > it will be a long time before those are widely available. In other > words, (c) is not a very realistic option. > (OTOH, if you have a no-security option for UDT, then (c) can be done by > the sysadmin if they want, without even having to tell the UDT app.) This is another option, minimizing overhead, > (d) is only useful if you're interested in the sum of user/host > authentication options available with SASL, GSS-API and DTLS. It's > worth considering, though mostly because of the very unfortunate reality > that authentication mechanisms are not equally available in all these > authentication frameworks :( This is something I will take into consideration. The draft is intended to cover a wide area of security options in considering security UDT. > (e) is like (d), but using IPsec; see (c) for why (e) not a realistic > option. > > Of these I'd say the best choice is to do (a), (b) and leave room for > adding (d) later. > The protocol would look roughly like: > > - First authenticate (exchange opaque GSS context / DTLS handshake > messages until authenticated) (for (d) you'd do both... we can > discuss that later). Additional references to RFC 5554 and 5238 will be incorporated to this ID. The protocol suggested above requires amplification. > - Then use per-message token functions (GSS-API) or DTLS record layer > (DTLS) to protect UDT messages. > > Interleaving could be an issue. You might need a separate security > context per-channel. Additional references to RFC 5554 and 5238 will be incorporated to this ID. The protocol suggested above requires amplification. Thanks for your inputs! > > Nico > -- > > > ------------------------------ > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > > End of saag Digest, Vol 16, Issue 6 > *********************************** > > _____________________________________________________ > This mail has been virus scanned by Australia On Line > see http://www.australiaonline.net.au/mailscanning > From Pasi.Eronen@nokia.com Fri Oct 30 02:37:51 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B468F3A6A4D; Fri, 30 Oct 2009 02:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9jGfriGHwGYR; Fri, 30 Oct 2009 02:37:50 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 823FD3A6948; Fri, 30 Oct 2009 02:37:49 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n9U9bnA7032633; Fri, 30 Oct 2009 11:38:03 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 11:37:54 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 11:37:49 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Fri, 30 Oct 2009 10:37:45 +0100 From: To: , Date: Fri, 30 Oct 2009 10:37:44 +0100 Thread-Topic: Pasi's AD Notes for October 2009 Thread-Index: AcpZRKH3PtyqoK+WSZ+18n7M2yaPfQ== Message-ID: <808FD6E27AD4884E94820BC333B2DB774E7F6F46A5@NOK-EUMSG-01.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 30 Oct 2009 09:37:49.0029 (UTC) FILETIME=[A4C1C150:01CA5944] X-Nokia-AV: Clean Subject: [saag] Pasi's AD Notes for October 2009 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 09:37:51 -0000 Here's again a short status update about what things are going on from my point-of-view. If you notice anything that doesn't look right, let me know -- miscommunication and mix-ups do happen. Best regards, Pasi MISC NOTES - Preparing IETF76 SAAG agenda and SecDir lunch with Tim. - Looking into RFC editor errata for security-related AD-sponsored=20 documents with Tim. - Some IODEF/INCH related discussions. - (Not wearing AD hat): Discussions about draft-krawczyk-hkdf on=20 CFRG list. - Tools work: Django 1.x transition, test suite improvements,=20 retiring many old scripts (my lines-of-code-per-day average=20 productivity this month is heavily negative :-). - I've been asked to sponsor draft-marin-eap-frm-fastreauth; waiting for me to take a look and reply to the authors [since 2009-10-26] WORKING GROUPS DKIM - draft-ietf-dkim-deployment: currently in Publication Requested state, waiting for me to read it [since 2009-10-26] - Waiting for Stephen and Barry for new charter text (noting that=20 current work items are completed and adding 4871bis) - I still need to review what to do about errata 1385, 1532, and 1596 - Talking with chairs and others about mailing list (mis)behavior. EMU - EMU WG received a new liaison statement from ITU-T about X.1034;=20 the WG chairs have the token for doing something about it. IPSECME - draft-ietf-ipsecme-ikev2-resumption: was approved by the IESG; waiting for the secretariat to send the announcement. - The IANA registrations for RFC 4543 have now been fixed, and RFC editor errata approved (see email on list for details). - draft-ietf-ipsecme-traffic-visibility: went through IETF last call; waiting for authors to address the comments received [since 2009-10-30] - draft-ietf-ipsecme-ikev2-ipv6-config (not wearing AD hat): went through IESG evaluation, and new version was submitted. Waiting for Tim to remove the RFC Editor Note and Russ to check the=20 new version, and clear his DISCUSS [since 2009-10-30] - draft-kanno-ipsecme-camellia-xcbc (not WG item): the authors have asked if I would sponsor this as individual submission. I've sent some questions to them, and I'm currently waiting for their reply [since 2009-10-14] - draft-ietf-ipsecme-ikev2-redirect (not wearing AD hat; Tim is=20 handling this one): currently in AUTH48, waiting for the authors (I think). - Some discussions about clarifying IKEv2 IANA registries (for encryption algorithms) and fixing a bug in RFC 4307. Waiting for Tero to submit an errata about the latter. - IANA registry entry for PRF_AES128_XCBC was fixed (thanks to=20 Alfred and Paul). - Processed one errata for RFC 2410. ISMS KEYPROV - Apparently waiting for the chairs to send some documents my way... PKIX - draft-ietf-pkix-sha2-dsa-ecdsa: was approved by IESG, now in RFC=20 editor queue. - draft-ietf-pkix-rfc4055-update: in RFC Editor queue, waiting for draft-ietf-pkix-sha2-dsa-ecdsa. SASL - draft-ietf-sasl-scram: was approved by IESG; now in RFC editor=20 queue. - draft-ietf-sasl-gs2: currently in IETF last call (ends 2009-11-18); hoping the authors submit a revised ID when submissions re-open. - (not WG item) draft-melnikov-sasl-scram-ldap: waiting for authors=20 to submit a revised ID when submissions re-open; placed on the agenda=20 of the 2009-11-19 IESG telechat. - (not WG item) draft-altman-tls-channel-bindings: currently in=20 IETF last call (ends 2009-11-02); active discussion ongoing. SYSLOG - draft-ietf-syslog-sign: in IESG evaluation; active discussions ongoing; waiting for me to reply to some of the emails; waiting for Alex to reply to some others. TLS - draft-ietf-tls-rfc4366-bis: the document was updated to address IETF last call comments; placed on the agenda of 2009-11-19 IESG telechat. - draft-ietf-tls-extractor: waiting for Eric to reply to email [since 2009-10-05]; also in AUTH48. - Processed two errata for RFC 4346. - (not WG item) see SASL WG for draft-altman-tls-channel-bindings OTHER DOCUMENTS DISCUSSES (active -- something happened within last month) - draft-ietf-bmwg-ipsec-meth: waiting for authors to reply to my comments [since 2009-10-22] - draft-ietf-bmwg-ipsec-term: waiting for authors to reply to my comments [since 2009-10-22] - draft-ietf-eai-downgraded-display: discussion ongoing; currently waiting for the authors to reply [since 2009-10-26] - draft-ietf-mipshop-pfmipv6: discussion ongoing; currently waiting for the authors to reply [since 2009-10-29] - draft-ietf-ntp-autokey: waiting for Ralph's proposal on how to proceed [since 2009-10-19] - draft-ietf-roll-home-routing-reqs: text agreed, waiting for the authors to submit a revised ID [sincer 2009-10-29] - draft-ietf-sip-certs: discussion ongoing; currently waiting for the authors to reply [since 2009-10-26] DISCUSSES (stalled -- I haven't heard anything from the authors or document shepherd for over one month) - draft-cain-post-inch-phishingextns: waiting for authors to submit a revised ID [since 2009-09-04] - draft-solinas-rfc4753bis: waiting for authors to reply to my comments [since 2009-09-24] DISCUSSES (presumed dead -- I haven't heard anything from the authors or document shepherd for over three months) - draft-cheshire-dnsext-nbp: waiting for authors to reply to my comments [since 2008-12-03] (pinged again on 2009-04-30, 2009-06-09, 2009-10-29) - draft-ietf-bfd-base: text agreed, waiting for authors to submit=20 a revised ID [since 2009-03-19] (pinged again on 2009-04-30, 2009-06-09, 2009-10-29) - draft-ietf-dime-diameter-api: waiting for Dan to get WG's opinion=20 on whether this will be useful and if yes, why [since 2009-06-18] - draft-ietf-sipping-policy-package: waiting for draft-ietf-sipping- media-policy-dataset to progress (or more information from Robert) [since 2008-10-28] --end--