From nobody Tue Oct 14 18:20:35 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CEF01A0105 for ; Tue, 14 Oct 2014 18:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7LKuul6caSq for ; Tue, 14 Oct 2014 18:20:31 -0700 (PDT) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90C971A0104 for ; Tue, 14 Oct 2014 18:20:31 -0700 (PDT) Received: by mail-yk0-f173.google.com with SMTP id 200so120683ykr.18 for ; Tue, 14 Oct 2014 18:20:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=4fwII3DrdgGSAe0cMG0QNjM+yoOkPxFqFv8AlT5JFpg=; b=ySmORaZQudCcIuJl2Y1SVdl4tECflMcVQICst9kdnUzmtNlNNNR2/Lx7TGS8KQCiBF 2kJPyLfhwTr7eKjGQ8HAHcp1I/MbBY4DbQDOeWnYjxMQ39J9xyf/CrFeUtOulpXNI0RK 7DJ06OJ1EzvBT7WBB4y4qcH/5z/OfWm1opCm3Mq6Ik60viPP/4vMbVdgbnkG4ADwwboH DK+TK9yIBSFcd1wHRfY9+S5GNwzkFWSAELTz8ypHuKYYOFSYCf/7Eyv5wI4Pr/YO6jvo g8SmNO6AlShCbH2zK1xG4uRqT4SAvP0dKVlsgjSCVb0fnv4SXL8c6Fak6KBeGRKoUgJd 4/ow== MIME-Version: 1.0 X-Received: by 10.236.7.52 with SMTP id 40mr98561yho.172.1413336030752; Tue, 14 Oct 2014 18:20:30 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Tue, 14 Oct 2014 18:20:30 -0700 (PDT) Date: Tue, 14 Oct 2014 18:20:30 -0700 Message-ID: From: Watson Ladd To: "saag@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/MBQLTiWQcro5geiSENxD1k1_9Bo Subject: [saag] POODLE avant le chein X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 01:20:33 -0000 Dear all, Now that we've all disabled SSLv3 on every machine in reach, let's review when this attack was discovered. Not in 2014, but in 2001: It's in Vaudenay, section 5, applied to randomized padding in SSHv2, where it was fixed. Credit belongs to Luca Bruno for pointing this out on Twitter. No one took the time to sit down with a copy of the paper and a copy of the spec, and compare them until now. I should have, but didn't. TLS isn't alone in this regard: I spent quite a bit of time trying to understand which way CMS composes encryption and authentication, and gave up in frustration reading the pile of RFCs. (The answer I believe is that CMS does not use a MAC by default: there is a different content type that does support AES-GCM, but I have no idea how often it is used. People more familiar than I am with S/MIME should chime in.) What other protocols have random padding in CBC mode after a MAC? Is there any way to determine this beyond asking everyone to help, dividing up a list of nearly 8,000 RFCs, and looking at them all? And perhaps most importantly, what process changes will prevent known attacks from surprising us in the future? There's also a question about how conservative we need to be when doing new cryptographic protocols. But that's a more challenging one. Sincerely, Watson Ladd From nobody Tue Oct 14 19:07:08 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9465D1A0151; Tue, 14 Oct 2014 19:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5RZpsvd3ITh; Tue, 14 Oct 2014 19:07:02 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB24B1A0145; Tue, 14 Oct 2014 19:07:01 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s9F270Ru025536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 15 Oct 2014 02:07:01 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s9F26x2a022030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Oct 2014 02:07:00 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s9F26wFY012439; Wed, 15 Oct 2014 02:06:59 GMT Received: from [10.159.70.14] (/10.159.70.14) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 14 Oct 2014 19:06:58 -0700 Message-ID: <543DD6D6.4080000@oracle.com> Date: Tue, 14 Oct 2014 20:07:18 -0600 From: Shawn M Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/20140924 Thunderbird/17.0.11 MIME-Version: 1.0 To: saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/saag/u9R4moJ7iRuZkRnySOGhLVtF90M Cc: Darren J Moffat , uri-review@ietf.org, Jan Pechanec Subject: [saag] Review Request for draft-pechanec-pkcs11uri-16 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 02:07:06 -0000 Folks, Apologies for any duplicate posts. We are looking for review comments on an individual submission that defines a URI scheme for PKCS#11 objects, tokens, and libraries. The draft can be found here: https://tools.ietf.org/html/draft-pechanec-pkcs11uri-16 Please send any comments to the list, even if your review of the document found no issues. Stephen Farrell has agreed to be the AD sponsor of the individual submission. Thank you, Shawn. -- From nobody Wed Oct 15 02:56:17 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E87B1A19E7 for ; Wed, 15 Oct 2014 02:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5xvY77tJtwZ for ; Wed, 15 Oct 2014 02:56:01 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E741B1A017A for ; Wed, 15 Oct 2014 02:56:00 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id em10so1369708wid.13 for ; Wed, 15 Oct 2014 02:55:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QzhU8CCwcAT2cHyH0++Wy0YQ8E5NdQg05pGlooVAreQ=; b=bmDhqvAfVA21aaEca6rvSOe4VSWUPCK4XjT0II+XB1A9gHHG1jG/HvvAqAloVv710d Lf5Zu1YMlSzQLFuMb9hPRAX6IKY26gfjC7iEjbSCxE5KlGMLzcmSfUte8dn9HjgIaRGl ME6QgnOsCPFVk5STKDnB6jFlHEZ5XTOgXGAUCW46AgS3jp5p7aoVPDy3o2NcVijc0EfG cQeFZ4rdYpxmxT9nwmuwpfNgGM0kxopQ5f8Dznv1OztyX7Z1tGf92vq3AsVYTNVMy51W cIxTQ/yPIcOuAfyiy3amREEqRisXH1bAyR/AoUXWac+jJ407Eou6Q8fWOfh5WpZrj3fv tIMw== X-Received: by 10.194.236.232 with SMTP id ux8mr9016395wjc.96.1413366959506; Wed, 15 Oct 2014 02:55:59 -0700 (PDT) Received: from [192.168.1.104] (IGLD-84-228-54-205.inter.net.il. [84.228.54.205]) by mx.google.com with ESMTPSA id xw9sm3202384wjc.24.2014.10.15.02.55.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 Oct 2014 02:55:59 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Yoav Nir In-Reply-To: Date: Wed, 15 Oct 2014 12:55:57 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <7AA42DB5-8F81-449E-ADBC-677B111C0D10@gmail.com> References: To: Watson Ladd X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/GdGn9yXIfAgwqNRCddPU_hlMJyI Cc: "saag@ietf.org" Subject: Re: [saag] POODLE avant le chein X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 09:56:09 -0000 On Oct 15, 2014, at 4:20 AM, Watson Ladd wrote: > Dear all, >=20 > Now that we've all disabled SSLv3 on every machine in reach, Well, 4.2% of us have [1]. On the bright side, 97.5% support something = better. > let's > review when this attack was discovered. Not in 2014, but in 2001: It's > in Vaudenay, section 5, applied to randomized padding in SSHv2, where > it was fixed. Credit belongs to Luca Bruno for pointing this out on > Twitter. >=20 > No one took the time to sit down with a copy of the paper and a copy > of the spec, and compare them until now. I should have, but didn't. > TLS isn't alone in this regard: I spent quite a bit of time trying to > understand which way CMS composes encryption and authentication, and > gave up in frustration reading the pile of RFCs. (The answer I believe > is that CMS does not use a MAC by default: there is a different > content type that does support AES-GCM, but I have no idea how often > it is used. People more familiar than I am with S/MIME should chime > in.) >=20 > What other protocols have random padding in CBC mode after a MAC? Is > there any way to determine this beyond asking everyone to help, > dividing up a list of nearly 8,000 RFCs, and looking at them all? And > perhaps most importantly, what process changes will prevent known > attacks from surprising us in the future? >=20 > There's also a question about how conservative we need to be when > doing new cryptographic protocols. But that's a more challenging one. First, you don=92t have to go over all 8000 RFCs, and there are some = standards (wifi or web) that are defined by IEEE and W3C respectively. = And some of those RFCs are for things nobody uses (either now or ever). = So it=92s more important to survey stuff that people actually: TLS, SSH, = and IPsec come to mind. There are a few other protocols that are in some = use like MPPE and PPTP, but they are rarely used today for their = security extensions that allowed encryption. Yoav [1] = https://securitypitfalls.wordpress.com/2014/09/29/scan-results-for-septemb= er-2014/= From nobody Wed Oct 15 04:32:13 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32C671A01AA for ; Wed, 15 Oct 2014 04:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyF-4gn-84mt for ; Wed, 15 Oct 2014 04:32:10 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01B051A003A for ; Wed, 15 Oct 2014 04:32:09 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id A30566D7E8; Wed, 15 Oct 2014 07:32:07 -0400 (EDT) Message-ID: <543E5B35.5000604@iang.org> Date: Wed, 15 Oct 2014 12:32:05 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/rx_Se3feK1P7gFZ7iBl1wskxA2M Subject: Re: [saag] POODLE avant le chein X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 11:32:12 -0000 On 15/10/2014 02:20 am, Watson Ladd wrote: > Dear all, > > Now that we've all disabled SSLv3 on every machine in reach, let's > review when this attack was discovered. Not in 2014, but in 2001: It's > in Vaudenay, section 5, applied to randomized padding in SSHv2, where > it was fixed. Credit belongs to Luca Bruno for pointing this out on > Twitter. (FWIW, when I was designing in the early 2000s, I was well aware of the need to move the padding into the domain of the MAC, and out of CBC-harm's way; we stuck the pad at the front. Which is to say it was not specialist knowledge.) > No one took the time to sit down with a copy of the paper and a copy > of the spec, and compare them until now. I should have, but didn't. > TLS isn't alone in this regard: I spent quite a bit of time trying to > understand which way CMS composes encryption and authentication, and > gave up in frustration reading the pile of RFCs. (The answer I believe > is that CMS does not use a MAC by default: there is a different > content type that does support AES-GCM, but I have no idea how often > it is used. People more familiar than I am with S/MIME should chime > in.) > > What other protocols have random padding in CBC mode after a MAC? I believe there's a better way to look at this. The better question is, do TLS versions have the random padding in CBC mode after a MAC? At a guess, later ones do not. Assuming that, then TLS is the solution. So the real question for engineers is this: why is SSL 3.0 still in use? > Is > there any way to determine this beyond asking everyone to help, > dividing up a list of nearly 8,000 RFCs, and looking at them all? :) > And > perhaps most importantly, what process changes will prevent known > attacks from surprising us in the future? > There's also a question about how conservative we need to be when > doing new cryptographic protocols. But that's a more challenging one. I believe it's the one that will answer the problem. The process change that is needed is how to upgrade protocols on a routine basis, so that older designs can fall away without embarrassment. (To put this in perspective, an oft-touted feature of the policy of algorithm agility is the ability to switch from one algorithm to another. But even there, there lacks any sense of how we do the switch.) Solve the problem that solves most of the attack space: upgrade! iang From nobody Wed Oct 15 04:58:59 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 382CE1A1B53 for ; Wed, 15 Oct 2014 04:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QAgXgCjbr5WO for ; Wed, 15 Oct 2014 04:58:56 -0700 (PDT) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49ED91A1B51 for ; Wed, 15 Oct 2014 04:58:56 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id s7so680646qap.32 for ; Wed, 15 Oct 2014 04:58:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KV6DctkA57e+ExwXu7nW1gIyBR4+Ws5XuXZNFwr68mM=; b=rrYMb8NVpHAG5bcsnc/GbWXi8dxtv7xiKKyqkjZOkR87JcOXJL3xdhvoiA/XVoAPOT 2VIpGZ0UKxeY4ahGsefWS9MEHqnTkTvGPFI7oNlGHl+CiQIwWBgLSdkhWI9RntWBKuwG Vm2Oap9EXKH+jYDVNackrQ8LK9jfcklWzqVJZXv/C5v29ubW617zbtk3+Hfzj9OV1LHd nF/J9HjyrGvwhmoB3L7FS37sdWD9QCCY1urNqIyDdFG44m6yYgUSDQlYNTuTs+ovAAdi fCThvp66TYv5sOK8cMtsh82yZZbmof0YWMWMaM6fyNnw8zSrcSnWP44y7BoKjrIy8ZOi w2fA== X-Received: by 10.224.167.208 with SMTP id r16mr17508901qay.42.1413374335260; Wed, 15 Oct 2014 04:58:55 -0700 (PDT) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id d68sm17309313qga.17.2014.10.15.04.58.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 Oct 2014 04:58:53 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: <543E5B35.5000604@iang.org> Date: Wed, 15 Oct 2014 07:58:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <543E5B35.5000604@iang.org> To: ianG Archived-At: http://mailarchive.ietf.org/arch/msg/saag/7ayjFNdoWbxTUXOlK3wuOWKMiCg Cc: "saag@ietf.org" Subject: Re: [saag] POODLE avant le chein X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 11:58:58 -0000 Sent from my iPhone > On Oct 15, 2014, at 7:32 AM, ianG wrote: >=20 >> On 15/10/2014 02:20 am, Watson Ladd wrote: >> Dear all, >>=20 >> Now that we've all disabled SSLv3 on every machine in reach, let's >> review when this attack was discovered. Not in 2014, but in 2001: It's >> in Vaudenay, section 5, applied to randomized padding in SSHv2, where >> it was fixed. Credit belongs to Luca Bruno for pointing this out on >> Twitter. >=20 >=20 > (FWIW, when I was designing in the early 2000s, I was well aware of the > need to move the padding into the domain of the MAC, and out of > CBC-harm's way; we stuck the pad at the front. Which is to say it was > not specialist knowledge.) >=20 >=20 >> No one took the time to sit down with a copy of the paper and a copy >> of the spec, and compare them until now. I should have, but didn't. >> TLS isn't alone in this regard: I spent quite a bit of time trying to >> understand which way CMS composes encryption and authentication, and >> gave up in frustration reading the pile of RFCs. (The answer I believe >> is that CMS does not use a MAC by default: there is a different >> content type that does support AES-GCM, but I have no idea how often >> it is used. People more familiar than I am with S/MIME should chime >> in.) >>=20 >> What other protocols have random padding in CBC mode after a MAC? >=20 >=20 > I believe there's a better way to look at this. The better question is, > do TLS versions have the random padding in CBC mode after a MAC? >=20 > At a guess, later ones do not. Assuming that, then TLS is the solution. > So the real question for engineers is this: why is SSL 3.0 still in use? >=20 My take on this is that server operators are afraid to break their clients. = What if browsers deprecated support for older versions so that it becomes e= asier for server operators to turn off support?=20 Could we work together with all the browser vendors to phase out SSLv3? The= n anything else we should deprecate. Of course this requires people to upgr= ade browsers. Thanks, Kathleen >=20 >> Is >> there any way to determine this beyond asking everyone to help, >> dividing up a list of nearly 8,000 RFCs, and looking at them all? >=20 > :) >=20 >> And >> perhaps most importantly, what process changes will prevent known >> attacks from surprising us in the future? >=20 >> There's also a question about how conservative we need to be when >> doing new cryptographic protocols. But that's a more challenging one. >=20 >=20 > I believe it's the one that will answer the problem. The process change > that is needed is how to upgrade protocols on a routine basis, so that > older designs can fall away without embarrassment. >=20 > (To put this in perspective, an oft-touted feature of the policy of > algorithm agility is the ability to switch from one algorithm to > another. But even there, there lacks any sense of how we do the switch.) >=20 > Solve the problem that solves most of the attack space: upgrade! >=20 >=20 >=20 > iang >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Wed Oct 15 08:41:13 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 500CB1A883A for ; Wed, 15 Oct 2014 08:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQmKFxDjzO9S for ; Wed, 15 Oct 2014 08:41:01 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B8821A8843 for ; Wed, 15 Oct 2014 08:41:01 -0700 (PDT) Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com [10.106.48.160]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s9FFewXA032326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Oct 2014 11:40:59 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com s9FFewXA032326 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1413387659; bh=y3U2Gc+HRJM3/OA4RstaUlydd1U=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=Kk0DLX7N2KJCVkfaoKbfpjzpIgzhTlQOkFLyODHMnTRjoY2wAbYReXYdLafwhqIPc UvVnO0A+0CeXuI5vQisHuETZwMMFAhzVHCJAej0k9uPy8zb/gQuAfNfEn4W9+le967 QvYcUpbd9KNmVLZ6YDim/4wrsIBa81XSmdTXLXgg= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com s9FFewXA032326 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd56.lss.emc.com (RSA Interceptor); Wed, 15 Oct 2014 11:40:23 -0400 Received: from mxhub24.corp.emc.com (mxhub24.corp.emc.com [128.222.70.136]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s9FFeken030883 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 Oct 2014 11:40:46 -0400 Received: from MXHUB104.corp.emc.com (10.253.58.16) by mxhub24.corp.emc.com (128.222.70.136) with Microsoft SMTP Server (TLS) id 8.3.327.1; Wed, 15 Oct 2014 11:40:45 -0400 Received: from MX104CL02.corp.emc.com ([169.254.8.131]) by MXHUB104.corp.emc.com ([::1]) with mapi id 14.03.0195.001; Wed, 15 Oct 2014 11:40:45 -0400 From: "Black, David" To: Kathleen Moriarty Thread-Topic: [saag] POODLE avant le chein Thread-Index: AQHP6BY9vaNCVSH8iUO10S2TatftnZwxSiyAgAAHfAD///nk8A== Date: Wed, 15 Oct 2014 15:40:44 +0000 Message-ID: References: <543E5B35.5000604@iang.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.122] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/saag/mlTTlp1UTTEENU1YxmAFk1RQBFQ Cc: "saag@ietf.org" Subject: Re: [saag] POODLE avant le chein X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 15:41:09 -0000 > What if browsers deprecated support for older versions so that it becomes > easier for server operators to turn off support? One down (Firefox) ... https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-end-= of-ssl-3-0/ "SSLv3 will be disabled by default in Firefox 34, which will be released on= Nov 25." FYI, --David Nit: Le mot en francais est "le chien", pas "le chein" ;-). > -----Original Message----- > From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Kathleen Moriarty > Sent: Wednesday, October 15, 2014 7:59 AM > To: ianG > Cc: saag@ietf.org > Subject: Re: [saag] POODLE avant le chein >=20 >=20 >=20 > Sent from my iPhone >=20 > > On Oct 15, 2014, at 7:32 AM, ianG wrote: > > > >> On 15/10/2014 02:20 am, Watson Ladd wrote: > >> Dear all, > >> > >> Now that we've all disabled SSLv3 on every machine in reach, let's > >> review when this attack was discovered. Not in 2014, but in 2001: It's > >> in Vaudenay, section 5, applied to randomized padding in SSHv2, where > >> it was fixed. Credit belongs to Luca Bruno for pointing this out on > >> Twitter. > > > > > > (FWIW, when I was designing in the early 2000s, I was well aware of the > > need to move the padding into the domain of the MAC, and out of > > CBC-harm's way; we stuck the pad at the front. Which is to say it was > > not specialist knowledge.) > > > > > >> No one took the time to sit down with a copy of the paper and a copy > >> of the spec, and compare them until now. I should have, but didn't. > >> TLS isn't alone in this regard: I spent quite a bit of time trying to > >> understand which way CMS composes encryption and authentication, and > >> gave up in frustration reading the pile of RFCs. (The answer I believe > >> is that CMS does not use a MAC by default: there is a different > >> content type that does support AES-GCM, but I have no idea how often > >> it is used. People more familiar than I am with S/MIME should chime > >> in.) > >> > >> What other protocols have random padding in CBC mode after a MAC? > > > > > > I believe there's a better way to look at this. The better question is= , > > do TLS versions have the random padding in CBC mode after a MAC? > > > > At a guess, later ones do not. Assuming that, then TLS is the solution= . > > So the real question for engineers is this: why is SSL 3.0 still in us= e? > > >=20 > My take on this is that server operators are afraid to break their client= s. > What if browsers deprecated support for older versions so that it becomes > easier for server operators to turn off support? >=20 > Could we work together with all the browser vendors to phase out SSLv3? = Then > anything else we should deprecate. Of course this requires people to upg= rade > browsers. >=20 > Thanks, > Kathleen > > > >> Is > >> there any way to determine this beyond asking everyone to help, > >> dividing up a list of nearly 8,000 RFCs, and looking at them all? > > > > :) > > > >> And > >> perhaps most importantly, what process changes will prevent known > >> attacks from surprising us in the future? > > > >> There's also a question about how conservative we need to be when > >> doing new cryptographic protocols. But that's a more challenging one. > > > > > > I believe it's the one that will answer the problem. The process chang= e > > that is needed is how to upgrade protocols on a routine basis, so that > > older designs can fall away without embarrassment. > > > > (To put this in perspective, an oft-touted feature of the policy of > > algorithm agility is the ability to switch from one algorithm to > > another. But even there, there lacks any sense of how we do the switch= .) > > > > Solve the problem that solves most of the attack space: upgrade! > > > > > > > > iang > > > > _______________________________________________ > > saag mailing list > > saag@ietf.org > > https://www.ietf.org/mailman/listinfo/saag >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Wed Oct 15 08:46:36 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A48A91A885C for ; Wed, 15 Oct 2014 08:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.769 X-Spam-Level: X-Spam-Status: No, score=0.769 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.982] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lF73DHngBOml for ; Wed, 15 Oct 2014 08:46:32 -0700 (PDT) Received: from minorthreat.org (ec2-54-68-221-247.us-west-2.compute.amazonaws.com [54.68.221.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 435901A884C for ; Wed, 15 Oct 2014 08:46:32 -0700 (PDT) Received: from [192.168.43.134] ([172.56.39.118]) (authenticated bits=0) by minorthreat.org (8.14.9/8.14.9) with ESMTP id s9FFjrHZ007851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 15 Oct 2014 15:46:01 GMT (envelope-from joelja@bogus.com) Message-ID: <543E96C1.3030301@bogus.com> Date: Wed, 15 Oct 2014 08:46:09 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:33.0) Gecko/20100101 Thunderbird/33.0 MIME-Version: 1.0 To: "Black, David" , Kathleen Moriarty References: <543E5B35.5000604@iang.org> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Dv6HLqwce2iaRbnfJ7QdCwrjrsCQPBoLT" Archived-At: http://mailarchive.ietf.org/arch/msg/saag/dOKhjOEmWji0pkLsjGusvClPGDY Cc: "saag@ietf.org" Subject: Re: [saag] POODLE avant le chein X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 15:46:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Dv6HLqwce2iaRbnfJ7QdCwrjrsCQPBoLT Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 10/15/14 8:40 AM, Black, David wrote: >> What if browsers deprecated support for older versions so that it beco= mes >> easier for server operators to turn off support? >=20 > One down (Firefox) ... >=20 > https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-= end-of-ssl-3-0/ >=20 > "SSLv3 will be disabled by default in Firefox 34, which will be release= d on Nov 25." basically server operators are already making the jump. https://blogs.akamai.com/2014/10/ssl-is-dead-long-live-tls.html https://blog.cloudflare.com/sslv3-support-disabled-by-default-due-to-vuln= erability/ http://www.fastly.com/blog/ > FYI, > --David > Nit: Le mot en francais est "le chien", pas "le chein" ;-). >=20 >> -----Original Message----- >> From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Kathleen Moriar= ty >> Sent: Wednesday, October 15, 2014 7:59 AM >> To: ianG >> Cc: saag@ietf.org >> Subject: Re: [saag] POODLE avant le chein >> >> >> >> Sent from my iPhone >> >>> On Oct 15, 2014, at 7:32 AM, ianG wrote: >>> >>>> On 15/10/2014 02:20 am, Watson Ladd wrote: >>>> Dear all, >>>> >>>> Now that we've all disabled SSLv3 on every machine in reach, let's >>>> review when this attack was discovered. Not in 2014, but in 2001: It= 's >>>> in Vaudenay, section 5, applied to randomized padding in SSHv2, wher= e >>>> it was fixed. Credit belongs to Luca Bruno for pointing this out on >>>> Twitter. >>> >>> >>> (FWIW, when I was designing in the early 2000s, I was well aware of t= he >>> need to move the padding into the domain of the MAC, and out of >>> CBC-harm's way; we stuck the pad at the front. Which is to say it wa= s >>> not specialist knowledge.) >>> >>> >>>> No one took the time to sit down with a copy of the paper and a copy= >>>> of the spec, and compare them until now. I should have, but didn't. >>>> TLS isn't alone in this regard: I spent quite a bit of time trying t= o >>>> understand which way CMS composes encryption and authentication, and= >>>> gave up in frustration reading the pile of RFCs. (The answer I belie= ve >>>> is that CMS does not use a MAC by default: there is a different >>>> content type that does support AES-GCM, but I have no idea how often= >>>> it is used. People more familiar than I am with S/MIME should chime >>>> in.) >>>> >>>> What other protocols have random padding in CBC mode after a MAC? >>> >>> >>> I believe there's a better way to look at this. The better question = is, >>> do TLS versions have the random padding in CBC mode after a MAC? >>> >>> At a guess, later ones do not. Assuming that, then TLS is the soluti= on. >>> So the real question for engineers is this: why is SSL 3.0 still in = use? >>> >> >> My take on this is that server operators are afraid to break their cli= ents. >> What if browsers deprecated support for older versions so that it beco= mes >> easier for server operators to turn off support? >> >> Could we work together with all the browser vendors to phase out SSLv3= ? Then >> anything else we should deprecate. Of course this requires people to = upgrade >> browsers. >> >> Thanks, >> Kathleen >>> >>>> Is >>>> there any way to determine this beyond asking everyone to help, >>>> dividing up a list of nearly 8,000 RFCs, and looking at them all? >>> >>> :) >>> >>>> And >>>> perhaps most importantly, what process changes will prevent known >>>> attacks from surprising us in the future? >>> >>>> There's also a question about how conservative we need to be when >>>> doing new cryptographic protocols. But that's a more challenging one= =2E >>> >>> >>> I believe it's the one that will answer the problem. The process cha= nge >>> that is needed is how to upgrade protocols on a routine basis, so tha= t >>> older designs can fall away without embarrassment. >>> >>> (To put this in perspective, an oft-touted feature of the policy of >>> algorithm agility is the ability to switch from one algorithm to >>> another. But even there, there lacks any sense of how we do the swit= ch.) >>> >>> Solve the problem that solves most of the attack space: upgrade! >>> >>> >>> >>> iang >>> >>> _______________________________________________ >>> 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 >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag >=20 --Dv6HLqwce2iaRbnfJ7QdCwrjrsCQPBoLT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlQ+lsEACgkQ8AA1q7Z/VrKYkQCff2btt7bjG7guERVdXlQl+jtx jWcAni25sJjYJdG7uVHFir/2BpTSIKPB =EKnm -----END PGP SIGNATURE----- --Dv6HLqwce2iaRbnfJ7QdCwrjrsCQPBoLT-- From nobody Wed Oct 15 08:46:59 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6BF1A8865 for ; Wed, 15 Oct 2014 08:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4bX-OIYQVrD for ; Wed, 15 Oct 2014 08:46:54 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D767A1A883F for ; Wed, 15 Oct 2014 08:46:50 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id n15so1245389lbi.25 for ; Wed, 15 Oct 2014 08:46:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1jN+PpsfO5zVGu1c5RCqLgJa5xsawLgIoIe3pwnhUhM=; b=HtS/AZtrBVdpnBBcaACt+HbUSalABACwwRwxGWA5Pn1QKUqSI41LzRHlxRrsByPswY XF3L6lOWjWRLRIywTGI+EYZe4PY2BNYBR9tD86HCmzEOQ9yXUJswp+jNtV8WADC0I2pF 2sv3mJdMofCF03bkBYx99wLpCYCj4DMfbfVYbKc73m1OX2/PnX1Oce9fQocn+3tJy6N8 gVvNin6D7yB/OqP1YTR6VRAG6UU7duDs63xSOU6LpSq31ojaZbhJITRb7tjF2WvDMZdb /SD/v1HlwsP8w41fLL3IC4rvasbTHEz4nWzIoz7NaWIHRPVzB5XRr34KKqjnoYFO2tRB ke4w== MIME-Version: 1.0 X-Received: by 10.112.173.69 with SMTP id bi5mr4665410lbc.61.1413388009020; Wed, 15 Oct 2014 08:46:49 -0700 (PDT) Received: by 10.112.95.36 with HTTP; Wed, 15 Oct 2014 08:46:48 -0700 (PDT) In-Reply-To: References: <543E5B35.5000604@iang.org> Date: Wed, 15 Oct 2014 11:46:48 -0400 Message-ID: From: Kathleen Moriarty To: "Black, David" Content-Type: multipart/alternative; boundary=001a11c234e83523910505780a62 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/W2WP8dDWo5bFRtKMhK4hgZ5sY-M Cc: "saag@ietf.org" Subject: Re: [saag] POODLE avant le chein X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 15:46:57 -0000 --001a11c234e83523910505780a62 Content-Type: text/plain; charset=UTF-8 On Wed, Oct 15, 2014 at 11:40 AM, Black, David wrote: > > What if browsers deprecated support for older versions so that it becomes > > easier for server operators to turn off support? > > One down (Firefox) ... > > > https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-end-of-ssl-3-0/ > > "SSLv3 will be disabled by default in Firefox 34, which will be released > on Nov 25." > Thanks for the article, it looks like the major browser vendors are already working together, no surprise there, but a big thanks to each of them as that's probably the best way to tackle this (from my experience). > > FYI, > --David > Nit: Le mot en francais est "le chien", pas "le chein" ;-). > > > -----Original Message----- > > From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Kathleen Moriarty > > Sent: Wednesday, October 15, 2014 7:59 AM > > To: ianG > > Cc: saag@ietf.org > > Subject: Re: [saag] POODLE avant le chein > > > > > > > > Sent from my iPhone > > > > > On Oct 15, 2014, at 7:32 AM, ianG wrote: > > > > > >> On 15/10/2014 02:20 am, Watson Ladd wrote: > > >> Dear all, > > >> > > >> Now that we've all disabled SSLv3 on every machine in reach, let's > > >> review when this attack was discovered. Not in 2014, but in 2001: It's > > >> in Vaudenay, section 5, applied to randomized padding in SSHv2, where > > >> it was fixed. Credit belongs to Luca Bruno for pointing this out on > > >> Twitter. > > > > > > > > > (FWIW, when I was designing in the early 2000s, I was well aware of the > > > need to move the padding into the domain of the MAC, and out of > > > CBC-harm's way; we stuck the pad at the front. Which is to say it was > > > not specialist knowledge.) > > > > > > > > >> No one took the time to sit down with a copy of the paper and a copy > > >> of the spec, and compare them until now. I should have, but didn't. > > >> TLS isn't alone in this regard: I spent quite a bit of time trying to > > >> understand which way CMS composes encryption and authentication, and > > >> gave up in frustration reading the pile of RFCs. (The answer I believe > > >> is that CMS does not use a MAC by default: there is a different > > >> content type that does support AES-GCM, but I have no idea how often > > >> it is used. People more familiar than I am with S/MIME should chime > > >> in.) > > >> > > >> What other protocols have random padding in CBC mode after a MAC? > > > > > > > > > I believe there's a better way to look at this. The better question > is, > > > do TLS versions have the random padding in CBC mode after a MAC? > > > > > > At a guess, later ones do not. Assuming that, then TLS is the > solution. > > > So the real question for engineers is this: why is SSL 3.0 still in > use? > > > > > > > My take on this is that server operators are afraid to break their > clients. > > What if browsers deprecated support for older versions so that it becomes > > easier for server operators to turn off support? > > > > Could we work together with all the browser vendors to phase out SSLv3? > Then > > anything else we should deprecate. Of course this requires people to > upgrade > > browsers. > > > > Thanks, > > Kathleen > > > > > >> Is > > >> there any way to determine this beyond asking everyone to help, > > >> dividing up a list of nearly 8,000 RFCs, and looking at them all? > > > > > > :) > > > > > >> And > > >> perhaps most importantly, what process changes will prevent known > > >> attacks from surprising us in the future? > > > > > >> There's also a question about how conservative we need to be when > > >> doing new cryptographic protocols. But that's a more challenging one. > > > > > > > > > I believe it's the one that will answer the problem. The process > change > > > that is needed is how to upgrade protocols on a routine basis, so that > > > older designs can fall away without embarrassment. > > > > > > (To put this in perspective, an oft-touted feature of the policy of > > > algorithm agility is the ability to switch from one algorithm to > > > another. But even there, there lacks any sense of how we do the > switch.) > > > > > > Solve the problem that solves most of the attack space: upgrade! > > > > > > > > > > > > iang > > > > > > _______________________________________________ > > > 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 > -- Best regards, Kathleen --001a11c234e83523910505780a62 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Oct 15, 2014 at 11:40 AM, Black, David <david.black@emc.com<= /a>> wrote:
&g= t; What if browsers deprecated support for older versions so that it become= s
> easier for server operators to turn off support?

