From margaretw42@gmail.com Sun Nov 4 13:11:23 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA8821F8839 for ; Sun, 4 Nov 2012 13:11:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MpyzudPrMIR2 for ; Sun, 4 Nov 2012 13:11:22 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 25D7D21F88BF for ; Sun, 4 Nov 2012 13:11:13 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id h15so2372404dan.31 for ; Sun, 04 Nov 2012 13:11:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=Ba1jP/j8kOGY6ijPMO83Dy92B3Ab5o7UseJuJicPsxA=; b=xzT8AcW46UpXEMwKGxrksNqbtCD+HAq4KKaVkTnl9DQsBn5lOvAFOju0vNtg9rQzJx rmyH2BGwNbv1SSmeqqdXcvb9uJ5QqhC5eZKt2CQCmmLfgZqP9YelBzkSMq6k2ctQmNvV 79Xb5VqEqcPsIWGnsm/Maem4NeFmIkpON9KtDS7k6gFAbYwR+69WIjvqricddEFwqysK +NNU59iAdQDGWfLYjS5S1kpQkIgLYTVqLrXB78435+7LIVIzUORF1aqRz4pUbC1E4WOE BfHSRKR9iELgO/pymhyATAVynVdJFOkMU4ZVg6UWuJ97mJPHQ/95R6i7wslr+MbWZhcn pBEg== Received: by 10.66.78.136 with SMTP id b8mr23259426pax.26.1352063472902; Sun, 04 Nov 2012 13:11:12 -0800 (PST) Received: from ?IPv6:2001:df8::16:462a:60ff:fef6:acfc? ([2001:df8:0:16:462a:60ff:fef6:acfc]) by mx.google.com with ESMTPS id sy1sm9356873pbc.66.2012.11.04.13.11.12 (version=SSLv3 cipher=OTHER); Sun, 04 Nov 2012 13:11:12 -0800 (PST) From: Margaret Wasserman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 4 Nov 2012 16:11:07 -0500 Message-Id: To: saag@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [saag] Heads Up on SDN Security Drafts X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 21:11:23 -0000 Hi All, I just wanted to draw your attention to a couple of drafts that we = recently published about SDN security: https://datatracker.ietf.org/doc/draft-hartman-sdnsec-requirements/ https://datatracker.ietf.org/doc/draft-mrw-sdnsec-openflow-analysis/ The first is an SDN Security Analysis, and the second is a security = analysis of the ONF OpenFlow protocol. =20 These are just individual drafts, not targeted to any WG, but we'd like = to get feedback on them from the IETF security community. We'll also be = presenting them briefly during the saag meeting on Thursday. Margaret From leifj@mnt.se Wed Nov 7 07:59:50 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5CFF21F8C04 for ; Wed, 7 Nov 2012 07:59:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ChQHw9k47Wqv for ; Wed, 7 Nov 2012 07:59:50 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3BCD221F8B99 for ; Wed, 7 Nov 2012 07:59:50 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so1313092pad.31 for ; Wed, 07 Nov 2012 07:59:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-gm-message-state; bh=0BlzfZXtm3XUQ7FXkvLYJ8LnBplVZKdMYbTSIoO0hWE=; b=el1mjw9g201tOaaAUzLcpqOsKweeH8pQrI03Bsu/4sG4A+ziyNP7f7qDuNIWonJa1r kE8noSgCL8CmX2pjVSw13NISDNtPFY5lS0YRif0N44wvtRBUp+BKOQ2fT286EiEWob+g fSGhuhzbcPDZuP2oOZJm7amosHOjASfNYXFr09uZsd5cwtLS1lGrODL5B09q6jzhNI+G wGW+UgvD/nSfnkk/hcRn3/iEJ9NrAGmonmxdlZg6wCFUeC+LrsvdWIgAjTWWr/AJeZYi 4I7XvWCLE1FSas9W9xsIlre4CH6ywO9bLZXf18tR+3jFR5dHwQg1FS2KUjm9GZK/6i/y 1N3A== Received: by 10.66.86.101 with SMTP id o5mr13712373paz.15.1352303989921; Wed, 07 Nov 2012 07:59:49 -0800 (PST) Received: from ?IPv6:2001:df8:0:8:59e:2857:aeea:9499? ([2001:df8:0:8:59e:2857:aeea:9499]) by mx.google.com with ESMTPS id gl9sm14313779pbc.51.2012.11.07.07.59.49 (version=SSLv3 cipher=OTHER); Wed, 07 Nov 2012 07:59:49 -0800 (PST) Message-ID: <509A8574.3030802@mnt.se> Date: Wed, 07 Nov 2012 16:59:48 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: "saag@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkOfOvl6Fxj/mwcyIb7xRvBzSjEE/zEG450ior96Iq8kKddW6OR07j95bVoXiMW2zxXBmH8 Subject: [saag] abfab @IETF85 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 15:59:50 -0000 The abfab group met in Atlanta on Monday. The WG is making good progress. Core documents are on their way out the door. The WG is currently primarly discussing what to include in an updated EAP applicability statement and certain issues related to the AAA SAML binding. Leif & Klaas (abfab Chairs) From cabo@tzi.org Mon Oct 29 14:16:32 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D83AD21F86E7; Mon, 29 Oct 2012 14:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.337 X-Spam-Level: X-Spam-Status: No, score=-107.337 tagged_above=-999 required=5 tests=[AWL=-1.087, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-OZ9WrV6y4B; Mon, 29 Oct 2012 14:16:32 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id ED9D721F86E1; Mon, 29 Oct 2012 14:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q9TLFdsf029404; Mon, 29 Oct 2012 22:15:39 +0100 (CET) Received: from [192.168.217.105] (p54891A96.dip.t-dialin.net [84.137.26.150]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 5B04D194; Mon, 29 Oct 2012 22:15:38 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <508EEB07.8080807@cs.tcd.ie> Date: Mon, 29 Oct 2012 22:15:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8AF21C42-1B84-4CD1-9904-AF4CA1AB16B5@tzi.org> References: <015901cdb0d3$d38cf1f0$7aa6d5d0$@a-star.edu.sg> <1116.1351177270@sandelman.ca> <02a101cdb5f5$51109a70$f331cf50$@a-star.edu.sg> <508EBD6B.1070606@cs.tcd.ie> <10703.1351542774@obiwan.sandelman.ca> <508EEB07.8080807@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1499) X-Mailman-Approved-At: Wed, 07 Nov 2012 11:55:37 -0800 Cc: Cullen Jennings , roll@ietf.org, "'Keoh, Sye Loong'" , saag@ietf.org, 6lowpan@ietf.org Subject: Re: [saag] [6lowpan] SOLACE things at SAAG X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 21:16:33 -0000 On Oct 29, 2012, at 21:45, Stephen Farrell = wrote: > If he and Cullen want to arm-wrestle > that's fine:-) Well, Cullen's I-D (please have a look at = draft-jennings-core-transitive-trust-enrollment-01.txt,.pdf) is a very good example for the kind of input document that we are = looking for. But it is just one way of doing things. There are so many others. To a = large extent, the differences are not just based on technological = choices, but on what people are actually trying to do with the smart = objects, i.e., what purpose in life they have. After half a decade of kicking around half-baked solutions in this space = in various IETF working groups, I think it is a good idea to spend more = time understanding the design space. How, and where, to spend this time = in the most productive way is what I would like to discuss with = interested people before we do the SAAG slot: -> solace@ietf.org Gr=FC=DFe, Carsten PS. Here is section 3.3 of the CoRE roadmap I-D, which lists a couple = more related drafts: Several individual drafts analyze the issues around the security of constrained devices in constrained networks. | draft-garcia-core-security | | 2012-03-26 | | draft-sarikaya-core-sbootstrapping | -05 | 2012-07-10 | | draft-jennings-core-transitive-trust-enrollment | -01 | 2012-10-13 | [I-D.garcia-core-security] in particular describes the "Thing Lifecycle" and discusses resulting architectural considerations. [I-D.jennings-core-transitive-trust-enrollment] demonstrates a specific approach to securing the Thing Lifecycle based on defined roles of security players, including a Manufacturer, an Introducer, and a Transfer Agent. Further work around Thing Lifecycles is also expected to occur in the SOLACE initiative (Smart Object Lifecycle Architecture for Constrained Environments), with its early mailing list at solace@ietf.org -- developed after the model of the COMAN initiative (Management for Constrained Management Networks and Devices, coman@ietf.org, [I-D.ersue-constrained-mgmt]). From fluffy@cisco.com Sun Nov 4 09:55:52 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 623F621F8626; Sun, 4 Nov 2012 09:55:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFiW7OlRIV1P; Sun, 4 Nov 2012 09:55:51 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 83F2721F8615; Sun, 4 Nov 2012 09:55:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3877; q=dns/txt; s=iport; t=1352051747; x=1353261347; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zx648dV1GzOpShKn+2bM3+/aAeY41xkQ6v7FWY9XXDo=; b=NoZG36LBQv5ZaV3RHwneAQYLTRJQB/Gr9qCius7XHPtpDemmfGOd4ZI4 Q2N2G4p/xJGD6ZEI6tpOECVwmTISG/9ZDX8s2EviC7JkY9GmBRA6sYd9K WPneGSUHxpMjBqBpWy/O2jmV1w79L7xYc3SZXs5+sWnEb+V1ylC0ygJ5z g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAP2qllCtJV2c/2dsb2JhbABEwzmBCIIeAQEBAgEBAQEBDwEnNAsQAgEIEgYKFBAnCxcOAgQBDQUIDAcHh2IGC5kxnwuMAYVbYQOkVIFrgm+CGQ X-IronPort-AV: E=Sophos;i="4.80,711,1344211200"; d="scan'208";a="138628238" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 04 Nov 2012 17:55:47 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id qA4HtkgV032526 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 4 Nov 2012 17:55:46 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.217]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.001; Sun, 4 Nov 2012 11:55:46 -0600 From: "Cullen Jennings (fluffy)" To: Stephen Farrell , Michael Richardson , "saag@ietf.org" , Sean Turner , Carsten Bormann Thread-Topic: [6lowpan] SOLACE things at SAAG Thread-Index: AQHNurWd8mDoYb2tQUy4Nk+S++c3Zw== Date: Sun, 4 Nov 2012 17:55:46 +0000 Message-ID: References: <015901cdb0d3$d38cf1f0$7aa6d5d0$@a-star.edu.sg> <1116.1351177270@sandelman.ca> <02a101cdb5f5$51109a70$f331cf50$@a-star.edu.sg> <508EBD6B.1070606@cs.tcd.ie> <10703.1351542774@obiwan.sandelman.ca> <508EEB07.8080807@cs.tcd.ie> In-Reply-To: <508EEB07.8080807@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.78.123] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19338.004 x-tm-as-result: No--48.905900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <81E1CB44A01F564E8B2605302FA46364@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 07 Nov 2012 11:55:37 -0800 Cc: "roll@ietf.org" , "Keoh, Sye Loong" , "6lowpan@ietf.org" <6lowpan@ietf.org> Subject: Re: [saag] [6lowpan] SOLACE things at SAAG X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 17:55:52 -0000 I have been doing some work with constrained devices and would be happy to = talk about the problem in SAAG. I've spend a fair amount of time talking to= few folks that I think of as part of the security mafia to try and underst= and how to describe some of the threats and try and get crisp about the ove= rall goals - particularly in thinking about how the problem is different th= an security problems we have already solved.=20 I do have a sketch of a proposed solution which I think helps people unders= tand the problem but may or may not be the right path to a good solution. = If someone from the security community wanted to help me move this from a s= ketch to a well formed proposal, that would be great but I think the key th= ing for SAAG right now is the problem.=20 I'm glad to do this with Carsten - he and I are at pretty opposite ends of = the spectrum on some of this stuff but the union of our views likely covers= a very large percentage of the broad communities views on the topic.=20 Cullen On Oct 29, 2012, at 14:45 , Stephen Farrell wro= te: >=20 > Hiya, >=20 > So Carsten volunteered to give saag a heads-up on the > problem this time. If he and Cullen want to arm-wrestle > that's fine:-) I'm sure either would do a fine job. >=20 > I didn't mean to say anything about the solace draft > being good, bad or indifferent. But I figured someone > is working on this problem somewhere and would like > to make sure that whatever solution looks like it'll > be adopted is something that wouldn't cause saag folk > to have fits. >=20 > Cheers, > S. >=20 > On 10/29/2012 08:32 PM, Michael Richardson wrote: >>=20 >>>>>>> "Stephen" =3D=3D Stephen Farrell writes= : >> Stephen> Would it be timely to spend 10 minutes on this during the saa= g >> Stephen> session? >>=20 >> I think, if you want to talk something SOLACE related which is more >> concrete than a possible SOLACE IRTF "charter", then maybe have Cullen >> talk about: >>=20 >> http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/papers/Cull= enJennings.pdf >> http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/slides/Cull= en1.pdf >>=20 >> Stephen> I'd really like that the security area not end up being surpr= ised >> Stephen> by whatever is eventually decided so getting a presentation a= t >> Stephen> saag would be useful at the point where you more or less know >> Stephen> the direction, but are still flexible enough to deal with som= eone >> Stephen> who e.g. points out significant security issues. >>=20 >> Except that: >> 1) the constrained devices are more constrained than the IP phones >> described. >>=20 >> 2) the constrained devices probably can not be attacked/p0wned until >> after they get on the network, and so actually authenticating to the >> network is the "application" >>=20 >> Cullen's slides provide a really good starting explanation. >> While the details of the ultimate answer are going to be a bit different >> in small ways, the basic architecture he presents has been articulated >> repeatedly by many. >>=20 >> So, if your aim is to get more security geeks thinking about attacks, >> and about defenses, in advance of an actual proposed protocol (and >> SOLACE is an I*R*TF group, recall. A protocol might not be the result >> anyway), then I suggest giving Cullen a few minutes to talk about his >> slide 7,8,9. >>=20 >> Stephen> It might be that waiting another meeting cycle or two would b= e >> Stephen> better if the basic ideas aren't yet firmed up. >>=20 >> One meeting cycle won't help. Four might. >>=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From rstruik.ext@gmail.com Wed Nov 7 12:33:04 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23ECF21F8B6E; Wed, 7 Nov 2012 12:33:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAqZgtOxW5uT; Wed, 7 Nov 2012 12:33:03 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1F08D21F8A26; Wed, 7 Nov 2012 12:33:03 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so3422550iec.31 for ; Wed, 07 Nov 2012 12:33:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=YqX6XnR1cvI7f0nfzmAI2RsUyy/ha6+o+ky8N7Cy1nk=; b=k00zT4TpyzyyfH7g5qE+7saNCzdydDwFf6D/AojzrR5L3MRxspQCHciaZO7SWMzLiF NOoBK8S56OBjvrgEK7VfrXzqEr7+7Y5NPslRQLe0/7KxJ53/d6C63KTFVOqao84Dcr9S 6tN0qMwLzw18laB1EdUKARgAMyoctofmd3EqewFzLZjA8GQA78M1+1yGsz8ys16ls0Jw 3JqazgewdfQjmeYt4h/V8z+pdhde7TVR7Gu6g+h8MPWD+FnKQz9rDcpKCKqeKoGluatt LphO8JtcxOjaR3hpiUgOEZXVaMytLNTIGlULiF/7/sjc3XmmJgAWkg7XYqIKY3h2cLBG OIuw== Received: by 10.50.7.232 with SMTP id m8mr5810439iga.48.1352320382644; Wed, 07 Nov 2012 12:33:02 -0800 (PST) Received: from [192.168.1.100] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [99.231.4.27]) by mx.google.com with ESMTPS id gs6sm2902405igc.11.2012.11.07.12.33.01 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Nov 2012 12:33:01 -0800 (PST) Message-ID: <509AC579.3090301@gmail.com> Date: Wed, 07 Nov 2012 15:32:57 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Carsten Bormann References: <17F77EDC-3726-4AF2-9848-1C98E3F98B7E@tzi.org> In-Reply-To: <17F77EDC-3726-4AF2-9848-1C98E3F98B7E@tzi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "saag@ietf.org" , "solace@ietf.org" Subject: Re: [saag] [solace] Slides posted for SAAG heads-up X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 20:33:04 -0000 Hi Carsten: Great to discuss some of these topics with SAAG. I believe it would have merit to take this on a more fundamental ITRF level, so as to prevent people throwing a single protocol at the topic area: all context needs to be defined here in a unified way. More importantly, though, this should become an effort aimed at wide-scale usability (the 50billion devices everyone seems to point to in presentations from time to time) Some brief comments: a) Deployment scenarios. I believe it would be a mistake to limit oneself to a single use case scenario. The proverbial light switch-lamp use case comes to mind, which would suffer from the often made assumption that one has a single, homogeneous trust domain (rather than a heterogeneous trust domain setting, where device roles etc are dynamic) and from small network size (after all, if internet of things will have 50 billion devices in 2020, then the avg network size *must* be large). This was the original approach within ZigBee all the way back in 2003, which - in my mind - set back the whole life-cycle management topic for years. By now (2012), there have been lots of studies into more realistic use cases with large-scale deployment by user groups, which do assume one can procure devices from mutually untrusted vendors, have many transitions in the supply-chain, may buy/sell/dispose of subsystems, etc. This all points towards heterogeneous trust models and very dynamic device behavior, without requiring centralized control flows involving a manufacturer (the latter is also undesirable from a survivability perspective). b) Trust life-cycle management. Please note that trust lifecycle management requires both crypto and security protocols (mechanical constructs) and constructs that take care of authorization decisions (initial authorization, changes to device role mapping, device replacement, etc.). The latter seems under-emphasized on the slides. This should include questions as to how to initialize 50 billion devices for virtually $0 apiece. c) Security objectives. An objective such as "not subject to a mass scale attack" would be hard to quantify in terms of required cryptographic assurances. Moreover, it seems to miss the point that some of these highly constrained networks are suppose to safeguard critical infrastructure (municipal water supply, hurricane prediction systems, etc.). In my mind, it would be a mistake to make this an exercise in toning down normal security requirements (under the pretext that this is only for "non-serious applications" (lamp-switch scenario again)). If one wants to get mass scale deployment of the 50 billion devices mark, one cannot aim for "crappy, but good enough" solutions, since no one in a position of accountability would sign off on these (lifes and jobs on the line if something goes wrong, so to speak). The good news is that most high-quality crypto that is also efficient and does not leave a huge implementation footprint is fast becoming a commodity (or is getting there). The bad news is that integration of individual crypto and security constructs *and* security policies that allow these to be woven into a unified, standardizable framework architecture is still far off from sufficient understanding, let alone support via standards (and often simply ruled out of scope, since a "convenient" way to lock out product from other vendors). == Weblink to NIST Cryptography for Emerging Technologies and Applications Workshop, Gaithersburg, MD, November 7-8, 2011 http://www.nist.gov/itl/csd/ct/ceta-workshop.cfm A very old IETF draft of potential interest - with requirements, spelling out crypto + policy requirements, etc. (true: 3yrs old draft [Nov 2009], but referring to needing a home with IETF in concluding section): http://tools.ietf.org/pdf/draft-struik-6lowapp-security-considerations-00.pdf On 11/7/2012 12:45 PM, Carsten Bormann wrote: > The slides for my short report at tomorrow's SAAG meeting are up: > > http://www.ietf.org/proceedings/85/slides/slides-85-saag-3.pdf > > (Disclaimer: These are presentation slides, not a presentation by itself. > So they make sense primarily in combination with what I'm going to say.) > > Grüße, Carsten > > _______________________________________________ > solace mailing list > solace@ietf.org > https://www.ietf.org/mailman/listinfo/solace -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 From cabo@tzi.org Wed Nov 7 13:39:12 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB12D21F8C3E; Wed, 7 Nov 2012 13:39:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.181 X-Spam-Level: X-Spam-Status: No, score=-106.181 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IgA0Dr6iCsc7; Wed, 7 Nov 2012 13:39:12 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id E690321F8AD3; Wed, 7 Nov 2012 13:39:04 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id qA7LcvPB015924; Wed, 7 Nov 2012 22:38:57 +0100 (CET) Received: from dhcp-9336.meeting.ietf.org (dhcp-9336.meeting.ietf.org [130.129.11.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 597108D5; Wed, 7 Nov 2012 22:38:56 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <509AC579.3090301@gmail.com> Date: Wed, 7 Nov 2012 16:38:54 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <30433E6B-C9B9-4EDC-B2D5-1D042F8199AD@tzi.org> References: <17F77EDC-3726-4AF2-9848-1C98E3F98B7E@tzi.org> <509AC579.3090301@gmail.com> To: Rene Struik X-Mailer: Apple Mail (2.1499) Cc: "saag@ietf.org" , "solace@ietf.org" Subject: Re: [saag] [solace] Slides posted for SAAG heads-up X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 21:39:13 -0000 Hi Rene, good to hear from you. Clearly, we cannot stop at exactly one usage scenario. But I strongly believe we need to start with exactly one. When we have the contributions for that, we can probably ask much better = questions for the next round, where we will add scenarios. The slides are indeed more for SAAG and less for people who would focus = on the logistics of rolling out 50000000000 devices. SOLACE clearly goes beyond security, or we could do it right there in = the security area. The security objectives slides are divided into one for the specific = ones for a scenario and one for the general ones (one could say = "motherhood and apple pie" if they were better understood). Even if the = specific ones can be toned down, we still have the general ones, and = that includes avoiding susceptibility to mass attacks. (This is one of = the points that were made at the March SoS workshop.) And that is, very = much, the reason why compromising on security always leads to security = compromises. Gr=FC=DFe, Carsten From shawn.emery@oracle.com Wed Nov 7 13:48:50 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 451E221F8B99 for ; Wed, 7 Nov 2012 13:48:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdHA5LwPhxsv for ; Wed, 7 Nov 2012 13:48:49 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 483E621F8B67 for ; Wed, 7 Nov 2012 13:48:49 -0800 (PST) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qA7LmlBl032079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 7 Nov 2012 21:48:48 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qA7LmlGg008338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 7 Nov 2012 21:48:47 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qA7Lmklk028666 for ; Wed, 7 Nov 2012 15:48:46 -0600 Received: from dhcp-14cb.meeting.ietf.org (/130.129.20.203) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Nov 2012 13:48:46 -0800 Message-ID: <509AD73F.4070602@oracle.com> Date: Wed, 07 Nov 2012 14:48:47 -0700 From: Shawn M Emery User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: saag@ietf.org References: <509AC18A.7070407@oracle.com> In-Reply-To: <509AC18A.7070407@oracle.com> X-Forwarded-Message-Id: <509AC18A.7070407@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Subject: [saag] Kitten and Krb-wg Summary - IETF 85 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 21:48:50 -0000 Co-chairs: Sam Hartman, Shawn Emery, and Josh Howlett (new, absent) The WGs met for the morning session on Tuesday (10.6.12). The 2 1/2 hour session was combined and will be merged under the kitten WG in the near future. draft-ietf-kitten-gssapi-extensions-iana ---------------------------------------- Per programming language registry update in 07 made by Alexey. Looking for reviewers. draft-ietf-kitten-gssapi-naming-exts ------------------------------------ Now RFC 6680! draft-ietf-kitten-sasl-openid ----------------------------- Now RFC 6616! draft-ietf-kitten-sasl-saml --------------------------- Now RFC 6595! draft-ietf-kitten-sasl-saml-ec ------------------------------ Scott Cantor gave a presentation on updates to the SASL SAML-EC draft and brought up issues with expert review, naming and keying issues. draft-ietf-kitten-sasl-oauth ---------------------------- WGLC expired on 10/7/12. Issues were brought up on the list. Hannes agreed to update the draft with example token types and fixes to the IMAP/SMTP examples. draft-ietf-krb-wg-kdc-model --------------------------- DISCUSS brought up by Pete Resnik. draft-ietf-krb-wg-pkinit-alg-agility ------------------------------------ Needs to be sent to IESG (passed WGLC) and Josh will shepherd. Tom had found an IANA conflict, which was discussed during the Kerberos IANA status. draft-ietf-krb-wg-kerberos-referrals ------------------------------------ Approved; in RFC editor queue. draft-sakane-dhc-dhcpv6-kdc-option ---------------------------------- In AUTH48. draft-ietf-krb-wg-camellia-cts ------------------------------ Approved; in RFC editor queue. Suite B Profile for Kerberos 5 ------------------------------ Kelly Burgin had presented Suite B profile use for Kerberos 5. He is looking for feed-back on his draft and direction on whether to adopt the draft as a WG item. Kerberos IANA ------------- Tom Yu had brought up a conflict with error code 82 and proposals to resolve this: update the pkinit-alg draft, erratum for 6111, or overload the error code. In regards to the registry draft there were questions on whether to document message types, tags, and ASN.1. Will take the questions to the list Charter Discussion ------------------ New work items were discussed for the merged WGs. Interest was gauged for each of these potential work items, while polling for individuals that would be major contributors and reviewers of subsequent drafts. Kerberos Authorization Data Container Authenticated by Multiple MACs -------------------------------------------------------------------- Tom Yu had brought a question on whether the KDC MAC is meaningful without a strong binding to the enclosing service ticket? Will take the question to the list. Open Mic -------- No one came forward. Shawn. -- kitten and krb-wg co-chair From paul.hoffman@vpnc.org Thu Nov 8 04:29:24 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 793FD21F87F7 for ; Thu, 8 Nov 2012 04:29:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5nkehBCcD+MM for ; Thu, 8 Nov 2012 04:29:24 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 057B721F8793 for ; Thu, 8 Nov 2012 04:29:23 -0800 (PST) Received: from [10.71.6.93] (173-15-223-105-BusName-Atlanta.hfc.comcastbusiness.net [173.15.223.105]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id qA8CTJOK007135 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 8 Nov 2012 05:29:20 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <9B93EFAD-AD9B-4402-8CC2-79239EB3DF2E@vpnc.org> Date: Thu, 8 Nov 2012 07:29:21 -0500 To: IETF Security Area Advisory Group Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [saag] Revision of "Attacks on Cryptographic Hashes in Internet Protocols" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 12:29:24 -0000 Greetings again. Bruce Schneier and I have started an update to RFC = 4270, "Attacks on Cryptographic Hashes in Internet Protocols". This = revision is meant to deal with new and more devastating attacks on MD5, = the fact that SHA-1 collisions will be financially feasible in the = foreseeable future, and NIST's upcoming SHA-3 announcements. We expect = to keep this revision process open for at least five months because NIST = probably won't finalize the parameters and naming and so on for KECCAK = until then; that is, we won't send this to RFC Editor until SHA-3 is = finalized. Please take a look at=20 http://tools.ietf.org/html/draft-hoffman-schneier-4270bis Sean and Stephen have agreed that we should use the SAAG mailing list = for discussing this draft.=20 --Paul Hoffman= From barryleiba.mailing.lists@gmail.com Thu Nov 8 06:21:44 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 637D321F8B91 for ; Thu, 8 Nov 2012 06:21:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.788 X-Spam-Level: X-Spam-Status: No, score=-102.788 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8IfXoQVme2XT for ; Thu, 8 Nov 2012 06:21:43 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id CB48421F8B7D for ; Thu, 8 Nov 2012 06:21:42 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id d4so1800588eek.31 for ; Thu, 08 Nov 2012 06:21:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=XpzRQW5UVEhlmOXxRwgvv8ACKVDQIT7TVlXA/4LpRq8=; b=JPw38SitkLBJ5QWpLunxpKOGCtzKksc7nO10v+Y+QwyfRLiyi3GTpd8yfaimH0eull 5Uvg4x/uZuw0HN8fr0NagRzjcUaNT6qtHjudmdDAtLZoJcKnIGPn/NkNk72mbZD4BRDB rN1mRsaR9wdikoNbixShbIXRlQ5i5GS6OoIWHryphizpYhWZfRSkrWy+Tm0XLbIzp6Ht yWiJiEhqh65sqnzg/PusJ+XX6eEsmyKmijTsdmpwGpb7YaElC4MgAuKaamOYRmt/VcTQ 8rHGL4xnfGpJ+DPhSWFsK6rbR1ki6LlP9ebcMB9lgwA9gBqz6667Oo1NC2wp6ZS7l0eR RxZQ== MIME-Version: 1.0 Received: by 10.14.173.67 with SMTP id u43mr27938681eel.27.1352384502070; Thu, 08 Nov 2012 06:21:42 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.14.98.71 with HTTP; Thu, 8 Nov 2012 06:21:41 -0800 (PST) In-Reply-To: <9B93EFAD-AD9B-4402-8CC2-79239EB3DF2E@vpnc.org> References: <9B93EFAD-AD9B-4402-8CC2-79239EB3DF2E@vpnc.org> Date: Thu, 8 Nov 2012 09:21:41 -0500 X-Google-Sender-Auth: oknRhEDttvJGuIlvDmpZkcpi3cw Message-ID: From: Barry Leiba To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF Security Area Advisory Group Subject: Re: [saag] Revision of "Attacks on Cryptographic Hashes in Internet Protocols" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 14:21:44 -0000 > Greetings again. Bruce Schneier and I have started an update to RFC 4270, > "Attacks on Cryptographic Hashes in Internet Protocols". This revision is > meant to deal with new and more devastating attacks on MD5, the fact that > SHA-1 collisions will be financially feasible in the foreseeable future, and > NIST's upcoming SHA-3 announcements. We expect to keep this revision > process open for at least five months because NIST probably won't finalize > the parameters and naming and so on for KECCAK until then; that is, we > won't send this to RFC Editor until SHA-3 is finalized. Please take a look at > > http://tools.ietf.org/html/draft-hoffman-schneier-4270bis Is there time in the SAAG session today to run through the major changes? Barry From stephen.farrell@cs.tcd.ie Thu Nov 8 06:26:25 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8348921F8B4B for ; Thu, 8 Nov 2012 06:26:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOR7FQ65v0io for ; Thu, 8 Nov 2012 06:26:25 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id F072621F8B6E for ; Thu, 8 Nov 2012 06:26:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4FFDFBE62; Thu, 8 Nov 2012 14:26:03 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJW23a1CLJOh; Thu, 8 Nov 2012 14:26:02 +0000 (GMT) Received: from [130.129.96.58] (dhcp-603a.meeting.ietf.org [130.129.96.58]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D3FA3BE61; Thu, 8 Nov 2012 14:26:00 +0000 (GMT) Message-ID: <509BC0F6.3060509@cs.tcd.ie> Date: Thu, 08 Nov 2012 14:25:58 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Barry Leiba References: <9B93EFAD-AD9B-4402-8CC2-79239EB3DF2E@vpnc.org> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Paul Hoffman , IETF Security Area Advisory Group Subject: Re: [saag] Revision of "Attacks on Cryptographic Hashes in Internet Protocols" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 14:26:25 -0000 On 11/08/2012 02:21 PM, Barry Leiba wrote: >> Greetings again. Bruce Schneier and I have started an update to RFC 4270, >> "Attacks on Cryptographic Hashes in Internet Protocols". This revision is >> meant to deal with new and more devastating attacks on MD5, the fact that >> SHA-1 collisions will be financially feasible in the foreseeable future, and >> NIST's upcoming SHA-3 announcements. We expect to keep this revision >> process open for at least five months because NIST probably won't finalize >> the parameters and naming and so on for KECCAK until then; that is, we >> won't send this to RFC Editor until SHA-3 is finalized. Please take a look at >> >> http://tools.ietf.org/html/draft-hoffman-schneier-4270bis > > Is there time in the SAAG session today to run through the major changes? Plan is for Paul to do that at open-mic without slides, but it'll be March-ish before NIST have the parameters AIUI so there's time. We also plan to AD sponsor this so it'll get an IETF LC, and might be better to see presented at IETF-86 around when that LC will be happening. S. > > Barry > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > From shanna@juniper.net Thu Nov 8 06:58:13 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84E9621F8B16 for ; Thu, 8 Nov 2012 06:58:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.441 X-Spam-Level: X-Spam-Status: No, score=-103.441 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NvHXHxC26nDv for ; Thu, 8 Nov 2012 06:58:13 -0800 (PST) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id B863F21F8B4B for ; Thu, 8 Nov 2012 06:58:12 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKUJvIg3VecPDnWAJwKmnaxq5Qk7lksSRj@postini.com; Thu, 08 Nov 2012 06:58:12 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 8 Nov 2012 06:43:56 -0800 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Thu, 8 Nov 2012 06:43:55 -0800 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.185) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 8 Nov 2012 06:46:25 -0800 Received: from mail154-co1-R.bigfish.com (10.243.78.233) by CO1EHSOBE001.bigfish.com (10.243.66.64) with Microsoft SMTP Server id 14.1.225.23; Thu, 8 Nov 2012 14:43:50 +0000 Received: from mail154-co1 (localhost [127.0.0.1]) by mail154-co1-R.bigfish.com (Postfix) with ESMTP id BFD63C60148 for ; Thu, 8 Nov 2012 14:43:50 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.244.213; KIP:(null); UIP:(null); (null); H:CH1PRD0510HT001.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -16 X-BigFish: PS-16(zzzz1de0h1202h1d1ah1d2ahzz1033IL8275dhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0l1155h) Received: from mail154-co1 (localhost.localdomain [127.0.0.1]) by mail154-co1 (MessageSwitch) id 1352385829722840_19354; Thu, 8 Nov 2012 14:43:49 +0000 (UTC) Received: from CO1EHSMHS030.bigfish.com (unknown [10.243.78.228]) by mail154-co1.bigfish.com (Postfix) with ESMTP id ADC5B2004A for ; Thu, 8 Nov 2012 14:43:49 +0000 (UTC) Received: from CH1PRD0510HT001.namprd05.prod.outlook.com (157.56.244.213) by CO1EHSMHS030.bigfish.com (10.243.66.40) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 8 Nov 2012 14:43:48 +0000 Received: from CH1PRD0510MB369.namprd05.prod.outlook.com ([169.254.10.49]) by CH1PRD0510HT001.namprd05.prod.outlook.com ([10.255.150.36]) with mapi id 14.16.0233.002; Thu, 8 Nov 2012 14:43:48 +0000 From: Stephen Hanna To: "saag@ietf.org" Thread-Topic: nea summary for IETF 85 Thread-Index: Ac29v3TFuzM3SJBtQcaeJZDJbphRNw== Date: Thu, 8 Nov 2012 14:43:47 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: [saag] nea summary for IETF 85 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 14:58:13 -0000 The nea Working Group did not meet at IETF 85 because all of our remaining deliverables are almost done. We have one document in the RFC Editor's Queue (the NEA Asokan Attack Analysis), one with the IESG (PT-TLS), and one that was updated this week and will shortly be going to the IESG requesting Proposed Standard status (PT-EAP). We recently had late IPR disclosures on PT-TLS and PT-EAP: https://datatracker.ietf.org/ipr/1889 https://datatracker.ietf.org/ipr/1890 The working group has reviewed these disclosures and reached consensus on the email list to proceed with standardization of PT-TLS and PT-EAP. We hope to get all our specs published as RFCs before IETF 86 and shut down the working group. From ynir@checkpoint.com Thu Nov 8 06:59:12 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E718321F85DA for ; Thu, 8 Nov 2012 06:59:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7SaSbkZ4zl5 for ; Thu, 8 Nov 2012 06:59:12 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id EEE9A21F890A for ; Thu, 8 Nov 2012 06:59:11 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id qA8Ex9DB018017 for ; Thu, 8 Nov 2012 16:59:09 +0200 X-CheckPoint: {509BC5FA-24-1B221DC2-2FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 8 Nov 2012 16:59:09 +0200 Received: from il-ex01.ad.checkpoint.com ([194.29.34.26]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Thu, 8 Nov 2012 16:59:09 +0200 From: Yoav Nir To: "saag@ietf.org" Date: Thu, 8 Nov 2012 16:59:08 +0200 Thread-Topic: httpauth BOF summary Thread-Index: Ac29wZrldRnBnzdKSHSg9GqCYAfdag== Message-ID: <4C36AC95-534A-4063-8EF8-A84DF9AE583F@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: multipart/alternative; boundary="_000_4C36AC95534A40638EF8A84DF9AE583Fcheckpointcom_" MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Subject: [saag] httpauth BOF summary X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 14:59:13 -0000 --_000_4C36AC95534A40638EF8A84DF9AE583Fcheckpointcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The HTTP(-)Auth BOF was held on Wednesday afternoon. 5 very different methods were presented. There was considerable resistance = to the idea for several reasons: * The problem statement is not well-defined * We don't have the website builders who are the target audience for the= se protocols, so we don't have meaningful requirements * The different solutions are obviously solving different problems. * The IETF has been unsuccessful in designing user interaction While there is considerable willingness to do work in this space, we need b= etter-defined goals, and we also probably need to recruit some people who e= ither manage the user experience in large websites, or write the frameworks= used by the smaller websites. Yoav --_000_4C36AC95534A40638EF8A84DF9AE583Fcheckpointcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The HTTP(-)Auth BOF was he= ld on Wednesday afternoon.