One down (Firefox) ...

https://blog.mozilla.org/security= /2014/10/14/the-poodle-attack-and-the-end-of-ssl-3-0/

"SSLv3 will be disabled by default in Firefox 34, which will be releas= ed on Nov 25."

Thanks for the arti= cle, it looks like the major browser vendors are already working together, = no surprise there, but a big thanks to each of them as that's probably = the best way to tackle this (from my experience).
=C2=A0

FYI,
--David
Nit: Le mot en francais est "le chien", pas "le chein" = ;-).

> -----Original Message-----
> From: saag [mailto:saag-bounc= es@ietf.org] On Behalf Of Kathleen Moriarty
> Sent: Wednesday, October 15, 2014 7:59 AM
> To: ianG
> Cc: saag@ietf.org
> Subject: Re: [saag] POODLE avant le chein
>
>
>
> Sent from my iPhone
>
> > On Oct 15, 2014, at 7:32 AM, ianG <iang@iang.org> wrote:
> >
> >> On 15/10/2014 02:20 am, Watson Ladd wrote:
> >> Dear all,
> >>
> >> Now that we've all disabled SSLv3 on every machine in rea= ch, let's
> >> review when this attack was discovered. Not in 2014, but in 2= 001: It's
> >> in Vaudenay, section 5, applied to randomized padding in SSHv= 2, where
> >> it was fixed. Credit belongs to Luca Bruno for pointing this = out on
> >> Twitter.
> >
> >
> > (FWIW, when I was designing in the early 2000s, I was well aware = of the
> > need to move the padding into the domain of the MAC, and out of > > CBC-harm's way; we stuck the pad at the front.=C2=A0 Which is= to say it was
> > not specialist knowledge.)
> >
> >
> >> No one took the time to sit down with a copy of the paper and= a copy
> >> of the spec, and compare them until now. I should have, but d= idn't.
> >> TLS isn't alone in this regard: I spent quite a bit of ti= me trying to
> >> understand which way CMS composes encryption and authenticati= on, and
> >> gave up in frustration reading the pile of RFCs. (The answer = I believe
> >> is that CMS does not use a MAC by default: there is a differe= nt
> >> content type that does support AES-GCM, but I have no idea ho= w often
> >> it is used. People more familiar than I am with S/MIME should= chime
> >> in.)
> >>
> >> What other protocols have random padding in CBC mode after a = MAC?
> >
> >
> > I believe there's a better way to look at this.=C2=A0 The bet= ter question is,
> > do TLS versions have the random padding in CBC mode after a MAC?<= br> > >
> > At a guess, later ones do not.=C2=A0 Assuming that, then TLS is t= he solution.
> > So the real question for engineers is this:=C2=A0 why is SSL 3.0 = still in use?
> >
>
> My take on this is that server operators are afraid to break their cli= ents.
> What if browsers deprecated support for older versions so that it beco= mes
> easier for server operators to turn off support?
>
> Could we work together with all the browser vendors to phase out SSLv3= ?=C2=A0 Then
> anything else we should deprecate.=C2=A0 Of course this requires peopl= e to upgrade
> browsers.
>
> Thanks,
> Kathleen
> >
> >> Is
> >> there any way to determine this beyond asking everyone to hel= p,
> >> dividing up a list of nearly 8,000 RFCs, and looking at them = all?
> >
> > :)
> >
> >> And
> >> perhaps most importantly, what process changes will prevent k= nown
> >> attacks from surprising us in the future?
> >
> >> There's also a question about how conservative we need to= be when
> >> doing new cryptographic protocols. But that's a more chal= lenging one.
> >
> >
> > I believe it's the one that will answer the problem.=C2=A0 Th= e process change
> > that is needed is how to upgrade protocols on a routine basis, so= that
> > older designs can fall away without embarrassment.
> >
> > (To put this in perspective, an oft-touted feature of the policy = of
> > algorithm agility is the ability to switch from one algorithm to<= br> > > another.=C2=A0 But even there, there lacks any sense of how we do= the switch.)
> >
> > Solve the problem that solves most of the attack space:=C2=A0 upg= rade!
> >
> >
> >
> > iang
> >
> > _______________________________________________
> > 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



--
=

Best regards,
Kathleen
--001a11c234e83523910505780a62-- From nobody Wed Oct 15 08:48:17 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD8E11A8864 for ; Wed, 15 Oct 2014 08:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sEccRF-0bucT for ; Wed, 15 Oct 2014 08:48:11 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20A491A885C for ; Wed, 15 Oct 2014 08:48:10 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id w7so1273469lbi.22 for ; Wed, 15 Oct 2014 08:48:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bThwDIDN1hCe+3mc9Hp325qcG7ar0U+tq8BAGYNjQgQ=; b=MBzS0b5p0R2kJPpLv3aBRpxtCbgdB2AQ+FANqsYBVC40htFiWJy1i2E2svoIT+HyfN vA/9/OvVkT57jq3//hyaKPK773M04niTP0pLNhGkZ1UKalvcBwk8JY8Haxu1D+Bc67j4 L1YUBu2HooMAXvX/sbMkTsPNNJ/GUoFJ7ENjazu1h7Jw5sFi2dURgBm56mccvYo7Ww3D TkdjXLsgKDRqwnXkCk8uUieewXchq1bpDWIEcjdodpdtBoY8T0E56YySrf6c14zgDCpq D/sjf4iJjIs0oJABztp8lV0eNyiE+K+LIxS/upaaL+zigCT4PNnQXuXL6CIhXftZW4Qn f6Ug== MIME-Version: 1.0 X-Received: by 10.112.137.202 with SMTP id qk10mr13287286lbb.0.1413388088505; Wed, 15 Oct 2014 08:48:08 -0700 (PDT) Received: by 10.112.95.36 with HTTP; Wed, 15 Oct 2014 08:48:08 -0700 (PDT) In-Reply-To: <543E96C1.3030301@bogus.com> References: <543E5B35.5000604@iang.org> <543E96C1.3030301@bogus.com> Date: Wed, 15 Oct 2014 11:48:08 -0400 Message-ID: From: Kathleen Moriarty To: joel jaeggli Content-Type: multipart/alternative; boundary=089e01227eb2f1fcbf0505780e5c Archived-At: http://mailarchive.ietf.org/arch/msg/saag/XmuPffNQR2K5UtI2Qetmw5cEHq8 Cc: "saag@ietf.org" Subject: Re: [saag] POODLE avant le chein X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 15:48:15 -0000 --089e01227eb2f1fcbf0505780e5c Content-Type: text/plain; charset=UTF-8 On Wed, Oct 15, 2014 at 11:46 AM, joel jaeggli wrote: > On 10/15/14 8:40 AM, Black, David wrote: > >> What if browsers deprecated support for older versions so that it > becomes > >> easier for server operators to turn off support? > > > > One down (Firefox) ... > > > > > https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-end-of-ssl-3-0/ > > > > "SSLv3 will be disabled by default in Firefox 34, which will be released > on Nov 25." > > basically server operators are already making the jump. > > https://blogs.akamai.com/2014/10/ssl-is-dead-long-live-tls.html > > https://blog.cloudflare.com/sslv3-support-disabled-by-default-due-to-vulnerability/ > http://www.fastly.com/blog/ Cool. It's the enterprise level ones that may fall behind that is my concern, this is all good news, thanks. Back to reading drafts :-) > > > > FYI, > > --David > > Nit: Le mot en francais est "le chien", pas "le chein" ;-). > > > >> -----Original Message----- > >> From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Kathleen > Moriarty > >> Sent: Wednesday, October 15, 2014 7:59 AM > >> To: ianG > >> Cc: saag@ietf.org > >> Subject: Re: [saag] POODLE avant le chein > >> > >> > >> > >> Sent from my iPhone > >> > >>> On Oct 15, 2014, at 7:32 AM, ianG wrote: > >>> > >>>> On 15/10/2014 02:20 am, Watson Ladd wrote: > >>>> Dear all, > >>>> > >>>> Now that we've all disabled SSLv3 on every machine in reach, let's > >>>> review when this attack was discovered. Not in 2014, but in 2001: It's > >>>> in Vaudenay, section 5, applied to randomized padding in SSHv2, where > >>>> it was fixed. Credit belongs to Luca Bruno for pointing this out on > >>>> Twitter. > >>> > >>> > >>> (FWIW, when I was designing in the early 2000s, I was well aware of the > >>> need to move the padding into the domain of the MAC, and out of > >>> CBC-harm's way; we stuck the pad at the front. Which is to say it was > >>> not specialist knowledge.) > >>> > >>> > >>>> No one took the time to sit down with a copy of the paper and a copy > >>>> of the spec, and compare them until now. I should have, but didn't. > >>>> TLS isn't alone in this regard: I spent quite a bit of time trying to > >>>> understand which way CMS composes encryption and authentication, and > >>>> gave up in frustration reading the pile of RFCs. (The answer I believe > >>>> is that CMS does not use a MAC by default: there is a different > >>>> content type that does support AES-GCM, but I have no idea how often > >>>> it is used. People more familiar than I am with S/MIME should chime > >>>> in.) > >>>> > >>>> What other protocols have random padding in CBC mode after a MAC? > >>> > >>> > >>> I believe there's a better way to look at this. The better question > is, > >>> do TLS versions have the random padding in CBC mode after a MAC? > >>> > >>> At a guess, later ones do not. Assuming that, then TLS is the > solution. > >>> So the real question for engineers is this: why is SSL 3.0 still in > use? > >>> > >> > >> My take on this is that server operators are afraid to break their > clients. > >> What if browsers deprecated support for older versions so that it > becomes > >> easier for server operators to turn off support? > >> > >> Could we work together with all the browser vendors to phase out > SSLv3? Then > >> anything else we should deprecate. Of course this requires people to > upgrade > >> browsers. > >> > >> Thanks, > >> Kathleen > >>> > >>>> Is > >>>> there any way to determine this beyond asking everyone to help, > >>>> dividing up a list of nearly 8,000 RFCs, and looking at them all? > >>> > >>> :) > >>> > >>>> And > >>>> perhaps most importantly, what process changes will prevent known > >>>> attacks from surprising us in the future? > >>> > >>>> There's also a question about how conservative we need to be when > >>>> doing new cryptographic protocols. But that's a more challenging one. > >>> > >>> > >>> I believe it's the one that will answer the problem. The process > change > >>> that is needed is how to upgrade protocols on a routine basis, so that > >>> older designs can fall away without embarrassment. > >>> > >>> (To put this in perspective, an oft-touted feature of the policy of > >>> algorithm agility is the ability to switch from one algorithm to > >>> another. But even there, there lacks any sense of how we do the > switch.) > >>> > >>> Solve the problem that solves most of the attack space: upgrade! > >>> > >>> > >>> > >>> iang > >>> > >>> _______________________________________________ > >>> saag mailing list > >>> saag@ietf.org > >>> https://www.ietf.org/mailman/listinfo/saag > >> > >> _______________________________________________ > >> saag mailing list > >> saag@ietf.org > >> https://www.ietf.org/mailman/listinfo/saag > > > > _______________________________________________ > > saag mailing list > > saag@ietf.org > > https://www.ietf.org/mailman/listinfo/saag > > > > > -- Best regards, Kathleen --089e01227eb2f1fcbf0505780e5c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Oct 15, 2014 at 11:46 AM, joel jaeggli <joelja@bogus.com>= ; wrote:
On 10/15= /14 8:40 AM, Black, David wrote:
>> What if browsers deprecated support for older versions so that it = becomes
>> easier for server operators to turn off support?
>
> One down (Firefox) ...
>
> https://blog.mozilla.org/sec= urity/2014/10/14/the-poodle-attack-and-the-end-of-ssl-3-0/
>
> "SSLv3 will be disabled by default in Firefox 34, which will be r= eleased on Nov 25."

basically server operators are already making the jump.

https://blogs.akamai.com/2014/10/ssl-is-dead-long-live-t= ls.html
https://blog.cloudflare.com/sslv3-su= pport-disabled-by-default-due-to-vulnerability/
http://www.fastly= .com/blog/

Cool.=C2=A0 It's the ent= erprise level ones that may fall behind that is my concern, this is all goo= d news, thanks. Back to reading drafts :-)
=C2=A0


> FYI,
> --David
> Nit: Le mot en francais est "le chien", pas "le chein&q= uot; ;-).
>
>> -----Original Message-----
>> From: saag [mailto:saag-b= ounces@ietf.org] On Behalf Of Kathleen Moriarty
>> Sent: Wednesday, October 15, 2014 7:59 AM
>> To: ianG
>> Cc: saag@ietf.org
>> Subject: Re: [saag] POODLE avant le chein
>>
>>
>>
>> Sent from my iPhone
>>
>>> On Oct 15, 2014, at 7:32 AM, ianG <iang@iang.org> wrote:
>>>
>>>> On 15/10/2014 02:20 am, Watson Ladd wrote:
>>>> Dear all,
>>>>
>>>> Now that we've all disabled SSLv3 on every machine in = reach, let's
>>>> review when this attack was discovered. Not in 2014, but i= n 2001: It's
>>>> in Vaudenay, section 5, applied to randomized padding in S= SHv2, where
>>>> it was fixed. Credit belongs to Luca Bruno for pointing th= is out on
>>>> Twitter.
>>>
>>>
>>> (FWIW, when I was designing in the early 2000s, I was well awa= re of the
>>> need to move the padding into the domain of the MAC, and out o= f
>>> CBC-harm's way; we stuck the pad at the front.=C2=A0 Which= is to say it was
>>> not specialist knowledge.)
>>>
>>>
>>>> No one took the time to sit down with a copy of the paper = and a copy
>>>> of the spec, and compare them until now. I should have, bu= t didn't.
>>>> TLS isn't alone in this regard: I spent quite a bit of= time trying to
>>>> understand which way CMS composes encryption and authentic= ation, and
>>>> gave up in frustration reading the pile of RFCs. (The answ= er I believe
>>>> is that CMS does not use a MAC by default: there is a diff= erent
>>>> content type that does support AES-GCM, but I have no idea= how often
>>>> it is used. People more familiar than I am with S/MIME sho= uld chime
>>>> in.)
>>>>
>>>> What other protocols have random padding in CBC mode after= a MAC?
>>>
>>>
>>> I believe there's a better way to look at this.=C2=A0 The = better question is,
>>> do TLS versions have the random padding in CBC mode after a MA= C?
>>>
>>> At a guess, later ones do not.=C2=A0 Assuming that, then TLS i= s the solution.
>>> So the real question for engineers is this:=C2=A0 why is SSL 3= .0 still in use?
>>>
>>
>> My take on this is that server operators are afraid to break their= clients.
>> What if browsers deprecated support for older versions so that it = becomes
>> easier for server operators to turn off support?
>>
>> Could we work together with all the browser vendors to phase out S= SLv3?=C2=A0 Then
>> anything else we should deprecate.=C2=A0 Of course this requires p= eople to upgrade
>> browsers.
>>
>> Thanks,
>> Kathleen
>>>
>>>> Is
>>>> there any way to determine this beyond asking everyone to = help,
>>>> dividing up a list of nearly 8,000 RFCs, and looking at th= em all?
>>>
>>> :)
>>>
>>>> And
>>>> perhaps most importantly, what process changes will preven= t known
>>>> attacks from surprising us in the future?
>>>
>>>> There's also a question about how conservative we need= to be when
>>>> doing new cryptographic protocols. But that's a more c= hallenging one.
>>>
>>>
>>> I believe it's the one that will answer the problem.=C2=A0= The process change
>>> that is needed is how to upgrade protocols on a routine basis,= so that
>>> older designs can fall away without embarrassment.
>>>
>>> (To put this in perspective, an oft-touted feature of the poli= cy of
>>> algorithm agility is the ability to switch from one algorithm = to
>>> another.=C2=A0 But even there, there lacks any sense of how we= do the switch.)
>>>
>>> Solve the problem that solves most of the attack space:=C2=A0 = upgrade!
>>>
>>>
>>>
>>> iang
>>>
>>> _______________________________________________
>>> saag mailing list
>>> saag@ietf.org
>>> https://www.ietf.org/mailman/listinfo/saag
>>
>> _______________________________________________
>> saag mailing list
>> saag@ietf.org
>> https://www.ietf.org/mailman/listinfo/saag
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
>





--
=

Best regards,
Kathleen
--089e01227eb2f1fcbf0505780e5c-- From nobody Wed Oct 15 08:56:32 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0FC31A8895 for ; Wed, 15 Oct 2014 08:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUy28g8PVa5y for ; Wed, 15 Oct 2014 08:56:28 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id B23211A885F for ; Wed, 15 Oct 2014 08:56:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 11E55BED4 for ; Wed, 15 Oct 2014 16:56:28 +0100 (IST) 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 I8Lz5MLQ_Jhn for ; Wed, 15 Oct 2014 16:56:27 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E73B2BE83 for ; Wed, 15 Oct 2014 16:56:27 +0100 (IST) Message-ID: <543E992C.7000802@cs.tcd.ie> Date: Wed, 15 Oct 2014 16:56:28 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: "saag@ietf.org" References: <543E5B35.5000604@iang.org> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/uQj2NkTpbfSNqt2bFHwpFDylRa4 Subject: [saag] getting rid of fairly old stuff (was: Re: POODLE avant le chein) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 15:56:30 -0000 On 15/10/14 16:46, Kathleen Moriarty wrote: > Thanks for the article, it looks like the major browser vendors are already > working together, no surprise there, but a big thanks to each of them as > that's probably the best way to tackle this (from my experience). Hopefully so, and good to see the browsers and some large server sites moving. If they can now get rid of SSLv3 within say a couple of months, (and I hope they can), then we should maybe be asking ourselves if we (the IETF) can help 'em somehow not let such stuff linger for so long in future. Not sure how, but say if we'd published an "SSLv3 considered possibly harmful" RFC about 8 years after RFC 2246 was published, do we think that might have helped, or might an equivalent help in future? Looking about randomly, I see TLS1.1 is 8 years old now:-) And just to clarify, my question isn't really about TLS, but about whether there's an IETF thing to be done here that might help. (And the answer for now is I'm not sure.) S. From nobody Wed Oct 15 09:02:17 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D34D31A889E for ; Wed, 15 Oct 2014 09:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.769 X-Spam-Level: X-Spam-Status: No, score=0.769 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.982] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Yg__oE05GXK for ; Wed, 15 Oct 2014 09:02:14 -0700 (PDT) Received: from minorthreat.org (ec2-54-68-221-247.us-west-2.compute.amazonaws.com [54.68.221.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 441571A889F for ; Wed, 15 Oct 2014 09:02:14 -0700 (PDT) Received: from mb-aye.local ([209.49.54.202]) (authenticated bits=0) by minorthreat.org (8.14.9/8.14.9) with ESMTP id s9FG1l7S007967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 15 Oct 2014 16:01:47 GMT (envelope-from joelja@bogus.com) Message-ID: <543E9A7A.1050106@bogus.com> Date: Wed, 15 Oct 2014 09:02:02 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:33.0) Gecko/20100101 Thunderbird/33.0 MIME-Version: 1.0 To: Kathleen Moriarty References: <543E5B35.5000604@iang.org> <543E96C1.3030301@bogus.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sgQldjvsJ83gcjoGBJaVe0miHD79RHDH8" Archived-At: http://mailarchive.ietf.org/arch/msg/saag/1MlZWhKuEnp6itMDWMvPyDWJoVU Cc: "saag@ietf.org" Subject: Re: [saag] POODLE avant le chein X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 16:02:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --sgQldjvsJ83gcjoGBJaVe0miHD79RHDH8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/15/14 8:48 AM, Kathleen Moriarty wrote: >=20 >=20 > On Wed, Oct 15, 2014 at 11:46 AM, joel jaeggli > wrote: >=20 > On 10/15/14 8:40 AM, Black, David wrote: > >> What if browsers deprecated support for older versions so that i= t becomes > >> easier for server operators to turn off support? > > > > One down (Firefox) ... > > > > https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-an= d-the-end-of-ssl-3-0/ > > > > "SSLv3 will be disabled by default in Firefox 34, which will be r= eleased on Nov 25." >=20 > basically server operators are already making the jump. >=20 > https://blogs.akamai.com/2014/10/ssl-is-dead-long-live-tls.html > https://blog.cloudflare.com/sslv3-support-disabled-by-default-due-t= o-vulnerability/ > http://www.fastly.com/blog/ >=20 >=20 > Cool. It's the enterprise level ones that may fall behind that is my > concern, this is all good news, thanks. Back to reading drafts :-) there's definitely a herd immunity here. if your pre sp3 ie6 no longer works on important sites then you'll get a new browser, which provides everyone else cover to change their servers accordingly. >=20 >=20 >=20 > > FYI, > > --David > > Nit: Le mot en francais est "le chien", pas "le chein" ;-). > > > >> -----Original Message----- > >> From: saag [mailto:saag-bounces@ietf.org > ] On Behalf Of Kathleen Moriarty > >> Sent: Wednesday, October 15, 2014 7:59 AM > >> To: ianG > >> Cc: saag@ietf.org > >> Subject: Re: [saag] POODLE avant le chein > >> > >> > >> > >> Sent from my iPhone > >> > >>> On Oct 15, 2014, at 7:32 AM, ianG > wrote: > >>> > >>>> On 15/10/2014 02:20 am, Watson Ladd wrote: > >>>> Dear all, > >>>> > >>>> Now that we've all disabled SSLv3 on every machine in reach, l= et's > >>>> review when this attack was discovered. Not in 2014, but in > 2001: It's > >>>> in Vaudenay, section 5, applied to randomized padding in SSHv2= , > where > >>>> it was fixed. Credit belongs to Luca Bruno for pointing this o= ut on > >>>> Twitter. > >>> > >>> > >>> (FWIW, when I was designing in the early 2000s, I was well awar= e > of the > >>> need to move the padding into the domain of the MAC, and out of= > >>> CBC-harm's way; we stuck the pad at the front. Which is to say= > it was > >>> not specialist knowledge.) > >>> > >>> > >>>> No one took the time to sit down with a copy of the paper and = a > copy > >>>> of the spec, and compare them until now. I should have, but di= dn't. > >>>> TLS isn't alone in this regard: I spent quite a bit of time > trying to > >>>> understand which way CMS composes encryption and > authentication, and > >>>> gave up in frustration reading the pile of RFCs. (The answer I= > believe > >>>> is that CMS does not use a MAC by default: there is a differen= t > >>>> content type that does support AES-GCM, but I have no idea how= > often > >>>> it is used. People more familiar than I am with S/MIME should = chime > >>>> in.) > >>>> > >>>> What other protocols have random padding in CBC mode after a M= AC? > >>> > >>> > >>> I believe there's a better way to look at this. The better > question is, > >>> do TLS versions have the random padding in CBC mode after a MAC= ? > >>> > >>> At a guess, later ones do not. Assuming that, then TLS is the > solution. > >>> So the real question for engineers is this: why is SSL 3.0 > still in use? > >>> > >> > >> My take on this is that server operators are afraid to break > their clients. > >> What if browsers deprecated support for older versions so that i= t > becomes > >> easier for server operators to turn off support? > >> > >> Could we work together with all the browser vendors to phase out= > SSLv3? Then > >> anything else we should deprecate. Of course this requires > people to upgrade > >> browsers. > >> > >> Thanks, > >> Kathleen > >>> > >>>> Is > >>>> there any way to determine this beyond asking everyone to help= , > >>>> dividing up a list of nearly 8,000 RFCs, and looking at them a= ll? > >>> > >>> :) > >>> > >>>> And > >>>> perhaps most importantly, what process changes will prevent kn= own > >>>> attacks from surprising us in the future? > >>> > >>>> There's also a question about how conservative we need to be w= hen > >>>> doing new cryptographic protocols. But that's a more > challenging one. > >>> > >>> > >>> I believe it's the one that will answer the problem. The > process change > >>> that is needed is how to upgrade protocols on a routine basis, > so that > >>> older designs can fall away without embarrassment. > >>> > >>> (To put this in perspective, an oft-touted feature of the polic= y of > >>> algorithm agility is the ability to switch from one algorithm t= o > >>> another. But even there, there lacks any sense of how we do th= e > switch.) > >>> > >>> Solve the problem that solves most of the attack space: upgrad= e! > >>> > >>> > >>> > >>> iang > >>> > >>> _______________________________________________ > >>> saag mailing list > >>> saag@ietf.org > >>> https://www.ietf.org/mailman/listinfo/saag > >> > >> _______________________________________________ > >> saag mailing list > >> saag@ietf.org > >> https://www.ietf.org/mailman/listinfo/saag > > > > _______________________________________________ > > saag mailing list > > saag@ietf.org > > https://www.ietf.org/mailman/listinfo/saag > > >=20 >=20 >=20 >=20 >=20 > --=20 >=20 > Best regards, > Kathleen --sgQldjvsJ83gcjoGBJaVe0miHD79RHDH8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlQ+mnsACgkQ8AA1q7Z/VrKx+ACfbRZPsfZmcgt0577fYjLyg1ra YaMAnRhgzuTm3y4QOrsq7dfrs5/bwzRu =Q1Uq -----END PGP SIGNATURE----- --sgQldjvsJ83gcjoGBJaVe0miHD79RHDH8-- From nobody Wed Oct 15 09:23:14 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE2B21A88A8 for ; Wed, 15 Oct 2014 09:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HcUrFN7WeqFk for ; Wed, 15 Oct 2014 09:23:08 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 004A21A047A for ; Wed, 15 Oct 2014 09:23:07 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id b6so1338046lbj.31 for ; Wed, 15 Oct 2014 09:23:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FDluf9Iw2t2VlFmTNi8VCkeBwuVI1yhFK38c1M2PzfE=; b=TZp3dL/63RGrN2W3lZQafHi3lA8HQ+kngkTsXWA0bC6f7tNyNukLkhQp0QNlkg5x+/ EHI668wUenXu6lwuMfz7eYbLhxhrIWnoOb5LUndV8qs0HJaiKmk7a9WjkBYIqSk+xqgm YX0Q3OtCOuKY86wRaMhI4EyrCw4QmxkFuUC8bNP22Zwcw/YI3yqFRfCTm3GhCi2OQ7mQ 2oxjnvToKovlwEAPdEVlI5x/YDx4njx2fu3USQ2BkSmhtjXAQsZMCu8owWUGVIlHM9au wpibbUzwlAYaBNtukGFCfEksxHCUMFlZmvo1QzneD+ZXs8eDG630Pm+xCkBMvGEeb+DY fWUg== MIME-Version: 1.0 X-Received: by 10.152.198.204 with SMTP id je12mr13521115lac.61.1413390182638; Wed, 15 Oct 2014 09:23:02 -0700 (PDT) Received: by 10.112.95.36 with HTTP; Wed, 15 Oct 2014 09:23:02 -0700 (PDT) In-Reply-To: <543E992C.7000802@cs.tcd.ie> References: <543E5B35.5000604@iang.org> <543E992C.7000802@cs.tcd.ie> Date: Wed, 15 Oct 2014 12:23:02 -0400 Message-ID: From: Kathleen Moriarty To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a11348e2ac3eb690505788b7b Archived-At: http://mailarchive.ietf.org/arch/msg/saag/vTi9qF37fj59_XfI6KyUpJMDkj0 Cc: "saag@ietf.org" Subject: Re: [saag] getting rid of fairly old stuff (was: Re: POODLE avant le chein) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 16:23:13 -0000 --001a11348e2ac3eb690505788b7b Content-Type: text/plain; charset=UTF-8 On Wed, Oct 15, 2014 at 11:56 AM, Stephen Farrell wrote: > > > On 15/10/14 16:46, Kathleen Moriarty wrote: > > Thanks for the article, it looks like the major browser vendors are > already > > working together, no surprise there, but a big thanks to each of them as > > that's probably the best way to tackle this (from my experience). > > Hopefully so, and good to see the browsers and some large > server sites moving. > > If they can now get rid of SSLv3 within say a couple of months, > (and I hope they can), then we should maybe be asking ourselves > if we (the IETF) can help 'em somehow not let such stuff linger > for so long in future. Not sure how, but say if we'd published > an "SSLv3 considered possibly harmful" RFC about 8 years after > RFC 2246 was published, do we think that might have helped, or > might an equivalent help in future? Looking about randomly, I > see TLS1.1 is 8 years old now:-) > > And just to clarify, my question isn't really about TLS, but > about whether there's an IETF thing to be done here that might > help. (And the answer for now is I'm not sure.) > It sounds like the browser vendors in this case worked together and made a decision to deprecate SSLv3. It may have to be a mix of working with a set of vendors on next steps that can drive the market coupled with social media campaigns. Tweets can be pretty effective when they start getting attention. A few folks mentioned that they were looking to see what other protocols might also be vulnerable, if some are found, that might be a good place to start. Then working with a set of IETF participating vendors on next steps and announcements. Vulnerability disclosure practices are well defined and following them may help us. For other known issues where there has not been movement, it might be good to work through a list and see what we can do/influence with each in priority order... ok, all should be pretty obvious, but requires work ;-) Thanks. > S. > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > -- Best regards, Kathleen --001a11348e2ac3eb690505788b7b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Oct 15, 2014 at 11:56 AM, Stephen Farrell <= ;stephen.far= rell@cs.tcd.ie> wrote:


On 15/10/14 16:46, Kathleen Moriarty wrote:
> Thanks for the article, it looks like the major browser vendors are al= ready
> working together, no surprise there, but a big thanks to each of them = as
> that's probably the best way to tackle this (from my experience).<= br>
Hopefully so, and good to see the browsers and some large
server sites moving.

If they can now get rid of SSLv3 within say a couple of months,
(and I hope they can), then we should maybe be asking ourselves
if we (the IETF) can help 'em somehow not let such stuff linger
for so long in future. Not sure how, but say if we'd published
an "SSLv3 considered possibly harmful" RFC about 8 years after RFC 2246 was published, do we think that might have helped, or
might an equivalent help in future? Looking about randomly, I
see TLS1.1 is 8 years old now:-)

And just to clarify, my question isn't really about TLS, but
about whether there's an IETF thing to be done here that might
help. (And the answer for now is I'm not sure.)
It sounds like the browser vendors in this case worked togethe= r and made a decision to deprecate SSLv3.=C2=A0 It may have to be a mix of = working with a set of vendors on next steps that can drive the market coupl= ed with social media campaigns.=C2=A0 Tweets can be pretty effective when t= hey start getting attention.

A few folks mentioned= that they were looking to see what other protocols might also be vulnerabl= e, if some are found, that might be a good place to start.=C2=A0 Then worki= ng with a set of IETF participating vendors on next steps and announcements= .=C2=A0 Vulnerability disclosure practices are well defined and following t= hem may help us.

For other known issues where ther= e has not been movement, it might be good to work through a list and see wh= at we can do/influence with each in priority order... ok, all should be pre= tty obvious, but requires work ;-)

Thanks.


S.

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



--

Best regards,
Kathleen
--001a11348e2ac3eb690505788b7b-- From nobody Wed Oct 15 09:27:57 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D70B1A8943 for ; Wed, 15 Oct 2014 09:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8KZV5bK_KD5x for ; Wed, 15 Oct 2014 09:27:51 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0721.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:721]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F52E1A892C for ; Wed, 15 Oct 2014 09:27:51 -0700 (PDT) Received: from BN1AFFO11FD041.protection.gbl (10.58.52.34) by BN1AFFO11HUB020.protection.gbl (10.58.52.130) with Microsoft SMTP Server (TLS) id 15.0.1039.16; Wed, 15 Oct 2014 16:27:28 +0000 Received: from mx01.five9.com (198.105.204.2) by BN1AFFO11FD041.mail.protection.outlook.com (10.58.52.252) with Microsoft SMTP Server (TLS) id 15.0.1039.16 via Frontend Transport; Wed, 15 Oct 2014 16:27:27 +0000 Received: from MB01.five9.com (10.7.8.141) by mx01.five9.com (10.7.15.111) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 15 Oct 2014 09:26:30 -0700 Received: from MB02.five9.com ([fe80::ede6:8312:5207:4046]) by mb01.five9.com ([fe80::ddc6:159a:f53:8ee7%15]) with mapi id 14.03.0158.001; Wed, 15 Oct 2014 09:27:26 -0700 From: Ronald del Rosario To: Kathleen Moriarty , joel jaeggli Thread-Topic: [saag] POODLE avant le chein Thread-Index: AQHP6BY8dUIjZAmkrkKIHvNFQop1XJwxfHaAgAAHfACAAD39AIAAAYSAgAAAjgD//5WegA== Date: Wed, 15 Oct 2014 16:27:26 +0000 Message-ID: References: <543E5B35.5000604@iang.org> <543E96C1.3030301@bogus.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [10.7.8.130] Content-Type: multipart/related; boundary="_004_D063EDF015FE0rrosariofive9com_"; type="multipart/alternative" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:198.105.204.2; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(438002)(24454002)(199003)(13464003)(164054003)(189002)(377454003)(479174003)(51704005)(69234005)(71186001)(107046002)(84326002)(83506001)(6806004)(19580395003)(31966008)(4396001)(15975445006)(16236675004)(44976005)(17760045003)(20776003)(64706001)(30436002)(21056001)(19580405001)(54356999)(18206015026)(15202345003)(76176999)(99936001)(36756003)(15974865002)(85852003)(50986999)(92566001)(92726001)(86362001)(575784001)(2656002)(87936001)(120916001)(77096002)(46102003)(106116001)(76482002)(95666004)(80022003)(67866002)(53416004)(19627595001)(512944002)(106466001)(93886004)(19617315012)(85306004)(99396003)(85436002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1AFFO11HUB020; H:mx01.five9.com; FPR:; MLV:sfv; PTR:mx01.five9.com; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1AFFO11HUB020; X-Exchange-Antispam-Report-Test: UriScan:; X-Forefront-PRVS: 0365C0E14B Received-SPF: Pass (protection.outlook.com: domain of five9.com designates 198.105.204.2 as permitted sender) receiver=protection.outlook.com; client-ip=198.105.204.2; helo=mx01.five9.com; Authentication-Results: spf=pass (sender IP is 198.105.204.2) smtp.mailfrom=rrosario@five9.com; X-OriginatorOrg: five9.com Archived-At: http://mailarchive.ietf.org/arch/msg/saag/rL3bvjWsDHZ_lf_6AEJXi0UxkpQ Cc: "saag@ietf.org" Subject: Re: [saag] POODLE avant le chein X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 16:27:55 -0000 --_004_D063EDF015FE0rrosariofive9com_ Content-Type: multipart/alternative; boundary="_000_D063EDF015FE0rrosariofive9com_" --_000_D063EDF015FE0rrosariofive9com_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable "Cool. It's the enterprise level ones that may fall behind that is my conc= ern, this is all good news, thanks. Back to reading drafts :-)=94 +1 Once all major browsers start dropping support for SSLv3 in favor of TLS, C= loud Service Providers like us relying on browsers will now have the author= ity to remind our customer base that we are dropping support for SSLv3. Ron F. del Rosario Information Security Officer [cid:D595BF2F-080A-49DB-A18E-91BC3ED02AF1] Five9, Inc. Cloud Contact Center Software 4000 Executive Pkwy, Ste 400 San Ramon, CA 94583 www.Five9.com From: Kathleen Moriarty > Date: Wednesday, October 15, 2014 at 8:48 AM To: joel jaeggli > Cc: "saag@ietf.org" > Subject: Re: [saag] POODLE avant le chein On Wed, Oct 15, 2014 at 11:46 AM, joel jaeggli > wrote: On 10/15/14 8:40 AM, Black, David wrote: >> What if browsers deprecated support for older versions so that it become= s >> easier for server operators to turn off support? > > One down (Firefox) ... > > https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-en= d-of-ssl-3-0/ > > "SSLv3 will be disabled by default in Firefox 34, which will be released = on Nov 25." basically server operators are already making the jump. https://blogs.akamai.com/2014/10/ssl-is-dead-long-live-tls.html https://blog.cloudflare.com/sslv3-support-disabled-by-default-due-to-vulner= ability/ http://www.fastly.com/blog/ Cool. It's the enterprise level ones that may fall behind that is my conce= rn, this is all good news, thanks. Back to reading drafts :-) > FYI, > --David > Nit: Le mot en francais est "le chien", pas "le chein" ;-). > >> -----Original Message----- >> From: saag [mailto:saag-bounces@ietf.org] = On Behalf Of Kathleen Moriarty >> Sent: Wednesday, October 15, 2014 7:59 AM >> To: ianG >> Cc: saag@ietf.org >> Subject: Re: [saag] POODLE avant le chein >> >> >> >> Sent from my iPhone >> >>> On Oct 15, 2014, at 7:32 AM, ianG >= wrote: >>> >>>> On 15/10/2014 02:20 am, Watson Ladd wrote: >>>> Dear all, >>>> >>>> Now that we've all disabled SSLv3 on every machine in reach, let's >>>> review when this attack was discovered. Not in 2014, but in 2001: It's >>>> in Vaudenay, section 5, applied to randomized padding in SSHv2, where >>>> it was fixed. Credit belongs to Luca Bruno for pointing this out on >>>> Twitter. >>> >>> >>> (FWIW, when I was designing in the early 2000s, I was well aware of the >>> need to move the padding into the domain of the MAC, and out of >>> CBC-harm's way; we stuck the pad at the front. Which is to say it was >>> not specialist knowledge.) >>> >>> >>>> No one took the time to sit down with a copy of the paper and a copy >>>> of the spec, and compare them until now. I should have, but didn't. >>>> TLS isn't alone in this regard: I spent quite a bit of time trying to >>>> understand which way CMS composes encryption and authentication, and >>>> gave up in frustration reading the pile of RFCs. (The answer I believe >>>> is that CMS does not use a MAC by default: there is a different >>>> content type that does support AES-GCM, but I have no idea how often >>>> it is used. People more familiar than I am with S/MIME should chime >>>> in.) >>>> >>>> What other protocols have random padding in CBC mode after a MAC? >>> >>> >>> I believe there's a better way to look at this. The better question is= , >>> do TLS versions have the random padding in CBC mode after a MAC? >>> >>> At a guess, later ones do not. Assuming that, then TLS is the solution= . >>> So the real question for engineers is this: why is SSL 3.0 still in us= e? >>> >> >> My take on this is that server operators are afraid to break their clien= ts. >> What if browsers deprecated support for older versions so that it become= s >> easier for server operators to turn off support? >> >> Could we work together with all the browser vendors to phase out SSLv3? = Then >> anything else we should deprecate. Of course this requires people to up= grade >> browsers. >> >> Thanks, >> Kathleen >>> >>>> Is >>>> there any way to determine this beyond asking everyone to help, >>>> dividing up a list of nearly 8,000 RFCs, and looking at them all? >>> >>> :) >>> >>>> And >>>> perhaps most importantly, what process changes will prevent known >>>> attacks from surprising us in the future? >>> >>>> There's also a question about how conservative we need to be when >>>> doing new cryptographic protocols. But that's a more challenging one. >>> >>> >>> I believe it's the one that will answer the problem. The process chang= e >>> that is needed is how to upgrade protocols on a routine basis, so that >>> older designs can fall away without embarrassment. >>> >>> (To put this in perspective, an oft-touted feature of the policy of >>> algorithm agility is the ability to switch from one algorithm to >>> another. But even there, there lacks any sense of how we do the switch= .) >>> >>> Solve the problem that solves most of the attack space: upgrade! >>> >>> >>> >>> iang >>> >>> _______________________________________________ >>> saag mailing list >>> saag@ietf.org >>> https://www.ietf.org/mailman/listinfo/saag >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > -- Best regards, Kathleen ________________________________ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain conf= idential information of Five9 and/or its affiliated entities. Access by the= intended recipient only is authorized. Any liability arising from any part= y acting, or refraining from acting, on any information contained in this e= -mail is hereby excluded. If you are not the intended recipient, please not= ify the sender immediately, destroy the original transmission and its attac= hments and do not disclose the contents to any other person, use it for any= purpose, or store or copy the information in any medium. Copyright in this= e-mail and any attachments belongs to Five9 and/or its affiliated entities= . --_000_D063EDF015FE0rrosariofive9com_ Content-Type: text/html; charset="Windows-1252" Content-ID: <11A0314F2059FF48AEF37F9C2C39DF7B@five9.com> Content-Transfer-Encoding: quoted-printable
"Cool.  It's the enterprise level ones that may fall behind = that is my concern, this is all good news, thanks. Back to reading drafts := -)=94

+1

Once all major browsers start dropping support for SSLv3 in favor of T= LS, Cloud Service Providers like us relying on browsers will now have the a= uthority to remind our customer base  that we are dropping support for= SSLv3.

= Ron F. de= l Rosario

I= nformation Security Officer




Five9, Inc. 
Cloud Contact Center Software 
4000 Executive Pkwy, Ste 400 San Ramon, CA 94583 


From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.c= om>
Date: Wednesday, October 15, 2014 a= t 8:48 AM
To: joel jaeggli <joelja@bogus.com>
Cc: "saag@ietf.org" <saag@i= etf.org>
Subject: Re: [saag] POODLE avant le= chein



On Wed, Oct 15, 2014 at 11:46 AM, joel jaeggli <= span dir=3D"ltr"> <joelja@bogus.com<= /a>> wrote:
On 10/15/14 8:40 AM, Black, David wrote:
>> What if browsers deprecated support for older versions so that it = becomes
>> easier for server operators to turn off support?
>
> One down (Firefox) ...
>
> https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-end-= of-ssl-3-0/
>
> "SSLv3 will be disabled by default in Firefox 34, which will be r= eleased on Nov 25."

basically server operators are already making the jump.

https://blogs.akamai.com/2014/10/ssl-is-dead-long-live-t= ls.html
https://blog.cloudflare.com/sslv3-su= pport-disabled-by-default-due-to-vulnerability/
http://www.fastly= .com/blog/

Cool.  It's the enterprise level ones that may fall behind that i= s my concern, this is all good news, thanks. Back to reading drafts :-)
 


> FYI,
> --David
> Nit: Le mot en francais est "le chien", pas "le chein&q= uot; ;-).
>
>> -----Original Message-----
>> From: saag [mailto:saag-b= ounces@ietf.org] On Behalf Of Kathleen Moriarty
>> Sent: Wednesday, October 15, 2014 7:59 AM
>> To: ianG
>> Cc: saag@ietf.org
>> Subject: Re: [saag] POODLE avant le chein
>>
>>
>>
>> Sent from my iPhone
>>
>>> On Oct 15, 2014, at 7:32 AM, ianG <iang@iang.org> wrote:
>>>
>>>> On 15/10/2014 02:20 am, Watson Ladd wrote:
>>>> Dear all,
>>>>
>>>> Now that we've all disabled SSLv3 on every machine in reac= h, let's
>>>> review when this attack was discovered. Not in 2014, but i= n 2001: It's
>>>> in Vaudenay, section 5, applied to randomized padding in S= SHv2, where
>>>> it was fixed. Credit belongs to Luca Bruno for pointing th= is out on
>>>> Twitter.
>>>
>>>
>>> (FWIW, when I was designing in the early 2000s, I was well awa= re of the
>>> need to move the padding into the domain of the MAC, and out o= f
>>> CBC-harm's way; we stuck the pad at the front.  Which is = to say it was
>>> not specialist knowledge.)
>>>
>>>
>>>> No one took the time to sit down with a copy of the paper = and a copy
>>>> of the spec, and compare them until now. I should have, bu= t didn't.
>>>> TLS isn't alone in this regard: I spent quite a bit of tim= e trying to
>>>> understand which way CMS composes encryption and authentic= ation, and
>>>> gave up in frustration reading the pile of RFCs. (The answ= er I believe
>>>> is that CMS does not use a MAC by default: there is a diff= erent
>>>> content type that does support AES-GCM, but I have no idea= how often
>>>> it is used. People more familiar than I am with S/MIME sho= uld chime
>>>> in.)
>>>>
>>>> What other protocols have random padding in CBC mode after= a MAC?
>>>
>>>
>>> I believe there's a better way to look at this.  The bett= er question is,
>>> do TLS versions have the random padding in CBC mode after a MA= C?
>>>
>>> At a guess, later ones do not.  Assuming that, then TLS i= s the solution.
>>> So the real question for engineers is this:  why is SSL 3= .0 still in use?
>>>
>>
>> My take on this is that server operators are afraid to break their= clients.
>> What if browsers deprecated support for older versions so that it = becomes
>> easier for server operators to turn off support?
>>
>> Could we work together with all the browser vendors to phase out S= SLv3?  Then
>> anything else we should deprecate.  Of course this requires p= eople to upgrade
>> browsers.
>>
>> Thanks,
>> Kathleen
>>>
>>>> Is
>>>> there any way to determine this beyond asking everyone to = help,
>>>> dividing up a list of nearly 8,000 RFCs, and looking at th= em all?
>>>
>>> :)
>>>
>>>> And
>>>> perhaps most importantly, what process changes will preven= t known
>>>> attacks from surprising us in the future?
>>>
>>>> There's also a question about how conservative we need to = be when
>>>> doing new cryptographic protocols. But that's a more chall= enging one.
>>>
>>>
>>> I believe it's the one that will answer the problem.  The= process change
>>> that is needed is how to upgrade protocols on a routine basis,= so that
>>> older designs can fall away without embarrassment.
>>>
>>> (To put this in perspective, an oft-touted feature of the poli= cy of
>>> algorithm agility is the ability to switch from one algorithm = to
>>> another.  But even there, there lacks any sense of how we= do the switch.)
>>>
>>> Solve the problem that solves most of the attack space:  = upgrade!
>>>
>>>
>>>
>>> iang
>>>
>>> _______________________________________________
>>> saag mailing list
>>> saag@ietf.org
>>> https://www.ietf.org/mailman/listinfo/saag
>>
>> _______________________________________________
>> saag mailing list
>> saag@ietf.org
>> https://www.ietf.org/mailman/listinfo/saag
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
>





--

Best regards,
Kathleen


CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain conf= idential information of Five9 and/or its affiliated entities. Access by the= intended recipient only is authorized. Any liability arising from any part= y acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are= not the intended recipient, please notify the sender immediately, destroy = the original transmission and its attachments and do not disclose the conte= nts to any other person, use it for any purpose, or store or copy the information in any medium. Copyright= in this e-mail and any attachments belongs to Five9 and/or its affiliated = entities.
--_000_D063EDF015FE0rrosariofive9com_-- --_004_D063EDF015FE0rrosariofive9com_ Content-Type: image/png; name="063218CA-78F5-4C87-B33F-1AF1081079A5.png" Content-Description: 063218CA-78F5-4C87-B33F-1AF1081079A5.png Content-Disposition: inline; filename="063218CA-78F5-4C87-B33F-1AF1081079A5.png"; size=4841; creation-date="Wed, 15 Oct 2014 16:27:26 GMT"; modification-date="Wed, 15 Oct 2014 16:27:26 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEsAAAAoCAYAAAC2LgceAAAKQWlDQ1BJQ0MgUHJvZmlsZQAASA2d lndUU9kWh8+9N73QEiIgJfQaegkg0jtIFQRRiUmAUAKGhCZ2RAVGFBEpVmRUwAFHhyJjRRQLg4Ji 1wnyEFDGwVFEReXdjGsJ7601896a/cdZ39nnt9fZZ+9917oAUPyCBMJ0WAGANKFYFO7rwVwSE8vE 9wIYEAEOWAHA4WZmBEf4RALU/L09mZmoSMaz9u4ugGS72yy/UCZz1v9/kSI3QyQGAApF1TY8fiYX 5QKUU7PFGTL/BMr0lSkyhjEyFqEJoqwi48SvbPan5iu7yZiXJuShGlnOGbw0noy7UN6aJeGjjASh XJgl4GejfAdlvVRJmgDl9yjT0/icTAAwFJlfzOcmoWyJMkUUGe6J8gIACJTEObxyDov5OWieAHim Z+SKBIlJYqYR15hp5ejIZvrxs1P5YjErlMNN4Yh4TM/0tAyOMBeAr2+WRQElWW2ZaJHtrRzt7VnW 5mj5v9nfHn5T/T3IevtV8Sbsz55BjJ5Z32zsrC+9FgD2JFqbHbO+lVUAtG0GQOXhrE/vIADyBQC0 3pzzHoZsXpLE4gwnC4vs7GxzAZ9rLivoN/ufgm/Kv4Y595nL7vtWO6YXP4EjSRUzZUXlpqemS0TM zAwOl89k/fcQ/+PAOWnNycMsnJ/AF/GF6FVR6JQJhIlou4U8gViQLmQKhH/V4X8YNicHGX6daxRo dV8AfYU5ULhJB8hvPQBDIwMkbj96An3rWxAxCsi+vGitka9zjzJ6/uf6Hwtcim7hTEEiU+b2DI9k ciWiLBmj34RswQISkAd0oAo0gS4wAixgDRyAM3AD3iAAhIBIEAOWAy5IAmlABLJBPtgACkEx2AF2 g2pwANSBetAEToI2cAZcBFfADXALDIBHQAqGwUswAd6BaQiC8BAVokGqkBakD5lC1hAbWgh5Q0FQ OBQDxUOJkBCSQPnQJqgYKoOqoUNQPfQjdBq6CF2D+qAH0CA0Bv0BfYQRmALTYQ3YALaA2bA7HAhH wsvgRHgVnAcXwNvhSrgWPg63whfhG/AALIVfwpMIQMgIA9FGWAgb8URCkFgkAREha5EipAKpRZqQ DqQbuY1IkXHkAwaHoWGYGBbGGeOHWYzhYlZh1mJKMNWYY5hWTBfmNmYQM4H5gqVi1bGmWCesP3YJ NhGbjS3EVmCPYFuwl7ED2GHsOxwOx8AZ4hxwfrgYXDJuNa4Etw/XjLuA68MN4SbxeLwq3hTvgg/B c/BifCG+Cn8cfx7fjx/GvyeQCVoEa4IPIZYgJGwkVBAaCOcI/YQRwjRRgahPdCKGEHnEXGIpsY7Y QbxJHCZOkxRJhiQXUiQpmbSBVElqIl0mPSa9IZPJOmRHchhZQF5PriSfIF8lD5I/UJQoJhRPShxF QtlOOUq5QHlAeUOlUg2obtRYqpi6nVpPvUR9Sn0vR5Mzl/OX48mtk6uRa5Xrl3slT5TXl3eXXy6f J18hf0r+pvy4AlHBQMFTgaOwVqFG4bTCPYVJRZqilWKIYppiiWKD4jXFUSW8koGStxJPqUDpsNIl pSEaQtOledK4tE20Otpl2jAdRzek+9OT6cX0H+i99AllJWVb5SjlHOUa5bPKUgbCMGD4M1IZpYyT jLuMj/M05rnP48/bNq9pXv+8KZX5Km4qfJUilWaVAZWPqkxVb9UU1Z2qbapP1DBqJmphatlq+9Uu q43Pp893ns+dXzT/5PyH6rC6iXq4+mr1w+o96pMamhq+GhkaVRqXNMY1GZpumsma5ZrnNMe0aFoL tQRa5VrntV4wlZnuzFRmJbOLOaGtru2nLdE+pN2rPa1jqLNYZ6NOs84TXZIuWzdBt1y3U3dCT0sv WC9fr1HvoT5Rn62fpL9Hv1t/ysDQINpgi0GbwaihiqG/YZ5ho+FjI6qRq9Eqo1qjO8Y4Y7ZxivE+ 41smsImdSZJJjclNU9jU3lRgus+0zwxr5mgmNKs1u8eisNxZWaxG1qA5wzzIfKN5m/krCz2LWIud Ft0WXyztLFMt6ywfWSlZBVhttOqw+sPaxJprXWN9x4Zq42Ozzqbd5rWtqS3fdr/tfTuaXbDdFrtO u8/2DvYi+yb7MQc9h3iHvQ732HR2KLuEfdUR6+jhuM7xjOMHJ3snsdNJp9+dWc4pzg3OowsMF/AX 1C0YctFx4bgccpEuZC6MX3hwodRV25XjWuv6zE3Xjed2xG3E3dg92f24+ysPSw+RR4vHlKeT5xrP C16Il69XkVevt5L3Yu9q76c+Oj6JPo0+E752vqt9L/hh/QL9dvrd89fw5/rX+08EOASsCegKpARG BFYHPgsyCRIFdQTDwQHBu4IfL9JfJFzUFgJC/EN2hTwJNQxdFfpzGC4sNKwm7Hm4VXh+eHcELWJF REPEu0iPyNLIR4uNFksWd0bJR8VF1UdNRXtFl0VLl1gsWbPkRoxajCCmPRYfGxV7JHZyqffS3UuH 4+ziCuPuLjNclrPs2nK15anLz66QX8FZcSoeGx8d3xD/iRPCqeVMrvRfuXflBNeTu4f7kufGK+eN 8V34ZfyRBJeEsoTRRJfEXYljSa5JFUnjAk9BteB1sl/ygeSplJCUoykzqdGpzWmEtPi000IlYYqw K10zPSe9L8M0ozBDuspp1e5VE6JA0ZFMKHNZZruYjv5M9UiMJJslg1kLs2qy3mdHZZ/KUcwR5vTk muRuyx3J88n7fjVmNXd1Z752/ob8wTXuaw6thdauXNu5Tnddwbrh9b7rj20gbUjZ8MtGy41lG99u it7UUaBRsL5gaLPv5sZCuUJR4b0tzlsObMVsFWzt3WazrWrblyJe0fViy+KK4k8l3JLr31l9V/nd zPaE7b2l9qX7d+B2CHfc3em681iZYlle2dCu4F2t5czyovK3u1fsvlZhW3FgD2mPZI+0MqiyvUqv akfVp+qk6oEaj5rmvep7t+2d2sfb17/fbX/TAY0DxQc+HhQcvH/I91BrrUFtxWHc4azDz+ui6rq/ Z39ff0TtSPGRz0eFR6XHwo911TvU1zeoN5Q2wo2SxrHjccdv/eD1Q3sTq+lQM6O5+AQ4ITnx4sf4 H++eDDzZeYp9qukn/Z/2ttBailqh1tzWibakNml7THvf6YDTnR3OHS0/m/989Iz2mZqzymdLz5HO FZybOZ93fvJCxoXxi4kXhzpXdD66tOTSna6wrt7LgZevXvG5cqnbvfv8VZerZ645XTt9nX297Yb9 jdYeu56WX+x+aem172296XCz/ZbjrY6+BX3n+l37L972un3ljv+dGwOLBvruLr57/17cPel93v3R B6kPXj/Mejj9aP1j7OOiJwpPKp6qP6391fjXZqm99Oyg12DPs4hnj4a4Qy//lfmvT8MFz6nPK0a0 RupHrUfPjPmM3Xqx9MXwy4yX0+OFvyn+tveV0auffnf7vWdiycTwa9HrmT9K3qi+OfrW9m3nZOjk 03dp76anit6rvj/2gf2h+2P0x5Hp7E/4T5WfjT93fAn88ngmbWbm3/eE8/syOll+AAAIY0lEQVRo BdVazXITRxCenhWB3JwniLhhKgf5mAIT+QkwDwCWnsDC5G77ntjyE2gND4D8BF4wVI44VSnMDfEE 0Q0StNv5enZnNftnW2KFyVStpqenZ6ant7une1bEzOpbLLd/P1lniu4zU4tItfI8guuxUhxopV+w DodnvfYoT1N3m74lYa30g6VPke5BEJuk1NJsm2Vfad5dpNC+GWGJJkXEg9mFlBUpBN3/Xke7b3pt aF69Rdc73XyzLe+9GDDx8wsFRRTE5le9DubofQz18U/9oGC61aMu13PlmiWCUoo65eyyT6yPrnth kNcUEcYk0hsQzjrGNvPjRagNHa391Wuf5vvmbV+psKoFxf4NzY/zAqra5PLeSYcV7+c1UwRGOlqp y49dmbBu753AkfO+KwCzuSh6cPZrO3Dxl4HN4cDec8Xcdulx2J++e3JvxcXNC1+JsJb7QVNF+r3L dF1mU6Gtu2db93bc9eaBr8TBc0QZjRLG6/IvZ1u/dEWbXGHgRWyK5rm4eeCvqlnC8Gc44zDSb3LM 1vLm7ZyiuYw1XB8GgfUpio4sjddQ41md/8KEFQeY3jqr6D5Ou7bLuGU4qUcwkZs53Bc3l/de7mCS 7Ysmgt8cktJHN5AFXHSg1G6GIiRh9KPxSRJk0vo5glLoP7hoQ/P039BR/zLjhD+kTQPhNxFw5bBa NUtiH5jYc6zWrFwx14FN/XDRG80NuXTz1t4LBLoijMsX8XcNL+qWmWhtmiWxDoLEY7DVPIe1Efrk MUUYW5SgZAEI6s94JWlQ4D7wYeO0zwEkaZd9yH4ctAEbecQ87eXfgrbSWvK6TBGGCD5BRXyYj51i LfRamQF1N3TkU+idvn2yOiybOuaBNjnnKmK3wQPkq2N37Bebofgosfd4gSlLxnEiCq8rep7OXD8U n56EDCBrsvKy3ZDmizXrY0SiUUvZLbD/DvFOFvfttpIX+uDW3ktJmXqWU9nXJNQDtE0GQOruox3b OUvNJ4c7ifkdZ8exL4FhFnd1LTeEIdLpS8U93inyxoO85pdnANQ921r1Sd15CG2buYz41dObJROP cLqtLNJpz8Kp9aUY06wah833323de+z2L++fHOdyTBMLznsaGocpjtFdBEfOQi7dsmtcrmVOM33h 6YwTU/Xilz6d16MwIzz0NOVycj5hER/JWxObtkvgDY1FVW37KmvjsHM3GufzQx03IJUYSw4od4x8 Dyg6eKJdl6gUnngjJSMjldLiJBmV0l4FMqJt90UKC+Dv8XUd+uIiyswTL1uS7b51IZICIbJPLUc+ nBSEJY77Mvujte6SmkyClDZqjNXWqqLVh+0UJ8CkMeI/BqMMLmnQz92makyabh+fPAvctpmPaQO4 Jp4WNjDC1seAj9Q1z+fjgcCZksRNKU4E9XZrtW8REvNB+9bcZFuE+0/otUEzFDrJFfHxZCCwFAlW 5zNDGT2ZtBQTHGHyUBhfuzBtpzjp88JtIS8t0mfHm1rFc4BYBEl3H8XzK9UBqo1nCT2tBN5Xn8P3 oOmhnRYJNF2tYrgHV1CWUE5BEzBbBGp8B5C5TbEaZttSzy8sdxYXZnXoNgF3jBbmkAluPYPmOKmm O90WhPwGfe1Mf7GxBNQ+BJZqQDiZ+lEhJ6LT4jCLoQ8Wukxdu7D49VMfC48zi/8bZoUinTFONmvL WH3nDY0QKTwG0u1LaPgUwChpuFUnr2G2E/FUy8LFmn8s4qoxBZ9lVL+aHrqqDhOBnEflo7OXEhBv AhacW+67DcDG/yRakhWUHDoN3bf+KfZjYrLGJO002xC037q/cfopsihQQOhy3583RTFXGFZnSinQ 9JCSYDZveAVhYURbhlUWTS8q+2xH6B3AjKbCwqbEB1lHH2uP+YRlRyiFMcbhe8Y/TfGsuvzq0J8i 8L5wCGCONfgsMdVm0ocDJ+rB1+wgqAzcoJIRRiA0WFJIrG9A6z9FcimpJbXJFh0GFmGcPcHjJUVu SGo3Q5nbCIXjU8UuphpRJ4WLZhmYMV7BXIMqLTZaxtPQxczNciuLEoa7ps7+bMtHEpxwf4PD0nzW TX0krsoMJxWUaVaGZu6Gx4cqciJ85g3MtZPMl2VkeijkfUh8IlYxQQxTcfUjNksJDZAU99HjaHfV JBAdtI3wPwlLkZhgx7allvv7grCQ87mru/Qzwfzy2RD+Z4RBzWRg05xy38FBU8YEx472tBJaW8lY eSpKNauS78FXfYgUFwLU/GQaadpb5184n4pfn0byAhZihikzRIcpLACFm/AznSzOuYPn3CmaIZy9 IU4dfxK5KUEp9McXv1OYBTeorvM30b2ijktHLOPxuc5F1g5PtJ8LStfBNLTH0QihsUXjGpinKQbQ 0MKcwC1tWc08zqOT4LIv+OQ2ISUx5kdhN0UIoL0meNy1OAg6vS1dqLDEadOdR0PH7JYgKAgrKTgE 7AlpMJEGbSbily/XQ349OLVD3LqQWoWNkdvvwhI+QAhtF5c3P+k77zJgsWYoq2s+kKq0yCHglEQo IwclpntcEAoITDyWSZWQWmmFl1EscgshvivTkzO/TF9FY6GaJWuamCjr6C0rIzkEbCOtibsmX0wR EACEQncfQrsoAFoE0sbTxOOWfpUGKvYQKsjJGZdS87Od59SL16x48aJ2Vfgic+uAQLTIM7WA6+Hp 4GnicQrSoGveroNIQWN+uX/WiPm5MVVKfAHwdYSFq5QCH0hfCrgEYUKJWGDjKhoH76trjTWbCjl4 VZf52TkbOG1K34glqKxxT4WofDo2knum8iIbgaPvKk1NQwHass25o0VgSGmGksLghNxAXzw2Jhoj kgzEH+bvv9w58M2wpSjnMyn0XZpZ4C/+bjjLYv932v8A3PTEbUKtr9sAAAAASUVORK5CYII= --_004_D063EDF015FE0rrosariofive9com_-- From nobody Wed Oct 15 09:33:19 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7A161A898A for ; Wed, 15 Oct 2014 09:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84ynfXOwKOP9 for ; Wed, 15 Oct 2014 09:33:15 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B4E71A8987 for ; Wed, 15 Oct 2014 09:33:15 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id hi2so13471215wib.9 for ; Wed, 15 Oct 2014 09:33:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CmGMUOX+8zP/R25lxm83TbtG79FbD9ToGDuuYWDIDaY=; b=EKqwVwB9zFr6RL71ioCzYBXOfZMQqeFIf7f8mDp3UV48bUDM8mrfUuOn7JIIPbfq7Y NeNiu4wHVGL5FiVVBBFtGGI40XeqXn6g/KAbMbqmtvwIJpOjPr6cTInOAD6+dctGXbbc wmyFyVnH9750GF1FJx4Y5mdspc5fX+urwpnLkeadBotxnL8Q0z8/MKJNIBecsFPJVqhc 9gmP0VkUHyylWXfwbsbDD7y/amxd0ujicfm2Zzao2cMm3NQwOVHlLWtmNOV2IgM+mlb+ i40MLs0Tf1YBnTks83aAVpt16ltJ0hWdj40cm6lzeT17aW/N/MtMAQoik81jaHVlzLm2 IxrQ== X-Received: by 10.180.72.241 with SMTP id g17mr13650322wiv.31.1413390794027; Wed, 15 Oct 2014 09:33:14 -0700 (PDT) Received: from [192.168.1.104] (IGLD-84-228-54-205.inter.net.il. [84.228.54.205]) by mx.google.com with ESMTPSA id cu9sm24459484wjc.3.2014.10.15.09.33.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 Oct 2014 09:33:13 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Yoav Nir In-Reply-To: <543E9A7A.1050106@bogus.com> Date: Wed, 15 Oct 2014 19:33:11 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <543E5B35.5000604@iang.org> <543E96C1.3030301@bogus.com> <543E9A7A.1050106@bogus.com> To: joel jaeggli X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/sYnoQg41dA0VefMUd7MrGlUMHuU Cc: "saag@ietf.org" Subject: Re: [saag] POODLE avant le chein X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 16:33:17 -0000 On Oct 15, 2014, at 7:02 PM, joel jaeggli wrote: >> Cool. It's the enterprise level ones that may fall behind that is my >> concern, this is all good news, thanks. Back to reading drafts :-) >=20 > there's definitely a herd immunity here. if your pre sp3 ie6 no longer > works on important sites then you'll get a new browser, which provides > everyone else cover to change their servers accordingly. IDK. Pre-SP3 IE6 is a checkbox away from working. They had TLS disabled = by default for some reason, but it can even be turned on by an = administrator through Microsoft=92s tools. It would be interesting to see in the next two iterations of the survey = how many sites will still have SSLv3 turned on. My guess is that the = percentage will be depressingly high, considering that 11.7% still = support SSLv2. = https://securitypitfalls.wordpress.com/2014/09/29/scan-results-for-septemb= er-2014/ I think there are two flavors to consider in enterprise servers. There=92s= the intranet servers (erp.mycompany.com, exchange.mycompany.com, = order-lunch.mycompany.com). It=92s hard to justify upgrading them, = because (a) they work, and (b) they=92re behind the firewall, and (c) = who knows if the =93order lunch=94 application will keep working if we = upgrade IIS, which we=92ll have to if we upgrade the Windows 2000 = server. Of course being behind the firewall doesn=92t help if your = favorite browser (including Firefox until late November) is going to = accept Javascript from outside sources that will run queries against = your lunch ordering system. Firewalls try to deal with this, but that = battle hasn=92t been won yet. Internet-facing servers are a different matter. On the one hand, they = have to deal with anything that=92s out there, but on the other hand, a = lot of them are hosted these days, so the hosting companies (or CDNs) = can make a lot of difference. A decision by the likes of Akamai or = Cloudflare can do a lot for the statistics. While the browser vendors are pretty much working together, there are a = lot of programmatic clients out there. Think of the app on your phone = that shows a pretty picture of a rainy or sunny day on your phone based = on data pulled from weather.com, or some client using SOAP or JSON or = any other web services technology. These can also live for a long time = unchanged since they =93just work=94.=20 Yoav= From nobody Wed Oct 15 09:42:41 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC441A8867 for ; Wed, 15 Oct 2014 09:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zk_T0HIcZE_G for ; Wed, 15 Oct 2014 09:42:38 -0700 (PDT) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2791F1A1AB2 for ; Wed, 15 Oct 2014 09:42:38 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id k15so1080878qaq.24 for ; Wed, 15 Oct 2014 09:42:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZA7TGo+/97am4Cx2+LCglyX9W5mIPjVk+XbK4mo6BH0=; b=ANR+eVvbZ2Rj9dzCuiBW0TzRjq3k9BRPmlKqknHZelM2Lm8jAlEUygSk5Ch5Iv3ZkL AmrdQF0QkfTmw5KzitFlZro0eKOO+R+MZfm0ld4UzPt4q42CcaZhmjsyMnFaSbwlflaH ZjwLAvTjbEZSOXnfh6pKjri1sXKi+qsXc/QPziq/sQttOWOiOZCnMK1pXJODdoh/Zbbm cgm3k0xBAbEEzE8RNB0aXvCPeCabcA/uT9n/nsPcvwzrCldC4f4TUieuXRcnQTizHYmY lYD91+LyN+uX1PEkrGke5iXX96pRV2C/mWXyP9HFcFNT8g/1m7BZpDQaqn05sGRedP0/ y4EQ== X-Received: by 10.140.85.116 with SMTP id m107mr19758307qgd.93.1413391357254; Wed, 15 Oct 2014 09:42:37 -0700 (PDT) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id x1sm18621748qax.17.2014.10.15.09.42.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 Oct 2014 09:42:35 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: Date: Wed, 15 Oct 2014 12:42:33 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8D532FB1-5145-439D-A5DF-16D178E66F91@gmail.com> References: <543E5B35.5000604@iang.org> <543E96C1.3030301@bogus.com> <543E9A7A.1050106@bogus.com> To: Yoav Nir Archived-At: http://mailarchive.ietf.org/arch/msg/saag/ecY1Jz3o-EuU8RjTjqY5FxoWTus Cc: "saag@ietf.org" Subject: Re: [saag] POODLE avant le chein X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 16:42:40 -0000 Sent from my iPhone > On Oct 15, 2014, at 12:33 PM, Yoav Nir wrote: >=20 >=20 > On Oct 15, 2014, at 7:02 PM, joel jaeggli wrote: >=20 >>> Cool. It's the enterprise level ones that may fall behind that is my >>> concern, this is all good news, thanks. Back to reading drafts :-) >>=20 >> there's definitely a herd immunity here. if your pre sp3 ie6 no longer >> works on important sites then you'll get a new browser, which provides >> everyone else cover to change their servers accordingly. >=20 > IDK. Pre-SP3 IE6 is a checkbox away from working. They had TLS disabled by= default for some reason, but it can even be turned on by an administrator t= hrough Microsoft=E2=80=99s tools. >=20 > It would be interesting to see in the next two iterations of the survey ho= w many sites will still have SSLv3 turned on. My guess is that the percentag= e will be depressingly high, considering that 11.7% still support SSLv2. >=20 Depressing stat, but thanks for the info. > https://securitypitfalls.wordpress.com/2014/09/29/scan-results-for-septemb= er-2014/ >=20 > I think there are two flavors to consider in enterprise servers. There=E2=80= =99s the intranet servers (erp.mycompany.com, exchange.mycompany.com, order-= lunch.mycompany.com). It=E2=80=99s hard to justify upgrading them, because (= a) they work, and (b) they=E2=80=99re behind the firewall, and (c) who knows= if the =E2=80=9Corder lunch=E2=80=9D application will keep working if we up= grade IIS, which we=E2=80=99ll have to if we upgrade the Windows 2000 server= . Of course being behind the firewall doesn=E2=80=99t help if your favorite b= rowser (including Firefox until late November) is going to accept Javascript= from outside sources that will run queries against your lunch ordering syst= em. Firewalls try to deal with this, but that battle hasn=E2=80=99t been won= yet. You're right, but I'd hope upgrades if browsers would help. >=20 > Internet-facing servers are a different matter. On the one hand, they have= to deal with anything that=E2=80=99s out there, but on the other hand, a lo= t of them are hosted these days, so the hosting companies (or CDNs) can make= a lot of difference. A decision by the likes of Akamai or Cloudflare can do= a lot for the statistics. >=20 > While the browser vendors are pretty much working together, there are a lo= t of programmatic clients out there. Think of the app on your phone that sho= ws a pretty picture of a rainy or sunny day on your phone based on data pull= ed from weather.com, or some client using SOAP or JSON or any other web serv= ices technology. These can also live for a long time unchanged since they =E2= =80=9Cjust work=E2=80=9D.=20 >=20 All good points. How do we help here? For Apple, they have a single place f= or apps, so they likely have a notification to authors of apps. I know EMC h= as the ability to post apps, but with Apple, there is a strict process aroun= d it. We could reach out to see what can be done there. Is anyone aware of options for other apps on other devices? =20 Or other places this will surface where we can help? Thanks, Kathleen=20 > Yoav From nobody Wed Oct 15 09:46:56 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 789F11A8A99 for ; Wed, 15 Oct 2014 09:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVvKAKcYhPSG for ; Wed, 15 Oct 2014 09:46:43 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 390DB1A8A07 for ; Wed, 15 Oct 2014 09:46:43 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 20F5C6D66E; Wed, 15 Oct 2014 12:46:35 -0400 (EDT) Message-ID: <543EA4EA.8020200@iang.org> Date: Wed, 15 Oct 2014 17:46:34 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Kathleen Moriarty References: <543E5B35.5000604@iang.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/fpYE270kvcF5idIAN4Y5nD5V2vc Cc: "saag@ietf.org" Subject: Re: [saag] POODLE avant le chein X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 16:46:49 -0000 On 15/10/2014 12:58 pm, Kathleen Moriarty wrote: >> So the real question for engineers is this: why is SSL 3.0 still in use? >> > > My take on this is that server operators are afraid to break their clients. What if browsers deprecated support for older versions so that it becomes easier for server operators to turn off support? Yes, a big long look at the situation leads to identification of a lot of "what if's" that combine to put the industry in deadly embrace. > Could we work together with all the browser vendors to phase out SSLv3? Then anything else we should deprecate. Of course this requires people to upgrade browsers. As a practical matter of Poodle, it's already a done deal. Google have already announced they'll kill SSLv3 within months, and they're prepared to break the net to do it. Mozilla too, no doubt MS is writing its PR as we speak. On the wider front, the next big failure -- I think the question may well be "who do we work with" ? Or, "what advice do we give?" Or, "how do we deliver a kill-bill in protocol/policy such that it bites in the field?" I don't have answers, only questions. But sometimes framing the right question is half the battle. iang From nobody Wed Oct 15 09:56:18 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1761A8A3E for ; Wed, 15 Oct 2014 09:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bG0PbnMVixRR for ; Wed, 15 Oct 2014 09:56:13 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3212D1A8A3A for ; Wed, 15 Oct 2014 09:56:13 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 517076D6E4; Wed, 15 Oct 2014 12:56:10 -0400 (EDT) Message-ID: <543EA728.1020803@iang.org> Date: Wed, 15 Oct 2014 17:56:08 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag@ietf.org References: <543E5B35.5000604@iang.org> <543E992C.7000802@cs.tcd.ie> In-Reply-To: <543E992C.7000802@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/iagNYBP4bdY2wg8xEVVeubFvFDw Subject: Re: [saag] getting rid of fairly old stuff X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 16:56:15 -0000 On 15/10/2014 16:56 pm, Stephen Farrell wrote: > > > On 15/10/14 16:46, Kathleen Moriarty wrote: >> Thanks for the article, it looks like the major browser vendors are already >> working together, no surprise there, but a big thanks to each of them as >> that's probably the best way to tackle this (from my experience). > > Hopefully so, and good to see the browsers and some large > server sites moving. > > If they can now get rid of SSLv3 within say a couple of months, > (and I hope they can), then we should maybe be asking ourselves > if we (the IETF) can help 'em somehow not let such stuff linger > for so long in future. Not sure how, but say if we'd published > an "SSLv3 considered possibly harmful" RFC about 8 years after > RFC 2246 was published, do we think that might have helped, or > might an equivalent help in future? Looking about randomly, I > see TLS1.1 is 8 years old now:-) Not sure where 8 years came from, but I'm fine with it because in my handwavy thinking, I settled on 7 years... So, let's say we settle on 8, either for all or independently negotiated per protocol. Perhaps a standard practice then in an RFC is that there should be a date by which the work is declared out-of-date. A sunset clause in the Security section, mandatory, based on the best view of the authors of the time. Thereby forcing a reconvening at that time to either vote to move the sunset date forward another 8 years (well done, nice design!) or to prepare V2 for replacement. This RFC will expire in 2022, by which time a new generation protocol will be prepared and all users encouraged to have transitioned, and/or this current version will be marked abandoned. or words to effect. > And just to clarify, my question isn't really about TLS, but > about whether there's an IETF thing to be done here that might > help. (And the answer for now is I'm not sure.) iang From nobody Wed Oct 15 10:29:36 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE2051AC3CD for ; Wed, 15 Oct 2014 10:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vcRA364PEda8 for ; Wed, 15 Oct 2014 10:29:32 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 342871AC3CE for ; Wed, 15 Oct 2014 10:29:32 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id fb4so13630670wid.6 for ; Wed, 15 Oct 2014 10:29:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=59rIo/qix9xIueuH8RpYHq7ROBqk6NtQDi+5R4iHzBQ=; b=MismnIetVApAlaZkIQt/POAbd72+OcKqzO0+BTgvsYEmZfedwpi9vqK1hj6iQXohWW 2KLQYAsLXuqrG9fkLOGZ7SF6tSXooFc74uik/yznn0f24P/BQcypiOIo2BTfNcAjdIGp fB/kGhHO7cuIdUGcrU7sgyFaUca7A6HYbPNaso119ZWhTd8Z22cssHOaJX0lXedev6bq TCtZETv1E2EV1XqlSuKEsdFUpfLcBOjGyQ+A+2JVYIUN6/u2QG1bNN5bp5ccEOrgCTFk 9w7dQFddYaZQ1ANNjIlLYLjJp3xj7JBl35nMmPiDik2TnCFIpeAeJc2x7lDbbz8D99/g 7PwQ== X-Received: by 10.194.203.201 with SMTP id ks9mr4975991wjc.105.1413394170722; Wed, 15 Oct 2014 10:29:30 -0700 (PDT) Received: from [192.168.1.104] (IGLD-84-228-54-205.inter.net.il. [84.228.54.205]) by mx.google.com with ESMTPSA id wk5sm24596972wjb.12.2014.10.15.10.29.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 Oct 2014 10:29:30 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_28BD3D3C-40BD-4AE8-ACA7-6918A5C2A7DD" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Yoav Nir In-Reply-To: <543EA728.1020803@iang.org> Date: Wed, 15 Oct 2014 20:29:28 +0300 Message-Id: References: <543E5B35.5000604@iang.org> <543E992C.7000802@cs.tcd.ie> <543EA728.1020803@iang.org> To: ianG X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/M8Sr5I5K7yqXI7SwrAhd8tzpjxM Cc: saag@ietf.org Subject: Re: [saag] getting rid of fairly old stuff X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 17:29:34 -0000 --Apple-Mail=_28BD3D3C-40BD-4AE8-ACA7-6918A5C2A7DD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 15, 2014, at 7:56 PM, ianG wrote: > On 15/10/2014 16:56 pm, Stephen Farrell wrote: >>=20 >>=20 >> On 15/10/14 16:46, Kathleen Moriarty wrote: >>> Thanks for the article, it looks like the major browser vendors are = already >>> working together, no surprise there, but a big thanks to each of = them as >>> that's probably the best way to tackle this (from my experience). >>=20 >> Hopefully so, and good to see the browsers and some large >> server sites moving. >>=20 >> If they can now get rid of SSLv3 within say a couple of months, >> (and I hope they can), then we should maybe be asking ourselves >> if we (the IETF) can help 'em somehow not let such stuff linger >> for so long in future. Not sure how, but say if we'd published >> an "SSLv3 considered possibly harmful" RFC about 8 years after >> RFC 2246 was published, do we think that might have helped, or >> might an equivalent help in future? Looking about randomly, I >> see TLS1.1 is 8 years old now:-) >=20 >=20 > Not sure where 8 years came from, but I'm fine with it because in my > handwavy thinking, I settled on 7 years... >=20 > So, let's say we settle on 8, either for all or independently = negotiated > per protocol. >=20 > Perhaps a standard practice then in an RFC is that there should be a > date by which the work is declared out-of-date. A sunset clause in = the > Security section, mandatory, based on the best view of the authors of > the time. >=20 > Thereby forcing a reconvening at that time to either vote to move the > sunset date forward another 8 years (well done, nice design!) or to > prepare V2 for replacement. >=20 > This RFC will expire in 2022, by which time > a new generation protocol will be prepared and > all users encouraged to have transitioned, and/or > this current version will be marked abandoned. >=20 > or words to effect. So are vendors supposed to ship products that just suddenly stop working = in 2022? It=92s hard to argue with the feeling of administrators that = =93the product works now. Why should I upgrade?=94 Let=92s keep picking on TLS. A TLS 1.3 specification is going to come = out at some point. There=92s dozens of implementations out there, and = I=92m sure all of those that are maintained will implement 1.3. Some = will implement it with bugs. Some combinations of client and server = implementations will not interoperate. Sure, OpenSSL and NSS and = whatever Microsoft calls their library internally (SCHANNEL?) will work = together. But it will be a good chance to remember that your firewall, = your ERP and your home router also have their own TLS implementation. So = the first administrators to upgrade their software *and* enable TLS 1.3 = are going to be the early adopters who get hit with interop problems.=20 Sure, if you have a modern code base, and you=92re using SSLv3 and now = enable TLS 1.0, you=92re very likely safe. But there was a reason why = Microsoft disabled TLS when XP first came out. And when Apple released = TLS 1.2 in iOS (they were pretty early in doing so) they got hit with = interop problems (which were in their code, but still=85) It=92s very tempting for administrators to wait until everyone does = something. But if you=92re waiting for =93everybody=94, that likely = means that you=92re disabling SSLv3 in late 2014 or early 2015, not = shortly after the publication of TLS 1.0 15 years earlier. Yoav --Apple-Mail=_28BD3D3C-40BD-4AE8-ACA7-6918A5C2A7DD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Oct 15, 2014, at 7:56 PM, ianG = <iang@iang.org> = wrote:

On 15/10/2014 16:56 pm, Stephen = Farrell wrote:


On 15/10/14 16:46, = Kathleen Moriarty wrote:
Thanks for the = article, it looks like the major browser vendors are already
working = together, no surprise there, but a big thanks to each of them = as
that's probably the best way to tackle this (from my = experience).

Hopefully so, and good to see the = browsers and some large
server sites moving.

If they can now = get rid of SSLv3 within say a couple of months,
(and I hope they = can), then we should maybe be asking ourselves
if we (the IETF) can = help 'em somehow not let such stuff linger
for so long in future. Not = sure how, but say if we'd published
an "SSLv3 considered possibly = harmful" RFC about 8 years after
RFC 2246 was published, do we think = that might have helped, or
might an equivalent help in future? = Looking about randomly, I
see TLS1.1 is 8 years old = now:-)


Not sure where 8 years came from, but I'm = fine with it because in my
handwavy thinking, I settled on 7 = years...

So, let's say we settle on 8, either for all or = independently negotiated
per protocol.

Perhaps a standard = practice then in an RFC is that there should be a
date by which the = work is declared out-of-date.  A sunset clause in the
Security = section, mandatory, based on the best view of the authors of
the = time.

Thereby forcing a reconvening at that time to either vote = to move the
sunset date forward another 8 years (well done, nice = design!) or to
prepare V2 for = replacement.

    This RFC will expire in = 2022, by which time
    a new generation protocol = will be prepared and
    all users encouraged to = have transitioned, and/or
    this current = version will be marked abandoned.

or words to = effect.

So are vendors supposed to = ship products that just suddenly stop working in 2022? It=92s hard to = argue with the feeling of administrators that =93the product works now. = Why should I upgrade?=94

Let=92s keep picking = on TLS. A TLS 1.3 specification is going to come out at some point. = There=92s dozens of implementations out there, and I=92m sure all of = those that are maintained will implement 1.3. Some will implement it = with bugs. Some combinations of client and server implementations will = not interoperate. Sure, OpenSSL and NSS and whatever Microsoft calls = their library internally (SCHANNEL?) will work together. But it will be = a good chance to remember that your firewall, your ERP and your home = router also have their own TLS implementation. So the first = administrators to upgrade their software *and* enable TLS 1.3 are going = to be the early adopters who get hit with interop = problems. 

Sure, if you have a modern code = base, and you=92re using SSLv3 and now enable TLS 1.0, you=92re very = likely safe. But there was a reason why Microsoft disabled TLS when XP = first came out. And when Apple released TLS 1.2 in iOS (they were pretty = early in doing so) they got hit with interop problems (which were in = their code, but still=85)

It=92s very tempting = for administrators to wait until everyone does something. But if you=92re = waiting for =93everybody=94, that likely means that you=92re disabling = SSLv3 in late 2014 or early 2015, not shortly after the publication of = TLS 1.0 15 years = earlier.

Yoav

= --Apple-Mail=_28BD3D3C-40BD-4AE8-ACA7-6918A5C2A7DD-- From nobody Wed Oct 15 10:38:04 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE0671AC3F7 for ; Wed, 15 Oct 2014 10:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7o9vPXhPCF6O for ; Wed, 15 Oct 2014 10:37:59 -0700 (PDT) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 528391AC3F0 for ; Wed, 15 Oct 2014 10:37:53 -0700 (PDT) Received: by mail-qc0-f171.google.com with SMTP id i17so1386450qcy.2 for ; Wed, 15 Oct 2014 10:37:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oPuzYEVvY9AzbC36hDmeT7gG8omuMwm6+CKmZ3y+l+s=; b=LyV7AqR0Ala+UiV9h2p93WwbxCBc40Xo5ge5baC2HkNcQ/xiUdcZ25LT5Rud/pNf/3 ZhltU6LllbVFKE0BeTGbznFQWiEK60ol295P5/9ZDokYvjR8QIpXMudQGX4dfV8d1sHq S8xw80/P6vSndBkrySVGfWCwdbKqVv9W3L8xhRMIrQOma2sUMRhORnbIXscfPsPvq3Au oCOXv5NAnm/s7wBVar8xdlS87cTRZC5bjmYzVZ4zJSEdbaujQFOGLYcpKfoxtd8h4K7p 3NWd0lRFt5422Q+UeujzGWqexGGHlIiyuoFHc+56CP9W6XWq74RSn+NgJPcLC20jy40Y BPyQ== X-Received: by 10.140.107.11 with SMTP id g11mr120958qgf.38.1413394672518; Wed, 15 Oct 2014 10:37:52 -0700 (PDT) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id w8sm19177638qag.2.2014.10.15.10.37.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 Oct 2014 10:37:51 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: multipart/alternative; boundary=Apple-Mail-DC1BC95D-6DC3-46EC-8E4F-2266B44B98F2 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: Date: Wed, 15 Oct 2014 13:37:49 -0400 Content-Transfer-Encoding: 7bit Message-Id: <030A1293-E48B-4E6D-B773-8AB09DA82D7F@gmail.com> References: <543E5B35.5000604@iang.org> <543E992C.7000802@cs.tcd.ie> <543EA728.1020803@iang.org> To: Yoav Nir Archived-At: http://mailarchive.ietf.org/arch/msg/saag/VFeY3krGp7gp6_HvfvVwQjx9dyE Cc: "saag@ietf.org" Subject: Re: [saag] getting rid of fairly old stuff X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 17:38:02 -0000 --Apple-Mail-DC1BC95D-6DC3-46EC-8E4F-2266B44B98F2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sent from my iPhone > On Oct 15, 2014, at 1:29 PM, Yoav Nir wrote: >=20 >=20 >> On Oct 15, 2014, at 7:56 PM, ianG wrote: >>=20 >>> On 15/10/2014 16:56 pm, Stephen Farrell wrote: >>>=20 >>>=20 >>>> On 15/10/14 16:46, Kathleen Moriarty wrote: >>>> Thanks for the article, it looks like the major browser vendors are alr= eady >>>> working together, no surprise there, but a big thanks to each of them a= s >>>> that's probably the best way to tackle this (from my experience). >>>=20 >>> Hopefully so, and good to see the browsers and some large >>> server sites moving. >>>=20 >>> If they can now get rid of SSLv3 within say a couple of months, >>> (and I hope they can), then we should maybe be asking ourselves >>> if we (the IETF) can help 'em somehow not let such stuff linger >>> for so long in future. Not sure how, but say if we'd published >>> an "SSLv3 considered possibly harmful" RFC about 8 years after >>> RFC 2246 was published, do we think that might have helped, or >>> might an equivalent help in future? Looking about randomly, I >>> see TLS1.1 is 8 years old now:-) >>=20 >>=20 >> Not sure where 8 years came from, but I'm fine with it because in my >> handwavy thinking, I settled on 7 years... >>=20 >> So, let's say we settle on 8, either for all or independently negotiated >> per protocol. >>=20 >> Perhaps a standard practice then in an RFC is that there should be a >> date by which the work is declared out-of-date. A sunset clause in the >> Security section, mandatory, based on the best view of the authors of >> the time. >>=20 >> Thereby forcing a reconvening at that time to either vote to move the >> sunset date forward another 8 years (well done, nice design!) or to >> prepare V2 for replacement. >>=20 >> This RFC will expire in 2022, by which time >> a new generation protocol will be prepared and >> all users encouraged to have transitioned, and/or >> this current version will be marked abandoned. >>=20 >> or words to effect. >=20 > So are vendors supposed to ship products that just suddenly stop working i= n 2022? It=E2=80=99s hard to argue with the feeling of administrators that =E2= =80=9Cthe product works now. Why should I upgrade?=E2=80=9D >=20 +1 I think there are enough issues that have been identified already that we co= uld help fix and have a bigger impact. Appreciate the continued discussion o= n what can we do. Thanks, Kathleen > Let=E2=80=99s keep picking on TLS. A TLS 1.3 specification is going to com= e out at some point. There=E2=80=99s dozens of implementations out there, an= d I=E2=80=99m sure all of those that are maintained will implement 1.3. Some= will implement it with bugs. Some combinations of client and server impleme= ntations will not interoperate. Sure, OpenSSL and NSS and whatever Microsoft= calls their library internally (SCHANNEL?) will work together. But it will b= e a good chance to remember that your firewall, your ERP and your home route= r also have their own TLS implementation. So the first administrators to upg= rade their software *and* enable TLS 1.3 are going to be the early adopters w= ho get hit with interop problems.=20 >=20 > Sure, if you have a modern code base, and you=E2=80=99re using SSLv3 and n= ow enable TLS 1.0, you=E2=80=99re very likely safe. But there was a reason w= hy Microsoft disabled TLS when XP first came out. And when Apple released TL= S 1.2 in iOS (they were pretty early in doing so) they got hit with interop p= roblems (which were in their code, but still=E2=80=A6) >=20 > It=E2=80=99s very tempting for administrators to wait until everyone does s= omething. But if you=E2=80=99re waiting for =E2=80=9Ceverybody=E2=80=9D, tha= t likely means that you=E2=80=99re disabling SSLv3 in late 2014 or early 201= 5, not shortly after the publication of TLS 1.0 15 years earlier. >=20 > Yoav >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --Apple-Mail-DC1BC95D-6DC3-46EC-8E4F-2266B44B98F2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


Sent from my iPhone
=
On Oct 15, 2014, at 1:29 PM, Yoav Nir <ynir.ietf@gmail.com> wrote:


On Oct 15, 2014, at 7:56 PM, ianG <iang@iang.org> wrote:

On 15/10/2014 16:56 pm, Stephen Fa= rrell wrote:


On 15/10/14 16:46, Kathlee= n Moriarty wrote:
Thanks for the article, it lo= oks like the major browser vendors are already
working together, no surpr= ise there, but a big thanks to each of them as
that's probably the best w= ay to tackle this (from my experience).

Hopefully so, an= d good to see the browsers and some large
server sites moving.

If t= hey can now get rid of SSLv3 within say a couple of months,
(and I hope t= hey can), then we should maybe be asking ourselves
if we (the IETF) can h= elp 'em somehow not let such stuff linger
for so long in future. Not sure= how, but say if we'd published
an "SSLv3 considered possibly harmful" RFC= about 8 years after
RFC 2246 was published, do we think that might have h= elped, or
might an equivalent help in future? Looking about randomly, Isee TLS1.1 is 8 years old now:-)


Not sure where 8 y= ears came from, but I'm fine with it because in my
handwavy thinking, I s= ettled on 7 years...

So, let's say we settle on 8, either for all or i= ndependently negotiated
per protocol.

Perhaps a standard practice t= hen in an RFC is that there should be a
date by which the work is declare= d out-of-date.  A sunset clause in the
Security section, mandatory, b= ased on the best view of the authors of
the time.

Thereby forcing a= reconvening at that time to either vote to move the
sunset date forward a= nother 8 years (well done, nice design!) or to
prepare V2 for replacement= .

    This RFC will expire in 2022, by which time=
    a new generation protocol will be prepared and    all users encouraged to have transitioned, and/or<= br>    this current version will be marked abandoned.
or words to effect.

So are vendors= supposed to ship products that just suddenly stop working in 2022? It=E2=80= =99s hard to argue with the feeling of administrators that =E2=80=9Cthe prod= uct works now. Why should I upgrade?=E2=80=9D


+1

I think there are enough issue= s that have been identified already that we could help fix and have a bigger= impact.  Appreciate the continued discussion on what can we do.
<= div>
Thanks,
Kathleen


<= blockquote type=3D"cite">
Let=E2=80=99s keep picking on TLS. A TLS 1= .3 specification is going to come out at some point. There=E2=80=99s dozens o= f implementations out there, and I=E2=80=99m sure all of those that are main= tained will implement 1.3. Some will implement it with bugs. Some combinatio= ns of client and server implementations will not interoperate. Sure, OpenSSL= and NSS and whatever Microsoft calls their library internally (SCHANNEL?) w= ill work together. But it will be a good chance to remember that your firewa= ll, your ERP and your home router also have their own TLS implementation. So= the first administrators to upgrade their software *and* enable TLS 1.3 are= going to be the early adopters who get hit with interop problems. 

Sure, if you have a modern code base, and you=E2=80=99= re using SSLv3 and now enable TLS 1.0, you=E2=80=99re very likely safe. But t= here was a reason why Microsoft disabled TLS when XP first came out. And whe= n Apple released TLS 1.2 in iOS (they were pretty early in doing so) they go= t hit with interop problems (which were in their code, but still=E2=80=A6)

It=E2=80=99s very tempting for administrators to wai= t until everyone does something. But if you=E2=80=99re waiting for =E2=80=9C= everybody=E2=80=9D, that likely means that you=E2=80=99re disabling SSLv3 in= late 2014 or early 2015, not shortly after the publication of TLS 1.0 15 ye= ars earlier.

Yoav