5 very different methods were= presented. There was considerable resistance to the idea for several reaso= ns:
  • The problem statement is not we= ll-defined
  • We don't have the website builders who are the target au= dience for these protocols, so we don't have meaningful requirements
    • The different solutions are obviously solving different problems.The IETF has been unsuccessful in designing user interaction

While there is considerable willingness to do work in= this space, we need better-defined goals, and we also probably need to rec= ruit some people who either manage the user experience in large websites, o= r write the frameworks used by the smaller websites.

Yoav

= --_000_4C36AC95534A40638EF8A84DF9AE583Fcheckpointcom_-- From ynir@checkpoint.com Thu Nov 8 07:02:16 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAD3E21F8B6E for ; Thu, 8 Nov 2012 07:02:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id spVwNyK3X9D0 for ; Thu, 8 Nov 2012 07:02:16 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id CF52621F8A60 for ; Thu, 8 Nov 2012 07:02:15 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id qA8F258F018695 for ; Thu, 8 Nov 2012 17:02:05 +0200 X-CheckPoint: {509BC6AB-0-1B221DC2-2FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 8 Nov 2012 17:02:05 +0200 Received: from il-ex01.ad.checkpoint.com ([194.29.34.26]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Thu, 8 Nov 2012 17:02:05 +0200 From: Yoav Nir To: "saag@ietf.org" Date: Thu, 8 Nov 2012 17:02:05 +0200 Thread-Topic: WebSec Meeting Thread-Index: Ac29wgOyy9DxdMUuSrS1QhET6TMASA== Message-ID: <1C98038B-4707-46BF-A29F-86A161F62616@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Subject: [saag] WebSec Meeting X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 15:02:16 -0000 WebSec will meet Thursday at 17:30.=20 We have HSTS in the RFC Editor's queue, the X-Frame-Options in WGLC, 1 othe= r document in progress (key pinning), and 1 document (framework requirement= s) that we will be asked to adopt. Two of our documents have questionable futures: frame-options and mime-snif= fing, and that will be discussed at the meeting as well. Yoav From kathleen.moriarty@emc.com Thu Nov 8 07:27:08 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A61D21F85AA for ; Thu, 8 Nov 2012 07:27:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5GgdlCNU9Dx for ; Thu, 8 Nov 2012 07:27:05 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id ADAD821F87DF for ; Thu, 8 Nov 2012 07:27:03 -0800 (PST) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qA8FR26O007020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 8 Nov 2012 10:27:02 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.251]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor) for ; Thu, 8 Nov 2012 10:26:44 -0500 Received: from mxhub04.corp.emc.com (mxhub04.corp.emc.com [10.254.141.106]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qA8FQeXc012148 for ; Thu, 8 Nov 2012 10:26:43 -0500 Received: from mx15a.corp.emc.com ([169.254.1.83]) by mxhub04.corp.emc.com ([10.254.141.106]) with mapi; Thu, 8 Nov 2012 10:26:42 -0500 From: "Moriarty, Kathleen" To: "saag@ietf.org" Date: Thu, 8 Nov 2012 10:26:41 -0500 Thread-Topic: MILE Summary Thread-Index: AQHNvcVzk0Hb9rt61EW/bB7k285pYA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [saag] MILE Summary X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 15:27:08 -0000 MILE WG Summary: MILE met on November 6th, Tuesday at 3:20 and had a productive session. Tw= o new drafts were reviewed and there seems to be general agreement that the= work is needed. The drafts will require a call for WG adoption and a char= ter change. Resource Oriented Lightweight Indicator Exchange:=20 http://datatracker.ietf.org/doc/draft-field-mile-rolie/ IODEF Enumeration Reference Format http://datatracker.ietf.org/doc/draft-montville-mile-enum-reference-form= at/ The Structured Cyber Security (SCI) draft was reviewed and updates per the = WG decision from the last meeting were made to the current version. The ed= itor will drive the document with a use case focus going forward to ensure = the use cases that are requirements driven are actually met through this dr= aft. We'll need to see discussion on the mailing list and participation fr= om incident responders (a little tough as they don't like to talk openly). IODEF extension to Support structured cybersecurity information http://datatracker.ietf.org/doc/draft-ietf-mile-sci/ Additionally, two other drafts are expected before the next meeting to upda= te the base format to exchange incident information as well as provide guid= ance to implementers to ensure consistent representation of incidents can b= e done for interoperability between implementations. RFC5070-bis with 2 volunteer editors (one was an RFC5070 editor) IODEF Guidance with 3 volunteer editors Additional drafts expected to be updated before the next meeting WG document: GRC Exchange,=20 http://datatracker.ietf.org/doc/draft-ietf-mile-grc-exchange/ non-WG document: IODEF Forensics extension http://datatracker.ietf.org/doc/draft-inacio-mile-forensics/ Some discussion on an XMPP binding for IODEF/RID and we need to hear feedba= ck on the list if this will be helpful with some use case background/explan= ation. Peter St. Andre has volunteered to work on such a draft if it is us= eful to the WG.= From leifj@sunet.se Thu Nov 8 07:52:57 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3060E21F8786 for ; Thu, 8 Nov 2012 07:52:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hg+topUCRvkh for ; Thu, 8 Nov 2012 07:52:53 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 59A2721F8595 for ; Thu, 8 Nov 2012 07:52:53 -0800 (PST) Received: from [130.129.9.70] (dhcp-9146.meeting.ietf.org [130.129.9.70]) (authenticated bits=0) by backup-server.nordu.net (8.14.5/8.14.3) with ESMTP id qA8FqlpA012888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 8 Nov 2012 16:52:51 +0100 (CET) Message-ID: <509BD54E.5080300@sunet.se> Date: Thu, 08 Nov 2012 16:52:46 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: "saag@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 08 Nov 2012 08:01:22 -0800 Subject: [saag] abfab @IETF85 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 15:52:57 -0000 The abfab group met in Atlanta on Monday. The WG is making good progress. Core documents are on their way out the door. The WG is currently primarly discussing what to include in an updated EAP applicability statement and certain issues related to the AAA SAML binding. Leif & Klaas (abfab Chairs) From jsalowey@cisco.com Thu Nov 8 08:29:24 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADEE421F8595 for ; Thu, 8 Nov 2012 08:29:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y42rJoQmiCPa for ; Thu, 8 Nov 2012 08:29:24 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 288CD21F8549 for ; Thu, 8 Nov 2012 08:29:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=400; q=dns/txt; s=iport; t=1352392161; x=1353601761; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=BPR9EeO2+StIbjzQTIZ4ffOoTvTOZkaPMc2fc7CYpTs=; b=ZN4PSF5qE3OJkNLq7hJWZwNu7VWPsbR2Y5+yi1JxC/LZDzKpI65K7CPC xZ3lk6yU7/7dHwIZ/ltluXYUUMY/yXzQfdpQAWwIvfhzBdqHJ5MM60E7L 9OvCqr1UK9KOv1geNft0xXuWXPivozhCQzwRHb8TLcS33NsAQ0F1szFLa Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoEIAIfdm1CtJXG+/2dsb2JhbABEw2uBAQeCIAEEEgEnUQEqFEInBBsah2iaT4EroDKReGEDpFOBa4Jvghk X-IronPort-AV: E=Sophos;i="4.80,738,1344211200"; d="scan'208";a="140179364" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 08 Nov 2012 16:29:19 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qA8GTJoH001534 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 8 Nov 2012 16:29:19 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.68]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.001; Thu, 8 Nov 2012 10:29:19 -0600 From: "Joseph Salowey (jsalowey)" To: "saag@ietf.org" Thread-Topic: emu @IETF85 Thread-Index: AQHNvc4zCcxBf3TYxEa0y6fIiT+tYA== Date: Thu, 8 Nov 2012 16:29:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.240.122] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19348.005 x-tm-as-result: No--21.191700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [saag] emu @IETF85 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 16:29:24 -0000 The EMU group met on Tuesday Afternoon. We discussed open issues from the= reviews of TEAP. Most issues were resolved and we will have some more rev= iew and comment on the list. The goal is to have working group last call = before IETF 86. The mutual crypto-binding draft needs a revision to compl= ete some sections. The goal is to have the revision submitted before IETF= 86. =20 From odonoghue@isoc.org Thu Nov 8 08:31:21 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7D021F8450 for ; Thu, 8 Nov 2012 08:31:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.82 X-Spam-Level: X-Spam-Status: No, score=-103.82 tagged_above=-999 required=5 tests=[AWL=-0.555, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XxOvj-WNgk7D for ; Thu, 8 Nov 2012 08:31:20 -0800 (PST) Received: from smtp150.dfw.emailsrvr.com (smtp150.dfw.emailsrvr.com [67.192.241.150]) by ietfa.amsl.com (Postfix) with ESMTP id DF6FC21F8433 for ; Thu, 8 Nov 2012 08:31:20 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp15.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 89953300738 for ; Thu, 8 Nov 2012 11:31:20 -0500 (EST) X-Virus-Scanned: OK Received: by smtp15.relay.dfw1a.emailsrvr.com (Authenticated sender: odonoghue-AT-isoc.org) with ESMTPSA id 6132D300356 for ; Thu, 8 Nov 2012 11:31:20 -0500 (EST) Message-ID: <509BDE5C.4000905@isoc.org> Date: Thu, 08 Nov 2012 11:31:24 -0500 From: Karen O'Donoghue Organization: ISOC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [saag] jose wg @ ietf85 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: odonoghue@isoc.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 16:31:21 -0000 The JOSE WG met on Wednesday at 9:00 am. The four core documents (JWA, JWE, JWK, JWS) have been updated addressing all the closed issues from the last IETF and some mailing list discussions. A number of remaining issues were discussed including header criticality, mandatory to implement, wrapped keys, and spi. Individuals were identified to work together to resolve these issues by the end of the year. The objective is to progress these four documents to WGLC by early 2013. Working group members are encouraged to take this opportunity to get final issues identified and on the mailing list. A number of potential additional work items were discussed. There was general agreement within the room to adopt these work items pending an update to the wg charter. These items include: - Use Cases (http://tools.ietf.org/id/draft-barnes-jose-use-cases-01.txt) - Serialization - W3C WebCrypto group request to define and standardize representations for private and symmetric keys From ekr@rtfm.com Thu Nov 8 09:48:07 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5964B21F8536 for ; Thu, 8 Nov 2012 09:48:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7CfeNPUWmtiY for ; Thu, 8 Nov 2012 09:48:07 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 92B5621F8533 for ; Thu, 8 Nov 2012 09:48:06 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id b11so2541220lam.31 for ; Thu, 08 Nov 2012 09:48:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=OoKpMhmP6gxvSXSWb75O5mdWdOAsyb5HVlf+FSPlVCM=; b=lxky8E5gOpP+qNGKeI0nOeHzIddrVKLSIoDNJ8naPHlYc79S8aPoVoEKlScoSyfcUZ sYcCQKkbDO1081jr8uVW5yFHo1v5RUaAxoZre+6QcOWITVK3Gut9H/3yO49I+f1ToRbH 9MULvxHi1nkDZys2KZutyMBXgZHlQwpGXAmoe4XrAM4JjIf7WbnwEgnfd/GarlhYrVUR RY9cRg1Y8uqGJm1BzpDAZIFpzNbE3Oisn9TfycqY0G7g7fDk75EkRJiLc2OOLf5pL8V7 hcT9H4kaUgGMsRap+zAAvH/BSebofW10ZsSJdkIENxgbBw8WXN3GSwBWUSjjyEcgW7ax LTPw== Received: by 10.152.105.44 with SMTP id gj12mr8357046lab.19.1352396885292; Thu, 08 Nov 2012 09:48:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.152.25.39 with HTTP; Thu, 8 Nov 2012 09:47:24 -0800 (PST) X-Originating-IP: [130.129.67.196] From: Eric Rescorla Date: Thu, 8 Nov 2012 12:47:24 -0500 Message-ID: To: saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmmv3ha9x7abaqeEC4WUAvQus4XuAlFyHLDxHdMg9z2a3YuVchqzeWpMsNZEHFIDZXHJwwK Subject: [saag] TLS WG Report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 17:48:07 -0000 The TLS WG met at 5:00 PM on Tuesday The following notes are drawn largely from Paul Hoffman's minutes. * TLS Cached Info draft (draft-ietf-tls-cached-info) In mailing list discussion afterwards, Stefan proposed some syntactic changes. We will need to discuss on the list. * The Certificate Status Extension (draft-ietf-tls-multiple-cert-status-extension) is ready for WGLC. * Out of Band Public key Validation ( draft-ietf-tls-oob-pubkey) There was some debate about whether we should be using the same mechanism/registry as RFC 6901. There was general consensus on the desired properties and a question about whether RFC 6091 could support it. EKR to analyze and report back. * We had a request from HTTPbis to take on a TLS-based upper-layer protocol negotiation mechanism. The WG agreed to take this on. * Origin Bound Certificates. Google has abandoned this in favor of a new approach and may bring that to IETF later. * We also had presentations about DTLS Multicast Security, TACK, and an AuthZ extension to use DTCP certificates in TLS. None of these have any immediate actions. -Ekr From paul.hoffman@vpnc.org Thu Nov 8 10:08:08 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CCFD21F84FC for ; Thu, 8 Nov 2012 10:08:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCeIeUJprjaQ for ; Thu, 8 Nov 2012 10:08:08 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id D1EE521F84D5 for ; Thu, 8 Nov 2012 10:08:07 -0800 (PST) Received: from dhcp-6045.meeting.ietf.org (dhcp-6045.meeting.ietf.org [130.129.96.69]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id qA8I83g5018992 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 8 Nov 2012 11:08:06 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <3C203CA9-F846-43C6-BD7E-83B33EAFF004@vpnc.org> Date: Thu, 8 Nov 2012 13:08:06 -0500 To: IETF Security Area Advisory Group Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [saag] IPsecME WG at IETF 85 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 18:08:08 -0000 The ad hoc VPN problem statement and scenarios document has stalled, = waiting for the authors to do a revision to meet comments from WG Last = Call. Once that happens, we'll verify that the document covers all the = outstanding comments and send it to the AD for IETF Last Call. The WG's other main document, running IKE over TCP, has gotten some = comments, particularly about NATs. The ECDSA design team sent their report to the mailing list, and a draft = will emerge soon. There was a discussion of replacing the RSA raw public key with a new = certificate type that handles other types of non-certificate key = containers. Dave McGrew presented his update to RFC 4835. The WG was interested in = the topic and will likely adopt this as a new WG work item. There were presentations on changes or profiles to IKEv2 to make it = smaller and easier to implement. We heard presentations on a couple of drafts that will most likely not = appear in the WG on multi-path IPsec, MIF security requirements, and an = operational issue with leakage over IPv6. --Paul Hoffman= From klaas@cisco.com Thu Nov 8 10:33:36 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A70A021F8433 for ; Thu, 8 Nov 2012 10:33:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5wLCDCqrQrFT for ; Thu, 8 Nov 2012 10:33:36 -0800 (PST) Received: from out45-ams.mf.surf.net (out45-ams.mf.surf.net [145.0.1.45]) by ietfa.amsl.com (Postfix) with ESMTP id C3A5C21F8431 for ; Thu, 8 Nov 2012 10:33:35 -0800 (PST) Received: from teletubbie.het.net.je (teletubbie.het.net.je [192.87.110.29]) by outgoing2-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id qA8IXQkL005167 for ; Thu, 8 Nov 2012 19:33:27 +0100 Received: from [2001:df8:0:16:21f:5bff:fe84:dc1] by teletubbie.het.net.je with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TWWph-0003xT-1J for saag@ietf.org; Thu, 08 Nov 2012 19:28:05 +0100 From: Klaas Wierenga Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 8 Nov 2012 19:33:24 +0100 Message-Id: To: saag@ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-Antivirus: no malware found X-Bayes-Prob: 0.0002 (Score 0, tokens from: @@RPTN) X-CanIt-Geo: ip=192.87.110.29; country=NL; latitude=52.5000; longitude=5.7500; http://maps.google.com/maps?q=52.5000,5.7500&z=6 X-CanItPRO-Stream: p-out:default (inherits from p:default,base:default) X-Canit-Stats-ID: 0vIl6xqU7 - 8182701c7e2d - 20121108 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Subject: [saag] abfab@ietf85 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 18:33:36 -0000 The abfab group met in Atlanta on Monday. The WG is making good progress. Core documents are on their way out the door. The WG is currently primarly discussing what to include in an updated EAP applicability statement and certain issues related to the AAA SAML binding. Leif & Klaas (abfab Chairs) From kathleen.moriarty@emc.com Thu Nov 8 10:58:10 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C466521F85CB for ; Thu, 8 Nov 2012 10:58:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFETmG455GXi for ; Thu, 8 Nov 2012 10:58:10 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1EDDF21F85B1 for ; Thu, 8 Nov 2012 10:58:09 -0800 (PST) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qA8Iw9eb030185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 8 Nov 2012 13:58:09 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor) for ; Thu, 8 Nov 2012 13:57:59 -0500 Received: from mxhub10.corp.emc.com (mxhub10.corp.emc.com [10.254.92.105]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qA8IvuHG029746 for ; Thu, 8 Nov 2012 13:57:56 -0500 Received: from mx15a.corp.emc.com ([169.254.1.83]) by mxhub10.corp.emc.com ([10.254.92.105]) with mapi; Thu, 8 Nov 2012 13:57:56 -0500 From: "Moriarty, Kathleen" To: "saag@ietf.org" Date: Thu, 8 Nov 2012 13:57:56 -0500 Thread-Topic: SACM BoF Summary Thread-Index: AQHNveL2gDmiDRcnVk2bmX+zkvkg9w== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [saag] SACM BoF Summary X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 18:58:10 -0000 SACM BoF -- Security Automation and Continuous Monitoring Tuesday morning BoF Chairs: Kathleen Moriarty & Dan Romascanu The SACM BoF went very well, providing an overview of the problem space and= proposed architecture for security automation and continuous monitoring (S= ACM). The set of drafts presented included some that have been previously = published through NIST and have been put into drafts. The work includes fo= rmats and protocols to represent assets, assess systems, map them to polici= es, and report. People mostly agree that the problem space is understood. There were 10 people who said they were willing to be editors and about 17 = reviewers. The consensus was to start from requirements and then develop an architectu= re to explain how the use cases can be met. The group has a fairly good un= derstanding of the problem space, but needs to document this and present it= more clearly with the requirements, then the architecture. These steps ne= ed to happen to progress the work. More detailed minutes should be posted soon.= From shanna@juniper.net Thu Nov 8 13:10:13 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22E3921F8AED for ; Thu, 8 Nov 2012 13:10:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.451 X-Spam-Level: X-Spam-Status: No, score=-103.451 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JqfdQPpVUXN8 for ; Thu, 8 Nov 2012 13:10:12 -0800 (PST) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id B8C6521F894D for ; Thu, 8 Nov 2012 13:10:06 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKUJwfrJaYAnNO3ODAdcCyHXb5VGWBHBYp@postini.com; Thu, 08 Nov 2012 13:10:08 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 8 Nov 2012 13:06:47 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Thu, 8 Nov 2012 13:06:47 -0800 Received: from CO9EHSOBE034.bigfish.com (207.46.163.27) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 8 Nov 2012 13:13:48 -0800 Received: from mail25-co9-R.bigfish.com (10.236.132.238) by CO9EHSOBE034.bigfish.com (10.236.130.97) with Microsoft SMTP Server id 14.1.225.23; Thu, 8 Nov 2012 21:06:46 +0000 Received: from mail25-co9 (localhost [127.0.0.1]) by mail25-co9-R.bigfish.com (Postfix) with ESMTP id 5D56EB8076C for ; Thu, 8 Nov 2012 21:06:46 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.234.117; KIP:(null); UIP:(null); (null); H:SN2PRD0510HT002.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: 4 X-BigFish: PS4(zzzz1de0h1202h1d1ah1d2ahzzz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0l1155h) Received: from mail25-co9 (localhost.localdomain [127.0.0.1]) by mail25-co9 (MessageSwitch) id 1352408804720461_2746; Thu, 8 Nov 2012 21:06:44 +0000 (UTC) Received: from CO9EHSMHS012.bigfish.com (unknown [10.236.132.243]) by mail25-co9.bigfish.com (Postfix) with ESMTP id AB88C5C0051 for ; Thu, 8 Nov 2012 21:06:44 +0000 (UTC) Received: from SN2PRD0510HT002.namprd05.prod.outlook.com (157.56.234.117) by CO9EHSMHS012.bigfish.com (10.236.130.22) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 8 Nov 2012 21:06:44 +0000 Received: from SN2PRD0510MB372.namprd05.prod.outlook.com ([169.254.12.27]) by SN2PRD0510HT002.namprd05.prod.outlook.com ([10.255.116.37]) with mapi id 14.16.0233.002; Thu, 8 Nov 2012 20:27:35 +0000 From: Stephen Hanna To: "saag@ietf.org" Thread-Topic: wpkops BOF report Thread-Index: Ac296N4rjhn99D7aTWWWhsplwz7pxAABbFxA Date: Thu, 8 Nov 2012 20:23:20 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: [saag] wpkops BOF report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 21:10:13 -0000 The Web PKI Operations BOF (wpkops) met on Monday afternoon. Although this BOF was technically in the OPS area, it is probably of interest to many people in the SEC area. Several presenters explained the mess that is the current web PKI. A draft WG charter was presented, proposing to document the widely-used parts of this mess so that the participants can know what to expect. Perhaps someone can even help make it a little better! But improvements to the web PKI are explicitly out of scope for this effort: only documentation of the status quo. The main topic discussed was whether user interface should be in scope. The consensus was that we should include functional documentation of the information provided to users about the web PKI and the actions they can take. With this agreement, there was strong consensus in the room that the problem statement is clear, well-scoped, solvable, and urgent. Plenty of editors are on board and about 20 people indicated that they would read the drafts and comment. So there was rough consensus that we should charter a working group in this area. From ajs@anvilwalrusden.com Thu Nov 8 13:57:59 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB34421F898E for ; Thu, 8 Nov 2012 13:57:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.83 X-Spam-Level: X-Spam-Status: No, score=-0.83 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5y04WDOlpzL for ; Thu, 8 Nov 2012 13:57:59 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 54FFE21F8904 for ; Thu, 8 Nov 2012 13:57:59 -0800 (PST) Received: from mx1.yitter.info (dhcp-13cd.meeting.ietf.org [130.129.19.205]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id EE4538A031 for ; Thu, 8 Nov 2012 21:57:57 +0000 (UTC) Date: Thu, 8 Nov 2012 16:57:51 -0500 From: Andrew Sullivan To: saag@ietf.org Message-ID: <20121108215751.GE78036@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [saag] DNSSEC key compromise draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 21:57:59 -0000 Dear colleagues, Since there was such discussion about key management issues at the meeting today, I thought I'd suggest that people might like to check a draft recently submitted on handling key compromise in DNSSEC. http://www.ietf.org/internet-drafts/draft-haikuo-ckds-01.txt Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From barryleiba.mailing.lists@gmail.com Fri Nov 9 05:41:36 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 417E421F8680 for ; Fri, 9 Nov 2012 05:41:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KupmzuPq9Aqc for ; Fri, 9 Nov 2012 05:41:32 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA4321F8621 for ; Fri, 9 Nov 2012 05:41:31 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id b11so3261587lam.31 for ; Fri, 09 Nov 2012 05:41:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=7rFiIiL2f4rtE2q6Fl/BNPc7XbklZ5YMUXlQiHvpfBI=; b=PpxBWx+h9F/PMtrDgk3EFFfHnG7lUIq8vw4MyoOvioioiK6tg27DrwSnGCHjhhVaiL NeiV71Zr3KfujUFTjstuMaJpxAp8VHoXR72UfC6mdy0/p1kJ2AzefTGsJ7uAZKdiQedP 7cGHWIcKaDeXl8Gg9eIz1y1/Ct6FyhRNzAyqhu+7bmq2vRjnYYUVUIVns4fCBBheSStF CGOo6mIXkCzZkmJ5p62fl3QjP2EsSvBlmbSrTmmL+WZ7m7e0yR8xOnPUmk9TUEsgHCUz 6teYuX0MBBuLn6oQPkXJmm8ON46cVPmkMU2dDPfFIeEaEL3bS20IquiGxAjNdwRu3uRC iXJA== MIME-Version: 1.0 Received: by 10.152.105.33 with SMTP id gj1mr10638019lab.49.1352468490554; Fri, 09 Nov 2012 05:41:30 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.54.167 with HTTP; Fri, 9 Nov 2012 05:41:30 -0800 (PST) In-Reply-To: References: <4B8D0A93-3838-4CDB-939B-1183718EFFFE@mnot.net> Date: Fri, 9 Nov 2012 08:41:30 -0500 X-Google-Sender-Auth: xCLazMsPLOP50Tz5D9-6awz-Lvs Message-ID: From: Barry Leiba To: saag Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [saag] Input for conflict review of draft-secure-cookie-session-protocol X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 13:41:36 -0000 I floated this about two weeks ago, and there've been no responses. This tells me that there is *not* interest in taking this document on in a working group, whether it be a revived httpstate WG, or the existing websec group, or whatever. It is on next week's telechat (15 Nov) for the IESG to decide how to respond to the Independent Stream Editor about the document. Unless we're convinced otherwise, I plan to propose the following for IESG approval: 1. The 5742 response is, "The IESG has concluded that this work is related to IETF work done in the websec and httpbis working groups, but this relationship does not prevent publishing." 2. The authors are asked to please add the company name to the title and introduction, to make it clear that this is their company's proposal, presented for the community's information. Barry > All that said, here's what I think, as the AD who's shepherding this > through the conflict review: > > 1. It's probably acceptable to do this through the ISE -- that is, > this probably does not *conflict* with IETF work. > > 2. It's probably better to do this through the IETF Stream -- it will > get better review and be a more solid document that way. > > 3. The authors are happy to do it that way; I've talked with them about it. > > 4. We could charter a new "son of httpstate" working group for this, > we could fit it into an existing working group (httpbis or appsawg, > likely), or we could do it as an AD-sponsored document (I would be > happy to sponsor it, and I suspect Stephen would also). If we did > that, it would go as Proposed Standard ... or we could let it > continue through the Independent Stream, as Informational. > > Thoughts? From touch@isi.edu Tue Nov 13 14:16:26 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25C2721F87B0 for ; Tue, 13 Nov 2012 14:16:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.33 X-Spam-Level: X-Spam-Status: No, score=-103.33 tagged_above=-999 required=5 tests=[AWL=-0.731, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id odn8aEVOlCrD for ; Tue, 13 Nov 2012 14:16:25 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 87A8021F86D3 for ; Tue, 13 Nov 2012 14:16:25 -0800 (PST) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id qADMG4jh005949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 13 Nov 2012 14:16:07 -0800 (PST) Message-ID: <50A2C6A3.7090700@isi.edu> Date: Tue, 13 Nov 2012 14:16:03 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Paul Hoffman References: <9B93EFAD-AD9B-4402-8CC2-79239EB3DF2E@vpnc.org> In-Reply-To: <9B93EFAD-AD9B-4402-8CC2-79239EB3DF2E@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: IETF Security Area Advisory Group Subject: Re: [saag] Revision of "Attacks on Cryptographic Hashes in Internet Protocols" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 22:16:26 -0000 Hi, Paul (et al.), This doc refers to IETF protocols that use hashes, but doesn't discuss any in specific. It also doesn't address how hashes are used, e.g., solo (as a fingerprint), keyed (for authentication and source confirmation), as part of an HMAC, or as part of key derivation. That sort of information might be additionally useful, IMO. Joe On 11/8/2012 4:29 AM, Paul Hoffman wrote: > Greetings again. Bruce Schneier and I have started an update to RFC 4270, "Attacks on Cryptographic Hashes in Internet Protocols". This revision is meant to deal with new and more devastating attacks on MD5, the fact that SHA-1 collisions will be financially feasible in the foreseeable future, and NIST's upcoming SHA-3 announcements. We expect to keep this revision process open for at least five months because NIST probably won't finalize the parameters and naming and so on for KECCAK until then; that is, we won't send this to RFC Editor until SHA-3 is finalized. Please take a look at > > http://tools.ietf.org/html/draft-hoffman-schneier-4270bis > > Sean and Stephen have agreed that we should use the SAAG mailing list for discussing this draft. > > --Paul Hoffman > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From murugiah.souppaya@nist.gov Fri Nov 9 11:05:05 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C512B21F858F for ; Fri, 9 Nov 2012 11:05:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.942 X-Spam-Level: X-Spam-Status: No, score=-5.942 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZgC5wxyY+8G for ; Fri, 9 Nov 2012 11:05:05 -0800 (PST) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id C956721F8550 for ; Fri, 9 Nov 2012 11:05:04 -0800 (PST) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.421.2; Fri, 9 Nov 2012 14:04:32 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Fri, 9 Nov 2012 14:04:41 -0500 From: "Souppaya, Murugiah" To: "'saag@ietf.org'" Date: Fri, 9 Nov 2012 14:03:35 -0500 Thread-Topic: Third-Round Report of the SHA-3 Cryptographic Hash Algorithm Competition Thread-Index: Ac2+qqOrqSP4+yK0Q7K+sfsW1i242gAAkdmb Message-ID: <0E35EA7C29BC734CB7072D14B0A613FD40FF569174@MBCLUSTER.xchange.nist.gov> 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_0E35EA7C29BC734CB7072D14B0A613FD40FF569174MBCLUSTERxcha_" MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 13 Nov 2012 15:42:57 -0800 Subject: [saag] Fw: Third-Round Report of the SHA-3 Cryptographic Hash Algorithm Competition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 19:05:05 -0000 --_000_0E35EA7C29BC734CB7072D14B0A613FD40FF569174MBCLUSTERxcha_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnlpDQoNCg0KRnJvbTogQ2Fzd2VsbCwgU2FyYSBKLiBbbWFpbHRvOnNhcmEuY2Fzd2VsbEBuaXN0 Lmdvdl0NClNlbnQ6IEZyaWRheSwgTm92ZW1iZXIgMDksIDIwMTIgMDE6NDYgUE0NClRvOiBIQVNI LUZPUlVNDQpTdWJqZWN0OiBUaGlyZC1Sb3VuZCBSZXBvcnQgb2YgdGhlIFNIQS0zIENyeXB0b2dy YXBoaWMgSGFzaCBBbGdvcml0aG0gQ29tcGV0aXRpb24NCg0KDQpUaGlyZC1Sb3VuZCBSZXBvcnQg b2YgdGhlIFNIQS0zIENyeXB0b2dyYXBoaWMgSGFzaCBBbGdvcml0aG0gQ29tcGV0aXRpb24gaXMg bm93IGF2YWlsYWJsZSENCg0KDQoNCk9uIE9jdG9iZXIgMiwgMjAxMiwgTklTVCBhbm5vdW5jZWQg S2VjY2FrIGFzIHRoZSB3aW5uZXIgb2YgdGhlIFNIQS0zIENvbXBldGl0aW9uLiBUaGUgc2VsZWN0 aW9uIHByb2Nlc3MgZm9yIHRoZSB0aGlyZCBhbmQgZmluYWwgcm91bmQgb2YgdGhlIGNvbXBldGl0 aW9uIGlzIHN1bW1hcml6ZWQgaW4gTklTVCBJbnRlcmFnZW5jeSBSZXBvcnQgKElSKSA3ODk2LCBU aGlyZC1Sb3VuZCBSZXBvcnQgb2YgdGhlIFNIQS0zIENyeXB0b2dyYXBoaWMgSGFzaCBBbGdvcml0 aG0gQ29tcGV0aXRpb24uIDxodHRwOi8vY3NyYy5uaXN0Lmdvdi9ncm91cHMvU1QvaGFzaC9zaGEt My9Sb3VuZDMvZG9jdW1lbnRzL1JvdW5kM19SZXBvcnRfTklTVElSXzc4OTYucGRmPg0KDQoNCg0K DQoNCihUaGUgRE9JIHJlZmVyZW5jZSBsaW5rIG9uIHRoZSBjb3ZlciBwYWdlIG9mIHRoZSByZXBv cnQgbWF5IG5vdCBiZSBhdmFpbGFibGUgcmlnaHQgYXdheS4pDQoNCg== --_000_0E35EA7C29BC734CB7072D14B0A613FD40FF569174MBCLUSTERxcha_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXVzLWFzY2lpIj48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250 ZW50PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8q IEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4 dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQg Q2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uUGxh aW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN Cgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tVVMg bGluaz1ibHVlIHZsaW5rPXB1cnBsZT48Zm9udCBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+DQpGeWk8YnI+PC9mb250Pjxicj4mbmJzcDs8YnI+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8Zm9udCBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+DQo8Yj5Gcm9tPC9iPjogQ2Fz d2VsbCwgU2FyYSBKLiBbbWFpbHRvOnNhcmEuY2Fzd2VsbEBuaXN0Lmdvdl0NPGJyPjxiPlNlbnQ8 L2I+OiBGcmlkYXksIE5vdmVtYmVyIDA5LCAyMDEyIDAxOjQ2IFBNPGJyPjxiPlRvPC9iPjogSEFT SC1GT1JVTQ08YnI+PGI+U3ViamVjdDwvYj46IFRoaXJkLVJvdW5kIFJlcG9ydCBvZiB0aGUgU0hB LTMgQ3J5cHRvZ3JhcGhpYyBIYXNoIEFsZ29yaXRobSBDb21wZXRpdGlvbg08YnI+PC9mb250PiZu YnNwOzxicj48L2Rpdj4NCjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb1BsYWlu VGV4dD48Yj5UaGlyZC1Sb3VuZCBSZXBvcnQgb2YgdGhlIFNIQS0zIENyeXB0b2dyYXBoaWMgSGFz aCBBbGdvcml0aG0gQ29tcGV0aXRpb24gaXMgbm93IGF2YWlsYWJsZSE8bzpwPjwvbzpwPjwvYj48 L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1z b1BsYWluVGV4dD5PbiBPY3RvYmVyIDIsIDIwMTIsIE5JU1QgYW5ub3VuY2VkIEtlY2NhayBhcyB0 aGUgd2lubmVyIG9mIHRoZSBTSEEtMyBDb21wZXRpdGlvbi4gVGhlIHNlbGVjdGlvbiBwcm9jZXNz IGZvciB0aGUgdGhpcmQgYW5kIGZpbmFsIHJvdW5kIG9mIHRoZSBjb21wZXRpdGlvbiBpcyBzdW1t YXJpemVkIGluIE5JU1QgSW50ZXJhZ2VuY3kgUmVwb3J0IChJUikgNzg5NiwgVGhpcmQtUm91bmQg UmVwb3J0IG9mIHRoZSBTSEEtMyBDcnlwdG9ncmFwaGljIEhhc2ggQWxnb3JpdGhtIENvbXBldGl0 aW9uLjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz4gPC9zcGFuPiZsdDs8YSBocmVmPSJodHRw Oi8vY3NyYy5uaXN0Lmdvdi9ncm91cHMvU1QvaGFzaC9zaGEtMy9Sb3VuZDMvZG9jdW1lbnRzL1Jv dW5kM19SZXBvcnRfTklTVElSXzc4OTYucGRmIj5odHRwOi8vY3NyYy5uaXN0Lmdvdi9ncm91cHMv U1QvaGFzaC9zaGEtMy9Sb3VuZDMvZG9jdW1lbnRzL1JvdW5kM19SZXBvcnRfTklTVElSXzc4OTYu cGRmPC9hPiZndDs8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PG86cD4mbmJz cDs8L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxw IGNsYXNzPU1zb1BsYWluVGV4dD48aT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+KFRo ZSBET0kgcmVmZXJlbmNlIGxpbmsgb24gdGhlIGNvdmVyIHBhZ2Ugb2YgdGhlIHJlcG9ydCBtYXkg bm90IGJlIGF2YWlsYWJsZSByaWdodCBhd2F5Lik8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48L2JvZHk+PC9odG1s Pg== --_000_0E35EA7C29BC734CB7072D14B0A613FD40FF569174MBCLUSTERxcha_-- From paul.hoffman@vpnc.org Tue Nov 13 20:24:23 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3CC21F84CE for ; Tue, 13 Nov 2012 20:24:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gaMO+-3o27U for ; Tue, 13 Nov 2012 20:24:23 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 57EF221F84C7 for ; Tue, 13 Nov 2012 20:24:21 -0800 (PST) Received: from wsip-24-120-140-174.lv.lv.cox.net (wsip-24-120-140-174.lv.lv.cox.net [24.120.140.174]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id qAE4OFot095546 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 13 Nov 2012 21:24:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: <50A2C6A3.7090700@isi.edu> Date: Tue, 13 Nov 2012 20:24:19 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9B93EFAD-AD9B-4402-8CC2-79239EB3DF2E@vpnc.org> <50A2C6A3.7090700@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1499) Cc: IETF Security Area Advisory Group Subject: Re: [saag] Revision of "Attacks on Cryptographic Hashes in Internet Protocols" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 04:24:23 -0000 On Nov 13, 2012, at 2:16 PM, Joe Touch wrote: > This doc refers to IETF protocols that use hashes, but doesn't discuss = any in specific. It also doesn't address how hashes are used, e.g., solo = (as a fingerprint), keyed (for authentication and source confirmation), = as part of an HMAC, or as part of key derivation. >=20 > That sort of information might be additionally useful, IMO. The opposite was decided when we did RFC 4270, of which this is a direct = revision. Many protocols use hashes in multiple ways, and trying to list = them was considered a distraction. I believe that is still the case. --Paul Hoffman= From touch@isi.edu Tue Nov 13 23:35:30 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95D7E21F8468 for ; Tue, 13 Nov 2012 23:35:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.785 X-Spam-Level: X-Spam-Status: No, score=-103.785 tagged_above=-999 required=5 tests=[AWL=-1.186, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttulvZSqIdyw for ; Tue, 13 Nov 2012 23:35:30 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 24BB321F8456 for ; Tue, 13 Nov 2012 23:35:30 -0800 (PST) Received: from [192.168.1.94] (pool-71-105-94-82.lsanca.dsl-w.verizon.net [71.105.94.82]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id qAE7Z4UQ000098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 13 Nov 2012 23:35:07 -0800 (PST) Message-ID: <50A349A8.7090903@isi.edu> Date: Tue, 13 Nov 2012 23:35:04 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Paul Hoffman References: <9B93EFAD-AD9B-4402-8CC2-79239EB3DF2E@vpnc.org> <50A2C6A3.7090700@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: IETF Security Area Advisory Group Subject: Re: [saag] Revision of "Attacks on Cryptographic Hashes in Internet Protocols" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 07:35:30 -0000 On 11/13/2012 8:24 PM, Paul Hoffman wrote: > On Nov 13, 2012, at 2:16 PM, Joe Touch wrote: > >> This doc refers to IETF protocols that use hashes, but doesn't discuss any in specific. It also doesn't address how hashes are used, e.g., solo (as a fingerprint), keyed (for authentication and source confirmation), as part of an HMAC, or as part of key derivation. >> >> That sort of information might be additionally useful, IMO. > > The opposite was decided when we did RFC 4270, of which this is a direct revision. Many protocols use hashes in multiple ways, and trying to list them was considered a distraction. I believe that is still the case. The doc says directly that the way in which specific hashes are used in "many" Internet protocols is safe. Indicating the details of that claim is critical to it having *any* weight. Further, there's a big difference in the way in which hashes are used which can be just as important as the use of "better hash algorithms" Leaving the interpretation of this doc as an exercise to the reader renders it inconsequential. Joe From mcgrew@cisco.com Wed Nov 14 05:14:36 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE37F21F85E1 for ; Wed, 14 Nov 2012 05:14:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJ2MlmUS5xn0 for ; Wed, 14 Nov 2012 05:14:36 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 0562021F85DA for ; Wed, 14 Nov 2012 05:14:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3277; q=dns/txt; s=iport; t=1352898876; x=1354108476; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=+nz///41PT3htrU7A/mLCRckEsGcdFHsSgq55lqnI9w=; b=A5RrHSI78K3HInBnv/H7hPueLjf/OxprhHJK8dfgvBXCb5kkRO7YWL42 Ixg5q2Nj6fPvludtZy4hL/WQibcDYui9L/tbmAtiAP3zmc4Gn9Sd5GsIR aQ303a2fMx59df6iuOQJSRBr5ewjFgJ4v9C8H6em9r792BXIcJ0ww7bjN c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALeYo1CtJV2a/2dsb2JhbABEDsMvgQiCHgEBAQQBAQEPASc0CxIBCBgKFDcLJQIEAQ0FCBqHaAuacKAOjC2FS2EDlxiNPIFrgjI9ghk X-IronPort-AV: E=McAfee;i="5400,1158,6895"; a="139275762" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 14 Nov 2012 13:14:35 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qAEDEZr6018571 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 Nov 2012 13:14:35 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.001; Wed, 14 Nov 2012 07:14:35 -0600 From: "David McGrew (mcgrew)" To: Joe Touch , Paul Hoffman Thread-Topic: [saag] Revision of "Attacks on Cryptographic Hashes in Internet Protocols" Thread-Index: AQHNweyKBFECjqGD4EK+xvmKz2CDQJfpYOIA Date: Wed, 14 Nov 2012 13:14:34 +0000 Message-ID: <747787E65E3FBD4E93F0EB2F14DB556B0F50B73B@xmb-rcd-x04.cisco.com> In-Reply-To: <50A2C6A3.7090700@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.117.10.228] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19364.000 x-tm-as-result: No--43.062700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <3CFB2AEAE017C744857BF09809491A62@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF Security Area Advisory Group Subject: Re: [saag] Revision of "Attacks on Cryptographic Hashes in Internet Protocols" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 13:14:37 -0000 Hi Joe and Paul, On 11/13/12 5:16 PM, "Joe Touch" wrote: >Hi, Paul (et al.), > >This doc refers to IETF protocols that use hashes, but doesn't discuss >any in specific. It also doesn't address how hashes are used, e.g., solo >(as a fingerprint), keyed (for authentication and source confirmation), >as part of an HMAC, or as part of key derivation. > >That sort of information might be additionally useful, IMO. I think you (Joe) have a valid point about how the draft could be improved, though the draft does address the use question somewhat (it even has a section on "How Internet Protocols Use Hash Algorithms"). I have a suggestion: the draft could 1) more precisely define the different ways that hash functions are used in more detail (in signatures, in HMAC, KDFs, other message authentication codes, integrity checking, ...) The definitions should be clear enough that a relative crypto novice, looking at a specification that describes a use of a hash function, could correctly categorize that use. 2) relate the security of each use case to the collision/first preimage/second preimage attacks 3) have a section that describes uses of hash functions in Internet protocols that rely on collision resistance. (My thinking here is that there are many uses of hash functions, and so we should focus on the most security critical cases) If we had an RFC with these clear categories in them, then we could categorize new uses of hash functions that appear in new drafts, perhaps focusing on the cases where collision resistance is required. This could be part of the SECDIR review process, or perhaps some other independent process (for instance, send an automatic message to the authors pointing out the hash function in their draft and the categories in the RFC). Yes, I realize that there are a lot of of RFC and drafts using hash functions, and that this is a non-trivial amount of work. But consider how much better off we would be now if we had started categorizing uses of hash functions in RFCs back in y2k ... What do you think? David > >Joe > >On 11/8/2012 4:29 AM, Paul Hoffman wrote: >> Greetings again. Bruce Schneier and I have started an update to RFC >>4270, "Attacks on Cryptographic Hashes in Internet Protocols". This >>revision is meant to deal with new and more devastating attacks on MD5, >>the fact that SHA-1 collisions will be financially feasible in the >>foreseeable future, and NIST's upcoming SHA-3 announcements. We expect >>to keep this revision process open for at least five months because NIST >>probably won't finalize the parameters and naming and so on for KECCAK >>until then; that is, we won't send this to RFC Editor until SHA-3 is >>finalized. Please take a look at >> >> http://tools.ietf.org/html/draft-hoffman-schneier-4270bis >> >> Sean and Stephen have agreed that we should use the SAAG mailing list >>for discussing this draft. >> >> --Paul Hoffman >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >> >_______________________________________________ >saag mailing list >saag@ietf.org >https://www.ietf.org/mailman/listinfo/saag From openpgp@brainhub.org Wed Nov 14 13:41:34 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB7C21F84E2 for ; Wed, 14 Nov 2012 13:41:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6WwqHG7E7QX3 for ; Wed, 14 Nov 2012 13:41:33 -0800 (PST) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by ietfa.amsl.com (Postfix) with ESMTP id D1DBC21F8490 for ; Wed, 14 Nov 2012 13:41:33 -0800 (PST) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta01.emeryville.ca.mail.comcast.net with comcast id PR1c1k0071u4NiLA1ZhZ3Q; Wed, 14 Nov 2012 21:41:33 +0000 Received: from [127.0.0.1] ([69.181.162.123]) by omta21.emeryville.ca.mail.comcast.net with comcast id PZhY1k00A2g33ZR8hZhYgF; Wed, 14 Nov 2012 21:41:33 +0000 Message-ID: <50A40FC8.8080602@brainhub.org> Date: Wed, 14 Nov 2012 13:40:24 -0800 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 MIME-Version: 1.0 To: IETF Security Area Advisory Group References: <9B93EFAD-AD9B-4402-8CC2-79239EB3DF2E@vpnc.org> In-Reply-To: <9B93EFAD-AD9B-4402-8CC2-79239EB3DF2E@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [saag] Revision of "Attacks on Cryptographic Hashes in Internet Protocols" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 21:41:34 -0000 On 11/08/2012 04:29 AM, Paul Hoffman wrote: > Greetings again. Bruce Schneier and I have started an update to RFC 4270, "Attacks on Cryptographic Hashes in Internet Protocols". This revision is meant to deal with new and more devastating attacks on MD5, the fact that SHA-1 collisions will be financially feasible in the foreseeable future, and NIST's upcoming SHA-3 announcements. We expect to keep this revision process open for at least five months because NIST probably won't finalize the parameters and naming and so on for KECCAK until then; that is, we won't send this to RFC Editor until SHA-3 is finalized. Please take a look at > > http://tools.ietf.org/html/draft-hoffman-schneier-4270bis > > Sean and Stephen have agreed that we should use the SAAG mailing list for discussing this draft. > > --Paul Hoffman One issue stands out for me in this excellent overview: the document suggests the preference of SHA-2 over the SHA-3 (Keccak), as in the following paragraph: > The authors acknowledge that deprecating a hash algorithm is > difficult from an operational standpoint, but it needs to be done > eventually, and this is a good time to again make a significant push > to SHA-2. When NIST finalizes the parameters and test vectors for > SHA-3, implementors might want to start adding SHA-3 to their > products. However, the authors do not believe that any push to start > using SHA-3 is warranted at any time soon. SHA-2 is well-supported today, but there are no solid reasons why SHA-3 will not be supported equally well in the future. AES was not the fastest algorithm in software, but look what Intel did to it with the AESNI. Keccak is outstanding in hardware and perhaps on less mainstream CPU architectures (can't beat table lookup + XOR as min. instruction set). Keccak is arguably the simplest standard hash algorithm, quite comparable to the simplicity of MD5. As the computing environment gets more diverse, this will increase the value of Keccak. I support the algorithm agility, but it's not as easy to accomplish for the hash algorithms than, for example, for the encryption preferences. Let's say there is a protocols that is hardwired to SHA1 or MD5. Are we telling people thinking about its improvement to go with the SHA-2? What about newly designed protocols? If you are a maintainer, what would you prefer: worry about explaining to others that "my SHA-2 use doesn't depend on collision resistance and is not vulnerable to extension attacks", v.s. I "use SHA-3". I suggest that the document at least softens the statements on SHA-2 v.s. SHA-3. Ideally, I would like to see a path on which we move to the universally supported SHA-3 and, hopefully, the hardware manufacturers are comfortable to jump in. Thank you. From paul.hoffman@vpnc.org Wed Nov 14 14:33:43 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33FA421F8809 for ; Wed, 14 Nov 2012 14:33:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.505 X-Spam-Level: X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epOFg2vavkau for ; Wed, 14 Nov 2012 14:33:42 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id A4C0C21F86D1 for ; Wed, 14 Nov 2012 14:33:42 -0800 (PST) Received: from [10.20.30.102] (50-0-66-243.dsl.dynamic.fusionbroadband.com [50.0.66.243]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id qAEMXdax031994 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 14 Nov 2012 15:33:39 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: <50A40FC8.8080602@brainhub.org> Date: Wed, 14 Nov 2012 14:33:43 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <9BE0FD3C-F9CE-492E-A64C-D7CFB7961D3C@vpnc.org> References: <9B93EFAD-AD9B-4402-8CC2-79239EB3DF2E@vpnc.org> <50A40FC8.8080602@brainhub.org> To: Andrey Jivsov X-Mailer: Apple Mail (2.1499) Cc: IETF Security Area Advisory Group Subject: Re: [saag] Revision of "Attacks on Cryptographic Hashes in Internet Protocols" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 22:33:43 -0000 On Nov 14, 2012, at 1:40 PM, Andrey Jivsov wrote: > SHA-2 is well-supported today, but there are no solid reasons why = SHA-3 will not be supported equally well in the future. In that future, we can re-look at support for it in IETF protocols. For = now, algorithm agility might be sufficient. > Let's say there is a protocols that is hardwired to SHA1 or MD5. Are = we telling people thinking about its improvement to go with the SHA-2? Yes. > What about newly designed protocols? The same. > If you are a maintainer, what would you prefer: worry about explaining = to others that "my SHA-2 use doesn't depend on collision resistance and = is not vulnerable to extension attacks", v.s. I "use SHA-3". Nowhere did we say that you should not use SHA-3. In fact, we said the = opposite. We said there was no need to push that. > I suggest that the document at least softens the statements on SHA-2 = v.s. SHA-3. Ideally, I would like to see a path on which we move to the = universally supported SHA-3 and, hopefully, the hardware manufacturers = are comfortable to jump in. That's one view; we took a different one. So far, we have had good = support in the IETF community for our view, but at some point that might = change. --Paul Hoffman= From paul.hoffman@vpnc.org Wed Nov 14 14:37:42 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFCA121F884E for ; Wed, 14 Nov 2012 14:37:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7Fv-jrGC4t8 for ; Wed, 14 Nov 2012 14:37:42 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2E73F21F884D for ; Wed, 14 Nov 2012 14:37:42 -0800 (PST) Received: from [10.20.30.102] (50-0-66-243.dsl.dynamic.fusionbroadband.com [50.0.66.243]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id qAEMbdZb032082 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 14 Nov 2012 15:37:40 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: <747787E65E3FBD4E93F0EB2F14DB556B0F50B73B@xmb-rcd-x04.cisco.com> Date: Wed, 14 Nov 2012 14:37:45 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <747787E65E3FBD4E93F0EB2F14DB556B0F50B73B@xmb-rcd-x04.cisco.com> To: David McGrew (mcgrew) X-Mailer: Apple Mail (2.1499) Cc: IETF Security Area Advisory Group Subject: Re: [saag] Revision of "Attacks on Cryptographic Hashes in Internet Protocols" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 22:37:42 -0000 On Nov 14, 2012, at 5:14 AM, David McGrew (mcgrew) = wrote: > I think you (Joe) have a valid point about how the draft could be > improved, though the draft does address the use question somewhat (it = even > has a section on "How Internet Protocols Use Hash Algorithms"). Yes, it does. > I have a suggestion: the draft could >=20 > 1) more precisely define the different ways that hash functions are = used > in more detail (in signatures, in HMAC, KDFs, other message = authentication > codes, integrity checking, ...) The definitions should be clear = enough > that a relative crypto novice, looking at a specification that = describes a > use of a hash function, could correctly categorize that use. Proposed wording would be greatly appreciated here. I cannot see how to = add that text and have it be anything other than singing to the choir. > 2) relate the security of each use case to the collision/first > preimage/second preimage attacks Ditto here. When we tried this seven years ago, we were attacked for = being to restrictive in our descriptions. Seriously: if you have a = contribution to make that you think is readable to a relative crypto = novice and still accurate, we're all ears. > 3) have a section that describes uses of hash functions in Internet > protocols that rely on collision resistance. (My thinking here is = that > there are many uses of hash functions, and so we should focus on the = most > security critical cases) We thought we had that in the existing RFC and the current draft. Which = other protocols are you thinking of? --Paul Hoffman From openpgp@brainhub.org Wed Nov 14 15:36:53 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9887421F85B3 for ; Wed, 14 Nov 2012 15:36:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2HrKxsk48+i5 for ; Wed, 14 Nov 2012 15:36:53 -0800 (PST) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:243]) by ietfa.amsl.com (Postfix) with ESMTP id 32BF921F84EC for ; Wed, 14 Nov 2012 15:36:53 -0800 (PST) Received: from omta08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by qmta13.emeryville.ca.mail.comcast.net with comcast id PZPp1k0040FhH24ADbct0q; Wed, 14 Nov 2012 23:36:53 +0000 Received: from [127.0.0.1] ([69.181.162.123]) by omta08.emeryville.ca.mail.comcast.net with comcast id Pbcr1k00G2g33ZR8UbcsQX; Wed, 14 Nov 2012 23:36:52 +0000 Message-ID: <50A42ACF.80208@brainhub.org> Date: Wed, 14 Nov 2012 15:35:43 -0800 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 MIME-Version: 1.0 To: Paul Hoffman References: <9B93EFAD-AD9B-4402-8CC2-79239EB3DF2E@vpnc.org> <50A40FC8.8080602@brainhub.org> <9BE0FD3C-F9CE-492E-A64C-D7CFB7961D3C@vpnc.org> In-Reply-To: <9BE0FD3C-F9CE-492E-A64C-D7CFB7961D3C@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF Security Area Advisory Group Subject: Re: [saag] Revision of "Attacks on Cryptographic Hashes in Internet Protocols" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 23:36:53 -0000 On 11/14/2012 02:33 PM, Paul Hoffman wrote: > On Nov 14, 2012, at 1:40 PM, Andrey Jivsov wrote: > >> SHA-2 is well-supported today, but there are no solid reasons why SHA-3 will not be supported equally well in the future. > > In that future, we can re-look at support for it in IETF protocols. For now, algorithm agility might be sufficient. I would agree, but the document such as RFC 4270 influence the future. If the message it sends is that the SHA-3 is an odd bifurcation in the SHA line, SHA-3 won't gain critical mass. >> Let's say there is a protocols that is hardwired to SHA1 or MD5. Are we telling people thinking about its improvement to go with the SHA-2? > > Yes. > >> What about newly designed protocols? > > The same. > >> If you are a maintainer, what would you prefer: worry about explaining to others that "my SHA-2 use doesn't depend on collision resistance and is not vulnerable to extension attacks", v.s. I "use SHA-3". > > Nowhere did we say that you should not use SHA-3. In fact, we said the opposite. We said there was no need to push that. > >> I suggest that the document at least softens the statements on SHA-2 v.s. SHA-3. Ideally, I would like to see a path on which we move to the universally supported SHA-3 and, hopefully, the hardware manufacturers are comfortable to jump in. > > That's one view; we took a different one. So far, we have had good support in the IETF community for our view, but at some point that might change. > It would be useful for me and others to see more details behind the arguments that the SHA-2 is preferred to SHA-3 at IETF. I suspect there are a lot of assumptions here that may not apply to every particular case. One of the parameters is the timeline. The transition to a new hash algorithm may take years in protocols and formats without algorithm agility, while the plans for which route to take are being made today. For example, in OpenPGP there is a hardwired SHA1 fingerprint. It still seems wrong to me to move to SHA-2 and not SHA-3. I am leaning toward non-agile solution here because of space constrains and the fact that the agility will only be a benefit if Keccak is broken (so instead of adding SHA-2 + agility, add hardwired SHA-3 which is good for a few decades, at least). From paul.hoffman@vpnc.org Wed Nov 14 15:42:52 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBFE921F862A for ; Wed, 14 Nov 2012 15:42:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8GZ7hGQrYEn for ; Wed, 14 Nov 2012 15:42:52 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 45E1721F85DF for ; Wed, 14 Nov 2012 15:42:52 -0800 (PST) Received: from [10.20.30.102] (50-0-66-243.dsl.dynamic.fusionbroadband.com [50.0.66.243]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id qAENglhk034053 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 14 Nov 2012 16:42:47 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: <50A42ACF.80208@brainhub.org> Date: Wed, 14 Nov 2012 15:42:52 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <75F9A834-CA86-4551-A0D9-382EBEBBD04C@vpnc.org> References: <9B93EFAD-AD9B-4402-8CC2-79239EB3DF2E@vpnc.org> <50A40FC8.8080602@brainhub.org> <9BE0FD3C-F9CE-492E-A64C-D7CFB7961D3C@vpnc.org> <50A42ACF.80208@brainhub.org> To: Andrey Jivsov X-Mailer: Apple Mail (2.1499) Cc: IETF Security Area Advisory Group Subject: Re: [saag] Revision of "Attacks on Cryptographic Hashes in Internet Protocols" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 23:42:53 -0000 On Nov 14, 2012, at 3:35 PM, Andrey Jivsov wrote: > On 11/14/2012 02:33 PM, Paul Hoffman wrote: >> On Nov 14, 2012, at 1:40 PM, Andrey Jivsov = wrote: >>=20 >>> SHA-2 is well-supported today, but there are no solid reasons why = SHA-3 will not be supported equally well in the future. >>=20 >> In that future, we can re-look at support for it in IETF protocols. = For now, algorithm agility might be sufficient. >=20 > I would agree, but the document such as RFC 4270 influence the future. = If the message it sends is that the SHA-3 is an odd bifurcation in the = SHA line, SHA-3 won't gain critical mass. If we have suggested that in the draft, we should change the text. Can = you say where you got that feeling? >>> Let's say there is a protocols that is hardwired to SHA1 or MD5. Are = we telling people thinking about its improvement to go with the SHA-2? >>=20 >> Yes. >>=20 >>> What about newly designed protocols? >>=20 >> The same. >>=20 >>> If you are a maintainer, what would you prefer: worry about = explaining to others that "my SHA-2 use doesn't depend on collision = resistance and is not vulnerable to extension attacks", v.s. I "use = SHA-3". >>=20 >> Nowhere did we say that you should not use SHA-3. In fact, we said = the opposite. We said there was no need to push that. >>=20 >>> I suggest that the document at least softens the statements on SHA-2 = v.s. SHA-3. Ideally, I would like to see a path on which we move to the = universally supported SHA-3 and, hopefully, the hardware manufacturers = are comfortable to jump in. >>=20 >> That's one view; we took a different one. So far, we have had good = support in the IETF community for our view, but at some point that might = change. >>=20 >=20 > It would be useful for me and others to see more details behind the = arguments that the SHA-2 is preferred to SHA-3 at IETF. I suspect there = are a lot of assumptions here that may not apply to every particular = case. Instead of speaking for others, I'll let them chime in here. > One of the parameters is the timeline. The transition to a new hash = algorithm may take years in protocols and formats without algorithm = agility, while the plans for which route to take are being made today. Noted. > For example, in OpenPGP there is a hardwired SHA1 fingerprint. It = still seems wrong to me to move to SHA-2 and not SHA-3. I am leaning = toward non-agile solution here because of space constrains and the fact = that the agility will only be a benefit if Keccak is broken (so instead = of adding SHA-2 + agility, add hardwired SHA-3 which is good for a few = decades, at least). The OpenPGP people can speak for themselves; I certainly don't represent = them. --Paul Hoffman From openpgp@brainhub.org Wed Nov 14 16:35:01 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B069B21F86E4 for ; Wed, 14 Nov 2012 16:35:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQS9nsekbEd3 for ; Wed, 14 Nov 2012 16:35:01 -0800 (PST) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:32]) by ietfa.amsl.com (Postfix) with ESMTP id 4144221F85EB for ; Wed, 14 Nov 2012 16:35:01 -0800 (PST) Received: from omta24.emeryville.ca.mail.comcast.net ([76.96.30.92]) by qmta03.emeryville.ca.mail.comcast.net with comcast id PRgp1k0031zF43QA3cb10Q; Thu, 15 Nov 2012 00:35:01 +0000 Received: from [127.0.0.1] ([69.181.162.123]) by omta24.emeryville.ca.mail.comcast.net with comcast id Pcaz1k00U2g33ZR8kcb0cw; Thu, 15 Nov 2012 00:35:00 +0000 Message-ID: <50A43870.6000605@brainhub.org> Date: Wed, 14 Nov 2012 16:33:52 -0800 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 MIME-Version: 1.0 To: Paul Hoffman References: <9B93EFAD-AD9B-4402-8CC2-79239EB3DF2E@vpnc.org> <50A40FC8.8080602@brainhub.org> <9BE0FD3C-F9CE-492E-A64C-D7CFB7961D3C@vpnc.org> <50A42ACF.80208@brainhub.org> <75F9A834-CA86-4551-A0D9-382EBEBBD04C@vpnc.org> In-Reply-To: <75F9A834-CA86-4551-A0D9-382EBEBBD04C@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF Security Area Advisory Group Subject: Re: [saag] Revision of "Attacks on Cryptographic Hashes in Internet Protocols" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 00:35:01 -0000 On 11/14/2012 03:42 PM, Paul Hoffman wrote: > On Nov 14, 2012, at 3:35 PM, Andrey Jivsov wrote: > >> On 11/14/2012 02:33 PM, Paul Hoffman wrote: >>> On Nov 14, 2012, at 1:40 PM, Andrey Jivsov wrote: >>> >>>> SHA-2 is well-supported today, but there are no solid reasons why SHA-3 will not be supported equally well in the future. >>> >>> In that future, we can re-look at support for it in IETF protocols. For now, algorithm agility might be sufficient. >> >> I would agree, but the document such as RFC 4270 influence the future. If the message it sends is that the SHA-3 is an odd bifurcation in the SHA line, SHA-3 won't gain critical mass. > > If we have suggested that in the draft, we should change the text. Can you say where you got that feeling? "However, the authors do not believe that any push to start using SHA-3 is warranted at any time soon." Suppose I am an Internet browser company. I read this as "OK, I will revisit the SHA-3 support in 5 year". In 5 years the Keccak "read" support is added, hopefully without bugs. X.509 CAs cannot enable the Keccak because they will want wide browser support. This means they are waiting for all the browser vendors to make the support available. OK, the other browser vendors added the support in the following few years. Then the CA will need to wait for the wide deployment of said browsers. Count the browsers in the TVs too. This will be another half of a decade. So, we are looking at more than a decade, perhaps two, when the SHA-3 can actually happen without significant disruptions. For this to happen a decade from now some of the players should start making plans today. I think the statement I quoted above is only true for an environment where we can upgrade every participant fairy easily. Hopefully NIST will force some timeline that will put the process in motion, because if I am in minority regarding how painful the new hash adoption is, I don't see it happening smoothly without a bit more proactive plan. From paul.hoffman@vpnc.org Wed Nov 14 16:39:38 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C671E21F877C for ; Wed, 14 Nov 2012 16:39:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FpsJT05pLUH2 for ; Wed, 14 Nov 2012 16:39:38 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 32BC721F8772 for ; Wed, 14 Nov 2012 16:39:38 -0800 (PST) Received: from [10.20.30.102] (50-0-66-243.dsl.dynamic.fusionbroadband.com [50.0.66.243]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id qAF0dRsa035667 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 14 Nov 2012 17:39:27 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: <50A43870.6000605@brainhub.org> Date: Wed, 14 Nov 2012 16:39:32 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6AF2A507-3533-42CD-95D1-26DB88A80952@vpnc.org> References: <9B93EFAD-AD9B-4402-8CC2-79239EB3DF2E@vpnc.org> <50A40FC8.8080602@brainhub.org> <9BE0FD3C-F9CE-492E-A64C-D7CFB7961D3C@vpnc.org> <50A42ACF.80208@brainhub.org> <75F9A834-CA86-4551-A0D9-382EBEBBD04C@vpnc.org> <50A43870.6000605@brainhub.org> To: Andrey Jivsov X-Mailer: Apple Mail (2.1499) Cc: IETF Security Area Advisory Group Subject: Re: [saag] Revision of "Attacks on Cryptographic Hashes in Internet Protocols" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 00:39:38 -0000 On Nov 14, 2012, at 4:33 PM, Andrey Jivsov wrote: > On 11/14/2012 03:42 PM, Paul Hoffman wrote: >> On Nov 14, 2012, at 3:35 PM, Andrey Jivsov = wrote: >>=20 >>> On 11/14/2012 02:33 PM, Paul Hoffman wrote: >>>> On Nov 14, 2012, at 1:40 PM, Andrey Jivsov = wrote: >>>>=20 >>>>> SHA-2 is well-supported today, but there are no solid reasons why = SHA-3 will not be supported equally well in the future. >>>>=20 >>>> In that future, we can re-look at support for it in IETF protocols. = For now, algorithm agility might be sufficient. >>>=20 >>> I would agree, but the document such as RFC 4270 influence the = future. If the message it sends is that the SHA-3 is an odd bifurcation = in the SHA line, SHA-3 won't gain critical mass. >>=20 >> If we have suggested that in the draft, we should change the text. = Can you say where you got that feeling? >=20 > "However, the authors do not believe that any push to start using = SHA-3 is warranted at any time soon." We disagree that that sentence indicates "that the SHA-3 is an odd = bifurcation in the SHA line". --Paul Hoffman From openpgp@brainhub.org Wed Nov 14 17:00:53 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E08621F87A9 for ; Wed, 14 Nov 2012 17:00:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ouvEamLeAKQF for ; Wed, 14 Nov 2012 17:00:53 -0800 (PST) Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:64]) by ietfa.amsl.com (Postfix) with ESMTP id 15F6A21F87A5 for ; Wed, 14 Nov 2012 17:00:53 -0800 (PST) Received: from omta04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by qmta07.emeryville.ca.mail.comcast.net with comcast id PWxz1k00B0lTkoCA7d0sX0; Thu, 15 Nov 2012 01:00:52 +0000 Received: from [127.0.0.1] ([69.181.162.123]) by omta04.emeryville.ca.mail.comcast.net with comcast id Pd0r1k00j2g33ZR8Qd0sAq; Thu, 15 Nov 2012 01:00:52 +0000 Message-ID: <50A43E80.1020003@brainhub.org> Date: Wed, 14 Nov 2012 16:59:44 -0800 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 MIME-Version: 1.0 To: Paul Hoffman References: <9B93EFAD-AD9B-4402-8CC2-79239EB3DF2E@vpnc.org> <50A40FC8.8080602@brainhub.org> <9BE0FD3C-F9CE-492E-A64C-D7CFB7961D3C@vpnc.org> <50A42ACF.80208@brainhub.org> <75F9A834-CA86-4551-A0D9-382EBEBBD04C@vpnc.org> <50A43870.6000605@brainhub.org> <6AF2A507-3533-42CD-95D1-26DB88A80952@vpnc.org> In-Reply-To: <6AF2A507-3533-42CD-95D1-26DB88A80952@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF Security Area Advisory Group Subject: Re: [saag] Revision of "Attacks on Cryptographic Hashes in Internet Protocols" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 01:00:53 -0000 On 11/14/2012 04:39 PM, Paul Hoffman wrote: > > On Nov 14, 2012, at 4:33 PM, Andrey Jivsov wrote: > >> On 11/14/2012 03:42 PM, Paul Hoffman wrote: >>> On Nov 14, 2012, at 3:35 PM, Andrey Jivsov wrote: >>> >>>> On 11/14/2012 02:33 PM, Paul Hoffman wrote: >>>>> On Nov 14, 2012, at 1:40 PM, Andrey Jivsov wrote: >>>>> >>>>>> SHA-2 is well-supported today, but there are no solid reasons why SHA-3 will not be supported equally well in the future. >>>>> >>>>> In that future, we can re-look at support for it in IETF protocols. For now, algorithm agility might be sufficient. >>>> >>>> I would agree, but the document such as RFC 4270 influence the future. If the message it sends is that the SHA-3 is an odd bifurcation in the SHA line, SHA-3 won't gain critical mass. >>> >>> If we have suggested that in the draft, we should change the text. Can you say where you got that feeling? >> >> "However, the authors do not believe that any push to start using SHA-3 is warranted at any time soon." > > We disagree that that sentence indicates "that the SHA-3 is an odd bifurcation in the SHA line". > > --Paul Hoffman > OK Paul, I noted this :-). I would not read it that way, but some people might. The Internet will keep your reply as a proof to those. Nonetheless... I would prefer to see some language suggesting that the hash transition issue may be more urgent because of the time lag in some cases (described in my previous email). Re-phrasing my earlier deployment concerns, let me observe that the hash algorithm agility/preferences is an elusive thing in general. In general, we sign persistent data structures that will be processed by entities we may not know anything about. Thus, we cannot gather capability preferences from entities who will be performing the verification. The only reliable solution is to (universally) deploy "read" support and then enable the "generation" of the new data structures. Thank you. From turners@ieca.com Thu Nov 15 11:26:49 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA46F21F84CA for ; Thu, 15 Nov 2012 11:26:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.493 X-Spam-Level: X-Spam-Status: No, score=-102.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MAbtxoSftKQw for ; Thu, 15 Nov 2012 11:26:49 -0800 (PST) Received: from gateway03.websitewelcome.com (gateway03.websitewelcome.com [74.52.223.144]) by ietfa.amsl.com (Postfix) with ESMTP id 26E1521F8487 for ; Thu, 15 Nov 2012 11:26:49 -0800 (PST) Received: by gateway03.websitewelcome.com (Postfix, from userid 5007) id D536078033963; Thu, 15 Nov 2012 13:26:49 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway03.websitewelcome.com (Postfix) with ESMTP id C80F178033923 for ; Thu, 15 Nov 2012 13:26:49 -0600 (CST) Received: from pool-108-18-174-45.washdc.east.verizon.net ([108.18.174.45]:55006 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TZ55M-0002kI-66 for saag@ietf.org; Thu, 15 Nov 2012 13:26:48 -0600 Message-ID: <50A541F7.1080803@ieca.com> Date: Thu, 15 Nov 2012 14:26:47 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: saag@ietf.org References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-108-18-174-45.washdc.east.verizon.net (thunderfish.local) [108.18.174.45]:55006 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 0 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [saag] Fwd: NIST SP 800-133, Recommendation for Cryptographic Key Generation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 19:26:49 -0000 Some folks on this list might find this of interest. spt -------- Original Message -------- Subject: NIST SP 800-133, Recommendation for Cryptographic Key Generation Date: Thu, 15 Nov 2012 14:02:13 -0500 From: Caswell, Sara J. To: turners@ieca.com NIST announces the completion of NIST Special Publication (SP) 800-133, /Recommendation for Cryptographic Key Generation/. This Recommendation discusses the generation of the keys to be used with NIST-*approved* cryptographic algorithms. The keys are either generated using mathematical processing on the output of *approved* Random Bit Generators, or generated based upon keys that are generated in this fashion. The document is available at http://csrc.nist.gov/publications/PubsSPs.html. From magnus.westerlund@ericsson.com Tue Nov 27 06:23:58 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8391F21F8421 for ; Tue, 27 Nov 2012 06:23:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBS8rrmAZnPT for ; Tue, 27 Nov 2012 06:23:58 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD4521F8425 for ; Tue, 27 Nov 2012 06:23:57 -0800 (PST) X-AuditID: c1b4fb25-b7f926d00000661f-93-50b4ccfcbc76 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 5B.4D.26143.CFCC4B05; Tue, 27 Nov 2012 15:23:56 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Tue, 27 Nov 2012 15:23:53 +0100 Message-ID: <50B4CCF9.80408@ericsson.com> Date: Tue, 27 Nov 2012 15:23:53 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: saag@ietf.org References: <50B4CC3E.6070705@ericsson.com> In-Reply-To: <50B4CC3E.6070705@ericsson.com> X-Enigmail-Version: 1.4.6 X-Forwarded-Message-Id: <50B4CC3E.6070705@ericsson.com> Content-Type: multipart/mixed; boundary="------------000201090706060901060806" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrAKsWRmVeSWpSXmKPExsUyM+Jvje6fM1sCDA69krSY0t/J5MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujF3fp7AX/LGq+PJ+O2sD436TLkZODgkBE4mfS8+xQthiEhfu rWfrYuTiEBI4ySgxa8EmJghnOaNE97XbzCBVvAKaEtc3HmQCsVkEVCUOn73EAmKzCVhI3PzR yAZiiwr4Ssza84sJol5Q4uTMJ2A1IkD2g75JYLawQKjE9T+7wTYLCWhL9PZsAKvnFNCROHbn AyPERZISi6Z1skDY5hInvi8Cu4FZIEDiz4LDzDC9DU0drBMYBWchWTcLSRmErScx5WoLI4Qt L7H97RyoeJHE97aVaOJcQHYPo8TmZefZZ4HtTpC4uesmyyxwYOxilPj5+wkjhLORUaJ18zw2 uEzvtitss8DOmsoo8W4iO0iCReALs8SNY5NYIGYpSvQtmgA2l0VAQWJ2QwPUqNWMEi9eb2CD KNKQmLHyAlCCA8jml1h7SHkWNIYmrjgAVcIrcXrKcbDNEgIzGSWO33zOBDHoAqPEwYUzWCDO 2Mco8b4N6gsTiYmP3jJDFJ1mlDi86wf7LFj89vbcZoUEoLbEs4XLoO5TlbhxewnYPlj8zkKK 31ngOFWS2DFpG/MspPhawGi6ipE9NzEzJ73caBMjMJUe3PJbdQfjnXMihxilOViUxHmtt+7x FxJITyxJzU5NLUgtii8qzUktPsTIxMEp1cDIGM7CstAieV3FlvbY1dPX7VbI/f/nS/K+GZM7 jyetv2H13fHHNW4NU/mFzNK9Zqt++Wz5pjXv9IlM/pLzCsrXXBqkWcNivjD9XS61ytP83/mT +c/MxE5fc9jt/XbCjrYy7u0L3jFuPBjXMrP15uXL3y0vpe2oC734bLMeg3RQb8Dl5hPmZR8L lViKMxINtZiLihMB/TtPtXMDAAA= Subject: [saag] Fwd: [AVTCORE] Working group last call on draft-ietf-avtcore-srtp-aes-gcm-03 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 14:23:58 -0000 --------------000201090706060901060806 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Dear Security Area Participants, The AVTCORE WG is currently running a WG last call on a SRTP cryptosuite for AES-GCM until the 12th of December. Additional reviews would be appreciated. Cheers Magnus Westerlund AVTCORE WG chair --------------000201090706060901060806 Content-Type: message/rfc822; name="[AVTCORE] Working group last call on draft-ietf-avtcore-srtp-aes-gcm-03.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="[AVTCORE] Working group last call on draft-ietf-avtcore-srtp"; filename*1="-aes-gcm-03.eml" X-Mozilla-Keys: Received: from esessmw0247.eemea.ericsson.se (153.88.115.93) by ESESSHC004.ericsson.se (153.88.183.30) with Microsoft SMTP Server (TLS) id 14.2.318.1; Tue, 27 Nov 2012 15:21:02 +0100 Received: from sesbmg11.ericsson.net (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.95) with Microsoft SMTP Server id 8.3.279.1; Tue, 27 Nov 2012 15:21:00 +0100 Received: from mail.ietf.org (mail.ietf.org [64.170.98.30]) by sesbmg11.ericsson.net (Symantec Mail Security) with SMTP id 4B.C7.25995.C4CC4B05; Tue, 27 Nov 2012 15:21:00 +0100 (CET) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00F1721F8641; Tue, 27 Nov 2012 06:20:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1354026058; bh=A9ST1hMcrW91NvzqFJxpqwJ6cQ6GjaXB1enq0vWjJc8=; h=Message-ID:Date:From:MIME-Version:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=c+TsrQYjHrKv/qpKjf+8dgY1x77p6vVt3l1pJsbirDYu0tGSrHfPfFOQhOuEc8hwa zm7kTnRvuZ83aRlU6NZdvfxAGPko/QVexONvw4gUIUU5M9l/uoOc19hDfR/DmCZsbK IlMOZSjYDbDFXOEbX70BmYCtt29r+EwdOVwTrvsc= X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E61A421F8425 for ; Tue, 27 Nov 2012 06:20:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Uv8pNvaTMmS for ; Tue, 27 Nov 2012 06:20:51 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 54DD721F841B for ; Tue, 27 Nov 2012 06:20:49 -0800 (PST) X-AuditID: c1b4fb39-b7fe96d00000658b-e8-50b4cc4bdb65 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 7B.21.11564.F3CC4B05; Tue, 27 Nov 2012 15:20:47 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Tue, 27 Nov 2012 15:20:47 +0100 Message-ID: <50B4CC3E.6070705@ericsson.com> Date: Tue, 27 Nov 2012 15:20:46 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 To: IETF AVTCore WG X-Enigmail-Version: 1.4.6 X-Brightmail-Tracker: H4sIAAAAAAAAA1WTfUxTVxjGOffetlfg6rHQ8dKp0RqjkYiQkHGW+EHcP1Ns0mk0usxowbu2 Wkp3b1UW/7CQiB8JhJIhwwUcBD+KGiPSDQ1RPsRBkaSihpaP6iYTPzKICTBQo972tqj/Pe95 3uf8ntzcw9LqV0otyxc4eMFmtOqUsUxWQ86iVZvvNhnSHo2nkKLhJhXxVXUg0hiwE8+4QBrP uyky1t+pIiXuGgXxdx2jSGGRSDwlTgXxdb+lSd+VIEWqqneTIfcAItUz35GS/iKGtA4Uqsit 1iklCc5MKknl0bXktneMztJ8+3ryodKAvo9ds5e3Wg7ywup1e2LNL3uHkf2JqmDk/qTCibzK k2gOCzgDXP/8R8v6C/AFr0jnsawaNyPoqB6l5KESgbfTFR4YPEGD/045I0eWQGldmSqkGbwY fnM6kZy4iCA4/CyytAJ+dfskg5X0PLjcvjSKc11ojdSYC/eeTYcBgKsQ/BWIovsQlAX8Cnm4 iaChaIyKNn8QGIrgeqS2N6ZV8nAewZNXx1Foi8Mp8LT2XKTgMvAP1oeBSkwgMF0Y1hqsh9Mt ryl5fz50V42EeydiHTSX/xH5NslQd+oEIxesU0DxeEU4nIC3wMTxFhRdGrz5fFafLBkJgzHG UFN/PQyIx+vA/+ekQtY/walOD1WGVpz+hB3SNE4Ff8UvSlmnwLnal/TviG5AGpEXc/JM6emp vGDJFcV8W6qNdzQi6T9ra3rzdTOqq89sR8kspdNw9pYmg3puTv7en81G0bxbOGDlxXb0Jcvo krjmwXqDGpuMDn4/z9t5IeouYFkdcHE9UnK+wJv4gh8tVsdHm2LntCNg43WJXFpohxPtxjzR YpJ9L1qiTeISQwYOGeYDttls9CX0oYXaBA7FxMSo4yVunsXxuf8CJbFIl8BpQrfEW2yO2dtf SGBKAuf2Xw2BHcaPltaJ8nMn9JWuQ+8fHjyz9VqWPttOvhFWxvGXG/f9/a54567127JuZOvR oe1D+jQGP99J7TFsdP6fee3x08PTmbWe6ozl2dhlMc0kb3Bnvi0VfKUZo2VnN/3rbbvX9W5w Y/mbbb3aqfUZCz0/7HMMfJVdmD92ZJneGSy2DqcPVFyq2WFgdYxoNqavpAXR+AEFJgCVBAQA AA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMJMWRmVeSWpSXmKPExsUyM+Jvja79mS0BBue/aVq87FnJ7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujNa5p9gLzrJVXGjvZ2pg3M/axcjJISFgInHl5h1GCFtM4sK9 9WxdjFwcQgInGSXeT13KAuEsZ5S4vPYUG0gVr4C2xLOFy9hBbBYBVYkbt5eAxdkELCRu/mgE s0UFfCVm7fnFBFEvKHFy5hMWEFtEQElix6RtzCC2sICbRN/TLWwQmyUlFk3rBKthFtCTmHK1 hRHClpdo3jobrF4IaG9DUwfrBEb+WUjGzkLSMgtJywJG5lWM7LmJmTnp5YabGIEBdXDLb90d jKfOiRxilOZgURLn5Ura7y8kkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBkant7Qav415PPv6Z eljv1NNXG7cLvd70u36hy/zYsrVP2hJTlFbuD1kktPFi8al5/MJa8y1/KkkVLhF33ba1a3dP hmvsJ+nKzTdD7fVWdMlW7WWdbRkZ+Hhz++1i53kJ944vmZLyrm5C2rH1XYqSbM3XOFRivngv XjElvilUbMkX735Pp9mTdyixFGckGmoxFxUnAgCl8hmy9gEAAA== Subject: [AVTCORE] Working group last call on draft-ietf-avtcore-srtp-aes-gcm-03 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: Errors-To: avt-bounces@ietf.org Return-Path: avt-bounces@ietf.org X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0 X-MS-Exchange-Organization-AuthSource: esessmw0247.eemea.ericsson.se X-MS-Exchange-Organization-AuthAs: Anonymous MIME-Version: 1.0 WG, This announces the WG last call on AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP) https://datatracker.ietf.org/doc/draft-ietf-avtcore-srtp-aes-gcm/ Please provide any comments no later than the 12th of December. Also comments of the nature of "I have read it and have no comments and think it should be published" are highly valuable. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt --------------000201090706060901060806-- From mcgrew@cisco.com Wed Nov 28 07:23:08 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 808D521F8843 for ; Wed, 28 Nov 2012 07:23:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQAaIrjoJzUP for ; Wed, 28 Nov 2012 07:23:07 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id C0F7321F8801 for ; Wed, 28 Nov 2012 07:23:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1472; q=dns/txt; s=iport; t=1354116187; x=1355325787; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Da/w+X8tWhlMjmUtLtNZS1Ac0KreKOglNAJFjGdptHY=; b=ansSb223+zgwt0FgXHD2xKen444XUm4/cZ0ghw+AISxWDH8ttLzA2/0o bf2kwB6IidUjmrqngxfW020NS8VP88QumbyIKgQMq6Rz0hwuJjsUfC8mA Wr5RQbcrakSIAFxlG/KeHQfjZ4g3aHU6bSTF2SU83NP4PGoXB/iN4Wl2l 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EANgrtlCtJXG9/2dsb2JhbABFwBUWc4IgAQQ6PxIBCCIUQiUCBA4NiAe/AZAfYQOmRYJwgiE X-IronPort-AV: E=McAfee;i="5400,1158,6909"; a="147155358" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 28 Nov 2012 15:23:07 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qASFN6oc023451 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 28 Nov 2012 15:23:06 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.66]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.001; Wed, 28 Nov 2012 09:23:06 -0600 From: "David McGrew (mcgrew)" To: Paul Hoffman Thread-Topic: [saag] Revision of "Attacks on Cryptographic Hashes in Internet Protocols" Thread-Index: AQHNweyKBFECjqGD4EK+xvmKz2CDQJfpYOIAgADxLoCAFTNfAA== Date: Wed, 28 Nov 2012 15:23:06 +0000 Message-ID: <747787E65E3FBD4E93F0EB2F14DB556B0F54B22B@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.117.10.227] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF Security Area Advisory Group Subject: Re: [saag] Revision of "Attacks on Cryptographic Hashes in Internet Protocols" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 15:23:08 -0000 Hi Paul, A quick comment. The draft says that uses for hash algorithms include o Integrity protection. It is common to compare a hash value that is received out-of-band for a file with the hash value of the file after it is received over an unsecured protocol such as FTP. ... and it then says that collision resistance is not needed for the integrity protection use case. However, it seems to me that there are possible threats against hash-based integrity protection that would be possible if the person/system generating the hash can generate collisions, and is untrustworthy. Consider the case of an md5sum hash on a debian ISO image. If the person responsible for generating the hash can create a malware-laden ISO imagine that has a hash collision with the actual ISO image, then they could substitute the bad one for the good one regardless of the hash checking step. An attacker might leave the good ISO image in place to avoid detection, while foisting the bad one on some victims. I am assuming that there are different ways of distributing ISO images, or that the substitution of bad for good can take place after the good one has been investigated and found to be good. It is debatable how important this scenario is in practice, but it seems that collision resistance is at least desirable for integrity protection. David P.S. - apologies for picking on debian, which is a most excellent distro :-) From paul.hoffman@vpnc.org Wed Nov 28 07:40:47 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5382E21F8521 for ; Wed, 28 Nov 2012 07:40:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3MQIsRjRlW0w for ; Wed, 28 Nov 2012 07:40:46 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id C1D5121F84E0 for ; Wed, 28 Nov 2012 07:40:46 -0800 (PST) Received: from [10.20.30.102] (50-0-66-243.dsl.dynamic.fusionbroadband.com [50.0.66.243]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id qASFejav045280 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 28 Nov 2012 08:40:46 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: <747787E65E3FBD4E93F0EB2F14DB556B0F54B22B@xmb-rcd-x04.cisco.com> Date: Wed, 28 Nov 2012 07:40:46 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <5A080BC5-C003-41FB-9542-B73D3A63A1C1@vpnc.org> References: <747787E65E3FBD4E93F0EB2F14DB556B0F54B22B@xmb-rcd-x04.cisco.com> To: IETF Security Area Advisory Group X-Mailer: Apple Mail (2.1499) Subject: Re: [saag] Revision of "Attacks on Cryptographic Hashes in Internet Protocols" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 15:40:47 -0000 On Nov 28, 2012, at 7:23 AM, David McGrew (mcgrew) = wrote: > Hi Paul, >=20 > A quick comment. The draft says that uses for hash algorithms = include >=20 > o Integrity protection. It is common to compare a hash value that > is received out-of-band for a file with the hash value of the = file > after it is received over an unsecured protocol such as FTP. >=20 > ... and it then says that collision resistance is not needed for the > integrity protection use case. However, it seems to me that there = are > possible threats against hash-based integrity protection that would be > possible if the person/system generating the hash can generate = collisions, > and is untrustworthy. Consider the case of an md5sum hash on a debian = ISO > image. If the person responsible for generating the hash can create a > malware-laden ISO imagine that has a hash collision with the actual = ISO > image, then they could substitute the bad one for the good one = regardless > of the hash checking step. An attacker might leave the good ISO image = in > place to avoid detection, while foisting the bad one on some victims. = I > am assuming that there are different ways of distributing ISO images, = or > that the substitution of bad for good can take place after the good = one > has been investigated and found to be good. >=20 > It is debatable how important this scenario is in practice, but it = seems > that collision resistance is at least desirable for integrity = protection. Collision resistance is not needed if you trust the party who created = the hash; it is needed if you do not trust that party. Proposed addition to the paragraph following the list: Integrity protection is affected by collision attacks if the party = checking the hash does not completely trust the party who published the = hash. --Paul Hoffman= From stephen.farrell@cs.tcd.ie Wed Nov 28 09:31:10 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C41A21F84B2 for ; Wed, 28 Nov 2012 09:31:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1wf0Od1g+0Y for ; Wed, 28 Nov 2012 09:31:09 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 67B7221F8472 for ; Wed, 28 Nov 2012 09:31:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6E39FBE5D; Wed, 28 Nov 2012 17:30:47 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FB0sFPHtLfv; Wed, 28 Nov 2012 17:30:46 +0000 (GMT) Received: from [IPv6:2001:770:10:203:9999:53ef:87e7:8281] (unknown [IPv6:2001:770:10:203:9999:53ef:87e7:8281]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8B612BE5C; Wed, 28 Nov 2012 17:30:46 +0000 (GMT) Message-ID: <50B64A46.5050903@cs.tcd.ie> Date: Wed, 28 Nov 2012 17:30:46 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "saag@ietf.org" , dns-dir@ops.ietf.org X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Michael StJohns , Ralph Droms Subject: [saag] RFC 5011 to IS question X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 17:31:10 -0000 Hi, The IESG recently are considering a request to move RFC 5011 [1] to Internet Standard. This is a fine RFC but I have one question and I'd be interested if anyone here has input. Should we re-think any of the timer values here in the light of the fact that it took a few weeks to find out about diginotar? In particular the 30 day add hold-down timer might arguably be better off at ~90 days if additions are planned well ahead of time and there are no bad side effects of a longer timer and we assume that gossipy protocols might detect bad new trust points in a few weeks, but not necessarily sooner. (Say if detection needed a clueful traveller to go to place X, see the bad new trust point and return to somewhere where the bad new trust point isn't seen.) I think the answer is "its still ok" and plan to remove my discuss on this shortly, but wanted to check in case others who know more about DNSSEC think differently. (Note - nobody brought this up during IETF LC, its just me asking.) Thanks, S. [1] http://tools.ietf.org/html/rfc5011 From mouse@Sparkle.Rodents-Montreal.ORG Wed Nov 28 13:32:29 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2800F21F847B for ; Wed, 28 Nov 2012 13:32:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.988 X-Spam-Level: X-Spam-Status: No, score=-9.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTCfV61ktuui for ; Wed, 28 Nov 2012 13:32:28 -0800 (PST) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by ietfa.amsl.com (Postfix) with ESMTP id 735A521F8453 for ; Wed, 28 Nov 2012 13:32:28 -0800 (PST) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id QAA14540; Wed, 28 Nov 2012 16:32:22 -0500 (EST) Date: Wed, 28 Nov 2012 16:32:22 -0500 (EST) From: Mouse Message-Id: <201211282132.QAA14540@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Wed, 28 Nov 2012 16:29:49 -0500 (EST) To: saag@ietf.org In-Reply-To: <747787E65E3FBD4E93F0EB2F14DB556B0F54B22B@xmb-rcd-x04.cisco.com> References: <747787E65E3FBD4E93F0EB2F14DB556B0F54B22B@xmb-rcd-x04.cisco.com> Subject: Re: [saag] Revision of "Attacks on Cryptographic Hashes in Internet Protocols" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 21:32:29 -0000 > Consider the case of an md5sum hash on a debian ISO image. If the > person responsible for generating the hash can create a malware-laden > ISO imagine that has a hash collision with the actual ISO image, ...then you're dealing with second-preimage reisistance, not just collision resistance. At least, unless the "actual ISO image" creator is in on the deal, and in that case even the best hash imaginable won't help. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From mcgrew@cisco.com Wed Nov 28 14:30:01 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B56D521F88D8 for ; Wed, 28 Nov 2012 14:30:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WbQDrU1Y6uuB for ; Wed, 28 Nov 2012 14:30:01 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 1859F21F8893 for ; Wed, 28 Nov 2012 14:30:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=992; q=dns/txt; s=iport; t=1354141801; x=1355351401; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=r0cbFeMlmsEIk0eEJx72Vugq3Zfo1WDZQHnHUaK1Q84=; b=P27xAJYBQxPgbvc0ZJB5LvPu7bH/K9iJHxEfkjdWTvfLdW3/7lz9keUi xZj1KP4PsmB0E1GSA1d/ooZWcm2afFOpm1GnCPWVP9bEOP6qWZOfvzQdj rDPpdc9klbB7DwWJL4iQ4G/TXpbYo+weqZ5ETbaPFOoi3HVUDG2Q74gyg I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAByPtlCtJV2Y/2dsb2JhbABFwCIWc4IeAQEBAwE6UQEIIhRCJQIEARIIiAIGvyeQH2EDpkWCcoIh X-IronPort-AV: E=McAfee;i="5400,1158,6910"; a="147282842" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 28 Nov 2012 22:30:00 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qASMU0bv008135 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 28 Nov 2012 22:30:00 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.66]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.001; Wed, 28 Nov 2012 16:30:00 -0600 From: "David McGrew (mcgrew)" To: Mouse , "saag@ietf.org" Thread-Topic: [saag] Revision of "Attacks on Cryptographic Hashes in Internet Protocols" Thread-Index: AQHNweyKBFECjqGD4EK+xvmKz2CDQJfpYOIAgADxLoCAFTNfAIAAuwAA//+8RAA= Date: Wed, 28 Nov 2012 22:29:59 +0000 Message-ID: <747787E65E3FBD4E93F0EB2F14DB556B0F54B580@xmb-rcd-x04.cisco.com> In-Reply-To: <201211282132.QAA14540@Sparkle.Rodents-Montreal.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.117.10.227] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [saag] Revision of "Attacks on Cryptographic Hashes in Internet Protocols" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 22:30:01 -0000 On 11/28/12 4:32 PM, "Mouse" wrote: >> Consider the case of an md5sum hash on a debian ISO image. If the >> person responsible for generating the hash can create a malware-laden >> ISO imagine that has a hash collision with the actual ISO image, > >...then you're dealing with second-preimage reisistance, not just >collision resistance. > >At least, unless the "actual ISO image" creator is in on the deal, and >in that case even the best hash imaginable won't help. The point that I wanted to make is: if the actual ISO image creator is untrustworthy and the hash function is not collision resistant, then it is possible for that person to make two images, one good and one bad. This enables attacks on the system that are not otherwise possible, i.e. publishing the good image in the distribution channels that will actually be checked by security auditors, then publishing the bad one in some other distribution channels. David From smb@cs.columbia.edu Wed Nov 28 14:38:57 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFB821F895D for ; Wed, 28 Nov 2012 14:38:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qVibKzICN3tb for ; Wed, 28 Nov 2012 14:38:56 -0800 (PST) Received: from salak.cc.columbia.edu (salak.cc.columbia.edu [128.59.29.6]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF4A21F8959 for ; Wed, 28 Nov 2012 14:38:56 -0800 (PST) Received: from [192.168.1.3] (49.sub-70-192-197.myvzw.com [70.192.197.49]) (user=smb2132 mech=PLAIN bits=0) by salak.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id qASMcdEb027430 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 28 Nov 2012 17:38:54 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Steven Bellovin In-Reply-To: <747787E65E3FBD4E93F0EB2F14DB556B0F54B580@xmb-rcd-x04.cisco.com> Date: Wed, 28 Nov 2012 17:38:39 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: <747787E65E3FBD4E93F0EB2F14DB556B0F54B580@xmb-rcd-x04.cisco.com> To: David McGrew (mcgrew) X-Mailer: Apple Mail (2.1499) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.6 Cc: "saag@ietf.org" Subject: Re: [saag] Revision of "Attacks on Cryptographic Hashes in Internet Protocols" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 22:38:57 -0000 On Nov 28, 2012, at 5:29 PM, David McGrew (mcgrew) wrote: > > > On 11/28/12 4:32 PM, "Mouse" wrote: > >>> Consider the case of an md5sum hash on a debian ISO image. If the >>> person responsible for generating the hash can create a malware-laden >>> ISO imagine that has a hash collision with the actual ISO image, >> >> ...then you're dealing with second-preimage reisistance, not just >> collision resistance. >> >> At least, unless the "actual ISO image" creator is in on the deal, and >> in that case even the best hash imaginable won't help. > > The point that I wanted to make is: if the actual ISO image creator is > untrustworthy and the hash function is not collision resistant, then it is > possible for that person to make two images, one good and one bad. This > enables attacks on the system that are not otherwise possible, i.e. > publishing the good image in the distribution channels that will actually > be checked by security auditors, then publishing the bad one in some other > distribution channels. > What about the party who prepares part of the contents, i.e., one file? The hash function reaches that file with fixed but unknown internal state. It's easy to prepare two different files that would cause a collision from the standard starting state, but I'm not sure about this scenario. --Steve Bellovin, https://www.cs.columbia.edu/~smb From mouse@Sparkle.Rodents-Montreal.ORG Wed Nov 28 22:20:16 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 783CF21F8A30 for ; Wed, 28 Nov 2012 22:20:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.988 X-Spam-Level: X-Spam-Status: No, score=-9.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXtY8qxnc4mV for ; Wed, 28 Nov 2012 22:20:16 -0800 (PST) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by ietfa.amsl.com (Postfix) with ESMTP id 7573921F8A29 for ; Wed, 28 Nov 2012 22:20:14 -0800 (PST) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id BAA16690; Thu, 29 Nov 2012 01:20:12 -0500 (EST) Date: Thu, 29 Nov 2012 01:20:12 -0500 (EST) From: Mouse Message-Id: <201211290620.BAA16690@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Thu, 29 Nov 2012 01:17:18 -0500 (EST) To: saag@ietf.org In-Reply-To: <747787E65E3FBD4E93F0EB2F14DB556B0F54B580@xmb-rcd-x04.cisco.com> References: <747787E65E3FBD4E93F0EB2F14DB556B0F54B580@xmb-rcd-x04.cisco.com> Subject: Re: [saag] Revision of "Attacks on Cryptographic Hashes in Internet Protocols" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 06:20:16 -0000 > The point that I wanted to make is: if the actual ISO image creator > is untrustworthy and the hash function is not collision resistant, > then it is possible for that person to make two images, one good and > one bad. This enables attacks on the system that are not otherwise > possible, [...] Ah! I misunderstood. Yes. (I could quibble about how the colliding data blobs have to be valid ISO images, but I suspect that part would border on trivial in any realistic collision-resistance break, just as the MD5 collision example I have managed to make both blobs valid PostScript programs.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From wjhns1@hardakers.net Fri Nov 30 11:01:52 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9636821F8B1F for ; Fri, 30 Nov 2012 11:01:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-rS3N+YK7eN for ; Fri, 30 Nov 2012 11:01:52 -0800 (PST) Received: from mail.hardakers.net (unknown [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id 61DD521F87FF for ; Fri, 30 Nov 2012 11:01:52 -0800 (PST) Received: from localhost (unknown [50.13.187.159]) by mail.hardakers.net (Postfix) with ESMTPSA id B77C721B; Fri, 30 Nov 2012 11:01:51 -0800 (PST) From: Wes Hardaker To: Stephen Farrell In-Reply-To: <50B64A46.5050903@cs.tcd.ie> (Stephen Farrell's message of "Wed, 28 Nov 2012 17:30:46 +0000") References: <50B64A46.5050903@cs.tcd.ie> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.1 (gnu/linux) Date: Fri, 30 Nov 2012 11:01:50 -0800 Message-ID: <0lfw3qdie9.fsf@wjh.hardakers.net> MIME-Version: 1.0 Content-Type: text/plain Cc: Ralph Droms , Michael StJohns , "saag@ietf.org" , dns-dir@ops.ietf.org Subject: Re: [saag] RFC 5011 to IS question X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 19:01:52 -0000 Stephen Farrell writes: > In particular the 30 day add hold-down timer might > arguably be better off at ~90 days if additions are > planned well ahead of time The end of your sentence captures the problem well... I agree, I'd love the case where we could always publish far enough in advance not to worry about a huge hold-down time. But the reality is, the real world is not so nice and I suspect there are times that people would be annoyed by the 30 day hold-down (eg, when believe but don't know that the current key may have been "seen"). So the 30 days seems like a reasonable compromise to me, and I'm not sure I'd want to move it either direction. If I move it in the direction you're talking about, it probably would be to something like 45 or 60. But the reality is that if you an operator can't see a problem in 30 days, I'm not sure anything longer will help them. -- Wes Hardaker My Pictures: http://capturedonearth.com/ My Thoughts: http://pontifications.hardakers.net/