_________________________________= ______________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saa= g
= --Apple-Mail-DC1BC95D-6DC3-46EC-8E4F-2266B44B98F2-- From nobody Wed Oct 15 11:33:27 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 912FE1A8AEB for ; Wed, 15 Oct 2014 11:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gUvz20c48WT for ; Wed, 15 Oct 2014 11:33:24 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDD451A86F4 for ; Wed, 15 Oct 2014 11:33:23 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2112420031; Wed, 15 Oct 2014 14:33:53 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 4EE6763B40; Wed, 15 Oct 2014 14:33:22 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 3B8C363B3F; Wed, 15 Oct 2014 14:33:22 -0400 (EDT) From: Michael Richardson To: Watson Ladd In-Reply-To: References: X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/saag/p4j-ZRCuFZz25qQwS3ZN7iKz8Ak Cc: "saag@ietf.org" Subject: Re: [saag] POODLE avant le chein X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 18:33:25 -0000 --=-=-= Watson Ladd wrote: > Now that we've all disabled SSLv3 on every machine in reach, let's > review when this attack was discovered. Not in 2014, but in 2001: It's > in Vaudenay, section 5, applied to randomized padding in SSHv2, where > it was fixed. Credit belongs to Luca Bruno for pointing this out on > Twitter. ... > What other protocols have random padding in CBC mode after a MAC? Is > there any way to determine this beyond asking everyone to help, IPsec ESP pads with sequential padding, encrypts, and then HMAC-x. So I think IPsec doesn't "CBC mode after a MAC" but rather, "CBC mode before a MAC". I haven't read the details of the attack yet; I figure I'll wait a day. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVD6974CLcPvd0N1lAQLuVgf/aGUaz2fkVrEKWGp+9wjZj1cZAUFnzaig 8LbRSIUj3rqXw947wFRlvzA1JU5FA/8JTyUMFvKWKRzfrXSA3yLfX4j9uY/yvcKD vxKWdVIUgyWxiBMa8J9pl2yFpio6YRaxmB8Cdibm/AUYl3AM3ovimIi4D1B+cwru nnf5rsqg7UiIoNVVVMN/qJBRB+ETbqxwxU3Qdd3QAExiKwB2fjHTMHU+AnhQEHWv D8yZ84ikz6eVFfN0LGZzBWRk4MfMdZwpj4iVOLyQ8dvOcYW5afn+QbWiIiO7LZ1j pi64CIaAGw25g4BCJSvHDKgKbY+eDYiUvbSO3nBA1BsjZmkCWPymKg== =Ss77 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Oct 15 14:35:01 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB461ACDBD for ; Wed, 15 Oct 2014 14:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwlpPzcAD_s5 for ; Wed, 15 Oct 2014 14:34:59 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0422F1ACDBC for ; Wed, 15 Oct 2014 14:34:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 584AFBED4; Wed, 15 Oct 2014 22:34:58 +0100 (IST) 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 bKuQACmY1Dxk; Wed, 15 Oct 2014 22:34:56 +0100 (IST) Received: from [10.87.48.12] (unknown [86.46.19.135]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 53C2DBE8B; Wed, 15 Oct 2014 22:34:56 +0100 (IST) Message-ID: <543EE87F.3000405@cs.tcd.ie> Date: Wed, 15 Oct 2014 22:34:55 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Yoav Nir , ianG References: <543E5B35.5000604@iang.org> <543E992C.7000802@cs.tcd.ie> <543EA728.1020803@iang.org> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Gt3-IfryPWjSsr-PZRby2izonu4 Cc: saag@ietf.org Subject: Re: [saag] getting rid of fairly old stuff X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 21:35:00 -0000 On 15/10/14 18:29, Yoav Nir wrote: > So are vendors supposed to ship products that just suddenly stop > working in 2022? Yeah, not sure I buy the "best-before date in the RFC" thing myself. Another issue is who'd do the work required. > It’s hard to argue with the feeling of > administrators that “the product works now. Why should I upgrade?” > > Let’s keep picking on TLS. A TLS 1.3 specification is going to come > out at some point. There’s dozens of implementations out there, and > I’m sure all of those that are maintained will implement 1.3. Some > will implement it with bugs. Some combinations of client and server > implementations will not interoperate. Sure, OpenSSL and NSS and > whatever Microsoft calls their library internally (SCHANNEL?) will > work together. But it will be a good chance to remember that your > firewall, your ERP and your home router also have their own TLS > implementation. So the first administrators to upgrade their software > *and* enable TLS 1.3 are going to be the early adopters who get hit > with interop problems. > > Sure, if you have a modern code base, and you’re using SSLv3 and now > enable TLS 1.0, you’re very likely safe. But there was a reason why > Microsoft disabled TLS when XP first came out. And when Apple > released TLS 1.2 in iOS (they were pretty early in doing so) they got > hit with interop problems (which were in their code, but still…) > > It’s very tempting for administrators to wait until everyone does > something. But if you’re waiting for “everybody”, that likely means > that you’re disabling SSLv3 in late 2014 or early 2015, not shortly > after the publication of TLS 1.0 15 years earlier. I don't think anyone would say that TLS1.2 ought be quickly deprecated once TLS1.3 is done. More like, is now the time to write an RFC deprecating TLS 1.0? Or, would TLS1.3 being done be the time to try deprecate TLS1.1? I still don't know if that'd be useful, but I do know that we're all paying some costs for there being such old stuff still in code bases that can't be gotten rid of 1.5 decades after its no longer needed really. S. From nobody Wed Oct 15 19:42:20 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B773F1A0123 for ; Wed, 15 Oct 2014 19:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bnii3W_rj-Hq for ; Wed, 15 Oct 2014 19:42:16 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB4C41A011F for ; Wed, 15 Oct 2014 19:42:16 -0700 (PDT) Received: from Philemon (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 03ADD2CA03; Wed, 15 Oct 2014 19:42:15 -0700 (PDT) From: "Jim Schaad" To: "'Watson Ladd'" , References: In-Reply-To: Date: Wed, 15 Oct 2014 19:39:39 -0700 Message-ID: <06f201cfe8ea$6f5f94c0$4e1ebe40$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHWYDOVRiUB9GEbrq/k7viiouGSPpwlE83A Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/saag/-RDd8LFWgNTDtfqFl_3lrM4Lyc4 Subject: Re: [saag] POODLE avant le chein X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 02:42:18 -0000 > -----Original Message----- > From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Watson Ladd > Sent: Tuesday, October 14, 2014 6:21 PM > To: saag@ietf.org > Subject: [saag] POODLE avant le chein > > Dear all, > > Now that we've all disabled SSLv3 on every machine in reach, let's review > when this attack was discovered. Not in 2014, but in 2001: It's in Vaudenay, > section 5, applied to randomized padding in SSHv2, where it was fixed. Credit > belongs to Luca Bruno for pointing this out on Twitter. > > No one took the time to sit down with a copy of the paper and a copy of the > spec, and compare them until now. I should have, but didn't. > TLS isn't alone in this regard: I spent quite a bit of time trying to understand > which way CMS composes encryption and authentication, and gave up in > frustration reading the pile of RFCs. (The answer I believe is that CMS does > not use a MAC by default: there is a different content type that does support > AES-GCM, but I have no idea how often it is used. People more familiar than I > am with S/MIME should chime > in.) S/MIME is not going to be affected by this since it has never been updated to use authenticated encryption algorithms CMS has defined an AEAD structure to be used with authenticated algorithms. The only algorithms currently defined are AES-CCM, AES-GCM and RFC 6476. The first two don't use CBC so are not affected. The last one does encrypt then MAC so that the entire encryption stream is MAC-ed. My understanding is that this means that it should not be an issue as the pad is covered by the MAC value. Jim > > What other protocols have random padding in CBC mode after a MAC? Is > there any way to determine this beyond asking everyone to help, dividing up > a list of nearly 8,000 RFCs, and looking at them all? And perhaps most > importantly, what process changes will prevent known attacks from > surprising us in the future? > > There's also a question about how conservative we need to be when doing > new cryptographic protocols. But that's a more challenging one. > > Sincerely, > Watson Ladd > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Wed Oct 15 21:09:37 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A93B1A016F for ; Wed, 15 Oct 2014 21:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.401 X-Spam-Level: X-Spam-Status: No, score=0.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_31=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_51=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5gdYoh6kinf for ; Wed, 15 Oct 2014 21:09:32 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CE131A016A for ; Wed, 15 Oct 2014 21:09:31 -0700 (PDT) Received: by mail-lb0-f181.google.com with SMTP id l4so2168949lbv.12 for ; Wed, 15 Oct 2014 21:09:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=lKljW3go/GprdqysOyDgou1PwYE9q5A/EyqJbMYytmg=; b=DpZibYdAbfduMCrWyAtIepzPnSEVOH6kYymlRfKUwE+fW87mdAISDcAbfmHOsB9Xwd jeHLVSWKutKsTOkv0kX7JrwKK89NQgTv4+GzgnozApW5wCtg6IsTw2ccl6sVglutSJ2h TVjHrJdXYDzrK/qKvjJNq70gfCO1NOsqHrtvJzvBDWD8ymV1GkhBrW2HJEgB7JI9Rd3W MgFzaJXkNOO1HrSejElFrDFC+v379g95R1x0G2HVW1c9fbiAKpTnKRDcKtrsKpA6pp3N TMf7k16+WB5jBtqles9tNnnTdFXQ/dqfGVRzmpxMFrdOAXcTJlBjB6FQiwCbYPsXT25x Yqcg== MIME-Version: 1.0 X-Received: by 10.152.6.228 with SMTP id e4mr8328575laa.71.1413432570203; Wed, 15 Oct 2014 21:09:30 -0700 (PDT) Received: by 10.25.143.203 with HTTP; Wed, 15 Oct 2014 21:09:30 -0700 (PDT) Date: Thu, 16 Oct 2014 10:09:30 +0600 Message-ID: From: Fahima Ahmed Khan Etha To: saag@ietf.org Content-Type: multipart/alternative; boundary=089e013d0f8a42d5ed0505826a15 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/bYSp2jiTsHbta0nsbO-eD6peS7k Subject: [saag] How to find out if you are really Hacked or not X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 04:09:35 -0000 --089e013d0f8a42d5ed0505826a15 Content-Type: text/plain; charset=UTF-8 Dear All, It might be an off topic. But I am seeking guidance from all of you. If any hacker group claimed that you are hacked... How to proof or find out its authenticity? Please share your view. Best regards, Fahima On 16 October 2014 01:00, wrote: > Send saag mailing list submissions to > saag@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/saag > or, via email, send a message with subject or body 'help' to > saag-request@ietf.org > > You can reach the person managing the list at > saag-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of saag digest..." > > > Today's Topics: > > 1. Re: getting rid of fairly old stuff (Kathleen Moriarty) > 2. Re: POODLE avant le chein (Michael Richardson) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 15 Oct 2014 13:37:49 -0400 > From: Kathleen Moriarty > To: Yoav Nir > Cc: "saag@ietf.org" > Subject: Re: [saag] getting rid of fairly old stuff > Message-ID: <030A1293-E48B-4E6D-B773-8AB09DA82D7F@gmail.com> > Content-Type: text/plain; charset="utf-8" > > > > Sent from my iPhone > > > On Oct 15, 2014, at 1:29 PM, Yoav Nir wrote: > > > > > >> On Oct 15, 2014, at 7:56 PM, ianG wrote: > >> > >>> On 15/10/2014 16:56 pm, Stephen Farrell wrote: > >>> > >>> > >>>> On 15/10/14 16:46, Kathleen Moriarty wrote: > >>>> Thanks for the article, it looks like the major browser vendors are > already > >>>> working together, no surprise there, but a big thanks to each of them > as > >>>> that's probably the best way to tackle this (from my experience). > >>> > >>> Hopefully so, and good to see the browsers and some large > >>> server sites moving. > >>> > >>> If they can now get rid of SSLv3 within say a couple of months, > >>> (and I hope they can), then we should maybe be asking ourselves > >>> if we (the IETF) can help 'em somehow not let such stuff linger > >>> for so long in future. Not sure how, but say if we'd published > >>> an "SSLv3 considered possibly harmful" RFC about 8 years after > >>> RFC 2246 was published, do we think that might have helped, or > >>> might an equivalent help in future? Looking about randomly, I > >>> see TLS1.1 is 8 years old now:-) > >> > >> > >> Not sure where 8 years came from, but I'm fine with it because in my > >> handwavy thinking, I settled on 7 years... > >> > >> So, let's say we settle on 8, either for all or independently negotiated > >> per protocol. > >> > >> Perhaps a standard practice then in an RFC is that there should be a > >> date by which the work is declared out-of-date. A sunset clause in the > >> Security section, mandatory, based on the best view of the authors of > >> the time. > >> > >> Thereby forcing a reconvening at that time to either vote to move the > >> sunset date forward another 8 years (well done, nice design!) or to > >> prepare V2 for replacement. > >> > >> This RFC will expire in 2022, by which time > >> a new generation protocol will be prepared and > >> all users encouraged to have transitioned, and/or > >> this current version will be marked abandoned. > >> > >> or words to effect. > > > > So are vendors supposed to ship products that just suddenly stop working > in 2022? It?s hard to argue with the feeling of administrators that ?the > product works now. Why should I upgrade?? > > > > +1 > > I think there are enough issues that have been identified already that we > could help fix and have a bigger impact. Appreciate the continued > discussion on what can we do. > > Thanks, > Kathleen > > > > Let?s keep picking on TLS. A TLS 1.3 specification is going to come out > at some point. There?s dozens of implementations out there, and I?m sure > all of those that are maintained will implement 1.3. Some will implement it > with bugs. Some combinations of client and server implementations will not > interoperate. Sure, OpenSSL and NSS and whatever Microsoft calls their > library internally (SCHANNEL?) will work together. But it will be a good > chance to remember that your firewall, your ERP and your home router also > have their own TLS implementation. So the first administrators to upgrade > their software *and* enable TLS 1.3 are going to be the early adopters who > get hit with interop problems. > > > > Sure, if you have a modern code base, and you?re using SSLv3 and now > enable TLS 1.0, you?re very likely safe. But there was a reason why > Microsoft disabled TLS when XP first came out. And when Apple released TLS > 1.2 in iOS (they were pretty early in doing so) they got hit with interop > problems (which were in their code, but still?) > > > > It?s very tempting for administrators to wait until everyone does > something. But if you?re waiting for ?everybody?, that likely means that > you?re disabling SSLv3 in late 2014 or early 2015, not shortly after the > publication of TLS 1.0 15 years earlier. > > > > Yoav > > > > _______________________________________________ > > saag mailing list > > saag@ietf.org > > https://www.ietf.org/mailman/listinfo/saag > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://www.ietf.org/mail-archive/web/saag/attachments/20141015/e0fbc344/attachment.html > > > > ------------------------------ > > Message: 2 > Date: Wed, 15 Oct 2014 14:33:22 -0400 > From: Michael Richardson > To: Watson Ladd > Cc: "saag@ietf.org" > Subject: Re: [saag] POODLE avant le chein > Message-ID: <21318.1413398002@sandelman.ca> > Content-Type: text/plain; charset="us-ascii" > > > Watson Ladd wrote: > > Now that we've all disabled SSLv3 on every machine in reach, let's > > review when this attack was discovered. Not in 2014, but in 2001: > It's > > in Vaudenay, section 5, applied to randomized padding in SSHv2, where > > it was fixed. Credit belongs to Luca Bruno for pointing this out on > > Twitter. > > ... > > > What other protocols have random padding in CBC mode after a MAC? Is > > there any way to determine this beyond asking everyone to help, > > IPsec ESP pads with sequential padding, encrypts, and then HMAC-x. > So I think IPsec doesn't "CBC mode after a MAC" but rather, "CBC mode > before > a MAC". > > I haven't read the details of the attack yet; I figure I'll wait a day. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 481 bytes > Desc: not available > URL: < > http://www.ietf.org/mail-archive/web/saag/attachments/20141015/ec97fdf2/attachment.sig > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > > ------------------------------ > > End of saag Digest, Vol 76, Issue 5 > *********************************** > --089e013d0f8a42d5ed0505826a15 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Dear All,

It might be an off topic. But I am seeking guidance from all of you.

If any hacker group claimed that you are hacked... How to proof or find out its authenticity?

Please share your view.

= Best regards,

Fahima


On 16 October 201= 4 01:00, <saag-request@ietf.org> wrote:
Send saag mailing list submissions to=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 saag@ietf.org<= /a>

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/saag or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 saag-r= equest@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 saag-own= er@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of saag digest..."


Today's Topics:

=C2=A0 =C2=A01. Re: getting rid of fairly old stuff (Kathleen Moriarty)
=C2=A0 =C2=A02. Re: POODLE avant le chein (Michael Richardson)


----------------------------------------------------------------------

Message: 1
Date: Wed, 15 Oct 2014 13:37:49 -0400
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
To: Yoav Nir <ynir.ietf@gmail.com= >
Cc: "saag@ietf.org" <saag@ietf.org>
Subject: Re: [saag] getting rid of fairly old stuff
Message-ID: <030A1293-E48B-4E6D-B773-8AB09DA82D7F@gmail.com>
Content-Type: text/plain; charset=3D"utf-8"



Sent from my iPhone

> On Oct 15, 2014, at 1:29 PM, Yoav Nir <ynir.ietf@gmail.com> wrote:
>
>
>> On Oct 15, 2014, at 7:56 PM, ianG <iang@iang.org> wrote:
>>
>>> On 15/10/2014 16:56 pm, Stephen Farrell wrote:
>>>
>>>
>>>> On 15/10/14 16:46, Kathleen Moriarty wrote:
>>>> Thanks for the article, it looks like the major browser ve= ndors are already
>>>> working together, no surprise there, but a big thanks to e= ach of them as
>>>> that's probably the best way to tackle this (from my e= xperience).
>>>
>>> Hopefully so, and good to see the browsers and some large
>>> server sites moving.
>>>
>>> If they can now get rid of SSLv3 within say a couple of months= ,
>>> (and I hope they can), then we should maybe be asking ourselve= s
>>> if we (the IETF) can help 'em somehow not let such stuff l= inger
>>> for so long in future. Not sure how, but say if we'd publi= shed
>>> an "SSLv3 considered possibly harmful" RFC about 8 y= ears after
>>> RFC 2246 was published, do we think that might have helped, or=
>>> might an equivalent help in future? Looking about randomly, I<= br> >>> see TLS1.1 is 8 years old now:-)
>>
>>
>> Not sure where 8 years came from, but I'm fine with it because= in my
>> handwavy thinking, I settled on 7 years...
>>
>> So, let's say we settle on 8, either for all or independently = negotiated
>> per protocol.
>>
>> Perhaps a standard practice then in an RFC is that there should be= a
>> date by which the work is declared out-of-date.=C2=A0 A sunset cla= use in the
>> Security section, mandatory, based on the best view of the authors= of
>> the time.
>>
>> Thereby forcing a reconvening at that time to either vote to move = the
>> sunset date forward another 8 years (well done, nice design!) or t= o
>> prepare V2 for replacement.
>>
>>=C2=A0 =C2=A0 =C2=A0This RFC will expire in 2022, by which time
>>=C2=A0 =C2=A0 =C2=A0a new generation protocol will be prepared and<= br> >>=C2=A0 =C2=A0 =C2=A0all users encouraged to have transitioned, and/= or
>>=C2=A0 =C2=A0 =C2=A0this current version will be marked abandoned.<= br> >>
>> or words to effect.
>
> So are vendors supposed to ship products that just suddenly stop worki= ng in 2022? It?s hard to argue with the feeling of administrators that ?the= product works now. Why should I upgrade??
>

+1

I think there are enough issues that have been identified already that we c= ould help fix and have a bigger impact.=C2=A0 Appreciate the continued disc= ussion on what can we do.

Thanks,
Kathleen


> Let?s keep picking on TLS. A TLS 1.3 specification is going to come ou= t at some point. There?s dozens of implementations out there, and I?m sure = all of those that are maintained will implement 1.3. Some will implement it= with bugs. Some combinations of client and server implementations will not= interoperate. Sure, OpenSSL and NSS and whatever Microsoft calls their lib= rary internally (SCHANNEL?) will work together. But it will be a good chanc= e to remember that your firewall, your ERP and your home router also have t= heir own TLS implementation. So the first administrators to upgrade their s= oftware *and* enable TLS 1.3 are going to be the early adopters who get hit= with interop problems.
>
> Sure, if you have a modern code base, and you?re using SSLv3 and now e= nable TLS 1.0, you?re very likely safe. But there was a reason why Microsof= t disabled TLS when XP first came out. And when Apple released TLS 1.2 in i= OS (they were pretty early in doing so) they got hit with interop problems = (which were in their code, but still?)
>
> It?s very tempting for administrators to wait until everyone does some= thing. But if you?re waiting for ?everybody?, that likely means that you?re= disabling SSLv3 in late 2014 or early 2015, not shortly after the publicat= ion of TLS 1.0 15 years earlier.
>
> Yoav
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mai= l-archive/web/saag/attachments/20141015/e0fbc344/attachment.html>
------------------------------

Message: 2
Date: Wed, 15 Oct 2014 14:33:22 -0400
From: Michael Richardson <mcr= +ietf@sandelman.ca>
To: Watson Ladd <watsonbladd@gm= ail.com>
Cc: "saag@ietf.org" <saag@ietf.org>
Subject: Re: [saag] POODLE avant le chein
Message-ID: <21318.1413= 398002@sandelman.ca>
Content-Type: text/plain; charset=3D"us-ascii"


Watson Ladd <watsonbladd@gmail.= com> wrote:
=C2=A0 =C2=A0 > Now that we've all disabled SSLv3 on every machine i= n reach, let's
=C2=A0 =C2=A0 > review when this attack was discovered. Not in 2014, but= in 2001: It's
=C2=A0 =C2=A0 > in Vaudenay, section 5, applied to randomized padding in= SSHv2, where
=C2=A0 =C2=A0 > it was fixed. Credit belongs to Luca Bruno for pointing = this out on
=C2=A0 =C2=A0 > Twitter.

...

=C2=A0 =C2=A0 > What other protocols have random padding in CBC mode aft= er a MAC? Is
=C2=A0 =C2=A0 > there any way to determine this beyond asking everyone t= o help,

IPsec ESP pads with sequential padding, encrypts, and then HMAC-x.
So I think IPsec doesn't "CBC mode after a MAC" but rather, &= quot;CBC mode before
a MAC".

I haven't read the details of the attack yet; I figure I'll wait a = day.

--
Michael Richardson <mcr+IETF@= sandelman.ca>, Sandelman Software Works
=C2=A0-=3D IPv6 IoT consulting =3D-



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 481 bytes
Desc: not available
URL: <http://www.ietf.org/mail= -archive/web/saag/attachments/20141015/ec97fdf2/attachment.sig>

------------------------------

Subject: Digest Footer

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


------------------------------

End of saag Digest, Vol 76, Issue 5
***********************************

--089e013d0f8a42d5ed0505826a15-- From nobody Thu Oct 16 01:24:26 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D23881A0439 for ; Thu, 16 Oct 2014 01:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8u_OFiOrHfhB for ; Thu, 16 Oct 2014 01:24:21 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 208A21A0398 for ; Thu, 16 Oct 2014 01:24:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1413447861; x=1444983861; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=UgfNtiImoaSg6hJawjx6wN77voNTwl8WOu9BUbZ8Hao=; b=J9BVn/nhvGQ08ymxAUfWNbca8+vfq0V0rERtXrK2p2hXv9E6NwoW9Lhx CFr1rXtrcSKoZ+GLU0PLOlDofWVR5wKhgPmjmVLatVmVK1+u+gZ4B1EjZ UqyHGrvdYsZMKxNlHvRkL/7EI0CywLti+ZVYXxs2I8IQeIE9DT+Pzz76A k=; X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="283635181" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 16 Oct 2014 21:24:16 +1300 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.70]) by uxchange10-fe3.UoA.auckland.ac.nz ([130.216.4.125]) with mapi id 14.03.0174.001; Thu, 16 Oct 2014 21:24:15 +1300 From: Peter Gutmann To: "saag@ietf.org" Thread-Topic: [saag] POODLE avant le chein Thread-Index: Ac/pGpJ2Vn8mJqDUS868FvsixtUaZw== Date: Thu, 16 Oct 2014 08:24:15 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9CCD86@uxcn10-tdc05.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Pyw3TD99AUEoy1_t6CI6LQvCNa8 Subject: Re: [saag] POODLE avant le chein X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 08:24:25 -0000 "Black, David" writes:=0A= =0A= >One down (Firefox) ...=0A= >=0A= >https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-end= -of-ssl-3-0/=0A= =0A= On another list there's a discussion that www.poodletest.com is reporting= =0A= Firefox (latest versions) vulnerable or not vulnerable for different people= ,=0A= there's no obvious pattern (although the sample size is currently rather=0A= small).=0A= =0A= >Nit: Le mot en francais est "le chien", pas "le chein" ;-).=0A= =0A= I was also wondering about the phrasing, I would have expected "POODLE:=0A= Attention au chien", what's the significance of saying "before the dog"?=0A= Also, if someone can give the next attack that comes along a feline name th= ey=0A= have my permission to use this:=0A= =0A= https://www.flickr.com/photos/nzphoto/15241814340/lightbox/=0A= =0A= CBC-HMAC Authenticator Truncation seems like one viable name.=0A= =0A= Peter :-).= From nobody Thu Oct 16 01:28:32 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2951A19E4 for ; Thu, 16 Oct 2014 01:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YeDSVr-NqzSA for ; Thu, 16 Oct 2014 01:28:30 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2C5F1A0398 for ; Thu, 16 Oct 2014 01:28:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1413448110; x=1444984110; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=/p1N33qRh914Px9HNWu/6Zcv0FZ2GPdnExSgXhn5G9w=; b=Yuzl+YJIKG2SBdJ+ANmymxnhF39D7IIbYv76o3pUVnervH2D6Q5NyiXu NDcGQKxVYvM/Q/UyZgpcREQ5aHWKpcXCqvfM4csyG8y2y4KAMLe097/ns AHOwg4ZtxGXFul5DoBUsO431EfguJr3PmL54urpq5r5pAYvQLwdqqSL1P A=; X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="283635531" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 16 Oct 2014 21:28:28 +1300 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.70]) by uxchange10-fe2.UoA.auckland.ac.nz ([169.254.27.86]) with mapi id 14.03.0174.001; Thu, 16 Oct 2014 21:28:28 +1300 From: Peter Gutmann To: "saag@ietf.org" Thread-Topic: [saag] getting rid of fairly old stuff (was: Re: POODLE avant le chein) Thread-Index: Ac/pGyi//cycRLRtSUWRhJ4stgT6SQ== Date: Thu, 16 Oct 2014 08:28:27 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9CCD93@uxcn10-tdc05.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/DcRSsIL-Q2UxvM9YD1LyD8hEZx4 Subject: Re: [saag] getting rid of fairly old stuff (was: Re: POODLE avant le chein) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 08:28:31 -0000 Stephen Farrell writes:=0A= =0A= >And just to clarify, my question isn't really about TLS, but about whether= =0A= >there's an IETF thing to be done here that might help. (And the answer for= =0A= >now is I'm not sure.)=0A= =0A= I realise I'm slightly biased on this issue since I'm the author of the RFC= ,=0A= but getting RFC 7366, "Encrypt-then-MAC for Transport Layer Security (TLS) = and=0A= Datagram Transport Layer Security (DTLS)", adopted as a matter of priority= =0A= would by a good start, that'd make 10-15 years of these attacks go away pre= tty=0A= quickly.=0A= =0A= Peter.=0A= From nobody Thu Oct 16 01:34:10 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C54F1A0354 for ; Thu, 16 Oct 2014 01:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qj1TKQoegytb for ; Thu, 16 Oct 2014 01:34:09 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C66C1A0053 for ; Thu, 16 Oct 2014 01:34:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1413448448; x=1444984448; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=xQfruuITuLL7lyUP8YNlfP/8ZHmEbUnljJN1pA2f+tU=; b=I+SCk76q1ApCYZT/OE1KvBWJvD7RnUPT050ExhqkYEkXyxVdmpvH6rsk yigx/B7CgNDG74ROejFuhHkuW2w7pUZ3YNZ94Ib44MlG1lSBOiM4QMLTC /o4cBPMEWefwWIHLPSYHzkOF6ZjNcdcOPbMMhCb6lg40LXaZXIH1novj5 Q=; X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="283636043" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 16 Oct 2014 21:34:07 +1300 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.70]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Thu, 16 Oct 2014 21:34:06 +1300 From: Peter Gutmann To: "saag@ietf.org" Thread-Topic: [saag] POODLE avant le chein Thread-Index: Ac/pG/Jg8rhpaPYDQKCtIjZvxrY6XQ== Date: Thu, 16 Oct 2014 08:34:05 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9CCDAC@uxcn10-tdc05.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/OjwOoeMQxQlkSm-bF-QhvfrQBIk Subject: Re: [saag] POODLE avant le chein X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 08:34:10 -0000 Jim Schaad writes:=0A= =0A= >CMS has defined an AEAD structure to be used with authenticated algorithms= .=0A= >The only algorithms currently defined are AES-CCM, AES-GCM and RFC 6476. T= he=0A= >first two don't use CBC so are not affected. The last one does encrypt th= en=0A= >MAC so that the entire encryption stream is MAC-ed. My understanding is t= hat=0A= >this means that it should not be an issue as the pad is covered by the MAC= =0A= >value.=0A= =0A= That was by deliberate design, MAC everything including metadata [0]. It's= =0A= the same for RFC 7366, "Encrypt-then-MAC for Transport Layer Security (TLS)= =0A= and Datagram Transport Layer Security (DTLS)", that finally fixes a problem= =0A= that's been plaguing SSL and TLS for 10-15 years (and what a battle it was= =0A= getting it adopted by the TLS WG).=0A= =0A= Peter.=0A= =0A= [0] Thanks to Jim for pointing out in an early draft that I'd missed a bit = :-).= From nobody Thu Oct 16 02:07:00 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAF01A014F for ; Thu, 16 Oct 2014 02:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b_K-Y92Tvd0i for ; Thu, 16 Oct 2014 02:06:54 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4974B1A1AE8 for ; Thu, 16 Oct 2014 02:06:54 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id d1so4134683wiv.0 for ; Thu, 16 Oct 2014 02:06:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=IFfv/b1xAMcUMDy/gAx/gwMzSi4I0Nbpsy3SnfcFdjw=; b=iEUJpcFNbpGtdc/cWt/7X/LB+sdhC0/nYW0HRlln8R8Geo6djWN3jVl3f80rvbC6nH +c81kKi+DLmSXzvh5ClevJwcn73fuXL3GSi79hJFlqMOuM1+6RjPBHIR8+sBv45pQ0fF ZToIjt7Z3MkHFTccPC1eZ5xNtel7ssUWRwpcgJ9GRPBny/tCl919glB2plukpxQtn5FB W6qhrp15ODQUv9Wrba4ePE/mjLY4cGkluEqQN9nxshypjBbob+2NVlJsLX8PBVWZY+11 AtRG89ZmQWonI3dLHBMQL0PJPxV09Nd7qg6QUgbs4QONvgJBic3uWUzdxt0h5eqkRGJY XJpQ== X-Received: by 10.180.206.202 with SMTP id lq10mr4196253wic.44.1413450412962; Thu, 16 Oct 2014 02:06:52 -0700 (PDT) Received: from [192.168.1.104] (IGLD-84-228-54-205.inter.net.il. [84.228.54.205]) by mx.google.com with ESMTPSA id ll20sm1221333wic.14.2014.10.16.02.06.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 16 Oct 2014 02:06:52 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_B77931FF-DE2F-49F0-8F7B-5476A13A305F" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Yoav Nir In-Reply-To: Date: Thu, 16 Oct 2014 12:06:50 +0300 Message-Id: <56FAD230-A7EE-4A8D-822F-6FE255028F29@gmail.com> References: To: Fahima Ahmed Khan Etha X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/GvT1CXklOmBWcayqRNNgcWIp8UY Cc: saag@ietf.org Subject: Re: [saag] How to find out if you are really Hacked or not X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 09:06:57 -0000 --Apple-Mail=_B77931FF-DE2F-49F0-8F7B-5476A13A305F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 =93Hack=94 is kind of a meaningless term. People use it to describe = anything from writing some piece of code in an interesting way, to = writing the same piece of code quickly, to breaking through some = defence. The usual thing some =93hacker group=94 might mean is either website = defacement (that=92s easy enough to check for) or stealing information = out of a database (harder to detect) or changing information in a = database (can maybe detected by comparing with backup copies). Rarely = they manage to change code, but defacing and stealing information are = the most common. HTH Yoav On Oct 16, 2014, at 7:09 AM, Fahima Ahmed Khan Etha = wrote: > Dear All, >=20 > It might be an off topic. But I am seeking guidance from all of you. >=20 > If any hacker group claimed that you are hacked... How to proof or = find out its authenticity? >=20 > Please share your view. >=20 > Best regards, > Fahima >=20 --Apple-Mail=_B77931FF-DE2F-49F0-8F7B-5476A13A305F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 =93Hack=94= is kind of a meaningless term. People use it to describe anything from = writing some piece of code in an interesting way, to writing the same = piece of code quickly, to breaking through some = defence.

The usual thing some =93hacker group=94 = might mean is either website defacement (that=92s easy enough to check = for) or stealing information out of a database (harder to detect) or = changing information in a database (can maybe detected by comparing with = backup copies). Rarely they manage to change code, but defacing and = stealing information are the most = common.

HTH

Yoav

On Oct 16, 2014, at 7:09 AM, Fahima Ahmed Khan Etha = <etha4u@gmail.com> = wrote:

Dear All,

It might be an off topic. But I am = seeking guidance from all of you.

If any hacker group claimed that you are = hacked... How to proof or find out its authenticity?

Please share your view.

Best regards,

Fahima


= --Apple-Mail=_B77931FF-DE2F-49F0-8F7B-5476A13A305F-- From nobody Thu Oct 16 07:35:26 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 714161A1B01 for ; Thu, 16 Oct 2014 07:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEXcw6vvSGnV for ; Thu, 16 Oct 2014 07:35:20 -0700 (PDT) Received: from mail-yh0-x22c.google.com (mail-yh0-x22c.google.com [IPv6:2607:f8b0:4002:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 807AC1A1A7F for ; Thu, 16 Oct 2014 07:35:20 -0700 (PDT) Received: by mail-yh0-f44.google.com with SMTP id i57so2024385yha.31 for ; Thu, 16 Oct 2014 07:35:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TDht8Li03lArc/3/mEPrtrjlSpeGJSuwFWJqiLQA9fI=; b=d9jV3qJk3t8Fx70Jt6BCQ0pFiSke0ZTdCdOGuTLOzDs8++lIMXEMnRBBi4ZRJIwfmO HQMxYF16JFNJf4/v6elwEv6Bq4gZIbV1r3Ij2WL9blT/Z0PLQoHvEPoKO+5p0yz8btby CiTFZW6m1SnWT/BrPu4JDTuhvVhg67d4/P6774Z76RpH1RJfN2/CDJFSEVuqVirG+Opt sEygwYUdToI5MxQ8msadr12O9mLuXjDYvRp3BR9fC6W7Y9dmxDe+lfYHP5CnbJF2OEop anRsTrsNZubHQt1yLWAMy14wZiYCfAlb7zW9EYmlIZLnrPv/lFUh/HMsCt2FYg/QasZk oe2Q== MIME-Version: 1.0 X-Received: by 10.236.207.164 with SMTP id n24mr2012493yho.17.1413470119845; Thu, 16 Oct 2014 07:35:19 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Thu, 16 Oct 2014 07:35:19 -0700 (PDT) In-Reply-To: <06f201cfe8ea$6f5f94c0$4e1ebe40$@augustcellars.com> References: <06f201cfe8ea$6f5f94c0$4e1ebe40$@augustcellars.com> Date: Thu, 16 Oct 2014 07:35:19 -0700 Message-ID: From: Watson Ladd To: Jim Schaad Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/ngjb-s0EiwQN-zYZ2-bLf4r92g8 Cc: "saag@ietf.org" Subject: Re: [saag] POODLE avant le chein X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 14:35:24 -0000 On Wed, Oct 15, 2014 at 7:39 PM, Jim Schaad wrote: > > >> -----Original Message----- >> From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Watson Ladd >> Sent: Tuesday, October 14, 2014 6:21 PM >> To: saag@ietf.org >> Subject: [saag] POODLE avant le chein >> >> Dear all, >> >> Now that we've all disabled SSLv3 on every machine in reach, let's review >> when this attack was discovered. Not in 2014, but in 2001: It's in > Vaudenay, >> section 5, applied to randomized padding in SSHv2, where it was fixed. > Credit >> belongs to Luca Bruno for pointing this out on Twitter. >> >> No one took the time to sit down with a copy of the paper and a copy of > the >> spec, and compare them until now. I should have, but didn't. >> TLS isn't alone in this regard: I spent quite a bit of time trying to > understand >> which way CMS composes encryption and authentication, and gave up in >> frustration reading the pile of RFCs. (The answer I believe is that CMS > does >> not use a MAC by default: there is a different content type that does > support >> AES-GCM, but I have no idea how often it is used. People more familiar > than I >> am with S/MIME should chime >> in.) > > S/MIME is not going to be affected by this since it has never been updated > to use authenticated encryption algorithms So, what is the actual security S/MIME provides? It's probably violates several assumptions about the authenticity of messages, by not authenticating ciphertext, and has plaintext revealing padding oracles as a result. Add it to the list of protocols that need fixing. PGP is already on it: that checksummed message format is weird, and MACs then encrypts. > > CMS has defined an AEAD structure to be used with authenticated algorithms. > The only algorithms currently defined are AES-CCM, AES-GCM and RFC 6476. > The first two don't use CBC so are not affected. The last one does encrypt > then MAC so that the entire encryption stream is MAC-ed. My understanding > is that this means that it should not be an issue as the pad is covered by > the MAC value. This understanding is correct. But the fact that there is an option where there is no MAC means we have a problem. The issue is not that SSL is 18 years old. The issue is that we have known for over a decade that many of the design choices were dangerous, that due to interop problems clients still had to support it, and did exactly nothing. This isn't isolated to TLS: OpenPGP is a similarly strange design. What will stop the IETF from making the same mistakes again? (Why "before the dog"? Because the attack was described in Vaudenay, 2001, long before it got the name POODLE. That's right: the most-read crypto paper in the world had an attack that no one realized was in there.) > > Jim > >> >> What other protocols have random padding in CBC mode after a MAC? Is >> there any way to determine this beyond asking everyone to help, dividing > up >> a list of nearly 8,000 RFCs, and looking at them all? And perhaps most >> importantly, what process changes will prevent known attacks from >> surprising us in the future? >> >> There's also a question about how conservative we need to be when doing >> new cryptographic protocols. But that's a more challenging one. >> >> Sincerely, >> Watson Ladd >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Thu Oct 16 07:39:30 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D9101A1B25 for ; Thu, 16 Oct 2014 07:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R433xjXYM6tr for ; Thu, 16 Oct 2014 07:39:23 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78A7C1A1AF2 for ; Thu, 16 Oct 2014 07:39:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1413470362; x=1445006362; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=CZWHoLQGS2qZvLK4abdbtq646iR1kHgZ8V9tK3G2AcU=; b=ZrVt8RbSgjh/mCTkpBnMIi6Wbpc3XrE179BzNoOxrA0rAAbNBJ1yqMST 0jUxKcf7Gp38t1KLHwU2+io7s/SB0i8Y3Oibys0lT/tGuW5E/6QxtEPEp UrJFZcoEd9q1nUIVtBpJ4Dgm/7N2R6fFBufiDj50Gu4N2qKuB1Aa5f8/K 0=; X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="283674310" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 17 Oct 2014 03:39:20 +1300 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.70]) by uxchange10-fe3.UoA.auckland.ac.nz ([130.216.4.125]) with mapi id 14.03.0174.001; Fri, 17 Oct 2014 03:39:20 +1300 From: Peter Gutmann To: "saag@ietf.org" Thread-Topic: [saag] POODLE avant le chein Thread-Index: Ac/pTvhqKQU2heiWR1ahK+2dfnEpaQ== Date: Thu, 16 Oct 2014 14:39:20 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9CD352@uxcn10-tdc05.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/7BEdb5IfzR03U5Dex92N4OARljQ Subject: Re: [saag] POODLE avant le chein X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 14:39:27 -0000 Watson Ladd writes:=0A= =0A= >So, what is the actual security S/MIME provides? It's probably violates=0A= >several assumptions about the authenticity of messages, by not authenticat= ing=0A= >ciphertext, and has plaintext revealing padding oracles as a result.=0A= =0A= You'd have to work pretty hard to create an implementation of a store-and-= =0A= forward protocol that could be used as a padding oracle.=0A= =0A= Peter.= From nobody Thu Oct 16 07:43:09 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3651F1A1BB7 for ; Thu, 16 Oct 2014 07:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SS9UiitJjl7A for ; Thu, 16 Oct 2014 07:43:01 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C57831A1BB5 for ; Thu, 16 Oct 2014 07:42:45 -0700 (PDT) Received: by mail-ig0-f181.google.com with SMTP id r10so3583721igi.2 for ; Thu, 16 Oct 2014 07:42:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=YHVjBC76kdR5NlwWdSnviOuHKvBs1R1LelXfLAIwnhU=; b=GT8XJmP9HhmeIX1L5TRVC+C1bYlUIroIHPU7Auc2uEW4r1Rh6x9oghhNs6YlJy4pmW eQm9fDwbsaUa0gSgpqpf7gtYcG4/2XECYncNXQeIgh/CrP8KEvoSwVrwZzhSl8b9BZzh k7gnwCvtrLuOc1lE4HMjGzPvgS8LORGuJ1JpUPP8e3mKwX9mEVuNx5j5LFQsH0rWgduz h1EurU6hfZ7AnDheEbRJuNs3CezBf3+HXZo44kRwHAT3+7rdnn36FQxvtBEdUl6P7rM9 Dodg8JwYY4KXc1ITA/YnogTDBTPGxDCkZjTQMOBdpy8RbES1relQPbqnCwTmDFgb7pzB xhrg== MIME-Version: 1.0 X-Received: by 10.42.21.19 with SMTP id i19mr4478199icb.37.1413470565266; Thu, 16 Oct 2014 07:42:45 -0700 (PDT) Received: by 10.107.3.87 with HTTP; Thu, 16 Oct 2014 07:42:45 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9CCD93@uxcn10-tdc05.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C739B9CCD93@uxcn10-tdc05.UoA.auckland.ac.nz> Date: Thu, 16 Oct 2014 10:42:45 -0400 Message-ID: From: Jeffrey Walton To: saag@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/N0KYQ0OlIdYSQf8UA5r1anNoV1o Subject: Re: [saag] getting rid of fairly old stuff (was: Re: POODLE avant le chein) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: noloader@gmail.com List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 14:43:04 -0000 On Thu, Oct 16, 2014 at 4:28 AM, Peter Gutmann wrote: > Stephen Farrell writes: > >>And just to clarify, my question isn't really about TLS, but about whether >>there's an IETF thing to be done here that might help. (And the answer for >>now is I'm not sure.) > > I realise I'm slightly biased on this issue since I'm the author of the RFC, > but getting RFC 7366, "Encrypt-then-MAC for Transport Layer Security (TLS) and > Datagram Transport Layer Security (DTLS)", adopted as a matter of priority > would by a good start, that'd make 10-15 years of these attacks go away pretty > quickly. +1 From nobody Thu Oct 16 08:06:59 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8816D1A1BCD for ; Thu, 16 Oct 2014 08:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9KFf0DiSFq6g for ; Thu, 16 Oct 2014 08:06:52 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C9F11A1A75 for ; Thu, 16 Oct 2014 08:06:51 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id pn19so3084871lab.0 for ; Thu, 16 Oct 2014 08:06:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=+7p5x6k0qpgHPH1f/syTp0KMPX7lQk0+GwT1c7X7F68=; b=OpDoQ5HKb3yx6axWZUmM+a67F7oD63w2gn6JvfKFeECZMY1ZL29yFoYI6Stz5jx1Is DN+9jKLl0ITHmVWNAAmx5yZ1u18oNoukIV7w9l6OkNTKRcS/PH3z4bnkRk5M6rzsT0LF YIoiEwNB19+pu77nWhOLrpjT05OXL7JB6tnrOqIwxrSnMwpBAxVAXY8PNlRnod8ods+t 2dUUoXGcT7CPPGxEokOgkoS8cZyIarcjm4auLSiMrv45YBlKtjRy48P8Snd8RvAD+0pR knYz6xNvWEHLIP7qzRie/6UOxrQi+2aDrNCXDteSUEryZ9yR6UXSwOacqISQzm1Xg8Mj 4Qug== X-Received: by 10.112.97.135 with SMTP id ea7mr2361036lbb.46.1413472010360; Thu, 16 Oct 2014 08:06:50 -0700 (PDT) MIME-Version: 1.0 Sender: mdchalmers@gmail.com Received: by 10.25.216.138 with HTTP; Thu, 16 Oct 2014 08:06:29 -0700 (PDT) In-Reply-To: References: <06f201cfe8ea$6f5f94c0$4e1ebe40$@augustcellars.com> From: Matthew Chalmers Date: Thu, 16 Oct 2014 10:06:29 -0500 X-Google-Sender-Auth: UkzOhs01Vz7fcmAujmXgHP2eXow Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=001a1133cede13dca505058b9917 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/m4z2b6A8C8w246mkXClpn9nCSBA Cc: "saag@ietf.org" Subject: Re: [saag] POODLE avant le chein X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 15:06:56 -0000 --001a1133cede13dca505058b9917 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 'Avant' is usually for the physical meaning of before; a better phrase might be "Plus t=C3=B4t que le chien." On Thu, Oct 16, 2014 at 9:35 AM, Watson Ladd wrote: > On Wed, Oct 15, 2014 at 7:39 PM, Jim Schaad > wrote: > > > > > >> -----Original Message----- > >> From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Watson Ladd > >> Sent: Tuesday, October 14, 2014 6:21 PM > >> To: saag@ietf.org > >> Subject: [saag] POODLE avant le chein > >> > >> Dear all, > >> > >> Now that we've all disabled SSLv3 on every machine in reach, let's > review > >> when this attack was discovered. Not in 2014, but in 2001: It's in > > Vaudenay, > >> section 5, applied to randomized padding in SSHv2, where it was fixed. > > Credit > >> belongs to Luca Bruno for pointing this out on Twitter. > >> > >> No one took the time to sit down with a copy of the paper and a copy o= f > > the > >> spec, and compare them until now. I should have, but didn't. > >> TLS isn't alone in this regard: I spent quite a bit of time trying to > > understand > >> which way CMS composes encryption and authentication, and gave up in > >> frustration reading the pile of RFCs. (The answer I believe is that CM= S > > does > >> not use a MAC by default: there is a different content type that does > > support > >> AES-GCM, but I have no idea how often it is used. People more familiar > > than I > >> am with S/MIME should chime > >> in.) > > > > S/MIME is not going to be affected by this since it has never been > updated > > to use authenticated encryption algorithms > > So, what is the actual security S/MIME provides? It's probably > violates several assumptions about the authenticity of messages, by > not authenticating ciphertext, and has plaintext revealing padding > oracles as a result. Add it to the list of protocols that need fixing. > PGP is already on it: that checksummed message format is weird, and > MACs then encrypts. > > > > CMS has defined an AEAD structure to be used with authenticated > algorithms. > > The only algorithms currently defined are AES-CCM, AES-GCM and RFC 6476= . > > The first two don't use CBC so are not affected. The last one does > encrypt > > then MAC so that the entire encryption stream is MAC-ed. My > understanding > > is that this means that it should not be an issue as the pad is covered > by > > the MAC value. > > This understanding is correct. But the fact that there is an option > where there is no MAC means we have a problem. > > The issue is not that SSL is 18 years old. The issue is that we have > known for over a decade that many of the design choices were > dangerous, that due to interop problems clients still had to support > it, and did exactly nothing. This isn't isolated to TLS: OpenPGP is a > similarly strange design. What will stop the IETF from making the same > mistakes again? > > (Why "before the dog"? Because the attack was described in Vaudenay, > 2001, long before it got the name POODLE. That's right: the most-read > crypto paper in the world had an attack that no one realized was in > there.) > > > > > Jim > > > >> > >> What other protocols have random padding in CBC mode after a MAC? Is > >> there any way to determine this beyond asking everyone to help, dividi= ng > > up > >> a list of nearly 8,000 RFCs, and looking at them all? And perhaps most > >> importantly, what process changes will prevent known attacks from > >> surprising us in the future? > >> > >> There's also a question about how conservative we need to be when doin= g > >> new cryptographic protocols. But that's a more challenging one. > >> > >> Sincerely, > >> Watson Ladd > >> > >> _______________________________________________ > >> saag mailing list > >> saag@ietf.org > >> https://www.ietf.org/mailman/listinfo/saag > > > > > > -- > "Those who would give up Essential Liberty to purchase a little > Temporary Safety deserve neither Liberty nor Safety." > -- Benjamin Franklin > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --001a1133cede13dca505058b9917 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
'Avant' is usually for the physical meaning of bef= ore; a better phrase might be "Plus t=C3=B4t que le chien."
=

On Thu, Oct 16, 2= 014 at 9:35 AM, Watson Ladd <watsonbladd@gmail.com> wrot= e:
On Wed, Oct 15, 2014 at 7:39 PM, Jim Schaad <ietf@augustcellars.com> wrote:
>
>
>> -----Original Message-----
>> From: saag [mailto:saag-b= ounces@ietf.org] On Behalf Of Watson Ladd
>> Sent: Tuesday, October 14, 2014 6:21 PM
>> To: saag@ietf.org
>> Subject: [saag] POODLE avant le chein
>>
>> Dear all,
>>
>> Now that we've all disabled SSLv3 on every machine in reach, l= et's review
>> when this attack was discovered. Not in 2014, but in 2001: It'= s in
> Vaudenay,
>> section 5, applied to randomized padding in SSHv2, where it was fi= xed.
> Credit
>> belongs to Luca Bruno for pointing this out on Twitter.
>>
>> No one took the time to sit down with a copy of the paper and a co= py of
> the
>> spec, and compare them until now. I should have, but didn't. >> TLS isn't alone in this regard: I spent quite a bit of time tr= ying to
> understand
>> which way CMS composes encryption and authentication, and gave up = in
>> frustration reading the pile of RFCs. (The answer I believe is tha= t CMS
> does
>> not use a MAC by default: there is a different content type that d= oes
> support
>> AES-GCM, but I have no idea how often it is used. People more fami= liar
> than I
>> am with S/MIME should chime
>> in.)
>
> S/MIME is not going to be affected by this since it has never been upd= ated
> to use authenticated encryption algorithms

So, what is the actual security S/MIME provides? It's proba= bly
violates several assumptions about the authenticity of messages, by
not authenticating ciphertext, and has plaintext revealing padding
oracles as a result. Add it to the list of protocols that need fixing.
PGP is already on it: that checksummed message format is weird, and
MACs then encrypts.
>
> CMS has defined an AEAD structure to be used with authenticated algori= thms.
> The only algorithms currently defined are AES-CCM, AES-GCM and RFC 647= 6.
> The first two don't use CBC so are not affected.=C2=A0 The last on= e does encrypt
> then MAC so that the entire encryption stream is MAC-ed.=C2=A0 My unde= rstanding
> is that this means that it should not be an issue as the pad is covere= d by
> the MAC value.

This understanding is correct. But the fact that there is an option<= br> where there is no MAC means we have a problem.

The issue is not that SSL is 18 years old. The issue is that we have
known for over a decade that many of the design choices were
dangerous, that due to interop problems clients still had to support
it, and did exactly nothing. This isn't isolated to TLS: OpenPGP is a similarly strange design. What will stop the IETF from making the same
mistakes again?

(Why "before the dog"? Because the attack was described in Vauden= ay,
2001, long before it got the name POODLE. That's right: the most-read crypto paper in the world had an attack that no one realized was in
there.)

>
> Jim
>
>>
>> What other protocols have random padding in CBC mode after a MAC? = Is
>> there any way to determine this beyond asking everyone to help, di= viding
> up
>> a list of nearly 8,000 RFCs, and looking at them all? And perhaps = most
>> importantly, what process changes will prevent known attacks from<= br> >> surprising us in the future?
>>
>> There's also a question about how conservative we need to be w= hen doing
>> new cryptographic protocols. But that's a more challenging one= .
>>
>> Sincerely,
>> Watson Ladd
>>
>> _______________________________________________
>> saag mailing list
>> saag@ietf.org
>> https://www.ietf.org/mailman/listinfo/saag
>



--
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither=C2=A0 Liberty nor Safety."
-- Benjamin Franklin

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

--001a1133cede13dca505058b9917-- From nobody Thu Oct 16 08:13:10 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7C8F1A1BF5 for ; Thu, 16 Oct 2014 08:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNVH1kp3vfUw for ; Thu, 16 Oct 2014 08:13:03 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1C0F1A1BE8 for ; Thu, 16 Oct 2014 08:13:03 -0700 (PDT) Received: by mail-ig0-f179.google.com with SMTP id h18so3643403igc.6 for ; Thu, 16 Oct 2014 08:13:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=QmQLImWKwtZZ9R3EnnL/VDb9De8vEKon6bW1XL5vOEw=; b=Vrmi/thse0Oa9uJSJDZYeIyYUR8wKldcejK5wA5+OdUvcc3j23tJBwPcZmYqvGKqrR TXbh2IpNdDwz0DzRlX6PLc3QauT+Rg5kv53zFzfmZLyyTPVOYpXb2v8kBKd+i+Vm0Iqe ONy+psg7VxF425eUcLZ5/yVT2EusxhvvBX1azavaqGnkSYmlhJKyA5WB8PH7P49ij97b EyGr2mGAi7O6k/sDC0uXGXSc2vLbCnVEv4ovVx01JRLehPkYF5fCJ3Z77AMwoikSl5Ff jAptTlTBm8uerzY4di8HFlf/CliZbcu6awNZGzCEeKeMdpBJeVq64oO4J+yanCCvXV9K gMGg== X-Received: by 10.50.129.1 with SMTP id ns1mr5737009igb.48.1413472383073; Thu, 16 Oct 2014 08:13:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.172.212 with HTTP; Thu, 16 Oct 2014 08:12:42 -0700 (PDT) In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C739B9CCD93@uxcn10-tdc05.UoA.auckland.ac.nz> From: Ira McDonald Date: Thu, 16 Oct 2014 11:12:42 -0400 Message-ID: To: noloader@gmail.com, Ira McDonald Content-Type: multipart/alternative; boundary=047d7b2e094b4b048405058baf87 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/7UYEYVkJHhCN9-Wvq_dkBKVHkr4 Cc: "saag@ietf.org" Subject: Re: [saag] getting rid of fairly old stuff (was: Re: POODLE avant le chein) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 15:13:06 -0000 --047d7b2e094b4b048405058baf87 Content-Type: text/plain; charset=UTF-8 Hi, +1 Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 On Thu, Oct 16, 2014 at 10:42 AM, Jeffrey Walton wrote: > On Thu, Oct 16, 2014 at 4:28 AM, Peter Gutmann > wrote: > > Stephen Farrell writes: > > > >>And just to clarify, my question isn't really about TLS, but about > whether > >>there's an IETF thing to be done here that might help. (And the answer > for > >>now is I'm not sure.) > > > > I realise I'm slightly biased on this issue since I'm the author of the > RFC, > > but getting RFC 7366, "Encrypt-then-MAC for Transport Layer Security > (TLS) and > > Datagram Transport Layer Security (DTLS)", adopted as a matter of > priority > > would by a good start, that'd make 10-15 years of these attacks go away > pretty > > quickly. > > +1 > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --047d7b2e094b4b048405058baf87 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

+1

Cheers,
- Ir= a


Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Tru= sted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
= Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Int= ernet Printing Protocol WG
IETF Designated Expert - IPP & Printer MI= B
Blue Roof Music / High North Inc
http:= //sites.google.com/site/blueroofmusic
ht= tp://sites.google.com/site/highnorthinc
mailto: blueroofmusic@gmail.com
Win= ter=C2=A0 579 Park Place=C2=A0 Saline, MI=C2=A0 48176=C2=A0 734-944-0094Summer=C2=A0 PO Box 221=C2=A0 Grand Marais, MI 49839=C2=A0 906-494-2434

On Thu, Oct 16, 2014 at 10:42 AM, Jeffrey Wa= lton <noloader@gmail.com> wrote:
On Thu, Oct 16, 2014 at 4:28 AM, Peter Gutmann
<pgut001@cs.auckland.ac.nz<= /a>> wrote:
> Stephen Farrell <steph= en.farrell@cs.tcd.ie> writes:
>
>>And just to clarify, my question isn't really about TLS, but ab= out whether
>>there's an IETF thing to be done here that might help. (And the= answer for
>>now is I'm not sure.)
>
> I realise I'm slightly biased on this issue since I'm the auth= or of the RFC,
> but getting RFC 7366, "Encrypt-then-MAC for Transport Layer Secur= ity (TLS) and
> Datagram Transport Layer Security (DTLS)", adopted as a matter of= priority
> would by a good start, that'd make 10-15 years of these attacks go= away pretty
> quickly.

+1

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

--047d7b2e094b4b048405058baf87-- From nobody Thu Oct 16 08:33:14 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA221A1BE7 for ; Thu, 16 Oct 2014 08:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.938 X-Spam-Level: X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9STDWlVwOJK for ; Thu, 16 Oct 2014 08:33:11 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 289841A1BAE for ; Thu, 16 Oct 2014 08:33:11 -0700 (PDT) Received: from mail-yh0-f49.google.com (mail-yh0-f49.google.com [209.85.213.49]) by mrelayeu.kundenserver.de (node=mreue005) with ESMTP (Nemesis) id 0M6ym1-1YPcP33FB7-00wkTO; Thu, 16 Oct 2014 17:33:09 +0200 Received: by mail-yh0-f49.google.com with SMTP id a41so2072201yho.8 for ; Thu, 16 Oct 2014 08:33:07 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.236.108.164 with SMTP id q24mr2382849yhg.131.1413473587660; Thu, 16 Oct 2014 08:33:07 -0700 (PDT) Received: by 10.170.194.15 with HTTP; Thu, 16 Oct 2014 08:33:07 -0700 (PDT) In-Reply-To: References: Date: Thu, 16 Oct 2014 17:33:07 +0200 Message-ID: From: Bodo Moeller To: IETF Security Area Advisory Group Content-Type: multipart/alternative; boundary=001a11c1c9fc17a87205058bf7e3 X-Provags-ID: V02:K0:BuOe9PlUlvXGTKqi1HsEPGJWL10AdkRzLHji5aXZ5ou ZJrt0z+OfwofRFVDRsP+dOg5eSXYn+8J+FxKQRnhgZFd3iLWjn U/mMEKLn6nswMiK0zIN+4tejunVxJdoAeTmtAmId37X7cJncYs TqKbUb4h3iPwJAtPU2vvBFGa93gT56EfeFuUGhVALDZQOt8O6X 7WN5A87A4+L463IBAK0gLFP0gQgZ/QyWl5kk3QCwxCa6dwtlgW bxigsUT+W2qkSFbwE0fx5Hx1CR0kRR0zh40+4nkzPcFOq+VrcJ cRYxY9B7hkTP2SjTUSbyMbs8zXTK1/LvZUWNS0KzT91BQMiGII 1f+9ZsqHkdRon7cN5iY/TsVgvs57fcHgwmxEnjqDHEGIiACp/z 98oc6yy5EOyWSxiPGK8YiqfLbIqM33STlgzasX86ceNm5jKpME y2lzj X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/saag/xV-5twIlV_keALjv7k9ymU86u5Q Subject: Re: [saag] POODLE avant le chein X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 15:33:13 -0000 --001a11c1c9fc17a87205058bf7e3 Content-Type: text/plain; charset=UTF-8 Watson Ladd : Now that we've all disabled SSLv3 on every machine in reach, let's > review when this attack was discovered. Not in 2014, but in 2001: It's > in Vaudenay, section 5, applied to randomized padding in SSHv2, where > it was fixed. Credit belongs to Luca Bruno for pointing this out on > Twitter. > Your references leave something to be desired ... what exactly do you mean by "Vaudenay, 2001" (aka "the most-read crypto paper in the world") and what is its section 5? I'm guessing that you mean "CBC Padding: Security Flaws in SSL, IPSEC, WTLS, ...", but at least the 2001 version doesn't appear to mention SSH at all. That said, certainly the observation that SSL 3.0 padding is cryptographically weak is not new (and all padding attacks ultimately go back to Serge). The "POODLE" paper is all about lifting the known weakness to fully recovering cookies or passwords, using BEAST techniques. What can I say, the POODLE attack didn't really surprise me. Bodo --001a11c1c9fc17a87205058bf7e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Wats= on Ladd <watsonbladd@gmail.com>:

Now that we've all disabled SSLv3 on every machine in reach, let's<= br> review when this attack was discovered. Not in 2014, but in 2001: It's<= br> in Vaudenay, section 5, applied to randomized padding in SSHv2, where
it was fixed. Credit belongs to Luca Bruno for pointing this out on
Twitter.

Your references leave somethin= g to be desired ... what exactly do you mean by "Vaudenay, 2001" = (aka "the = most-read=C2=A0crypto paper in the world") and what is its section 5? I'm = guessing that you mean "CBC Pa= dding: Security Flaws in SSL, IPSEC, WTLS, ...", but at least the 2001= version doesn't appear to mention SSH at all.

That sa= id, certainly the observation that SSL 3.0 padding is cryptographically wea= k is not new (and all padding attacks=C2=A0ultimately go back to Serge).=C2=A0The "POODLE"= ; paper is all about lifting the known weakness to fully recovering cookies= or passwords, using=C2=A0BEAST techniques. What can I say, the POODLE attack didn&= #39;t really surprise me.

Bodo
--001a11c1c9fc17a87205058bf7e3-- From nobody Thu Oct 16 09:50:33 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBD901A0113 for ; Thu, 16 Oct 2014 09:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAHT5ipNUwOM for ; Thu, 16 Oct 2014 09:50:26 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A33BE1A0121 for ; Thu, 16 Oct 2014 09:50:25 -0700 (PDT) Received: from [IPv6:::1] (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 947DD6D812; Thu, 16 Oct 2014 12:50:22 -0400 (EDT) Message-ID: <543FF74D.1060700@iang.org> Date: Thu, 16 Oct 2014 17:50:21 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag@ietf.org References: <9A043F3CF02CD34C8E74AC1594475C739B9CCD93@uxcn10-tdc05.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9CCD93@uxcn10-tdc05.UoA.auckland.ac.nz> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/OTQDHwvxIcIHTXj8Ns7U0dfxPQ0 Subject: Re: [saag] getting rid of fairly old stuff (was: Re: POODLE avant le chein) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 16:50:29 -0000 On 16/10/2014 09:28 am, Peter Gutmann wrote: > Stephen Farrell writes: > >> And just to clarify, my question isn't really about TLS, but about whether >> there's an IETF thing to be done here that might help. (And the answer for >> now is I'm not sure.) > > I realise I'm slightly biased on this issue since I'm the author of the RFC, > but getting RFC 7366, "Encrypt-then-MAC for Transport Layer Security (TLS) and > Datagram Transport Layer Security (DTLS)", adopted as a matter of priority > would by a good start, that'd make 10-15 years of these attacks go away pretty > quickly. quote: The use of extensions precludes use with SSL 3.0, but then it's likely that anything still using that protocol, which is nearly two decades old, will be vulnerable to any number of other attacks anyway, so there seems little point in bending over backwards to accommodate SSL 3.0. You're showing those unfortunate biases again, Peter! iang From nobody Wed Oct 22 05:59:21 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C8441A8BC4 for ; Wed, 22 Oct 2014 05:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6SIMb_rcPv86 for ; Wed, 22 Oct 2014 05:59:18 -0700 (PDT) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5964C1A8AFE for ; Wed, 22 Oct 2014 05:59:18 -0700 (PDT) Received: by mail-lb0-f178.google.com with SMTP id w7so2795845lbi.37 for ; Wed, 22 Oct 2014 05:59:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=TqXmL8YtXGF4P14H5k+9Ago2CrWV+agvH/t/LTbMi40=; b=PnGgtv837i+7kdBac2FQUEFLwx6baHKpqq6CXEvAOVioQMfMt8+JvRiCTH4vscIWYM kkHyaTjV5D0eOVmqm/Yh+qTd0Wh9YxgCgIHhfuRo0X1TnLwDmZ8fYAABRPJWN/4ySRWK 9egeBjgKmoksGm5+pDptTBRZdidrnHgT/8WJjbuUTKbVSqZdfOLiZmtBIbO3N7OLmUb3 1LvToTXGMcpWrxB7l1XVSP4mnp0JC56+cnroG2BXMkFXilp6nu0hVW5lzo/fnQlkrVXQ mFKzTYZLzuiHUWlkuRdoK/48N+XNH7Gs2+8BXLZOQThi+dj0jRxTS/EGMh4BwVaVd03g ObQQ== MIME-Version: 1.0 X-Received: by 10.152.87.171 with SMTP id az11mr2620461lab.97.1413982756300; Wed, 22 Oct 2014 05:59:16 -0700 (PDT) Received: by 10.112.95.36 with HTTP; Wed, 22 Oct 2014 05:59:16 -0700 (PDT) Date: Wed, 22 Oct 2014 08:59:16 -0400 Message-ID: From: Kathleen Moriarty To: "saag@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/YJo-qDUXC4vZXaSSPfddhlk1okE Subject: [saag] ISOC blog on Internet governance X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 12:59:20 -0000 Kathy Brown posted the following blog to provide an update on the ITU Plenipotentiary and Internet governance. It's worth a read: http://www.internetsociety.org/blog/public-policy/2014/10/road-busan -- Best regards, Kathleen & Stephen From nobody Sun Oct 26 08:36:57 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B93DE1A890F; Sun, 26 Oct 2014 08:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CrjRf-pWqC-R; Sun, 26 Oct 2014 08:36:50 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 961681A0081; Sun, 26 Oct 2014 08:36:50 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 7B10D509B5; Sun, 26 Oct 2014 11:36:49 -0400 (EDT) Message-ID: <544D14C8.4070604@seantek.com> Date: Sun, 26 Oct 2014 08:35:36 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: pkix@ietf.org, saag@ietf.org References: <540E0A56.7060301@seantek.com> In-Reply-To: <540E0A56.7060301@seantek.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/HF4oJKV3mdXK-PXcghSXC4CC9j0 Subject: Re: [saag] [pkix] New Version Notification for draft-seantek-certfrag-00.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 15:36:52 -0000 Just wanted to follow up on this request for feedback/review for draft-seantek-certfrag, which defines fragment identifiers for certificates. This is a short draft (just four pages--and the fourth page is just the author info). If you read it and don't find any issues, please let me know as well. Thanks, Sean On 9/8/2014 12:58 PM, Sean Leonard wrote: Hello PKIX and SAAG lists: Based on discussions had at IETF 90, I have written up a new Internet-Draft to define URI fragment identifiers for certificates. The proposal is very simple, as there are only a limited number of well-defined PKIX certificate parts. This text is a spinoff of draft-seantek-certspec, since the fragment definitions depend on the media type (application/pkix-cert), not on the URI scheme or other parts. Feedback is appreciated. Sean ************************* A new version of I-D, draft-seantek-certfrag-00.txt has been successfully submitted by Sean Leonard and posted to the IETF repository. Name: draft-seantek-certfrag Revision: 00 Title: URI Fragment Identifiers for the application/pkix-cert Media Type Document date: 2014-09-08 Group: Individual Submission Pages: 4 URL: http://www.ietf.org/internet-drafts/draft-seantek-certfrag-00.txt Status: https://datatracker.ietf.org/doc/draft-seantek-certfrag/ Htmlized: http://tools.ietf.org/html/draft-seantek-certfrag-00 Abstract: This memo describes Uniform Resource Identifier (URI) fragment identifiers for PKIX certificates, which are identified with the Internet media type application/pkix-cert. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Mon Oct 27 10:03:50 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB19C1A1B9E for ; Mon, 27 Oct 2014 10:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IL8hmGTLVI5A; Mon, 27 Oct 2014 10:03:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB711A1F20; Mon, 27 Oct 2014 10:03:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: ietf-dane@dukhovni.org, draft-dukhovni-opportunistic-security@tools.ietf.org, saag@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027170304.7843.25034.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 10:03:04 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/saag/6gCxsuvTY7TZyt6AtdVxqjBYHAw Subject: [saag] ID Tracker State Update Notice: X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 17:03:48 -0000 IESG state changed to Last Call Requested from IESG Evaluation - Defer::AD Followup ID Tracker URL: http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ From nobody Mon Oct 27 10:04:22 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86D001A1BF9; Mon, 27 Oct 2014 10:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id co6aTZLAbTBM; Mon, 27 Oct 2014 10:04:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB2E1A0105; Mon, 27 Oct 2014 10:03:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: ietf-dane@dukhovni.org, iesg-secretary@ietf.org, iesg@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org, saag@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027170334.6068.9151.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 10:03:34 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/saag/FbT55M5qEOTV8nqRZAsyJ5lRZXI Subject: [saag] Telechat update notice: X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 17:04:19 -0000 Telechat date has been changed to 2014-11-25 from 2014-09-18 ID Tracker URL: http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ From nobody Mon Oct 27 10:16:08 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC0A1A6FF1 for ; Mon, 27 Oct 2014 10:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfFw7PVjkFEA; Mon, 27 Oct 2014 10:15:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 81E0B1A6F8E; Mon, 27 Oct 2014 10:14:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: ietf-dane@dukhovni.org, draft-dukhovni-opportunistic-security@tools.ietf.org, saag@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027171422.6947.7715.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 10:14:22 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/saag/fkMpSZe-_N6vq4oKJyEQSLoWH4w Subject: [saag] ID Tracker State Update Notice: X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 17:15:59 -0000 Last call has been made for draft-dukhovni-opportunistic-security and state has been changed to In Last Call ID Tracker URL: http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ From nobody Mon Oct 27 17:10:21 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECE741A1B39 for ; Mon, 27 Oct 2014 17:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K_YA16HE0cgZ for ; Mon, 27 Oct 2014 17:10:14 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id AC7B31A012D for ; Mon, 27 Oct 2014 17:10:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 96F29BE1D; Tue, 28 Oct 2014 00:10:11 +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 H9WyWqqOTZZ9; Tue, 28 Oct 2014 00:10:09 +0000 (GMT) Received: from [10.87.48.12] (unknown [86.46.26.9]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2AA56BDCF; Tue, 28 Oct 2014 00:10:09 +0000 (GMT) Message-ID: <544EDEE1.7090208@cs.tcd.ie> Date: Tue, 28 Oct 2014 00:10:09 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "saag@ietf.org" References: <20141026231606.32240.5984.idtracker@ietfa.amsl.com> In-Reply-To: <20141026231606.32240.5984.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/fkWeGIpx1HL7F55jf2X1YM21jfs Cc: draft-farrelll-mpls-opportunistic-encrypt@tools.ietf.org Subject: [saag] FW: New Version Notification for draft-farrelll-mpls-opportunistic-encrypt-03.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 00:10:18 -0000 Hiya, The Farrelll twins have been playing with the concept of opportunistic encryption for MPLS. This is very much positioned as an experiment. We'd like to hear from people who are interested in this as an idea we should look into further. And, of course, we'd love to discuss the ideas in the draft. Adrian and Stephen PS: A similar message has been sent to the mpls wg list. Feel free to discuss using whichever venue is best, but please try cc the draft alias above as we're not both subscribed to both lists;-) > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: 26 October 2014 23:16 > To: Adrian Farrel; Stephen Farrell; Adrian Farrel; Stephen Farrell > Subject: New Version Notification for draft-farrelll-mpls-opportunistic-encrypt- > 03.txt > > > A new version of I-D, draft-farrelll-mpls-opportunistic-encrypt-03.txt > has been successfully submitted by Adrian Farrel and posted to the > IETF repository. > > Name: draft-farrelll-mpls-opportunistic-encrypt > Revision: 03 > Title: Opportunistic Security in MPLS Networks > Document date: 2014-10-26 > Group: Individual Submission > Pages: 30 > URL: http://www.ietf.org/internet-drafts/draft-farrelll-mpls-opportunistic- > encrypt-03.txt > Status: https://datatracker.ietf.org/doc/draft-farrelll-mpls-opportunistic- > encrypt/ > Htmlized: http://tools.ietf.org/html/draft-farrelll-mpls-opportunistic-encrypt- > 03 > Diff: http://www.ietf.org/rfcdiff?url2=draft-farrelll-mpls-opportunistic- > encrypt-03 > > Abstract: > This document describes a way to apply opportunistic security > between adjacent nodes on an MPLS Label Switched Path (LSP) or > between end points of an LSP. It explains how keys may be agreed > to enable encryption, and how key identifiers are exchanged in > encrypted MPLS packets. Finally, this document describes the > applicability of this approach to opportunistic security in MPLS > networks with an indication of the level of improved security as > well as the continued vulnerabilities. > > This document does not describe security for MPLS control plane > protocols. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat From nobody Mon Oct 27 19:44:49 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8ED1A1B60 for ; Mon, 27 Oct 2014 19:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKurBY53G4OG for ; Mon, 27 Oct 2014 19:44:46 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B07F1A1B74 for ; Mon, 27 Oct 2014 19:44:46 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1Xiwm1-00083M-Dh; Tue, 28 Oct 2014 02:44:41 +0000 Date: Tue, 28 Oct 2014 11:44:40 +0900 Message-ID: From: Randy Bush To: Stephen Farrell In-Reply-To: <544EDEE1.7090208@cs.tcd.ie> References: <20141026231606.32240.5984.idtracker@ietfa.amsl.com> <544EDEE1.7090208@cs.tcd.ie> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/saag/FQC6EVjHC9Q4RwmZHEISoYNs8ls Cc: draft-farrelll-mpls-opportunistic-encrypt@tools.ietf.org, saag Subject: Re: [saag] FW: New Version Notification for draft-farrelll-mpls-opportunistic-encrypt-03.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 02:44:48 -0000 trying to put a P in mpls-based VNs, eh? a bit of porcine maquillage. shame lsps are only protected against wiretap on the hop. but better then running nekkid, i guess. go for it. randy From nobody Wed Oct 29 06:19:14 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E16991A00B2 for ; Wed, 29 Oct 2014 06:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.122 X-Spam-Level: X-Spam-Status: No, score=0.122 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gy5gTRtJ2WCG for ; Wed, 29 Oct 2014 06:19:10 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73DA41A0095 for ; Wed, 29 Oct 2014 06:19:10 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id q1so2493120lam.38 for ; Wed, 29 Oct 2014 06:19:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=2u1bvcheDWU71TGvaaqeYwJ/JsAO8hoOSPSzX0czqbI=; b=QlJZ3Bx2QCARxwzuAvl53z60aupvcI24DYRLIAsU35J2i7/8udknEdjXSSp2WR7AtF 647ln+Us4Lu6Y36eDbmR5JfdLEk0Bmjxxc9hub96OM/l+GwXyN0TWX+KTh/Ihc8WOSKx myxlRyyNmlT0ogdHh3br9WwJxemWzFVXyKF5VxqjGXC457Wvitmr4Ysi8a9RTKrxB5ee TwI8rK8MU4FsyBMi+xl3qzF9763BUFDpfqRQa40eGLtyUH/h1WsuWbajokrN/6EHk3c7 REM7sDxubUlgVjvUpUnkvYI1JAH0ggL7OHQBPaeL7UfLjavY9+SL31+Abb71NnNKJZ6c kF7A== MIME-Version: 1.0 X-Received: by 10.152.234.136 with SMTP id ue8mr11322911lac.21.1414588748505; Wed, 29 Oct 2014 06:19:08 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.214.163 with HTTP; Wed, 29 Oct 2014 06:19:08 -0700 (PDT) In-Reply-To: <543E992C.7000802@cs.tcd.ie> References: <543E5B35.5000604@iang.org> <543E992C.7000802@cs.tcd.ie> Date: Wed, 29 Oct 2014 09:19:08 -0400 X-Google-Sender-Auth: LIYS9TNon8m98Q-c6kI-erxFAzA Message-ID: From: Phillip Hallam-Baker To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/rC5Qb9xAonz8ijRHnUOtOO6Ffz0 Cc: "saag@ietf.org" Subject: Re: [saag] getting rid of fairly old stuff (was: Re: POODLE avant le chein) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 13:19:12 -0000 On Wed, Oct 15, 2014 at 11:56 AM, Stephen Farrell wrote: > > > On 15/10/14 16:46, Kathleen Moriarty wrote: >> Thanks for the article, it looks like the major browser vendors are already >> working together, no surprise there, but a big thanks to each of them as >> that's probably the best way to tackle this (from my experience). > > Hopefully so, and good to see the browsers and some large > server sites moving. > > If they can now get rid of SSLv3 within say a couple of months, > (and I hope they can), then we should maybe be asking ourselves > if we (the IETF) can help 'em somehow not let such stuff linger > for so long in future. Not sure how, but say if we'd published > an "SSLv3 considered possibly harmful" RFC about 8 years after > RFC 2246 was published, do we think that might have helped, or > might an equivalent help in future? Looking about randomly, I > see TLS1.1 is 8 years old now:-) > > And just to clarify, my question isn't really about TLS, but > about whether there's an IETF thing to be done here that might > help. (And the answer for now is I'm not sure.) We don't have any maintenance processes other than letting the specification rot for a decade then digging it up and seeing if we can bring it back to life. Note also the rather peculiar dichotomy in the DPRIVE work versus the TLS group. In DPRIVE we are being told 'just use DTLS' and in TLS we have 'time to redesign from the ground up'. I think we need a more modular approach. At the moment we have IPSEC and TLS and they both have a key agreement scheme. Why are these different? Do the security issues for key agreement change depending on what level you work at? We need a key agreement at the application layer for Web services as well. But we don't have one right now. Rather than doing TLS 2.0 as just a continuation of TLS/1.1, I would like to see us split TLS into two separate problems, a key agreement part which is a general purpose module that can be reused everywhere and a packaging part that applies a prenegotiated key to transport protocol. Then we would have a part that applies the prenegotiated key to packets (i.e. IPsec 2.0) and HTTP sessions. From nobody Wed Oct 29 06:24:42 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 945351A00B9 for ; Wed, 29 Oct 2014 06:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PwmFf2yA0TFd for ; Wed, 29 Oct 2014 06:24:38 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C4441A00B0 for ; Wed, 29 Oct 2014 06:24:38 -0700 (PDT) Received: by mail-lb0-f179.google.com with SMTP id w7so2455047lbi.10 for ; Wed, 29 Oct 2014 06:24:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=NASJEwNXiLRrwnzfmxBImTgWYQ6Fu/77iV3YGaXTRBo=; b=XsJCmzXg1VTo9CroOsAzh05H98HnjMqXZleCxAs95Jnlmr0/ZEr8fFH8gqWQLdmVJG JPWiGGKekh1QhE5r2XIvI7+/FK7Np9VvN0LP0DWn29RnJ17hsasSSFtNfVNk/Wdd8Gou /sdMYsG18qjGS6+SkTk0AmTsdoF4ehZAHed5jQjXgRJvJpZ0OfUYF1nGb6X3n8CGDkg1 fnSSe3HQG3VwSV16+qj3l8KOl/obAITDBxCSY47FL8u3jE+oxXHYHzi6aB/G+I+I02f9 WUo6J4usMKOY00BCWSDMQgXlUo3FKTvOlkiCXL8zExwa6eeOgaq1gjVvj57cVJ2DVp8z U1+Q== MIME-Version: 1.0 X-Received: by 10.112.162.105 with SMTP id xz9mr11202915lbb.49.1414589076108; Wed, 29 Oct 2014 06:24:36 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.214.163 with HTTP; Wed, 29 Oct 2014 06:24:36 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9CCD93@uxcn10-tdc05.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C739B9CCD93@uxcn10-tdc05.UoA.auckland.ac.nz> Date: Wed, 29 Oct 2014 09:24:36 -0400 X-Google-Sender-Auth: Uskmr3NAOaxNtNFAZP6ClsUj74Q Message-ID: From: Phillip Hallam-Baker To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/4CPqDsPSXep-6kcz08Z39LsyxYU Cc: "saag@ietf.org" Subject: Re: [saag] getting rid of fairly old stuff (was: Re: POODLE avant le chein) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 13:24:40 -0000 On Thu, Oct 16, 2014 at 4:28 AM, Peter Gutmann wrote: > Stephen Farrell writes: > >>And just to clarify, my question isn't really about TLS, but about whether >>there's an IETF thing to be done here that might help. (And the answer for >>now is I'm not sure.) > > I realise I'm slightly biased on this issue since I'm the author of the RFC, > but getting RFC 7366, "Encrypt-then-MAC for Transport Layer Security (TLS) and > Datagram Transport Layer Security (DTLS)", adopted as a matter of priority > would by a good start, that'd make 10-15 years of these attacks go away pretty > quickly. What the draft does not state is what the security concerns are. And this worries me because I remember that when MAC-then-Encrypt was selected it was because people suggested there were vague security concerns about doing the reverse. Are we really getting more security or are we just swapping one set of issues for another? From nobody Wed Oct 29 06:31:28 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB551A00E0 for ; Wed, 29 Oct 2014 06:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Uy5XdpOz3Mj for ; Wed, 29 Oct 2014 06:31:25 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 07D5B1A00D4 for ; Wed, 29 Oct 2014 06:31:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 57B9CBE0F; Wed, 29 Oct 2014 13:31:24 +0000 (GMT) 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 FK9xHGr9oPDu; Wed, 29 Oct 2014 13:31:24 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 344E0BE0D; Wed, 29 Oct 2014 13:31:24 +0000 (GMT) Message-ID: <5450EC2C.8000102@cs.tcd.ie> Date: Wed, 29 Oct 2014 13:31:24 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <543E5B35.5000604@iang.org> <543E992C.7000802@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/LrZHTpJrszU3kd-EfEJlylxbXVw Cc: "saag@ietf.org" Subject: Re: [saag] getting rid of fairly old stuff X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 13:31:26 -0000 Hiya, On 29/10/14 13:19, Phillip Hallam-Baker wrote: > We don't have any maintenance processes other than letting the > specification rot for a decade then digging it up and seeing if we can > bring it back to life. > > Note also the rather peculiar dichotomy in the DPRIVE work versus the > TLS group. In DPRIVE we are being told 'just use DTLS' and in TLS we > have 'time to redesign from the ground up'. Well, DPRIVE may end up having a similar discussion as will happen in TCPINC; that is, whether to re-use (D)TLS or to do a new thing (tcpcrypt-like in the TCPINC case). > > > I think we need a more modular approach. At the moment we have IPSEC > and TLS and they both have a key agreement scheme. Why are these > different? Do the security issues for key agreement change depending > on what level you work at? > > We need a key agreement at the application layer for Web services as > well. But we don't have one right now. One data point there: I'm told that the webpush WG [1] will define a thing like that with a real chance of being widely deployed, which could be interesting. S. [1] https://datatracker.ietf.org/wg/webpush/charter/ > > > Rather than doing TLS 2.0 as just a continuation of TLS/1.1, I would > like to see us split TLS into two separate problems, a key agreement > part which is a general purpose module that can be reused everywhere > and a packaging part that applies a prenegotiated key to transport > protocol. Then we would have a part that applies the prenegotiated key > to packets (i.e. IPsec 2.0) and HTTP sessions. From nobody Wed Oct 29 06:45:46 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6CF1A00EF for ; Wed, 29 Oct 2014 06:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wSUfIgm5QfFO for ; Wed, 29 Oct 2014 06:45:43 -0700 (PDT) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D751D1A00ED for ; Wed, 29 Oct 2014 06:45:42 -0700 (PDT) Received: by mail-yk0-f173.google.com with SMTP id 131so1282977ykp.18 for ; Wed, 29 Oct 2014 06:45:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fdLDv2OT7TDZE1c7zOkNLWa6x1ejohwZvCBPUBihjyo=; b=tBGQe5mnOEOoBhaI+1Y3coVPryUKP//pU5NSxovv70I0DEsEn2XmWVn6cTCKaFctoG uH4AgeGIrGLdYOjP8N1SMgbfuitOhnYMAaTAbo4rvsypmYour+cELCnCnITZumjfQPjd 4HQkfSFyR3VyeqCb27UdYUlX8qTVN1coHagvOoG4y73QipRo5vfK5otxjnolmGsgehI1 q58lF8IphsaKaYGLVhS4wmIjMCd6mzyn/DgQLj5FDxyNBg/Ofm1eHOg78ectXpaiZpR/ kznOvbGMyqZxXWiOmELKwBtD+HDT9W/ICsJRAR4kZKTNScvKl01HZdI58RNyTkiV/0FK wPCg== MIME-Version: 1.0 X-Received: by 10.236.7.52 with SMTP id 40mr1259830yho.172.1414590342060; Wed, 29 Oct 2014 06:45:42 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Wed, 29 Oct 2014 06:45:42 -0700 (PDT) In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C739B9CCD93@uxcn10-tdc05.UoA.auckland.ac.nz> Date: Wed, 29 Oct 2014 06:45:42 -0700 Message-ID: From: Watson Ladd To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/zrmmZmssOYDxfaeu__9K1zsnCiU Cc: "saag@ietf.org" Subject: Re: [saag] getting rid of fairly old stuff (was: Re: POODLE avant le chein) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 13:45:45 -0000 On Wed, Oct 29, 2014 at 6:24 AM, Phillip Hallam-Baker wrote: > On Thu, Oct 16, 2014 at 4:28 AM, Peter Gutmann > wrote: >> Stephen Farrell writes: >> >>>And just to clarify, my question isn't really about TLS, but about whether >>>there's an IETF thing to be done here that might help. (And the answer for >>>now is I'm not sure.) >> >> I realise I'm slightly biased on this issue since I'm the author of the RFC, >> but getting RFC 7366, "Encrypt-then-MAC for Transport Layer Security (TLS) and >> Datagram Transport Layer Security (DTLS)", adopted as a matter of priority >> would by a good start, that'd make 10-15 years of these attacks go away pretty >> quickly. > > > What the draft does not state is what the security concerns are. And > this worries me because I remember that when MAC-then-Encrypt was > selected it was because people suggested there were vague security > concerns about doing the reverse. They were wrong: Encrypt then MAC was always clearly satisfying the correct security definition, to the point where draft-rogaway-ipsec-comments in 1995 mentions this as a major mistake. You can read the comments here http://web.cs.ucdavis.edu/~rogaway/papers/draft-rogaway-ipsec-comments-00.txt. (Of course, the IETF has gone and made the archival version vanish in a maze of broken links) > > Are we really getting more security or are we just swapping one set of > issues for another? Read "Generic Composition Revisited" (Rogaway,Shrimpton,Namprempre, available from https://eprint.iacr.org/2014/206.pdf) Sincerely, Watson Ladd > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Wed Oct 29 07:39:31 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B17571A015B; Wed, 29 Oct 2014 07:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMmTHdILbzfg; Wed, 29 Oct 2014 07:39:26 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99B2B1A0166; Wed, 29 Oct 2014 07:39:26 -0700 (PDT) Received: from maildlpprd05.lss.emc.com (maildlpprd05.lss.emc.com [10.253.24.37]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id s9TEdFoK029007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Oct 2014 10:39:15 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com s9TEdFoK029007 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1414593557; bh=wWgfjjdfsujNo+roE+NWG+kS4QQ=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=l/b1ogkOi575+TVm/uuw2PUqxuG+Tip2pLbaEDQbfrxUVqhH2wwKilfGjr4keg+YY 0WtFa9SkMDXuH0cUk9jhdr0k3kedakZBlQaGTvW04AeAC7YY0QkVFUViZgND2JkXgJ lItlWherVCcizzpLWqOKQokPjdQI3YL9slTyp/7w= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com s9TEdFoK029007 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd05.lss.emc.com (RSA Interceptor); Wed, 29 Oct 2014 10:38:57 -0400 Received: from mxhub07.corp.emc.com (mxhub07.corp.emc.com [128.222.70.204]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id s9TEcvPI006611 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Oct 2014 10:38:57 -0400 Received: from MXHUB104.corp.emc.com (10.253.58.16) by mxhub07.corp.emc.com (128.222.70.204) with Microsoft SMTP Server (TLS) id 8.3.327.1; Wed, 29 Oct 2014 10:38:56 -0400 Received: from MX104CL02.corp.emc.com ([169.254.8.131]) by MXHUB104.corp.emc.com ([::1]) with mapi id 14.03.0195.001; Wed, 29 Oct 2014 10:38:56 -0400 From: "Black, David" To: Stephen Farrell Thread-Topic: [saag] getting rid of fairly old stuff Thread-Index: AQHP83yq6KLb2dJyCEiOqvO4jEOKW5xHIy2g Date: Wed, 29 Oct 2014 14:38:55 +0000 Message-ID: References: <543E5B35.5000604@iang.org> <543E992C.7000802@cs.tcd.ie> <5450EC2C.8000102@cs.tcd.ie> In-Reply-To: <5450EC2C.8000102@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.101] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: http://mailarchive.ietf.org/arch/msg/saag/hTInpIGNlR4BttrFSqYarPKKETI Cc: "saag@ietf.org" , "tsvwg-chairs@ietf.org" Subject: Re: [saag] getting rid of fairly old stuff X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 14:39:29 -0000 > > Note also the rather peculiar dichotomy in the DPRIVE work versus the > > TLS group. In DPRIVE we are being told 'just use DTLS' and in TLS we > > have 'time to redesign from the ground up'. >=20 > Well, DPRIVE may end up having a similar discussion as will > happen in TCPINC; that is, whether to re-use (D)TLS or to > do a new thing (tcpcrypt-like in the TCPINC case). And even 'just use DTLS' is not that simple :-( ... draft-ietf-tsvwg-sctp-dtls-encaps is effectively stalled at the moment courtesy of confusion over which version of DTLS to use for WebRTC and why. I hesitate to ask - but who in the Security Area thinks they're responsible for the Security-side aspects of resolving this confusion? Thanks, --David (as a tsvwg WG chair) > -----Original Message----- > From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Stephen Farrell > Sent: Wednesday, October 29, 2014 9:31 AM > To: Phillip Hallam-Baker > Cc: saag@ietf.org > Subject: Re: [saag] getting rid of fairly old stuff >=20 >=20 > Hiya, >=20 > On 29/10/14 13:19, Phillip Hallam-Baker wrote: > > We don't have any maintenance processes other than letting the > > specification rot for a decade then digging it up and seeing if we can > > bring it back to life. > > > > Note also the rather peculiar dichotomy in the DPRIVE work versus the > > TLS group. In DPRIVE we are being told 'just use DTLS' and in TLS we > > have 'time to redesign from the ground up'. >=20 > Well, DPRIVE may end up having a similar discussion as will > happen in TCPINC; that is, whether to re-use (D)TLS or to > do a new thing (tcpcrypt-like in the TCPINC case). >=20 > > > > > > I think we need a more modular approach. At the moment we have IPSEC > > and TLS and they both have a key agreement scheme. Why are these > > different? Do the security issues for key agreement change depending > > on what level you work at? > > > > We need a key agreement at the application layer for Web services as > > well. But we don't have one right now. >=20 > One data point there: I'm told that the webpush WG [1] will > define a thing like that with a real chance of being widely > deployed, which could be interesting. >=20 > S. >=20 > [1] https://datatracker.ietf.org/wg/webpush/charter/ >=20 > > > > > > Rather than doing TLS 2.0 as just a continuation of TLS/1.1, I would > > like to see us split TLS into two separate problems, a key agreement > > part which is a general purpose module that can be reused everywhere > > and a packaging part that applies a prenegotiated key to transport > > protocol. Then we would have a part that applies the prenegotiated key > > to packets (i.e. IPsec 2.0) and HTTP sessions. >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Wed Oct 29 08:03:11 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 724521A0248 for ; Wed, 29 Oct 2014 08:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.621 X-Spam-Level: X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6fh_cD5zXeFR for ; Wed, 29 Oct 2014 08:03:03 -0700 (PDT) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 134171A01E1 for ; Wed, 29 Oct 2014 08:02:49 -0700 (PDT) Received: by mail-qg0-f53.google.com with SMTP id z107so2350490qgd.26 for ; Wed, 29 Oct 2014 08:02:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=w0IzQMwIgdf0qtk5wgeaim5rngc/cE6Hm+UZbwqmpME=; b=Z/Mze5pg294IoTqorL+PLFcuefVTbdZuGfIV6VKMPN9bNUNrgLdM18pea2CmBnuOmQ 1G710vlkwf48Cxibx0HtDEwuP4uZWOUueiPFdme/RBYDik/+G527otNB5b3aS6NTvgDH YhIhryXSFmdQWu8pitMXQgUad4Jj5AWT0UxI5M9Ab2OF7MPOxSzK31iNWmmkJgBTagc0 4wuHxCwJ+wCC/deLy7fjuI21VKdQNcnKb5mbqYNVwYGX+jDblrv0mcZhgpf5bpQCZZ63 tUzVKqZGvUIwBOeN1U6Uapohk11hckIgFnNqKOjAPTJTVR9tGjZr7SlG6nR9IHKlTMtO JBDg== MIME-Version: 1.0 X-Received: by 10.229.183.199 with SMTP id ch7mr16606835qcb.19.1414594969287; Wed, 29 Oct 2014 08:02:49 -0700 (PDT) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.229.231.73 with HTTP; Wed, 29 Oct 2014 08:02:49 -0700 (PDT) In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C739B9CCD93@uxcn10-tdc05.UoA.auckland.ac.nz> Date: Wed, 29 Oct 2014 16:02:49 +0100 X-Google-Sender-Auth: JrCOvfiRH0JFJSEvm38Q4Y9Mfy0 Message-ID: From: Nikos Mavrogiannopoulos To: Watson Ladd Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/a2dq58fQldhyCHjCUa_XOToaMFY Cc: "saag@ietf.org" Subject: Re: [saag] getting rid of fairly old stuff (was: Re: POODLE avant le chein) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 15:03:05 -0000 On Wed, Oct 29, 2014 at 2:45 PM, Watson Ladd wrote: >>> I realise I'm slightly biased on this issue since I'm the author of the RFC, >>> but getting RFC 7366, "Encrypt-then-MAC for Transport Layer Security (TLS) and >>> Datagram Transport Layer Security (DTLS)", adopted as a matter of priority >>> would by a good start, that'd make 10-15 years of these attacks go away pretty >>> quickly. >> What the draft does not state is what the security concerns are. And >> this worries me because I remember that when MAC-then-Encrypt was >> selected it was because people suggested there were vague security >> concerns about doing the reverse. > They were wrong: Encrypt then MAC was always clearly satisfying the > correct security definition, to the point where > draft-rogaway-ipsec-comments > in 1995 mentions this as a major mistake. You can read the comments > here http://web.cs.ucdavis.edu/~rogaway/papers/draft-rogaway-ipsec-comments-00.txt. That's an interesting story, so I take the bite and continue it a bit. At the time Rogaway send these comments other cryptographers were advising otherwise. For example Ferguson and Schneier and in their "A Cryptographic Evaluation of IPsec" argued for the 'The Horton principle', i.e. "Authentication should thus be applied to the plaintext (as it is in SSL [FKK96]), and not to the ciphertext.". Moreover, few years later Krawczyk in the "The Order of Encryption and Authentication for Protecting Communications (or: How Secure Is SSL?)" proved that AtE is as good construction for practical reasons, and one shouldn't bother switching (that was also his advice to the WG chair at the moment if I remember well). What he missed though was that TLS was not doing AtE the way he assumed. That was noticed by Kenny Paterson who published "Tag Size Does Matter: Attacks and Proofs for the TLS Record Protocol", and differentiated between two AtE variants the: "Encode-then-MAC-then-Encrypt" (EME the variant refered to as AtE by Krawczyk) and "MAC-then-Encode-then-Encrypt" (MEE - the TLS variant). The story after that goes with MEE being broken for practical applications. So indeed, some cryptographers had made an argument against AtE, and based on results (the variant of AtE used in TLS is broken), they were correct. Unfortunately "correctness", can only be said today that we know that the MEE variant of AtE is broken. One cannot still argue for the EME variant of AtE (which is proven secure by Krawczyk) vs the EtA. >> Are we really getting more security or are we just swapping one set of issues for another? That's a nice question with no easy answer. Of course once you fix a known weak link, you get no guarantees about any other possible weak links. In that particular case, the encryption part is fixed, at the cost of the authentication part being in the clear. In theory it is ok as long as the MAC algorithm is considered secure. In practice we have no experience on what could happen when a MAC like HMAC-MD5 is broken. regards, Nikos From nobody Wed Oct 29 08:42:55 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01BD71A0A85 for ; Wed, 29 Oct 2014 08:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujU7_8Kd1zhP for ; Wed, 29 Oct 2014 08:42:50 -0700 (PDT) Received: from mail-yh0-x22b.google.com (mail-yh0-x22b.google.com [IPv6:2607:f8b0:4002:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A9731A06E9 for ; Wed, 29 Oct 2014 08:42:43 -0700 (PDT) Received: by mail-yh0-f43.google.com with SMTP id z6so693002yhz.16 for ; Wed, 29 Oct 2014 08:42:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qeQ7Yo4s4rYr9P/xoCcCJ/yP3dQfgOR0zrnItN4QjOs=; b=fbLF85t1585ckPPXb4QOrnMVN5+2qZYoWscXpLaAlSP/lnQn217hpHwzbVLLxGv4fD 5OnT4fd+dfeH/kaMDrC2NeW3Ta0aN0D6ojrwBDHeaF+njm55NKzEF2w51Rim9rAu7AdW g5o7yz8N2kn1TbaWn8mPMO5FZO2anCsC1E60IDJcdZq43hSNUCJkfN1T2rOjuZa4DSQT kquSKz30WWqNVASrM6MeVMYJFEm8CxpBqAzZTYjGFxtmQ4bnA2HLWwMCKEFhkhH9UXtL qEwW9YmMnQbxc8EQCqWZcTWJwnW0SKbdXXB9WneQyZvDgwIJrAAsZHaKufgLqOhEIt67 CTLA== MIME-Version: 1.0 X-Received: by 10.236.30.197 with SMTP id k45mr2072129yha.163.1414597362846; Wed, 29 Oct 2014 08:42:42 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Wed, 29 Oct 2014 08:42:42 -0700 (PDT) In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C739B9CCD93@uxcn10-tdc05.UoA.auckland.ac.nz> Date: Wed, 29 Oct 2014 08:42:42 -0700 Message-ID: From: Watson Ladd To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/VT6aQ-OyB_E3chzd04CltAktrTk Cc: "saag@ietf.org" Subject: Re: [saag] getting rid of fairly old stuff (was: Re: POODLE avant le chein) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 15:42:53 -0000 On Wed, Oct 29, 2014 at 8:02 AM, Nikos Mavrogiannopoulos wrote: > On Wed, Oct 29, 2014 at 2:45 PM, Watson Ladd wrote: > >>>> I realise I'm slightly biased on this issue since I'm the author of the RFC, >>>> but getting RFC 7366, "Encrypt-then-MAC for Transport Layer Security (TLS) and >>>> Datagram Transport Layer Security (DTLS)", adopted as a matter of priority >>>> would by a good start, that'd make 10-15 years of these attacks go away pretty >>>> quickly. >>> What the draft does not state is what the security concerns are. And >>> this worries me because I remember that when MAC-then-Encrypt was >>> selected it was because people suggested there were vague security >>> concerns about doing the reverse. >> They were wrong: Encrypt then MAC was always clearly satisfying the >> correct security definition, to the point where >> draft-rogaway-ipsec-comments >> in 1995 mentions this as a major mistake. You can read the comments >> here http://web.cs.ucdavis.edu/~rogaway/papers/draft-rogaway-ipsec-comments-00.txt. > > That's an interesting story, so I take the bite and continue it a bit. > At the time Rogaway send these comments other cryptographers were > advising otherwise. For example Ferguson and Schneier and in their "A > Cryptographic Evaluation of IPsec" argued for the 'The Horton > principle', i.e. "Authentication should thus be applied to the > plaintext (as it is in SSL [FKK96]), and not to the ciphertext.". No, they merely stated the principal, without looking at the definitions and seeing which way works. Rogaway's statement that the security was open was true. In 2000 it would be shown by Bellare and Namprempre that MAC then Encrypt with randomized schemes was not generically secure: one could provide a MAC and encryption scheme that wouldn't work when composed one way. > > Moreover, few years later Krawczyk in the "The Order of Encryption and > Authentication for Protecting Communications (or: How Secure Is SSL?)" > proved that AtE is as good construction for practical reasons, and one > shouldn't bother switching (that was also his advice to the WG chair > at the moment if I remember well). What he missed though was that TLS > was not doing AtE the way he assumed. That was noticed by Kenny > Paterson who published "Tag Size Does Matter: Attacks and Proofs for > the TLS Record Protocol", and differentiated between two AtE variants > the: "Encode-then-MAC-then-Encrypt" (EME the variant refered to as > AtE by Krawczyk) and "MAC-then-Encode-then-Encrypt" (MEE - the TLS > variant). The story after that goes with MEE being broken for > practical applications. The Krawczyk paper appeared in the same year as the Vaudenay padding attack oracle. I believe they were in the same volume of Eurocrypt proceedings, but will have to look further to confirm. Furthermore, in the ePrint version we find of Krawczyk we find. "However, we note the fragility of this last statement: very simple (seemingly innocuous) changes to the encryption function, including changes that do not influence the secrecy protection provided by the encryption when considered as a stand-alone primitive, can be fatal for the security of the implemented channels." This remark may have been added later, but certainly not much more recently. By 2003, it was clear that practical attacks on the TLS construction existed (not just due to Paterson: timing attacks are due to several different authors in addition, some of whom are cited in the TLS 1.1 RFC), and so TLS 1.1 gave advice on not leaking information through timing channels, by reducing their size. However, the assumption that this was sufficient was just wrong, and it wasn't noticed until Lucky 13, almost a decade later. But all of this applies only to TLS: OpenPGP and S/MIME never even tried to provide a composition of encrypt and MAC, and SSH also got it wrong. The knowledge of these attacks diffused very slowly through IETF standards. Even the bodo-cbc attack textfile didn't provoke action by the TLS WG: completed in 2004, one can probably still read it today and extract attacks. TLS 1.0 also got CBC encryption wrong, hence BEAST. That was published in 2004 by Bard. It shouldn't take a live demo for us to fix problems. This also isn't the only broken old thing. PKCS 1.5 encryption survives, as does PKCS 1.5 signatures. We don't know how to attack the signatures, but we do know that implementations frequently get verification wrong by parsing the result of a decryption, rather than doing the comparison properly. And the encryption is very badly weakened by Bleichenbacher style attacks. These attacks, as well as the better replacements, have been around for quite some time now, in some cases 20 or 19 years. But we still haven't fixed the root problems, and instead act surprised when we find the same bugs crop up again and again. Of course, it's not clear that we can do better: RFC 6090 was incorrect, as the formulas were not transcribed out of Chudnovosky and Chudnovosky, or Silverman and in the process were incorrect. Luckily no one actually followed that RFC. There is also the case of MD5. From the beginning, concerns were raised about the 2^64 collision search time. By 1996, collisions in the compression function were known. And then there is RC4, which finally, some 14 years after the discovery that it is distinguishable from random, we are turning off. My mutual fund still uses it though: I'll let you know when that changes. Once is an accident, twice is bad luck, but this... > > So indeed, some cryptographers had made an argument against AtE, and > based on results (the variant of AtE used in TLS is broken), they were > correct. Unfortunately "correctness", can only be said today that we > know that the MEE variant of AtE is broken. One cannot still argue for > the EME variant of AtE (which is proven secure by Krawczyk) vs the > EtA. Encrypt then MAC is generically secure: this means that if it is insecure, one of the two parts is not meeting its security goals. This cannot be said, and was not said, and isn't true, for any other possible combination. Even in "Generic Composition Revisited" one needs the encryption and decryption processes to be bijective to get anything other then Encrypt then MAC construction to be secure. The EME variant is not generically secure: one needs to know certain additional things about the encryption scheme being used. Why are we trying to save other combinations then EtA? They aren't more efficient, don't do anything EtA doesn't, and will fail in practice because of gaps between what the proofs assume and what the systems used provide, or even because of application level implementation choices. > >>> Are we really getting more security or are we just swapping one set of issues for another? > > That's a nice question with no easy answer. Of course once you fix a > known weak link, you get no guarantees about any other possible weak > links. In that particular case, the encryption part is fixed, at the > cost of the authentication part being in the clear. In theory it is ok > as long as the MAC algorithm is considered secure. In practice we have > no experience on what could happen when a MAC like HMAC-MD5 is broken. If HMAC-MD5 is completely broken, we will have to migrate away from it. But that is a simple matter of changing a ciphersuite, and we have other options, unlike this batch of bugs. At this point we will have had lots of practice. Of course, it's another month: this means another TLS problem. Sincerely, Watson Ladd > > regards, > Nikos -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Wed Oct 29 10:56:34 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E55F41A8764 for ; Wed, 29 Oct 2014 10:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQfVr45zUFdY for ; Wed, 29 Oct 2014 10:56:27 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6CB71A875D for ; Wed, 29 Oct 2014 10:56:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1414605387; x=1446141387; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=OBfB1WrCVgD8Cyb35CsnPXBNPPEYo+vqEyVL4XSBa9A=; b=TpURWx/0ZSaADGEpiyyRE3AMoMmyDBQQq7JeJQ6zHOEALrkRVtgwjldE 53Rgo86zaW/kjREUvCLPo9E0b3aHMrpYrt8LJr859qO5J7fPbW6t+vBnN yoWlp/SWDavYvq/6YsDi26Peh4fp48SMi75dlUIap4yLOKu5sXIPd649b o=; X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="286462993" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 30 Oct 2014 06:56:25 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.15]) by uxchange10-fe2.UoA.auckland.ac.nz ([169.254.27.86]) with mapi id 14.03.0174.001; Thu, 30 Oct 2014 06:56:24 +1300 From: Peter Gutmann To: "saag@ietf.org" Thread-Topic: [saag] getting rid of fairly old stuff (was: Re: POODLE avant le chein) Thread-Index: Ac/zoacX8k+4NekBSwmiqI7q5DaPHA== Date: Wed, 29 Oct 2014 17:56:23 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9DB5D1@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/2VFUS7UP5tgIlcTn--ayfFamAkU Subject: Re: [saag] getting rid of fairly old stuff (was: Re: POODLE avant le chein) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 17:56:31 -0000 Watson Ladd writes:=0A= =0A= >But all of this applies only to TLS: OpenPGP and S/MIME never even tried t= o=0A= >provide a composition of encrypt and MAC, and SSH also got it wrong.=0A= =0A= Minor nit: S/MIME (or at least CMS) does do encrypt-then-MAC, see RFC 6476.= =0A= PGP uses its own oddball encrypt-the-hash mechanism (yuck), and SSH still= =0A= resolutely sticks to MAC-then-encrypt. I tried to get it changed but got= =0A= brushed off, and after the battle over getting it fixed in TLS I just didn'= t=0A= feel like having the same fight over SSH as well.=0A= =0A= Peter.= From nobody Wed Oct 29 12:00:34 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE261ACE62 for ; Mon, 27 Oct 2014 09:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G0AKG5UmGoL9; Mon, 27 Oct 2014 09:01:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9851ACE50; Mon, 27 Oct 2014 09:01:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: ietf-dane@dukhovni.org, draft-dukhovni-opportunistic-security@tools.ietf.org, saag@ietf.org, stephen.farrell@cs.tcd.ie, ted.lemon@nominum.com, presnick@qti.qualcomm.com, barryleiba@computer.org, alissa@cooperw.in X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027160133.21431.94569.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 09:01:33 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/bDMJNAdbU5IEFt9m5Jf21DKerCg X-Mailman-Approved-At: Wed, 29 Oct 2014 12:00:26 -0700 Subject: [saag] New Version Notification - draft-dukhovni-opportunistic-security-05.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 16:02:00 -0000 A new version (-05) has been submitted for draft-dukhovni-opportunistic-security: http://www.ietf.org/internet-drafts/draft-dukhovni-opportunistic-security-05.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-dukhovni-opportunistic-security-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Wed Oct 29 17:26:13 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF9941ACE49 for ; Wed, 29 Oct 2014 17:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMdqCCSzLMZl for ; Wed, 29 Oct 2014 17:26:09 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA4071ACE47 for ; Wed, 29 Oct 2014 17:26:08 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 5CCA86D798; Wed, 29 Oct 2014 20:26:03 -0400 (EDT) Message-ID: <5451859B.7050202@iang.org> Date: Thu, 30 Oct 2014 00:26:03 +0000 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag@ietf.org References: <9A043F3CF02CD34C8E74AC1594475C739B9CCD93@uxcn10-tdc05.UoA.auckland.ac.nz> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/7MdCmwoNX736jF7UxdSORSAtacs Subject: Re: [saag] getting rid of fairly old stuff (was: Re: POODLE avant le chein) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 00:26:10 -0000 On 29/10/2014 13:24 pm, Phillip Hallam-Baker wrote: > On Thu, Oct 16, 2014 at 4:28 AM, Peter Gutmann > wrote: >> Stephen Farrell writes: >> >>> And just to clarify, my question isn't really about TLS, but about whether >>> there's an IETF thing to be done here that might help. (And the answer for >>> now is I'm not sure.) >> >> I realise I'm slightly biased on this issue since I'm the author of the RFC, >> but getting RFC 7366, "Encrypt-then-MAC for Transport Layer Security (TLS) and >> Datagram Transport Layer Security (DTLS)", adopted as a matter of priority >> would by a good start, that'd make 10-15 years of these attacks go away pretty >> quickly. > > > What the draft does not state is what the security concerns are. And > this worries me because I remember that when MAC-then-Encrypt was > selected it was because people suggested there were vague security > concerns about doing the reverse. > > Are we really getting more security or are we just swapping one set of > issues for another? My personal thought on this is that y'all are banging on the stable door while the horse took off a few years back. If we knew where it was, we wouldn't want it back anyway, the poor nag's almost dead. Encryption architecture has moved on from the late 1990s days of block cipher + mode + padding + HMAC. Although it wasn't clear at the time, it is now very clear that the cryptographers threw these things over the wall, leaving the software engineers to plug them together like lego or constructor kit (meccano if elsewhere). Since then, some time around mid 2000s, there has been a realisation that the product has to be shipped back to cryptographers for repair. The thing we want now is an authenticated encryption stream cipher. Which means, it's up to the cryptographer to decide whether it is encrypt-then-MAC or the reverse, converse, inverse, or perverse. What he says, we do. Which in practical terms means we are in a three phase approach. 1. lead all the lemmings suites to the cliff, pied piper mode. 2. switch to ChaCha20/Poly1305 as a holding pattern. 3. wait until CAESAR and implement the better one of that set. iang From nobody Wed Oct 29 20:29:10 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 490841ACFC5 for ; Wed, 29 Oct 2014 20:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6amPVBh2PF_M for ; Wed, 29 Oct 2014 20:29:08 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8F511ACD0C for ; Wed, 29 Oct 2014 20:29:07 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLB96025; Thu, 30 Oct 2014 03:29:06 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 30 Oct 2014 03:29:05 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.21]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Thu, 30 Oct 2014 11:28:59 +0800 From: "Songhaibin (A)" To: "saag@ietf.org" Thread-Topic: Router backdoor threat model Thread-Index: Ac/z8aS1WbXpFLzVTQeO7I4nW5Oj5w== Date: Thu, 30 Oct 2014 03:28:59 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.49] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/saag/_OO_gPmohWICdpX-o9IPY4i_2r4 Subject: [saag] Router backdoor threat model X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 03:29:09 -0000 Hi, We have submitted a draft on router backdoor threat model. The main target = is the threat model at the beginning. We would like to see if there are peo= ple interested in this work. Any related discussion in the list or with the= authors is welcome : ) http://www.ietf.org/id/draft-song-router-backdoor-00.txt Best Regards! -Haibin From nobody Wed Oct 29 22:31:51 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AEEC1AD012 for ; Wed, 29 Oct 2014 22:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84e0endhG4nQ for ; Wed, 29 Oct 2014 22:31:49 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6BF91AD00E for ; Wed, 29 Oct 2014 22:31:48 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id h11so6357764wiw.12 for ; Wed, 29 Oct 2014 22:31:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=85bezrjBtft57tjyLYZVnFqoyAP34V5G2+slNnrwkqM=; b=h8GicOG5P+xwAQFb8vgTQ/FSW4Z3+EKFjSULzAa/gnjFmF2YTletChI/hJJUCBpWaE s4UhbUThuu2HFp8/R9oYVPNEOgPgrm3zIWBNkG3WlAe0aOUis6dVJEdnmZJmFbGZQOtE Q8XOqVQ+GdIJ8jpWgbckQnCSYlrc0Xd4ahNRRxwDE/Zh+a+Uy5+6l98g0ge1AhUSnCSq pxkoZCvrEY+VQSDU11eSXsK2rrqJ6B1Z5EaNjxze2Ts8SsVIlcAD9vp0V0TuoflmIpTs GA0XQTWEroIX7RtYhAw2OnkyGTctQ4ETOocFEhztvAJhrMJfQC861lc4EBL7FBmhDXo9 KyRw== X-Received: by 10.180.74.76 with SMTP id r12mr24818583wiv.6.1414647107354; Wed, 29 Oct 2014 22:31:47 -0700 (PDT) Received: from [192.168.1.104] (IGLD-84-228-87-161.inter.net.il. [84.228.87.161]) by mx.google.com with ESMTPSA id bq8sm7433423wjb.6.2014.10.29.22.31.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 Oct 2014 22:31:46 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Yoav Nir In-Reply-To: <5451859B.7050202@iang.org> Date: Thu, 30 Oct 2014 07:31:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9A043F3CF02CD34C8E74AC1594475C739B9CCD93@uxcn10-tdc05.UoA.auckland.ac.nz> <5451859B.7050202@iang.org> To: ianG X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/hnonvmt07kTJ7HaEL_quBmsuASY Cc: saag@ietf.org Subject: Re: [saag] getting rid of fairly old stuff (was: Re: POODLE avant le chein) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 05:31:50 -0000 > On Oct 30, 2014, at 2:26 AM, ianG wrote: >=20 > On 29/10/2014 13:24 pm, Phillip Hallam-Baker wrote: >> On Thu, Oct 16, 2014 at 4:28 AM, Peter Gutmann >> wrote: >>> Stephen Farrell writes: >>>=20 >>>> And just to clarify, my question isn't really about TLS, but about = whether >>>> there's an IETF thing to be done here that might help. (And the = answer for >>>> now is I'm not sure.) >>>=20 >>> I realise I'm slightly biased on this issue since I'm the author of = the RFC, >>> but getting RFC 7366, "Encrypt-then-MAC for Transport Layer Security = (TLS) and >>> Datagram Transport Layer Security (DTLS)", adopted as a matter of = priority >>> would by a good start, that'd make 10-15 years of these attacks go = away pretty >>> quickly. >>=20 >>=20 >> What the draft does not state is what the security concerns are. And >> this worries me because I remember that when MAC-then-Encrypt was >> selected it was because people suggested there were vague security >> concerns about doing the reverse. >>=20 >> Are we really getting more security or are we just swapping one set = of >> issues for another? >=20 >=20 > My personal thought on this is that y'all are banging on the stable = door > while the horse took off a few years back. If we knew where it was, = we > wouldn't want it back anyway, the poor nag's almost dead. >=20 > Encryption architecture has moved on from the late 1990s days of block > cipher + mode + padding + HMAC. Although it wasn't clear at the time, > it is now very clear that the cryptographers threw these things over = the > wall, leaving the software engineers to plug them together like lego = or > constructor kit (meccano if elsewhere). >=20 > Since then, some time around mid 2000s, there has been a realisation > that the product has to be shipped back to cryptographers for repair. > The thing we want now is an authenticated encryption stream cipher. > Which means, it's up to the cryptographer to decide whether it is > encrypt-then-MAC or the reverse, converse, inverse, or perverse. What > he says, we do. What those cryptographers do is stick together a cipher, a mode, padding = and a MAC function and call it an authenticated encryption. How is that different from sticking together a cipher, a mode, padding = and a MAC function and calling it a =E2=80=9Cciphersuite=E2=80=9D? That = is what TLS always did, unlike IPsec that let you mix and match. IMO the decision that AEAD was TLS 1.2-only was entirely arbitrary, and = ciphersuites could have specified whatever processing we wanted them to. Yoav From nobody Thu Oct 30 08:25:04 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7913F1AD507 for ; Thu, 30 Oct 2014 08:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1zaRxmM0Htu for ; Thu, 30 Oct 2014 08:24:52 -0700 (PDT) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62D3F1AD4EB for ; Thu, 30 Oct 2014 08:24:50 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id n3so7732571wiv.14 for ; Thu, 30 Oct 2014 08:24:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=LSpnMUxPta4L/+B2u37sQCGRvv3tZlzuDlrSj1Kf74k=; b=JJbipRuAI5uOQaCvWlnLXTLQ4NMct5UV8KWet9my1qr4fIX+RS9ykQETaHRPbzuX3b 0YX5vzeYsN9j2oxHj2uQJc27w8GK0z9HctSfAkI87MgiEw+Qh1424eeOx9qwAURF1foR 0Z1d/aoC0AAM3kGRLcsQquTxC/hnQQtTmNRyD9V968ugO4oZiLaMaqzd5QeqhgEoEMVD mwLR7fYJPZSKWcK0hfO/iZk0iXm/3sPgpD2CdWFN+Zcz4GGfYbKYCcXIax4L24O8ckvp jC0HtVNvS3chNBmEkuL3QOLQF89Ixd+je4EZd3hVkU0pNmV8BB1HNwQPNEkYj3yC90QE hxjw== X-Gm-Message-State: ALoCoQkVMhkzncwpre6+XZ2o4/HmOprKuPUSxvvjUcEWdcqyUeUF0Zk+ugXpkiYh9dd8QI1PJb4k MIME-Version: 1.0 X-Received: by 10.194.63.229 with SMTP id j5mr21438757wjs.23.1414682688910; Thu, 30 Oct 2014 08:24:48 -0700 (PDT) Received: by 10.194.77.134 with HTTP; Thu, 30 Oct 2014 08:24:48 -0700 (PDT) In-Reply-To: References: Date: Thu, 30 Oct 2014 11:24:48 -0400 Message-ID: From: Warren Kumari To: "Songhaibin (A)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/TUCsC-1CVuZ58_h2xNvL5q16OjU Cc: "saag@ietf.org" Subject: Re: [saag] Router backdoor threat model X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 15:25:00 -0000 Boggle.... W On Wed, Oct 29, 2014 at 11:28 PM, Songhaibin (A) wrote: > Hi, > > We have submitted a draft on router backdoor threat model. The main target is the threat model at the beginning. We would like to see if there are people interested in this work. Any related discussion in the list or with the authors is welcome : ) > http://www.ietf.org/id/draft-song-router-backdoor-00.txt > > Best Regards! > -Haibin > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Thu Oct 30 08:33:38 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8F5F1AD511 for ; Thu, 30 Oct 2014 08:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZ53yGOQMQLs for ; Thu, 30 Oct 2014 08:33:35 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C61D1AD506 for ; Thu, 30 Oct 2014 08:33:35 -0700 (PDT) Received: by mail-pd0-f175.google.com with SMTP id y13so5336165pdi.6 for ; Thu, 30 Oct 2014 08:33:34 -0700 (PDT) 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:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=+VT4ymGoM9j1/Ep/BZ+cLfSe2L3HRcvBYZfJvsBaNB8=; b=DrkZm5kblvmkhNDaSt0eABTFyq5mc3ct6TntN2903OUg4Rk9tA5Qv+NfE0EhYV7NRC UHVVOAslP/lus93vHdKv0462u+3JOtFozjy4D8dZqNilZ52oL3YIL6fncl8Mw5DSn4WP bmZJoGVn2LpPdrJox59XcEqgKhj/QjX2pFUP3cPVfl+z+1DkzPvq2mEUKTZqjKl94ffY Li7Jvvh+V34oy7Le1eMxIEjElCit8HlT7HkelmBlymsjEuIQXMwdkSXpbUMKHt3Q8tqy gJJU82meHdiQAfRAQbJayi0fQ6WRZDX6Gq6J8O6R80zDxM5H3FeagsRHPuupe7/xznwD 7FHw== X-Received: by 10.69.31.234 with SMTP id kp10mr7323072pbd.79.1414683214808; Thu, 30 Oct 2014 08:33:34 -0700 (PDT) Received: from Melindas-MacBook-Pro.local (50-200-68-226-static.hfc.comcastbusiness.net. [50.200.68.226]) by mx.google.com with ESMTPSA id ql6sm7453196pbb.39.2014.10.30.08.33.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 Oct 2014 08:33:33 -0700 (PDT) Message-ID: <54525A4C.9010704@gmail.com> Date: Thu, 30 Oct 2014 08:33:32 -0700 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/fMRp3Tqhes_nEPOTfn-9_3oWvfU Subject: Re: [saag] Router backdoor threat model X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 15:33:37 -0000 On 10/30/14, 8:24 AM, Warren Kumari wrote: > Boggle.... Boggle what? Melinda From nobody Thu Oct 30 11:48:08 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4AA1A01AE for ; Thu, 30 Oct 2014 11:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-lN_c67N-QT for ; Thu, 30 Oct 2014 11:48:04 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CF141A00BB for ; Thu, 30 Oct 2014 11:48:04 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 17A6B6D8EB; Thu, 30 Oct 2014 14:48:00 -0400 (EDT) Message-ID: <545287E0.1040308@iang.org> Date: Thu, 30 Oct 2014 18:48:00 +0000 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Yoav Nir References: <9A043F3CF02CD34C8E74AC1594475C739B9CCD93@uxcn10-tdc05.UoA.auckland.ac.nz> <5451859B.7050202@iang.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/O0clJy24nWiunHbt3Pu54CurTT4 Cc: saag@ietf.org Subject: Re: [saag] getting rid of fairly old stuff (was: Re: POODLE avant le chein) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 18:48:06 -0000 On 30/10/2014 05:31 am, Yoav Nir wrote: > >> On Oct 30, 2014, at 2:26 AM, ianG wrote: >> >> My personal thought on this is that y'all are banging on the stable door >> while the horse took off a few years back. If we knew where it was, we >> wouldn't want it back anyway, the poor nag's almost dead. >> >> Encryption architecture has moved on from the late 1990s days of block >> cipher + mode + padding + HMAC. Although it wasn't clear at the time, >> it is now very clear that the cryptographers threw these things over the >> wall, leaving the software engineers to plug them together like lego or >> constructor kit (meccano if elsewhere). >> >> Since then, some time around mid 2000s, there has been a realisation >> that the product has to be shipped back to cryptographers for repair. >> The thing we want now is an authenticated encryption stream cipher. >> Which means, it's up to the cryptographer to decide whether it is >> encrypt-then-MAC or the reverse, converse, inverse, or perverse. What >> he says, we do. > > What those cryptographers do is stick together a cipher, a mode, padding and a MAC function and call it an authenticated encryption. > > How is that different from sticking together a cipher, a mode, padding and a MAC function and calling it a “ciphersuite”? The 'why' and 'what' are no different, the 'who' and the 'where' is. What we're now saying is that it is a cryptographer responsibility, not a software engineer responsibility. That's because /inter alia/ software engineers aren't good at making the MAC-then-encrypt decision, whereas cryptographers have to be good at that. > That is what TLS always did, unlike IPsec that let you mix and match. ofc. And, in TLS 1.5 you won't need to do that design, you'll just need to choose one from amongst the 5 recommended set of CAESAR. Which will free up a lot of developer time to work on other things. Hallelujah! > IMO the decision that AEAD was TLS 1.2-only was entirely arbitrary, and ciphersuites could have specified whatever processing we wanted them to. The way ciphersuites have been added could be said to be arbitrary, yes. Back to the subject line: How about taking away? ;-) Here's a strawman proposal: TLS 1.5 will deprecate all but 1 suite from the TLS 1.4 set. iang ps; I might be wrong on the numbers... From nobody Thu Oct 30 13:11:30 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B14551A6F2E for ; Thu, 30 Oct 2014 13:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.356 X-Spam-Level: X-Spam-Status: No, score=0.356 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bN3QOL7-7XxL for ; Thu, 30 Oct 2014 13:11:26 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 4B2F61A6F30 for ; Thu, 30 Oct 2014 13:11:26 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTP id 9F2361E05D for ; Thu, 30 Oct 2014 13:11:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=X5KAbcdZ0bXrC+WgX7oX fcCeOjY=; b=LORoixJgZfAnBH05kGGU0KyfkF35RQvrEropwa3VUnqQYrk/HsoG ztuitHA8K6Mr4PsdZnZj9l1RU7FRyBB5rt/yAthZ8SivWASIeNrUlzJRSpcOqapp iAdIsjtQFlk0XIC/St0FY6p1DBXBNMcGIGS/ukbScohu0IxyIx7mFOY= Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTPSA id 41A961E059 for ; Thu, 30 Oct 2014 13:11:25 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id m15so5095544wgh.35 for ; Thu, 30 Oct 2014 13:11:23 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.190.130 with SMTP id gq2mr22531063wjc.18.1414699883784; Thu, 30 Oct 2014 13:11:23 -0700 (PDT) Received: by 10.216.32.135 with HTTP; Thu, 30 Oct 2014 13:11:23 -0700 (PDT) In-Reply-To: <543EA728.1020803@iang.org> References: <543E5B35.5000604@iang.org> <543E992C.7000802@cs.tcd.ie> <543EA728.1020803@iang.org> Date: Thu, 30 Oct 2014 15:11:23 -0500 Message-ID: From: Nico Williams To: ianG Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/jt19wbII1KK57JBrpI4ECkrPu-M Cc: "saag@ietf.org" Subject: Re: [saag] getting rid of fairly old stuff X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 20:11:28 -0000 I've no interest in prohibiting RC4, SSL3, at least in an oppotunistic security context where the alternative would be sending plaintext. I'm much more interested in prohibiting fallback to SSL3 in UAs, and prohibiting the use of broken protocols in required security cases (including opportunistic ones where the client securely discovers that the server can use the latest and greatest). Nico -- From nobody Fri Oct 31 09:29:59 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF981ACD01 for ; Fri, 31 Oct 2014 09:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zowpfsbCPPUd for ; Fri, 31 Oct 2014 09:29:49 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D894C1ACCFE for ; Fri, 31 Oct 2014 09:29:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 64AE6E2034; Fri, 31 Oct 2014 12:29:46 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 06099-02; Fri, 31 Oct 2014 12:29:44 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 27DD1E2031; Fri, 31 Oct 2014 12:29:44 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id s9VGThu2020868; Fri, 31 Oct 2014 12:29:43 -0400 From: Derek Atkins To: ianG References: <9A043F3CF02CD34C8E74AC1594475C739B9CCD93@uxcn10-tdc05.UoA.auckland.ac.nz> <5451859B.7050202@iang.org> <545287E0.1040308@iang.org> Date: Fri, 31 Oct 2014 12:29:43 -0400 In-Reply-To: <545287E0.1040308@iang.org> (iang@iang.org's message of "Thu, 30 Oct 2014 18:48:00 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: http://mailarchive.ietf.org/arch/msg/saag/KVTBevTpi7LtN1n-FDkzvNfClTU Cc: saag@ietf.org Subject: Re: [saag] getting rid of fairly old stuff X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 16:29:51 -0000 ianG writes: > Back to the subject line: How about taking away? ;-) Here's a strawman > proposal: > > TLS 1.5 will deprecate all but 1 suite from the TLS 1.4 set. So we'll standardize on that in about 2020, and deployment will finally get out around 2030 or so. Not too bad! :) -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Fri Oct 31 14:47:46 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2086E1A6F20 for ; Fri, 31 Oct 2014 14:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NmaqZn2nU_Ng for ; Fri, 31 Oct 2014 14:47:41 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D7E11A6F1E for ; Fri, 31 Oct 2014 14:47:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1414792060; x=1446328060; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=j39cBLVIa/82vkTAUZ9KL/4NYi6NQA/k9qIRcoq7c8k=; b=mGI9Pdqp+3D7HI32ZRqbqJpT5A/DHcMQw8ggQuM58vbBqWE80Iwlu8Fh 20QizC8MQUi8JgNKkVcdrBHhieontY1KUuyBzW1BWUJsvQ63DIlDG393p 0CwzNBUo7JzS1MuI1bAEyfFPoSGdV6O4DXLHuDtnNnvxScG0d3hcXmZmo 0=; X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="286995691" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 01 Nov 2014 10:47:37 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.15]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Sat, 1 Nov 2014 10:47:37 +1300 From: Peter Gutmann To: "saag@ietf.org" Thread-Topic: [saag] getting rid of fairly old stuff Thread-Index: Ac/1VEi1zoWm3u3aSMeERRLNqijLUw== Date: Fri, 31 Oct 2014 21:47:36 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9DD3AD@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/AQaq_7nAhs_H2Yj7rSnHpVPVJxQ Subject: Re: [saag] getting rid of fairly old stuff X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 21:47:45 -0000 Derek Atkins writes:=0A= >ianG writes:=0A= >> Back to the subject line: How about taking away? ;-) Here's a strawman= =0A= >> proposal:=0A= >>=0A= >> TLS 1.5 will deprecate all but 1 suite from the TLS 1.4 set.=0A= >=0A= >So we'll standardize on that in about 2020, and deployment will finally ge= t=0A= >out around 2030 or so. Not too bad! :)=0A= =0A= I think that's being optimistic. I don't think it'll actually be possible = to=0A= form a committee big enough to standardise TLS 1.5.=0A= =0A= Peter.= From nobody Fri Oct 31 22:13:47 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A24301A87E6 for ; Fri, 31 Oct 2014 22:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23OWkA3XEFxU for ; Fri, 31 Oct 2014 22:13:41 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AD2A1A87D7 for ; Fri, 31 Oct 2014 22:13:41 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id 10so7051064lbg.36 for ; Fri, 31 Oct 2014 22:13:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=G3+QBs5NEfce1w0gxLwquwRURIB2MJkTG32qRvxKIAg=; b=S0fsT/cs/RBhcgnq/znUBxo/D5/JnvDX9CrAtXOg507Av65QCtjjqUJdyI6jaYAdlU GLXkJ43TuymzQ5f3CjCoOfNWpZAfnKDcK7FB/LhcASibaUmqZGiG4OPBNiIZPFC/r/gW J29IfHz2vzeeWfHaakOAm0Cv1RS3UgqCbkm5WpusISPR6hWMa4tpR/vYhOD4Ywsq+7vU l38JQBf1zcBeVyd8SEUR50oNx4TK8a/fkdrwT4JXDKnDHm+Ih8MrOi1Z9G0Se6n7rNk7 3QTu6vBn7UKnzsdwbZhYrV6c6I97yheR4IMYUalbOJz+bFTM9z4F84egXZ6dhl7RFgDb 41+g== MIME-Version: 1.0 X-Received: by 10.152.27.38 with SMTP id q6mr472943lag.92.1414818819716; Fri, 31 Oct 2014 22:13:39 -0700 (PDT) Received: by 10.25.215.134 with HTTP; Fri, 31 Oct 2014 22:13:39 -0700 (PDT) In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C739B9CCD93@uxcn10-tdc05.UoA.auckland.ac.nz> <5451859B.7050202@iang.org> Date: Fri, 31 Oct 2014 22:13:39 -0700 Message-ID: From: Martin Thomson To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/J_ljHCsGaKXjvm1yHMlbB-xuZHg Cc: saag Subject: Re: [saag] getting rid of fairly old stuff (was: Re: POODLE avant le chein) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2014 05:13:43 -0000 On 29 October 2014 22:31, Yoav Nir wrote: > IMO the decision that AEAD was TLS 1.2-only was entirely arbitrary, and ciphersuites could have specified whatever processing we wanted them to. Indeed, but it is arguably a useful marker that distinguishes old from new :) From nobody Fri Oct 31 22:52:31 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5DBC1A8821 for ; Fri, 31 Oct 2014 22:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omCCdFlSbhXe for ; Fri, 31 Oct 2014 22:52:28 -0700 (PDT) Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 016561A87F1 for ; Fri, 31 Oct 2014 22:52:27 -0700 (PDT) Received: by mail-yh0-f54.google.com with SMTP id 29so3563193yhl.27 for ; Fri, 31 Oct 2014 22:52:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+kS75N/PTMCdtr+w1PLFGObRz2vtjwWhbNCf1gz9CcA=; b=pGnJovLOnRl30SKzUnu9fq3Y5qNu+jrHpDwX4B/lj069BLrvlJ2QZlg3CP+emQ/Ee4 KVcqy27JdJdrU5jih+qEDKD3uEW0xgp7xcUPmEd12W2o6vmQeZWGM9cnjoz4UuW7Xp+z OLLBXriCzYacn6vbJi47Pvb2BjHur3KNkPxqD5L4mRYQmRQTF/RZPDhkOoIoBYRpvxRy Hod9Z9cATJ8k3mCnfn2okfv4P5arCP746P+aSHD176T39+c5P9cTiY9MS4mksIAN5UCX fjIorbzNTP7COl1kQG09Q926ULOYoK/lUInmaTRZq5W27bv3TU6IHvmoTF5z1Qct4F0N atrA== MIME-Version: 1.0 X-Received: by 10.236.226.109 with SMTP id a103mr17307410yhq.21.1414821147386; Fri, 31 Oct 2014 22:52:27 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Fri, 31 Oct 2014 22:52:27 -0700 (PDT) In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C739B9CCD93@uxcn10-tdc05.UoA.auckland.ac.nz> <5451859B.7050202@iang.org> Date: Fri, 31 Oct 2014 22:52:27 -0700 Message-ID: From: Watson Ladd To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/J0KMSFEqRyecSqwUIveKCeSpV5c Cc: saag Subject: Re: [saag] getting rid of fairly old stuff (was: Re: POODLE avant le chein) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2014 05:52:29 -0000 On Fri, Oct 31, 2014 at 10:13 PM, Martin Thomson wrote: > On 29 October 2014 22:31, Yoav Nir wrote: >> IMO the decision that AEAD was TLS 1.2-only was entirely arbitrary, and ciphersuites could have specified whatever processing we wanted them to. > > Indeed, but it is arguably a useful marker that distinguishes old from new :) The important thing is to secure communications. To the extent this decision prevented adoption of the only secure ciphersuites in TLS by winding them up in a bunch of other protocol changes that didn't affect security it was a bad one. Did I say only secure one? Well, I was neglecting remote timing attacks on AES encryption discovered in 2006, exploitable on almost any system using the venerable rijndael.c, and the issues with GCM without hardware support. Writing implementations that are fast and not vulnerable is an exercise in vector unit abuse without hardware support. Sincerely, Watson Ladd > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin