From nobody Thu Jan 1 12:37:45 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2AC1A1A56; Thu, 1 Jan 2015 12:37:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.233 X-Spam-Level: X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 tTFZU5m-jDAs; Thu, 1 Jan 2015 12:37:40 -0800 (PST) Received: from homiemail-a35.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA2C1A00F7; Thu, 1 Jan 2015 12:37:40 -0800 (PST) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id F3A6F54073; Thu, 1 Jan 2015 12:37:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=0IAbHMCeSYadsS YuBU9AvueVVFI=; b=HakKlTxMtGJXW/4RO58LDyC45qsTfb/jTIkU/34pPQQrad tPFpaYUhcM3NzAGQLLKK4kwkHGM4SxoAW1+kXZRUPJr6ATWDlJd4QyAe1rg5Y6Z6 4VvLcumb98fQ1F8h9lIzuRAy2ci4MN43GB+5RbJhUKGlNYwFFP44ZmgpO4OpA= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPA id 902B354058; Thu, 1 Jan 2015 12:37:39 -0800 (PST) Date: Thu, 1 Jan 2015 14:37:39 -0600 From: Nico Williams To: Alexey Melnikov Message-ID: <20150101203734.GF24442@localhost> References: <1420033807.4638.16.camel@scientia.net> <1420042774.10106.10.camel@scientia.net> <20141231221420.GX24442@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/zPlw6hMM826HbPUcPhEEjBFjxzg Cc: "cfrg@irtf.org" , ietf@ietf.org, tls@ietf.org Subject: [TLS] Reconsider TLS/CFRG relationship (Re: should the CFRG really strive for consensus?) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jan 2015 20:37:41 -0000 [Reply-To set to tls@ietf.org.] On Thu, Jan 01, 2015 at 05:52:55PM +0000, Alexey Melnikov wrote: > > On 31 Dec 2014, at 22:14, Nico Williams wrote: [Elided here is a sub-thread about how much trouble CFRG has had making decisions, and how unsuited they are to the task. These were opinions stated by others. My response was that if CFRG can't choose, that's fine, let CFRG do what it's good at (cryptology), and let the IETF do what it's good at (engineering). For the benefit of ietf@ietf.org readers, the context is that CFRG was tasked with producing recommendations for the TLS WG, but CFRG seems mired in debate about them. From my point of view the risk is that the logjam won't soon be broken.] > > Let the IRTF publish one or more documents describing various curves > > suitable for use in Internet protocols. The IETF can pick from among > > those. > > That is not what TLS WG /SEC AD asked for. They would rather CFRG make > a choice that can be used in TLS and other places, instead of letting > each IETF WG make their own different choice. We may have to reconsider this then. If it is really true that CFRG is not adept at making choices, then let the cryptologists document algorithms (including their cryptographic attributes, pros, cons, cryptanalysis, general performance analysis, security considerations, and an overall assessment), and let the engineers pick from among them. I.e., what we've always done at the IETF. This might require some process (a call for consensus in the TLS WG?), but once done CFRG will be freed to do what it's good at, and to do it more quickly because there will be no more lengthy arguments about what to choose. Authors will publish I-Ds, reviewers will review them, and barring any serious problems, CFRG will progress those I-Ds. The TLS (and other) WGs can then choose what they like. I don't mean to start a debate about this _now_. Rather, now is the time point out that we may have to have this debate, possibly before the next time we ask the IRTF for recommendations. Nico -- From nobody Thu Jan 1 15:37:59 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C411A1B14 for ; Thu, 1 Jan 2015 15:37:57 -0800 (PST) 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 slqLIszlReI6 for ; Thu, 1 Jan 2015 15:37:55 -0800 (PST) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27F001A1B0C for ; Thu, 1 Jan 2015 15:37:55 -0800 (PST) Received: by mail-yk0-f175.google.com with SMTP id 200so8475714ykr.6 for ; Thu, 01 Jan 2015 15:37:54 -0800 (PST) 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 :content-type; bh=i9RaEC+MN/5Ev+Vhd8WWMzwvyYbl4+DR/b8lu2MvCO0=; b=wxueSamWdhZR1oSa51nCyam5LAvOj7ZT6C98Dbn8yTM3Md4q3l0Pfr/XFhJGf94GOV boL0ftyxlfCW0KeTSWAfQxOMqIwE4SAgMZqgnnTQench8yvSu8azBciiH4t5ALPl/Ihr 4YN5xaCnNQhPsVubXbBjp+rSIwYQcTt6si5yZdYXPjt/Oy1VyFFcA1c+9Fzq9FgcFhbq eg8x3z6oCpNtsWePXZczPz//8KcuNMQWKrazZAiBpiFqKxqC7LNF5DJGgB8sc449SOQc Y0QeURcqmkZ9pTI8OtSAp+Xqy7hkMJrjczc0wu3Xw3dfi7EYvsytxLJWcZByXYJfVbXB 3fXQ== MIME-Version: 1.0 X-Received: by 10.170.220.195 with SMTP id m186mr20917401ykf.58.1420155474393; Thu, 01 Jan 2015 15:37:54 -0800 (PST) Received: by 10.170.207.6 with HTTP; Thu, 1 Jan 2015 15:37:54 -0800 (PST) In-Reply-To: <20150101203734.GF24442@localhost> References: <1420033807.4638.16.camel@scientia.net> <1420042774.10106.10.camel@scientia.net> <20141231221420.GX24442@localhost> <20150101203734.GF24442@localhost> Date: Thu, 1 Jan 2015 18:37:54 -0500 Message-ID: From: Watson Ladd To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/EXQiLIi8ftx8kBqrlS_urWnb1ZM Subject: Re: [TLS] [Cfrg] Reconsider TLS/CFRG relationship (Re: should the CFRG really strive for consensus?) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jan 2015 23:37:57 -0000 On Thu, Jan 1, 2015 at 3:37 PM, Nico Williams wrote: > [Reply-To set to tls@ietf.org.] > > On Thu, Jan 01, 2015 at 05:52:55PM +0000, Alexey Melnikov wrote: >> > On 31 Dec 2014, at 22:14, Nico Williams wrote: > > [Elided here is a sub-thread about how much trouble CFRG has had making > decisions, and how unsuited they are to the task. These were opinions > stated by others. My response was that if CFRG can't choose, that's > fine, let CFRG do what it's good at (cryptology), and let the IETF do > what it's good at (engineering). > > For the benefit of ietf@ietf.org readers, the context is that CFRG was > tasked with producing recommendations for the TLS WG, but CFRG seems > mired in debate about them. From my point of view the risk is that the > logjam won't soon be broken.] Can we at least wait until next week when everyone is back to work, and not send emails to multiple mailing lists that will fracture the thread in all sorts of bad ways? > >> > Let the IRTF publish one or more documents describing various curves >> > suitable for use in Internet protocols. The IETF can pick from among >> > those. >> >> That is not what TLS WG /SEC AD asked for. They would rather CFRG make >> a choice that can be used in TLS and other places, instead of letting >> each IETF WG make their own different choice. > > We may have to reconsider this then. > > If it is really true that CFRG is not adept at making choices, then let > the cryptologists document algorithms (including their cryptographic > attributes, pros, cons, cryptanalysis, general performance analysis, > security considerations, and an overall assessment), and let the > engineers pick from among them. I.e., what we've always done at the > IETF. The IETF isn't adept at making choices either, nor is it the case that we would have an easier time of doing what was suggested as an alternative. Obviously proponents would try to ensure their work is represented in the best light, and would try very hard to muddle the issues if they had problems. The hope that some of the participants had is we would imitate the contest based model of ECRYPT and AES and SHA3. But this didn't happen for a variety of reasons too boring to go into here. > > This might require some process (a call for consensus in the TLS WG?), > but once done CFRG will be freed to do what it's good at, and to do it > more quickly because there will be no more lengthy arguments about what > to choose. Authors will publish I-Ds, reviewers will review them, and > barring any serious problems, CFRG will progress those I-Ds. The TLS > (and other) WGs can then choose what they like. There is substantially less distance between ECDH proposals at the 255 bit length then there was before. In fact, the only difference is whether the same generator as the existing Curve25519 code should be used, or not. This was not true when the original proposals were made: one group substantially modified their proposal to make it approach the other one, and did so very recently. Yes, it took us a year to decide that the original draft that kicked this off was okay. I'm not happy about it either, but it doesn't seem to have slowed down the TLS WG, which also way behind. I'd recommend seeing what happens next week, and then hitting the red button. Sincerely, Watson > > I don't mean to start a debate about this _now_. Rather, now is the > time point out that we may have to have this debate, possibly before the > next time we ask the IRTF for recommendations. > > Nico > -- > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Thu Jan 1 15:55:42 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22CD81A802A for ; Thu, 1 Jan 2015 15:55:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.233 X-Spam-Level: X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 6Du8-XVXsVsJ for ; Thu, 1 Jan 2015 15:55:39 -0800 (PST) Received: from homiemail-a55.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 581701A1AF1 for ; Thu, 1 Jan 2015 15:55:39 -0800 (PST) Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id 0505C161D; Thu, 1 Jan 2015 15:55:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=sZyxapN2UMoGgp dK930s9TzHTpg=; b=unSy72zM79hEhKvSxiU+R+iUj73iDyLjUW8akjVjlVsvCY LaiPBsWLtgLZzJNU9y2jg4BISqWpucJcDvNTGwTtKy1S0itLByzVYnnU+zSUOttE YYK0rP0Ii+yAynZxkkn92LhymY0Etp5IQrYOlLlTGk6UEzVfgBYw1ts3hleCQ= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTPA id B1743161A; Thu, 1 Jan 2015 15:55:38 -0800 (PST) Date: Thu, 1 Jan 2015 17:55:38 -0600 From: Nico Williams To: Watson Ladd Message-ID: <20150101235534.GL24442@localhost> References: <1420033807.4638.16.camel@scientia.net> <1420042774.10106.10.camel@scientia.net> <20141231221420.GX24442@localhost> <20150101203734.GF24442@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/AiIHeGWL6M-WNPPYZ5H--_aeYZ4 Cc: "tls@ietf.org" Subject: Re: [TLS] [Cfrg] Reconsider TLS/CFRG relationship (Re: should the CFRG really strive for consensus?) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jan 2015 23:55:40 -0000 On Thu, Jan 01, 2015 at 06:37:54PM -0500, Watson Ladd wrote: > On Thu, Jan 1, 2015 at 3:37 PM, Nico Williams wrote: > > Can we at least wait until next week when everyone is back to work, > and not send emails to multiple mailing lists that will fracture the > thread in all sorts of bad ways? I should have, yes. > The IETF isn't adept at making choices either, nor is it the case that > we would have an easier time of doing what was suggested as an > alternative. Obviously proponents would try to ensure their work is > represented in the best light, and would try very hard to muddle the > issues if they had problems. There are more engineers than cryptologists. It seems likely to be easier to find rough consensus among a larger group of informed participants than a smaller group (though getting 11 answers out of 10 people is always a possibility). More importantly, asking cryptologists to make decisions that the engineers could have just as well... strikes me as an inefficient use of the cryptologists' time. > The hope that some of the participants had is we would imitate the > contest based model of ECRYPT and AES and SHA3. But this didn't happen > for a variety of reasons too boring to go into here. That would have been nice. > There is substantially less distance between ECDH proposals at the 255 > bit length then there was before. [...] If I'd waited a few hours to post, and had read this mornings' posts to CFRG, I'd have realized this. My apologies. There still would have been something to say (see above), but with less urgency. > Yes, it took us a year to decide that the original draft that kicked > this off was okay. I'm not happy about it either, but it doesn't seem > to have slowed down the TLS WG, which also way behind. I'd recommend > seeing what happens next week, and then hitting the red button. Fair enough. Thanks, Nico -- From nobody Fri Jan 2 04:47:02 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEAB51A1AD9 for ; Fri, 2 Jan 2015 04:47:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.512 X-Spam-Level: X-Spam-Status: No, score=-5.512 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, 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 jIlX6K2Nt1mZ for ; Fri, 2 Jan 2015 04:46:59 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 668321A1AAF for ; Fri, 2 Jan 2015 04:46:59 -0800 (PST) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t02CkvkA003749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Fri, 2 Jan 2015 07:46:58 -0500 Received: from pintsize.usersys.redhat.com (vpn1-4-49.ams2.redhat.com [10.36.4.49]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t02CksBk007083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 2 Jan 2015 07:46:56 -0500 From: Hubert Kario To: tls@ietf.org Date: Fri, 02 Jan 2015 13:46:53 +0100 Message-ID: <2348107.Lj21YcAO1u@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.3 (Linux/3.17.4-200.fc20.x86_64; KDE/4.14.3; x86_64; ; ) In-Reply-To: <54A252EA.1010905@iki.fi> References: <54A252EA.1010905@iki.fi> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/vofyCFAiTIuGZy1hQs3hNu6Q0s0 Subject: Re: [TLS] Do we need DH? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2015 12:47:01 -0000 On Tuesday 30 December 2014 09:23:22 Tapio Sokura wrote: > With regards to all eggs being in the same basket, AES is also something > that really should have a realistic alternative standardized and > deployed _before_ (/if) AES is broken. Like SHA-3 is coming around the > corner while SHA-2 is still well alive and kicking. We do have Camellia ciphers defined, PFS AEAD included (RFC 6367). -- Regards, Hubert Kario From nobody Fri Jan 2 05:08:46 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D5A11A1B45 for ; Fri, 2 Jan 2015 05:08:25 -0800 (PST) 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 Dm9abBCquw3T for ; Fri, 2 Jan 2015 05:08:19 -0800 (PST) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A429D1A1B3E for ; Fri, 2 Jan 2015 05:08:18 -0800 (PST) Received: by mail-wg0-f52.google.com with SMTP id x12so24049481wgg.11 for ; Fri, 02 Jan 2015 05:08:10 -0800 (PST) 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=g2uGwX7L7rMiU7/b1HbQFfRL7XtyJ1+DdAO0PWvc8iA=; b=ABwvCJffKiJtImyFl39OABLFwKVkuEal3yjfRzY+MKmZ09kIYXocXk6iPZuWfHamKg mGpvemQgLMAqr+zRsvRSzR5TY8Gdkvs5lXrZ/QJSoNMBtP8kuox1a+gBI9o9iUFNue+o avKyoKcsK1gN8/ct30QvnQW7UBNa1VcJYQ+EU70XlcrkewMGWSk0GkuHj9OuZAi+Jnpw uLXpsMufWAipo7TE++ebA9DKJQWzZiJyp8qBhgaUDhutuqHpnwdulgUpbnas5P8VsyXF Qro0MEJ5XZyaaYyJf7WJXdCZGcFPmXX2silanCMYyeaISS01rg8Byn/taun/errQNBNd lH6w== X-Received: by 10.194.59.234 with SMTP id c10mr152071178wjr.49.1420204090039; Fri, 02 Jan 2015 05:08:10 -0800 (PST) Received: from [192.168.1.102] (IGLD-84-228-227-214.inter.net.il. [84.228.227.214]) by mx.google.com with ESMTPSA id u18sm64561995wjq.42.2015.01.02.05.08.08 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 02 Jan 2015 05:08:09 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Yoav Nir In-Reply-To: <2348107.Lj21YcAO1u@pintsize.usersys.redhat.com> Date: Fri, 2 Jan 2015 15:08:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54A252EA.1010905@iki.fi> <2348107.Lj21YcAO1u@pintsize.usersys.redhat.com> To: Hubert Kario X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Slc81BCQJUdbiZLNSUXYCI6pV8c Cc: tls@ietf.org Subject: Re: [TLS] Do we need DH? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2015 13:08:29 -0000 > On Jan 2, 2015, at 2:46 PM, Hubert Kario wrote: >=20 > On Tuesday 30 December 2014 09:23:22 Tapio Sokura wrote: >> With regards to all eggs being in the same basket, AES is also = something >> that really should have a realistic alternative standardized and >> deployed _before_ (/if) AES is broken. Like SHA-3 is coming around = the >> corner while SHA-2 is still well alive and kicking. >=20 >=20 > We do have Camellia ciphers defined, PFS AEAD included (RFC 6367). That, and the ChaCha20+Poly1305 AEAD will be defined when = http://tools.ietf.org/html/draft-mavrogiannopoulos-chacha-tls-04 is = adopted. Yoav From nobody Fri Jan 2 05:29:53 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E16A1A874B for ; Fri, 2 Jan 2015 05:29:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 zVms3CMSPDHL for ; Fri, 2 Jan 2015 05:29:51 -0800 (PST) Received: from entima.net (entima.net [78.129.143.175]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54E9A1A1B43 for ; Fri, 2 Jan 2015 05:29:51 -0800 (PST) In-Reply-To: References: <54A252EA.1010905@iki.fi> <2348107.Lj21YcAO1u@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Alyssa Rowan Date: Fri, 02 Jan 2015 13:29:39 +0000 To: Yoav Nir ,Hubert Kario Message-ID: <676C7631-E080-4370-ADA2-BB8BBBBB023C@akr.io> Archived-At: http://mailarchive.ietf.org/arch/msg/tls/0c1m18BzDXw2F5pAdwFOvxIaGCQ Cc: tls@ietf.org Subject: Re: [TLS] Do we need DH? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2015 13:29:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2 January 2015 13:08:07 GMT+00:00, Yoav Nir wrote: >>> With regards to all eggs being in the same basket, AES is also something that really should have a realistic alternative standardized and deployed _before_ (/if) AES is broken. Like SHA-3 is coming around the corner while SHA-2 is still well alive and kicking. >> We do have Camellia ciphers defined, PFS AEAD included (RFC 6367). >That, and the ChaCha20+Poly1305 AEAD will be defined when http://tools.ietf.org/html/draft-mavrogiannopoulos-chacha-tls-04 is adopted. ...which is already deployed in BoringSSL, LibreSSL, Chromium, Google and a few other places, from the previous (agl) draft. (The AEAD itself is basically ready, going through IESG review process after clearing CFRG LC, I recall?) I actually don't think we have anything on the table for SHA-3 (or any post-SHA-2 hashes in general) - do we? Might be worth thinking of in due course, but I don't currently anticipate any urgency, as SHA-2 is still holding up quite well. - -- /akr -----BEGIN PGP SIGNATURE----- Version: APG v1.1.1 iQI3BAEBCgAhBQJUpp1DGhxBbHlzc2EgUm93YW4gPGFrckBha3IuaW8+AAoJEOyE jtkWi2t6HzoQAIBh4/ZweXRFAqBK5WMRkgsP+f/EBpX2XcUId6RQmtOCI4769iV4 vrOQsKlnHd65XRVd9/GKQ6H349iDCvYOwze46CNRwTdCLzr7z4a+2OLmYbMkGu7l Rc+FrPHzH/4JXxr4245gkBOz2s6KcL80y2C+W8bCoI2nAHqK0JFvn1wofQpfaqqo 6h/lNjGuEEHYZAHiXzK8jv8dH94hV1HchFD4OQM9yrrvRCeiigpt3p0PwrGQA6Hs Y7XbpVNp4xUApK0VyrSL6rdezN0IcNQJqA9ADP6tW5teUrubq3KyLsk6V3KRcTtP s90qI+mxaF46tqmX1lILIcL1xr3t+YxiYq3Hhmc7O0AJNevjm7duw4Dfcq1r0PKv 9/U60ZiMn2fq4LtDvpwHvq6IPJGIyqblMRu3NgY3ohjPt+ayqMILNSh+DBQavzRV zOqhblrWEXIwFW3gVs8ePNvO4u/4cs4Wc7/Jfl3DFBGvP5OfYOsglF3xhQDec4Fx SitAND6eEXMlmqIlc9luLZW1a6KoW/QTUKG+WpYR0rfNlh8Wohk2ICqQTVLQrueu YIqe/+2AFqkNMNESXi7gwz3U/v+VFFQAnRyun3agNJg71BvP2JYk4OfpwZbHgVjD xXKd9y+nMu+C8w6xwZlxb3FDe2GRT0zLlL5UiCI3vucgML/q7DUA7JdH =evi3 -----END PGP SIGNATURE----- From nobody Fri Jan 2 09:17:19 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97C251A1B84 for ; Fri, 2 Jan 2015 09:17:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 FwPU8HHGDcNh for ; Fri, 2 Jan 2015 09:17:16 -0800 (PST) Received: from homiemail-a86.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 74A981A1B55 for ; Fri, 2 Jan 2015 09:17:16 -0800 (PST) Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id 5544336006D; Fri, 2 Jan 2015 09:17:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=hE9NhI8rDVDIlB JuZy+aKF3arQI=; b=gFUJDMG1pSqLVejqB5vKsjji4VrGZOBe24Rlr2BpiYyQOS VUBqq/BqrXN5ThQUwtU30O2k3lYnFIPScB15KfCJO/00hWlwshUuhvFiKOL4ja21 29Gnj8B5a7PxKaF7o/Sg4c1PnUqabFVPChXQKp1hJmjHHq7eHRB0IxPf1p4Z0= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPA id 00E4F36006B; Fri, 2 Jan 2015 09:17:15 -0800 (PST) Date: Fri, 2 Jan 2015 11:17:15 -0600 From: Nico Williams To: Yoav Nir Message-ID: <20150102171711.GY24442@localhost> References: <54A252EA.1010905@iki.fi> <2348107.Lj21YcAO1u@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/dg_1_WB6QGJyvDznISAHdSx8624 Cc: tls@ietf.org Subject: Re: [TLS] Do we need DH? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2015 17:17:17 -0000 On Fri, Jan 02, 2015 at 03:08:07PM +0200, Yoav Nir wrote: > > On Jan 2, 2015, at 2:46 PM, Hubert Kario wrote: > > On Tuesday 30 December 2014 09:23:22 Tapio Sokura wrote: > >> With regards to all eggs being in the same basket, AES is also something > >> that really should have a realistic alternative standardized and > >> deployed _before_ (/if) AES is broken. Like SHA-3 is coming around the > >> corner while SHA-2 is still well alive and kicking. > > > > We do have Camellia ciphers defined, PFS AEAD included (RFC 6367). > > That, and the ChaCha20+Poly1305 AEAD will be defined when http://tools.ietf.org/html/draft-mavrogiannopoulos-chacha-tls-04 is adopted. I think Hubert may be referring to the need for for interoperable alternatives. As in: being likely to find those alternatives deployed. IOW, we need at least two realistic *REQUIRED to implement* algorithms (curves for ECC) of most kinds: two hash functions, two PRFs, two ECDH curves, two digital signature algorithms (e.g., RSA and E*DSA), two AEAD ciphers. For some kinds of algorithms (ciphers) this might be difficult, politically. But it's worth considering. Nico -- From nobody Fri Jan 2 10:41:27 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67AC81A0052 for ; Fri, 2 Jan 2015 10:41:26 -0800 (PST) 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 iGxcoGG9t9HW for ; Fri, 2 Jan 2015 10:41:24 -0800 (PST) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F3DE1A0056 for ; Fri, 2 Jan 2015 10:41:24 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id z12so6672229wgg.41 for ; Fri, 02 Jan 2015 10:41:23 -0800 (PST) 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=BfG+dgG94rr7zREzMCM6OK1FTg6mgQC6XtlmYUrPOS8=; b=xYcEuvCD3oPgz0OisL873P2u+Xy4ElAquxoyx1oUImGR3lmas5gDVY4eir1txF8UCe ZDYaii5HG34H8ivEvi1UXorbvmQkrkBE8OUOUzT7bFXRZtxBr+MlSamFxBhfxT2sXFgG m4bl+epAogo8xQrddtEHNDrvdvGi6aPn9p/K+m7syAW/YHP8yuyDktjdTJEps7bESBPl Y1DS19MFjj7lapFbXKGW9uZtt3PEC7A7p1ha/rYziIg+8ZKdvxpGc9PGcQzNuLYP9lHm CuDxDZdSg0g0ytLv41XyRZAV2k5zr3D5FFRlU/GAJMVLpVHqLeFG3CA+oY5wiRSWpL/o 4RfQ== X-Received: by 10.194.110.69 with SMTP id hy5mr155141727wjb.121.1420224083283; Fri, 02 Jan 2015 10:41:23 -0800 (PST) Received: from [192.168.1.102] (IGLD-84-228-227-214.inter.net.il. [84.228.227.214]) by mx.google.com with ESMTPSA id vs8sm40618061wjc.6.2015.01.02.10.41.21 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 02 Jan 2015 10:41:22 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Yoav Nir In-Reply-To: <20150102171711.GY24442@localhost> Date: Fri, 2 Jan 2015 20:41:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54A252EA.1010905@iki.fi> <2348107.Lj21YcAO1u@pintsize.usersys.redhat.com> <20150102171711.GY24442@localhost> To: Nico Williams X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/yqI-CuMT9ebnX62ZCqO5t4OhrmI Cc: tls@ietf.org Subject: Re: [TLS] Do we need DH? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2015 18:41:26 -0000 > On Jan 2, 2015, at 7:17 PM, Nico Williams = wrote: >=20 > On Fri, Jan 02, 2015 at 03:08:07PM +0200, Yoav Nir wrote: >>> On Jan 2, 2015, at 2:46 PM, Hubert Kario wrote: >>> On Tuesday 30 December 2014 09:23:22 Tapio Sokura wrote: >>>> With regards to all eggs being in the same basket, AES is also = something >>>> that really should have a realistic alternative standardized and >>>> deployed _before_ (/if) AES is broken. Like SHA-3 is coming around = the >>>> corner while SHA-2 is still well alive and kicking. >>>=20 >>> We do have Camellia ciphers defined, PFS AEAD included (RFC 6367). >>=20 >> That, and the ChaCha20+Poly1305 AEAD will be defined when = http://tools.ietf.org/html/draft-mavrogiannopoulos-chacha-tls-04 is = adopted. >=20 > I think Hubert may be referring to the need for for interoperable > alternatives. As in: being likely to find those alternatives = deployed. >=20 > IOW, we need at least two realistic *REQUIRED to implement* algorithms > (curves for ECC) of most kinds: two hash functions, two PRFs, two ECDH > curves, two digital signature algorithms (e.g., RSA and E*DSA), two = AEAD > ciphers. >=20 > For some kinds of algorithms (ciphers) this might be difficult, > politically. But it's worth considering. I think ChaCha20+Poly1305 has a very good chance of becoming deployed. = Chrome has an implementation of an earlier draft, and I=E2=80=99m sure = once draft-mavrogiannopoulos gets published as an RFC both the Chrome = implementation and the contribution to OpenSSL will get updated. I = can=E2=80=99t speak for SCHANNEL, NSS and whatever Safari is using, but = I think it has a better chance of becoming ubiquitous than anything else = that=E2=80=99s on the table. Yoav From nobody Sat Jan 3 04:30:43 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9FB61A89FE for ; Sat, 3 Jan 2015 04:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 uomiE78cNyeQ for ; Sat, 3 Jan 2015 04:30:38 -0800 (PST) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83A011A8A04 for ; Sat, 3 Jan 2015 04:30:38 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 5C60D3A133; Sat, 3 Jan 2015 13:30:36 +0100 (CET) Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 52A80410AD; Sat, 3 Jan 2015 13:30:36 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 393011B0C2; Sat, 3 Jan 2015 13:30:36 +0100 (CET) In-Reply-To: <201412271739.24476.davemgarrett@gmail.com> To: Dave Garrett Date: Sat, 3 Jan 2015 13:30:36 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20150103123036.393011B0C2@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/RkUvojjt2dPm_7q1hlwMCdHoToU Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] drop obsolete SSL 2 backwards compatibility from TLS 1.3 draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2015 12:30:41 -0000 Dave Garrett wrote: > > The newest version of TLS should not be have to be written to accommodate > an 8 year old EOL Java version's default settings. While Android seems to use OpenSSL (native code) rather than the SSL from the JDK, Android 4.1 through 4.3 (Jelly Bean) and Android 4.4 (KitKat) seem to all be using Java 6. And its not like end uses would have a choice to perform an upgrade themselves. Java 7 is limited to Android 5, and that is mostly vaporware for what was sold during the 2014 Xmas sales. Pretty much all brand new sales are Android 4.x with Java 6. -Martin From nobody Sat Jan 3 07:53:50 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 693F41A877F for ; Sat, 3 Jan 2015 07:53:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 jUJouUkMgMRK for ; Sat, 3 Jan 2015 07:53:42 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 73A911A8787 for ; Sat, 3 Jan 2015 07:53:42 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 2893647678; Sat, 3 Jan 2015 15:53:41 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id CD0A24764B; Sat, 3 Jan 2015 15:53:40 +0000 (GMT) Received: from email.msg.corp.akamai.com (unknown [172.27.123.34]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id C0DC380044; Sat, 3 Jan 2015 15:53:40 +0000 (GMT) Received: from usma1ex-cashub6.kendall.corp.akamai.com (172.27.105.22) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.913.22; Sat, 3 Jan 2015 10:49:27 -0500 Received: from USMBX1.msg.corp.akamai.com ([169.254.1.15]) by USMA1EX-CASHUB6.kendall.corp.akamai.com ([172.27.105.22]) with mapi; Sat, 3 Jan 2015 10:49:27 -0500 From: "Salz, Rich" To: "mrex@sap.com" , Dave Garrett Date: Sat, 3 Jan 2015 10:49:25 -0500 Thread-Topic: [TLS] drop obsolete SSL 2 backwards compatibility from TLS 1.3 draft Thread-Index: AdAnURsRdFn8RFuFRuCNgnfyWamNWAAG5ITg Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D55237430@USMBX1.msg.corp.akamai.com> References: <201412271739.24476.davemgarrett@gmail.com> <20150103123036.393011B0C2@ld9781.wdf.sap.corp> In-Reply-To: <20150103123036.393011B0C2@ld9781.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/cUQY6M1june5enHygwgzSDOyn-g Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] drop obsolete SSL 2 backwards compatibility from TLS 1.3 draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2015 15:53:46 -0000 A TLS 1.3 server can get the hello, and if it fails to parse it, retry it a= s a pre-1.3 Hello. No? Then it's not a TLS 1.3 server, is it. Will we always have to accommodate all the installed base with a protocol t= hat's like a decade old? -- =20 Principal Security Engineer, Akamai Technologies IM: rsalz@jabber.me Twitter: RichSalz From nobody Sat Jan 3 12:40:04 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D64311A024E for ; Sat, 3 Jan 2015 12:40:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.339 X-Spam-Level: X-Spam-Status: No, score=0.339 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DE=0.35, 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 s_m6z_uCVrHn for ; Sat, 3 Jan 2015 12:40:01 -0800 (PST) Received: from albireo.enyo.de (albireo.enyo.de [46.237.207.196]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0FF01A024C for ; Sat, 3 Jan 2015 12:40:00 -0800 (PST) Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) id 1Y7VUL-0005T9-O3; Sat, 03 Jan 2015 21:39:57 +0100 Received: from fw by deneb.enyo.de with local (Exim 4.80) (envelope-from ) id 1Y7VUL-0004yh-G1; Sat, 03 Jan 2015 21:39:57 +0100 From: Florian Weimer To: Watson Ladd References: Date: Sat, 03 Jan 2015 21:39:57 +0100 In-Reply-To: (Watson Ladd's message of "Sun, 28 Dec 2014 17:38:11 -0500") Message-ID: <877fx3sin6.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/tls/NYTXwTzw-e0yitOuQk-GyMnM9No Cc: "tls@ietf.org" Subject: Re: [TLS] Do we need DH? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2015 20:40:03 -0000 * Watson Ladd: > I invite you to consider the following interesting sources > > http://www.spiegel.de/media/media-35511.pdf > http://www.spiegel.de/media/media-35510.pdf > > These show that the NSA has a comparatively easy time exploiting > static RSA. Did you reference the correct slide decks? These don't mention that offline attack capabilities against RSA exist (assuming the key material has been managed properly). From nobody Sat Jan 3 14:00:25 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F85E1A1DBE; Sat, 3 Jan 2015 14:00:20 -0800 (PST) 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 3-0yB6JLjwdJ; Sat, 3 Jan 2015 14:00:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CD0C71A6ED8; Sat, 3 Jan 2015 14:00:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150103220017.14032.97332.idtracker@ietfa.amsl.com> Date: Sat, 03 Jan 2015 14:00:17 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/1g7cI-XM-kzDTqheIKhU4-2uVSM Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-tls13-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2015 22:00:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : The Transport Layer Security (TLS) Protocol Version 1.3 Authors : Tim Dierks Eric Rescorla Filename : draft-ietf-tls-tls13-04.txt Pages : 92 Date : 2015-01-03 Abstract: This document specifies Version 1.3 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-tls13-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-tls13-04 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Jan 3 14:02:58 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B014A1A6EEC for ; Sat, 3 Jan 2015 14:02:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 gGGXCqNsvl2B for ; Sat, 3 Jan 2015 14:02:54 -0800 (PST) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78A6B1A1DBE for ; Sat, 3 Jan 2015 14:02:54 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id h11so1220498wiw.15 for ; Sat, 03 Jan 2015 14:02:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=a78nN5kH9KvCApFosypq3aMY4PUD2ZtU5OD2VaASJiQ=; b=MjPS5d5fsanutxQXayhZiuHdNvPxetCuoTfGyz6QdHMa1p4Put4u7/ZzL1g2Yfsl45 r11elxZ5+GTeyvMnjTl6jjUSAOKOHECVrjidphwmkuWBznqrLzp7pInrqqsxhDVgi9Us vfqIx5Q7+VwH6RA/XTV7LoEMbmgFyU6uPErCjgVIJo8oC8JicWc2GR5/qg2NjDGK9Kuv ZO8tn0UaPzJJIwlk1f0Xu+GXB48gl6lnOnWOXyP28dByWsrp+XXCcZXXmFcncVaeS1Jt W9pDHuz9YeuCAArPWu01rqqts4xkOajZf5T7t3d515ESSvOGup7XzYG7P1MrdqBmgukO Kyag== X-Gm-Message-State: ALoCoQm08C7g8kxpKNngdksfNEWfjJo0UGTtKkfmLY277bPiKPgqdytV9d/qc6Kkeou51/OJUte/ X-Received: by 10.194.108.98 with SMTP id hj2mr164826348wjb.102.1420322573108; Sat, 03 Jan 2015 14:02:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.130.34 with HTTP; Sat, 3 Jan 2015 14:02:12 -0800 (PST) From: Eric Rescorla Date: Sat, 3 Jan 2015 14:02:12 -0800 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=089e010d8a8c6fdf37050bc69eee Archived-At: http://mailarchive.ietf.org/arch/msg/tls/IqRCSTXPhxFJK3h7-_zEMeXZ5qs Subject: [TLS] Updated TLS 1.3 draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2015 22:02:56 -0000 --089e010d8a8c6fdf37050bc69eee Content-Type: text/plain; charset=UTF-8 Folks, I've just published draft-04 (https://tools.ietf.org/html/draft-ietf-tls-tls13-04 ). This includes the following changes based on WG discussion. - Modify key computations to include session hash. - Remove ChangeCipherSpec - Renumber the new handshake messages to be somewhat more consistent with existing convention and to remove a duplicate registration. - Remove renegotiation. - Update format of signatures with context. - Remove point format negotiation. And of course a bunch of editorial changes. Thanks to all who sent in comments and PRs. Comments welcome! -Ekr --089e010d8a8c6fdf37050bc69eee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Folks,

I've just publi= shed draft-04
changes based on WG discussion.

- Modify k= ey computations to include session hash.

- Remove = ChangeCipherSpec

- Renumber the new handshake mess= ages to be somewhat more
=C2=A0 consistent with existing conventi= on and to remove a duplicate
=C2=A0 registration.

<= /div>
- Remove renegotiation.

- Update format = of signatures with context.

- Remove point format = negotiation.

And of course a bunch of editorial changes. Thanks to a= ll who sent in
comments and PRs. Comment= s welcome!

-Ekr
--089e010d8a8c6fdf37050bc69eee-- From nobody Mon Jan 5 08:08:23 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD04A1A1A31 for ; Mon, 5 Jan 2015 08:08:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_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 QShZ7ZPYltPK for ; Mon, 5 Jan 2015 08:08:19 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC4BD1A1A04 for ; Mon, 5 Jan 2015 08:08:18 -0800 (PST) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t05G8GXi016101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Mon, 5 Jan 2015 11:08:17 -0500 Received: from dhcp-2-127.brq.redhat.com (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t05G8EAx006272 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Mon, 5 Jan 2015 11:08:16 -0500 Message-ID: <1420474094.10168.49.camel@redhat.com> From: Nikos Mavrogiannopoulos To: IETF TLS Date: Mon, 05 Jan 2015 17:08:14 +0100 Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/qTH6LYByqRMfWefziINiHQQsH0Y Subject: [TLS] issues with DTLS + PSK X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 16:08:21 -0000 Some issues while using PSK in combination with DTLS. 1. The PSK ciphersuites rely on Finished messages mismatch to detect a wrong preshared-key. That doesn't work well with DTLS where wrongly encrypted messages are simply ignored. Thus there is no reasonable way to detect wrong PSK keys except wait for some timeout. 2. Even if one would not ignore the finished message decryption issue, and fail the handshake immediately, there is no way to notify the peer of the failure. The exchanged keys don't match, so any alert message will not be received by the peer. A solution would be, on a revision of the PSK ciphersuites, to define PSK ciphersuites which will authenticate (e.g., with a MAC), an (EC)DH key exchange. That would allow a graceful failure in case of a mismatch of keys. In addition it will allow the usage of hardware security modules with PSK (something that is very hard to impossible with the current ECDHE/DHE PSK ciphersuites). regards, Nikos From nobody Mon Jan 5 09:42:59 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A815B1A86DE for ; Mon, 5 Jan 2015 09:42:57 -0800 (PST) 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 IESQ_qGB6jL4 for ; Mon, 5 Jan 2015 09:42:56 -0800 (PST) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C9071A0041 for ; Mon, 5 Jan 2015 09:42:56 -0800 (PST) Received: by mail-ob0-f170.google.com with SMTP id wp18so61850141obc.1 for ; Mon, 05 Jan 2015 09:42:55 -0800 (PST) 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=q0AASc3rv9bVbIF1FSep/yjpnIYJXd/nDz9lBxcV7sU=; b=t7g/pcG4A+fbGcXfCmHdD/HkJaKul3y1g+B15CmQpaRic/88mhsBF/RA4XpBHoOjls /fG1AiFuzdt55lcHnmEeMr1KuqDfaH/gDeZR5/p8GoVYX1mt9K0mHY9z2JrkaOH+uVNg Tlo6ViSH2j3/W8TcJUUIskG++/RHEYWAwcPYBPQaT3/qpt8fzCUTH2YFvXN3bcJLDbZL 1kQOGpeW/G/It+dQG++1drTuSFUl/ff+t8kZqYit0CET+5BDadTOVtW505/Rvc2w629B XXLAJSETy6xO5PgnB4c19D746eYnEyasdRRr1Uvm5E27H1mKeJx9X2AGaz/3zCQ+pBdk 5Yhw== MIME-Version: 1.0 X-Received: by 10.60.76.10 with SMTP id g10mr34447840oew.0.1420479775630; Mon, 05 Jan 2015 09:42:55 -0800 (PST) Received: by 10.202.226.136 with HTTP; Mon, 5 Jan 2015 09:42:55 -0800 (PST) In-Reply-To: <1420474094.10168.49.camel@redhat.com> References: <1420474094.10168.49.camel@redhat.com> Date: Mon, 5 Jan 2015 09:42:55 -0800 Message-ID: From: Martin Thomson To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/VgLpFVLewFgFFQ6bSkmh_0l7N2k Cc: IETF TLS Subject: Re: [TLS] issues with DTLS + PSK X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 17:42:57 -0000 On 5 January 2015 at 08:08, Nikos Mavrogiannopoulos wrote: > A solution would be, on a revision of the PSK ciphersuites, to define > PSK ciphersuites which will authenticate (e.g., with a MAC), an (EC)DH > key exchange. That would allow a graceful failure in case of a mismatch > of keys. In addition it will allow the usage of hardware security > modules with PSK (something that is very hard to impossible with the > current ECDHE/DHE PSK ciphersuites). If the same general formulation we've been using for TLS 1.3 is consistently applied to PSK, then key derivation will be based on the (EC)DH exchange and the PSK will only be used to authenticate, exactly as you describe. I think that would be a pretty good answer. From nobody Mon Jan 5 10:26:28 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 935941A876E for ; Mon, 5 Jan 2015 10:26:25 -0800 (PST) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 4tYL3amqS2cg for ; Mon, 5 Jan 2015 10:26:23 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 E2DC61A87A5 for ; Mon, 5 Jan 2015 10:26:20 -0800 (PST) Received: from [192.168.131.143] ([80.92.122.140]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LiTm8-1XXlfs1R4m-00clfg; Mon, 05 Jan 2015 19:26:12 +0100 Message-ID: <54AAD743.6070801@gmx.net> Date: Mon, 05 Jan 2015 19:26:11 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Nikos Mavrogiannopoulos , IETF TLS References: <1420474094.10168.49.camel@redhat.com> In-Reply-To: <1420474094.10168.49.camel@redhat.com> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="vwBV3DsBIEHHdPaO4WHtEIrcOMFOGT1Gc" X-Provags-ID: V03:K0:tiTOs5lJ7FdcIGXUc/L0reC7oSNSaonpj+24StgWYByq05dw99u LDAn9L5doLvjMs4b+anNx9ofl4PgKoZwzowuwlj6yiTnxTa2Nb1yb5eenAOwN1/lwPJyzmL XVi8K03P30ZiRsmRoFeGLUj5X0SZ8mtxo0iYU7x1d8QDVMVHt95JWIVmzmsI4efXyWgB5UT 5JfQibVIKavEiA25OjyRQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/LQjtvyUt9MVlEkUt8FaR7dY1T0U Subject: Re: [TLS] issues with DTLS + PSK X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 18:26:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --vwBV3DsBIEHHdPaO4WHtEIrcOMFOGT1Gc Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Nikos, the issue you raise did not surface as a problem in the IoT space with the use of DTLS. When you do not have the right key for authentication in DTLS then waiting for the timeout is not going to be a big deal. Note that this is not a user sitting in front of the machine and typing in passwords. This is, as the name indicates, a shared secret-based mechanis= m. Using DTLS-PSK in combination with DH is IMHO not particularly useful since then you can also switch to a raw public key right away since you loose all the performance and code size benefits that the PSK mechanism provides with DTLS. Ciao Hannes On 01/05/2015 05:08 PM, Nikos Mavrogiannopoulos wrote: > Some issues while using PSK in combination with DTLS. > 1. The PSK ciphersuites rely on Finished messages mismatch to detect a > wrong preshared-key. That doesn't work well with DTLS where wrongly > encrypted messages are simply ignored. Thus there is no reasonable way > to detect wrong PSK keys except wait for some timeout. >=20 > 2. Even if one would not ignore the finished message decryption issue, > and fail the handshake immediately, there is no way to notify the peer > of the failure. The exchanged keys don't match, so any alert message > will not be received by the peer. >=20 >=20 > A solution would be, on a revision of the PSK ciphersuites, to define > PSK ciphersuites which will authenticate (e.g., with a MAC), an (EC)DH > key exchange. That would allow a graceful failure in case of a mismatch= > of keys. In addition it will allow the usage of hardware security > modules with PSK (something that is very hard to impossible with the > current ECDHE/DHE PSK ciphersuites). >=20 > regards, > Nikos >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --vwBV3DsBIEHHdPaO4WHtEIrcOMFOGT1Gc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUqtdDAAoJEGhJURNOOiAtX58H/j0+c3pX60t5Tu1+ISYZKW/a FdsvBruihCB3fv+HmFL6FeFMi4ssuH+uHwblmDhwAH1IcNUKG+hZaIj1uG1RIDeO ib7foCep1Vaq2WBQdhhCnH3ExqZma/vGW8IhkwFQ76XWfC0LtAjfb/3cX8tGoRFX 3wUweE25430jf5Ht2Uuu6QKOrjPt0Xh/wIJnsoxp96yExDRPRPTaPOlkLcy1NTbI APUnHwJjenMKACqSi77y9BylZ3FUJILirn5szB1/BKWIv20H4GZVZ3y/xjf7qnnK 3wzwKZfT4RQduYFj+Xa5h6tAbOep7at90IgaKXmJyiaGNyF8SDgMlgZzVEbTlx0= =Ndj1 -----END PGP SIGNATURE----- --vwBV3DsBIEHHdPaO4WHtEIrcOMFOGT1Gc-- From nobody Mon Jan 5 10:41:22 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3EBE1A6FFB for ; Mon, 5 Jan 2015 10:41:19 -0800 (PST) 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 mtBRt65vvVqo for ; Mon, 5 Jan 2015 10:41:18 -0800 (PST) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17E531A6FEB for ; Mon, 5 Jan 2015 10:41:18 -0800 (PST) Received: by mail-ob0-f173.google.com with SMTP id uy5so62311297obc.4 for ; Mon, 05 Jan 2015 10:41:17 -0800 (PST) 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=mFNSppvvdxJVBfBWWYt2Dc9titd9YO0q7b+1FUGaA4k=; b=uZlP9dy3NgCKICbK0ODL4Y0GWfJqNff5YyY3/dHeN8ThKdaQu5Pm/T5OweFtI1mzul jUatQDv8mPGEb8NN/xnVNtIT2LK3ANMH9T0YCpsFL8DZngmBcX5Hyiz10BS4f2qFmCT7 ATaMuXpanaxNF3f4yeG7w7YK4JhUZwFXPsO+ws1cKmX9AYqbTNCHqnTh8g2Jrt4Cjv9e MYMEghjtLbkLjFW2lZaIuNgvTQsJuWxNM6oK+uNfKSdWlTe3XxmgQdzuAhz1b6lhEk2n ++O37wQOm3L33OAqIJB4mjLm2S3YXrOjq/u0mC7uYBG0M5mOhDp4Y2MFb097cVLePFWV za8g== MIME-Version: 1.0 X-Received: by 10.60.145.167 with SMTP id sv7mr53763638oeb.38.1420483277333; Mon, 05 Jan 2015 10:41:17 -0800 (PST) Received: by 10.202.226.136 with HTTP; Mon, 5 Jan 2015 10:41:17 -0800 (PST) In-Reply-To: <54AAD743.6070801@gmx.net> References: <1420474094.10168.49.camel@redhat.com> <54AAD743.6070801@gmx.net> Date: Mon, 5 Jan 2015 10:41:17 -0800 Message-ID: From: Martin Thomson To: Hannes Tschofenig Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/XGuYrlnIb1_F_YK_SzuKZS85baM Cc: IETF TLS Subject: Re: [TLS] issues with DTLS + PSK X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 18:41:20 -0000 On 5 January 2015 at 10:26, Hannes Tschofenig wrote: > Using DTLS-PSK in combination with DH is IMHO not particularly useful > since then you can also switch to a raw public key right away since you > loose all the performance and code size benefits that the PSK mechanism > provides with DTLS. The theory that I've heard regarding this was that we might have two modes: 1. A PSK that mapped directly into session resumption (i.e., you are "resuming" some non-existent session). 2. A PSK that followed the full handshake with DH. While the latter is certainly slow and expensive, I think it was Carsten who suggested that some IoT devices would be interested in - occasionally - doing an ephemeral handshake. Forward secrecy was a desirable property, and some devices would be able to do the work as long it was infrequent and there were no time-critical functions in progress. From nobody Mon Jan 5 10:47:26 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01F631A87D9 for ; Mon, 5 Jan 2015 10:47:20 -0800 (PST) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 VwDm6MHv7XXB for ; Mon, 5 Jan 2015 10:47:17 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 B99131A6FEB for ; Mon, 5 Jan 2015 10:47:16 -0800 (PST) Received: from [192.168.131.143] ([80.92.122.140]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LngNT-1Xbrnw3dPD-00hxzK; Mon, 05 Jan 2015 19:47:08 +0100 Message-ID: <54AADC2A.2050202@gmx.net> Date: Mon, 05 Jan 2015 19:47:06 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Martin Thomson References: <1420474094.10168.49.camel@redhat.com> <54AAD743.6070801@gmx.net> In-Reply-To: OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="65gIPlmcju1NKQIL2tspDb39Wst7XJVvH" X-Provags-ID: V03:K0:A23VCV76aB3jGGL9fZopEaXK9k12odtqP2YG1qmypXmoILE3EzF 1i05RwH2GpWuT0edie0xa17W7WsktkmlnFY/sJzr5pO7cbCv7WZQXxBGxUKyYg4yF35rU/D IC+eXzePVThdjy/yo3GvAKsxcOMiLzZViZhHGuWMK4sjZD3tl9+EfMoXSsciEipy1n1ymii MxTsDIUsbhFC4U0XrSuRA== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/l6zBcqzeeAtMboS9aTNFW509tac Cc: IETF TLS Subject: Re: [TLS] issues with DTLS + PSK X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 18:47:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --65gIPlmcju1NKQIL2tspDb39Wst7XJVvH Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Martin, I was talking about PSK is used today in DTLS 1.2. Of course, in the future (with TLS/DTLS 1.3) it might look differently and approach mentioned below with #1 makes sense to me. Ciao Hannes On 01/05/2015 07:41 PM, Martin Thomson wrote: > On 5 January 2015 at 10:26, Hannes Tschofenig wrote: >> Using DTLS-PSK in combination with DH is IMHO not particularly useful >> since then you can also switch to a raw public key right away since yo= u >> loose all the performance and code size benefits that the PSK mechanis= m >> provides with DTLS. >=20 >=20 > The theory that I've heard regarding this was that we might have two mo= des: >=20 > 1. A PSK that mapped directly into session resumption (i.e., you are > "resuming" some non-existent session). >=20 > 2. A PSK that followed the full handshake with DH. >=20 > While the latter is certainly slow and expensive, I think it was > Carsten who suggested that some IoT devices would be interested in - > occasionally - doing an ephemeral handshake. Forward secrecy was a > desirable property, and some devices would be able to do the work as > long it was infrequent and there were no time-critical functions in > progress. >=20 --65gIPlmcju1NKQIL2tspDb39Wst7XJVvH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUqtwqAAoJEGhJURNOOiAtAEUH/16TqoYjmbJc7u8oPCJRTJn2 BkwKZFP9ENbQyAMr8+whAqCKCC/6xQUPIXVsMtyjULAdn4t7QYAYatQYuc/FkPsh yEbXCuhh/v8buFz5VOVYSyFZk9ms7V17pAKn6TMYuUsoBw+5AYqGGeSX+pX9UZ3K M4jCC23nn2blTwDg4MCh3V8DBG3VL9b/5iQ3KZRbw4pmkwlC00q7+bgVPdjzUCTo mFEZxt/5nhCyRe+bk1vSL0Jzyc4muju3bTgUZlY4bIqsvXOdtDnjK4GibaxTLUAP VewJ3EigSCYdKZ+pp17+JqLfEvBB4WDuB80XpZaPpga4XvFJoX5fwAK3T4olrrk= =TvIn -----END PGP SIGNATURE----- --65gIPlmcju1NKQIL2tspDb39Wst7XJVvH-- From nobody Mon Jan 5 10:55:19 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 882FC1A887F for ; Mon, 5 Jan 2015 10:55:18 -0800 (PST) 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 vufMoKeeBFd2 for ; Mon, 5 Jan 2015 10:55:17 -0800 (PST) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D29A31A8833 for ; Mon, 5 Jan 2015 10:55:16 -0800 (PST) Received: by mail-ob0-f170.google.com with SMTP id wp18so62178736obc.1 for ; Mon, 05 Jan 2015 10:55:16 -0800 (PST) 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=FkbwgzjwwQ6HH1i/h+M1Ti7/eEudYB7BLXgwjMVNUOU=; b=1HtYVyzBWhHFmFPIK1j0wAYYfq4zcComcmBLJ0yVKlUTQ2CNqmnfQ4p9Pw7BmuA9CL GT0hzm5EYBaEZzH29VMJGIEWY5plEFE4CkVbE8Ryi6pAq1d6orxWHo2zJvENWoEugt6q 7I8ZzhMLAgVdtqMCnprlSNWtwJ2Y5/etDbeTXIi5rHG/7pbrPD73xLCoSNi7LWntGVlG ET0uNaQ5vXDWtFYJ79we+S8I/Rej+pt0Bihdqz3W1KFuQgZF8Q0bVxvlQ6OJzvTqsHqv PxzEdqmZPacjt4++JEX8cRVb+A8uHs1dTkejczc022qfkCIzQhO1ZgTPeCGKRXFdrTwY a08w== MIME-Version: 1.0 X-Received: by 10.182.165.9 with SMTP id yu9mr22845023obb.34.1420484116260; Mon, 05 Jan 2015 10:55:16 -0800 (PST) Received: by 10.202.226.136 with HTTP; Mon, 5 Jan 2015 10:55:16 -0800 (PST) In-Reply-To: <54AADC2A.2050202@gmx.net> References: <1420474094.10168.49.camel@redhat.com> <54AAD743.6070801@gmx.net> <54AADC2A.2050202@gmx.net> Date: Mon, 5 Jan 2015 10:55:16 -0800 Message-ID: From: Martin Thomson To: Hannes Tschofenig Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/OZHT_-EojS0yz9J0nR3xpt08IoA Cc: IETF TLS Subject: Re: [TLS] issues with DTLS + PSK X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 18:55:18 -0000 On 5 January 2015 at 10:47, Hannes Tschofenig wrote: > I was talking about PSK is used today in DTLS 1.2. Of course, in the > future (with TLS/DTLS 1.3) it might look differently and approach > mentioned below with #1 makes sense to me. Maybe it's just me, but I don't see much point in addressing the sort of concerns Nikos has in TLS 1.2 or earlier :) From nobody Tue Jan 6 00:43:50 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7804D1A1F01 for ; Tue, 6 Jan 2015 00:43:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, 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 nzXsTo1mHUin for ; Tue, 6 Jan 2015 00:43:46 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41E701A899D for ; Tue, 6 Jan 2015 00:43:44 -0800 (PST) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t068hb1R024670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 6 Jan 2015 03:43:37 -0500 Received: from dhcp-2-127.brq.redhat.com (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t068hZ9C026088 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 6 Jan 2015 03:43:36 -0500 Message-ID: <1420533814.16301.12.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Hannes Tschofenig Date: Tue, 06 Jan 2015 09:43:34 +0100 In-Reply-To: <54AAD743.6070801@gmx.net> References: <1420474094.10168.49.camel@redhat.com> <54AAD743.6070801@gmx.net> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/M7IUW7Bt9dVqN61wJ8mAp_rJBY0 Cc: IETF TLS Subject: Re: [TLS] issues with DTLS + PSK X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 08:43:48 -0000 On Mon, 2015-01-05 at 19:26 +0100, Hannes Tschofenig wrote: > Hi Nikos, > > the issue you raise did not surface as a problem in the IoT space with > the use of DTLS. When you do not have the right key for authentication > in DTLS then waiting for the timeout is not going to be a big deal. Note > that this is not a user sitting in front of the machine and typing in > passwords. This is, as the name indicates, a shared secret-based mechanism. My use case is not with unattended clients and the main issue as I see it, is configuration. You cannot have instructions like put a key, and if it works everything went well. Otherwise if you see random errors, the key is wrong, or there is network issue, or whatever and go figure. Of course that is still usable, but has a horrible debugging mechanism in case of a failure. > Using DTLS-PSK in combination with DH is IMHO not particularly useful > since then you can also switch to a raw public key right away since > you loose all the performance and code size benefits that the PSK > mechanism provides with DTLS. DHE-PSK is more efficient than DHE-RSA, and the same is for the ECDHE equivalent, because you don't need digital signatures, only the key exchange. Moreover, you don't need to drag or rely to an ASN.1 parser. regards, Nikos From nobody Tue Jan 6 02:24:53 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EDD41A9168 for ; Tue, 6 Jan 2015 02:24:51 -0800 (PST) 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 UdPo7OY1bvSl for ; Tue, 6 Jan 2015 02:24:43 -0800 (PST) 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 A08671A914A for ; Tue, 6 Jan 2015 02:24:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1420539883; x=1452075883; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=9HJSrQrRcQdilywf6zX1PxkjkhVTUF7GUzDsChzA4OY=; b=nVyaqAQN20uRlYmUlv3jZ5fQFHFn0o1s880CT2a0dtShu6y4KBWM8li5 Mn8vGQW/qflthENlGtwxaIhcS0pNe9jba2Y3ZuvL54l+wxQv2e49GDsuz y3UAGoK1UYwWWKBqwrF7/jaYUtW7pCVk8lVUwwtYndoK9BKDd7GHOaYA8 g=; X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="299834186" 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/AES256-SHA; 06 Jan 2015 23:24:40 +1300 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.148]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0174.001; Tue, 6 Jan 2015 23:24:39 +1300 From: Peter Gutmann To: "" Thread-Topic: [TLS] AAED ciphers: AES-GCM vs AES-EAX/AES-CCM: a meta-analysis Thread-Index: AdApmvo6FjNg+4muRmKsYOSI8dViWQ== Date: Tue, 6 Jan 2015 10:24:39 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAF525A9@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/tls/p6KsERNdXCz-cYO18haQinIPVnA Subject: Re: [TLS] AAED ciphers: AES-GCM vs AES-EAX/AES-CCM: a meta-analysis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 10:24:51 -0000 Michael Clark writes:=0A= =0A= >A TLSv1.3 ClientHello and ServerHello extensions could advertise something= =0A= >like this this:=0A= =0A= Ugh, not, we don't need yet more extensions and complexity, we just need a= =0A= single set of options that everyone uses (see Grigg's Law, "There is only o= ne=0A= cipher suite and that is #1").=0A= =0A= Peter.=0A= From nobody Tue Jan 6 02:27:13 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C57B71A3B9F for ; Tue, 6 Jan 2015 02:27:09 -0800 (PST) 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 8SIOwRFasAwm for ; Tue, 6 Jan 2015 02:27:07 -0800 (PST) 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 B97F91A914B for ; Tue, 6 Jan 2015 02:27:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1420540027; x=1452076027; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=2KVnmLuNnYdd//zxuAukcfBfYcroW+wuMqExYOA1+ig=; b=m2YiQOTPK4tNLkJ9BPg1UXZEfgDwdE6jB0d2T/0npe3tWu07KHj5GRkn uLc6+r8+TqP4JCHePBiYMdtfu4doLOMOovuzR7C13wSPFspy371O/pRKn aUmB2O8fCs3Qsrk5SGe/mPtgK8KAjx11y1eUHkLHSKDgBtnVqAI4S1mlp c=; X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="299834400" 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/AES256-SHA; 06 Jan 2015 23:27:05 +1300 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.148]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0174.001; Tue, 6 Jan 2015 23:27:04 +1300 From: Peter Gutmann To: "" Thread-Topic: [TLS] AAED ciphers: AES-GCM vs AES-EAX/AES-CCM: a meta-analysis Thread-Index: AdApm1Dp+QfpFbQHSrGreNGElYnrkg== Date: Tue, 6 Jan 2015 10:27:04 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAF525B9@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/tls/xh6cUVs87qyYsVxMmMLeAxLn8Rs Subject: Re: [TLS] AAED ciphers: AES-GCM vs AES-EAX/AES-CCM: a meta-analysis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 10:27:10 -0000 Michael Clark writes:=0A= =0A= >Before I've read through can we do this with it?=0A= >=0A= >AES-256-GCM + hmac_null =3D 128 bits authentication=0A= >AES-256-CBC + hmac_sha128 =3D 128 bits authentication=0A= >=0A= >AES-256-GCM + hmac_sha128 =3D 256 bits authentication=0A= >AES-256-CBC + hmac_sha256 =3D 256 bits authentication=0A= >=0A= >AES-256-GCM + hmac_sha256 =3D 384 bits authentication=0A= >AES-256-CBC + hmac_sha384 =3D 384 bits authentication=0A= =0A= The MAC is whatever is negotiated for the session, and if you want a shorte= r=0A= one you can send the truncated-MAC extension (which, however, nothing suppo= rts=0A= AFAIK). Having said that, see my previous message about not needing a=0A= thousand options, we only need one that everyone uses.=0A= =0A= Peter.=0A= From nobody Tue Jan 6 02:37:04 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB94B1A912C for ; Tue, 6 Jan 2015 02:37:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 a5NcpvVx0pG2 for ; Tue, 6 Jan 2015 02:37:01 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0670.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::670]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3EBC1A1BDD for ; Tue, 6 Jan 2015 02:37:00 -0800 (PST) Received: from DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) by DBXPR03MB382.eurprd03.prod.outlook.com (10.141.10.12) with Microsoft SMTP Server (TLS) id 15.1.49.12; Tue, 6 Jan 2015 10:35:16 +0000 Received: from DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) by DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) with mapi id 15.01.0049.002; Tue, 6 Jan 2015 10:35:16 +0000 From: "Paterson, Kenny" To: Peter Gutmann , "" Thread-Topic: [TLS] AAED ciphers: AES-GCM vs AES-EAX/AES-CCM: a meta-analysis Thread-Index: AdApm1DpFjNg+4muRmKsYOSI8dViWQAASE0A Date: Tue, 6 Jan 2015 10:35:16 +0000 Message-ID: References: <9A043F3CF02CD34C8E74AC1594475C73AAF525B9@uxcn10-tdc05.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAF525B9@uxcn10-tdc05.UoA.auckland.ac.nz> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [134.219.227.30] authentication-results: spf=none (sender IP is ) smtp.mailfrom=Kenny.Paterson@rhul.ac.uk; x-dmarcaction: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:DBXPR03MB382; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:DBXPR03MB382; x-forefront-prvs: 0448A97BF2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(479174004)(199003)(51704005)(243025005)(189002)(24454002)(4396001)(68736005)(50986999)(66066001)(40100003)(54356999)(102836002)(76176999)(15975445007)(77156002)(2950100001)(2900100001)(62966003)(99396003)(19580405001)(64706001)(77096005)(19580395003)(122556002)(20776003)(92566001)(120916001)(36756003)(97736003)(83506001)(86362001)(101416001)(87936001)(21056001)(2656002)(31966008)(105586002)(74482002)(46102003)(106356001)(107886001)(107046002); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR03MB382; H:DBXPR03MB383.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: rhul.ac.uk does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jan 2015 10:35:16.4129 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR03MB382 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/SCVUY-E5173i-b-25MwsFmgQYvA Subject: Re: [TLS] AAED ciphers: AES-GCM vs AES-EAX/AES-CCM: a meta-analysis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 10:37:04 -0000 Hi On 06/01/2015 10:27, "Peter Gutmann" wrote: >Michael Clark writes: > >>Before I've read through can we do this with it? >> >>AES-256-GCM + hmac_null =3D 128 bits authentication >>AES-256-CBC + hmac_sha128 =3D 128 bits authentication >> >>AES-256-GCM + hmac_sha128 =3D 256 bits authentication >>AES-256-CBC + hmac_sha256 =3D 256 bits authentication >> >>AES-256-GCM + hmac_sha256 =3D 384 bits authentication >>AES-256-CBC + hmac_sha384 =3D 384 bits authentication > >The MAC is whatever is negotiated for the session, and if you want a >shorter >one you can send the truncated-MAC extension (which, however, nothing >supports >AFAIK). =20 It's good that nothing supports the truncated-MAC extension, because, in combination with TLS's support for variable length padding, it introduces a security vulnerability. See: http://www.isg.rhul.ac.uk/~kp/mee-comp.pdf which shows that if the tag size (MAC length) is shorter than the CBC-mode block size, then there's a distinguishing attack that can tell the difference between the encryption of a short message and a longer message (even though both are padded to the same size before encryption). This is not an issue for any of the cihersuites proposed above, but it's something to be kept in mind when considering "exotic" ciphersuites. Regards Kenny=20 >Having said that, see my previous message about not needing a >thousand options, we only need one that everyone uses. > >Peter. > >_______________________________________________ >TLS mailing list >TLS@ietf.org >https://www.ietf.org/mailman/listinfo/tls From nobody Tue Jan 6 03:37:24 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97D3C1AC3AC for ; Tue, 6 Jan 2015 03:37:20 -0800 (PST) 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 4UQiaBPvm-Qd for ; Tue, 6 Jan 2015 03:37:16 -0800 (PST) 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 3062C1AC3A9 for ; Tue, 6 Jan 2015 03:37:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1420544237; x=1452080237; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=M7jDATJfyy25kulHQVkwA9IGxrRnXHgSgjfBDxefQ0A=; b=j2ZGvdPmeLMQmU5Zkz2iW/NPIpXkLsePJm/zSjOMcW9eqnxptoTTruUU 4biglY/pJMrwN1boUq7FTbY1fcKl2u+hyW+yYwV3ujFGxj2wnQtrn7PgN dilGMssZzkvxRtJnMkFK5NNMKLc3N3bN1/zkNuC1dmMKUMXSqHCrcgs6z Y=; X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="299839510" 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/AES256-SHA; 07 Jan 2015 00:37:15 +1300 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.148]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0174.001; Wed, 7 Jan 2015 00:37:13 +1300 From: Peter Gutmann To: "" Thread-Topic: [TLS] AAED ciphers: AES-GCM vs AES-EAX/AES-CCM: a meta-analysis Thread-Index: AdAppR1mLlQ4YHkETd2icvdmMpre+A== Date: Tue, 6 Jan 2015 11:37:13 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAF5268C@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/tls/V4crIKSWGDfX4inacGTwlxopMyg Subject: Re: [TLS] AAED ciphers: AES-GCM vs AES-EAX/AES-CCM: a meta-analysis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 11:37:21 -0000 "Paterson, Kenny" writes:=0A= =0A= >It's good that nothing supports the truncated-MAC extension, because, in= =0A= >combination with TLS's support for variable length padding, it introduces = a=0A= >security vulnerability.=0A= =0A= Ooh, good to know, thanks! The truncated-MAC extension is actually kind of= =0A= silly, there's only one size allowed, 80 bits, which isn't really useful (y= ou=0A= save all of 48 bits for a 128-bit MAC) while for ridiculous-sized MACs like= =0A= HMAC-SHA256 and HMAC-SHA512 where you would want to truncate, say to 128 bi= ts,=0A= you can't do it.=0A= =0A= >This is not an issue for any of the cihersuites proposed above, but it's= =0A= >something to be kept in mind when considering "exotic" ciphersuites.=0A= =0A= Actually it does affect AES, since you can only truncate to 80 bits.=0A= =0A= Peter.= From nobody Tue Jan 6 05:23:51 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3FE1A6EDC for ; Tue, 6 Jan 2015 05:23:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.622 X-Spam-Level: * X-Spam-Status: No, score=1.622 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_56=0.6, SPF_HELO_PASS=-0.001, 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 j3ZKC_Ng1M2c for ; Tue, 6 Jan 2015 05:23:43 -0800 (PST) Received: from klaatu.metaparadigm.com (klaatu.metaparadigm.com [67.207.128.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B65561A6EF8 for ; Tue, 6 Jan 2015 05:23:43 -0800 (PST) Received: from monty.local (unknown.maxonline.com.sg [58.182.90.50] (may be forged)) (authenticated bits=0) by klaatu.metaparadigm.com (8.14.4/8.14.4/Debian-4) with ESMTP id t06Dj44U002668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 6 Jan 2015 13:45:07 GMT DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=metaparadigm.com; s=klaatu; t=1420551911; bh=PDfILhWFUY7mof8qQTtaAYuV1DWoEve8OpAw1LxAEZQ=; h=Date:From:To:Subject:References:In-Reply-To:From; b=Nmfmz+eT5ozgWtnBW9jhjmLjICV14s0KT9D13pWv+kYEjitTx0BiYRVhBeJJDukAN I5AfkJMypMYhKuRaBaCPGQbEfoipvLKMyog27HxcZEGJldkEfeeJ5neusrhTzV1xkA 9htM1zFizpfVCou9oKcgYa4ix3OYU9x/Nra+RAB0= Message-ID: <54ABE1D2.7090601@metaparadigm.com> Date: Tue, 06 Jan 2015 21:23:30 +0800 From: Michael Clark Organization: Metaparadigm Pte Ltd User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: tls@ietf.org References: <54A252EA.1010905@iki.fi> <2348107.Lj21YcAO1u@pintsize.usersys.redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.98.4 at klaatu.metaparadigm.com X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/tls/LS4jkp4-urAfuIwsKL65gqdEhJU Subject: [TLS] Spec tls13 comments, handshake tampering, mitigation, counter/seq_no predictability: WAS: Do we need DH? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 13:23:49 -0000 On 2/1/15 9:08 pm, Yoav Nir wrote: > >> On Jan 2, 2015, at 2:46 PM, Hubert Kario wrote: >> >> On Tuesday 30 December 2014 09:23:22 Tapio Sokura wrote: >>> With regards to all eggs being in the same basket, AES is also something >>> that really should have a realistic alternative standardized and >>> deployed _before_ (/if) AES is broken. Like SHA-3 is coming around the >>> corner while SHA-2 is still well alive and kicking. >> >> >> We do have Camellia ciphers defined, PFS AEAD included (RFC 6367). > > That, and the ChaCha20+Poly1305 AEAD will be defined when http://tools.ietf.org/html/draft-mavrogiannopoulos-chacha-tls-04 is adopted. Sharing some comments. Perhaps some are for TLSv2.0 :-D I think adding SHA-3 is a testable idea as it was designed to mitigate future attacks on SHA-2. If we were proactive, we would have the mitigation in place. i.e. a choice of alternative hash algorithms, choice of alternative ciphers. We are getting down to one safe AEAD algorithm (AES-GCM) and one safe key exchange algorithm (ECDHE). I have also made comments regarding an alternative system of composition of cipher primitives that could be used as part of a "design for mitigation". See Replacement idea for CipherSpec and CipherSuites later in this mail. Maybe this is TLSv1.4 material (or TLS 2.0). I don't know the time-frame. We ideally want to have the cryptographic primitive alternatives available to mitigate via configuration changes versus patches, from an operational perspective. As an operator it's better if you can push out config changes versus having to perform package updates. Apologies in advance if I am duplicating comments that have already been shared... also note these are draft comments for consideration... and are based on my developing understanding of TLSv1.2 and of my reading of the current draft-ietf-tls-tls13. Please read and consider. === Comment: the draft should change SHA-2 constants to include the 2. tls_prf_sha256 -> tls_prf_sha2_256, SHA256, SHA384 should be changed to SHA2_256, SHA2_384, so that implementations can use alternative hash and MAC functions as a mitigation strategy, even if not introducing SHA-3, the constants could be renamed in the spec to keep it consistent if SHA-3 is added later. === I see it is already mentioned in the spec that static RSA and DH key exchange are removed. Certificates can be tampered with by a MiFi, at least with TLSv1.2 I believe it is still feasible based on the current spec. TLSv1.3 should use DHE, FFDHE and ECDHE with Ephemeral Forward Secrecy, use named parameters and/or contain guidance on how to check for weak DH parameters. DHE is okay if implementations have guidance on how to check for weak DH parameters. TLSv1.3 should authenticates Hello, KEX parameters, CertificateShares and all other handshake messages to prevent them from being tampered with in transit by a MITM (ISP transparent proxy) like they presently do with TLSv1.2 and below. TLSv1.3 should eliminate handshake rewriting by authenticating handshake messages. The issue is someone who can do layer 2/3 rewriting and may be friends with a CA or have a big database of DH pairs can break TLSv1.2 as the public now is patently aware of. It seems we are only as strong as the weakest KEX and cipher we offer and an implementation needs to check for weak DH parameters, and in TLSv1.2 they are not necessarily the parameters you expose if someone in the middle (ISP transparent proxy, versus simple eavesdropping) tries to downgrade your CipherSuite or substitutes DH parameters and certificate shares by rewriting handshake messages. TLSv1.2 handshake messages are trivially rewritable by a MITM as there is no authentication of handshake messages e.g. Currently we could potentially be downgraded to TLS_RSA_WITH_RC4_128_MD5 with some clients and servers or our certificate DH parameters could be tampered with by rewriting the handshake to negotiate a KEX that helps a MITM learn the pre master secret. >From TLSv1.2 - The connection is reliable. Message transport includes a message integrity check using a keyed MAC. Secure hash functions (e.g., SHA-1, etc.) are used for MAC computations. The Record Protocol can operate without a MAC, but is generally only used in this mode while another protocol is using the Record Protocol as a transport for negotiating security parameters. === Comment: NULL_NULL AEAD for handshake messages should be changed to NULL_HMAC_SHA2_256 AEAD, null cipher, mandatory HMAC using (client|server)_random for AD for all handshake messages. The initial (client|server)_random needs to be included verbatim as the AD and HMAC on all subsequent handshake messages. If it specified that (client|server)_random is included in all handshake messages and is a verbatim repetition of the (client|server)_random in the initial ClientHello/ServerHello and is included as AD for HMAC in the record protocol for every handshake messages, e.g. Encrypt-then-Mac[null,hmac_sha2_256]. The implementation must check that (client|server)_random in subsequent handshake messages matches that from the initial ClientHello/ServerHello and that the HMAC on each handshake message is verified with the initial (client|server)_random as AD.This will make all handshake messages tamper-resistant because (client|server)_random is used for pre-master key derivation. It is no longer possible for a MITM to alter a ClientHello/ServerHello or any subsequent handshake message unless they can forge the HMAC. If a MITM changes the (client|server)_random in any handshake message (for example to alter ciphers offered in ClientHello) then the pre-master secret derivation will fail. I can't see any wording in the spec to this effect. This is a biggie. If you fix the choice of HMAC used for handshake messages in the spec, then you can't mitigate by changing to a stronger hash later if a hash algorithm becomes compromised, so we should have a mandatory set of HMAC algorithms: HMAC_SHA2_256, HMAC_SHA2_384 and HMAC_SHA2_512 and include the HMAC enum in the record protocol to indicate which one is used at the record layer. This approach is symmetrical with an Encrypt-then-Mac meta AEAD referred to later as ETM-AEAD[aead-cipher,hmac], to (optionally) extend the message integrity check on application data messages. === I can't see any handshake record protection in TLSv1.2 spec or in Wireshark? Tell me what I am missing? I note the current draft uses NULL_NULL AEAD for handshake messages. This is the status quo. I may be misunderstanding something and client and server random are in fact part of the AD for handshake messages and NULL_NULL AEAD, but my read of the spec and indications are that the handshake can be tampered with. I can't see it in the spec where the handshake MAC and AD is defined, just NULL_NULL AEAD for the handshake messages. The TLSv1.3 has misleading comments regarding record protection. The handshake is not protected. I might be missing something. I believe handshake messages can still be rewritten by a proxy with the TLSv1.3 draft as it stands? I'm working on writing a proxy so I can test... but I can't see any authentication of handshake in Wireshark decodes of TLSv1.2 handshaking. I was a little surprised. The client and/or server random must be included verbatim in every handshake message and used as part of the handshake AD and there needs to be a MAC on all handshake messages. SHA2-384? otherwise anyone who cap tap layer 2/3 will still be able to rewrite TLSv1.3 handshake messages. === Comment: The spec also needs to advise and reference DHE parameter bounds checking requirements or used named parameters (rfc5114). It reads like it is moving in this direction. Named parameters have their own problems if they are well known and a MITM records lots of traffic then they become vulnerable. Today, if you only expose ECDHE you are relatively safe from most wiretappers as it uses named curves (secp256r1, secp384r1, secp521r1). Worst case with TLSv1.2 and ECDHE exposed as the lowest KEX is that you could be downgraded to secp256r1 (by rewriting extensions in ClientHello) which has known twist vulnerabilities (DJB safe curves) and is vulnerable to side-channel attacks (collocation, timing, FLUSH+RELOAD, non-constant time math). Much harder than DHE tampering. TLSv1.2 DH is vulnerable if the spec doesn't advise implementations how to check for weak DH parameters and TLSv1.2 suffers from handshake rewriting problems i.e. those who can win friends and influence CAs and can get warrants to tap ISPs. DH hides a shared secret from eavesdroppers but is vulnerable to MITM i.e. so is not trustworthy unless CA has public audit records, that would show evidence of certificate tampering. The problem is anyone who can influence a regional CA can break DH and TLS handshake records are not authenticated and there are still cipher downgrade and parameter modification attacks that are possible if handshake protocol isn't AEAD authenticated with an HMAC and null cipher before the handshake is complete. === === Comment: It is also a very testable idea to have several AEAD ciphers, MAC algorithms, key exchange methods and cipher primitives to mitigate future attacks on individual primitives for the same reasoning behind the development of SHA-3. SHA-3 was designed based on the principle of mitigating against future attacks on SHA-2 even though no complete attacks are currently known. It is also testable reasoning to base cryptographic primitive selection on a system of composition versus the current CipherSpec system. See my sketch/comments on overhauling CipherSpecs with a "design for mitigation" strategy. === The current TLSv1.3 draft wording retires MAC-then-Encrypt and depends entirely on AEAD cipher authentication tags for message integrity (see draft-ietf-tls-tls13 / Record Payload Protection). I have no technical issue with the requirement for AEAD ciphers and retiring MAC-then-Encrypt. Here are six well known AEAD ciphers, however all have 128-bit message authentication tags. The first four have IETF specs or drafts: - ChaCha20+Poly1305 http://tools.ietf.org/html/draft-mavrogiannopoulos-chacha-tls-04 - Camellia-GCM http://tools.ietf.org/html/draft-kanno-tls-camellia-gcm-00.html - AES-GCM https://tools.ietf.org/html/rfc5288 - AES-CCM https://tools.ietf.org/html/rfc6655 - AES-EAX (NIST candidate) - AES-OCB (Patented in the US with exemption for any OSI source license) These all fit within the TLSv1.3 draft Record Payload Protection requirements which states exclusive use of AEAD ciphers (draft-ietf-tls-tls13 / Record Payload Protection) and providing at least three would provide exploit mitigation capabilities. === Observation: From reading the current TLSv1.3 draft, it seems CBC and the non GCM version of Camelia are removed by omission which means they would be supported in implementations via backwards compatibility with TLSv1.2. === The issue is the current AEAD ciphers reduce all message authentication to 128-bits due to properties of the current AEAD ciphers. The probability of a forgery is 1 / n<=112 with 16KB messages but this could be reduced with a large dictionary. It is well known that authentication strength is independent from the tag size and GCM weak keys could potentially be exploited. SHA2-256 theoretically provides 128 bits security, SHA2-384, 192 bits security and SHA2-512, 256 bits security. SHA2-384 with 192 bits security strength was available with earlier non-AEAD cipher suites in the deprecated MAC-then-Encrypt scheme in TLSv1.2. There is a *notional* drop in payload integrity protection in the current draft of TLS1.3 due to the requirement for AEAD ciphers and the current AEAD cipher authentication limitations (128-bit tags) with the removal of MAC-then-Encrypt, which offered SHA384 tags with 256 bit ciphers, or 192 bits of message authentication (MAC-then-Encrypt technical issues aside). The choices for the new TLS version should be made not just for those with high performance requirements, but also for those with high security requirements. i.e. 256 bit ciphers and > 192 security bits for message integrity. This is not provided by the current AEAD only wording. AES-CCM (referred to in the current draft) fits the draft Record Payload Protection requirements for AEAD ciphers. CCM is worth retaining and EAX or OCB may be worth reconsidering; for the same mitigation reasoning behind SHA-3 as an alternative to SHA-2. CCM, EAX and OCB all have more entropy in the IV than AES-GCM, and their tags and IV are computed using complimentary approaches (security by diversity). None are as fast as AES-GCM as they don't benefit from GHASH parallelization (useful for a plausible probabilistic integrity attack). The intent is not to use these slower algos as the plaintext replacement for the Internet (AES_128_GCM) rather to mitigate future attacks. We are down to one cipher. It is a very testable idea to have AEAD ciphers with a GHASH alternative to mitigate forgery attacks on GHASH. Someone with lots of resources could probabilistically forge GCM auth tags (or any of the schemes) and substitute bogus data; sometime in the near future. If we are limited to 128-bits content authentication in TLS, then higher layers than TLS will have to add message integrity security due to TLS layer limits in current AEAD ciphers. This is a backwards step from HMAC_SHA384 in the old MAC-then-Encrypt mode (with fixed padding). HMAC_SHA384 offers 192 security bits for message authentication. Also of note is the GCM counter scheme (modified from CTR) was designed to allow 32-bit adders in hardware. The counter starts at 0x0000001 and the entropy in the IV prefix is 96-bits expanded from the nonce. The 32 bits of the IV is predictable. This is not a good property. gcm-spec states this design was to avoid the overhead of 128-bit adders for the counter (adder logic, carry propagation, etc). AES-EAX nonce expands to full 128-bits of entropy in the IV/CTR but requires 128-bit adders as it layers authentication on top of CTR mode. It is slower than GCM but performs similarly to CCM. Someone might be able to comment on the IV entropy for CCM. I think it xors the previous block similarly to CBC so IV doesn't contain predictable components like GCM however it doesn't benefit from single stream parallelization (AES-GCM with GHASH). The issue is raising the message authentication integrity back to TLSv1.2 levels (at least notionally) or higher; given all AEAD ciphers have 128 bit tags (and a lower forgery bound). There is the Encrypt-then-MAC (RFC 7366) extension that if modified in relation to TLSv1.3 could be rephrased as a parameterizable meta-AEAD cipher that meets the Record Payload Protection requirements in the TLSv1.3 draft, as ETM-AEAD[aead-cipher,hmac] and ETM-AEAD[null,hmac] that could be used for handshake messages with (client|server)_random used as AD in all TLSv1.3 handshake messages, and ETM-AEAD[aead-cipher,null] for security levels where 128-bit tags are acceptable. This kind of approach would keep the spec simple and symmetrical. * An AEAD cipher's 128-bit tag plus HMAC_SHA256 would returning the message integrity security bounds to the order of 192 bits (above quantum scale). * An AEAD cipher's 128-bit tag plus HMAC_SHA384 would raise the order above 256 bits. === Comment: Adding AEAD NULL HMAC_SHA2_256, HMAC_SHA2_384 and HMAC_SHA2_512 in an Encrypt-then-MAC scheme for tamper resistant handshake messages in the record protocol ETM-AEAD[null,hmac] and optionally for the application data ETM-AEAD[aead-cipher,hmac] would be symmetrical with handshake rewriting mitigation; which is essentially Encrypt-then-MAC with a NULL cipher e.g. ETM-AEAD[null,hmac] for handshake messages, or a ETM-AEAD[aead-cipher,null] for application data in the case where 128-bit tags from the AEAD cipher are sufficient. The spec would define the AD for handshake messages as (client|server)_random to be repeated verbatim in all handshake messages instead of (seq_num + TLSPlaintext.type + TLSPlaintext.version) as is used for AD construction for application data. === === Probabilistic integrity attack on 128-bit AEAD auth tags - downgrade from HMAC_SHA384 192 bits strength authentication - (Snoopy vs Loki) === The primary issue is that all AEAD ciphers have 128 bit authentication tags. The prevailing argument is that this is sufficient given the nonce lifespan however there is a reasonable argument to provide more integrity protection and this has been mentioned by others. I've done some more research and reasoning. A MITM attacker could find collisions probabilistically for known message lengths with a partial database of tagged AD + bogus data, and bulk data transfer in TLS is likely to have a known size of 16KB less TLS struct overhead, unless message sizes were randomized with message size blinding. Lots of traffic with bulk transfers and 16KB messages (i.e. the Internet) could be vulnerable and opens up the possibility of a probabilistic integrity attacks that could substitute good messages with forged messages by matching AD and 128-bit tag (a very small lookup key) for the same size message. Numbers. 16K message size, n Exabytes (~n â‹…260) dictionary and n Exabytes (~n â‹…260) of traffic and you could probabilistically inject bit errors with a certain probability. The probability is small but is approachable with quantum computing. We need to quantify the computation and storage required to find sizeof(struct(AD) + (16KB - sizeof(ContentType) - sizeof(ProtocolVersion) - sizeof(uint16)) blocks and calculate the probability of finding matching AD plus auth tags given a large DHT and some large pre-computation. AD and tag are visible. The integrity attacker would need a database of AD (seq_num + TLSPlaintext.type + TLSPlaintext.version) at the typical bulk transfer block size of a known TLS implementations to forge AEAD tags and substitute good data with bogus data. This seems a feasible attack on "the Internet" in the very near future (tractable in 10-20 years) with quantum computing and quantum storage (2150) given the orders we are dealing with. This would be infeasible with 256 bits of security. CCM-8 tags at 64-bit could be attacked today with Exascale so shouldn't be used in a modern TLS AEAD suite. It seems from the literature that GHASH forgery probability is (214)/(2128) for 16KB blocks. The 128-bit tag and ADs (seq_num + TLSPlaintext.type + TLSPlaintext.version) are visible. Note this is a not an eavesdropping attack. === === Comment: I noted an earlier TLSv1.3 draft hinted that the initial seq_num should be derived according to (RFC1948) however the wording has changed in the latest draft. TLSv1.2 has predictable sequence number which lowers the order of certain types of attack. Initial sequence number if randomized would need to be included in (Client|Server)Hello and authenticated with the HMAC so they cannot be tampered with. This would increase the order of certain types of attacks. === The current TLSv1.3 draft says this which is: sequence number : Each connection state contains a sequence number, which is maintained separately for read and write states. The sequence number MUST be set to zero whenever a connection state is made the active state. Sequence numbers are of type uint64 and may not exceed 2^64-1. Sequence numbers do not wrap. If a TLS implementation would need to wrap a sequence number, it must terminate the connection. A sequence number is incremented after each record: specifically, the first record transmitted under a particular connection state MUST use sequence number 0. === Comment: Given sequence numbers are 64 bit, randomizing the lower 48-bits of the sequence number would not limit data transfer capabilities or introduce any significant wrap problems. Consider randomizing the lower n-bits of the sequence number. === An Encrypt-then-MAC (RFC 7366) derived meta-AEAD i.e. ETM-AEAD[aead-cipher,hmac] with higher strength authentication tags (AEAD tag combined with HMAC) and randomized initial sequence numbers included in the Hello would mitigate forgery attacks for application data. AEAD ciphers with > 128 bit tags are perhaps impracticable in the short-term because they don't exist so ETM-AEAD[aead-cipher,hmac] would be a practical approach and also fix the handshake authentication issues ETM-AEAD[null,hmac]. Given the amount of Internet data transferred, storage capacity predictions and so forth, the (lack of) entropy in the AD sequence numbers and the tag sizes, it seems that this type of attack could easily be mounted in the next 10 years (maybe sooner). It would be interesting to quantify the probability of bogus block injection rate given predicted storage. From pencil calculation it seems feasible at lower than quantum scale i.e. way less than a Googol ;-). GCM + HMAC_SHA256 for 384 bits authentication would provide > 192 security bits and render this infeasible at quantum scale. A small overhead for a 16KB message. However this is a minor issue compared to the ability for transparent proxies rewriting handshake messages however it is addressed in a similar way. ETM-AEAD[null,hmac] for handshake and ETM-AEAD[aead-cipher,null] or ETM-AEAD[aead-cipher,hmac] for application data. " ### Record Payload Protection The record protection functions translate a TLSPlaintext structure into a TLSCiphertext. The deprotection functions reverse the process. In TLS 1.3 as opposed to previous versions of TLS, all ciphers are modelled as "Authenticated Encryption with Additional Data" (AEAD) {{RFC5116}}. AEAD functions provide a unified encryption and authentication operation which turns plaintext into authenticated ciphertext and back again. AEAD ciphers take as input a single key, a nonce, a plaintext, and "additional data" to be included in the authentication check, as described in Section 2.1 of {{RFC5116}}. The key is either the client_write_key or the server_write_key. struct { ContentType type; ProtocolVersion version; uint16 length; opaque nonce_explicit[SecurityParameters.record_iv_length]; aead-ciphered struct { opaque content[TLSPlaintext.length]; } fragment; } TLSCiphertext; " In July 2012, NIST revised SP800-57, which provides guidance for cryptographic key management. The publication disallows creation of digital signatures with a hash security lower than 112-bits after 2013. The previous revision from 2007 specified the cutoff to be the end of 2010. I would say that 128-bit AEAD tags with 16KB block message authentication tags are in the order of <=112 bits security and count as signatures and are subject to this new minimum? so it makes sense to find a way to raise it back to 192 (as with SHA2-384). === Comment: CipherSpecs. I think removing CipherSpecs and replacing them with a composition based approach may reduce both spec and implementation complexity and allow better expression of security strength factor (ssf) that could be used as a tag to specify acceptable combinations of cryptographic primitives in ClientHello and ServerHello, rather than have a combinatorial explosion of CipherSpecs. Propose to remove CipherSpec and replace it with a simpler system based on composition of various cryptographic primitives at the expense of a few more bytes in the (Client|Server)Hello. Here is a sketch of a possible CipherSuite replacement for a TLSv1.x (Client|Server)Hello. Note, it is just a sketch. === Replacement idea for CipherSpec and CipherSuites section of ClientHello/ServerHello { 4, 0 } === enum SpecComponent { tls_security_strength, tls_key_exchange_algorithm, tls_verify_algorithm, tls_prf_algorithm, tls_record_protection_algorithm }; enum SecurityStrengthFactor { tls_ssf_null, tls_ssf_56, tls_ssf_112, tls_ssf_168 }; enum KeyExchangeAlgorithm { tls_kex_null, tls_kex_FFDHE, tls_kex_ECDHE }; enum VerifyAlgorithm { tls_verify_null, tls_verify_RSA, tls_verify_EdDSA }; enum SignatureAlgorithm { rsa2048, rsa3072, rsa4096, rsa6072, rsa8192, ed25519, ed41417 }; enum PRFAlgorithm { tls_prf_sha2_256 }; enum AuthenticationAlgorithm { tls_hmac_null, tls_hmac_sha2_256, tls_hmac_sha2_384, tls_hmac_sha2_512, tls_hmac_sha3_256, tls_hmac_sha3_384, tls_hmac_sha3_512 }; enum ProtectionType { tls_aead_null_hmac, tls_aead_aead_null, tls_aead_aead_etm }; enum ProtectionAlgorithm { aes_gcm, aes_ccm, camellia_gcm, chacha20_poly1305 }; struct SecurityStrengthList { SecurityStrengthFactor security_strength_list<1...n> }; struct KeyExchangeAlgorithmSpec { KeyExchangeAlgorithm key_exchange_algorithm, SecurityStrengthFactor ssf; NamedGroup group }; struct KeyExchangeAlgorithmList { KeyExchangeAlgorithmSpec key_exchange_algorithm_list<1...n> }; struct VerifyAlgorithmSpec { VerifyAlgorithm verify_algorithm, SecurityStrengthFactor ssf; SignatureAlgorithm signature_algorithm; }; struct VerifyAlgorithmList { VerifyAlgorithmSpec verify_algorithm_list<1...n> }; struct RecordProtectionAlgorithmSpec { ProtectionType protection_type; SecurityStrengthFactor ssf; ProtectionAlgorithm protection_algorithm; uint16 key_bits; AuthenticationAlgorithm additional_authentication_algorithm; }; struct RecordProtectionAlgorithmList { RecordProtectionAlgorithmSpec record_protection_algorithm_list<1...n> }; /* * This is just an example... * * Note: ssf tag value is notional and its purpose is to tag * compatible combinations of primitives. * AEAD 128 bit ciphers with 128 tags and current algorithms * labeled notional tls_ssf_56 * Note: AEAD 256-bit ciphers using ETM[aead-cipher,hmac_sha2_256] * labeled notional tls_ssf_168 * Note: ssf tag value would need to be pinned to each cryptographic * primitive in the spec so that during protocol negotiation, a * primitive can only be downgraded. This improves the status quo * and give operators an active mitigation strategy. The ssf is * protected by the tamper resistance of the handshake record protocol * assuming NULL_NULL AEAD is replaced by NULL_HMAC_SHA2_256 AEAD. * * tls_security_strength = sizeof(uint16) * (3 * 1 + 2) = 10 bytes * tls_key_exchange = sizeof(uint16) * (7 * 3 + 2) = 46 bytes * tls_verify_algorithm = sizeof(uint16) * (5 * 4 + 2) = 44 bytes * tls_prf_algorithm = sizeof(uint16) * (2 * 1 + 2) = 8 bytes * tls_record_protection = sizeof(uint16) * (11 * 5 + 2) = 114 bytes * total = a measly 140 bytes */ { tls_security_strength, length=3 tls_ssf_56, tls_ssf_112, tls_ssf_168, tls_key_exchange_algorithm, length=7 tls_kex_FFDHE tls_ssf_56, ffdhe2048, tls_kex_FFDHE, tls_ssf_112, ffdhe4096, tls_kex_FFDHE, tls_ssf_168, ffdhe8192, tls_kex_ECDHE, tls_ssf_56, secp256r1, tls_kex_ECDHE, tls_ssf_112, secp521r1, tls_kex_ECDHE, tls_ssf_112, curve25519, tls_kex_ECDHE, tls_ssf_168, curve41417, tls_verify_algorithm, length=5 tls_verify_RSA, tls_ssf_56, rsa2048, sha2_128, tls_verify_RSA, tls_ssf_112, rsa4096, sha2_256, tls_verify_RSA, tls_ssf_168, rsa8192, sha2_512, tls_verify_EdDSA, tls_ssf_112, ed25519, sha2_512, tls_verify_EdDSA, tls_ssf_168, ed41417, sha2_512, tls_prf_algorithm, length=2 tls_prf_sha2_256, tls_prf_sha3_256, tls_record_protection_algorithm, length=11 tls_aead_aead_null, tls_ssf56, aes_gcm, 128, hmac_null, tls_aead_aead_null, tls_ssf56, aes_ccm, 128, hmac_null, tls_aead_aead_null, tls_ssf56, camellia_gcm, 128, hmac_null, tls_aead_aead_null, tls_ssf112, aes_gcm, 256, hmac_null, tls_aead_aead_null, tls_ssf112, aes_ccm, 256, hmac_null, tls_aead_aead_null, tls_ssf112, camellia_gcm, 256, hmac_null, tls_aead_aead_null, tls_ssf112, chacha20_poly1305, 256, hmac_null, tls_aead_aead_etm, tls_ssf168, aes_gcm, 256, hmac_sha2_256, tls_aead_aead_etm, tls_ssf168, aes_ccm, 256, hmac_sha2_256, tls_aead_aead_etm, tls_ssf168, camellia_gcm, 256, hmac_sha2_256, tls_aead_aead_etm, tls_ssf168, chacha20_poly1305, 256, hmac_sha2_256, } This type of composition scheme makes more sense than a combinatorial explosion of CipherSpecs with security and integrity levels inflexibly tied together, that do not necessarily accurately represent their respective strengths, such as in the case of AES_256_GCM_SHA384 where authentication is limited to 128 bits. CipherSpecs also further limit the policy combination of security components as an attack mitigation strategy that allows substitution of individual cryptographic primitives. A simple constraints solver could pick a combination of primitives that satisfies a mutual minimum or maximum ssf based on order. === Comment: add This proposal would allow 384bit message authentication such as the 128-bit AEAD tag plus optionally using ETM-AEAD[aead-cipher,hmac_sha2_256] which passes the AD to an HMAC as well as the AEAD cipher, and this would be consistent with using ETM-AEAD[null,hmac_sha2_256] with (client|server)_random to make the handshake messages tamper resistant. i.e. prevent handshake from being be re-written by proxies as (client|server)_random is used for pre-master key derivation. === The reason to allow specification of the HMAC for an ETM_AEAD in a revised compositional approach to protection algorithms is to avoid explosion of AEAD ciphers definitions with variants that have stronger authentication tags. This would quickly become problematic with the current CipherSpec scheme. Note what I have sketched out above is quite pessimistic with respect to the security strength of present algorithms given a review of recent literature. Consider it more of an engineering perspective with a relative knowledge of the security parameters of the underlying cryptographic primitives. Consider the ssf the margin of attack reach, i.e. a notional strength. And yes, the MAC in the current Cipher Specs at present is a little misleading (AES_256_GCM_SHA384) and I see elsewhere that it was mentioned that it should be removed. A composition based approach adds clarity.Does TLSv1.3 (or TLSv2.0) even need CipherSpecs given they could be supported via backwards compatibility in an implementations offering TLSv1.2? An implementations needs tables internally to expand to the various cryptographic primitives from the selected CipherSuites and the spec and extensions seem to be moving towards a compositional approach in other areas (named groups), so it may make things simpler. Should TLSv1.3 (Client/Server)Hello be re-designed to remove CipherSpec and use a simple system based on composition of cryptographic components linked by notional security strength tags? === Comment: I note that ChangeCipherSpec is mentioned as removed in the introductory notes but is still listed later in the spec (draft-ietf-tls-tls13 / Change Cipher Specs Message): === ## Change Cipher Specs Message struct { enum { change_cipher_spec(1), (255) } type; } ChangeCipherSpec; Conclusions * Adding sha3_ and using sha2_ prefixes on the existing SHA2 and new SHA3 constants adds mitigation capabilities to mitigate vulnerabilities in hashes as per the reasoning behind SHA-3. SHA-2 hashes can be specified as mandatory. * All handshake messages should use AEAD NULL_HMAC_SHA2_256 AEAD using (client|server)_random as AD to mitigate MITM handshake message tampering * Adding a meta AEAD using cipher AEAD tag plus HMAC to extend message authentication integrity is practical with the present cryptographic primitives and could meet the AEAD requirements in Record Payload Protection section, by abstraction, and increase authentication bits beyond 128 for application data. * Current CipherSpec and CipherSuites could be revisited to avoid the combinatorial explosion that exists with the current scheme. Design for composition. * Current CipherSpec and CipherSuites limits flexibility for attack mitigation by limiting the ability to substitute or downgrade a compromi sed cryptographic primitive if it becomes vulnerable due to how they are currently tied together in CipherSuites. Design for mitigation. * A composition based cipher spec in the ClientHello and ServerHello adds mitigation capabilities to operators via configuration (downgrade cryptographic primitives) and might reduce implementation complexity for a TLSv1.3 (or TLSv2.0) that favors security over backwards compatibility. * Randomizing lower 48 bits of sequence number would lower the predictability of AD in content messages and not add wrap issues. Initial sequence number would need to be shared in the signed (Client|Server)Hello handshake messages * Add the ability for blinding countermeasures. e.g. allow adding 32 random bytes to AD in record protocol. ~0.1% of 16KB blocks to thwart AD dictionary attacks for message forgery. It could be designed symmetrically with the handshake random data and HMAC to prevent handshake tampering. i.e. make a provision for 32 random data bytes in the record protocol, then the same framing could be used for (client|server)_random to authenticate handshake messages. i.e. ETM-AEAD[null,hmac_sha2_256] for handshake messages. Packet length blinding to consider too? Just putting my comments out there. Many of these issues have been mentioned elsewhere and in academic papers. I though I would share a compilation of my own analysis as it might be useful. I believe that handshake rewriting via proxy is well-known public knowledge. Big-IP's SSL proxy does part of this already and could be augmented with assistance from a friendly neighborhood CA (without public audit records). Google "implementing proxy ssl". A perfect place to drop-in online attacks on RSA keys, DH parameters, or downgrading clients to TLS_RSA_WITH_RC4_128_MD5 (many clients and servers still support this) to record streams and work on cracking them offline, etc... I think it is a biggie. Otherwise someone tell me how a layer 2/3 transparent proxy can't fiddle with cipher advertisements in a ClientHello in TLSv1.2? What am I missing? There is no AD and HMAC on handshake messages in the spec and I can't see them in Wireshark. I guess I'll have to finish my proxy and try rewriting ClientHellos and see for myself... Michael. From nobody Tue Jan 6 05:31:22 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1301A6F27 for ; Tue, 6 Jan 2015 05:31:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.468 X-Spam-Level: X-Spam-Status: No, score=-1.468 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, 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 mxMUtdVpsuDx for ; Tue, 6 Jan 2015 05:31:16 -0800 (PST) Received: from klaatu.metaparadigm.com (klaatu.metaparadigm.com [67.207.128.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA2201A6EDC for ; Tue, 6 Jan 2015 05:31:16 -0800 (PST) Received: from monty.local (unknown.maxonline.com.sg [58.182.90.50] (may be forged)) (authenticated bits=0) by klaatu.metaparadigm.com (8.14.4/8.14.4/Debian-4) with ESMTP id t06DplwE002684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 6 Jan 2015 13:51:50 GMT DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=metaparadigm.com; s=klaatu; t=1420552311; bh=Q2gu3W6G2sSdHgaD0NC4UPIf4mKlgb/z+77A9FtLo8M=; h=Date:From:To:Subject:References:In-Reply-To:From; b=hleQGK0TwThcqgCRWcyTwJRupeJlMD4O+jCrvNCaXWYgqXr4pcT3MbHhFi7jrg8Bi GjjmrcOgaOMaMHk5/hlQr0NVCmc0MMuTvjlnCknIJfmNYLeWl9Biu30ddMFWwsmjhl n/oa6q0SmJGy2VG+5lpcbdcsoHwvUGWJMiNWUXGo= Message-ID: <54ABE365.70300@metaparadigm.com> Date: Tue, 06 Jan 2015 21:30:13 +0800 From: Michael Clark Organization: Metaparadigm Pte Ltd User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Peter Gutmann , "" References: <9A043F3CF02CD34C8E74AC1594475C73AAF525A9@uxcn10-tdc05.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAF525A9@uxcn10-tdc05.UoA.auckland.ac.nz> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.98.4 at klaatu.metaparadigm.com X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/tls/_dDBus4EtqOn8mwdNrlaGPf363E Subject: Re: [TLS] AAED ciphers: AES-GCM vs AES-EAX/AES-CCM: a meta-analysis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 13:31:21 -0000 On 6/1/15 6:24 pm, Peter Gutmann wrote: > Michael Clark writes: > >> A TLSv1.3 ClientHello and ServerHello extensions could advertise something >> like this this: > Ugh, not, we don't need yet more extensions and complexity, we just need a > single set of options that everyone uses (see Grigg's Law, "There is only one > cipher suite and that is #1"). I have some alternative ideas. You probably won't like them ;-) There are different dimensions of simplicity and complexity relating to composition and layering. I think the worst problem with TLS is supporting backwards compatibility. There is a possibility to add symmetry and reduce complexity. I just posted about HMAC on handshakes and some other comments, that may actually mean Encrypt-then-MAC is needed, and you just have hmac_null in the common case where you are satisfied with the 128-bit tag from the AEAD cipher. * handshake ETM-AEAD[null,hmac_sha2_256] * application data ETM-AEAD[aead-cipher,hmac_null] * application data with extended authentication ETM-AEAD[aead-cipher,hmac_sha2_256] From nobody Tue Jan 6 16:29:17 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 162FE1A8830 for ; Tue, 6 Jan 2015 16:29:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, 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 eLgYK9iKMdnq for ; Tue, 6 Jan 2015 16:29:14 -0800 (PST) Received: from klaatu.metaparadigm.com (klaatu.metaparadigm.com [67.207.128.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 805211A882D for ; Tue, 6 Jan 2015 16:29:14 -0800 (PST) Received: from monty.local (unknown.maxonline.com.sg [58.182.90.50] (may be forged)) (authenticated bits=0) by klaatu.metaparadigm.com (8.14.4/8.14.4/Debian-4) with ESMTP id t070ocji006933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 7 Jan 2015 00:50:41 GMT DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=metaparadigm.com; s=klaatu; t=1420591843; bh=9KNn0RdZ+pdyANtC5hWrJCLrLdoDqx3QuswAumCGpG4=; h=Date:From:To:Subject:References:In-Reply-To:From; b=YNsGlmzLySKxPHF6sxD797i/spuHUOHrGmuKv5W9AmaFIApcEXYOu9Vx+aDA6CwvF PgrkehJoCyTY+OrdCXCw6SSaEoRNHp8nLxr+5iXOgqupW2GdLku6aIpFB436EEJNGM sGD0s1m1gsTA/1jYSk8rz0yXyDwJL/lmDgUGRwT8= Message-ID: <54AC7DCF.6070302@metaparadigm.com> Date: Wed, 07 Jan 2015 08:29:03 +0800 From: Michael Clark Organization: Metaparadigm Pte Ltd User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: tls@ietf.org References: <54A252EA.1010905@iki.fi> <2348107.Lj21YcAO1u@pintsize.usersys.redhat.com> <54ABE1D2.7090601@metaparadigm.com> In-Reply-To: <54ABE1D2.7090601@metaparadigm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.98.4 at klaatu.metaparadigm.com X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/tls/VPrisYM2AIjrqQeahw1umUAY-gM Subject: Re: [TLS] Spec tls13 comments, handshake tampering, mitigation, counter/seq_no predictability: WAS: Do we need DH? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 00:29:16 -0000 > tls_record_protection_algorithm, length=11 > tls_aead_aead_null, tls_ssf56, aes_gcm, 128, hmac_null, > tls_aead_aead_null, tls_ssf56, aes_ccm, 128, hmac_null, > tls_aead_aead_null, tls_ssf56, camellia_gcm, 128, hmac_null, > tls_aead_aead_null, tls_ssf112, aes_gcm, 256, hmac_null, > tls_aead_aead_null, tls_ssf112, aes_ccm, 256, hmac_null, > tls_aead_aead_null, tls_ssf112, camellia_gcm, 256, hmac_null, > tls_aead_aead_null, tls_ssf112, chacha20_poly1305, 256, hmac_null, > tls_aead_aead_etm, tls_ssf168, aes_gcm, 256, hmac_sha2_256, > tls_aead_aead_etm, tls_ssf168, aes_ccm, 256, hmac_sha2_256, > tls_aead_aead_etm, tls_ssf168, camellia_gcm, 256, hmac_sha2_256, > tls_aead_aead_etm, tls_ssf168, chacha20_poly1305, 256, hmac_sha2_256, These ciphers are essentially the four AEAD ciphers that have existing IETF RFCs or drafts. CCM is a valid AEAD cipher choice and fits within the draft framework. However my earlier comment was that EAX (a NIST candidate) has complementary properties and a security proof. EAX2, the foundation for AES_EAX provides a generalized framework for Encypt-then-MAC i.e. EAX2[AES,OMAC2[AES]] I'm not attached to any of the ciphers and don't have an interest in CCM, other than having a choice of 3 AEAD ciphers, and one of them from NTT would be good. My conclusion on reading the literature was that EAX has better properties than CCM, despite its slightly longer key setup time (less then GCM) and equivalent performance to CCM. CCM is more like CBC mode with MAC whereas EAX is more like CTR mode (GCM) with IV increased entropy in the counter and the use of an alternative cipher based MAC, making it complementary to the current suite. AES_EAX has similar design properties to chacha20_poly1305 (poly1305 being a cipher based MAC based on AES security proof). This would be my revised list removing CCM and including the NTT alternative and chacha20_poly1305, both having IETF drafts (and losing interest in EAX): tls_record_protection_algorithm, length=8 tls_aead_aead_null, tls_ssf56, aes_gcm, 128, hmac_null, tls_aead_aead_null, tls_ssf56, camellia_gcm, 128, hmac_null, tls_aead_aead_null, tls_ssf112, aes_gcm, 256, hmac_null, tls_aead_aead_null, tls_ssf112, camellia_gcm, 256, hmac_null, tls_aead_aead_null, tls_ssf112, chacha20_poly1305, 256, hmac_null, tls_aead_aead_etm, tls_ssf168, aes_gcm, 256, hmac_sha2_256, tls_aead_aead_etm, tls_ssf168, camellia_gcm, 256, hmac_sha2_256, tls_aead_aead_etm, tls_ssf168, chacha20_poly1305, 256, hmac_sha2_256, 1). if there are no AEAD ciphers with > 128-bit MACS, what is the message forgery mitigation proposal for TLS application data? 2). is there consideration of an AEAD-ETM[null,hmac] for authentication of handshake messages? i.e. handshake forgery mitigation proposal. The random used for key derivation would need to be a constant AD on all handshake messages to mitigate against handshake tampering. i.e. authenticated handshake. AEAD-ETM[aaed-cipher,hmac] would fall out of adding authentication to the record protection layer and provide for extended authentication on application data. These were my main concerns for draft-tls13. The observation is that with the scope of global eCommerce, that handshake tampering capabilities provide more harm than good. It pays more to be merciful than mercenary when the core issue is protection of public data (business and consumer). It is a farcical stance to deny this protection if it is well known (as it is) that our eCommerce handshakes can be tampered with by *any* ISP in any jurisdiction (with or without the approval of various national affiliations). Michael Clark Independent. From nobody Wed Jan 7 01:21:38 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B38FF1A898C for ; Wed, 7 Jan 2015 01:21:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, 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 qJXtbzkjKG3h for ; Wed, 7 Jan 2015 01:21:33 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 938181A1BD9 for ; Wed, 7 Jan 2015 01:21:33 -0800 (PST) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t079LWGR024091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 7 Jan 2015 04:21:32 -0500 Received: from dhcp-2-127.brq.redhat.com (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t079LUMG017253 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 7 Jan 2015 04:21:31 -0500 Message-ID: <1420622490.7097.36.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Michael Clark Date: Wed, 07 Jan 2015 10:21:30 +0100 In-Reply-To: <54AC7DCF.6070302@metaparadigm.com> References: <54A252EA.1010905@iki.fi> <2348107.Lj21YcAO1u@pintsize.usersys.redhat.com> <54ABE1D2.7090601@metaparadigm.com> <54AC7DCF.6070302@metaparadigm.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/gfLyEFwv0xo0gnMxKKqCXP3jMx8 Cc: tls@ietf.org Subject: Re: [TLS] Spec tls13 comments, handshake tampering, mitigation, counter/seq_no predictability: WAS: Do we need DH? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 09:21:37 -0000 On Wed, 2015-01-07 at 08:29 +0800, Michael Clark wrote: > These ciphers are essentially the four AEAD ciphers that have existing > IETF RFCs or drafts. CCM is a valid AEAD cipher choice and fits within > the draft framework. > However my earlier comment was that EAX (a NIST candidate) has > complementary properties and a security proof. EAX2, the foundation for > AES_EAX provides a generalized framework for Encypt-then-MAC i.e. > EAX2[AES,OMAC2[AES]] > I'm not attached to any of the ciphers and don't have an interest in > CCM, other than having a choice of 3 AEAD ciphers, and one of them from > NTT would be good. My conclusion on reading the literature was that EAX > has better properties than CCM, despite its slightly longer key setup > time (less then GCM) and equivalent performance to CCM. CCM is more like > CBC mode with MAC whereas EAX is more like CTR mode (GCM) with IV > increased entropy in the counter and the use of an alternative cipher > based MAC, making it complementary to the current suite. I also prefer EAX to CCM. CCM is a very special and limited AEAD mode (e.g., it needs to know the size of the encrypted data in advance), and I'd avoid using it when possible. regards, Nikos From nobody Wed Jan 7 06:23:52 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADEE11A902D for ; Wed, 7 Jan 2015 06:23:49 -0800 (PST) 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 dOMFJCeboWVW for ; Wed, 7 Jan 2015 06:23:47 -0800 (PST) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c: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 8DBD91A6F34 for ; Wed, 7 Jan 2015 06:23:47 -0800 (PST) Received: by mail-we0-f169.google.com with SMTP id m14so1259824wev.14 for ; Wed, 07 Jan 2015 06:23:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:message-id:mime-version:subject:date:references :to:in-reply-to; bh=evrIx6hpdMaMc93tdOXRHSrGtcLcWImrFZzBoMxvqTY=; b=yscV+NIKohmohaWFf+FY8mGeMpN349PaC8MWkDW7DE8N1mgpsw0skW11HNMecJjD85 DmR/+2CB0ZI22aptDDC17JJ/W6C2cGJZgBZpBsD1dCpeyOFVkIt3UIUj86LUGbLuYTFd DYeFX3iqJYQwvXdmgs3BQwWLDKWBK7dFdGar1aqhAWEeQ2LL91HMOmIBuCyR4f0EzTdf Fh1gYWJPagH7BpkBCRCr4VeWs0CmExLsvsS4HxlR2vMLkQ0XAdhy1ecz842oIPUB6XK5 n6GUp4ushSFL1x04uqkMmvPlBXbP5FwhY4RnT+NN4E+Dv6qhMPHzpE9Fv4eUhOW+UUpU 2FJw== X-Received: by 10.180.72.178 with SMTP id e18mr47609247wiv.23.1420640625936; Wed, 07 Jan 2015 06:23:45 -0800 (PST) Received: from [172.24.249.55] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id a1sm2312688wjx.28.2015.01.07.06.23.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 07 Jan 2015 06:23:45 -0800 (PST) From: Yoav Nir Content-Type: multipart/alternative; boundary="Apple-Mail=_91749EDB-8B5F-40B4-A764-058BA274999B" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Date: Wed, 7 Jan 2015 16:23:43 +0200 References: <274716D0-EC91-4131-A8F7-CD13A9B42CE7@gmail.com> To: "TLS@ietf.org (tls@ietf.org)" In-Reply-To: <274716D0-EC91-4131-A8F7-CD13A9B42CE7@gmail.com> X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/TDBoHv8ug3n8LKUke9hIVXv2XHU Subject: Re: [TLS] RFC4492bis - Removing ECDH X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 14:23:49 -0000 --Apple-Mail=_91749EDB-8B5F-40B4-A764-058BA274999B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi. I realize this was sent right in the middle of the holiday season, so = I=E2=80=99ll give it another try. Please have a look at the pull request and post comments to the list = about whether you=E2=80=99re fine with removing ECDH. Thanks Yoav > On Dec 16, 2014, at 12:29 AM, Yoav Nir wrote: >=20 > Hi. >=20 > I=E2=80=99ve created pulll request #2 for removing references to ECDH = (static elliptic curve key) key exchange and ciphersuites. >=20 > https://github.com/tlswg/rfc4492bis/pull/2 = >=20 > Nikos suggested it here: = http://www.ietf.org/mail-archive/web/tls/current/msg14555.html = > Yes, there are other suggestions there, but I=E2=80=99d like to take = them one by one. >=20 > Let me know what you think >=20 > Yoav >=20 --Apple-Mail=_91749EDB-8B5F-40B4-A764-058BA274999B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi.

I = realize this was sent right in the middle of the holiday season, so = I=E2=80=99ll give it another try.

Please have a look at the pull request = and post comments to the list about whether you=E2=80=99re fine with = removing ECDH.

Thanks

Yoav

On Dec 16, 2014, at 12:29 AM, = Yoav Nir <ynir.ietf@gmail.com> wrote:

Hi.

I=E2=80=99ve created = pulll request #2 for removing references to ECDH (static elliptic curve = key) key exchange and ciphersuites.

https://github.com/tlswg/rfc4492bis/pull/2

Nikos suggested it = here: http://www.ietf.org/mail-archive/web/tls/current/msg14555.html<= /a>
Yes, there are other suggestions there, but = I=E2=80=99d like to take them one by one.

Let me know what you think

Yoav


= --Apple-Mail=_91749EDB-8B5F-40B4-A764-058BA274999B-- From nobody Wed Jan 7 13:41:07 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92E251A6EEC for ; Wed, 7 Jan 2015 13:41:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, 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 l1N2i_1g6Kxb for ; Wed, 7 Jan 2015 13:41:04 -0800 (PST) Received: from mail.voltage.com (mail.voltage.com [71.6.108.2]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75AA11A6F03 for ; Wed, 7 Jan 2015 13:41:04 -0800 (PST) Received: from HQMAILSVR02.voltage.com (unknown [172.16.0.6]) by mail.voltage.com with smtp (TLS: TLSv1/SSLv3,128bits,AES128-SHA) id 10c5_153b_6335d0fb_2b9b_45f4_a776_d48b8fc45362; Wed, 07 Jan 2015 05:42:39 -0800 Received: from HQMAILSVR02.voltage.com ([::1]) by HQMAILSVR02.voltage.com ([::1]) with mapi; Wed, 7 Jan 2015 13:40:57 -0800 From: Tom Wu To: Watson Ladd , "tls@ietf.org" Date: Wed, 7 Jan 2015 13:40:56 -0800 Thread-Topic: [TLS] Comments on PR #95 Thread-Index: AdAfv4zT0aeLlharSiGPRe9jRI7M5gLApFBw Message-ID: <0607259810418348811F3A862D51E8856FADDE41D4@HQMAILSVR02.voltage.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/bCgLKNuGgNjW57-2WT0CF-P2Utc Subject: Re: [TLS] Comments on PR #95 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 21:41:05 -0000 > Line 1912: Was anyone using SRP? The more generic we have to make TLS 1.3= , and the more we > have to shoehorn in, the more complex it gets. > This open issue could get hairy. SRP is definitely useful, as it's the only PAKE ciphersuite available in TL= S. What exactly are the interactions that need to be worked out with PSK a= nd SRP? Tom From nobody Wed Jan 7 14:36:37 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 319721A1B93 for ; Wed, 7 Jan 2015 14:36:32 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 0klFKidU3C86 for ; Wed, 7 Jan 2015 14:36:29 -0800 (PST) Received: from emh01.mail.saunalahti.fi (emh01.mail.saunalahti.fi [62.142.5.107]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A82D81A1BA3 for ; Wed, 7 Jan 2015 14:36:29 -0800 (PST) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id 664CD90029; Thu, 8 Jan 2015 00:36:26 +0200 (EET) Date: Thu, 8 Jan 2015 00:36:26 +0200 From: Ilari Liusvaara To: Tom Wu Message-ID: <20150107223626.GA20002@LK-Perkele-VII> References: <0607259810418348811F3A862D51E8856FADDE41D4@HQMAILSVR02.voltage.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <0607259810418348811F3A862D51E8856FADDE41D4@HQMAILSVR02.voltage.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: http://mailarchive.ietf.org/arch/msg/tls/FzfQ7R1RhwdXbCEfapxpJ6yhHa4 Cc: "tls@ietf.org" Subject: Re: [TLS] Comments on PR #95 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 22:36:32 -0000 On Wed, Jan 07, 2015 at 01:40:56PM -0800, Tom Wu wrote: > > Line 1912: Was anyone using SRP? The more generic we have to make TLS > > 1.3, and the more we > have to shoehorn in, the more complex it gets. > > This open issue could get hairy. > > SRP is definitely useful, as it's the only PAKE ciphersuite available > in TLS. What exactly are the interactions that need to be worked out > with PSK and SRP? AFAIK, There issues are: 1) None of the groups defined for TLS are compatible with SRP. 2) Server will encrypt first (in TLS 1.2, client encrypted first). This may have cryptographic implications on SRP (and those are beyond my ability to analyze). 3) PSK has identities and identity hints. A solution for 1) If server selected SRP ciphersuite, it deems client to have missed a group guess. The message about this includes the SRP group parameters, and client then transmits its nonce public key (with some fixed group number, the server knows the group). A solution for 3) If server selected PSK ciphersuite and client asked for a hint, deem client to have missed the group guess. The message about this includes hint about the identity. The client then transmits its final identity (if doing "remedials", one could perhaps just miss the identity and transmit it as a special handshake message). -Ilari From nobody Wed Jan 7 15:36:29 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20DA41A7D81 for ; Wed, 7 Jan 2015 15:36:25 -0800 (PST) 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 wHF_prkLLdFX for ; Wed, 7 Jan 2015 15:36:23 -0800 (PST) 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 2D55E1A7026 for ; Wed, 7 Jan 2015 15:36:23 -0800 (PST) Received: by mail-yh0-f44.google.com with SMTP id c41so1128079yho.17 for ; Wed, 07 Jan 2015 15:36:22 -0800 (PST) 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=hHWRckVGkTvyvaN4RM69tOhJIj3AXkHicGdh54Npgvg=; b=Qu26+K5ecIc73xGoxHcTs6/ivZLSXNHSxVtMBRMQ2rA8Vj7FtKfbuuwe6cHwItnKdU EDX9HImVD7nR0cadZJRN6+fyxVBZhubVKEY01jP/rL05c9BtAd+yFLhsyPJrkqnH/NQW njKViLdTNu3KGNJRrftG7W8lds8FN3PsM8F2smqOqA982zUAOPjRFdiY+tTfpxH71uXF Ij3ctMpJgmg/3ZqiopkVmO8b/ayIF3nkv7l2X9F7PwLT79eoxKptK0KPFgq4M3/Zoxvn 0Zt+V9FCnks8XrIDHc38DspUII7Qpkf5INPbS4VBr8uikU+44OTu2z7wgKGhzIpvb6CP 9obQ== MIME-Version: 1.0 X-Received: by 10.170.89.130 with SMTP id g124mr4703742yka.24.1420673782341; Wed, 07 Jan 2015 15:36:22 -0800 (PST) Received: by 10.170.207.6 with HTTP; Wed, 7 Jan 2015 15:36:22 -0800 (PST) In-Reply-To: <0607259810418348811F3A862D51E8856FADDE41D4@HQMAILSVR02.voltage.com> References: <0607259810418348811F3A862D51E8856FADDE41D4@HQMAILSVR02.voltage.com> Date: Wed, 7 Jan 2015 18:36:22 -0500 Message-ID: From: Watson Ladd To: Tom Wu Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/hALCMc3Ow-0I02Ab30jPDKALuYc Cc: "tls@ietf.org" Subject: Re: [TLS] Comments on PR #95 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 23:36:25 -0000 On Wed, Jan 7, 2015 at 4:40 PM, Tom Wu wrote: >> Line 1912: Was anyone using SRP? The more generic we have to make TLS 1.3, and the more we > have to shoehorn in, the more complex it gets. >> This open issue could get hairy. > > SRP is definitely useful, as it's the only PAKE ciphersuite available in TLS. What exactly are the interactions that need to be worked out with PSK and SRP? SRP in TLS is inherently 2-RTT as implemented now: the client sends a username, the server a key exchange response, and the client its response, at which point a key can be computed. But the server sends parameters that client uses for the exchange in their message. It may be possible to change this, having the client pick the group, send identity and A in the first message, and server respond with everything else for the PMS in the second message. Doesn't help with identity hints. Sincerely, Watson Ladd > > Tom From nobody Wed Jan 7 18:22:00 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2641A1AC3 for ; Wed, 7 Jan 2015 18:21:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.467 X-Spam-Level: X-Spam-Status: No, score=-1.467 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, 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 KTtIv8Lam-iT for ; Wed, 7 Jan 2015 18:21:56 -0800 (PST) Received: from klaatu.metaparadigm.com (klaatu.metaparadigm.com [67.207.128.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E4F31A1A7D for ; Wed, 7 Jan 2015 18:21:56 -0800 (PST) Received: from monty.local (unknown.maxonline.com.sg [58.182.90.50] (may be forged)) (authenticated bits=0) by klaatu.metaparadigm.com (8.14.4/8.14.4/Debian-4) with ESMTP id t082hJBo010965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 8 Jan 2015 02:43:22 GMT DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=metaparadigm.com; s=klaatu; t=1420685005; bh=3SGVGmuU6OvO6hGVUbBixPP4y1gpLFVd9Jcvn/mVv/c=; h=Date:From:To:Subject:References:In-Reply-To:From; b=ioiYloSwfYGGyijuCld7wj1EJHoYo24Ww62fvAaiZNKUkDYRV40cbEgJmtGcjaqiB EMu678/yNwiCePWnwlIIXibHdWBzSFwcJ7eBgcRjSdiDWinIKJYif6byF1q5DZSu3u 9Bv1YfmLNirwlSQv/1AkuROkoRHT4ByNYvBiBWDM= Message-ID: <54ADE9B6.4080700@metaparadigm.com> Date: Thu, 08 Jan 2015 10:21:42 +0800 From: Michael Clark Organization: Metaparadigm Pte Ltd User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Yoav Nir , "TLS@ietf.org (tls@ietf.org)" References: <274716D0-EC91-4131-A8F7-CD13A9B42CE7@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030905070003070900010104" X-Virus-Scanned: clamav-milter 0.98.4 at klaatu.metaparadigm.com X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/tls/lJ9GjthKIK9YoG4k7dsBO7EMv5U Subject: Re: [TLS] RFC4492bis - Removing ECDH X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 02:21:58 -0000 This is a multi-part message in MIME format. --------------030905070003070900010104 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, After spending 14 years in Asia I get mixed up with holidays and started calling them Solstice holidays and Lunar holidays (Feb 19th this year). I'm hoping I can have a break in the Lunar New Year. My family in New Zealand celebrated Solstice holidays without us... as we still trying to /Escape from Singapore/ (reminds me of Snake Plissken)... we'll make it out. We still have Internet access here. (*1,*2) ;-). Yes. You might want more consensus, however as a data point, I am in support of ephemeral key negotiation mechanisms that /in theory/ preserve forward secrecy and for removing those that leave administrators hamstrung (and aren't implemented). i.e. fine with removing ECDH. There appears to be an emerging consensus from server administrators and the certificates issued from all major vendors have "Parameters: None". In the case they were used in practice, they would make attack mitigation depend on third parties. My understanding is the DH-RSA and ECDH-(RSA|ECDSA) are practically unused and that implementations use DHE-RSA and ECDHE-(RSA|ECDSA). ECDH requires the CA to embed static named or explicit points in certificates. The practice is that implementations let server administrators choose and /sign/ *somewhat* ephemeral parameters e.g. secp256r1, secp384r1 works widely, but secp521r1 failed in my tests with Win8.1 IE11; this report matches my data point: (*3). I use the word /sign/ loosely until we have a proof that handshake messages can't be replaced in situ (*4). i.e. the client and server establish a chain of trust from their first Hellos to the pre-master secret establishment; which is possible with careful refinements to the protocol (constant salt in AD across all handshake messages). This of course then pushes an integrity problem down to another layer. i.e. DNSSEC (*5). It raises another question. Is DH_anon a misnomer? Should it be DHE_anon? Is it used anywhere in practice? Michael. [1] http://foreignpolicy.com/2014/07/29/the-social-laboratory/ [2] https://tools.ietf.org/html/rfc7258 [3] https://twitter.com/ericlaw/status/532296076670533632 [4] http://arstechnica.com/security/2015/01/gogo-issues-fake-https-certificat= e-to-users-visiting-youtube/ [5] http://www.internetsociety.org/deploy360/dnssec/maps/ On 7/1/15 10:23 pm, Yoav Nir wrote: > Hi. > > I realize this was sent right in the middle of the holiday season, so > I=92ll give it another try. > > Please have a look at the pull request and post comments to the list > about whether you=92re fine with removing ECDH. > > Thanks > > Yoav > >> On Dec 16, 2014, at 12:29 AM, Yoav Nir > > wrote: >> >> Hi. >> >> I=92ve created pulll request #2 for removing references to ECDH (stati= c >> elliptic curve key) key exchange and ciphersuites. >> >> https://github.com/tlswg/rfc4492bis/pull/2 >> >> Nikos suggested it >> here: http://www.ietf.org/mail-archive/web/tls/current/msg14555.html >> Yes, there are other suggestions there, but I=92d like to take them on= e >> by one. >> >> Let me know what you think >> >> Yoav >> --------------030905070003070900010104 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi,

After spending 14 years in Asia I get mixed up with holidays and started calling them Solstice holidays and Lunar holidays (Feb 19th this year). I'm hoping I can have a break in the Lunar New Year. My family in New Zealand celebrated Solstice holidays without us... as we still trying to /Escape from Singapore/ (reminds me of Snake Plissken)... we'll make it out. We still have Internet access here. (*1,*2) ;-).

Yes. You might want more consensus, however as a data point, I am in support of ephemeral key negotiation mechanisms that /in theory/ preserve forward secrecy and for removing those that leave administrators hamstrung (and aren't implemented). i.e. fine with removing ECDH. There appears to be an emerging consensus from server administrators and the certificates issued from all major vendors have "Parameters: None". In the case they were used in practice, they would make attack mitigation depend on third parties.

My understanding is the DH-RSA and ECDH-(RSA|ECDSA) are practically unused and that implementations use DHE-RSA and ECDHE-(RSA|ECDSA). ECDH requires the CA to embed static named or explicit points in certificates. The practice is that implementations let server administrators choose and /sign/ *somewhat* ephemeral parameters e.g. secp256r1,  secp384r1 works widely, but secp521r1 failed in my tests with Win8.1 IE11; this report matches my data point: (*3). I use the word /sign/ loosely until we have a proof that handshake messages can't be replaced in situ (*4). i.e. the client and server establish a chain of trust from their first Hellos to the pre-master secret establishment; which is possible with careful refinements to the protocol (constant salt in AD across all handshake messages). This of course then pushes an integrity problem down to another layer. i.e. DNSSEC (*5).

It raises another question. Is DH_anon a misnomer? Should it be DHE_anon? Is it used anywhere in practice?

Michael.

[1] http://foreignpolicy.com/2014/07/29/the-social-laboratory/
[2] https://tools.ietf.org/html/rfc7258
[3] https://twitter.com/ericlaw/status/532296076670533632
[4] http://arstechnica.com/security/2015/01/gogo-issues-fake-https-certificate-to-users-visiting-youtube/
[5] http://www.internetsociety.org/deploy360/dnssec/maps/


On 7/1/15 10:23 pm, Yoav Nir wrote:
Hi.

I realize this was sent right in the middle of the holiday season, so I’ll give it another try.

Please have a look at the pull request and post comments to the list about whether you’re fine with removing ECDH.

Thanks

Yoav

On Dec 16, 2014, at 12:29 AM, Yoav Nir <ynir.ietf@gmail.com> wrote:

Hi.

I’ve created pulll request #2 for removing references to ECDH (static elliptic curve key) key exchange and ciphersuites.


Yes, there are other suggestions there, but I’d like to take them one by one.

Let me know what you think

Yoav


--------------030905070003070900010104-- From nobody Wed Jan 7 20:42:36 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48D3C1A8843 for ; Wed, 7 Jan 2015 20:42:36 -0800 (PST) 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 iKs41VKYl4bc for ; Wed, 7 Jan 2015 20:42:34 -0800 (PST) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 118FD1A1A9D for ; Wed, 7 Jan 2015 20:42:34 -0800 (PST) Received: by mail-we0-f182.google.com with SMTP id w62so416689wes.13 for ; Wed, 07 Jan 2015 20:42:32 -0800 (PST) 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=vxYeWbUVc8SRdsugsi4l1n0vpZoPTA36x7B7uWOeV9c=; b=ELO6IoUboxQw7iMKwc5vSHpgx+UGW4XOddmO0zN5intMVG1SH3RfNVAFHpNETxh4Mk FkB7vcHQ/o+1oTKO9vNAq8Wu4vuFo/2IxaDkuVTCDjGTY5ANvbIZUmO5wQg7QIJohed9 /oHviR7M5MRYnWMSOPdnKYCgrMMytero0umlmQeHnB93zwKVl0fM7lwROfx1LE3Izkbb q0TrudFiBIldt2FNpc0nGhvQLRPYhW0JXfMY2kc1FF2Vp0of+fqF0yflFG5BUEaHgYNL Ak+BP+erLiBRJF4j1Ix9e1jRzrnnbe6DqHRFOWSDppPoJ9NRMrgiTeJd6Tm2de7wfx3+ gIYQ== X-Received: by 10.194.2.240 with SMTP id 16mr14758160wjx.108.1420692152790; Wed, 07 Jan 2015 20:42:32 -0800 (PST) Received: from [192.168.1.15] ([46.120.13.132]) by mx.google.com with ESMTPSA id 18sm4487891wjr.46.2015.01.07.20.42.31 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 07 Jan 2015 20:42:32 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Yoav Nir In-Reply-To: <54ADE9B6.4080700@metaparadigm.com> Date: Thu, 8 Jan 2015 06:42:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <702F318A-FE04-45F7-8CA1-30256D628CF7@gmail.com> References: <274716D0-EC91-4131-A8F7-CD13A9B42CE7@gmail.com> <54ADE9B6.4080700@metaparadigm.com> To: Michael Clark X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/k4gwOSC1bHmjKr9iL_Bbd6cf5nY Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] RFC4492bis - Removing ECDH X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 04:42:36 -0000 Hi, Michael > On Jan 8, 2015, at 4:21 AM, Michael Clark = wrote: >=20 > Hi, >=20 > After spending 14 years in Asia I get mixed up with holidays and = started calling them Solstice holidays and Lunar holidays (Feb 19th this = year). I'm hoping I can have a break in the Lunar New Year. My family in = New Zealand celebrated Solstice holidays without us... as we still = trying to /Escape from Singapore/ (reminds me of Snake Plissken)... = we'll make it out. We still have Internet access here. (*1,*2) ;-). >=20 > Yes. You might want more consensus, however as a data point, I am in = support of ephemeral key negotiation mechanisms that /in theory/ = preserve forward secrecy and for removing those that leave = administrators hamstrung (and aren't implemented). i.e. fine with = removing ECDH. There appears to be an emerging consensus from server = administrators and the certificates issued from all major vendors have = "Parameters: None". In the case they were used in practice, they = would make attack mitigation depend on third parties. >=20 > My understanding is the DH-RSA and ECDH-(RSA|ECDSA) are practically = unused and that implementations use DHE-RSA and ECDHE-(RSA|ECDSA). ECDH = requires the CA to embed static named or explicit points in = certificates. The practice is that implementations let server = administrators choose and /sign/ *somewhat* ephemeral parameters e.g. = secp256r1, secp384r1 works widely, but secp521r1 failed in my tests = with Win8.1 IE11; this report matches my data point: (*3). I use the = word /sign/ loosely until we have a proof that handshake messages can't = be replaced in situ (*4). i.e. the client and server establish a chain = of trust from their first Hellos to the pre-master secret establishment; = which is possible with careful refinements to the protocol (constant = salt in AD across all handshake messages). This of course then pushes an = integrity problem down to another layer. i.e. DNSSEC (*5). #4 is a TLS proxy. And it does get noticed, because you don=92t trust = Gogo=92s CA, so it=92s not so great as an attack. I do wonder why they = would apply it to Youtube of all services. Filter out video clips with = crashing planes? > It raises another question. Is DH_anon a misnomer? Should it be = DHE_anon? Is it used anywhere in practice? It is a misnomer. It is not used on the web, but it is used in some = situations. For example, my company=92s firewalls use it to establish = the initial trust between a firewall and the management station. They = will establish a TLS connection with DH_anon (should be DHE_anon, I = guess), and then run certificate enrollment over that. Yoav From nobody Wed Jan 7 21:20:35 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB7E01A885A for ; Wed, 7 Jan 2015 21:20:24 -0800 (PST) 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 cJhfE4IaBAUf for ; Wed, 7 Jan 2015 21:20:22 -0800 (PST) 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 8A7D91A8854 for ; Wed, 7 Jan 2015 21:20:22 -0800 (PST) Received: by mail-qg0-f53.google.com with SMTP id l89so778188qgf.12 for ; Wed, 07 Jan 2015 21:20:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:mime-version:content-type :content-transfer-encoding:message-id; bh=1rd2XG4RVPsDcoeGSGCtm2yNPiFsZve2nqiMSp0SDyY=; b=eyFlaDUf1CCQCVDuSvc328FsBjepx+FCMo8G+kFGepe3eL8LwwL5CUPzLMtC001yxi nk9z5bvc+oKNgk5xu69aKOtGm3YYNvigmQpA9oLpGQpjbRsMyW0WGyIOpnEyqOUUEH1p iS4CSjDeaf8LXHr0kRoIOVngc+/PHcFKiU9+RGprhLB7QruoLKNdyc94/q48jxU0JDgg hvRV4YX66M6yiDSg5nh1t/dVZxXSfSa88xgapIY6nQf4YZN+zyqo/+SNHZO9c7702nTk 67HQTTgaG8y7HNp1jd73MWMQd73Tv2isHdgZmQo3urnwzAShRf7zFXWX7sUDb92yM+t8 K49A== X-Received: by 10.229.126.129 with SMTP id c1mr11965957qcs.12.1420694421841; Wed, 07 Jan 2015 21:20:21 -0800 (PST) Received: from dave-laptop.localnet (pool-72-78-212-218.phlapa.fios.verizon.net. [72.78.212.218]) by mx.google.com with ESMTPSA id 91sm3195630qgf.1.2015.01.07.21.20.21 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 07 Jan 2015 21:20:21 -0800 (PST) From: Dave Garrett To: presnick@qti.qualcomm.com Date: Thu, 8 Jan 2015 00:20:19 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-70-generic-pae; KDE/4.4.5; i686; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201501080020.20326.davemgarrett@gmail.com> Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Vv8c_P3Yk6xVN01TL_wK-7xUDU0 Cc: "TLS@ietf.org \(tls@ietf.org\)" , draft-ietf-tls-prohibiting-rc4@tools.ietf.org Subject: [TLS] draft-ietf-tls-prohibiting-rc4-01 opportunistic security X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 05:20:25 -0000 https://datatracker.ietf.org/doc/draft-ietf-tls-prohibiting-rc4/ballot/403780/ A reply to Pete Resnick's ballot comment for draft-ietf-tls-prohibiting-rc4-01: Under what opportunistic security implementation would something better than RC4 not be supported by both endpoints? (I'm curious is one exists at all) Considering it permissible risks encouraging the usage of RC4 for opportunistic security, rather than more secure ciphers. If it is no longer fit for any purpose then the goal should be to kill it off entirely. Diluting the requirement risks compromising that goal. I'm not inclined to believe this is a "better than nothing" scenario unless there exists data on an existing RC4 OS system with a particularly large number of users that won't be upgraded. Though, in that case, they may just not honor this RFC. A simple requirement is best. I'm just sending this in the hope that this very good progress isn't made unnecessarily more complicated at the last second. Dave From nobody Wed Jan 7 21:34:19 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DEB71A8852; Wed, 7 Jan 2015 21:34:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 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_HI=-5, 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 Cilcc4cVtsSj; Wed, 7 Jan 2015 21:34:16 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9CB71A0E10; Wed, 7 Jan 2015 21:34:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1420695255; x=1452231255; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=n+w5uBAT/mBxU9+Skgu0BsGfKQP9HIwCLZjxB1Rahio=; b=lFuM2+tISdcmpxsmL30cBkVNIs4gM0BlJkfpwyKEsMBo/UZFeJSZvh9R 2syDjJMhg55LLerU7Wu8/mB4C0Uyz+A/JBf0X4pNgzktSjjTZLMmFech7 NCY1wlqNlbJxjjsMlsSuK/hn2Kx1Rhy+ktr6CIPNXzUfCS6AFbt9qSb1R Q=; X-IronPort-AV: E=McAfee;i="5600,1067,7674"; a="97104533" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Jan 2015 21:34:14 -0800 X-IronPort-AV: E=Sophos;i="5.07,719,1413270000"; d="scan'208";a="825636767" Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 07 Jan 2015 21:34:14 -0800 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 7 Jan 2015 21:34:13 -0800 Message-ID: <54AE16D3.4060707@qti.qualcomm.com> Date: Wed, 7 Jan 2015 23:34:11 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Dave Garrett References: <201501080020.20326.davemgarrett@gmail.com> In-Reply-To: <201501080020.20326.davemgarrett@gmail.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01G.na.qualcomm.com (10.85.0.33) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/WoxF1apDx-rOXomgXeCcnequ89o Cc: "TLS@ietf.org \(tls@ietf.org\)" , draft-ietf-tls-prohibiting-rc4@tools.ietf.org, The IESG Subject: Re: [TLS] draft-ietf-tls-prohibiting-rc4-01 opportunistic security X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 05:34:18 -0000 [Cc'ing the IESG, since this document is currently being discussed there] FYI, just so this doesn't generate a long thread on TLS for no reason: I am reading over the October WG list discussion on the draft where it appears this issue did come up, and my reaction so far is that I may simply be in the rough part of the rough consensus that existed on the list. That is, I think there is an issue here (i.e., the potential for a future OS implementation that, while being able to do better than RC4, may want to talk to something that can only either RC4 or clear text), but it looks like the WG did consider this objection and reasonably concluded that the current text is sufficient to cover the case. I do think it's a bit bogus for a document to say "implementations MUST NOT do X" when we know full-well that there is at least one good reason to ignore that requirement, but that's not enough for me to hold up the document. So unless I spot some point in the discussion of this topic that I think the WG really muffed, I'm almost certain to ballot No Objection before the IESG telechat tomorrow. pr On 1/7/15 11:20 PM, Dave Garrett wrote: > https://datatracker.ietf.org/doc/draft-ietf-tls-prohibiting-rc4/ballot/403780/ > > A reply to Pete Resnick's ballot comment for draft-ietf-tls-prohibiting-rc4-01: > > Under what opportunistic security implementation would something better than RC4 > not be supported by both endpoints? (I'm curious is one exists at all) > Considering it permissible risks encouraging the usage of RC4 for opportunistic > security, rather than more secure ciphers. > > If it is no longer fit for any purpose then the goal should be to kill it off > entirely. Diluting the requirement risks compromising that goal. I'm not > inclined to believe this is a "better than nothing" scenario unless there exists > data on an existing RC4 OS system with a particularly large number of users that > won't be upgraded. Though, in that case, they may just not honor this RFC. > > A simple requirement is best. I'm just sending this in the hope that this very > good progress isn't made unnecessarily more complicated at the last second. > > > Dave > -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Wed Jan 7 22:41:12 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E41ED1A8864 for ; Wed, 7 Jan 2015 22:41:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.023 X-Spam-Level: * X-Spam-Status: No, score=1.023 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, 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 AvbadAfV-uKC for ; Wed, 7 Jan 2015 22:41:09 -0800 (PST) Received: from klaatu.metaparadigm.com (klaatu.metaparadigm.com [67.207.128.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A8871A885D for ; Wed, 7 Jan 2015 22:41:08 -0800 (PST) Received: from monty.local (unknown.maxonline.com.sg [58.182.90.50] (may be forged)) (authenticated bits=0) by klaatu.metaparadigm.com (8.14.4/8.14.4/Debian-4) with ESMTP id t0872VDU011836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 8 Jan 2015 07:02:35 GMT DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=metaparadigm.com; s=klaatu; t=1420700558; bh=K27QGVcgSzRf1kr6MW5U5NPeun9UDgvF9V8gQlFFqj4=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=VQRUPZZmWT4lCaiwmnEH5n3ZssiEVzSWaWGTcDxh90Qdo1auPWCxTCjlBfXkg9CHb B0bJsWL/6azfrFNCE6apKpWWmdudV8JkWOUVSYFZ7+fdo5D1M3zTnDJzH++0RZYFuO pjGN2yXOwqJJ+FseqKDP4MCKbR1Xe6eOfa2FLMUk= Message-ID: <54AE2676.8020709@metaparadigm.com> Date: Thu, 08 Jan 2015 14:40:54 +0800 From: Michael Clark Organization: Metaparadigm Pte Ltd User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Yoav Nir References: <274716D0-EC91-4131-A8F7-CD13A9B42CE7@gmail.com> <54ADE9B6.4080700@metaparadigm.com> <702F318A-FE04-45F7-8CA1-30256D628CF7@gmail.com> In-Reply-To: <702F318A-FE04-45F7-8CA1-30256D628CF7@gmail.com> Content-Type: multipart/alternative; boundary="------------040209040106010203070303" X-Virus-Scanned: clamav-milter 0.98.4 at klaatu.metaparadigm.com X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/tls/cj5xBHTWpG0zq2eZQmtKCJdMBRc Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] RFC4492bis - Removing ECDH X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 06:41:12 -0000 This is a multi-part message in MIME format. --------------040209040106010203070303 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Yoav, On 8/1/15 12:42 pm, Yoav Nir wrote: > My understanding is the DH-RSA and ECDH-(RSA|ECDSA) are practically unu= sed and that implementations use DHE-RSA and ECDHE-(RSA|ECDSA). ECDH requ= ires the CA to embed static named or explicit points in certificates. The= practice is that implementations let server administrators choose and /s= ign/ *somewhat* ephemeral parameters e.g. secp256r1, secp384r1 works wid= ely, but secp521r1 failed in my tests with Win8.1 IE11; this report match= es my data point: (*3). I use the word /sign/ loosely until we have a pro= of that handshake messages can't be replaced in situ (*4). i.e. the clien= t and server establish a chain of trust from their first Hellos to the pr= e-master secret establishment; which is possible with careful refinements= to the protocol (constant salt in AD across all handshake messages). Thi= s of course then pushes an integrity problem down to another layer. i.e. = DNSSEC (*5). > #4 is a TLS proxy. And it does get noticed, because you don=E2=80=99t t= rust Gogo=E2=80=99s CA, so it=E2=80=99s not so great as an attack. I do w= onder why they would apply it to Youtube of all services. Filter out vide= o clips with crashing planes? I watched "Non-Stop" on an Singapore Airlines flight from New Zealand to Singapore in late-October, and at the same time noticed the plane altered course at Darwin, and instead of flying direct, flew over East Timor towards West Kalimantan (Borneo), completely avoiding the Java sea. Coincidence. Likely planning. "Weather". An AirAsia plane however sadly flew straight through the Java Sea during monsoon season. They had requested for new flight path and were denied due to heavy air traffic; so they flew on straight through a storm. My partner and I were boarding an A320 to Bangkok to Singapore 2 days after on Dec 30. http://www.rottentomatoes.com/m/non_stop_2013/ "Non-Stop" was about an Air Marshall who was trying to trace an unknown device on the plane sending him hijack threat messages, now they have WiFI and GSM... The reality is anyone serious would be using LoFi. "Non-Stop" is fiction. There is no need for MiFi. It human nature that people are angry when they are denied security (physical or ephemeral). I can separate fact from fiction. Rotten Tomatos gave it the thumbs. It was an okay movie however I think I liked it more because I was watching it on a plane. I am aware in the case where the CA is not in the trust store; and this is noticeable to the user, and there are techniques such as public key pinning in HTTP headers (which relies on establishing the first connection on a trusted network as a proxy could easily re-write the pins). The security needs to go down to the next layer. I still believe there is a rationale to (not in spite of RSA and other digital signature algorithms, rather to enhance them), make the client software aware, not just the user in the case of certificate tampering. Otherwise the browser needs a database. The policy could be that the client can indicate to the user that the handshake has been tampered and an implementation chose to accept invalid tags however I suspect it might be a slippery slope towards tamper free TLS handshakes. i.e. net neutrality. packets that arrive as they were sent. Someone will like derive a closed user group derivation of TLS once they are aware of this, if this kind of strategy is not adopted (assuming it is possible). I am still reasoning about adding HMAC on handshake messages with constant (client|server)_random as AD in all handshake messages (HMAC_SHA2_=F0=9D=91=9B). My reasoning probably has flaws or this would h= ave been solved. The MAC from the ClientHello MAC from the client may need to be signed by the cert and returned in the Finished message from the server. We have to distinguish between the HMACs that are *sent* not *seen* and perhaps use the *sent* in key derivation or tamper detection. This allows the browser to know at the TLS level (versus via the trust store) that the handshake was modified "in flight" (no pun intended). The browser developers and therefor the user can distinguish and take appropriate action. There is a distinction between untrusted cert and a tampered handshake that isn't currently exposed to the TLS client. I'm thinking of the rewriting case and reasoning about it... The client knows the MAC of it's ClientHello so it may need to be included in the Finished message signed by the servers certificate (and a MITM would need to change it). The server *sees* the MAC of the ClientHello it receives, not necessarily the one that was sent. It's almost like an HMAC of the handshake messages (from both sides as they were *sent*) needs to contribute to the pre-master secret, and each side knows what they sent. The tamperer would need to HMAC his tampered message. I will think some more about it... My thinking may have flaws... >> It raises another question. Is DH_anon a misnomer? Should it be DHE_an= on? Is it used anywhere in practice? > It is a misnomer. It is not used on the web, but it is used in some sit= uations. For example, my company=E2=80=99s firewalls use it to establish = the initial trust between a firewall and the management station. They wil= l establish a TLS connection with DH_anon (should be DHE_anon, I guess), = and then run certificate enrollment over that. Forward progress. It probably wasn't incorrect at the time until there was context for the distinction. Michael. --------------040209040106010203070303 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Hi Yoav,

On 8/1/15 12:42 pm, Yoav Nir wrote:
My understanding is the DH-RSA and ECDH-(RSA|ECDSA) are practically unused and that implementations use DHE-RSA and ECDHE-(RSA|ECDSA). ECDH requires the CA to embed static named or explicit points in certificates. The practice is that implementations let server administrators choose and /sign/ *somewhat* ephemeral parameters e.g. secp256r1,  secp384r1 works widely, but secp521r1 failed in my tests with Win8.1 IE11; this report matches my data point: (*3). I use the word /sign/ loosely until we have a proof that handshake messages can't be replaced in situ (*4). i.e. the client and server establish a chain of trust from their first Hellos to the pre-master secret establishment; which is possible with careful refinements to the protocol (constant salt in AD across all handshake messages). This of course then pushes an integrity problem down to another layer. i.e. DNSSEC (*5).

#4 is a TLS proxy. And it does get noticed, because you don’t trust Gogo’s CA, so it’s not so great as an attack. I do wonder why they would apply it to Youtube of all services. Filter out video clips with crashing planes?

I watched "Non-Stop" on an Singapore Airlines flight from New Zealand to Singapore in late-October, and at the same time noticed the plane altered course at Darwin, and instead of flying direct, flew over East Timor towards West Kalimantan (Borneo), completely avoiding the Java sea. Coincidence. Likely planning. "Weather". An AirAsia plane however sadly flew straight through the Java Sea during monsoon season. They had requested for new flight path and were denied due to heavy air traffic; so they flew on straight through a storm. My partner and I were boarding an A320 to Bangkok to Singapore 2 days after on Dec 30.

    http://www.rottentomatoes.com/m/non_stop_2013/

"Non-Stop" was about an Air Marshall who was trying to trace an unknown device on the plane sending him hijack threat messages, now they have WiFI and GSM... The reality is anyone serious would be using LoFi. "Non-Stop" is fiction. There is no need for MiFi. It human nature that people are angry when they are denied security (physical or ephemeral).

I can separate fact from fiction. Rotten Tomatos gave it the thumbs. It was an okay movie however I think I liked it more because I was watching it on a plane.

I am aware in the case where the CA is not in the trust store; and this is noticeable to the user, and there are techniques such as public key pinning in HTTP headers (which relies on establishing the first connection on a trusted network as a proxy could easily re-write the pins). The security needs to go down to the next layer. I still believe there is a rationale to (not in spite of RSA and other digital signature algorithms, rather to enhance them), make the client software aware, not just the user in the case of certificate tampering. Otherwise the browser needs a database. The policy could be that the client can indicate to the user that the handshake has been tampered and an implementation chose to accept invalid tags however I suspect it might be a slippery slope towards tamper free TLS handshakes. i.e. net neutrality. packets that arrive as they were sent. Someone will like derive a closed user group derivation of TLS once they are aware of this, if this kind of strategy is not adopted (assuming it is possible).

I am still reasoning about adding HMAC on handshake messages with constant (client|server)_random as AD in all handshake messages (HMAC_SHA2_đť‘›). My reasoning probably has flaws or this would have been solved. The MAC from the ClientHello MAC from the client may need to be signed by the cert and returned in the Finished message from the server. We have to distinguish between the HMACs that are *sent* not *seen* and perhaps use the *sent* in key derivation or tamper detection. This allows the browser to know at the TLS level (versus via the trust store) that the handshake was modified "in flight" (no pun intended). The browser developers and therefor the user can distinguish and take appropriate action. There is a distinction between untrusted cert and a tampered handshake that isn't currently exposed to the TLS client.

I'm thinking of the rewriting case and reasoning about it... The client knows the MAC of it's ClientHello so it may need to be included in the Finished message signed by the servers certificate (and a MITM would need to change it). The server *sees* the MAC of the ClientHello it receives, not necessarily the one that was sent. It's almost like an HMAC of the handshake messages (from both sides as they were *sent*) needs to contribute to the pre-master secret, and each side knows what they sent. The tamperer would need to HMAC his tampered message. I will think some more about it... My thinking may have flaws...


      

        
It raises another question. Is DH_anon a misnomer? Should it be DHE_anon? Is it used anywhere in practice?


      

      
It is a misnomer. It is not used on the web, but it is used in some situations. For example, my company’s firewalls use it to establish the initial trust between a firewall and the management station. They will establish a TLS connection with DH_anon (should be DHE_anon, I guess), and then run certificate enrollment over that.


    

    

    Forward progress. It probably wasn't incorrect at the time until
    there was context for the distinction.

    

    Michael.

    

  


--------------040209040106010203070303--


From nobody Thu Jan  8 01:04:44 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BDC41ACCDF for ; Thu,  8 Jan 2015 01:04:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level: 
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_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 yRydHHWHfNmg for ; Thu,  8 Jan 2015 01:04:41 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 192CB1ACCDC for ; Thu,  8 Jan 2015 01:04:40 -0800 (PST)
Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t0894cMX025588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 8 Jan 2015 04:04:38 -0500
Received: from dhcp-2-127.brq.redhat.com (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t0894Za8032764 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2015 04:04:37 -0500
Message-ID: <1420707875.11993.4.camel@redhat.com>
From: Nikos Mavrogiannopoulos 
To: Michael Clark 
Date: Thu, 08 Jan 2015 10:04:35 +0100
In-Reply-To: <54ADE9B6.4080700@metaparadigm.com>
References: <274716D0-EC91-4131-A8F7-CD13A9B42CE7@gmail.com>  <54ADE9B6.4080700@metaparadigm.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/kRtRMikawv7Fn09t6HZIPg7byRo
Cc: "TLS@ietf.org \(tls@ietf.org\)" 
Subject: Re: [TLS] RFC4492bis - Removing ECDH
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Jan 2015 09:04:43 -0000

On Thu, 2015-01-08 at 10:21 +0800, Michael Clark wrote:
> Hi,
> It raises another question. Is DH_anon a misnomer? Should it be
> DHE_anon? Is it used anywhere in practice?

That's a nice question. No DH_anon and ECDH_anon was not a misnomer.
They are often (or always?) used with ephemeral keys, but some other use
of them is with static non ephemeral keys, which will be used to verify
the server's identity on reconnect. Pretty much, no authentication, but
key continuity. That was never documented in the text though, but I
remember seeing it in mailing list discussions. I think that's the
reason of the missing 'E'.

regards,
Nikos




From nobody Thu Jan  8 06:45:37 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE6A21A8A20 for ; Thu,  8 Jan 2015 06:45:35 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, 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 HC6boML1Y0VD for ; Thu,  8 Jan 2015 06:45:34 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0132.outbound.protection.outlook.com [65.55.169.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AAC81A8A0C for ; Thu,  8 Jan 2015 06:45:34 -0800 (PST)
Received: from BN1PR09MB0258.namprd09.prod.outlook.com (25.160.80.19) by BN1PR09MB0257.namprd09.prod.outlook.com (25.160.80.18) with Microsoft SMTP Server (TLS) id 15.1.53.17; Thu, 8 Jan 2015 14:45:31 +0000
Received: from BN1PR09MB0258.namprd09.prod.outlook.com ([25.160.80.19]) by BN1PR09MB0258.namprd09.prod.outlook.com ([25.160.80.19]) with mapi id 15.01.0053.000; Thu, 8 Jan 2015 14:45:31 +0000
From: "Dang, Quynh" 
To: "tls@ietf.org" , "ekr@rtfm.com" 
Thread-Topic: "ClientKeyExhange" in the resumption handshake was just an editorial error. 
Thread-Index: AQHQK04bTnSeVsXda0me3ZVpgetEsg==
Date: Thu, 8 Jan 2015 14:45:31 +0000
Message-ID: <1420728327083.38073@nist.gov>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [129.6.218.73]
authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; 
x-dmarcaction: None
x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:BN1PR09MB0257;
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB0257;
x-forefront-prvs: 0450A714CB
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(199003)(189002)(86362001)(19625215002)(40100003)(106116001)(106356001)(31966008)(54356999)(50986999)(36756003)(101416001)(16236675004)(2656002)(4396001)(120916001)(105586002)(122556002)(99396003)(68736005)(102836002)(107886001)(64706001)(97736003)(19627405001)(20776003)(229853001)(107046002)(2900100001)(2501002)(99286002)(66066001)(21056001)(62966003)(117636001)(77156002)(92566001)(46102003)(87936001)(558084003)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB0257; H:BN1PR09MB0258.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; A:1; MX:3; LANG:en; 
received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts)
Content-Type: multipart/alternative; boundary="_000_142072832708338073nistgov_"
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2015 14:45:31.0308 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB0257
Archived-At: 
Subject: [TLS] "ClientKeyExhange" in the resumption handshake was just an editorial error.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Jan 2015 14:45:36 -0000

--_000_142072832708338073nistgov_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Eric,

I think the "ClientKeyExhange" in Figure 3 was an error, left from some old=
er version.

Quynh.




--_000_142072832708338073nistgov_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









Eric,






I think the "ClientKeyExhange" in Figure 3 was an =
error, left from some older version. 









Quynh. 























--_000_142072832708338073nistgov_--


From nobody Fri Jan  9 10:05:55 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEC9E1A87CD; Fri,  9 Jan 2015 10:05:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 QjgY1urosbuC; Fri,  9 Jan 2015 10:05:41 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 86C3D1A0075; Fri,  9 Jan 2015 10:05:39 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG 
To: IETF-Announce 
X-Test-IDTracker: no
X-IETF-IDTracker: 5.10.0.p8
Auto-Submitted: auto-generated
Precedence: bulk
Sender: 
Message-ID: <20150109180539.22231.7270.idtracker@ietfa.amsl.com>
Date: Fri, 09 Jan 2015 10:05:39 -0800
Archived-At: 
Cc: tls@ietf.org
Subject: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: ietf@ietf.org
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Jan 2015 18:05:49 -0000

The IESG has received a request from the Transport Layer Security WG
(tls) to consider the following document:
- 'TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing
   Protocol Downgrade Attacks'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-01-23. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   This document defines a Signaling Cipher Suite Value (SCSV) that
   prevents protocol downgrade attacks on the Transport Layer Security
   (TLS) protocol.  It updates RFC 2246, RFC 4346, and RFC 5246.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-tls-downgrade-scsv/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-tls-downgrade-scsv/ballot/


No IPR declarations have been submitted directly on this I-D.



From nobody Fri Jan  9 12:10:25 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA1CA1A0406; Fri,  9 Jan 2015 12:10:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 yLZ3mMhanHzN; Fri,  9 Jan 2015 12:10:20 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 34AAE1A900A; Fri,  9 Jan 2015 12:10:09 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG 
To: IETF-Announce 
X-Test-IDTracker: no
X-IETF-IDTracker: 5.10.0.p8
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150109201009.26717.62937.idtracker@ietfa.amsl.com>
Date: Fri, 09 Jan 2015 12:10:09 -0800
Archived-At: 
Cc: tls mailing list , tls chair , RFC Editor 
Subject: [TLS] Protocol Action: 'Prohibiting RC4 Cipher Suites' to Proposed Standard (draft-ietf-tls-prohibiting-rc4-01.txt)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Jan 2015 20:10:22 -0000

The IESG has approved the following document:
- 'Prohibiting RC4 Cipher Suites'
  (draft-ietf-tls-prohibiting-rc4-01.txt) as Proposed Standard

This document is the product of the Transport Layer Security Working
Group.

The IESG contact persons are Stephen Farrell and Kathleen Moriarty.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-tls-prohibiting-rc4/





Technical Summary

   This document requires that Transport Layer Security (TLS) clients
   and servers never negotiate the use of RC4 cipher suites when they
   establish connections.

Working Group Summary

   There is strong working group consensus for this document.  During 
   WGLC there was some concern that there may be some 
   implementations that only support RC4 and a "MUST NOT" may not 
   be appropriate for servers.  The was strong consensus within the 
   group to move forward with RC4 as a "MUST NOT."  

   In case it comes up, during AD review I did ask the WG if they
   wanted to go beyond just killing this list of ciphersuites and
   massacre some more, but the answer, as I expected, was that
   no, just doing this is what they want to do for now.

Document Quality

   The document has been reviewed by the TLS working group. There 
   is also significant evidence that  only a very small percentage of 
   deployments only support RC4.  

Personnel

   The document shepherd is Joseph Salowey.  
   The irresponsible Area Director is Stephen Farrell.

RFC Editor Note

   Please remove the square brackets from the abstract.


From nobody Sat Jan 10 11:31:23 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E98C61A8736; Sat, 10 Jan 2015 11:31:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.212
X-Spam-Level: 
X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, 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 HVV8PAzkXKVG; Sat, 10 Jan 2015 11:31:20 -0800 (PST)
Received: from mx5-phx2.redhat.com (mx5-phx2.redhat.com [209.132.183.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1A4A1A700D; Sat, 10 Jan 2015 11:31:19 -0800 (PST)
Received: from zmail22.collab.prod.int.phx2.redhat.com (zmail22.collab.prod.int.phx2.redhat.com [10.5.83.26]) by mx5-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t0AJVIbv009658; Sat, 10 Jan 2015 14:31:19 -0500
Date: Sat, 10 Jan 2015 14:31:16 -0500 (EST)
From: Nikos Mavrogiannopoulos 
To: ietf@ietf.org
Message-ID: <285245260.5608886.1420918276899.JavaMail.zimbra@redhat.com>
In-Reply-To: <20150109180539.22231.7270.idtracker@ietfa.amsl.com>
References: <20150109180539.22231.7270.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.5.82.11]
X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF31 (Linux)/8.0.6_GA_5922)
Thread-Topic: Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
Thread-Index: T01/zi/PAkMcUbtQ2dMcOUXF9ipdmg==
Archived-At: 
Cc: tls@ietf.org
Subject: Re: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 10 Jan 2015 19:31:22 -0000

----- Original Message -----
> 
> The IESG has received a request from the Transport Layer Security WG
> (tls) to consider the following document:
> - 'TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing
>    Protocol Downgrade Attacks'
>    as Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf@ietf.org mailing lists by 2015-01-23. Exceptionally, comments may be
> sent to iesg@ietf.org instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>    This document defines a Signaling Cipher Suite Value (SCSV) that
>    prevents protocol downgrade attacks on the Transport Layer Security
>    (TLS) protocol.  It updates RFC 2246, RFC 4346, and RFC 5246.

The "TLS Fallback Signaling Cipher Suite" fix cannot be a proposed standard. 
The mechanism it fixes (the browser's special downgrade of TLS) is not an IETF
protocol, nor related to the TLS WG. Making this a proposed standard, would 
imply that the flawed technique is into standards track. I believe that this 
text should be informational.

regards,
Nikos


From nobody Sat Jan 10 12:54:38 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FBC71A1A09; Sat, 10 Jan 2015 12:54:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 hDHO4GUynDjP; Sat, 10 Jan 2015 12:54:35 -0800 (PST)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id E233B1A0396; Sat, 10 Jan 2015 12:54:34 -0800 (PST)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id C5268476AF; Sat, 10 Jan 2015 20:54:33 +0000 (GMT)
Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id B8C9D476AE; Sat, 10 Jan 2015 20:54:33 +0000 (GMT)
Received: from email.msg.corp.akamai.com (unknown [172.27.123.34]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id B2B402026; Sat, 10 Jan 2015 20:54:33 +0000 (GMT)
Received: from usma1ex-cashub5.kendall.corp.akamai.com (172.27.105.21) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.913.22; Sat, 10 Jan 2015 15:54:10 -0500
Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Sat, 10 Jan 2015 15:54:10 -0500
From: "Salz, Rich" 
To: Nikos Mavrogiannopoulos , "ietf@ietf.org" 
Date: Sat, 10 Jan 2015 15:54:09 -0500
Thread-Topic: Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
Thread-Index: AdAtF5RqPhs7A1ZuQfugN43Qg9JVbQ==
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D55675E29@USMBX1.msg.corp.akamai.com>
References: <20150109180539.22231.7270.idtracker@ietfa.amsl.com> <285245260.5608886.1420918276899.JavaMail.zimbra@redhat.com>
In-Reply-To: <285245260.5608886.1420918276899.JavaMail.zimbra@redhat.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 10 Jan 2015 20:54:37 -0000

> The mechanism it fixes (the browser's special downgrade of TLS) is not an
> IETF protocol, nor related to the TLS WG. Making this a proposed standard=
,
> would imply that the flawed technique is into standards track. I believe =
that
> this text should be informational.

I disagree.  Just because it addresses one common behavior, defining semant=
ics for a client to say "I tried better, this is what I have now" and the r=
elated server semantics is a very good thing.  It keeps the  client/server =
interaction stateless (well on the server side) across multiple connections=
.

-- =20
Principal Security Engineer, Akamai Technologies
IM: rsalz@jabber.me Twitter: RichSalz



From nobody Sat Jan 10 16:48:18 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBD121A1A81; Sat, 10 Jan 2015 16:48:12 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, 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 NIzOdicjgTOJ; Sat, 10 Jan 2015 16:48:09 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFA2F1A1A6E; Sat, 10 Jan 2015 16:48:06 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 383CBBED0; Sun, 11 Jan 2015 00:48:05 +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 vY_LUcdg99FX; Sun, 11 Jan 2015 00:48:02 +0000 (GMT)
Received: from [10.87.48.73] (unknown [86.46.26.244]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A982DBECC; Sun, 11 Jan 2015 00:48:02 +0000 (GMT)
Message-ID: <54B1C841.2020707@cs.tcd.ie>
Date: Sun, 11 Jan 2015 00:48:01 +0000
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Nikos Mavrogiannopoulos , ietf@ietf.org
References: <20150109180539.22231.7270.idtracker@ietfa.amsl.com> <285245260.5608886.1420918276899.JavaMail.zimbra@redhat.com>
In-Reply-To: <285245260.5608886.1420918276899.JavaMail.zimbra@redhat.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: tls@ietf.org
Subject: Re: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 11 Jan 2015 00:48:13 -0000

Hi Nikos,

On 10/01/15 19:31, Nikos Mavrogiannopoulos wrote:
> ----- Original Message -----
>>
>> The IESG has received a request from the Transport Layer Security WG
>> (tls) to consider the following document:
>> - 'TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing
>>    Protocol Downgrade Attacks'
>>    as Proposed Standard
>>
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final comments on this action. Please send substantive comments to the
>> ietf@ietf.org mailing lists by 2015-01-23. Exceptionally, comments may be
>> sent to iesg@ietf.org instead. In either case, please retain the
>> beginning of the Subject line to allow automated sorting.
>>    This document defines a Signaling Cipher Suite Value (SCSV) that
>>    prevents protocol downgrade attacks on the Transport Layer Security
>>    (TLS) protocol.  It updates RFC 2246, RFC 4346, and RFC 5246.
> 
> The "TLS Fallback Signaling Cipher Suite" fix cannot be a proposed standard. 
> The mechanism it fixes (the browser's special downgrade of TLS) is not an IETF
> protocol, nor related to the TLS WG. Making this a proposed standard, would 
> imply that the flawed technique is into standards track. 

I don't believe that that last conclusion follows. AFIAK there is
nothing to prevent the IETF standardising a fix for someone else's
or even our own past mistakes(*) even when those mistakes are not
on the standards track. And if in fact stardardising the "fix"
improves the Internet, then we should do that as the set of folks
responsible for this technology. (If doing so has IETF consensus.)

However, I'm pretty sanguine about us "doing the right thing
regardless" whereas I know others care more about the details of
this kind of thing so I'd be glad be corrected if I'm wrong about
this.

Cheers,
S.

(*) "mistake" is a bit pejorative but s/mistake/recently discovered
threat/ if you prefer - I think we reach the same conclusion so we
don't need to discuss if the downgrade dance was a mistake in order
to handle the issue that Nikos raises above.




> I believe that this 
> text should be informational.
> 
> regards,
> Nikos
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 


From nobody Sat Jan 10 18:17:28 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8BC91A0A85 for ; Sat, 10 Jan 2015 18:17:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.378
X-Spam-Level: 
X-Spam-Status: No, score=-0.378 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_22=0.6, SPF_HELO_PASS=-0.001, 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 qsM8JWZvw2Yt for ; Sat, 10 Jan 2015 18:17:22 -0800 (PST)
Received: from klaatu.metaparadigm.com (klaatu.metaparadigm.com [67.207.128.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00AF31A0373 for ; Sat, 10 Jan 2015 18:17:21 -0800 (PST)
Received: from monty.local (unknown.maxonline.com.sg [58.182.90.50] (may be forged)) (authenticated bits=0) by klaatu.metaparadigm.com (8.14.4/8.14.4/Debian-4) with ESMTP id t0B2cphX011751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Sun, 11 Jan 2015 02:38:55 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=metaparadigm.com; s=klaatu; t=1420943937; bh=EOSUQ9z5anmad0m1oLO1cLo2X2P8C/rPQ/IA5/gotCg=; h=Date:From:To:Subject:References:In-Reply-To:From; b=RHQecGkuXmJICIEpjeQUDRluayG1rdKMaSOM/Tlt0ejp5b645ixq6T5A86dQ7n73D cux5LNHy25RcYWgHdVvq7Sg2iqE83qX+XziUbkFxeUSIGfMLey3oyRcGQHwgJ/cSgP 9tXJOeiP9Yiib90wryLKWywRVWOTNJ7RihZmkY/w=
Message-ID: <54B1DD25.8090305@metaparadigm.com>
Date: Sun, 11 Jan 2015 10:17:09 +0800
From: Michael Clark 
Organization: Metaparadigm Pte Ltd
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: "TLS@ietf.org (tls@ietf.org)" 
References: <274716D0-EC91-4131-A8F7-CD13A9B42CE7@gmail.com>  <54ADE9B6.4080700@metaparadigm.com> <702F318A-FE04-45F7-8CA1-30256D628CF7@gmail.com>
In-Reply-To: <702F318A-FE04-45F7-8CA1-30256D628CF7@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.98.4 at klaatu.metaparadigm.com
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [TLS] RFC4492bis - Removing ECDH
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 11 Jan 2015 02:17:26 -0000

tl;dr

> #4 is a TLS proxy. And it does get noticed, because you don’t trust Gogo’s CA, so it’s not so great as an attack. I do wonder why they would apply it to Youtube of all services. Filter out video clips with crashing planes?

I've come to the conclusion that the GoGo full proxy case is impossible
to do anything about but is highly visible to the user. It's like being
on an Island in the Sky without much Internet, a big cache and a high
latency satellite link. It reminds me of New Zealand Internet in the mid
90s when I worked at an ISP with sat and copper submarine cables. The
router guys did policy routes to send latency sensitive stuff over cable
(SYN,SYNACK,ACK) and bulk transfer to latency insensitive stuff over
satellite (NNTP). Similar mechanism to the grey box (see below).

| |
 O -< full proxy
| |

If GoGo were smarter, they would put a trusty looking logo on their WiFi
captive portal signin pop-up e.g. a gold crown with a red seal and
ribbon; like those on a Reader's Digest prize letter; asking users to
install and trust their certificate for "Enhanced in-flight security".
Put an advertisement for Fidelity A-ssurance and a picture of Benjamin
next to it, and then you can just generate certificates "on the fly"
after snarfing out all of the ASN.1 fields from the remote end. They
could even do EV and point to their own OCSP. Any address they like (NAT
and anycast). Conclusion: Bank in Hawaii, but fly there to make withdrawals.

However I believe that GoGo is kind of a cover story to show off crude
tampering to mask much more subtle tampering.

In fact there is no way around someone who is friends with a CA as they
can implement a full proxy, especially if they have insertion points at
all major POPs, deep packet inspection and selective policy routes to
send you off to their grey boxes. Public-Key-Pins will only work if you
initiate your first connection on a network you know is trusted. i.e. at
the office. When you know the Tier 1 (backbone) in your own country is
part of the five eyes then all bets are off. Vodafone fessed up and made
a public statement about the 5 countries and they *don't approve*
http://www.bbc.com/news/business-27732743

If *they* can compel Vodafone then they can compel a CA or 'Chorus' our
own Fibre backbone provider to do whatever they want. Who knows what
they are doing? Everyone. The law is "search warrant" and "probable
cause". Wholesale wiretapping is illegal in almost all democracies. OK,
it's a "representative" democracy. I'm a-political. Who cares what crowd
gets in. Mil is going to be there either way. Military or Militant.
What's the diff? One drives a fiat apparently.

| |
¦ ¦<- pass-through tampering.
| |

There is a more subtle pass through case where handshake messages can be
tampered with (without access to a CA, just an Internet coffee bucks
WiFi tap). Allows attacks such as editing cipher lists and any other
associated handshake metadata (curve format extensions, switching on
compression) that are not properly authenticated. Until I am certain
they are completely mitigated I remain skeptical.

I am still thinking about pass-through tamper mitigation using random
constant as AD and MAC for all pre-kex handshake messages and having the
server returning the client MAC it saw from the client signed with its
RSA or ECDSA key (and notify that all were equal including its original
ServerHello MAC signed in the Finished message (given ChangeCipherSpec
is proposed to be removed). Both can do this when they have a shared
chain of trust and the client offers a certificate.

Until I've finished my proxy, its just reasoning from auditing the spec.
I am curruently unsure how MITM handshake tampering in the rouge WiFi or
ISP active tapping case is mitigated. I've read SCSV but it confuses me
a little. If it's in the clear and unauthenticate it can be tampered
with. Any slightly milicious WiFi provider can do NAT and transparent
proxy, introduce delays, drop handshake messages and rewrite cipher
lists and extensions for anything not authenticated.

Just wiresharking again... I can't see why I can't try to emulate
WindowsXP ClientHello in a pass through proxy, by dropping, delaying or
rewriting messages I don't like (including fallback).

Windows XP IE 8 offers a 1.0 CLientHello often gets given
TLS_WITH_RSA_RC4_128_SHA. Firefox has a 1.2 ClientHello and it gets
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 but TLS_WITH_RSA_RC4_128_SHA is
offered in its ClientHello and it can talk TLS1.0.

MiFi could fool a client into thinking all servers are TLS1.0 (for
servers that still support TLS1.0)? and downgrade them to
TLS_WITH_RSA_RC4_128_SHA and rewrite/filter their responses. Still we
can't easily crack RC4. We'd need a huge black building in the dessert
with acres of GPUs or a cave under a mountain, protected by ninjas.

It seems the other direction is minimizing negotiation and removing
extensions. Make SNI mandatory field. No compression. No renegotiation.
It's all wise stuff. Label all cryptographic primitives with 'notional
labels' in the spec so everything is pre-negotiated. Sign the chosen
label with random salt. Return all offered and negotiated parameters
signed after the kex (small negotiation or an HMAC known to the other
end). Make TLSv1.3 require all of the existing primitives such as  curve
point formats, and make everything based on a tiny label.

enum ssf { ssf56, ssf112, ssf168, ssf224, ssf336, ssf448, mssf56,
mssf112, mssf168, mssf224, mssf336, mssf448 };

enum kex { kex_dh_anon, kex_psk_rsa, key_ffdhe_rsa, kex_ecdhe_rsa,
kex_psk_eddsa, kex_ecdhe_eddsa };

enum orphan { srp }; /* protocol layer auth? */

Still, even when the negotiation is small, if *all* parameters offered
in the Hellos are not returned signed (or by using a AD anti-tamper MAC
of the negotiation parameters), then we can still be downgraded to ssf56
if we were to offer it in the range we are willing to accept.

We want to know if we offer a range from ssf112 to ssf448 that ssf448 is
an option and we are not going to be downgraded to ssf112. All
negotiation parameters need to be signed no matter what the chosen kex
is, and in the symmetric case (psk or client and server certs), then
both ends can detect tampering (except in the crude case with RSA and
compromised CAs). It makes downgrading hard instead of trivial.

That said, SCSV helps mitigate without an overhaul of the handshake and
I can understand why it is there. This is not despite SCSV, as
fundamental changes to TLS negotiation and authentication are much more
intrusive changes; and even with a solid spec there are chances of
implementation bugs. We are humans.

P.S. I'm not on any sec list; as if I was I would have a duty to keep
quiet. I'm just auditing the spec based on public discourse and am not
under any non-disclosure agreements expressed or implied. Just a candid
third eye.


=====================================================================
TL;DR Free Idea - semi-off-topic - symmetry likely already considered
=====================================================================

It seems to me pinning and so forth are just papering around lack of
tamper-resistance in TLS handshakes and CA transparency and the price of
random bits. It's harder to change TLS but if you make changes to
servers and clients that have common issues then browsers can mitigate
using a common mechanism. Pinning. We all have a common interest. Public
audit records for CA make huge sense. The cert is offered by the server
so the CA should let you look in an audit trail of fingerprints. But
re-issue doesn't imply revocation (unless it's handled like a domain
transfer). Hard problem.

A TLS derivative (essentially policy) could add (or remove) symmetry and
make CertificateShare (either chained or self-signed) a requirement for
clients (browsers, or whatever). This would allow the servers to see if
clients were being impersonated if they stored client certs (or simply
fingerprints, like sessions, in a paxos/flashcached), on behalf of the
user, to allow service providers to give their users protection against
impersonation (most good people don't want their identity stolen), and
at the TLS level (essentially making them device certificates) using
pre-existing functionality. At the moment we have n-methods of
impersonation protection (all on behalf of users) for n-service
providers. HTTPS/SMTP(TLS) everywhere would let service providers
leverage RSA or EdDSA for protection of their users against identity
theft. We clearly need (tamper-resistant) TLS everywhere. In support of
AGL, Google, Firefox and everyone else working on TLS and Internet
security in general. I'm just adding to the fire. Soon we will need some
SMTP providers to start blocking based on certificate verification. Of
course an anonymous client cert with a random common name could only be
used for "confidence" after seeing it behave in a particular way
repeatedly. It seems Asia needs a lot of work:

  http://www.google.com/transparencyreport/saferemail/

Anonymity would then become at the expense of CPU cycles. i.e. Opening
up an incognito window would require cycles to generate a key and
self-signed certificate. Sending anonymous SPAM would require more CPU
cycles and it would have no effect on solicited bulk mail performance as
legitimate mailers aren't trying to get their certificate fingerprints
blacklisted. We could use certs in DNSSEC for SMTP blacklists (as one
example). Back to stamps for mail.

This would allow a server to detect someone trying to impersonate a
client using the same mechanisms the client can use. i.e. signing of the
handshake MAC in both directions when both sides have a cert.

Servers could have an MCU (most commonly used) cache to expire client
certs (or just their fingerprints). i.e. scaling the fingerprint expiry
based on frequency of usage. i.e. Bayesian confidence in the association
between a user and their certificate. Paranoid clients could generate a
new cert for each domain. It takes ~200ms to create a 2048bit RSA key.
This would make unsolicited bulk mail expensive.

Attackers that wanted to make wide attacks would be CPU bound as honest
clients and servers do key generation infrequently. Anyone who wanted to
be trusted would leave fingerprints.

This would make anonymous SPAM (SMTP with MX DVSNI vs self-signed certs)
add almost no extraordinary expense for normal usage but anyone covering
their tracks would have to use lots of CPU.

Browsers might someday start serving up certificates to servers. The
question is whether they prompt the user? prompt for policy choice? or
do so implicitly to protect the identity of their users? That's policy.
Not my area. Just putting ideas out there based on public knowledge from
lots of awesome people (judgement is half perspective).

Michael.


From nobody Sat Jan 10 19:29:34 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 408741A1A4F for ; Sat, 10 Jan 2015 19:29:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.078
X-Spam-Level: 
X-Spam-Status: No, score=-1.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_22=0.6, SPF_HELO_PASS=-0.001, 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 mlzUkoKkmOXp for ; Sat, 10 Jan 2015 19:29:32 -0800 (PST)
Received: from klaatu.metaparadigm.com (klaatu.metaparadigm.com [67.207.128.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D6C51A1A07 for ; Sat, 10 Jan 2015 19:29:31 -0800 (PST)
Received: from monty.local (unknown.maxonline.com.sg [58.182.90.50] (may be forged)) (authenticated bits=0) by klaatu.metaparadigm.com (8.14.4/8.14.4/Debian-4) with ESMTP id t0B3p2eX011917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Sun, 11 Jan 2015 03:51:06 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=metaparadigm.com; s=klaatu; t=1420948267; bh=cQQy9vDFlNHbsv3fR965mext5qyvOw5VlOIIfFrKNUg=; h=Date:From:To:Subject:References:In-Reply-To:From; b=Q1G0e57068EHGspOpHqvEfqsaKjICcbuj7tBjenp271LToT/4zkiwGI2TFl1dxitj zp6GiFFfgdnFSlpvr3zuf5DAwSphu+aCbiSeO6LPDCEhFxkSsRLjf7N9aujWsadmcd kCDA0Hm65KALNBxymo7IlEM6fV+6BbFgJTHT4Owo=
Message-ID: <54B1EE10.6030205@metaparadigm.com>
Date: Sun, 11 Jan 2015 11:29:20 +0800
From: Michael Clark 
Organization: Metaparadigm Pte Ltd
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: "TLS@ietf.org (tls@ietf.org)" 
References: <274716D0-EC91-4131-A8F7-CD13A9B42CE7@gmail.com>  <54ADE9B6.4080700@metaparadigm.com> <702F318A-FE04-45F7-8CA1-30256D628CF7@gmail.com> <54B1DD25.8090305@metaparadigm.com>
In-Reply-To: <54B1DD25.8090305@metaparadigm.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Virus-Scanned: clamav-milter 0.98.4 at klaatu.metaparadigm.com
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [TLS] RFC4492bis - Removing ECDH
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 11 Jan 2015 03:29:33 -0000

On 11/1/15 10:17 am, Michael Clark wrote:
> tl;dr

please excuse any factual or typographic errors. my client is pedantic
and does not approve of any of them. unfortunately i am human.

consider my mail a draft draft comment on a request for comment. a
hopelessly meta stream of consciousness. it's the thought that counts.

it's dysgraphia or dyslexia. one or the other.


From nobody Sat Jan 10 21:14:32 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88C4A1A1AD9 for ; Sat, 10 Jan 2015 21:14:28 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, 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 lPXm84QnGwmi for ; Sat, 10 Jan 2015 21:14:25 -0800 (PST)
Received: from emh06.mail.saunalahti.fi (emh06.mail.saunalahti.fi [62.142.5.116]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF93C1A1AD8 for ; Sat, 10 Jan 2015 21:14:24 -0800 (PST)
Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh06.mail.saunalahti.fi (Postfix) with ESMTP id 9D35B699CB; Sun, 11 Jan 2015 07:14:21 +0200 (EET)
Date: Sun, 11 Jan 2015 07:14:21 +0200
From: Ilari Liusvaara 
To: Michael Clark 
Message-ID: <20150111051421.GA32295@LK-Perkele-VII>
References: <274716D0-EC91-4131-A8F7-CD13A9B42CE7@gmail.com>  <54ADE9B6.4080700@metaparadigm.com> <702F318A-FE04-45F7-8CA1-30256D628CF7@gmail.com> <54B1DD25.8090305@metaparadigm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <54B1DD25.8090305@metaparadigm.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara 
Archived-At: 
Cc: "TLS@ietf.org \(tls@ietf.org\)" 
Subject: Re: [TLS] RFC4492bis - Removing ECDH
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 11 Jan 2015 05:14:28 -0000

On Sun, Jan 11, 2015 at 10:17:09AM +0800, Michael Clark wrote:
> 
> There is a more subtle pass through case where handshake messages can be
> tampered with (without access to a CA, just an Internet coffee bucks
> WiFi tap). Allows attacks such as editing cipher lists and any other
> associated handshake metadata (curve format extensions, switching on
> compression) that are not properly authenticated. Until I am certain
> they are completely mitigated I remain skeptical.

This attack won't work.

- TLS 1.3: The messages are hashed into hMS, so you can't decrypt the
  rest of the handshake due to having wrong keys.
- TLS 1.0-1.2 w/o false start: The Finished values will fail to verify.
- TLS 1.0-1.2 /w false start: The selected crypto must be strong, or
  endpoints won't enage in false start.


-Ilari


From nobody Mon Jan 12 01:13:36 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36CD11A1B3E for ; Mon, 12 Jan 2015 01:13:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.076
X-Spam-Level: *
X-Spam-Status: No, score=1.076 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FB_WORD1_END_DOLLAR=3.294, FB_WORD2_END_DOLLAR=3.294, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, 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 JzmGItn5Nz4J for ; Mon, 12 Jan 2015 01:13:32 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFD3D1A1B2E for ; Mon, 12 Jan 2015 01:13:32 -0800 (PST)
Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t0C9DUl9026419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 12 Jan 2015 04:13:30 -0500
Received: from dhcp-2-127.brq.redhat.com (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t0C9DReX024499 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 12 Jan 2015 04:13:28 -0500
Message-ID: <1421054006.3211.13.camel@redhat.com>
From: Nikos Mavrogiannopoulos 
To: Yoav Nir 
Date: Mon, 12 Jan 2015 10:13:26 +0100
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Archived-At: 
Cc: "TLS@ietf.org \(tls@ietf.org\)" 
Subject: Re: [TLS] RFC4492bis - Removing ECDH
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Jan 2015 09:13:34 -0000

----- Original Message -----
> Hi.
> 
> I realize this was sent right in the middle of the holiday season, so I’ll
> give it another try.
> Please have a look at the pull request and post comments to the list about
> whether you’re fine with removing ECDH.

I'm of course for it.

Another request for this document, would be to remove the following text:
"This is the byte string representation of an elliptic curve
      point following the conversion routine in Section 4.3.6 of ANSI
      X9.62 [7]. "
and replace it with a publicly available reference, or just describe the 
conversion. It is an important part of the protocol and unfortunately 
requires 100$ to read.

regards,
Nikos



From nobody Mon Jan 12 01:16:11 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1763F1A8A79; Mon, 12 Jan 2015 01:16:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level: 
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, 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 drPTH8tpJGjN; Mon, 12 Jan 2015 01:16:07 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8443F1A8A65; Mon, 12 Jan 2015 01:16:07 -0800 (PST)
Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t0C9FxRK002568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 12 Jan 2015 04:15:59 -0500
Received: from dhcp-2-127.brq.redhat.com (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t0C9FunS025657 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 12 Jan 2015 04:15:59 -0500
Message-ID: <1421054156.3211.15.camel@redhat.com>
From: Nikos Mavrogiannopoulos 
To: Stephen Farrell 
Date: Mon, 12 Jan 2015 10:15:56 +0100
In-Reply-To: <54B1C841.2020707@cs.tcd.ie>
References: <20150109180539.22231.7270.idtracker@ietfa.amsl.com> <285245260.5608886.1420918276899.JavaMail.zimbra@redhat.com> <54B1C841.2020707@cs.tcd.ie>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Archived-At: 
Cc: ietf@ietf.org, tls@ietf.org
Subject: Re: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Jan 2015 09:16:09 -0000

On Sun, 2015-01-11 at 00:48 +0000, Stephen Farrell wrote:
> Hi Nikos,
> >> The IESG plans to make a decision in the next few weeks, and solicits
> >> final comments on this action. Please send substantive comments to the
> >> ietf@ietf.org mailing lists by 2015-01-23. Exceptionally, comments may be
> >> sent to iesg@ietf.org instead. In either case, please retain the
> >> beginning of the Subject line to allow automated sorting.
> >>    This document defines a Signaling Cipher Suite Value (SCSV) that
> >>    prevents protocol downgrade attacks on the Transport Layer Security
> >>    (TLS) protocol.  It updates RFC 2246, RFC 4346, and RFC 5246.
> > The "TLS Fallback Signaling Cipher Suite" fix cannot be a proposed standard. 
> > The mechanism it fixes (the browser's special downgrade of TLS) is not an IETF
> > protocol, nor related to the TLS WG. Making this a proposed standard, would 
> > imply that the flawed technique is into standards track. 
> I don't believe that that last conclusion follows. AFIAK there is
> nothing to prevent the IETF standardising a fix for someone else's
> or even our own past mistakes(*) even when those mistakes are not
> on the standards track. And if in fact stardardising the "fix"
> improves the Internet, then we should do that as the set of folks
> responsible for this technology. (If doing so has IETF consensus.)

It's not up to me to say whether there was consensus for this draft or
not. I voiced my opinion against that draft. However, if you think that
this has to be on standards track, please provide at least some
argumentation for it. 

As far as I understand, this fix exists because Microsoft, Google and
Mozilla cannot coordinate and drop their insecure negotiation of TLS.

regards,
Nikos



From nobody Mon Jan 12 03:12:31 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1030C1A6F10; Mon, 12 Jan 2015 03:12:01 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, 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 yUDc59dUDhUB; Mon, 12 Jan 2015 03:11:55 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 557461A1B75; Mon, 12 Jan 2015 03:11:55 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5B619BEFC; Mon, 12 Jan 2015 11:11:53 +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 ztp4w9WT0kDo; Mon, 12 Jan 2015 11:11:53 +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 32082BEF3; Mon, 12 Jan 2015 11:11:53 +0000 (GMT)
Message-ID: <54B3ABF9.7000809@cs.tcd.ie>
Date: Mon, 12 Jan 2015 11:11:53 +0000
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Nikos Mavrogiannopoulos 
References: <20150109180539.22231.7270.idtracker@ietfa.amsl.com>	 <285245260.5608886.1420918276899.JavaMail.zimbra@redhat.com>	 <54B1C841.2020707@cs.tcd.ie> <1421054156.3211.15.camel@redhat.com>
In-Reply-To: <1421054156.3211.15.camel@redhat.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: ietf@ietf.org, tls@ietf.org
Subject: Re: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Jan 2015 11:12:01 -0000

Hi Nikos,

On 12/01/15 09:15, Nikos Mavrogiannopoulos wrote:
> On Sun, 2015-01-11 at 00:48 +0000, Stephen Farrell wrote:
>> Hi Nikos,
>>>> The IESG plans to make a decision in the next few weeks, and solicits
>>>> final comments on this action. Please send substantive comments to the
>>>> ietf@ietf.org mailing lists by 2015-01-23. Exceptionally, comments may be
>>>> sent to iesg@ietf.org instead. In either case, please retain the
>>>> beginning of the Subject line to allow automated sorting.
>>>>    This document defines a Signaling Cipher Suite Value (SCSV) that
>>>>    prevents protocol downgrade attacks on the Transport Layer Security
>>>>    (TLS) protocol.  It updates RFC 2246, RFC 4346, and RFC 5246.
>>> The "TLS Fallback Signaling Cipher Suite" fix cannot be a proposed standard. 
>>> The mechanism it fixes (the browser's special downgrade of TLS) is not an IETF
>>> protocol, nor related to the TLS WG. Making this a proposed standard, would 
>>> imply that the flawed technique is into standards track. 
>> I don't believe that that last conclusion follows. AFIAK there is
>> nothing to prevent the IETF standardising a fix for someone else's
>> or even our own past mistakes(*) even when those mistakes are not
>> on the standards track. And if in fact stardardising the "fix"
>> improves the Internet, then we should do that as the set of folks
>> responsible for this technology. (If doing so has IETF consensus.)
> 
> It's not up to me to say whether there was consensus for this draft or
> not. 

Yep, we'll see when the IETF LC is done.

> I voiced my opinion against that draft. 

Not quite. You said this "cannot be" a PS based on an argument
that is independent of the content of the draft.

> However, if you think that
> this has to be on standards track, please provide at least some
> argumentation for it. 

Sorry, I was only answering your general point above, where
you said the IETF couldn't produce a PS to fix a problem with
a non-IETF thing - I was addressing the "cannot be a proposed
standard" part. I think it clearly can, and given that you're
moving the discussion along to the specifics of the draft, I
assume you accept that.

So now you're being more specific and saying that I need
to provide an argument that this "has to be on the standards
track." I don't think I actually do need to provide such an
argument that there was no other good choice - that the TLS
WG chose to process it as a PS is reasonable enough. And are
we really going to benefit if we argue about the RFC status
here anyway? (Especially when it seems from the text below
and the WG list discussion that your main issue is with the
approach being taken and not with the RFC meta-data or
process followed.)

But in any case, this is changing protocol that is specified
in PS RFCs so a PS RFC does seem like the only good choice in
this case. I think the WG also made that choice because this
formally updates a bunch of RFCs and they want implementers
of those to pick this up, which is a teeny bit more likely
with the updates meta-data in the RFC editor's database.
That's explicitly noted in the shepherd's write-up [1] and I
assume was made clear on the WG list. As also noted in [1]
the volume of mail on this was very high, so I'd have to go
look. So having this be a PS that updates a bunch of other
PS RFCs is cleaner and I hope avoids a bunch of RFC process
wrangling. (It is sadly not uncommon for one or other of us
on the IESG to quibble about the utterly boring minutiae of
such relationships between RFCs as we process them:-)

> As far as I understand, this fix exists because Microsoft, Google and
> Mozilla cannot coordinate and drop their insecure negotiation of TLS.

I don't see that as a new argument. I think we all agree
there is a problem. The TLS WG (after much debate) chose
this particular approach. At this point I do not see that
opinions as to the ultimate cause of the problem are useful
for the IETF LC.

Cheers,
S.

[1]
https://datatracker.ietf.org/doc/draft-ietf-tls-downgrade-scsv/shepherdwriteup/


> 
> regards,
> Nikos
> 
> 


From SRS0=W2x6=B7=acm.org=bmoeller@srs.kundenserver.de  Mon Jan 12 03:52:28 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDD111A8AF6; Mon, 12 Jan 2015 03:52:28 -0800 (PST)
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 rUEPIPQwyogm; Mon, 12 Jan 2015 03:52:27 -0800 (PST)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.13]) (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 11DE71A7003; Mon, 12 Jan 2015 03:52:27 -0800 (PST)
Received: from mail-la0-f49.google.com ([209.85.215.49]) by mrelayeu.kundenserver.de (mreue102) with ESMTPSA (Nemesis) id 0LdEdl-1XSByL0fGT-00iRjq; Mon, 12 Jan 2015 12:52:24 +0100
Received: by mail-la0-f49.google.com with SMTP id hs14so23606054lab.8; Mon, 12 Jan 2015 03:52:23 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.112.131.1 with SMTP id oi1mr35369027lbb.2.1421063543170; Mon, 12 Jan 2015 03:52:23 -0800 (PST)
Received: by 10.25.25.145 with HTTP; Mon, 12 Jan 2015 03:52:23 -0800 (PST)
In-Reply-To: <1421054156.3211.15.camel@redhat.com>
References: <20150109180539.22231.7270.idtracker@ietfa.amsl.com> <285245260.5608886.1420918276899.JavaMail.zimbra@redhat.com> <54B1C841.2020707@cs.tcd.ie> <1421054156.3211.15.camel@redhat.com>
Date: Mon, 12 Jan 2015 12:52:23 +0100
Message-ID: 
From: Bodo Moeller 
To: ietf@ietf.org
Content-Type: multipart/alternative; boundary=047d7b343106b1b204050c7323c6
X-Provags-ID: V03:K0:CKeXB4OULY8aOjDTEU+9i3P0VZe+XPPwHHhnlaUJiuBS5PqkXN0 5cpF88PtxbJszikgptkSNDKzcmge4ZzonFMWCtKfslubpCuVwPNKmcUwYg2SVTsAc4pzDu1 JjvMiGYdBtxiPKhStZ73zUywdLy6kxdCzu+d6Tg1m1mzpzV40eNuO6HCfVGAn2AzZa1SmqT lRU7XRfFOMbCZkcbuuyQA==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Jan 2015 11:53:13 -0000

--047d7b343106b1b204050c7323c6
Content-Type: text/plain; charset=UTF-8

Nikos Mavrogiannopoulos :

>
> [...] However, if you think that
> this has to be on standards track, please provide at least some
> argumentation for it.
>

draft-ietf-tls-downgrade-scsv-03 mandates server-side behavior (in response
to certain Client Hello messages) that requires wide deployment to achieve
the desired effect, hence Standards Track seems appropriate and
Informational status would be insufficient.

I don't agree with your assessment that "Making this a proposed standard,
would imply that the flawed technique is into standards track."
draft-ietf-tls-downgrade-scsv-03
does not say that clients should implement a downgrade dance, it merely
recommends sending a certain signal *if* they choose to do so.

Also note that the point that some clients may use downgraded retries for
compatibility with buggy servers *is* already acknowledged by Standards
Track RFCs, e.g. RFC 5246 Appendix E.1:  "Note: some server implementations
are known to implement version negotiation incorrectly. [...]
Interoperability with such buggy servers is a complex topic beyond the
scope of this document, and may require multiple connection attempts by the
client."

Bodo

--047d7b343106b1b204050c7323c6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Niko=
s Mavrogiannopoulos <nmav@redhat.com>:
=C2=A0

[...] However, if you think that

this has to be on standards track, please provide at least some

argumentation for it.

draft-ietf-tls-do=
wngrade-scsv-03 mandates server-side behavior (in response to certain Clien=
t Hello messages) that requires wide deployment to achieve the desired effe=
ct, hence Standards Track seems appropriate and Informational status would =
be insufficient.

I don't agree with your asses=
sment that "Making this a proposed stan=
dard, would=C2=A0imply that the flawe=
d technique is into standards track." =C2=A0draft-ietf-tls-down=
grade-scsv-03 does not say that clients should implement a downgrade dance,=
 it merely recommends sending a certain signal *if* they choose to do so.

Also note that the point that some clients may use =
downgraded retries for compatibility with buggy servers *is* already acknow=
ledged by Standards Track RFCs, e.g. RFC 5246 Appendix E.1: =C2=A0"Not=
e: some server implementations are known to implement version negotiation i=
ncorrectly. [...] Interoperability with such buggy servers is a complex top=
ic beyond the scope of this document, and may require multiple connection a=
ttempts by the client."

Bodo



--047d7b343106b1b204050c7323c6--


From nobody Mon Jan 12 04:03:48 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB58A1A8F3C; Mon, 12 Jan 2015 04:03:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level: 
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, 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 b-s8aySwhqme; Mon, 12 Jan 2015 04:03:43 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FAC21A8BB7; Mon, 12 Jan 2015 04:03:42 -0800 (PST)
Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t0CC3btf023673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 12 Jan 2015 07:03:38 -0500
Received: from dhcp-2-127.brq.redhat.com (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t0CC3YQ5010194 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 12 Jan 2015 07:03:36 -0500
Message-ID: <1421064214.3211.29.camel@redhat.com>
From: Nikos Mavrogiannopoulos 
To: Stephen Farrell 
Date: Mon, 12 Jan 2015 13:03:34 +0100
In-Reply-To: <54B3ABF9.7000809@cs.tcd.ie>
References: <20150109180539.22231.7270.idtracker@ietfa.amsl.com> <285245260.5608886.1420918276899.JavaMail.zimbra@redhat.com> <54B1C841.2020707@cs.tcd.ie> <1421054156.3211.15.camel@redhat.com> <54B3ABF9.7000809@cs.tcd.ie>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
Archived-At: 
Cc: ietf@ietf.org, tls@ietf.org
Subject: Re: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Jan 2015 12:03:46 -0000

On Mon, 2015-01-12 at 11:11 +0000, Stephen Farrell wrote:

> > It's not up to me to say whether there was consensus for this draft or
> > not. 
> Yep, we'll see when the IETF LC is done.
> > I voiced my opinion against that draft. 
> Not quite. You said this "cannot be" a PS based on an argument
> that is independent of the content of the draft.

I assumed that the history of discussions on this draft was known. There
have been long discussions in this list about this draft, where my
opinion was expressed. For example:
The thread:
https://www.ietf.org/mail-archive/web/tls/current/msg13871.html
My opinion:
http://www.ietf.org/mail-archive/web/tls/current/msg14016.html

regards,
Nikos



From nobody Mon Jan 12 14:38:45 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD3A1A87D5 for ; Mon, 12 Jan 2015 14:38:43 -0800 (PST)
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 3BdTpW29WOGM for ; Mon, 12 Jan 2015 14:38:41 -0800 (PST)
Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 535DF1A1A86 for ; Mon, 12 Jan 2015 14:38:41 -0800 (PST)
Received: by mail-we0-f173.google.com with SMTP id q58so21745000wes.4 for ; Mon, 12 Jan 2015 14:38:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:content-type:message-id:mime-version:subject:date:references :to:in-reply-to; bh=5fO1d8NN7CEWKjjamVqifsIdF1O1LIalslSdiw+Bnb0=; b=JWn2zK9PgdkU1TZnGGUOniOMdu8MwYKjmzy7bUjg1kikkgSvzhEwDNFyH4J2ZA7cPj NwLgF9eQrMjwXN1hUcqt0CA72X30YafXzdHSjojA0LDBtZixXIKtL7SM6su8yyoBsbR2 h3AYx9RsHTrwOWjSrXbJfm18L7kkN2ra+LDL0P51EnxVJqoFB4ar8p3r/wkoEmYVKk2T U38zB7uLp3I3+vo7IXwhR1GrPW7KTJNDtwsIXLCdcLt012qgRUYafP1CqvNq4pSF4DIR zwd0g375oJVD+v/fhD2G5MSRdfUdAn3300ScWOhfv6LAHNGru0EkTlEQb8C5sYF3qKN9 pTog==
X-Received: by 10.194.187.235 with SMTP id fv11mr63243447wjc.16.1421102320094;  Mon, 12 Jan 2015 14:38:40 -0800 (PST)
Received: from [192.168.1.15] ([46.120.13.132]) by mx.google.com with ESMTPSA id cg8sm23331562wjc.1.2015.01.12.14.38.38 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 12 Jan 2015 14:38:39 -0800 (PST)
From: Yoav Nir 
Content-Type: multipart/alternative; boundary="Apple-Mail=_CFEBD4C7-95EC-44D5-866A-739890D497DD"
Message-Id: <4C94ED9B-F29C-4830-96BE-762788DCC870@gmail.com>
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
Date: Tue, 13 Jan 2015 00:38:38 +0200
References: <274716D0-EC91-4131-A8F7-CD13A9B42CE7@gmail.com> 
To: "TLS@ietf.org (tls@ietf.org)" 
In-Reply-To: 
X-Mailer: Apple Mail (2.1993)
Archived-At: 
Subject: Re: [TLS] RFC4492bis - Removing ECDH
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Jan 2015 22:38:43 -0000

--Apple-Mail=_CFEBD4C7-95EC-44D5-866A-739890D497DD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

OK. Seeing as there was some support and no objection, the ECDH stuff is =
removed.

I=E2=80=99ll post version -01 in a minute.

Yoav

> On Jan 7, 2015, at 4:23 PM, Yoav Nir  wrote:
>=20
> Hi.
>=20
> I realize this was sent right in the middle of the holiday season, so =
I=E2=80=99ll give it another try.
>=20
> Please have a look at the pull request and post comments to the list =
about whether you=E2=80=99re fine with removing ECDH.
>=20
> Thanks
>=20
> Yoav
>=20
>> On Dec 16, 2014, at 12:29 AM, Yoav Nir > wrote:
>>=20
>> Hi.
>>=20
>> I=E2=80=99ve created pulll request #2 for removing references to ECDH =
(static elliptic curve key) key exchange and ciphersuites.
>>=20
>> https://github.com/tlswg/rfc4492bis/pull/2 =

>>=20
>> Nikos suggested it here: =
http://www.ietf.org/mail-archive/web/tls/current/msg14555.html =

>> Yes, there are other suggestions there, but I=E2=80=99d like to take =
them one by one.
>>=20
>> Let me know what you think
>>=20
>> Yoav
>>=20
>=20


--Apple-Mail=_CFEBD4C7-95EC-44D5-866A-739890D497DD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

OK. Seeing as there was some support and no objection, the =
ECDH stuff is removed.

I=E2=80=99ll post version -01 in a minute.

Yoav

On Jan 7, 2015, at 4:23 PM, Yoav Nir <ynir.ietf@gmail.com>=
 wrote:

Hi.

I realize this was sent =
right in the middle of the holiday season, so I=E2=80=99ll give it =
another try.

Please have a look at the pull request and post comments to =
the list about whether you=E2=80=99re fine with removing ECDH.

Thanks

Yoav

On Dec 16, 2014, at 12:29 AM, Yoav Nir <ynir.ietf@gmail.com>=
 wrote:

Hi.

I=E2=80=99ve created =
pulll request #2 for removing references to ECDH (static elliptic curve =
key) key exchange and ciphersuites.

https://github.com/tlswg/rfc4492bis/pull/2

Nikos suggested it =
here: http://www.ietf.org/mail-archive/web/tls/current/msg14555.html<=
/a>
Yes, there are other suggestions there, but =
I=E2=80=99d like to take them one by one.

Let me know what you think

Yoav



=

--Apple-Mail=_CFEBD4C7-95EC-44D5-866A-739890D497DD--


From nobody Mon Jan 12 14:38:56 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E01101ACDF3; Mon, 12 Jan 2015 14:38:54 -0800 (PST)
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 sq8uGZg-algb; Mon, 12 Jan 2015 14:38:51 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 826141ACDF1; Mon, 12 Jan 2015 14:38:51 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.10.0.p8
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150112223851.26462.69405.idtracker@ietfa.amsl.com>
Date: Mon, 12 Jan 2015 14:38:51 -0800
Archived-At: 
Cc: tls@ietf.org
Subject: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-01.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Jan 2015 22:38:55 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Transport Layer Security Working Group of the IETF.

        Title           : Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier
        Author          : Yoav Nir
	Filename        : draft-ietf-tls-rfc4492bis-01.txt
	Pages           : 30
	Date            : 2015-01-12

Abstract:
   This document describes key exchange algorithms based on Elliptic
   Curve Cryptography (ECC) for the Transport Layer Security (TLS)
   protocol.  In particular, it specifies the use of Ephemeral Elliptic
   Curve Diffie-Hellman (ECDHE) key agreement in a TLS handshake and the
   use of Elliptic Curve Digital Signature Algorithm (ECDSA) as a new
   authentication mechanism.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-rfc4492bis-01


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Tue Jan 13 08:40:13 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 957671A8AE6 for ; Tue, 13 Jan 2015 08:40:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.096
X-Spam-Level: *
X-Spam-Status: No, score=1.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.793, 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 h1oFHwnasEUG for ; Tue, 13 Jan 2015 08:40:08 -0800 (PST)
Received: from vps2.offspark.com (unknown [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 934EF1A1B91 for ; Tue, 13 Jan 2015 08:40:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim;  h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=Kg+Kb5MJLQnAsfGNxpFalf8Gc4M/LxfZ0wOe40bc9Vo=;  b=fFpLl6RVVTQPr5/qn1h8r6LVdFw53DzegAL1RqsM3Khp1UWvDbCcPcHOCX9tdh7A8AlZk/xDrad4RXPprxAk7aSP0mnM+4vrEBGzVS0t8j0Uj5X4I52o4yDdB0TVc+y/dGF+KOGuJqwmbBojgXmPGYj1kmSf1ZPr6du/rnv9E8k=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YB4VR-00018r-TM; Tue, 13 Jan 2015 17:39:50 +0100
Message-ID: <54B54A5F.7020401@polarssl.org>
Date: Tue, 13 Jan 2015 17:39:59 +0100
From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: "Paterson, Kenny" ,  Peter Gutmann , "" 
References: <9A043F3CF02CD34C8E74AC1594475C73AAF525B9@uxcn10-tdc05.UoA.auckland.ac.nz> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: 
Subject: Re: [TLS] AAED ciphers: AES-GCM vs AES-EAX/AES-CCM: a meta-analysis
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jan 2015 16:40:12 -0000

On 06/01/2015 11:35, Paterson, Kenny wrote:
> On 06/01/2015 10:27, "Peter Gutmann"  wrote:
> 
>> The MAC is whatever is negotiated for the session, and if you want a
>> shorter
>> one you can send the truncated-MAC extension (which, however, nothing
>> supports
>> AFAIK).  
> 
For some definition of nothing, which includes CyaSSL, MatrixSSL, PolarSSL and
apparently RSA BSAFE too:
https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations#Extensions

(FWIW, in PolarSSL we're going to disable it by default in the next major version.)

> It's good that nothing supports the truncated-MAC extension, because, in
> combination with TLS's support for variable length padding, it introduces
> a security vulnerability. See:
> 
> http://www.isg.rhul.ac.uk/~kp/mee-comp.pdf
> 
> 
> which shows that if the tag size (MAC length) is shorter than the CBC-mode
> block size, then there's a distinguishing attack that can tell the
> difference between the encryption of a short message and a longer message
> (even though both are padded to the same size before encryption).
> 
But if one does not expect any length hiding, is there still a problem with
truncated MACs?

Manuel.


From nobody Tue Jan 13 09:04:37 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 374E91A901E for ; Tue, 13 Jan 2015 09:04:35 -0800 (PST)
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 Sv_hNPge9GJA for ; Tue, 13 Jan 2015 09:04:32 -0800 (PST)
Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 844391A1EEF for ; Tue, 13 Jan 2015 09:04:32 -0800 (PST)
Received: by mail-wg0-f45.google.com with SMTP id y19so4192041wgg.4 for ; Tue, 13 Jan 2015 09:04:31 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type; bh=iYklQPqrB62bTc6/HJYeq1gFtOoPrMNxn8Tth+D3Nx8=; b=HrHzOEA80G5gQTeHEYWOeTDlZDAkJeVC3Cn6dK6tmytbrgxBdWrho+1oQhX9wYP/ET G+Y3lzaS9GSw4CpM3UtsZ2q50msTphDKG4Xdsykc9al9JFNk22tI0Oq2u7lFYhfyZa/4 hpMCm8XNK1/fnuFvjSDFuqPFMkn+kcZYEHRSCBoWq9bmZMd6BKCkQqjBoxAldK6bz+6M KXYYs0nrQ+Dtv49VCER/lhCdXQAgoMcKXiKV6u7wrqK1KjDBjpGAGlwq1w4LqGp0JWBT 0Nni1+ZHCXdvfaWl0KuCuUg6eQwUVLMSFWiy4T18P8tZbssbUNO3rrPOplJuwzdAJAhB W67Q==
X-Gm-Message-State: ALoCoQkwp8mLWxXO2FLgMqQ6KcMUE62M73zcdblP6IHZzIt4+y6aZLcFvuA9E9Zw2Bphz3ef0bf/
X-Received: by 10.180.72.199 with SMTP id f7mr576927wiv.58.1421168671015; Tue, 13 Jan 2015 09:04:31 -0800 (PST)
Received: from [192.168.23.139] (chello084112076043.34.11.vie.surfer.at. [84.112.76.43]) by mx.google.com with ESMTPSA id dp8sm15012111wib.20.2015.01.13.09.04.29 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 13 Jan 2015 09:04:30 -0800 (PST)
Message-ID: <54B5501A.4070402@azet.org>
Date: Tue, 13 Jan 2015 18:04:26 +0100
From: Aaron Zauner 
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: TLS Mailing List 
X-Enigmail-Version: 1.2.3
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig50A0D33EBD0ACAF1223F5C65"
Archived-At: 
Subject: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jan 2015 17:04:35 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig50A0D33EBD0ACAF1223F5C65
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi TLS-WG,

Over the last couple of days I've again looked into OCB, read the
original paper as well as quite some literature on it, patents, CFRG
discussion et cetera.

OCB looks like an elegant and parallel mode for inclusion in TLS.
I've searched through recent TLS-WG discussion, OCB has been
mentioned in passing as has EAX(2). When first looking into that my
main concerns were:

   * IPR/patents: the authors have granted access to OSI licensed
     software as well as to commercial (non military!) software for
     all use [0] [1].

   * IETF applicability: an informational RFC has been written by
     the original author of OCB mode, reviewed and accepted by CFRG
     and published by IESG in May 2014 [RFC7253].

   * Software implementations: OCB mode is available in various
     cryptographic libraries:

      - OpenSSL's 1.0.2 branch

(https://github.com/openssl/openssl/blob/0c1bd7f03fcd1cc8256f89f4962d91b7=
8432c74a/crypto/modes/ocb128.c)

      - Bouncy Castle
        (https://www.bouncycastle.org/specifications.html)

      - Botan

(https://github.com/randombit/botan/tree/74522169a907715d4d41b3680f20b6f8=
66733de7/src/lib/modes/aead/ocb)

      - Soon; dynamic languages linking to these libraries.

      - I might have left out a few, where I couldn't find a
        clear indication that they intend to support OCB mode.

=46rom looking at [RFC7253] it would make sense to have;
`AEAD_AES_128_OCB_TAGLEN64` and `AEAD_AES_256_OCB_TAGLEN128` in TL3
1.3 ciphersuites.

Now I'm a bit clueless as to how new AEAD modes are supposed to be
added to TLS 1.3. In the past there have been various documents
extending TLS ciphersuites by a certain block cipher/AEAD mode:
[RFC5288] [RFC6367] [RFC6655] [RFC5528] [RFC6209]. There is a
general document for an interface for AEAD modes [RFC5116] which the
authors have used for their informational RFC [RFC7253]. I'd like to
ask for a bit of guidance how this can be done more efficiently for
all ciphers that will end up in TLS 1.3. Having a seperate RFC for
every cipher and thus ciphersuite seems a bit confusing. Is this the
intended approach still?

I'd be willing to author such a document or make the necessary
changes to the TLS 1.3 draft in order to get OCB mode into TLS 1.3.
Currently we're limited to GCM (with known issues on mobile
plattforms) and CCM (CBC-MAC, which is one of the reasons the OCB
authors started work on this mode, because it's more elegant and
efficient).


Recent developments regarding OCB mode are documented here:
http://web.cs.ucdavis.edu/~rogaway/ocb/news/

All and any input appreciated.

Thanks,
Aaron

[0] https://www.ietf.org/mail-archive/web/cfrg/current/msg03301.html
[1] http://web.cs.ucdavis.edu/~rogaway/ocb/ocb-faq.htm#patent:phil


--------------enig50A0D33EBD0ACAF1223F5C65
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUtVAbAAoJEOTbZJL9ubXVgQYP/2RW7Oj8Ge0hPYbdXdvVUbkg
IuXelngNiQpXbKx7mU91LgIm8FVSpciyi9Lfyuj5yLNLTat3+84icYQHlMLhGyB/
XHz431W94bbL3PoP232ljjn2FTl9pEziTryibEq4okDk8AryfVyGVPTTnWSRVbeW
dLRcizkdjeTnSj8EJ+Kwtwx/omWd5z70wkE8jGx2aDvv0jIxnMdyWSFz/X8hRIZ0
qi/+Cy46IvrL96zuYy6itw+XC3Z+mW5bGZ7JYzOLCUPmWaM0K81n0X0KaWLrLjjz
YsbBXNLTRTvMzxcx7aC2eBh3HyY/Vu2sonLI6+5OXn3+AdcRzF+0XkWdfyTPRq8r
Dig31WyZzejTjtzLbDUzo1WZlDi+yIGQ2S0U8z1kMtHUbqRA8Y3zd8yi69+0HaPU
wEw6DF/YrvDXgQmjfJnbmNJKHZRjj3PrBX2q42AnF7dQumgGSKrMHGJFeMT79k08
sDTVTrLHthQbKhMqU8phRVf9VfwnGJUz3slbHaUam8hKp9WGzz5njLiIkRi2sdfh
KjcxI2ScvRsEj6ecKkJUFWv+iLzQxFEnOpKhbQq/OEeWuymp2gcZUAin3CIUpIfT
LozonxIh9wtnsT0PIgGnzWMmkJpOUgknHO156SukqR/rahUn7jUN/4cca1SafDZc
44y7IZ/vkic2rzzHd3Vm
=OsiU
-----END PGP SIGNATURE-----

--------------enig50A0D33EBD0ACAF1223F5C65--


From nobody Tue Jan 13 09:26:30 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 343C41A8FD7 for ; Tue, 13 Jan 2015 09:26:27 -0800 (PST)
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 j-tNT2DZ9W02 for ; Tue, 13 Jan 2015 09:26:25 -0800 (PST)
Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C78551A8BB2 for ; Tue, 13 Jan 2015 09:26:24 -0800 (PST)
Received: by mail-oi0-f52.google.com with SMTP id a3so3333086oib.11 for ; Tue, 13 Jan 2015 09:26:24 -0800 (PST)
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=Wm/R9KDDMKx3JUzw/Bh7EIBsTwKz/jiXi2VI/DdPgAk=; b=wTIxO5+IO9wPEJQJasQIPqguCg1VLY/P3TLk8aQFF1Aq4GmHDbvZ46lIM+OucTIGFm /Q2wfBSMyfsspD9JkUsgwKI/PDZdiNsov9sgzqCeFGodg/idrORY7bKFN4z2M9tM44N1 SYiFCrFgIqMXSHS6bRh1i1atTPRM7wi5FvgGCeaGnN3yJu+gFzLjMsZvfLrHMjHJ9MMC Pz//iNoYnbtQLYxtoVh5/VI9Q/M3k6NPEwaDfj86f+6a6AheexF4pOzXXpf/TNIpxs9C xvQXzYxvvFIDd9l8urZZprwlLLhwwRolaR2XSCF+sXppx/dNaDYKnvpv6X58M23f6rMq +ciw==
MIME-Version: 1.0
X-Received: by 10.202.89.213 with SMTP id n204mr20259461oib.77.1421169984129;  Tue, 13 Jan 2015 09:26:24 -0800 (PST)
Received: by 10.202.226.136 with HTTP; Tue, 13 Jan 2015 09:26:24 -0800 (PST)
In-Reply-To: <54B5501A.4070402@azet.org>
References: <54B5501A.4070402@azet.org>
Date: Tue, 13 Jan 2015 09:26:24 -0800
Message-ID: 
From: Martin Thomson 
To: Aaron Zauner 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: TLS Mailing List 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jan 2015 17:26:27 -0000

On 13 January 2015 at 09:04, Aaron Zauner  wrote:
> Now I'm a bit clueless as to how new AEAD modes are supposed to be
> added to TLS 1.3.


In this case, I would suggest writing an Internet Draft describing how
the cipher suite is identified and how it operates.  That would be a
relatively short document.

Unless there are specific reasons not to, a new AEAD cipher should be
defined for TLS 1.2 as well.  One reason (that doesn't apply to OCB)
is that it might require non-deterministic padding, for which there is
a bug in the TLS 1.2 AEAD construction (see
https://github.com/tlswg/tls13-spec/issues/47).

There are, of course, reasons why people would not want to accept a
proposal like that.  More cipher suites isn't strictly a good thing.
Of course, if OCB is demonstrably better in some fashion (speed,
security, whatever it happens to be), then that makes the case easier.


From nobody Tue Jan 13 09:29:44 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 334AA1A8FD6 for ; Tue, 13 Jan 2015 09:29:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 xpmtc29Hl9Ye for ; Tue, 13 Jan 2015 09:29:36 -0800 (PST)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 25DC31A8BB2 for ; Tue, 13 Jan 2015 09:29:36 -0800 (PST)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 4CD1347618; Tue, 13 Jan 2015 17:29:35 +0000 (GMT)
Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 3E8614764A; Tue, 13 Jan 2015 17:29:35 +0000 (GMT)
Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 386B68004B; Tue, 13 Jan 2015 17:29:35 +0000 (GMT)
Received: from USMA1EX-CASHUB4.kendall.corp.akamai.com (172.27.105.20) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.913.22; Tue, 13 Jan 2015 12:28:22 -0500
Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Tue, 13 Jan 2015 12:28:22 -0500
From: "Salz, Rich" 
To: Martin Thomson , Aaron Zauner 
Date: Tue, 13 Jan 2015 12:28:21 -0500
Thread-Topic: [TLS] Inclusion of OCB mode in TLS 1.3
Thread-Index: AdAvVhRM6PILn8G7QbSEUrUjCsrXnQAABz+A
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D55AEC364@USMBX1.msg.corp.akamai.com>
References: <54B5501A.4070402@azet.org> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: TLS Mailing List 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jan 2015 17:29:38 -0000

> There are, of course, reasons why people would not want to accept a
> proposal like that.  More cipher suites isn't strictly a good thing.
> Of course, if OCB is demonstrably better in some fashion (speed, security=
,
> whatever it happens to be), then that makes the case easier.

That "no military use" being particularly problematic.  Does anyone know if=
 the IETF has other IPR grants with similar field-of-use limitations?

	/r$

-- =20
Principal Security Engineer, Akamai Technologies
IM: rsalz@jabber.me Twitter: RichSalz



From nobody Tue Jan 13 09:33:04 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B90D1A6FF7 for ; Tue, 13 Jan 2015 09:33:03 -0800 (PST)
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 BU8LNIGx0v4c for ; Tue, 13 Jan 2015 09:33:02 -0800 (PST)
Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D1B01A6F2A for ; Tue, 13 Jan 2015 09:33:01 -0800 (PST)
Received: by mail-wi0-f175.google.com with SMTP id l15so22932260wiw.2 for ; Tue, 13 Jan 2015 09:33:00 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=2B4oxeYVFfULln3w7V7qkm532YeKGLesUVsGtTeJ9Yg=; b=TC2Uo7o8TRThheIt8xf45hBKmpw3VRItgyjrQRd2D6sSYkRWlpEp6CLbDONvlGCBB6 w/OmoeZHidCg0oBNxR8kdP8sGrL2vxS0UjvFnBrFk+UcArNMKs9x9i7DLO1931fOR6bk wvOFV4mn7tJQ1mawkCr+n6xGg31kOrxTCEmZiHh4rqUwxizgE5tQ5PVtO+iIg1xRPWk/ HC/+oPyeOdRV09YeReyXLyDzfY3rVsL78Qt/WzsQoIqQo/GQs5O9H40hjo6Okzc9OtHY /3rKyVTfZaukmVqFDO610PCHY0WeEeK35Lu+5stgHULmy/saovdxj8EMJhgsg7XA5vm/ a3zQ==
X-Gm-Message-State: ALoCoQk0teJTIsSAu+FhioCXuAbSQ07lBoq/k5b0DdQvKCRK6UTHBJfV7JE+38f5akV9QWHovCMI
X-Received: by 10.180.21.225 with SMTP id y1mr6439952wie.42.1421170380174; Tue, 13 Jan 2015 09:33:00 -0800 (PST)
Received: from [192.168.23.139] (chello084112076043.34.11.vie.surfer.at. [84.112.76.43]) by mx.google.com with ESMTPSA id cs8sm15152557wib.1.2015.01.13.09.32.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 13 Jan 2015 09:32:59 -0800 (PST)
Message-ID: <54B556C7.4070808@azet.org>
Date: Tue, 13 Jan 2015 18:32:55 +0100
From: Aaron Zauner 
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: "Salz, Rich" 
References: <54B5501A.4070402@azet.org>  <2A0EFB9C05D0164E98F19BB0AF3708C71D55AEC364@USMBX1.msg.corp.akamai.com>
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D55AEC364@USMBX1.msg.corp.akamai.com>
X-Enigmail-Version: 1.2.3
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig083DD899B55C3347C37FA3C6"
Archived-At: 
Cc: TLS Mailing List 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jan 2015 17:33:03 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig083DD899B55C3347C37FA3C6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



Salz, Rich wrote:
>> There are, of course, reasons why people would not want to accept a
>> proposal like that.  More cipher suites isn't strictly a good thing.
>> Of course, if OCB is demonstrably better in some fashion (speed, secur=
ity,
>> whatever it happens to be), then that makes the case easier.
>=20
> That "no military use" being particularly problematic.  Does anyone kno=
w if the IETF has other IPR grants with similar field-of-use limitations?=

>=20
I agree (actually, personally; I do not care). But it seems to have made
through CFRG/IESG review and was accepted (see rogaways email regarding
IPR issues). Can someone with more knowledge about handling IPR issues
like this very specific one comment on this?

Thanks,
Aaron


--------------enig083DD899B55C3347C37FA3C6
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUtVbHAAoJEOTbZJL9ubXVBB4P/R4MxWw+SYhNA6qAxAaEjjnP
5aSliTnftojwd867ss26UIQbqCh+0Xxv5v5Rjs0ZBMC2M5GYztR9kE4KFDx7rFH6
xcHxsYv1N2Uj20ZVrVoAjBMJ7CbexWkhjFcdcCURXTdrzzwRxPP9jLq5BO1kJttO
O4fdxYFzUN0TTSPUgnqm8FY8txmoPeuK6mVf1p/shputkAcM2oTBLyxsK6QPgk6h
84zLuxud5GB8FB+iUbWC40Jm6UZ2PVWCyd7oAdjID8EY2rsm02kjuFFUv70qB26h
JnAibPbwzJc0gZHp3EDnCK1vhZxa6BrUOeMEMi488A1I+LPVsMDEQYbKov0KJPbR
Z9xB+Izxv5Lte2Gwno4URNVVIphe7qWmAM9l2FXVhTb7YOorymdMCQn8j2tHpuo4
4oxxT25VD89y8oqmLx2L1FhNsYDn4Xkj9yjapyBxp7HRnbfzTAqnwHpKm2/JlEtk
SjoeDQd0yzKbQ7chQi7w9VF03CMlCa7nx/+T8Zj9QMyNZYtNPZJintn79Jht152A
XNWgBhP4TlshifhcRBvhk0Sw+VOXeJMlaytZEdOMXNIkB30SqTd3AZjsn7fAZK+j
ziXKeLEda942iKLZpXM2si2si5SDMTu9HTI7/sIjSc4xC8fu29pcyWP6XMTWxvz9
tHlo6PntG72UjXnCvtRX
=J3lD
-----END PGP SIGNATURE-----

--------------enig083DD899B55C3347C37FA3C6--


From nobody Tue Jan 13 09:43:54 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B661F1A8BB2 for ; Tue, 13 Jan 2015 09:43:52 -0800 (PST)
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 TLXnkhFVzuOA for ; Tue, 13 Jan 2015 09:43:50 -0800 (PST)
Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2C421A6FF7 for ; Tue, 13 Jan 2015 09:43:49 -0800 (PST)
Received: by mail-we0-f176.google.com with SMTP id w61so4303175wes.7 for ; Tue, 13 Jan 2015 09:43:48 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=FZyHJfZWAar/6Y6CCwCQFfpTXAI02CxeSuRVgs49NUE=; b=RE6D6vBa2RO5oXiHIShlOXlG0L1bN/7lYBlz1sJdh7cm69cE/qEQVn/oSl/5u9j8bY ZMHG8BVx15oY04LiqcNvOnQTHANKPEg8uRnDRFx5B2oCElMPLuhnW+ZYOzPrLqPeS1uO WXkP6YJGLU5s1/XTUF60bFtnK0C57FvQMmn90TxB+or8CaXxzFt/kPtgU2FwiB40OtuO ywbyAim1QFj950z7LQ+pewQ7F/vV/JQUz/pwMPsNEhTX2n9gdkQFCczQVnMehN5qAeDN +u+qdePG9NNXJiZShg/gZY9b+MM9CADE3ab5x6olIBZWr84RQDFfGVxstquofbhi8nO3 iHcw==
X-Gm-Message-State: ALoCoQk6/Pw3Srz0K0A2nv3KDEe8s/Ep2lxjU4+AJ4BSMvCUTdMflkmTmIw9lj/5V9QdR3O8FozJ
X-Received: by 10.180.198.52 with SMTP id iz20mr42839940wic.60.1421171028511;  Tue, 13 Jan 2015 09:43:48 -0800 (PST)
Received: from [192.168.23.139] (chello084112076043.34.11.vie.surfer.at. [84.112.76.43]) by mx.google.com with ESMTPSA id vj1sm26565556wjc.49.2015.01.13.09.43.47 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 13 Jan 2015 09:43:47 -0800 (PST)
Message-ID: <54B55950.4090606@azet.org>
Date: Tue, 13 Jan 2015 18:43:44 +0100
From: Aaron Zauner 
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: Martin Thomson 
References: <54B5501A.4070402@azet.org> 
In-Reply-To: 
X-Enigmail-Version: 1.2.3
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigA014A117FA4EB62FA2BB6E02"
Archived-At: 
Cc: TLS Mailing List 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jan 2015 17:43:53 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigA014A117FA4EB62FA2BB6E02
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



Martin Thomson wrote:
> On 13 January 2015 at 09:04, Aaron Zauner  wrote:
>> Now I'm a bit clueless as to how new AEAD modes are supposed to be
>> added to TLS 1.3.
>=20
>=20
> In this case, I would suggest writing an Internet Draft describing how
> the cipher suite is identified and how it operates.  That would be a
> relatively short document.
>=20
> Unless there are specific reasons not to, a new AEAD cipher should be
> defined for TLS 1.2 as well.  One reason (that doesn't apply to OCB)
> is that it might require non-deterministic padding, for which there is
> a bug in the TLS 1.2 AEAD construction (see
> https://github.com/tlswg/tls13-spec/issues/47).

Thanks for this piece of information! So that would be an ID to the
extent of RFC5288 or RFC6655.

> There are, of course, reasons why people would not want to accept a
> proposal like that.  More cipher suites isn't strictly a good thing.
> Of course, if OCB is demonstrably better in some fashion (speed,
> security, whatever it happens to be), then that makes the case easier.

Generally I would agree, but I think for now OCB mode would be a very
good addition to AEAD in TLS. Let's see what the CAESAR competition
brings us in 2017,..

Aaron


--------------enigA014A117FA4EB62FA2BB6E02
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUtVlQAAoJEOTbZJL9ubXVuAMQAJbQGcyeepEphewOec+xeT9H
vv8knzF5CeUpFRu15gGmXwAr7wZTdiarX+2JlrM+Ff/wRohuJcpbsDikw3MEnPoe
E/+3fdS3cRSXwe7kc3HqpHK3huWtCLkL1hp6jtymj71r936IDvaqKI8fDy2MbxKL
Dmb355ii29x3ax5Nfs5xMBsc45eFGzrbXVmUhjYXoMFifGIBqe/4E3WvXOlceSTO
srphjs2gtjNJrbrVM0PhAxv1LPO9bQ/o74vgP6aXaEtzYeeCRKAyK2e3ZLtRwSXu
4sykri64JKZiF906taFcP1ybWyZI3l+aorgWo6E3dT0H7IW+GL0yndUN0j7m2XlH
nBfwLRkCRi/Mxv+RE2DkNeCdeMnmOY0DoCFzqBhSS3uY+F6iuJyutp9F04Tf2HvG
CnmPX7oosTnQBJpiy7w9HWskX7P4ROntvgB1Ggn3nHb+IuomgyGV5pzjk3fy634A
pNI+HOUs5yxktTXnJiBWrNdFlwoBUvhpgsNNmuvqlICaaX9V3mCKeYdFJf6mDqyB
y3BHAxUIpMIzW+MzJ9j6lL/yoG6FbGlR2mUjBZCkkCe7DhAfIDCZ6TiamlsHhaeL
WtLWSZrHMJDcvw8wrR3de1HqvoXY1wFrL/Z+2YmY18mdM9DBf5/wCIz/pM4cqZo8
/ai7Pw49+KsAt+xa8aOB
=4y/7
-----END PGP SIGNATURE-----

--------------enigA014A117FA4EB62FA2BB6E02--


From nobody Tue Jan 13 09:46:13 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEF991A8BB2 for ; Tue, 13 Jan 2015 09:46:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 m7Yc88QDSLqy for ; Tue, 13 Jan 2015 09:46:08 -0800 (PST)
Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9AB1A6FF7 for ; Tue, 13 Jan 2015 09:46:08 -0800 (PST)
Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id EA7CE9A400F; Tue, 13 Jan 2015 12:45:57 -0500 (EST)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id h5UDk6xAH6Dh; Tue, 13 Jan 2015 12:45:35 -0500 (EST)
Received: from [192.168.2.101] (pool-173-79-205-14.washdc.fios.verizon.net [173.79.205.14]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 188029A4012; Tue, 13 Jan 2015 12:45:35 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: Russ Housley 
In-Reply-To: <54B5501A.4070402@azet.org>
Date: Tue, 13 Jan 2015 12:45:22 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <54B5501A.4070402@azet.org>
To: Aaron Zauner 
X-Mailer: Apple Mail (2.1085)
Archived-At: 
Cc: TLS Mailing List 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jan 2015 17:46:12 -0000

I do not mind OCB being specified for _optional_ use with TLS, but there =
are unencumbered alternatives, and one of those alternatives should be =
the mandatory to implement algorithm.

Russ


On Jan 13, 2015, at 12:04 PM, Aaron Zauner wrote:

> Hi TLS-WG,
>=20
> Over the last couple of days I've again looked into OCB, read the
> original paper as well as quite some literature on it, patents, CFRG
> discussion et cetera.
>=20
> OCB looks like an elegant and parallel mode for inclusion in TLS.
> I've searched through recent TLS-WG discussion, OCB has been
> mentioned in passing as has EAX(2). When first looking into that my
> main concerns were:
>=20
>   * IPR/patents: the authors have granted access to OSI licensed
>     software as well as to commercial (non military!) software for
>     all use [0] [1].
>=20
>   * IETF applicability: an informational RFC has been written by
>     the original author of OCB mode, reviewed and accepted by CFRG
>     and published by IESG in May 2014 [RFC7253].
>=20
>   * Software implementations: OCB mode is available in various
>     cryptographic libraries:
>=20
>      - OpenSSL's 1.0.2 branch
>=20
> =
(https://github.com/openssl/openssl/blob/0c1bd7f03fcd1cc8256f89f4962d91b78=
432c74a/crypto/modes/ocb128.c)
>=20
>      - Bouncy Castle
>        (https://www.bouncycastle.org/specifications.html)
>=20
>      - Botan
>=20
> =
(https://github.com/randombit/botan/tree/74522169a907715d4d41b3680f20b6f86=
6733de7/src/lib/modes/aead/ocb)
>=20
>      - Soon; dynamic languages linking to these libraries.
>=20
>      - I might have left out a few, where I couldn't find a
>        clear indication that they intend to support OCB mode.
>=20
> =46rom looking at [RFC7253] it would make sense to have;
> `AEAD_AES_128_OCB_TAGLEN64` and `AEAD_AES_256_OCB_TAGLEN128` in TL3
> 1.3 ciphersuites.
>=20
> Now I'm a bit clueless as to how new AEAD modes are supposed to be
> added to TLS 1.3. In the past there have been various documents
> extending TLS ciphersuites by a certain block cipher/AEAD mode:
> [RFC5288] [RFC6367] [RFC6655] [RFC5528] [RFC6209]. There is a
> general document for an interface for AEAD modes [RFC5116] which the
> authors have used for their informational RFC [RFC7253]. I'd like to
> ask for a bit of guidance how this can be done more efficiently for
> all ciphers that will end up in TLS 1.3. Having a seperate RFC for
> every cipher and thus ciphersuite seems a bit confusing. Is this the
> intended approach still?
>=20
> I'd be willing to author such a document or make the necessary
> changes to the TLS 1.3 draft in order to get OCB mode into TLS 1.3.
> Currently we're limited to GCM (with known issues on mobile
> plattforms) and CCM (CBC-MAC, which is one of the reasons the OCB
> authors started work on this mode, because it's more elegant and
> efficient).
>=20
>=20
> Recent developments regarding OCB mode are documented here:
> http://web.cs.ucdavis.edu/~rogaway/ocb/news/
>=20
> All and any input appreciated.
>=20
> Thanks,
> Aaron
>=20
> [0] https://www.ietf.org/mail-archive/web/cfrg/current/msg03301.html
> [1] http://web.cs.ucdavis.edu/~rogaway/ocb/ocb-faq.htm#patent:phil
>=20
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


From nobody Tue Jan 13 09:51:37 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 994FB1A8BB2 for ; Tue, 13 Jan 2015 09:51:34 -0800 (PST)
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 lR4lcmR-GbPB for ; Tue, 13 Jan 2015 09:51:33 -0800 (PST)
Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C991F1A9029 for ; Tue, 13 Jan 2015 09:51:26 -0800 (PST)
Received: by mail-we0-f182.google.com with SMTP id w62so4306666wes.13 for ; Tue, 13 Jan 2015 09:51:25 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=nYqrnn8Y2xbAZCIP6khYlkqIskaYotkJ4Fkhty2zy8w=; b=k4d85s4xBEERSvhgGkYSB1aur26ruLXbsf9CxNv0PhPEqLid16SH50/8uLiBPa7N8+ IuGmR/9pTiOOZAWizlfUu4HBPoEsMUC9ZMj9lrsc0s6nOvb7wEeD3urXFkJzhnoaB5iL yv2zt8Rgp2fcVATbl4ioaaPUB4OmPcyeRaWdFp6bqMdrcGm99LtYqVQI1jDnyJzb8LQN uLjgLWI2+oBsdML3SdPv0n+edUBEwNQLM4IKuies/3uGdkjs2diyGAu9P2B8uv71y/O5 4Behj3hcb+tpbZFf/Nl9MQFmmuZNbnlT8b0JdZHTIntf6KiIj7o3Ypf9jeZIKFQ3Z3on 7OUQ==
X-Gm-Message-State: ALoCoQkN6qsiHfwXme+hgMAMgC2MNEgGFa/LnzyeswHCr6zjF8ckZykKw0xloX/i1j3C2keZiEM7
X-Received: by 10.180.72.199 with SMTP id f7mr43125615wiv.53.1421171485574; Tue, 13 Jan 2015 09:51:25 -0800 (PST)
Received: from [192.168.23.139] (chello084112076043.34.11.vie.surfer.at. [84.112.76.43]) by mx.google.com with ESMTPSA id hn2sm26622176wjc.5.2015.01.13.09.51.17 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 13 Jan 2015 09:51:24 -0800 (PST)
Message-ID: <54B55B13.20909@azet.org>
Date: Tue, 13 Jan 2015 18:51:15 +0100
From: Aaron Zauner 
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: Russ Housley 
References: <54B5501A.4070402@azet.org> 
In-Reply-To: 
X-Enigmail-Version: 1.2.3
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig43F6D2057A7D5ADA87B3C8A5"
Archived-At: 
Cc: TLS Mailing List 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jan 2015 17:51:34 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig43F6D2057A7D5ADA87B3C8A5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



Russ Housley wrote:
> I do not mind OCB being specified for _optional_ use with TLS, but ther=
e are unencumbered alternatives, and one of those alternatives should be =
the mandatory to implement algorithm.
>=20

I'm not intimately familiar with EAX(2) but it seems to be a viable
option. I'm currently focused on OCB and the feedback of TLS-WG. If
nobody want's to see it in TLS, I'm not going to write an ID.

Aaron


--------------enig43F6D2057A7D5ADA87B3C8A5
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUtVsTAAoJEOTbZJL9ubXVzqYP/RdZFAGjGQiNMQjxEW8vhA8a
+g0UQGwBlvHXbLUZ1yfxwnvzMBCsOb8EucW/vj+LQwMoL0tDIkQh/gv3xg3SRmJJ
HAhw2hFaDhpMfGvtOo5p/0dOuuY8/3GEv95ZUGmGQy4NFvI7Q4I5NVteN8UXJH/e
lHw50k/JBIvEYKHvnA3dbsIA4LI3zcWM3f8jHO9+gkEj//Y0aYoV8i8MXuk10rPq
YLb+TkprZlJN5nYubzqAKN5ANwnitvNeYDTsmqEB8dI6S89wuf8sRVs1gL9nDfN/
SAKrvJm/AGFtFjBURjAftDWcoIPU5kYUnHcwAe0uxXJ/LRT4cJ2LvxzbyfaG5PEr
hPUdDz8WBNIEMZcapKe1jz7a2r1J2rEj9T78kn/krzrob0TGOW4oCteD6qGDtJAD
4Jc1qwtXC47KjS5MKTe5FGmCIPS/yJiDEGve/MHHWZkVqNqWDueBRDT4yaWSOuQC
Im28vpURVckpHQ2e8Lay5elOIABtWbgOs159UD7Avwk09XgKChnVTv973NV2uG8G
Uyve8R4BMPOwHThSxh/eKT5p+FnC2JGVnBEMqNiiDe03Nv4Iy9GCQiX5C4TAk8sM
GDGHSzhMuW/JX9D/aQykV5JkbAFPgLB5E6OjnRCu5cBTshjMOyvku7bQm3Mmmw6s
/nEhdRZtDo5gu6a39C/P
=0iXC
-----END PGP SIGNATURE-----

--------------enig43F6D2057A7D5ADA87B3C8A5--


From nobody Tue Jan 13 09:53:10 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C64C81A8BB2 for ; Tue, 13 Jan 2015 09:53:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.602
X-Spam-Level: 
X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-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 CCBBnGJyIQkC for ; Tue, 13 Jan 2015 09:53:06 -0800 (PST)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0612.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::612]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA29D1A9029 for ; Tue, 13 Jan 2015 09:53:05 -0800 (PST)
Received: from DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) by DBXPR03MB381.eurprd03.prod.outlook.com (10.141.10.11) with Microsoft SMTP Server (TLS) id 15.1.53.17; Tue, 13 Jan 2015 17:52:41 +0000
Received: from DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) by DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) with mapi id 15.01.0053.000; Tue, 13 Jan 2015 17:52:41 +0000
From: "Paterson, Kenny" 
To: =?iso-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= , "Peter Gutmann" , "" 
Thread-Topic: [TLS] AAED ciphers: AES-GCM vs AES-EAX/AES-CCM: a meta-analysis
Thread-Index: AdApm1DpFjNg+4muRmKsYOSI8dViWQAASE0AAWzH8IAAAojMgA==
Date: Tue, 13 Jan 2015 17:52:41 +0000
Message-ID: 
References: <9A043F3CF02CD34C8E74AC1594475C73AAF525B9@uxcn10-tdc05.UoA.auckland.ac.nz>  <54B54A5F.7020401@polarssl.org>
In-Reply-To: <54B54A5F.7020401@polarssl.org>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.7.141117
x-originating-ip: [134.219.227.30]
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Kenny.Paterson@rhul.ac.uk; 
x-dmarcaction-test: None
x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:DBXPR03MB381;
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:DBXPR03MB381;
x-forefront-prvs: 045584D28C
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(189002)(479174004)(51704005)(243025005)(199003)(24454002)(83506001)(77156002)(54356999)(66066001)(105586002)(106356001)(40100003)(62966003)(19580395003)(19580405001)(50986999)(107886001)(76176999)(2900100001)(2656002)(102836002)(122556002)(15975445007)(68736005)(2950100001)(97736003)(87936001)(74482002)(36756003)(64706001)(46102003)(101416001)(77096005)(86362001)(92566002)(491001); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR03MB381; H:DBXPR03MB383.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: rhul.ac.uk does not designate permitted sender hosts)
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <44B2868B3A312C4EA6A1AABA25C08CD5@eurprd03.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: rhul.ac.uk
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jan 2015 17:52:41.6443 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR03MB381
Archived-At: 
Subject: Re: [TLS] AAED ciphers: AES-GCM vs AES-EAX/AES-CCM: a meta-analysis
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jan 2015 17:53:09 -0000

Hi

On 13/01/2015 16:39, "Manuel P=E9gouri=E9-Gonnard"  wrote=
:
>On 06/01/2015 11:35, Paterson, Kenny wrote:
>> It's good that nothing supports the truncated-MAC extension, because, in
>> combination with TLS's support for variable length padding, it
>>introduces
>> a security vulnerability. See:
>>=20
>> http://www.isg.rhul.ac.uk/~kp/mee-comp.pdf
>>=20
>>=20
>> which shows that if the tag size (MAC length) is shorter than the
>>CBC-mode
>> block size, then there's a distinguishing attack that can tell the
>> difference between the encryption of a short message and a longer
>>message
>> (even though both are padded to the same size before encryption).
>>=20
>But if one does not expect any length hiding, is there still a problem
>with
>truncated MACs?

I think one would expect length hiding at least up to the granularity of
the block size in TLS with CBC mode. (The RFC even suggests that more
should be possible: "Lengths longer than necessary might be desirable to
frustrate attacks on a protocol that are based on analysis of the lengths
of exchanged messages." [1])

As a special case of the general attack, consider a notional application
using TLS that sends either the message "YES" or the message "NO". Suppose
we negotiate truncated MACs, and the TLS Record Protocol implementation
selects the amount of padding to add at random (from the set of possible
padding lengths allowed under the TLS padding scheme).

By truncating the ciphertext, doing some bit flipping, and reinjecting the
modified ciphertext, an adversary can tell whether "YES" or "NO" was
originally encrypted. (This assumes that the minimum amount of padding is
NOT selected; this happens with probability roughly 15/16 under the above
assumptions.)=20

I'd consider that to be an attack in your "don't expect any length hiding"
setting - after all, the difference in plaintext lengths is just 1 byte,
which is well below the CBC-mode block size. Does that seem reasonable, or
is it still outside your attack model?

Cheers

Kenny

[1] RFC 5246, Section 6.2.3.2


From nobody Tue Jan 13 09:54:53 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11D9C1A8FD7 for ; Tue, 13 Jan 2015 09:54:52 -0800 (PST)
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 OPvi5sFMscuP for ; Tue, 13 Jan 2015 09:54:50 -0800 (PST)
Received: from mail-yh0-x22f.google.com (mail-yh0-x22f.google.com [IPv6:2607:f8b0:4002:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A3851A8BB2 for ; Tue, 13 Jan 2015 09:54:50 -0800 (PST)
Received: by mail-yh0-f47.google.com with SMTP id f73so2180598yha.6 for ; Tue, 13 Jan 2015 09:54:49 -0800 (PST)
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=gEY141irdKbIPVoW1yR88PzOMPBmJBlpCERe2dAwXqw=; b=SOf+J3GICbFuPCZRAxg7WNEBjpAAktNHOkbnWIYv++8Q0XlpfVtcadqjQByBP9DnNB 2IvCgTw1x17nkHaQLT3W5h4KlDds7uqutXoINcVcuBQf7EuA+chhRHGBZJNWjGK8TChc LYaGZV7VBKJebLD4x1W1ECnAQsHmFX42OkXh4UpXq0ldsvhX1R53T2n4mP83GHTDuZHI tp9KFtOeIpWNJi9S+LgGwCYqhNoOPBCszknbX6QF1DwWH0zg5W+ZTxx5e/iKw4D6y4hX uIoXA5iHUuyXJOfFAQf+UAyhoOtDDJJ3+XD6Gvn9eNWPN9RttoQW2gVWA4MfmjKfRVcV YKSA==
MIME-Version: 1.0
X-Received: by 10.170.220.195 with SMTP id m186mr31909414ykf.58.1421171689499;  Tue, 13 Jan 2015 09:54:49 -0800 (PST)
Received: by 10.170.207.6 with HTTP; Tue, 13 Jan 2015 09:54:49 -0800 (PST)
In-Reply-To: <54B55B13.20909@azet.org>
References: <54B5501A.4070402@azet.org>  <54B55B13.20909@azet.org>
Date: Tue, 13 Jan 2015 09:54:49 -0800
Message-ID: 
From: Watson Ladd 
To: Aaron Zauner 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: TLS Mailing List 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jan 2015 17:54:52 -0000

On Tue, Jan 13, 2015 at 9:51 AM, Aaron Zauner  wrote:
>
>
> Russ Housley wrote:
>> I do not mind OCB being specified for _optional_ use with TLS, but there are unencumbered alternatives, and one of those alternatives should be the mandatory to implement algorithm.
>>
>
> I'm not intimately familiar with EAX(2) but it seems to be a viable
> option. I'm currently focused on OCB and the feedback of TLS-WG. If
> nobody want's to see it in TLS, I'm not going to write an ID.

The advantage of OCB is its high efficiency and easy implementation on
a wide range of platforms. I agree it shouldn't be mandatory, but
plenty of people will want to use it, particularly on embedded
platforms.

Sincerely,
Watson Ladd

>
> Aaron
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



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


From nobody Tue Jan 13 10:09:25 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 213C61A9029 for ; Tue, 13 Jan 2015 10:09:18 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001] 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 azHpokI7ZHYU for ; Tue, 13 Jan 2015 10:09:08 -0800 (PST)
Received: from ns3.dns-engine.com (ns3.dns-engine.com [87.106.189.53]) by ietfa.amsl.com (Postfix) with ESMTP id B1FF91A903D for ; Tue, 13 Jan 2015 10:09:08 -0800 (PST)
Received: from [192.168.2.64] (host86-154-35-48.range86-154.btcentralplus.com [86.154.35.48]) by ns3.dns-engine.com (Postfix) with ESMTPA id 5C0A118009D5 for ; Tue, 13 Jan 2015 18:09:06 +0000 (GMT)
Message-ID: <54B55F42.2010501@baggins.org>
Date: Tue, 13 Jan 2015 18:09:06 +0000
From: Matt Caswell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: tls@ietf.org
References: <54B5501A.4070402@azet.org>
In-Reply-To: <54B5501A.4070402@azet.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jan 2015 18:09:18 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 13/01/15 17:04, Aaron Zauner wrote:
> - OpenSSL's 1.0.2 branch
> 
> (https://github.com/openssl/openssl/blob/0c1bd7f03fcd1cc8256f89f4962d91b78432c74a/crypto/modes/ocb128.c)

A
> 
slight correction. OCB is not in the OpenSSL 1.0.2 branch. It is in
the master branch (which means its scheduled for 1.1.0).

Matt

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUtV9CAAoJENnE0m0OYESR+4oH/1IaIjZ+9YB6B1mN5ry5bUz0
5LyPVyJ6+EJj96aUnDR713jLLsyyzW8iXJXHBXxZS2s+/OewQpQjlwybZKtS8YPE
0wwm7VZB7QaR2vDybGgmRx5H6Qw4nFDV/IBHnhIT1ynzG4mWqdgMuCey0h/lk3SD
EHQ5RnO6Wt3ym68mAipmp3KeKwsao/gCuRrFRXTepvKBAwVXBUzbgDqwSAY19ht7
4NZ3qiW3H0vXVU3rptVzAH4y0imEiv2JGUwIZp8LJiqWWNZLMndcoVZGWzxXqQA/
0vJ+aKkWCGd6w88ZyeY1WCwY2XrZTiM0s6WMpuP1t0ZFT9vyQtJbvnpuYCL/nvk=
=wFWs
-----END PGP SIGNATURE-----


From nobody Tue Jan 13 10:09:54 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96FD01A902F for ; Tue, 13 Jan 2015 10:09:51 -0800 (PST)
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 1HIi78FfeUt6 for ; Tue, 13 Jan 2015 10:09:43 -0800 (PST)
Received: from mail-yh0-x22f.google.com (mail-yh0-x22f.google.com [IPv6:2607:f8b0:4002:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DC541A904B for ; Tue, 13 Jan 2015 10:09:42 -0800 (PST)
Received: by mail-yh0-f47.google.com with SMTP id f73so2224535yha.6 for ; Tue, 13 Jan 2015 10:09:41 -0800 (PST)
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:content-transfer-encoding; bh=ci1Sotqt/P1+WtIvyl0QVkVuhJ7+U4Pz7GSPCk42SFw=; b=tEnX6pf0vAlHAVhaV6MFmViJ9hEAUxJR47/yPloUGABDpl7TET96Cvhq8Fi7dN7cyT mNe4jcv2oVEhxsQuLdU2AKt+amlOBpp53G24+i9KK5h17NNTaYk1pnibZcOGlT8jjlb8 Y7afBd8XSQmftXKCD/loHiDZnShn9/l1yGhHACaVEPrw4fgnTw0iUksmBfNAq/JhYAs7 iGUiD7sFtRe3TjgCyZANmlPPgBB/D7QAZAOeFGrLvwYWBSZQ9HXeq8JnBbhfgy0lgIbC rsGcikxf9OaQXDQ/NJeVSEqL0Mj8N74XytC5x9+T3dRPDg/xDB/S3jpM1hWLhBg5frtL TDuA==
MIME-Version: 1.0
X-Received: by 10.236.26.233 with SMTP id c69mr27250112yha.49.1421172581464; Tue, 13 Jan 2015 10:09:41 -0800 (PST)
Received: by 10.170.207.6 with HTTP; Tue, 13 Jan 2015 10:09:41 -0800 (PST)
In-Reply-To: 
References: <9A043F3CF02CD34C8E74AC1594475C73AAF525B9@uxcn10-tdc05.UoA.auckland.ac.nz>  <54B54A5F.7020401@polarssl.org> 
Date: Tue, 13 Jan 2015 10:09:41 -0800
Message-ID: 
From: Watson Ladd 
To: "Paterson, Kenny" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: =?UTF-8?Q?Manuel_P=C3=A9gouri=C3=A9=2DGonnard?= , "" 
Subject: Re: [TLS] AAED ciphers: AES-GCM vs AES-EAX/AES-CCM: a meta-analysis
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jan 2015 18:09:51 -0000

On Tue, Jan 13, 2015 at 9:52 AM, Paterson, Kenny
 wrote:
> Hi
>
> On 13/01/2015 16:39, "Manuel P=C3=A9gouri=C3=A9-Gonnard"  wrote:
>>On 06/01/2015 11:35, Paterson, Kenny wrote:
>>> It's good that nothing supports the truncated-MAC extension, because, i=
n
>>> combination with TLS's support for variable length padding, it
>>>introduces
>>> a security vulnerability. See:
>>>
>>> http://www.isg.rhul.ac.uk/~kp/mee-comp.pdf
>>>
>>>
>>> which shows that if the tag size (MAC length) is shorter than the
>>>CBC-mode
>>> block size, then there's a distinguishing attack that can tell the
>>> difference between the encryption of a short message and a longer
>>>message
>>> (even though both are padded to the same size before encryption).
>>>
>>But if one does not expect any length hiding, is there still a problem
>>with
>>truncated MACs?
>
> I think one would expect length hiding at least up to the granularity of
> the block size in TLS with CBC mode. (The RFC even suggests that more
> should be possible: "Lengths longer than necessary might be desirable to
> frustrate attacks on a protocol that are based on analysis of the lengths
> of exchanged messages." [1])
>
> As a special case of the general attack, consider a notional application
> using TLS that sends either the message "YES" or the message "NO". Suppos=
e
> we negotiate truncated MACs, and the TLS Record Protocol implementation
> selects the amount of padding to add at random (from the set of possible
> padding lengths allowed under the TLS padding scheme).
>
> By truncating the ciphertext, doing some bit flipping, and reinjecting th=
e
> modified ciphertext, an adversary can tell whether "YES" or "NO" was
> originally encrypted. (This assumes that the minimum amount of padding is
> NOT selected; this happens with probability roughly 15/16 under the above
> assumptions.)
>
> I'd consider that to be an attack in your "don't expect any length hiding=
"
> setting - after all, the difference in plaintext lengths is just 1 byte,
> which is well below the CBC-mode block size. Does that seem reasonable, o=
r
> is it still outside your attack model?

>From what I understand, when AES-GCM is used there isn't any padding,
and the length of the encrypted record is equal to the unencrypted one
plus the tag, so this attack still works. So if we accept this attack
(and I think we should), then the way AEAD ciphers are used in TLS are
also insecure. I believe this attack got used to determine autofill
entries in the Google search bar via passive observation, but I've not
dug up the paper, so my memory may be wrong.

To fix this we need to add padding in TLS 1.3 and TLS 1.2 for AEAD modes.

Sincerely,
Watson Ladd

>
> Cheers
>
> Kenny
>
> [1] RFC 5246, Section 6.2.3.2
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


From nobody Tue Jan 13 10:13:39 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 777CF1A9029 for ; Tue, 13 Jan 2015 10:13:37 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001] 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 RUz4qI6bmOj3 for ; Tue, 13 Jan 2015 10:13:35 -0800 (PST)
Received: from ns3.dns-engine.com (ns3.dns-engine.com [87.106.189.53]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9BD1A8FD7 for ; Tue, 13 Jan 2015 10:13:35 -0800 (PST)
Received: from [192.168.2.64] (host86-154-35-48.range86-154.btcentralplus.com [86.154.35.48]) by ns3.dns-engine.com (Postfix) with ESMTPA id 808C31800730 for ; Tue, 13 Jan 2015 18:13:33 +0000 (GMT)
Message-ID: <54B5604D.3050105@baggins.org>
Date: Tue, 13 Jan 2015 18:13:33 +0000
From: Matt Caswell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: tls@ietf.org
References: <54B5501A.4070402@azet.org>  <2A0EFB9C05D0164E98F19BB0AF3708C71D55AEC364@USMBX1.msg.corp.akamai.com>
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D55AEC364@USMBX1.msg.corp.akamai.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jan 2015 18:13:37 -0000

On 13/01/15 17:28, Salz, Rich wrote:
>> There are, of course, reasons why people would not want to accept a
>> proposal like that.  More cipher suites isn't strictly a good thing.
>> Of course, if OCB is demonstrably better in some fashion (speed, security,
>> whatever it happens to be), then that makes the case easier.
> 
> That "no military use" being particularly problematic.  Does anyone know if the IETF has other IPR grants with similar field-of-use limitations?

For the record, the "no military use" clause only applies to the generic
OSI licence. It was that restriction that prevented OCB's inclusion in
OpenSSL for some while. The OpenSSL implementation uses a different licence:
https://www.openssl.org/docs/misc/OCB-patent-grant-OpenSSL.pdf

This is not encumbered by the no military use restriction.

Matt




From nobody Tue Jan 13 10:19:47 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B11131A9034 for ; Tue, 13 Jan 2015 10:19:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 JvJe4zbGn9MJ for ; Tue, 13 Jan 2015 10:19:43 -0800 (PST)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id B02AD1A902D for ; Tue, 13 Jan 2015 10:19:43 -0800 (PST)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 7400747661; Tue, 13 Jan 2015 18:19:42 +0000 (GMT)
Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 67CB84765A; Tue, 13 Jan 2015 18:19:42 +0000 (GMT)
Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 633B42034; Tue, 13 Jan 2015 18:19:42 +0000 (GMT)
Received: from usma1ex-cashub5.kendall.corp.akamai.com (172.27.105.21) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.913.22; Tue, 13 Jan 2015 13:18:56 -0500
Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Tue, 13 Jan 2015 13:18:56 -0500
From: "Salz, Rich" 
To: Matt Caswell , "tls@ietf.org" 
Date: Tue, 13 Jan 2015 13:18:55 -0500
Thread-Topic: [TLS] Inclusion of OCB mode in TLS 1.3
Thread-Index: AdAvXKpXXCji4tMgTqiax4RgRQFD9gAAIoYQ
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D55AEC3AE@USMBX1.msg.corp.akamai.com>
References: <54B5501A.4070402@azet.org>  <2A0EFB9C05D0164E98F19BB0AF3708C71D55AEC364@USMBX1.msg.corp.akamai.com> <54B5604D.3050105@baggins.org>
In-Reply-To: <54B5604D.3050105@baggins.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jan 2015 18:19:45 -0000

> https://www.openssl.org/docs/misc/OCB-patent-grant-OpenSSL.pdf
>=20
> This is not encumbered by the no military use restriction.

Arguably worse from the IETF viewpoint because it would be constraining to =
a particular field of use OR to a particular implementation.  That last hal=
f ... no way.

-- =20
Principal Security Engineer, Akamai Technologies
IM: rsalz@jabber.me Twitter: RichSalz


From nobody Tue Jan 13 10:23:31 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B77211A9034 for ; Tue, 13 Jan 2015 10:23:30 -0800 (PST)
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 yIXwF1q_wguS for ; Tue, 13 Jan 2015 10:23:28 -0800 (PST)
Received: from mail-yh0-x22f.google.com (mail-yh0-x22f.google.com [IPv6:2607:f8b0:4002:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46FDB1A902D for ; Tue, 13 Jan 2015 10:23:28 -0800 (PST)
Received: by mail-yh0-f47.google.com with SMTP id f73so2262535yha.6 for ; Tue, 13 Jan 2015 10:23:27 -0800 (PST)
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=wIrqWR9YL/raeReQ36UUBjNAg+IYY/+VLoZfQNQadW0=; b=zdnoDmctUbzW0BwwVQ89buVKwH+0b88HTC6oHfeLeF4bCRneET5mZhwWx9nYA1SIFk Aaz6f8QRQt5HKXJ1EefxgZIwtvKGaa9GuoS8jDJ8VpipNNX0OlFAe4YlfkI6w3/9BOFe mSeXhZhkecswL/31qOeZ7VsV7U2WZKl94nFwwV0n4Ld+PjxA9BiR0coGu/R2zdyC3IsM WnBni7/a+kwP6KCMX0yVNn8Zt14yqXq3JvYpcdOp33mf7zSgJh7ZvhGevWTAGGliRPJA BAKGx6cg3HJEuwNYoXWffwcd6kR8g78dKE7901wzfDLjSCeIRGjzzUx+w/PrOshNIzAI U4Pw==
MIME-Version: 1.0
X-Received: by 10.170.128.73 with SMTP id u70mr32274423ykb.19.1421173407606; Tue, 13 Jan 2015 10:23:27 -0800 (PST)
Received: by 10.170.207.6 with HTTP; Tue, 13 Jan 2015 10:23:27 -0800 (PST)
In-Reply-To: 
References: <9A043F3CF02CD34C8E74AC1594475C73AAF525B9@uxcn10-tdc05.UoA.auckland.ac.nz>  <54B54A5F.7020401@polarssl.org>   
Date: Tue, 13 Jan 2015 10:23:27 -0800
Message-ID: 
From: Watson Ladd 
To: "Paterson, Kenny" 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: =?UTF-8?Q?Manuel_P=C3=A9gouri=C3=A9=2DGonnard?= , "" 
Subject: Re: [TLS] AAED ciphers: AES-GCM vs AES-EAX/AES-CCM: a meta-analysis
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jan 2015 18:23:30 -0000

On Tue, Jan 13, 2015 at 10:15 AM, Paterson, Kenny
 wrote:
> Hi Watson,
>
> On 13/01/2015 18:09, "Watson Ladd"  wrote:
>
> >From what I understand, when AES-GCM is used there isn't any padding,
>>and the length of the encrypted record is equal to the unencrypted one
>>plus the tag,
>
> True.
>
>>so this attack still works.
>
> Actually, it's an even simpler, passive attack for AES-GCM - you just
> observe the ciphertext length and you are done. The attack on CBC mode
> requires an activity adversary and leads to closure of the TLS session
> half of the time.
>
>>So if we accept this attack
>>(and I think we should), then the way AEAD ciphers are used in TLS are
>>also insecure. I believe this attack got used to determine autofill
>>entries in the Google search bar via passive observation, but I've not
>>dug up the paper, so my memory may be wrong.
>
> That would be an interesting reference to have to hand. Please dig!

https://eprint.iacr.org/2014/959.pdf is the paper I was thinking of.

>
>>To fix this we need to add padding in TLS 1.3 and TLS 1.2 for AEAD modes.
>
> https://tools.ietf.org/html/draft-pironti-tls-length-hiding-01 would be a
> good starting point, no?

Seem to be, although I don't remember it being discussed on the list
before. We should fix this problem.

>
>
> Cheers
>
> Kenny
>



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


From nobody Tue Jan 13 10:25:12 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2AD1A9034 for ; Tue, 13 Jan 2015 10:25:09 -0800 (PST)
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 lPp07Q-CwGi0 for ; Tue, 13 Jan 2015 10:25:06 -0800 (PST)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 713E61A902D for ; Tue, 13 Jan 2015 10:25:06 -0800 (PST)
Received: by mail-wg0-f44.google.com with SMTP id y19so4599147wgg.3 for ; Tue, 13 Jan 2015 10:25:04 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=vRjnKvZTQMrfVBIwEGeoK06KKBFPmzs0PmuszPHoBP8=; b=Yyc9PscqMNFfwRvILY3FWK+/ajYfKHN920nYqMXD23dMJQULyakmt2XneDCIorAJiX IGJ4NnpW04uQd2kG2MsM4Hv0kHBfh1g+UsiGzfJMWhKiY9wjfU24eKMo0ifN0Q8D0J6Q N9KZvri+gg4cq77hHBQgbU7XJxjhe1X5yYwNpKgvKgQ8blhG2gZtVnwlHu6CBuvHrW2R k4V64gwTwef6eU0z9oFPY5JDRWX/rl7TiXFb1BhD6FjJb6QC1V3ZLdLdrrPprd/BoPIP VfzyiOv0Mi8ycC9s0S5sW49jcAlfJfIkN7rORUc9EU6Gx/C/wYcj2psCipjI2M3ObBc+ PMmw==
X-Gm-Message-State: ALoCoQm69wx6Isc58rKLUHn9sd+PkabHk5jRcAZ0NwAUgfC6/pd/ZfRgcOfacePh9fZfPlHq9WR2
X-Received: by 10.194.191.164 with SMTP id gz4mr72905340wjc.70.1421173504376;  Tue, 13 Jan 2015 10:25:04 -0800 (PST)
Received: from [10.0.0.142] (chello080108032135.14.11.univie.teleweb.at. [80.108.32.135]) by mx.google.com with ESMTPSA id cg8sm26737513wjc.1.2015.01.13.10.25.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 13 Jan 2015 10:25:03 -0800 (PST)
Message-ID: <54B562FC.8000600@azet.org>
Date: Tue, 13 Jan 2015 19:25:00 +0100
From: Aaron Zauner 
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: "Salz, Rich" 
References: <54B5501A.4070402@azet.org>  <2A0EFB9C05D0164E98F19BB0AF3708C71D55AEC364@USMBX1.msg.corp.akamai.com> <54B5604D.3050105@baggins.org> <2A0EFB9C05D0164E98F19BB0AF3708C71D55AEC3AE@USMBX1.msg.corp.akamai.com>
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D55AEC3AE@USMBX1.msg.corp.akamai.com>
X-Enigmail-Version: 1.2.3
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigC747D356F897B56CE105BF8B"
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jan 2015 18:25:09 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigC747D356F897B56CE105BF8B
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



Salz, Rich wrote:
>> https://www.openssl.org/docs/misc/OCB-patent-grant-OpenSSL.pdf
>>
>> This is not encumbered by the no military use restriction.
>=20
> Arguably worse from the IETF viewpoint because it would be constraining=
 to a particular field of use OR to a particular implementation.  That la=
st half ... no way.
>=20

As far as I understand that means: It's free to use for everone except
commercial military-use implementations. I agree that's not optimal for
an IETF standard, but as OPTIONAL, this should work. *And* could be used
in FOSS software and/or embedded systems, where it makes most sense.

Aaron


--------------enigC747D356F897B56CE105BF8B
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUtWL8AAoJEOTbZJL9ubXVwmMQALp0G1Xhb3hctAPmGcEoFtsO
z3cE4I39AcRNcXhPgRDZLDrbNYZNWrXc0zYDkOfD3a+zr9LiuztvcwIu75o9xADY
SNKpDxRdBNZh+8k/ZBylz9sfVAXvYtHTLevbQhrw6aM/DjBe0DbjUY8YWKNvpvSc
abEfBb9woMW/+SKIOHpOGdZSYmUb+2U2edwuBE6gX6zQJojAY8cwburMeozmPhIg
fcfpj7gtYCh2CltkgbeTZ2x7zeDFzfQjA2kXC9ZT88v1wZ4YOVl2/XIGoTVWHSy8
3QYbRCZ/+vTclyXApmpsf8MpmfIOJbxcIeLRCP8LUSO7Nkd02v7rBT0ZDMO+F6pa
L12EyzUSHjPKHyqfyX7ALU2LGCd20KWK1CC9oYAxnKmqBCf6XI7qBRcrgczR/fOc
siEtCblHsupybUfkKoxMI9pEHXX/9RW/qMvgtxKTH7wnS0yc5bd5B0ZBM39B0A7Q
c9WGhQB9EiU3Bx9O027tMMiC7rpSpvRK5HKWENYYcZ0RinbGvF8TtE4y1lhRRVmZ
JDw5AUFuY5Ojg2R3D4Xq8Eg0LNvfTZAkjdh0U0t/zvAfR1oYHt0+n5MraGecT+dB
oS6hkY85A0R9TBQMDRROZK5oUebTkeVddhfYNOXfdpWR9A55W66Tqhp8CrMohGFP
EoIrJlmX0PgOd051qJw+
=rq9O
-----END PGP SIGNATURE-----

--------------enigC747D356F897B56CE105BF8B--


From nobody Tue Jan 13 10:28:16 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 512541A902D for ; Tue, 13 Jan 2015 10:28:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 VFA0M5rnU_Af for ; Tue, 13 Jan 2015 10:28:11 -0800 (PST)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0686.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::686]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E63001A906D for ; Tue, 13 Jan 2015 10:28:08 -0800 (PST)
Received: from DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) by DBXPR03MB384.eurprd03.prod.outlook.com (10.141.10.20) with Microsoft SMTP Server (TLS) id 15.1.53.17; Tue, 13 Jan 2015 18:15:14 +0000
Received: from DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) by DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) with mapi id 15.01.0053.000; Tue, 13 Jan 2015 18:15:15 +0000
From: "Paterson, Kenny" 
To: Watson Ladd 
Thread-Topic: [TLS] AAED ciphers: AES-GCM vs AES-EAX/AES-CCM: a meta-analysis
Thread-Index: AdApm1DpFjNg+4muRmKsYOSI8dViWQAASE0AAWzH8IAAAojMgAAAmS+AAAAwugA=
Date: Tue, 13 Jan 2015 18:15:15 +0000
Message-ID: 
References: <9A043F3CF02CD34C8E74AC1594475C73AAF525B9@uxcn10-tdc05.UoA.auckland.ac.nz>  <54B54A5F.7020401@polarssl.org>  
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.7.141117
x-originating-ip: [134.219.227.30]
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Kenny.Paterson@rhul.ac.uk; 
x-dmarcaction-test: None
x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:DBXPR03MB384;
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:DBXPR03MB384;
x-forefront-prvs: 045584D28C
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(479174004)(24454002)(189002)(199003)(36756003)(2900100001)(122556002)(40100003)(68736005)(106356001)(105586002)(15975445007)(102836002)(93886004)(83506001)(110136001)(2950100001)(19580405001)(46102003)(74482002)(66066001)(87936001)(2656002)(77156002)(97736003)(86362001)(101416001)(19580395003)(77096005)(50986999)(1411001)(64706001)(62966003)(92566002)(76176999)(54356999); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR03MB384; H:DBXPR03MB383.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: rhul.ac.uk does not designate permitted sender hosts)
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <17321A3D4770544D9F83A26E691C08CC@eurprd03.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: rhul.ac.uk
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jan 2015 18:15:15.0027 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR03MB384
Archived-At: 
Cc: =?iso-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= , "" 
Subject: Re: [TLS] AAED ciphers: AES-GCM vs AES-EAX/AES-CCM: a meta-analysis
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jan 2015 18:28:14 -0000

Hi Watson,

On 13/01/2015 18:09, "Watson Ladd"  wrote:

>From what I understand, when AES-GCM is used there isn't any padding,
>and the length of the encrypted record is equal to the unencrypted one
>plus the tag,=20

True.

>so this attack still works.

Actually, it's an even simpler, passive attack for AES-GCM - you just
observe the ciphertext length and you are done. The attack on CBC mode
requires an activity adversary and leads to closure of the TLS session
half of the time.

>So if we accept this attack
>(and I think we should), then the way AEAD ciphers are used in TLS are
>also insecure. I believe this attack got used to determine autofill
>entries in the Google search bar via passive observation, but I've not
>dug up the paper, so my memory may be wrong.

That would be an interesting reference to have to hand. Please dig!

>To fix this we need to add padding in TLS 1.3 and TLS 1.2 for AEAD modes.

https://tools.ietf.org/html/draft-pironti-tls-length-hiding-01 would be a
good starting point, no?


Cheers

Kenny


From nobody Tue Jan 13 10:29:00 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0081A906E for ; Tue, 13 Jan 2015 10:28:58 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001] 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 8oLBO0bR7LTC for ; Tue, 13 Jan 2015 10:28:56 -0800 (PST)
Received: from ns3.dns-engine.com (ns3.dns-engine.com [87.106.189.53]) by ietfa.amsl.com (Postfix) with ESMTP id 322901A9034 for ; Tue, 13 Jan 2015 10:28:56 -0800 (PST)
Received: from [192.168.2.64] (host86-154-35-48.range86-154.btcentralplus.com [86.154.35.48]) by ns3.dns-engine.com (Postfix) with ESMTPA id AE6B91800552; Tue, 13 Jan 2015 18:28:52 +0000 (GMT)
Message-ID: <54B563E5.8010200@baggins.org>
Date: Tue, 13 Jan 2015 18:28:53 +0000
From: Matt Caswell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: "Salz, Rich" , "tls@ietf.org" 
References: <54B5501A.4070402@azet.org>  <2A0EFB9C05D0164E98F19BB0AF3708C71D55AEC364@USMBX1.msg.corp.akamai.com> <54B5604D.3050105@baggins.org> <2A0EFB9C05D0164E98F19BB0AF3708C71D55AEC3AE@USMBX1.msg.corp.akamai.com>
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D55AEC3AE@USMBX1.msg.corp.akamai.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jan 2015 18:28:58 -0000

On 13/01/15 18:18, Salz, Rich wrote:
>> https://www.openssl.org/docs/misc/OCB-patent-grant-OpenSSL.pdf
>>
>> This is not encumbered by the no military use restriction.
> 
> Arguably worse from the IETF viewpoint because it would be constraining to a particular field of use OR to a particular implementation.  That last half ... no way.

If that was seen as a blocker then its probably worth starting a
conversation with Phil Rogaway. He was very amenable to dealing with the
OpenSSL issue.

Matt


From nobody Tue Jan 13 10:32:29 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDD6E1A9034 for ; Tue, 13 Jan 2015 10:32:28 -0800 (PST)
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 F_NOskIRDSCw for ; Tue, 13 Jan 2015 10:32:27 -0800 (PST)
Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003: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 382831A902F for ; Tue, 13 Jan 2015 10:32:27 -0800 (PST)
Received: by mail-ob0-f172.google.com with SMTP id va8so4031721obc.3 for ; Tue, 13 Jan 2015 10:32:26 -0800 (PST)
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=hFcSRdmOzpbAcVWn5byZekPQhhpyp5b7lGA60inu1Sw=; b=vxUzJViKh2pQKrGiKndoq/6dLoJecvRUg8rYUCNcFf/fHDF91fDwWMBGggoWmifjAW gSExfB0xmbOywYffW2HhpLBr8IzUsD1YRUnpmnqhMg0xB7uQNuFtMwU0dEJ7jNHdcLg8 UorkKAcReWMjfAWBNzlc0Ezf8fkTm9G7WFI2E9p44ysJybVuI5eY3XAtrgS4khXcHKFp UYp75oPnv+dM/uuvA/gGbLmwl2MyLvXyXRYEPZnFyM5K5Jx91qxev3lsX3tWiPmPHTRw x3imZBfO+POKV9wMndUIolB8O8BrT7d6FnUVg+vAJRSaWH/GtCLf/K+8DwroM8KI+Pvn hlXw==
MIME-Version: 1.0
X-Received: by 10.182.108.194 with SMTP id hm2mr21666735obb.85.1421173946517;  Tue, 13 Jan 2015 10:32:26 -0800 (PST)
Received: by 10.202.226.136 with HTTP; Tue, 13 Jan 2015 10:32:26 -0800 (PST)
In-Reply-To: 
References: <9A043F3CF02CD34C8E74AC1594475C73AAF525B9@uxcn10-tdc05.UoA.auckland.ac.nz>  <54B54A5F.7020401@polarssl.org>    
Date: Tue, 13 Jan 2015 10:32:26 -0800
Message-ID: 
From: Martin Thomson 
To: Watson Ladd 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: =?UTF-8?Q?Manuel_P=C3=A9gouri=C3=A9=2DGonnard?= , "" 
Subject: Re: [TLS] AAED ciphers: AES-GCM vs AES-EAX/AES-CCM: a meta-analysis
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jan 2015 18:32:29 -0000

On 13 January 2015 at 10:23, Watson Ladd  wrote:
>> https://tools.ietf.org/html/draft-pironti-tls-length-hiding-01 would be a
>> good starting point, no?
>
> Seem to be, although I don't remember it being discussed on the list
> before. We should fix this problem.


We discussed it at some length at a meeting (Denver).  There was
significant interest in doing this, though I think we agreed that we
had to sort out a few things before the time was right.

See also https://github.com/tlswg/tls13-spec/issues/69


From nobody Tue Jan 13 10:49:05 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 684071A90CF for ; Tue, 13 Jan 2015 10:49:03 -0800 (PST)
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 82ukZtLRMvmq for ; Tue, 13 Jan 2015 10:49:01 -0800 (PST)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70FA91A90CC for ; Tue, 13 Jan 2015 10:49:01 -0800 (PST)
Received: by mail-we0-f172.google.com with SMTP id k11so4637591wes.3 for ; Tue, 13 Jan 2015 10:49:00 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=GNOrcZ0+FplTOwGkQ+XZsiesSmluoq5GrFaRvUzyP9w=; b=hF11T6bFod32Zs5RSNvNr9pZ9nkoEYTAHf4lKrSiFoyf7vOA4TVu7umHYR681nG0vZ d26MFAjR0lILSMek8YRkp57ln6dP0+xV5P7gVuXhhTr0M4gJbp3YL+6e325WLegk40bo jsgZ0dlO6c2qMpXgdsSouc2CUHTAIhWdtKqPrgWmfC0b+k+74Y+GJEcaV20jzfjksKMY ii2G0jFTcSoK7Wi4k/5e5lZAtHbel7zespFkNskKPaWYtu3D882oDIqdkL94ymYlVWLN AIOcfwBzboCHps0ILswjVQFgeXGbiKiyMDVIMWjwmFQYS+oYVreFwiV768wJL8rYn3tH Q6Uw==
X-Gm-Message-State: ALoCoQlHEDBnJJvPZq49kflW6AgrfGmbJJ30sRDqFAO7FurPvA+GiBmHsxwirboswRw9tFf8Etix
X-Received: by 10.194.83.41 with SMTP id n9mr70622975wjy.133.1421174940220; Tue, 13 Jan 2015 10:49:00 -0800 (PST)
Received: from [10.0.0.142] (chello080108032135.14.11.univie.teleweb.at. [80.108.32.135]) by mx.google.com with ESMTPSA id gb10sm26798151wjb.21.2015.01.13.10.48.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 13 Jan 2015 10:48:58 -0800 (PST)
Message-ID: <54B56896.1030502@azet.org>
Date: Tue, 13 Jan 2015 19:48:54 +0100
From: Aaron Zauner 
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: Paul Lambert 
References: <54B5501A.4070402@azet.org> 
In-Reply-To: 
X-Enigmail-Version: 1.2.3
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigBA8F006DBF7B0867B25C8778"
Archived-At: 
Cc: TLS Mailing List 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jan 2015 18:49:03 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigBA8F006DBF7B0867B25C8778
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

Paul Lambert wrote:
>> Hi TLS-WG,
>>
>> Over the last couple of days I've again looked into OCB, read the
>> original paper as well as quite some literature on it, patents, CFRG
>> discussion et cetera.
>>
>> OCB looks like an elegant and parallel mode for inclusion in TLS.
> Yes, OCB is a very nice AEAD.
>=20
>> I've searched through recent TLS-WG discussion, OCB has been
>> mentioned in passing as has EAX(2). When first looking into that my
>> main concerns were:
>>
>>   * IPR/patents: the authors have granted access to OSI licensed
>>     software as well as to commercial (non military!) software for
>>     all use [0] [1].
> No - the IETF IPR database statement does reflect the claims in [1]
> https://datatracker.ietf.org/ipr/search/?submit=3Ddraft&id=3Ddraft-irtf=
-cfrg-oc
> b=20
>=20
> The problem with OCB, when first introduced as an option for
> 802.11i was that there were multiple claimed owners of the IPR.
>=20
> This still seems to be the case.  Looking at the IETF IPR disclosures:
> 	#6,973,187 - Gligor & Donescu (VDG Inc)
> 	#6,963,976  #7,093,126 - Jutla (IBM)
> 	#7,046,802 #7,200,227 #7,949,129 #8321675 - Rogaway

Thanks for pointing this out.

FYI: CFRG members made some statements regarding different IPR (and
performance) issues in discussions [0] [1] [2]. Rogaway is pretty clear
on his own patents in [3].

This did not seem to stop adoption.

> This should not stop inclusion of OCB as an optional mode in TLS,
> but OCB is not clearly =C5=92free=C2=B9.

Sure. I agree. I'd still be nice to have it in there though.

Aaron

[0] https://www.ietf.org/mail-archive/web/cfrg/current/msg03300.html
[1] https://www.ietf.org/mail-archive/web/cfrg/current/msg03277.html
[2] https://www.ietf.org/mail-archive/web/cfrg/current/msg02989.html
[3] https://www.ietf.org/mail-archive/web/cfrg/current/msg03301.html


--------------enigBA8F006DBF7B0867B25C8778
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUtWiXAAoJEOTbZJL9ubXVEocQAIL8SZBTF6U/jG0TEuIb/AYp
35SxD0l5K+EaCmT5/NWbUjmNbPEvddF7YGPEZIcxG00ULN1V8js1wFu73XJ5qLJv
JMfhI1k8QPBYek2/Dq8ad5el8vYh0vfBpr3K/e/82HV8/efr3s2ivihIjO0rHzgP
OLIilrZaCConfLtfFKLz+lSwOqVSKmdant3DOTnz0oSQ1wob1TJa393WuMRA1Azu
Y3Gvi1M4B8SHhB9A6w9QBZNb/oFK99SS5AsI7lIAFhOxWi3VO1P1aYk4hyXgwkns
E242WuM537p0twyIvqzPysewGJggbE+agpk0tVVCsikWgjyKhvQo1OdfIjl1NEkY
41Vbz9ql2+MEqaqDM+4j5E6nG9bVD46hAI/EG4otmMmTTKkT3r6z8h5VAlOoKmia
tzMlWILlo7Jv5Zu7mS7Bsgtsb5PYw/RLrRh8duqQ8FEmGR5Q/Tn8G3Zt8NcePd6u
w0xZ6OETengUcUo7XmJC2+lliA5ZoeZ1yPOgTfBF3e0wWoza2KbhAB9O1pMwRw6h
ebJPuGBOoMOtWzw6FxwoNTaC0MIddAQHWIf5FMRHEReM44MSI/nbl9PjdTr8mhPi
fb3Q1TdnmOUrlAo10V3cJPhWN426W/X+kYB27/WcZBqPwbUXnzHyjd2wK9Fuz6CJ
w6haTkkZEgyGJqiePMnf
=TS/B
-----END PGP SIGNATURE-----

--------------enigBA8F006DBF7B0867B25C8778--


From nobody Tue Jan 13 10:59:27 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BDB61A911F for ; Tue, 13 Jan 2015 10:59:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.267
X-Spam-Level: 
X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, 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 w-rA-rfpANSv for ; Tue, 13 Jan 2015 10:59:23 -0800 (PST)
Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1036C1A9112 for ; Tue, 13 Jan 2015 10:59:22 -0800 (PST)
Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id t0DIPQeT022155; Tue, 13 Jan 2015 10:25:31 -0800
Received: from sc-owa04.marvell.com ([199.233.58.150]) by mx0b-0016f401.pphosted.com with ESMTP id 1rv520mvx0-3 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 13 Jan 2015 10:25:31 -0800
Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA04.marvell.com ([::1]) with mapi; Tue, 13 Jan 2015 10:25:17 -0800
From: Paul Lambert 
To: Aaron Zauner , TLS Mailing List 
Date: Tue, 13 Jan 2015 10:25:16 -0800
Thread-Topic: [TLS] Inclusion of OCB mode in TLS 1.3
Thread-Index: AdAvXkec0cLzn9VDTvCXMbD4HAiE7A==
Message-ID: 
References: <54B5501A.4070402@azet.org>
In-Reply-To: <54B5501A.4070402@azet.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.7.141117
acceptlanguage: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33,  0.0.0000 definitions=2015-01-13_07:2015-01-13,2015-01-13,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1501130177
Archived-At: 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jan 2015 18:59:26 -0000

>Hi TLS-WG,
>
>Over the last couple of days I've again looked into OCB, read the
>original paper as well as quite some literature on it, patents, CFRG
>discussion et cetera.
>
>OCB looks like an elegant and parallel mode for inclusion in TLS.
Yes, OCB is a very nice AEAD.

>I've searched through recent TLS-WG discussion, OCB has been
>mentioned in passing as has EAX(2). When first looking into that my
>main concerns were:
>
>   * IPR/patents: the authors have granted access to OSI licensed
>     software as well as to commercial (non military!) software for
>     all use [0] [1].
No - the IETF IPR database statement does reflect the claims in [1]
https://datatracker.ietf.org/ipr/search/?submit=3Ddraft&id=3Ddraft-irtf-cfr=
g-oc
b=20

The problem with OCB, when first introduced as an option for
802.11i was that there were multiple claimed owners of the IPR.

This still seems to be the case.  Looking at the IETF IPR disclosures:
	#6,973,187 - Gligor & Donescu (VDG Inc)
	#6,963,976  #7,093,126 - Jutla (IBM)
	#7,046,802 #7,200,227 #7,949,129 #8321675 - Rogaway



This should not stop inclusion of OCB as an optional mode in TLS,
but OCB is not clearly =8Cfree=B9.

Paul


>
>   * IETF applicability: an informational RFC has been written by
>     the original author of OCB mode, reviewed and accepted by CFRG
>     and published by IESG in May 2014 [RFC7253].
>
>   * Software implementations: OCB mode is available in various
>     cryptographic libraries:
>
>      - OpenSSL's 1.0.2 branch
>
>(https://github.com/openssl/openssl/blob/0c1bd7f03fcd1cc8256f89f4962d91b78
>432c74a/crypto/modes/ocb128.c)
>
>      - Bouncy Castle
>        (https://www.bouncycastle.org/specifications.html)
>
>      - Botan
>
>(https://github.com/randombit/botan/tree/74522169a907715d4d41b3680f20b6f86
>6733de7/src/lib/modes/aead/ocb)
>
>      - Soon; dynamic languages linking to these libraries.
>
>      - I might have left out a few, where I couldn't find a
>        clear indication that they intend to support OCB mode.
>
>From looking at [RFC7253] it would make sense to have;
>`AEAD_AES_128_OCB_TAGLEN64` and `AEAD_AES_256_OCB_TAGLEN128` in TL3
>1.3 ciphersuites.
>
>Now I'm a bit clueless as to how new AEAD modes are supposed to be
>added to TLS 1.3. In the past there have been various documents
>extending TLS ciphersuites by a certain block cipher/AEAD mode:
>[RFC5288] [RFC6367] [RFC6655] [RFC5528] [RFC6209]. There is a
>general document for an interface for AEAD modes [RFC5116] which the
>authors have used for their informational RFC [RFC7253]. I'd like to
>ask for a bit of guidance how this can be done more efficiently for
>all ciphers that will end up in TLS 1.3. Having a seperate RFC for
>every cipher and thus ciphersuite seems a bit confusing. Is this the
>intended approach still?
>
>I'd be willing to author such a document or make the necessary
>changes to the TLS 1.3 draft in order to get OCB mode into TLS 1.3.
>Currently we're limited to GCM (with known issues on mobile
>plattforms) and CCM (CBC-MAC, which is one of the reasons the OCB
>authors started work on this mode, because it's more elegant and
>efficient).
>
>
>Recent developments regarding OCB mode are documented here:
>http://web.cs.ucdavis.edu/~rogaway/ocb/news/
>
>All and any input appreciated.
>
>Thanks,
>Aaron
>
>[0] https://www.ietf.org/mail-archive/web/cfrg/current/msg03301.html
>[1] http://web.cs.ucdavis.edu/~rogaway/ocb/ocb-faq.htm#patent:phil
>


From nobody Tue Jan 13 13:34:24 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3CFD1B29A5 for ; Tue, 13 Jan 2015 13:34:23 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, 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 olTectYV-xYl for ; Tue, 13 Jan 2015 13:34:22 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C20E1AD481 for ; Tue, 13 Jan 2015 13:34:22 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D91A8BE97; Tue, 13 Jan 2015 21:34:20 +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 aH_dgakQfHNA; Tue, 13 Jan 2015 21:34:19 +0000 (GMT)
Received: from [10.87.48.73] (unknown [86.41.54.55]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9D990BE79; Tue, 13 Jan 2015 21:34:19 +0000 (GMT)
Message-ID: <54B58F5B.2010704@cs.tcd.ie>
Date: Tue, 13 Jan 2015 21:34:19 +0000
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Paul Lambert , Aaron Zauner ,  TLS Mailing List 
References: <54B5501A.4070402@azet.org> 
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jan 2015 21:34:24 -0000



On 13/01/15 18:25, Paul Lambert wrote:
> This should not stop inclusion of OCB as an optional mode in TLS,

I don't get why additional options are at all attractive. In
fact, I think they're ugly.

TLS has about 327 ciphersuites. That's just stupid. (I'm not
saying any person is stupid there btw, but we have gotten
ourselves into a stupid place.)

If we have a really better thing, they why not make it MTI? If
we do not have something sufficiently better then I'd argue to
exclude as much as possible, and certainly against adding
anything that is just nice to have.

I'd even like to make almost all current ciphersuites a MUST NOT
(or start a new registry) for TLS1.3 and to not add any new
ciphersuites at all, and just stick with two MTI ciphersuites
that are as genetically different as possible and cover as many
implementations (h/w AES or not) as possible.

So my suggestion is to reduce the ciphersuite field to be
2 bits wide in TLS 1.3, with 00 being default, 01 backup, 02
being "proprietary" and 03 reserved. If either 00 or 01 needs
to be changed then I'd say rev the TLS version. (I don't care
if we did s/default/has-AES-hw/ and s/backup/just-sw-crypto/
that'd also be fine.)

And yes, I realise that's not likely to get traction, but
turning 327 into 427 is even dumber when reality shows that
only a few of 'em are used or needed.



With a random hat: the OCB RFC is an IRTF informational document
and had CFRG consensus for publication. Using that in a standards
track spec would require TLS WG consensus, and then IETF consensus.
So there's no magic, just the usual IPR processing that each
participant has to do for themselves. I'd be pretty confident in
a bet that the odd encumbrance of OCB will be a hard barrier to
overcome, but who knows.

Cheers,
S.


From nobody Tue Jan 13 16:25:43 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CDD21ACE0F for ; Tue, 13 Jan 2015 16:25:41 -0800 (PST)
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 M5XEf-Vjfj38 for ; Tue, 13 Jan 2015 16:25:39 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07BC11ACDD3 for ; Tue, 13 Jan 2015 16:25:39 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 0E833282CC8; Wed, 14 Jan 2015 00:25:38 +0000 (UTC)
Date: Wed, 14 Jan 2015 00:25:38 +0000
From: Viktor Dukhovni 
To: tls@ietf.org
Message-ID: <20150114002537.GP7322@mournblade.imrryr.org>
References: <54B5501A.4070402@azet.org>  <54B58F5B.2010704@cs.tcd.ie>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <54B58F5B.2010704@cs.tcd.ie>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Jan 2015 00:25:41 -0000

On Tue, Jan 13, 2015 at 09:34:19PM +0000, Stephen Farrell wrote:

> I don't get why additional options are at all attractive. In
> fact, I think they're ugly.

Yes, except that OCB might well have been the most attractive AEAD
mode to implement, were it not for IPR and the history of how we
got here.  On a purely technical basis it appears superior to GCM.

> If we have a really better thing, they why not make it MTI? If
> we do not have something sufficiently better then I'd argue to
> exclude as much as possible, and certainly against adding
> anything that is just nice to have.

It would be nice to get there some day.  However we're still actively
discovering what works:

	* Which EC curves and signature schemes to use

	* Which modes to use

	* Which stream ciphers to use (have we settled on ChaCha20 yet?)

	* Which block ciphers to use (must TLS support CAMELLIA? SEED?)

	* Which hash functions to use (though SHA-2 is holding up well)

Plus of course TLS is used in a rather diverse set of applications
whose needs vary.

> I'd even like to make almost all current ciphersuites a MUST NOT
> (or start a new registry) for TLS1.3 and to not add any new
> ciphersuites at all, and just stick with two MTI ciphersuites
> that are as genetically different as possible and cover as many
> implementations (h/w AES or not) as possible.
>
> So my suggestion is to reduce the cipher suite field to be
> 2 bits wide in TLS 1.3, with 00 being default, 01 backup, 02
> being "proprietary" and 03 reserved. If either 00 or 01 needs
> to be changed then I'd say rev the TLS version. (I don't care
> if we did s/default/has-AES-hw/ and s/backup/just-sw-crypto/
> that'd also be fine.)

This would then require per-application TLS "profiles", with
per-application definitions of the two ciphersuites in question.
I don't think that'll work just yet.

We might be able to get away with approximately two choices per
degree of freedom:

    * Two public key systems (RSA and ECDSA and/or EdDSA, drop DSA?).

    * A couple of block ciphers (AES and CAMELLIA, drop SEED, IDEA, RC2, ...?).

    * Two key lengths 128 and 256.

    * One or two stream ciphers (ChaCha20 and ???).

    * A couple of AEAD variants (GCM, Poly1305, OCB?)

    ...

Which should still be a smaller set of possible outcomes that the
current ~327, but I think we are sadly far from having just two be
realistic.

-- 
	Viktor.


From nobody Tue Jan 13 16:32:45 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 503951ACE0D for ; Tue, 13 Jan 2015 16:32:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.208
X-Spam-Level: 
X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 75xNHOIoUD5x for ; Tue, 13 Jan 2015 16:32:41 -0800 (PST)
Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id 201C81ACE04 for ; Tue, 13 Jan 2015 16:32:40 -0800 (PST)
Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id t0E0Wc62025067 for ; Tue, 13 Jan 2015 19:32:38 -0500
From: "Blumenthal, Uri - 0558 - MITLL" 
To: "tls@ietf.org" 
Thread-Topic: [TLS] Inclusion of OCB mode in TLS 1.3
Thread-Index: AQHQL1MExXQ6KPqgoEiVNz85RavZKpy+sbkAgAA00oCAAC/eAP//rgYA
Date: Wed, 14 Jan 2015 00:32:37 +0000
Message-ID: 
References: <54B5501A.4070402@azet.org>  <54B58F5B.2010704@cs.tcd.ie> <20150114002537.GP7322@mournblade.imrryr.org>
In-Reply-To: <20150114002537.GP7322@mournblade.imrryr.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.6.141106
x-originating-ip: [172.25.177.187]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3504022334_27857347"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33,  0.0.0000 definitions=2015-01-13_08:2015-01-13,2015-01-13,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1501140003
Archived-At: 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Jan 2015 00:32:44 -0000

--B_3504022334_27857347
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable

Good points!

Also, do we acknowledge that there will be specific applications that need
specific cipher suites that are not included in those few selected for
universal use (i.e. a couple of AEAD modes, a couple of block ciphers,
etc)?

For example, what if Russia insists on using Kuznetchik? Surely you don=E2=80=99t
expect everybody to implement it, but surely you don=E2=80=99t expect them to say
=E2=80=9CIETF did not bless Grasshopper for TLS, so we=E2=80=99ll switch to AES-based
suites, or use ChaCha20=E2=80=9D?

How are we planning to handle such =E2=80=9Cspecial=E2=80=9D needs?
--=20
Regards,
Uri Blumenthal                               Voice: (781) 981-1638




On 1/13/15, 19:25 , "Viktor Dukhovni"  wrote:
>On Tue, Jan 13, 2015 at 09:34:19PM +0000, Stephen Farrell wrote:
>
>> I don't get why additional options are at all attractive. In
>> fact, I think they're ugly.
>
>Yes, except that OCB might well have been the most attractive AEAD
>mode to implement, were it not for IPR and the history of how we
>got here.  On a purely technical basis it appears superior to GCM.
>
>> If we have a really better thing, they why not make it MTI? If
>> we do not have something sufficiently better then I'd argue to
>> exclude as much as possible, and certainly against adding
>> anything that is just nice to have.
>
>It would be nice to get there some day.  However we're still actively
>discovering what works:
>
>	* Which EC curves and signature schemes to use
>
>	* Which modes to use
>
>	* Which stream ciphers to use (have we settled on ChaCha20 yet?)
>
>	* Which block ciphers to use (must TLS support CAMELLIA? SEED?)
>
>	* Which hash functions to use (though SHA-2 is holding up well)
>
>Plus of course TLS is used in a rather diverse set of applications
>whose needs vary.
>
>> I'd even like to make almost all current ciphersuites a MUST NOT
>> (or start a new registry) for TLS1.3 and to not add any new
>> ciphersuites at all, and just stick with two MTI ciphersuites
>> that are as genetically different as possible and cover as many
>> implementations (h/w AES or not) as possible.
>>
>> So my suggestion is to reduce the cipher suite field to be
>> 2 bits wide in TLS 1.3, with 00 being default, 01 backup, 02
>> being "proprietary" and 03 reserved. If either 00 or 01 needs
>> to be changed then I'd say rev the TLS version. (I don't care
>> if we did s/default/has-AES-hw/ and s/backup/just-sw-crypto/
>> that'd also be fine.)
>
>This would then require per-application TLS "profiles", with
>per-application definitions of the two ciphersuites in question.
>I don't think that'll work just yet.
>
>We might be able to get away with approximately two choices per
>degree of freedom:
>
>    * Two public key systems (RSA and ECDSA and/or EdDSA, drop DSA?).
>
>    * A couple of block ciphers (AES and CAMELLIA, drop SEED, IDEA, RC2,
>...?).
>
>    * Two key lengths 128 and 256.
>
>    * One or two stream ciphers (ChaCha20 and ???).
>
>    * A couple of AEAD variants (GCM, Poly1305, OCB?)
>
>    ...
>
>Which should still be a smaller set of possible outcomes that the
>current ~327, but I think we are sadly far from having just two be
>realistic.
>
>--=20
>	Viktor.
>
>_______________________________________________
>TLS mailing list
>TLS@ietf.org
>https://www.ietf.org/mailman/listinfo/tls

--B_3504022334_27857347
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIUOAYJKoZIhvcNAQcCoIIUKTCCFCUCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B
BwGgghIHMIIE6jCCA9KgAwIBAgIKH0XZoAAAAAABzTANBgkqhkiG9w0BAQsFADBRMQswCQYD
VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ
MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE0MDQxNjIxNTMwMloXDTE1MDQxNjIxNTMwMlow
YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV
BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCx/gK75UYos2g8JavX0BVfe3TCGsmjQY34z9ZVeucP
8dGtqRA8T5i1OKdf++Jd81a0/qQA6mIGyzTW6lOtY+77qKUJtEeLM5URd+iv2EejAwxsa2B5
pMq9L9qWuVokR1rTEfEcuUeKR1Kko6xmRE/y6AzBnUhTvHx2X9F6JSVdR36Lx3R62CNeQqFi
ZDeHuTI8AhRY4UdPkri1FTDxV6gLYaLKxsGIurrL/6EzdlkX8ImTcxKzEmxX1VjTPy9ZRNYj
akDGcJF9clCfcwbq3DI3gAUkVxXf+UbHEjzOCVNQcoga7bYbBUuDpN25Lc86P9RaOiiICtyu
ZZP2P/2kkKYRAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUEN9QHIi9GvlGjs9Th46jrfPir+Uw
DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud
HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB
BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD
QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3
FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAi
BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3
EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM
AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAL2kCh9ovO8AbHgAVU6T
eH5qRmKnOrfTUfn9JnHzkspdWMQA1IdtftSpiZZ7C3lCmblSDCgPqbQl4zMZxXeTgxnQsB6m
1LA6uDHM/0G27RcOJH4OTN9sQ0/2CKb4JPIXXIps1z+s8XjSRzPJZuD8fPC8R8QWvOH3owL2
BLzZebZTOMa5yws3kohY02vP/Clv0KQXYVzUZUYXoYmhUSYmQ1UZZZSFJ2rNdgNn0z8fPrUQ
NIYlVaJV0kKQYjlHWTfomVapLEfIY7xRHZy9g997IjYReD0t9IZd6tTwcJES+2ijFM8l/fxk
u/cQ4WCYyI+58DaBaV9p68/AC147b0HhvLUwggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB
BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww
CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN
MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi
b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF
vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9
RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP
6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA
mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk
xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm
DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD
VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s
bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu
ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy
bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G
CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB
AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG
SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L
TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ
cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT
iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r
/aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf
MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE
ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM
TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC
VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG
A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO
KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z
Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD
2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo
bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM
nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T
AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU
Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+
G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf
gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO
1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa
a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn
rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIEzjCCA7agAwIBAgIK
PVEvPAAAAACTsDANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU
IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0y
MB4XDTE0MDIxMjE4NTMwMVoXDTE1MDIxMjE4NTMwMVowYTELMAkGA1UEBhMCVVMxHzAdBgNV
BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX
Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQCKHhhu75bRiOvWhbZ//TxS76yI2d+rHN2s8bp8wxW8oMjmsaplLeGQusUFRyRNSkfYtdB4
YApjnV6TCxS0Mqzly5BaoeZWoP+CbbMDNGYMszus9iFj22SSlTzGRo+gaL6rqsDKdwDOzs3C
PYqh4Uu8sLzEq+QD9rhqAuMJ76635JKWELxK0uDehpNBMCGqVeAY8ht5u2h4ojPdwiuDQDW2
QxWRJjPDL8n1JczuEHY71jHldER3b2+UhpDDYRQ9aVOiGCjW8BwJOruVsBfLNxyDxgffNQ1D
1konuneMpL9H2S8ciHOdy5+Gi7snCQJ+7w30rIJ2NTldWaY6avZAaCa3AgMBAAGjggGWMIIB
kjAdBgNVHQ4EFgQUZ7oGjnu6gWRmom/4UswgdVBW/3wwDgYDVR0PAQH/BAQDAgUgMB8GA1Ud
IwQYMBaAFI5KfYmhYxccgYg0VzcmRV4Zin4kMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j
cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTIwYgYIKwYBBQUHAQEEVjBUMC0GCCsGAQUFBzAC
hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTIwIwYIKwYBBQUHMAGGF2h0dHA6
Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAwPQYJKwYBBAGCNxUHBDAwLgYmKwYB
BAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYE
VR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMBCDAZ
BgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTANBgkqhkiG9w0BAQsFAAOCAQEAJiU3WfJ9GvGJ
iDNPClLazyh252wxxOc/TmClMKtyqHnbFObDEoXAMaoHGxrvs+lU8fU2F2ELpV8q8eYgqLLw
7PG09z5s/GkajlxVZ/FHj/9hNHTfwlicrCRY3zrna1GbOMZgWFz8R6akAoLKpqGulNrvjvU8
c63U+JVmgJmBPCMv5JlH10m87+WPJ+ToK0m4XfZjl7n5OKDJ/hOyBwbBntc+W2gDppfR1BCt
DNfEG0+zHjFqF+Of1Q5NI5abhgvw5IEuVA1M4SV/utwmmdreBEv/YuLnDd/PhVgQwp3LHGCX
X1dANyiKso2aACl9jrkylq39cA/WgvAlS21w9vxVpDGCAfUwggHxAgEBMF8wUTELMAkGA1UE
BhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTET
MBEGA1UEAxMKTUlUTEwgQ0EtMwIKH0XZoAAAAAABzTANBglghkgBZQMEAgEFAKBpMC8GCSqG
SIb3DQEJBDEiBCC1ximh9/hmDrr7wUfBrUC3yQXVoqQGVx5mZB1XIV31uDAYBgkqhkiG9w0B
CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTAxMTQwMDMyMTRaMA0GCSqGSIb3
DQEBAQUABIIBAHnntKZQtcks0E8gaGhGWzMNOwUglzvrN3fVap2X6GKL9rL13+pS9lL50OVL
jOkg9/v6eMk4q2R5Fc1z+in07XV+p9EUEZBkJhPNPrVigxRw5hKAJ+iB29rOhjGRR3T7R4VI
0YaLYbdZchmrn6SuMk9Ws7EODym6WRhT6gpAvQzbzB91w/jKMgjV0KgsJPyMicR90ycXHE2Q
G4pa/4rwuV6RUct67EH+k92NPPGSODB3THXwyA4beFmmVtjrxFsfnq3ULsAR+41flbtl81bB
/nxLxaMc3rkrsQLDN3tMviOvHVQuMfFABVTLs9cjSGrXxtm2kGFHUHH8XE6A5z9rNJY=

--B_3504022334_27857347--


From nobody Tue Jan 13 16:38:22 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 383661ACE04 for ; Tue, 13 Jan 2015 16:38:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level: 
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, 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 Y599LL1Vq1Dc for ; Tue, 13 Jan 2015 16:38:18 -0800 (PST)
Received: from mail-oi0-f50.google.com (mail-oi0-f50.google.com [209.85.218.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 208351ACE18 for ; Tue, 13 Jan 2015 16:38:17 -0800 (PST)
Received: by mail-oi0-f50.google.com with SMTP id x69so5068511oia.9 for ; Tue, 13 Jan 2015 16:38:17 -0800 (PST)
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=VkKK9/OpEYa2QHw3MswrHEaB/xTMIBYCNPj0zm7tsBA=; b=UMsCdS1QOtf1OqOK67UVuBsKNDbkkBo3hqKp1k8BwkZM6ViZaheiv8A0JxKYq5ukAX 1/qKo6PbKjShmSgZJprJa5XUn9jESQP6+SHZINiednNQ8/rryulgsYj0oCMkkXNDa6wv bfdDI0/AkMk6zKyKwDoIkQTP+sFdg/8QK4N8PKGRj/Kjcz/onSQ4VJ/48PCyX0+qitDP 6seiWoexB/18Vp0y5jjFiJdAblQX/Erc1h8WD/fbV5OFNSAdypv14wB+xWxvHEIO6xtx 7Jzjmkc+zAhE3OB8w2qmWPSqeyQ0oYuc3E1aFkH7cYELQQvNHpzH05pIWXvtexDOB6tE 431Q==
X-Gm-Message-State: ALoCoQnRGhFqY+heYxkR1s9L2+Kn9MAdyQBIyEatp6znBcgAag+9tF0wizcXQos38gQRwn1Gm64l
MIME-Version: 1.0
X-Received: by 10.202.137.70 with SMTP id l67mr628705oid.89.1421195897192; Tue, 13 Jan 2015 16:38:17 -0800 (PST)
Received: by 10.76.71.228 with HTTP; Tue, 13 Jan 2015 16:38:17 -0800 (PST)
In-Reply-To: <54B5501A.4070402@azet.org>
References: <54B5501A.4070402@azet.org>
Date: Tue, 13 Jan 2015 16:38:17 -0800
Message-ID: 
From: Brian Smith 
To: Aaron Zauner 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: TLS Mailing List 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Jan 2015 00:38:20 -0000

Aaron Zauner  wrote:
> Having a seperate RFC for
> every cipher and thus ciphersuite seems a bit confusing. Is this the
> intended approach still?

I agree that it ideally we wouldn't insist on a separate RFC for every
cipher suite. On the other hand, because of IPR concerns and other
non-technical factors, I think it is better to specify these cipher
suites in a separate RFC. That way, there'd be no risk of IPR concerns
clouding the IPR status of TLS 1.3 itself and/or delaying its
publication.

Cheers,
Brian


From nobody Tue Jan 13 17:01:31 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 699531ACD46 for ; Tue, 13 Jan 2015 17:01:29 -0800 (PST)
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 9e97NAPRO-JP for ; Tue, 13 Jan 2015 17:01:27 -0800 (PST)
Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6445C1ACE20 for ; Tue, 13 Jan 2015 17:01:27 -0800 (PST)
Received: by mail-qc0-f179.google.com with SMTP id c9so5162303qcz.10 for ; Tue, 13 Jan 2015 17:01:26 -0800 (PST)
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=Tpco4GxK8hL32nKde00q+gmziqfCAPXqqZSYnw7bgYM=; b=OfxWfAsfU5k9wiIdVwGVQfz1d7kH26cOy5A2zMoYgTBnBGV+qACvyOWxgjSaoxl34P yriTN4kzgPzoQ5EnhyEyDwYxDHQqp3LGMuoJuNI49OyCyTqYyIpIsRkqbSOI4e9VR+Jb XgPSlz92V0A6nqEzo1ixQznAm7tFZwcOxQ6wkOnL1W2qvudWS/jPXdEJReZwDcdr+tFK 5Zz8UNnsjLAVsKTO3fXEZXhG73cr9EG2DFmmRwAIWpeyEUecHhHoY1O+TNs1LGtJK+Pp tg6t6sw4EUSurQPrlOCgLqgvEyWaQjpV37b5QGysdKX1bZjr+GQiFbv9GT8rZS5hVHGx xQjg==
X-Gm-Message-State: ALoCoQkaOx5CzaaLiPBPFkNarAkx0JoOWnUbsN65+NpSjHwxCPiC9hGsqZT1xvkHDmcr7vpJWKXd
MIME-Version: 1.0
X-Received: by 10.224.137.2 with SMTP id u2mr2507626qat.70.1421197286713; Tue, 13 Jan 2015 17:01:26 -0800 (PST)
Received: by 10.140.89.241 with HTTP; Tue, 13 Jan 2015 17:01:26 -0800 (PST)
X-Originating-IP: [178.16.220.162]
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D55AEC364@USMBX1.msg.corp.akamai.com>
References: <54B5501A.4070402@azet.org>  <2A0EFB9C05D0164E98F19BB0AF3708C71D55AEC364@USMBX1.msg.corp.akamai.com>
Date: Wed, 14 Jan 2015 01:01:26 +0000
Message-ID: 
From: Jacob Appelbaum 
To: "Salz, Rich" 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: TLS Mailing List 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Jan 2015 01:01:29 -0000

On 1/13/15, Salz, Rich  wrote:
>> There are, of course, reasons why people would not want to accept a
>> proposal like that.  More cipher suites isn't strictly a good thing.
>> Of course, if OCB is demonstrably better in some fashion (speed,
>> security,
>> whatever it happens to be), then that makes the case easier.
>
> That "no military use" being particularly problematic.  Does anyone know if
> the IETF has other IPR grants with similar field-of-use limitations?
>

I don't see it as problematic at all. It is his right and also his
responsibility. I think it is fantastic that Phil Rogaway is aware of
his power and uses it. It sounds like he willing to talk about it too.
This discussion even comes up because of that reasonable use of power.

The concern trolling and endorsement of the military is much more
problematic, frankly. Especially since we know that they run people as
part of the BULLRUN[0] programs to influence standards bodies - such
as the IETF specifically!

Hopefully OCB will be included in TLS 1.3 without a separate RFC. It
seems like Phil's page has specific licenses that are very
reasonable[1]:

"That said, I have freely licensed any IP I own over a very large
space: there is one license grant for open-source software; one for
non-military software; and a third done just for OpenSSL.

All the best,
Jacob

[0] https://en.wikipedia.org/wiki/Bullrun_(decryption_program)
[1] http://web.cs.ucdavis.edu/~rogaway/ocb/ocb-faq.htm#patent:phil


From nobody Tue Jan 13 22:54:12 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 199911A89A5 for ; Tue, 13 Jan 2015 22:54:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.95
X-Spam-Level: 
X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, 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 epid-_yhz9pR for ; Tue, 13 Jan 2015 22:54:09 -0800 (PST)
Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DC5A1A896D for ; Tue, 13 Jan 2015 22:54:08 -0800 (PST)
Received: from [2.66.67.90] (2.66.67.90.mobile.tre.se [2.66.67.90]) by mail.frobbit.se (Postfix) with ESMTPSA id 1789F2135D; Wed, 14 Jan 2015 07:54:07 +0100 (CET)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: =?utf-8?Q?Joachim_Str=C3=B6mbergson?= 
X-Mailer: iPhone Mail (12B440)
In-Reply-To: 
Date: Wed, 14 Jan 2015 07:54:07 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <54B5501A.4070402@azet.org>  <2A0EFB9C05D0164E98F19BB0AF3708C71D55AEC364@USMBX1.msg.corp.akamai.com> 
To: Jacob Appelbaum 
Archived-At: 
Cc: TLS Mailing List 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Jan 2015 06:54:11 -0000

Aloha!


> On 14 Jan 2015, at 02:01, Jacob Appelbaum  wrote:
>=20
> Hopefully OCB will be included in TLS 1.3 without a separate RFC. It
> seems like Phil's page has specific licenses that are very
> reasonable[1]:
>=20
> "That said, I have freely licensed any IP I own over a very large
> space: there is one license grant for open-source software; one for
> non-military software; and a third done just for OpenSSL.

For us doing open source HW designs, having licenses that specifically speci=
fies usage rights for open source _software_ it becomes problematic. Please j=
ust state "open source" if possible.

Phil's license is an example of such a problem. I've written to him asking i=
f it would be possible to also allow open HW implementations of OCB. Unfortu=
nately I've yet to receive a response.

Yours
JoachimS=


From nobody Wed Jan 14 04:03:03 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BDEA1B2C6D for ; Wed, 14 Jan 2015 04:03:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.668
X-Spam-Level: 
X-Spam-Status: No, score=-1.668 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-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 4l187mdGwM9P for ; Wed, 14 Jan 2015 04:03:00 -0800 (PST)
Received: from tlsx.org (tlsx.org [67.207.128.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 322C91B2C6C for ; Wed, 14 Jan 2015 04:03:00 -0800 (PST)
Received: from monty.local (unknown.maxonline.com.sg [58.182.90.50] (may be forged)) (authenticated bits=0) by tlsx.org (8.14.4/8.14.4/Debian-4) with ESMTP id t0ECOS5O001057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 14 Jan 2015 12:24:31 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=metaparadigm.com; s=klaatu; t=1421238273; bh=jyk2gZIEtCnVSMles2ASWNuPKAjzgbNuwhEHKXFzLyI=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=SP4rKaOB9J7RGR57vP6UGAyAuYqh4RtELJQRdNrS53MAYs1PkQiGLduDFk1bGaRLc +IY6XCA+58GN1Fti7MJq1hAUyICLtWjEq1m9aVCQnEptH0Tmu+e8gcCEReQmBnjD/2 WbPzl07slfcD5PFnHi0TAa7ahza7MYRKXj/rTjjM=
Message-ID: <54B65ADF.5020506@metaparadigm.com>
Date: Wed, 14 Jan 2015 20:02:39 +0800
From: Michael Clark 
Organization: Metaparadigm
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Ilari Liusvaara 
References: <274716D0-EC91-4131-A8F7-CD13A9B42CE7@gmail.com>  <54ADE9B6.4080700@metaparadigm.com> <702F318A-FE04-45F7-8CA1-30256D628CF7@gmail.com> <54B1DD25.8090305@metaparadigm.com> <20150111051421.GA32295@LK-Perkele-VII>
In-Reply-To: <20150111051421.GA32295@LK-Perkele-VII>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.98.4 at klaatu.metaparadigm.com
X-Virus-Status: Clean
Archived-At: 
Cc: "TLS@ietf.org \(tls@ietf.org\)" 
Subject: Re: [TLS] RFC4492bis - Removing ECDH
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Jan 2015 12:03:02 -0000

On 11/1/15 1:14 pm, Ilari Liusvaara wrote:
> On Sun, Jan 11, 2015 at 10:17:09AM +0800, Michael Clark wrote:
>>
>> There is a more subtle pass through case where handshake messages can be
>> tampered with (without access to a CA, just an Internet coffee bucks
>> WiFi tap). Allows attacks such as editing cipher lists and any other
>> associated handshake metadata (curve format extensions, switching on
>> compression) that are not properly authenticated. Until I am certain
>> they are completely mitigated I remain skeptical.
> 
> This attack won't work.
> 
> - TLS 1.3: The messages are hashed into hMS, so you can't decrypt the
>   rest of the handshake due to having wrong keys.

This was my thinking however I could not read this clearly in the text
as the record protection for handshake was stated as NULL NULL AEAD.

I am still looking for clear text in {{key-calculation}} that describes
that a strong authenticator of all sent handshake messages are returned
to each end signed in the Finished message.

Can we differentiate a tamper from garbled data?

Anyway it offers no protection against the yellow patch cable to the
grey box. There are many CA certs in the vendor trust stores. If you
sent 3 certs from CAs with no relationships then you could eliminate
this kind of tampering. multi-rooted. Verify is only a cost for 24H
(given session caching and ticket timeout is sorted).

> - TLS 1.0-1.2 w/o false start: The Finished values will fail to verify.
> - TLS 1.0-1.2 /w false start: The selected crypto must be strong, or
>   endpoints won't enage in false start.

OK In TLS 1.2 the spec states there is no record protection for
handshake messages. I see verify_data field in Finished. It is vaguely
specified in RFC5426 and RFC5288 (AES-GCM) makes no reference to it.

However I am still skeptical as there is no record protection for
handshake messages so I don't know what is preventing the proxy from
returning illegal_parameter to the client hello until the client does a
TLS1.0 ClientHello and then edit the cipher list remove SCSV and cause
client to negotiate TLS_WITH_RSA_RC4_128_SHA with Windows XP.

I'm trying to find where the 12 octect verify_data is specified. If
*all* of the the handshake payload is in a MAC in verify data then you
could generate still generated ignored extensions to get a 96-bit hash
collision. Still reasoning about it...

Michael


From nobody Wed Jan 14 04:03:17 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 210D61B2C79 for ; Wed, 14 Jan 2015 04:03:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.458
X-Spam-Level: 
X-Spam-Status: No, score=-1.458 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=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 FjyIlQP3k3R1 for ; Wed, 14 Jan 2015 04:03:09 -0800 (PST)
Received: from tlsx.org (tlsx.org [67.207.128.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D71251B2C78 for ; Wed, 14 Jan 2015 04:03:08 -0800 (PST)
Received: from monty.local (unknown.maxonline.com.sg [58.182.90.50] (may be forged)) (authenticated bits=0) by tlsx.org (8.14.4/8.14.4/Debian-4) with ESMTP id t0ECOium001065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 14 Jan 2015 12:24:47 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=metaparadigm.com; s=klaatu; t=1421238289; bh=S/2FIIZypdQSd5/zSTK5kw93qo1H0fEur1SjzHI1QjY=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=Q4xV/0DimQG0csadmmSf8BC5qL/oHgCpQaKEaq57LoNlymHbk6dSKk0RBM8Ukt3nb CnzvGeKiRG14xbrM6wNhTZbooh3yxyBNvVdQWEH5dmbTa9H78gFRwquNJBn+lBCa6/ hHQv1l4/Czn8dYNNFx5seFztWBeRRathKYmRmrYw=
Message-ID: <54B65AF0.1080503@metaparadigm.com>
Date: Wed, 14 Jan 2015 20:02:56 +0800
From: Michael Clark 
Organization: Metaparadigm
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Martin Thomson , Watson Ladd 
References: <9A043F3CF02CD34C8E74AC1594475C73AAF525B9@uxcn10-tdc05.UoA.auckland.ac.nz>  <54B54A5F.7020401@polarssl.org>     
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.98.4 at klaatu.metaparadigm.com
X-Virus-Status: Clean
Archived-At: 
Cc: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= , "" 
Subject: Re: [TLS] AAED ciphers: AES-GCM vs AES-EAX/AES-CCM: a meta-analysis
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Jan 2015 12:03:10 -0000

On 14/1/15 2:32 am, Martin Thomson wrote:
> On 13 January 2015 at 10:23, Watson Ladd  wrote:
>>> https://tools.ietf.org/html/draft-pironti-tls-length-hiding-01 would be a
>>> good starting point, no?
>>
>> Seem to be, although I don't remember it being discussed on the list
>> before. We should fix this problem.
> 
> 
> We discussed it at some length at a meeting (Denver).  There was
> significant interest in doing this, though I think we agreed that we
> had to sort out a few things before the time was right.
> 
> See also https://github.com/tlswg/tls13-spec/issues/69

Interesting. Should draft-pironti-tls-length-hiding-01 be added to
Related Active Documents (not working group documents) section here:

    https://tools.ietf.org/wg/tls/

Michael


From nobody Wed Jan 14 04:22:02 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83F7E1B2C79 for ; Wed, 14 Jan 2015 04:22:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.668
X-Spam-Level: 
X-Spam-Status: No, score=-1.668 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-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 zoqnIJi7kQ7a for ; Wed, 14 Jan 2015 04:21:59 -0800 (PST)
Received: from tlsx.org (tlsx.org [67.207.128.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 352111B2C78 for ; Wed, 14 Jan 2015 04:21:59 -0800 (PST)
Received: from monty.local (unknown.maxonline.com.sg [58.182.90.50] (may be forged)) (authenticated bits=0) by tlsx.org (8.14.4/8.14.4/Debian-4) with ESMTP id t0EChRaX001215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 14 Jan 2015 12:43:30 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=metaparadigm.com; s=klaatu; t=1421239412; bh=R14rErxXCA14Gl+bkQ2CGsbV4GaZOSTZ5/eLf1Q5VF4=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=MsuZWU/zegbl0qF6Qa/huCxZRZKZbEYRrBVivTRHrfbjyWygFOrip/lqWdSCHqvpw GutqC3m2cEgvQLCbl/4Ccyol5ldoliXKbOTotODH+g4hryadYpQxYnCqfjrhOQiyQl htFHIL2XdnP/MZ1t0GO0wQhkUAZLRal35xMY78kc=
Message-ID: <54B65F52.6040707@metaparadigm.com>
Date: Wed, 14 Jan 2015 20:21:38 +0800
From: Michael Clark 
Organization: Metaparadigm
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Ilari Liusvaara 
References: <274716D0-EC91-4131-A8F7-CD13A9B42CE7@gmail.com>  <54ADE9B6.4080700@metaparadigm.com> <702F318A-FE04-45F7-8CA1-30256D628CF7@gmail.com> <54B1DD25.8090305@metaparadigm.com> <20150111051421.GA32295@LK-Perkele-VII> <54B65ADF.5020506@metaparadigm.com>
In-Reply-To: <54B65ADF.5020506@metaparadigm.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.98.4 at klaatu.metaparadigm.com
X-Virus-Status: Clean
Archived-At: 
Cc: "TLS@ietf.org \(tls@ietf.org\)" 
Subject: Re: [TLS] RFC4492bis - Removing ECDH
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Jan 2015 12:22:00 -0000

> On 11/1/15 1:14 pm, Ilari Liusvaara wrote:
>> - TLS 1.0-1.2 w/o false start: The Finished values will fail to verify.
>> - TLS 1.0-1.2 /w false start: The selected crypto must be strong, or
>>   endpoints won't enage in false start.
> 
> OK In TLS 1.2 the spec states there is no record protection for
> handshake messages. I see verify_data field in Finished. It is vaguely
> specified in RFC5426 and RFC5288 (AES-GCM) makes no reference to it.
> 
> However I am still skeptical as there is no record protection for
> handshake messages so I don't know what is preventing the proxy from
> returning illegal_parameter to the client hello until the client does a
> TLS1.0 ClientHello and then edit the cipher list remove SCSV and cause
> client to negotiate TLS_WITH_RSA_RC4_128_SHA with Windows XP.

*as* Windows XP.

> I'm trying to find where the 12 octet verify_data is specified. If
> *all* of the the handshake payload is in a MAC in verify data then you
> could generate still generated ignored extensions to get a 96-bit hash
> collision. Still reasoning about it...

sorry garbled. I meant construct 96-bit collision to forge verify_data.


From nobody Wed Jan 14 05:38:49 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAC401A8AB4 for ; Wed, 14 Jan 2015 05:38:46 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, 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 bFMhSIINpHdt for ; Wed, 14 Jan 2015 05:38:42 -0800 (PST)
Received: from emh01.mail.saunalahti.fi (emh01.mail.saunalahti.fi [62.142.5.107]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71A561B2CA9 for ; Wed, 14 Jan 2015 05:38:40 -0800 (PST)
Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id AD6D39003E; Wed, 14 Jan 2015 15:38:37 +0200 (EET)
Date: Wed, 14 Jan 2015 15:38:37 +0200
From: Ilari Liusvaara 
To: Michael Clark 
Message-ID: <20150114133837.GA32171@LK-Perkele-VII>
References: <274716D0-EC91-4131-A8F7-CD13A9B42CE7@gmail.com>  <54ADE9B6.4080700@metaparadigm.com> <702F318A-FE04-45F7-8CA1-30256D628CF7@gmail.com> <54B1DD25.8090305@metaparadigm.com> <20150111051421.GA32295@LK-Perkele-VII> <54B65ADF.5020506@metaparadigm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <54B65ADF.5020506@metaparadigm.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara 
Archived-At: 
Cc: "TLS@ietf.org \(tls@ietf.org\)" 
Subject: Re: [TLS] RFC4492bis - Removing ECDH
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Jan 2015 13:38:47 -0000

On Wed, Jan 14, 2015 at 08:02:39PM +0800, Michael Clark wrote:
> On 11/1/15 1:14 pm, Ilari Liusvaara wrote:
> > On Sun, Jan 11, 2015 at 10:17:09AM +0800, Michael Clark wrote:
> >>
> >> There is a more subtle pass through case where handshake messages can be
> >> tampered with (without access to a CA, just an Internet coffee bucks
> >> WiFi tap). Allows attacks such as editing cipher lists and any other
> >> associated handshake metadata (curve format extensions, switching on
> >> compression) that are not properly authenticated. Until I am certain
> >> they are completely mitigated I remain skeptical.
> > 
> > This attack won't work.
> > 
> > - TLS 1.3: The messages are hashed into hMS, so you can't decrypt the
> >   rest of the handshake due to having wrong keys.
> 
> This was my thinking however I could not read this clearly in the text
> as the record protection for handshake was stated as NULL NULL AEAD.
> 
> I am still looking for clear text in {{key-calculation}} that describes
> that a strong authenticator of all sent handshake messages are returned
> to each end signed in the Finished message.

The first message keying includes hashes of all previous messages, so
those have to match for the keys to match.

For messages after the first keying, those are protected by the MAC built
into AEAD cipher.

> Anyway it offers no protection against the yellow patch cable to the
> grey box. There are many CA certs in the vendor trust stores. If you
> sent 3 certs from CAs with no relationships then you could eliminate
> this kind of tampering. multi-rooted. Verify is only a cost for 24H
> (given session caching and ticket timeout is sorted).

Yeah, certificates are another kettle of fish (made lots worse by
actual implementations that just plain don't work).

> > - TLS 1.0-1.2 w/o false start: The Finished values will fail to verify.
> > - TLS 1.0-1.2 /w false start: The selected crypto must be strong, or
> >   endpoints won't enage in false start.
> 
> OK In TLS 1.2 the spec states there is no record protection for
> handshake messages. I see verify_data field in Finished. It is vaguely
> specified in RFC5426 and RFC5288 (AES-GCM) makes no reference to it.

RFC5246 (TLS 1.2) you mean? And it does specify how Finished is computed,
and yes, it does include a hash of handshake messages in the computations.

Of course, if endpoint does not check the Finished message, things go
badly wrong (TLS 1.3 just blows up due to mismatched keys).

> However I am still skeptical as there is no record protection for
> handshake messages so I don't know what is preventing the proxy from
> returning illegal_parameter to the client hello until the client does a
> TLS1.0 ClientHello and then edit the cipher list remove SCSV and cause
> client to negotiate TLS_WITH_RSA_RC4_128_SHA with Windows XP.

Not having client ever fall back (of course, browsers have historically
been pretty bad at this, which made POODLE more than just a curiosity).

> I'm trying to find where the 12 octect verify_data is specified. If
> *all* of the the handshake payload is in a MAC in verify data then you
> could generate still generated ignored extensions to get a 96-bit hash
> collision. Still reasoning about it...

It is specified in base TLS spec (Section 7.4.9 for TLS1.2 / RFC5246).

And given the realtime requirements, even ~2^48 work to collide a 96-
bit hash is a lot of work. And looks like one would need a preimage
to do anything interesting, which is ~2^96 work (regarded infeasible
even with lots of resource).


-Ilari


From nobody Wed Jan 14 06:16:01 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71CB91B2C72 for ; Wed, 14 Jan 2015 06:15:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level: 
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, 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 9CBzV3_ElJjt for ; Wed, 14 Jan 2015 06:15:57 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE8791A8AB4 for ; Wed, 14 Jan 2015 06:15:57 -0800 (PST)
Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t0EEFtu3014403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 14 Jan 2015 09:15:56 -0500
Received: from oldenburg.str.redhat.com (oldenburg.str.redhat.com [10.33.200.60]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t0EEFrNt017708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 14 Jan 2015 09:15:54 -0500
Message-ID: <54B67A19.9010507@redhat.com>
Date: Wed, 14 Jan 2015 15:15:53 +0100
From: Florian Weimer 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Johannes Merkle , "" 
References: <525BADBD.8020007@secunet.com>
In-Reply-To: <525BADBD.8020007@secunet.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Archived-At: 
Subject: Re: [TLS] Using RSA PSS in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Jan 2015 14:15:59 -0000

On 10/14/2013 10:39 AM, Johannes Merkle wrote:
> While the current discussion on this list is about ECC, I would like to raise the question if it were not desirable to
> allow usage of provably secure RSA-PSS signatures from PKCS#1v2.1 in TLS.

So it seems that using RSA-PSS is difficult (although CAs could offer to 
issue multiple certificates which could be switched as needed if a 
server operator doesn't want to make both RSA-PSS signatures and PKCS#1 
1.5 signatures).

What about changing PFS for the RSA ciphersuites so that they continue 
to use RSA encryption, and not rely on an RSA signature for server 
authentication?  From my point of view, this removes one major objection 
to enabling PFS (namely, as it stands now, it's a completely different 
protocol, potentially with drastically different security properties).

-- 
Florian Weimer / Red Hat Product Security


From nobody Wed Jan 14 06:32:47 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEF921B2CB7 for ; Wed, 14 Jan 2015 06:32:44 -0800 (PST)
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 8JAiYCP3aSSU for ; Wed, 14 Jan 2015 06:32:43 -0800 (PST)
Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D5C51A0191 for ; Wed, 14 Jan 2015 06:32:43 -0800 (PST)
Received: by mail-ig0-f174.google.com with SMTP id hn15so22661050igb.1 for ; Wed, 14 Jan 2015 06:32:42 -0800 (PST)
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=rf8JS3Kg/FrIM6aCjQSiTaAPGDRcZDttBJWCoqPFpEM=; b=GdWqerD+vZp7Dr223hwHxr5QYyoPUYJg3l1MBH3k7i2iH56vi4zDwCzMl94Veatjg7 6idNOi6bhewzVkS6lM8gIbyubdmh+16RzTvEDEVaNSz3igKXd50j8XkaGZ+kV5aLAaLB RF9jcItLP3XrTNUqQCFzU5kxA4PldwCCEZOn3N9S3kb8WA48x0lJ/YZK9Bizf/fajMy8 3cEMFvO0SsCw05nTjzy58yweXGetsvXVh6FJ337liASiS/BOhIDyVHFV1F7yfgn+jew5 sQ4XmRe5IzZZBlPCLnj6xRfmN/v/pJ4ljLM+a9uw0YEtHo/xE9rFi7w7QHxyWOrLKBXA NaXw==
MIME-Version: 1.0
X-Received: by 10.50.142.99 with SMTP id rv3mr3879489igb.11.1421245962343; Wed, 14 Jan 2015 06:32:42 -0800 (PST)
Received: by 10.107.12.220 with HTTP; Wed, 14 Jan 2015 06:32:42 -0800 (PST)
In-Reply-To: <54B67A19.9010507@redhat.com>
References: <525BADBD.8020007@secunet.com> <54B67A19.9010507@redhat.com>
Date: Wed, 14 Jan 2015 15:32:42 +0100
Message-ID: 
From: CodesInChaos 
To: Florian Weimer 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "" 
Subject: Re: [TLS] Using RSA PSS in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Jan 2015 14:32:44 -0000

On Wed, Jan 14, 2015 at 3:15 PM, Florian Weimer  wrote:
> What about changing PFS for the RSA ciphersuites so that they continue to
> use RSA encryption, and not rely on an RSA signature for server
> authentication?

Switching from PKCS#1v1.5 encryption to OAEP is just as tricky as
switching from PKCS#1v1.5 signing to PSS signatures.

I consider the risk of PKCS#1v1.5 encryption far bigger than the risk
of PKCS#1v1.5 signatures.
I'm not aware of any attack against  PKCS#1v1.5 signatures, they
merely lack a security proof.
PKCS#1v1.5 encryption is problematic since detectable decryption
failures can act as an oracle. Implementations need to be really
careful to avoid these.


From nobody Wed Jan 14 06:47:19 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 503981B2CD9 for ; Wed, 14 Jan 2015 06:47:15 -0800 (PST)
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 GnnEL7Cz-9oU for ; Wed, 14 Jan 2015 06:47:11 -0800 (PST)
Received: from mail-we0-f169.google.com (mail-we0-f169.google.com [74.125.82.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C8231B2CCF for ; Wed, 14 Jan 2015 06:46:57 -0800 (PST)
Received: by mail-we0-f169.google.com with SMTP id m14so9226184wev.0 for ; Wed, 14 Jan 2015 06:46:55 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=2RqCdqjbGCPjNCfYg6yN/SiBZzFVC5j1hZYdsyget3k=; b=cQQq+46IZ5i5phMHsYF32GWw6YylP1yBGAdoTc2c6Rr+uPggYiSRIPNSTnbSpBk/Y7 VdEIq1XwWgJ1O8JwBOm4Os/MpS+zYbL1yiEZPosc8KMAr4bjzK3NSXvxqfLSuE+YY/kp 5o+lbF9fN914P1u7FG0bhdBqwJzVVf02Qb7ZDwhLyI9Yr5VCFuTf6C+k0+37Z0912ojc bSk3u/2DQy6udpDPgdruPj63o3xGrCtL6rAz68cUft9ZyzFMNh90eFt3Fbx5lK2JjwiP lavpjAQLPbeQFZgGpCm25dwIVSsXBhRAGYSAgbU6LF+RspBAPvwVJHN1XnYHf4q6cTHo xbAw==
X-Gm-Message-State: ALoCoQkxEOxOGjBI/5zavOZUc1Fn8DYNiudP0cEvZa+8lM8hl7ckA2/vmF5NR8KkbC9X9L1ccG/Z
X-Received: by 10.194.79.226 with SMTP id m2mr7989551wjx.60.1421246815791; Wed, 14 Jan 2015 06:46:55 -0800 (PST)
Received: from [10.60.20.30] ([193.170.94.190]) by mx.google.com with ESMTPSA id la10sm30360448wjc.36.2015.01.14.06.46.54 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 14 Jan 2015 06:46:54 -0800 (PST)
Message-ID: <54B6815A.7060102@azet.org>
Date: Wed, 14 Jan 2015 15:46:50 +0100
From: Aaron Zauner 
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: Stephen Farrell 
References: <54B5501A.4070402@azet.org>  <54B58F5B.2010704@cs.tcd.ie>
In-Reply-To: <54B58F5B.2010704@cs.tcd.ie>
X-Enigmail-Version: 1.2.3
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig46281C79351D1F6137AA8AF1"
Archived-At: 
Cc: TLS Mailing List 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Jan 2015 14:47:15 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig46281C79351D1F6137AA8AF1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Stephen,

Stephen Farrell wrote:
> 
>=20
> On 13/01/15 18:25, Paul Lambert wrote:
>> This should not stop inclusion of OCB as an optional mode in TLS,
>=20
> I don't get why additional options are at all attractive. In
> fact, I think they're ugly.
>=20
> TLS has about 327 ciphersuites. That's just stupid. (I'm not
> saying any person is stupid there btw, but we have gotten
> ourselves into a stupid place.)

Yup. Having different naming schemes for different
libraries/implementations beyond that makes it almost impossible to give
good recommendations to end-users (admins, management) as we've noticed
in the bettercrypto.org project.

>=20
> If we have a really better thing, they why not make it MTI? If
> we do not have something sufficiently better then I'd argue to
> exclude as much as possible, and certainly against adding
> anything that is just nice to have.
>=20
> I'd even like to make almost all current ciphersuites a MUST NOT
> (or start a new registry) for TLS1.3 and to not add any new
> ciphersuites at all, and just stick with two MTI ciphersuites
> that are as genetically different as possible and cover as many
> implementations (h/w AES or not) as possible.
>=20
> So my suggestion is to reduce the ciphersuite field to be
> 2 bits wide in TLS 1.3, with 00 being default, 01 backup, 02
> being "proprietary" and 03 reserved. If either 00 or 01 needs
> to be changed then I'd say rev the TLS version. (I don't care
> if we did s/default/has-AES-hw/ and s/backup/just-sw-crypto/
> that'd also be fine.)
>=20
> And yes, I realise that's not likely to get traction, but
> turning 327 into 427 is even dumber when reality shows that
> only a few of 'em are used or needed.

Just as a suggestion, how about a document that does only include
forward-secret cipher-suites that are valid for TLS 1.3? That would
drastically remove the number of OCB ciphersuites that I would have to
add in case of TLS 1.2.

One issue though: as far as I can tell (from the recent RWC presentation
by EKR) there are still going to be three block ciphers in TLS 1.3: AES,
CAMELLIA, ARIA. One could also only define ciphersuites for AES. The
original paper only talks about the merits of OCB mode with AES - so
this would make sense. Since of the other ciphers are -- to some extent
-- based on AES, OCB mode would work perfectly fine with them, but then
again; who really uses them? I certainly agree that ciphersuite
pollution is not the best way to go. But having three different AEAD
block modes to choose from is.

Is this a reasonable proposal?

As for Jake's comment: Personally I fully agree with that, but can see
why the military exception would make it hard for IETF to have this mode
as mandatory to implement. So it'd probably end up as optional. Given
that support for OCB is already present in (some) implementations; this
would, again, make sense.

Aaron


--------------enig46281C79351D1F6137AA8AF1
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUtoFbAAoJEOTbZJL9ubXVV3AQAKlaGeRmp7YHKZBPyz00fe4g
EWY8oy7qfU7a64+gI4YPUAg0yTqGAY0YpxficxCVnRrrdtIpHrF5ZtMbLJCNUVLH
qiqsSxDu4sLbYzNcQtNurfKy8Q6uGAezuJqdRhj9jBxC7uj4yhWZGLixjBY48xFP
fXLLrxwZ5rrocZVdrJWL4R1P9jPUf1tgG+1TN77T8e5RwyFaiGyH9rAVKHYYotl3
uis7U5JsNPBjD4bkacLCtdThPZyvr+ErV3x/LBbW/FIAUHTj6UnPinMriUpdycXt
tCTLy5Hv/G8XybsIAyQwIx9M15JOgNjbad+/WsoATINEeWAduhbboX5LEuZMu9fE
ZX2v+Ld8MbHNJYZp2HIClAsj0U0dwNL8w8feXXUfVMgfraIKccXNKTxrnZGTCgPO
5YVqzBxgi7a7fwcfVbhIn1n1vZqwS7Xa1fkIxx9y7bQvV017or2gwvgrhdBTr6Aw
ufpttVte7HCitVGOk6qkx/7CUxALP6eL9Pw7NJcOct+pZrTU9DhczfF0OsMp5QkC
BmjOQvHJJmknlDo/qPyeyJRMUsKjhexnxMz3P3izEP6ck4M9cvdf6q5Ir9eEawwq
Q7pI+aB/RpmBYF8tZ4XuNiFJdkW4E0+qeWz7gbVgswvv0BXQqzWvoMQ0RIb7Mmhq
yXYUDnm3DkvuGn7JS0Z2
=hu32
-----END PGP SIGNATURE-----

--------------enig46281C79351D1F6137AA8AF1--


From nobody Wed Jan 14 07:26:26 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 062551A8873 for ; Wed, 14 Jan 2015 07:26:25 -0800 (PST)
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 IckLANmmWX95 for ; Wed, 14 Jan 2015 07:26:23 -0800 (PST)
Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 200321A87D5 for ; Wed, 14 Jan 2015 07:26:22 -0800 (PST)
Received: by mail-we0-f176.google.com with SMTP id w61so9387131wes.7 for ; Wed, 14 Jan 2015 07:26:21 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=+3FQl6+8i+9PGYulyZGOapzScJR9SoRSumuP7sq9444=; b=dEmPNA6pcOO2NL2tSAGB//GUgC2iMer/6nzVZJHG/L6CUwwqGSgAei+CvSnJh56hF8 pjbBkk7pejtLX+DT5OO/t2zHZkuTzyRis+qWJD7+PCJ4/2K2Ww/U927077kl4bbd82Y/ AjYdjV1y3oHhZ6QpFHquBTGRoJVGLrwsmgTEfIeRfItZjNV/YtGE7/pX/IJyVNMWCEOe pZXL36Ld2lf3IthlzvHWQMydO/t/SX8SdWRLGjCB7FQ+gSqyKX/4BYw+bCwRXD6VxhFc ZuusnX8AYbVY0NCfbiNtEZny7ezfHgpaxOK3rxZAQFEbIdbS0V2ql0o1Ga7f7Ai0pVD4 jfHA==
X-Gm-Message-State: ALoCoQmlfinrrUDXFBZx3OkqJbn3+cI6sQ2cTqV+lLW/s2NxEDaBomBnf20VTnn+Ggkm5pMs6IgC
X-Received: by 10.180.73.235 with SMTP id o11mr16058654wiv.51.1421249180199; Wed, 14 Jan 2015 07:26:20 -0800 (PST)
Received: from [10.60.20.30] ([193.170.94.190]) by mx.google.com with ESMTPSA id a14sm19053256wib.22.2015.01.14.07.26.18 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 14 Jan 2015 07:26:19 -0800 (PST)
Message-ID: <54B68A97.3010007@azet.org>
Date: Wed, 14 Jan 2015 16:26:15 +0100
From: Aaron Zauner 
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: Stephen Farrell 
References: <54B5501A.4070402@azet.org>  <54B58F5B.2010704@cs.tcd.ie> <54B6815A.7060102@azet.org>
In-Reply-To: <54B6815A.7060102@azet.org>
X-Enigmail-Version: 1.2.3
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigC64C1704203A12C3693DF4B3"
Archived-At: 
Cc: TLS Mailing List 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Jan 2015 15:26:25 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigC64C1704203A12C3693DF4B3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi *,

Aaron Zauner wrote:
>=20
> Just as a suggestion, how about a document that does only include
> forward-secret cipher-suites that are valid for TLS 1.3? That would
> drastically remove the number of OCB ciphersuites that I would have to
> add in case of TLS 1.2.
>=20

Going through the ChaCha20/Poly1305 ID, it suggest something very
similar, only adding three ciphersuites:
http://tools.ietf.org/id/draft-agl-tls-chacha20poly1305-04.txt (S. 6).

Aaron


--------------enigC64C1704203A12C3693DF4B3
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUtoqYAAoJEOTbZJL9ubXVukYQAPYdMizDKlzZYmBT5srR6Hse
85v+9jPxIsxkeAHThDb59BOlkvJeUS8C11ODc3P36kzo3KuoRAImHmfjVrenZ4Dn
mtmWZhP6fub6spwpH2GiWVdR7mgpbjcCQfe5CXUxOl2Id++541EEJrj7orxp3aG6
8u78D6+lrPNeXn5qHkXZy8TI0Qn849D3LMnyEsWVm8E+ocdEZwgFKOt2Y3FP4poZ
xmShzr0LgVFSHZO2nUk2ghmHRZ1rMZTwoSZyaBOJUQaWlylVhRpMrgyJYKTZNbLu
FzBwtawGW/riaAgU1e5vi+lnjFQODYRyJlw+2O9FPFayjEMSvlX43pYbLP7Okoa/
zofhWaXQLL5lQoXrrpzN4ueGIjRSmBo/Zd/kX0WBG/3LjaOlOKSC14nYc7oGks/u
fctsZikjKrSq20MBOsgqip7ZgBZe0wPR4OnJsVdDom6u0O+u0fHGGThTeJS74ntw
AnX7oKKeoqwBwzfUtQXNo4Y4B6bWXYWj9WJUPTUYReYVry8Oo31NGQF4GpJxBhES
MM1G8Enp5ZaS6bsYtimYb7q6PVak1aLyKDsNOr/u8spu/Xc56kf/USJeVCYwH0uZ
nny2nLD+sc6pb4gE8DfCFYwC7Ttq5OBumRsloTs4zQFuHHi+EpzWzrBT+wPTd7YA
IUurRtdZZg+HqZ1zaO3g
=w/lB
-----END PGP SIGNATURE-----

--------------enigC64C1704203A12C3693DF4B3--


From nobody Wed Jan 14 07:30:17 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2021A8A03 for ; Wed, 14 Jan 2015 07:30:15 -0800 (PST)
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, 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 p90lLxva6UzL for ; Wed, 14 Jan 2015 07:30:13 -0800 (PST)
Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA671A8954 for ; Wed, 14 Jan 2015 07:30:13 -0800 (PST)
Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id D02DB284E6; Wed, 14 Jan 2015 15:30:12 +0000 (GMT)
Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id B6B89284F2; Wed, 14 Jan 2015 15:30:12 +0000 (GMT)
Received: from email.msg.corp.akamai.com (unknown [172.27.123.34]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id B266C80047; Wed, 14 Jan 2015 15:30:12 +0000 (GMT)
Received: from usma1ex-cashub5.kendall.corp.akamai.com (172.27.105.21) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 14 Jan 2015 10:30:04 -0500
Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Wed, 14 Jan 2015 10:30:04 -0500
From: "Salz, Rich" 
To: Aaron Zauner , Stephen Farrell 
Date: Wed, 14 Jan 2015 10:30:03 -0500
Thread-Topic: [TLS] Inclusion of OCB mode in TLS 1.3
Thread-Index: AdAwDnkUNbQ6WV3gSS2W0eIrDWS2gQAAEnbw
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D55AEC6A9@USMBX1.msg.corp.akamai.com>
References: <54B5501A.4070402@azet.org>  <54B58F5B.2010704@cs.tcd.ie> <54B6815A.7060102@azet.org> <54B68A97.3010007@azet.org>
In-Reply-To: <54B68A97.3010007@azet.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: TLS Mailing List 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Jan 2015 15:30:15 -0000

TLS 1.3 is already AEAD and PFS only, since draft-02:
	Removed support for static RSA and DH key exchange.
	Removed support for non-AEAD ciphers


From nobody Wed Jan 14 07:46:46 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2B481A8A57 for ; Wed, 14 Jan 2015 07:46:42 -0800 (PST)
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 aXChqw0X3utG for ; Wed, 14 Jan 2015 07:46:40 -0800 (PST)
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 624C21A8958 for ; Wed, 14 Jan 2015 07:46:40 -0800 (PST)
Received: by mail-wi0-f181.google.com with SMTP id hi2so11764437wib.2 for ; Wed, 14 Jan 2015 07:46:39 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=Zwq9ZnZmVZRVAXuWPFEvKkFI853ZVtQ0uEJvvge7fZo=; b=cjqymneCBP15sHRxDt728q6fYP+f3uopyqKOgGcDSYpneFkqVa+iJmDD2kviegYBbD vM4SdMs2RAOvXMPDQhhIMo/fB9d2/1ZY1M9Zx/p8W3pUEE2w10LvhO7wC4IMyhdssITp hziNe1IVX9urKl68fEUE1tOmG4BuZGLVZEqA9SC0deFiRqwrvftiJnzoll0EtADH5eO1 AG5LmRnrgYDO2+vIjlC2jNeHxAc9ej7CDwSfzR01hUQYnVzlBtfcx61zlkkzUCiEkNrV jsQSso1JE1hEjOvRFbSELcS2+mogUhYMhrWu34OM1qLLXfJjFlEjOaDYyTpX8O7pcWDA CAnA==
X-Gm-Message-State: ALoCoQkK+6gu3DlqDw11d9PLptzbWcTd/kORkJVlNGUPG0EIj1EG1qfMGrUlqPay+ZOsqBg0BHNT
X-Received: by 10.180.221.201 with SMTP id qg9mr15904287wic.29.1421250399094;  Wed, 14 Jan 2015 07:46:39 -0800 (PST)
Received: from [10.60.20.30] ([193.170.94.190]) by mx.google.com with ESMTPSA id ei5sm19164190wid.2.2015.01.14.07.46.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 14 Jan 2015 07:46:38 -0800 (PST)
Message-ID: <54B68F5B.7070803@azet.org>
Date: Wed, 14 Jan 2015 16:46:35 +0100
From: Aaron Zauner 
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: "Salz, Rich" 
References: <54B5501A.4070402@azet.org>  <54B58F5B.2010704@cs.tcd.ie> <54B6815A.7060102@azet.org> <54B68A97.3010007@azet.org> <2A0EFB9C05D0164E98F19BB0AF3708C71D55AEC6A9@USMBX1.msg.corp.akamai.com>
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D55AEC6A9@USMBX1.msg.corp.akamai.com>
X-Enigmail-Version: 1.2.3
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig4FD662B287C145246EB0F560"
Archived-At: 
Cc: TLS Mailing List 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Jan 2015 15:46:43 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig4FD662B287C145246EB0F560
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



Salz, Rich wrote:
> TLS 1.3 is already AEAD and PFS only, since draft-02:
> 	Removed support for static RSA and DH key exchange.
> 	Removed support for non-AEAD ciphers
Yes, I know. Exactly.

One previous suggestion in this thread was to add ciphersuites down to
TLS 1.2, which would result in an enormous amount of ciphersuites as
Stephen Farrell pointed out earlier. Hence the title of this thread and
my asking if a proposal that only adds TLS 1.3 compatible ciphersuites
would be acceptable by the WG.

Aaron


--------------enig4FD662B287C145246EB0F560
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUto9bAAoJEOTbZJL9ubXVNhUP/1EaKmSw/SSOKwaK5XCwxqjW
HaNjZJPrzz87QG7/h7TKJ5nLJWb2fOJMkKIoNjTBxxTcmRSOXbhnAQt7830I63Ku
/qSYP05WMSWrutGIXU4HTKpIhypyqGoFci+/McFEfpKxMZ0UjKbut/DRVwqWau0W
HEg384kaxZx6CTt7jCvIve7v1bgDFCs0uJv5fDQfcPykQVaDJ1O42apQbQUJcY8g
nav2umIUQ4Z+vPPaORx6kYvGM+RioxqwwwQUQeDby3GoGsdj6pjxUprms+gcQOH/
b1ryBieAbJYdsR9aphjb2nNKgtGne7dPrwOadTUyC6ZEBvgHgMswkFkH67bzSton
8dC1e+Hf0vyh3Zpq+8PbdxXfwm7+SUqhZ0/QuDVEP/r6yetKbZM8w6lis+WrwHmp
qP9uNaJZuEGRkGsG84FFBZiZ0BY0Ld9oJG+nOs7fK5SwvsiTScjx2s8ACUe9+E8Y
LHkJjjPlsv78Njzw666Ba76J+SzKLGL24QMKdzLMmcMeqIVsaCQfeomLqSuBiI33
oDcVdTErHyI3oOfP5KHRiDolccSd2PdvWdyz7KuWpeS5g6DSLVpYi1CP1yLxdVtb
+gBRs2M07xPPBpx4Q9IzDVh3jxeHkrlaVijwZvXBqik+VTBBYub6lZwyCI9gTnMw
wP7Mfaslg2pAjHpiufLB
=UCrR
-----END PGP SIGNATURE-----

--------------enig4FD662B287C145246EB0F560--


From nobody Wed Jan 14 07:51:38 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27B271A6FD5 for ; Wed, 14 Jan 2015 07:51:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level: 
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_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 6176Wgo2abLS for ; Wed, 14 Jan 2015 07:51:32 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDE341A8ABF for ; Wed, 14 Jan 2015 07:51:31 -0800 (PST)
Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t0EFpU48012612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 14 Jan 2015 10:51:30 -0500
Received: from dhcp-2-127.brq.redhat.com (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t0EFpRIx022901 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 14 Jan 2015 10:51:29 -0500
Message-ID: <1421250687.2899.2.camel@redhat.com>
From: Nikos Mavrogiannopoulos 
To: Aaron Zauner 
Date: Wed, 14 Jan 2015 16:51:27 +0100
In-Reply-To: <54B68A97.3010007@azet.org>
References: <54B5501A.4070402@azet.org>  <54B58F5B.2010704@cs.tcd.ie> <54B6815A.7060102@azet.org> <54B68A97.3010007@azet.org>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
Archived-At: 
Cc: TLS Mailing List 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Jan 2015 15:51:34 -0000

On Wed, 2015-01-14 at 16:26 +0100, Aaron Zauner wrote:
> Hi *,
> 
> Aaron Zauner wrote:
> > 
> > Just as a suggestion, how about a document that does only include
> > forward-secret cipher-suites that are valid for TLS 1.3? That would
> > drastically remove the number of OCB ciphersuites that I would have to
> > add in case of TLS 1.2.
> > 
> 
> Going through the ChaCha20/Poly1305 ID, it suggest something very
> similar, only adding three ciphersuites:
> http://tools.ietf.org/id/draft-agl-tls-chacha20poly1305-04.txt (S. 6).

This is not the case in the latest draft. Defining only 3 ciphersuites
means that PSK will not take advantage of the OCB mode. Is there a
reason for that?

regards,
Nikos



From nobody Wed Jan 14 08:08:55 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 985AE1A8AE6 for ; Wed, 14 Jan 2015 08:08:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level: 
X-Spam-Status: No, score=-1.7 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_8BIT_HEADER=0.3, 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 rxpp0mmEzwRS for ; Wed, 14 Jan 2015 08:08:49 -0800 (PST)
Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7ABA1A8BB5 for ; Wed, 14 Jan 2015 08:08:48 -0800 (PST)
Received: by mail-la0-f48.google.com with SMTP id gf13so8902871lab.7 for ; Wed, 14 Jan 2015 08:08:47 -0800 (PST)
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 :content-transfer-encoding; bh=WFSyKqKGRrknhjMCrMuyieV+XXkyfUVgJyd6X/QItSo=; b=Tb6dh+vj8CJbOOsnSUnyc5xSe3bt2Fiw/VG7JqDgY7BH8HgWS4pb8kHWwitPm3nyd2 LHE6OgO5Yvo4arqhLrEG0lIHCNLOYaeGNvjGdDQyOnLNhDWjuiFt6n+XK68u5RKTzKYm iqtiJEXSj5CxbgpkiiTWZY7OufQ/dETamhvBKV4ZD8qWDpE0rwzBNe1Evzdf/nXF4fwx 82fYc029l0asmeYmkFo62+3Br0A3FsEvcEN4l0ZvwOHtcBVyGABkSkvy2TehK3CiFWEU PSxBh08uhlqrFHLo2lD/WdyW4/bSDRIWl/1GEvcNX/yzD5Tw0n7PLt3Fb+8LFbcPZYwZ Yw5A==
MIME-Version: 1.0
X-Received: by 10.112.56.142 with SMTP id a14mr4719589lbq.16.1421251727087; Wed, 14 Jan 2015 08:08:47 -0800 (PST)
Received: by 10.112.200.4 with HTTP; Wed, 14 Jan 2015 08:08:47 -0800 (PST)
Date: Wed, 14 Jan 2015 17:08:47 +0100
Message-ID: 
From: =?UTF-8?Q?Henrik_Grubbstr=C3=B6m?= 
To: "tls@ietf.org" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: [TLS] RFC4492bis - Clairify sections 2.1 and 2.2 with respect to RFC 5246 7.4.2.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Jan 2015 16:08:50 -0000

[https://github.com/tlswg/rfc4492bis/issues/3]

In TLS 1.2 the restrictions on what certificates are allowed in a
certificate chain were relaxed so the following text from sections 2.1
and 2.2 in the RFC4492bis draft should be clarified with respect to
TLS 1.2:

  2.1:
    In ECDHE_ECDSA, the server's certificate MUST contain an ECDSA-
    capable public key and be signed with ECDSA.

  2.2:
    The server certificate MUST be signed with RSA.

There's also similar text in section 5.3 Table 3.

--=20
Henrik Grubbstr=C3=B6m                                       grubba@grubba.=
org
Roxen Internet Software AB                              grubba@roxen.com


From nobody Wed Jan 14 08:11:15 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FCF51A8AE6 for ; Wed, 14 Jan 2015 08:11:11 -0800 (PST)
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 rwrUNNz5gg3e for ; Wed, 14 Jan 2015 08:11:06 -0800 (PST)
Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B0A31A8AAE for ; Wed, 14 Jan 2015 08:11:06 -0800 (PST)
Received: by mail-wg0-f53.google.com with SMTP id x13so9798521wgg.12 for ; Wed, 14 Jan 2015 08:11:05 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=lvu1dFAjHXsfXMEtJ1PMSXMZjvNE6ZSj8/oHLVVQaPQ=; b=bwP2+BuPJndvX16oiOjVSUZbwNLWogk6UyBP0Y9yn2eWqifXRAQMXQ8nJfQmhrQvoE bpwtr2aS8Qva6a6rqOQTPapeXad6DAikmyDiscRHLcnB6nIhQRvZHEXvjkiNmJESPR9K AvZIxuIZV0pj+yH25Spe4GSZjsaFIsBOEqdJTERI8rqmOo49AJUQMeTRCf/q6q9XKX1g QFjWunbxPXkauHeHVn6J5lPPgbXTCPWzZiaqpk8UVwwonGHn8zHD06x9WzJjB96EfNnd LH5f2ZRvv8BIpbWcXJkqxpD11xxqeSAGfW3EFIetYgahz8uxoL6s5oBwgWcktbY3X68T AIzA==
X-Gm-Message-State: ALoCoQlWeLzYi669AJiqFto3lgDA/xTme2VYYm8eHk+HB3/XFhPJdGpbDgg7j5goa47hVZb/+ET0
X-Received: by 10.180.208.79 with SMTP id mc15mr52662601wic.34.1421251864957;  Wed, 14 Jan 2015 08:11:04 -0800 (PST)
Received: from [10.60.20.30] ([193.170.94.190]) by mx.google.com with ESMTPSA id q7sm3937221wiv.8.2015.01.14.08.11.03 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 14 Jan 2015 08:11:03 -0800 (PST)
Message-ID: <54B69514.9000508@azet.org>
Date: Wed, 14 Jan 2015 17:11:00 +0100
From: Aaron Zauner 
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: Nikos Mavrogiannopoulos 
References: <54B5501A.4070402@azet.org>  <54B58F5B.2010704@cs.tcd.ie> <54B6815A.7060102@azet.org> <54B68A97.3010007@azet.org> <1421250687.2899.2.camel@redhat.com>
In-Reply-To: <1421250687.2899.2.camel@redhat.com>
X-Enigmail-Version: 1.2.3
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig59DEC2610B23D94D46D664DA"
Archived-At: 
Cc: TLS Mailing List 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Jan 2015 16:11:11 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig59DEC2610B23D94D46D664DA
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Nikos,

Nikos Mavrogiannopoulos wrote:
>=20
> This is not the case in the latest draft. Defining only 3 ciphersuites
> means that PSK will not take advantage of the OCB mode. Is there a
> reason for that?

No. If PSK is still going to be supported in TLS 1.3 then I'll have to
add that as well. This was the newest draft on ChaCha20/Poly1305 I could
find on the IETF website. Still not that bad in comparison to adding all
the cipher-suites that conforming with TLS 1.2 would mean.

Aaron


--------------enig59DEC2610B23D94D46D664DA
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUtpUVAAoJEOTbZJL9ubXVRWgQAKhtacJQY+Fi0RDDvYr1pOdh
pMW0PzwJTpsiVcWmzIxCvhK75wAEz3sf+wB/7sg58vjZSXzpVa1fh72sdmYa8SHN
Hps6r8qXmeLtCAwJlWfaEDEUK1Jhrqed5VJk2nI8BBmDcpvVzBEoEKsvCN2SQQVG
bJ/0DvseL9sngwrs5OptesQoVmo4/eLsvbYS52fN/uzIpA0taEKbIvdehbn78v6h
XRqSArqD79WV9a6+6A3xuRtfcp2Ny1bHh/fEjWeobxzbAqm13HK+Wutj3sjegEW3
E64nzfFclHvNuv1YNcrGfpJTKihiKdbr464BdySbc69xxESzuZ0hB7TWbgcNl5oL
0HhCyOjyM7rQBW7oTCnKKj3UeoRFXPfLi88o2HBr1YM/lg/Y/CMw+tzpgXQG0XzI
vtIfSzBCZqEdQklLfOoTHD6ZxB+ebbAPPB4unp/HZwiB3ostWbUo2ylXgV7D9eCD
P03CD5rvutLqWxdOfAz71cswlMO1xxix0Ku9h9STlP/n0/rXHrNWqqqMZ/3N4GJV
beXz+fyiFF5+D0OFT7sADONGQCobVcgwhXRsZq/ZMoW7jhwaVwg5RBvbsz+TEkon
lmgFRmwBh3B1uexTFw6Yqp48agsLhiUZaAriyudaNcpoSv0tORVIZwXRY72Mh1cr
bZTTQL0EnyGXa0iugKe8
=5Ovi
-----END PGP SIGNATURE-----

--------------enig59DEC2610B23D94D46D664DA--


From nobody Wed Jan 14 08:11:27 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 139CB1A8AF8 for ; Wed, 14 Jan 2015 08:11:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level: 
X-Spam-Status: No, score=-1.7 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_8BIT_HEADER=0.3, 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 ugtA9-gtPU0x for ; Wed, 14 Jan 2015 08:11:21 -0800 (PST)
Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0811B1A886C for ; Wed, 14 Jan 2015 08:11:21 -0800 (PST)
Received: by mail-lb0-f170.google.com with SMTP id 10so8743214lbg.1 for ; Wed, 14 Jan 2015 08:11:19 -0800 (PST)
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 :content-transfer-encoding; bh=wdRCT0VBuq2qnx/8F46um4wHQS1ESuD4k8LC3VBNFVg=; b=qxN0QIrY9zoogT6s2xGulx0CPX+RshKby4A0BGqTcISyIgd/l+36K1Tl9Wg67dHu5v HBYRCTFn4ZLLLlQVwXaZx98fY+faoVW8kfmo9L3oj7c3osvKQDWUvAC+J4ohw/cz1kKn Nv2/Y29DEwvneV4pVxm+0bTXsBhkVTUztVaadH331fFu7dSCJG1vHi3mJYVPsjF3jwv6 M/aJfwzYqaDAuNzQm663qSJcddeSZR3RiuhUix1WVcAbUigk3HdT8I49077uZu3nlzQ4 edyN9u9SOCYLEl4VhVtUkUmL+cjHJ6BsUA8wAj9oQJIshduXB1hDNI9POTBqIby3Nbau 7dbQ==
MIME-Version: 1.0
X-Received: by 10.152.23.38 with SMTP id j6mr4723413laf.81.1421251879445; Wed, 14 Jan 2015 08:11:19 -0800 (PST)
Received: by 10.112.200.4 with HTTP; Wed, 14 Jan 2015 08:11:19 -0800 (PST)
Date: Wed, 14 Jan 2015 17:11:19 +0100
Message-ID: 
From: =?UTF-8?Q?Henrik_Grubbstr=C3=B6m?= 
To: "tls@ietf.org" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: [TLS] RFC4492bis - Rename the "Supported Elliptic Curves" extension
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Jan 2015 16:11:23 -0000

[https://github.com/tlswg/rfc4492bis/issues/4]

This extension has been renamed "Supported Groups" in the drafts of
TLS 1.3 and FFDHE.

Having different names for the same extension in different concurrent
RFCs should be avoided.

Section 5.1.1 and other places should be updated accordingly.

--=20
Henrik Grubbstr=C3=B6m                                       grubba@grubba.=
org
Roxen Internet Software AB                              grubba@roxen.com


From nobody Wed Jan 14 08:32:55 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC7D71A8AF8 for ; Wed, 14 Jan 2015 08:32:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.677
X-Spam-Level: 
X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 mqjG1hUUb0k4 for ; Wed, 14 Jan 2015 08:32:51 -0800 (PST)
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 DF8DB1A8F41 for ; Wed, 14 Jan 2015 08:32:50 -0800 (PST)
Received: by mail-wi0-f181.google.com with SMTP id hi2so12090521wib.2 for ; Wed, 14 Jan 2015 08:32:49 -0800 (PST)
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:from:date :message-id:subject:to:cc:content-type; bh=jF9Vy7UvmYA9ieV+nd9g08lHYE/EFjBUL0wat2l5eA4=; b=FjnpsB/hYtTdlvqb/e1RiEUSHFEEDMqv9aQELm4RrcOzfiJjTJ+mBWT7NjOU/fWxU1 yic/9zfjK5zBauaOuxXk96GmPnGMxR48Hr7fVqgzPVLG9MU5vA/Oz9QKryhcyeJ6AhmS gZ1oxGx8tMNo73soQuwJUd6/CzM+8nHNGGJP529EXzQB+fNqFYlCbQ8BS9+ImgiP25YU 3/Wh78CPTEf8ndRR/MSypRfkJWD2sOva+C8AyxKD3q7kT8pskfSlfO5OWGL831pjKM+i NGuXh7Uq/IFYiq+aol0ZRrkRm/0aypY7wjpMb3KhQ2AHNim+BLe5N5BaCDwDfdDbiw0t 2t5w==
X-Gm-Message-State: ALoCoQmM8PJzSQBU7DW1d47fXZSKah24F3v0ZD34BHcIsWunmEK3OUkK/g4VrFioLS0kS93yQHAw
X-Received: by 10.180.91.193 with SMTP id cg1mr52092384wib.26.1421253169171; Wed, 14 Jan 2015 08:32:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.27.142.215 with HTTP; Wed, 14 Jan 2015 08:32:08 -0800 (PST)
In-Reply-To: 
References: 
From: Eric Rescorla 
Date: Wed, 14 Jan 2015 08:32:08 -0800
Message-ID: 
To: =?UTF-8?Q?Henrik_Grubbstr=C3=B6m?= 
Content-Type: multipart/alternative; boundary=f46d041c408e48eb95050c9f4ad8
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] RFC4492bis - Rename the "Supported Elliptic Curves" extension
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Jan 2015 16:32:53 -0000

--f46d041c408e48eb95050c9f4ad8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

This seems like a good idea to me. Alternatively, we could have a separate
draft that *just* did the rename and then just update 4492bis as we already
have TLS 1.3.

-Ekr


On Wed, Jan 14, 2015 at 8:11 AM, Henrik Grubbstr=C3=B6m  =
wrote:

> [https://github.com/tlswg/rfc4492bis/issues/4]
>
> This extension has been renamed "Supported Groups" in the drafts of
> TLS 1.3 and FFDHE.
>
> Having different names for the same extension in different concurrent
> RFCs should be avoided.
>
> Section 5.1.1 and other places should be updated accordingly.
>
> --
> Henrik Grubbstr=C3=B6m                                       grubba@grubb=
a.org
> Roxen Internet Software AB                              grubba@roxen.com
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--f46d041c408e48eb95050c9f4ad8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


This seems like a good idea to me. Alternatively, we could=
 have a separate
draft that *just* did the rename and then just update =
4492bis as we already
have TLS 1.3.

-Ekr=



On Wed, Jan 14, 2015 at 8:11 AM, Henrik Grubbstr=C3=B6m <grubba@g=
mail.com> wrote:
[https:/=
/github.com/tlswg/rfc4492bis/issues/4]



This extension has been renamed "Supported Groups" in the drafts =
of

TLS 1.3 and FFDHE.



Having different names for the same extension in different concurrent

RFCs should be avoided.



Section 5.1.1 and other places should be updated accordingly.



--

Henrik Grubbstr=C3=B6m=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0grubba@grubba.org

Roxen Internet Software AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 grubba@roxen.com



_______________________________________________

TLS mailing list

TLS@ietf.org

htt=
ps://www.ietf.org/mailman/listinfo/tls





--f46d041c408e48eb95050c9f4ad8--


From nobody Wed Jan 14 08:44:04 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C37961A904D for ; Wed, 14 Jan 2015 08:44:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level: 
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, 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 f4BrCS7wyHgj for ; Wed, 14 Jan 2015 08:43:59 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6725B1A8AF8 for ; Wed, 14 Jan 2015 08:43:59 -0800 (PST)
Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t0EGhvTf013491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 14 Jan 2015 11:43:57 -0500
Received: from dhcp-2-127.brq.redhat.com (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t0EGhtaA031438 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 14 Jan 2015 11:43:56 -0500
Message-ID: <1421253834.21577.7.camel@redhat.com>
From: Nikos Mavrogiannopoulos 
To: Aaron Zauner 
Date: Wed, 14 Jan 2015 17:43:54 +0100
In-Reply-To: <54B69514.9000508@azet.org>
References: <54B5501A.4070402@azet.org>  <54B58F5B.2010704@cs.tcd.ie> <54B6815A.7060102@azet.org> <54B68A97.3010007@azet.org> <1421250687.2899.2.camel@redhat.com> <54B69514.9000508@azet.org>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Archived-At: 
Cc: TLS Mailing List 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Jan 2015 16:44:02 -0000

On Wed, 2015-01-14 at 17:11 +0100, Aaron Zauner wrote:

> > This is not the case in the latest draft. Defining only 3 ciphersuites
> > means that PSK will not take advantage of the OCB mode. Is there a
> > reason for that?
> No. If PSK is still going to be supported in TLS 1.3 then I'll have to
> add that as well. This was the newest draft on ChaCha20/Poly1305 I could
> find on the IETF website. Still not that bad in comparison to adding all
> the cipher-suites that conforming with TLS 1.2 would mean.

 Hi,
I don't see why OCB has to be tied to TLS 1.3. The last time such move
was made with having GCM/AEAD restricted to TLS 1.2, it proved quite
wrong (in the sense that not doing it would have avoided the majority of
the problems we saw the last years). TLS 1.3 is a draft document to be
deployed in 2-3 years after published (in the best case scenario). There
is no reason the existing implementations cannot take advantage of OCB,
if ever defined. 

regards,
Nikos



From nobody Wed Jan 14 08:52:10 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC9D1A90D4 for ; Wed, 14 Jan 2015 08:52:07 -0800 (PST)
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 VcUl2xbpvfOT for ; Wed, 14 Jan 2015 08:52:02 -0800 (PST)
Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 270051A90E9 for ; Wed, 14 Jan 2015 08:52:02 -0800 (PST)
Received: by mail-wi0-f177.google.com with SMTP id l15so12254612wiw.4 for ; Wed, 14 Jan 2015 08:52:00 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=KBrwMS/HyvpRMI2Xm6tVOk0h+0zCMZSRiNexK53NpRE=; b=e712JA/Pf07nhz7GcgXNRDfys6U/fORrEOY0CbksnJ9eaT9kCIgXw0OBEZibNLj4OD tTLyKKdRYyQxfgDp3wb1l6xD6Mh0jHlt7dByvNbLnhleRzzAdmhO0lQ7rBlraA6RXYdL BL1/Yh9Y796DnkC8nIk5n28OLjcOm2c8FexX1KwHHcZjPG/O3qNsKiatU1Y5P+StZOwp b8u1zxPK4TaOHnFcXJoHRaGy3dfGjgFHDfcZU/E1GgJlx+elzYnZsQ9AIanqPGtxmVmq sI8bsKND23rYxJSz4jDUYJTC1WAa2seJtrrEEggQW9nLU6GNO1QhUvjdOKVrzojM3gPM yDEg==
X-Gm-Message-State: ALoCoQl6gz8bkmutetmKAY2yug6XHeg3ue7HCE5Cs+aJkNlW+zFCNFq4SDlt3tx1DRS7mTzwtPkE
X-Received: by 10.180.101.131 with SMTP id fg3mr44153590wib.36.1421254320649;  Wed, 14 Jan 2015 08:52:00 -0800 (PST)
Received: from [10.60.20.30] ([193.170.94.190]) by mx.google.com with ESMTPSA id q10sm30784096wjx.34.2015.01.14.08.51.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 14 Jan 2015 08:51:59 -0800 (PST)
Message-ID: <54B69EAB.4060904@azet.org>
Date: Wed, 14 Jan 2015 17:51:55 +0100
From: Aaron Zauner 
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: Nikos Mavrogiannopoulos 
References: <54B5501A.4070402@azet.org>  <54B58F5B.2010704@cs.tcd.ie> <54B6815A.7060102@azet.org> <54B68A97.3010007@azet.org> <1421250687.2899.2.camel@redhat.com> <54B69514.9000508@azet.org> <1421253834.21577.7.camel@redhat.com>
In-Reply-To: <1421253834.21577.7.camel@redhat.com>
X-Enigmail-Version: 1.2.3
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig1C25391296086EEAD1A4CD1A"
Archived-At: 
Cc: TLS Mailing List 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Jan 2015 16:52:07 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig1C25391296086EEAD1A4CD1A
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



Nikos Mavrogiannopoulos wrote:
> I don't see why OCB has to be tied to TLS 1.3. The last time such move
> was made with having GCM/AEAD restricted to TLS 1.2, it proved quite
> wrong (in the sense that not doing it would have avoided the majority o=
f
> the problems we saw the last years). TLS 1.3 is a draft document to be
> deployed in 2-3 years after published (in the best case scenario). Ther=
e
> is no reason the existing implementations cannot take advantage of OCB,=

> if ever defined.=20
>=20
I'm trying to find a compromise between having to pollute the TLS
ciphersuite registry with tons of ciphersuites (as has been pointed out
to me is not desirable) and OCB being deployable in the real world for
implementors that would like to use it (and are allowed to w.r.t. it's
licensing).

If the majority is for a) dropping the idea b) having OCB in >=3D TLS 1.2=
,
and thus tons of ciphersuites or c) for TLS 1.3 applicable ciphersuites
only - I'll draft it that way.

Having this discussion beforehand will also save time on editing the
draft all the time, in case on is to be written.

I'm open for any suggestions and some consensus on the topic would be nic=
e.

Aaron


--------------enig1C25391296086EEAD1A4CD1A
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUtp6sAAoJEOTbZJL9ubXVKTYQAJg6bhK9lqktMjosph5Cf8B9
DqGJSBEeVr8ZUAtIrMzXz+nnEfRRMwEKBZqFVhO9XeO+e0/irPzQBT7T0GIrjwSC
7Nuwb9g02xb7wJDG1W2m6EuQeIhKKCjlMHit1lg/WqWmm+BGBbYmLlr+NVW2kJuQ
xVR0nnLs0febCw/DaaLePdkXmYWc9G/4sBhvlXr1YShqs/16hAE4p/LkesCxAK/3
FE0lGk+WICq8dkoI2aNKk1XDUa6LXjvtDy3S2TlRhBUYNV6ifCak1qjyqylGKxJa
kJe4mzwjPEJmiy3RwZ1FioXP8D95IH0ok6PUf+2WipvnFE5DGOt+37x8QvpFYyoP
M2oBMRJL7t4RNE53HFSVMS/V54a0Vsh++lmFnoWPQdyGJEU6Nmcoa3nE3KGW3L+B
U/ALjBopnCEegZQ/zYdWmsbzqcyoA6xeODyOiMhawc6YcsIUz1rAm4CgArR2fe8s
QlWum7XA2yEWCYUju3l8EszTsS48PLs3TAmKTTKitEtiTWMKD17e5qKhXk+l/Tqg
7qMHoSP0z0Tug5UNs/A48FX51UJA/3LlF6rWUzO/EKmPo1qsQHoVyi4JNpEuLhzU
8uru6orWb7RE0D+0e/6lY9ngEQVBLbFpBVPYWVOwz9Nj7OReOf5bV4dZJ82EBqMQ
I2mapCy3AJ2W3jMUZ0pK
=1biD
-----END PGP SIGNATURE-----

--------------enig1C25391296086EEAD1A4CD1A--


From nobody Wed Jan 14 09:03:12 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A27041A90E3 for ; Wed, 14 Jan 2015 09:03:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 tfS7Eaa8GUi2 for ; Wed, 14 Jan 2015 09:03:03 -0800 (PST)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60C061A90D4 for ; Wed, 14 Jan 2015 09:02:58 -0800 (PST)
Received: by mail-wg0-f44.google.com with SMTP id y19so10116927wgg.3 for ; Wed, 14 Jan 2015 09:02:57 -0800 (PST)
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:from:date :message-id:subject:to:cc:content-type; bh=Vmop082sFdAezLuYrTAITQoVMDvaA4EQBKeymUUCGkE=; b=A/l33rEeVtHHkgAhDSxFCledkG1Aa2JPzphOeT/FGqYxYSwW0HexoHnj01gjPU+f41 fFWocCFuYxXhzZG1AlTdTmnKQCXEnu3g7663LFVF1ZvSAECT6yfPeVr6Kl8Gb0MSJtiW K/shsKDJXPtR0beS9HkmPsHfBwhJxnso6MBVMStebym/8GsoZRxYyDEBe7Y1ndv2q3Zb JYsOc2zIe6iPXTCxY0E1HRPR3BT13/t4N1HUIlER6JpadHA+7tvC4HdPJQ/6gNuB22Ct dnKJZ7FYZvSR4WXCkdaYEixOls7QuJma+WwSSmYucU/EVGnOrknQejsrW81hvGaWvOcg 6F3w==
X-Gm-Message-State: ALoCoQldZiar6awnNGLJ+4+fOyg5lriG1NGYbjIKagxkHC7xswukNxkUUg9Z9J8KaVYmV8K2tsM/
X-Received: by 10.180.207.66 with SMTP id lu2mr10489839wic.13.1421254977042; Wed, 14 Jan 2015 09:02:57 -0800 (PST)
MIME-Version: 1.0
Received: by 10.27.142.215 with HTTP; Wed, 14 Jan 2015 09:02:16 -0800 (PST)
In-Reply-To: <54B6815A.7060102@azet.org>
References: <54B5501A.4070402@azet.org>  <54B58F5B.2010704@cs.tcd.ie> <54B6815A.7060102@azet.org>
From: Eric Rescorla 
Date: Wed, 14 Jan 2015 09:02:16 -0800
Message-ID: 
To: Aaron Zauner 
Content-Type: multipart/alternative; boundary=001a11c3d8ee0ae1d8050c9fb65e
Archived-At: 
Cc: TLS Mailing List 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Jan 2015 17:03:09 -0000

--001a11c3d8ee0ae1d8050c9fb65e
Content-Type: text/plain; charset=UTF-8

On Wed, Jan 14, 2015 at 6:46 AM, Aaron Zauner  wrote:

> Hi Stephen,
>
> Stephen Farrell wrote:
> > 
> >
> > On 13/01/15 18:25, Paul Lambert wrote:
> >> This should not stop inclusion of OCB as an optional mode in TLS,
> >
> > I don't get why additional options are at all attractive. In
> > fact, I think they're ugly.
> >
> > TLS has about 327 ciphersuites. That's just stupid. (I'm not
> > saying any person is stupid there btw, but we have gotten
> > ourselves into a stupid place.)
>
> Yup. Having different naming schemes for different
> libraries/implementations beyond that makes it almost impossible to give
> good recommendations to end-users (admins, management) as we've noticed
> in the bettercrypto.org project.
>
> >
> > If we have a really better thing, they why not make it MTI? If
> > we do not have something sufficiently better then I'd argue to
> > exclude as much as possible, and certainly against adding
> > anything that is just nice to have.
> >
> > I'd even like to make almost all current ciphersuites a MUST NOT
> > (or start a new registry) for TLS1.3 and to not add any new
> > ciphersuites at all, and just stick with two MTI ciphersuites
> > that are as genetically different as possible and cover as many
> > implementations (h/w AES or not) as possible.
> >
> > So my suggestion is to reduce the ciphersuite field to be
> > 2 bits wide in TLS 1.3, with 00 being default, 01 backup, 02
> > being "proprietary" and 03 reserved. If either 00 or 01 needs
> > to be changed then I'd say rev the TLS version. (I don't care
> > if we did s/default/has-AES-hw/ and s/backup/just-sw-crypto/
> > that'd also be fine.)
> >
> > And yes, I realise that's not likely to get traction, but
> > turning 327 into 427 is even dumber when reality shows that
> > only a few of 'em are used or needed.
>
> Just as a suggestion, how about a document that does only include
> forward-secret cipher-suites that are valid for TLS 1.3? That would
> drastically remove the number of OCB ciphersuites that I would have to
> add in case of TLS 1.2.
>
> One issue though: as far as I can tell (from the recent RWC presentation
> by EKR) there are still going to be three block ciphers in TLS 1.3: AES,
> CAMELLIA, ARIA.


To be clear, this is just a statement of fact. I.e., TLS 1.3 can only be
used
with AEAD and these are the AEAD ciphers that are presently defined.
The WG could adopt more AEAD ciphers or conversely, remove ones that
currently exist.

Speaking only for myself, it seems like AES-GCM is the leading candidate
for the MTI for TLS 1.3, based on the fact that it's the most common
AEAD algorithm with 1.2.

-Ekr

--001a11c3d8ee0ae1d8050c9fb65e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Wed, Jan 14, 2015 at 6:46 AM, Aaron Zauner <azet@azet.org> wrote:
Hi Stephen,



Stephen Farrell wrote:

> <no-hats>

>

> On 13/01/15 18:25, Paul Lambert wrote:

>> This should not stop inclusion of OCB as an optional mode in TLS,<=
br>
>

> I don't get why additional options are at all attractive. In

> fact, I think they're ugly.

>

> TLS has about 327 ciphersuites. That's just stupid. (I'm not
> saying any person is stupid there btw, but we have gotten

> ourselves into a stupid place.)



Yup. Having different naming schemes for different

libraries/implementations beyond that makes it almost impossible to give
good recommendations to end-users (admins, management) as we've noticed=


in the bettercrypto.o=
rg project.



>

> If we have a really better thing, they why not make it MTI? If

> we do not have something sufficiently better then I'd argue to

> exclude as much as possible, and certainly against adding

> anything that is just nice to have.

>

> I'd even like to make almost all current ciphersuites a MUST NOT
> (or start a new registry) for TLS1.3 and to not add any new

> ciphersuites at all, and just stick with two MTI ciphersuites

> that are as genetically different as possible and cover as many

> implementations (h/w AES or not) as possible.

>

> So my suggestion is to reduce the ciphersuite field to be

> 2 bits wide in TLS 1.3, with 00 being default, 01 backup, 02

> being "proprietary" and 03 reserved. If either 00 or 01 need=
s

> to be changed then I'd say rev the TLS version. (I don't care<=
br>
> if we did s/default/has-AES-hw/ and s/backup/just-sw-crypto/

> that'd also be fine.)

>

> And yes, I realise that's not likely to get traction, but

> turning 327 into 427 is even dumber when reality shows that

> only a few of 'em are used or needed.



Just as a suggestion, how about a document that does only include
forward-secret cipher-suites that are valid for TLS 1.3? That would

drastically remove the number of OCB ciphersuites that I would have to

add in case of TLS 1.2.



One issue though: as far as I can tell (from the recent RWC presentation
by EKR) there are still going to be three block ciphers in TLS 1.3: AES,
CAMELLIA, ARIA.

To be clear, this is just a=
 statement of fact. I.e., TLS 1.3 can only be used
with AEAD and =
these are the AEAD ciphers that are presently defined.
The WG cou=
ld adopt more AEAD ciphers or conversely, remove ones that
curren=
tly exist.

Speaking only for myself, it seems like=
 AES-GCM is the leading candidate
for the MTI for TLS 1.3, based =
on the fact that it's the most common
AEAD algorithm with 1.2=
.

-Ekr



--001a11c3d8ee0ae1d8050c9fb65e--


From nobody Wed Jan 14 09:19:57 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 535261A9104 for ; Wed, 14 Jan 2015 09:19:54 -0800 (PST)
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 Pwjh84LeqVop for ; Wed, 14 Jan 2015 09:19:52 -0800 (PST)
Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 742CF1A90F0 for ; Wed, 14 Jan 2015 09:19:52 -0800 (PST)
Received: by mail-ob0-f179.google.com with SMTP id nt9so9095700obb.10 for ; Wed, 14 Jan 2015 09:19:51 -0800 (PST)
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=21eEiauoitgRVYX14WmnNlaWrROgeEPyrir+6cZ+1aw=; b=xfuZDCo4UVOIL0VL7XEBFeAwFD3GI6bH2kz8n0qi6PayNgCcFDI3XZZbxb63SOjK6a yLhjBMdQ5If+uSe3PqWILsUprj6xVfWgIkQh1L1rIiPuTK+pt24w3fmY3V3BP4859Ve+ rAfsFnw3Yawurs/Uxgx1qtIDkGa+SSMDrOHuL7977oztqjyQAEPXTfWmzs0oxBU8QtyB mw4+tQhRy8U0cmHgqonI2N9d+B8zFgEFbXzvfRIAYSKw5H1vawtJBrMeL9Q4gxzVKu+n lnADPX53Mq3sMFFiQ1ne1TVSTlEmFSWyGpOY+RzrtJFnUv0ug+dsS9ujs0LeqkXQDTiV ZCTA==
MIME-Version: 1.0
X-Received: by 10.202.79.149 with SMTP id d143mr3009006oib.16.1421255991785; Wed, 14 Jan 2015 09:19:51 -0800 (PST)
Received: by 10.202.226.136 with HTTP; Wed, 14 Jan 2015 09:19:51 -0800 (PST)
In-Reply-To: <54B65AF0.1080503@metaparadigm.com>
References: <9A043F3CF02CD34C8E74AC1594475C73AAF525B9@uxcn10-tdc05.UoA.auckland.ac.nz>  <54B54A5F.7020401@polarssl.org>      <54B65AF0.1080503@metaparadigm.com>
Date: Wed, 14 Jan 2015 09:19:51 -0800
Message-ID: 
From: Martin Thomson 
To: Michael Clark 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: =?UTF-8?Q?Manuel_P=C3=A9gouri=C3=A9=2DGonnard?= , "" 
Subject: Re: [TLS] AAED ciphers: AES-GCM vs AES-EAX/AES-CCM: a meta-analysis
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Jan 2015 17:19:54 -0000

On 14 January 2015 at 04:02, Michael Clark  wrote:
> Interesting. Should draft-pironti-tls-length-hiding-01 be added to
> Related Active Documents (not working group documents) section

That's an automatically generated list.  I suspect the reason that it
doesn't appear is that it is presently expired.


From nobody Wed Jan 14 09:23:31 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17DE41A910A for ; Wed, 14 Jan 2015 09:23:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.105
X-Spam-Level: 
X-Spam-Status: No, score=-0.105 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, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, 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 sp6JqvJppbaf for ; Wed, 14 Jan 2015 09:23:28 -0800 (PST)
Received: from smtp-01-out.s.azet.sk (smtp-09-out.s.azet.sk [91.235.53.34]) by ietfa.amsl.com (Postfix) with ESMTP id B9B461A90F0 for ; Wed, 14 Jan 2015 09:23:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=azet.sk; s=azet; t=1421256207; bh=QDrh5hoqe8DPDFYdmlkeNKTNEo76vVffYCmw8y26738=; h=Date:From:To:Subject:References:In-Reply-To:From; b=Se5SEwSR+FVFy6h6Uwll47T8w4Y2qZNJqaPl0iEYqfx7/KD5XzpGNSU0VHAknBA7v 1+GAcG68sJefzrm0bVtPquWeMXlk+op0vaXOyYFV1vl9qOwFbA9dBSXALRpYo7H1dC FOLaBpGFT+qYJj6i+z0Kcce5go4c7tSEb7aAQEPM=
X-Virus-Scanned: by AntiSpam at azet.sk
Received: from [0.0.0.0] (euserv4-10.rana.at [81.7.8.101]) (Authenticated sender: fedor.brunner@azet.sk) by smtp.azet.sk (Postfix) with ESMTPA id 0A32286 for ; Wed, 14 Jan 2015 18:23:23 +0100 (CET)
X-SenderID: Sendmail Sender-ID Filter v1.0.0 smtp.azet.sk 0A32286
Authentication-Results: smtp.azet.sk; sender-id=fail (NotPermitted) header.from=fedor.brunner@azet.sk; auth=pass (PLAIN); spf=fail (NotPermitted) smtp.mfrom=fedor.brunner@azet.sk
Message-ID: <54B6A607.7080009@azet.sk>
Date: Wed, 14 Jan 2015 18:23:19 +0100
From: Fedor Brunner 
MIME-Version: 1.0
To: tls@ietf.org
References: <525BADBD.8020007@secunet.com>	<54B67A19.9010507@redhat.com> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [TLS] Using RSA PSS in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Jan 2015 17:23:31 -0000

Better solution would be to use RSA-KEM (see basic description in RFC
5990) instead of PKCS#1v1.5 encryption.

The RSA-KEM is secure in the random oracle model (modelling the KDF as a
random oracle), with very good security guarantees:

Johan Hastad and Mats Naslund. The security of all RSA and discrete log
bits.
http://www.nada.kth.se/~johanh/hnrsaacm.pdf

Victor Shoup. A Proposal for an ISO Standard for Public Key Encryption.
https://eprint.iacr.org/2001/112.pdf

On 14.01.2015 15:32, CodesInChaos wrote:
> On Wed, Jan 14, 2015 at 3:15 PM, Florian Weimer  wrote:
>> What about changing PFS for the RSA ciphersuites so that they continue to
>> use RSA encryption, and not rely on an RSA signature for server
>> authentication?
> 
> Switching from PKCS#1v1.5 encryption to OAEP is just as tricky as
> switching from PKCS#1v1.5 signing to PSS signatures.
> 
> I consider the risk of PKCS#1v1.5 encryption far bigger than the risk
> of PKCS#1v1.5 signatures.
> I'm not aware of any attack against  PKCS#1v1.5 signatures, they
> merely lack a security proof.
> PKCS#1v1.5 encryption is problematic since detectable decryption
> failures can act as an oracle. Implementations need to be really
> careful to avoid these.
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 


From nobody Wed Jan 14 09:33:43 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD7491A9127 for ; Wed, 14 Jan 2015 09:33:41 -0800 (PST)
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 l1ghMF4zwRk0 for ; Wed, 14 Jan 2015 09:33:40 -0800 (PST)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id E80991A90E9 for ; Wed, 14 Jan 2015 09:33:39 -0800 (PST)
Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id C6BC1F984 for ; Wed, 14 Jan 2015 12:33:37 -0500 (EST)
Received: by fifthhorseman.net (Postfix, from userid 1000) id A99A020152; Wed, 14 Jan 2015 12:33:42 -0500 (EST)
From: Daniel Kahn Gillmor 
To: tls@ietf.org
In-Reply-To: 
References:  
User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu)
Date: Wed, 14 Jan 2015 12:33:42 -0500
Message-ID: <871tmx5ksp.fsf@alice.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [TLS] RFC4492bis - Rename the "Supported Elliptic Curves" extension
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Jan 2015 17:33:41 -0000

On Wed 2015-01-14 11:32:08 -0500, Eric Rescorla wrote:
> This seems like a good idea to me. Alternatively, we could have a separate
> draft that *just* did the rename and then just update 4492bis as we already
> have TLS 1.3.

Do folks think that the separate draft to do the extension rename is
useful?  It seems a bit process-heavy to me, but i'm not an IETF process
expert either.

       --dkg


From nobody Wed Jan 14 09:36:42 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D14821A1A86 for ; Wed, 14 Jan 2015 09:36:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 nyYfQk52O5JT for ; Wed, 14 Jan 2015 09:36:39 -0800 (PST)
Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E3BA1A90E9 for ; Wed, 14 Jan 2015 09:36:38 -0800 (PST)
Received: by mail-wg0-f52.google.com with SMTP id x12so10271890wgg.11 for ; Wed, 14 Jan 2015 09:36:37 -0800 (PST)
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:from:date :message-id:subject:to:cc:content-type; bh=Qbmnmjqzu9saz+bdPBwVXcJTbdylZy+sTPRho6+MKzI=; b=FqmkjgJFZhDwDcJ17fx7RqRwqgOlIxoDFhECceF34tCNOH7CckccQxw96Fz0LCYBJX y7IaFfScksSXYowPrD+a3N4rl3B6/jwYkQkMROvU2XmvnMoeLAkS1XQAM3IV78bYKvUl 63m7nwEj/VwrWwQe3PB6vOctd5YT1henDlMqkXpG6K4oFTYwzZQLfbkAu2FyNUazccgV lPAOY6CNqvKDAxA8FymK8h2UjhHkvM3ctf4/6uh6njIzU8/5eQ4TzMBD5cWFyDmWy8CU va+nBxHpQoQihfpkXaAJRA2OQHqdB1455VPnaz/o0s5LpSHd9AHWHIZTQexTIzs4hbU9 Puxg==
X-Gm-Message-State: ALoCoQkgJP+2BOTo44+7FH+fd3OfWM4SDkGVS9vN5ReYzaWFN0Jt4nCnnOLzzQHX2Tu4GPpVvSlx
X-Received: by 10.180.72.177 with SMTP id e17mr10649689wiv.42.1421256997218; Wed, 14 Jan 2015 09:36:37 -0800 (PST)
MIME-Version: 1.0
Received: by 10.27.142.215 with HTTP; Wed, 14 Jan 2015 09:35:56 -0800 (PST)
In-Reply-To: <871tmx5ksp.fsf@alice.fifthhorseman.net>
References:   <871tmx5ksp.fsf@alice.fifthhorseman.net>
From: Eric Rescorla 
Date: Wed, 14 Jan 2015 09:35:56 -0800
Message-ID: 
To: Daniel Kahn Gillmor 
Content-Type: multipart/alternative; boundary=f46d043c7c16746042050ca02e9d
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] RFC4492bis - Rename the "Supported Elliptic Curves" extension
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Jan 2015 17:36:41 -0000

--f46d043c7c16746042050ca02e9d
Content-Type: text/plain; charset=UTF-8

On Wed, Jan 14, 2015 at 9:33 AM, Daniel Kahn Gillmor 
wrote:

> On Wed 2015-01-14 11:32:08 -0500, Eric Rescorla wrote:
> > This seems like a good idea to me. Alternatively, we could have a
> separate
> > draft that *just* did the rename and then just update 4492bis as we
> already
> > have TLS 1.3.
>
> Do folks think that the separate draft to do the extension rename is
> useful?  It seems a bit process-heavy to me, but i'm not an IETF process
> expert either.


I don't think it's necessary. Just wanted to suggest it if people thought it
was easier for some reason.

-Ekr


>
>        --dkg
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--f46d043c7c16746042050ca02e9d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



=
On Wed, Jan 14, 2015 at 9:33 AM, Daniel Kahn Gillmor <=
dkg@fifthhorsema=
n.net> wrote:
On Wed 2015-01-14 11:32:08 -0500, Eric Rescorla wrote:

> This seems like a good idea to me. Alternatively, we could have a sepa=
rate

> draft that *just* did the rename and then just update 4492bis as we al=
ready

> have TLS 1.3.



Do folks think that the separate draft to do the extension rename is=


useful?=C2=A0 It seems a bit process-heavy to me, but i'm not an IETF p=
rocess

expert either.

I don't think it's n=
ecessary. Just wanted to suggest it if people thought it
was easi=
er for some reason.

-Ekr
=C2=A0
=


=C2=A0 =C2=A0 =C2=A0 =C2=A0--dkg




_______________________________________________

TLS mailing list

TLS@ietf.org

htt=
ps://www.ietf.org/mailman/listinfo/tls





--f46d043c7c16746042050ca02e9d--


From nobody Wed Jan 14 11:45:04 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65F691AD074 for ; Wed, 14 Jan 2015 11:45:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level: 
X-Spam-Status: No, score=-1.699 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_8BIT_HEADER=0.3, 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 pVfWi0SEepzr for ; Wed, 14 Jan 2015 11:45:00 -0800 (PST)
Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4B771AD06F for ; Wed, 14 Jan 2015 11:44:53 -0800 (PST)
Received: by mail-wg0-f48.google.com with SMTP id l2so10931921wgh.7 for ; Wed, 14 Jan 2015 11:44:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:mime-version:to:from:subject:date:in-reply-to:references :content-type; bh=hWsICUHP4HSUqmiUK9vr3R7schRaNJyJHDF3n5szasA=; b=A/8l6RcYJHlZEJn/lpzCSqvjWwB4IOl8M9X7Tefginuu4+up3P9dZRdaFHCZEyk2kc IJRhvgVeZFSHwkK7umMujprFLHvbwhDw1Q8KYU9sTvboQXgQP+7jOe3zhU9WiITOYhdM L4iHhGOk5kK5j3GpnJroYOtQF4yUZ/LwM9oBo2gA33GFjx6QS55Eg4t3VIVCYMzM8EOG DYSmU09Yb1H1aMMA0WS0OXZtcwB5tPYaWg04iXkZ5WBI+coAgAfY6yUwQcVDnA8warIm fxVhW6bpyrFL+Qef8paATdd+pLmdIius9Kod6BCJy7UJpVN53Xt5shC+7IhxJevAGfYn 8d2Q==
X-Received: by 10.180.7.198 with SMTP id l6mr11919845wia.26.1421264692705; Wed, 14 Jan 2015 11:44:52 -0800 (PST)
Received: from [192.168.1.16] ([46.120.13.132]) by mx.google.com with ESMTPSA id et4sm31364335wjd.15.2015.01.14.11.44.51 (version=SSLv3 cipher=RC4-SHA bits=128/128); Wed, 14 Jan 2015 11:44:52 -0800 (PST)
Message-ID: <54b6c734.e40cc30a.52a1.02ef@mx.google.com>
MIME-Version: 1.0
To: =?utf-8?Q?Henrik_Grubbstr=C3=B6m?= ,  "tls@ietf.org" 
From: Yoav Nir 
Date: Wed, 14 Jan 2015 21:44:52 +0200
In-Reply-To: 
References: 
Content-Type: multipart/alternative; boundary="_DC50C1DA-5E05-437D-8602-097BE4667659_"
Archived-At: 
Subject: Re: [TLS] RFC4492bis - Rename the "Supported Elliptic Curves" extension
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Jan 2015 19:45:02 -0000

--_DC50C1DA-5E05-437D-8602-097BE4667659_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"

I'm weakly opposed to renaming it. The name exists in codebases, protocol a=
nalyzers, books and web articles. I get that now we're adding non-EC groups=
, but renaming it seems like a gratuitous change to me with a non-zero cost=
.

Yoav=20

-----Original Message-----
From: "Henrik Grubbstr=C3=B6m" 
Sent: =E2=80=8E1/=E2=80=8E14/=E2=80=8E2015 18:12
To: "tls@ietf.org" 
Subject: [TLS] RFC4492bis - Rename the "Supported Elliptic Curves" extensio=
n

[https://github.com/tlswg/rfc4492bis/issues/4]=0A=
=0A=
This extension has been renamed "Supported Groups" in the drafts of=0A=
TLS 1.3 and FFDHE.=0A=
=0A=
Having different names for the same extension in different concurrent=0A=
RFCs should be avoided.=0A=
=0A=
Section 5.1.1 and other places should be updated accordingly.=0A=
=0A=
-- =0A=
Henrik Grubbstr=C3=B6m                                       grubba@grubba.=
org=0A=
Roxen Internet Software AB                              grubba@roxen.com=0A=
=0A=
_______________________________________________=0A=
TLS mailing list=0A=
TLS@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/tls=0A=

--_DC50C1DA-5E05-437D-8602-097BE4667659_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="utf-8"


I'm weakly opposed to renaming it. The name exists in cod=
ebases, protocol analyzers, books and web articles. I get that now we're ad=
ding non-EC groups, but renaming it seems like a gratuitous change to me wi=
th a non-zero cost.

Yoav 
=
From: Henrik Grubbstr=C3=B6mSent: =E2=80=8E1/=E2=80=8E14/=E2=80=8E2015 18:12
To: tls@ietf.org
=
Subject: [TLS] RFC4492bis - Rename the "Supported Elliptic Curves" extension<=
/span>

[https://github.com/tlswg/rfc4492bis/issues/4]

T=
his extension has been renamed "Supported Groups" in the drafts of
TLS 1=
.3 and FFDHE.

Having different names for the same extension in diffe=
rent concurrent
RFCs should be avoided.

Section 5.1.1 and other p=
laces should be updated accordingly.

-- 
Henrik Grubbstr=C3=B6m&n=
bsp;            =
;            &n=
bsp;            =
; grubba@grubba.org
Roxen Internet Software AB    &n=
bsp;            =
;             g=
rubba@roxen.com

_______________________________________________
T=
LS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tl=
s
=

--_DC50C1DA-5E05-437D-8602-097BE4667659_--


From nobody Wed Jan 14 12:31:01 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D544B1B2A7C for ; Wed, 14 Jan 2015 12:30:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.6
X-Spam-Level: 
X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3] 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 xGBEYVWl2Mz4 for ; Wed, 14 Jan 2015 12:30:57 -0800 (PST)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3811B2A8A for ; Wed, 14 Jan 2015 12:30:57 -0800 (PST)
Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id A9A9CF984; Wed, 14 Jan 2015 15:30:55 -0500 (EST)
Received: by fifthhorseman.net (Postfix, from userid 1000) id C52FF2009B; Wed, 14 Jan 2015 15:30:51 -0500 (EST)
From: Daniel Kahn Gillmor 
To: Yoav Nir , Henrik =?utf-8?Q?Grubbstr=C3=B6m?= , "tls\@ietf.org" 
In-Reply-To: <54b6c734.e40cc30a.52a1.02ef@mx.google.com>
References:  <54b6c734.e40cc30a.52a1.02ef@mx.google.com>
User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu)
Date: Wed, 14 Jan 2015 15:30:51 -0500
Message-ID: <87fvbd3y10.fsf@alice.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [TLS] RFC4492bis - Rename the "Supported Elliptic Curves" extension
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Jan 2015 20:30:59 -0000

On Wed 2015-01-14 14:44:52 -0500, Yoav Nir wrote:
> I'm weakly opposed to renaming it. The name exists in codebases,
> protocol analyzers, books and web articles. I get that now we're
> adding non-EC groups, but renaming it seems like a gratuitous change
> to me with a non-zero cost.

I understand your concern, but it's also a quite annoying to have names
that diverge from definitions such that someone coming to it new has to
understand the history of a construct to make sense of the modern state,
which is what would happen if the non-curve groups get added and the
extension keeps the name "elliptic_curves".  software names can be
easily updated, and an alias for the old name exposed if it crosses API
or ABI boundaries.

What order do we expect these updates to be applied?  It seems like the
-negotiated-ffdhe draft and 4492bis should reference each other, and
should aim to reflect the same final state, if possible, right?

and aiui, 4492bis should ultimately reflect the response from the CFRG,
if it ever comes, right?

I'm happy to help coordinate so that the two drafts don't cause a
divergent state; maybe by proposing a pull request to 4492bis once
-negotiated-ffdhe has been settled.  does that sound OK?

Regards,

        --dkg


From nobody Wed Jan 14 13:04:17 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29FF01A8AB7 for ; Wed, 14 Jan 2015 13:04:15 -0800 (PST)
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 Bhis_aOEiJ9J for ; Wed, 14 Jan 2015 13:04:13 -0800 (PST)
Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B01ED1A901F for ; Wed, 14 Jan 2015 13:04:12 -0800 (PST)
Received: by mail-wg0-f43.google.com with SMTP id k14so11294015wgh.2 for ; Wed, 14 Jan 2015 13:04:11 -0800 (PST)
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=thCVulBaaAKlQbpDF2b7FTzn9FF21Df20br+AB2DT1I=; b=GnE7KKRF+V5ul4ZFQy2BLy5g7pTa2mEOIFnHuZRbV/M6/Wv7+B+6Qddt15u8ly5HNJ azxBuaP4RomcMwn2NAoAtX+Kbx3QrtjOERXwC3pAqBJSpAKapttz18WuMrqV/NDJcUyN HUYUaQLnWfvB58+TKD1WxOzR6apiabjxAIu0S7jOZy1nhWNQAcJMFSCK/oHAq7ptcjUw BYU2rKuY0GqnqZdnHBf5H0QQ5J7t33v/bL4kavCB0Cs54oJETZgWduU0xzMp46aOMnQE BvN6kBRKDnG3vaDGTDEHUWjsCohZHXKhdrC8yF/15ei9kf7ELzi5l2hyztcPhp5n9R2a 1Wbg==
X-Received: by 10.180.187.67 with SMTP id fq3mr18726659wic.37.1421269451098; Wed, 14 Jan 2015 13:04:11 -0800 (PST)
Received: from [192.168.1.15] ([46.120.13.132]) by mx.google.com with ESMTPSA id fo12sm20143622wic.19.2015.01.14.13.04.10 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 14 Jan 2015 13:04:10 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Yoav Nir 
In-Reply-To: <87fvbd3y10.fsf@alice.fifthhorseman.net>
Date: Wed, 14 Jan 2015 23:04:09 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <7DE5B6FE-F114-4A2F-8A1F-B79C49452887@gmail.com>
References:  <54b6c734.e40cc30a.52a1.02ef@mx.google.com> <87fvbd3y10.fsf@alice.fifthhorseman.net>
To: Daniel Kahn Gillmor 
X-Mailer: Apple Mail (2.1993)
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] RFC4492bis - Rename the "Supported Elliptic Curves" extension
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Jan 2015 21:04:15 -0000

> On Jan 14, 2015, at 10:30 PM, Daniel Kahn Gillmor =
 wrote:
>=20
> On Wed 2015-01-14 14:44:52 -0500, Yoav Nir wrote:
>> I'm weakly opposed to renaming it. The name exists in codebases,
>> protocol analyzers, books and web articles. I get that now we're
>> adding non-EC groups, but renaming it seems like a gratuitous change
>> to me with a non-zero cost.
>=20
> I understand your concern, but it's also a quite annoying to have =
names
> that diverge from definitions such that someone coming to it new has =
to
> understand the history of a construct to make sense of the modern =
state,
> which is what would happen if the non-curve groups get added and the
> extension keeps the name "elliptic_curves".  software names can be
> easily updated, and an alias for the old name exposed if it crosses =
API
> or ABI boundaries.
>=20
> What order do we expect these updates to be applied?  It seems like =
the
> -negotiated-ffdhe draft and 4492bis should reference each other, and
> should aim to reflect the same final state, if possible, right?
>=20
> and aiui, 4492bis should ultimately reflect the response from the =
CFRG,
> if it ever comes, right?
>=20
> I'm happy to help coordinate so that the two drafts don't cause a
> divergent state; maybe by proposing a pull request to 4492bis once
> -negotiated-ffdhe has been settled.  does that sound OK?

As I said, weakly opposed. And yes, if I rename the extension, I will =
reference your draft.=


From nobody Wed Jan 14 16:28:23 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7CA1B2A8B for ; Wed, 14 Jan 2015 16:28:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level: 
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 kChgSQgK-wxD for ; Wed, 14 Jan 2015 16:28:20 -0800 (PST)
Received: from zucker2.schokokeks.org (zucker2.schokokeks.org [178.63.68.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDC131B2A87 for ; Wed, 14 Jan 2015 16:28:19 -0800 (PST)
Received: from pc (ip5b400166.dynamic.kabel-deutschland.de [::ffff:91.64.1.102]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Thu, 15 Jan 2015 01:28:15 +0100 id 0000000000000058.0000000054B7099F.000077FA
Date: Thu, 15 Jan 2015 01:28:15 +0100
From: Hanno =?UTF-8?B?QsO2Y2s=?= 
To: tls@ietf.org
Message-ID: <20150115012815.3727ae17@pc>
In-Reply-To: <54B67A19.9010507@redhat.com>
References: <525BADBD.8020007@secunet.com> <54B67A19.9010507@redhat.com>
X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-30714-1421281695-0001-2"
Archived-At: 
Subject: Re: [TLS] Using RSA PSS in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Jan 2015 00:28:22 -0000

This is a MIME-formatted message.  If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--=_zucker.schokokeks.org-30714-1421281695-0001-2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, 14 Jan 2015 15:15:53 +0100
Florian Weimer  wrote:

> On 10/14/2013 10:39 AM, Johannes Merkle wrote:
> > While the current discussion on this list is about ECC, I would
> > like to raise the question if it were not desirable to allow usage
> > of provably secure RSA-PSS signatures from PKCS#1v2.1 in TLS.
>=20
> So it seems that using RSA-PSS is difficult (although CAs could offer
> to issue multiple certificates which could be switched as needed if a=20
> server operator doesn't want to make both RSA-PSS signatures and
> PKCS#1 1.5 signatures).

There's nothing difficult about PSS.
Sure, it is not "nice" to use the same key for PKCS #1 1.5 and 2.1. But
I'm not aware of anything even close to an attack, it's "just" good
cryptographic practice.

Right now TLS uses the same key for encryption and signatures, which is
basically the same problem. Nobody has raised this as an issue ever
as far as I'm aware.

We should simply switch to PSS. I plan to submit a pull request to do
that as soon as I find time for it.

--=20
Hanno B=C3=B6ck
http://hboeck.de/

mail/jabber: hanno@hboeck.de
GPG: BBB51E42

--=_zucker.schokokeks.org-30714-1421281695-0001-2
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJUtwmfAAoJEKWIAHK7tR5CE3MQAKMV0x+xj00mC8VmmUAoOqFs
BVwmJ703yz7xGNj5EZha9i7aJfJNuUUaZd8xNrP1wY9jiy2Fe67+5rn8lD8RKrBA
X5K3kkq/CnCCfn6/aN9a3WDuU831KFwuoUh1DxQ19hSW368ifQoan+h0wdWANjnF
UuxQ2tiaD79yJ8dE2T4kCGYeHwPZBne3oWxW/E5PzFQphGpjy2mJDy2aEeoxJeQI
cBbSuCR32FssmI7Uwgur3Rq4K0cbwjykOrV4bHZf7yYVRQ6dratMXsr5VxHRWu++
QjGaA/lYvAPBEio5yFUQEJ+bt2c4Ebh6pwMTjo6jbvvEbQxmqHNGYZn5r5C/Z6Fl
JzvcsjbQ/F2BiRPLa+p/LVXjIs2yfwpXtqokHtKh9X0cNBRJJIP4sSEmXMWBrLxZ
GWnKcf8Ir25saQEmrbatqjPz7SRAAo4qAcYwFvWI0m3GwfBdnUfi8kU/H//BCsmj
zhOHue/Hug6N7PvE3bqA5PN3VjH6pucwHEr7Sn8DJTKHonWOQg13rlaQoRxFvUYv
tRxYIl1GuIEYQNkNtpYhOFXezNweUW4EbzlHGk+t1MXQgeQWqR1FMXMsFHguBo3P
TWgwz947tex6newSYdPb/rVEmK86AAvMNB1tamT2ssZrhS+mD58riWhFz+S/A83P
+EAPpD4v7j5UyhxIm2nX
=jvX6
-----END PGP SIGNATURE-----

--=_zucker.schokokeks.org-30714-1421281695-0001-2--


From nobody Wed Jan 14 16:31:57 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1EB81B2A72 for ; Wed, 14 Jan 2015 16:31:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level: 
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 izZzb-GyUtOq for ; Wed, 14 Jan 2015 16:31:54 -0800 (PST)
Received: from zucker2.schokokeks.org (zucker2.schokokeks.org [178.63.68.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE5AC1B2AB8 for ; Wed, 14 Jan 2015 16:31:51 -0800 (PST)
Received: from pc (ip5b400166.dynamic.kabel-deutschland.de [::ffff:91.64.1.102]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Thu, 15 Jan 2015 01:31:49 +0100 id 0000000000000058.0000000054B70A75.00007B2C
Date: Thu, 15 Jan 2015 01:31:49 +0100
From: Hanno =?UTF-8?B?QsO2Y2s=?= 
To: tls@ietf.org
Message-ID: <20150115013149.0185bea4@pc>
In-Reply-To: 
References: <525BADBD.8020007@secunet.com> <54B67A19.9010507@redhat.com> 
X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-31532-1421281909-0001-2"
Archived-At: 
Subject: Re: [TLS] Using RSA PSS in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Jan 2015 00:31:55 -0000

This is a MIME-formatted message.  If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--=_zucker.schokokeks.org-31532-1421281909-0001-2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, 14 Jan 2015 15:32:42 +0100
CodesInChaos  wrote:

> I consider the risk of PKCS#1v1.5 encryption far bigger than the risk
> of PKCS#1v1.5 signatures.
> I'm not aware of any attack against  PKCS#1v1.5 signatures, they
> merely lack a security proof.

Bleichenbacher's signature forgery attack [1], which has recently been
re-discovered in combination with some ASN.1 issues under the name
BERserk [2].

Sure, these are "mere implementation issues". You can do PKCS #1 1.5
signatures right - just like you can do PKCS #1 1.5 encryption right.
It's just that people did it wrong multiple times. I don't see simliar
risks with PSS, it's the much more robust solution.


[1] https://www.ietf.org/mail-archive/web/openpgp/current/msg00999.html
[2] http://www.intelsecurity.com/advanced-threat-research/
--=20
Hanno B=C3=B6ck
http://hboeck.de/

mail/jabber: hanno@hboeck.de
GPG: BBB51E42

--=_zucker.schokokeks.org-31532-1421281909-0001-2
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJUtwp1AAoJEKWIAHK7tR5C+oAP/Rh6zaXJyMo6iuO1gQLuw0/G
/Ej0Ey03e1TZrew7I4ERW3y/X7dybtbY3UfUwHIafddGTWTR3vgsLX3Lt4xQi2UH
V+egc272LqExQDXA+/b6TtgMwRbyb+LNxqGbrvMp1nt5eGcHYeIgY6yQalRwoOZB
wQ8TWSdqNdfuj5fGInUFvTZNo6NI+WUp10dXT5Os6joGUcxKh2c+R2pkSUZEXY4g
C2wqzwY8L1DzkqQCtnk7qT1m+YMxKtTeER6fZ0DENzO8fA5osSA7qBfBpTxSA3dy
yt2QqX30M2Rod+QOGZd3HhXh/jJmBjIoqyFbYCKYRbCJ3MTlcXscITWcAllA8pJg
fFg3E58si+R23KWJ46NkgvBIjYvkzSVD30NNdJjQc3Qp9NJvTkczJPXnEK1mp8cb
wwvrzd3h4rjEJxA/7kZXssoYG/AMVpXEAYFE2L6nvrHdlajd+RJ5hqy8F3XGoJis
Sdr9JzFunbk5Az+etAl1GsbmtWauPGpoOoof9Bx6PeNUn4OAUVB+xBDNyCiUTBLD
qlnsrCRPWvKTnmDAbi/maEggeFblQJGPmkGuaV0mLB2DqlA6gG6fBh171UA4lTHt
lTpmlxRMiPdeQib+vOEhjZ94XNzV6J/4wmZdwBe370BgkfPf+VA74vWARFBRx7Eh
yz3buPnhXHqvGEVkZJHo
=wDWL
-----END PGP SIGNATURE-----

--=_zucker.schokokeks.org-31532-1421281909-0001-2--


From nobody Wed Jan 14 16:50:43 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2488E1B2A86 for ; Wed, 14 Jan 2015 16:50:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.251
X-Spam-Level: 
X-Spam-Status: No, score=-6.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, 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 DYEFenr7c8P8 for ; Wed, 14 Jan 2015 16:50:34 -0800 (PST)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 522451B2A72 for ; Wed, 14 Jan 2015 16:50:34 -0800 (PST)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 455683A403; Thu, 15 Jan 2015 01:50:32 +0100 (CET)
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 286FA425C9; Thu, 15 Jan 2015 01:50:32 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 1FBC41B0EA; Thu, 15 Jan 2015 01:50:32 +0100 (CET)
In-Reply-To: <20150115013149.0185bea4@pc>
To: =?UTF-8?Q?Hanno_B=C3=B6ck?= 
Date: Thu, 15 Jan 2015 01:50:32 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="ISO-8859-1"
Message-Id: <20150115005032.1FBC41B0EA@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: 
Cc: tls@ietf.org
Subject: Re: [TLS] Using RSA PSS in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Jan 2015 00:50:40 -0000

Hanno B=F6ck wrote:

[ Charset UTF-8 unsupported, converting... ]
> On Wed, 14 Jan 2015 15:32:42 +0100
> CodesInChaos  wrote:
>=20
> > I consider the risk of PKCS#1v1.5 encryption far bigger than the risk
> > of PKCS#1v1.5 signatures.
> > I'm not aware of any attack against  PKCS#1v1.5 signatures, they
> > merely lack a security proof.
>=20
> Bleichenbacher's signature forgery attack [1], which has recently been
> re-discovered in combination with some ASN.1 issues under the name
> BERserk [2].
>=20
> Sure, these are "mere implementation issues". You can do PKCS #1 1.5
> signatures right - just like you can do PKCS #1 1.5 encryption right.
> It's just that people did it wrong multiple times. I don't see simliar
> risks with PSS, it's the much more robust solution.

The problem really is the original bogus approach how to _verify_
PKCS#1 v1.5 signatures.
If the spec was tightened to prohibit *all* kinds of parsing
of the RSA-decrypted BT01 padding signature plaintext,
and instead required rebuilding of the BT01 padding from the input hash
value and input hash oid, and comparison of the newly composed result
with what the RSA decryption returned, then none of the parser problems
for RSA PKCS#1 v1.5 signatures would have existed.

That approach to RSA signature verification is actually the one
recommended by PKCS#1 v2.1 for the RSASSA-PKCS1-V1_5-VERIFY operation.

  https://tools.ietf.org/html/rfc3447#section-8.2.2

And given its age (rfc3447 was published in February 2003),
the more robust verification _could_ have been required for
TLSv1.1 (2006) and TLSv1.2 (2008), but such improvements seem
to have been rotting in the same forgotten drawer as Serge Vaudenay's
proposed fix to the CBC mac-pad-encrypt weakness...


-Martin


From nobody Wed Jan 14 18:07:22 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 802661B2A96 for ; Wed, 14 Jan 2015 18:07:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.668
X-Spam-Level: 
X-Spam-Status: No, score=-1.668 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-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 tkrIyREQas-Q for ; Wed, 14 Jan 2015 18:07:16 -0800 (PST)
Received: from tlsx.org (tlsx.org [67.207.128.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFD2D1B2A8B for ; Wed, 14 Jan 2015 18:07:16 -0800 (PST)
Received: from monty.local (unknown.maxonline.com.sg [58.182.90.50] (may be forged)) (authenticated bits=0) by tlsx.org (8.14.4/8.14.4/Debian-4) with ESMTP id t0F2Sokt003443 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 15 Jan 2015 02:28:54 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=metaparadigm.com; s=klaatu; t=1421288936; bh=bAHfq2T2+yF2wM3PyJ7c94vyHRVamKsdgbplBynRy1Q=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=IQPZyUedqB61ik/2GU/fRWQ5TC90Scufpg1TdHm97/ybmaff2YOMythcgwP/fu03/ PqN20U2IY4rCtqfqPZhJ/aOyKkECh5qPy5KUudwZlGca5V/5TgXGZURlLL0pcFUlN+ u6Hn8FBEKrh8IqVFgRRTkCdVo5rYRz+PjOwEEMjY=
Message-ID: <54B720C5.7070600@metaparadigm.com>
Date: Thu, 15 Jan 2015 10:07:01 +0800
From: Michael Clark 
Organization: Metaparadigm
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Ilari Liusvaara 
References: <274716D0-EC91-4131-A8F7-CD13A9B42CE7@gmail.com>  <54ADE9B6.4080700@metaparadigm.com> <702F318A-FE04-45F7-8CA1-30256D628CF7@gmail.com> <54B1DD25.8090305@metaparadigm.com> <20150111051421.GA32295@LK-Perkele-VII> <54B65ADF.5020506@metaparadigm.com> <20150114133837.GA32171@LK-Perkele-VII>
In-Reply-To: <20150114133837.GA32171@LK-Perkele-VII>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.98.4 at klaatu.metaparadigm.com
X-Virus-Status: Clean
Archived-At: 
Cc: "TLS@ietf.org \(tls@ietf.org\)" 
Subject: Re: [TLS] RFC4492bis - Removing ECDH
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Jan 2015 02:07:19 -0000

On 14/1/15 9:38 pm, Ilari Liusvaara wrote:
> It is specified in base TLS spec (Section 7.4.9 for TLS1.2 / RFC5246).
> 
> And given the realtime requirements, even ~2^48 work to collide a 96-
> bit hash is a lot of work. And looks like one would need a preimage
> to do anything interesting, which is ~2^96 work (regarded infeasible
> even with lots of resource).

Makes sense. It's getting reachable in the relatively near future (for a
somewhat value of relatively). You could still do probabilistic attacks
with a smaller image. Like fishing.

>= 128-bits verify_data sounds better for draft a TLSv1.3 considering it
may be around for 10+ years. 256-bit MAC is 128 security bits (> 112).
The NIST requirement for signature strength beyond 2013 is 112 bits. I
suppose this mandates 256 bit MAC if the NIST requirement goes into FIPS
or any other national body requirements.

verify_data might be <16...64> octets instead of 12. 32 meets FIPS
signature strength requirements beyond 2013 if we interpret it as a
"handshake and signature" and 256-bit MAC as 128 security bits.

However verify_data is a "signature of a handshake" as RSA, PSK, EdDSA,
etc are used for signing. Either way you look at it, it is a signature.


From nobody Wed Jan 14 18:11:52 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7CCD1B2A75 for ; Wed, 14 Jan 2015 18:11:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.895
X-Spam-Level: 
X-Spam-Status: No, score=0.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_HELO_PASS=-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 eaPz7R1J-v21 for ; Wed, 14 Jan 2015 18:11:48 -0800 (PST)
Received: from dragaera.releasedominatrix.com (unknown [198.0.208.83]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCA361AD26E for ; Wed, 14 Jan 2015 18:11:48 -0800 (PST)
Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 4C97E33D1A2; Thu, 15 Jan 2015 02:11:18 +0000 (UTC)
Sender: geoffk@localhost.localdomain
To: mrex@sap.com
References: <20150115013149.0185bea4@pc> <20150115005032.1FBC41B0EA@ld9781.wdf.sap.corp>
From: Geoffrey Keating 
Date: 14 Jan 2015 18:11:18 -0800
In-Reply-To: <20150115005032.1FBC41B0EA@ld9781.wdf.sap.corp>
Message-ID: 
Lines: 16
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Archived-At: 
Cc: tls@ietf.org
Subject: Re: [TLS] Using RSA PSS in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Jan 2015 02:11:51 -0000

mrex@sap.com (Martin Rex) writes:

> If the spec was tightened to prohibit *all* kinds of parsing
> of the RSA-decrypted BT01 padding signature plaintext,
> and instead required rebuilding of the BT01 padding from the input hash
> value and input hash oid, and comparison of the newly composed result
> with what the RSA decryption returned, then none of the parser problems
> for RSA PKCS#1 v1.5 signatures would have existed.
> 
> That approach to RSA signature verification is actually the one
> recommended by PKCS#1 v2.1 for the RSASSA-PKCS1-V1_5-VERIFY operation.
> 
>   https://tools.ietf.org/html/rfc3447#section-8.2.2

Would this actually work?  I suspect implementations use slightly
inconsistent padding generation...


From nobody Wed Jan 14 21:14:53 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CDAB1B2ADA for ; Wed, 14 Jan 2015 21:14:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.1
X-Spam-Level: 
X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[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 Ud94rsEThXfC for ; Wed, 14 Jan 2015 21:14:49 -0800 (PST)
Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8833F1ACEF6 for ; Wed, 14 Jan 2015 21:14:49 -0800 (PST)
Received: by mail-yh0-f41.google.com with SMTP id a41so6418640yho.0 for ; Wed, 14 Jan 2015 21:14:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:date:message-id:subject:from:to:cc:content-type;  bh=yu+N3JXE0suJh0GoHm33DWiltF9/Wv/UwMeJWTXC0yk=; b=amM47bppPZ6kqUaZMlYf7xuF2iopu9INeJTQfkpBCJ4AS7uK99PWWECBgvwJBpNniI 0D7Zck3QrOvqb0zi1mfSuBmXZ3oyuSxpGwYj0M0DuppNhCwffvQ6Q4TYy4/z7ziUcODt OqF+bqScb7bkdH5d6iFMOnrhCaP2gcojOKR0Eg9f8FvzzzKAbKxVaEV49XsFFB5JGfZq ZHyUJlyFdiT4Nlzn3xs7qQ6wRlL+K8VDiRatsoj/3Ju2osb+am5kF+/P1ZmFUwROQQpi WEfRnZisNN3aDb8HPNvqU99+FPVwvO8cS6LOKqo/XcHgc+qQR1FR0t+vS8In85Xj55P4 P+qg==
MIME-Version: 1.0
X-Received: by 10.236.63.6 with SMTP id z6mr4688578yhc.65.1421298888693; Wed, 14 Jan 2015 21:14:48 -0800 (PST)
Received: by 10.170.207.6 with HTTP; Wed, 14 Jan 2015 21:14:48 -0800 (PST)
Date: Wed, 14 Jan 2015 21:14:48 -0800
Message-ID: 
From: Watson Ladd 
To: Eric Rescorla 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: TLS Mailing List 
Subject: [TLS] MTI suite (was Re:  Inclusion of OCB mode in TLS 1.3)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Jan 2015 05:14:51 -0000

On Wed, Jan 14, 2015 at 9:02 AM, Eric Rescorla  wrote:
>
>
> On Wed, Jan 14, 2015 at 6:46 AM, Aaron Zauner  wrote:
>>
>> Hi Stephen,
>>
>> Stephen Farrell wrote:
>> > 
>> >
>> > On 13/01/15 18:25, Paul Lambert wrote:
>> >> This should not stop inclusion of OCB as an optional mode in TLS,
>> >
>> > I don't get why additional options are at all attractive. In
>> > fact, I think they're ugly.
>> >
>> > TLS has about 327 ciphersuites. That's just stupid. (I'm not
>> > saying any person is stupid there btw, but we have gotten
>> > ourselves into a stupid place.)
>>
>> Yup. Having different naming schemes for different
>> libraries/implementations beyond that makes it almost impossible to give
>> good recommendations to end-users (admins, management) as we've noticed
>> in the bettercrypto.org project.
>>
>> >
>> > If we have a really better thing, they why not make it MTI? If
>> > we do not have something sufficiently better then I'd argue to
>> > exclude as much as possible, and certainly against adding
>> > anything that is just nice to have.
>> >
>> > I'd even like to make almost all current ciphersuites a MUST NOT
>> > (or start a new registry) for TLS1.3 and to not add any new
>> > ciphersuites at all, and just stick with two MTI ciphersuites
>> > that are as genetically different as possible and cover as many
>> > implementations (h/w AES or not) as possible.
>> >
>> > So my suggestion is to reduce the ciphersuite field to be
>> > 2 bits wide in TLS 1.3, with 00 being default, 01 backup, 02
>> > being "proprietary" and 03 reserved. If either 00 or 01 needs
>> > to be changed then I'd say rev the TLS version. (I don't care
>> > if we did s/default/has-AES-hw/ and s/backup/just-sw-crypto/
>> > that'd also be fine.)
>> >
>> > And yes, I realise that's not likely to get traction, but
>> > turning 327 into 427 is even dumber when reality shows that
>> > only a few of 'em are used or needed.
>>
>> Just as a suggestion, how about a document that does only include
>> forward-secret cipher-suites that are valid for TLS 1.3? That would
>> drastically remove the number of OCB ciphersuites that I would have to
>> add in case of TLS 1.2.
>>
>> One issue though: as far as I can tell (from the recent RWC presentation
>> by EKR) there are still going to be three block ciphers in TLS 1.3: AES,
>> CAMELLIA, ARIA.
>
>
> To be clear, this is just a statement of fact. I.e., TLS 1.3 can only be
> used
> with AEAD and these are the AEAD ciphers that are presently defined.
> The WG could adopt more AEAD ciphers or conversely, remove ones that
> currently exist.
>
> Speaking only for myself, it seems like AES-GCM is the leading candidate
> for the MTI for TLS 1.3, based on the fact that it's the most common
> AEAD algorithm with 1.2.

In my view that may be mistake. AES-CCM is supportable everywhere with
AES, while AES-GCM requires hardware multiplier support, which in the
embedded world can be less common. AES-GCM as MTI creates an effective
lower bound on devices that is quite high. The range of hardware that
can support it securely and efficiently is very narrow.
ChaCha20-Poly1305 is rare, but easy to support everywhere.

We have a similar balancing act with respect to ECC, although there
P256 is a much more obvious seeming choice.

Sincerely,
Watson Ladd

>
> -Ekr
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



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


From nobody Thu Jan 15 10:38:50 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3E631B3037 for ; Thu, 15 Jan 2015 10:38:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.3
X-Spam-Level: ***
X-Spam-Status: No, score=3.3 tagged_above=-999 required=5 tests=[BAYES_50=0.8,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, 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 sf0CxGyLE5ae for ; Thu, 15 Jan 2015 10:38:44 -0800 (PST)
Received: from mail-yh0-x22a.google.com (mail-yh0-x22a.google.com [IPv6:2607:f8b0:4002:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D9971B3032 for ; Thu, 15 Jan 2015 10:38:40 -0800 (PST)
Received: by mail-yh0-f42.google.com with SMTP id v1so8095229yhn.1 for ; Thu, 15 Jan 2015 10:38:39 -0800 (PST)
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:content-transfer-encoding; bh=lmNACsSNEYu/qpyuAQ1JFxFstdBJlsGXp6PVA04P4w4=; b=GVqB5Iv1qSiVS6QSETmz9FlMvhfskhyRZhZ0BBb5+/1KNHaAc9SI2cR9b5lvzn8sxP ood9xJAkU+6oxGEFwWLgU6SvHmhdkGX1PVQbVyr8TryKpfpj6gQmPQulZypaLaX5MALj 5+3xq1FqsB56ZX6xj+ezw/I7X0Uh4VmNFSOKytTscEX7kevCHpWINXcMAWY7yGYUID5A g/nHHG2B2sFbg19U5Qkyf6xD2Y9Ew7I1JtnN7kYMcRIevCeT9gEsQX5EKZPDGAkfEmc4 B4sUy5Ip/XrM+RwQpTgWee/qINOcUfHezfn/uPkl4cPA/IKiYv+HczY7IVOdSxqV1tvI Depw==
MIME-Version: 1.0
X-Received: by 10.236.7.70 with SMTP id 46mr6991068yho.138.1421347119442; Thu, 15 Jan 2015 10:38:39 -0800 (PST)
Received: by 10.170.207.6 with HTTP; Thu, 15 Jan 2015 10:38:39 -0800 (PST)
In-Reply-To: <20150115013149.0185bea4@pc>
References: <525BADBD.8020007@secunet.com> <54B67A19.9010507@redhat.com>  <20150115013149.0185bea4@pc>
Date: Thu, 15 Jan 2015 10:38:39 -0800
Message-ID: 
From: Watson Ladd 
To: =?UTF-8?Q?Hanno_B=C3=B6ck?= 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Using RSA PSS in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Jan 2015 18:38:47 -0000

On Wed, Jan 14, 2015 at 4:31 PM, Hanno B=C3=B6ck  wrote:
> On Wed, 14 Jan 2015 15:32:42 +0100
> CodesInChaos  wrote:
>
>> I consider the risk of PKCS#1v1.5 encryption far bigger than the risk
>> of PKCS#1v1.5 signatures.
>> I'm not aware of any attack against  PKCS#1v1.5 signatures, they
>> merely lack a security proof.
>
> Bleichenbacher's signature forgery attack [1], which has recently been
> re-discovered in combination with some ASN.1 issues under the name
> BERserk [2].
>
> Sure, these are "mere implementation issues". You can do PKCS #1 1.5
> signatures right - just like you can do PKCS #1 1.5 encryption right.
> It's just that people did it wrong multiple times. I don't see simliar
> risks with PSS, it's the much more robust solution.

You *cannot* do PKCS 1.5 encryption right. The countermeasures to
Bleichenbacher depend on enforcing additional structure on the
messages, which SSL imposed by accident. As everyone should know, many
implementations still do not get this right. (Can't name which ones,
but even if they make the check, they may expose timing channels that
are exploitable: there was a German PhD thesis a year or two ago that
investigated exactly this, and broke some Java implementations).

Implementors are clearly not reading the documents we produce in a
more than cursory manner: RFC 2437 tells you exactly how to avoid
these issues, and refers to papers explaining how bad things can go.
That was in 1998! Yet we still see bugs in PKCS 1.5 signature
verification caused by not following the spec.

RSA-OEAP has similar error oracle issues,
https://www.iacr.org/archive/crypto2001/21390229.pdf. It's a moot
point because we aren't using an RSA encryption based method in TLS
1.3, but there is an obviously secure alternative in the ROM, namely a
variant of RSA-KEM, which doesn't have these implementation issues.

We need to think in terms of "how badly is the coder who writes things
going to mess up" when designing, and check that the actual deployed,
running code, is doing the right thing. The downgrade dance is an
example of something that should have been visible years ago. RC4
insecurity was known in 2001. POODLE is in a text document from 2004.
Encrypt-then-MAC was since 2000-20001, and we didn't properly fix it
for 13 years afterward.

In terms of the original thread necromancy, yes, the security
properties are different: one set has PFS. I'm not sure what
properties are being discussed, especially given that we now know
almost everything about TLS's actual security, that make changing
tough.

>
>
> [1] https://www.ietf.org/mail-archive/web/openpgp/current/msg00999.html
> [2] http://www.intelsecurity.com/advanced-threat-research/
> --
> Hanno B=C3=B6ck
> http://hboeck.de/
>
> mail/jabber: hanno@hboeck.de
> GPG: BBB51E42
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



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


From nobody Thu Jan 15 12:51:37 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF531B29CA for ; Thu, 15 Jan 2015 12:51:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.239
X-Spam-Level: 
X-Spam-Status: No, score=0.239 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=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 6i864BFVPfNQ for ; Thu, 15 Jan 2015 12:51:31 -0800 (PST)
Received: from BLU004-OMC2S25.hotmail.com (blu004-omc2s25.hotmail.com [65.55.111.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A92991B29BD for ; Thu, 15 Jan 2015 12:51:31 -0800 (PST)
Received: from BLU177-W20 ([65.55.111.73]) by BLU004-OMC2S25.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751);  Thu, 15 Jan 2015 12:51:31 -0800
X-TMN: [4iZ72o6n1aUgDWDuIz6NwQC8glMNsdrq]
X-Originating-Email: [yuhongbao_386@hotmail.com]
Message-ID: 
From: Yuhong Bao 
To: Watson Ladd , Eric Rescorla 
Date: Thu, 15 Jan 2015 12:51:30 -0800
Importance: Normal
In-Reply-To: 
References: 
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 15 Jan 2015 20:51:31.0308 (UTC) FILETIME=[0A6A4AC0:01D03105]
Archived-At: 
Cc: TLS Mailing List 
Subject: Re: [TLS] MTI suite (was Re:  Inclusion of OCB mode in TLS 1.3)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Jan 2015 20:51:33 -0000

> In my view that may be mistake. AES-CCM is supportable everywhere with=0A=
> AES=2C while AES-GCM requires hardware multiplier support=2C which in the=
=0A=
> embedded world can be less common. AES-GCM as MTI creates an effective=0A=
> lower bound on devices that is quite high. The range of hardware that=0A=
> can support it securely and efficiently is very narrow.=0A=
> ChaCha20-Poly1305 is rare=2C but easy to support everywhere.=0A=
Which reminds me that they seems to forgot ECDHE_RSA when standardizing CCM=
 in TLS 1.2.=0A=
I think another Internet-Draft is needed.=0A=
=0A=
Yuhong Bao 		 	   		  =


From nobody Thu Jan 15 14:51:59 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5778E1A90A9 for ; Thu, 15 Jan 2015 14:51:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 ExELlCJI_-7P for ; Thu, 15 Jan 2015 14:51:52 -0800 (PST)
Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7E531A90A1 for ; Thu, 15 Jan 2015 14:51:51 -0800 (PST)
Received: by mail-wg0-f54.google.com with SMTP id z12so17619490wgg.13 for ; Thu, 15 Jan 2015 14:51:50 -0800 (PST)
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:from:date :message-id:subject:to:cc:content-type; bh=5x8aXk6Zjfih4o/3pNvxwE0/N7FPdI/swnpKBmvpGbY=; b=hHQE0FM5eqhhNVEhJ475Yv9w6OI7u0Sq7U+LY5M8vR19S/N7zO5dr7gkEBuSx83Buv WjXtgHFLQavIKK7d9FxeoWOHAowNeiTAnYZDAiMxiGK6YwdTX5ucu1WUaHWGtAFtLmSN 8J31Ybp37dVrX9rRhGGuHKOROhdoYRN/Kv92HxAwK70Jd4olUAB/Q/Ngskv2NKADzDTB 2PKCPf+snPpSXkjl1dgsKaVjkzZt5ZPm/Tuo9SXjvEYADBp40TqprBvcUQ4FX2bpeUS3 sraN0qGbdbXU+h/VcqSEzc3dhgHaEbiNjMmPdRerGuhRDv1oc/VABPWY5pKP1xtB0gLP EWuQ==
X-Gm-Message-State: ALoCoQlbUqaVrNDwOT0lL4q+O5Ri6fjiqXUfqSdMIFOBUbOJSXPmohN2E+RmbPUJ16QAmLsf7Ymf
X-Received: by 10.180.84.98 with SMTP id x2mr511855wiy.14.1421362310545; Thu, 15 Jan 2015 14:51:50 -0800 (PST)
MIME-Version: 1.0
Received: by 10.27.142.215 with HTTP; Thu, 15 Jan 2015 14:51:10 -0800 (PST)
In-Reply-To: <75C82EF9-8800-453F-A489-10FD26E7F2CD@gmail.com>
References:  <62165FC2-540D-48A5-A7AC-3D6D9087FDD2@gmail.com>  <75C82EF9-8800-453F-A489-10FD26E7F2CD@gmail.com>
From: Eric Rescorla 
Date: Thu, 15 Jan 2015 14:51:10 -0800
Message-ID: 
To: Yoav Nir 
Content-Type: multipart/alternative; boundary=f46d044401b29e160b050cb8b310
Archived-At: 
Cc: Stephen Checkoway , "TLS@ietf.org \(tls@ietf.org\)" 
Subject: Re: [TLS] WGLC: draft-ietf-tls-session-hash
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Jan 2015 22:51:56 -0000

--f46d044401b29e160b050cb8b310
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

So to be clear, the proposed language is:

For sessions negotiated without EMS:
- SHOULD not resume
- MUST not resume sessions if the client offers EMS in the resumption
  (and therefore SHOULD do a complete negotiation).

For sessions negotiated with EMS:
- The client ??? offer EMS
- The server MUST NOT echo it?

I propose that the ??? be MUST and that the server MUST fail if the client
does not offer EMS. The intuition here is that the client is saying that it
wants EMS.

-Ekr

P.S. Thanks to Wan-Teh and Martin for talking this over privately.




On Mon, Nov 24, 2014 at 6:22 AM, Yoav Nir  wrote:

>
> > On Nov 24, 2014, at 1:58 PM, Stephen Checkoway  wrote:
> >
> >
> > On Nov 24, 2014, at 3:44 AM, Yoav Nir  wrote:
> >
> >> Third issue: Why can=E2=80=99t an attacker disable this protection by =
simply
> omitting the extension from both its ClientHello and ServerHello?  At lea=
st
> in the short term it won=E2=80=99t be practical to fail a handshake becau=
se the
> other side doesn=E2=80=99t support this extension. I guess the answer is =
that the
> ruse will work, but the other attacks mentioned in TRIPLE-HS will fail, b=
ut
> it=E2=80=99s not clear to me why. A can still proxy unchanged records fro=
m C to S
> if the connections are resumptions. Perhaps servers should be prohibited
> from resuming a session set up without this extension if the ClientHello
> does include the extension.
> >
> > The draft currently says "Clients and servers SHOULD NOT resume session=
s
> that do not use the extended master secret..." Are you saying you want th=
at
> to be MUST NOT?
>
> I missed that line.
>
> What I was suggesting was that servers MUST NOT resume sessions that were
> negotiated without the extended master secret in handshakes that do have
> the extension.
>
> Thinking it over now, I guess it would be better to have both lines,
> because there=E2=80=99s a significant performance penalty to prohibiting =
sessions
> resumption with all existing clients, and prohibiting the resumption wher=
e
> the attacker is not manipulating the handshake defeats the known attacks.
>
> Yoav
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--f46d044401b29e160b050cb8b310
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


So to be clear, the proposed language is:

For sessions negotiated without EMS:
- SHOULD not resume
=

- MUST not resume sessions if the client offers EMS in the resumption<=
/div>
=C2=A0 (and therefore SHOULD do a complete negotiation).

For sessions negotiated with EMS:
- The client ?=
?? offer EMS
- The server MUST NOT echo it?

<=
div>I propose that the ??? be MUST and that the server MUST fail if the cli=
ent
does not offer EMS. The intuition here is that the client is =
saying that it
wants EMS.

-Ekr

P.S. Thanks to Wan-Teh and Martin for talking this over pri=
vately.




On Mon, Nov 24, 2014 at 6:2=
2 AM, Yoav Nir <ynir.ietf@gmail.com> wrote:


> On Nov 24, 2014, at 1:58 PM, Stephen Checkoway <s@pahtak.org> wrote:

>

>

> On Nov 24, 2014, at 3:44 AM, Yoav Nir <ynir.ietf@gmail.com> wrote:

>

>> Third issue: Why can=E2=80=99t an attacker disable this protection=
 by simply omitting the extension from both its ClientHello and ServerHello=
?=C2=A0 At least in the short term it won=E2=80=99t be practical to fail a =
handshake because the other side doesn=E2=80=99t support this extension. I =
guess the answer is that the ruse will work, but the other attacks mentione=
d in TRIPLE-HS will fail, but it=E2=80=99s not clear to me why. A can still=
 proxy unchanged records from C to S if the connections are resumptions. Pe=
rhaps servers should be prohibited from resuming a session set up without t=
his extension if the ClientHello does include the extension.

>

> The draft currently says "Clients and servers SHOULD NOT resume s=
essions that do not use the extended master secret..." Are you saying =
you want that to be MUST NOT?



I missed that line.



What I was suggesting was that servers MUST NOT resume sessions that were n=
egotiated without the extended master secret in handshakes that do have the=
 extension.



Thinking it over now, I guess it would be better to have both lines, becaus=
e there=E2=80=99s a significant performance penalty to prohibiting sessions=
 resumption with all existing clients, and prohibiting the resumption where=
 the attacker is not manipulating the handshake defeats the known attacks.<=
br>


Yoav






_______________________________________________

TLS mailing list

TLS@ietf.org

htt=
ps://www.ietf.org/mailman/listinfo/tls





--f46d044401b29e160b050cb8b310--


From nobody Thu Jan 15 15:21:31 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 876F01A908D for ; Thu, 15 Jan 2015 15:21:29 -0800 (PST)
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 ZzsRTuqkGAni for ; Thu, 15 Jan 2015 15:21:27 -0800 (PST)
Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEF391A9089 for ; Thu, 15 Jan 2015 15:21:26 -0800 (PST)
Received: by mail-oi0-f51.google.com with SMTP id h136so14877523oig.10 for ; Thu, 15 Jan 2015 15:21:26 -0800 (PST)
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=Bj0wGiwmCLT938YJLuG6kBaNwpVBZj7waDQ7pzAmCzI=; b=u8BX9DcVTxeMmXJv5uRWgWuTCl+AKvJozApRffMRigIJkOXBZ4NnQbY5gNmOfYdxwD z1Sxgby79Y+/QlXuyc5vutlYxaFX8+jbBpCSxNRG0SUesnO5slPQ5fGj7cSTdIVs2KCo yPLSU0Xua+MiaPUWI2KzVR7TEcJ9UZXFuNFkcPzPMNquMDul0YK966JBupqlNaSwA8gE XToCkt0tr3wb1oaL67BzuYXE4vlhwP5i9/fNahN1De4AR+9xyhyKt0UKrW+DSckeF09p UmHQVdyISqYdf9bPN+AA3QnOkimlbo69WT8XoFy5daXtFEFJIJvXuROhDp7hFnQb0jEU IHKg==
MIME-Version: 1.0
X-Received: by 10.202.75.202 with SMTP id y193mr7167013oia.12.1421364086204; Thu, 15 Jan 2015 15:21:26 -0800 (PST)
Received: by 10.202.226.136 with HTTP; Thu, 15 Jan 2015 15:21:26 -0800 (PST)
In-Reply-To: 
References:  <62165FC2-540D-48A5-A7AC-3D6D9087FDD2@gmail.com>  <75C82EF9-8800-453F-A489-10FD26E7F2CD@gmail.com> 
Date: Thu, 15 Jan 2015 15:21:26 -0800
Message-ID: 
From: Martin Thomson 
To: Eric Rescorla 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: Stephen Checkoway , "TLS@ietf.org \(tls@ietf.org\)" 
Subject: Re: [TLS] WGLC: draft-ietf-tls-session-hash
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Jan 2015 23:21:29 -0000

On 15 January 2015 at 14:51, Eric Rescorla  wrote:
> For sessions negotiated without EMS:
> - SHOULD not resume
> - MUST not resume sessions if the client offers EMS in the resumption
>   (and therefore SHOULD do a complete negotiation).
>
> For sessions negotiated with EMS:
> - The client ??? offer EMS
> - The server MUST NOT echo it?

Just to be clear, this latter part is...when renegotiating.

My preference is: if the session had EMS, when renegotiating:
 - the client MUST offer the extension, and
 - the server MUST fail the handshake (new alert needed?) if the
extension isn't present.

That means no resumption, OR fallback to the complete handshake.

I think that I'd prefer to have the server echo the extension in this
case too.  It's a few bytes effectively wasted, but it makes
everything nice and symmetrical.  Clients says "I want EMS" and server
says "you got EMS".


From nobody Thu Jan 15 15:29:46 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D43981A9089 for ; Thu, 15 Jan 2015 15:29:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 gYjnNzG9Trtd for ; Thu, 15 Jan 2015 15:29:43 -0800 (PST)
Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A0491A9087 for ; Thu, 15 Jan 2015 15:29:43 -0800 (PST)
Received: by mail-wg0-f41.google.com with SMTP id l18so17810530wgh.0 for ; Thu, 15 Jan 2015 15:29:42 -0800 (PST)
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:from:date :message-id:subject:to:cc:content-type; bh=52Cyu7Z7RfYZTsMdo9geCOQ6Utx0e6BM67AIaxyki08=; b=Pc1lc2M1xGTo0jWkF0ILhTGH3ak1byvQbqY0rJ4Z8cB5f+QJgFiAm+ZXIczRagi70A 81S5+2urz4r5hownVVb+OPhLzOG0xd+rxnGBuuxU6hQY/3sBRIGtiNBe0Hq6Vvpe7XB3 NoHTMLALjNmJkuvMpD4ecIE9BQ7LZf55vlydp3rf3s0zKebUCvGT6y+a+EzXojo7dg74 YlnhlVs/bXLZlJbm5zVt0CAYg/NYo5Bc34dDqjroEe0PhayOsb6BrLNWR1jOxbj9tOzD kHMsRABJJg/HKWn0ReCqBEEpFQuFvA7LQvnNnJfECgSW5tSVqBPAP0sfKn7RUn3dLR5z nY+A==
X-Gm-Message-State: ALoCoQk6KuxToAnUg6Aggu8i49LwN4mtt8l+625EN7kCTCXXLaB87bkJZtncfE2GYWlm/d0s8sf/
X-Received: by 10.194.203.104 with SMTP id kp8mr18584622wjc.103.1421364582059;  Thu, 15 Jan 2015 15:29:42 -0800 (PST)
MIME-Version: 1.0
Received: by 10.27.142.215 with HTTP; Thu, 15 Jan 2015 15:29:01 -0800 (PST)
In-Reply-To: 
References:  <62165FC2-540D-48A5-A7AC-3D6D9087FDD2@gmail.com>  <75C82EF9-8800-453F-A489-10FD26E7F2CD@gmail.com>  
From: Eric Rescorla 
Date: Thu, 15 Jan 2015 15:29:01 -0800
Message-ID: 
To: Martin Thomson 
Content-Type: multipart/alternative; boundary=047d7bae493e02a864050cb93b97
Archived-At: 
Cc: Stephen Checkoway , "TLS@ietf.org \(tls@ietf.org\)" 
Subject: Re: [TLS] WGLC: draft-ietf-tls-session-hash
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Jan 2015 23:29:45 -0000

--047d7bae493e02a864050cb93b97
Content-Type: text/plain; charset=UTF-8

On Thu, Jan 15, 2015 at 3:21 PM, Martin Thomson 
wrote:

> On 15 January 2015 at 14:51, Eric Rescorla  wrote:
> > For sessions negotiated without EMS:
> > - SHOULD not resume
> > - MUST not resume sessions if the client offers EMS in the resumption
> >   (and therefore SHOULD do a complete negotiation).
> >
> > For sessions negotiated with EMS:
> > - The client ??? offer EMS
> > - The server MUST NOT echo it?
>
> Just to be clear, this latter part is...when renegotiating.
>

When resuming, right?




> My preference is: if the session had EMS, when renegotiating:
>  - the client MUST offer the extension, and
>  - the server MUST fail the handshake (new alert needed?) if the
> extension isn't present.
>
> That means no resumption, OR fallback to the complete handshake.
>
> I think that I'd prefer to have the server echo the extension in this
> case too.  It's a few bytes effectively wasted, but it makes
> everything nice and symmetrical.  Clients says "I want EMS" and server
> says "you got EMS".
>

I could live with this as well.

-Ekr

--047d7bae493e02a864050cb93b97
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Thu, Jan 15, 2015 at 3:21 PM, Martin Thomson <<=
a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson=
@gmail.com> wrote:
On 15 January 2015 at 14:51, Eric Rescorla <ekr@rtfm.com> wrote:

> For sessions negotiated without EMS:

> - SHOULD not resume

> - MUST not resume sessions if the client offers EMS in the resumption<=
br>
>=C2=A0 =C2=A0(and therefore SHOULD do a complete negotiation).

>

> For sessions negotiated with EMS:

> - The client ??? offer EMS

> - The server MUST NOT echo it?



Just to be clear, this latter part is...when renegotiating.

When resuming, right?

=

=C2=A0

My preference is: if the session had EMS, when renegotiating:

=C2=A0- the client MUST offer the extension, and

=C2=A0- the server MUST fail the handshake (new alert needed?) if the

extension isn't present.



That means no resumption, OR fallback to the complete handshake.



I think that I'd prefer to have the server echo the extension in this
case too.=C2=A0 It's a few bytes effectively wasted, but it makes

everything nice and symmetrical.=C2=A0 Clients says "I want EMS" =
and server

says "you got EMS".



I could live with t=
his as well.

-Ekr



--047d7bae493e02a864050cb93b97--


From nobody Thu Jan 15 15:33:24 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC7EB1A908D for ; Thu, 15 Jan 2015 15:33:22 -0800 (PST)
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 AWWF8SfLEXOc for ; Thu, 15 Jan 2015 15:33:21 -0800 (PST)
Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B5FA1A9089 for ; Thu, 15 Jan 2015 15:33:21 -0800 (PST)
Received: by mail-ob0-f169.google.com with SMTP id vb8so16309286obc.0 for ; Thu, 15 Jan 2015 15:33:21 -0800 (PST)
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=euCkdIoO4MTUY9jxnWlJRaeejna6YbWQrOTu8VBiCRg=; b=i7i6YzAOnAmqXg0FIyavsV1pdEIdtx5kOhdSj4heX+1leBwmnZQwIymNaZ5tjA0AFv CQ83f84iUq8UtRID71n9hlR/x9q1VbvZaPq6VBhoVTRGUEk7VHVdLOd84Z0YVuRPRqKe 6BfQWVe52VHq5Bosa+U+ypFZRPiuxMESscx83QUcab79gG3t3ofoF01QgHR1oj4nmVsT ic21/U+gQAdoDdYea47yA0ubaVI4pdFDV40kgLkNfq/eOhU1g7/PdhNBTbjDoxPyoJWU 4yQ1FYMi+S5/aKjfqxwTNN/T6IGp+LTTycx+yADCeUuiszGmz3m2jCVIvnVZXMbGBgv+ 1bHw==
MIME-Version: 1.0
X-Received: by 10.202.185.198 with SMTP id j189mr7245704oif.72.1421364800969;  Thu, 15 Jan 2015 15:33:20 -0800 (PST)
Received: by 10.202.226.136 with HTTP; Thu, 15 Jan 2015 15:33:20 -0800 (PST)
In-Reply-To: 
References:  <62165FC2-540D-48A5-A7AC-3D6D9087FDD2@gmail.com>  <75C82EF9-8800-453F-A489-10FD26E7F2CD@gmail.com>   
Date: Thu, 15 Jan 2015 15:33:20 -0800
Message-ID: 
From: Martin Thomson 
To: Eric Rescorla 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: Stephen Checkoway , "TLS@ietf.org \(tls@ietf.org\)" 
Subject: Re: [TLS] WGLC: draft-ietf-tls-session-hash
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Jan 2015 23:33:22 -0000

On 15 January 2015 at 15:29, Eric Rescorla  wrote:
> When resuming, right?

My bad, I seem to do that all the time.


From nobody Fri Jan 16 02:52:47 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D70A31ACD35 for ; Fri, 16 Jan 2015 02:52:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level: 
X-Spam-Status: No, score=-1.7 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_8BIT_HEADER=0.3, 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 TV4XRcGPgWYK for ; Fri, 16 Jan 2015 02:52:42 -0800 (PST)
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 84F1D1ACD2B for ; Fri, 16 Jan 2015 02:52:42 -0800 (PST)
Received: by mail-lb0-f172.google.com with SMTP id l4so5100106lbv.3 for ; Fri, 16 Jan 2015 02:52:41 -0800 (PST)
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:content-transfer-encoding; bh=KTOlw4bQTwblzRpQllgX8cbXVbvJow8W9d/Y4n71cAU=; b=twxuFzgyWK9hl/Y3v8/ynkXMcQmNGuKsAqaKNEVFXXK1HaQd+L0tDFYItJNnNw+QCv cDtzOWZQvusJCOnN8a4YjcGpyU4E5gOj+SYlrOgO15H1GA5eFd3y6krtTNkCEMiuXAKX voUl9dhdSXqJRcKIITAnObRqo58qfJxeRTC+MoN6JdIWF1BXB9AHTfmE9MpQ52ywyrLW qSwzDsQo6d6UbOgSUK3xHhYOe/8uuTJYnvBtDXhdbuULMgeNLoHTUMFFOK+rgc65Thpm x7D73aL8BMExX/Ck6LPoYHC3F0dccpBoNvVk+YLN0jS9vY2WUcdwupFBl1HJnHi77w6h K7RQ==
MIME-Version: 1.0
X-Received: by 10.152.88.44 with SMTP id bd12mr8671187lab.88.1421405561052; Fri, 16 Jan 2015 02:52:41 -0800 (PST)
Received: by 10.112.200.4 with HTTP; Fri, 16 Jan 2015 02:52:40 -0800 (PST)
In-Reply-To: 
References:  <62165FC2-540D-48A5-A7AC-3D6D9087FDD2@gmail.com>  <75C82EF9-8800-453F-A489-10FD26E7F2CD@gmail.com>   
Date: Fri, 16 Jan 2015 11:52:40 +0100
Message-ID: 
From: =?UTF-8?Q?Henrik_Grubbstr=C3=B6m?= 
To: Eric Rescorla 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: Stephen Checkoway , "TLS@ietf.org \(tls@ietf.org\)" 
Subject: Re: [TLS] WGLC: draft-ietf-tls-session-hash
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Jan 2015 10:52:44 -0000

On Fri, Jan 16, 2015 at 12:29 AM, Eric Rescorla  wrote:
>
> On Thu, Jan 15, 2015 at 3:21 PM, Martin Thomson 
> wrote:
>>
>> On 15 January 2015 at 14:51, Eric Rescorla  wrote:
>> > For sessions negotiated without EMS:
>> > - SHOULD not resume
>> > - MUST not resume sessions if the client offers EMS in the resumption
>> >   (and therefore SHOULD do a complete negotiation).
>> >
>> > For sessions negotiated with EMS:
>> > - The client ??? offer EMS
>> > - The server MUST NOT echo it?
>>
>> Just to be clear, this latter part is...when renegotiating.
>
> When resuming, right?

Maybe something like the following should be added in TLS 1.3?

A session MUST only be resumed if the server would create an
equivalent session (including the same server certificate and version
of TLS) on resumption failure. On resumption failure the session_id
provided in the ClientHello MUST be invalidated.

Such a rule would ensure that extensions like server_name,
max_fragment_length, truncated_hmac, encrypt_then_mac and
extended_master_secret (where relevant) are kept in the resumption
ClientHello, and that the connection won't be downgraded on resumption
failure.

>> My preference is: if the session had EMS, when renegotiating:
>>  - the client MUST offer the extension, and
>>  - the server MUST fail the handshake (new alert needed?) if the
>> extension isn't present.
>>
>> That means no resumption, OR fallback to the complete handshake.
>>
>> I think that I'd prefer to have the server echo the extension in this
>> case too.  It's a few bytes effectively wasted, but it makes
>> everything nice and symmetrical.  Clients says "I want EMS" and server
>> says "you got EMS".

Sounds good to me.

/grubba

--=20
Henrik Grubbstr=C3=B6m                                       grubba@grubba.=
org
Roxen Internet Software AB                              grubba@roxen.com


From nobody Fri Jan 16 03:09:20 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0DD71ACD70 for ; Fri, 16 Jan 2015 03:09:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.21
X-Spam-Level: 
X-Spam-Status: No, score=-1.21 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, 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 nUe-hWPgTZLS for ; Fri, 16 Jan 2015 03:09:09 -0800 (PST)
Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A15BA1ACD6F for ; Fri, 16 Jan 2015 03:09:09 -0800 (PST)
Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 8A5551A009D for ; Fri, 16 Jan 2015 12:08:58 +0100 (CET)
X-Virus-Scanned: by secunet
Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id BbGQ5j9mqLcI for ; Fri, 16 Jan 2015 12:08:56 +0100 (CET)
Received: from mail-essen-01.secunet.de (unknown [10.53.40.204]) by a.mx.secunet.com (Postfix) with ESMTP id C09F91A0096 for ; Fri, 16 Jan 2015 12:08:56 +0100 (CET)
Received: from [10.208.1.76] (10.208.1.76) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.224.2; Fri, 16 Jan 2015 12:09:05 +0100
Message-ID: <54B8F151.5040604@secunet.com>
Date: Fri, 16 Jan 2015 12:09:05 +0100
From: Johannes Merkle 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: 
References: <525BADBD.8020007@secunet.com> <54B67A19.9010507@redhat.com>  <20150115013149.0185bea4@pc> 
In-Reply-To: 
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.208.1.76]
X-EXCLAIMER-MD-CONFIG: 2c86f778-e09b-4440-8b15-867914633a10
Archived-At: 
Subject: Re: [TLS] Using RSA PSS in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Jan 2015 11:09:17 -0000

> You *cannot* do PKCS 1.5 encryption right. The countermeasures to
> Bleichenbacher depend on enforcing additional structure on the
> messages, which SSL imposed by accident. As everyone should know, many
> implementations still do not get this right. (Can't name which ones,
> but even if they make the check, they may expose timing channels that
> are exploitable: there was a German PhD thesis a year or two ago that
> investigated exactly this, and broke some Java implementations).

Jager, Schinzel and Somorovsky also showed how XML encryption is vulnerably and there was also this report about
practical attacks against hardware implementations:
https://eprint.iacr.org/2012/417


-- 
Johannes


From nobody Fri Jan 16 04:52:34 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F23011ACDC8 for ; Fri, 16 Jan 2015 04:52:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.096
X-Spam-Level: *
X-Spam-Status: No, score=1.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.793, 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 HwGiKVOVIS7S for ; Fri, 16 Jan 2015 04:52:30 -0800 (PST)
Received: from vps2.offspark.com (unknown [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93EAD1ACDCF for ; Fri, 16 Jan 2015 04:52:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim;  h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:CC:To:MIME-Version:From:Date:Message-ID; bh=offjyzz+Vjs3VaV+MWSW/eo1MYf0B3ZMT5n7q4fkIs0=;  b=K3qfr5NGOAOmAmICrHToFF68RwnKEMXOeCwQXzYtCQlG5duaBygan5e+Knk4zJSnBoTWTzqml6+Ry5LA2l8X4avzVHhMgrIpq5c/ze+GLyxPUTUGeapKKbpKv5sXFkkCVNZzukaYoWjOT8MkrCOD/HQz3L5E4Fh0MwG5Gpiv/XA=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YC6Nr-0000Iz-0h; Fri, 16 Jan 2015 13:52:15 +0100
Message-ID: <54B90989.1030401@polarssl.org>
Date: Fri, 16 Jan 2015 13:52:25 +0100
From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Geoffrey Keating , mrex@sap.com
References: <20150115013149.0185bea4@pc> <20150115005032.1FBC41B0EA@ld9781.wdf.sap.corp> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: 
Cc: tls@ietf.org
Subject: Re: [TLS] Using RSA PSS in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Jan 2015 12:52:32 -0000

On 15/01/2015 03:11, Geoffrey Keating wrote:
> mrex@sap.com (Martin Rex) writes:
> 
>> If the spec was tightened to prohibit *all* kinds of parsing
>> of the RSA-decrypted BT01 padding signature plaintext,
>> and instead required rebuilding of the BT01 padding from the input hash
>> value and input hash oid, and comparison of the newly composed result
>> with what the RSA decryption returned, then none of the parser problems
>> for RSA PKCS#1 v1.5 signatures would have existed.
>>
>> That approach to RSA signature verification is actually the one
>> recommended by PKCS#1 v2.1 for the RSASSA-PKCS1-V1_5-VERIFY operation.
>>
>>   https://tools.ietf.org/html/rfc3447#section-8.2.2
> 
> Would this actually work?  I suspect implementations use slightly
> inconsistent padding generation...
> 
Appparently [1] NSS and BoringSSL has been doing that for a few months now
(though NSS seems to take steps to allow some variation), maybe they could
provide some feedback?

[1]: https://www.imperialviolet.org/2014/09/26/pkcs1.html

Manuel


From nobody Fri Jan 16 07:27:27 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 328121ACD74 for ; Fri, 16 Jan 2015 07:27:26 -0800 (PST)
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 7caGiLJrx2jB for ; Fri, 16 Jan 2015 07:27:24 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0733.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::733]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E862D1ACD73 for ; Fri, 16 Jan 2015 07:27:23 -0800 (PST)
Received: from BN1PR09MB0258.namprd09.prod.outlook.com (25.160.80.19) by BN1PR09MB0257.namprd09.prod.outlook.com (25.160.80.18) with Microsoft SMTP Server (TLS) id 15.1.59.20; Fri, 16 Jan 2015 15:27:00 +0000
Received: from BN1PR09MB0258.namprd09.prod.outlook.com ([25.160.80.19]) by BN1PR09MB0258.namprd09.prod.outlook.com ([25.160.80.19]) with mapi id 15.01.0059.007; Fri, 16 Jan 2015 15:27:00 +0000
From: "Dang, Quynh" 
To: "tls@ietf.org" 
Thread-Topic: Singular or multiple NamedGroup(s)  in the "HelloRetryRequest"
Thread-Index: AQHQMaBYsYs5DZhf6k+RjnoRkswrlw==
Date: Fri, 16 Jan 2015 15:26:59 +0000
Message-ID: <1421422017019.67267@nist.gov>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [132.163.219.31]
authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; 
x-dmarcaction-test: None
x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:BN1PR09MB0257;
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB0257;
x-forefront-prvs: 04583CED1A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(53754006)(2900100001)(62966003)(110136001)(77156002)(66066001)(68736005)(2501002)(64706001)(97736003)(36756003)(102836002)(86362001)(46102003)(2656002)(16236675004)(87936001)(40100003)(92566002)(122556002)(101416001)(19625215002)(2351001)(50986999)(54356999)(229853001)(106356001)(105586002)(106116001)(19627405001)(117636001)(99286002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB0257; H:BN1PR09MB0258.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:3; A:3; LANG:en; 
received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts)
Content-Type: multipart/alternative; boundary="_000_142142201701967267nistgov_"
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jan 2015 15:26:59.9093 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB0257
Archived-At: 
Subject: [TLS] Singular or multiple NamedGroup(s) in the "HelloRetryRequest"
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Jan 2015 15:27:26 -0000

--_000_142142201701967267nistgov_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi all,


It seems to be fine to improve inter-operability (or efficiency: less back =
and forth) by allowing multiple groups (multiple "NamedGroup"s) in the "Hel=
loRetryRequest" message since a server might be willing to accept 2 (or mor=
e) groups for a particular key exchange method. For example,  a client migh=
t offer only one FFDH group in its Client Key Share message and the server =
is willing to offer two higher level security groups for the client to choo=
se from.


The situation would be similar if we had 3 or more curves.


Quynh.

--_000_142142201701967267nistgov_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable










Hi all,









It seems to be fine to improve inter-operability (or efficiency: le=
ss back and forth) by allowing multiple groups (multiple "NamedGr=
oup"s) in the "HelloRetryRequest" message since a serve=
r might be willing to accept 2 (or more) groups for a particular =
key
 exchange method. For example,  a client might offer only one FFDH gro=
up in its Client Key Share message and the server is willing to offer two h=
igher level security groups for the client to choose from. 









The situation would be similar if we had 3 or more curves.









Quynh. 








--_000_142142201701967267nistgov_--


From nobody Fri Jan 16 07:45:36 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10B021ACD31 for ; Fri, 16 Jan 2015 07:45:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 fxEa3kWQtxjI for ; Fri, 16 Jan 2015 07:45:31 -0800 (PST)
Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5FD71ACD2C for ; Fri, 16 Jan 2015 07:45:30 -0800 (PST)
Received: by mail-we0-f170.google.com with SMTP id w61so20967189wes.1 for ; Fri, 16 Jan 2015 07:45:29 -0800 (PST)
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:from:date :message-id:subject:to:cc:content-type; bh=dnq4yaHj4qbVPAOKAV3FKC9ZSPFwwhWyr/IxzKJ6qUc=; b=XVGvlG0AnFPZ0nWqD8A+NJI3ngC/MvA+/n6vgAGdNi47APhfo2pcPfGhHKE7LpBbwt Ptpth27A0Nb3ilgZJvqTzDsIHZl28DUrnbcKt288OkIzuOXUzDO5vEmE17n0kkb5gFAs SnlM4HxHPKKlil7+n68VR/VMI/yMq5Q5VzF1FmV2/hXK1Bu3LEe+B3d7p3OLnagqrlUG mn2Li10/2urgiijlkIW1UxMX1/SkHTjnw6Ih6iAzSZsRjxbK732qKI9wrQ69/nncbLGj iS02YkF/SdW63OavA0ncRxuwYBk59Ex05fzDHT1zbPUphTL6iPaGxw8UzjRhRl/5gL4d ZMQw==
X-Gm-Message-State: ALoCoQl82PJ7S+IBlpfWiG4Fb/3nqPsgZB+Zg+XtSidAe/0K7sCUuTe37WkHNJO/rcM0O/5sdKSE
X-Received: by 10.194.203.104 with SMTP id kp8mr25849865wjc.103.1421423129532;  Fri, 16 Jan 2015 07:45:29 -0800 (PST)
MIME-Version: 1.0
Received: by 10.27.142.215 with HTTP; Fri, 16 Jan 2015 07:44:44 -0800 (PST)
In-Reply-To: <1421422017019.67267@nist.gov>
References: <1421422017019.67267@nist.gov>
From: Eric Rescorla 
Date: Fri, 16 Jan 2015 07:44:44 -0800
Message-ID: 
To: "Dang, Quynh" 
Content-Type: multipart/alternative; boundary=047d7bae493eb634f6050cc6dcb9
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Singular or multiple NamedGroup(s) in the "HelloRetryRequest"
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Jan 2015 15:45:33 -0000

--047d7bae493eb634f6050cc6dcb9
Content-Type: text/plain; charset=UTF-8

Note that the client advertises all the groups it can support, so the server
can just pick the "best" one on the clients list.

-Ekr


On Fri, Jan 16, 2015 at 7:26 AM, Dang, Quynh  wrote:

>  Hi all,
>
>
>  It seems to be fine to improve inter-operability (or efficiency: less
> back and forth) by allowing multiple groups (multiple "NamedGroup"s) in the
> "HelloRetryRequest" message since a server might be willing to accept 2 (or
> more) groups for a particular key exchange method. For example,  a client
> might offer only one FFDH group in its Client Key Share message and the
> server is willing to offer two higher level security groups for the client
> to choose from.
>
>
>  The situation would be similar if we had 3 or more curves.
>
>
>  Quynh.
>

--047d7bae493eb634f6050cc6dcb9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Note that the client advertises all the groups it can supp=
ort, so the server
can just pick the "best" one on the client=
s list.

-Ekr


On Fri, Jan 16, 2015 at 7:26 AM, Dang, Q=
uynh <quynh.dang@nist.gov> wrote:










Hi all,









It seems to be fine to improve inter-operability (or=C2=A0efficiency: le=
ss back and forth)=C2=A0by allowing multiple groups (multiple "NamedGr=
oup"s)=C2=A0in the "HelloRetryRequest" message since a serve=
r=C2=A0might be willing to accept 2=C2=A0(or more) groups for a particular =
key
 exchange method. For example, =C2=A0a client might offer only one FFDH gro=
up in its Client Key Share message and the server is willing to offer two h=
igher level=C2=A0security groups for the client to choose from.=C2=A0









The situation would be similar if we had 3 or more curves.









Quynh.=C2=A0












--047d7bae493eb634f6050cc6dcb9--


From nobody Fri Jan 16 07:51:28 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0A481ACD3A for ; Fri, 16 Jan 2015 07:51:25 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, 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 Rf1LT1Sa-x94 for ; Fri, 16 Jan 2015 07:51:23 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0102.outbound.protection.outlook.com [207.46.100.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4073A1ACD46 for ; Fri, 16 Jan 2015 07:51:23 -0800 (PST)
Received: from BN1PR09MB0258.namprd09.prod.outlook.com (25.160.80.19) by BN1PR09MB0257.namprd09.prod.outlook.com (25.160.80.18) with Microsoft SMTP Server (TLS) id 15.1.59.20; Fri, 16 Jan 2015 15:51:21 +0000
Received: from BN1PR09MB0258.namprd09.prod.outlook.com ([25.160.80.19]) by BN1PR09MB0258.namprd09.prod.outlook.com ([25.160.80.19]) with mapi id 15.01.0059.007; Fri, 16 Jan 2015 15:51:21 +0000
From: "Dang, Quynh" 
To: Eric Rescorla 
Thread-Topic: Singular or multiple NamedGroup(s) in the "HelloRetryRequest"
Thread-Index: AQHQMaN2uE7AF8cZjk6SMXFDlBGPL5zC5FIB
Date: Fri, 16 Jan 2015 15:51:21 +0000
Message-ID: <1421423478675.87032@nist.gov>
References: <1421422017019.67267@nist.gov>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [132.163.219.31]
authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; 
x-dmarcaction-test: None
x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:BN1PR09MB0257;
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB0257;
x-forefront-prvs: 04583CED1A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(53754006)(199003)(24454002)(189002)(19580405001)(101416001)(122556002)(19625215002)(19580395003)(92566002)(117636001)(76176999)(19627405001)(99286002)(54356999)(50986999)(106356001)(105586002)(106116001)(64706001)(2950100001)(2900100001)(62966003)(66066001)(77156002)(68736005)(110136001)(40100003)(86362001)(46102003)(102836002)(97736003)(36756003)(87936001)(16236675004)(2656002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB0257; H:BN1PR09MB0258.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts)
Content-Type: multipart/alternative; boundary="_000_142142347867587032nistgov_"
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jan 2015 15:51:21.6517 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB0257
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Singular or multiple NamedGroup(s) in the "HelloRetryRequest"
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Jan 2015 15:51:25 -0000

--_000_142142347867587032nistgov_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

?If a client offers all of the options it supports and a server sends back =
one group out of these options, it would guarantee a failure.


Quynh.

________________________________
From: Eric Rescorla 
Sent: Friday, January 16, 2015 10:44 AM
To: Dang, Quynh
Cc: tls@ietf.org
Subject: Re: Singular or multiple NamedGroup(s) in the "HelloRetryRequest"

Note that the client advertises all the groups it can support, so the serve=
r
can just pick the "best" one on the clients list.

-Ekr


On Fri, Jan 16, 2015 at 7:26 AM, Dang, Quynh > wrote:

Hi all,


It seems to be fine to improve inter-operability (or efficiency: less back =
and forth) by allowing multiple groups (multiple "NamedGroup"s) in the "Hel=
loRetryRequest" message since a server might be willing to accept 2 (or mor=
e) groups for a particular key exchange method. For example,  a client migh=
t offer only one FFDH group in its Client Key Share message and the server =
is willing to offer two higher level security groups for the client to choo=
se from.


The situation would be similar if we had 3 or more curves.


Quynh.


--_000_142142347867587032nistgov_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable










​If a client offers all of the options it supports and a server se=
nds back one group out of these options, it would guarantee a failure. =
;









Quynh. 








From: Eric Rescorla <ekr=
@rtfm.com>

Sent: Friday, January 16, 2015 10:44 AM

To: Dang, Quynh

Cc: tls@ietf.org

Subject: Re: Singular or multiple NamedGroup(s) in the "HelloRe=
tryRequest"

 






Note that the client advertises all the groups it can supp=
ort, so the server

can just pick the "best" one on the clients list.







-Ekr








On Fri, Jan 16, 2015 at 7:26 AM, Dang, Quynh 
<quynh.dang@nis=
t.gov> wrote:








Hi all,









It seems to be fine to improve inter-operability (or efficiency: le=
ss back and forth) by allowing multiple groups (multiple "NamedGr=
oup"s) in the "HelloRetryRequest" message since a serve=
r might be willing to accept 2 (or more) groups for a particular =
key
 exchange method. For example,  a client might offer only one FFDH gro=
up in its Client Key Share message and the server is willing to offer two h=
igher level security groups for the client to choose from. 









The situation would be similar if we had 3 or more curves.










Quynh. 




























--_000_142142347867587032nistgov_--


From nobody Fri Jan 16 07:58:51 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D20041ACE6D for ; Fri, 16 Jan 2015 07:58:40 -0800 (PST)
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 KEdipTa8C1kX for ; Fri, 16 Jan 2015 07:58:39 -0800 (PST)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3B9A1ACD77 for ; Fri, 16 Jan 2015 07:58:38 -0800 (PST)
Received: by mail-we0-f172.google.com with SMTP id k11so20962475wes.3 for ; Fri, 16 Jan 2015 07:58:37 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=5TY4O8X7KJwSUa5hwnEko1MJF05M/rD3belme4znCbs=; b=Q3t3mxacNq2LUJdvDVMcm7r854Bp4PJmNpgwGWUxN3w6axqewn6f5A1md7IMTyw8mg jkNIbsKi+wkulfDtLRrtYAdbvfZ5AjMo7pieZvvI78PGB1B5L4hL53nTlFCQ8Z51IAw3 +Fg0aggk2UpcXBbUYO1iLlcKEWpXgDNWBrl/tTHb4j28H/Ehhqhr/M9JU6itDGghuEoZ FOu3rqsZuc7TXf8gTo1UvmjHnnrhkW+RzWYOtOUU3IRrAHOF6AYEF9tGSOWPTw1g4w7u ATRkGdrKWubbYXjkrXSU5+lZeljMCWOpYZm/cgWRH3WGzyNYxJ9IYr+7Ttgtt6jQiFQD hKBg==
X-Gm-Message-State: ALoCoQnT4coO7XwCekX2Vz9XXCV/L59qea1hGOFHfvMZcPs8XxMZdKfDTSoCQioHBBJxh+ulrMft
X-Received: by 10.194.48.109 with SMTP id k13mr31009101wjn.7.1421423917565; Fri, 16 Jan 2015 07:58:37 -0800 (PST)
Received: from [172.16.1.25] ([188.21.236.102]) by mx.google.com with ESMTPSA id fo2sm3529844wib.10.2015.01.16.07.58.36 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 16 Jan 2015 07:58:36 -0800 (PST)
Message-ID: <54B9352C.70203@azet.org>
Date: Fri, 16 Jan 2015 16:58:36 +0100
From: Aaron Zauner 
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: TLS Mailing List 
References: <54B5501A.4070402@azet.org>  <54B58F5B.2010704@cs.tcd.ie> <54B6815A.7060102@azet.org> 
In-Reply-To: 
X-Enigmail-Version: 1.2.3
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigF570DBF206B4B1DF33E71E07"
Archived-At: 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Jan 2015 15:58:41 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigF570DBF206B4B1DF33E71E07
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

I came up with the following list of cipher-suites applicable to >=3D TLS=
 1.2:

(EC)DHE:
TLS_DHE_RSA_WITH_AES_128_OCB=09
TLS_DHE_RSA_WITH_AES_256_OCB
TLS_ECDHE_RSA_WITH_AES_128_OCB
TLS_ECDHE_RSA_WITH_AES_256_OCB
TLS_ECDHE_ECDSA_WITH_AES_128_OCB
TLS_ECDHE_ECDSA_WITH_AES_256_OCB

PSK:
TLS_DHE_PSK_WITH_AES_128_OCB
TLS_DHE_PSK_WITH_AES_256_OCB=09
TLS_ECDHE_PSK_WITH_AES_128_OCB
TLS_ECDHE_PSK_WITH_AES_256_OCB

As for the nonce, would it make sense to use a 128bit nonce for both
AES128 and AES256 instead of 64/128 (see:
https://www.imperialviolet.org/2014/05/25/strengthmatching.html)?

What about SRP? Gone in 1.3? I tend to like SRP although it's rarely used=
=2E

Any objections, additions and/or comments?

Aaron


--------------enigF570DBF206B4B1DF33E71E07
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUuTUsAAoJEOTbZJL9ubXVGUsP/0XbBJ5mGZHkq7N4JQvSk0Vc
vjTaBuxFlzF3U0pWON9MkGANKGIUn5a0I6XEAFo+F8pOEe6V47c0Oi9gr8tos/iz
q5WTtfYuLK7QRXDD+Iir4ZTMSBi7HDa3erNpsKXALLgLAUPdHdkjigxjBGo6ggjL
2LzWbfJSlBYFVEsO5ziNqyBse6sdg89pUpar2P0MEuW42YWxgEHHON8vMJ0XXBzU
fNylxWBmtjuM6mkvfihgmtmDtKeUGDeYlyUcP3yG0YsDi2TiQdqQrnVuCXw3cYH3
iIwhdxSwHPrqmHIiw7SkqAFv1nvHduDqqv5a41YIGZun0E4niEMJtZAw9aLdXICN
Dc2INGMdVu6WCsXmqRV3RRbYMLQWLsJg5i1uYOASH2lAZYyiRGSjabGT0z/+7wMe
tctacOWry4fkaL2le/i41p0WXeWb8OWCMDAcyo5dO/NijWlcpmC6cJkk3NQrThBR
opiqGoC5EP5zds3dnH/p427K0osGjif7uhmMaWUv/cLVTiNVKIkVZTh69gZl5J2i
dS4T5VwcnFV0NTYP5RAoc8pNdo+EIJYLLWH3/COBwo2tbRceSNQWxJn3HOzqC4XB
ithR9g/Llc01e2HdIJ5Xl6PFeLS9eRsHgautSY0PgYzO8yChvJl3cXqwNGVRJuLL
0YdItDjNXyzz3nmd451K
=5dBl
-----END PGP SIGNATURE-----

--------------enigF570DBF206B4B1DF33E71E07--


From nobody Fri Jan 16 08:29:54 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E98D01ACEB0 for ; Fri, 16 Jan 2015 08:29:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level: 
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] 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 yAG4yQx1gWUc for ; Fri, 16 Jan 2015 08:29:52 -0800 (PST)
Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D732A1ACCED for ; Fri, 16 Jan 2015 08:29:52 -0800 (PST)
Received: from [10.20.30.90] (50-1-98-91.dsl.dynamic.fusionbroadband.com [50.1.98.91]) (authenticated bits=0) by proper.com (8.15.1/8.14.7) with ESMTPSA id t0GGTp6Q025865 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Jan 2015 09:29:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: proper.com: Host 50-1-98-91.dsl.dynamic.fusionbroadband.com [50.1.98.91] claimed to be [10.20.30.90]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Paul Hoffman 
In-Reply-To: 
Date: Fri, 16 Jan 2015 08:29:50 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <1421422017019.67267@nist.gov> 
To: Eric Rescorla 
X-Mailer: Apple Mail (2.1993)
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Singular or multiple NamedGroup(s) in the "HelloRetryRequest"
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Jan 2015 16:29:54 -0000

On Jan 16, 2015, at 7:44 AM, Eric Rescorla  wrote:
> Note that the client advertises all the groups it can support, so the =
server
> can just pick the "best" one on the clients list.

I think what Quynh wants is to turn the HelloRetryRequest into an =
advertisement for the server's capabilities, and having that =
advertisement be longer than 1 would be better. That is, it would be =
"We're failing and I'm choosing none of yours, but if you retry and can =
do any of these, please do so".

I'm not saying I like that idea, and I waffled a lot on it in IKEv2, but =
it is a common proposal for how to do negotiation (as compared to =
"offer-pick").

--Paul Hoffman=


From nobody Fri Jan 16 08:34:19 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAF731ACEC1 for ; Fri, 16 Jan 2015 08:34:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 cyl7k7uMc5uG for ; Fri, 16 Jan 2015 08:34:09 -0800 (PST)
Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A64C21ACEC2 for ; Fri, 16 Jan 2015 08:33:48 -0800 (PST)
Received: by mail-wi0-f176.google.com with SMTP id z2so1636321wiv.3 for ; Fri, 16 Jan 2015 08:33:47 -0800 (PST)
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:from:date :message-id:subject:to:cc:content-type; bh=rpJyXDdFQjVjRx+YjCx4gFhOBMyym17lYwOIUi26N9o=; b=QpsinllErqWrMSKNRRf8JCWC6mL5z39ZiIcqCNl+dIh0UOUkKQeaXVs6Rocg7DSNzy 6FgymjTIbx35jVmPYC+yj3zGr84SlQ2WVZBysxf70/63fDEGSt7yU1DXzjdGqXFCLBLJ dO0Zdpzx9Tc9GDmqr39R2b1eAP9VVGH7f0i+znTLEmZDyHcdwiWgtDPPDiHPz8OaPp0h mgifFcSktwICwnfbGVeWVdnlRcAxv7rog7r5lnUNwU3CByJMv/mpv9bY3xYqW48VRKYJ 9OaRn+emlU28TEsrtDBBnvNF/UAf7ytK3WM1vjLa470DqUHnztnMUqw9RXcZPoXg83e0 Eg3Q==
X-Gm-Message-State: ALoCoQk4Snljt1Oscf/fL698yg9gT0/S0zZ7mRXgIokV5C0Rq8HR4pY6z6pfsQYuZeDHz+KHEt/K
X-Received: by 10.180.85.35 with SMTP id e3mr7833218wiz.14.1421426027358; Fri, 16 Jan 2015 08:33:47 -0800 (PST)
MIME-Version: 1.0
Received: by 10.27.142.215 with HTTP; Fri, 16 Jan 2015 08:33:07 -0800 (PST)
In-Reply-To: <1421423478675.87032@nist.gov>
References: <1421422017019.67267@nist.gov>  <1421423478675.87032@nist.gov>
From: Eric Rescorla 
Date: Fri, 16 Jan 2015 08:33:07 -0800
Message-ID: 
To: "Dang, Quynh" 
Content-Type: multipart/alternative; boundary=f46d041824f66f864a050cc78991
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Singular or multiple NamedGroup(s) in the "HelloRetryRequest"
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Jan 2015 16:34:12 -0000

--f46d041824f66f864a050cc78991
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Jan 16, 2015 at 7:51 AM, Dang, Quynh  wrote:

>  =E2=80=8BIf a client offers all of the options it supports and a server =
sends
> back one group out of these options, it would guarantee a failure.
>

I don't understand. The client sends a list of all the groups it supports
and a ClientKeyShare with a subset of those groups. If the server doesn't
support any group in the ClientKeyShare it sends back HRR with a single
group out of the clients larger set that the client needs to respond with.
How does that guarantee a failure?

-Ekr

Quynh.
>  ------------------------------
> *From:* Eric Rescorla 
> *Sent:* Friday, January 16, 2015 10:44 AM
> *To:* Dang, Quynh
> *Cc:* tls@ietf.org
> *Subject:* Re: Singular or multiple NamedGroup(s) in the
> "HelloRetryRequest"
>
>  Note that the client advertises all the groups it can support, so the
> server
> can just pick the "best" one on the clients list.
>
>  -Ekr
>
>
> On Fri, Jan 16, 2015 at 7:26 AM, Dang, Quynh  wrote:
>
>>  Hi all,
>>
>>
>>  It seems to be fine to improve inter-operability (or efficiency: less
>> back and forth) by allowing multiple groups (multiple "NamedGroup"s) in =
the
>> "HelloRetryRequest" message since a server might be willing to accept 2 =
(or
>> more) groups for a particular key exchange method. For example,  a clien=
t
>> might offer only one FFDH group in its Client Key Share message and the
>> server is willing to offer two higher level security groups for the clie=
nt
>> to choose from.
>>
>>
>>  The situation would be similar if we had 3 or more curves.
>>
>>
>>  Quynh.
>>
>
>

--f46d041824f66f864a050cc78991
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Fri, Jan 16, 2015 at 7:51 AM, Dang, Quynh <quynh.dang@nist.gov> wrote:










=E2=80=8BIf a client offers all of the options it supports and a server =
sends back one group out of these options, it would guarantee a failure.=C2=
=A0

I don't understand.=
 The client sends a list of all the groups it supports
and a Clie=
ntKeyShare with a subset of those groups. If the server doesn't
support any group in the ClientKeyShare it sends back HRR with a single<=
/div>
group out of the clients larger set that the client needs to resp=
ond with.
How does that guarantee a failure?

=

-Ekr



Quynh.=C2=A0












Note that the client advertises all the groups it can supp=
ort, so the server

can just pick the "best" one on the clients list.







-Ekr








On Fri, Jan 16, 2015 at 7:26 AM, Dang, Quynh 
<quynh.dang@nis=
t.gov> wrote:








Hi all,









It seems to be fine to improve inter-operability (or=C2=A0efficiency: le=
ss back and forth)=C2=A0by allowing multiple groups (multiple "NamedGr=
oup"s)=C2=A0in the "HelloRetryRequest" message since a serve=
r=C2=A0might be willing to accept 2=C2=A0(or more) groups for a particular =
key
 exchange method. For example, =C2=A0a client might offer only one FFDH gro=
up in its Client Key Share message and the server is willing to offer two h=
igher level=C2=A0security groups for the client to choose from.=C2=A0









The situation would be similar if we had 3 or more curves.










Quynh.=C2=A0
































--f46d041824f66f864a050cc78991--


From nobody Fri Jan 16 08:35:34 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF3D1ACDCE for ; Fri, 16 Jan 2015 08:35:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 PupXIAOnkTU0 for ; Fri, 16 Jan 2015 08:35:30 -0800 (PST)
Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 623191ACEB9 for ; Fri, 16 Jan 2015 08:35:30 -0800 (PST)
Received: by mail-we0-f171.google.com with SMTP id u56so21190662wes.2 for ; Fri, 16 Jan 2015 08:35:29 -0800 (PST)
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:from:date :message-id:subject:to:cc:content-type; bh=NOWTcj8JCRN5m8Fsj1an1Y98Y2YZXgoUwasxiaK4X6M=; b=cgrMCKTDXihsJ7mwY/kaGBAzjSdYucHwqUvOXy+VDEHpNbg7wbsVLaCITHdJUDFGw2 pT7i37A7w40zyvXS85YSwjV+XKvo/Q183nehFwOnK7AWFtiqRDBPsq7RP5ra8iS5HqOy NPm7hALEGEZYq71e5IM3RkRfQQDBbmZ7Hed8ZsHVifs5WOACP1idamUa0LrPvCwZcvjk 73spcjEq0Q7eEB/VyDUDY7iCKpqNH42FJhrZ/GtsYX/8mZPUNn7XjES8w4wOw1/Jl3LT AMw6qEOgRaG7N3H7O9nBcras4fYA9s7iSpT3WXeBgC8CWpMICrEQ9szWaedEAEG1OOfi bZWQ==
X-Gm-Message-State: ALoCoQkJJLyuJn3WNeActlDRwVG+HTrHko30YCHqn7EYtk4u7thWtZGQLxRDTHms60Xx2Tiy+AQM
X-Received: by 10.181.13.42 with SMTP id ev10mr7779071wid.78.1421426129128; Fri, 16 Jan 2015 08:35:29 -0800 (PST)
MIME-Version: 1.0
Received: by 10.27.142.215 with HTTP; Fri, 16 Jan 2015 08:34:46 -0800 (PST)
In-Reply-To: 
References: <1421422017019.67267@nist.gov>  
From: Eric Rescorla 
Date: Fri, 16 Jan 2015 08:34:46 -0800
Message-ID: 
To: Paul Hoffman 
Content-Type: multipart/alternative; boundary=f46d04388df180673f050cc78fac
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Singular or multiple NamedGroup(s) in the "HelloRetryRequest"
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Jan 2015 16:35:32 -0000

--f46d04388df180673f050cc78fac
Content-Type: text/plain; charset=UTF-8

On Fri, Jan 16, 2015 at 8:29 AM, Paul Hoffman  wrote:

> On Jan 16, 2015, at 7:44 AM, Eric Rescorla  wrote:
> > Note that the client advertises all the groups it can support, so the
> server
> > can just pick the "best" one on the clients list.
>
> I think what Quynh wants is to turn the HelloRetryRequest into an
> advertisement for the server's capabilities, and having that advertisement
> be longer than 1 would be better. That is, it would be "We're failing and
> I'm choosing none of yours, but if you retry and can do any of these,
> please do so".
>
> I'm not saying I like that idea, and I waffled a lot on it in IKEv2, but
> it is a common proposal for how to do negotiation (as compared to
> "offer-pick").
>

Sure, but that basically just pushes the choice back on the client. What's
the
advantage of that?

-Ekr

--f46d04388df180673f050cc78fac
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On F=
ri, Jan 16, 2015 at 8:29 AM, Paul Hoffman <paul.hoffman@vpnc.org&g=
t; wrote:
On Jan =
16, 2015, at 7:44 AM, Eric Rescorla <ekr=
@rtfm.com> wrote:

> Note that the client advertises all the groups it can support, so the =
server

> can just pick the "best" one on the clients list.



I think what Quynh wants is to turn the HelloRetryRequest into an ad=
vertisement for the server's capabilities, and having that advertisemen=
t be longer than 1 would be better. That is, it would be "We're fa=
iling and I'm choosing none of yours, but if you retry and can do any o=
f these, please do so".



I'm not saying I like that idea, and I waffled a lot on it in IKEv2, bu=
t it is a common proposal for how to do negotiation (as compared to "o=
ffer-pick").

Sure, but that basica=
lly just pushes the choice back on the client. What's the
adv=
antage of that?

-Ekr
=C2=A0


--f46d04388df180673f050cc78fac--


From nobody Fri Jan 16 08:44:14 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18AF41ACED0 for ; Fri, 16 Jan 2015 08:44:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level: 
X-Spam-Status: No, score=-1.7 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_8BIT_HEADER=0.3, 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 D7KI2cc0abxD for ; Fri, 16 Jan 2015 08:44:10 -0800 (PST)
Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 018911ACEB6 for ; Fri, 16 Jan 2015 08:44:10 -0800 (PST)
Received: by mail-la0-f46.google.com with SMTP id ge10so10098964lab.5 for ; Fri, 16 Jan 2015 08:44:08 -0800 (PST)
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:content-transfer-encoding; bh=7bbZQN/BrKLq/HLyod+fDoEarrr72r8gSBg/VZUzSOA=; b=RrV4jdhtmjiSkvkgLze4B2mbvGEM7MRbGPhV9KFOEWFUFQ1XmkzhllEEll3TBCO2GA 5oqD19hdxqYxlA7+brvH0SvOl0BTF9weSJzpgdx1cE5iF063h7MAfwUk0HEILr2piLMU mYiacGomGtAzFUWEazXdMXDPE2dKQr+blLIJvnmV2CvhZmvd/UYs4y1l0YoUhwKG6igh P+nw53BwwGMtXYeW9hUerB+DtcpEHWgTQnbAFz5rmgqMccEFCp2fObzpr//ypkJM8G/a JjJwnPmijmf+thUxu73hQ4foQjifOQCFEfS8IDienCFVP/EnrYtQlH/pwNhFNEcGhRjY Y0iQ==
MIME-Version: 1.0
X-Received: by 10.152.203.201 with SMTP id ks9mr16361827lac.57.1421426648476;  Fri, 16 Jan 2015 08:44:08 -0800 (PST)
Received: by 10.112.200.4 with HTTP; Fri, 16 Jan 2015 08:44:08 -0800 (PST)
In-Reply-To: <1421423478675.87032@nist.gov>
References: <1421422017019.67267@nist.gov>  <1421423478675.87032@nist.gov>
Date: Fri, 16 Jan 2015 17:44:08 +0100
Message-ID: 
From: =?UTF-8?Q?Henrik_Grubbstr=C3=B6m?= 
To: "Dang, Quynh" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Singular or multiple NamedGroup(s) in the "HelloRetryRequest"
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Jan 2015 16:44:12 -0000

On Fri, Jan 16, 2015 at 4:51 PM, Dang, Quynh  wrote:
> If a client offers all of the options it supports and a server sends back
> one group out of these options, it would guarantee a failure.

It seems you've misunderstood; the client announces all named groups
that it supports in the named_group extension, but usually only
provides a subset of these in its ClientKeyShare message. Thus the
server can ask for a named group that the client supports but hasn't
provided a key share for in its HelloRetry.

/grubba

--=20
Henrik Grubbstr=C3=B6m                                       grubba@grubba.=
org
Roxen Internet Software AB                              grubba@roxen.com


From nobody Fri Jan 16 08:47:12 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52C1C1ACEF1 for ; Fri, 16 Jan 2015 08:47:10 -0800 (PST)
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 KKeNiR2T74Mv for ; Fri, 16 Jan 2015 08:47:09 -0800 (PST)
Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A665D1ACEE1 for ; Fri, 16 Jan 2015 08:47:08 -0800 (PST)
Received: by mail-wi0-f169.google.com with SMTP id bs8so5576284wib.0 for ; Fri, 16 Jan 2015 08:47:07 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=rbrpCkijktNW5G3/zrxvwvGEkVQd+CkAtHBosi//J+s=; b=TEf4B+dW2CxWugt6DCZxYYBVuKzNC8YgCq90hqN3ASoYKufsjVarSt4aQl8I4xdCUs 7ee1uJRkbby47BYFgZjqCyaGIId5FOx/DoEbP56SCEKdWk0g4E0QartDCh2jnsdJnbSI e4CGM7iqMpbr1c3G8jpJltUff3lMCs57mEnvZE5WLrP0wZzdGtNM4YYDS50A4OVBmGhK s6vECVZGfl16NkxnssdjDUxoQZwt7BkmWvlw9t7rwiNZiEcO9eEBlVZYW/gABMzBOx88 BTo2WP/zr6y7aGk9CbDyddq81qFO7I4cF37LLYwCnD+EZWKRoYjENVYFBaNg7tKwOjWS /9/w==
X-Gm-Message-State: ALoCoQmqHSVaxCCv2lYFeOWyyTQbGNSr+1tXkBNl7lmWkvxObThkdvTXEpd8NIhBNpNMAjTeBbsS
X-Received: by 10.194.175.102 with SMTP id bz6mr29947987wjc.120.1421426827420;  Fri, 16 Jan 2015 08:47:07 -0800 (PST)
Received: from [172.16.1.25] ([188.21.236.102]) by mx.google.com with ESMTPSA id a14sm3637003wib.22.2015.01.16.08.47.05 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 16 Jan 2015 08:47:06 -0800 (PST)
Message-ID: <54B9408B.8000306@azet.org>
Date: Fri, 16 Jan 2015 17:47:07 +0100
From: Aaron Zauner 
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: TLS Mailing List 
References: <54B5501A.4070402@azet.org>  <54B58F5B.2010704@cs.tcd.ie> <54B6815A.7060102@azet.org>  <54B9352C.70203@azet.org>
In-Reply-To: <54B9352C.70203@azet.org>
X-Enigmail-Version: 1.2.3
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig159768F26F9C6431EFB6C7E8"
Archived-At: 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Jan 2015 16:47:10 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig159768F26F9C6431EFB6C7E8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



Aaron Zauner wrote:
>=20
> As for the nonce, would it make sense to use a 128bit nonce for both
> AES128 and AES256 instead of 64/128 (see:
> https://www.imperialviolet.org/2014/05/25/strengthmatching.html)?
>=20
Sorry. Clarification; this refers to the tag length (TAGLEN) from
RFC7253, not the nonce as used in the TLS context.

Aaron


--------------enig159768F26F9C6431EFB6C7E8
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUuUCLAAoJEOTbZJL9ubXVRFUP/15AblpRXg4lKAQhauYHOpTo
mXt7nSm66dlPOlotnWJrzBaL+Rh6mrwQ7I356Q+vo8Hp9OdkXT+TJ7OvhxXyxTY/
ewbB0ltIG1nGnSrb0z1bZP8ozG9l3qcaAWcrQRkleDhVmMH7FrFCo97Egi9BuaH2
SJH71h4ZMlNwhXp4UswojB81Dl6VCbpqBk3mHSpzH7880FMoVclmtkljlz/9Ujx7
bKrTq9UFL4AvFdF48xDg+6A5jbt/MbL44iuJJN3zxG+TEZmzAXbU3Q8TZBVDRHIy
U1SXfWPDsP3NcjUB9JHiBeqaSjKfkFyfIinU5W9Gy7S7jq6IO3BDluhQ5DrpkEdI
RXvUPA+xWUWdJX49puMHQSoJrKWgYVupXM7B6RFZiZtIKd+ar7xbEEZOV77cMV/+
XVVYGq9MkLMcvKfMk5Yo2RZL/F2ceSBnAz+7PS329gX8D9floCk1/zL2HqAXOcRV
CholBeT5Rfa4vogxs3HpcDYgMwfv5lOa79NMgG3aeQBEtUFbioMjlbHOXlMQZSuF
P6HStjTNr8I9hQJQoV4VstfcFUX/JMYb1L/wxegD5GHSvGAKCwxCdiIRPUA/83IX
ZkT/eM1+53v099WTCNl8G+m4dgFnnuXabpS4+M0KJ6FQB851I8QoiG7kozupvBjZ
WtFDpHhHlG7p0pRBMcaW
=6qUt
-----END PGP SIGNATURE-----

--------------enig159768F26F9C6431EFB6C7E8--


From nobody Fri Jan 16 10:00:23 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C2471AD151 for ; Fri, 16 Jan 2015 10:00:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.602
X-Spam-Level: 
X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-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 CjOrFmmvMv1Q for ; Fri, 16 Jan 2015 10:00:19 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0774.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:774]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7043A1ACE72 for ; Fri, 16 Jan 2015 10:00:19 -0800 (PST)
Received: from BN1PR09MB0258.namprd09.prod.outlook.com (25.160.80.19) by BN1PR09MB0258.namprd09.prod.outlook.com (25.160.80.19) with Microsoft SMTP Server (TLS) id 15.1.59.20; Fri, 16 Jan 2015 17:59:56 +0000
Received: from BN1PR09MB0258.namprd09.prod.outlook.com ([25.160.80.19]) by BN1PR09MB0258.namprd09.prod.outlook.com ([25.160.80.19]) with mapi id 15.01.0059.007; Fri, 16 Jan 2015 17:59:56 +0000
From: "Dang, Quynh" 
To: =?iso-8859-1?Q?Henrik_Grubbstr=F6m?= 
Thread-Topic: [TLS] Singular or multiple NamedGroup(s) in the "HelloRetryRequest"
Thread-Index: AQHQMaN2uE7AF8cZjk6SMXFDlBGPL5zC5FIBgAAPsgCAABMO9Q==
Date: Fri, 16 Jan 2015 17:59:56 +0000
Message-ID: <1421431192333.70850@nist.gov>
References: <1421422017019.67267@nist.gov>  <1421423478675.87032@nist.gov>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [132.163.219.31]
authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; 
x-dmarcaction-test: None
x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:BN1PR09MB0258;
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB0258;
x-forefront-prvs: 04583CED1A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(199003)(24454002)(189002)(50986999)(54356999)(97736003)(76176999)(77156002)(62966003)(117636001)(110136001)(46102003)(93886004)(19580405001)(19580395003)(68736005)(66066001)(64706001)(2900100001)(86362001)(102836002)(2950100001)(92566002)(105586002)(122556002)(2656002)(106356001)(40100003)(106116001)(87936001)(99286002)(36756003)(1411001)(101416001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB0258; H:BN1PR09MB0258.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jan 2015 17:59:56.6169 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB0258
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Singular or multiple NamedGroup(s) in the "HelloRetryRequest"
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Jan 2015 18:00:21 -0000

Hi Eric and Henrik,=0A=
=0A=
That would be fine. I just read the description of the "Client Key Share Me=
ssage" again, It does not reflect the intent (to me); I found the descripti=
on confusing, not clear.=0A=
=0A=
Quynh. =0A=
=0A=
=0A=
=0A=
________________________________________=0A=
From: Henrik Grubbstr=F6m =0A=
Sent: Friday, January 16, 2015 11:44 AM=0A=
To: Dang, Quynh=0A=
Cc: Eric Rescorla; tls@ietf.org=0A=
Subject: Re: [TLS] Singular or multiple NamedGroup(s) in the "HelloRetryReq=
uest"=0A=
=0A=
On Fri, Jan 16, 2015 at 4:51 PM, Dang, Quynh  wrote:=
=0A=
> If a client offers all of the options it supports and a server sends back=
=0A=
> one group out of these options, it would guarantee a failure.=0A=
=0A=
It seems you've misunderstood; the client announces all named groups=0A=
that it supports in the named_group extension, but usually only=0A=
provides a subset of these in its ClientKeyShare message. Thus the=0A=
server can ask for a named group that the client supports but hasn't=0A=
provided a key share for in its HelloRetry.=0A=
=0A=
/grubba=0A=
=0A=
--=0A=
Henrik Grubbstr=F6m                                       grubba@grubba.org=
=0A=
Roxen Internet Software AB                              grubba@roxen.com=0A=


From nobody Fri Jan 16 10:19:42 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98F0D1AD213 for ; Fri, 16 Jan 2015 10:19:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 1FLh1uLmuOiF for ; Fri, 16 Jan 2015 10:19:31 -0800 (PST)
Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 622D41AD0F0 for ; Fri, 16 Jan 2015 10:19:31 -0800 (PST)
Received: by mail-wg0-f47.google.com with SMTP id l18so4769396wgh.6 for ; Fri, 16 Jan 2015 10:19:30 -0800 (PST)
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:from:date :message-id:subject:to:cc:content-type; bh=mI72E1VKpgTOtEkVgti6bSCgygsAJDqvJYeSGh4fe/o=; b=AuBOKLbIJK4kZ1I81nwEU1wRS+9zuZ9NEMhs2dBv5DnO/mRdkYxTvvIptcpl5wvr7u niNGlSbWDAfJfG6i4Y+glTfzKatFDLdzYRopwO6aRA4LyjeBycr/Fhe5Us1n8DkSgwBB 797ACfb8fo5chWrWg5xKlIC+Lr6IcM6IBDqwkQ3+EcOkAjsct5FBUh799G7NvSWYoe0n LeHntiyEpdWcq2xpanRbIac2SQ5WXvZ4amxOrymzb4k21ns1m7KxazrrBSfpknzfArX+ XwyA0oGOGZ5lDoHJHEgeATQGVeTvN5lVVdB9qc83BACzwr5iW/RLwc6/cr2abfU2F1qw Rcmw==
X-Gm-Message-State: ALoCoQkVzdV8BuJ0/02dC4L4lWAwaTZyc62sRkRqehy4Nb/QTpq6WNkG1esBqQ4l2fUZr9cj8eWJ
X-Received: by 10.194.203.234 with SMTP id kt10mr32320531wjc.88.1421432369987;  Fri, 16 Jan 2015 10:19:29 -0800 (PST)
MIME-Version: 1.0
Received: by 10.27.142.215 with HTTP; Fri, 16 Jan 2015 10:18:49 -0800 (PST)
In-Reply-To: <1421431192333.70850@nist.gov>
References: <1421422017019.67267@nist.gov>  <1421423478675.87032@nist.gov>  <1421431192333.70850@nist.gov>
From: Eric Rescorla 
Date: Fri, 16 Jan 2015 10:18:49 -0800
Message-ID: 
To: "Dang, Quynh" 
Content-Type: multipart/alternative; boundary=047d7b5d8bd97c5a14050cc903ee
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Singular or multiple NamedGroup(s) in the "HelloRetryRequest"
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Jan 2015 18:19:36 -0000

--047d7b5d8bd97c5a14050cc903ee
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Jan 16, 2015 at 9:59 AM, Dang, Quynh  wrote:

> Hi Eric and Henrik,
>
> That would be fine. I just read the description of the "Client Key Share
> Message" again, It does not reflect the intent (to me); I found the
> description confusing, not clear.
>

That's too bad. If you have some editorial improvements, a pull request
would
be appreciated.

Best,
-Ekr

Quynh.
>
>
>
> ________________________________________
> From: Henrik Grubbstr=C3=B6m 
> Sent: Friday, January 16, 2015 11:44 AM
> To: Dang, Quynh
> Cc: Eric Rescorla; tls@ietf.org
> Subject: Re: [TLS] Singular or multiple NamedGroup(s) in the
> "HelloRetryRequest"
>
> On Fri, Jan 16, 2015 at 4:51 PM, Dang, Quynh  wrote:
> > If a client offers all of the options it supports and a server sends ba=
ck
> > one group out of these options, it would guarantee a failure.
>
> It seems you've misunderstood; the client announces all named groups
> that it supports in the named_group extension, but usually only
> provides a subset of these in its ClientKeyShare message. Thus the
> server can ask for a named group that the client supports but hasn't
> provided a key share for in its HelloRetry.
>
> /grubba
>
> --
> Henrik Grubbstr=C3=B6m                                       grubba@grubb=
a.org
> Roxen Internet Software AB                              grubba@roxen.com
>

--047d7b5d8bd97c5a14050cc903ee
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On F=
ri, Jan 16, 2015 at 9:59 AM, Dang, Quynh <quynh.dang@nist.gov> wrote:
Hi Eric and Henrik,



That would be fine. I just read the description of the "Client Key Sha=
re Message" again, It does not reflect the intent (to me); I found the=
 description confusing, not clear.

That=
's too bad. If you have some editorial improvements, a pull request wou=
ld
be appreciated.

Best,
-Ekr<=
/div>


Quynh.







________________________________________

From: Henrik Grubbstr=C3=B6m <grubba=
@gmail.com>

Sent: Friday, January 16, 2015 11:44 AM

To: Dang, Quynh

Cc: Eric Rescorla; tls@ietf.org

Subject: Re: [TLS] Singular or multiple NamedGroup(s) in the "HelloRet=
ryRequest"




On Fri, Jan 16, 2015 at 4:51 PM, Dang, Quynh <quynh.dang@nist.gov> wrote:

> If a client offers all of the options it supports and a server sends b=
ack

> one group out of these options, it would guarantee a failure.



It seems you've misunderstood; the client announces all named groups
that it supports in the named_group extension, but usually only

provides a subset of these in its ClientKeyShare message. Thus the

server can ask for a named group that the client supports but hasn't
provided a key share for in its HelloRetry.



/grubba



--

Henrik Grubbstr=C3=B6m=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0grubba@grubba.org

Roxen Internet Software AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 grubba@roxen.com





--047d7b5d8bd97c5a14050cc903ee--


From nobody Fri Jan 16 10:59:37 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAAD1AD351 for ; Wed, 14 Jan 2015 15:03:22 -0800 (PST)
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, 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 utciU-pArwH3 for ; Wed, 14 Jan 2015 15:03:20 -0800 (PST)
Received: from smtp3.ucdavis.edu (smtp3.ucdavis.edu [128.120.32.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04D551ACF54 for ; Wed, 14 Jan 2015 15:03:19 -0800 (PST)
Received: from ocb.cs.ucdavis.edu (ocb.cs.ucdavis.edu [169.237.6.151]) by smtp3.ucdavis.edu (8.14.4/8.14.5/it-oel6-mimedefang-smtp-1.9) with ESMTP id t0EN3IqD053095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 14 Jan 2015 15:03:18 -0800
Received: from localhost (ocb.cs.ucdavis.edu [169.237.6.151]) by ocb.cs.ucdavis.edu (8.14.3/8.14.1/Debian-8ubuntu1) with ESMTP id t0EN3H9O015118 for ; Wed, 14 Jan 2015 15:03:18 -0800
Date: Wed, 14 Jan 2015 15:02:54 -0800 (Pacific Standard Time)
From: Phillip Rogaway 
To: tls@ietf.org
Message-ID: 
User-Agent: Alpine 2.00 (WNT 1167 2008-08-23)
X-X-Sender: rogaway@rogaway-toshiba
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (smtp3.ucdavis.edu [128.120.32.8]); Wed, 14 Jan 2015 15:03:18 -0800 (PST)
X-Virus-Scanned: clamav-milter 0.98.1 at smtp3
X-Virus-Status: Clean
X-Scanned-By: MIMEDefang 2.74
Archived-At: 
X-Mailman-Approved-At: Fri, 16 Jan 2015 10:59:37 -0800
Subject: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Jan 2015 23:03:22 -0000

A couple of colleagues were kind enough to tell me that there 
were discussions going on on this mailing list about including 
OCB in TLS 1.3; but that there were still some IP-related 
concerns.  I'd like to quell those as best I can.  So let 
me go on record as indicating that I think it would be great 
if TLS supported OCB; and that I'm happy to freely and 
automatically license any IP of mine for OCB under TLS.

I suspect that most use-cases for TLS-with-OCB would 
already be covered by one of the prior patent-grants 
I've done.  But, for anything that might fall in a gap, 
the simplest thing, I suspect, is for me to do an 
"IETF Patent Disclosure and Licensing Declaration" 
specifying royalty-free licensing for use of OCB in 
compliance with a TLS-specifying RFC.  I'm happy to 
submit one of those.  I might need some help to identify
what RFC number(s) to cite.

Thanks for all your hard work on advancing crypto
standards and improving TLS.

phil


From nobody Fri Jan 16 12:03:36 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D34C1ACEA5; Fri, 16 Jan 2015 12:03:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.399
X-Spam-Level: *
X-Spam-Status: No, score=1.399 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 UtsfW0UsZ31S; Fri, 16 Jan 2015 12:03:31 -0800 (PST)
Received: from zucker2.schokokeks.org (zucker2.schokokeks.org [178.63.68.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D3191B2B06; Fri, 16 Jan 2015 12:03:31 -0800 (PST)
Received: from pc (ip5b40005c.dynamic.kabel-deutschland.de [::ffff:91.64.0.92]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Fri, 16 Jan 2015 21:03:28 +0100 id 0000000000000034.0000000054B96E90.0000684E
Date: Fri, 16 Jan 2015 21:03:27 +0100
From: Hanno =?UTF-8?B?QsO2Y2s=?= 
To: tls@ietf.org
Message-ID: <20150116210327.61046788@pc>
In-Reply-To: <20150109180539.22231.7270.idtracker@ietfa.amsl.com>
References: <20150109180539.22231.7270.idtracker@ietfa.amsl.com>
X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-26702-1421438608-0001-2"
Archived-At: 
Cc: ietf@ietf.org
Subject: Re: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Jan 2015 20:03:33 -0000

This is a MIME-formatted message.  If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--=_zucker.schokokeks.org-26702-1421438608-0001-2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Recently Mozilla has disabled the now so-called protocol dance, which
makes adding another workaround (SCSV) pretty much obsolete:
https://bugzilla.mozilla.org/show_bug.cgi?id=3D1084025#c7

And a few days ago mozilla dev Brian Smith tweetet this:
"Fx experiment to disable non-secure TLS version fallback is going even
better than expected. Starting to feel silly for delaying it so long."
https://twitter.com/BRIAN_____/status/555138042428526593

I think this adds further evidence that adding another workaround layer
(SCSV) is the wrong thing to do. Instead browsers should just stop
doing weird things with protocols that compromise security and drop
the protocol dance completely.

(By the way: Has anyone thought what happens when people implement TLS
hardware that is version intolerant to versions > 1.2 and at the same
time send SCSV in the handshake? I'm pretty sure that at some point
some hardware will appear that does exactly that. Will we need another
SCSV standard for every TLS version then?)

--=20
Hanno B=C3=B6ck
http://hboeck.de/

mail/jabber: hanno@hboeck.de
GPG: BBB51E42

--=_zucker.schokokeks.org-26702-1421438608-0001-2
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJUuW6PAAoJEKWIAHK7tR5CazoQAL/XCwzekd25jfhUVeZ68V8i
U0jUP7y5fDnd6jFPbzrP4a0RhcxXLJbSSrx337PF9QTBVGvPNn7MrjVwCsFFRK/7
Z8FE77HNnzaRUl72QfRIsq9YE0qCbxRgMyLShRK8gDR8mWdu/fZULCSEKtbH/pgm
tPSSVQVNQyrSeCGv5QJfXzdn8U28LHjV1aTEO/Ssel06IroL+MKKIrs1u9z7eCzK
uyR6+XJXB4xUkSioNB/LSlCuEkpQI04Ubwjs6LzyLRNX2sgIHs/hetrEVhQCk8K7
F7kf2EW3unGfl3dK2SPNTW/KFIM/pkr0Wex901RX/rLb2+viFl81VE9InlpxRKGD
hD9uo4ILWg2FYkIDFw0XaYaX9LdNLr9+HUOepF5KuvcnJIcSugQjJNaOlXJ3BxJT
CZTEhkUmpyBsC4qQTeaf4QVuBA/C1mEFZ5oi+02ULcf6i3fLyxCL8gEr1/BdON0w
7uJ65LPa/9HeZoaMZzeDlEFkLd9wriiPUrtineJuM61Abu+Q09p+fBLyBJHnUXe0
D4LcQF2WHXW9wVhMC/JXuFwjEOetR23mcyH8OmCdvLM7YWtaerK5salYhCbHg2hO
dZ37vV1F1gFG98O5daZH7adwqerw3fl6s6pueN8doUpt6KbuccpzNLEOmHHzP2as
iBVi+fthcJi+nphXYAJc
=swT+
-----END PGP SIGNATURE-----

--=_zucker.schokokeks.org-26702-1421438608-0001-2--


From nobody Fri Jan 16 12:04:03 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2B2F1ACEE4 for ; Fri, 16 Jan 2015 12:04:01 -0800 (PST)
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 v7iiXEyI04cE for ; Fri, 16 Jan 2015 12:03:57 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0758.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:758]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9B7F1ACEA5 for ; Fri, 16 Jan 2015 12:03:56 -0800 (PST)
Received: from BN1PR09MB0258.namprd09.prod.outlook.com (25.160.80.19) by BN1PR09MB0259.namprd09.prod.outlook.com (25.160.80.20) with Microsoft SMTP Server (TLS) id 15.1.59.20; Fri, 16 Jan 2015 20:03:32 +0000
Received: from BN1PR09MB0258.namprd09.prod.outlook.com ([25.160.80.19]) by BN1PR09MB0258.namprd09.prod.outlook.com ([25.160.80.19]) with mapi id 15.01.0059.007; Fri, 16 Jan 2015 20:03:32 +0000
From: "Dang, Quynh" 
To: "tls@ietf.org" 
Thread-Topic: [TLS] Singular or multiple NamedGroup(s) in the "HelloRetryRequest"
Thread-Index: AQHQMaN2uE7AF8cZjk6SMXFDlBGPL5zC5FIBgAAPsgCAABMO9YAAB2aAgAAYltw=
Date: Fri, 16 Jan 2015 20:03:31 +0000
Message-ID: <1421438609022.41446@nist.gov>
References: <1421422017019.67267@nist.gov>  <1421423478675.87032@nist.gov>  <1421431192333.70850@nist.gov>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [132.163.219.31]
authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; 
x-dmarcaction-test: None
x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:BN1PR09MB0259;
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB0259;
x-forefront-prvs: 04583CED1A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(377454003)(24454002)(199003)(189002)(50986999)(76176999)(92566002)(117636001)(2351001)(105586002)(19625215002)(106356001)(106116001)(2501002)(46102003)(101416001)(36756003)(93886004)(54356999)(19580405001)(64706001)(87936001)(99286002)(2656002)(86362001)(68736005)(2950100001)(19580395003)(102836002)(110136001)(2900100001)(122556002)(97736003)(40100003)(16236675004)(77156002)(19627405001)(62966003)(66066001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB0259; H:BN1PR09MB0258.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; A:1; MX:3; LANG:en; 
received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts)
Content-Type: multipart/alternative; boundary="_000_142143860902241446nistgov_"
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jan 2015 20:03:31.9488 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB0259
Archived-At: 
Subject: Re: [TLS] Singular or multiple NamedGroup(s) in the "HelloRetryRequest"
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Jan 2015 20:04:01 -0000

--_000_142143860902241446nistgov_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

How about replacing the following text in Section 7.3.2


"Meaning of this message:

      This message contains the client's cryptographic parameters for
      zero or more key establishment methods.

   Structure of this message:

      struct {
          NamedGroup group;
          opaque key_exchange<1..2^16-1>;
      } ClientKeyShareOffer;

   group  The named group for the key share offer.  This identifies the
      specific key exchange method that the ClientKeyShareOffer
      describes.  Finite Field Diffie-Hellman parameters are described
      in Section 7.4.2.1; 7.3.2.1; Elliptic Curve Diffie-Hellman parameters=
 are
      described in Section 7.4.2.2. 7.3.2.2.

   key_exchange  Key exchange information.  The contents of this field
      are determined by the value of NamedGroup entry and its
      corresponding definition.

      struct {
          ClientKeyShareOffer offers<0..2^16-1>;
      } ClientKeyShare;

   offers
      A list of ClientKeyShareOffer values."


by the following text?

"

Meaning of this message: This message contains the client's cryptographic p=
arameters for zero or more groups for key establishment it supports. The cl=
ient indicates which group(s) it supports in the "supported_groups" extensi=
on (Section 7.3.2.5.2). This message contains a "ClientKeyShare" value spec=
ified below.


Structure of each client key share for a particular group:

struct {

           NamedGroup group;

           opaque key_exchange;

          } ClientKeyShareOffer;



      group  The named group for the key share offer.  This identifies the

      specific key exchange method that the ClientKeyShareOffer

      describes.  Finite Field Diffie-Hellman parameters are described

      in Section 7.3.2.1; Elliptic Curve Diffie-Hellman parameters are

      described in Section 7.3.2.2.



      key_exchange  Key exchange information.  The contents (and the length=
) of this field

      are determined by the value of NamedGroup entry and its corresponding=
 definition.


Structure of a "ClientKeyShare" message:



      struct {

                   ClientKeyShareOffer offers<0..2^16-1>;

                 } ClientKeyShare;



      offers  A list of ClientKeyShareOffer values.?

"
If the group finds that the proposed text is clearer than the current text,=
 I will do a pull request.

Quynh.


________________________________
From: Eric Rescorla 
Sent: Friday, January 16, 2015 1:18 PM
To: Dang, Quynh
Cc: Henrik Grubbstr=F6m; tls@ietf.org
Subject: Re: [TLS] Singular or multiple NamedGroup(s) in the "HelloRetryReq=
uest"

On Fri, Jan 16, 2015 at 9:59 AM, Dang, Quynh > wrote:
Hi Eric and Henrik,

That would be fine. I just read the description of the "Client Key Share Me=
ssage" again, It does not reflect the intent (to me); I found the descripti=
on confusing, not clear.

That's too bad. If you have some editorial improvements, a pull request wou=
ld
be appreciated.

Best,
-Ekr

Quynh.



________________________________________
From: Henrik Grubbstr=F6m >
Sent: Friday, January 16, 2015 11:44 AM
To: Dang, Quynh
Cc: Eric Rescorla; tls@ietf.org
Subject: Re: [TLS] Singular or multiple NamedGroup(s) in the "HelloRetryReq=
uest"

On Fri, Jan 16, 2015 at 4:51 PM, Dang, Quynh > wrote:
> If a client offers all of the options it supports and a server sends back
> one group out of these options, it would guarantee a failure.

It seems you've misunderstood; the client announces all named groups
that it supports in the named_group extension, but usually only
provides a subset of these in its ClientKeyShare message. Thus the
server can ask for a named group that the client supports but hasn't
provided a key share for in its HelloRetry.

/grubba

--
Henrik Grubbstr=F6m                                       grubba@grubba.org=

Roxen Internet Software AB                              grubba@roxen.com


--_000_142143860902241446nistgov_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable












How about replacing the following text in Section 7.3.2 





"Meaning of this message:=0A=
=0A=
      This message contains the client's cryptographic parameters for=0A=
      zero or more key establishment methods.=0A=
=0A=
   Structure of this message:=0A=
=0A=
      struct {=0A=
          NamedGroup group;=0A=
          opaque key_exchange<1..2^16-1>;=0A=
      } ClientKeyShareOffer;=0A=
=0A=
   group  The named group for the key share offer.  This identifies the=0A=
      specific key exchange method that the ClientKeyShareOffer=0A=
      describes.  Finite Field Diffie-Hellman parameters are described=0A=
      in Section 7.4.2.1; 7.3.2.1; Elliptic Curve Diffie-Hel=
lman parameters are=0A=
      described in Section 7.4.2.2. 7.3.2.2.=0A=
=0A=
   key_exchange  Key exchange information.  The contents of this field=0A=
      are determined by the value of NamedGroup entry and its=0A=
      corresponding definition.=0A=
=0A=
      struct {=0A=
          ClientKeyShareOffer offers<0..2^16-1>;=0A=
      } ClientKeyShare;=0A=
=0A=
   offers=0A=
      A list of ClientKeyShareOffer values."=0A=








by the following text?







" 






Meaning of this message: This message contains the client's cryptographi=
c parameters for zero or more groups for key establishment it supports. The=
 client indicates which group(s) it supports in the "supported_groups&=
quot; extension (Section 7.3.2.5.2). This message
 contains a “ClientKeyShare” value specified below.









Structure of each client key share for a particular group: 


struct {




           NamedGroup group;


           opaque key_excha=
nge;


          } ClientKeyShareOffer;


 


      group  The named group for the key s=
hare offer.  This identifies the


      specific key exchange method that the Cli=
entKeyShareOffer


      describes.  Finite Field Diffie-Hell=
man parameters are described


      in Section 7.3.2.1; Elliptic Curve Diffie=
-Hellman parameters are


      described in Section 7.3.2.2.


 


      key_exchange  Key exchange informati=
on.  The contents (and the length) of this field


      are determined by the value of NamedGroup=
 entry and its corresponding definition.









Structure of a “ClientKeyShare” message: 


      


      struct {


              &nb=
sp;    ClientKeyShareOffer offers<0..2^16-1>;


             &nbs=
p;   } ClientKeyShare;


 


      offers  =
A list of ClientKeyShareOffer values.



From: Eric Rescorla <ekr=
@rtfm.com>

Sent: Friday, January 16, 2015 1:18 PM

To: Dang, Quynh

Cc: Henrik Grubbstr=F6m; tls@ietf.org

Subject: Re: [TLS] Singular or multiple NamedGroup(s) in the "H=
elloRetryRequest"

 










On Fri, Jan 16, 2015 at 9:59 AM, Dang, Quynh 
<quynh.dang@nis=
t.gov> wrote:



Hi Eric and Henrik,



That would be fine. I just read the description of the "Client Key Sha=
re Message" again, It does not reflect the intent (to me); I found the=
 description confusing, not clear.









That's too bad. If you have some editorial improvements, a pull reques=
t would


be appreciated.







Best,


-Ekr








Quynh.







________________________________________

From: Henrik Grubbstr=F6m <grubba@gm=
ail.com>

Sent: Friday, January 16, 2015 11:44 AM

To: Dang, Quynh

Cc: Eric Rescorla; tls@ietf.org

Subject: Re: [TLS] Singular or multiple NamedGroup(s) in the "HelloRet=
ryRequest"






On Fri, Jan 16, 2015 at 4:51 PM, Dang, Quynh <quynh.dang@nist.gov> wrote:

> If a client offers all of the options it supports and a server sends b=
ack

> one group out of these options, it would guarantee a failure.



It seems you've misunderstood; the client announces all named groups

that it supports in the named_group extension, but usually only

provides a subset of these in its ClientKeyShare message. Thus the

server can ask for a named group that the client supports but hasn't

provided a key share for in its HelloRetry.



/grubba



--

Henrik Grubbstr=F6m                =
                     =
;  grubba@grubba.org

Roxen Internet Software AB              =
                
grubba@roxen.com
























--_000_142143860902241446nistgov_--


From nobody Fri Jan 16 12:05:21 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1EB11B2B06; Fri, 16 Jan 2015 12:05:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.36
X-Spam-Level: 
X-Spam-Status: No, score=-1.36 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, 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 5QCwS3m6Sf5o; Fri, 16 Jan 2015 12:05:08 -0800 (PST)
Received: from BLU004-OMC1S34.hotmail.com (blu004-omc1s34.hotmail.com [65.55.116.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 482A61ACE3D; Fri, 16 Jan 2015 12:05:08 -0800 (PST)
Received: from BLU177-W27 ([65.55.116.8]) by BLU004-OMC1S34.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751);  Fri, 16 Jan 2015 12:05:07 -0800
X-TMN: [BMAwHbPGwJBSHXznzbynbjBjUkfoqHp8]
X-Originating-Email: [yuhongbao_386@hotmail.com]
Message-ID: 
From: Yuhong Bao 
To: =?iso-8859-1?B?SGFubm8gQvZjaw==?= , "tls@ietf.org" 
Date: Fri, 16 Jan 2015 12:05:07 -0800
Importance: Normal
In-Reply-To: <20150116210327.61046788@pc>
References: <20150109180539.22231.7270.idtracker@ietfa.amsl.com>, <20150116210327.61046788@pc>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 16 Jan 2015 20:05:07.0584 (UTC) FILETIME=[B9997800:01D031C7]
Archived-At: 
Cc: "ietf@ietf.org" 
Subject: Re: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Jan 2015 20:05:17 -0000

This does not mean that every browser will do it.=0A=
=0A=
----------------------------------------=0A=
Date: Fri=2C 16 Jan 2015 21:03:27 +0100=0A=
From: hanno@hboeck.de=0A=
To: tls@ietf.org=0A=
CC: ietf@ietf.org=0A=
Subject: Re: [TLS] Last Call:  (TLS F=
allback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgra=
de Attacks) to Proposed Standard=0A=
=0A=
=0A=
Recently Mozilla has disabled the now so-called protocol dance=2C which=0A=
makes adding another workaround (SCSV) pretty much obsolete:=0A=
https://bugzilla.mozilla.org/show_bug.cgi?id=3D1084025#c7=0A=
=0A=
And a few days ago mozilla dev Brian Smith tweetet this:=0A=
"Fx experiment to disable non-secure TLS version fallback is going even=0A=
better than expected. Starting to feel silly for delaying it so long."=0A=
https://twitter.com/BRIAN_____/status/555138042428526593=0A=
=0A=
I think this adds further evidence that adding another workaround layer=0A=
(SCSV) is the wrong thing to do. Instead browsers should just stop=0A=
doing weird things with protocols that compromise security and drop=0A=
the protocol dance completely.=0A=
=0A=
(By the way: Has anyone thought what happens when people implement TLS=0A=
hardware that is version intolerant to versions> 1.2 and at the same=0A=
time send SCSV in the handshake? I'm pretty sure that at some point=0A=
some hardware will appear that does exactly that. Will we need another=0A=
SCSV standard for every TLS version then?)=0A=
=0A=
--=0A=
Hanno B=F6ck=0A=
http://hboeck.de/=0A=
=0A=
mail/jabber: hanno@hboeck.de=0A=
GPG: BBB51E42=0A=
=0A=
_______________________________________________=0A=
TLS mailing list=0A=
TLS@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/tls=0A=
 		 	   		  =


From nobody Fri Jan 16 12:10:47 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 078871B2B2B for ; Fri, 16 Jan 2015 12:10:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.211
X-Spam-Level: *
X-Spam-Status: No, score=1.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, 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 tUJ4rANqYKIM for ; Fri, 16 Jan 2015 12:10:39 -0800 (PST)
Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1684E1B2B1D for ; Fri, 16 Jan 2015 12:10:38 -0800 (PST)
Received: by mail-qa0-f47.google.com with SMTP id n8so17029693qaq.6 for ; Fri, 16 Jan 2015 12:10:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=dh7jIr/LvbcLCkdm7jzFVoVAYVeFBuNLbowrRNR1iyc=; b=oJ3oBCsNnZzOH5HHM7ODzE6eir/TWs9Z1a7NsRR9a0SuYhsa7kLifbZWHydcM+X1vc I5NhgZUWoWvuo+zacr4CNmqqktExC47QGLWW4ZCqpC1Gt/8aOr4DwxXcpzC1P69n7KTk mWbrC60J3adVmyV9p1qKBXKuuFWRwzNkRsZDLV+43XFCvkIc4Ifcyq41IqP1+hzqceTA 9rC3Mgy7xCZuDA1YBr8+mRv4XHM4Eaej7RBOSU0zDAm76Hr3rtz3ORrhSYAlpTsaZqh3 VovEsCE+Gc3sYE5SuNsGDQF4W+8JMxACm61FGGikNg0u8MP/ST0pTTnLVgb55+iZ3DGU zZxA==
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:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=dh7jIr/LvbcLCkdm7jzFVoVAYVeFBuNLbowrRNR1iyc=; b=MNS6bUfsjcrrHSHgrZIbx2INvkPFEi34oDRpaxv9JEavfNe5K+3w0r3iwJwO52fe4O lrKsQe7co6Gh5Xjuy04N4OTOG6LCCYRBASQROEJ3tpqrh+TO2fbfqSbmiKe7UMaSbdZW /zGq+qHQjtujmXp/M1rm1JrvK8g+gJPs1QzZ2gGlH5kKyds+meEbKsS4BVJwTuQCnRBE rzRRb1Vub9gzh21zHkCY57F72dzSkKwvhPL2mOq1v5/eyriNOsi4RRK7fb3lFzaeRhzC SzlfMI6PtY6el5OgBgUlqA4pDXe20Q5QUElRKI+hncBy3lx3u5I9S8/QEln1mTPat6GM HW6Q==
X-Gm-Message-State: ALoCoQlA0PmRcr/tXUwGftgWXblCAenHCjMJAwOvwh9J7s+kWqLHNzHT8YsRPQE/8Ezkb+gyKU2M
X-Received: by 10.224.131.70 with SMTP id w6mr28364540qas.78.1421439038177; Fri, 16 Jan 2015 12:10:38 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.8.195 with HTTP; Fri, 16 Jan 2015 12:10:18 -0800 (PST)
In-Reply-To: <20150116210327.61046788@pc>
References: <20150109180539.22231.7270.idtracker@ietfa.amsl.com> <20150116210327.61046788@pc>
From: Adam Langley 
Date: Fri, 16 Jan 2015 12:10:18 -0800
Message-ID: 
To: =?UTF-8?Q?Hanno_B=C3=B6ck?= 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: "tls@ietf.org" , ietf@ietf.org
Subject: Re: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Jan 2015 20:10:40 -0000

On Fri, Jan 16, 2015 at 12:03 PM, Hanno B=C3=B6ck  wrote:
> Recently Mozilla has disabled the now so-called protocol dance, which
> makes adding another workaround (SCSV) pretty much obsolete:

Until they add TLS 1.3 support, when they'll need it again.

> (By the way: Has anyone thought what happens when people implement TLS
> hardware that is version intolerant to versions > 1.2 and at the same
> time send SCSV in the handshake? I'm pretty sure that at some point
> some hardware will appear that does exactly that. Will we need another
> SCSV standard for every TLS version then?)

The draft specifies that servers should compare the ClientHello
version to the version that they implement. If a client tries TLS 1.3,
fails because of intolerance then tries TLS 1.2 + FALLBACK_SCSV, the
server will accept the connection because the ClientHello version is
>=3D its maximum version.


Cheers

AGL


From nobody Fri Jan 16 12:14:00 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E891A1B2B71; Fri, 16 Jan 2015 12:13:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.255
X-Spam-Level: 
X-Spam-Status: No, score=-0.255 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 ICQz-MLKOaZq; Fri, 16 Jan 2015 12:13:51 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0111.outbound.protection.outlook.com [207.46.100.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2D4E1B2B6F; Fri, 16 Jan 2015 12:13:50 -0800 (PST)
Received: from BN3PR0301MB1252.namprd03.prod.outlook.com (25.161.207.28) by BN3PR0301MB1185.namprd03.prod.outlook.com (25.160.156.147) with Microsoft SMTP Server (TLS) id 15.1.59.20; Fri, 16 Jan 2015 20:13:50 +0000
Received: from BN3PR0301MB1250.namprd03.prod.outlook.com (25.161.207.26) by BN3PR0301MB1252.namprd03.prod.outlook.com (25.161.207.28) with Microsoft SMTP Server (TLS) id 15.1.59.20; Fri, 16 Jan 2015 20:13:48 +0000
Received: from BN3PR0301MB1250.namprd03.prod.outlook.com ([25.161.207.26]) by BN3PR0301MB1250.namprd03.prod.outlook.com ([25.161.207.26]) with mapi id 15.01.0059.007; Fri, 16 Jan 2015 20:13:48 +0000
From: Andrei Popov 
To: Yuhong Bao , =?iso-8859-1?Q?Hanno_B=F6ck?= , "tls@ietf.org" 
Thread-Topic: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
Thread-Index: AQHQLDb4p3YI4XMTuk2zmtbg4N2xWpzDNo2AgAAAd4CAAADYAA==
Date: Fri, 16 Jan 2015 20:13:48 +0000
Message-ID: 
References: <20150109180539.22231.7270.idtracker@ietfa.amsl.com>, <20150116210327.61046788@pc> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e8:ed31::2]
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; 
x-dmarcaction-test: None
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(3005004); SRVR:BN3PR0301MB1252; UriScan:; 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1252; 
x-forefront-prvs: 04583CED1A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(13464003)(52034003)(189002)(377454003)(19580405001)(19580395003)(106116001)(77156002)(99286002)(92566002)(86612001)(76576001)(62966003)(122556002)(54206007)(106356001)(86362001)(40100003)(105586002)(15395725005)(50986999)(54606007)(64706001)(101416001)(97736003)(46102003)(2900100001)(2656002)(87936001)(102836002)(2950100001)(68736005)(74316001)(76176999)(54356999)(230783001)(15975445007)(33656002)(2501002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1252; H:BN3PR0301MB1250.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jan 2015 20:13:48.1330 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1252
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1185;
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: 
Cc: "ietf@ietf.org" 
Subject: Re: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Jan 2015 20:13:53 -0000

> This does not mean that every browser will do it.

True, but if FF is able to stick with this, and roll it out into production=
, that's a strong indication that other browsers may be able to do the same=
. And, of course, this eliminates the fallback problem at the root.

One remaining issue, however, is reported high rates of TLS 1.3 version int=
olerance.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Yuhong Bao
Sent: Friday, January 16, 2015 12:05 PM
To: Hanno B=F6ck; tls@ietf.org
Cc: ietf@ietf.org
Subject: Re: [TLS] Last Call:  (TLS F=
allback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgra=
de Attacks) to Proposed Standard

This does not mean that every browser will do it.

----------------------------------------
Date: Fri, 16 Jan 2015 21:03:27 +0100
From: hanno@hboeck.de
To: tls@ietf.org
CC: ietf@ietf.org
Subject: Re: [TLS] Last Call:  (TLS F=
allback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgra=
de Attacks) to Proposed Standard


Recently Mozilla has disabled the now so-called protocol dance, which makes=
 adding another workaround (SCSV) pretty much obsolete:
https://bugzilla.mozilla.org/show_bug.cgi?id=3D1084025#c7

And a few days ago mozilla dev Brian Smith tweetet this:
"Fx experiment to disable non-secure TLS version fallback is going even bet=
ter than expected. Starting to feel silly for delaying it so long."
https://twitter.com/BRIAN_____/status/555138042428526593

I think this adds further evidence that adding another workaround layer
(SCSV) is the wrong thing to do. Instead browsers should just stop doing we=
ird things with protocols that compromise security and drop the protocol da=
nce completely.

(By the way: Has anyone thought what happens when people implement TLS hard=
ware that is version intolerant to versions> 1.2 and at the same time send =
SCSV in the handshake? I'm pretty sure that at some point some hardware wil=
l appear that does exactly that. Will we need another SCSV standard for eve=
ry TLS version then?)

--
Hanno B=F6ck
http://hboeck.de/

mail/jabber: hanno@hboeck.de
GPG: BBB51E42

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
 		 	   		 =20
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


From nobody Fri Jan 16 12:39:01 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0721B2B97; Fri, 16 Jan 2015 12:38:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.301
X-Spam-Level: 
X-Spam-Status: No, score=0.301 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, MANGLED_BACK=2.3, 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 5n2byFt6Cu1q; Fri, 16 Jan 2015 12:38:55 -0800 (PST)
Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D1861B2B9C; Fri, 16 Jan 2015 12:38:55 -0800 (PST)
Received: by mail-yk0-f179.google.com with SMTP id 19so10467128ykq.10; Fri, 16 Jan 2015 12:38:54 -0800 (PST)
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=QONugxw1p+AKBJcVH4qsBnXaKZ4bht5LYKBv/cU3xRY=; b=FW8f1lNIdDci6wKR/8EVS5TBH3/Om6kPgSlNaIMdjvyne751l5DWztOfJO1VDrqkdB crsoPUdNvCpzaOCo2j8oWaNYAl7vk6Hau2L1Cm9nARIrbij7tUHDYhztrOZ6r1L4h6Zq U2G2Nr3f1S90q6Dmvx8Cv9r1u6oejKQsHApbpji9pH1JL7ZzD9NqDIpQd2vDIJWNzebt CDpAVSC2H/gcet6VFy5LcnZTXhUSu5aPu/UtANntzbZKjUgCAhLE181J/CcZTopt2RkG fsLwcZBCz17jAmrHPMjmAExCFCBMpgn9JGxXHEIXRY3UoLuwfVq0DfaLDux7/L7IfXc8 Gd/g==
MIME-Version: 1.0
X-Received: by 10.170.91.194 with SMTP id i185mr12453216yka.20.1421440734697;  Fri, 16 Jan 2015 12:38:54 -0800 (PST)
Received: by 10.170.207.6 with HTTP; Fri, 16 Jan 2015 12:38:54 -0800 (PST)
Received: by 10.170.207.6 with HTTP; Fri, 16 Jan 2015 12:38:54 -0800 (PST)
In-Reply-To: 
References: <20150109180539.22231.7270.idtracker@ietfa.amsl.com> <20150116210327.61046788@pc>  
Date: Fri, 16 Jan 2015 12:38:54 -0800
Message-ID: 
From: Watson Ladd 
To: Andrei Popov 
Content-Type: multipart/alternative; boundary=001a1139775e0fa2ec050ccaf68d
Archived-At: 
Cc: "" , "tls@ietf.org" 
Subject: Re: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Jan 2015 20:38:57 -0000

--001a1139775e0fa2ec050ccaf68d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Jan 16, 2015 12:14 PM, "Andrei Popov"  wrote=
:
>
> > This does not mean that every browser will do it.
>
> True, but if FF is able to stick with this, and roll it out into
production, that's a strong indication that other browsers may be able to
do the same. And, of course, this eliminates the fallback problem at the
root.
>
> One remaining issue, however, is reported high rates of TLS 1.3 version
intolerance.

Why are we insisting on increasing on the wire version numbers for TLS 1.3,
instead of using the extension mechanism, even though we know this will
cause adoption problems?

Sincerely,
Watson Ladd
>
> Cheers,
>
> Andrei
>
> -----Original Message-----
> From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Yuhong Bao
> Sent: Friday, January 16, 2015 12:05 PM
> To: Hanno B=C3=B6ck; tls@ietf.org
> Cc: ietf@ietf.org
> Subject: Re: [TLS] Last Call:  (TLS
Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol
Downgrade Attacks) to Proposed Standard
>
> This does not mean that every browser will do it.
>
> ----------------------------------------
> Date: Fri, 16 Jan 2015 21:03:27 +0100
> From: hanno@hboeck.de
> To: tls@ietf.org
> CC: ietf@ietf.org
> Subject: Re: [TLS] Last Call:  (TLS
Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol
Downgrade Attacks) to Proposed Standard
>
>
> Recently Mozilla has disabled the now so-called protocol dance, which
makes adding another workaround (SCSV) pretty much obsolete:
> https://bugzilla.mozilla.org/show_bug.cgi?id=3D1084025#c7
>
> And a few days ago mozilla dev Brian Smith tweetet this:
> "Fx experiment to disable non-secure TLS version fallback is going even
better than expected. Starting to feel silly for delaying it so long."
> https://twitter.com/BRIAN_____/status/555138042428526593
>
> I think this adds further evidence that adding another workaround layer
> (SCSV) is the wrong thing to do. Instead browsers should just stop doing
weird things with protocols that compromise security and drop the protocol
dance completely.
>
> (By the way: Has anyone thought what happens when people implement TLS
hardware that is version intolerant to versions> 1.2 and at the same time
send SCSV in the handshake? I'm pretty sure that at some point some
hardware will appear that does exactly that. Will we need another SCSV
standard for every TLS version then?)
>
> --
> Hanno B=C3=B6ck
> http://hboeck.de/
>
> mail/jabber: hanno@hboeck.de
> GPG: BBB51E42
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

--001a1139775e0fa2ec050ccaf68d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Jan 16, 2015 12:14 PM, "Andrei Popov" <Andrei.Popov@microsoft.com> wrote:

>

> > This does not mean that every browser will do it.

>

> True, but if FF is able to stick with this, and roll it out into produ=
ction, that's a strong indication that other browsers may be able to do=
 the same. And, of course, this eliminates the fallback problem at the root=
.

>

> One remaining issue, however, is reported high rates of TLS 1.3 versio=
n intolerance.


Why are we insisting on increasing on the wire version numbe=
rs for TLS 1.3, instead of using the extension mechanism, even though we kn=
ow this will cause adoption problems?


Sincerely, 

Watson Ladd

>

> Cheers,

>

> Andrei

>

> -----Original Message-----

> From: TLS [mailto:tls-bounces@=
ietf.org] On Behalf Of Yuhong Bao

> Sent: Friday, January 16, 2015 12:05 PM

> To: Hanno B=C3=B6ck; tls@ietf.org<=
br>
> Cc: ietf@ietf.org

> Subject: Re: [TLS] Last Call: <draft-ietf-tls-downgrade-scsv-03.txt=
> (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Proto=
col Downgrade Attacks) to Proposed Standard

>

> This does not mean that every browser will do it.

>

> ----------------------------------------

> Date: Fri, 16 Jan 2015 21:03:27 +0100

> From: hanno@hboeck.de

> To: tls@ietf.org

> CC: ietf@ietf.org

> Subject: Re: [TLS] Last Call: <draft-ietf-tls-downgrade-scsv-03.txt=
> (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Proto=
col Downgrade Attacks) to Proposed Standard

>

>

> Recently Mozilla has disabled the now so-called protocol dance, which =
makes adding another workaround (SCSV) pretty much obsolete:

> =
https://bugzilla.mozilla.org/show_bug.cgi?id=3D1084025#c7

>

> And a few days ago mozilla dev Brian Smith tweetet this:

> "Fx experiment to disable non-secure TLS version fallback is goin=
g even better than expected. Starting to feel silly for delaying it so long=
."

> h=
ttps://twitter.com/BRIAN_____/status/555138042428526593

>

> I think this adds further evidence that adding another workaround laye=
r

> (SCSV) is the wrong thing to do. Instead browsers should just stop doi=
ng weird things with protocols that compromise security and drop the protoc=
ol dance completely.

>

> (By the way: Has anyone thought what happens when people implement TLS=
 hardware that is version intolerant to versions> 1.2 and at the same ti=
me send SCSV in the handshake? I'm pretty sure that at some point some =
hardware will appear that does exactly that. Will we need another SCSV stan=
dard for every TLS version then?)

>

> --

> Hanno B=C3=B6ck

> http://hboeck.de/

>

> mail/jabber: hanno@hboeck.de
> GPG: BBB51E42

>

> _______________________________________________

> TLS mailing list

> TLS@ietf.org

> https://www.ietf=
.org/mailman/listinfo/tls

>

> _______________________________________________

> TLS mailing list

> TLS@ietf.org

> https://www.ietf=
.org/mailman/listinfo/tls

>

> _______________________________________________

> TLS mailing list

> TLS@ietf.org

> https://www.ietf=
.org/mailman/listinfo/tls




--001a1139775e0fa2ec050ccaf68d--


From SRS0=Nj8K=CD=acm.org=bmoeller@srs.kundenserver.de  Fri Jan 16 13:04:21 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 577A01B2C20; Fri, 16 Jan 2015 13:04:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.362
X-Spam-Level: *
X-Spam-Status: No, score=1.362 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MANGLED_BACK=2.3, 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 337wqNtOHYk4; Fri, 16 Jan 2015 13:04:19 -0800 (PST)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.10]) (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 42DA51B2C18; Fri, 16 Jan 2015 13:04:19 -0800 (PST)
Received: from mail-la0-f43.google.com ([209.85.215.43]) by mrelayeu.kundenserver.de (mreue102) with ESMTPSA (Nemesis) id 0MeSdD-1YOVJu0aaN-00QDwN; Fri, 16 Jan 2015 22:04:17 +0100
Received: by mail-la0-f43.google.com with SMTP id q1so5598017lam.2; Fri, 16 Jan 2015 13:04:16 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.112.172.194 with SMTP id be2mr17950161lbc.53.1421442256351;  Fri, 16 Jan 2015 13:04:16 -0800 (PST)
Received: by 10.25.25.145 with HTTP; Fri, 16 Jan 2015 13:04:16 -0800 (PST)
In-Reply-To: <20150116210327.61046788@pc>
References: <20150109180539.22231.7270.idtracker@ietfa.amsl.com> <20150116210327.61046788@pc>
Date: Fri, 16 Jan 2015 22:04:16 +0100
Message-ID: 
From: Bodo Moeller 
To: ietf@ietf.org
Content-Type: multipart/alternative; boundary=001a11c34730c2380e050ccb5030
X-Provags-ID: V03:K0:L5EDn+tCGoFmFPTR9uRdrQ+oU3M2US2rmdDINJJySqB4iGH1e1s M+dReZ93ybqNKtU76Dkor29zz4M43O9raf7wuOGRrt+ByofzTlqEnGYT6g5vkQapJWCybrv fvDMOPJQq804jrn6HDG7y77xxLkDklKomfthBI/aXG3nGlsK0lsPRgZewPnG9Dv89YtdSk4 EyBuvBWz+55dWpleu9Jiw==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Jan 2015 21:05:27 -0000

--001a11c34730c2380e050ccb5030
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hanno B=C3=B6ck :

I think this adds further evidence that adding another workaround layer
> (SCSV) is the wrong thing to do. Instead browsers should just stop
> doing weird things with protocols that compromise security and drop
> the protocol dance completely.
>

They shouldn't have to do the downgrade dance (and indeed
draft-ietf-tls-downgrade-scsv-03 does say so), and certainly I'll be very
glad if it turns out that now they really won't have to, but I wouldn't
hold my breath.

Ideally, the server-side TLS_FALLBACK_SCSV logic will be present as dormant
code that never gets executed (because clients just don't do those
fallbacks), but which is available if and when needed again.

I hope that the Firefox change will make it into the release channel and
survive there, but note that it doesn't actually remove the downgrade dance
entirely. Rather, there's now a setting that controls whether the downgrade
dance is enabled (https://bugzilla.mozilla.org/show_bug.cgi?id=3D1083058),
and the plan merely is to disable this by default (
https://bugzilla.mozilla.org/show_bug.cgi?id=3D1084025). Also, you may be
able to enable the kludge on a per-domain basis (
https://bugzilla.mozilla.org/show_bug.cgi?id=3D1114816).

There's still a lot that can happen here. If the change works well enough
for the Firefox release channel (and for all other browsers), I still
expect that a bunch of users will need to enable the downgrade dance to get
HTTPS connections to legacy devices on their local networks to work. Then
it would be discomforting to not have TLS_FALLBACK_SCSV support in servers.

Also, quite clearly, we can't yet know how the TLS 1.3 (1.4, 1.5, ...)
rollout will work out.

Bodo

--001a11c34730c2380e050ccb5030
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hann=
o B=C3=B6ck <hanno@hboeck.de>:


I think this adds further evidence that adding another workaround layer

(SCSV) is the wrong thing to do. Instead browsers should just stop

doing weird things with protocols that compromise security and drop

the protocol dance completely.

They sho=
uldn't have to do the downgrade dance (and indeed draft-ietf-tls-downgr=
ade-scsv-03 does say so), and certainly I'll be very glad if it turns o=
ut that now they really won't have to, but I wouldn't hold my breat=
h.

Ideally, the server-side TLS_FALLBACK_SCSV logi=
c will be present as dormant code that never gets executed (because clients=
 just don't do those fallbacks), but which is available if and when nee=
ded again.

I hope that the Firefox change will mak=
e it into the release channel and survive there, but note that it doesn'=
;t actually remove the downgrade dance entirely. Rather, there's now a =
setting that controls whether the downgrade dance is enabled (https://bugzilla.mozi=
lla.org/show_bug.cgi?id=3D1083058), and the plan merely is to disable t=
his by default (https://bugzilla.mozilla.org/show_bug.cgi?id=3D1084025). Also, =
you may be able to enable the kludge on a per-domain basis (https://bugzilla.mozill=
a.org/show_bug.cgi?id=3D1114816).

There's =
still a lot that can happen here. If the change works well enough for the F=
irefox release channel (and for all other browsers), I still expect that a =
bunch of users will need to enable the downgrade dance to get HTTPS connect=
ions to legacy devices on their local networks to work. Then it would=C2=A0=
be discomforting to not have TLS_FALLBACK_SC=
SV support in servers.

=

Also, quite clearly, we ca=
n't yet know how the TLS 1.3 (1.4, 1.5, ...) rollout will work out.

Bodo



--001a11c34730c2380e050ccb5030--


From nobody Fri Jan 16 13:19:16 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05D541B2C53 for ; Fri, 16 Jan 2015 13:19:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.321
X-Spam-Level: 
X-Spam-Status: No, score=0.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MANGLED_BACK=2.3, RCVD_IN_DNSWL_LOW=-0.7, 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 joOMCEBegfno for ; Fri, 16 Jan 2015 13:19:07 -0800 (PST)
Received: from mail-ob0-f169.google.com (mail-ob0-f169.google.com [209.85.214.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E17C01B2C51 for ; Fri, 16 Jan 2015 13:19:06 -0800 (PST)
Received: by mail-ob0-f169.google.com with SMTP id vb8so21125027obc.0 for ; Fri, 16 Jan 2015 13:19:06 -0800 (PST)
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 :content-transfer-encoding; bh=W4HhZs+C0M8iSN8BW+VvChXOAThoESGB2oTR7C37c+8=; b=Ff5V0wTEOeB/db9XdaRa8Te2Sp1csF6eCiIKDKny6MjcXlBn/hdBw5VxlI/5dhHk0l DezWfqssrYjLeshKCP1VZYNWb3tc/pgjhQ1nwZuKpi8ACxKQyBJjtA1fPvMPqdZQlNf4 k6lzB8K2LbptB3TYPXh0/op5EtvaqKp5njydgg4SSCxeoZfPoIA13O5vHOMApHoNlTyw WEhC8ssSf9l50T+arkECeoBJWlDY6IuNNLKL5mzZyBbW39M2lYbM+wrPIDqC4dpiUjIO vM1gqLLvc0hp/MLFf+d2NPTvAi/4o2Q6+ea7oezP0EfD5kXmK6WHbwgJ8GIUgBCLBK4u dEwQ==
X-Gm-Message-State: ALoCoQkg+tlkfdGFHIYCKr5Rj7CV1CsU5fLjSlNzrgFUi9iZEJRfG8Gk0aNqFt1G7pNrno1uO59d
MIME-Version: 1.0
X-Received: by 10.60.155.195 with SMTP id vy3mr10906820oeb.62.1421443146306; Fri, 16 Jan 2015 13:19:06 -0800 (PST)
Received: by 10.76.71.228 with HTTP; Fri, 16 Jan 2015 13:19:06 -0800 (PST)
In-Reply-To: 
References: <20150109180539.22231.7270.idtracker@ietfa.amsl.com> <20150116210327.61046788@pc> 
Date: Fri, 16 Jan 2015 13:19:06 -0800
Message-ID: 
From: Brian Smith 
To: Adam Langley 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: "tls@ietf.org" , ietf@ietf.org
Subject: Re: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Jan 2015 21:19:08 -0000

Adam Langley  wrote:
> On Fri, Jan 16, 2015 at 12:03 PM, Hanno B=C3=B6ck  wrote=
:
>> Recently Mozilla has disabled the now so-called protocol dance, which
>> makes adding another workaround (SCSV) pretty much obsolete:
>
> Until they add TLS 1.3 support, when they'll need it again.

I don't think so, because we can change the way versions are
negotiated for TLS 1.3, so that the issue doesn't arise. In
particular, we can keep ClientHello.client_version as 0x0303 (TLS 1.2)
and negotiate TLS 1.3 with an extension.

Also, the rate of TLS 1.3 intolerance might be significantly lower
than projected. Ivan's numbers are based on a ClientHello with 0x0304
(TLS 1.3) as the record-layer version number. We know from past
experience working on NSS that 0x0301 (TLS 1.0) is a more compatible
record-layer version number. I think it was established that many
servers work fine when ClientHello.client_version =3D 0x0304 (TLS 1.3)
as long as the record-layer version number is 0x0301 (TLS 1.0) but
break when then record-layer vsion is 0x0304 (TLS 1.3). We'll need to
measure this in a more definitive way, but there's reason to be
optimistic.

Cheers,
Brian


From nobody Fri Jan 16 15:08:25 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70E6B1A8987; Fri, 16 Jan 2015 15:08:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Level: 
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 T2i27-zVEPb8; Fri, 16 Jan 2015 15:08:13 -0800 (PST)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CB631A897C; Fri, 16 Jan 2015 15:08:13 -0800 (PST)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id E604C3A564; Sat, 17 Jan 2015 00:08:10 +0100 (CET)
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id D4A7442219; Sat, 17 Jan 2015 00:08:10 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id CA2D91B0FA; Sat, 17 Jan 2015 00:08:10 +0100 (CET)
In-Reply-To: 
To: Brian Smith 
Date: Sat, 17 Jan 2015 00:08:10 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="ISO-8859-1"
Message-Id: <20150116230810.CA2D91B0FA@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: 
Cc: "tls@ietf.org" , ietf@ietf.org
Subject: Re: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Jan 2015 23:08:16 -0000

Brian Smith wrote:
> Adam Langley  wrote:
>> On Fri, Jan 16, 2015 at 12:03 PM, Hanno B=F6ck  wrote:
>>> Recently Mozilla has disabled the now so-called protocol dance, which
>>> makes adding another workaround (SCSV) pretty much obsolete:
>>
>> Until they add TLS 1.3 support, when they'll need it again.
>=20
> I don't think so, because we can change the way versions are
> negotiated for TLS 1.3, so that the issue doesn't arise. In
> particular, we can keep ClientHello.client_version as 0x0303 (TLS 1.2)
> and negotiate TLS 1.3 with an extension.
>=20
> Also, the rate of TLS 1.3 intolerance might be significantly lower
> than projected. Ivan's numbers are based on a ClientHello with 0x0304
> (TLS 1.3) as the record-layer version number. We know from past
> experience working on NSS that 0x0301 (TLS 1.0) is a more compatible
> record-layer version number. I think it was established that many
> servers work fine when ClientHello.client_version =3D 0x0304 (TLS 1.3)
> as long as the record-layer version number is 0x0301 (TLS 1.0) but
> break when then record-layer vsion is 0x0304 (TLS 1.3).


Sending { 0x03, 0x04 } at the record layer for the ClientHello at the
beginning of a new connection MUST be expected to get unconditionally
rejected by pre-TLSv1.2 servers.  It puzzles me to why so many implementers
get this wrong.

Adding the aggressive automatic silent fallback reconnects
(the "downgrade dance") to browser was not very smart.  The problems
such fallbacks create was extensively discussed in the TLS WG in late 2009
(renegotiation issue that resulted in rfc5746).

But what was a really bad idea was neither offering a user an opt-in
for individual downgrades, nor allowing the user to disable the downgrade
dance.  Also not attempt was made to count how often downgrades happened,
nor to limit how often browsers would perform automatic silen downgrades.
This gross negligence was one of the reasons why the brittle connection
management in Firefox, that regularly caused downgrades all by itself,
was (a) unnoticed by the responsible developers and (b) was ignored
for almost 6 years after reported as an easily reproducible FF bug...


Making repetitive/frequent downgrades (e.g. more than 1 full handshake
per host per hour) an interactive user opt-in, rather than the automatic
silent can-not-be-disabled-by-user nuisance and security problem that it
currently is, would immediately provide significant protection
-- and entirely without server-side changes.  As a bonus, this would also
help in identifying/reminding on server software/devices that should
probably be updated.


-Martin


From nobody Fri Jan 16 20:57:06 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 070401B2AE8; Fri, 16 Jan 2015 20:57:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Level: 
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 GEmi9y9oZxdY; Fri, 16 Jan 2015 20:57:02 -0800 (PST)
Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A467D1A914E; Fri, 16 Jan 2015 20:57:02 -0800 (PST)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 41F973A3A8; Sat, 17 Jan 2015 05:57:00 +0100 (CET)
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 34BB94178B; Sat, 17 Jan 2015 05:57:00 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 2E3801B0FA; Sat, 17 Jan 2015 05:57:00 +0100 (CET)
In-Reply-To: <20150116230810.CA2D91B0FA@ld9781.wdf.sap.corp>
To: mrex@sap.com
Date: Sat, 17 Jan 2015 05:57:00 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20150117045700.2E3801B0FA@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: 
Cc: ietf@ietf.org, "tls@ietf.org" 
Subject: Re: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 17 Jan 2015 04:57:05 -0000

Martin Rex wrote:
> 
> Adding the aggressive automatic silent fallback reconnects
> (the "downgrade dance") to browser was not very smart.  The problems
> such fallbacks create was extensively discussed in the TLS WG in late 2009
> (renegotiation issue that resulted in rfc5746).
> 
> Making repetitive/frequent downgrades (e.g. more than 1 full handshake
> per host per hour) an interactive user opt-in, rather than the automatic
> silent can-not-be-disabled-by-user nuisance and security problem that it
> currently is, would immediately provide significant protection
> -- and entirely without server-side changes.  As a bonus, this would also
> help in identifying/reminding on server software/devices that should
> probably be updated.

For quite a while, Yngve Petterson has been proposing a scheme to
limit the downgrade dance problem (and willingness of clients/browsers
to perform the downgrade dance), that will work immediately, not require
and server-side changes, and without all of the massive serious operational
problems of the current fallback-scsv proposal:

  https://tools.ietf.org/html/draft-pettersen-tls-version-rollback-removal-03


Rubber-Stamping the fallback-scsv hack onto the standards track is
IMHO a very bad idea.

I've once heard the saying "If you can't be good, at least be good at it."

If Browsers (and the few, if any) other TLS clients that are currently
doing the dangerous downgrade dances, can't be good and stop doing
such dangerous stuff, they should at least do this in a much less
risky fashion than what they're currently doing.

... such as adopting Yngve's approach above and do not perform downgrades
without interactive user confirmation where Yngve's proposal asks for a
handshake failure.


bottom line:  I am violently opposed to making the fallback-scsv
document a proposed standard.


-Martin


From nobody Fri Jan 16 21:07:52 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63EB11B2AE8; Fri, 16 Jan 2015 21:07:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.3
X-Spam-Level: 
X-Spam-Status: No, score=0.3 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, MANGLED_BACK=2.3, 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 oQVZTFpGcwXz; Fri, 16 Jan 2015 21:07:45 -0800 (PST)
Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 601BB1A9167; Fri, 16 Jan 2015 21:07:45 -0800 (PST)
Received: by mail-ie0-f178.google.com with SMTP id vy18so24119690iec.9; Fri, 16 Jan 2015 21:07:44 -0800 (PST)
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:cc:content-type:content-transfer-encoding; bh=bG0bpDxCLzgLfzZpuE2QT/1iWOBhoUlOnH9+7wf35Ds=; b=NdHW1xHhyHaYCS5ZZAnsBU6Ky6LiwapQv8NqFMxiaVPyfCazZD7Y3NVe7WGqGosFH8 6T8SvIGKArsrDFBc14PC9RyynrEAEwV0BpG6Bkm/afaCiKgFWF+XFROAJqVCsAE5N3ph zJOuSAyNjb7EOdenZU2GPoiLUUVBu2IM/yOXISmB2t14KzLrqmwXIGpgBGTCPwQMP461 gLz5ljEu/GReJV471BGWVftjICM0GN7UFnldtvVI/gijkJ68CKoxUayRfiBi/WEMFZZ7 1yZEB3rlC3R9FzxOcBRzY6FigNsVwEjraEfGGLJftK/EMw+uaz1aVenyVF1+Wgg4YR1w hhag==
MIME-Version: 1.0
X-Received: by 10.42.54.5 with SMTP id p5mr17949128icg.37.1421471264512; Fri, 16 Jan 2015 21:07:44 -0800 (PST)
Received: by 10.107.134.170 with HTTP; Fri, 16 Jan 2015 21:07:44 -0800 (PST)
In-Reply-To: 
References: <20150109180539.22231.7270.idtracker@ietfa.amsl.com> <20150116210327.61046788@pc> 
Date: Sat, 17 Jan 2015 00:07:44 -0500
Message-ID: 
From: Jeffrey Walton 
To: Bodo Moeller 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: ietf@ietf.org, "tls@ietf.org" 
Subject: Re: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: noloader@gmail.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 17 Jan 2015 05:07:49 -0000

On Fri, Jan 16, 2015 at 4:04 PM, Bodo Moeller  wrote:
> Hanno B=C3=B6ck :
>
>> I think this adds further evidence that adding another workaround layer
>> (SCSV) is the wrong thing to do. Instead browsers should just stop
>> doing weird things with protocols that compromise security and drop
>> the protocol dance completely.
>
> Also, quite clearly, we can't yet know how the TLS 1.3 (1.4, 1.5, ...)
> rollout will work out.
>
The WG should be solving problems that do exist; and not manufactured
problems or theoretical future problems that don't exist.

Jeff


From nobody Fri Jan 16 23:55:46 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF30B1AC39B; Fri, 16 Jan 2015 23:55:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.3
X-Spam-Level: 
X-Spam-Status: No, score=0.3 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, MANGLED_BACK=2.3, 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 pcbPkWMdg0G1; Fri, 16 Jan 2015 23:55:42 -0800 (PST)
Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82C841ACE79; Fri, 16 Jan 2015 23:55:42 -0800 (PST)
Received: by mail-wi0-f173.google.com with SMTP id r20so6577488wiv.0; Fri, 16 Jan 2015 23:55:41 -0800 (PST)
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=kjXFoq5LjhQMOV/IdFd9L0WEkmgwCH5QlPyGEB/E04c=; b=gnR42z4xHlqfKrl7/7TeGdjbbXCQIupl4p+FT91qlATfIATqvWXSh3G/wi1u4wWFZE FtHr4J6nGpVbeedFthQg2g3Agr1l366okburH/VDZBSNTxYdpFgZii9oxoGUkU9Wiag1 xY29cTbuJsC90S9MEherS9vDDBUAkcFiUbfcpKAqJLv0Qb7lHpD0gyFrmbsyE3Ks/c3s 1ypJyJIBE9fuNRTdZpjkSIFhQFJa2TanyGuhRyNNOljYP9+SA45eoQHmsOdGXA030lWR AhdrTN0S5i3DKcPAmlkGEuZVYx3mYARZmq+z50+5aqFqF++1hgTt3CWjdELfb9Xpmi7M +nFw==
X-Received: by 10.194.91.145 with SMTP id ce17mr37204486wjb.132.1421481341253;  Fri, 16 Jan 2015 23:55:41 -0800 (PST)
Received: from [192.168.1.15] ([46.120.13.132]) by mx.google.com with ESMTPSA id fg9sm5812502wib.9.2015.01.16.23.55.39 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 16 Jan 2015 23:55:40 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Yoav Nir 
In-Reply-To: 
Date: Sat, 17 Jan 2015 09:55:37 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <39E90B1F-13A3-4BD5-8C97-12989009E0B8@gmail.com>
References: <20150109180539.22231.7270.idtracker@ietfa.amsl.com> <20150116210327.61046788@pc>  
To: noloader@gmail.com
X-Mailer: Apple Mail (2.1993)
Archived-At: 
Cc: ietf@ietf.org, "tls@ietf.org" 
Subject: Re: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 17 Jan 2015 07:55:44 -0000

> On Jan 17, 2015, at 7:07 AM, Jeffrey Walton  =
wrote:
>=20
> On Fri, Jan 16, 2015 at 4:04 PM, Bodo Moeller  =
wrote:
>> Hanno B=C3=B6ck :
>>=20
>>> I think this adds further evidence that adding another workaround =
layer
>>> (SCSV) is the wrong thing to do. Instead browsers should just stop
>>> doing weird things with protocols that compromise security and drop
>>> the protocol dance completely.
>>=20
>> Also, quite clearly, we can't yet know how the TLS 1.3 (1.4, 1.5, =
...)
>> rollout will work out.
>>=20
> The WG should be solving problems that do exist; and not manufactured
> problems or theoretical future problems that don't exist.

They=E2=80=99re not theoretical. Servers that do not tolerate =
(0x03,0x04) in ClientHello exist *now*. Surprisingly, some of those do =
support TLS 1.2 and Renegotiation Info. Unless those are all gone by the =
time browsers roll out TLS 1.3, there will be a problem to solve.

Yoav


From nobody Sat Jan 17 01:54:41 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA8511B2B6F for ; Sat, 17 Jan 2015 01:54:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.104
X-Spam-Level: *
X-Spam-Status: No, score=1.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.793, SPF_PASS=-0.001, UPPERCASE_50_75=0.008] 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 8xx6Abk8uaAY for ; Sat, 17 Jan 2015 01:54:38 -0800 (PST)
Received: from vps2.offspark.com (unknown [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 834AE1B2B71 for ; Sat, 17 Jan 2015 01:54:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim;  h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=LFgLmwqA9bcvu/obyZ26+UZaFNsDcaui7e5SjJo4/Zk=;  b=bdnx4sZHKz2AFs3z70mKDOVhOPq3NSdbh00diHHGE7mN8eATaL6YcqLCA+I8VA64TVkXJFaXjlrD0vjZhrXFKqXXtUUY4BPrjI9DUTS5BY4L8iE+xzFz9ZxlmJsvUpwaLZYs+yhumwuFhFI1hNqh0zelO+MaR1i+QxdYZP3BFx0=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YCQ5H-0002J5-Ix; Sat, 17 Jan 2015 10:54:23 +0100
Message-ID: <54BA315A.7020804@polarssl.org>
Date: Sat, 17 Jan 2015 10:54:34 +0100
From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Aaron Zauner , TLS Mailing List 
References: <54B5501A.4070402@azet.org>  <54B58F5B.2010704@cs.tcd.ie> <54B6815A.7060102@azet.org>  <54B9352C.70203@azet.org>
In-Reply-To: <54B9352C.70203@azet.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 17 Jan 2015 09:54:40 -0000

On 16/01/2015 16:58, Aaron Zauner wrote:
> I came up with the following list of cipher-suites applicable to >= TLS 1.2:
> 
> (EC)DHE:
> TLS_DHE_RSA_WITH_AES_128_OCB	
> TLS_DHE_RSA_WITH_AES_256_OCB
> TLS_ECDHE_RSA_WITH_AES_128_OCB
> TLS_ECDHE_RSA_WITH_AES_256_OCB
> TLS_ECDHE_ECDSA_WITH_AES_128_OCB
> TLS_ECDHE_ECDSA_WITH_AES_256_OCB
> 
> PSK:
> TLS_DHE_PSK_WITH_AES_128_OCB
> TLS_DHE_PSK_WITH_AES_256_OCB	
> TLS_ECDHE_PSK_WITH_AES_128_OCB
> TLS_ECDHE_PSK_WITH_AES_256_OCB
> 
I think it would make sense to also include pure PSK (no DH) suite for very
constrained devices that can't afford the asymetric crypto.

Manuel.


From nobody Sat Jan 17 06:37:36 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6284D1ACD87 for ; Sat, 17 Jan 2015 06:37:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.323
X-Spam-Level: 
X-Spam-Status: No, score=0.323 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MANGLED_BACK=2.3, RCVD_IN_DNSWL_LOW=-0.7] 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 Dl-vjvvDvYT5 for ; Sat, 17 Jan 2015 06:37:30 -0800 (PST)
Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87F9F1ACD6F for ; Sat, 17 Jan 2015 06:37:30 -0800 (PST)
Received: by mail-wg0-f45.google.com with SMTP id y19so24991917wgg.4 for ; Sat, 17 Jan 2015 06:37:29 -0800 (PST)
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:from:date :message-id:subject:to:cc:content-type; bh=MtW5p68rT5LRJyBhEKgM1ggGDA0jtdb6n374/H+Yzew=; b=bvHSTlRMmsjeIc/zQXkk+rR6oG2C0Kz/XP4c8u7yfJ2pL92qBob1wCFIHRizJfWfI4 kIdeYl4k4O1qFPMt64YAbt+EXjOpl+aYBNGf23yNgj+pK3w7+Jy19d9vhC1UpWPpw84Y EawKpQVdY6GCRQpv/eldfwXjhGM8/eI+NWIYkDxeqLWbGOG5Vn1j90IQznOTTQbmR8Gb vNdchPjHgXOqDxTjLAfVKFH3JXCGyZVqxqeD4aqy/F2nO7f6ZhLV4aXDFKk+awyNVLW5 KcOvYynmix8oKle+tPX+kqOEp4Y8Xhyh0vy3hcjzZddafFqkFzwSCJpVQOjiFNvznW08 QiHw==
X-Gm-Message-State: ALoCoQlOYmiNlH1QTQyMOo3fRMM8vK1F7j0AA3WGsBWNeraKH5BsXlD9t5fmMwtcYCOpsal2PAyL
X-Received: by 10.180.109.45 with SMTP id hp13mr16409249wib.4.1421505449361; Sat, 17 Jan 2015 06:37:29 -0800 (PST)
MIME-Version: 1.0
Received: by 10.27.142.215 with HTTP; Sat, 17 Jan 2015 06:36:47 -0800 (PST)
In-Reply-To: 
References: <20150109180539.22231.7270.idtracker@ietfa.amsl.com> <20150116210327.61046788@pc>  
From: Eric Rescorla 
Date: Sat, 17 Jan 2015 06:36:47 -0800
Message-ID: 
To: Brian Smith 
Content-Type: multipart/alternative; boundary=e89a8f3bae995b1801050cda0783
Archived-At: 
Cc: "tls@ietf.org" , IETF discussion list 
Subject: Re: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 17 Jan 2015 14:37:33 -0000

--e89a8f3bae995b1801050cda0783
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Jan 16, 2015 at 1:19 PM, Brian Smith  wrote:

> Adam Langley  wrote:
> > On Fri, Jan 16, 2015 at 12:03 PM, Hanno B=C3=B6ck  wro=
te:
> >> Recently Mozilla has disabled the now so-called protocol dance, which
> >> makes adding another workaround (SCSV) pretty much obsolete:
> >
> > Until they add TLS 1.3 support, when they'll need it again.
>
> I don't think so, because we can change the way versions are
> negotiated for TLS 1.3, so that the issue doesn't arise. In
> particular, we can keep ClientHello.client_version as 0x0303 (TLS 1.2)
> and negotiate TLS 1.3 with an extension.
>
> Also, the rate of TLS 1.3 intolerance might be significantly lower
> than projected. Ivan's numbers are based on a ClientHello with 0x0304
> (TLS 1.3) as the record-layer version number. We know from past
> experience working on NSS that 0x0301 (TLS 1.0) is a more compatible
> record-layer version number. I think it was established that many
> servers work fine when ClientHello.client_version =3D 0x0304 (TLS 1.3)
> as long as the record-layer version number is 0x0301 (TLS 1.0) but
> break when then record-layer vsion is 0x0304 (TLS 1.3). We'll need to
> measure this in a more definitive way, but there's reason to be
> optimistic.


Thanks for the detail. I've been planning to run some experiments using
Firefox Telemetry, but haven't gotten around to them yet. More when
I have them.

-Ekr


>
>
Cheers,
> Brian
>
>

--e89a8f3bae995b1801050cda0783
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Fri, Jan 16, 2015 at 1:19 PM, Brian Smith <brian@briansmith.org<=
/a>> wrote:
Ad=
am Langley <agl@google.com> wro=
te:

> On Fri, Jan 16, 2015 at 12:03 PM, Hanno B=C3=B6ck <hanno@hboeck.de> wrote:

>> Recently Mozilla has disabled the now so-called protocol dance, wh=
ich

>> makes adding another workaround (SCSV) pretty much obsolete:

>

> Until they add TLS 1.3 support, when they'll need it again.



I don't think so, because we can change the way versions are

negotiated for TLS 1.3, so that the issue doesn't arise. In

particular, we can keep ClientHello.client_version as 0x0303 (TLS 1.2)

and negotiate TLS 1.3 with an extension.



Also, the rate of TLS 1.3 intolerance might be significantly lower

than projected. Ivan's numbers are based on a ClientHello with 0x0304
(TLS 1.3) as the record-layer version number. We know from past

experience working on NSS that 0x0301 (TLS 1.0) is a more compatible

record-layer version number. I think it was established that many

servers work fine when ClientHello.client_version =3D 0x0304 (TLS 1.3)

as long as the record-layer version number is 0x0301 (TLS 1.0) but

break when then record-layer vsion is 0x0304 (TLS 1.3). We'll need to
measure this in a more definitive way, but there's reason to be

optimistic.

Thanks for the detail. I've=
 been planning to run some experiments using
Firefox Telemetry, b=
ut haven't gotten around to them yet. More when
I have them.<=
/div>

-Ekr
=C2=A0
=C2=A0

Cheers,

Brian







--e89a8f3bae995b1801050cda0783--


From nobody Sat Jan 17 07:11:02 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF01D1ACD6F for ; Sat, 17 Jan 2015 07:11:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.3
X-Spam-Level: 
X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 4LlhN5c4chcj for ; Sat, 17 Jan 2015 07:10:59 -0800 (PST)
Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E50631ACD69 for ; Sat, 17 Jan 2015 07:10:58 -0800 (PST)
Received: by mail-wg0-f51.google.com with SMTP id l18so2992718wgh.10 for ; Sat, 17 Jan 2015 07:10:57 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=nRdW19tZS24MPv6eJbkbT79UMvhGnfh5rSw1nbsQuq4=; b=EbxWVYkRodcbS/0QETdCSP/NzF1kDLXNvl2Zsn95FO+98/zgCjFcPSSOsb9jXsJ/dN +0BoLaP/twMxmeEr5eISBNex+JHkURBD22P26nCT10G6qAAGjvyx4Ui9ZpzXoRQQw5gT vjARFbRmYhJqzqWZkBk3orDB+8Nz6JTU9I8MmZ8HkLwK9ytXo/ky4tglgYiFW7H1EExw bq+guj5JUo3WTdn8TycblQjEjMqUVw0AtFZ+ERknzhS4Gd8No9Mwc+jdbMlVyvAdxCAm kRHGQjMqLn5G1/6K8MH93B/PNy9H9nOhVYIKirOgygYEdkh0a+VcddnyZgOOfQVXj/oQ BT4w==
X-Gm-Message-State: ALoCoQncxmJrCVi8/RYF8j5iAajmTzZ8Pc+b0m4OBNU0von5Wzpjg7t5lubyo8k77jHOy9LmR7Mk
X-Received: by 10.180.83.129 with SMTP id q1mr16824291wiy.8.1421507457679; Sat, 17 Jan 2015 07:10:57 -0800 (PST)
Received: from typhoon.azet.org (chello080108032135.14.11.univie.teleweb.at. [80.108.32.135]) by mx.google.com with ESMTPSA id c10sm10093556wjy.4.2015.01.17.07.10.56 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 17 Jan 2015 07:10:56 -0800 (PST)
Date: Sat, 17 Jan 2015 16:11:07 +0100
From: Aaron Zauner 
To: Manuel =?utf-8?B?UMOpZ291cmnDqS1Hb25uYXJk?= 
Message-ID: <20150117151105.GA5549@typhoon.azet.org>
References: <54B5501A.4070402@azet.org>  <54B58F5B.2010704@cs.tcd.ie> <54B6815A.7060102@azet.org>  <54B9352C.70203@azet.org> <54BA315A.7020804@polarssl.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="UlVJffcvxoiEqYs2"
Content-Disposition: inline
In-Reply-To: <54BA315A.7020804@polarssl.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Cc: TLS Mailing List 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 17 Jan 2015 15:11:01 -0000

--UlVJffcvxoiEqYs2
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* Manuel P=C3=A9gouri=C3=A9-Gonnard  [17/01/2015 10:54:36=
] wrote:
> On 16/01/2015 16:58, Aaron Zauner wrote:
> > I came up with the following list of cipher-suites applicable to >=3D T=
LS 1.2:
> >=20
> > (EC)DHE:
> > TLS_DHE_RSA_WITH_AES_128_OCB=09
> > TLS_DHE_RSA_WITH_AES_256_OCB
> > TLS_ECDHE_RSA_WITH_AES_128_OCB
> > TLS_ECDHE_RSA_WITH_AES_256_OCB
> > TLS_ECDHE_ECDSA_WITH_AES_128_OCB
> > TLS_ECDHE_ECDSA_WITH_AES_256_OCB
> >=20
> > PSK:
> > TLS_DHE_PSK_WITH_AES_128_OCB
> > TLS_DHE_PSK_WITH_AES_256_OCB=09
> > TLS_ECDHE_PSK_WITH_AES_128_OCB
> > TLS_ECDHE_PSK_WITH_AES_256_OCB
> >=20
> I think it would make sense to also include pure PSK (no DH) suite for ve=
ry
> constrained devices that can't afford the asymetric crypto.

Makes sense. So your suggestion is to swap or add these
ciphersuites? I have no real-world data on the usage of TLS with
pre-shared keys, nor it's deployment. I can only guess, would be
interesting to hear the opinion of embedded development people on
that subject.

Aaron

--UlVJffcvxoiEqYs2
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUunuJAAoJEOTbZJL9ubXVtKwQAO10GujvEIqRjTkSGlLq1LDt
yzYzG/VBj7Ime97rDuIhzPyJ4VPAjyGHwNAD1/PHxAkITSx6tkMLZX2roIC0L/E2
EaaEkO64ARphglvJT7rcBp7rYBfnnKBHG9p0/jDV0IfD0cndeov8WzrYymG3/SAK
90oXpfH+04iYfl4IUY/qyLNTTvyQ5xEPqukcaZpI5/ntZtK43N5JW9twJKqkQgzd
A3im3mGJadX8zohZqRsWGk9Kj/4mZXY6T7K5qzMGwjXhpg58KC3R3Np950fz1/B+
8yYYrvRZshXm1AhRzS5zFofUxEhD2AktEG76auQJiZPh0XjFirE2ZEVN7C4vgRs7
ZRbUb26s3ZVNSzXj6VxofOeI8y2O8NiHXyapWoln+cHRTUUKvG5IfCKOf454B8MH
M59XaHOi2wgbrWwHObHiG1ULsKcSl9/80sbyvUCWCekygkNzVW03at/9EbBAuTGt
vSbpWHi4Tf5C+N5UvujFIsGM9cc/AjQv4Rlo/VexauQe5TfX5kqao5VWWkJ1gktr
GSBF6H2nGuYNK505GKm1KKsGh92QtHRKezLpi030RHVHF+PO3MMJXTKvE6GCelhk
gjClGmri8Hitm3Lzd7toWW0qxTI5Es34aPwZv0tIOsFBi31J1z84woW+NXIeIduM
rb8BnyVECYtsCr735LFn
=sxCi
-----END PGP SIGNATURE-----

--UlVJffcvxoiEqYs2--


From nobody Sat Jan 17 10:33:50 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37C211ACEB8 for ; Sat, 17 Jan 2015 10:33:49 -0800 (PST)
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, 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 coxIBwYoYbsq for ; Sat, 17 Jan 2015 10:33:47 -0800 (PST)
Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 76BB61AC3AC for ; Sat, 17 Jan 2015 10:33:47 -0800 (PST)
Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 60E572857D; Sat, 17 Jan 2015 18:33:46 +0000 (GMT)
Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 4A90A28579; Sat, 17 Jan 2015 18:33:46 +0000 (GMT)
Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 4646E80044; Sat, 17 Jan 2015 18:33:46 +0000 (GMT)
Received: from usma1ex-cashub6.kendall.corp.akamai.com (172.27.105.22) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.913.22; Sat, 17 Jan 2015 13:31:29 -0500
Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB6.kendall.corp.akamai.com ([172.27.105.22]) with mapi; Sat, 17 Jan 2015 13:31:29 -0500
From: "Salz, Rich" 
To: "mrex@sap.com" 
Date: Sat, 17 Jan 2015 13:31:29 -0500
Thread-Topic: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
Thread-Index: AdAyEhVWyLDgM1CAS6idf8kmsrjvAgAcY7MQ
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D55AED04B@USMBX1.msg.corp.akamai.com>
References: <20150116230810.CA2D91B0FA@ld9781.wdf.sap.corp> <20150117045700.2E3801B0FA@ld9781.wdf.sap.corp>
In-Reply-To: <20150117045700.2E3801B0FA@ld9781.wdf.sap.corp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 17 Jan 2015 18:33:49 -0000

> without all of the massive serious operational problems of
> the current fallback-scsv proposal:

Can you elaborate on what this problems are?  We didn't see any at Akamai. =
 I wonder if we got lucky?
=20
-- =20
Principal Security Engineer, Akamai Technologies
IM: rsalz@jabber.me Twitter: RichSalz


From nobody Sat Jan 17 18:47:49 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFAB01A9140 for ; Sat, 17 Jan 2015 18:47:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.81
X-Spam-Level: 
X-Spam-Status: No, score=-2.81 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 61oV-jL8uKDZ for ; Sat, 17 Jan 2015 18:47:43 -0800 (PST)
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 20FD31A912C for ; Sat, 17 Jan 2015 18:47:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1421549263; x=1453085263; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=jPy/LHL0Wkok1Fbr0V9fvS0Q+LupMei53keKVGhU0yU=; b=Vv45nRb3tl1ov3pkVmd0u0Cyu2zieAoBAk8Dykc3ST/2TaxBCr8k/YC8 R4OfBzgYzQLKgi38pqtWOiyMnY+TKW8PkdQJ7PTAfzhHWV4qofZQf9E+8 iiv9lQGg1SEhDAMqINahLaZE4ucGM8Wo3peOpg56Hy+n0nK/mJdNIEGmT c=;
X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="301951152"
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/AES256-SHA; 18 Jan 2015 15:47:39 +1300
Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.148]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Sun, 18 Jan 2015 15:47:39 +1300
From: Peter Gutmann 
To: "" 
Thread-Topic: [TLS] Using RSA PSS in TLS
Thread-Index: AdAyyR9KVIrbJDYoQTaCs9oyQ1giYA==
Date: Sun, 18 Jan 2015 02:47:38 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAF5D4AB@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: 
Subject: Re: [TLS] Using RSA PSS in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 18 Jan 2015 02:47:48 -0000

Watson Ladd  writes:=0A=
=0A=
>RSA-OEAP has similar error oracle issues,=0A=
=0A=
That's one thing I noticed when I implemented it some time ago, OAEP is an=
=0A=
absolute goldmine (or minefield) of oracles.  PKCS 1.5 is just a=0A=
straightforward walk-down-the-byte-string check while OAEP requires multipl=
e=0A=
complex steps to decode/check it, even with very careful ordering of the=0A=
checks you do to make sure there's very little time difference between them=
=0A=
(including deferring checks to cluster them around the same time and simila=
r=0A=
steps) you can't really create an oracle-free implementation.=0A=
=0A=
Peter.=0A=


From nobody Sat Jan 17 19:20:34 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 930651ACE6E for ; Sat, 17 Jan 2015 19:20:30 -0800 (PST)
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 Bq7_91WJ17hj for ; Sat, 17 Jan 2015 19:20:28 -0800 (PST)
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 2F23E1ACE73 for ; Sat, 17 Jan 2015 19:20:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1421551228; x=1453087228; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=G6fpCksdKEFPzJm92rNM10ScetrGpt/9Ya1jSNGxGFU=; b=PPD82LPxoDNllNzK0ql4ohRm/6n/HJOou7iaOznNVKY6uzep1Dx2gfZ7 jwGJWfArc3zx5QUo4YjbukBmwvBuKCbHAva6SGvm3OpE44F5eBNG/1nPk bSywcnRkHmLyKC0Id2crURm/gm1zX3e25z5YSvYYnxUgqjD5fXR2zHVcx 8=;
X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="301952785"
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/AES256-SHA; 18 Jan 2015 16:20:22 +1300
Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.148]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0174.001; Sun, 18 Jan 2015 16:20:22 +1300
From: Peter Gutmann 
To: "" 
Thread-Topic: [TLS] Inclusion of OCB mode in TLS 1.3
Thread-Index: AdAyzbELWoWAOy+tSTOVpMKJ9RZ1Sg==
Date: Sun, 18 Jan 2015 03:20:21 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAF5D4FB@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: 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 18 Jan 2015 03:20:30 -0000

Phillip Rogaway  writes:=0A=
=0A=
>I suspect that most use-cases for TLS-with-OCB would already be covered by=
=0A=
>one of the prior patent-grants I've done.  But, for anything that might fa=
ll=0A=
>in a gap, the simplest thing, I suspect, is for me to do an "IETF Patent=
=0A=
>Disclosure and Licensing Declaration" specifying royalty-free licensing fo=
r=0A=
>use of OCB in compliance with a TLS-specifying RFC.  I'm happy to submit o=
ne=0A=
>of those.  I might need some help to identify what RFC number(s) to cite.=
=0A=
=0A=
That would be great to have!  I've always liked OCB, but as an open-source=
=0A=
developer I don't have any control over how my code is used (beyond "you ha=
ve=0A=
to make the source code available", "you need to include an acknowledgement=
 in=0A=
your docs", or whatever the preferred license is), so I haven't been able t=
o=0A=
use it until now.  Being allowed to use it for a TLS implementation without=
=0A=
further restrictions would be a great help.=0A=
=0A=
Peter.=


From nobody Sat Jan 17 19:31:09 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E45A1ACD3C for ; Sat, 17 Jan 2015 19:31:07 -0800 (PST)
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 6vzjKhUpYv7p for ; Sat, 17 Jan 2015 19:31:05 -0800 (PST)
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 B24E61A9071 for ; Sat, 17 Jan 2015 19:31:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1421551865; x=1453087865; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=SGqWlKwd8hlmGT+ns+BsfjvJp8wipY7x74Uc8nMpnJ4=; b=u5IPRaxQML7GcmeA42/CJ7W/Wmrro7rUEXn58/QuuKD4dnQ42hba8Gr6 02OCZ2JuCmROilSet/NJVyXsdKLipEtUlPLU4b3biYReBpq76C3SFV13c yri7biVXfK0nQsziqrq0ooTcyzaGdRHvanTWOf3LpsX0Bp3R3ps8WwxAz I=;
X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="301953259"
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/AES256-SHA; 18 Jan 2015 16:31:03 +1300
Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.148]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0174.001; Sun, 18 Jan 2015 16:31:03 +1300
From: Peter Gutmann 
To: "" 
Thread-Topic: [TLS] Using RSA PSS in TLS
Thread-Index: AdAyzy+o91yvLz4bRGO1KA470ddSeg==
Date: Sun, 18 Jan 2015 03:31:03 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAF5D521@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: 
Subject: Re: [TLS] Using RSA PSS in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 18 Jan 2015 03:31:07 -0000

=3D?windows-1252?Q?Manuel_P=3DE9gouri=3DE9-Gonnard?=3D  w=
rites:=0A=
=0A=
>Appparently [1] NSS and BoringSSL has been doing that for a few months now=
=0A=
>(though NSS seems to take steps to allow some variation), maybe they could=
=0A=
>provide some feedback?=0A=
>=0A=
>[1]: https://www.imperialviolet.org/2014/09/26/pkcs1.html=0A=
=0A=
I've been doing this for ages, and I believe OpenSSL does as well(?).  Neve=
r=0A=
had any problems (or at least none reported) so far...=0A=
=0A=
Peter.=


From nobody Sun Jan 18 11:07:22 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1FD71ACDED for ; Sun, 18 Jan 2015 11:07:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Level: 
X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 EsV1XYG_eRwl for ; Sun, 18 Jan 2015 11:07:16 -0800 (PST)
Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4B92F1ACDE0 for ; Sun, 18 Jan 2015 11:07:15 -0800 (PST)
Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id t0IJ6cwr001409; Sun, 18 Jan 2015 14:06:38 -0500
From: "Blumenthal, Uri - 0558 - MITLL" 
To: "'pgut001@cs.auckland.ac.nz'" , "'tls@ietf.org'" 
Thread-Topic: [TLS] Inclusion of OCB mode in TLS 1.3
Thread-Index: AdAyzbELxXQ6KPqgoEiVNz85RavZKgAhDGGN
Date: Sun, 18 Jan 2015 19:06:38 +0000
Message-ID: <65D2FD736B6B2B48B2EAD2BD189DC9CC1404EBDC@LLE2K10-MBX01.mitll.ad.local>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAF5D4FB@uxcn10-tdc05.UoA.auckland.ac.nz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [155.34.14.22]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33,  0.0.0000 definitions=2015-01-18_03:2015-01-16,2015-01-18,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1501180205
Archived-At: 
Cc: "'rogaway@cs.ucdavis.edu'" 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 18 Jan 2015 19:07:18 -0000

I like OCB, and in my opinion the current license that Phil granted is acce=
ptable to *any* OpenSSL user (unless a lawyer would say that I'm wrong here=
 and point at my mistake).=20

I think OCB should be included in TLS 1.3, and hopefully/maybe "retrofitted=
" to 1.2.

--
Regards,
Uri Blumenthal                            Voice: (781) 981-1638
Cyber Systems and Technology   Fax:   (781) 981-0186
MIT Lincoln Laboratory                Cell:  (339) 223-5363
244 Wood Street, Lexington, MA 02420-9185      =20

Web:  http://www.ll.mit.edu/CST/
MIT LL Root CA:  

----- Original Message -----
From: Peter Gutmann [mailto:pgut001@cs.auckland.ac.nz]
Sent: Saturday, January 17, 2015 10:20 PM=0A=
To:  
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3

Phillip Rogaway  writes:

>I suspect that most use-cases for TLS-with-OCB would already be covered by
>one of the prior patent-grants I've done.  But, for anything that might fa=
ll
>in a gap, the simplest thing, I suspect, is for me to do an "IETF Patent
>Disclosure and Licensing Declaration" specifying royalty-free licensing fo=
r
>use of OCB in compliance with a TLS-specifying RFC.  I'm happy to submit o=
ne
>of those.  I might need some help to identify what RFC number(s) to cite.

That would be great to have!  I've always liked OCB, but as an open-source
developer I don't have any control over how my code is used (beyond "you ha=
ve
to make the source code available", "you need to include an acknowledgement=
 in
your docs", or whatever the preferred license is), so I haven't been able t=
o
use it until now.  Being allowed to use it for a TLS implementation without
further restrictions would be a great help.

Peter.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


From nobody Sun Jan 18 11:38:40 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 682CB1ACCEB for ; Sun, 18 Jan 2015 04:06:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.353
X-Spam-Level: **
X-Spam-Status: No, score=2.353 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FSL_HELO_BARE_IP_2=1, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_NUMERIC_HELO=1.164, SPF_HELO_PASS=-0.001, 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 TF2hqdDrtK-R for ; Sun, 18 Jan 2015 04:06:38 -0800 (PST)
Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D10C1ACCD9 for ; Sun, 18 Jan 2015 04:06:37 -0800 (PST)
Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1YCoci-0005Iw-Tu for tls@ietf.org; Sun, 18 Jan 2015 13:06:33 +0100
Received: from 66.87.139.239 ([66.87.139.239]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 18 Jan 2015 13:06:32 +0100
Received: from eternaleye by 66.87.139.239 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 18 Jan 2015 13:06:32 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: tls@ietf.org
From: Alex Elsayed 
Date: Sun, 18 Jan 2015 04:06:23 -0800
Lines: 35
Message-ID: 
References: <54B5501A.4070402@azet.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7Bit
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: 66.87.139.239
User-Agent: KNode/4.14.3
Archived-At: 
X-Mailman-Approved-At: Sun, 18 Jan 2015 11:38:38 -0800
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 18 Jan 2015 12:06:41 -0000

Aaron Zauner wrote:

> Hi TLS-WG,
> 
> Over the last couple of days I've again looked into OCB, read the
> original paper as well as quite some literature on it, patents, CFRG
> discussion et cetera.
> 
> OCB looks like an elegant and parallel mode for inclusion in TLS.
> I've searched through recent TLS-WG discussion, OCB has been
> mentioned in passing as has EAX(2). When first looking into that my
> main concerns were:
> 
>    * IPR/patents: the authors have granted access to OSI licensed
>      software as well as to commercial (non military!) software for
>      all use [0] [1].


Note that while the authors have licensed their patents, IIRC there are 
still concerns over whether the Gligor & Donescu or Jutla patents [1] apply.

In addition, I'd like to call the attention of the group to the CAESAR AEAD 
competition [2], in which there are multiple entrants (and Rogaway &c has 
submitted a new mode "AEZ" in addition to OCB). There is a mailing list [3] 
for discussion and a wiki [4] which has collected the entrants, similar to 
the SHA-3 Zoo.

One thing in particular that may be worth thinking about is that several of 
the modes proposed are nonce-misuse resistant, akin to SIV.


[1] 6,963,976, 6,973,187, 7,093,126, and 8,107,620.
[2] http://competitions.cr.yp.to/caesar.html
[3] https://groups.google.com/forum/#!forum/crypto-competitions
[4] http://aezoo.compute.dtu.dk/


From SRS0=F53o=CF=acm.org=bmoeller@srs.kundenserver.de  Sun Jan 18 12:12:34 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0B251ACE13; Sun, 18 Jan 2015 12:12:34 -0800 (PST)
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 W6CkkXGJp6lf; Sun, 18 Jan 2015 12:12:33 -0800 (PST)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.187]) (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 D1F8F1ACE09; Sun, 18 Jan 2015 12:12:32 -0800 (PST)
Received: from mail-lb0-f181.google.com ([209.85.217.181]) by mrelayeu.kundenserver.de (mreue004) with ESMTPSA (Nemesis) id 0MCdZW-1Y4ijM0kl8-009Sdg; Sun, 18 Jan 2015 21:12:30 +0100
Received: by mail-lb0-f181.google.com with SMTP id u14so15698731lbd.12; Sun, 18 Jan 2015 12:12:01 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.112.172.194 with SMTP id be2mr26552349lbc.53.1421611921833;  Sun, 18 Jan 2015 12:12:01 -0800 (PST)
Received: by 10.25.25.145 with HTTP; Sun, 18 Jan 2015 12:12:01 -0800 (PST)
In-Reply-To: 
References: <20150109180539.22231.7270.idtracker@ietfa.amsl.com> <20150116210327.61046788@pc>  
Date: Sun, 18 Jan 2015 21:12:01 +0100
Message-ID: 
From: Bodo Moeller 
To: ietf@ietf.org
Content-Type: multipart/alternative; boundary=001a11c347309c0cb0050cf2d1ec
X-Provags-ID: V03:K0:9MGEetuGTqnMotLKM7S+qnhUGtOKki2HAZxCTwHOEvpMeEGIuDI gCZ0afQ0l/jXB9+9RlLaeF+DyMcAxA7YTQ/SbD/7gsLFqavSlbtgiFZR6byUjvj7/9FTcEV nWbwJ9UK0yjn+aA16Z8NMn71jEoygtqav0kXG7yLDyzOfK1QkJwQrl5GWeYi1RNzeDL7T30 5ZMqbfH2gh1jx3RaCX87w==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 18 Jan 2015 20:14:52 -0000

--001a11c347309c0cb0050cf2d1ec
Content-Type: text/plain; charset=UTF-8

Jeffrey Walton :

> Bodo Moeller  wrote:
>


> > Also, quite clearly, we can't yet know how the TLS 1.3 (1.4, 1.5, ...)
> > rollout will work out.
>


> The WG should be solving problems that do exist; and not manufactured
> problems or theoretical future problems that don't exist.


I can't entirely agree with second part of this statement: presumably
everyone in the TLS WG is well aware of past design decisions that didn't
take into account problems that didn't exist then but should have been
foreseeable.  (Related: I really shouldn't have had to write
https://www.openssl.org/~bodo/ssl-poodle.pdf to kill off the fallback to
SSL 3.0 in practice ... the "insecure fallback" to earlier protocol
versions, including SSL 3.0, was a known "theoretical problem", and
deserving of being addressed independently of concrete attacks).

I do agree with the sentiment, though: we shouldn't create Rube-Goldberg
protocol mechanisms that don't serve a demonstrable purpose (and yet TLS
arguably has a fair number of those).  If the I-D was all about solving a
theoretical problem with TLS 1.3, it shouldn't be accepted as an RFC (if
only because then the TLS 1.3 specification would be the right place to
specify the mechanism).

But of course, this isn't the case.  The main point of the I-D is not to
solve a problem with TLS 1.3.  Rather, the specification's main purpose, at
this time, is to solve problems with earlier versions.  Notably, the
mechanism from this specification has demonstrably protected users against
vulnerabilities such as POODLE.  It's just that the I-D achieves that by
specifying a version-independent mechanism that *also* lends itself to
addressing potential future problems with potential future protocol
versions.

Bodo

--001a11c347309c0cb0050cf2d1ec
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Jeff=
rey Walton <noloader@gmail.com>:
Bodo Moeller <bmoeller@ac=
m.org> wrote:
=C2=A0

> Also, quite clearly, we can't yet know how=
 the TLS 1.3 (1.4, 1.5, ...)

> rollout will work out.
=C2=A0

The WG should be solving problems that do exist; and not manufacture=
d

problems or theoretical future problems that don't exist.<=
div>
I can't entirely agree with second part of this stat=
ement: presumably everyone in the TLS WG is well aware of past design decis=
ions that didn't take into account problems that didn't exist then =
but should have been foreseeable. =C2=A0(Related: I really shouldn't ha=
ve had to write=C2=A0https://www.openssl.org/~bodo/ssl-poodle.pdf to kill off the fallbac=
k to SSL 3.0 in practice ... the "insecure fallback" to earlier p=
rotocol versions, including SSL 3.0, was a known "theoretical problem&=
quot;, and deserving of being addressed independently of concrete attacks).=


I do agree with the sentiment, though: we shouldn=
't create Rube-Goldberg protocol mechanisms that don't serve a demo=
nstrable purpose (and yet TLS arguably has a fair number of those).=C2=A0 I=
f the I-D was all about solving a theoretical problem with TLS 1.3, it shou=
ldn't be accepted as an RFC (if only because then the TLS 1.3 specifica=
tion would be the right place to specify the mechanism).

But of course, this isn't the case.=C2=A0 The main point of the =
I-D is not to solve a problem with TLS 1.3.=C2=A0 Rather, the specification=
's main purpose, at this time, is to solve problems with earlier versio=
ns.=C2=A0 Notably, the mechanism from this specification has demonstrably p=
rotected users against vulnerabilities such as POODLE.=C2=A0 It's just =
that the I-D achieves that by specifying a version-independent mechanism th=
at *also* lends itself to addressing potential future problems with potenti=
al future protocol versions. =C2=A0

Bodo



--001a11c347309c0cb0050cf2d1ec--


From nobody Sun Jan 18 12:32:55 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE3B61ACE17 for ; Sun, 18 Jan 2015 12:32:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level: 
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 mggX_0Mrm9o9 for ; Sun, 18 Jan 2015 12:32:53 -0800 (PST)
Received: from mail-ob0-f171.google.com (mail-ob0-f171.google.com [209.85.214.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01CB51ACE10 for ; Sun, 18 Jan 2015 12:32:53 -0800 (PST)
Received: by mail-ob0-f171.google.com with SMTP id va2so16173247obc.2 for ; Sun, 18 Jan 2015 12:32:52 -0800 (PST)
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=/qDXqQV480N85UppqKbkErudLi9P9Yoev62pcaEh/Fc=; b=iW8wjPeNJkj9OghaTJ7cd3XN7RrHegApaf5noylUMJozJWGOT+QWz/vqOrwWhEhU3o 5wDmPhtfhgA9hNGEhjDrtQQMOop2j3wgzUrJSkbh8+ymvI3T8X4NUjxYxg9z+ixKaDkp E+Ik/MRgooVkQpkxUFAUF9T78cwm6wySzEwdrfKazJA0WBVaY5dzA8h1tA0XOeTW8rPL uaKy/gKA4M7yAOjuDlesjXbI4DYmvi6/mOxs1iLWYlvkA6aY/t3fqE7+F2COOScpISdX RhyLYu/uOYwtrPuIG3zzqkJXyyXtYoyjxIPVMDoh/ty+jndvH+o1usrM9n0JexVZiyZj 23BQ==
X-Gm-Message-State: ALoCoQlLwpBwStmtgehLjdDTcRxaPFwkTojdqpJA67myw0AnVEMaspDccX2Lrdp9grnCvJUFwBTy
MIME-Version: 1.0
X-Received: by 10.202.228.9 with SMTP id b9mr6813953oih.40.1421613172272; Sun, 18 Jan 2015 12:32:52 -0800 (PST)
Received: by 10.76.129.235 with HTTP; Sun, 18 Jan 2015 12:32:52 -0800 (PST)
In-Reply-To: <20150109180539.22231.7270.idtracker@ietfa.amsl.com>
References: <20150109180539.22231.7270.idtracker@ietfa.amsl.com>
Date: Sun, 18 Jan 2015 12:32:52 -0800
Message-ID: 
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= 
To: ietf@ietf.org
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 18 Jan 2015 20:32:54 -0000

On Fri, Jan 9, 2015 at 10:05 AM, The IESG  wrote:
>
> The IESG has received a request from the Transport Layer Security WG
> (tls) to consider the following document:
> - 'TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing
>    Protocol Downgrade Attacks'
>    as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf@ietf.org mailing lists by 2015-01-23. Exceptionally, comments may be
> sent to iesg@ietf.org instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.

+1 on making this document a standard.

The mechanism seems sensible and pragmatic.  I have implemented the
mechanism on the server side and the document was clear and helpful;
it took only a few minutes.

I'm not clear on how the IANA process works, but if the document
progresses to RFC (in any status); it'd be great if the existing
extension number and alert values were to remain the same.

-- 
Colm


From nobody Mon Jan 19 00:02:01 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2B71ACEBD; Mon, 19 Jan 2015 00:01:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.66
X-Spam-Level: 
X-Spam-Status: No, score=-0.66 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, 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 20BecAGNQ1ju; Mon, 19 Jan 2015 00:01:57 -0800 (PST)
Received: from BLU004-OMC3S32.hotmail.com (blu004-omc3s32.hotmail.com [65.55.116.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CAE91AD17F; Mon, 19 Jan 2015 00:01:57 -0800 (PST)
Received: from BLU177-W42 ([65.55.116.74]) by BLU004-OMC3S32.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751);  Mon, 19 Jan 2015 00:01:56 -0800
X-TMN: [MRhLzkU2H23UEjszIlYRKPdhvjc7RmKD]
X-Originating-Email: [yuhongbao_386@hotmail.com]
Message-ID: 
From: Yuhong Bao 
To: Bodo Moeller , "ietf@ietf.org" 
Date: Mon, 19 Jan 2015 00:01:55 -0800
Importance: Normal
In-Reply-To: 
References: <20150109180539.22231.7270.idtracker@ietfa.amsl.com>, <20150116210327.61046788@pc>, , , 
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 19 Jan 2015 08:01:56.0329 (UTC) FILETIME=[31A2A590:01D033BE]
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Jan 2015 08:01:59 -0000

=0A=
=0A=
________________________________=0A=
> Date: Sun=2C 18 Jan 2015 21:12:01 +0100 =0A=
> From: bmoeller@acm.org =0A=
> To: ietf@ietf.org =0A=
> CC: tls@ietf.org =0A=
> Subject: Re: [TLS] Last Call:  =0A=
> (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing =0A=
> Protocol Downgrade Attacks) to Proposed Standard =0A=
> =0A=
> Jeffrey Walton >: =0A=
> Bodo Moeller > wrote: =0A=
> =0A=
>> Also=2C quite clearly=2C we can't yet know how the TLS 1.3 (1.4=2C 1.5=
=2C ...) =0A=
>> rollout will work out. =0A=
> =0A=
> The WG should be solving problems that do exist=3B and not manufactured =
=0A=
> problems or theoretical future problems that don't exist. =0A=
> =0A=
> I can't entirely agree with second part of this statement: presumably =0A=
> everyone in the TLS WG is well aware of past design decisions that =0A=
> didn't take into account problems that didn't exist then but should =0A=
> have been foreseeable. (Related: I really shouldn't have had to =0A=
> write https://www.openssl.org/~bodo/ssl-poodle.pdf to kill off the =0A=
> fallback to SSL 3.0 in practice ... the "insecure fallback" to earlier =
=0A=
> protocol versions=2C including SSL 3.0=2C was a known "theoretical =0A=
> problem"=2C and deserving of being addressed independently of concrete =
=0A=
> attacks). =0A=
POODLE being in the news probably helped pushed admins to fix these servers=
=2C=A0=0A=
though it wasn't initially made clear that TLS extension intolerance can al=
so cause SSLv3 fallback.=0A=
=0A=
 		 	   		  =


From nobody Mon Jan 19 00:11:04 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 585711AD1BF for ; Mon, 19 Jan 2015 00:11:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.713
X-Spam-Level: 
X-Spam-Status: No, score=-4.713 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, 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 Wir-DJ5w6obg for ; Mon, 19 Jan 2015 00:11:01 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD48A1AD17F for ; Mon, 19 Jan 2015 00:11:00 -0800 (PST)
Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t0J8Axb2005128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 19 Jan 2015 03:10:59 -0500
Received: from dhcp-2-127.brq.redhat.com (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t0J8AvfC002713 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 19 Jan 2015 03:10:58 -0500
Message-ID: <1421655057.2854.5.camel@redhat.com>
From: Nikos Mavrogiannopoulos 
To: Manuel =?ISO-8859-1?Q?P=E9gouri=E9-Gonnard?= 
Date: Mon, 19 Jan 2015 09:10:57 +0100
In-Reply-To: <54BA315A.7020804@polarssl.org>
References: <54B5501A.4070402@azet.org>  <54B58F5B.2010704@cs.tcd.ie> <54B6815A.7060102@azet.org>  <54B9352C.70203@azet.org> <54BA315A.7020804@polarssl.org>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
Archived-At: 
Cc: TLS Mailing List 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Jan 2015 08:11:02 -0000

On Sat, 2015-01-17 at 10:54 +0100, Manuel Pégourié-Gonnard wrote:
> On 16/01/2015 16:58, Aaron Zauner wrote:
> > I came up with the following list of cipher-suites applicable to >= TLS 1.2:
> > 
> > (EC)DHE:
> > TLS_DHE_RSA_WITH_AES_128_OCB	
> > TLS_DHE_RSA_WITH_AES_256_OCB
> > TLS_ECDHE_RSA_WITH_AES_128_OCB
> > TLS_ECDHE_RSA_WITH_AES_256_OCB
> > TLS_ECDHE_ECDSA_WITH_AES_128_OCB
> > TLS_ECDHE_ECDSA_WITH_AES_256_OCB
> > 
> > PSK:
> > TLS_DHE_PSK_WITH_AES_128_OCB
> > TLS_DHE_PSK_WITH_AES_256_OCB	
> > TLS_ECDHE_PSK_WITH_AES_128_OCB
> > TLS_ECDHE_PSK_WITH_AES_256_OCB
> > 
> I think it would make sense to also include pure PSK (no DH) suite for very
> constrained devices that can't afford the asymetric crypto.

Plain PSK can also be used to establish an additional channel in an
existing TLS connection (which may already already be under PFS).

regards,
Nikos



From nobody Mon Jan 19 01:03:16 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 322631AD359 for ; Mon, 19 Jan 2015 01:03:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level: 
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_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 QupeZiM1FuXt for ; Mon, 19 Jan 2015 01:03:14 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CFA31AD210 for ; Mon, 19 Jan 2015 01:03:14 -0800 (PST)
Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t0J93B0L018810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 19 Jan 2015 04:03:12 -0500
Received: from dhcp-2-127.brq.redhat.com (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t0J939J1015624 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 19 Jan 2015 04:03:10 -0500
Message-ID: <1421658189.2854.11.camel@redhat.com>
From: Nikos Mavrogiannopoulos 
To: Aaron Zauner 
Date: Mon, 19 Jan 2015 10:03:09 +0100
In-Reply-To: <20150117151105.GA5549@typhoon.azet.org>
References: <54B5501A.4070402@azet.org>  <54B58F5B.2010704@cs.tcd.ie> <54B6815A.7060102@azet.org>  <54B9352C.70203@azet.org> <54BA315A.7020804@polarssl.org> <20150117151105.GA5549@typhoon.azet.org>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Archived-At: 
Cc: Manuel =?ISO-8859-1?Q?P=E9gouri=E9-Gonnard?= , TLS Mailing List 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Jan 2015 09:03:15 -0000

On Sat, 2015-01-17 at 16:11 +0100, Aaron Zauner wrote:
> > > (EC)DHE:
> > > TLS_DHE_RSA_WITH_AES_128_OCB	
> > > TLS_DHE_RSA_WITH_AES_256_OCB
> > > TLS_ECDHE_RSA_WITH_AES_128_OCB
> > > TLS_ECDHE_RSA_WITH_AES_256_OCB
> > > TLS_ECDHE_ECDSA_WITH_AES_128_OCB
> > > TLS_ECDHE_ECDSA_WITH_AES_256_OCB
> > > 
> > > PSK:
> > > TLS_DHE_PSK_WITH_AES_128_OCB
> > > TLS_DHE_PSK_WITH_AES_256_OCB	
> > > TLS_ECDHE_PSK_WITH_AES_128_OCB
> > > TLS_ECDHE_PSK_WITH_AES_256_OCB
> > > 
> > I think it would make sense to also include pure PSK (no DH) suite for very
> > constrained devices that can't afford the asymetric crypto.
> 
> Makes sense. So your suggestion is to swap or add these
> ciphersuites? I have no real-world data on the usage of TLS with
> pre-shared keys, nor it's deployment. I can only guess, would be
> interesting to hear the opinion of embedded development people on
> that subject.

I don't believe you can second guess here. There can be many valid
use-cases unknown to anyone in the WG, or IETF, as PSK is often used in
protocols which are non-standardized or standardized outside IETF.

regards,
Nikos



From nobody Mon Jan 19 06:03:40 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66B721B2A5D for ; Mon, 19 Jan 2015 06:03:38 -0800 (PST)
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 sF79QSHKAn-F for ; Mon, 19 Jan 2015 06:03:36 -0800 (PST)
Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BE5B1B2A2A for ; Mon, 19 Jan 2015 06:03:36 -0800 (PST)
Received: by mail-wi0-f171.google.com with SMTP id l15so7572943wiw.4 for ; Mon, 19 Jan 2015 06:03:35 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=mzrsGKVemSOXfx6JzE0l/tLEwTkc/kP1Q3xD3YLVU4k=; b=gkikPqTH2+MZky5fzQT8DjTVmTqTXrB7eXFE+zJhvLEEQ/dAewgvAVWyQL6Dr0lyuC xSmFBZb2P8gND54TOAR7bexgndRn6hynbwAYU3rvi5hhoMu12bNivxoadbhnJA9C6q7e 0WPzwaCYU5yJ6HSlkU2BwmM+EkNrbiMqeAgZKEayrj9bYFTdF2x2gSu4HYoNcckqQYr7 VUxnoLvIGG7a6kd3D4YxH2iKS+dy7NGhFhfU/lR0mTrvHrMw4hRiUAzDLNNxGwr12dfY huQMMlSay5cbLyAEXKrtNWHjiXBH9FqMYFMdSISUs0hbFH2P9jkc01US80f6hxH0AM2B zfEA==
X-Gm-Message-State: ALoCoQlmF0MLoFOJJfTkfekrZL5Fg1eKlippymKQ+ME4fOYVtvVlYBroT9mOIPRDR0HOeSwWDaYg
X-Received: by 10.194.24.103 with SMTP id t7mr33787529wjf.15.1421676215156; Mon, 19 Jan 2015 06:03:35 -0800 (PST)
Received: from [10.0.0.142] (chello080108032135.14.11.univie.teleweb.at. [80.108.32.135]) by mx.google.com with ESMTPSA id i3sm14313011wie.23.2015.01.19.06.03.33 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 Jan 2015 06:03:34 -0800 (PST)
Message-ID: <54BD0EB2.3050009@azet.org>
Date: Mon, 19 Jan 2015 15:03:30 +0100
From: Aaron Zauner 
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: Alex Elsayed 
References: <54B5501A.4070402@azet.org> 
In-Reply-To: 
X-Enigmail-Version: 1.2.3
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig2AF425961A7F66DC2480836E"
Archived-At: 
Cc: tls@ietf.org
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Jan 2015 14:03:38 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig2AF425961A7F66DC2480836E
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Alex Elsayed wrote:
> Aaron Zauner wrote:
>=20
>> Hi TLS-WG,
>>
>> Over the last couple of days I've again looked into OCB, read the
>> original paper as well as quite some literature on it, patents, CFRG
>> discussion et cetera.
>>
>> OCB looks like an elegant and parallel mode for inclusion in TLS.
>> I've searched through recent TLS-WG discussion, OCB has been
>> mentioned in passing as has EAX(2). When first looking into that my
>> main concerns were:
>>
>>    * IPR/patents: the authors have granted access to OSI licensed
>>      software as well as to commercial (non military!) software for
>>      all use [0] [1].
> 
>=20
> Note that while the authors have licensed their patents, IIRC there are=
=20
> still concerns over whether the Gligor & Donescu or Jutla patents [1] a=
pply.
>=20
> In addition, I'd like to call the attention of the group to the CAESAR =
AEAD=20
> competition [2], in which there are multiple entrants (and Rogaway &c h=
as=20
> submitted a new mode "AEZ" in addition to OCB). There is a mailing list=
 [3]=20
> for discussion and a wiki [4] which has collected the entrants, similar=
 to=20
> the SHA-3 Zoo.

I've already noted CAESAR in this thread. The problem being: the
competition ends in 2017 as far as I know. Until then we're stuck with
what we have right now (plus ChaCha20/Poly1305 probably).

Aaron

>=20
> One thing in particular that may be worth thinking about is that severa=
l of=20
> the modes proposed are nonce-misuse resistant, akin to SIV.
>=20
>=20
> [1] 6,963,976, 6,973,187, 7,093,126, and 8,107,620.
> [2] http://competitions.cr.yp.to/caesar.html
> [3] https://groups.google.com/forum/#!forum/crypto-competitions
> [4] http://aezoo.compute.dtu.dk/


--------------enig2AF425961A7F66DC2480836E
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUvQ6zAAoJEOTbZJL9ubXV6A8QAJWhVk46l/rY5DEdeqrMwQ7Q
FwilTwxuUSgohjMUPJxp/qFrLKPdxsieFHR42ogJhTMoiIvAmbyIXPPPQqpLwGnS
gJHanmi6uvNSYjfZXArEAbCYSu9ym4rJx9SHvPMp1G2aqpyW6eEgZi8AB9UCyEk3
lyvjhd1ok+tXVfOGyAY0lpExojm6yrBuJxIBoWk0ZHAvYBoOvpIBB1FdG1fHaqbY
Q2fqn790i33I8rIRCPP6x7thB4+tAb+dLIkznZw9pWuxJSEBNBF8fDeWftUDczEM
0rvz270YCeC8W/LyeeVtwvS7SU8SRHtobFLAGeLF6F8KpHbiV2FOHD5D8A5XooJb
uD/xk5DV9GxoWYyu0X9tNwQLaTUgSUldPHxD2W+d97GOKVhHYX50tjiyPgqDS+15
lrUc9VJiDc5HOL7/3HEDcuuYupvO49iv9Bu2B2NJ8OzVZEdmP+giiELkw4f2zaSe
Yf9FLWyk5y9UOF1Bfw2JiUpUoFFtIeA1ewbASqhHLEBhZpkeK3ZFPxA2l1p2okCj
qMF2jP5DxXzltozymIzuadEIkPnkt5RZHh1Ov93eHrr1ocWWbOh8HxzMrDxnx8aD
qFIRXkDGzf7V6lKcwBf+0wA+xkMGU4HkKfWZJjVJM1laC18/g69uMX4YLDuqh1pz
A8kwGrGw7uAj4/pmqMJY
=0MXd
-----END PGP SIGNATURE-----

--------------enig2AF425961A7F66DC2480836E--


From nobody Mon Jan 19 06:07:05 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D50771B2A8B for ; Mon, 19 Jan 2015 06:07:02 -0800 (PST)
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 fFat0WE0BaYx for ; Mon, 19 Jan 2015 06:07:01 -0800 (PST)
Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5596C1B2A2A for ; Mon, 19 Jan 2015 06:06:59 -0800 (PST)
Received: by mail-wi0-f170.google.com with SMTP id em10so5808488wid.1 for ; Mon, 19 Jan 2015 06:06:58 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=HbIFBSFTxS2oAftzcKw9GqYhE72Y4p0JCv7ILc7FU9c=; b=YcGVY/A+avXlyledIcqP0jaEsmgV7CYx3gBkdxKI1k89wgpMbOba7U/sQcSrx4IHyM ythPdEtat4ksKOLHamglItfUEpIgt0DRzhkuC+wJ25BSnnUH5N9bbreKKQIQCd2SIR9j FMR4+Rsi55g4XJcE3my57aVAxsHx1+vGG0GQVdMCbcLKZWGA1oTY0ZxncIXqm5MMZls6 idcm4LrSvhiLqE8znW9fK4pI0bs3DY4ZQ7+LiWyGMOtbxu8V14K4fe6J6vV20diN5n7t 4rOSVyPSWH5IHBuPL158H8l6FVoORkMWOdYkLW3CWZxB+KIws/rTwpI85LQjiNuSWMAa QJUw==
X-Gm-Message-State: ALoCoQk0QFr9eju7/Wa0exHjA8SJiLHMtIEVafFTh646hL1pPhgZGmrQWXefFl1Qk9VydJYaVdla
X-Received: by 10.180.211.34 with SMTP id mz2mr35548298wic.56.1421676418086; Mon, 19 Jan 2015 06:06:58 -0800 (PST)
Received: from [10.0.0.142] (chello080108032135.14.11.univie.teleweb.at. [80.108.32.135]) by mx.google.com with ESMTPSA id hn2sm17429202wjc.5.2015.01.19.06.06.56 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 Jan 2015 06:06:57 -0800 (PST)
Message-ID: <54BD0F7E.9020300@azet.org>
Date: Mon, 19 Jan 2015 15:06:54 +0100
From: Aaron Zauner 
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: Nikos Mavrogiannopoulos 
References: <54B5501A.4070402@azet.org>  <54B58F5B.2010704@cs.tcd.ie> <54B6815A.7060102@azet.org>  <54B9352C.70203@azet.org> <54BA315A.7020804@polarssl.org> <20150117151105.GA5549@typhoon.azet.org> <1421658189.2854.11.camel@redhat.com>
In-Reply-To: <1421658189.2854.11.camel@redhat.com>
X-Enigmail-Version: 1.2.3
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig013A8752B745C0000FC6B66F"
Archived-At: 
Cc: =?UTF-8?B?TWFudWVsIFDDqWdvdXJpw6ktR29ubmFyZA==?= , TLS Mailing List 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Jan 2015 14:07:03 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig013A8752B745C0000FC6B66F
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



Nikos Mavrogiannopoulos wrote:
> On Sat, 2015-01-17 at 16:11 +0100, Aaron Zauner wrote:
>>>> (EC)DHE:
>>>> TLS_DHE_RSA_WITH_AES_128_OCB=09
>>>> TLS_DHE_RSA_WITH_AES_256_OCB
>>>> TLS_ECDHE_RSA_WITH_AES_128_OCB
>>>> TLS_ECDHE_RSA_WITH_AES_256_OCB
>>>> TLS_ECDHE_ECDSA_WITH_AES_128_OCB
>>>> TLS_ECDHE_ECDSA_WITH_AES_256_OCB
>>>>
>>>> PSK:
>>>> TLS_DHE_PSK_WITH_AES_128_OCB
>>>> TLS_DHE_PSK_WITH_AES_256_OCB=09
>>>> TLS_ECDHE_PSK_WITH_AES_128_OCB
>>>> TLS_ECDHE_PSK_WITH_AES_256_OCB
>>>>
>>> I think it would make sense to also include pure PSK (no DH) suite fo=
r very
>>> constrained devices that can't afford the asymetric crypto.
>> Makes sense. So your suggestion is to swap or add these
>> ciphersuites? I have no real-world data on the usage of TLS with
>> pre-shared keys, nor it's deployment. I can only guess, would be
>> interesting to hear the opinion of embedded development people on
>> that subject.
>=20
> I don't believe you can second guess here. There can be many valid
> use-cases unknown to anyone in the WG, or IETF, as PSK is often used in=

> protocols which are non-standardized or standardized outside IETF.
>=20

I'm not trying to second guess anybody/anything. I'd like to have some
common ground. If I take the lead from RFC6655 (AES-CCM) that'd be:

CipherSuite TLS_PSK_WITH_AES_128_OCB
CipherSuite TLS_PSK_WITH_AES_256_OCB
CipherSuite TLS_DHE_PSK_WITH_AES_128_OCB
CipherSuite TLS_DHE_PSK_WITH_AES_256_OCB

Plus:

>>>> TLS_ECDHE_PSK_WITH_AES_128_OCB
>>>> TLS_ECDHE_PSK_WITH_AES_256_OCB

Does this make sense for you?

Thanks,
Aaron


--------------enig013A8752B745C0000FC6B66F
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUvQ9+AAoJEOTbZJL9ubXVANoQAOwPfB5/5JJ6blCS+uy+xmn3
B+H5+fJ/xIuwZ1jFNbp5wgXA0F4d5UA5NQVloTe0aDQJUMX5EqhoN2fdGJIe+Hly
gE4gjif8SGyjGJBaTDPFkIcblypKU7XxC0mZx7qHR7davOr1pGcorpS9J2ERQFVm
cjKfVOMyYLhIKHfVomLVgzEUIbSoTp/babaCVPvWgmWUZX/hr61b/ibIAd9z6+uE
kJ/iZNiL+O/A3ZkxXX5+jK+oVbBHA+UK/xLzhmq0LhVRaVRmLqw60Un2/ekve6E0
6H9zE6AJRSdv74/4vv6LUeSphzyLO5u/ptYfFzzABBH9wpdDgGHSIYLr1a0nUzS7
nA0PoKepcdQ5wWDwY1urZyGZ+lHklvMq4NxoMZ9ufmxhotGxJ3NPNSAkLYWJvTeq
m11deGIaD/wbT+Y9XTI4LnrAYC//FXk8pKkOVS28cZO8qmVPGynJ+higoNFhTa6y
GOAsPllM6//MW8mP7XYunjArBvuZEt/Hg0Qu9U10A+sHdoGogOdsRkA3JKyxqOJF
hvyEKai4op6VxjpvIeg1l8cRS2xCQ+aKpBkLlvHE18yczviptOe5x9nEvcd1ubmf
8QflrPu89OWmGM11iQOXE0gWuudYkjji1k2ZLflEoXUoYDIbuz4/PoX3Gf3RY+CM
m4yXWSZ8ZMF8FEBNC0in
=xcpr
-----END PGP SIGNATURE-----

--------------enig013A8752B745C0000FC6B66F--


From nobody Mon Jan 19 06:12:16 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 064501B2A2A for ; Mon, 19 Jan 2015 06:12:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level: 
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, 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 9erKDWWJ0cvg for ; Mon, 19 Jan 2015 06:12:09 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F41A71AD2A9 for ; Mon, 19 Jan 2015 06:12:08 -0800 (PST)
Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t0JEC62e018267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 19 Jan 2015 09:12:06 -0500
Received: from dhcp-2-127.brq.redhat.com (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t0JEC4at010658 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 19 Jan 2015 09:12:06 -0500
Message-ID: <1421676724.2854.17.camel@redhat.com>
From: Nikos Mavrogiannopoulos 
To: Aaron Zauner 
Date: Mon, 19 Jan 2015 15:12:04 +0100
In-Reply-To: <54BD0F7E.9020300@azet.org>
References: <54B5501A.4070402@azet.org>  <54B58F5B.2010704@cs.tcd.ie> <54B6815A.7060102@azet.org>  <54B9352C.70203@azet.org> <54BA315A.7020804@polarssl.org> <20150117151105.GA5549@typhoon.azet.org> <1421658189.2854.11.camel@redhat.com> <54BD0F7E.9020300@azet.org>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Archived-At: 
Cc: Manuel =?ISO-8859-1?Q?P=E9gouri=E9-Gonnard?= , TLS Mailing List 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Jan 2015 14:12:14 -0000

On Mon, 2015-01-19 at 15:06 +0100, Aaron Zauner wrote:

> >>> I think it would make sense to also include pure PSK (no DH) suite for very
> >>> constrained devices that can't afford the asymetric crypto.
> >> Makes sense. So your suggestion is to swap or add these
> >> ciphersuites? I have no real-world data on the usage of TLS with
> >> pre-shared keys, nor it's deployment. I can only guess, would be
> >> interesting to hear the opinion of embedded development people on
> >> that subject.
> > I don't believe you can second guess here. There can be many valid
> > use-cases unknown to anyone in the WG, or IETF, as PSK is often used in
> > protocols which are non-standardized or standardized outside IETF.
> I'm not trying to second guess anybody/anything. I'd like to have some
> common ground. If I take the lead from RFC6655 (AES-CCM) that'd be:
> CipherSuite TLS_PSK_WITH_AES_128_OCB
> CipherSuite TLS_PSK_WITH_AES_256_OCB
> CipherSuite TLS_DHE_PSK_WITH_AES_128_OCB
> CipherSuite TLS_DHE_PSK_WITH_AES_256_OCB
> Plus:
> >>>> TLS_ECDHE_PSK_WITH_AES_128_OCB
> >>>> TLS_ECDHE_PSK_WITH_AES_256_OCB
> Does this make sense for you?

Yes that looks reasonable.

regards,
Nikos



From nobody Mon Jan 19 07:55:07 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF951B2AAE for ; Mon, 19 Jan 2015 07:55:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Level: 
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 1-T_PC5Fo2-O for ; Mon, 19 Jan 2015 07:54:59 -0800 (PST)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5A8A1AD10A for ; Mon, 19 Jan 2015 07:54:58 -0800 (PST)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 9327E3A247; Mon, 19 Jan 2015 16:54:56 +0100 (CET)
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 6503641FF5; Mon, 19 Jan 2015 16:54:56 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 5B5541B0FE; Mon, 19 Jan 2015 16:54:56 +0100 (CET)
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D55AED04B@USMBX1.msg.corp.akamai.com>
To: "Salz, Rich" 
Date: Mon, 19 Jan 2015 16:54:56 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20150119155456.5B5541B0FE@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Jan 2015 15:55:04 -0000

Salz, Rich wrote:
>> without all of the massive serious operational problems of
>> the current fallback-scsv proposal:
> 
> Can you elaborate on what this problems are?

The current document scratches the tip of the iceberg here:
   https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-03#section-5


We know that part of the problem isn't TLS version/extension intolerant
servers, but version/extension intolerant middle-boxes.  These can be
client-side middleboxes, network middle-boxes or servers-side middleboxes.
In such cases, the server will only see handshakes with the
fallback SCSV asserted and, if it supports a sufficiently new protocol
will (have to) abort all TLS handshakes that reach the server in a
knee-jerk-reaction if it follows that proposal.  There is exactly zero
room for common sense behaviour left by this proposal.

We also know that there is a significant amount of installed-base servers
which never return any fatal SSL alerts before closing a network connection
after a TLS handshake failure (Microsoft IIS), because they're using
a transport-less TLS protocol stack and the application caller (not just
the TLS server-side implementation) will have to be changed in order to
make a fatal TLS alert newly appear on the network.

Aborting the TLS handshake is going to be the most stupid behaviour
in any case, because it will require a new TCP connection and a
new TCP handshake, plus any necessary app-level protocol negotiation
(HTTP CONNECT proxy traversal and pre-STARTTLS protocol handshakes)
to be repeated.


It would be so *MUCH* cleaner and easier when a different server behaviour
was specified and allowed (rather than rubber-stamping the knee-jerk-reaction),
such as allowing the server to continue the TLS handshake with
protocol version (ClientHello.client_version + 1) when ClientHello
contained the FALLBACK_SCSV among the TLS ciphersuites.

Such server behaviour would still allow the client to recognize that
the server could do better when offered, and allow the client to perform
sensible risk management -- becaus only the client knows what kind of
"better" protocol options it did not offer (remove) from his ClientHello
and how often it attempted to connect to the server.

Continuation of the handshake would also work much nicer (not require any
app-level changes) with servers such as Microsoft IIS, which currently
do not send fatal alerts back before closing the network connection.


(the only thing we would have to addtionally specify for servers
 continuing with (ClientHello.client_version + 1) is to skip doing
 the protocol version check on the RSA premaster secret for
 static-RSA key exchanges).


Another problem of the current proposal is that it addresses only
TLS version intolerance, but not TLS extension intolerance.  *BOTH*
exist out there.  And it doesn't really address reconnect fallbacks
that skip TLS versions on the downgrade dance.   MSIE 8 on Windows 7
will apparently perform the downgrade dance in the fashion
  TLSv1.2 -> TLSv1.0 -> SSLv3

This gets more important if the cause for handshake failures are
middle-boxes rather than the servers themselves.

-Martin


From nobody Mon Jan 19 09:24:40 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB641B2B7F for ; Mon, 19 Jan 2015 09:24:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 D_Bn3WqmERff for ; Mon, 19 Jan 2015 09:24:36 -0800 (PST)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id DC53F1B2B80 for ; Mon, 19 Jan 2015 09:24:33 -0800 (PST)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id D1C5D47681; Mon, 19 Jan 2015 17:24:32 +0000 (GMT)
Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id B224C47692; Mon, 19 Jan 2015 17:24:32 +0000 (GMT)
Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 9929C8003C; Mon, 19 Jan 2015 17:24:32 +0000 (GMT)
Received: from USMA1EX-DAG1MB2.msg.corp.akamai.com (172.27.123.102) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 19 Jan 2015 12:21:52 -0500
Received: from USMA1EX-DAG1MB2.msg.corp.akamai.com ([172.27.123.102]) by usma1ex-dag1mb2.msg.corp.akamai.com ([172.27.123.102]) with mapi id 15.00.0913.011; Mon, 19 Jan 2015 12:21:34 -0500
From: "Salz, Rich" 
To: "mrex@sap.com" 
Thread-Topic: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
Thread-Index: AdAyEhVWyLDgM1CAS6idf8kmsrjvAgAcY7MQAGmifAAAB5d7cA==
Date: Mon, 19 Jan 2015 17:21:33 +0000
Message-ID: <40128f312378442fbd26459bf5d7593b@usma1ex-dag1mb2.msg.corp.akamai.com>
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D55AED04B@USMBX1.msg.corp.akamai.com> <20150119155456.5B5541B0FE@ld9781.wdf.sap.corp>
In-Reply-To: <20150119155456.5B5541B0FE@ld9781.wdf.sap.corp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.19.57.202]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Jan 2015 17:24:38 -0000

I read your note very carefully.  It is a nice detailed list of things that=
 could be improved.

But I see no elucidation of any massive serious operational problems.  The =
I-D section you pointed to contains an answer. Many large network operators=
 have rolled this out, and the net has been pretty silent about any "tales =
of woe."

	/r$

-- =20
Principal Security Engineer, Akamai Technologies
IM: rsalz@jabber.me Twitter: RichSalz



From nobody Mon Jan 19 11:27:11 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE0BB1B2C0F for ; Mon, 19 Jan 2015 11:27:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Level: 
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 6j-IMDlHpUfy for ; Mon, 19 Jan 2015 11:27:04 -0800 (PST)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26FBB1B2C11 for ; Mon, 19 Jan 2015 11:27:03 -0800 (PST)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 2BEF83A270; Mon, 19 Jan 2015 20:27:01 +0100 (CET)
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 1FAB6420BE; Mon, 19 Jan 2015 20:27:01 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 190C71B0FF; Mon, 19 Jan 2015 20:27:01 +0100 (CET)
In-Reply-To: <40128f312378442fbd26459bf5d7593b@usma1ex-dag1mb2.msg.corp.akamai.com>
To: "Salz, Rich" 
Date: Mon, 19 Jan 2015 20:27:01 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20150119192701.190C71B0FF@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Jan 2015 19:27:08 -0000

Salz, Rich wrote:
> I read your note very carefully.
> It is a nice detailed list of things that could be improved.

Permitting the server to continue the TLS handshake with
ServerHello.server_version = (ClientHello.client_version +1)

This would be an extremely small change, but a *HUGE* improvement to this
proposal and make TLS handshakes _succeed_, i.e. promote interop.
Should a TLS client be unsatisfied with the properties of the resulting
TLS session, that client could still decide attempting a new/different
handshake by proposing additional features in ClientHello (that should
have never been absent from ClientHello in the first place).

And this improvement is something that I could imagine implementing
for our servers -- other than the currently specified knee-jerk-reaction.


> 
> But I see no elucidation of any massive serious operational problems.
> The I-D section you pointed to contains an answer.

The current last call is a request to rubber-stamp the current
fallback-scsv proposal, that wants to require from the server
an unconditional knee-jerk-reaction and complete interop failure,
onto the standards track.

It is difficult to conceive a proposal that violates rfc2116 section 6
in a more serious fashion than the current fallback-scsv proposal --
and fixing this would be trivial (see above).


It's not that suggestions to improvement to this proposal haven't been
made.  It's really disappointing to see this go _through_ the TLS WG
and not seeing any improvement whatsoever, and then going straight
to asking for rubber-stamping it.


http://www.ietf.org/mail-archive/web/tls/current/msg11238.html
http://www.ietf.org/mail-archive/web/tls/current/msg11221.html



>
> Many large network operators have rolled this out, and the net has
> been pretty silent about any "tales of woe."


If all of the parties that you care for already have this implemented,
then there is no need to puslish this proposal on the standards track
any more.  So we don't have to find out how others implement this.


I can easily remember the unfortunate outcome the last time that
the TLS WG asked for anal behaviour (RSA premaster secret version check)
and how much interop problems this caused in the installed base
because one vendor decided to ship this unvalidated:

  http://www.ietf.org/mail-archive/web/tls/current/msg11226.html

This particular handshake failure flaw has is known for > 3 years,
and still has not been fixed on the platform that has by far the
largest market share...


No, I am *NOT* in favour of the IESG rubber-stamping another proposal
for TLS handshake failures, when the alternative, allowing a handshake
complete with better properties (such as suggested at the beginning
of this message) will be trivial to achieve. 




Several implementers may be in the fortunate position to ignore or
laugh at most end-users that see error messages or white pages in
their browsers.

And the firefox bug with the brittle client-side connection management
that caused fallbacks to SSLv3 all by itself over several years:
   https://bugzilla.mozilla.org/show_bug.cgi?id=450280

is a good example of this.


I'm not in such a position.  We take support seriously, and we try
to actually help customers overcome interoperability problems, even
when such interop problems are caused by third party software or
network middle-boxes.  (We don't actually fix third-party software,
but I do the analysis sufficiently thorough so that customers request
patches for clear defects from the relevant vendors).



-Martin


From nobody Mon Jan 19 12:56:50 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A00AE1B2C63 for ; Mon, 19 Jan 2015 12:56:48 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, 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 ee3NcQ7FpwyS for ; Mon, 19 Jan 2015 12:56:45 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 197F91B2C48 for ; Mon, 19 Jan 2015 12:56:45 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E29C3BEE0 for ; Mon, 19 Jan 2015 20:56:42 +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 O5KVt5S3L9VY for ; Mon, 19 Jan 2015 20:56:41 +0000 (GMT)
Received: from [10.87.48.73] (unknown [86.46.19.240]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0F652BDFC for ; Mon, 19 Jan 2015 20:56:41 +0000 (GMT)
Message-ID: <54BD6F88.3080703@cs.tcd.ie>
Date: Mon, 19 Jan 2015 20:56:40 +0000
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: "tls@ietf.org" 
References: <20150119204811.4569.95820.idtracker@ietfa.amsl.com>
In-Reply-To: <20150119204811.4569.95820.idtracker@ietfa.amsl.com>
X-Forwarded-Message-Id: <20150119204811.4569.95820.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [TLS] Fwd: Stephen Farrell's Discuss on draft-ietf-tsvwg-sctp-dtls-encaps-08: (with DISCUSS and COMMENT)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Stephen Farrell 
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Jan 2015 20:56:49 -0000

Hiya,

Please see my DISCUSS on a document below - the interesting
question relates to which version of DTLS to mandate for
WebRTC in general, as I think once this document is done,
others will just copy the relevant text.

I don't think there are any major security issues involved,
but that this is more to do with implementations. But I'd
welcome any opinions or information about any important
security differences or about whether or not current
implementations mean DTLS1.2 should be ok to mandate here
today or not.

I've set reply-to as my address and not the TLS list as
I don't think the TLS WG need to debate this much and I'm
really just checking, so please don't bother the WG list
unless there's a real point of interest for the WG. And
to repeat: I'm just checking more thoroughly than usual
on this one since this will I think set a precedent for
WebRTC.

Feedback is also needed by this Thursday 22nd to be useful.
Sorry about that but thanks in advance if you do manage to
send some:-)

Thanks,
S.



-------- Forwarded Message --------
Subject: Stephen Farrell's Discuss on
draft-ietf-tsvwg-sctp-dtls-encaps-08: (with DISCUSS and COMMENT)
Date: Mon, 19 Jan 2015 12:48:11 -0800
From: Stephen Farrell 
To: The IESG 
CC: Gorry Fairhurst 

Stephen Farrell has entered the following ballot position for
draft-ietf-tsvwg-sctp-dtls-encaps-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-dtls-encaps/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------


I'll clear once we've checked on this. Section 5 says
DTLS1.0 (from 2006) is MTI and DTLS1.2 (2012) is a
SHOULD. I could imagine that being reasonable when
DTLS1.2 was newish, say when this work was getting
started 2 years ago, but now a couple of years have
passed, it might well be just fine to require DTLS1.2 -
a lot has happened since and TLS1.2 deployment is now
far ahead of where it was in 2012, and most specs have
tended to include text like this because some
implementers only had the older TLS version. So the
DISCUSS is - is the 9 year old RFC still needed as MTI
- can we not just say to use 1.2 now?  (Note: since
this is sort-of a WebRTC spec, I think it's worth
quickly re-visiting this question now to be sure we're
taking the right approach, as the answer we pick here
is quite likely to be followed by other WebRTC docs
over the next year or so. I think this is the first
relevant WebRTC protocol spec with this bit of text
isn't it?  Apologies to the authors of this one for
landing the discuss on them:-)


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------



- Figure 1: Couldn't ICE/UDP be somewhat confusing for
someone unaware that ICE is more of an algorithm than a
wire protocol? Might be nice to clarify that here in
the intro. (If you want to be nice, if you don't that's
ok too and can be the right decision.)

- section 3: Isn't "complete SCTP packet" a teeny bit
ambiguous? It could mean including the IP and other
lower headers but I guess you do not. But that's a nit
since it's probably clear enough that you don't put an
IP or layer 2 header into the DTLS payload:-)

- Given heartbleed, and the use here of RFC6520 I think
some note of that famous implementation bug would be
wise. Just to a pointer to how to not have that
problem. But it's not a protocol bug so I'm not trying
to insist, i.e. no need for us to argue the toss on
this:-)

- I'm also wondering if the text here on 6520 is
sufficiently clear given this week's discussion of that
on the rtcweb list. (I'm not on tsvwg@ so would
appreciate an update on how the thread [1] pans out on
the tsvwg list before we approve this.)

  [1] https://www.ietf.org/mail-archive/web/rtcweb/current/msg14069.html





From nobody Mon Jan 19 12:58:34 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20ACC1B2C5A for ; Mon, 19 Jan 2015 12:58:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.321
X-Spam-Level: 
X-Spam-Status: No, score=0.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MANGLED_LOW=2.3, RCVD_IN_DNSWL_LOW=-0.7, 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 trlektEdnkk1 for ; Mon, 19 Jan 2015 12:58:29 -0800 (PST)
Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06B851ACDE7 for ; Mon, 19 Jan 2015 12:58:29 -0800 (PST)
Received: by mail-ob0-f181.google.com with SMTP id gq1so30870649obb.12 for ; Mon, 19 Jan 2015 12:58:28 -0800 (PST)
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=smN6GrFzKd7jSypLbQsII6ozcj+cRv6tu9Uoq6hPEQY=; b=gR0WTip40RmD5/8NQ86NTjYukhVTgOzzoNz2xb5pl0h5xCQOQTXZIohSjJgKrq1U7t wrv4+/ccjCNj+xE8k6nEhtrx2zlMk9MRNmrRD3FzTcssGceR7+jsYX1xCbi0ztSIKZp9 ooN3l/Am+dMJMCahV25MMnF13PpjNgIfHu0aknXO89e90ourl73q4NL8OGecrL/nPDEv NjmiHkcIyzaQirrh33CXwnjnXpiB7vSQi9mqUGAh+OPhq2khhERWgLv/LfE8TfzteTOR JwJZzu83E9zh22SGG9n+Y8Acm7lj2XTPKnHV0jaTY3pcuBIUV70yJbfbM4F5ITyVj617 mL8Q==
X-Gm-Message-State: ALoCoQnS2FsbQ0BCnsuF6mybo+akGUZR2AznaDyRcGQIVtqGQ69uh9VmbzUAVsXb77WjOuWTqXwR
MIME-Version: 1.0
X-Received: by 10.202.168.142 with SMTP id r136mr12960404oie.92.1421701108471;  Mon, 19 Jan 2015 12:58:28 -0800 (PST)
Received: by 10.76.71.228 with HTTP; Mon, 19 Jan 2015 12:58:28 -0800 (PST)
In-Reply-To: <20150119192701.190C71B0FF@ld9781.wdf.sap.corp>
References: <40128f312378442fbd26459bf5d7593b@usma1ex-dag1mb2.msg.corp.akamai.com> <20150119192701.190C71B0FF@ld9781.wdf.sap.corp>
Date: Mon, 19 Jan 2015 12:58:28 -0800
Message-ID: 
From: Brian Smith 
To: mrex@sap.com
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Jan 2015 20:58:33 -0000

Martin Rex  wrote:
> Permitting the server to continue the TLS handshake with
> ServerHello.server_version = (ClientHello.client_version +1)
>
> This would be an extremely small change, but a *HUGE* improvement to this
> proposal and make TLS handshakes _succeed_, i.e. promote interop.

This doesn't work. Consider this example of how your suggestion would work:

Client and server both support TLS 1.2.

Client attempts TLS 1.2, receives RST.
Client attempts TLS 1.1 w/ downgrade SCSV, receives RST.
Client attempts TLS 1.0 w/ downgrade SCSV, receives TLS 1.1 ServerHello.

This results in a downgrade from TLS 1.2 to TLS 1.1.

> Should a TLS client be unsatisfied with the properties of the resulting
> TLS session, that client could still decide attempting a new/different
> handshake by proposing additional features in ClientHello (that should
> have never been absent from ClientHello in the first place).

I think at this point browsers are only "satisfied" when the
connection is TLS 1.2 using an AEAD cipher suite, but they still feel
the need to support servers that only support worse crypto. So, this
part of the idea doesn't work either.

> It's not that suggestions to improvement to this proposal haven't been
> made.  It's really disappointing to see this go _through_ the TLS WG
> and not seeing any improvement whatsoever, and then going straight
> to asking for rubber-stamping it.

I don't think that the characterization of "rubber-stamping" is
accurate or helpful for moving the discussion forward.

I DO think it would be useful for the IETF to wait ~8 weeks to see the
results of Firefox's experiment in disabling the non-secure fallback,
and to see the results of studies of TLS 1.3 intolerance with
ClientHello messages with different record-level version numbers. If
it turns out to be reasonable for web browsers to stop doing the
non-secure fallback, then it really would be bad policy for IETF to
make the downgrade a proposed standard, because the downgrade SCSV
will always be limited in effectiveness by the fact that a huge number
of servers will not deploy the downgrade SCSV mechanism any time soon.
Still, it's not clear yet that web browsers can reasonably stop doing
the non-secure fallback, so I think it makes sense to have the
downgrade SCSV mechanism ready as insurance.

Cheers,
Brian


From nobody Mon Jan 19 14:42:45 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 061B21B2D06 for ; Mon, 19 Jan 2015 14:42:44 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, 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 vfpnSxNuTxE1 for ; Mon, 19 Jan 2015 14:42:41 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E8581B2D03 for ; Mon, 19 Jan 2015 14:42:41 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0EE63BEF7 for ; Mon, 19 Jan 2015 22:42:40 +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 XgJfRpbFKIhb for ; Mon, 19 Jan 2015 22:42:38 +0000 (GMT)
Received: from [10.87.48.73] (unknown [86.46.19.240]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 22A75BED9 for ; Mon, 19 Jan 2015 22:42:38 +0000 (GMT)
Message-ID: <54BD885D.7060408@cs.tcd.ie>
Date: Mon, 19 Jan 2015 22:42:37 +0000
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: "tls@ietf.org" 
References: <20150119204811.4569.95820.idtracker@ietfa.amsl.com> <54BD6F88.3080703@cs.tcd.ie>
In-Reply-To: <54BD6F88.3080703@cs.tcd.ie>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [TLS] Fwd: Stephen Farrell's Discuss on draft-ietf-tsvwg-sctp-dtls-encaps-08: (with DISCUSS and COMMENT)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Jan 2015 22:42:44 -0000

Hi again,

I'm told that the WG discussed this back in November so I've
cleared my discuss - if it was checked that recently then
that's fine. So no need to follow up on this.

Cheers,
S.

On 19/01/15 20:56, Stephen Farrell wrote:
> 
> Hiya,
> 
> Please see my DISCUSS on a document below - the interesting
> question relates to which version of DTLS to mandate for
> WebRTC in general, as I think once this document is done,
> others will just copy the relevant text.
> 
> I don't think there are any major security issues involved,
> but that this is more to do with implementations. But I'd
> welcome any opinions or information about any important
> security differences or about whether or not current
> implementations mean DTLS1.2 should be ok to mandate here
> today or not.
> 
> I've set reply-to as my address and not the TLS list as
> I don't think the TLS WG need to debate this much and I'm
> really just checking, so please don't bother the WG list
> unless there's a real point of interest for the WG. And
> to repeat: I'm just checking more thoroughly than usual
> on this one since this will I think set a precedent for
> WebRTC.
> 
> Feedback is also needed by this Thursday 22nd to be useful.
> Sorry about that but thanks in advance if you do manage to
> send some:-)
> 
> Thanks,
> S.
> 
> 
> 
> -------- Forwarded Message --------
> Subject: Stephen Farrell's Discuss on
> draft-ietf-tsvwg-sctp-dtls-encaps-08: (with DISCUSS and COMMENT)
> Date: Mon, 19 Jan 2015 12:48:11 -0800
> From: Stephen Farrell 
> To: The IESG 
> CC: Gorry Fairhurst 
> 
> Stephen Farrell has entered the following ballot position for
> draft-ietf-tsvwg-sctp-dtls-encaps-08: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> http://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-dtls-encaps/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> 
> I'll clear once we've checked on this. Section 5 says
> DTLS1.0 (from 2006) is MTI and DTLS1.2 (2012) is a
> SHOULD. I could imagine that being reasonable when
> DTLS1.2 was newish, say when this work was getting
> started 2 years ago, but now a couple of years have
> passed, it might well be just fine to require DTLS1.2 -
> a lot has happened since and TLS1.2 deployment is now
> far ahead of where it was in 2012, and most specs have
> tended to include text like this because some
> implementers only had the older TLS version. So the
> DISCUSS is - is the 9 year old RFC still needed as MTI
> - can we not just say to use 1.2 now?  (Note: since
> this is sort-of a WebRTC spec, I think it's worth
> quickly re-visiting this question now to be sure we're
> taking the right approach, as the answer we pick here
> is quite likely to be followed by other WebRTC docs
> over the next year or so. I think this is the first
> relevant WebRTC protocol spec with this bit of text
> isn't it?  Apologies to the authors of this one for
> landing the discuss on them:-)
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 
> 
> - Figure 1: Couldn't ICE/UDP be somewhat confusing for
> someone unaware that ICE is more of an algorithm than a
> wire protocol? Might be nice to clarify that here in
> the intro. (If you want to be nice, if you don't that's
> ok too and can be the right decision.)
> 
> - section 3: Isn't "complete SCTP packet" a teeny bit
> ambiguous? It could mean including the IP and other
> lower headers but I guess you do not. But that's a nit
> since it's probably clear enough that you don't put an
> IP or layer 2 header into the DTLS payload:-)
> 
> - Given heartbleed, and the use here of RFC6520 I think
> some note of that famous implementation bug would be
> wise. Just to a pointer to how to not have that
> problem. But it's not a protocol bug so I'm not trying
> to insist, i.e. no need for us to argue the toss on
> this:-)
> 
> - I'm also wondering if the text here on 6520 is
> sufficiently clear given this week's discussion of that
> on the rtcweb list. (I'm not on tsvwg@ so would
> appreciate an update on how the thread [1] pans out on
> the tsvwg list before we approve this.)
> 
>   [1] https://www.ietf.org/mail-archive/web/rtcweb/current/msg14069.html
> 
> 
> 
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 


From nobody Mon Jan 19 16:13:48 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 944141ACE77 for ; Mon, 19 Jan 2015 16:13:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 2Xq9Zb0qP9M4 for ; Mon, 19 Jan 2015 16:13:42 -0800 (PST)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id B46991ACDC6 for ; Mon, 19 Jan 2015 16:13:42 -0800 (PST)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 35E784768E; Tue, 20 Jan 2015 00:13:41 +0000 (GMT)
Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 7ECCD4768B; Tue, 20 Jan 2015 00:13:40 +0000 (GMT)
Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 714C980054; Tue, 20 Jan 2015 00:13:40 +0000 (GMT)
Received: from USMA1EX-DAG1MB2.msg.corp.akamai.com (172.27.123.102) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 19 Jan 2015 19:07:02 -0500
Received: from USMA1EX-DAG1MB2.msg.corp.akamai.com ([172.27.123.102]) by usma1ex-dag1mb2.msg.corp.akamai.com ([172.27.123.102]) with mapi id 15.00.0913.011; Mon, 19 Jan 2015 19:06:44 -0500
From: "Salz, Rich" 
To: "mrex@sap.com" 
Thread-Topic: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
Thread-Index: AdAyEhVWyLDgM1CAS6idf8kmsrjvAgAcY7MQAGmifAAAB5d7cP///oWAgAA5aNA=
Date: Tue, 20 Jan 2015 00:06:44 +0000
Message-ID: 
References: <40128f312378442fbd26459bf5d7593b@usma1ex-dag1mb2.msg.corp.akamai.com> <20150119192701.190C71B0FF@ld9781.wdf.sap.corp>
In-Reply-To: <20150119192701.190C71B0FF@ld9781.wdf.sap.corp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.19.57.202]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Jan 2015 00:13:44 -0000

> Permitting the server to continue the TLS handshake with
> ServerHello.server_version =3D (ClientHello.client_version +1)

Brian pointed out that this seems to not work.

> And this improvement is something that I could imagine implementing for
> our servers -- other than the currently specified knee-jerk-reaction.

Can we avoid this kind of language?


From nobody Mon Jan 19 16:15:59 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3DB21B2C5D for ; Mon, 19 Jan 2015 16:15:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.14
X-Spam-Level: 
X-Spam-Status: No, score=-1.14 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, 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 pL0XBhIguq8q for ; Mon, 19 Jan 2015 16:15:49 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 5BF101B2C53 for ; Mon, 19 Jan 2015 16:15:49 -0800 (PST)
Received: from netb ([89.204.155.144]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MZOan-1YRRWE3aBh-00LE5D; Tue, 20 Jan 2015 01:15:44 +0100
From: Bjoern Hoehrmann 
To: Stephen Farrell 
Date: Tue, 20 Jan 2015 01:15:42 +0100
Message-ID: <5g7rba14bmlus81ikm2pa7ucjacusoevjk@hive.bjoern.hoehrmann.de>
References: <20150119204811.4569.95820.idtracker@ietfa.amsl.com> <54BD6F88.3080703@cs.tcd.ie> <54BD885D.7060408@cs.tcd.ie>
In-Reply-To: <54BD885D.7060408@cs.tcd.ie>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:5lDd+2gLz9znXlfGVc98cU9KmROyxpuRtaefVArNkhx12/QhJ7b SPB3WDxEqsHcgVp+9gIf/nx/tPEdRoOJyOITKMHlixp/v5A940uKMaIBVJBUaBwsCG3e8zQ cxUEYMyuYSKGWE6cnDlngmZ6jNc9rqS+xd64nANBhCTX/dxnsMCHsSmWDkCU2yhZUjWZVgU syQl02in8dv5RGWYKyIAw==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Fwd: Stephen Farrell's Discuss on draft-ietf-tsvwg-sctp-dtls-encaps-08: (with DISCUSS and COMMENT)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Jan 2015 00:15:50 -0000

* Stephen Farrell wrote:
>I'm told that the WG discussed this back in November so I've
>cleared my discuss - if it was checked that recently then
>that's fine. So no need to follow up on this.

In order to keep a papertrail, it would be nice if somebody could post a
link to the discussion.

Thanks,
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de
 Available for hire in Berlin (early 2015)  · http://www.websitedev.de/ 


From nobody Mon Jan 19 16:59:21 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADA171A90D9 for ; Mon, 19 Jan 2015 16:59:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.251
X-Spam-Level: 
X-Spam-Status: No, score=-4.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MANGLED_LOW=2.3, RCVD_IN_DNSWL_HI=-5, 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 02Aj1gLkMrWJ for ; Mon, 19 Jan 2015 16:59:17 -0800 (PST)
Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D362B1B2C03 for ; Mon, 19 Jan 2015 16:59:16 -0800 (PST)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 790AD3A223; Tue, 20 Jan 2015 01:59:14 +0100 (CET)
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 471794211A; Tue, 20 Jan 2015 01:59:14 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 3D1851B0FF; Tue, 20 Jan 2015 01:59:14 +0100 (CET)
In-Reply-To: 
To: Brian Smith 
Date: Tue, 20 Jan 2015 01:59:14 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20150120005914.3D1851B0FF@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Jan 2015 00:59:19 -0000

Brian Smith wrote:
> Martin Rex  wrote:
>> Permitting the server to continue the TLS handshake with
>> ServerHello.server_version = (ClientHello.client_version +1)
>>
>> This would be an extremely small change, but a *HUGE* improvement to this
>> proposal and make TLS handshakes _succeed_, i.e. promote interop.
> 
> This doesn't work. Consider this example of how your suggestion would work:
> 
> Client and server both support TLS 1.2.
> 
> Client attempts TLS 1.2, receives RST.
> Client attempts TLS 1.1 w/ downgrade SCSV, receives RST.
> Client attempts TLS 1.0 w/ downgrade SCSV, receives TLS 1.1 ServerHello.
> 
> This results in a downgrade from TLS 1.2 to TLS 1.1.


The improvement works *PERFECTLY* in your above example.

 - the server continues the handshake successfully
 - the client can clearly see from the server's response that the
   server recognized the FALLBACK_SCSV

It is then properly up to the client who asserted FALLBACK_SCSV
to consciously decide whether aborting the current handshake could
*really* provide a benefit, maybe even keeping the established session
around.

In case the server, or client, or both, support only RC4 stream cipher 
and CBC cipher suites, the resulting TLS session with TLSv1.1
(the version that succeeds in your example) is comparable in strength
to one that would have succeeded with TLSv1.2.


The improvement is already better by a significant margin that the current
proposal if it makes *additional* TLS handshakes complete rather than fail
compared to the current proposal.  In your above example,


Now the part that you didn't say here:  if the cause of the RSTs wasn't
an attacker, but a dense middle-box, then the result would be a complete
interop failure -- and the only workaround (rather than the user removing
the "s" from the https://some.host/ URL), would be for the client to
not send the FALLBACK_SCSV -- in which case the entire protection scheme
would fail.




> 
> > Should a TLS client be unsatisfied with the properties of the resulting
> > TLS session, that client could still decide attempting a new/different
> > handshake by proposing additional features in ClientHello (that should
> > have never been absent from ClientHello in the first place).
> 
> I think at this point browsers are only "satisfied" when the
> connection is TLS 1.2 using an AEAD cipher suite, but they still feel
> the need to support servers that only support worse crypto. So, this
> part of the idea doesn't work either.


Many servers do not even support AEAD cipher suites, including lots of
servers that support TLSv1.2.  And hundreds of millions of clients do
not support AEAD cipher suites either (think mobile).

Keep in mind that TLSv1.2 (rfc5246) contains not a single AEAD cipher
suite in the base specification, and the mandatory-to-implement cipher
suite in TLSv1.2 is TLS_RSA_WITH_AES_128_CBC_SHA.
Until _VERY_ recently (in a botched initial Hotfix delivery), Microsoft
did not support any AEAD cipher suites with RSA server certificates
on Windows 7 & 2008R2.

Random pick of a production Akamai server (TLSv1.2, but no AEAD):
https://www.ssllabs.com/ssltest/analyze.html?d=www.microsoft.com&s=23.203.223.109


-Martin


From nobody Mon Jan 19 21:15:06 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 107161AD079 for ; Mon, 19 Jan 2015 21:15:01 -0800 (PST)
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 Rxqd36epW05K for ; Mon, 19 Jan 2015 21:14:58 -0800 (PST)
Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003: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 9C0FF1A909C for ; Mon, 19 Jan 2015 21:14:58 -0800 (PST)
Received: by mail-ob0-f182.google.com with SMTP id wo20so32294255obc.13 for ; Mon, 19 Jan 2015 21:14:58 -0800 (PST)
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=5JFfflHUc4RgXCsiVkOHdUumqoSKMtMLIYtwLK6924M=; b=W4wYkrc62Z2/HEFHJ3O7AaM1RzIqPcHmxd3jknTSXeCAP29BVQoZBulD6INXXtNNP+ 5E5sASiC4JboK4DelbRf8FiBPFQo5TwyfdpFoRvqCt+AApkn9YwRCJeswgprxBrdSyxX ExlsS7GJwERjEw+K6cH0lVF78XsZynRwrzsYKD6PwfnLq7gHRGVHsrN3/xMO85mx/iAG RlIYCDCx6PvJrj+F/JPhcFUfOs7lZ9d4VSCtUx7+W5h3dTrQmHbK5MhTPnv8CofR4ae+ 6pQ/9ydk9FpDbvejo2jpZfwLh1O3oYenKJx1H0Q1iv4wX2lbby5IqdI+t9qAPNCsmuFn vWRA==
MIME-Version: 1.0
X-Received: by 10.182.29.68 with SMTP id i4mr18555620obh.30.1421730897979; Mon, 19 Jan 2015 21:14:57 -0800 (PST)
Received: by 10.202.226.136 with HTTP; Mon, 19 Jan 2015 21:14:57 -0800 (PST)
In-Reply-To: <5g7rba14bmlus81ikm2pa7ucjacusoevjk@hive.bjoern.hoehrmann.de>
References: <20150119204811.4569.95820.idtracker@ietfa.amsl.com> <54BD6F88.3080703@cs.tcd.ie> <54BD885D.7060408@cs.tcd.ie> <5g7rba14bmlus81ikm2pa7ucjacusoevjk@hive.bjoern.hoehrmann.de>
Date: Mon, 19 Jan 2015 21:14:57 -0800
Message-ID: 
From: Martin Thomson 
To: Bjoern Hoehrmann 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Fwd: Stephen Farrell's Discuss on draft-ietf-tsvwg-sctp-dtls-encaps-08: (with DISCUSS and COMMENT)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Jan 2015 05:15:01 -0000

On 19 January 2015 at 16:15, Bjoern Hoehrmann  wrote:
> * Stephen Farrell wrote:
>>I'm told that the WG discussed this back in November so I've
>>cleared my discuss - if it was checked that recently then
>>that's fine. So no need to follow up on this.
>
> In order to keep a papertrail, it would be nice if somebody could post a
> link to the discussion.

https://tools.ietf.org/wg/rtcweb/minutes?item=minutes-91-rtcweb.html

Search for "DTLS 1.0"


From nobody Tue Jan 20 09:10:17 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5511B2ACC for ; Tue, 20 Jan 2015 09:10:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.511
X-Spam-Level: 
X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GUARANTEED_100_PERCENT=2.699, RCVD_IN_DNSWL_MED=-2.3, 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 pyaHqUt795Cm for ; Tue, 20 Jan 2015 09:10:10 -0800 (PST)
Received: from maple.randombit.net (maple.randombit.net [66.228.45.112]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AAD91ACE2F for ; Tue, 20 Jan 2015 09:09:56 -0800 (PST)
Received: by maple.randombit.net (Postfix, from userid 1000) id 4E11CA08FC; Tue, 20 Jan 2015 12:09:54 -0500 (EST)
Date: Tue, 20 Jan 2015 12:09:54 -0500
From: Jack Lloyd 
To: tls@ietf.org
Message-ID: <20150120170954.GA9731@randombit.net>
Mail-Followup-To: tls@ietf.org
References: <54B5501A.4070402@azet.org>  <54B58F5B.2010704@cs.tcd.ie> <54B6815A.7060102@azet.org>  <54B9352C.70203@azet.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <54B9352C.70203@azet.org>
X-PGP-Fingerprint: 3F69 2E64 6D92 3BBE E7AE 9258 5C0F 96E8 4EC1 6D6B
X-PGP-Key: http://www.randombit.net/pgpkey.html
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Jan 2015 17:10:11 -0000

On Fri, Jan 16, 2015 at 04:58:36PM +0100, Aaron Zauner wrote:
> Hi,
> 
> I came up with the following list of cipher-suites applicable to >= TLS 1.2:
> 
> (EC)DHE:
> TLS_DHE_RSA_WITH_AES_128_OCB	
> TLS_DHE_RSA_WITH_AES_256_OCB
> TLS_ECDHE_RSA_WITH_AES_128_OCB
> TLS_ECDHE_RSA_WITH_AES_256_OCB
> TLS_ECDHE_ECDSA_WITH_AES_128_OCB
> TLS_ECDHE_ECDSA_WITH_AES_256_OCB
> 
> PSK:
> TLS_DHE_PSK_WITH_AES_128_OCB
> TLS_DHE_PSK_WITH_AES_256_OCB	
> TLS_ECDHE_PSK_WITH_AES_128_OCB
> TLS_ECDHE_PSK_WITH_AES_256_OCB
> 
> As for the nonce, would it make sense to use a 128bit nonce for both
> AES128 and AES256 instead of 64/128 (see:
> https://www.imperialviolet.org/2014/05/25/strengthmatching.html)?

OCB mode as defined in RFC 7253 supports nonces of at most 120 bits.

When used in TLS both GCM and CCM use 96 bit nonces, 32 from key
exchange and 64 explicit in the message. Given the 2^64 message limit
(and that any sensible implementation just uses the sequence number
for the 64 nonce bits included in each message) I don't see why OCB
should require anything different. A 128 bit nonce isn't increasing
the security level when it is already 100% guaranteed that the nonce
will never repeat using just 96.

Another option would be to avoid explicit nonces entirely and
following ChaCha20 define the nonce to always be exactly the sequence
number in network order. This value is known to be unique for protocol
reasons, and it avoids the wire bytes taken for any explicit value.

Cheers,
  Jack


From nobody Tue Jan 20 10:03:01 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68B451B2B04 for ; Tue, 20 Jan 2015 10:02:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.099
X-Spam-Level: 
X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GUARANTEED_100_PERCENT=2.699, RCVD_IN_DNSWL_LOW=-0.7] 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 cbGj9jsJdSLE for ; Tue, 20 Jan 2015 10:02:58 -0800 (PST)
Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4192E1B2B05 for ; Tue, 20 Jan 2015 10:02:58 -0800 (PST)
Received: by mail-wi0-f179.google.com with SMTP id l15so16907810wiw.0 for ; Tue, 20 Jan 2015 10:02:57 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=t7RwwpXlgbsaPNaG1fU2pGbg10jJ4/lG5K9Ewa6A+4I=; b=DEO+EsLV5BcGuPntU8i9YYh16qeSS3EymhyjaRU1I4cJi9ihqn56oeQD53D+F66Rdy qqDBxk+MxbXbMMQ/aZ3/ldx4s9OqbsUcEt9EXWcIOUD6VjMm2Hhed5FnLb829AMysffW lVsKhVp+h3z2NP9RPJkWu5lWXwzojRYf81wB7y72KXByiqhxA//fgrsNqk3x+7KkN6J1 H3Iy+LPlZrxX1A+B5BwFC5Zlj9vq65i7GeTi7iryCc9OdHq4L3EaFWZLm/Q9i/tUPVdE N0ZNnhIWsCvwmv6sbP/DLE/dQHkv+c982w2iq0eE1zVWfLLTiYLz8rKhWuUiYY3J7rba I44A==
X-Gm-Message-State: ALoCoQn2Y6okJjCXdEsEHtDUi/OiN40WSaWOdlwy3iIWxpjF/uP4LCedvn1pZ2UGG6IHFl6bek6R
X-Received: by 10.194.24.103 with SMTP id t7mr47889151wjf.15.1421776977058; Tue, 20 Jan 2015 10:02:57 -0800 (PST)
Received: from [10.0.0.142] (chello080108032135.14.11.univie.teleweb.at. [80.108.32.135]) by mx.google.com with ESMTPSA id hn2sm22221754wjc.5.2015.01.20.10.02.55 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 20 Jan 2015 10:02:55 -0800 (PST)
Message-ID: <54BE984B.5080002@azet.org>
Date: Tue, 20 Jan 2015 19:02:51 +0100
From: Aaron Zauner 
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: tls@ietf.org
References: <54B5501A.4070402@azet.org>  <54B58F5B.2010704@cs.tcd.ie> <54B6815A.7060102@azet.org>  <54B9352C.70203@azet.org> <20150120170954.GA9731@randombit.net>
In-Reply-To: <20150120170954.GA9731@randombit.net>
X-Enigmail-Version: 1.2.3
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig17C7CE59BB5B0F3AF963BF26"
Archived-At: 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Jan 2015 18:02:59 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig17C7CE59BB5B0F3AF963BF26
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



Jack Lloyd wrote:
>=20
> OCB mode as defined in RFC 7253 supports nonces of at most 120 bits.
>=20
> When used in TLS both GCM and CCM use 96 bit nonces, 32 from key
> exchange and 64 explicit in the message. Given the 2^64 message limit
> (and that any sensible implementation just uses the sequence number
> for the 64 nonce bits included in each message) I don't see why OCB
> should require anything different. A 128 bit nonce isn't increasing
> the security level when it is already 100% guaranteed that the nonce
> will never repeat using just 96.
>=20
> Another option would be to avoid explicit nonces entirely and
> following ChaCha20 define the nonce to always be exactly the sequence
> number in network order. This value is known to be unique for protocol
> reasons, and it avoids the wire bytes taken for any explicit value.
>=20
Yes, thanks! I figured that out on my own a couple of days ago.
Unfortunately the ID I submitted still has the TAGLEN128 constructs in
it (I forgot to edit this part). So there's probably going to be a -01.
Let's see if my submission gets accepted.

Thanks for your feedback,
Aaron


--------------enig17C7CE59BB5B0F3AF963BF26
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUvphMAAoJEOTbZJL9ubXV9iYP/iX2Bz34C3IVNQqsBxHzKceR
zZbJjlkj92d4CVNxaB/hL4s21RXKGJOM55h0aKw1G5HwJKuWWHvQ1zEXMz/80Luu
M5+GhfG9L/nQxEj5r6TfFQ2WCOgFiGIWSAPP8UVe/hj0DZrUg3itfbj5IISQKIta
XbMfswK9DjWUYxJBPUTmApEXgr6/brLuq+0g7C/fw++Vg/IaTaecorDu7fCT8C4H
6MRc7U2LgQ3WOURDJYCesWYxc18/GZGfaWY6CDOsyNc47y/lG+vDFDj+h3j0zc7V
ZWRmGc0JgJd9MsVh6eO+NS5Y7UrD82pNz1vNw6uum5Ex9nx66907sWowzn5rHn3f
/YCCBEwCHllGA+VFS7FiBu4Cwx/E1e5FhRjP1t6aZCpok1JRARSAj7GHnQX4WSOy
tnPEQYcsbvb55poBhNM6zxFO5bwQEy8aI1huOGXEdyW2pk85o/jnawrj52xSzaZq
T7c/3ErqgxYWGFgAu1x/Uvva5q1v5bPvkjXCxnSAyhbyDMuUo+5JZcFySSnPy1VP
bAkdW3gJ9kCGV23+Km1vdZzK4r3jZZ1mmmBGKIIU7MzNhIK/ShO9Qlyki8VOeJUS
Q7pZFX75r/ksOD/HMaRmKU2cSFG6yYRv/mLPz/amukhuyIlhZxWNGGzfvrtGbDH0
cvdRpIAgOnEy8aUE2F7h
=8lLP
-----END PGP SIGNATURE-----

--------------enig17C7CE59BB5B0F3AF963BF26--


From nobody Tue Jan 20 11:18:19 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4AC01B2ADC for ; Tue, 20 Jan 2015 11:18:15 -0800 (PST)
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,  J_CHICKENPOX_52=0.6, 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 eOFh9O3-zAQC for ; Tue, 20 Jan 2015 11:18:14 -0800 (PST)
Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C9D91ACDB2 for ; Tue, 20 Jan 2015 11:18:14 -0800 (PST)
Received: by mail-wi0-f174.google.com with SMTP id n3so6818030wiv.1 for ; Tue, 20 Jan 2015 11:18:12 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=mOlRhzVSdEa35QgfNO57CrOmQ4qWd1ELBc7sMwKvcOo=; b=l+aXHEJFy7dtG1fT1CMN5LVXJuOwuIdAJZjJnX60EGWUQu8/jmVdCrdJo5Eh2yUXaV 2508Ow/3HK/+fa4fqmB44ORexTqNUAvPKkQzJsDCLz6tRY4819sf7eoPRY8IIwMyry/Q Rs5ZT2ft2tXEd+v8mZ9JOz6Y8keZgp4IUIrRD2Q2kEFw0CnxOuxH9msCoBujIRIGvB24 dIgdTTYrxCpWraQWVdw/zgtC5llFHYuFzD4uHWBKMJix2XO+gyLe6FfS1L22yITojb8i CcqPjjpZdGkBQrSO+ZF0610mQgUBA1HNSupguG4PhrBin046w6FsdJv7d4mk7z9m54Y2 4jNA==
X-Gm-Message-State: ALoCoQmzCbFQWtTshQMUV/rOMWm80tF/azNF/XWQ1UBLa6UcDqhBoTu6VdcY5hhb8E2y4PbFPngG
X-Received: by 10.180.20.177 with SMTP id o17mr35841535wie.20.1421781490668; Tue, 20 Jan 2015 11:18:10 -0800 (PST)
Received: from typhoon.azet.org (chello080108032135.14.11.univie.teleweb.at. [80.108.32.135]) by mx.google.com with ESMTPSA id hn2sm22470737wjc.5.2015.01.20.11.18.08 for  (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Jan 2015 11:18:09 -0800 (PST)
Date: Tue, 20 Jan 2015 20:18:21 +0100
From: Aaron Zauner 
To: TLS Mailing List 
Message-ID: <20150120191819.GA8165@typhoon.azet.org>
References: <54B5501A.4070402@azet.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="VS++wcV0S1rZb1Fb"
Content-Disposition: inline
In-Reply-To: <54B5501A.4070402@azet.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Jan 2015 19:18:16 -0000

--VS++wcV0S1rZb1Fb
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline

Hi TLS-WG,

The Internet Draft can be found over here:
https://datatracker.ietf.org/doc/draft-zauner-tls-aes-ocb/

Further discussion very welcome.

One of the things I have in mind, right now there're two PSK
ciphersuites defined (that I defined because they're in CCM and GCM
as well) that do not make much sense in my opinion. These are PSK
with DHE. For embedded devices the use of ECDHE is for sure more
suitable. So removing those would be an option. Right now this ID
would add twelve (12) new ciphersuites to the TLS ciphersuite
registry, if we /can/ get rid of these two we're down to ten (10).

As always; any input appreciated,
Aaron

--VS++wcV0S1rZb1Fb
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUvqn7AAoJEOTbZJL9ubXV95gQAMdqQbVWEvOhL1iZ4d0fFIqL
72CYSXxUx+Ff8n/l60VUSrICN4RtEuL2+lEOgsqlcz7oOenbVbJQli6PLhmSF8EE
U/JS7J0ueEy8iWoCdrnkx7zuBtpmMFZaLQIbpyh4aTONNxskaH+7Nf1KzdHYBWSz
fLg556CETrHi4850u+td6hO+WxgSzY1cHdMVqEgE2MoEVw4CjDjwaNjDNBLLAzz7
FxmTdptY8ME0m5q4BhyDlOsssZzgBln1oaQOmUeV2NAbVAQx4sLZA1sJqiUGDdjf
y7SL3CuK+XQ1cKha0mE66WhkjEO35CM/q5TwUa8q6KzQ26joIOVRouV15ZTYFblV
ucjbn3DYhetx1+MkkleG/58FcWLOicmCMUCQEHPylKMkNWk/DQ/V0eMKSv1NeRVS
qgt71db3WT/Y9DbVQRlfxV8+hjQMdOFdC53WpZ/+7yEuXfptuggEkUZxOoOy9oXB
YIKFVnM3nM2pSzqQhBFZB4uY2jLL6tYyK0Xle/IREy+d/QYYD3b+iqsUJubxzWH1
hg/N5sXVHbdSCwxlL8cAZfhXyQ0U2GMN8XCIHkYlZVyfXQWvZLEzAY62b8su/beq
bydfPD2nk1qIGMK6GooUsMOTs1hgtVMfS7llmMygfvVf0CFP7Vyjs7NQizn2TurD
esPjCKE29IowCiUVUtWB
=jeOe
-----END PGP SIGNATURE-----

--VS++wcV0S1rZb1Fb--


From nobody Tue Jan 20 11:34:07 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 868761ACDB2 for ; Tue, 20 Jan 2015 11:34:05 -0800 (PST)
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 MIi0taICyJyB for ; Tue, 20 Jan 2015 11:34:04 -0800 (PST)
Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE5681B2B23 for ; Tue, 20 Jan 2015 11:34:03 -0800 (PST)
Received: by mail-we0-f177.google.com with SMTP id l61so18369965wev.8 for ; Tue, 20 Jan 2015 11:34:02 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=aI75ujcFZ46/ZZ6eE7QLbCQo95qeRuzgU4EJdWPGf8E=; b=QX59KvKD0WIa3yMo6G7aRgt87x3tQiI2DNWIeA/p086TOxufNiMo8bp+wI6cvzbPPH xVNm1n3ACv4uzbZK6WMqbcFDbCmd03s9Ovk/3cITnHcqSPUfckjNHKtNq1+td8oYvzDI IOQb9NKIJSgAkhbexKj3p0UiVlOGK3cqj21zlgDW2KnR+tvsYZyn2SOLcTJj7L4eopPu ldsf1BNNfI2e1dPntqBYQ/o58umlPsNEFrWvAdDAejTHToejR8SKwKTxdOpHs0wih7aa BKP+Q7DcKNmYJyx3yFPxy4Kr9Xf9dceFxSBKPHI9hfG+CPzBTS6rEq/Wr0KMqFu3VLVL XYfg==
X-Gm-Message-State: ALoCoQmDcTuULz0APruGGc2MJbklT7qbhOS37B7mHtWz/tsgqAKm+dCS1U8jyHyMxXPYJ2cnHDyW
X-Received: by 10.180.9.115 with SMTP id y19mr22666236wia.32.1421782442493; Tue, 20 Jan 2015 11:34:02 -0800 (PST)
Received: from typhoon.azet.org (chello080108032135.14.11.univie.teleweb.at. [80.108.32.135]) by mx.google.com with ESMTPSA id s9sm4265696wiz.12.2015.01.20.11.34.00 for  (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Jan 2015 11:34:01 -0800 (PST)
Date: Tue, 20 Jan 2015 20:34:13 +0100
From: Aaron Zauner 
To: TLS Mailing List 
Message-ID: <20150120193412.GA10140@typhoon.azet.org>
References: <54B5501A.4070402@azet.org> <20150120191819.GA8165@typhoon.azet.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ZGiS0Q5IWpPtfppv"
Content-Disposition: inline
In-Reply-To: <20150120191819.GA8165@typhoon.azet.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Jan 2015 19:34:05 -0000

--ZGiS0Q5IWpPtfppv
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* Aaron Zauner  [20/01/2015 20:18:09] wrote:
> Hi TLS-WG,
>=20
> The Internet Draft can be found over here:
> https://datatracker.ietf.org/doc/draft-zauner-tls-aes-ocb/

PS: In TLS-WG fashion I've put the draft on GitHub and Travis-CI for
issues and Pull Requests (thanks to Martin Thompson for his great
template!). In accordance to IETF contribution guidelines all comments=20
must also be made to this very mailing list.

https://github.com/azet/draft-zauner-tls-aes-ocb

Aaron

--ZGiS0Q5IWpPtfppv
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUvq2zAAoJEOTbZJL9ubXVKEUP/iURNyzx7YLH72fN1QwyPvfJ
P/yo3HQI1PLqj6xZGpyY9JuRtrF8ZGpcl9bWDP2OHPddqyOFGgVqO4XEgNZVsi9w
pMAsnYux+ZWGJmjP9zAaC+PjQcP10KtPtDAwqwNzOQa92S0DXfXNHpiyPRujIx4a
ZNPU2NUe2To+eCJG5snDLUTlsRwJSFaqQ7rjekDCA9hqmt4dQkCPrvAoWPKkha0G
zUIQ4q99HeZp0jWfZL1HbIoKkdg55+6U6O4jiE/gjjKToOO0VYD6mRsbh3qKZM4l
1VUE3Onar7umN6DDY09amLkXRoXWUiVf68CuqYKDJNzSbKq6Fz6ZHsgvAnfLpZJC
njb66UWsRubQI0c41jtoNHuShtzJTLAFF4Va7PKEeFsGJQPNJEyq8bdsJ3gP8R1B
RiTyRjIBiDcWBumcWD26OerajDTkd64LDhO7sCC/7HyNyEAnG8Bpo9Mhw/ZOfEFI
eg0uViJ5wuHnc4G0YlTIrSuCl0jUpjTj4h6ePFU/pFLN0TfDFgMdqpLlWfa1AJ4r
oZbwhx53OtgT9Q1S/hBPLbWZPJT+Ld06hBFUJ2c+S+ycszz5OnObLgg7xSaGv9lp
rYsqq733eHYGrgA6dDk1yFP2HeS9NEz/M0GtktjAWb58ocyeow/E6q1fIqcLdAvL
NlP3D0mgpKfvH4neDk5S
=4Ecj
-----END PGP SIGNATURE-----

--ZGiS0Q5IWpPtfppv--


From nobody Tue Jan 20 14:17:31 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A02C41A003B for ; Tue, 20 Jan 2015 14:17:28 -0800 (PST)
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 zqkjfdBcBkUR for ; Tue, 20 Jan 2015 14:17:27 -0800 (PST)
Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7BA81A0006 for ; Tue, 20 Jan 2015 14:17:26 -0800 (PST)
Received: by mail-oi0-f53.google.com with SMTP id i138so3945222oig.12 for ; Tue, 20 Jan 2015 14:17:26 -0800 (PST)
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=rbL7Y1a8uXeI2edMaI6xRrp+mFLfEbx2TC3cpHj2kzc=; b=v+wLKhgKPuqLhEKv3gZfngmiMtRsH6H9sFMt+rDQ3HT4eSxh/JVEHOJBkFTqviByjR pF1hhhPF8UtHD2sfH+U/4FZkLgj7hjtWsaY9yjyv63UNqtt7jmbv9sLSfytqSdC4zqm9 UqnMCcn36k2dW3JJt7nwVrSe59fbQ6aOXKIxvKc0YcIdfia19VWXW4xYdjMZ804gRpUu YoQVDl/stOSZkijtMawz65QtMmxIKp1Oyht8FcHXKtjxjXlyy/7jdXNqCx3/vk5gKOs1 4CMwb3+DunlIPa5fpNBTu1tVIS0+Dzrp0y9ji6Vt4siCAogOf+dQJwAn7MLX6YigkOWx O4JQ==
MIME-Version: 1.0
X-Received: by 10.182.125.72 with SMTP id mo8mr23219650obb.61.1421792246014; Tue, 20 Jan 2015 14:17:26 -0800 (PST)
Received: by 10.202.226.136 with HTTP; Tue, 20 Jan 2015 14:17:25 -0800 (PST)
In-Reply-To: <20150120193412.GA10140@typhoon.azet.org>
References: <54B5501A.4070402@azet.org> <20150120191819.GA8165@typhoon.azet.org> <20150120193412.GA10140@typhoon.azet.org>
Date: Tue, 20 Jan 2015 14:17:25 -0800
Message-ID: 
From: Martin Thomson 
To: Aaron Zauner 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: TLS Mailing List 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Jan 2015 22:17:29 -0000

On 20 January 2015 at 11:34, Aaron Zauner  wrote:
> https://github.com/azet/draft-zauner-tls-aes-ocb

LGTM, providing you get interest in shipping it.

Is the following premise entirely correct?

Because
   TLS has no way for the client to indicate that it supports TLS 1.2
   but not earlier, a non-compliant server might potentially negotiate
   TLS 1.1 or earlier and select one of the cipher suites in this
   document.

Maybe instead:

A client MUST treat the selection of these cipher suites in
combination with a version of TLS that does not support AEAD (i.e.,
TLS 1.1 or earlier) as an error and generate a fatal
'illegal_parameter' alert.


From nobody Tue Jan 20 14:46:11 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37BD51A0064 for ; Tue, 20 Jan 2015 14:46:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Level: 
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 Bq4DdY1E3owt for ; Tue, 20 Jan 2015 14:46:05 -0800 (PST)
Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 611F51A005C for ; Tue, 20 Jan 2015 14:46:05 -0800 (PST)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 5242C3A27C; Tue, 20 Jan 2015 23:46:03 +0100 (CET)
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 2EB23425F6; Tue, 20 Jan 2015 23:46:03 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 2531B1B105; Tue, 20 Jan 2015 23:46:03 +0100 (CET)
In-Reply-To: 
To: "Salz, Rich" 
Date: Tue, 20 Jan 2015 23:46:03 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20150120224603.2531B1B105@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Jan 2015 22:46:09 -0000

Salz, Rich wrote:
> 
>> Permitting the server to continue the TLS handshake with
>> ServerHello.server_version = (ClientHello.client_version +1)
> 
> Brian pointed out that this seems to not work.

Technically, my proposed and extremely simple improvement works *PERFECTLY*
in his example.  But Brian and I might be talking past each other.


I'm not saying that the early adopters of the downgrade-scsv proposal
must change.  But I also do not want to see a knee-jerk reaction, that
can easily lead to a complete interop failure rubber-stamped for
standards track, when it could be easily improved by allowing servers
an alternative response that bears a significantly lower risk of
causing harm in the form of complete interop failure, when shipped
as server patch into an installed base of unknown usage scenarios.



The semantics of the FALLBACK_SCSV (i.e. the presence of the cipher suite
in ClientHello) specified in the current proposal could be described as

"Client signals to Server that it supports a TLS protocol version
 that is higher than what is currently conveyed in ClientHello.client_version".

The semantics of the fatal inappropriate_fallback(86) alert from the
server of the current proposal could be described as

"Server signals to Client that it also supports a TLS protocol version
 that is higher than what the server received in ClientHello.client_version".


Improving the current downgrade-scsv proposal, by giving the server the
choice to alternatively continue the TLS handshake successfully, using
ServerHello.server_version = (ClientHello.client_version+1) will convey
back to the client the same information as the "inappropriate_fallback(86)"
fatal alert--but give the client significantly *MORE* options to
perform a successful TLS handshake with that server.

The server's willigness to continue the handshake, selected from among
the TLS protocol options actually offered in ClientHello, is *NOT* an
obligation for the client to continue that handshake and to send
application data over the resulting session.  If the TLS client believes
that it could do better, it may take chances and retry a new connection
immediately.  But with the alternative of a successful continuation of
the handshake, interop is still a viable option to the client, and not
all conceivable protocol downgrades will actually impair the security.


Clients, in particular Web Browsers, are notorious about breaking
connections frequently and during all connection states (after connect
after TLS handshake start or during data transfer).  This may be users
doing navigation on partially loaded pages that contain myriads of embedded
seperate objects, or this may be active scripting composing colorful
UIs from myriads of small UI elements.

Servers, on the other hand, are normally patient and well-behaved, but
may appear unresponsive under high load or flaky network connectivity.

 
I firmly believe that most of the causes for TLS protocol downgrades
will continue to be non-malicious rather than active attacks.  And
in many cases, the proposed improvement of the server successfully
continuing with ServerHello.server_version=(ClientHello.client_version + 1)
will provide a comparable level of security to what would happen had
the client had proposed a higher protocol version in ClientHello.
So this improvement can also save network round-trips on non-malicious
downgrades.


Looking at the downgrade dance of Firefox 34, it does

  1.  record={3,1}   client_version={3,3}  + extensions
  2.  record={3,1}   client_version={3,2}  + extensions
  3.  record={3,1}   client_version={3,1}  + extensions
  

So Firefox seems to have abandoned not only SSLv3, but also
extension-less ClientHellos.

It seems that the only "problem" that is left here, is an unfortunate
requirement in AEAD cipher suite RFCs (such as AES-GCM, rfc5288):

https://tools.ietf.org/html/rfc5288#section-4

   4.  TLS Versions

   These cipher suites make use of the authenticated encryption with
   additional data defined in TLS 1.2 [RFC5246].  They MUST NOT be
   negotiated in older versions of TLS.
*                                         Clients MUST NOT offer these
*   cipher suites if they do not offer TLS 1.2 or later.
                                                         Servers that
   select an earlier version of TLS MUST NOT select one of these cipher
   suites.  Because TLS has no way for the client to indicate that it
   supports TLS 1.2 but not earlier, a non-compliant server might
   potentially negotiate TLS 1.1 or earlier and select one of the cipher
   suites in this document.  Clients MUST check the TLS version and
   generate a fatal "illegal_parameter" alert if they detect an
   incorrect version.


Considering that TLS version intolerance had been well-known when the
AEAD cipher suite documents where published, the above (*) requirement
should have better been something like the following from the beginning:

   When a Client offers any of these cipher suites, it implies that
   the client supports and is willing to use protocol version TLS 1.2
   or later.  This implication will take precedence over any protocol
   version in ClientHello.client_version that is lower than TLS 1.2,
   and might have been used by the client purely for better interoperability
   with old or defective TLS servers that are intolerant to newer TLS
   protocol versions in ClientHello.client_version.


Then browsers would not have had to worry as much about their downgrade
dance, there would be a strong argument for programmatic clients (those
that do not contain any app-level downgrade dance heuristics)
to adopt TLSv1.2 + AEAD cipher suites.


How about assigning a small number (<=4) of alternative TLS cipher suite IDs
to existing AEAD TLS cipher suites than will carry the above implication?

Candidate cipher suites for assignment of an alias cipher suite ID:

     CipherSuite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256    = {0xC0,0x27};
     CipherSuite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384    = {0xC0,0x28};


-Martin


From nobody Tue Jan 20 14:53:31 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6DC1A0067 for ; Tue, 20 Jan 2015 14:53:29 -0800 (PST)
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 eWDF4KUuAdAs for ; Tue, 20 Jan 2015 14:53:28 -0800 (PST)
Received: from mail-we0-f174.google.com (mail-we0-f174.google.com [74.125.82.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA7811A006B for ; Tue, 20 Jan 2015 14:53:27 -0800 (PST)
Received: by mail-we0-f174.google.com with SMTP id x3so7354921wes.5 for ; Tue, 20 Jan 2015 14:53:26 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=SpkYYUXIAN7aLO6Xjsv7pSosCvQPc3T924Bf6jV9USA=; b=DWVlSaoU6GtGv+Hgqnyc/X+XnN0nZnaxPtQmhwh6s6QkXdNkbyD51XCxeXNGbMjdhE SL046VdQrlpru/vaujxYE8z20k7MXkTiXWvWgmV3btS5FbbsXHnwKhl0lo/fM38hurkN 7ls1dC2e4C5fVsK3MbyeR8ElA8qL6kTcpCr9jl/LZIVFehA8yXHCXVKz5kbfnS//dFCl uz5x/sSK0HYwboR3OpJpv+QuEebaeyODJaWCjympZjdHVc+cE8CMp0vHSDy3FVxAl5Dz fvb1VSwBZmDge+8z/Lf1D4cipwv65ghrRclhBjAPg/BJC554y2alLakLbBLbe74l0TC1 tGrg==
X-Gm-Message-State: ALoCoQmN1TLLT5XqRMDkIEv+5dGqMRBdN/iyFtWIfeW8rH+a7IRWr0bqghOTVEvaqwxRkoOBos+1
X-Received: by 10.181.12.17 with SMTP id em17mr51115652wid.45.1421794406570; Tue, 20 Jan 2015 14:53:26 -0800 (PST)
Received: from typhoon.azet.org (chello080108032135.14.11.univie.teleweb.at. [80.108.32.135]) by mx.google.com with ESMTPSA id fm10sm4830084wib.7.2015.01.20.14.53.24 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Jan 2015 14:53:25 -0800 (PST)
Date: Tue, 20 Jan 2015 23:53:37 +0100
From: Aaron Zauner 
To: Martin Thomson 
Message-ID: <20150120225335.GA871@typhoon.azet.org>
References: <54B5501A.4070402@azet.org> <20150120191819.GA8165@typhoon.azet.org> <20150120193412.GA10140@typhoon.azet.org> 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="mYCpIKhGyMATD0i+"
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Cc: TLS Mailing List 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Jan 2015 22:53:29 -0000

--mYCpIKhGyMATD0i+
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* Martin Thomson  [20/01/2015 23:17:26] wrote:
> On 20 January 2015 at 11:34, Aaron Zauner  wrote:
> > https://github.com/azet/draft-zauner-tls-aes-ocb
>=20
> LGTM, providing you get interest in shipping it.
>=20
> Is the following premise entirely correct?
>=20
> Because
>    TLS has no way for the client to indicate that it supports TLS 1.2
>    but not earlier, a non-compliant server might potentially negotiate
>    TLS 1.1 or earlier and select one of the cipher suites in this
>    document.
>=20
> Maybe instead:
>=20
> A client MUST treat the selection of these cipher suites in
> combination with a version of TLS that does not support AEAD (i.e.,
> TLS 1.1 or earlier) as an error and generate a fatal
> 'illegal_parameter' alert.

Makes sense. The quoted text was copied verbatim by myself from
the GCM/CCM RFCs. I'm happy to include your suggestion as a
replacement. Maybe change the last sentence to:
"..and generate a fatal 'illegal_parameter' TLS alert response"?

Aaron

--mYCpIKhGyMATD0i+
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUvtxvAAoJEOTbZJL9ubXVvrQP/3LvOcwt8f0YvfRDrbyT1bHz
8Xl8MzEU8SSYr6xSBPHCO4f7SnuC/Ba2pyizG8osHoIDRbd/M2pmCAZxNrhtxwVX
fRy2uKcqT9f4yv228NLlKk/u6HIgrSKteVmHT2ZJ+6LBOaiwydw70xieDDB87kuz
CtgdjxiX58bRP6x5xl1KDoO/ZachBO1EMeSO4hHOpauy0awCOb7MvwhhmYlFOoDK
rtMWvS1prpdAeRTAWW3I8RthFGPYpbSwV6QuzjFzqO+HtnGFcR5RgOpjiL7yN55T
sGBMlmG7VqOuqVpVPQGv9y6d/0CqHtk8GyZ3WJZHtmImD/eWcuc0iqqgJVBQD2Sb
BzzsC7lWJRhFmjDTcz42OOxNbEAF/g8VhLnKsVIQcHGUdBPmHqH817dFAXa+5tAw
8ofP3F7Bxe8JYHhnPNHwq8kODsNVEPshR2e6duVhWFHc2++4MymE5zqRNi3+OQUb
fmt2wmhJ/OkWTfeOynSyuSx71dy6/kFOBRBhmTVZJ4xOXSJRhiCvSGuwi+/nIQ70
GsQSlOZx+OtE6eAZJ1/q2/KrbYaZnH7NjH20HetJmyBg9IIZrIQGs7liRuNYMU8N
FWUZ4MSjbQII/ay20nCUCA4WaVLpcyGbEE9iGZfu3rsiX2im+MAwumdhb9w5gHAV
1VccVfQyxB9dph3Acnsw
=S51O
-----END PGP SIGNATURE-----

--mYCpIKhGyMATD0i+--


From nobody Tue Jan 20 15:35:34 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28E971A0095 for ; Tue, 20 Jan 2015 15:35:28 -0800 (PST)
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 P0sqB9ItXqWL for ; Tue, 20 Jan 2015 15:35:26 -0800 (PST)
Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF3E41A0091 for ; Tue, 20 Jan 2015 15:35:26 -0800 (PST)
Received: by mail-ob0-f174.google.com with SMTP id wo20so27227558obc.5 for ; Tue, 20 Jan 2015 15:35:25 -0800 (PST)
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=kHW5EGMFbwDZeopSf4hk0qhzJQp1EfBeJA65p7ZSv3o=; b=NvfzYAl4CFDANAU8z9mzQpsqM1GgCRaJTw27IY8OI1L/sBm0cBvDheW6Hcam58MAyD +TFWIgqx0O1WdczgWm+MuyaRClcYrNBprEgGyMzYGHXBUbN6lwWDOCUsc+v74fJq0XF0 nZLRSJJoeO0mzl9n7ho6ADsfZUMUoW73c90cUxV+FPaJFqyche/M0OYDu5mgZqWf9J8N HrCSiZaDM8qxGumA1CDGROosPWGSBEtkR1tJuBrA2JGf66G5CwHTrsMd6Lh4XSSgaTf1 wFmHv45UV5Jp3Yz8iCRGZg41ASJ8j00CvghcZ6v1fSoZXO/EnnEGRcvZSbWX+r9c5Sou 4Waw==
MIME-Version: 1.0
X-Received: by 10.182.108.194 with SMTP id hm2mr22969009obb.85.1421796925942;  Tue, 20 Jan 2015 15:35:25 -0800 (PST)
Received: by 10.202.226.136 with HTTP; Tue, 20 Jan 2015 15:35:25 -0800 (PST)
In-Reply-To: <20150120225335.GA871@typhoon.azet.org>
References: <54B5501A.4070402@azet.org> <20150120191819.GA8165@typhoon.azet.org> <20150120193412.GA10140@typhoon.azet.org>  <20150120225335.GA871@typhoon.azet.org>
Date: Tue, 20 Jan 2015 15:35:25 -0800
Message-ID: 
From: Martin Thomson 
To: Aaron Zauner 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: TLS Mailing List 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Jan 2015 23:35:28 -0000

On 20 January 2015 at 14:53, Aaron Zauner  wrote:
> "..and generate a fatal 'illegal_parameter' TLS alert response"?

Sure.  Though s/response//; it's not a response in the classic sense,
just a message.


From nobody Tue Jan 20 16:46:58 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A06FD1A00BE for ; Tue, 20 Jan 2015 16:46:57 -0800 (PST)
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 xU5uq5j3H-wc for ; Tue, 20 Jan 2015 16:46:56 -0800 (PST)
Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E4F31A003B for ; Tue, 20 Jan 2015 16:46:56 -0800 (PST)
Received: by mail-we0-f176.google.com with SMTP id w62so14733470wes.7 for ; Tue, 20 Jan 2015 16:46:54 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=HbgTxc0L5Tjnbna9y2mogjn3MA4MlaM0Qp76M38xcyU=; b=Jp7tVXX8d6sQfGrBjBAgJrBsyjTZRevg6UkFNSYDkOyC99FBvsrI8Y+GMsM6n6QDrZ ENl+mluGve+NpVoKYSHWYrKtfTKkkol80/INzyEi4znNiEW15e2dNITswAWSntcAc9jf I0fv8BjvLgw1N0+KAbyqN0qOAIhYEJr2+E20J/1hAff6nDLntriJjzbqHc5jah0Nu921 aFEO81UxD2GCFEeD1bLyMLWdR/Sphm/ShrSpDCldu3SaT30X1jobu4GnSrg7ZQUgMFXo 3fdoNXcjgDrnt0/nd8PV+RZPHH0VkHwVHMahwm2xalNiB/Ms4KddMsRTOgN/eA4wcyr5 WOKg==
X-Gm-Message-State: ALoCoQn86+YyzUyvBcbfYH+NY/yjgnjNl6fo0XOVJ+PLiQToBq2DJdpUlNGkNbvSf8Qk7Iz5Gl5u
X-Received: by 10.194.81.1 with SMTP id v1mr55937890wjx.50.1421801214842; Tue, 20 Jan 2015 16:46:54 -0800 (PST)
Received: from typhoon.azet.org (chello080108032135.14.11.univie.teleweb.at. [80.108.32.135]) by mx.google.com with ESMTPSA id gu5sm5038530wib.24.2015.01.20.16.46.53 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Jan 2015 16:46:54 -0800 (PST)
Date: Wed, 21 Jan 2015 01:47:05 +0100
From: Aaron Zauner 
To: Martin Thomson 
Message-ID: <20150121004704.GA15203@typhoon.azet.org>
References: <54B5501A.4070402@azet.org> <20150120191819.GA8165@typhoon.azet.org> <20150120193412.GA10140@typhoon.azet.org>  <20150120225335.GA871@typhoon.azet.org> 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="KsGdsel6WgEHnImy"
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Cc: TLS Mailing List 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Jan 2015 00:46:57 -0000

--KsGdsel6WgEHnImy
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* Martin Thomson  [21/01/2015 00:35:26] wrote:
> On 20 January 2015 at 14:53, Aaron Zauner  wrote:
> > "..and generate a fatal 'illegal_parameter' TLS alert response"?
>=20
> Sure.  Though s/response//; it's not a response in the classic sense,
> just a message.

Tracked & Changed as suggested:
https://github.com/azet/draft-zauner-tls-aes-ocb/issues/1
https://github.com/azet/draft-zauner-tls-aes-ocb/commit/8c93b4c4d799675468f=
2b460dbb8fbc53e88fe6c

Thanks,
Aaron

--KsGdsel6WgEHnImy
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUvvcIAAoJEOTbZJL9ubXVX8MP/1hpgtt9PTD4BcgNGHodTRc3
1bd+V4xNctlOVYRddoAwRRJcZbtwM7d2YFPeX09XhvVwify7Yb8w8ykY3wlit3V3
ZCyM6wAeUm1cRCd4cED1t0fG7QEzMmaD+3unf+Utr7E2iSrOr8iIn7h4G5Wrx1fm
2U2uPfFpXP/3pFDHN+VinfotlqzNluJO53F6ogpB/HXRn+hgR17Unj22ASZA3tR1
kaWnKS3VDU58HVvFmS6k7SScUyvMqcUV4oRU6x1WsnN0nfVBLhquJSpN5SNylCTY
5v3JaXeup/ofrmateuHQghoGz0/aLBoED3qizQ0w8hANPxgZNXoZqGN7n+cPwyCl
829QBTrmH3UzOivyC9cHKI8+V1j8nW0wnSAzYVC4WGzk9lr6gtyVs2Zew0xfQthI
F+TSTxT3DaUF8vxjnsLuAIS/Y6jP49MU/X2IJRc/2wwSft+AfqaIAuqIqsi7sUPp
MzsxDl3vGSIDe+78MDqm3QGCeHs2h9zhIhY+2zXrf9SiOc/SdCrdgiHM+wLY2oNX
8ULme8JI49ti7X7jhkwrMwu4tMBLwmnTLq+GSBXibDMhNlyGo1FWsqetrvYGqOP5
vPtC7KtPxy8/4RW19wVXEbzOAbY5WuivZWq75aLAdG6sE3mjfBeyyKPFTNEapyDg
duR7yTezhkJ+xJWbW7J7
=EUCV
-----END PGP SIGNATURE-----

--KsGdsel6WgEHnImy--


From nobody Tue Jan 20 20:01:58 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 202EE1A0278 for ; Tue, 20 Jan 2015 20:01:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.402
X-Spam-Level: *
X-Spam-Status: No, score=1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, MANGLED_LOW=2.3, RCVD_IN_DNSWL_NONE=-0.0001, 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 FCrdy8TJkjO8 for ; Tue, 20 Jan 2015 20:01:31 -0800 (PST)
Received: from BAY004-OMC1S17.hotmail.com (bay004-omc1s17.hotmail.com [65.54.190.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE0C41A0270 for ; Tue, 20 Jan 2015 20:01:31 -0800 (PST)
Received: from BAY180-W68 ([65.54.190.59]) by BAY004-OMC1S17.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751);  Tue, 20 Jan 2015 20:01:31 -0800
X-TMN: [YpwbqTykcJFCaoCxWW2BlSxF96IHYGW+]
X-Originating-Email: [xiaoyin.l@outlook.com]
Message-ID: 
Content-Type: multipart/alternative; boundary="_99eff871-74bb-4488-a368-6e9c313ed2e7_"
From: Xiaoyin Liu 
To: Brian Smith , "mrex@sap.com" 
Date: Tue, 20 Jan 2015 23:01:31 -0500
Importance: Normal
In-Reply-To: 
References: <40128f312378442fbd26459bf5d7593b@usma1ex-dag1mb2.msg.corp.akamai.com>,  <20150119192701.190C71B0FF@ld9781.wdf.sap.corp>, 
MIME-Version: 1.0
X-OriginalArrivalTime: 21 Jan 2015 04:01:31.0502 (UTC) FILETIME=[F09838E0:01D0352E]
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Jan 2015 04:01:35 -0000

--_99eff871-74bb-4488-a368-6e9c313ed2e7_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi=2C
=20
I just finished a scan of Alexa top 1 million websites to test for TLS vers=
ion intolerance. I hope this information can be useful in the discussion of=
 downgrade SCSV.
=20
For each site=2C I made at most four attempts with the following order to f=
allback:
(TLS 1.3=2C TLS 1.3) -> (TLS 1.0=2C TLS 1.3) -> (TLS 1.0=2C TLS 1.2) -> (TL=
S 1.0=2C TLS 1.0)
where the first is TLS record layer version=2C and the second is Client Hel=
lo version.
=20
Here is the result:
(1) Number of sites scanned: 1=2C000=2C001
(2) Number of DNS Error: 45=2C402
(3) Number of sites that refuse TCP connection on port 443 (RST=2C timeout)=
: 289=2C334
(4) Number of sites that fail sending ServerHello in all 4 attempts: 238=2C=
846
(5) Number of sites that are tolerant to (TLS1.3=2C TLS1.3): 397=2C152 (93.=
1%)
(6) Number of sites that need to fallback to (TLS1.0=2C TLS1.3): 22=2C461 (=
5.3%)
(7) Number of sites that need to fallback to (TLS1.0=2C TLS1.2): 6=2C352 (1=
.5%)
(8) Number of sites that need to fallback to (TLS1.0=2C TLS1.0): 454 (0.1%)

The total number of TLS enabled sites is 426=2C419. TLS 1.3 intolerant site=
s (7 and 8) are about 1.6%. TLS 1.2 intolerant sites are about 0.1%. Also i=
t shows setting a lower record layer version does improve compatibility a l=
ot. An example is https://paypal.com is intolerant to (TLS 1.3=2C TLS 1.3) =
but is tolerant to (TLS 1.0=2C TLS 1.3). Please note that I did not validat=
e certificates nor check the integrity of handshakes. I closed the connecti=
on immediately after receiving ServerHello.
=20
If my data is accurate=2C I am against making downgrade SCSV a proposed sta=
ndard=2C and I believe browsers should stop insecure fallback. At least=2C =
the percentage of TLS 1.2 intolerant sites is low enough. For TLS 1.3=2C I =
think maybe browser vendors can announce a deadline=2C after which fallback=
 to TLS 1.2 will no longer be accepted? Or simply break them? Both are reas=
onable to me. Also I want to point out that if even as few as 1.6% sites wo=
n't upgrade their servers=2C can we count on most of the rest 98% supportin=
g SCSV?
=20
P.S. The statistic of Server Hello version is:
(9) SSL 2.0: 0 (0.0%)
(10) SSL 3.0: 413 (0.1%)
(11) TLS 1.0: 176051 (41.3%)
(12) TLS 1.1: 2261 (0.5%)
(13) TLS 1.2: 247668 (58.1%)
(14) Above TLS 1.2: 26 (0.0%=2C malformed response)
=20
The raw data of my scan result can be downloaded from here: https://onedriv=
e.live.com/redir?resid=3D8D6F364311BB35F2!110&authkey=3D!AI5Kno4OzsXbkII&it=
hint=3Dfile%2czip.
=20
Best=2C
Xiaoyin
=20
=20
> Date: Mon=2C 19 Jan 2015 12:58:28 -0800
> From: brian@briansmith.org
> To: mrex@sap.com
> CC: tls@ietf.org
> Subject: Re: [TLS] Last Call:  (TLS=
 Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downg=
rade Attacks) to Proposed Standard
>=20
> Martin Rex  wrote:
> > Permitting the server to continue the TLS handshake with
> > ServerHello.server_version =3D (ClientHello.client_version +1)
> >
> > This would be an extremely small change=2C but a *HUGE* improvement to =
this
> > proposal and make TLS handshakes _succeed_=2C i.e. promote interop.
>=20
> This doesn't work. Consider this example of how your suggestion would wor=
k:
>=20
> Client and server both support TLS 1.2.
>=20
> Client attempts TLS 1.2=2C receives RST.
> Client attempts TLS 1.1 w/ downgrade SCSV=2C receives RST.
> Client attempts TLS 1.0 w/ downgrade SCSV=2C receives TLS 1.1 ServerHello=
.
>=20
> This results in a downgrade from TLS 1.2 to TLS 1.1.
>=20
> > Should a TLS client be unsatisfied with the properties of the resulting
> > TLS session=2C that client could still decide attempting a new/differen=
t
> > handshake by proposing additional features in ClientHello (that should
> > have never been absent from ClientHello in the first place).
>=20
> I think at this point browsers are only "satisfied" when the
> connection is TLS 1.2 using an AEAD cipher suite=2C but they still feel
> the need to support servers that only support worse crypto. So=2C this
> part of the idea doesn't work either.
>=20
> > It's not that suggestions to improvement to this proposal haven't been
> > made.  It's really disappointing to see this go _through_ the TLS WG
> > and not seeing any improvement whatsoever=2C and then going straight
> > to asking for rubber-stamping it.
>=20
> I don't think that the characterization of "rubber-stamping" is
> accurate or helpful for moving the discussion forward.
>=20
> I DO think it would be useful for the IETF to wait ~8 weeks to see the
> results of Firefox's experiment in disabling the non-secure fallback=2C
> and to see the results of studies of TLS 1.3 intolerance with
> ClientHello messages with different record-level version numbers. If
> it turns out to be reasonable for web browsers to stop doing the
> non-secure fallback=2C then it really would be bad policy for IETF to
> make the downgrade a proposed standard=2C because the downgrade SCSV
> will always be limited in effectiveness by the fact that a huge number
> of servers will not deploy the downgrade SCSV mechanism any time soon.
> Still=2C it's not clear yet that web browsers can reasonably stop doing
> the non-secure fallback=2C so I think it makes sense to have the
> downgrade SCSV mechanism ready as insurance.
>=20
> Cheers=2C
> Brian
>=20
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
 		 	   		  =

--_99eff871-74bb-4488-a368-6e9c313ed2e7_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable





Hi=2C
 =3B
I just fini=
shed a scan of Alexa =3Btop 1 million websites to test for TLS version =
intolerance. I hope this information can be useful in =3Bthe discussion=
 of =3Bdowngrade SCSV.
 =3B
For each site=2C I made at most f=
our attempts with the following order to fallback:
(TLS 1.3=2C TLS 1.3) =
->=3B (TLS 1.0=2C TLS 1.3) ->=3B (TLS 1.0=2C TLS 1.2) ->=3B (TLS 1.0=
=2C TLS 1.0)
where the first is TLS =3Brecord layer version=2C and t=
he second is =3BClient Hello version.
 =3B
Here =3Bis the=
 result:
(1) Number of sites scanned: 1=2C000=2C001
(2) Number of DNS=
 Error: 45=2C402
(3) Number of sites that refuse TCP connection on port =
443 (RST=2C timeout): 289=2C334
(4) Number of sites that fail sending Se=
rverHello in all 4 attempts: 238=2C846
(5) Number of sites that are tole=
rant to (TLS1.3=2C TLS1.3): 397=2C152 (93.1%)
(6) Number of sites that n=
eed to fallback to (TLS1.0=2C TLS1.3): 22=2C461 (5.3%)
(7) Number of sit=
es that need to fallback to (TLS1.0=2C TLS1.2): 6=2C352 (1.5%)
(8) Numbe=
r of sites that need to fallback to (TLS1.0=2C TLS1.0): 454 (0.1%)

T=
he total number of TLS enabled sites is 426=2C419. =3BTLS 1.3 intoleran=
t sites (7 and 8) =3Bare about 1.6%. TLS 1.2 intolerant sites are about=
 0.1%. Also it shows =3Bsetting a lower record layer version does impro=
ve compatibility a lot. An example is https:=
//paypal.com is intolerant to (TLS 1.3=2C TLS 1.3) but is tolerant to (=
TLS 1.0=2C TLS 1.3). Please note that I did not validate certificates nor c=
heck the integrity =3Bof handshakes. I closed the connection immediatel=
y after receiving ServerHello.
 =3B
If my data is accurate=2C I a=
m against making downgrade SCSV a proposed standard=2C and I believe browse=
rs should stop insecure fallback. =3BAt least=2C the =3Bpercentage&=
nbsp=3Bof TLS 1.2 intolerant sites is =3Blow enough. For TLS 1.3=2C I t=
hink maybe browser vendors can announce a deadline=2C after which fallback =
to TLS 1.2 will no longer be =3Baccepted? Or simply break them? Both ar=
e reasonable to me. Also I want to point out that =3Bif even as few as =
1.6% sites won't upgrade their servers=2C =3Bcan we count on =3Bmos=
t of the rest 98% supporting =3BSCSV?
 =3B
P.S. The statistic=
 of Server Hello version is:
(9) SSL 2.0: 0 (0.0%)
(10) SSL 3.0: 413 =
(0.1%)
(11) TLS 1.0: 176051 (41.3%)
(12) TLS 1.1: 2261 (0.5%)
(13)=
 TLS 1.2: 247668 (58.1%)
(14) Above TLS 1.2: 26 (0.0%=2C malformed respo=
nse)
 =3B
The raw data of my scan =3Bresult can be downloaded=
 from here: https:=
//onedrive.live.com/redir?resid=3D8D6F364311BB35F2!110&=3Bauthkey=3D!AI5=
Kno4OzsXbkII&=3Bithint=3Dfile%2czip.
 =3B
Best=2C
Xiaoy=
in
 =3B
 =3B
>=3B Date: Mon=2C 19 Jan 2015 12:58:28=
 -0800
>=3B From: brian@briansmith.org
>=3B To: mrex@sap.com
&=
gt=3B CC: tls@ietf.org
>=3B Subject: Re: [TLS] Last Call: <=3Bdraft-=
ietf-tls-downgrade-scsv-03.txt>=3B (TLS Fallback Signaling Cipher Suite V=
alue (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard=

>=3B 
>=3B Martin Rex <=3Bmrex@sap.com>=3B wrote:
>=3B =
>=3B Permitting the server to continue the TLS handshake with
>=3B &=
gt=3B ServerHello.server_version =3D (ClientHello.client_version +1)
>=
=3B >=3B
>=3B >=3B This would be an extremely small change=2C but =
a *HUGE* improvement to this
>=3B >=3B proposal and make TLS handsha=
kes _succeed_=2C i.e. promote interop.
>=3B 
>=3B This doesn't wo=
rk. Consider this example of how your suggestion would work:
>=3B 
=
>=3B Client and server both support TLS 1.2.
>=3B 
>=3B Client =
attempts TLS 1.2=2C receives RST.
>=3B Client attempts TLS 1.1 w/ down=
grade SCSV=2C receives RST.
>=3B Client attempts TLS 1.0 w/ downgrade =
SCSV=2C receives TLS 1.1 ServerHello.
>=3B 
>=3B This results in =
a downgrade from TLS 1.2 to TLS 1.1.
>=3B 
>=3B >=3B Should a T=
LS client be unsatisfied with the properties of the resulting
>=3B >=
=3B TLS session=2C that client could still decide attempting a new/differen=
t
>=3B >=3B handshake by proposing additional features in ClientHell=
o (that should
>=3B >=3B have never been absent from ClientHello in =
the first place).
>=3B 
>=3B I think at this point browsers are o=
nly "satisfied" when the
>=3B connection is TLS 1.2 using an AEAD ciph=
er suite=2C but they still feel
>=3B the need to support servers that =
only support worse crypto. So=2C this
>=3B part of the idea doesn't wo=
rk either.
>=3B 
>=3B >=3B It's not that suggestions to improve=
ment to this proposal haven't been
>=3B >=3B made.  It's really disa=
ppointing to see this go _through_ the TLS WG
>=3B >=3B and not seei=
ng any improvement whatsoever=2C and then going straight
>=3B >=3B t=
o asking for rubber-stamping it.
>=3B 
>=3B I don't think that th=
e characterization of "rubber-stamping" is
>=3B accurate or helpful fo=
r moving the discussion forward.
>=3B 
>=3B I DO think it would b=
e useful for the IETF to wait ~8 weeks to see the
>=3B results of Fire=
fox's experiment in disabling the non-secure fallback=2C
>=3B and to s=
ee the results of studies of TLS 1.3 intolerance with
>=3B ClientHello=
 messages with different record-level version numbers. If
>=3B it turn=
s out to be reasonable for web browsers to stop doing the
>=3B non-sec=
ure fallback=2C then it really would be bad policy for IETF to
>=3B ma=
ke the downgrade a proposed standard=2C because the downgrade SCSV
>=
=3B will always be limited in effectiveness by the fact that a huge number<=
br>>=3B of servers will not deploy the downgrade SCSV mechanism any time =
soon.
>=3B Still=2C it's not clear yet that web browsers can reasonabl=
y stop doing
>=3B the non-secure fallback=2C so I think it makes sense=
 to have the
>=3B downgrade SCSV mechanism ready as insurance.
>=
=3B 
>=3B Cheers=2C
>=3B Brian
>=3B 
>=3B _____________=
__________________________________
>=3B TLS mailing list
>=3B TLS=
@ietf.org
>=3B https://www.ietf.org/mailman/listinfo/tls
 		 =
	   		  

=

--_99eff871-74bb-4488-a368-6e9c313ed2e7_--


From nobody Tue Jan 20 22:49:59 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E35BA1A0378 for ; Tue, 20 Jan 2015 22:49:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.652
X-Spam-Level: 
X-Spam-Status: No, score=-0.652 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, RCVD_IN_BL_SPAMCOP_NET=1.347, 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 fTrGcgbsmmR4 for ; Tue, 20 Jan 2015 22:49:55 -0800 (PST)
Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 271761A00D8 for ; Tue, 20 Jan 2015 22:49:55 -0800 (PST)
Received: by mail-wi0-f172.google.com with SMTP id bs8so32211819wib.5 for ; Tue, 20 Jan 2015 22:49:54 -0800 (PST)
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=jkpiJ25WlIY/S8m9kKrP2IG/UIBKYSR4Dn10puFvRmU=; b=NnhvGLqlmttmNdsGuJqvtM4IsIx0yY+J2tkZH1FQa+kL/X6FV+0WuHIfxLBm6SwREm cN0HX8bPYXg2GYDdMMIvhWmlU1tiDrmAczPzizUAOQLlKmpAEJttcr/lzyuDRaHs+867 o3bJH/VH2l4aQ1iPTrYq3dLrq/iFcEAkHQbQU5/QI6WQ7j336seg2tPYVVcbhA0wxpEj tAQr+fuOpdis85/j4/SSeVGR4EYwAIZwov0/+F7kXUwgcTfKVqFA+aRqOe/O6MThd5R8 oQimGoEE+1c7qEJb9Q2Qe+frhtORS9bTmBgCFr72EUtmC3yGPR5nIzF4wo+I8gGhg7jx Wfkw==
X-Received: by 10.180.90.241 with SMTP id bz17mr35356411wib.0.1421822993944; Tue, 20 Jan 2015 22:49:53 -0800 (PST)
Received: from [10.4.14.135] ([80.179.9.115]) by mx.google.com with ESMTPSA id b1sm5920795wiz.6.2015.01.20.22.49.20 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 20 Jan 2015 22:49:53 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_D301A4B7-B42A-4176-BC41-0C04A5298316"
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Yoav Nir 
In-Reply-To: 
Date: Wed, 21 Jan 2015 08:47:15 +0200
Message-Id: <04690E05-4905-4941-A60D-7BC5CDC93431@gmail.com>
References: <40128f312378442fbd26459bf5d7593b@usma1ex-dag1mb2.msg.corp.akamai.com> <,  > <20150119192701.190C71B0FF@ld9781.wdf.sap.corp> <, >  
To: Xiaoyin Liu 
X-Mailer: Apple Mail (2.1993)
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Jan 2015 06:49:58 -0000

--Apple-Mail=_D301A4B7-B42A-4176-BC41-0C04A5298316
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Hi, Xiaoyin

Thank you for the effort. I have one question. See below

> On Jan 21, 2015, at 6:01 AM, Xiaoyin Liu  =
wrote:
>=20
> Hi,
> =20
> I just finished a scan of Alexa top 1 million websites to test for TLS =
version intolerance. I hope this information can be useful in the =
discussion of downgrade SCSV.
> =20
> For each site, I made at most four attempts with the following order =
to fallback:
> (TLS 1.3, TLS 1.3) -> (TLS 1.0, TLS 1.3) -> (TLS 1.0, TLS 1.2) -> (TLS =
1.0, TLS 1.0)
> where the first is TLS record layer version, and the second is Client =
Hello version.
> =20
> Here is the result:
> (1) Number of sites scanned: 1,000,001
> (2) Number of DNS Error: 45,402
> (3) Number of sites that refuse TCP connection on port 443 (RST, =
timeout): 289,334
> (4) Number of sites that fail sending ServerHello in all 4 attempts: =
238,846
> (5) Number of sites that are tolerant to (TLS1.3, TLS1.3): 397,152 =
(93.1%)

What do you mean by tolerance here? Since no servers at all support TLS =
1.3, they have to break this kind of connection. Does it count as =
tolerance if they issue the proper alert?

> (6) Number of sites that need to fallback to (TLS1.0, TLS1.3): 22,461 =
(5.3%)

Does tolerance here and below means the same thing as above? In other =
words, do they count as tolerant if they break the connection, or only =
if they respond in TLS 1.2, 1.1, or 1.0 ?

> (7) Number of sites that need to fallback to (TLS1.0, TLS1.2): 6,352 =
(1.5%)
> (8) Number of sites that need to fallback to (TLS1.0, TLS1.0): 454 =
(0.1%)
>=20
> The total number of TLS enabled sites is 426,419. TLS 1.3 intolerant =
sites (7 and 8) are about 1.6%. TLS 1.2 intolerant sites are about 0.1%. =
Also it shows setting a lower record layer version does improve =
compatibility a lot. An example is https://paypal.com =
 is intolerant to (TLS 1.3, TLS 1.3) but is =
tolerant to (TLS 1.0, TLS 1.3). Please note that I did not validate =
certificates nor check the integrity of handshakes. I closed the =
connection immediately after receiving ServerHello.
> =20
> If my data is accurate, I am against making downgrade SCSV a proposed =
standard, and I believe browsers should stop insecure fallback. At =
least, the percentage of TLS 1.2 intolerant sites is low enough.

I think you will find that browser vendors may not consider this low =
enough.=20

> For TLS 1.3, I think maybe browser vendors can announce a deadline, =
after which fallback to TLS 1.2 will no longer be accepted? Or simply =
break them? Both are reasonable to me.

OpenSSL has been version tolerant forever. As has Microsoft=92s =
SChannel. I=92m not sure, but I think the Java library is as well. The =
people running these servers are using some exotic technology, and it=92s =
not clear they know how to upgrade them.

> Also I want to point out that if even as few as 1.6% sites won't =
upgrade their servers, can we count on most of the rest 98% supporting =
SCSV?

This is a strong argument, especially if we could obtain a list of =
high-value sites in the sense that the data on them is high-value. Sites =
like Facebook, banking, shops, email providers, dating sites, and check =
those.=20

Yoav



--Apple-Mail=_D301A4B7-B42A-4176-BC41-0C04A5298316
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

Hi, Xiaoyin

Thank you for the effort. I have one question. See =
below

On Jan 21, 2015, at 6:01 AM, Xiaoyin Liu =
<xiaoyin.l@outlook.com> wrote:

Hi,
 
I just finished a scan of Alexa top =
1 million websites to test for TLS version intolerance. I hope this =
information can be useful in the discussion of downgrade =
SCSV.
 
For each site, I made at most =
four attempts with the following order to fallback:
(TLS =
1.3, TLS 1.3) -> (TLS 1.0, TLS 1.3) -> (TLS 1.0, TLS 1.2) -> =
(TLS 1.0, TLS 1.0)
where the first is TLS record =
layer version, and the second is Client Hello version.
 
Here is the result:
(1)=
 Number of sites scanned: 1,000,001
(2) Number of DNS =
Error: 45,402
(3) Number of sites that refuse TCP =
connection on port 443 (RST, timeout): 289,334
(4) Number =
of sites that fail sending ServerHello in all 4 attempts: 238,846
(5) Number of sites that are tolerant to (TLS1.3, TLS1.3): =
397,152 (93.1%)

What do you mean by tolerance here? Since no servers at =
all support TLS 1.3, they have to break this kind of connection. Does it =
count as tolerance if they issue the proper alert?

(6) =
Number of sites that need to fallback to (TLS1.0, TLS1.3): 22,461 =
(5.3%)

Does tolerance here and below means the same thing as =
above? In other words, do they count as tolerant if they break the =
connection, or only if they respond in TLS 1.2, 1.1, or 1.0 =
?

(7) Number of sites that need to fallback to (TLS1.0, =
TLS1.2): 6,352 (1.5%)
(8) Number of sites that need to =
fallback to (TLS1.0, TLS1.0): 454 (0.1%)

The =
total number of TLS enabled sites is 426,419. TLS 1.3 intolerant =
sites (7 and 8) are about 1.6%. TLS 1.2 intolerant sites are about =
0.1%. Also it shows setting a lower record layer version does =
improve compatibility a lot. An example is https://paypal.com is intolerant to (TLS 1.3, =
TLS 1.3) but is tolerant to (TLS 1.0, TLS 1.3). Please note that I did =
not validate certificates nor check the integrity of handshakes. I =
closed the connection immediately after receiving ServerHello.
 
If my data is accurate, I am against =
making downgrade SCSV a proposed standard, and I believe browsers should =
stop insecure fallback. At least, the percentage of TLS =
1.2 intolerant sites is low enough. =


I think you will =
find that browser vendors may not consider this low =
enough. 

For TLS 1.3, I think maybe =
browser vendors can announce a deadline, after which fallback to TLS 1.2 =
will no longer be accepted? Or simply break them? Both are =
reasonable to me.

OpenSSL has been version tolerant forever. As has =
Microsoft=92s SChannel. I=92m not sure, but I think the Java library is =
as well. The people running these servers are using some exotic =
technology, and it=92s not clear they know how to upgrade them.

 =
Also I want to point out that if even as few as 1.6% sites won't =
upgrade their servers, can we count on most of the rest 98% =
supporting SCSV?

This is a strong argument, especially if we could =
obtain a list of high-value sites in the sense that the data on them is =
high-value. Sites like Facebook, banking, shops, email providers, dating =
sites, and check those. 

Yoav


=

--Apple-Mail=_D301A4B7-B42A-4176-BC41-0C04A5298316--


From nobody Tue Jan 20 23:40:52 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA5D31A038C for ; Tue, 20 Jan 2015 23:40:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.898
X-Spam-Level: 
X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 aB56J5QQLkRg for ; Tue, 20 Jan 2015 23:40:48 -0800 (PST)
Received: from BAY004-OMC1S16.hotmail.com (bay004-omc1s16.hotmail.com [65.54.190.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E1B61A0389 for ; Tue, 20 Jan 2015 23:40:48 -0800 (PST)
Received: from BAY180-W18 ([65.54.190.60]) by BAY004-OMC1S16.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751);  Tue, 20 Jan 2015 23:40:48 -0800
X-TMN: [oVqs5zPvvizFHUIcLA+DlzeyWIYYhRV+]
X-Originating-Email: [xiaoyin.l@outlook.com]
Message-ID: 
Content-Type: multipart/alternative; boundary="_8df3fa31-ba8f-42a2-b677-d78856816866_"
From: Xiaoyin Liu 
To: Yoav Nir 
Date: Wed, 21 Jan 2015 02:40:48 -0500
Importance: Normal
In-Reply-To: <04690E05-4905-4941-A60D-7BC5CDC93431@gmail.com>
References: <40128f312378442fbd26459bf5d7593b@usma1ex-dag1mb2.msg.corp.akamai.com> <, > <20150119192701.190C71B0FF@ld9781.wdf.sap.corp> <,>  , <04690E05-4905-4941-A60D-7BC5CDC93431@gmail.com>
MIME-Version: 1.0
X-OriginalArrivalTime: 21 Jan 2015 07:40:48.0349 (UTC) FILETIME=[92AFC0D0:01D0354D]
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Jan 2015 07:40:51 -0000

--_8df3fa31-ba8f-42a2-b677-d78856816866_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi=2C Yoav=2C Thanks for your reply! Here is my answer: What do you mean by=
 tolerance here? Since no servers at all support TLS 1.3=2C they have to br=
eak this kind of connection. Does it count as tolerance if they issue the p=
roper alert?            A: I count a server tolerant to TLS 1.3 if and only=
 if it replies a ServerHello handshake message with its version being TLS 1=
.2 or lower. Sending fatal alert (such as handshake failure=2C decode error=
=2C and protocol version) is not considered as tolerance. By the way=2C I w=
onder what's the proper alert here=2C since RFC 5246 Appendix E.1 requires =
"if a TLS server receives a ClientHello containing a version number greater=
 than the highest version supported by the server=2C it MUST reply accordin=
g to the highest version supported by the server".
 Does tolerance here and below means the same thing as above? In other word=
s=2C do they count as tolerant if they break the connection=2C or only if t=
hey respond in TLS 1.2=2C 1.1=2C or 1.0 ?          A: Yes=2C all of the "to=
lerance" means the same thing: only if they respond in TLS 1.2=2C 1.1=2C 1.=
0 or SSL 3.0.  Best=2C Xiaoyin
 Subject: Re: [TLS] Last Call:  (TLS =
Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgr=
ade Attacks) to Proposed Standard
From: ynir.ietf@gmail.com
Date: Wed=2C 21 Jan 2015 08:47:15 +0200
CC: tls@ietf.org
To: xiaoyin.l@outlook.com

Hi=2C Xiaoyin
Thank you for the effort. I have one question. See below
On Jan 21=2C 2015=2C at 6:01 AM=2C Xiaoyin Liu  wrot=
e:Hi=2C
=20
I just finished a scan of Alexa top 1 million websites to test for TLS vers=
ion intolerance. I hope this information can be useful in the discussion of=
 downgrade SCSV.
=20
For each site=2C I made at most four attempts with the following order to f=
allback:
(TLS 1.3=2C TLS 1.3) -> (TLS 1.0=2C TLS 1.3) -> (TLS 1.0=2C TLS 1.2) -> (TL=
S 1.0=2C TLS 1.0)
where the first is TLS record layer version=2C and the second is Client Hel=
lo version.
=20
Here is the result:
(1) Number of sites scanned: 1=2C000=2C001
(2) Number of DNS Error: 45=2C402
(3) Number of sites that refuse TCP connection on port 443 (RST=2C timeout)=
: 289=2C334
(4) Number of sites that fail sending ServerHello in all 4 attempts: 238=2C=
846
(5) Number of sites that are tolerant to (TLS1.3=2C TLS1.3): 397=2C152 (93.=
1%)

What do you mean by tolerance here? Since no servers at all support TLS 1.3=
=2C they have to break this kind of connection. Does it count as tolerance =
if they issue the proper alert?
(6) Number of sites that need to fallback to (TLS1.0=2C TLS1.3): 22=2C461 (=
5.3%)

Does tolerance here and below means the same thing as above? In other words=
=2C do they count as tolerant if they break the connection=2C or only if th=
ey respond in TLS 1.2=2C 1.1=2C or 1.0 ?
(7) Number of sites that need to fallback to (TLS1.0=2C TLS1.2): 6=2C352 (1=
.5%)
(8) Number of sites that need to fallback to (TLS1.0=2C TLS1.0): 454 (0.1%)

The total number of TLS enabled sites is 426=2C419. TLS 1.3 intolerant site=
s (7 and 8) are about 1.6%. TLS 1.2 intolerant sites are about 0.1%. Also i=
t shows setting a lower record layer version does improve compatibility a l=
ot. An example is https://paypal.com is intolerant to (TLS 1.3=2C TLS 1.3) =
but is tolerant to (TLS 1.0=2C TLS 1.3). Please note that I did not validat=
e certificates nor check the integrity of handshakes. I closed the connecti=
on immediately after receiving ServerHello.
=20
If my data is accurate=2C I am against making downgrade SCSV a proposed sta=
ndard=2C and I believe browsers should stop insecure fallback. At least=2C =
the percentage of TLS 1.2 intolerant sites is low enough.=20
I think you will find that browser vendors may not consider this low enough=
.=20
For TLS 1.3=2C I think maybe browser vendors can announce a deadline=2C aft=
er which fallback to TLS 1.2 will no longer be accepted? Or simply break th=
em? Both are reasonable to me.
OpenSSL has been version tolerant forever. As has Microsoft=92s SChannel. I=
=92m not sure=2C but I think the Java library is as well. The people runnin=
g these servers are using some exotic technology=2C and it=92s not clear th=
ey know how to upgrade them.
 Also I want to point out that if even as few as 1.6% sites won't upgrade t=
heir servers=2C can we count on most of the rest 98% supporting SCSV?

This is a strong argument=2C especially if we could obtain a list of high-v=
alue sites in the sense that the data on them is high-value. Sites like Fac=
ebook=2C banking=2C shops=2C email providers=2C dating sites=2C and check t=
hose.=20
Yoav

 		 	   		  =

--_8df3fa31-ba8f-42a2-b677-d78856816866_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable





Hi=2C Yoav=2C
&nb=
sp=3B
Thanks for your reply! Here is my answer:
 =
=3B
What do you mean by tolerance here? Since no servers at all s=
upport TLS 1.3=2C they have to break this kind of connection. Does it count=
 as tolerance if they issue the proper alert?
 =3B
=
 =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb=
sp=3B A: =3BI count a server tolerant to TLS 1.3 if and only if it repl=
ies a ServerHello handshake message with its version being TLS 1.2 or =
=3Blower. Sending fatal alert (such as handshake failure=2C decode error=2C=
 and protocol version) is not considered as tolerance. By the way=2C I wond=
er what's the proper alert here=2C since RFC 5246 Appendix E.1 requires "if=
 a TLS server receives a ClientHello containing a version number =3Bgre=
ater than the highest version supported by the server=2C it MUST =3Brep=
ly according to the highest version supported by the server".
 =3B
Does tolerance here and below means the same thing as a=
bove? In other words=2C do they count as tolerant if they break the connect=
ion=2C or only if they respond in TLS 1.2=2C 1.1=2C or 1.0 ?
&nbs=
p=3B =3B =3B =3B =3B =3B =3B =3B =3B A: Yes=
=2C all of the "tolerance" means the same thing: only if they respond in TL=
S 1.2=2C 1.1=2C 1.0 or SSL 3.0. =3B
 =3B
Best=
=2C 
Xiaoyin
 =3B
Subjec=
t: Re: [TLS] Last Call: <=3Bdraft-ietf-tls-downgrade-scsv-03.txt>=3B (T=
LS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Dow=
ngrade Attacks) to Proposed Standard
From: ynir.ietf@gmail.com
Date: =
Wed=2C 21 Jan 2015 08:47:15 +0200
CC: tls@ietf.org
To: xiaoyin.l@outl=
ook.com

Hi=2C Xiaoyin

Thank you for the effort. I=
 have one question. See below

On Jan 21=
=2C 2015=2C at 6:01 AM=2C Xiaoyin Liu <=3Bxiaoyin.l@outlook.com>=3B wrote:

Hi=2C
 =3B
I just =
finished a scan of Alexa =3Btop 1 million websites to test for TLS vers=
ion intolerance. I hope this information can be useful in =3Bthe discus=
sion of =3Bdowngrade SCSV.
 =3B
For each site=2C I made at mo=
st four attempts with the following order to fallback:
(TLS 1.3=2C TLS 1=
.3) ->=3B (TLS 1.0=2C TLS 1.3) ->=3B (TLS 1.0=2C TLS 1.2) ->=3B (TLS =
1.0=2C TLS 1.0)
where the first is TLS =3Brecord layer version=2C an=
d the second is =3BClient Hello version.
 =3B
Here =3Bis =
the result:
(1) Number of sites scanned: 1=2C000=2C001
(2) Number of =
DNS Error: 45=2C402
(3) Number of sites that refuse TCP connection on po=
rt 443 (RST=2C timeout): 289=2C334
(4) Number of sites that fail sending=
 ServerHello in all 4 attempts: 238=2C846
(5) Number of sites that are t=
olerant to (TLS1.3=2C TLS1.3): 397=2C152 (93.1%)

What do you mean by tolerance here? Since no servers at al=
l support TLS 1.3=2C they have to break this kind of connection. Does it co=
unt as tolerance if they issue the proper alert?

=

(6) Number of sites that need to fallback to (TLS1=
.0=2C TLS1.3): 22=2C461 (5.3%)

D=
oes tolerance here and below means the same thing as above? In other words=
=2C do they count as tolerant if they break the connection=2C or only if th=
ey respond in TLS 1.2=2C 1.1=2C or 1.0 ?

(7) Number of sites that need to fallback to (TLS1.0=2C TL=
S1.2): 6=2C352 (1.5%)
(8) Number of sites that need to fallback to (TLS1=
.0=2C TLS1.0): 454 (0.1%)

The total number of TLS enabled sites is 4=
26=2C419. =3BTLS 1.3 intolerant sites (7 and 8) =3Bare about 1.6%. =
TLS 1.2 intolerant sites are about 0.1%. Also it shows =3Bsetting a low=
er record layer version does improve compatibility a lot. An example is =3Bhttps://paypal.com =3Bis intolerant to (TLS 1.3=2C TLS 1.3) but is =
tolerant to (TLS 1.0=2C TLS 1.3). Please note that I did not validate certi=
ficates nor check the integrity =3Bof handshakes. I closed the connecti=
on immediately after receiving ServerHello.
 =3B
If my data is ac=
curate=2C I am against making downgrade SCSV a proposed standard=2C and I b=
elieve browsers should stop insecure fallback. =3BAt least=2C the =
=3Bpercentage =3Bof TLS 1.2 intolerant sites is =3Blow enough. 

I think you will find that browser=
 vendors may not consider this low enough. =3B

For TLS 1.3=2C I think maybe browser vendors can anno=
unce a deadline=2C after which fallback to TLS 1.2 will no longer be =
=3Baccepted? Or simply break them? Both are reasonable to me.

OpenSSL has been version tolerant forever. A=
s has Microsoft=92s SChannel. I=92m not sure=2C but I think the Java librar=
y is as well. The people running these servers are using some exotic techno=
logy=2C and it=92s not clear they know how to upgrade them.

 Also I want to point out that =3Bif ev=
en as few as 1.6% sites won't upgrade their servers=2C =3Bcan we count =
on =3Bmost of the rest 98% supporting =3BSCSV?

This is a strong argument=2C especially if we could =
obtain a list of high-value sites in the sense that the data on them is hig=
h-value. Sites like Facebook=2C banking=2C shops=2C email providers=2C dati=
ng sites=2C and check those. =3B

Yoav


 		 	   		  

=

--_8df3fa31-ba8f-42a2-b677-d78856816866_--


From nobody Wed Jan 21 01:16:53 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36CAD1A07BC for ; Wed, 21 Jan 2015 01:16:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Level: 
X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, 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 UHqRDl2XbU-7 for ; Wed, 21 Jan 2015 01:16:48 -0800 (PST)
Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c: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 6AD6A1A09CF for ; Wed, 21 Jan 2015 01:16:48 -0800 (PST)
Received: by mail-wi0-f181.google.com with SMTP id fb4so19115421wid.2 for ; Wed, 21 Jan 2015 01:16:47 -0800 (PST)
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=p1NEPenQh5ZGflg4/EyT8Id4myjtDJdUcit+EQ+dXJk=; b=FJm8y+v4puHY5xptHIX9n5xn7vGgatMuswgLlVaCuOOskIx+dlemR3qwYnEEvYd92T jFRbhBMbvcxwK51xiRFWdH00Imr2KWh4/xwKEtQBBHSSp5nHTMY3vTqKlzSOIJp3FwIX sQuy+4sgMGaCdovOtigtWr86iDv9Vf22ozs28GJxpPvLh9RseCRqTsVjNOVxFTC0FnRX OhYAf0Nx8hRISyakAuDKVUxAubiN6UcYk2QayvjXPyFA9AHNhqY54cYP+KpHKHPB1cnl 2/eT42BfYKcZIxop/Iu6ZuIS7jHzM0swbrX2RWWPjphvcb777OF0DRD9AC9t6rEupgFp ch3g==
X-Received: by 10.194.203.234 with SMTP id kt10mr24898962wjc.88.1421831807035;  Wed, 21 Jan 2015 01:16:47 -0800 (PST)
Received: from [172.24.251.208] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id vh8sm24654646wjc.12.2015.01.21.01.16.45 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 21 Jan 2015 01:16:46 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_D65E6CFA-B6CC-4A53-9548-15A51BDF32C2"
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Yoav Nir 
In-Reply-To: 
Date: Wed, 21 Jan 2015 11:16:43 +0200
Message-Id: <39B8BC24-D539-456F-970B-B11665B0E892@gmail.com>
References: <40128f312378442fbd26459bf5d7593b@usma1ex-dag1mb2.msg.corp.akamai.com> <,  > <20150119192701.190C71B0FF@ld9781.wdf.sap.corp> <, >   <, <04690E05-4905-4941-A60D-7BC5CDC93431@gmail.com> <>> 
To: Xiaoyin Liu 
X-Mailer: Apple Mail (2.1993)
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Jan 2015 09:16:51 -0000

--Apple-Mail=_D65E6CFA-B6CC-4A53-9548-15A51BDF32C2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Thanks

In that case, I think my implementation would fail with (1.3,1.3). Since =
I can=92t know what changes TLS 1.3 made to the record layer, I can=92t =
be sure that I understand what I=92m parsing. Perhaps those bytes that I =
thought were the ClientHello are actually some new fields that were =
added to the record header.

If the record layer version exceeds what the server supports, I think it =
wouldn=92t be prudent to reply with anything but an alert. Many =
implementations treated the record layer version in the ClientHello as a =
minimum version number. Yes, I know this goes against a MUST requirement =
in appendix E.1 or RFC 5246, but as that appendix says, this is behavior =
that is often implemented.

Yoav

> On Jan 21, 2015, at 9:40 AM, Xiaoyin Liu  =
wrote:
>=20
> Hi, Yoav,
> =20
> Thanks for your reply! Here is my answer:
> =20
> What do you mean by tolerance here? Since no servers at all support =
TLS 1.3, they have to break this kind of connection. Does it count as =
tolerance if they issue the proper alert?
> =20
>            A: I count a server tolerant to TLS 1.3 if and only if it =
replies a ServerHello handshake message with its version being TLS 1.2 =
or lower. Sending fatal alert (such as handshake failure, decode error, =
and protocol version) is not considered as tolerance. By the way, I =
wonder what's the proper alert here, since RFC 5246 Appendix E.1 =
requires "if a TLS server receives a ClientHello containing a version =
number greater than the highest version supported by the server, it MUST =
reply according to the highest version supported by the server".
>=20
> =20
> Does tolerance here and below means the same thing as above? In other =
words, do they count as tolerant if they break the connection, or only =
if they respond in TLS 1.2, 1.1, or 1.0 ?
>           A: Yes, all of the "tolerance" means the same thing: only if =
they respond in TLS 1.2, 1.1, 1.0 or SSL 3.0.=20
> =20
> Best,=20
> Xiaoyin
> =20
> Subject: Re: [TLS] Last Call:  =
(TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing =
Protocol Downgrade Attacks) to Proposed Standard
> From: ynir.ietf@gmail.com
> Date: Wed, 21 Jan 2015 08:47:15 +0200
> CC: tls@ietf.org
> To: xiaoyin.l@outlook.com
>=20
> Hi, Xiaoyin
>=20
> Thank you for the effort. I have one question. See below
>=20
> On Jan 21, 2015, at 6:01 AM, Xiaoyin Liu > wrote:
>=20
> Hi,
> =20
> I just finished a scan of Alexa top 1 million websites to test for TLS =
version intolerance. I hope this information can be useful in the =
discussion of downgrade SCSV.
> =20
> For each site, I made at most four attempts with the following order =
to fallback:
> (TLS 1.3, TLS 1.3) -> (TLS 1.0, TLS 1.3) -> (TLS 1.0, TLS 1.2) -> (TLS =
1.0, TLS 1.0)
> where the first is TLS record layer version, and the second is Client =
Hello version.
> =20
> Here is the result:
> (1) Number of sites scanned: 1,000,001
> (2) Number of DNS Error: 45,402
> (3) Number of sites that refuse TCP connection on port 443 (RST, =
timeout): 289,334
> (4) Number of sites that fail sending ServerHello in all 4 attempts: =
238,846
> (5) Number of sites that are tolerant to (TLS1.3, TLS1.3): 397,152 =
(93.1%)
>=20
> What do you mean by tolerance here? Since no servers at all support =
TLS 1.3, they have to break this kind of connection. Does it count as =
tolerance if they issue the proper alert?
>=20
> (6) Number of sites that need to fallback to (TLS1.0, TLS1.3): 22,461 =
(5.3%)
>=20
> Does tolerance here and below means the same thing as above? In other =
words, do they count as tolerant if they break the connection, or only =
if they respond in TLS 1.2, 1.1, or 1.0 ?
>=20
> (7) Number of sites that need to fallback to (TLS1.0, TLS1.2): 6,352 =
(1.5%)
> (8) Number of sites that need to fallback to (TLS1.0, TLS1.0): 454 =
(0.1%)
>=20
> The total number of TLS enabled sites is 426,419. TLS 1.3 intolerant =
sites (7 and 8) are about 1.6%. TLS 1.2 intolerant sites are about 0.1%. =
Also it shows setting a lower record layer version does improve =
compatibility a lot. An example is https://paypal.com =
 is intolerant to (TLS 1.3, TLS 1.3) but is =
tolerant to (TLS 1.0, TLS 1.3). Please note that I did not validate =
certificates nor check the integrity of handshakes. I closed the =
connection immediately after receiving ServerHello.
> =20
> If my data is accurate, I am against making downgrade SCSV a proposed =
standard, and I believe browsers should stop insecure fallback. At =
least, the percentage of TLS 1.2 intolerant sites is low enough.=20
>=20
> I think you will find that browser vendors may not consider this low =
enough.=20
>=20
> For TLS 1.3, I think maybe browser vendors can announce a deadline, =
after which fallback to TLS 1.2 will no longer be accepted? Or simply =
break them? Both are reasonable to me.
>=20
> OpenSSL has been version tolerant forever. As has Microsoft=92s =
SChannel. I=92m not sure, but I think the Java library is as well. The =
people running these servers are using some exotic technology, and it=92s =
not clear they know how to upgrade them.
>=20
> Also I want to point out that if even as few as 1.6% sites won't =
upgrade their servers, can we count on most of the rest 98% supporting =
SCSV?
>=20
> This is a strong argument, especially if we could obtain a list of =
high-value sites in the sense that the data on them is high-value. Sites =
like Facebook, banking, shops, email providers, dating sites, and check =
those.=20
>=20
> Yoav


--Apple-Mail=_D65E6CFA-B6CC-4A53-9548-15A51BDF32C2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

Thanks

In =
that case, I think my implementation would fail with (1.3,1.3). Since I =
can=92t know what changes TLS 1.3 made to the record layer, I can=92t be =
sure that I understand what I=92m parsing. Perhaps those bytes that I =
thought were the ClientHello are actually some new fields that were =
added to the record header.

If the record layer version exceeds what the server =
supports, I think it wouldn=92t be prudent to reply with anything but an =
alert. Many implementations treated the record layer version in the =
ClientHello as a minimum version number. Yes, I know this goes against a =
MUST requirement in appendix E.1 or RFC 5246, but as that appendix says, =
this is behavior that is often implemented.

Yoav

On =
Jan 21, 2015, at 9:40 AM, Xiaoyin Liu <xiaoyin.l@outlook.com> wrote:

Hi, =
Yoav,
 
Thanks for your =
reply! Here is my answer:
 
What do you mean by tolerance here? Since no servers at all =
support TLS 1.3, they have to break this kind of connection. Does it =
count as tolerance if they issue the proper alert?
 
           =
A: I count a server tolerant to TLS 1.3 if and only if it replies a =
ServerHello handshake message with its version being TLS 1.2 =
or lower. Sending fatal alert (such as handshake failure, decode =
error, and protocol version) is not considered as tolerance. By the way, =
I wonder what's the proper alert here, since RFC 5246 Appendix E.1 =
requires "if a TLS server receives a ClientHello containing a version =
number greater than the highest version supported by the server, it =
MUST reply according to the highest version supported by the =
server".

 
Does tolerance here and below means the same thing as above? =
In other words, do they count as tolerant if they break the connection, =
or only if they respond in TLS 1.2, 1.1, or 1.0 ?
          A: =
Yes, all of the "tolerance" means the same thing: only if they respond =
in TLS 1.2, 1.1, 1.0 or SSL 3.0. 
 
Best, 
Xiaoyin
 
Subject: Re: [TLS] Last Call: =
<draft-ietf-tls-downgrade-scsv-03.txt> (TLS Fallback Signaling =
Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to =
Proposed Standard
From: ynir.ietf@gmail.com
Date: Wed, 21 Jan 2015 08:47:15 +0200
CC: tls@ietf.org
To:=
 xiaoyin.l@outlook.com

Hi, =
Xiaoyin

Thank you =
for the effort. I have one question. See below

On Jan =
21, 2015, at 6:01 AM, Xiaoyin Liu <xiaoyin.l@outlook.com> wrote:

Hi,
 
I just finished a scan of Alexa top =
1 million websites to test for TLS version intolerance. I hope this =
information can be useful in the discussion of downgrade =
SCSV.
 
For each site, I made at most =
four attempts with the following order to fallback:
(TLS =
1.3, TLS 1.3) -> (TLS 1.0, TLS 1.3) -> (TLS 1.0, TLS 1.2) -> =
(TLS 1.0, TLS 1.0)
where the first is TLS record =
layer version, and the second is Client Hello version.
 
Here is the result:
(1)=
 Number of sites scanned: 1,000,001
(2) Number of DNS =
Error: 45,402
(3) Number of sites that refuse TCP =
connection on port 443 (RST, timeout): 289,334
(4) Number =
of sites that fail sending ServerHello in all 4 attempts: 238,846
(5) Number of sites that are tolerant to (TLS1.3, TLS1.3): =
397,152 (93.1%)
What do you mean by tolerance here? Since no servers =
at all support TLS 1.3, they have to break this kind of connection. Does =
it count as tolerance if they issue the proper alert?

(6) Number of sites =
that need to fallback to (TLS1.0, TLS1.3): 22,461 (5.3%)

Does tolerance here and below means the same thing as =
above? In other words, do they count as tolerant if they break the =
connection, or only if they respond in TLS 1.2, 1.1, or 1.0 ?

(7) Number of sites =
that need to fallback to (TLS1.0, TLS1.2): 6,352 (1.5%)
(8) =
Number of sites that need to fallback to (TLS1.0, TLS1.0): 454 (0.1%)

The total number of TLS enabled sites is =
426,419. TLS 1.3 intolerant sites (7 and 8) are about 1.6%. =
TLS 1.2 intolerant sites are about 0.1%. Also it shows setting a =
lower record layer version does improve compatibility a lot. An example =
is https://paypal.com is intolerant to (TLS =
1.3, TLS 1.3) but is tolerant to (TLS 1.0, TLS 1.3). Please note that I =
did not validate certificates nor check the integrity of =
handshakes. I closed the connection immediately after receiving =
ServerHello.
 
If my data is accurate, =
I am against making downgrade SCSV a proposed standard, and I believe =
browsers should stop insecure fallback. At least, =
the percentage of TLS 1.2 intolerant sites is low =
enough. 

I think you will find =
that browser vendors may not consider this low enough. 

For TLS 1.3, I think =
maybe browser vendors can announce a deadline, after which fallback to =
TLS 1.2 will no longer be accepted? Or simply break them? Both are =
reasonable to me.

OpenSSL has been version tolerant =
forever. As has Microsoft=92s SChannel. I=92m not sure, but I think the =
Java library is as well. The people running these servers are using some =
exotic technology, and it=92s not clear they know how to upgrade =
them.

Also I want to point =
out that if even as few as 1.6% sites won't upgrade their =
servers, can we count on most of the rest 98% =
supporting SCSV?

This is a strong argument, especially if =
we could obtain a list of high-value sites in the sense that the data on =
them is high-value. Sites like Facebook, banking, shops, email =
providers, dating sites, and check those. 

Yoav

=

--Apple-Mail=_D65E6CFA-B6CC-4A53-9548-15A51BDF32C2--


From nobody Wed Jan 21 02:56:12 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C4DC1A1A07 for ; Wed, 21 Jan 2015 02:56:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level: 
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, 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 c1ZgrqUm71qS for ; Wed, 21 Jan 2015 02:56:06 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 174E31A19EF for ; Wed, 21 Jan 2015 02:56:05 -0800 (PST)
Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t0LAu3Kq002561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 21 Jan 2015 05:56:03 -0500
Received: from dhcp-2-127.brq.redhat.com (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t0LAu1Cg015024 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 21 Jan 2015 05:56:02 -0500
Message-ID: <1421837761.2723.32.camel@redhat.com>
From: Nikos Mavrogiannopoulos 
To: Yoav Nir 
Date: Wed, 21 Jan 2015 11:56:01 +0100
In-Reply-To: <39B8BC24-D539-456F-970B-B11665B0E892@gmail.com>
References: <40128f312378442fbd26459bf5d7593b@usma1ex-dag1mb2.msg.corp.akamai.com> <, > <20150119192701.190C71B0FF@ld9781.wdf.sap.corp> <, >   <, <04690E05-4905-4941-A60D-7BC5CDC93431@gmail.com> <> >  <39B8BC24-D539-456F-970B-B11665B0E892@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Jan 2015 10:56:08 -0000

On Wed, 2015-01-21 at 11:16 +0200, Yoav Nir wrote:
> Thanks

> In that case, I think my implementation would fail with (1.3,1.3).
> Since I can’t know what changes TLS 1.3 made to the record layer, I
> can’t be sure that I understand what I’m parsing. Perhaps those bytes
> that I thought were the ClientHello are actually some new fields that
> were added to the record header.

You can know that. It is mentioned in rfc5246:
https://tools.ietf.org/html/rfc5246#appendix-E.1

"TLS servers compliant with this specification MUST accept any value
{03,XX} as the record layer version number for ClientHello."

It is, then, explicit that the record format cannot change without
changing the TLS major version from 03 to 04 or so.

> If the record layer version exceeds what the server supports, I think
> it wouldn’t be prudent to reply with anything but an alert. Many
> implementations treated the record layer version in the ClientHello as
> a minimum version number. Yes, I know this goes against a MUST
> requirement in appendix E.1 or RFC 5246, but as that appendix says,
> this is behavior that is often implemented.

Well, we can only interoperate as long as we implement the same
protocol, and the protocol is specific on what to do in that case.

regards,
Nikos




From SRS0=t9k+=CI=acm.org=bmoeller@srs.kundenserver.de  Wed Jan 21 07:11:44 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 938081A1ADB for ; Wed, 21 Jan 2015 07:11:44 -0800 (PST)
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 bViggXRd2zKP for ; Wed, 21 Jan 2015 07:11:43 -0800 (PST)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.10]) (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 114EB1A1AD0 for ; Wed, 21 Jan 2015 07:11:35 -0800 (PST)
Received: from mail-la0-f48.google.com ([209.85.215.48]) by mrelayeu.kundenserver.de (mreue101) with ESMTPSA (Nemesis) id 0MSrrB-1YLLL444pR-00Rqh6 for ; Wed, 21 Jan 2015 16:11:32 +0100
Received: by mail-la0-f48.google.com with SMTP id gf13so40625375lab.7 for ; Wed, 21 Jan 2015 07:11:31 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.152.161.168 with SMTP id xt8mr44786342lab.35.1421853091410;  Wed, 21 Jan 2015 07:11:31 -0800 (PST)
Received: by 10.25.25.145 with HTTP; Wed, 21 Jan 2015 07:11:31 -0800 (PST)
In-Reply-To: <04690E05-4905-4941-A60D-7BC5CDC93431@gmail.com>
References: <40128f312378442fbd26459bf5d7593b@usma1ex-dag1mb2.msg.corp.akamai.com> <20150119192701.190C71B0FF@ld9781.wdf.sap.corp>   <04690E05-4905-4941-A60D-7BC5CDC93431@gmail.com>
Date: Wed, 21 Jan 2015 16:11:31 +0100
Message-ID: 
From: Bodo Moeller 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=001a1134583e6fba59050d2af815
X-Provags-ID: V03:K0:r11YGb97HkK1qPdaQrnH6HmCpp/HNaAvdmbPQizA16gyAIZATcB Moz/jRJ2jQMG9vc7MQFxu8tUeHIA+veZFCexLsg4TBVRoIniamutZQDAk5V/IoS1h8vn1lh vBZ29NGhcQ1M0tjclINu5hXF8zg7lUXHQFNgn39EFdqC9MTf/mBwDHopULTs0giDcU5IDgY X/TM5IB9QAaTCJO6IRF5Q==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: 
Subject: Re: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Jan 2015 15:12:41 -0000

--001a1134583e6fba59050d2af815
Content-Type: text/plain; charset=UTF-8

Yoav Nir :

Also I want to point out that if even as few as 1.6% sites won't upgrade
> their servers, can we count on most of the rest 98% supporting SCSV?
>
>
> This is a strong argument, especially if we could obtain a list of
> high-value sites in the sense that the data on them is high-value. Sites
> like Facebook, banking, shops, email providers, dating sites, and check
> those.
>

I must admit I don't quite understand what the argument here is (sorry),
but in any case let me point out this:

If even just a *single* high-value site that you, personally, use does
support the SCSV, you'll benefit from the SCSV (provided that you're using
a browser that does a downgrade dance for compatibility with other servers
and sends the SCSV in downgraded Client Hello messages).

Bodo

--001a1134583e6fba59050d2af815
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Yoav=
 Nir <ynir.ietf@gmail.com>:

=

Also I want to point out that=C2=A0if even as few a=
s 1.6% sites won't upgrade their servers,=C2=A0can we count on=C2=A0mos=
t of the rest 98% supporting=C2=A0SCSV?
This is a strong argument, especially if we could obtain a l=
ist of high-value sites in the sense that the data on them is high-value. S=
ites like Facebook, banking, shops, email providers, dating sites, and chec=
k those.=C2=A0

I must adm=
it I don't quite understand what the argument here is (sorry), but in a=
ny case let me point out this:

If even just a *sin=
gle* high-value site=C2=A0that you, personally, use does support the SCSV, =
you'll benefit from the SCSV (provided that you're using a browser =
that does a downgrade dance for compatibility with other servers and sends =
the SCSV in downgraded Client Hello messages).

Bod=
o



--001a1134583e6fba59050d2af815--


From nobody Wed Jan 21 07:18:07 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAF861A1ADF for ; Wed, 21 Jan 2015 07:18:05 -0800 (PST)
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 do-E15R79dni for ; Wed, 21 Jan 2015 07:18:04 -0800 (PST)
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 B1CF81A1ADC for ; Wed, 21 Jan 2015 07:18:01 -0800 (PST)
Received: by mail-wi0-f181.google.com with SMTP id fb4so21588436wid.2 for ; Wed, 21 Jan 2015 07:18:00 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=5tfA1uzrxIW4mXdMdByVgNyHVCUVTLGmC2AMw0aYJvo=; b=bHCNzagf3L0rOQzej1GiL8vOMg8BZwdq0SoNvEk0hRw2PDh772Mxx2enpHEpZDLjgv kdx2TI/gXDLQKWMo5pw4B5Ea/epHr4dhacbztA9EtmzmWeI5fBd6zRxoEW3mv9XvNaAC M7TkmuUemwewHY+c2EcMxENAvvTm8OvAGccg7PhGKdRWCyHiUvigdV/pkXgEFKu+jkKA eLiqIKARswKnL3MQ7E7fU5UlyCG+ABvGAqWcXrDMWBlhY4Afe9C07/4tDD86jALhdY07 wa1c5A6dEzIyWZESv9IGsOcprFccNGK9OknkE4Hdrhbw18qdyPBwnRgiLJxZTBeDgNtd y1WA==
X-Gm-Message-State: ALoCoQlcMYxkwB5G5vIVlVGtkktCIM3EW0ueYFP2W6DtludnbjOU3lqQRUf/k7XNFOMMPrXH4zsE
X-Received: by 10.180.89.210 with SMTP id bq18mr2556787wib.45.1421853480449; Wed, 21 Jan 2015 07:18:00 -0800 (PST)
Received: from [172.16.1.132] ([188.21.236.102]) by mx.google.com with ESMTPSA id h13sm7677572wiw.4.2015.01.21.07.17.58 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 21 Jan 2015 07:17:59 -0800 (PST)
Message-ID: <54BFC326.4010302@azet.org>
Date: Wed, 21 Jan 2015 16:17:58 +0100
From: Aaron Zauner 
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: TLS Mailing List 
References: <54B5501A.4070402@azet.org> <20150120191819.GA8165@typhoon.azet.org> <20150120193412.GA10140@typhoon.azet.org>  <20150120225335.GA871@typhoon.azet.org>  <20150121004704.GA15203@typhoon.azet.org>
In-Reply-To: <20150121004704.GA15203@typhoon.azet.org>
X-Enigmail-Version: 1.2.3
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigE0227BEB15D5DC5DD517A053"
Archived-At: 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Jan 2015 15:18:06 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigE0227BEB15D5DC5DD517A053
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,

Any comments on the idea of removing the following two ciphersuites from
the draft?

     CipherSuite TLS_DHE_PSK_WITH_AES_128_OCB =3D {TBD9, TBD9}
     CipherSuite TLS_DHE_PSK_WITH_AES_256_OCB =3D {TBD10, TBD10}

I don't see how these would be relevant to embedded devices.

Aaron


--------------enigE0227BEB15D5DC5DD517A053
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUv8MmAAoJEOTbZJL9ubXV3bAQAMW5J0y/we+uNvvsTT7zu+cv
bitxYmmayx6BTg3j0zAfmoYk/bNkhEwFE2Tc2rJOVT1TqDRPIoCTJuHpPk254jkU
/CuQjB7aqjR1CZgpYXd77a/1NgrDGFl8f1QvrsPTNUPTjlB+2oT5WvUdsaOMXHyf
ZGB+w5lSXT5zK6afIw1rA0jc3OFB1vLUIAy3sIdQno/crLTeDC7AKzXuSAe2/4Ej
ZlUwPdcy0IzSdUjX0F/O52KvvcTCoYKYc2nLZsok4xSkKjccCfSryJB8/xd2/zyj
MF+T0enrypwIbTfeUPKrLvLhXlzsjYK98KDdtuuqpaXREc8YgEsiHvf5bEwvWKKW
CypD/vm2TFWGMg4zz/bv5lx9dfqQVRzcIfzPglvaluIv/PdB3y/JAXoAeDClDmeA
6FVvI32zL3WJWRRUSwMPw6OfKiwsRutHH2un09h5h3wQEsvRdRLjSfGXXLPWpcyf
tEACAL2MwYen502pVazcjIbWVDyNrI6g1pJB56e4eH6t+Zt3JkAgyumELBbT5McD
quOUnAN5YI6kiUz+m0bIgqiSstI9/7msIW35ShIRj+pQtkW7WbUbumE3ZvBVLW6l
uudrZDtxHyYJ13Wwy8QN73LfwCuPAVW4bjIiauzxk2xX6phJq4C4tRA421Luoj1T
A6vY0SdqM3Nw8bBHwEJp
=B80n
-----END PGP SIGNATURE-----

--------------enigE0227BEB15D5DC5DD517A053--


From nobody Wed Jan 21 08:16:33 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 227821A1AFE for ; Wed, 21 Jan 2015 08:16:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 V71MrLuH65s9 for ; Wed, 21 Jan 2015 08:16:28 -0800 (PST)
Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBCFA1A1AE0 for ; Wed, 21 Jan 2015 08:16:27 -0800 (PST)
Received: by mail-wg0-f48.google.com with SMTP id x12so12253975wgg.7 for ; Wed, 21 Jan 2015 08:16:26 -0800 (PST)
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:from:date :message-id:subject:to:cc:content-type; bh=02489GuxSX7bvmeI+84IsiZGJ0zYNtH34mOkE3QSHLY=; b=R+5XolKX8OrVM6lxVi/LlhTmoIkONbZBXfBwgA7WPpXDzKYVeEsQXckjOkqLYYMr7p ik1i6hjzO8FNBZvR1gAxfVml08tIK7IdoC8SGQnQzxveLud9Tjk5FFruWQ6+StyoHDJq 8AWIxC0qz7j25rCjZZMr3bL0FjCDGP1z2dignemvKamdyMumIsjPgVbb0W7509Zd3KDQ ThFi8zji6tRtu7FibrF2AiH3lgv/SXFlyh5dikKS0sEa33phqeKDvzB9yqktEIcp3/MO 1OR72+UfMG+FkFmEM4iMczfh77VgtvG6kj29x1mbcYAqAzCZc5kfMifQMpsyvKGiyVc0 Q/dQ==
X-Gm-Message-State: ALoCoQl6YXtJl495Ob95UDL8cETJcLfVZ0+HvqF6L+tD1NQxDC0UWBC1ffiw+cL7GClwWbbWPu7e
X-Received: by 10.180.21.225 with SMTP id y1mr57319807wie.42.1421856985492; Wed, 21 Jan 2015 08:16:25 -0800 (PST)
MIME-Version: 1.0
Received: by 10.27.142.215 with HTTP; Wed, 21 Jan 2015 08:15:45 -0800 (PST)
In-Reply-To: <54BFC326.4010302@azet.org>
References: <54B5501A.4070402@azet.org> <20150120191819.GA8165@typhoon.azet.org> <20150120193412.GA10140@typhoon.azet.org>  <20150120225335.GA871@typhoon.azet.org>  <20150121004704.GA15203@typhoon.azet.org> <54BFC326.4010302@azet.org>
From: Eric Rescorla 
Date: Wed, 21 Jan 2015 08:15:45 -0800
Message-ID: 
To: Aaron Zauner 
Content-Type: multipart/alternative; boundary=047d7bb709888ac331050d2be0a8
Archived-At: 
Cc: TLS Mailing List 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Jan 2015 16:16:31 -0000

--047d7bb709888ac331050d2be0a8
Content-Type: text/plain; charset=UTF-8

If we generally think DHE_PSK is a good idea, is there a specific reason why
it wouldn't be a good idea for OCB?

-Ekr


On Wed, Jan 21, 2015 at 7:17 AM, Aaron Zauner  wrote:

> Hi,
>
> Any comments on the idea of removing the following two ciphersuites from
> the draft?
>
>      CipherSuite TLS_DHE_PSK_WITH_AES_128_OCB = {TBD9, TBD9}
>      CipherSuite TLS_DHE_PSK_WITH_AES_256_OCB = {TBD10, TBD10}
>
> I don't see how these would be relevant to embedded devices.
>
> Aaron
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>

--047d7bb709888ac331050d2be0a8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


If we generally think DHE_PSK is a good idea, is there a s=
pecific reason why
it wouldn't be a good idea for OCB?
-Ekr


=

On Wed, Jan 21, 2015 at 7:17 AM, Aaron Zauner <azet=
@azet.org> wrote:
Hi,



Any comments on the idea of removing the following two ciphersuites from
the draft?



=C2=A0 =C2=A0 =C2=A0CipherSuite TLS_DHE_PSK_WITH_AES_128_OCB =3D {TBD9, TBD=
9}

=C2=A0 =C2=A0 =C2=A0CipherSuite TLS_DHE_PSK_WITH_AES_256_OCB =3D {TBD10, TB=
D10}



I don't see how these would be relevant to embedded devices.



Aaron




_______________________________________________

TLS mailing list

TLS@ietf.org

htt=
ps://www.ietf.org/mailman/listinfo/tls





--047d7bb709888ac331050d2be0a8--


From nobody Wed Jan 21 08:23:23 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F28011A1B0C for ; Wed, 21 Jan 2015 08:23:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.21
X-Spam-Level: 
X-Spam-Status: No, score=-1.21 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, 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 jVPLBkX_qyzq for ; Wed, 21 Jan 2015 08:23:19 -0800 (PST)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 1DBDA1A1B0B for ; Wed, 21 Jan 2015 08:23:18 -0800 (PST)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 2CCD247628; Wed, 21 Jan 2015 16:23:18 +0000 (GMT)
Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 1D21747624; Wed, 21 Jan 2015 16:23:18 +0000 (GMT)
Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.34]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 17BE7202E; Wed, 21 Jan 2015 16:23:18 +0000 (GMT)
Received: from USMA1EX-DAG1MB2.msg.corp.akamai.com (172.27.123.102) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 21 Jan 2015 11:21:38 -0500
Received: from USMA1EX-DAG1MB2.msg.corp.akamai.com ([172.27.123.102]) by usma1ex-dag1mb2.msg.corp.akamai.com ([172.27.123.102]) with mapi id 15.00.0913.011; Wed, 21 Jan 2015 11:21:38 -0500
From: "Salz, Rich" 
To: Aaron Zauner , TLS Mailing List 
Thread-Topic: [TLS] Inclusion of OCB mode in TLS 1.3
Thread-Index: AdAvUwVbzm8zizwqTXS0eqroQIbuXQFvL3iAACF1UcA=
Date: Wed, 21 Jan 2015 16:21:38 +0000
Message-ID: <6d7dec54c4da410e9a395af0688322df@usma1ex-dag1mb2.msg.corp.akamai.com>
References: <54B5501A.4070402@azet.org> <20150120191819.GA8165@typhoon.azet.org>
In-Reply-To: <20150120191819.GA8165@typhoon.azet.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.19.41.69]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Jan 2015 16:23:21 -0000

PiBSaWdodCBub3cgdGhpcyBJRCB3b3VsZCBhZGQgdHdlbHZlICgxMikgbmV3IGNpcGhlcnN1aXRl
cyB0bw0KPiB0aGUgVExTIGNpcGhlcnN1aXRlIHJlZ2lzdHJ5LCBpZiB3ZSAvY2FuLyBnZXQgcmlk
IG9mIHRoZXNlIHR3byB3ZSdyZSBkb3duIHRvDQo+IHRlbiAoMTApLg0KDQpHYWFrLg0KDQpXaGF0
IGRvZXMgT0NCIGJyaW5nIHRvIHRoZSB0YWJsZSB0aGF0IGp1c3RpZmllcyBzdWNoIGEgaHVnZSBp
bmNyZWFzZSAoMTAlKSBpbiB0aGUgbnVtYmVyIG9mIGNpcGhlcnMuDQoNCldlIG5lZWQgYSBjaXBo
ZXIgY2FnZSBtYXRjaC4gIFRoZXkgY2FsbCBnbyBpbiwgYW5kIG9ubHkgYSBjb3VwbGUgY29tZSBv
dXQuDQogDQo=


From nobody Wed Jan 21 08:25:47 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 847861A1B13 for ; Wed, 21 Jan 2015 08:25:45 -0800 (PST)
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 OwtbAIjQzQjZ for ; Wed, 21 Jan 2015 08:25:44 -0800 (PST)
Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C37461A1B01 for ; Wed, 21 Jan 2015 08:25:37 -0800 (PST)
Received: by mail-yk0-f181.google.com with SMTP id 79so6947584ykr.12 for ; Wed, 21 Jan 2015 08:25:37 -0800 (PST)
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=DQtUDU5+wNWCdAnyuK3fIGqKuWPRo3wQnTtu5SZN9Ew=; b=nWWCcDALNmWjsdn+0000oy+s413Y/Q/iNH9TohuVuBEY2/0uj8EA0yzlV0DqO8jgX0 niWpWvDfjCvc/0b0jijAH1VaJhoHvsnENHX+43vS0iA/QePP6dTMN/AUUd1iRtVtNjTc 2ki/MoOhDaIy1lO4q19K03rqUbpvGlXvP4jITOXvBc+d9/WETDpd54iWGtamUBHVmcT0 0ELE3f2NzbtgPYxxx+apV43NSE8tRzpmdgPOO3dI5YThJSjaw3P+SgV5SnwePlelSkx2 1rBtIc4kjRQ52FPo1GJllO9/kxDKsp693m2o0I9w0IIwK9IrhENnf4PYN1e0wY5GwcEc AxmA==
MIME-Version: 1.0
X-Received: by 10.236.26.233 with SMTP id c69mr24349339yha.49.1421857537037; Wed, 21 Jan 2015 08:25:37 -0800 (PST)
Received: by 10.170.115.77 with HTTP; Wed, 21 Jan 2015 08:25:36 -0800 (PST)
In-Reply-To: <6d7dec54c4da410e9a395af0688322df@usma1ex-dag1mb2.msg.corp.akamai.com>
References: <54B5501A.4070402@azet.org> <20150120191819.GA8165@typhoon.azet.org> <6d7dec54c4da410e9a395af0688322df@usma1ex-dag1mb2.msg.corp.akamai.com>
Date: Wed, 21 Jan 2015 08:25:36 -0800
Message-ID: 
From: Watson Ladd 
To: "Salz, Rich" 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: TLS Mailing List 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Jan 2015 16:25:45 -0000

On Wed, Jan 21, 2015 at 8:21 AM, Salz, Rich  wrote:
>> Right now this ID would add twelve (12) new ciphersuites to
>> the TLS ciphersuite registry, if we /can/ get rid of these two we're down to
>> ten (10).
>
> Gaak.
>
> What does OCB bring to the table that justifies such a huge increase (10%) in the number of ciphers.

Side-channel resistance and performance on hardware with AES but no
carryless multiplier.

>
> We need a cipher cage match.  They call go in, and only a couple come out.

If you don't need to support them all, what's the cost (assuming they
are all secure)?
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



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


From nobody Wed Jan 21 08:28:28 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7431A1B15 for ; Wed, 21 Jan 2015 08:28:26 -0800 (PST)
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, 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 rT7Mk_Q366Wn for ; Wed, 21 Jan 2015 08:28:24 -0800 (PST)
Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id D7F3F1A1B11 for ; Wed, 21 Jan 2015 08:28:09 -0800 (PST)
Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id E864828501; Wed, 21 Jan 2015 16:28:08 +0000 (GMT)
Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id D68FF284F6; Wed, 21 Jan 2015 16:28:08 +0000 (GMT)
Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id A8DDA2034; Wed, 21 Jan 2015 16:28:08 +0000 (GMT)
Received: from USMA1EX-DAG1MB2.msg.corp.akamai.com (172.27.123.102) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 21 Jan 2015 11:28:07 -0500
Received: from USMA1EX-DAG1MB2.msg.corp.akamai.com ([172.27.123.102]) by usma1ex-dag1mb2.msg.corp.akamai.com ([172.27.123.102]) with mapi id 15.00.0913.011; Wed, 21 Jan 2015 11:28:07 -0500
From: "Salz, Rich" 
To: Watson Ladd 
Thread-Topic: [TLS] Inclusion of OCB mode in TLS 1.3
Thread-Index: AdAvUwVbzm8zizwqTXS0eqroQIbuXQFvL3iAACF1UcAACszIAAAKcuTA
Date: Wed, 21 Jan 2015 16:28:07 +0000
Message-ID: <54456f8f41cc4635ac4fd6a74883f09b@usma1ex-dag1mb2.msg.corp.akamai.com>
References: <54B5501A.4070402@azet.org> <20150120191819.GA8165@typhoon.azet.org> <6d7dec54c4da410e9a395af0688322df@usma1ex-dag1mb2.msg.corp.akamai.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.19.41.69]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Cc: TLS Mailing List 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Jan 2015 16:28:26 -0000

PiBJZiB5b3UgZG9uJ3QgbmVlZCB0byBzdXBwb3J0IHRoZW0gYWxsLCB3aGF0J3MgdGhlIGNvc3Qg
KGFzc3VtaW5nIHRoZXkgYXJlIGFsbA0KPiBzZWN1cmUpPw0KDQpUaGF0J3MgYSBwcmV0dHkgd2Vp
Z2h0eSBhc3N1bXB0aW9uLiAgQW5kIGhvdyBkbyB5b3UgZGVjaWRlIHdoaWNoIG9uZXMgeW91IGhh
dmUgdG8gc3VwcG9ydCwgd2hpY2ggYXJlIE1USSwgZXRjPyAgSG93IGRvIHlvdSBhZHZpc2UgY3Vz
dG9tZXJzIHRvIHVzZSBPQ0Igb3ZlciB0aGVpciBmYXZvcml0ZSBuYXRpb25hbCBjaXBoZXIsIGxp
a2UgR09TVCBvciBTRUVEPyAgT3IgQ2FtZWxsaWE/DQoNCg==


From nobody Wed Jan 21 08:40:54 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B39C1A1B1B for ; Wed, 21 Jan 2015 08:40:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Level: 
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 o15XPTo65KyK for ; Wed, 21 Jan 2015 08:40:49 -0800 (PST)
Received: from homiemail-a16.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF981A1B1C for ; Wed, 21 Jan 2015 08:40:49 -0800 (PST)
Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id 57BAF50808E; Wed, 21 Jan 2015 08:40:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=6z5BLVln3601Ay IB+NDrrgn8h1g=; b=ggx8vRUo+zy5JESkwFqaxqu8kDuWhbJpLaXNz9fg9dp2z0 vR7eVmCuLRsySlRiyGXNgaq+bCIV4k0xLjabvGiyOCh7DYu/LYnlZbv/WJ8d877L iNDtouBC4fXlA7qkWqohfIgsbuFQ8BGlVTg/605Tjn7hYnd/E7zaZMxC42RRA=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPA id E3DAF50808C; Wed, 21 Jan 2015 08:40:48 -0800 (PST)
Date: Wed, 21 Jan 2015 10:40:42 -0600
From: Nico Williams 
To: "Salz, Rich" 
Message-ID: <20150121164037.GO2350@localhost>
References: <54B5501A.4070402@azet.org> <20150120191819.GA8165@typhoon.azet.org> <6d7dec54c4da410e9a395af0688322df@usma1ex-dag1mb2.msg.corp.akamai.com>  <54456f8f41cc4635ac4fd6a74883f09b@usma1ex-dag1mb2.msg.corp.akamai.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <54456f8f41cc4635ac4fd6a74883f09b@usma1ex-dag1mb2.msg.corp.akamai.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: 
Cc: TLS Mailing List 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Jan 2015 16:40:50 -0000

On Wed, Jan 21, 2015 at 04:28:07PM +0000, Salz, Rich wrote:
> > If you don't need to support them all, what's the cost (assuming
> > they are all secure)?
> 
> That's a pretty weighty assumption.  And how do you decide which ones
> you have to support, which are MTI, etc?  How do you advise customers

None would be required to implement.

> to use OCB over their favorite national cipher, like GOST or SEED?  Or
> Camellia?

We wouldn't.  Customers who have to give preference to national
ciphers... would, and presumably the legislation and regulations they
are subject to would say something about cipher modes (or, if not, then
what modes they prefer seems irrelevant since it's just a preference and
the negotiation should just work).

Nico
-- 


From nobody Wed Jan 21 08:41:46 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99C451A1B1B for ; Wed, 21 Jan 2015 08:41:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level: 
X-Spam-Status: No, score=-1.7 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_8BIT_HEADER=0.3, 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 SUaVeOawerpw for ; Wed, 21 Jan 2015 08:41:42 -0800 (PST)
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 DB4171A1B10 for ; Wed, 21 Jan 2015 08:41:41 -0800 (PST)
Received: by mail-lb0-f180.google.com with SMTP id b6so14662409lbj.11 for ; Wed, 21 Jan 2015 08:41:40 -0800 (PST)
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:content-transfer-encoding; bh=krCV6nxyfoWgk7C/YRIhXXER466bstmo4RzUyuey5G0=; b=f2mOIvgpieVT0OeKblY0iwKxqtNfwCPzpNSPYXDy42XKeA4RCjLTs6QDx7nXMuEsAZ hQbCR/AloaA5yO8s7fUsJtMFnrRvgvrG/AIbDLKmqWHU5v6CYROIpY8RCga5ijehl6yw q02pwhDaqfy5ZMPr7jeCCHONUwDxYK2fW/EUQ4RThoAVSY0QlEUi5EjHSfJyp96jH7gQ UwcnBf8acCHHaUZ5HEJyx/d38wgq6Ho0015bcd1Ffi8bFlXVmybxwPT2rvMpsacywW+T T6AAWRJHwFDsaKbx3DN2vbKMO2sXQ5ax/6p20Z+v5zuMokH6QmNLsGycPY0hUyS9Pb22 zDbw==
MIME-Version: 1.0
X-Received: by 10.112.12.65 with SMTP id w1mr45147788lbb.68.1421858500334; Wed, 21 Jan 2015 08:41:40 -0800 (PST)
Received: by 10.112.200.4 with HTTP; Wed, 21 Jan 2015 08:41:40 -0800 (PST)
In-Reply-To: <54456f8f41cc4635ac4fd6a74883f09b@usma1ex-dag1mb2.msg.corp.akamai.com>
References: <54B5501A.4070402@azet.org> <20150120191819.GA8165@typhoon.azet.org> <6d7dec54c4da410e9a395af0688322df@usma1ex-dag1mb2.msg.corp.akamai.com>  <54456f8f41cc4635ac4fd6a74883f09b@usma1ex-dag1mb2.msg.corp.akamai.com>
Date: Wed, 21 Jan 2015 17:41:40 +0100
Message-ID: 
From: =?UTF-8?Q?Henrik_Grubbstr=C3=B6m?= 
To: "Salz, Rich" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: TLS Mailing List 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Jan 2015 16:41:43 -0000

On Wed, Jan 21, 2015 at 5:28 PM, Salz, Rich  wrote:
>> If you don't need to support them all, what's the cost (assuming they ar=
e all
>> secure)?
>
> That's a pretty weighty assumption.  And how do you decide which ones you=
 have to support, which are MTI, etc?

The ones that you need to support are the suite(s) specified as MUST
in the TLS 1.3 RFC.

>  How do you advise customers to use OCB over their favorite national ciph=
er, like GOST or SEED?  Or Camellia?

Apples and oranges; AFAIK OCB is a generic mode, so presumably there
will be at least an ID for Camellia/OCB mirroring the AES/OCB cipher
suites as soon as the people at NTT wake up...

/grubba

--=20
Henrik Grubbstr=C3=B6m                                       grubba@grubba.=
org
Roxen Internet Software AB                              grubba@roxen.com


From nobody Wed Jan 21 08:42:59 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 771A51A1B23 for ; Wed, 21 Jan 2015 08:42:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.967
X-Spam-Level: 
X-Spam-Status: No, score=0.967 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FRT_LOLITA1=1.865, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 5RBCB9VXtUET for ; Wed, 21 Jan 2015 08:42:52 -0800 (PST)
Received: from BAY004-OMC1S3.hotmail.com (bay004-omc1s3.hotmail.com [65.54.190.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 682FE1A1B1E for ; Wed, 21 Jan 2015 08:42:52 -0800 (PST)
Received: from BAY405-EAS137 ([65.54.190.60]) by BAY004-OMC1S3.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751);  Wed, 21 Jan 2015 08:42:52 -0800
X-TMN: [8fZ204Qv9iS+E2NXf25GfTIkOnSpoAqI]
X-Originating-Email: [xiaoyin.l@outlook.com]
Message-ID: 
Content-Type: multipart/alternative; boundary="_d25633f4-46e4-41c2-ad47-359ecf775fca_"
MIME-Version: 1.0
To: Bodo Moeller , "tls@ietf.org" 
From: Xiaoyin Liu 
Date: Wed, 21 Jan 2015 11:42:43 -0500
X-OriginalArrivalTime: 21 Jan 2015 16:42:52.0694 (UTC) FILETIME=[4CB4F360:01D03599]
Archived-At: 
Subject: Re: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Jan 2015 16:42:55 -0000

--_d25633f4-46e4-41c2-ad47-359ecf775fca_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"

My argument is that suppose 50% websites support fallback SCSV now=2C 48% w=
ebsites do not support SCSV but are version tolerant=2C and less than 2% ar=
e version intolerant. Is it worth to sacrifice the security of the 48%=2C t=
o make the 2% "just work"?

I also want to point out that disabling RC4 and deprecating SHA-1 certifica=
tes will break some sites as well. Why could browsers afford that=2C but in=
sist on doing downgrade dance?
________________________________
From: Bodo Moeller
Sent: =E2=80=8E1/=E2=80=8E21/=E2=80=8E2015 10:11
To: tls@ietf.org
Cc: Xiaoyin Liu=3B Yoav Nir
Subject: Re: [TLS] Last Call:  (TLS F=
allback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgra=
de Attacks) to Proposed Standard

Yoav Nir :

Also I want to point out that if even as few as 1.6% sites won't upgrade
> their servers=2C can we count on most of the rest 98% supporting SCSV?
>
>
> This is a strong argument=2C especially if we could obtain a list of
> high-value sites in the sense that the data on them is high-value. Sites
> like Facebook=2C banking=2C shops=2C email providers=2C dating sites=2C a=
nd check
> those.
>

I must admit I don't quite understand what the argument here is (sorry)=2C
but in any case let me point out this:

If even just a *single* high-value site that you=2C personally=2C use does
support the SCSV=2C you'll benefit from the SCSV (provided that you're usin=
g
a browser that does a downgrade dance for compatibility with other servers
and sends the SCSV in downgraded Client Hello messages).

Bodo

--_d25633f4-46e4-41c2-ad47-359ecf775fca_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="utf-8"









My a=
rgument is that suppose 50% websites support fallback SCSV now=2C 48% websi=
tes do not support SCSV but are version tolerant=2C and less than 2% are ve=
rsion intolerant. Is it worth to sacrifice the
 security of the 48%=2C to make the 2% "=3Bjust work"=3B?



I also want to point out that disabling RC4 and deprecating SHA-1 certifica=
tes will break some sites as well. Why could browsers afford that=2C but in=
sist on doing downgrade dance?







From:
Bodo Moeller

Sent:
=E2=80=8E1/=E2=80=8E21/=E2=80=8E2015 10:11

To:
tls@ietf.org

Cc:
Xiaoyin Liu=3B
Yoav Nir

Subject:
Re: [TLS] Last Call: <=3Bdraft-ietf-tls-downgrade-scsv-03.txt>=3B =
(TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol D=
owngrade Attacks) to Proposed Standard












Yoav Nir <=3Bynir.ietf@gmail.com>=3B:






















Also I want to point out that =3Bif even as few as 1.6% sites won't upg=
rade their servers=2C =3Bcan we count on =3Bmost of the rest 98% su=
pporting =3BSCSV?












This is a strong argument=2C especially if we could obtain a list of=
 high-value sites in the sense that the data on them is high-value. Sites l=
ike Facebook=2C banking=2C shops=2C email providers=2C dating sites=2C and =
check those. =3B













I must admit I don't quite understand what the argument here is (sorry=
)=2C but in any case let me point out this:







If even just a *single* high-value site =3Bthat you=2C personally=
=2C use does support the SCSV=2C you'll benefit from the SCSV (provided tha=
t you're using a browser that does a downgrade dance for compatibility with=
 other servers and sends the SCSV in downgraded
 Client Hello messages).







Bodo

















--_d25633f4-46e4-41c2-ad47-359ecf775fca_--


From nobody Wed Jan 21 08:46:11 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6A91A1B24 for ; Wed, 21 Jan 2015 08:46:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.066
X-Spam-Level: 
X-Spam-Status: No, score=-1.066 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_64=0.6, 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 K7Rh4SkEr9sY for ; Wed, 21 Jan 2015 08:45:56 -0800 (PST)
Received: from homiemail-a74.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id BDFAF1A1B1E for ; Wed, 21 Jan 2015 08:45:56 -0800 (PST)
Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id 882B267C073; Wed, 21 Jan 2015 08:45:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=LPw/qI+NbFkafO BeYimqSvVeTWQ=; b=y8MOvMQmCUswPF2N7pg2DTkTaWdSvaU0kz5bc4DW/K+w4Y IoFPpZ6nbN3vOQo5s/ZQ4H5B51rdGJO9L5V90kiEXPexJpHP102nflC+D7mOJyDA UFefiXL2/ejeS6ZpVJRt9e9Jn7HqDkQtfCvNb3e7pUiRsrwEcdfmDG+x6OJdQ=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPA id 1CABF67C072; Wed, 21 Jan 2015 08:45:55 -0800 (PST)
Date: Wed, 21 Jan 2015 10:45:49 -0600
From: Nico Williams 
To: "Salz, Rich" 
Message-ID: <20150121164544.GP2350@localhost>
References: <54B5501A.4070402@azet.org> <20150120191819.GA8165@typhoon.azet.org> <6d7dec54c4da410e9a395af0688322df@usma1ex-dag1mb2.msg.corp.akamai.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <6d7dec54c4da410e9a395af0688322df@usma1ex-dag1mb2.msg.corp.akamai.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: 
Cc: TLS Mailing List 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Jan 2015 16:46:00 -0000

On Wed, Jan 21, 2015 at 04:21:38PM +0000, Salz, Rich wrote:
> What does OCB bring to the table that justifies such a huge increase
> (10%) in the number of ciphers.

Cartesian explosion of unrelated things is a problem TLS has that it
doesn't need to have in 1.3.

Key exchange, server authentication, PRF, hash functions, and
cipher+mode, should all be negotiated separately (but cipher and mode
must be negotiated together).  Yes, in some cases key exchange and
server authentication can be very closely tied, e.g., RSA key transport.
SSHv2 gets all of this right; why can't TLS 1.3?

> We need a cipher cage match.  They call go in, and only a couple come
> out.

That seems unrealistic :(

Nico
-- 


From nobody Wed Jan 21 08:50:26 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E664E1A1B24 for ; Wed, 21 Jan 2015 08:50:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.066
X-Spam-Level: 
X-Spam-Status: No, score=-1.066 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_64=0.6, 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 kalCeyTOQn6k for ; Wed, 21 Jan 2015 08:50:20 -0800 (PST)
Received: from homiemail-a87.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2A66B1A1B1E for ; Wed, 21 Jan 2015 08:50:20 -0800 (PST)
Received: from homiemail-a87.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTP id 08B0B26C06F; Wed, 21 Jan 2015 08:50:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=6F6s5WvqUTBYmZ pCnI8wODPWpUc=; b=tpSL6/lMszgYq1bYbHxTqgGixPRqcB/aZ9rBSoZvURYUr+ 1A9WCDdZCQ+fG54/c3pag+P3LuSPlpN9WXhtw7xZ8SF4CFhrK65hNUutM8m2ZvUE VJzBDgPxJgG1lN3B+CkRbmlhEuZshPETI/NhGwmAEqxhoi8K24V6gimsEpJbQ=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTPA id A612726C063; Wed, 21 Jan 2015 08:50:19 -0800 (PST)
Date: Wed, 21 Jan 2015 10:50:13 -0600
From: Nico Williams 
To: Eric Rescorla 
Message-ID: <20150121165008.GQ2350@localhost>
References: <54B5501A.4070402@azet.org> <20150120191819.GA8165@typhoon.azet.org> <20150120193412.GA10140@typhoon.azet.org>  <20150120225335.GA871@typhoon.azet.org>  <20150121004704.GA15203@typhoon.azet.org> <54BFC326.4010302@azet.org> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: 
Cc: TLS Mailing List 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Jan 2015 16:50:21 -0000

On Wed, Jan 21, 2015 at 08:15:45AM -0800, Eric Rescorla wrote:
> On Wed, Jan 21, 2015 at 7:17 AM, Aaron Zauner  wrote:
> > Any comments on the idea of removing the following two ciphersuites from
> > the draft?
> >
> >      CipherSuite TLS_DHE_PSK_WITH_AES_128_OCB = {TBD9, TBD9}
> >      CipherSuite TLS_DHE_PSK_WITH_AES_256_OCB = {TBD10, TBD10}
> >
> > I don't see how these would be relevant to embedded devices.

If DHE_PSK is relevant to an embedded device then all cipher+mode
combinations might be as well.  Obviously OCB wouldn't be required to
implement, but that's no reason to exclude any one subset of ciphersuits
using OCB.

> If we generally think DHE_PSK is a good idea, is there a specific
> reason why it wouldn't be a good idea for OCB?

There isn't.  Embedded devices need not implement the full set of
suites.

But really, this is once more about the gross inefficiency (in terms of
registration as well as number of bytes used on the wire) of cartesian
explosion ciphersuites.  Can we fix this?

Nico
-- 


From nobody Wed Jan 21 08:59:10 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B92021A1B1E for ; Wed, 21 Jan 2015 08:59:04 -0800 (PST)
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,  J_CHICKENPOX_64=0.6, 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 HUXbZcg4uqEN for ; Wed, 21 Jan 2015 08:59:02 -0800 (PST)
Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBD021A1B10 for ; Wed, 21 Jan 2015 08:59:01 -0800 (PST)
Received: by mail-wi0-f169.google.com with SMTP id bs8so34898054wib.0 for ; Wed, 21 Jan 2015 08:59:00 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=0rUFvFaAtZj4AAvZzUFxohsFslzWwsE9AVS6GFjuHh4=; b=Mw+/7rmRvq39ZNSRDXLxcTwgmFNgGyb9zGiKKbmTlV+WiYsRkRauIEIGQFmkQ3wmgE 6wRMiTjTkmv4RnK5OnVczk0kWZs026ZrCJsQrM+BuCJE7QHL86xOks0IVLH6dw4Vqndk n3DQrEhS/r6xyh58ONGainRn4Ro5i9L/Z2TM9jYUGvdbGWia/H7iAne8eXsbGvFjixOf mEMbYGj2aHBNRJov8cS8mPdkAmKyne9Na0C7qJnjOLaBnYgYjyz8/Wox2OY7AUG01DjD btEfkLmEYq6niCjiVm07R3nT6kwyRGN0UVfz7qHb4ZNp5hX7lWtvNO5IdWJtUR9ZGxeA sx+A==
X-Gm-Message-State: ALoCoQmrG+FZgsPs1IFHwrLj1w59I+jp+xkSqySmuabOae4EUxsc2CcMbW3xlIMdd40kkkGNHAIs
X-Received: by 10.180.7.198 with SMTP id l6mr58961521wia.26.1421859540473; Wed, 21 Jan 2015 08:59:00 -0800 (PST)
Received: from [172.16.1.132] ([188.21.236.102]) by mx.google.com with ESMTPSA id gz7sm8004250wib.22.2015.01.21.08.58.58 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 21 Jan 2015 08:58:59 -0800 (PST)
Message-ID: <54BFDAD1.6050403@azet.org>
Date: Wed, 21 Jan 2015 17:58:57 +0100
From: Aaron Zauner 
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: TLS Mailing List 
References: <54B5501A.4070402@azet.org> <20150120191819.GA8165@typhoon.azet.org> <20150120193412.GA10140@typhoon.azet.org>  <20150120225335.GA871@typhoon.azet.org>  <20150121004704.GA15203@typhoon.azet.org> <54BFC326.4010302@azet.org>  <20150121165008.GQ2350@localhost>
In-Reply-To: <20150121165008.GQ2350@localhost>
X-Enigmail-Version: 1.2.3
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigAB2766B570CD8AAAFB620576"
Archived-At: 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Jan 2015 16:59:05 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigAB2766B570CD8AAAFB620576
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

Salz, Rich wrote:
>
> We need a cipher cage match.  They call go in, and only a couple come o=
ut.
>

I'm not opposed to that. And am sure OCB would win over e.g. CCM. Also:
I'm not suggesting OCB mode should be MTI. That's up to the people
currently spec'ing TLS 1.3. GCM based ciphersuites seem like a good idea
to be MTI. e.g. CCM do not.

BTW: Amazed to find out that GOST is still in use (and still mandatory
for russian gov./banking?).

Nico Williams wrote:
> On Wed, Jan 21, 2015 at 08:15:45AM -0800, Eric Rescorla wrote:
>> On Wed, Jan 21, 2015 at 7:17 AM, Aaron Zauner  wrote:
>>> Any comments on the idea of removing the following two ciphersuites f=
rom
>>> the draft?
>>>
>>>      CipherSuite TLS_DHE_PSK_WITH_AES_128_OCB =3D {TBD9, TBD9}
>>>      CipherSuite TLS_DHE_PSK_WITH_AES_256_OCB =3D {TBD10, TBD10}
>>>
>>> I don't see how these would be relevant to embedded devices.
>=20
> If DHE_PSK is relevant to an embedded device then all cipher+mode
> combinations might be as well.  Obviously OCB wouldn't be required to
> implement, but that's no reason to exclude any one subset of ciphersuit=
s
> using OCB.

Well. No. Not really. Why would an embedded device prefer to do DHE over
ECDHE? ECC operations are sure to be more efficient on embedded
devices/IoT. That's was my reason to ask for removal.

>=20
>> If we generally think DHE_PSK is a good idea, is there a specific
>> reason why it wouldn't be a good idea for OCB?
>=20
> There isn't.  Embedded devices need not implement the full set of
> suites.

+1

> But really, this is once more about the gross inefficiency (in terms of=

> registration as well as number of bytes used on the wire) of cartesian
> explosion ciphersuites.  Can we fix this?

What's your suggestion to fixing this? I totally agree that there are
far too many ciphersuites around, which is somewhat ironical because I
just suggested adding 10-12 more. But I'd really like to see and use OCB
mode over CCM in TLS. This is also the reason I'm trying to get rid of
as many unnecessary (or insecure) ciphersuites as possible for OCB.

Aaron


--------------enigAB2766B570CD8AAAFB620576
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUv9rSAAoJEOTbZJL9ubXV5qUQAMbUHTRVL/GD6yUI7KXDIOct
DDgD1lp89lx3OULX4RNC0ASxei4Z2NwCgc2K/IIpiCasac4Au9aes4J2aazg8xGl
9xh8p14Vbu+E9wzC3zlSYRrd8oHswSC72sZJ7sHnPMYz6MDPglXnKZuPgzV7zgsy
kao/iMk8nsgQa9s3syJMLW4hwb+yaEgw0UKL++sqK1ZoGEteN6vk3kBtOTTMHw6U
tOCJEx8FgUKWfrIrusftuQUrPm158z7ALnCKMtrPJhJaAqlGaTPg7TFzQhv6RDxc
bNarbjTWWGpfPL1wVqBBo+he6okFQrouawoKYSe65uPpfKQMldlst60W31Tv9ziY
HMR3JIS+O+ySa73ZVuJ49Qfs0INWJRM4QMSp/FR/32DuTrSybrAM8a2m/6CEY3R8
b6UFtA4N71iKM/kLnbA2GdXNifmVp5QwFh6XOCDRgGY1v6MV0/svmkVcIYb7PSrL
As7zpa90/V4j90uQjkkvDwrhbK16BBNH2xMKk1g/JJ/ufegFNTNdGEl9mu5sHX8I
lEBwu9o9zgdrtQlZDETH1zEpxQugIRE7jFLjxyDj3D6oN5cmplc9nCwL/IfSqbtD
ddZlhiJoJvMyIhnLkfR5y6h3j5mN46Z58Q/ZAeWpitB10DkxRWArG7O7V/08U4J2
LyMQ7ENQL7d0l5LV5IoV
=vUOL
-----END PGP SIGNATURE-----

--------------enigAB2766B570CD8AAAFB620576--


From nobody Wed Jan 21 09:01:58 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 667FA1A1B1E for ; Wed, 21 Jan 2015 09:01:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 al3A9LcoKTki for ; Wed, 21 Jan 2015 09:01:53 -0800 (PST)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0061A1AFA for ; Wed, 21 Jan 2015 09:01:53 -0800 (PST)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 82FFA4762C; Wed, 21 Jan 2015 17:01:52 +0000 (GMT)
Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 75CD347567; Wed, 21 Jan 2015 17:01:52 +0000 (GMT)
Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.34]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 6FF66202A; Wed, 21 Jan 2015 17:01:52 +0000 (GMT)
Received: from USMA1EX-DAG1MB2.msg.corp.akamai.com (172.27.123.102) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 21 Jan 2015 12:01:51 -0500
Received: from USMA1EX-DAG1MB2.msg.corp.akamai.com ([172.27.123.102]) by usma1ex-dag1mb2.msg.corp.akamai.com ([172.27.123.102]) with mapi id 15.00.0913.011; Wed, 21 Jan 2015 12:01:33 -0500
From: "Salz, Rich" 
To: Aaron Zauner , TLS Mailing List 
Thread-Topic: [TLS] Inclusion of OCB mode in TLS 1.3
Thread-Index: AdAvUwVbzm8zizwqTXS0eqroQIbuXQFvL3iAAACN3IAABbMfgAABQ6eAAAF1uYAAAoDAgAAeak0AAAIEoIAAATQogAAAThWAAApolGA=
Date: Wed, 21 Jan 2015 17:01:33 +0000
Message-ID: 
References: <54B5501A.4070402@azet.org> <20150120191819.GA8165@typhoon.azet.org> <20150120193412.GA10140@typhoon.azet.org>  <20150120225335.GA871@typhoon.azet.org>  <20150121004704.GA15203@typhoon.azet.org> <54BFC326.4010302@azet.org>  <20150121165008.GQ2350@localhost> <54BFDAD1.6050403@azet.org>
In-Reply-To: <54BFDAD1.6050403@azet.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.19.41.69]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Jan 2015 17:01:55 -0000

PiBCVFc6IEFtYXplZCB0byBmaW5kIG91dCB0aGF0IEdPU1QgaXMgc3RpbGwgaW4gdXNlIChhbmQg
c3RpbGwgbWFuZGF0b3J5IGZvcg0KPiBydXNzaWFuIGdvdi4vYmFua2luZz8pLg0KDQpTdGlsbCBp
biB1c2UsIGFuZCBhIG5ldyB2ZXJzaW9uIGp1c3QgY2FtZSBvdXQgYW5kIGFuIE9wZW5TU0wgdGlj
a2V0IGZpbGVkIHRvIHN1cHBvcnQgaXQuDQoNClRueCBmb3IgeW91ciBleHBsYW5hdGlvbiBvbiB0
aGUgb3RoZXIgc3R1ZmYuDQoNCg==


From nobody Wed Jan 21 09:09:08 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84AC41A1B28 for ; Wed, 21 Jan 2015 09:09:06 -0800 (PST)
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 WiTCCDnsz19D for ; Wed, 21 Jan 2015 09:09:05 -0800 (PST)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.187]) (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 CD64E1A1AFA for ; Wed, 21 Jan 2015 09:09:04 -0800 (PST)
Received: from mail-la0-f47.google.com ([209.85.215.47]) by mrelayeu.kundenserver.de (mreue003) with ESMTPSA (Nemesis) id 0Mcixh-1YVEXn3W3V-00HwN4 for ; Wed, 21 Jan 2015 18:09:02 +0100
Received: by mail-la0-f47.google.com with SMTP id hz20so8115623lab.6 for ; Wed, 21 Jan 2015 09:09:02 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.112.150.98 with SMTP id uh2mr9295202lbb.92.1421860142147; Wed, 21 Jan 2015 09:09:02 -0800 (PST)
Received: by 10.25.25.145 with HTTP; Wed, 21 Jan 2015 09:09:01 -0800 (PST)
In-Reply-To: 
References: 
Date: Wed, 21 Jan 2015 18:09:01 +0100
Message-ID: 
From: Bodo Moeller 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=047d7b34329cb17357050d2c9c38
X-Provags-ID: V03:K0:BZAz22X4MiA5fSaItW+gcbHLANz7AGzVgjixHDieEGh+iBN2rIJ fJdsAQLTDyVZHqfx3sEin5mwIV6t/HnVJ0AxoZqVrU7AGXwlcrHTZhdLvGPRVzc4BcWGFO9 wbXzIgf/92Ob9CFsEcIaWgmrpHpeatPGb6kWTvOBZGK2r0r07o4qVBa4BUj4hD4GTxeUjfl cirLqagVErBVM6kbN0iyA==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: 
Subject: Re: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Jan 2015 17:09:06 -0000

--047d7b34329cb17357050d2c9c38
Content-Type: text/plain; charset=UTF-8

Xiaoyin Liu :

Also I want to point out that if even as few as 1.6% sites won't upgrade
>>> their servers, can we count on most of the rest 98% supporting SCSV?
>>
>>

> This is a strong argument, especially if we could obtain a list of
>>> high-value sites in the sense that the data on them is high-value. Sites
>>> like Facebook, banking, shops, email providers, dating sites, and check
>>> those.
>>
>>

> I must admit I don't quite understand what the argument here is (sorry),
>> but in any case let me point out this:
>> If even just a *single* high-value site that you, personally, use does
>> support the SCSV, you'll benefit from the SCSV (provided that you're using
>> a browser that
>>
>

> My argument is that suppose 50% websites support fallback SCSV now, 48%
> websites do not support SCSV but are version tolerant, and less than 2% are
> version intolerant. Is it worth to sacrifice the security of the 48%, to
> make the 2% "just work"?


I see, thank you.

draft-ietf-tls-downgrade-scsv-03 doesn't ask that clients do downgrades at
all, it just helps them avoid security pitfalls *if* they choose to.
Historically, many browsers have done this (and still do) and while I'll be
glad if this practice can be stopped, it is still an issue for now (and if
we manage to get rid of it, it might become an issue again).  A couple of
years ago I thought it would go away, but that hasn't happened yet, and
I've seen browsers that initially tried to get along without implementing
the downgrade dance add it.  Even in the yet-to-be-released Firefox version
that disables the downgrade dance by default, there'll still be a
configurable setting for those who think they'll need it -- and the SCSV
will improve their security.


I also want to point out that disabling RC4 and deprecating SHA-1
> certificates will break some sites as well. Why could browsers afford that,
> but insist on doing downgrade dance?


I hope they'll do *all* of this. The point is that the SCSV improves your
security before you have completed such a transition -- or indeed before
you even know about a concrete vulnerability that might convince you to
disable a legacy protocol.

Bodo

--047d7b34329cb17357050d2c9c38
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Xiao=
yin Liu <xiaoyin.l@outlook.com>:

<=
div style=3D"font-size:13px">
Also I want to point out that=C2=A0if even as few as 1=
.6% sites won't upgrade their servers,=C2=A0can we count on=C2=A0most o=
f the rest 98% supporting=C2=A0SCSV?
=

=C2=A0
This is a strong argument, especially if we could obtain a list of high-=
value sites in the sense that the data on them is high-value. Sites like Fa=
cebook, banking, shops, email providers, dating sites, and check those.=C2=
=A0
=C2=A0
I must admit I don't quite=
 understand what the argument here is (sorry), but in any case let me point=
 out this:
If even just a *single* high-value site=C2=A0that you, person=
ally, use does support the SCSV, you'll benefit from the SCSV (provided=
 that you're using a browser that=C2=A0
=

=C2=A0<=
/div>
My argument is that suppose 50% websites support fallback SCSV now=
, 48% websites do not support SCSV but are version tolerant, and less than =
2% are version intolerant. Is it worth to sacrifice the
 security of the 48%, to make the 2% "just work"?

I see, thank you.

draft-ie=
tf-tls-downgrade-scsv-03 doesn't ask that clients do downgrades at all,=
 it just helps them avoid security pitfalls *if* they choose to.=C2=A0 Hist=
orically, many browsers have done this (and still do) and while I'll be=
 glad if this practice can be stopped, it is still an issue for now (and if=
 we manage to get rid of it, it might become an issue again).=C2=A0 A coupl=
e of years ago I thought it would go away, but that hasn't happened yet=
, and I've seen browsers that initially tried to get along without impl=
ementing the downgrade dance add it.=C2=A0 Even in the yet-to-be-released F=
irefox version that disables the downgrade dance by default, there'll s=
till be a configurable setting for those who think they'll need it -- a=
nd the SCSV will improve their security.


I also =
want to point out that disabling RC4 and deprecating SHA-1 certificates wil=
l break some sites as well. Why could browsers afford that, but insist on d=
oing downgrade dance?

I hope they=
9;ll do *all* of this. The point is that the SCSV improves your security be=
fore you have completed such a transition -- or indeed before you even know=
 about a concrete vulnerability that might convince you to disable a legacy=
 protocol.

Bodo



--047d7b34329cb17357050d2c9c38--


From nobody Wed Jan 21 09:09:40 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A31B1A1B34 for ; Wed, 21 Jan 2015 09:09:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.066
X-Spam-Level: 
X-Spam-Status: No, score=-1.066 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_64=0.6, 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 qO-19xa7YVYv for ; Wed, 21 Jan 2015 09:09:34 -0800 (PST)
Received: from homiemail-a72.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id B29E51A1B2F for ; Wed, 21 Jan 2015 09:09:33 -0800 (PST)
Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 72EF26B007B; Wed, 21 Jan 2015 09:09:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=yeVpwFpC7Tf7/P tBjNp0VSBYUa8=; b=eqwsUFeN/7pNMwADas/GplVcsgZ0LeKoS5MWqWOzH4E3+e KBoyJp9iRN6wMGQmJQPZMQj3K5MMuo7AlmItQma9KQAGgtk8UuVjS9VdszyhO+ks OpFSkP6l3q8fHgCGh/u949jwEYCCWaj3BFNDbUujGDN5NDM0Q8/i7vEgvtPps=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPA id 2B8296B0059; Wed, 21 Jan 2015 09:09:33 -0800 (PST)
Date: Wed, 21 Jan 2015 11:09:26 -0600
From: Nico Williams 
To: Aaron Zauner 
Message-ID: <20150121170922.GS2350@localhost>
References: <20150120191819.GA8165@typhoon.azet.org> <20150120193412.GA10140@typhoon.azet.org>  <20150120225335.GA871@typhoon.azet.org>  <20150121004704.GA15203@typhoon.azet.org> <54BFC326.4010302@azet.org>  <20150121165008.GQ2350@localhost> <54BFDAD1.6050403@azet.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <54BFDAD1.6050403@azet.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: 
Cc: TLS Mailing List 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Jan 2015 17:09:35 -0000

On Wed, Jan 21, 2015 at 05:58:57PM +0100, Aaron Zauner wrote:
> 
> Nico Williams wrote:
> > On Wed, Jan 21, 2015 at 08:15:45AM -0800, Eric Rescorla wrote:
> >> On Wed, Jan 21, 2015 at 7:17 AM, Aaron Zauner  wrote:
> >>> Any comments on the idea of removing the following two ciphersuites from
> >>> the draft?
> >>>
> >>>      CipherSuite TLS_DHE_PSK_WITH_AES_128_OCB = {TBD9, TBD9}
> >>>      CipherSuite TLS_DHE_PSK_WITH_AES_256_OCB = {TBD10, TBD10}
> >>>
> >>> I don't see how these would be relevant to embedded devices.
> > 
> > If DHE_PSK is relevant to an embedded device then all cipher+mode
> > combinations might be as well.  Obviously OCB wouldn't be required to
> > implement, but that's no reason to exclude any one subset of ciphersuits
> > using OCB.
> 
> Well. No. Not really. Why would an embedded device prefer to do DHE over
> ECDHE? ECC operations are sure to be more efficient on embedded
> devices/IoT. That's was my reason to ask for removal.

Sure, but why not just deprecate/remove non-ECDH ciphersuites and be done?

> > But really, this is once more about the gross inefficiency (in terms of
> > registration as well as number of bytes used on the wire) of cartesian
> > explosion ciphersuites.  Can we fix this?
> 
> What's your suggestion to fixing this? [...]

Negotiate key exchange, server authentication, PRF, hash, and
cipher+mode separately.  (Cipher and mode go together, as not every mode
makes sense for every cipher, but key exchange should have no relation
to the choice of cipher+mode.)  Key exchange and server authentication
are closely tied in some cases (e.g., RSA key transport), but that's not
a problem (SSHv2 managed).

Nico
-- 


From nobody Wed Jan 21 09:14:12 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2D211A1B24 for ; Wed, 21 Jan 2015 09:14:10 -0800 (PST)
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 4VtUwqzLzMZc for ; Wed, 21 Jan 2015 09:14:08 -0800 (PST)
Received: from mail-yh0-x22d.google.com (mail-yh0-x22d.google.com [IPv6:2607:f8b0:4002:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB2EB1A1AFA for ; Wed, 21 Jan 2015 09:14:08 -0800 (PST)
Received: by mail-yh0-f45.google.com with SMTP id f73so2018847yha.4 for ; Wed, 21 Jan 2015 09:14:07 -0800 (PST)
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=ujQMAAiztqkCcQilGnTyJH0CqiIDtuu4Ofwek6Dbuh8=; b=MTVQP71McW64jeW3XjMj8ZSgU5eXX4Z8jeY4lNCBts5S5R882WRlLbTw6CoJcVmE1m 9GpXWUYes9GskfTNLdSIdd5DQO/NIm2QY0lwgnYwaN1nwDksoM7SlgYc5ZOQu8Rx/+vw rpY7ZnV57BFzt77l5oKqqjLV99XHy3IiwjbnmRrrUzjI8BeOmkOG/EvzTnJuHN0kUNxy yXxcFJp4hC78NormC6dBjKL2+aPnfckwOY8GKg7xk5/JyqsRyIs+I/92PKlgYWjY3afT o78lx/y4EZQB543BQ1PvqdZcl4DgCO8I8pyv0U2YA0e67k/uk9C0o/QmEF+257eVtX4v BfPA==
MIME-Version: 1.0
X-Received: by 10.236.202.233 with SMTP id d69mr24360757yho.22.1421860447856;  Wed, 21 Jan 2015 09:14:07 -0800 (PST)
Received: by 10.170.134.66 with HTTP; Wed, 21 Jan 2015 09:14:07 -0800 (PST)
In-Reply-To: <54BFDAD1.6050403@azet.org>
References: <54B5501A.4070402@azet.org> <20150120191819.GA8165@typhoon.azet.org> <20150120193412.GA10140@typhoon.azet.org>  <20150120225335.GA871@typhoon.azet.org>  <20150121004704.GA15203@typhoon.azet.org> <54BFC326.4010302@azet.org>  <20150121165008.GQ2350@localhost> <54BFDAD1.6050403@azet.org>
Date: Wed, 21 Jan 2015 20:14:07 +0300
Message-ID: 
From: Dmitry Belyavsky 
To: Aaron Zauner 
Content-Type: multipart/alternative; boundary=089e01538856ea30e1050d2caead
Archived-At: 
Cc: TLS Mailing List 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Jan 2015 17:14:11 -0000

--089e01538856ea30e1050d2caead
Content-Type: text/plain; charset=UTF-8

Helo all,


On Wed, Jan 21, 2015 at 7:58 PM, Aaron Zauner  wrote:

>
> BTW: Amazed to find out that GOST is still in use (and still mandatory
> for russian gov./banking?).
>

Yes, it's still in use. And new algorithms appeared in 2012.


>
>

-- 
SY, Dmitry Belyavsky

--089e01538856ea30e1050d2caead
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Helo all,


On Wed, Jan 21, 2015 at 7:58 PM, Aaron Zauner <azet@azet.org> wrote:


BTW: Amazed to find out that GOST is still in use (and still mandatory

for russian gov./banking?).

Yes, it'=
;s still in use. And new algorithms appeared in 2012.
=C2=A0



-- 
SY, Dmitry Belyavsky



--089e01538856ea30e1050d2caead--


From nobody Wed Jan 21 09:20:37 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB891A1B37 for ; Wed, 21 Jan 2015 09:20:23 -0800 (PST)
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,  J_CHICKENPOX_64=0.6, 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 4pEveqCHF21u for ; Wed, 21 Jan 2015 09:20:20 -0800 (PST)
Received: from mail-we0-f174.google.com (mail-we0-f174.google.com [74.125.82.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50A441A1B2F for ; Wed, 21 Jan 2015 09:20:20 -0800 (PST)
Received: by mail-we0-f174.google.com with SMTP id x3so10844366wes.5 for ; Wed, 21 Jan 2015 09:20:19 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=whB88E2uWbQ/7MEZS+GlyLuONsc7+NQL77pJ4hKz0vw=; b=lBRqQCZpNWpohUGcvPf1tvObJZbxkrSjxBlkFGWEaYGw3XKna7gjqq++CXd5qeyEy/ pobeDQ9VcBDoUOg3QbMwM7SJeKdNQ4gwhGORLuPAA6dP8m4n35OeDd/Z75VtHM3+2HmZ LfRLOwEE609oieOzeUI5KdNUi4JHTNaEE1NqljFU6ibHWuv7NMh3RFl4v/3hUfpZ+91c pVU0PSHcrpgkCOBIZ6E/wKSJyVLBa3XIIYY4gbE0yDo8gs5woIJiVGdRD0EUovSyBBVj 1/vvhhKw8Ay52i1oLo7aQC/c+P+CUPeBHP5ytDVqVbgsE4DQQZoyqqX884ULSaYs1Juf ihEA==
X-Gm-Message-State: ALoCoQmmgbM2W6mnFAzPS+LaAttEuXhW+NxuiLo+qtpQWGwmpgKIbLD2z81Qon9sZInPYYM98VVA
X-Received: by 10.180.74.147 with SMTP id t19mr21885276wiv.6.1421860819086; Wed, 21 Jan 2015 09:20:19 -0800 (PST)
Received: from [172.16.1.132] ([188.21.236.102]) by mx.google.com with ESMTPSA id cx3sm8099170wib.10.2015.01.21.09.20.17 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 21 Jan 2015 09:20:18 -0800 (PST)
Message-ID: <54BFDFD0.2050801@azet.org>
Date: Wed, 21 Jan 2015 18:20:16 +0100
From: Aaron Zauner 
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: Nico Williams 
References: <20150120191819.GA8165@typhoon.azet.org> <20150120193412.GA10140@typhoon.azet.org>  <20150120225335.GA871@typhoon.azet.org>  <20150121004704.GA15203@typhoon.azet.org> <54BFC326.4010302@azet.org>  <20150121165008.GQ2350@localhost> <54BFDAD1.6050403@azet.org> <20150121170922.GS2350@localhost>
In-Reply-To: <20150121170922.GS2350@localhost>
X-Enigmail-Version: 1.2.3
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigE3D86AC9621E8A98A8FA3001"
Archived-At: 
Cc: TLS Mailing List 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Jan 2015 17:20:23 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigE3D86AC9621E8A98A8FA3001
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



Nico Williams wrote:
> Sure, but why not just deprecate/remove non-ECDH ciphersuites and be do=
ne?

That'd be the best option, I agree. But Nikos pointed out that people
might still want PSK without diffie-hellman at all for confined
environments/embedded. Otherwise I wouldn't have put it in there in the
first place. I'm happy to remove these ciphersuites if there's consensus.=



> Negotiate key exchange, server authentication, PRF, hash, and
> cipher+mode separately.  (Cipher and mode go together, as not every mod=
e
> makes sense for every cipher, but key exchange should have no relation
> to the choice of cipher+mode.)  Key exchange and server authentication
> are closely tied in some cases (e.g., RSA key transport), but that's no=
t
> a problem (SSHv2 managed).

Sounds like a plan. But more like something for the TLS spec than this
ID, right?

RSA as key transport doesn't concern this ID anyway. And AFAIK it's
going deprecated with TLS 1.3 because of security concerns. I've even
explicitly stated it in the security considerations section of my ID.

Aaron


--------------enigE3D86AC9621E8A98A8FA3001
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUv9/RAAoJEOTbZJL9ubXV6owP/jU1DStTXO5mOaJbtvFj3TUY
WkJal7/UueWuhvv4h7ykfdWEIqPCot4rPtguo4/bJHYRixtczv4jvUzVXgnG5Jt4
dqOXfBBWcoqvSbib60jzaefDn7T/cC1pjHQAzAM2qElmIdSCnlwVFVq8mKZF9laz
QVp4FlRj6qMBA1RFDGewJux7aJ/LtlDd2DXxD2j1dpdTRlzZQQ9CyaHkPOMs5zix
hVRV34OlpN2FcSRDcDEUUBXKTAtIN8R2NOOsMG/YvMmhIDwkVTp6iHih8QY/bKlc
r6rWJ6Jl58EJogt3teL/OOEc1IGhwDvhvYDhhx+U7KX8i/BR0e5oO+jrFbHMMqPe
Dik8J6Wkxd6ToEOgx2ESLVTFyAeh0W2OvPLpfbC4nTYOVtc77lSsOJQf55G2juBE
1z0efo9Srd9KbJRVx7u3vH/Kf1UTJ1Ul4mz38y3+6t4apwasszuhNlBobGBM9qG+
VRo554bciCed3RTvAf75FrmQ361/dBMQ6sgLu9v911CBtYKuy3HodI6CD9XSOrNC
Qh9baFT3/lTiWf9uT/YpSaHRODeNccxWLMxRD88YVsf1eEVDT0pZ699h5Mkgnt9W
ty0IHpVvKCROGGFjuF8tJspFK5g/yBQPcnO+NpBp2fOFSYFNfakmfOYwB3ifOTzw
KmSNEO0geetuHh8Z5F9/
=Esdk
-----END PGP SIGNATURE-----

--------------enigE3D86AC9621E8A98A8FA3001--


From nobody Wed Jan 21 14:27:54 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 771E81A8979 for ; Wed, 21 Jan 2015 14:27:51 -0800 (PST)
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, 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 c6oUOHq6OS4F for ; Wed, 21 Jan 2015 14:27:50 -0800 (PST)
Received: from maple.randombit.net (maple.randombit.net [66.228.45.112]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6B7C1A0047 for ; Wed, 21 Jan 2015 14:27:48 -0800 (PST)
Received: by maple.randombit.net (Postfix, from userid 1000) id 2A0F01ADB07; Wed, 21 Jan 2015 17:27:48 -0500 (EST)
Date: Wed, 21 Jan 2015 17:27:48 -0500
From: Jack Lloyd 
To: tls@ietf.org
Message-ID: <20150121222748.GA30732@randombit.net>
Mail-Followup-To: tls@ietf.org
References: <54B5501A.4070402@azet.org> <20150120191819.GA8165@typhoon.azet.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20150120191819.GA8165@typhoon.azet.org>
X-PGP-Fingerprint: 3F69 2E64 6D92 3BBE E7AE 9258 5C0F 96E8 4EC1 6D6B
X-PGP-Key: http://www.randombit.net/pgpkey.html
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Jan 2015 22:27:51 -0000

On Tue, Jan 20, 2015 at 08:18:21PM +0100, Aaron Zauner wrote:
> Hi TLS-WG,
> 
> The Internet Draft can be found over here:
> https://datatracker.ietf.org/doc/draft-zauner-tls-aes-ocb/

My initial understanding on reading the draft was that in the nonce construction
the sequence number is implicit (or already explicit in the message in the case
of DTLS), and the record_iv_length of these ciphersuites is zero. However it
then refers to RFC 5288 (the GCM ciphersuite definition), which includes an
explicit 8 byte nonce in each message. Or is this reference purely with regards
to the formatting of the nonce input to the AEAD algorithm? Even just an
additional statement "The record_iv_length is X." should resolve this.

If anyone is interested in interop testing, I have implemented these ciphersuites
(assuming record_iv_length is 0) for the next release of botan (available via
https://github.com/randombit/botan) using ids in the private use range.

Cheers,
  Jack


From nobody Wed Jan 21 15:58:18 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF801A1A81 for ; Wed, 21 Jan 2015 15:58:16 -0800 (PST)
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 gnc81QwV3gqc for ; Wed, 21 Jan 2015 15:58:14 -0800 (PST)
Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1010B1A00A2 for ; Wed, 21 Jan 2015 15:58:14 -0800 (PST)
Received: by mail-wg0-f48.google.com with SMTP id x12so14257112wgg.7 for ; Wed, 21 Jan 2015 15:58:12 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=xwm5QYW7jQJrfgJ9I8EUOeAEONoupFXUSGE5D8m+jhE=; b=mR6ssAK12BGQjStPaikUax0s8PAxBbzGrwwAolrOv8YKSqMfS3Jlxp1DEOS9t9w0CY 1JiayDUCIkJhBTz3oiOMHBrfwDYi0s0QP87e2I1Q5Kbdxxl7bMG8fo9ONHTt8lfpc+Oy 3MuBUzCxNn4GnDmjIrsuuubaeSZ9HzGm60xDytmoOkUP93DXWH1FFT/vl0RdXRtJj0c3 eQuR0cjpm+P4R+z90CnaG7Y3RqGrAq8rT10XOrFbKtebAVGCsxg+cERrJDqla5/801PI WRBgrgzNU9S4BN+3b+z5gVTi/vvHpUlF1RQuRDPnpnZU1AlZZ4gbIKQtClBurFKRrDBh sahQ==
X-Gm-Message-State: ALoCoQmwAHhILvvI6pod+7inbDQxxXMlp68D5dMjsnyEyqoRBn557lz2LyipV3aNAw230UDdK8yD
X-Received: by 10.180.83.129 with SMTP id q1mr61134632wiy.8.1421884692878; Wed, 21 Jan 2015 15:58:12 -0800 (PST)
Received: from [10.0.0.142] (chello080108032135.14.11.univie.teleweb.at. [80.108.32.135]) by mx.google.com with ESMTPSA id h8sm826197wiy.4.2015.01.21.15.58.11 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 21 Jan 2015 15:58:12 -0800 (PST)
Message-ID: <54C03D10.1090201@azet.org>
Date: Thu, 22 Jan 2015 00:58:08 +0100
From: Aaron Zauner 
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: tls@ietf.org
References: <54B5501A.4070402@azet.org> <20150120191819.GA8165@typhoon.azet.org> <20150121222748.GA30732@randombit.net>
In-Reply-To: <20150121222748.GA30732@randombit.net>
X-Enigmail-Version: 1.2.3
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig7A87DE4079E037B6ACE5FBC3"
Archived-At: 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Jan 2015 23:58:16 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig7A87DE4079E037B6ACE5FBC3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Jack,

Jack Lloyd wrote:
> My initial understanding on reading the draft was that in the nonce con=
struction
> the sequence number is implicit (or already explicit in the message in =
the case
> of DTLS), and the record_iv_length of these ciphersuites is zero. Howev=
er it
> then refers to RFC 5288 (the GCM ciphersuite definition), which include=
s an
> explicit 8 byte nonce in each message.=20

Good catch!

> Or is this reference purely with regards to the formatting of the nonce=
 input to the AEAD algorithm?=20

Yes.

> Even just an additional statement "The record_iv_length is X." should r=
esolve this.

I'm in the process of editing the draft and will add this information to
it. Do you want to suggest a paragraph/sentence or do you think this
will suffice for implementors?

> If anyone is interested in interop testing, I have implemented these ci=
phersuites
> (assuming record_iv_length is 0) for the next release of botan (availab=
le via
> https://github.com/randombit/botan) using ids in the private use range.=


Nice. I always liked Botan (I knew it supported OCB - Sorry for failing
to mention you guys in my initial message), thanks for being so quick to
adapt your codebase to my ID!

(OT: I'd really like to see usable Python bindings for Botan.)

Aaron


--------------enig7A87DE4079E037B6ACE5FBC3
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUwD0QAAoJEOTbZJL9ubXVwMYP/RuJkLZ3knHj9WbpNeeubpsB
FojPjclMMQ/dQYrn360VjuD8ODDYpQIhzdxvtjYQBXHqxrEkFtBiWzqY86EEYJze
/3l7nHiYZJBKI4pb8h0t49bwrcJPQhkX2I6Ha7/dwxCnUECWkiWhImD4eiO52X2F
l4vguSP+uX59JpsQ7phh7NRa6ZR5vwWBhL1zYbkj3qk402af0YKHCt8LE3g38EdQ
d3GssEqr2JNuDYi3VHHVGxnwOPYsdKHtPsQ8lMYkDti8/1My45dbGO8JtZtlGGQB
pMJwzf04ZVly0SgQYJeQN1FfqIJNCIQvX64vADu43AM6Pu360o75GDl91vM0So0R
tu9e+VCxa6JDpK5pyLS3zxoQl/PGjDKVDsXhcI200KBmTGkXsQoVo5W1MtgX9CDH
JdepBKurLcYHIozErfRwcC3MueXeWbSeuOA/t43zNUb8VVqTRQeyGfqF7inp/yF3
3x9eQxcH+43b80pQVM/qdHYRgBaRfdmJ/WrHHrFYWXM9lXWcNKEt9hPpRXpI/NEt
fjCSr3EI5/4c6X2jfFidhQZ9L14eRrw+mgacvN/7FXvzPZtXGnlv9Bfufp+82mPB
RbzMTbxN9zmFb3hytxZMnKfkU/8QaBX2boehQVKavXPZ/x0/KsOiPBb+nVVqk6YK
R2elDYq5d1FNcUMQuFiM
=QUtS
-----END PGP SIGNATURE-----

--------------enig7A87DE4079E037B6ACE5FBC3--


From nobody Wed Jan 21 16:45:38 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5291F1A8AE9; Wed, 21 Jan 2015 16:45:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.802
X-Spam-Level: 
X-Spam-Status: No, score=-0.802 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 r5clq54hq6ls; Wed, 21 Jan 2015 16:45:36 -0800 (PST)
Received: from sasl.smtp.pobox.com (pb-sasl1.int.icgroup.com [208.72.237.25]) by ietfa.amsl.com (Postfix) with ESMTP id 2BBEB1A8AE5; Wed, 21 Jan 2015 16:45:34 -0800 (PST)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-sasl1.pobox.com (Postfix) with ESMTP id 4E4BC3131A; Wed, 21 Jan 2015 19:45:33 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=0RpDcG/OGRdU /6eZuQFvH49QHuM=; b=DK3TBpwSH3Hd8v5it3wwNmI2mMIUUaKWS59bObcrFdIi FPiT8pxVkrzFNmPwigR+MHY3XiyHqrkThBiBZkRbtC38e3jySYXpAXcDUWiCU3q9 Eic0NcK6nbRV6LoLBWlRCJwS52tysjNX/G6qt3R/st3v/Vup+un9XoITjH3gEKI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=K/kWdc DDt1sfFgmUG3Q73tEL3JtlbF8mOwlzZYDE2HI5pFItZxEgC91rvP/ldcps4fzxxs COqLIgUdXKbT+avq5gXe/acJ+qs49RZ7d/l7OrvJQlMnDBrbjbf132/ravvwvjhr Sp1hhHvMDVE3FF4Fii0zJWj1ezUw49hAhKm7A=
Received: from pb-sasl1.int.icgroup.com (unknown [127.0.0.1]) by pb-sasl1.pobox.com (Postfix) with ESMTP id 44ED231319; Wed, 21 Jan 2015 19:45:33 -0500 (EST)
Received: from iMac.local (unknown [24.234.153.62]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pb-sasl1.pobox.com (Postfix) with ESMTPSA id 9B09131318; Wed, 21 Jan 2015 19:45:32 -0500 (EST)
Message-ID: <54C0482B.8010607@pobox.com>
Date: Wed, 21 Jan 2015 16:45:31 -0800
From: Michael D'Errico 
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: mrex@sap.com
References: <20150117045700.2E3801B0FA@ld9781.wdf.sap.corp>
In-Reply-To: <20150117045700.2E3801B0FA@ld9781.wdf.sap.corp>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: F898E7AC-A1CF-11E4-BC6B-B05EFC961345-38729857!pb-sasl1.pobox.com
Archived-At: 
Cc: ietf@ietf.org, "tls@ietf.org" 
Subject: Re: [TLS] Last Call: 
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Jan 2015 00:45:37 -0000

Martin Rex wrote:
> Rubber-Stamping the fallback-scsv hack onto the standards track is
> IMHO a very bad idea.

I apologize if this has been discussed before (I have about 1400
unread TLS mailing list messages in my queue), but it seems that
a simpler SCSV or extension could just ask the server to echo its
highest supported version:

     ClientHello w/SCSV    ----->
                           <-----    ServerHello w/version extension

Servers wouldn't have to change any logic or close the connection,
the client would make that call.

Mike


From nobody Wed Jan 21 18:06:56 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 055511A00D1 for ; Wed, 21 Jan 2015 18:06:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Level: 
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 be6rY8otjxGw for ; Wed, 21 Jan 2015 18:06:48 -0800 (PST)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C69A31A00DC for ; Wed, 21 Jan 2015 18:06:27 -0800 (PST)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 9674F3A318; Thu, 22 Jan 2015 03:06:25 +0100 (CET)
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 481B542828; Thu, 22 Jan 2015 03:06:25 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 3CCCB1B10F; Thu, 22 Jan 2015 03:06:25 +0100 (CET)
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAF5D521@uxcn10-tdc05.UoA.auckland.ac.nz>
To: Peter Gutmann 
Date: Thu, 22 Jan 2015 03:06:25 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20150122020625.3CCCB1B10F@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: 
Cc: "" 
Subject: Re: [TLS] Using RSA PSS in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Jan 2015 02:06:50 -0000

Peter Gutmann wrote:
>  writes:
> 
>>Appparently [1] NSS and BoringSSL has been doing that for a few months now
>>(though NSS seems to take steps to allow some variation), maybe they could
>>provide some feedback?
>>
>>[1]: https://www.imperialviolet.org/2014/09/26/pkcs1.html
> 
> I've been doing this for ages, and I believe OpenSSL does as well(?).  Never
> had any problems (or at least none reported) so far...

Btw. TLSv1.2 explicitly requires support for a slight variation
(NULL and absent parameters) on the TLSv1.2 RSA PKCS#1 v1.5
digitally-signed signature verification, see rfc5246,
section 4.7 3rd paragraph:

  https://tools.ietf.org/html/rfc5246#section-4.7

   In RSA signing, the opaque vector contains the signature generated
   using the RSASSA-PKCS1-v1_5 signature scheme defined in [PKCS1].  As
   discussed in [PKCS1], the DigestInfo MUST be DER-encoded [X680]
   [X690].  For hash algorithms without parameters (which includes
   SHA-1), the DigestInfo.AlgorithmIdentifier.parameters field MUST be
   NULL, but implementations MUST accept both without parameters and
   with NULL parameters.  Note that earlier versions of TLS used a
   different RSA signature scheme that did not include a DigestInfo
   encoding.


-Martin


From nobody Wed Jan 21 19:33:18 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A07B1A9145 for ; Wed, 21 Jan 2015 19:33:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Level: 
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 fI9F50-SW3vx for ; Wed, 21 Jan 2015 19:33:15 -0800 (PST)
Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B864C1A9141 for ; Wed, 21 Jan 2015 19:33:15 -0800 (PST)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id E61F33A349; Thu, 22 Jan 2015 04:33:12 +0100 (CET)
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id D70E842894; Thu, 22 Jan 2015 04:33:12 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id CD05A1B110; Thu, 22 Jan 2015 04:33:12 +0100 (CET)
In-Reply-To: 
To: "Salz, Rich" 
Date: Thu, 22 Jan 2015 04:33:12 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20150122033312.CD05A1B110@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: 
Cc: TLS Mailing List 
Subject: [TLS] GOST in TLS (Re:  Inclusion of OCB mode in TLS 1.3)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Jan 2015 03:33:17 -0000

Salz, Rich wrote:
>
>> BTW: Amazed to find out that GOST is still in use (and still mandatory for
>> russian gov./banking?).
> 
> Still in use, and a new version just came out and an OpenSSL ticket filed
> to support it.

The closest thing to a public specification is a long expired I-D:

  https://tools.ietf.org/html/draft-chudov-cryptopro-cptls-04

with essentially one TLS cipher suite TLS_GOSTR341001_WITH_28147_CNT_IMIT
that uses an officially deprecated/retired algorithm (R 34.10-2001)
and lacks the code point assignments that would be necessary for use
with TLSv1.2.


Googling just now, I found what might be a potential spec update:

https://www.cryptopro.ru/sites/default/files/products/csp/rus-popov-tls-gost-00-rf.pdf

but I don't understand russian.

The TLS parameters code point assignments in the new document seem to
be from the private use areas (cptls-04 had kidnapped the cipher suite ids).

-Martin


From nobody Wed Jan 21 21:20:19 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A11401A1A3D for ; Wed, 21 Jan 2015 21:20:14 -0800 (PST)
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 KW-iIot9cPRi for ; Wed, 21 Jan 2015 21:20:10 -0800 (PST)
Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB1B01A1A56 for ; Wed, 21 Jan 2015 21:20:09 -0800 (PST)
Received: by mail-yk0-f170.google.com with SMTP id q9so740837ykb.1 for ; Wed, 21 Jan 2015 21:20:09 -0800 (PST)
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=4AI81zRRWceXlMEdqDc2kLCmLLOnXj3y0yQMg9ZJIVs=; b=M0qIybfVOlwylqr5PkxNx5HhdWH/vxOppeKdv/1Ve68XoSnd8T0aFeOuOIq3Nt7f5k vMB2iupFwRT5/IPx/5bM/cHPeQ20IFLDoKNzwPHJgkoZ5LopkZR82S1Yv7g/Od5a8DyJ cRwYCIamMtEl9Uf785nSq8rtJOhi8+xom6RVRKcphX+yC+7niblwfBqeWwSmsMmwo0Nu n8Nk/dkm+MXuyGB25ahwVsvN/S73vXBfSzTiJHvefyLynpRoMi52gvdMHnwlEEjfiSZG Hgw0aKJPdk0SpMxNzr/j/QYDQeddmekqNmLbgF+IlDRetR1e9r+StGiohofFg9+h/mHG Ja/Q==
MIME-Version: 1.0
X-Received: by 10.170.187.213 with SMTP id d204mr3660903yke.99.1421904009115;  Wed, 21 Jan 2015 21:20:09 -0800 (PST)
Received: by 10.170.134.66 with HTTP; Wed, 21 Jan 2015 21:20:09 -0800 (PST)
In-Reply-To: <20150122033312.CD05A1B110@ld9781.wdf.sap.corp>
References:  <20150122033312.CD05A1B110@ld9781.wdf.sap.corp>
Date: Thu, 22 Jan 2015 08:20:09 +0300
Message-ID: 
From: Dmitry Belyavsky 
To: mrex@sap.com
Content-Type: multipart/alternative; boundary=001a1139f2b25e4416050d36d3ff
Archived-At: 
Cc: TLS Mailing List 
Subject: Re: [TLS] GOST in TLS (Re: Inclusion of OCB mode in TLS 1.3)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Jan 2015 05:20:14 -0000

--001a1139f2b25e4416050d36d3ff
Content-Type: text/plain; charset=UTF-8

Hello Martin,

On Thu, Jan 22, 2015 at 6:33 AM, Martin Rex  wrote:

> Salz, Rich wrote:
> >
> >> BTW: Amazed to find out that GOST is still in use (and still mandatory
> for
> >> russian gov./banking?).
> >
> > Still in use, and a new version just came out and an OpenSSL ticket filed
> > to support it.
>
> The closest thing to a public specification is a long expired I-D:
>
>   https://tools.ietf.org/html/draft-chudov-cryptopro-cptls-04
>
> with essentially one TLS cipher suite TLS_GOSTR341001_WITH_28147_CNT_IMIT
> that uses an officially deprecated/retired algorithm (R 34.10-2001)
> and lacks the code point assignments that would be necessary for use
> with TLSv1.2.
>
>
> Googling just now, I found what might be a potential spec update:
>
>
> https://www.cryptopro.ru/sites/default/files/products/csp/rus-popov-tls-gost-00-rf.pdf
>
> but I don't understand russian.
>
> The TLS parameters code point assignments in the new document seem to
> be from the private use areas (cptls-04 had kidnapped the cipher suite
> ids).
>
>
Yes, it's a new specification updated for using new GOST signature and
digest alorithms. It does not take into account TLS 1.3 specification at
all.
The R 34.10-2001 algorithm is not deprecated yet but will be deprecate soon.


-- 
SY, Dmitry Belyavsky

--001a1139f2b25e4416050d36d3ff
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hello Martin,=C2=A0

On Thu, Jan 22, 2015 at 6:33 AM, Martin Rex <mrex@sap.com> wrote:
Salz, Rich wrote:

>

>> BTW: Amazed to find out that GOST is still in use (and still manda=
tory for

>> russian gov./banking?).

>

> Still in use, and a new version just came out and an OpenSSL ticket fi=
led

> to support it.



The closest thing to a public specification is a long expired I-D:



=C2=A0 https://tools.ietf.org/html/draft-chudov-cryptopro-cp=
tls-04



with essentially one TLS cipher suite TLS_GOSTR341001_WITH_28147_CNT_IMIT
that uses an officially deprecated/retired algorithm (R 34.10-2001)

and lacks the code point assignments that would be necessary for use

with TLSv1.2.





Googling just now, I found what might be a potential spec update:



https://www.cryptopro.ru/sites/de=
fault/files/products/csp/rus-popov-tls-gost-00-rf.pdf



but I don't understand russian.



The TLS parameters code point assignments in the new document seem to

be from the private use areas (cptls-04 had kidnapped the cipher suite ids)=
.


=C2=A0
Yes, it's a new specification up=
dated for using new GOST signature and digest alorithms. It does not take i=
nto account TLS 1.3 specification at all.
The R 34.10-2001 algori=
thm is not deprecated yet but will be deprecate soon.


-- 
SY, Dmitry Be=
lyavsky




--001a1139f2b25e4416050d36d3ff--


From nobody Wed Jan 21 22:11:42 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7541AC419 for ; Wed, 21 Jan 2015 22:11:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.151
X-Spam-Level: 
X-Spam-Status: No, score=-5.151 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 C2tFfdMI7fXD for ; Wed, 21 Jan 2015 22:11:35 -0800 (PST)
Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9FEB1AC416 for ; Wed, 21 Jan 2015 22:11:34 -0800 (PST)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id B1EEC3A31D; Thu, 22 Jan 2015 07:11:32 +0100 (CET)
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id A9CAF4281D; Thu, 22 Jan 2015 07:11:32 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id A0E441B111; Thu, 22 Jan 2015 07:11:32 +0100 (CET)
In-Reply-To: 
To: Bodo Moeller 
Date: Thu, 22 Jan 2015 07:11:32 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20150122061132.A0E441B111@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Jan 2015 06:11:37 -0000

Bodo Moeller wrote:
> 
> If even just a *single* high-value site that you, personally, use does
> support the SCSV, you'll benefit from the SCSV (provided that you're using
> a browser that does a downgrade dance for compatibility with other servers
> and sends the SCSV in downgraded Client Hello messages).


I've been looking long and hard, but I'm having difficulties
to see a noticable benefit.   OK, a Poodle demonstration of the CBC
padding weakness will no longer work, and maybe a minor fraction of
the script kiddies will spend their time on other activities.

But for the security of the typical web browser, and I'm not currently
aware of any TLS clients other than web browsers that are doing
downgrade dances.  I'm not seeing a measurable benefit from fallback-scsv.


The real problem, that is a prerequisite to Browser attacks like Poodle
(and BEAST and CRIME predecessors) are

   1) a browsers aggressive willingness to execute *ANYTHING* from
      *ANYWHERE* that looks like active content

   2) provisioning of a cross-site-request-forgery (CSRF) facility,
      where the browser will share/insert the user's authentication
      credentials into *EVERY* GET/POST, irrespective where that
      request originates

For a number of sites, being able to perform crafted GETs and POSTs,
for which the browser will automatically provide/perform the
authentication on behalf of the user, will provide ample room
to cause trouble or damage to the end user.  No existing nor future TLS
protocol version and no existing or future TLS cipher suites
can prevent exploitation of such a Browser (mis)feature.

A single Poodle attack on a browser requires the attacker to be on-path
between browser and server, for which the attacker intends to recover the
users basic authentication credentials or SSL session cookie through
repeated guessing -- and to perform active attacks on thousands of
network connections between browser and server, creating thousands
of otherwise quite rare TLS MAC errors in the server's logfile.

When (ab)using the browsers CSRF facility directly, rather than for noisy
and boring Poodle, it will be sufficient to piggy-back one single arbitrary
page that the user's browsers happens to load (or can be lured to load).
When properly done, the attack will be indistinguishable from a genuine
action of the user for the server, and be noticable for the user only
by forensic inspection.  The browser's CSRF facility may even
allow (ab)use of TLS PSK credentials or TLS client certificates,
a form of credential that can not be attacked/recovered by Poodle.


Attacking an *arbitrary* page is still quite trivial depressingly often,
because so many sites force their users to use plaintext HTTP for at
least parts of their stuff -- effectively throwing all security
overboard each time.

lots of online shops.  a popular auction site.

Today I visited the site of a popular video/phone/chat software.
Even when accessing their site via https: the "Sign in" and "Join us"
URLs (at the upper right of all pages of the site) will _force_ the
user through plaintext-HTTP.   The link to their Download section
is https, but in the download section, the actual green software
download button, again, forces you through plaintext-HTTP -- OUCH!


-Martin


From nobody Wed Jan 21 22:25:46 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1A51AC41A for ; Wed, 21 Jan 2015 22:25:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Level: 
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 8XipmCmw4Qlx for ; Wed, 21 Jan 2015 22:25:42 -0800 (PST)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A8F21AC419 for ; Wed, 21 Jan 2015 22:25:42 -0800 (PST)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id AA8693A3C1; Thu, 22 Jan 2015 07:25:40 +0100 (CET)
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 815D2415BD; Thu, 22 Jan 2015 07:25:40 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 7738B1B111; Thu, 22 Jan 2015 07:25:40 +0100 (CET)
In-Reply-To: 
To: Dmitry Belyavsky 
Date: Thu, 22 Jan 2015 07:25:40 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20150122062540.7738B1B111@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: 
Cc: TLS Mailing List 
Subject: Re: [TLS] GOST in TLS (Re: Inclusion of OCB mode in TLS 1.3)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Jan 2015 06:25:44 -0000

Dmitry Belyavsky wrote:
> 
> Martin Rex  wrote:
>>
>> The closest thing to a public specification is a long expired I-D:
>>
>>   https://tools.ietf.org/html/draft-chudov-cryptopro-cptls-04
>>
>> with essentially one TLS cipher suite TLS_GOSTR341001_WITH_28147_CNT_IMIT
>> that uses an officially deprecated/retired algorithm (R 34.10-2001)
>> and lacks the code point assignments that would be necessary for use
>> with TLSv1.2.
>>
>>
>> Googling just now, I found what might be a potential spec update:
>>
>> https://www.cryptopro.ru/sites/default/files/products/csp/rus-popov-tls-gost-00-rf.pdf
>>
>> but I don't understand russian.
>>
>> The TLS parameters code point assignments in the new document seem to
>> be from the private use areas (cptls-04 had kidnapped the cipher suite
>> ids).
>
>
> Yes, it's a new specification updated for using new GOST signature and
> digest alorithms.  It does not take into account TLS 1.3 specification at
> all.

The 2009 spec precluded that a TLS client could offer TLSv1.2 and
GOST in the same ClientHello (due to the lack of code point assignments)


It would really facilitate interop (and review/feedback) when the
new/updated specification could be translated and published in English.


>
> The R 34.10-2001 algorithm is not deprecated yet but will be deprecate soon.

This is how I read and understood this:

  https://tools.ietf.org/html/rfc7091#section-1.1

   GOST R 34.10-2001 is superseded by GOST R 34.10-2012 from 1 January
   2013.  That means that all new systems that are presented for
   certification MUST use GOST R 34.10-2012 and MAY use
   GOST R 34.10-2001 also for maintaining compatibility with existing
   systems.  Usage of GOST R 34.10-2001 in current systems is allowed at
   least for a 5-year period.


Reality does not always follow plans -- similar to the planned published
sunset date (end of 2010) for SHA1-based digital signatures in
US NISTs SP800-57 Part1 rev2 (March 2007)...


-Martin


From nobody Thu Jan 22 00:16:11 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3B061A0278 for ; Thu, 22 Jan 2015 00:16:08 -0800 (PST)
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 L51ipnNuhuT0 for ; Thu, 22 Jan 2015 00:16:06 -0800 (PST)
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 893C61A037D for ; Thu, 22 Jan 2015 00:16:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1421914566; x=1453450566; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=w53uVsP/K1RmD4bjCy1+nfm5JkgZHU9ZrakVZfj7wiA=; b=mWt9f6uf76vl7syBoOkLa+ob2JODmkzUodRTGzT3V4Sl1bbp3Q0zezIb YkP9H9DeXKatVMZRnM7YVwp28wDXrPd9hfbAAskSyoMowJRt6IO/y3J4I 8cxdHn/bOa/dQFcq/6KzyQwr0NOAxCVrE9CmvwgdvW6VhpXEZ5yDaWRBC Q=;
X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="303056081"
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/AES256-SHA; 22 Jan 2015 21:16:02 +1300
Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.148]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0174.001; Thu, 22 Jan 2015 21:16:01 +1300
From: Peter Gutmann 
To: "" 
Thread-Topic: [TLS] Using RSA PSS in TLS
Thread-Index: AdA2G6imJmOUDeVjRti6zRzrl9dIzw==
Date: Thu, 22 Jan 2015 08:16:01 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAF61DB4@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: 
Subject: Re: [TLS] Using RSA PSS in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Jan 2015 08:16:09 -0000

Martin Rex  writes:=0A=
=0A=
>Btw. TLSv1.2 explicitly requires support for a slight variation (NULL and=
=0A=
>absent parameters) on the TLSv1.2 RSA PKCS#1 v1.5 digitally-signed signatu=
re=0A=
>verification, see rfc5246, section 4.7 3rd paragraph:=0A=
=0A=
That looks like another one of those bits of TLS 1.2 that implementers have=
 to=0A=
know to ignore...=0A=
=0A=
Peter.=


From nobody Thu Jan 22 00:18:58 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4D51A01CB for ; Thu, 22 Jan 2015 00:18:55 -0800 (PST)
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 E68klrXw7IUS for ; Thu, 22 Jan 2015 00:18:53 -0800 (PST)
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 640E51A0166 for ; Thu, 22 Jan 2015 00:18:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1421914734; x=1453450734; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=GUBrQJ+By05RXEJF+elvS/Lgn8CB2yAjn10NFiGEslk=; b=EbU2V+d/vGTt2R+dyAAWd0bFu6eK3MAJprta5qMMMPrQG7WkzdXLtCCg KRZb9QgersQnB8omy0n69WnAesnLCdJxjdqIuF3eYUrAt9grQSV15Krdx 3aleRFSGthfvLzk3qR8ld75bTNb2Sx/2GNn1/hi1s280JGK0Llm/IZ4UA k=;
X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="303056288"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing
Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 22 Jan 2015 21:18:52 +1300
Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.148]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Thu, 22 Jan 2015 21:18:51 +1300
From: Peter Gutmann 
To: "" 
Thread-Topic: [TLS] Inclusion of OCB mode in TLS 1.3
Thread-Index: AdA2HA21KWwRKeC5SzmA1hs7cnakEA==
Date: Thu, 22 Jan 2015 08:18:51 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAF61DC4@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: 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Jan 2015 08:18:55 -0000

Aaron Zauner  writes:=0A=
=0A=
>Any comments on the idea of removing the following two ciphersuites from t=
he=0A=
>draft?=0A=
>=0A=
>     CipherSuite TLS_DHE_PSK_WITH_AES_128_OCB =3D {TBD9, TBD9}=0A=
>     CipherSuite TLS_DHE_PSK_WITH_AES_256_OCB =3D {TBD10, TBD10}=0A=
=0A=
Those cipher suites are really good ones, they give you PFS, mutual auth of=
=0A=
both parties, and OCB.  Why would you remove exactly those two?=0A=
=0A=
Peter.=0A=


From nobody Thu Jan 22 00:37:42 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3F51A03AB for ; Thu, 22 Jan 2015 00:37:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.311
X-Spam-Level: 
X-Spam-Status: No, score=-6.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_HI=-5, SPF_HELO_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 LCEbOi5olJHM for ; Thu, 22 Jan 2015 00:37:38 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDFF61A01D8 for ; Thu, 22 Jan 2015 00:37:38 -0800 (PST)
Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t0M8bbDZ009885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 22 Jan 2015 03:37:37 -0500
Received: from dhcp-2-127.brq.redhat.com (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t0M8bZOT019851 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 22 Jan 2015 03:37:36 -0500
Message-ID: <1421915855.2723.52.camel@redhat.com>
From: Nikos Mavrogiannopoulos 
To: Aaron Zauner 
Date: Thu, 22 Jan 2015 09:37:35 +0100
In-Reply-To: <54BFDAD1.6050403@azet.org>
References: <54B5501A.4070402@azet.org> <20150120191819.GA8165@typhoon.azet.org> <20150120193412.GA10140@typhoon.azet.org>  <20150120225335.GA871@typhoon.azet.org>  <20150121004704.GA15203@typhoon.azet.org> <54BFC326.4010302@azet.org>  <20150121165008.GQ2350@localhost> <54BFDAD1.6050403@azet.org>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Archived-At: 
Cc: TLS Mailing List 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Jan 2015 08:37:40 -0000

On Wed, 2015-01-21 at 17:58 +0100, Aaron Zauner wrote:

> > If DHE_PSK is relevant to an embedded device then all cipher+mode
> > combinations might be as well.  Obviously OCB wouldn't be required to
> > implement, but that's no reason to exclude any one subset of ciphersuits
> > using OCB.
> Well. No. Not really. Why would an embedded device prefer to do DHE over
> ECDHE? ECC operations are sure to be more efficient on embedded
> devices/IoT. That's was my reason to ask for removal.

It will not. However, there will be no PFS fallback if for some reason
there is some attack on ECDHE that is not applicable on DHE. In any case
I don't find the issue critical. Even if removed it's only 2
ciphersuites saved, and we are nowhere close to believing that the
ciphersuite space is close to an end.

regards,
Nikos



From nobody Thu Jan 22 00:40:56 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD1721A044D for ; Thu, 22 Jan 2015 00:40:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.468
X-Spam-Level: 
X-Spam-Status: No, score=-0.468 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_22=0.6, J_CHICKENPOX_51=0.6, SPF_HELO_PASS=-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 lDK6uOjkM1VY for ; Thu, 22 Jan 2015 00:40:49 -0800 (PST)
Received: from tlsx.org (tlsx.org [67.207.128.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0473D1A1B26 for ; Thu, 22 Jan 2015 00:40:48 -0800 (PST)
Received: from monty.local (unknown.maxonline.com.sg [58.182.168.20] (may be forged)) (authenticated bits=0) by tlsx.org (8.14.4/8.14.4/Debian-4) with ESMTP id t0M92bj0012539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 22 Jan 2015 09:02:41 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=metaparadigm.com; s=klaatu; t=1421917364; bh=PB8MGs348VjYUWek3Xs+vg93CjPbnWboK/Krm/JZXgQ=; h=Date:From:To:Subject:References:In-Reply-To:From; b=GLgXC4vY4g4vYPIjpcYF9Je3DQOHVDyr2oImBz0ZkfZubYXleZheGrVEY2unwqknT cCyvp7XoLEZOaNLyIlwFfwIV7swbiA6XcSQvUzKLfwlUllL4ARy4aX2+YYtuzNYkWP cAk9mdufKdq5oO7IHICHhRpSa+r1lghI8cFVCNnU=
Message-ID: <54C0B783.2060604@metaparadigm.com>
Date: Thu, 22 Jan 2015 16:40:35 +0800
From: Michael Clark 
Organization: Metaparadigm
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: "tls@ietf.org" 
References: <40128f312378442fbd26459bf5d7593b@usma1ex-dag1mb2.msg.corp.akamai.com> <,  > <20150119192701.190C71B0FF@ld9781.wdf.sap.corp> <, >   <, <04690E05-4905-4941-A60D-7BC5CDC93431@gmail.com> <>>  <39B8BC24-D539-456F-970B-B11665B0E892@gmail.com>
In-Reply-To: <39B8BC24-D539-456F-970B-B11665B0E892@gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.98.4 at klaatu.tlsx.org
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Jan 2015 08:40:52 -0000

Hi All,

* Very interesting stats. Are they independently verifiable?

* Very interesting facts on the specification ambiguity regards
  ClientHello "message Layer" version and "record layer" version
  SCSV might not have existed had implementations followed E.1.

- Agree with not adding SCSV to the proposed standard assuming
  the accuracy of these stats (even if I wrote SCSV myself I would
  stand corrected).

+ SCSV served a purpose of a mitigation while clients downgraded
  due to version upgrade intolerant servers. It may have served its
  purpose. Don't downgrade and there is no attack vector (1.6% servers).


Recommendations:

= Based on these numbers, it appears that clients MUST avoid downgrade
  when sending their highest ClientHello "Message Layer" TLS minor
  version number; given the TLS 1.3 ClientHello "Message Layer" minor
  version upgrade intolerance is 1.6% (for the Alexia top 1 million).

= ClientHello "Message Layer" TLS minor *version upgrade tolerance*
  intrinsically mitigates downgrade attacks.

= Appendix E.1 should state that servers MUST tolerate higher
  ClientHello "Message Layer" TLS minor protocol versions rather
  than recommend it and recommends the lower bound on the record
  layer TLS minor protocol version. It states:

  "No single value will
   guarantee interoperability with all old servers, but this is a
   complex topic beyond the scope of this document."


Reasoning:

= Based on these findings, we could safely tighten the spec:

   During non resumed handshake the ClientHello record protocol
   version MUST indicate the clients minimum supported TLS version
   and the ClientHello message layer TLS version must indicate the
   maximum supported TLS version. The ClientHello TLS version MUST
   be greater than or equal to the record protocol TLS version.

= TLSv1.3 implementations could remove SSLv3.0 support such that
  the minimum TLS record layer version for TLS 1.3 is 1.0 { 3, 1 }
  instead of { 3, 0 } which is mentioned in the Appendix as a
  "typical value" and the maximum "message layer" version a server
  accepts is specified as { 3, XX }. A TLSv1.2 client could send
  { 3, 1 } { 3, 3 } and a TLSv1.3 client would send { 3, 1 } { 3, 4 }
  in its ClientHello to support TLSv1.0 through TLSv1.2/3. This accords
  with protocol major/minor best practices for binary changes and
  backwards compatibility. i.e. no binary incompatible changes in minor
  versions. Just raise non-compliance with Appendix E.1 as a bug.

= Ambiguity only exists for ClientHello.

= ClientHello Message Layer TLS version tolerance; no upper bound
  for the *message layer* TLS "minor" protocol version) is protective.
  { 3, XX } or even { 4, 0 } for TLSv1.3 as I reason below.

= ClientHello Record Layer TLS version intolerance; strict lower bound
  for the *record layer* TLS "minor" protocol version) is protective.
  Use { 3, 1 } to deprecate SSLv3.0, which is now past its use by date
  (from an evolutionary perspective).


Issues (beyond the scope of TLS spec according to Appendix E.1):

= The issue is there is an (implicit and variable) *range* of
  acceptable versions; based on different policy of various clients
  and servers; caused by recommendations for deprecation of earlier
  protocol versions; most importantly SSLv3.0 (predictable IV); and
  the timing of roll outs of protocol upgrades to clients and servers.
  The deprecation, or lower bound needs to be made explicit.

= The notes in Appendix E.1 considers a "backwards compatibility"
  mechanism but do not make explicit the "deprecation" mechanism.

= Forward and Backwards compatibility (backwards binary compatibility
  through careful structure addition, unknown extension tolerance,
  minor version upgrade tolerance and unknown cipher suite tolerance
  should be preserved within "minor" protocol versions. This matches
  best practices for protocol discipline. Reconnecting with a lower
  version after alerts should only be attempted for deprecated
  protocols (SSLv3.0) after going through a "proceed with caution"
  screen. e.g. new minimum at the record layer of { 3, 1 }. You
  then only have "user agreement" to downgrade, or based on stats
  you can make { 3, 1 } the new minimum.

= It raises the issue that the TLSv1.3 spec specifies major version
  tolerance for the "message layer" ClientHello e.g. { 3, 1 } { 4, 0 }
  for at least "one major version" to prevent future downgrade attacks
  with a new major protocol version upgrade. This would build into
  TLSv1.3 the provision to introduce a new major version without
  being attacked.

= This would mean that a new major protocol version would need to
  define an embedding for its ClientHello within the record protocol
  of the previous major version (verbose legacy) as well as defining
  its new ClientHello format. A putative TLSx { 4, 0 } could send a
  verbose ClientHello "message layer" { 3, 1 } { 4, 0 } containing a
  legacy "combinatorial explosion" of cipher suites and already
  widely supported curve point formats, etc, SNI ext and optimistically
  embed its { 4, 0 } Hello data in an extension then learn/cache the
  version of servers and subsequently sends concatenated new Hellos
  { 4, 0 } { 4, 0 } for fast starts using a lean "profiles" system
  with profiles and pre-negotiated cryptographic primitives. Servers
  tolerant of ClientHello message layer major version upgrade is also
  protective given a mandate that major version upgrades define an
  embedding of their ClientHello (yucky verbose cipher suites) for
  the previous major protocol version. Doable.

= Yes. AEAD-AES-GCM is the cipher suite you would keep to maintain a
  bridge to TLSv1.2. Most of the other 304? are not AEAD.

= Do you want to specify more cipher suites at present? I argue below
  that based on verify_data that it may be a bad idea. See below
  TL;DR --- related but forward looking --- and the missing
  specification of verify_data_length in all cipher suites including GCM


On 21/1/15 5:16 pm, Yoav Nir wrote:
> Thanks
> 
> In that case, I think my implementation would fail with (1.3,1.3). Since
> I can’t know what changes TLS 1.3 made to the record layer, I can’t be
> sure that I understand what I’m parsing. Perhaps those bytes that I
> thought were the ClientHello are actually some new fields that were
> added to the record header.

Reasoning aloud.

You can if we know we are adhering to strict minor protocol version
binary compatibility rules. i.e. reasoned structure addition and
length prefixes, unknown extension tolerance and higher Hello version
tolerance. The "rule of thumb" is to only break binary compatibility
on major version changes.

If you are a 1.2 server and you receive a 1.3 ClientHello
{ 3, 1 } { 3, 4} and reply with a { 3, 3 }, { 3, 3 } ServerHello
then tolerant behavior (tolerance to higher ClientHello minor version
is protective) and is acting on the presumption that the client accepts
the older version specified in the record layer as you mention.
Likewise client intolerance to lower than ClientHello record layer
TLS version in ServerHello is also protective.

This accords with Appendix E.1 and it makes sense to avoid round trips,
and this intrinsically mitigates the downgrade attack vector. An alert
due to version upgrade intolerance in fact *opens* the attack vector.

If you are a 1.3 server, your server knows as with other TLS versions
that the ClientHello and ServerHello format will be designed with
"forwards compatibility" so you would not have any problem replying,
with the version you support, either 1.3 (after it is specified) or
1.0, 1.1 or 1.2 in response to a 1.3 ClientHello (Appendix E.1) with
1.0 at the record layer. Sure, if you reply with 1.3 now then a client
will abort. The version tolerance as per Appendix E.1 mitigates
downgrade tampering, as intolerance (or non compliant implementations)
lets your security be downgraded, by the "work-around" reconnect.
The implementations that are not version tolerant are not compliant
and stopping "work-around" reconnect improves things.

There is also TLS extension tolerance and cipher suite tolerance
(which SCSV relies on) to consider.

    https://bugzilla.mozilla.org/show_bug.cgi?id=689814

The core issue is Appendix E does not make explicit a protocol version
deprecation mechanism. It seems TLSv1.3 { 3, 4 } should specify a
lower bound of { 3, 1 } for the record layer TLS version in the
ClientHello as they are the same major version (in reality).
The fact that SSLv3.0 has partial record layer binary compatibility
is a red herring. We should notionally subtract { 2, 1 }.
SSLv3.0 is past the used by date.


Thought experiment.

The crux is the server lacks the information (through ambiguity of
specification) on the "range" of older versions supported by the
client. The reality is as Yoav mentions is the record layer has become
an adhoc signalling mechanism of the lower bound. Without this knowledge
we might invent an extension for the ClientHello to signal a list of
earlier versions in a "Compatible Versions Advisory Extension"
to signal to older servers that the client also accepts these.
This would provide for deprecation once servers are *upgraded* with
the "Compatible Versions Advisory Extension" extension. However the
problem is not with servers that upgrade. It's the 1.6% that have not
been upgraded. So yes. This is also equally as redundant as SCSV if
the record layer TLS version in the ClientHello is the lower bound.
The real issue is the client has to stop talking SSLv3.0.
i.e. There is no point to upgrade a server with this mechanism, rather
you need to start blocking the 1.6% servers that are not upgrading,
or at least prompt the user before downgrading a connection. i.e.
The proceed with caution screen. Simply becoming intolerant of
"message layer" version intolerance makes you no longer susceptible
to downgrade attacks.

This or any other advisory signalling mechanism becomes redundant
assuming downgrades should never happen within the same minor protocol
version and that the ClientHello record layer lower bound is { 3, 1 }
and the message layer ClientHello version upper bound is say { 3, 99 }.

End thought experiment.


Conclusion: Ipso facto, SCSV is redundant if servers implement version
tolerance as per the spec and clients don't try downgraded connections.


That said, SCSV was a valuable temporary fix to prevent downgrade
workarounds while lots of SSLv3.0 and/or version intolerant servers
were still in the wild. According to stats, this is no longer the case.


Based on those stats, if browsers adopted a common strategy of not
attempting to re-connect at lower TLS versions than what they signal
at the record layer, and servers followed Appendix E.1 version
tolerance, we would gain downgrade tamper resistance without any
signalling mechanism, and servers that were version intolerant would
naturally end up being upgraded when enough new clients adopted
Appendix E.1 guidelines. The small fraction of servers will get
upgraded if they have any customers.

If the recalcitrant servers are doing eCommerce, then we would be
doing them a public service. Give them 90 days and cut the cord on
SSLv3.0. They can always put a proxy in front :-D


> If the record layer version exceeds what the server supports, I think it
> wouldn’t be prudent to reply with anything but an alert. Many
> implementations treated the record layer version in the ClientHello as a
> minimum version number. Yes, I know this goes against a MUST requirement
> in appendix E.1 or RFC 5246, but as that appendix says, this is behavior
> that is often implemented.


I agree. If clients become intolerant of implementations that are not
version tolerant (compliant with the spec) then there is no need to
attempt to re-connect, and thus become vulnerable to downgrade attacks.
The nuance that is missing is clear text on guidance for the constraints
on the "record layer" and "message layer" TLS versions for the
ClientHello. Thanks for making it clear. I wasn't aware of the
ClientHello version ambiguity.



TL;DR --- related but forward looking ---


SNI is being sent to many servers that don't support the SNI extension
but most servers are tolerant of unknown extensions? I am now curious
about extension tolerance.

1). Q. Is there a similar data for extension intolerance?
2). Q. Is extension tolerance on the flip-side an attack vector?
       i.e. appending unknown extensions to the handshake to forge
       the 96-bits of verify_data?


There is a related threat analysis of extension tolerance forgery
potential; version and extension tolerance seem to be the status.
I found anecdotal mention from Ivan Ristic related to a small number
of servers that are SNI extension intolerance. Extension tolerance
however provides verify_data forgery potential. The question was
whether it is a credible threat. The answer was not right now.
Perhaps not this year, but certainly in the time-frame of TLSv1.3.


3). Q. From TLSv1.2 rfc5246, cipher suites can specify a longer
verify_data. Do any of them do so? neither rfc4492 (ECC) or rfc5289
(AES-GCM) mention verify_data length.

  In previous versions of TLS, the verify_data was always 12 octets
      long.  In the current version of TLS, it depends on the cipher
      suite.  Any cipher suite which does not explicitly specify
      verify_data_length has a verify_data_length equal to 12.  This
      includes all existing cipher suites.  Note that this
      representation has the same encoding as with previous versions.
      Future cipher suites MAY specify other lengths but such length
      MUST be at least 12 bytes.

As discussed earlier, using specially crafted extension data and
exploiting extension tolerance to forge verify_data is bounded by the
probability of a verify_data collision with a 16K message (2^14) which
with 96-bits verify_data (2^96). This is tractable at quantum scale (in
the TLSv1.3 timeframe) but not a present credible thread (unless there
is information to the contrary). The probability is (if my math is
correct?):

    handshakes * (2^14) / (2^96)
    handshakes / (2^82)

This is not a credible threat right at this moment, but I believe it
should be addressed in TLSv1.3. i.e. 96-bits doesn't offer enough
handshake forgery protection for the next 10 years.


4). Q. Is there consideration in TLSv1.3 to decouple verify data from
the cipher spec (given it is in practice decoupled) and extend it?

>From master https://github.com/tlswg/tls13-spec/draft-ietf-tls-tls13.md

  In previous versions of TLS, the verify_data was always 12 octets
     long. In the current version of TLS, it depends on the cipher
     suite. Any cipher suite which does not explicitly specify
     verify_data_length has a verify_data_length equal to 12. This
     includes all existing cipher suites. Note that this
     representation has the same encoding as with previous versions.
     Future cipher suites MAY specify other lengths but such length
     MUST be at least 12 bytes.

Based on the current wording, all cipher suites would need to be changed
to increase the handshake integrity, which gives one pause
to consider wiping them in TLSv1.3, or only offering the AES_GCM
subset with different operational semantics (to allow for backwards
compatibility) with respect to verify_data if TLSv1.3 is negotiated,
and then add new cryptographic primitives through extensions as is
already done with ECC curve points, etc or profiles. I know a lot
about combinatorial explosions. TLS already has one. What about
only having three of four cipher suites?

  TLSX_XKEX_XVERIFY_XAEAD = { ?, ? }

  "Supported Elliptic Curves Extension" {}
  "Supported Point Formats Extension" {}
  "Supported Key Exchange Mechanism Extension" {}
  "Supported Certificate Verification Algorithms Extension" : { }
  "Supported Authenticated Encryption Algorithms Extension" : { }
  "Supported Signature Algorithms Extension" : { }

or

  TLSX_PSK_XPROFILE = { ?, ? }
  TLSX_ECDHE_RSA_XPROFILE = { ?, ? }
  TLSX_ECDHE_ECDSA_XPROFILE = { ?, ? }
  TLSX_ECDHE_EDDSA_XPROFILE = { ?, ? }

  "Supported Profiles Extension" : { ssf112_embedded_r1 }

This gives you a TLSv1.x embedding with extensions and a mechanism for
a short short negotiation with a newer TLS server that uses
prenegotiated labels and makes these now widespread primitives
part of the new mandate.

This approach was alluded I think by Watson and or others (apologies
if I am wrongly attributing this). I don't see why within TLSvx.x,
that cipher suites could be eliminated, and servers could advertise
"cryptographic primitives" in extensions, as an embedding in TLS1.x
and/or use a concatenated negotiation for profiles where all of the
primitives have been pre-negotiated against specified profiles.
The extension embedding relies on protection for "verify_data".
i.e. solving the verify_data forgery attack vector, but most
implementations are already extension tolerant. It is bounded.
Sending profile labels to indicate support of a predefined table of
primitives just requires the Server to tell you which primitives it
selected from the list it knows you support.

Using more extensions pushes onto the handshake sign, encrypt, verify
mechanism. i.e. so that the minimum RSA, PSK or ECC/EdDSA can protect
must be >= 128-bits of verify_data in a maximum 16K handshake messsage.
With a "profiles" or "labeled" primitives approach servers could
distinguish between embedded and desktop. i.e. servers can prohibit
certain operations. Often an embedded device is used for second factor
auth or recovery for a desktop profile device.

Cipher Suites are not necessarily wrong. They were right when there was
about 32 of them. 304 changes things. Evolution...

Michael.


From nobody Thu Jan 22 00:52:34 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 578D61A03AB for ; Thu, 22 Jan 2015 00:52:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.668
X-Spam-Level: 
X-Spam-Status: No, score=-1.668 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-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 62YEOp-dz4l0 for ; Thu, 22 Jan 2015 00:52:31 -0800 (PST)
Received: from tlsx.org (tlsx.org [67.207.128.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41DDC1A0277 for ; Thu, 22 Jan 2015 00:52:31 -0800 (PST)
Received: from monty.local (unknown.maxonline.com.sg [58.182.168.20] (may be forged)) (authenticated bits=0) by tlsx.org (8.14.4/8.14.4/Debian-4) with ESMTP id t0M9EMf4012566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 22 Jan 2015 09:14:25 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=metaparadigm.com; s=klaatu; t=1421918066; bh=gPqEvxQ5z38uS2+zT+mFU7qp2EsJ9x28d09Phc/D6fw=; h=Date:From:To:Subject:References:In-Reply-To:From; b=HUMhrwMaZiy3zwm1a15ocW5WZdg0MOmlsEliGBfB0bZjI8dBMm+Z/oqybdE+wOeLW 4XKe0MOuEmY7WCM0T1kzoQPkiR8pQmEFe1/vHEd1ASDZdc6m7/7MZ3kEc3xaau0Kwe uw44nOfaY7GsT9eHNJVj7PHm+W82BNYGATTkjF1s=
Message-ID: <54C0BA43.7060304@metaparadigm.com>
Date: Thu, 22 Jan 2015 16:52:19 +0800
From: Michael Clark 
Organization: Metaparadigm
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: "tls@ietf.org" 
References: <40128f312378442fbd26459bf5d7593b@usma1ex-dag1mb2.msg.corp.akamai.com> <,  > <20150119192701.190C71B0FF@ld9781.wdf.sap.corp> <, >   <, <04690E05-4905-4941-A60D-7BC5CDC93431@gmail.com> <>>  <39B8BC24-D539-456F-970B-B11665B0E892@gmail.com> <54C0B783.2060604@metaparadigm.com>
In-Reply-To: <54C0B783.2060604@metaparadigm.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.98.4 at klaatu.tlsx.org
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Jan 2015 08:52:32 -0000

On 22/1/15 4:40 pm, Michael Clark wrote:

> = Appendix E.1 should state that servers MUST tolerate higher
>   ClientHello "Message Layer" TLS minor protocol versions rather
>   than recommend it and recommends the lower bound on the record
>   layer TLS minor protocol version. It states:
> 
>   "No single value will
>    guarantee interoperability with all old servers, but this is a
>    complex topic beyond the scope of this document."

This is the salient point. If laxity of the spec introduces an
attack vector then it is within the scope of the spec.

It seems { 3, 1 } should be the new minimum and version upgrade
intolerance should be a bug.

If the 1.6% of servers are fixed (assuming this is validated)
then SCSV and downgraded reconnect attempts in general should be
avoided.

~mc


From nobody Thu Jan 22 01:41:03 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1FF1A0687 for ; Thu, 22 Jan 2015 01:40:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level: 
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, 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 EFdy5mEggiOi for ; Thu, 22 Jan 2015 01:40:47 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A77301A049C for ; Thu, 22 Jan 2015 01:40:47 -0800 (PST)
Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t0M9ej8E016470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 22 Jan 2015 04:40:46 -0500
Received: from dhcp-2-127.brq.redhat.com (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t0M9eg8g019715 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 22 Jan 2015 04:40:44 -0500
Message-ID: <1421919642.2723.63.camel@redhat.com>
From: Nikos Mavrogiannopoulos 
To: Michael Clark 
Date: Thu, 22 Jan 2015 10:40:42 +0100
In-Reply-To: <54C0B783.2060604@metaparadigm.com>
References: <40128f312378442fbd26459bf5d7593b@usma1ex-dag1mb2.msg.corp.akamai.com> <, > <20150119192701.190C71B0FF@ld9781.wdf.sap.corp> <, >   <, <04690E05-4905-4941-A60D-7BC5CDC93431@gmail.com> <> >  <39B8BC24-D539-456F-970B-B11665B0E892@gmail.com> <54C0B783.2060604@metaparadigm.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Jan 2015 09:40:50 -0000

On Thu, 2015-01-22 at 16:40 +0800, Michael Clark wrote:

> = TLSv1.3 implementations could remove SSLv3.0 support such that
>   the minimum TLS record layer version for TLS 1.3 is 1.0 { 3, 1 }
>   instead of { 3, 0 } which is mentioned in the Appendix as a
>   "typical value" and the maximum "message layer" version a server
>   accepts is specified as { 3, XX }. A TLSv1.2 client could send
>   { 3, 1 } { 3, 3 } and a TLSv1.3 client would send { 3, 1 } { 3, 4 }
>   in its ClientHello to support TLSv1.0 through TLSv1.2/3. This accords
>   with protocol major/minor best practices for binary changes and
>   backwards compatibility. i.e. no binary incompatible changes in minor
>   versions. Just raise non-compliance with Appendix E.1 as a bug.
> [...]
> = ClientHello Record Layer TLS version intolerance; strict lower bound
>   for the *record layer* TLS "minor" protocol version) is protective.
>   Use { 3, 1 } to deprecate SSLv3.0, which is now past its use by date
>   (from an evolutionary perspective).

These recommendations are plainly wrong, and worse, they harm
interoperability for no security benefit. Unfortunately for some reason
they somehow got implemented.

1. The version in the record layer, _DOES NOT_ indicate the minimum
version the client supports. It does indicate the format of the record
packet. Having SSL 3.0 is perfectly valid, since the packet format
remained the same.

2. Using it as an indicator of the client's minimum version is wrong as
this field is not protected by the handshake hashes, so it shouldn't
affect any of the decisions taken as part of the handshake.

3. Forbidding SSL 3.0 version from the record layer breaks perfectly
valid clients, which advertise TLS 1.2. These clients can only use a
variant of fallback dance to connect to broken servers which impose
those limits. Please _DON'T CREATE MORE REASONS FOR FALLBACK DANCES_.

regards,
Nikos



From nobody Thu Jan 22 02:12:08 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3391A887B for ; Thu, 22 Jan 2015 02:12:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.668
X-Spam-Level: 
X-Spam-Status: No, score=-1.668 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-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 XsKHYGcNTYjv for ; Thu, 22 Jan 2015 02:12:05 -0800 (PST)
Received: from tlsx.org (tlsx.org [67.207.128.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A5401A1B62 for ; Thu, 22 Jan 2015 02:12:05 -0800 (PST)
Received: from monty.local (unknown.maxonline.com.sg [58.182.168.20] (may be forged)) (authenticated bits=0) by tlsx.org (8.14.4/8.14.4/Debian-4) with ESMTP id t0MAXtqE012789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 22 Jan 2015 10:33:59 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=metaparadigm.com; s=klaatu; t=1421922840; bh=nA2Jd5HXvP3X59z1Rzt2ILQaAzRWkAmy6s81Fs9dAXQ=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=crVaaAhTr5Qwxnsdk8Qd5tXC6wWwxEX1V70s0xNHOxsHjhM6ZfDtQEkdxPjGWV6HY Na9FIDXo2cn4V5tW9o+BaX59FaMP6LdnCNJlA2rdpwvyXU4Q7lo7lUs3Bx15HjmhUC f1MM8GIHgX5WbdkyeHvaKbr94q7jjnnvtd2JNnY0=
Message-ID: <54C0CCE9.40604@metaparadigm.com>
Date: Thu, 22 Jan 2015 18:11:53 +0800
From: Michael Clark 
Organization: Metaparadigm
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Nikos Mavrogiannopoulos 
References: <40128f312378442fbd26459bf5d7593b@usma1ex-dag1mb2.msg.corp.akamai.com> <,  >	 <20150119192701.190C71B0FF@ld9781.wdf.sap.corp> <, >	 	 	 <, <04690E05-4905-4941-A60D-7BC5CDC93431@gmail.com> <>	> 	 <39B8BC24-D539-456F-970B-B11665B0E892@gmail.com>	 <54C0B783.2060604@metaparadigm.com> <1421919642.2723.63.camel@redhat.com>
In-Reply-To: <1421919642.2723.63.camel@redhat.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.98.4 at klaatu.tlsx.org
X-Virus-Status: Clean
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Jan 2015 10:12:06 -0000

On 22/1/15 5:40 pm, Nikos Mavrogiannopoulos wrote:
> On Thu, 2015-01-22 at 16:40 +0800, Michael Clark wrote:
> 
>> = TLSv1.3 implementations could remove SSLv3.0 support such that
>>   the minimum TLS record layer version for TLS 1.3 is 1.0 { 3, 1 }
>>   instead of { 3, 0 } which is mentioned in the Appendix as a
>>   "typical value" and the maximum "message layer" version a server
>>   accepts is specified as { 3, XX }. A TLSv1.2 client could send
>>   { 3, 1 } { 3, 3 } and a TLSv1.3 client would send { 3, 1 } { 3, 4 }
>>   in its ClientHello to support TLSv1.0 through TLSv1.2/3. This accords
>>   with protocol major/minor best practices for binary changes and
>>   backwards compatibility. i.e. no binary incompatible changes in minor
>>   versions. Just raise non-compliance with Appendix E.1 as a bug.
>> [...]
>> = ClientHello Record Layer TLS version intolerance; strict lower bound
>>   for the *record layer* TLS "minor" protocol version) is protective.
>>   Use { 3, 1 } to deprecate SSLv3.0, which is now past its use by date
>>   (from an evolutionary perspective).
> 
> These recommendations are plainly wrong, and worse, they harm
> interoperability for no security benefit. Unfortunately for some reason
> they somehow got implemented.
> 
> 1. The version in the record layer, _DOES NOT_ indicate the minimum
> version the client supports. It does indicate the format of the record
> packet. Having SSL 3.0 is perfectly valid, since the packet format
> remained the same.

The spec has wording that alludes to this. In my read.

> 2. Using it as an indicator of the client's minimum version is wrong as
> this field is not protected by the handshake hashes, so it shouldn't
> affect any of the decisions taken as part of the handshake.


This I was not aware of. That is a hole I can now see (in my reasoning
with respect to handshake tampering). Thanks for pointing this out.

I was under the impression that verify data protects the handshake.

Thanks. This should be addressed.

> 3. Forbidding SSL 3.0 version from the record layer breaks perfectly
> valid clients, which advertise TLS 1.2. These clients can only use a
> variant of fallback dance to connect to broken servers which impose
> those limits. Please _DON'T CREATE MORE REASONS FOR FALLBACK DANCES_.

OK. Then an extension to indicate supported versions would in fact be an
improvement as it would be protected by verify_data.

I'm not in supported of downgrade dancing. I was completely unaware that
the entire handshake is not hashed.

Thanks.


From nobody Thu Jan 22 02:25:09 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1408C1AC444 for ; Thu, 22 Jan 2015 02:24:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level: 
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, 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 r5P5-DVXFnfh for ; Thu, 22 Jan 2015 02:24:56 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DE7B1AC447 for ; Thu, 22 Jan 2015 02:24:53 -0800 (PST)
Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t0MAOqgn028924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 22 Jan 2015 05:24:52 -0500
Received: from dhcp-2-127.brq.redhat.com (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t0MAOoEB008977 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 22 Jan 2015 05:24:51 -0500
Message-ID: <1421922289.2723.67.camel@redhat.com>
From: Nikos Mavrogiannopoulos 
To: Michael Clark 
Date: Thu, 22 Jan 2015 11:24:49 +0100
In-Reply-To: <54C0CCE9.40604@metaparadigm.com>
References: <40128f312378442fbd26459bf5d7593b@usma1ex-dag1mb2.msg.corp.akamai.com> <, > <20150119192701.190C71B0FF@ld9781.wdf.sap.corp> <, >   <, <04690E05-4905-4941-A60D-7BC5CDC93431@gmail.com> <>	>  <39B8BC24-D539-456F-970B-B11665B0E892@gmail.com> <54C0B783.2060604@metaparadigm.com> <1421919642.2723.63.camel@redhat.com> <54C0CCE9.40604@metaparadigm.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
Archived-At: 
Cc: "tls@ietf.org" 
Subject: [TLS] advertizing the minimum TLS supported version [was: Last Call: ]
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Jan 2015 10:24:59 -0000

On Thu, 2015-01-22 at 18:11 +0800, Michael Clark wrote:
> > 3. Forbidding SSL 3.0 version from the record layer breaks perfectly
> > valid clients, which advertise TLS 1.2. These clients can only use a
> > variant of fallback dance to connect to broken servers which impose
> > those limits. Please _DON'T CREATE MORE REASONS FOR FALLBACK DANCES_.
> OK. Then an extension to indicate supported versions would in fact be an
> improvement as it would be protected by verify_data.

Some time ago, I had proposed a method for clients to advertise the list
of protocols they support, for the same reason. To allow the server to
fallback to their preferred protocol:
https://tools.ietf.org/html/draft-mavrogiannopoulos-tls-more-extensions-00#section-4

regards,
Nikos



From nobody Thu Jan 22 02:30:17 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6362B1A9108 for ; Thu, 22 Jan 2015 02:30:15 -0800 (PST)
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 jAY6jSFOmwLx for ; Thu, 22 Jan 2015 02:30:13 -0800 (PST)
Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A65811A907F for ; Thu, 22 Jan 2015 02:30:13 -0800 (PST)
Received: by mail-ie0-f172.google.com with SMTP id rd18so631515iec.3 for ; Thu, 22 Jan 2015 02:30:12 -0800 (PST)
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:cc:content-type; bh=5CzWA0BskCehV+YR/0LeDAvFDKPQToB9yhnEE8XbGIo=; b=hiUB35GX6qSQMi29TTicfRiaflFadJm0YRY6CAxaVKk/nY/tpK0jZsV3KuCN7YTIU4 LhriooqDpfgm06NSGQcwtQ4aEVS9s0XcuDLl5N7Df0JPLV1qoacQVkVTenCXvUdvEaRY Wn5gwwQtg2NLqgGheCpiQ8pSpRbLSeHHTTVYCRUDLg8stLAsPPXAD34xTDgwYz20OTzW Vg3Jrg8mBy5cngPc9p5G36JwUkErQKvFHe6BntL6wxMvg1XQ2mvucl0e++ZeTv/AiR+4 Z5yv0Iuj/vlFLEvfvfgp2/TtItQRT7OIgUWIY08lYXkSEHDFVgw/InYsiXIvIwaU2oIQ QN3g==
MIME-Version: 1.0
X-Received: by 10.42.76.135 with SMTP id e7mr1980379ick.46.1421922612820; Thu, 22 Jan 2015 02:30:12 -0800 (PST)
Received: by 10.36.20.15 with HTTP; Thu, 22 Jan 2015 02:30:12 -0800 (PST)
In-Reply-To: <1421919642.2723.63.camel@redhat.com>
References: <40128f312378442fbd26459bf5d7593b@usma1ex-dag1mb2.msg.corp.akamai.com> <20150119192701.190C71B0FF@ld9781.wdf.sap.corp>   <04690E05-4905-4941-A60D-7BC5CDC93431@gmail.com>  <39B8BC24-D539-456F-970B-B11665B0E892@gmail.com> <54C0B783.2060604@metaparadigm.com> <1421919642.2723.63.camel@redhat.com>
Date: Thu, 22 Jan 2015 05:30:12 -0500
Message-ID: 
From: Jeffrey Walton 
To: Nikos Mavrogiannopoulos 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: noloader@gmail.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Jan 2015 10:30:15 -0000

On Thu, Jan 22, 2015 at 4:40 AM, Nikos Mavrogiannopoulos
 wrote:
> ...
>
> 2. Using it as an indicator of the client's minimum version is wrong as
> this field is not protected by the handshake hashes, so it shouldn't
> affect any of the decisions taken as part of the handshake.
If its not protected, then its wrong - period. It lacks semantic
authentication. If its not going to be protected, then it should not
be used. Since it should not be used, it should be removed altogether.

Wagner and Schenier told us that back in the 1990s.
https://www.schneier.com/paper-ssl.html.


From nobody Thu Jan 22 02:37:38 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC8A11AC410 for ; Thu, 22 Jan 2015 02:37:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.668
X-Spam-Level: 
X-Spam-Status: No, score=-1.668 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-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 bwyvvj-JI_JD for ; Thu, 22 Jan 2015 02:37:35 -0800 (PST)
Received: from tlsx.org (tlsx.org [67.207.128.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C67F1A0AF8 for ; Thu, 22 Jan 2015 02:37:35 -0800 (PST)
Received: from monty.local (unknown.maxonline.com.sg [58.182.168.20] (may be forged)) (authenticated bits=0) by tlsx.org (8.14.4/8.14.4/Debian-4) with ESMTP id t0MAxQ6s012872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 22 Jan 2015 10:59:29 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=metaparadigm.com; s=klaatu; t=1421924371; bh=tdW5ol8GxcIEH06MwxbBldSO1KVP1GAz5FIccjqf1hI=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=GUjQmtM1+7qW8ei7hcsEusyQHufqHeN4iyCELHZufKF4n9sDP5ypRwO4YiMZm/aud QENP2e66/h3IjpZ/yaDEoPiiuiCOc5Z+DqKbZTiS4HiyL5T8P5HP9JrJwQJNNkdbSW dhoes5q//7vccBKjLfWsS9UpNE2xiZVaOjzYgOBs=
Message-ID: <54C0D2E4.4090204@metaparadigm.com>
Date: Thu, 22 Jan 2015 18:37:24 +0800
From: Michael Clark 
Organization: Metaparadigm
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Nikos Mavrogiannopoulos 
References: <40128f312378442fbd26459bf5d7593b@usma1ex-dag1mb2.msg.corp.akamai.com> <,  >	 <20150119192701.190C71B0FF@ld9781.wdf.sap.corp> <, >	 	 	 <, <04690E05-4905-4941-A60D-7BC5CDC93431@gmail.com> <>	> 	 <39B8BC24-D539-456F-970B-B11665B0E892@gmail.com>	 <54C0B783.2060604@metaparadigm.com> <1421919642.2723.63.camel@redhat.com> <54C0CCE9.40604@metaparadigm.com>
In-Reply-To: <54C0CCE9.40604@metaparadigm.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.98.4 at klaatu.tlsx.org
X-Virus-Status: Clean
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Jan 2015 10:37:37 -0000

On 22/1/15 6:11 pm, Michael Clark wrote:
> On 22/1/15 5:40 pm, Nikos Mavrogiannopoulos wrote:
>> 3. Forbidding SSL 3.0 version from the record layer breaks perfectly
>> valid clients, which advertise TLS 1.2. These clients can only use a
>> variant of fallback dance to connect to broken servers which impose
>> those limits. Please _DON'T CREATE MORE REASONS FOR FALLBACK DANCES_.
> 
> OK. Then an extension to indicate supported versions would in fact be an
> improvement as it would be protected by verify_data.
> 
> I'm not in supported of downgrade dancing. I was completely unaware that
> the entire handshake is not hashed.

I guess this is the crux of the matter. I was trying to figure this out
from the spec. A future version needs to state that *all* handshake data
is authenticated. My original suspicion.

My read of the stats was that < TLS1.0 { 3, 1 } represents 1.6%

Clearly the version *range* indication as per Appendix E.1 i.e. the
actual point of my mail, should be hashed as it does then allow for
handshake tampering. I made a note of my *false* assumption, that
the handshake is hashed (and required pre-image).

The spec does say:

 TLS clients that wish to negotiate with older servers MAY send any
   value {03,XX} as the record layer version number.  Typical values
   would be {03,00}, the lowest version number supported by the client,
   and the value of ClientHello.client_version.  No single value will
   guarantee interoperability with all old servers, but this is a
   complex topic beyond the scope of this document.

SSLv3.0 is advised against everywhere. I guess it's living with a wart
of using a record protocol version that you don't support given the
minimum most are willing to negotiate these days is TLSv1.0 { 3, 1 }.

Anyway that fact that the handshake is *not* completely hashed is
perhaps the most important issue to address given there is no secure
way to indicate a range of supported versions. i.e. SSLv3.0 deprecation.

If { 3, 0 } has to be the record protocol version in an unauthenticated
layer then so be it. It only gives more weight to the need for a
mechanism to indicate "Supported Versions" in an extension that is part
of the hash. i.e. the Thought Experiment that I discounted based on the
false assumption of the forgery proof of handshake messages.

Clearly TLS needs to authenticate the *whole* handshake and signal
minimum version securely and have no fallback to insecure versions if
this minimum version can be tampered with. Clearly the minimum version
needs to be in the verify_data hash (somehow as an extension).

TLS 1.0 should be a minimum. People need to upgrade. You can't keep
backwards compatibility and security at the same time when SSLv3.0
is insecure.


From nobody Thu Jan 22 02:40:31 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01DEA1A907F for ; Thu, 22 Jan 2015 02:40:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.668
X-Spam-Level: 
X-Spam-Status: No, score=-1.668 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-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 0xgowQBRoPRw for ; Thu, 22 Jan 2015 02:40:28 -0800 (PST)
Received: from tlsx.org (tlsx.org [67.207.128.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A56E1A0E10 for ; Thu, 22 Jan 2015 02:40:28 -0800 (PST)
Received: from monty.local (unknown.maxonline.com.sg [58.182.168.20] (may be forged)) (authenticated bits=0) by tlsx.org (8.14.4/8.14.4/Debian-4) with ESMTP id t0MB2JIX012904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 22 Jan 2015 11:02:22 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=metaparadigm.com; s=klaatu; t=1421924543; bh=gmf5sOJzTH9InnZ54a57KPvU7qc+ZyDOnodaOFiIq3I=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=P9AwMSMtAWat0NSTMz1yBVItTt1Jv1mBC7IvqSksInzpGjs/2CO0+tP6kphBgfaW9 fpQxpiCpwRO0FYdU9KSW8YOfzHrB6chLL3TzjP/3eG0rVHmtKAE3UYiR5vMxvpmxc5 6n/8BPIrF6qc9RrQ50kScHQloJ+v0+ob1nIQucug=
Message-ID: <54C0D391.5090505@metaparadigm.com>
Date: Thu, 22 Jan 2015 18:40:17 +0800
From: Michael Clark 
Organization: Metaparadigm
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Nikos Mavrogiannopoulos 
References: <40128f312378442fbd26459bf5d7593b@usma1ex-dag1mb2.msg.corp.akamai.com> <,  >		 <20150119192701.190C71B0FF@ld9781.wdf.sap.corp> <, >		 		 		 <, <04690E05-4905-4941-A60D-7BC5CDC93431@gmail.com> <>	>	 		 <39B8BC24-D539-456F-970B-B11665B0E892@gmail.com>		 <54C0B783.2060604@metaparadigm.com> <1421919642.2723.63.camel@redhat.com>	 <54C0CCE9.40604@metaparadigm.com> <1421922289.2723.67.camel@redhat.com>
In-Reply-To: <1421922289.2723.67.camel@redhat.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.98.4 at klaatu.tlsx.org
X-Virus-Status: Clean
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] advertizing the minimum TLS supported version [was: Last Call: ]
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Jan 2015 10:40:29 -0000

On 22/1/15 6:24 pm, Nikos Mavrogiannopoulos wrote:
> On Thu, 2015-01-22 at 18:11 +0800, Michael Clark wrote:
>>> 3. Forbidding SSL 3.0 version from the record layer breaks perfectly
>>> valid clients, which advertise TLS 1.2. These clients can only use a
>>> variant of fallback dance to connect to broken servers which impose
>>> those limits. Please _DON'T CREATE MORE REASONS FOR FALLBACK DANCES_.
>> OK. Then an extension to indicate supported versions would in fact be an
>> improvement as it would be protected by verify_data.
> 
> Some time ago, I had proposed a method for clients to advertise the list
> of protocols they support, for the same reason. To allow the server to
> fallback to their preferred protocol:
> https://tools.ietf.org/html/draft-mavrogiannopoulos-tls-more-extensions-00#section-4

Good idea. Thanks I understand now. More logical than SCSV to have the
minimum version in the handshake hash.


From nobody Thu Jan 22 03:06:47 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0385B1AC447 for ; Thu, 22 Jan 2015 03:06:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.668
X-Spam-Level: 
X-Spam-Status: No, score=-1.668 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-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 Ccx5NhlS0n2x for ; Thu, 22 Jan 2015 03:06:43 -0800 (PST)
Received: from tlsx.org (tlsx.org [67.207.128.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 907F81AC443 for ; Thu, 22 Jan 2015 03:06:43 -0800 (PST)
Received: from monty.local (unknown.maxonline.com.sg [58.182.168.20] (may be forged)) (authenticated bits=0) by tlsx.org (8.14.4/8.14.4/Debian-4) with ESMTP id t0MBSXuj013003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 22 Jan 2015 11:28:36 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=metaparadigm.com; s=klaatu; t=1421926119; bh=gCgQjJV7jebJadvT3MEfyTypZnWreJ5q00zulzM6acQ=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=S+s63c0DM3Q+vBUEENJRX29KDcmgsoBUYElW/2vsOSwYKAc5LQCllo6EoHj4yHs0s xMul4Z2Smq2PwqZpk8xPo8UmEK0PyVgjgbVXUdJLPO3yCPxvJBvg2YKdzcfEeqGmH8 6DylH0ixvD8t4RJc1KMx67n6DfBo7NkjiUK+Ue+Y=
Message-ID: <54C0D9B7.2000000@metaparadigm.com>
Date: Thu, 22 Jan 2015 19:06:31 +0800
From: Michael Clark 
Organization: Metaparadigm
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Nikos Mavrogiannopoulos 
References: <40128f312378442fbd26459bf5d7593b@usma1ex-dag1mb2.msg.corp.akamai.com> <,  >		 <20150119192701.190C71B0FF@ld9781.wdf.sap.corp> <, >		 		 		 <, <04690E05-4905-4941-A60D-7BC5CDC93431@gmail.com> <>	>	 		 <39B8BC24-D539-456F-970B-B11665B0E892@gmail.com>		 <54C0B783.2060604@metaparadigm.com> <1421919642.2723.63.camel@redhat.com>	 <54C0CCE9.40604@metaparadigm.com> <1421922289.2723.67.camel@redhat.com> <54C0D391.5090505@metaparadigm.com>
In-Reply-To: <54C0D391.5090505@metaparadigm.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.98.4 at klaatu.tlsx.org
X-Virus-Status: Clean
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] advertizing the minimum TLS supported version [was: Last Call: ]
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Jan 2015 11:06:45 -0000

On 22/1/15 6:40 pm, Michael Clark wrote:
> On 22/1/15 6:24 pm, Nikos Mavrogiannopoulos wrote:
>> On Thu, 2015-01-22 at 18:11 +0800, Michael Clark wrote:
>>>> 3. Forbidding SSL 3.0 version from the record layer breaks perfectly
>>>> valid clients, which advertise TLS 1.2. These clients can only use a
>>>> variant of fallback dance to connect to broken servers which impose
>>>> those limits. Please _DON'T CREATE MORE REASONS FOR FALLBACK DANCES_.
>>> OK. Then an extension to indicate supported versions would in fact be an
>>> improvement as it would be protected by verify_data.
>>
>> Some time ago, I had proposed a method for clients to advertise the list
>> of protocols they support, for the same reason. To allow the server to
>> fallback to their preferred protocol:
>> https://tools.ietf.org/html/draft-mavrogiannopoulos-tls-more-extensions-00#section-4
> 
> Good idea. Thanks I understand now. More logical than SCSV to have the
> minimum version in the handshake hash.


I would audit the handshake hash in an open implementation to be certain
and (based on new information in *my head* at least):

a) support Nikos proposal to advertise the list of protocols as
   a better short/medium term mitigation in preference to SCSV as
   this is the real issue. We could easily make the SCSV mistake if
   we were unaware of the handshake hash construction. I did.

b) TLSv1.3 in the medium to long should authenticate the entire
   handshake. There shouldn't be any unauthenticated bytes that
   can be tampered with. This would be in concert with reviewing
   verify_data_length and the 12 octet and the wording that defers
   to the cipher suite to increase it, but then they don't.
   TLSv1.3 could address this in a more permanent way.

So the thought experiment still stands, rather we made a false
assumption on authentication of the handshake. Some bytes can
be tampered with.

I will be reading (Open|Boring)SSL code to make sure. The reality
is however that when I reasoned from the spec, I saw hash(handshake)
but I did not see the wording that specified whether this is
the content of the handshake record or the whole record. I will look
for the wording in the spec. If it is there and specifies only the
content then it is a little mistake (for some value of little).

The reasoning in my prior email still stands despite the *pivot*
on the knowledge of the handshake hash construction.

I will read code...


From nobody Thu Jan 22 03:07:33 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87AFB1AC44E; Thu, 22 Jan 2015 03:07:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level: 
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, 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 jR2KV9272J3w; Thu, 22 Jan 2015 03:07:13 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A5BA1AC7E7; Thu, 22 Jan 2015 03:07:12 -0800 (PST)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t0MB7AVJ008311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 22 Jan 2015 06:07:11 -0500
Received: from pintsize.usersys.redhat.com (dhcp-0-172.brq.redhat.com [10.34.0.172]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t0MB79XV022987 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 22 Jan 2015 06:07:10 -0500
From: Hubert Kario 
To: tls@ietf.org
Date: Thu, 22 Jan 2015 12:07:08 +0100
Message-ID: <1587366.7iKLmClaM6@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.3 (Linux/3.17.8-200.fc20.x86_64; KDE/4.14.3; x86_64; ; )
In-Reply-To: <54C0482B.8010607@pobox.com>
References: <20150117045700.2E3801B0FA@ld9781.wdf.sap.corp> <54C0482B.8010607@pobox.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Archived-At: 
Cc: ietf@ietf.org
Subject: Re: [TLS] Last Call: 
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Jan 2015 11:07:21 -0000

On Wednesday 21 January 2015 16:45:31 Michael D'Errico wrote:
> Martin Rex wrote:
> > Rubber-Stamping the fallback-scsv hack onto the standards track is
> > IMHO a very bad idea.
>=20
> I apologize if this has been discussed before (I have about 1400
> unread TLS mailing list messages in my queue), but it seems that
> a simpler SCSV or extension could just ask the server to echo its
> highest supported version:
>=20
>      ClientHello w/SCSV    ----->
>                            <-----    ServerHello w/version extension

that's not allowed by the RFC's, the server can send back only the exte=
nsion=20
id's client has sent

--=20
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republi=
c


From nobody Thu Jan 22 06:31:29 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B5671A1B30 for ; Thu, 22 Jan 2015 06:31:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level: 
X-Spam-Status: No, score=-1.7 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_8BIT_HEADER=0.3, 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 RKqRUYXa1QS6 for ; Thu, 22 Jan 2015 06:31:27 -0800 (PST)
Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E332E1A1ABC for ; Thu, 22 Jan 2015 06:31:26 -0800 (PST)
Received: by mail-la0-f46.google.com with SMTP id s18so1916005lam.5 for ; Thu, 22 Jan 2015 06:31:25 -0800 (PST)
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:content-transfer-encoding; bh=q3LnBktBIJ6KfzEPwqyS6J68VpvuFif1i4UnhcrpLMM=; b=hrCsT4C9Fy1VVCHaiXaf46XJFCQ+w9xEZL4WEr+IXIxd418tmNSaTTVxyKx6xZIxXM xdiN68l/YF3ogqbmDcv09skIt03IL23IylpBgE3k46uMn7fos32G2jwHa0feLxEWD8is 395jdJ+UmiWdVrC6iEPothIdbn3p4KjMqbQ2MOCK2vMpVth+i8NAdiBowjbb7Bm1Jrmn IZnoxTMlITS2G7BABRh8nJ94VnVI5BzF9fHVKG7OLbYgVe+ZuW1e5FPrnnut39Vkvuv3 bYovJ4AU9Wtax4sN/hv9IbRaf6Z3oZYf8Z/uEKzYjPvEqbsREqMujAC9X2as3qbu0mQc MZWw==
MIME-Version: 1.0
X-Received: by 10.112.148.73 with SMTP id tq9mr1876976lbb.37.1421937085379; Thu, 22 Jan 2015 06:31:25 -0800 (PST)
Received: by 10.112.200.4 with HTTP; Thu, 22 Jan 2015 06:31:25 -0800 (PST)
In-Reply-To: 
References: <40128f312378442fbd26459bf5d7593b@usma1ex-dag1mb2.msg.corp.akamai.com> <20150119192701.190C71B0FF@ld9781.wdf.sap.corp>  
Date: Thu, 22 Jan 2015 15:31:25 +0100
Message-ID: 
From: =?UTF-8?Q?Henrik_Grubbstr=C3=B6m?= 
To: Xiaoyin Liu 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Jan 2015 14:31:28 -0000

On Wed, Jan 21, 2015 at 5:01 AM, Xiaoyin Liu  wrote:
> Hi,
>
> I just finished a scan of Alexa top 1 million websites to test for TLS
> version intolerance. I hope this information can be useful in the discuss=
ion
> of downgrade SCSV.

Great work!

> For each site, I made at most four attempts with the following order to
> fallback:
> (TLS 1.3, TLS 1.3) -> (TLS 1.0, TLS 1.3) -> (TLS 1.0, TLS 1.2) -> (TLS 1.=
0,
> TLS 1.0)
> where the first is TLS record layer version, and the second is Client Hel=
lo
> version.
[...]
> The total number of TLS enabled sites is 426,419. TLS 1.3 intolerant site=
s
> (7 and 8) are about 1.6%. TLS 1.2 intolerant sites are about 0.1%. Also i=
t
> shows setting a lower record layer version does improve compatibility a l=
ot.
> An example is https://paypal.com is intolerant to (TLS 1.3, TLS 1.3) but =
is
> tolerant to (TLS 1.0, TLS 1.3). Please note that I did not validate
> certificates nor check the integrity of handshakes. I closed the connecti=
on
> immediately after receiving ServerHello.

Probably not an issue yet, but note that servers actually implementing
TLS 1.3 as currently drafted will for a TLS 1.3 or later ClientHello:

  * Wait for a ClientKeyShare packet.

  * May reply with a HelloRetryRequest instead of a ServerHello.

  * Fail if the ClientHello doesn't contain AEAD suites or sufficient
extensions.

Any of the above may skew your statistics to have more failures.

/grubba

--=20
Henrik Grubbstr=C3=B6m                                       grubba@grubba.=
org
Roxen Internet Software AB                              grubba@roxen.com


From nobody Thu Jan 22 06:39:57 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E61A1A1ABF; Thu, 22 Jan 2015 06:39:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level: 
X-Spam-Status: No, score=-1.7 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_8BIT_HEADER=0.3, 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 ARZZqvc6CEvq; Thu, 22 Jan 2015 06:39:54 -0800 (PST)
Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4795D1ACC80; Thu, 22 Jan 2015 06:39:54 -0800 (PST)
Received: by mail-lb0-f170.google.com with SMTP id w7so1891323lbi.1; Thu, 22 Jan 2015 06:39:52 -0800 (PST)
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:content-transfer-encoding; bh=7aoqIJO1k39NEwEL49E3EB8P8Po3BrUJzt4lvq+7Zp8=; b=oIuzvcO5ZDqxKP/o9z0EfFNtLBBEwX2lWlNEyJo2UEso5DGYXzkRJ3BnXXP/Fn7Gir geW855qrSLBSTGYFlZMwra8da+oBsgspaEZEoyPcteXbuQ/nFVW1fDKNMwoYFA0oqRYN XYU3kxSgjprpb3Yl1YCZz1CPboeUBusaWNzcKNbwwbDmcXAQUqrZ60uWpzHSRDpcGCjr 1/HIXH7ZDKMrj2NvchSIi90FVdBk6XC/qish9WXZM+Zyp8P3r80qLxsILYe9vGI2Cksl vp+9nvSLb9Z3HrqXJ0Yy5MKCzKjHLFOrpTn9fNMhgTf5gmd4KRq3bPl8z2+sb+M19Hhz aj7A==
MIME-Version: 1.0
X-Received: by 10.152.4.200 with SMTP id m8mr1921520lam.17.1421937592777; Thu, 22 Jan 2015 06:39:52 -0800 (PST)
Received: by 10.112.200.4 with HTTP; Thu, 22 Jan 2015 06:39:52 -0800 (PST)
In-Reply-To: <1587366.7iKLmClaM6@pintsize.usersys.redhat.com>
References: <20150117045700.2E3801B0FA@ld9781.wdf.sap.corp> <54C0482B.8010607@pobox.com> <1587366.7iKLmClaM6@pintsize.usersys.redhat.com>
Date: Thu, 22 Jan 2015 15:39:52 +0100
Message-ID: 
From: =?UTF-8?Q?Henrik_Grubbstr=C3=B6m?= 
To: Hubert Kario 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: "tls@ietf.org" , ietf@ietf.org
Subject: Re: [TLS] Last Call: 
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Jan 2015 14:39:55 -0000

On Thu, Jan 22, 2015 at 12:07 PM, Hubert Kario  wrote:
> On Wednesday 21 January 2015 16:45:31 Michael D'Errico wrote:
>> Martin Rex wrote:
>> > Rubber-Stamping the fallback-scsv hack onto the standards track is
>> > IMHO a very bad idea.
>>
>> I apologize if this has been discussed before (I have about 1400
>> unread TLS mailing list messages in my queue), but it seems that
>> a simpler SCSV or extension could just ask the server to echo its
>> highest supported version:
>>
>>      ClientHello w/SCSV    ----->
>>                            <-----    ServerHello w/version extension
>
> that's not allowed by the RFC's, the server can send back only the extens=
ion
> id's client has sent

Not quite; cf RFC 5746 (Renegotiation Indication Extension), where the
client may use the SCSV TLS_EMPTY_RENEGOTIATION_INFO_SCSV instead of
the renegotiation_info extension in its ClientHello, but the server
will reply with the renegotiation_info extension.

/grubba

--=20
Henrik Grubbstr=C3=B6m                                       grubba@grubba.=
org
Roxen Internet Software AB                              grubba@roxen.com


From nobody Thu Jan 22 08:35:05 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09A621A8AF6 for ; Thu, 22 Jan 2015 08:35:02 -0800 (PST)
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 kZIr6LS8ahxO for ; Thu, 22 Jan 2015 08:34:59 -0800 (PST)
Received: from mail-yh0-x22a.google.com (mail-yh0-x22a.google.com [IPv6:2607:f8b0:4002:c01::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8932B1A8877 for ; Thu, 22 Jan 2015 08:34:59 -0800 (PST)
Received: by mail-yh0-f42.google.com with SMTP id a41so1180067yho.1 for ; Thu, 22 Jan 2015 08:34:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:date:message-id:subject:from:to:cc:content-type;  bh=MM0V+UZzY1g/ZPMyXa9DyNlWiU0bxfREG7EYrCIcIYg=; b=RUUouQif9dX+iD2slmGaFt152WBrXy+fg+51d4tKSvmGAoxHGTSywvVlXU3QvQby5y vFV5uG3ESZoerpescm4CsmuJdWAHkWSnwG905pN92rd7CcfxGdKikTjpVDjaUytIPIAm BPl+qW8dj91gO9XtxMZluzxDUFyTbNS9Np5VouIxOuxqHeOUnOVh7vuZTEyX6Mt1P63T IlfvciyLgjbPKi8CllM3vClFGuPBz9BI/GjAAJhY93GXFNv2GPxudlyVrdJCTnWgNAML 23Ef/6YtoVFB19txBmGxUp1GPMv6OMVf5YwD42iJI+sZ7eqEqoiGtLLUihs4UtVbe9F4 kDCA==
MIME-Version: 1.0
X-Received: by 10.236.18.194 with SMTP id l42mr1382813yhl.172.1421944498830; Thu, 22 Jan 2015 08:34:58 -0800 (PST)
Received: by 10.170.115.77 with HTTP; Thu, 22 Jan 2015 08:34:58 -0800 (PST)
Date: Thu, 22 Jan 2015 08:34:58 -0800
Message-ID: 
From: Watson Ladd 
To: "mrex@sap.com" 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "tls@ietf.org" 
Subject: [TLS] The Web Security model vs.TLS (was Re: Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Jan 2015 16:35:02 -0000

On Wed, Jan 21, 2015 at 10:11 PM, Martin Rex  wrote:
> Bodo Moeller wrote:
>>
>> If even just a *single* high-value site that you, personally, use does
>> support the SCSV, you'll benefit from the SCSV (provided that you're using
>> a browser that does a downgrade dance for compatibility with other servers
>> and sends the SCSV in downgraded Client Hello messages).
>
>
> I've been looking long and hard, but I'm having difficulties
> to see a noticable benefit.   OK, a Poodle demonstration of the CBC
> padding weakness will no longer work, and maybe a minor fraction of
> the script kiddies will spend their time on other activities.
>
> But for the security of the typical web browser, and I'm not currently
> aware of any TLS clients other than web browsers that are doing
> downgrade dances.  I'm not seeing a measurable benefit from fallback-scsv.
>
>
> The real problem, that is a prerequisite to Browser attacks like Poodle
> (and BEAST and CRIME predecessors) are
>
>    1) a browsers aggressive willingness to execute *ANYTHING* from
>       *ANYWHERE* that looks like active content
>
>    2) provisioning of a cross-site-request-forgery (CSRF) facility,
>       where the browser will share/insert the user's authentication
>       credentials into *EVERY* GET/POST, irrespective where that
>       request originates
>
> For a number of sites, being able to perform crafted GETs and POSTs,
> for which the browser will automatically provide/perform the
> authentication on behalf of the user, will provide ample room
> to cause trouble or damage to the end user.  No existing nor future TLS
> protocol version and no existing or future TLS cipher suites
> can prevent exploitation of such a Browser (mis)feature.

Go ahead and exploit this "vulnerability" you are discussing against
Paypal, Gmail, Facebook, or Amazon. You won't be able to. While there
is much to criticize the web security model for, and plenty of
websites are open to CSRF, characterizing the issue as unresolved is
wrong: there are standard, effective, protections that are regularly
used.

Would you use the fact that ASN.1 parsers routinely give RCE as an
argument against deployment of TLS, or removing broken ciphers? What
about the significant information leaks caused by TLS's disclosure of
timing and sizes of data transfers between client and server?
Ultimately, if you want to look for excuses, the failure of operating
systems to even attempt to provide basic security properties is a
problem.

Is there any historic or imaginable security issue in TLS, which this
logic can't be employed to dispose of? Renegotiation bug: well, it's a
consequence of internal layering we can't possibly be expected to know
about. Triple handshake: oh, the real problem is not validating every
certificate chain you see during the events. The fact that the
implementers were never advised of these issues in the first place is
conveniently omitted.

There is plenty to be said about the languid pace with which the IETF
addresses known security issues, the general apathy with which
designing for security is greeted in general, and the slow adoption of
known solutions, but none of this is an excuse for worsening the
problem.

I agree that if browsers could use existing extensions as indicators
of functioning servers, that would be a better approach that provides
security benefit to far more connections.

>
> A single Poodle attack on a browser requires the attacker to be on-path
> between browser and server, for which the attacker intends to recover the
> users basic authentication credentials or SSL session cookie through
> repeated guessing -- and to perform active attacks on thousands of
> network connections between browser and server, creating thousands
> of otherwise quite rare TLS MAC errors in the server's logfile.

You assume people a) read logs, b) recognize these errors c) connect
them to an attack, d) have an action to take and e) take it. This is
unlikely.

You also assume that being "on-path" is a constraint. It isn't.
Sitting in between the user and the website are dozens of poorly
secured routers, many with default passwords and hard coded SSH keys.
These routers are more than capable of mounting Poodle.

>
> When (ab)using the browsers CSRF facility directly, rather than for noisy
> and boring Poodle, it will be sufficient to piggy-back one single arbitrary
> page that the user's browsers happens to load (or can be lured to load).
> When properly done, the attack will be indistinguishable from a genuine
> action of the user for the server, and be noticable for the user only
> by forensic inspection.  The browser's CSRF facility may even
> allow (ab)use of TLS PSK credentials or TLS client certificates,
> a form of credential that can not be attacked/recovered by Poodle.

I hadn't thought of that last idea. Should be easy enough to test.

>
>
> Attacking an *arbitrary* page is still quite trivial depressingly often,
> because so many sites force their users to use plaintext HTTP for at
> least parts of their stuff -- effectively throwing all security
> overboard each time.
>
> lots of online shops.  a popular auction site.
>
> Today I visited the site of a popular video/phone/chat software.
> Even when accessing their site via https: the "Sign in" and "Join us"
> URLs (at the upper right of all pages of the site) will _force_ the
> user through plaintext-HTTP.   The link to their Download section
> is https, but in the download section, the actual green software
> download button, again, forces you through plaintext-HTTP -- OUCH!

So what? I don't see why Johnny with the screen door on his house
means that the bank shouldn't have a bank vault. There are plenty of
outdated Wordpress versions out there: does that mean we shouldn't
stop SQL injections?

Sincerely,
Watson Ladd

>
>
> -Martin
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



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


From nobody Thu Jan 22 08:47:31 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7D1F1A1AD2 for ; Thu, 22 Jan 2015 08:47:29 -0800 (PST)
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 RgzSzlPtasry for ; Thu, 22 Jan 2015 08:47:29 -0800 (PST)
Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABDA41A1ACA for ; Thu, 22 Jan 2015 08:47:28 -0800 (PST)
Received: by mail-wg0-f53.google.com with SMTP id a1so2795535wgh.12 for ; Thu, 22 Jan 2015 08:47:27 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=rklkcxrA9UqXsDa0lQTK9/hKePxWjftOZ1jgbEMh0lw=; b=j2SbK3ROAEc/efeQrRRHu21/jElgJbq/qs5FMC4QVUh7aGY8cNULDzazixmdiZV3L4 G7sszux0KOUpVd+nfs2FV32di9zFfsKaca4sh4TgZA/obJwJ9U9bz9sGWpLXqlaJBwbn EJWJ43jFMGgdA+c/EYN9du9UfPhnOcVQa7RYPPdSLqvck+SyaJlb9TQKdK83ZBM9tb3Z ds6AsYNcWKOl0H+4o5CZ10urgNpNADUhcUoiOT5RyPSpKfOS6nlUsN8xbUBmSqhPA0vB r/2WobihoXYfMnyb769fvF45Y7G9Q9rYIshq0YfSl9kLWhXX5tYdJwU9HjBuC/IobDaQ 0i7A==
X-Gm-Message-State: ALoCoQnjBnKWydNmzmUhmCqlDrE6EVYSLX1OzJTeorRvWfdTNu7Kwv50tTaEkWBgCjgKL49TmpuM
X-Received: by 10.194.205.138 with SMTP id lg10mr4918684wjc.130.1421945247450;  Thu, 22 Jan 2015 08:47:27 -0800 (PST)
Received: from [10.0.0.142] (chello080108032135.14.11.univie.teleweb.at. [80.108.32.135]) by mx.google.com with ESMTPSA id n3sm4637833wja.36.2015.01.22.08.47.25 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 22 Jan 2015 08:47:26 -0800 (PST)
Message-ID: <54C129A0.7050808@azet.org>
Date: Thu, 22 Jan 2015 17:47:28 +0100
From: Aaron Zauner 
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: Nikos Mavrogiannopoulos 
References: <54B5501A.4070402@azet.org> <20150120191819.GA8165@typhoon.azet.org> <20150120193412.GA10140@typhoon.azet.org>  <20150120225335.GA871@typhoon.azet.org>  <20150121004704.GA15203@typhoon.azet.org> <54BFC326.4010302@azet.org>  <20150121165008.GQ2350@localhost> <54BFDAD1.6050403@azet.org> <1421915855.2723.52.camel@redhat.com>
In-Reply-To: <1421915855.2723.52.camel@redhat.com>
X-Enigmail-Version: 1.2.3
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig6B3B835FDAF1F26B4064C7FB"
Archived-At: 
Cc: TLS Mailing List 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Jan 2015 16:47:30 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig6B3B835FDAF1F26B4064C7FB
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Nikos,

Nikos Mavrogiannopoulos wrote:
> It will not. However, there will be no PFS fallback if for some reason
> there is some attack on ECDHE that is not applicable on DHE. In any cas=
e
> I don't find the issue critical. Even if removed it's only 2
> ciphersuites saved, and we are nowhere close to believing that the
> ciphersuite space is close to an end.

Yes I agree. The issue I see is that confined/embedded might not have
DHE as fallback in any case, because they probably opt to not support it
because if plattform constraints. And as far as I understand PSK is
exactly there for these use-cases. It would be really good to have
someone doing TLS crypto in the embedded world comment on this topic.
I've done embedded development but nothing that touched TLS so far.

That being said: You're right. I'd much rather have it in there than
have no fallback.

Aaron


--------------enig6B3B835FDAF1F26B4064C7FB
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUwSmhAAoJEOTbZJL9ubXV9sMP+QHYwGtkxj00q1s+7hxgyN3/
ZGKnQuL8jZ/UDH2+PUOPo9fzOutwJts4Gy1o2KgSkXTOE+T2fDvFb53w3MKOMTkQ
NNnciigp0iHRycpLc3+OTyzVg+7sEMehKkQHG26lr3JIPkFathM7wcinvOFACQJI
ZvNTs7f6daGKGQzc6PC6MGcXJPMgFgdp4ZBaJ9uhTOooVJknzg6YT+7rHRPjiQ8d
zZoARoc8cnGLjNFlAiDqNruDZZFKFr8jkbpPAAU34wPm6lsqPXQ6qVZP1P1usqPf
QAVwvmGc5po01hoHRG6vNrnVHsntMrnTy3Qhp6XevBzD3tI1hJHV+lRU0UB5LHkZ
YWD/cs0xVYrLz0Lr+N3aAlqRl2rdOJ4dvxHTeIJK8h9gxEs2+Q99CAsFkuzKYDod
I64bMruTWc/LimtOi7l+TvuWIUuWIJpl08bTkmf1casn9o8PTVjY04x+gknAQURc
ygIgSU8lwOOi6LQQacyFjPaeE7HRZNqyLcdfRUxgu/GlwULSouTL8nuG4J/C925h
xZ5tdSBbmwnBxGUW0BMx8Oixw5kUr9Fkxp8ZCA2dhpi1TBuDj4YfzxrtPCBThiPl
VVzVPMfGuVZIfOiNSqPxZU+FXI/5LqTfeAaPcyb2ynUsmM6aGCoi/HgUyuf9xcvr
YzBSIM5gik3w5zcD1RAM
=d2DW
-----END PGP SIGNATURE-----

--------------enig6B3B835FDAF1F26B4064C7FB--


From SRS0=bNxw=CJ=acm.org=bmoeller@srs.kundenserver.de  Thu Jan 22 08:47:22 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A412A1A1ACA for ; Thu, 22 Jan 2015 08:47:22 -0800 (PST)
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 inIYqDnI8YXr for ; Thu, 22 Jan 2015 08:47:21 -0800 (PST)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.130]) (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 C98DB1A1AD2 for ; Thu, 22 Jan 2015 08:47:20 -0800 (PST)
Received: from mail-lb0-f182.google.com ([209.85.217.182]) by mrelayeu.kundenserver.de (mreue005) with ESMTPSA (Nemesis) id 0M5Ksl-1XVjZZ0Otj-00za7u for ; Thu, 22 Jan 2015 17:47:18 +0100
Received: by mail-lb0-f182.google.com with SMTP id l4so2554388lbv.13 for ; Thu, 22 Jan 2015 08:47:17 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.112.150.98 with SMTP id uh2mr2821775lbb.92.1421945237615; Thu, 22 Jan 2015 08:47:17 -0800 (PST)
Received: by 10.25.25.145 with HTTP; Thu, 22 Jan 2015 08:47:17 -0800 (PST)
In-Reply-To: <20150122061132.A0E441B111@ld9781.wdf.sap.corp>
References:  <20150122061132.A0E441B111@ld9781.wdf.sap.corp>
Date: Thu, 22 Jan 2015 17:47:17 +0100
Message-ID: 
From: Bodo Moeller 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=047d7b34329cc73b74050d406c9e
X-Provags-ID: V03:K0:+RDOUv+p791plXBAJPYTErBjomMwZOb7ZcYHMFASTRB44larIY1 u4t0IYMSZx7VuKwRdmmzETBZ3ka6KQE+l2Oh2HVh3ZlBkD7aGJAnxDzB18c5F5xaEfPse7B oAhILyJ+carxpitfIH04UGl15cdCybY6bBHMYxH/6rT4jPUpoJ1a6eEAHeG/RNZb5Ne+avF JSR8LUVqDqyTROqYhRi9Q==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: 
Subject: Re: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Jan 2015 16:59:36 -0000

--047d7b34329cc73b74050d406c9e
Content-Type: text/plain; charset=UTF-8

Martin Rex :

[...]
> But for the security of the typical web browser, and I'm not currently
> aware of any TLS clients other than web browsers that are doing
> downgrade dances.  I'm not seeing a measurable benefit from fallback-scsv.
>
>
> The real problem, that is a prerequisite to Browser attacks like Poodle
> (and BEAST and CRIME predecessors) are
>
>    1) a browsers aggressive willingness to execute *ANYTHING* from
>       *ANYWHERE* that looks like active content
>
>    2) provisioning of a cross-site-request-forgery (CSRF) facility,
>       where the browser will share/insert the user's authentication
>       credentials into *EVERY* GET/POST, irrespective where that
>       request originates
>
[...]

> When (ab)using the browsers CSRF facility directly, rather than for noisy
> and boring Poodle, it will be sufficient to piggy-back one single arbitrary
> page that the user's browsers happens to load (or can be lured to load).
>

Yes and no.  While it is certainly true that this is an unfortunate problem
with the protocols that browsers use today, the kind of cross-site request
forgery that you describe is commonly prevented by adding appropriate
additional verification tokens (that the attacker couldn't obtain or
predict or otherwise caused to be added) into legitimate requests,
supplementing the credentials (such as HTTP basic authentication passwords
or HTTP cookies) that would also go into the requests caused by the
attacker.  (Often enough, of course, the need for such protection is
missed, or tokens are added but not verified, etc.)

With such protection in place, browsers attacks like BEAST and POODLE can
undermine the security you'd otherwise achieve.  So in the reality of the
web today, browser attacks like BEAST and POODLE *are* relevant if they are
possible.  You might wish that this wasn't the case, but there's certainly
no near-term resolution of the basic CSRF issues in sight.

[As an aside, note that the "cross-site" jump may be only from
http://www.example.com/foo to https://www.example.com/bar if we assume that
the attacker controls the network, so it's a "cross--web-origin" attack
rather than a "cross-site" attack.]

Bodo

--047d7b34329cc73b74050d406c9e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Mart=
in Rex <mrex@sap.com>:

=

[...]

But for the security of the typical web browser, and I'm not currently<=
br>
aware of any TLS clients other than web browsers that are doing

downgrade dances.=C2=A0 I'm not seeing a measurable benefit from fallba=
ck-scsv.





The real problem, that is a prerequisite to Browser attacks like Poodle

(and BEAST and CRIME predecessors) are



=C2=A0 =C2=A01) a browsers aggressive willingness to execute *ANYTHING* fro=
m

=C2=A0 =C2=A0 =C2=A0 *ANYWHERE* that looks like active content



=C2=A0 =C2=A02) provisioning of a cross-site-request-forgery (CSRF) facilit=
y,

=C2=A0 =C2=A0 =C2=A0 where the browser will share/insert the user's aut=
hentication

=C2=A0 =C2=A0 =C2=A0 credentials into *EVERY* GET/POST, irrespective where =
that

=C2=A0 =C2=A0 =C2=A0 request originates
[...]

When (ab)using the browsers CSRF facility directly, rather than for noisy
and boring Poodle, it will be sufficient to piggy-back one single arbitrary=


page that the user's browsers happens to load (or can be lured to load)=
.

Yes and no.=C2=A0 While it is certain=
ly true that this is an unfortunate problem with the protocols that browser=
s use today, the kind of cross-site request forgery that you describe is co=
mmonly prevented by adding appropriate additional verification tokens (that=
 the attacker couldn't obtain or predict or otherwise caused to be adde=
d) into legitimate requests, supplementing the credentials (such as HTTP ba=
sic authentication passwords or HTTP cookies) that would also go into the r=
equests caused by the attacker. =C2=A0(Often enough, of course, the need fo=
r such protection is missed, or tokens are added but not verified, etc.)

With such protection in place, browsers attacks like=
 BEAST and POODLE can undermine the security you'd otherwise achieve.=
=C2=A0 So in the reality of the web today, browser attacks like BEAST and P=
OODLE *are* relevant if they are possible.=C2=A0 You might wish that this w=
asn't the case, but there's certainly no near-term resolution of th=
e basic CSRF issues in sight.

[As an aside, note t=
hat the "cross-site" jump may be only from http://www.example.com/foo to https://www.example.com/bar if we assume that the attac=
ker controls the network, so it's a "cross--web-origin" attac=
k rather than a "cross-site" attack.]

Bo=
do




--047d7b34329cc73b74050d406c9e--


From SRS0=bNxw=CJ=acm.org=bmoeller@srs.kundenserver.de  Thu Jan 22 08:59:22 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B60331ACD2A for ; Thu, 22 Jan 2015 08:59:22 -0800 (PST)
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 umwuIFtNh8fM for ; Thu, 22 Jan 2015 08:59:21 -0800 (PST)
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 DBE511ACD2D for ; Thu, 22 Jan 2015 08:59:19 -0800 (PST)
Received: from mail-la0-f51.google.com ([209.85.215.51]) by mrelayeu.kundenserver.de (mreue004) with ESMTPSA (Nemesis) id 0LfWbl-1XuNYL1wSH-00p6Yq for ; Thu, 22 Jan 2015 17:59:16 +0100
Received: by mail-la0-f51.google.com with SMTP id ge10so2751429lab.10 for ; Thu, 22 Jan 2015 08:59:15 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.112.13.103 with SMTP id g7mr2851572lbc.29.1421945955139; Thu, 22 Jan 2015 08:59:15 -0800 (PST)
Received: by 10.25.25.145 with HTTP; Thu, 22 Jan 2015 08:59:14 -0800 (PST)
In-Reply-To: <54C0B783.2060604@metaparadigm.com>
References: <40128f312378442fbd26459bf5d7593b@usma1ex-dag1mb2.msg.corp.akamai.com> <20150119192701.190C71B0FF@ld9781.wdf.sap.corp>   <04690E05-4905-4941-A60D-7BC5CDC93431@gmail.com>  <39B8BC24-D539-456F-970B-B11665B0E892@gmail.com> <54C0B783.2060604@metaparadigm.com>
Date: Thu, 22 Jan 2015 17:59:14 +0100
Message-ID: 
From: Bodo Moeller 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11c39f568bc710050d4097cf
X-Provags-ID: V03:K0:4AbxnYPNNbw7T/YSZ0CCbQpxoJAqXAenxcNBz6x5v29K3HTsP7S mNPpkEK2JmWX7BIf+WMPOxzX1j6nSW8tOzlaBiGTu1xZ8i/+A4dToiDrJWjTuq7y0o6quvB GWSNWQFOEZT7FA7aYH186tcls3GCLAm9E3rDUZVZAGh10+582Gc2Fids3F5d8xMNLIuiiSF ln2DR79TcvD1q2gdLtr4g==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: 
Subject: Re: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Jan 2015 17:01:17 -0000

--001a11c39f568bc710050d4097cf
Content-Type: text/plain; charset=UTF-8

Michael Clark :


> + SCSV served a purpose of a mitigation while clients downgraded
>   due to version upgrade intolerant servers. It may have served its
>   purpose. Don't downgrade and there is no attack vector


This is certainly true, but note that all the major browsers (including the
current release of Mozilla Firefox) still *do* downgrade. Firefox has plans
to disable the downgrade dance by default, but there'll still be a user
setting for this, and various users may (have to) set this.  Not
downgrading isn't entirely science fiction any more, but it ain't over
until the fat lady sings.

Not having to do downgrade retries is the right goal, but when we have
achieved that, having the SCSV logic dormant in servers is really a minor
low-complexity addition to the protocol that won't do any harm, and may (or
may not) turn out to be useful again in the future.

Bodo

--001a11c39f568bc710050d4097cf
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Mich=
ael Clark <michael@metaparadigm.com>:
=C2=A0

+ SCSV served a purpose of a mitigation while clients downgraded

=C2=A0 due to version upgrade intolerant servers. It may have served its
=C2=A0 purpose. Don't downgrade and there is no attack vector

This is certainly true, but note that all the major =
browsers (including the current release of Mozilla Firefox) still *do* down=
grade. Firefox has plans to disable the downgrade dance by default, but the=
re'll still be a user setting for this, and various users may (have to)=
 set this.=C2=A0 Not downgrading isn't entirely science fiction any mor=
e, but it ain't over until the fat lady sings.

Not having to do downgrade retries is the right goal, but when we have ach=
ieved that, having the SCSV logic dormant in servers is really a minor low-=
complexity addition to the protocol that won't do any harm, and may (or=
 may not) turn out to be useful again in the future.

Bodo



--001a11c39f568bc710050d4097cf--


From nobody Thu Jan 22 09:21:49 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12F841ACD77 for ; Thu, 22 Jan 2015 09:21:42 -0800 (PST)
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 DX-60u4xlFS9 for ; Thu, 22 Jan 2015 09:21:36 -0800 (PST)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 736A41ACD74 for ; Thu, 22 Jan 2015 09:20:19 -0800 (PST)
Received: by mail-we0-f172.google.com with SMTP id k11so3044414wes.3 for ; Thu, 22 Jan 2015 09:20:18 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=Ah0/yyTc2bU5T3NyYraL0lAUVldGUY/HyuOzC7h+PrI=; b=fAe72SGz4HA4uh1+6bjr1Pwn5ro9iHO+/hTucqF0ryEYubloqoXmWnVk/a8//h0Zrk zU4Ko7bFssoiDK2VQDwk0ezaMKPiav/HHFjjUf/QxtCmzzKRwoMB+lL7Ys8On9xJemOj pdSH7ZVk2+n74Eslpwi3n3ejw2vPf1lZExQyeALJVKHUymBiPj6m1U7AneKAx/NNjtpJ TSxsoevI4mqAN3mTZi1cr4bi59srCTMe/7Ws9UtNSVX9wsBckt73RwcFHQzHaUuic6/r vZJfXx5o8YIuuzdeVqekrSeo8R6FhjZuO7poV0DAs9KfIubd8Oz4xsD6FwXvgRgeWJIj xMdQ==
X-Gm-Message-State: ALoCoQkoDdv9338I8cFAaAuzES+kPepWP0yOGttI9Ir9pwFB0C/hsZQpJeu/RIMFnXXDbk/2OU9W
X-Received: by 10.180.207.110 with SMTP id lv14mr47369729wic.41.1421947216785;  Thu, 22 Jan 2015 09:20:16 -0800 (PST)
Received: from [10.0.0.142] (chello080108032135.14.11.univie.teleweb.at. [80.108.32.135]) by mx.google.com with ESMTPSA id g10sm3840488wic.7.2015.01.22.09.20.15 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 22 Jan 2015 09:20:15 -0800 (PST)
Message-ID: <54C13152.4020600@azet.org>
Date: Thu, 22 Jan 2015 18:20:18 +0100
From: Aaron Zauner 
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: TLS Mailing List 
References: <54B5501A.4070402@azet.org> <20150120191819.GA8165@typhoon.azet.org> <20150120193412.GA10140@typhoon.azet.org>  <20150120225335.GA871@typhoon.azet.org>  <20150121004704.GA15203@typhoon.azet.org> <54BFC326.4010302@azet.org>  <20150121165008.GQ2350@localhost> <54BFDAD1.6050403@azet.org> <1421915855.2723.52.camel@redhat.com> <54C129A0.7050808@azet.org>
In-Reply-To: <54C129A0.7050808@azet.org>
X-Enigmail-Version: 1.2.3
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig0D6463369684D5C140A9D520"
Archived-At: 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Jan 2015 17:21:42 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig0D6463369684D5C140A9D520
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi TLS-WG,

I've uploaded an updated, edited version of the ID incorporating some
suggestions and changes that were pointed out to me in this thread:
http://datatracker.ietf.org/doc/draft-zauner-tls-aes-ocb/

Diff:
http://www.ietf.org/rfcdiff?url1=3Ddraft-zauner-tls-aes-ocb-00&url2=3Ddra=
ft-zauner-tls-aes-ocb-01

git History:
https://github.com/azet/draft-zauner-tls-aes-ocb/commits/master

Feedback as always appreciated.

Aaron


--------------enig0D6463369684D5C140A9D520
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUwTFSAAoJEOTbZJL9ubXVpIEP/2TWPIwOVkXGZW5DFEZ4dCea
glyAMSmGp1a85Ku5gEy2yXTUR9vD1dMCXmi4/G7PGPggU7wJWWsBGVYNqLIzwWtZ
P9T3wVVLjw4LMWOJxMAA/D+6I4njatw8IMIHPBnAEyNP6gHXv4s2UhtAgraylMFR
EHzVS8+BLnWWJpQtHYIgVR5Mb312Dim3TRPLShWr0CUW4mLw3+lMGgIC1DI2wfbb
NObu3GzbwaminqZSrl1LL2MmvFZyj7QQqCSMSMyUul656Nh+HxqZ7HJpxmPUHLqC
FvyzqZ0Fy1OsJatufYLB6ust75/BqHfA6vCuZ/1SUtF/ETFrw0ChTU1NiywL+GLy
Dz/7VVsm5J5XJ2tYtRe/Fr+w9htvsRgYhdz1SUzMEgbu2RhXyaBQHOBj0hq/t6Vi
7IMbvnObn03fXdpZOK3azpObW+0ua+MtIfimzqP0tQYKHTqFHL4qrWoW/l8K/O7H
Qj1nN/GDeO9azve+a6SnhYG5Ns/S2/F6VI+5yAxbF6nVxCqGFvAMdhDaYLsdmRJ3
cgJEw/INTZcQbm19X5/oFJj3GBrmlMqY3uqPCgzZNiEkIBL96zhXvyIFlh/7BYu4
nE3jFDOFQyvyeU9kZ8BBIsCnLSoaiUCo0C3bf5lZC98RSPyPjreEuo3Dn87CM5ju
pYjiLb/IyRvOL/QT8rSu
=dDdv
-----END PGP SIGNATURE-----

--------------enig0D6463369684D5C140A9D520--


From nobody Thu Jan 22 09:28:11 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A67E1ACD7B for ; Thu, 22 Jan 2015 09:28:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level: 
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, 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 RfWLq7JWaywC for ; Thu, 22 Jan 2015 09:28:08 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 831441ACD78 for ; Thu, 22 Jan 2015 09:28:08 -0800 (PST)
Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t0MHS6Il000593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 22 Jan 2015 12:28:06 -0500
Received: from dhcp-2-127.brq.redhat.com (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t0MHS4sD021036 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 22 Jan 2015 12:28:06 -0500
Message-ID: <1421947684.2723.120.camel@redhat.com>
From: Nikos Mavrogiannopoulos 
To: Aaron Zauner 
Date: Thu, 22 Jan 2015 18:28:04 +0100
In-Reply-To: <54C129A0.7050808@azet.org>
References: <54B5501A.4070402@azet.org> <20150120191819.GA8165@typhoon.azet.org> <20150120193412.GA10140@typhoon.azet.org>  <20150120225335.GA871@typhoon.azet.org>  <20150121004704.GA15203@typhoon.azet.org> <54BFC326.4010302@azet.org>  <20150121165008.GQ2350@localhost> <54BFDAD1.6050403@azet.org> <1421915855.2723.52.camel@redhat.com> <54C129A0.7050808@azet.org>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
Archived-At: 
Cc: TLS Mailing List 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Jan 2015 17:28:10 -0000

On Thu, 2015-01-22 at 17:47 +0100, Aaron Zauner wrote:
> Hi Nikos,
> 
> Nikos Mavrogiannopoulos wrote:
> > It will not. However, there will be no PFS fallback if for some reason
> > there is some attack on ECDHE that is not applicable on DHE. In any case
> > I don't find the issue critical. Even if removed it's only 2
> > ciphersuites saved, and we are nowhere close to believing that the
> > ciphersuite space is close to an end.
> Yes I agree. The issue I see is that confined/embedded might not have
> DHE as fallback in any case, because they probably opt to not support it
> because if plattform constraints.

Hi,
 I don't think you should associate TLS-PSK with embedded systems only.
In RFC7360 you'll see DTLS used with PSK for the radius protocol, which
is implemented in a bigger variety of systems than embedded.

regards,
Nikos



From nobody Thu Jan 22 11:49:38 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 634E21A6F34 for ; Thu, 22 Jan 2015 11:49:36 -0800 (PST)
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 3PQlqtVaD62Y for ; Thu, 22 Jan 2015 11:49:35 -0800 (PST)
Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DB8E1A6EF0 for ; Thu, 22 Jan 2015 11:49:35 -0800 (PST)
Received: by mail-wi0-f177.google.com with SMTP id r20so5866903wiv.4 for ; Thu, 22 Jan 2015 11:49:33 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=LjW01FeZo1BTR1iCB6/fQP9ScCAL3Hl90sMlDmPsNnE=; b=eocONujCR88N56HFufdXz17+4AgEAcxk95KfyLlnijveq/qJGrGxuXrcKG8AhFzGUE JJxfwnQQzf1JGUdVW9zACwttZ4K8cpY5DDZLsuqNvhca8b2WP2gzIRfYKm3sFiTqK5WK SsSAAt4MLk/39qtikpUkY3jr72zWuRbKcK5CNaT2a6C13JGhlA2/n4PC48ETpZsw0KQd kp0s1HbGAAXlMbvxgs32ETcbSpy8CMuN7BMDCKgiPmCf/J7T2SEJ60OzG2+bq+ICqoYW pASe1Pa4HrXBe2Ub9aFEXKApA2gVtd6RSg1AOUjXgxoUma3vLs8ormaO0rCKQz0Xu9mk bhnw==
X-Gm-Message-State: ALoCoQnNUAindNMBFjHa7ugfVhH8DqLzs4/cmkKpfZ/j6m26PObLgFY93DpEWyAFFb6y6ubkvi7z
X-Received: by 10.180.21.206 with SMTP id x14mr70842866wie.64.1421956173885; Thu, 22 Jan 2015 11:49:33 -0800 (PST)
Received: from [10.0.1.164] ([86.59.123.226]) by mx.google.com with ESMTPSA id fm10sm76673wib.7.2015.01.22.11.49.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 22 Jan 2015 11:49:33 -0800 (PST)
Message-ID: <54C1544F.5070809@azet.org>
Date: Thu, 22 Jan 2015 20:49:35 +0100
From: Aaron Zauner 
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: Nikos Mavrogiannopoulos 
References: <54B5501A.4070402@azet.org> <20150120191819.GA8165@typhoon.azet.org> <20150120193412.GA10140@typhoon.azet.org>  <20150120225335.GA871@typhoon.azet.org>  <20150121004704.GA15203@typhoon.azet.org> <54BFC326.4010302@azet.org>  <20150121165008.GQ2350@localhost> <54BFDAD1.6050403@azet.org> <1421915855.2723.52.camel@redhat.com> <54C129A0.7050808@azet.org> <1421947684.2723.120.camel@redhat.com>
In-Reply-To: <1421947684.2723.120.camel@redhat.com>
X-Enigmail-Version: 1.2.3
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig29438674DD323ED1305B1781"
Archived-At: 
Cc: TLS Mailing List 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Jan 2015 19:49:36 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig29438674DD323ED1305B1781
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



Nikos Mavrogiannopoulos wrote:
> On Thu, 2015-01-22 at 17:47 +0100, Aaron Zauner wrote:
>> Hi Nikos,
>>
>> Nikos Mavrogiannopoulos wrote:
>>> It will not. However, there will be no PFS fallback if for some reaso=
n
>>> there is some attack on ECDHE that is not applicable on DHE. In any c=
ase
>>> I don't find the issue critical. Even if removed it's only 2
>>> ciphersuites saved, and we are nowhere close to believing that the
>>> ciphersuite space is close to an end.
>> Yes I agree. The issue I see is that confined/embedded might not have
>> DHE as fallback in any case, because they probably opt to not support =
it
>> because if plattform constraints.
>=20
> Hi,
>  I don't think you should associate TLS-PSK with embedded systems only.=

> In RFC7360 you'll see DTLS used with PSK for the radius protocol, which=

> is implemented in a bigger variety of systems than embedded.
>=20
Did not know this RFC. Thanks for pointing it out.

In the edited/updated ID I've left all the PSK ciphersuites untouched.

Aaron


--------------enig29438674DD323ED1305B1781
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUwVRPAAoJEOTbZJL9ubXVWbcP/2+B+fUN87JAV9Y+lSpABDDE
67CtgJl8a871qqbFTQBeTQx+pt0bu7rTXBZVgK3s9wH0nb2/tQ0LcYf+z49Zc3H+
8GSXdKvOs6T6uJVG23KVMDrpwIWsjday8292ubpMlzIgYAcpIBS4X6JxOibwVfX5
fwSS4F9atY/YE0NV+Y0vH7TUSgxuBg1bGiiTn2IcHXIj84l5tOlRhZobqHfEJgSG
PxvwrRjvyRbgagHQGKZscCJF15bIwPOKHeLXGQpAtjLmEt1udUSzSHnLcraX6aD2
GR02TAZbmwLVnSs7gtTgiE+2pHNtGmZ7Rx1eE96T3GYWKsOU+RlOIJzGHMKCyXan
NVUx2Xg7MOSP+shm65HwMAWYh1MDftCMt6fk8H8clPx496WwRMAEZd+s9+pjctLn
5xP/+5mUaCM1/qzhu/RMsrTOCwZwy+W+UU3pVe63dFmBhtYdayfixy0oLqCBZKjq
EAW4jIa3T2NvdImHDYxAnP9XTqOGzm92nUiPuc5fTzO7mkl/RT0LPUVTpuJ8ftkS
L0Jvy4wWS9NnnsBk9v/EH/YOai+uwBkI/lg65rgFvK4097TQ6enahRE4t07m27Wm
S7/+GSFb0SZfHq90N/bzIIepNW2lkjDfe8A3OVBlWD6jJT9ar3ZVmJsNDrQTgQvw
xAltHoZozcgN9Lp1piXv
=Jeen
-----END PGP SIGNATURE-----

--------------enig29438674DD323ED1305B1781--


From nobody Thu Jan 22 12:22:39 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AAD81B29F7 for ; Thu, 22 Jan 2015 12:22:30 -0800 (PST)
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 j71ts7sHUeRw for ; Thu, 22 Jan 2015 12:22:28 -0800 (PST)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 540341B2A01 for ; Thu, 22 Jan 2015 12:22:28 -0800 (PST)
Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 45153F984 for ; Thu, 22 Jan 2015 15:22:22 -0500 (EST)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 09DE1201D1; Thu, 22 Jan 2015 15:22:19 -0500 (EST)
From: Daniel Kahn Gillmor 
To: TLS Mailing List 
In-Reply-To: <1421947684.2723.120.camel@redhat.com>
References: <54B5501A.4070402@azet.org> <20150120191819.GA8165@typhoon.azet.org> <20150120193412.GA10140@typhoon.azet.org>  <20150120225335.GA871@typhoon.azet.org>  <20150121004704.GA15203@typhoon.azet.org> <54BFC326.4010302@azet.org>  <20150121165008.GQ2350@localhost> <54BFDAD1.6050403@azet.org> <1421915855.2723.52.camel@redhat.com> <54C129A0.7050808@azet.org> <1421947684.2723.120.camel@redhat.com>
User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu)
Date: Thu, 22 Jan 2015 15:22:19 -0500
Message-ID: <87vbjymupw.fsf@alice.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: [TLS] PSK [was: Re:  Inclusion of OCB mode in TLS 1.3]
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Jan 2015 20:22:30 -0000

On Thu 2015-01-22 12:28:04 -0500, Nikos Mavrogiannopoulos wrote:
>  I don't think you should associate TLS-PSK with embedded systems only.
> In RFC7360 you'll see DTLS used with PSK for the radius protocol, which
> is implemented in a bigger variety of systems than embedded.

There's also talk (for TLS 1.3) about eventually collapsing three
mechanisms we currently have into one:

 * PSK
 * session tickets
 * session ids

It looks like these can all be handled in the same way, which could
potentially make a TLS 1.3-only (or 1.3-and-later) implementation
simpler, because it would have fewer codepaths to follow and options to
keep track of.

        --dkg


From nobody Thu Jan 22 14:08:03 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 561551A87E4 for ; Thu, 22 Jan 2015 14:07:59 -0800 (PST)
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 cT4vyV7reY7J for ; Thu, 22 Jan 2015 14:07:55 -0800 (PST)
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 319451A87A5 for ; Thu, 22 Jan 2015 14:07:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1421964476; x=1453500476; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=lehG/TvYUiRZCVY1rEy6Ip0PA7IYGcXCEqF2Rozb73I=; b=ugIIr8s7Brv1bZC6b1jv4NYBkAqs7Lyy8hrSGq1uN+qf7/2aJSHRbn3v +O78hBO+q2wK5W3F+/cxgBj8ze2blDwMTqIpdfQQVde4rFXKsjoQIsFju zMzPW/t5x2eBPbjCA84Vf2xVvqmeQIbi85NWgfFVH0i6P5gyL9U4r4oA1 w=;
X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="303155665"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing
Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 23 Jan 2015 11:07:53 +1300
Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.148]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Fri, 23 Jan 2015 11:07:52 +1300
From: Peter Gutmann 
To: "" 
Thread-Topic: [TLS] Inclusion of OCB mode in TLS 1.3
Thread-Index: AdA2j92obButSWp5QhmD2iJJC2WYEQ==
Date: Thu, 22 Jan 2015 22:07:52 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAF626ED@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: 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Jan 2015 22:07:59 -0000

Aaron Zauner  writes:=0A=
=0A=
>The issue I see is that confined/embedded might not have DHE as fallback i=
n=0A=
>any case, because they probably opt to not support it because if plattform=
=0A=
>constraints. And as far as I understand PSK is exactly there for these use=
-=0A=
>cases.=0A=
=0A=
Not necessarily.  When I did my PSK draft I added the discussion of embedde=
d=0A=
systems use mostly as a red herring to deal with the people who complained=
=0A=
that since we already have PKI in all its infinite wonder and perfection to=
=0A=
secure TLS, there's no need for anything involving shared secrets.  The=0A=
mention of use in embedded systems was to deal with the PKI zombies, not=0A=
embedded systems.  RFC 4279 doesn't mention embedded systems at all.=0A=
=0A=
>It would be really good to have someone doing TLS crypto in the embedded=
=0A=
>world comment on this topic.=0A=
=0A=
I've got lots of TLS running in embedded systems.  I'm not aware of anythin=
g=0A=
currently using pure PSK, it's always DHE with PSK.  To deal with lower-pow=
er=0A=
CPUs, you use smaller DH parameters.  Even for older stuff from before it w=
as=0A=
ARM everywhere (with a side order of MIPS, PPC, NIOS, and whatnot everywher=
e),=0A=
the standard approach was still to use smaller RSA/DH values rather than pu=
re=0A=
PSK.  I support non-PFS PSK, but only after all of the PFS PSK suites, so I=
=0A=
doubt that ever gets used.=0A=
=0A=
At a pinch you can even do DHE-RSA in an embedded device, you just memcpy()=
=0A=
out a pre-encoded certificate chain that's generated on install so you don'=
t=0A=
have to have any certificate-processing code present.  Problem is that (a)=
=0A=
this doesn't give you mutual auth and (b) more importantly certificates=0A=
inherently don't work with embedded devices which can't be identified or=0A=
provisioned in any manner that's expected for certificates.  At best you ca=
n=0A=
hardcode in a fixed certificate with a meaningless identifier and infinite=
=0A=
lifetime at system build time, but that's just going through the motions of=
=0A=
using certs.=0A=
=0A=
Peter.=


From nobody Thu Jan 22 16:19:13 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0061A8A72 for ; Thu, 22 Jan 2015 16:19:10 -0800 (PST)
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 zmybbK1lWmIO for ; Thu, 22 Jan 2015 16:18:59 -0800 (PST)
Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DAB51A19F8 for ; Thu, 22 Jan 2015 16:18:59 -0800 (PST)
Received: by mail-qa0-f43.google.com with SMTP id v10so3766524qac.2 for ; Thu, 22 Jan 2015 16:18:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=eEp5tZV9TGzvafwpVGs9GEAzS5aGAvLqR0dGl6wA6TY=; b=U6oZrrozCzMrXN1aO+eEeUqeR+eliBrufRNPeZ9vD/njT0DR0jJynCwPRZXA8m9KnJ AmRXayr9HtsaNtJRDJRshAcRF2SXqpDvuErC5D2WgeL0rPh2xkuiJYQtlR0mewummWju STcY+Cpum9QgkICRR7RJn2BJRIeZiwFrzo6/6ke/QIxPEYSfoThIF5qL4buvzDeY56LE K+hxShf0sDlZ0Otkj2yNk5toeACVY8OJUwh0N7gM4KKP8ctjNpmRTPRtn7yKo317i+jC ULaJOyCsL/zBQ8cmYMvuBvCtEEarkJuvWOaUzewEtXyjxT25AMqCvXo1ZclhZSi0Fte2 lrMA==
X-Received: by 10.224.2.71 with SMTP id 7mr8653665qai.94.1421972338863; Thu, 22 Jan 2015 16:18:58 -0800 (PST)
Received: from dave-laptop.localnet ([96.245.56.59]) by mx.google.com with ESMTPSA id q78sm4800889qgq.5.2015.01.22.16.18.58 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 22 Jan 2015 16:18:58 -0800 (PST)
From: Dave Garrett 
To: tls@ietf.org
Date: Thu, 22 Jan 2015 19:18:56 -0500
User-Agent: KMail/1.13.5 (Linux/2.6.32-70-generic-pae; KDE/4.4.5; i686; ; )
References: <40128f312378442fbd26459bf5d7593b@usma1ex-dag1mb2.msg.corp.akamai.com> <39B8BC24-D539-456F-970B-B11665B0E892@gmail.com> <54C0B783.2060604@metaparadigm.com>
In-Reply-To: <54C0B783.2060604@metaparadigm.com>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Message-Id: <201501221918.56994.davemgarrett@gmail.com>
Archived-At: 
Subject: Re: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Jan 2015 00:19:11 -0000

On Thursday, January 22, 2015 03:40:35 am Michael Clark wrote:
> = TLSv1.3 implementations could remove SSLv3.0 support such that
>   the minimum TLS record layer version for TLS 1.3 is 1.0 { 3, 1 }
>   instead of { 3, 0 } which is mentioned in the Appendix as a
>   "typical value" and the maximum "message layer" version a server
>   accepts is specified as { 3, XX }. A TLSv1.2 client could send
>   { 3, 1 } { 3, 3 } and a TLSv1.3 client would send { 3, 1 } { 3, 4 }
>   in its ClientHello to support TLSv1.0 through TLSv1.2/3. This accords
>   with protocol major/minor best practices for binary changes and
>   backwards compatibility. i.e. no binary incompatible changes in minor
>   versions. Just raise non-compliance with Appendix E.1 as a bug.
[...]
> The core issue is Appendix E does not make explicit a protocol version
> deprecation mechanism. It seems TLSv1.3 { 3, 4 } should specify a
> lower bound of { 3, 1 } for the record layer TLS version in the
> ClientHello as they are the same major version (in reality).
> The fact that SSLv3.0 has partial record layer binary compatibility
> is a red herring. We should notionally subtract { 2, 1 }.
> SSLv3.0 is past the used by date.

I have PRs to deal with this area in TLS 1.3 still pending a decision. The 
current version is the consensus from the previous discussion on the topic.

https://github.com/tlswg/tls13-spec/pull/105
https://github.com/tlswg/tls13-spec/pull/107

The changes are to prohibit SSL negotiation, drop SSL2 hello format 
documentation, freeze record layer hello version to 3.1, as well as other 
editorial improvements.

I haven't heard back from ekr in a couple weeks.


Dave


From nobody Thu Jan 22 16:24:18 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A85B1A19E4 for ; Thu, 22 Jan 2015 16:24:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 T4s9Zf3xGda4 for ; Thu, 22 Jan 2015 16:24:13 -0800 (PST)
Received: from mail-we0-f174.google.com (mail-we0-f174.google.com [74.125.82.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D30D1A004C for ; Thu, 22 Jan 2015 16:24:12 -0800 (PST)
Received: by mail-we0-f174.google.com with SMTP id x3so4806447wes.5 for ; Thu, 22 Jan 2015 16:24:11 -0800 (PST)
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:from:date :message-id:subject:to:cc:content-type; bh=0RzuBjVbKB331NQRAqCsqtZ4xRdfDBBQekQ7eMBG2H0=; b=Q6KyzzGehCKpGioFllGiVT5WfVEIYJpQ18HF2htZU9NgeOhHKCbnm2Dur2qXwCScT0 r0lpRzbEBOyxe7tkn8J5GSR0498M1ZdsAmZkGr1OdSQFT5Gl3UAFEe8174muWmztK2Nd +cNh0MaUtLq9ASEAo2VHo6sSdesInNdn6WHKrP+VHBCw+SpOUsrNFvQ5mdjmHWyjLrAH KD1lxQhpvPhhfOwXAnjY+B49jNq4DdPzLFkgM8BeVoS1c5lFYCF0B1pM5dmDsrpUdZmv g3NhOXzMgxxt9Yext9PkDLGNQh5utssAe7KVwYfYagaBAWsrxW92rCsVkWLaC+rHXmwY uTsw==
X-Gm-Message-State: ALoCoQnatZG6BLy7SJv7ATWAH2vYKy8j5xWcmO8tESJrc1bbEKAv7AnEP4G9QoLNBmtkPuq/ntkN
X-Received: by 10.194.2.240 with SMTP id 16mr8520852wjx.108.1421972651340; Thu, 22 Jan 2015 16:24:11 -0800 (PST)
MIME-Version: 1.0
Received: by 10.27.142.215 with HTTP; Thu, 22 Jan 2015 16:23:31 -0800 (PST)
In-Reply-To: <201501221918.56994.davemgarrett@gmail.com>
References: <40128f312378442fbd26459bf5d7593b@usma1ex-dag1mb2.msg.corp.akamai.com> <39B8BC24-D539-456F-970B-B11665B0E892@gmail.com> <54C0B783.2060604@metaparadigm.com> <201501221918.56994.davemgarrett@gmail.com>
From: Eric Rescorla 
Date: Thu, 22 Jan 2015 16:23:31 -0800
Message-ID: 
To: Dave Garrett 
Content-Type: multipart/alternative; boundary=047d7b343d84c38cbf050d46ce69
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Jan 2015 00:24:15 -0000

--047d7b343d84c38cbf050d46ce69
Content-Type: text/plain; charset=UTF-8

Sorry I've been AWOL here. I'll try to take a look at it this weekend.

If the chairs wanted to review these PRs and confirm that they match the
WG consensus, that would save me some time.

-Ekr


On Thu, Jan 22, 2015 at 4:18 PM, Dave Garrett 
wrote:

> On Thursday, January 22, 2015 03:40:35 am Michael Clark wrote:
> > = TLSv1.3 implementations could remove SSLv3.0 support such that
> >   the minimum TLS record layer version for TLS 1.3 is 1.0 { 3, 1 }
> >   instead of { 3, 0 } which is mentioned in the Appendix as a
> >   "typical value" and the maximum "message layer" version a server
> >   accepts is specified as { 3, XX }. A TLSv1.2 client could send
> >   { 3, 1 } { 3, 3 } and a TLSv1.3 client would send { 3, 1 } { 3, 4 }
> >   in its ClientHello to support TLSv1.0 through TLSv1.2/3. This accords
> >   with protocol major/minor best practices for binary changes and
> >   backwards compatibility. i.e. no binary incompatible changes in minor
> >   versions. Just raise non-compliance with Appendix E.1 as a bug.
> [...]
> > The core issue is Appendix E does not make explicit a protocol version
> > deprecation mechanism. It seems TLSv1.3 { 3, 4 } should specify a
> > lower bound of { 3, 1 } for the record layer TLS version in the
> > ClientHello as they are the same major version (in reality).
> > The fact that SSLv3.0 has partial record layer binary compatibility
> > is a red herring. We should notionally subtract { 2, 1 }.
> > SSLv3.0 is past the used by date.
>
> I have PRs to deal with this area in TLS 1.3 still pending a decision. The
> current version is the consensus from the previous discussion on the topic.
>
> https://github.com/tlswg/tls13-spec/pull/105
> https://github.com/tlswg/tls13-spec/pull/107
>
> The changes are to prohibit SSL negotiation, drop SSL2 hello format
> documentation, freeze record layer hello version to 3.1, as well as other
> editorial improvements.
>
> I haven't heard back from ekr in a couple weeks.
>
>
> Dave
>

--047d7b343d84c38cbf050d46ce69
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Sorry I've been AWOL here. I'll try to take a look=
 at it this weekend.

If the chairs wanted to review thes=
e PRs and confirm that they match the
WG consensus, that would sa=
ve me some time.

-Ekr


On Thu, =
Jan 22, 2015 at 4:18 PM, Dave Garrett <davemgarrett@gmail.com>=
 wrote:
On Thursd=
ay, January 22, 2015 03:40:35 am Michael Clark wrote:

> =3D TLSv1.3 implementations could remove SSLv3.0 support such that

>=C2=A0 =C2=A0the minimum TLS record layer version for TLS 1.3 is 1.0 { =
3, 1 }

>=C2=A0 =C2=A0instead of { 3, 0 } which is mentioned in the Appendix as =
a

>=C2=A0 =C2=A0"typical value" and the maximum "message la=
yer" version a server

>=C2=A0 =C2=A0accepts is specified as { 3, XX }. A TLSv1.2 client could =
send

>=C2=A0 =C2=A0{ 3, 1 } { 3, 3 } and a TLSv1.3 client would send { 3, 1 }=
 { 3, 4 }

>=C2=A0 =C2=A0in its ClientHello to support TLSv1.0 through TLSv1.2/3. T=
his accords

>=C2=A0 =C2=A0with protocol major/minor best practices for binary change=
s and

>=C2=A0 =C2=A0backwards compatibility. i.e. no binary incompatible chang=
es in minor

>=C2=A0 =C2=A0versions. Just raise non-compliance with Appendix E.1 as a=
 bug.

[...]

> The core issue is Appendix E does not make explicit a=
 protocol version

> deprecation mechanism. It seems TLSv1.3 { 3, 4 } should specify a

> lower bound of { 3, 1 } for the record layer TLS version in the

> ClientHello as they are the same major version (in reality).

> The fact that SSLv3.0 has partial record layer binary compatibility
> is a red herring. We should notionally subtract { 2, 1 }.

> SSLv3.0 is past the used by date.



I have PRs to deal with this area in TLS 1.3 still pending a decisio=
n. The

current version is the consensus from the previous discussion on the topic.=




=
https://github.com/tlswg/tls13-spec/pull/105

=
https://github.com/tlswg/tls13-spec/pull/107



The changes are to prohibit SSL negotiation, drop SSL2 hello format

documentation, freeze record layer hello version to 3.1, as well as other
editorial improvements.



I haven't heard back from ekr in a couple weeks.





Dave





--047d7b343d84c38cbf050d46ce69--


From nobody Thu Jan 22 18:33:40 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DDC41B2B9D for ; Thu, 22 Jan 2015 18:33:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.667
X-Spam-Level: 
X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-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 ySAZMiYk4vC6 for ; Thu, 22 Jan 2015 18:33:34 -0800 (PST)
Received: from tlsx.org (tlsx.org [67.207.128.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5D281A8917 for ; Thu, 22 Jan 2015 18:33:33 -0800 (PST)
Received: from monty.local (unknown.maxonline.com.sg [58.182.168.20] (may be forged)) (authenticated bits=0) by tlsx.org (8.14.4/8.14.4/Debian-4) with ESMTP id t0N2tJA3015301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 23 Jan 2015 02:55:23 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=metaparadigm.com; s=klaatu; t=1421981726; bh=ZlqIqyER2mQABEipKWJEh9vA01LL1ZlRk9FBw45+oAg=; h=Date:From:To:Subject:References:In-Reply-To:From; b=rCXWKG4wPPUy4KikYoUOsYfj39JvdmxfkNSMNjFxZotvepgLSVBFvtdOLmHdEbaMW x6JxXgtMG5Y7IB4aBbkBB0dg5na97zm8GegZsiRWPhCHT724qdDbG/vwJ7N9Z5SC/f E6MJqbNubzLg8YjUv/xgMBUN7aZ30ld/rVFHN/7o=
Message-ID: <54C1B2EC.2060507@metaparadigm.com>
Date: Fri, 23 Jan 2015 10:33:16 +0800
From: Michael Clark 
Organization: Metaparadigm
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Bodo Moeller , "tls@ietf.org" 
References: <40128f312378442fbd26459bf5d7593b@usma1ex-dag1mb2.msg.corp.akamai.com>	<20150119192701.190C71B0FF@ld9781.wdf.sap.corp>			<04690E05-4905-4941-A60D-7BC5CDC93431@gmail.com>		<39B8BC24-D539-456F-970B-B11665B0E892@gmail.com>	<54C0B783.2060604@metaparadigm.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------060606010809030104040309"
X-Virus-Scanned: clamav-milter 0.98.4 at klaatu.tlsx.org
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Jan 2015 02:33:36 -0000

This is a multi-part message in MIME format.
--------------060606010809030104040309
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 23/1/15 12:59 am, Bodo Moeller wrote:
> Michael Clark  >:
> =20
>
>     + SCSV served a purpose of a mitigation while clients downgraded
>       due to version upgrade intolerant servers. It may have served its=

>       purpose. Don't downgrade and there is no attack vector
>
>
> This is certainly true, but note that all the major browsers
> (including the current release of Mozilla Firefox) still *do*
> downgrade. Firefox has plans to disable the downgrade dance by
> default, but there'll still be a user setting for this, and various
> users may (have to) set this.  Not downgrading isn't entirely science
> fiction any more, but it ain't over until the fat lady sings.
>
> Not having to do downgrade retries is the right goal, but when we have
> achieved that, having the SCSV logic dormant in servers is really a
> minor low-complexity addition to the protocol that won't do any harm,
> and may (or may not) turn out to be useful again in the future.

I agree with you. Ideally a standards track draft should not codify a
workaround. People make mistakes. I'm not suggesting SCSV is a mistake.
It appears to be a workaround. We're humans.

If we have the ears (or eyes) of the standards group then I think
working towards downgrade avoidance and adding an extension to indicate
acceptable versions is a cleaner long term solution. If a server replies
with the version it uses on the record layer in an extension and we know
this is signed in verify_data then this serves an almost equivalent
purpose of SCSV but is much more explicit and offers a deprecation
mechanism that will be useful in the future. IMHO a cleaner mitigation.
Sure I understand the context that mitigation often needs to be deployed
in a hurry so I am sure everyone has consideration of that.

However this is my thinking, which was modified by the comments of others=
=2E

A).

    1). Codify use of a "Supported TLS Versions Extension" with either a
strong recommendation for a minimum of TLSv1.0 { 3, 1 } to deprecate SSLv=
3.0
        * Advisory to recommend the record layer ClientHello version be
fixed to the lower bound { 3, 0 } ; which there seems to be some
consensus for
        * In the case where the extension is echoed. i.e. supported, the
record layer version is echoed by the server and signed in the handshake.=

        * This is TLSv1.0 through TLSv1.2 compatible via extension
tolerance. i.e. All TLS implementations can benefit from it.

And in TLSv1.3, where payload can be changed, and extensions can be
mandated, without breaking backwards compatibility, it also makes sense t=
o:

B).

    1). MUST Codify use of a "Supported TLS Versions Extension" with
either a strong recommendation or MUST for a minimum of TLSv1.0 { 3, 1 }
to deprecate SSLv3.0
        * In the case where the extension is echoed. i.e. the lower
bound is signed in the handshake.
        * This provides administrators with a clear indication of
supported versions and the ability to set their lower bound
        * This is TLSv1.0 through TLSv1.2 compatible via extension
tolerance.
        * Complete deprecation of SSLv3.0 would like be achieved by the
time TLSv1.3 is in the wild.

    2). MUST tighten the wording with respect to the ClientHello record
layer and message layer versions
        * Fix the record layer ClientHello version to the lower bound {
3, 0 } ; which there seems to be some consensus for
        * This is TLSv1.0 through TLSv1.2 compatible via extension
tolerance.

    3). MUST Extend the TLSv1.3 verify_data size from 12 octets to >=3D16=

octets
        * In the TLSv1.3 time frame we are approaching a point where (
handshakes * ( 2^12) / ( 2^96 ) ) becomes a potentially exploitable weakn=
ess
        * The wording that defers to the cipher suite for
verify_data_length should be changed.

    4). MUST Include the entire handshake record layer rather than
content in the veryify_data hash
        * While this is a duplication of the mitigation in A.1, it is in
fact the real fix and the "Supported TLS Versions Extension" becomes an
indicator
        * "Supported TLS Versions Extension" would echoed to indicate
the lower bound and { 3, 0 } would be fixed at record layer.
        * Reasoning: The fact a mitigation is deployed (for backwards
compatibility) should not prevent the standard from deploying the real fi=
x.
        * TLSv1.3 has an opportunity to change content layer semantics
of the handshake hash without breaking backwards compatibility
        * It needs to be tight { 3, 1} lower bound via extension and at
the same time loose { 3, 0 } in record layer for inclusive backwards and
forwards compatibility.

This is my analysis (plastic based on new information discovery); and I
realize my MUSTs may be different from the standards track or chair.

I still need to read the handshake hash code in one of the open
implementations. i.e. to prove at least to myself the core issue is
Hash(handshake_messages) vs Hash(handshake_records).

I read Hash(handshake_messages) which is a little ambiguous or a little
mistake. We're all human.

Below is a work in progress patch for 3). and 4).

Cheers,
Michael.

--- a/draft-ietf-tls-tls13.md
+++ b/draft-ietf-tls-tls13.md
@@ -2674,7 +2674,7 @@ Structure of this message:
=20
=20
 verify_data
-:      PRF(hs_master_secret, finished_label, Hash(handshake_messages))
+:      PRF(hs_master_secret, finished_label, Hash(handshake_records))
              [0..verify_data_length-1];
=20
 finished_label
@@ -2691,7 +2691,7 @@ Finished computation.
 > In previous versions of TLS, the verify_data was always 12 octets long=
=2E In
 the current version of TLS, it depends on the cipher suite. Any cipher s=
uite
 which does not explicitly specify verify_data_length has a verify_data_l=
ength
-equal to 12. This includes all existing cipher suites. Note that this
+equal to 16. This includes all existing cipher suites. Note that this
 representation has the same encoding as with previous versions. Future c=
ipher
 suites MAY specify other lengths but such length MUST be at least 12 byt=
es.



--------------060606010809030104040309
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 23/1/15 12:59 am, Bodo Moeller
      wrote:

    

    

      

        

          
Michael Clark <michael@metaparadigm.com>:
            
 

            
+
              SCSV served a purpose of a mitigation while clients
              downgraded

                due to version upgrade intolerant servers. It may have
              served its

                purpose. Don't downgrade and there is no attack vector

            


            

            
This is certainly true, but note that all the major
              browsers (including the current release of Mozilla
              Firefox) still *do* downgrade. Firefox has plans to
              disable the downgrade dance by default, but there'll still
              be a user setting for this, and various users may (have
              to) set this.  Not downgrading isn't entirely science
              fiction any more, but it ain't over until the fat lady
              sings.

            


            

            
Not having to do downgrade retries is the right goal,
              but when we have achieved that, having the SCSV logic
              dormant in servers is really a minor low-complexity
              addition to the protocol that won't do any harm, and may
              (or may not) turn out to be useful again in the future.

          

        

      

    

    

    I agree with you. Ideally a standards track draft should not codify
    a workaround. People make mistakes. I'm not suggesting SCSV is a
    mistake. It appears to be a workaround. We're humans.

    

    If we have the ears (or eyes) of the standards group then I think
    working towards downgrade avoidance and adding an extension to
    indicate acceptable versions is a cleaner long term solution. If a
    server replies with the version it uses on the record layer in an
    extension and we know this is signed in verify_data then this serves
    an almost equivalent purpose of SCSV but is much more explicit and
    offers a deprecation mechanism that will be useful in the future.
    IMHO a cleaner mitigation. Sure I understand the context that
    mitigation often needs to be deployed in a hurry so I am sure
    everyone has consideration of that.

    

    However this is my thinking, which was modified by the comments of
    others.

    

    A).

    

        1). Codify use of a "Supported TLS Versions Extension" with
    either a strong recommendation for a minimum of TLSv1.0 { 3, 1 } to
    deprecate SSLv3.0

            * Advisory to recommend the record layer ClientHello version
    be fixed to the lower bound { 3, 0 } ; which there seems to be some
    consensus for

            * In the case where the extension is echoed. i.e. supported,
    the record layer version is echoed by the server and signed in the
    handshake.

            * This is TLSv1.0 through TLSv1.2 compatible via extension
    tolerance. i.e. All TLS implementations can benefit from it.

    

    And in TLSv1.3, where payload can be changed, and extensions can be
    mandated, without breaking backwards compatibility, it also makes
    sense to:

    

    B).

    

        1). MUST Codify use of a "Supported TLS Versions Extension" with
    either a strong recommendation or MUST for a minimum of TLSv1.0 { 3,
    1 } to deprecate SSLv3.0

            * In the case where the extension is echoed. i.e. the lower
    bound is signed in the handshake.

            * This provides administrators with a clear indication of
    supported versions and the ability to set their lower bound

            * This is TLSv1.0 through TLSv1.2 compatible via extension
    tolerance.

            * Complete deprecation of SSLv3.0 would like be achieved by
    the time TLSv1.3 is in the wild.

    

        2). MUST tighten the wording with respect to the ClientHello
    record layer and message layer versions

            * Fix the record layer ClientHello version to the lower
    bound { 3, 0 } ; which there seems to be some consensus for

            * This is TLSv1.0 through TLSv1.2 compatible via extension
    tolerance.

    

        3). MUST Extend the TLSv1.3 verify_data size from 12 octets to
    >=16 octets

            * In the TLSv1.3 time frame we are approaching a point where
    ( handshakes * ( 2^12) / ( 2^96 ) ) becomes a potentially
    exploitable weakness

            * The wording that defers to the cipher suite for
    verify_data_length should be changed.

    

        4). MUST Include the entire handshake record layer rather than
    content in the veryify_data hash

            * While this is a duplication of the mitigation in A.1, it
    is in fact the real fix and the "Supported TLS Versions Extension"
    becomes an indicator

            * "Supported TLS Versions Extension" would echoed to
    indicate the lower bound and { 3, 0 } would be fixed at record
    layer.

            * Reasoning: The fact a mitigation is deployed (for
    backwards compatibility) should not prevent the standard from
    deploying the real fix.

            * TLSv1.3 has an opportunity to change content layer
    semantics of the handshake hash without breaking backwards
    compatibility

            * It needs to be tight { 3, 1} lower bound via extension and
    at the same time loose { 3, 0 } in record layer for inclusive
    backwards and forwards compatibility.

    

    This is my analysis (plastic based on new information discovery);
    and I realize my MUSTs may be different from the standards track or
    chair.

    

    I still need to read the handshake hash code in one of the open
    implementations. i.e. to prove at least to myself the core issue is
    Hash(handshake_messages) vs Hash(handshake_records).

    

    I read Hash(handshake_messages) which is a little ambiguous or a
    little mistake. We're all human.

    

    Below is a work in progress patch for 3). and 4).

    

    Cheers,

    Michael.

    

    
--- a/draft-ietf-tls-tls13.md
+++ b/draft-ietf-tls-tls13.md
@@ -2674,7 +2674,7 @@ Structure of this message:
 
 
 verify_data
-:      PRF(hs_master_secret, finished_label, Hash(handshake_messages))
+:      PRF(hs_master_secret, finished_label, Hash(handshake_records))
              [0..verify_data_length-1];
 
 finished_label
@@ -2691,7 +2691,7 @@ Finished computation.
 > In previous versions of TLS, the verify_data was always 12 octets long. In
 the current version of TLS, it depends on the cipher suite. Any cipher suite
 which does not explicitly specify verify_data_length has a verify_data_length
-equal to 12. This includes all existing cipher suites. Note that this
+equal to 16. This includes all existing cipher suites. Note that this
 representation has the same encoding as with previous versions. Future cipher
 suites MAY specify other lengths but such length MUST be at least 12 bytes.



    

  


--------------060606010809030104040309--


From nobody Thu Jan 22 18:40:56 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7A61B2BAF for ; Thu, 22 Jan 2015 18:40:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.668
X-Spam-Level: 
X-Spam-Status: No, score=-1.668 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-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 czTyidfaix6w for ; Thu, 22 Jan 2015 18:40:52 -0800 (PST)
Received: from tlsx.org (tlsx.org [67.207.128.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E3A51A8AF0 for ; Thu, 22 Jan 2015 18:40:52 -0800 (PST)
Received: from monty.local (unknown.maxonline.com.sg [58.182.168.20] (may be forged)) (authenticated bits=0) by tlsx.org (8.14.4/8.14.4/Debian-4) with ESMTP id t0N32gUm015333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 23 Jan 2015 03:02:46 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=metaparadigm.com; s=klaatu; t=1421982167; bh=xv0sJkcCR0EIGzmVmV71QXQtaCAb48KTL5zS/1lcOXg=; h=Date:From:To:Subject:References:In-Reply-To:From; b=Hxgsg76q+4LWrpWx5u2B+gKAGAqft4V2uo8Vk1aajNTGn7Ug9ZBsbsw2y7H7O3COS wO55LVRNU2ybpXdFYJ/Vw8wtbX3lXhCRIYqOMl5zX7BSaf4mMS3yeTpcNSrvCiTU0O li0SDHnv/wguCdUeysPJnG0Ba71UGuz5hSn1NuX8=
Message-ID: <54C1B4A7.2040205@metaparadigm.com>
Date: Fri, 23 Jan 2015 10:40:39 +0800
From: Michael Clark 
Organization: Metaparadigm
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Bodo Moeller , "tls@ietf.org" 
References: <40128f312378442fbd26459bf5d7593b@usma1ex-dag1mb2.msg.corp.akamai.com>	<20150119192701.190C71B0FF@ld9781.wdf.sap.corp>			<04690E05-4905-4941-A60D-7BC5CDC93431@gmail.com>		<39B8BC24-D539-456F-970B-B11665B0E892@gmail.com>	<54C0B783.2060604@metaparadigm.com>  <54C1B2EC.2060507@metaparadigm.com>
In-Reply-To: <54C1B2EC.2060507@metaparadigm.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.98.4 at klaatu.tlsx.org
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Jan 2015 02:40:54 -0000

On 23/1/15 10:33 am, Michael Clark wrote:
> --- a/draft-ietf-tls-tls13.md
> +++ b/draft-ietf-tls-tls13.md
> @@ -2674,7 +2674,7 @@ Structure of this message:
>  
>  
>  verify_data
> -:      PRF(hs_master_secret, finished_label, Hash(handshake_messages))
> +:      PRF(hs_master_secret, finished_label, Hash(handshake_records))
>               [0..verify_data_length-1];
>  
>  finished_label
> @@ -2691,7 +2691,7 @@ Finished computation.
>  > In previous versions of TLS, the verify_data was always 12 octets long. In
>  the current version of TLS, it depends on the cipher suite. Any cipher suite
>  which does not explicitly specify verify_data_length has a verify_data_length
> -equal to 12. This includes all existing cipher suites. Note that this
> +equal to 16. This includes all existing cipher suites. Note that this
>  representation has the same encoding as with previous versions. Future cipher
>  suites MAY specify other lengths but such length MUST be at least 12 bytes.

Extending verify_data obviously pushes on he lower bound of the
protection bits offered by the lowest asymmetric encryption or
pre-shared key size allowed in TLSv1.3 so that should probably be advised.

I'll leave it up to the experts to decide whether my patch is appropriate.

I made a mistake and missed a second occurrence of 12. Here is a re-spin
of the Hash verify_data patch.

--- a/draft-ietf-tls-tls13.md
+++ b/draft-ietf-tls-tls13.md
@@ -2674,7 +2674,7 @@ Structure of this message:
 
 
 verify_data
-:      PRF(hs_master_secret, finished_label, Hash(handshake_messages))
+:      PRF(hs_master_secret, finished_label, Hash(handshake_records))
              [0..verify_data_length-1];
 
 finished_label
@@ -2691,9 +2691,9 @@ Finished computation.
 > In previous versions of TLS, the verify_data was always 12 octets long. In
 the current version of TLS, it depends on the cipher suite. Any cipher suite
 which does not explicitly specify verify_data_length has a verify_data_length
-equal to 12. This includes all existing cipher suites. Note that this
+equal to 16. This includes all existing cipher suites. Note that this
 representation has the same encoding as with previous versions. Future cipher
-suites MAY specify other lengths but such length MUST be at least 12 bytes.
+suites MAY specify other lengths but such length MUST be at least 16 bytes.
 
 handshake_messages



From nobody Thu Jan 22 19:48:35 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 828871A0125 for ; Thu, 22 Jan 2015 19:48:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.458
X-Spam-Level: 
X-Spam-Status: No, score=-1.458 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=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 1zTnTC9O8wYb for ; Thu, 22 Jan 2015 19:48:32 -0800 (PST)
Received: from tlsx.org (tlsx.org [67.207.128.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDB951A0130 for ; Thu, 22 Jan 2015 19:48:31 -0800 (PST)
Received: from monty.local (unknown.maxonline.com.sg [58.182.168.20] (may be forged)) (authenticated bits=0) by tlsx.org (8.14.4/8.14.4/Debian-4) with ESMTP id t0N4AICq015489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 23 Jan 2015 04:10:22 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=metaparadigm.com; s=klaatu; t=1421986224; bh=9p7NdCOurf42ul+mlJ51jDxf3Kh9GTqvLyHhPuE+XQU=; h=Date:From:To:Subject:References:In-Reply-To:From; b=Fnlm3OgKvKuybujI8cdHpE2r3vwqv7iWpHutOzfnHCgXj3O2ikaDFJ6onB5gP75wt AEgd6J4HAN+bpHDvAOtCCrmLO5CB8mQBm7kRk9ejs+vj2cwIAARzWp6ukEzPIb8Yfc feLfXLSAPmxZc7iPjc7iPFq3LBDd8QStjIARUWkU=
Message-ID: <54C1C47F.1010605@metaparadigm.com>
Date: Fri, 23 Jan 2015 11:48:15 +0800
From: Michael Clark 
Organization: Metaparadigm
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: "tls@ietf.org" , Nikos Mavrogiannopoulos ,  Dave Garrett , Bodo Moeller 
References: <40128f312378442fbd26459bf5d7593b@usma1ex-dag1mb2.msg.corp.akamai.com>	<20150119192701.190C71B0FF@ld9781.wdf.sap.corp>			<04690E05-4905-4941-A60D-7BC5CDC93431@gmail.com>		<39B8BC24-D539-456F-970B-B11665B0E892@gmail.com>	<54C0B783.2060604@metaparadigm.com>  <54C1B2EC.2060507@metaparadigm.com>
In-Reply-To: <54C1B2EC.2060507@metaparadigm.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
X-Virus-Scanned: clamav-milter 0.98.4 at klaatu.tlsx.org
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Jan 2015 03:48:33 -0000

On 23/1/15 10:33 am, Michael Clark wrote:
> However this is my thinking, which was modified by the comments of othe=
rs.
>
> A).
>
>     1). Codify use of a "Supported TLS Versions Extension" with either
> a strong recommendation for a minimum of TLSv1.0 { 3, 1 } to deprecate
> SSLv3.0
>         * Advisory to recommend the record layer ClientHello version
> be fixed to the lower bound { 3, 0 } ; which there seems to be some
> consensus for
>         * In the case where the extension is echoed. i.e. supported,
> the record layer version is echoed by the server and signed in the
> handshake.
>         * This is TLSv1.0 through TLSv1.2 compatible via extension
> tolerance. i.e. All TLS implementations can benefit from it.
>
> And in TLSv1.3, where payload can be changed, and extensions can be
> mandated, without breaking backwards compatibility, it also makes
> sense to:
>
> B).
>
>     1). MUST Codify use of a "Supported TLS Versions Extension" with
> either a strong recommendation or MUST for a minimum of TLSv1.0 { 3, 1
> } to deprecate SSLv3.0
>         * In the case where the extension is echoed. i.e. the lower
> bound is signed in the handshake.
>         * This provides administrators with a clear indication of
> supported versions and the ability to set their lower bound
>         * This is TLSv1.0 through TLSv1.2 compatible via extension
> tolerance.
>         * Complete deprecation of SSLv3.0 would like be achieved by
> the time TLSv1.3 is in the wild.
>
>     2). MUST tighten the wording with respect to the ClientHello
> record layer and message layer versions
>         * Fix the record layer ClientHello version to the lower bound
> { 3, 0 } ; which there seems to be some consensus for
>         * This is TLSv1.0 through TLSv1.2 compatible via extension
> tolerance.


Based on Nikos's comment there needs to be a clarification on the
mitigation track (for TLSv1.0 through TLSv1.2) vs standards track (for
TLSv1.3) on whether the ClientHello "record layer" lower bound is { 3, 0
} or { 3, 1 } and this could potentially be different in TLSv1.3?

=46rom my read, it seems in the time frame of current mitigations (SVSC i=
n
the field or Nikos's "Supported Versions Extension" as a more elegant
forwards and backwards compatible version signalling mechanism). Nikos
was pushing on { 3, 0 } for a current lower bound (at the record layer)
for TLSv1.0 through TLSv1.2 as { 3, 1 } at the record layer in the
current time-frame *allegedly* causes dancing for a few remaining
upgrade recalcitrant servers. i.e. causing problems in the wild. This
was my read.

So the decision remains whether { 3, 0 } or { 3, 1 } is the "record
layer" lower bound in TLSv1.3; depending on whether mitigation
propagation has made provision for the lower bound to be raised to { 3,
1 } in TLSv1.3. Implementors tried { 3, 1 } and Nikos disagreed and said
this compounded the dancing issue. We proposed a compromise that is both
forwards and backwards compatible and it happened to match something
Nikos had previously proposed. It was to pin { 3, 0 } at the record
layer (essentially making the protocol major version the record layer
version as opposed to TLSv1.0 { 3, 1 } ; this is in fact a record layer
binary compatibility boundary) and listing "Supported TLS Versions
Extension" with { 3, 1 } as a mandatory lower bound (ignored by the
recalcitrant servers). This allows someone unwise to add SSLv3 { 3, 0 }
to "Supported Versions" if they want to support it, but most importantly
lets you signal { 3, 1 } as a signed lower bound in any TLS version (1.0
through 1.3) while showing { 3, 0 } at the record layer for
compatibility. This seems ideal.

I understand this is issue is already mitigated where it is important
(using SVSC or other tightening mechanisms) rather the mechanism is
completely not standardized.

Sorry I am on the temporal track, not the standards track. I'll read
these pull requests:

  https://github.com/tlswg/tls13-spec/pull/105
  https://github.com/tlswg/tls13-spec/pull/107

Thanks for clarifications.



From nobody Fri Jan 23 07:37:22 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 031B91A9235 for ; Fri, 23 Jan 2015 07:37:21 -0800 (PST)
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, 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 5wR_RehkDp5v for ; Fri, 23 Jan 2015 07:37:20 -0800 (PST)
Received: from maple.randombit.net (maple.randombit.net [66.228.45.112]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF67A1A9218 for ; Fri, 23 Jan 2015 07:37:13 -0800 (PST)
Received: from oak.randombit.net (oak.randombit.net [50.116.63.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by maple.randombit.net (Postfix) with ESMTPS id 39BD61ADB07 for ; Fri, 23 Jan 2015 10:37:12 -0500 (EST)
Received: by oak.randombit.net (sSMTP sendmail emulation); Fri, 23 Jan 2015 10:37:11 -0500
From: "Jack Lloyd" 
Date: Fri, 23 Jan 2015 10:37:11 -0500
To: tls@ietf.org
Message-ID: <20150123153711.GA2758@randombit.net>
Mail-Followup-To: tls@ietf.org
References: <54B5501A.4070402@azet.org> <20150120191819.GA8165@typhoon.azet.org> <20150121222748.GA30732@randombit.net> <54C03D10.1090201@azet.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <54C03D10.1090201@azet.org>
X-PGP-Fingerprint: 3F69 2E64 6D92 3BBE E7AE 9258 5C0F 96E8 4EC1 6D6B
X-PGP-Key: http://www.randombit.net/pgpkey.html
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Jan 2015 15:37:21 -0000

On Thu, Jan 22, 2015 at 12:58:08AM +0100, Aaron Zauner wrote:

> I'm in the process of editing the draft and will add this information to
> it. Do you want to suggest a paragraph/sentence or do you think this
> will suffice for implementors?

Just that statement probably is sufficient, but to minimize the number
of misinterpretations possible maybe something like this is better -

"""
The nonce input to the AEAD is described above using the TLS
presentation language. All values are represented in big-endian form
when constructing the AEAD input.

The sequence number of a message is always known to the receiver
through other means (either implicit protocol state or a per-message
header in the case of DTLS), so the nonce construction used does not
require any extra per-message information. Thus the record_iv_length
is zero (0) for all ciphersuites defined in this document.
"""

Cheers,
  Jack


From nobody Fri Jan 23 07:59:49 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 923D31A8AE7 for ; Fri, 23 Jan 2015 07:59:47 -0800 (PST)
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 oDsyl1S9pAmY for ; Fri, 23 Jan 2015 07:59:46 -0800 (PST)
Received: from mail-we0-f174.google.com (mail-we0-f174.google.com [74.125.82.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 148321A911E for ; Fri, 23 Jan 2015 07:59:46 -0800 (PST)
Received: by mail-we0-f174.google.com with SMTP id x3so8378985wes.5 for ; Fri, 23 Jan 2015 07:59:44 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=HGIFMDE4neuzeApe/pJw1KekawCg7sFbhysiyV0x0pk=; b=Xt8L3oeezVWlyWtBibG0BSrYNPyOdf7PVt0hoSwEt7qmyanVlTnK2Rn+DYDmffKHfZ pAV8dqKhzR5PSDxIugfPzlDUDMz64axnVPN78dPU7X35LP2QbnZuqEHT3pS3ytTTrBUs 41nvDOau+x/G6j+LaJ6IW3IbZJ8SlwsJ270T2yXlSBrnU/us/KLTAhMbG/IJOCS2VK5S XtWEHJ0qHhtcakrlrNYtV0fidjrW9Q881LqSKNuD/mPcUvkhV1VdCxOqyR7l8gJ78CUX pKbNOouydW5DhGhPlNnJu+VXmtLzLqBuuKMIrfdAeekZFS/sXZZSTbVKyxHBsd8DziT9 UlkQ==
X-Gm-Message-State: ALoCoQkhW9eVQ1G5wVx5Vc930KQ4ZU62gM2y3KVLlpTkpAQGilm8ZbGbG457Sn5xzZwCHcMnjfxI
X-Received: by 10.180.10.131 with SMTP id i3mr5185665wib.54.1422028784857; Fri, 23 Jan 2015 07:59:44 -0800 (PST)
Received: from [10.0.0.112] (chello080108032135.14.11.univie.teleweb.at. [80.108.32.135]) by mx.google.com with ESMTPSA id g10sm2366352wic.7.2015.01.23.07.59.43 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 23 Jan 2015 07:59:43 -0800 (PST)
Message-ID: <54C26FF5.8040506@azet.org>
Date: Fri, 23 Jan 2015 16:59:49 +0100
From: Aaron Zauner 
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: tls@ietf.org
References: <54B5501A.4070402@azet.org> <20150120191819.GA8165@typhoon.azet.org> <20150121222748.GA30732@randombit.net> <54C03D10.1090201@azet.org> <20150123153711.GA2758@randombit.net>
In-Reply-To: <20150123153711.GA2758@randombit.net>
X-Enigmail-Version: 1.2.3
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigB6EBDF0ADBA211FE6C771A95"
Archived-At: 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Jan 2015 15:59:47 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigB6EBDF0ADBA211FE6C771A95
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



Jack Lloyd wrote:
> On Thu, Jan 22, 2015 at 12:58:08AM +0100, Aaron Zauner wrote:
>=20
>> I'm in the process of editing the draft and will add this information =
to
>> it. Do you want to suggest a paragraph/sentence or do you think this
>> will suffice for implementors?
>=20
> Just that statement probably is sufficient, but to minimize the number
> of misinterpretations possible maybe something like this is better -
>=20
> """
> The nonce input to the AEAD is described above using the TLS
> presentation language. All values are represented in big-endian form
> when constructing the AEAD input.
>=20
> The sequence number of a message is always known to the receiver
> through other means (either implicit protocol state or a per-message
> header in the case of DTLS), so the nonce construction used does not
> require any extra per-message information. Thus the record_iv_length
> is zero (0) for all ciphersuites defined in this document.
> """
>=20
Thanks a lot! I'll add those paragraphs to the document. The current
revision has just the single sentence in it.

Aaron


--------------enigB6EBDF0ADBA211FE6C771A95
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUwm/2AAoJEOTbZJL9ubXV+r4P/1SUGtut1jPHTmADt8nfS11G
VcREtueNnVss/DjU3tX4Vm+KMzqTMzr8J1Y3+YCLa9LyopOriX//AClw8QCmNz+b
ggKzncrnL1e/8D/wK6mn+tDKRHnhx0FwxEdPiuuZELIuJZIiMVRIQ/rIAS3wapL6
9Js426RmwY9mlwCroi0zCEfYsnpnBJEVsIbRlrXoVffldMzKHCmfkazziIMcee5j
Sq2HEFcnhwA7dW7+fmf0tlKO9z9jHiDj5SGK3d+LuvKkrD4kBrU/HZu72L4scdKK
akgUFlDfs7PBagZNH1kplT2nEXaBW+RkCNyd2tKZUFOVU7wcYZEEsedNWxhvk2eU
qAe2ZvmZ5CVQ5PE7F3rNt9vcRPbiHJ9Z1EwQxW/kiw4eBQsdmnd0nQs7kJ59KLjx
+nT+gd7y1iGrLu72NaT2UqhFrHKCfRxy+XJWJQ4w1C6o21ufdnjcbYFRwD8tamEl
zOTZIJe6S4jELMVSQ/mR2n8cfvR9Es3hraKdQfPXMdiBm0GY/amfMLg7p1Dy/utl
9PCeRUwIMqRbQCg1tjCHXuKNiV5YVXMqQf6Fv5SUSE1aspd/vcDigb2MK+wNb7cc
bKeRq4bzi0z2iT4dSfwWkrU6VaTKiQX8NiqnfDtcFkYvP200RJs37IpXWUDRWziQ
8bGzq9mUQOaBvm/gCsN6
=SZls
-----END PGP SIGNATURE-----

--------------enigB6EBDF0ADBA211FE6C771A95--


From nobody Fri Jan 23 08:10:35 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B237C1A9170 for ; Fri, 23 Jan 2015 08:10:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.567
X-Spam-Level: 
X-Spam-Status: No, score=-0.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_BARE_IP_2=1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 oT530qvVLIBU for ; Fri, 23 Jan 2015 08:10:29 -0800 (PST)
Received: from gateway09.websitewelcome.com (gateway09.websitewelcome.com [67.18.1.6]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A08D41A924A for ; Fri, 23 Jan 2015 08:10:20 -0800 (PST)
Received: by gateway09.websitewelcome.com (Postfix, from userid 507) id E50AFAF372697; Fri, 23 Jan 2015 10:10:19 -0600 (CST)
Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway09.websitewelcome.com (Postfix) with ESMTP id C505EAF3725B4 for ; Fri, 23 Jan 2015 10:10:19 -0600 (CST)
Received: from [96.231.226.60] (port=60119 helo=192.168.1.2) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1YEgoN-0004Wl-2Q; Fri, 23 Jan 2015 10:10:19 -0600
From: Sean Turner 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Date: Fri, 23 Jan 2015 11:10:16 -0500
To: "TLS@ietf.org (tls@ietf.org)" 
Message-Id: <9A7F583F-A1AB-4EC1-9F36-88E74C5EB9E1@ieca.com>
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator3286.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ieca.com
X-BWhitelist: no
X-Source-IP: 96.231.226.60
X-Exim-ID: 1YEgoN-0004Wl-2Q
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: (192.168.1.2) [96.231.226.60]:60119
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 2
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20=
Archived-At: 
Subject: [TLS] (draft final) ITU Q3/16 Liaison Response
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Jan 2015 16:10:33 -0000

All,

We received a liaison from ITU-T Q3/16 that contain some questions that =
we need to reply to.  Joe and I have drafted a response but would like =
to know if you have any comments on the following before 2015-01-30.  On =
the 30th, we=92ll craft some appropriate liaison language as boiler =
plate and ship it back to the ITU.

Q1-Q4 are their questions and A1-A4 are our responses.

Cheers,

spt

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

Q1.

[What is] the distinction between (D)TLS session and (D)TLS connection =
(which implies a definition for each term, beyond the available =
descriptions / glossary from RFC side).

A1.

A TLS session is shared cryptographic state established by a full TLS =
handshake between two peers.  The session=92s cryptographic state is =
used to establish the cryptographic key material for a TLS connection.  =
A TLS connection is a transport relationship established between two =
peers that contains the cryptographic state to cryptographically protect =
data sent and received on the connection established through a full or =
abbreviated (session resumption) TLS handshake.  A TLS session may span =
one or more TLS connections.  Every TLS connection is associated with =
one TLS session.  If session resumption (abbreviated handshake) is not =
used then the TLS session and TLS connection will essentially be the =
same.  A TLS session is identified by a Session ID in the client and =
server hellos.  A TLS connection is usually identified by a host =
addresses and port numbers.

Q2.

The DTLS association concept, e.g., is it equivalent to a DTLS session =
or DTLS connection or something in addition?

A2.

They are the same.

Q3.

The TLS renegotiation procedure: what is the definition and at which =
level (TLS session or TLS connection level) does this procedure occur?

A3.

The TLS renegotiation procedure establishes new cryptographic state for =
the TLS connection.  It may also establish a new TLS session if the =
renegotiation uses the full TLS handshake. =20
=20
Please note that renegotiation is an optional feature for pre-TLS 1.3 =
clients and servers.

Please also note that renegotiation is being dropped in TLS 1.3.  =
Clients and servers will use a different mechanism to update the =
cryptographic state. =20
=20
Q4.

The TLS resumption procedure: what is the definition and relation to TLS =
renegotiation?

A4.

Resumption refers to the use of the state from an existing TLS session =
to establish a new TLS connection using an abbreviated handshake.  =
During resumption the cryptographic parameters (algorithms etc.) remain =
the same.  TLS renegotiation is the process of executing a new TLS =
handshake to establish new cryptographic parameters for a TLS connection =
(effectively a new TLS connection using the same host addresses and =
ports as the previous one).  If the handshake is a full handshake then =
both a new session and a new connection are established and the =
renegotiated session may have different parameters. =20
=20
Please note that session resumption is an optional feature.=


From nobody Fri Jan 23 08:30:44 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F751A1B06 for ; Fri, 23 Jan 2015 08:30:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level: 
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] 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 AtHyDcM3WSQN for ; Fri, 23 Jan 2015 08:30:42 -0800 (PST)
Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 076871A1A9D for ; Fri, 23 Jan 2015 08:30:42 -0800 (PST)
Received: from [10.20.30.90] (50-1-98-91.dsl.dynamic.fusionbroadband.com [50.1.98.91]) (authenticated bits=0) by proper.com (8.15.1/8.14.7) with ESMTPSA id t0NGUcNo079382 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Jan 2015 09:30:39 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: proper.com: Host 50-1-98-91.dsl.dynamic.fusionbroadband.com [50.1.98.91] claimed to be [10.20.30.90]
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Paul Hoffman 
In-Reply-To: <9A7F583F-A1AB-4EC1-9F36-88E74C5EB9E1@ieca.com>
Date: Fri, 23 Jan 2015 08:30:38 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <3D67EA40-B69C-4621-A377-489E3EE5DF5C@vpnc.org>
References: <9A7F583F-A1AB-4EC1-9F36-88E74C5EB9E1@ieca.com>
To: Sean Turner 
X-Mailer: Apple Mail (2.1993)
Archived-At: 
Cc: "TLS@ietf.org \(tls@ietf.org\)" 
Subject: Re: [TLS] (draft final) ITU Q3/16 Liaison Response
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Jan 2015 16:30:42 -0000

These look good. However, it may be premature to say "renegotiation is =
being dropped in TLS 1.3" since we are far from finishing TLS 1.3. Maybe =
change this to "renegotiation is likely to be dropped in TLS 1.3". =
Similarly, it might be good to add at the end of A4: "Resumption is very =
likely to be changed in TLS 1.3, which is work in progress at this =
time".

--Paul Hoffman


From nobody Fri Jan 23 09:13:38 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 426181A906D for ; Fri, 23 Jan 2015 09:13:38 -0800 (PST)
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 DDFa693arQUN for ; Fri, 23 Jan 2015 09:13:37 -0800 (PST)
Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C43F41A1AD8 for ; Fri, 23 Jan 2015 09:13:36 -0800 (PST)
Received: by mail-yk0-f172.google.com with SMTP id 9so3309984ykp.3 for ; Fri, 23 Jan 2015 09:13:36 -0800 (PST)
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:content-transfer-encoding; bh=/98IdwB8L3QmadpqS6Bzj2QiiwJxYYTscRiF0E/+nQw=; b=IMmhPimIPLtv/LMJEwKPu9AjwHd2HBily2uL/u3eWUeIkDVTNpfr/5d78dwdW7/9R6 8TFr1mLXT4nh7LvkDC+qDgGk8kyoVGmyEVQnBUkOuF8SlLCyISeumhoiWYuCfhRqxJEW fFBcyBxMWhGNEA6lyJ71XBRK84yMlezvfTX2EA2ermo7tzjSSqS0ziqLxdpePE05BqDo pPwVB0rX0tgYDxJDUY6smt0x9SH9Kwmn38LxCjK9doDhXNvNjrNtFiip0/Z1hMwUD1vL M2UwnPuVKWPf7qVyYgJMCZbXp1cF59HgtRkIm4f30BsPs8R8dzUDhUpbXQ0mBQhKQQBx LUPA==
MIME-Version: 1.0
X-Received: by 10.236.7.70 with SMTP id 46mr3804513yho.138.1422033215951; Fri, 23 Jan 2015 09:13:35 -0800 (PST)
Received: by 10.170.115.77 with HTTP; Fri, 23 Jan 2015 09:13:35 -0800 (PST)
In-Reply-To: <3D67EA40-B69C-4621-A377-489E3EE5DF5C@vpnc.org>
References: <9A7F583F-A1AB-4EC1-9F36-88E74C5EB9E1@ieca.com> <3D67EA40-B69C-4621-A377-489E3EE5DF5C@vpnc.org>
Date: Fri, 23 Jan 2015 09:13:35 -0800
Message-ID: 
From: Watson Ladd 
To: Paul Hoffman 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: "TLS@ietf.org \(tls@ietf.org\)" 
Subject: Re: [TLS] (draft final) ITU Q3/16 Liaison Response
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Jan 2015 17:13:38 -0000

I do not understand A2. There are three possible antecedents for they,
and it is not clear which two are the same. Is a DTLS association a
DTLS connection, or is it a DTLS session? Or are DTLS sessions and
associations the same?

A3 needs to be substantially fleshed out: given that sessions are
cryptographic states, doesn't every renegotiation involve a new
session? (I understood the intended answer is that the same connection
changes which session it is a part of, but that session may not be new
as it may be resumed.) A4 does better at this.

On Fri, Jan 23, 2015 at 8:30 AM, Paul Hoffman  wrote=
:
> These look good. However, it may be premature to say "renegotiation is be=
ing dropped in TLS 1.3" since we are far from finishing TLS 1.3. Maybe chan=
ge this to "renegotiation is likely to be dropped in TLS 1.3". Similarly, i=
t might be good to add at the end of A4: "Resumption is very likely to be c=
hanged in TLS 1.3, which is work in progress at this time".
>
> --Paul Hoffman
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



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


From nobody Fri Jan 23 09:21:32 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 029841A1B06 for ; Fri, 23 Jan 2015 09:21:31 -0800 (PST)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 gBQIHsLDOGEg for ; Fri, 23 Jan 2015 09:21:28 -0800 (PST)
Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 569F51A8848 for ; Fri, 23 Jan 2015 09:21:28 -0800 (PST)
Received: by mail-qa0-f47.google.com with SMTP id n8so6757807qaq.6 for ; Fri, 23 Jan 2015 09:21:27 -0800 (PST)
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=2vEfmca4CSt+Nb16frifN173qh2OOCrfE3KXxFVELgs=; b=QH4gf3tefc1PDjtdLrNGO/dJVCiiQTk/ZzQAhzklaYnxaJ9xymf+whF5r7yGYTtgMs rYFbMiL4bziCbUXD4d7Wr56YNyi/2SpyZg6SknA0GOWh63UhbD3WQmTTfDDw+hNW/2yN s+SC6v7oCAwT8pVO2fBF9PYxFRPSYEcwcKvIdgS5RpOxb8ZowuL3HYGg545jhModkxgT VnkwLjwr6hUuLeg4Ub++x7k7gK4NfWgAr0f1WeuHdKzPIi8fgOPhYXNghysjvcC6O3Uf NQ9yF+GmKSAk2psQ74q+DVBDhoejwGUuFIv4oIUF5aSbbx+ifAqZG9EdnSInkc6afP39 86cQ==
X-Gm-Message-State: ALoCoQlRYG5M58GTiMKqbo8Hq4Wp6/ab3E83l6rGisHvAmU0H5DzlqpG+thyUnC8hqlnLTjr80Y1
MIME-Version: 1.0
X-Received: by 10.140.107.164 with SMTP id h33mr15699037qgf.71.1422033687567;  Fri, 23 Jan 2015 09:21:27 -0800 (PST)
Received: by 10.96.238.73 with HTTP; Fri, 23 Jan 2015 09:21:27 -0800 (PST)
X-Originating-IP: [50.206.82.141]
In-Reply-To: 
References: <9A7F583F-A1AB-4EC1-9F36-88E74C5EB9E1@ieca.com> <3D67EA40-B69C-4621-A377-489E3EE5DF5C@vpnc.org> 
Date: Fri, 23 Jan 2015 09:21:27 -0800
Message-ID: 
From: Joseph Salowey 
To: Watson Ladd 
Content-Type: multipart/alternative; boundary=001a113a6cfcce78a0050d5504a0
Archived-At: 
Cc: Paul Hoffman , "TLS@ietf.org \(tls@ietf.org\)" 
Subject: Re: [TLS] (draft final) ITU Q3/16 Liaison Response
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Jan 2015 17:21:31 -0000

--001a113a6cfcce78a0050d5504a0
Content-Type: text/plain; charset=UTF-8

On Fri, Jan 23, 2015 at 9:13 AM, Watson Ladd  wrote:

> I do not understand A2. There are three possible antecedents for they,
> and it is not clear which two are the same. Is a DTLS association a
> DTLS connection, or is it a DTLS session? Or are DTLS sessions and
> associations the same?
>
>
[Joe] Good catch. It should say that associations are the same as TLS
connections.


> A3 needs to be substantially fleshed out: given that sessions are
> cryptographic states, doesn't every renegotiation involve a new
> session? (I understood the intended answer is that the same connection
> changes which session it is a part of, but that session may not be new
> as it may be resumed.) A4 does better at this.
>
>
[Joe] Maybe we should just use the text in A4 as the response to both Q3
and Q4.

A3 and A4:

Resumption refers to the use of the state from an existing TLS session to
establish a new TLS connection using an abbreviated handshake.  During
resumption the cryptographic parameters (algorithms etc.) remain the same.
TLS renegotiation is the process of executing a new TLS handshake to
establish new cryptographic parameters for a TLS connection (effectively a
new TLS connection using the same host addresses and ports as the previous
one).  If the handshake is a full handshake then both a new session and a
new connection are established and the renegotiated session may have
different parameters.

Please note that session resumption and renegotiation are optional
features.  Session resumption is very likely to be changed in TLS 1.3,
which is work in progress at this time




> On Fri, Jan 23, 2015 at 8:30 AM, Paul Hoffman 
> wrote:
> > These look good. However, it may be premature to say "renegotiation is
> being dropped in TLS 1.3" since we are far from finishing TLS 1.3. Maybe
> change this to "renegotiation is likely to be dropped in TLS 1.3".
> Similarly, it might be good to add at the end of A4: "Resumption is very
> likely to be changed in TLS 1.3, which is work in progress at this time".
> >
> > --Paul Hoffman
> >
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
>
>
>
> --
> "Those who would give up Essential Liberty to purchase a little
> Temporary Safety deserve neither  Liberty nor Safety."
> -- Benjamin Franklin
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--001a113a6cfcce78a0050d5504a0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Fri, Jan 23, 2015 at 9:13 AM, Watson Ladd <watsonbladd@gmail.co=
m> wrote:
I do not understand A2. There a=
re three possible antecedents for they,

and it is not clear which two are the same. Is a DTLS association a

DTLS connection, or is it a DTLS session? Or are DTLS sessions and

associations the same?



[Joe] Good catch. It should say that a=
ssociations are the same as TLS connections. =C2=A0
=C2=A0
<=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa=
dding-left:1ex">
A3 needs to be substantially fleshed out: given that sessions are

cryptographic states, doesn't every renegotiation involve a new

session? (I understood the intended answer is that the same connection

changes which session it is a part of, but that session may not be new

as it may be resumed.) A4 does better at this.




[Joe] Maybe we s=
hould just use the text in A4 as the response to both Q3 and Q4. =C2=A0

A3 and A4:

Resumption refers to the use of the state from an existing TL=
S session to establish a new TLS connection using an abbreviated handshake.=
=C2=A0 During resumption the cryptographic parameters (algorithms etc.) rem=
ain the same.=C2=A0 TLS renegotiation is the process of executing a new TLS=
 handshake to establish new cryptographic parameters for a TLS connection (=
effectively a new TLS connection using the same host addresses and ports as=
 the previous one).=C2=A0 If the handshake is a full handshake then both a =
new session and a new connection are established and the renegotiated sessi=
on may have different parameters.

Please note that sess=
ion resumption and renegotiation are optional features.=C2=A0 Session resumption is very likely to be changed in=
 TLS 1.3, which is work in progress at this time

<=
/div>

=C2=A0

On Fri, Jan 23, 2015 at 8:30 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:

> These look good. However, it may be premature to say "renegotiati=
on is being dropped in TLS 1.3" since we are far from finishing TLS 1.=
3. Maybe change this to "renegotiation is likely to be dropped in TLS =
1.3". Similarly, it might be good to add at the end of A4: "Resum=
ption is very likely to be changed in TLS 1.3, which is work in progress at=
 this time".

>

> --Paul Hoffman

>

> _______________________________________________

> TLS mailing list

> TLS@ietf.org

> https://www.ietf.org/mailman/listinfo/tls








--

"Those who would give up Essential Liberty to purchase a little

Temporary Safety deserve neither=C2=A0 Liberty nor Safety."

-- Benjamin Franklin




_______________________________________________

TLS mailing list

TLS@ietf.org

htt=
ps://www.ietf.org/mailman/listinfo/tls





--001a113a6cfcce78a0050d5504a0--


From nobody Fri Jan 23 10:27:34 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE6CA1A86F0 for ; Fri, 23 Jan 2015 10:27:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.901
X-Spam-Level: 
X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_BARE_IP_2=1, RCVD_IN_DNSWL_NONE=-0.0001, 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 8vxSVCX_VSbn for ; Fri, 23 Jan 2015 10:27:13 -0800 (PST)
Received: from gateway02.websitewelcome.com (gateway02.websitewelcome.com [74.52.222.226]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E36AE1A8701 for ; Fri, 23 Jan 2015 10:27:05 -0800 (PST)
Received: by gateway02.websitewelcome.com (Postfix, from userid 5007) id 6401732D0B57E; Fri, 23 Jan 2015 12:27:04 -0600 (CST)
Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway02.websitewelcome.com (Postfix) with ESMTP id 3CA4432D0B531 for ; Fri, 23 Jan 2015 12:27:04 -0600 (CST)
Received: from [96.231.226.60] (port=60495 helo=192.168.1.2) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1YEiwh-0008Hp-6X; Fri, 23 Jan 2015 12:27:03 -0600
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Sean Turner 
In-Reply-To: <3D67EA40-B69C-4621-A377-489E3EE5DF5C@vpnc.org>
Date: Fri, 23 Jan 2015 13:27:01 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <36C47478-CE96-4869-AF67-B0ED1309FB65@ieca.com>
References: <9A7F583F-A1AB-4EC1-9F36-88E74C5EB9E1@ieca.com> <3D67EA40-B69C-4621-A377-489E3EE5DF5C@vpnc.org>
To: Paul Hoffman 
X-Mailer: Apple Mail (2.1878.6)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator3286.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ieca.com
X-BWhitelist: no
X-Source-IP: 96.231.226.60
X-Exim-ID: 1YEiwh-0008Hp-6X
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: (192.168.1.2) [96.231.226.60]:60495
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 2
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20=
Archived-At: 
Cc: "TLS@ietf.org \(tls@ietf.org\)" 
Subject: Re: [TLS] (draft final) ITU Q3/16 Liaison Response
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Jan 2015 18:27:14 -0000

On Jan 23, 2015, at 11:30, Paul Hoffman  wrote:

> These look good. However, it may be premature to say "renegotiation is =
being dropped in TLS 1.3" since we are far from finishing TLS 1.3. Maybe =
change this to "renegotiation is likely to be dropped in TLS 1.3". =
Similarly, it might be good to add at the end of A4: "Resumption is very =
likely to be changed in TLS 1.3, which is work in progress at this =
time".
>=20
> --Paul Hoffman

Yeah that=92s a good point, we=92re not done with TLS1.3 so we shouldn=92t=
 presuppose how it=92s going to turn out.

spt


From nobody Fri Jan 23 11:29:59 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B33231ACEDD for ; Fri, 23 Jan 2015 11:29:37 -0800 (PST)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 J0Fh7YSNlJ6U for ; Fri, 23 Jan 2015 11:29:36 -0800 (PST)
Received: from mail-qc0-f174.google.com (mail-qc0-f174.google.com [209.85.216.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D811C1ACEF7 for ; Fri, 23 Jan 2015 11:29:34 -0800 (PST)
Received: by mail-qc0-f174.google.com with SMTP id s11so7939269qcv.5 for ; Fri, 23 Jan 2015 11:29:34 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=UHq7VHznAMS9YfOiDoqdewbL7OBqNPcpW9TiQHodj30=; b=ZkKGugPfRjkSvuoO49GfDh5zRC49YgAAMVjanPwBNV4pMsTaSpiieHHl8VivJ4janD HDfFYZek7vlOoPAt/a6bBzXZnCYbacHD1+D1IR2Lu4rFQ2EopE2f+AUP7PzYHryQ5Tyz +LA+hCrOD9nd7Pq89KZ15jOHl52ArOFAQbHbGijzWacpYzgxE+7xC/Gbe/TQd2cvXE9K YL/ERhPShxqp7ImluMDRLOfHtVnm30+YTP+wViRXdaTtR1lsOa5V6P4EJIatirNRkeJL FK/qDLDOuDS/PRZHnJkWVRLzu2TTzq6S+58vpnK4kBw/ca5bJb2GL5kGMTE9uZUy4ap8 L6fQ==
X-Gm-Message-State: ALoCoQnr78IqvGHWz9cqGrbQkaTJpBSHyrkKmk3FkJyYjrpv4rcEjMRbCK7bCpPH/PzyAWo9aY/Q
MIME-Version: 1.0
X-Received: by 10.229.65.133 with SMTP id j5mr17419499qci.27.1422041374106; Fri, 23 Jan 2015 11:29:34 -0800 (PST)
Received: by 10.96.238.73 with HTTP; Fri, 23 Jan 2015 11:29:34 -0800 (PST)
X-Originating-IP: [50.206.82.141]
Date: Fri, 23 Jan 2015 11:29:34 -0800
Message-ID: 
From: Joseph Salowey 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11339d1ef5bfa7050d56ce49
Archived-At: 
Subject: [TLS] Working Group Last Call for draft-ietf-tls-sslv3-diediedie-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Jan 2015 19:29:37 -0000

--001a11339d1ef5bfa7050d56ce49
Content-Type: text/plain; charset=UTF-8

This is a working group last call for draft-ietf-tls-sslv3-diediedie-00.
Please reply to the TLS working group list with an indication of whether or
not the draft is ready for publication and any other comments you may
have.  Please respond by February 16, 2015.

Thanks,

S & J

--001a11339d1ef5bfa7050d56ce49
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


This is a working group last=
 call for=C2=A0draft-ietf-tls-sslv3-diediedie-00.=C2=A0 Please reply to the=
 TLS working group list with an indication of whether or not the draft is r=
eady for publication and any other comments you may have.=C2=A0 Please resp=
ond by February 16, 2015. =C2=A0

Thanks,

S & J=C2=A0


--001a11339d1ef5bfa7050d56ce49--


From nobody Fri Jan 23 11:31:06 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAB9A1ACEEB for ; Fri, 23 Jan 2015 11:30:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.567
X-Spam-Level: 
X-Spam-Status: No, score=-0.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_BARE_IP_2=1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 qDwWgUFdqU8B for ; Fri, 23 Jan 2015 11:30:45 -0800 (PST)
Received: from gateway03.websitewelcome.com (gateway03.websitewelcome.com [69.93.66.24]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF7331ACEFD for ; Fri, 23 Jan 2015 11:30:45 -0800 (PST)
Received: by gateway03.websitewelcome.com (Postfix, from userid 5007) id 37593E5394E26; Fri, 23 Jan 2015 13:30:45 -0600 (CST)
Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway03.websitewelcome.com (Postfix) with ESMTP id 24B03E5394D51 for ; Fri, 23 Jan 2015 13:30:45 -0600 (CST)
Received: from [96.231.226.60] (port=60652 helo=192.168.1.2) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1YEjwK-0008O8-BN for tls@ietf.org; Fri, 23 Jan 2015 13:30:44 -0600
From: Sean Turner 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Message-Id: <3F4C76ED-4375-438F-ADC9-66E49A19574B@ieca.com>
Date: Fri, 23 Jan 2015 14:30:42 -0500
To: "TLS@ietf.org (tls@ietf.org)" 
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator3286.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ieca.com
X-BWhitelist: no
X-Source-IP: 96.231.226.60
X-Exim-ID: 1YEjwK-0008O8-BN
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: (192.168.1.2) [96.231.226.60]:60652
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 7
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20=
Archived-At: 
Subject: [TLS] WGLC:  draft-ietf-tls-negotiated-ff-dhe-05
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Jan 2015 19:30:46 -0000

This is the WGLC (working group last call) for =
draft-ietf-tls-negotiated-ff-dhe-05:
http://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe-05/
Please send comments on this draft to the TLS list before February 16, =
2015.

The chairs and our AD are curious about whether switching to use of =93e=94=
 as opposed to =93pi=94, as RFC 3526 did, is an issue.  The draft =
provides rationale for the change, but Stephen asked about this =
particular point @ our Hawaii session.

spt=


From nobody Fri Jan 23 11:32:10 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7585C1ACEDD for ; Fri, 23 Jan 2015 11:31:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.151
X-Spam-Level: 
X-Spam-Status: No, score=-5.151 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 p3ixFul54hCe for ; Fri, 23 Jan 2015 11:31:46 -0800 (PST)
Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3AD81A212A for ; Fri, 23 Jan 2015 11:31:45 -0800 (PST)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 81BDC3A44D; Fri, 23 Jan 2015 20:31:43 +0100 (CET)
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 7843542D73; Fri, 23 Jan 2015 20:31:43 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 7251A1B117; Fri, 23 Jan 2015 20:31:43 +0100 (CET)
In-Reply-To: <54C1B2EC.2060507@metaparadigm.com>
To: Michael Clark 
Date: Fri, 23 Jan 2015 20:31:43 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20150123193143.7251A1B117@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Jan 2015 19:31:48 -0000

Michael Clark wrote:
> 
>     4). MUST Include the entire handshake record layer rather than
> content in the veryify_data hash


Excuse me while I panic.

There seems to be a complete misunderstanding of the TLS protocol.
The TLS record protocol was *INTENTED* to be independent of the
protocol inside (handshake, appdata, alerts, ccs).


> --- a/draft-ietf-tls-tls13.md
> +++ b/draft-ietf-tls-tls13.md
> @@ -2674,7 +2674,7 @@ Structure of this message:
>  
>  
>  verify_data
> -:      PRF(hs_master_secret, finished_label, Hash(handshake_messages))
> +:      PRF(hs_master_secret, finished_label, Hash(handshake_records))
>               [0..verify_data_length-1];


This would be totally wrong.

The TLS record layer protocol was designed to be independent of the
protocols within ON PURPOSE.  In particular, the TLS record protocol
is independent from the protocol within about fragmenting and coalescing
data.

Look at the TLS protocol handshake flowchart:

https://tools.ietf.org/html/rfc2246#page-31

     Client                                               Server

      ClientHello                  -------->
                                                      ServerHello
                                                     Certificate*
                                               ServerKeyExchange*
                                              CertificateRequest*
                                   <--------      ServerHelloDone
      Certificate*
      ClientKeyExchange
      CertificateVerify*
      [ChangeCipherSpec]
      Finished                     -------->
                                               [ChangeCipherSpec]
                                   <--------             Finished
      Application Data             <------->     Application Data


How the TLS record layer packages the initial response from the server
to the client into TLS records, is entirely up to the TLS record layer
and irrelevant to the computation of handshake message hash and the
TLS finished handshake messages:

                                                     ServerHello
                                                     Certificate*
                                               ServerKeyExchange*
                                              CertificateRequest*
                                                 ServerHelloDone

i.e. whether each handshake message is packaged into a seperate TLS record,
whether some or all of them are stuffed into one record -- and where
exactly the fragmentation will occur if the maximum TLS plaintext size
(2^14 = 16384 bytes) is reached, is entirely at the discretion of the
TLS record layer, and the TLS handshake protocol engine does not know
or care about it.   This complete independence is likely also the
reason why ChangeCipherSpec is a seperate content type (this forces
flushing of the record layer buffers, because the record layer might
want to coalesce handshake messages, e.g. in the abbreviated handshake
for the server response:

      Client                                                Server

      ClientHello                   -------->
                                                       ServerHello
                                                [ChangeCipherSpec]
                                    <--------             Finished


While this might not be an issue for TLSv1.3 when Renegotiation is dropped
-- completely ignoring additional HelloRequests from the server would
not be possible if the handshake message hash would cover *EVERYTHING*
rather than only the handshake messages that belong to the current
handshake.


-Martin


From nobody Fri Jan 23 11:43:24 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48EEE1A0025 for ; Fri, 23 Jan 2015 11:43:03 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, 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 BKwM3DHVq0L5 for ; Fri, 23 Jan 2015 11:43:01 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0126.outbound.protection.outlook.com [207.46.100.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B06C1A001B for ; Fri, 23 Jan 2015 11:43:01 -0800 (PST)
Received: from BN3PR0301MB1250.namprd03.prod.outlook.com (25.161.207.26) by BN3PR0301MB1251.namprd03.prod.outlook.com (25.161.207.27) with Microsoft SMTP Server (TLS) id 15.1.59.20; Fri, 23 Jan 2015 19:43:00 +0000
Received: from BN3PR0301MB1250.namprd03.prod.outlook.com ([25.161.207.26]) by BN3PR0301MB1250.namprd03.prod.outlook.com ([25.161.207.26]) with mapi id 15.01.0059.007; Fri, 23 Jan 2015 19:43:00 +0000
From: Andrei Popov 
To: Joseph Salowey , "tls@ietf.org" 
Thread-Topic: [TLS] Working Group Last Call for draft-ietf-tls-sslv3-diediedie-00
Thread-Index: AQHQN0L/qaSWNUCDHEGCBJr1ylY4wJzOGpag
Date: Fri, 23 Jan 2015 19:42:58 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e8:ed31::2]
authentication-results: salowey.net; dkim=none (message not signed) header.d=none;salowey.net; dmarc=none action=none header.from=microsoft.com;
x-dmarcaction-test: None
x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:BN3PR0301MB1251;
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1251; 
x-forefront-prvs: 0465429B7F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(377454003)(76576001)(74316001)(19580395003)(2950100001)(2900100001)(102836002)(62966003)(77156002)(2501002)(15975445007)(122556002)(46102003)(87936001)(19625215002)(106116001)(33656002)(16236675004)(19300405004)(92566002)(54206007)(19580405001)(54606007)(40100003)(230783001)(2656002)(86612001)(107886001)(54356999)(76176999)(86362001)(50986999)(99286002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1251; H:BN3PR0301MB1250.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB12503ACE01AC0CED0E73B9168C360BN3PR0301MB1250_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jan 2015 19:42:58.9173 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1251
Archived-At: 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-sslv3-diediedie-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Jan 2015 19:43:03 -0000

--_000_BN3PR0301MB12503ACE01AC0CED0E73B9168C360BN3PR0301MB1250_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SeKAmW0gaW4gZnVsbCBzdXBwb3J0LCBsZXTigJlzIGdldCByaWQgb2YgU1NMLg0KDQpDaGVlcnMs
DQoNCkFuZHJlaQ0KDQpGcm9tOiBUTFMgW21haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZ10gT24g
QmVoYWxmIE9mIEpvc2VwaCBTYWxvd2V5DQpTZW50OiBGcmlkYXksIEphbnVhcnkgMjMsIDIwMTUg
MTE6MzAgQU0NClRvOiB0bHNAaWV0Zi5vcmcNClN1YmplY3Q6IFtUTFNdIFdvcmtpbmcgR3JvdXAg
TGFzdCBDYWxsIGZvciBkcmFmdC1pZXRmLXRscy1zc2x2My1kaWVkaWVkaWUtMDANCg0KVGhpcyBp
cyBhIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGZvciBkcmFmdC1pZXRmLXRscy1zc2x2My1kaWVk
aWVkaWUtMDAuICBQbGVhc2UgcmVwbHkgdG8gdGhlIFRMUyB3b3JraW5nIGdyb3VwIGxpc3Qgd2l0
aCBhbiBpbmRpY2F0aW9uIG9mIHdoZXRoZXIgb3Igbm90IHRoZSBkcmFmdCBpcyByZWFkeSBmb3Ig
cHVibGljYXRpb24gYW5kIGFueSBvdGhlciBjb21tZW50cyB5b3UgbWF5IGhhdmUuICBQbGVhc2Ug
cmVzcG9uZCBieSBGZWJydWFyeSAxNiwgMjAxNS4NCg0KVGhhbmtzLA0KDQpTICYgSg0K

--_000_BN3PR0301MB12503ACE01AC0CED0E73B9168C360BN3PR0301MB1250_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9
DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj
b2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz
cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv
cjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxl
MTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli
cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t
c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp
Zjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEu
MGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj
dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm
YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48
IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv
OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh
W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZs
aW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SeKAmW0gaW4gZnVsbCBzdXBw
b3J0LCBsZXTigJlzIGdldCByaWQgb2YgU1NMLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7
Y29sb3I6IzFGNDk3RCI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6
IzFGNDk3RCI+QW5kcmVpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3Nw
YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFRMUyBbbWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3Jn
XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Kb3NlcGggU2Fsb3dleTxicj4NCjxiPlNlbnQ6PC9iPiBG
cmlkYXksIEphbnVhcnkgMjMsIDIwMTUgMTE6MzAgQU08YnI+DQo8Yj5Ubzo8L2I+IHRsc0BpZXRm
Lm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbVExTXSBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCBm
b3IgZHJhZnQtaWV0Zi10bHMtc3NsdjMtZGllZGllZGllLTAwPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5U
aGlzIGlzIGEgd29ya2luZyBncm91cCBsYXN0IGNhbGwgZm9yJm5ic3A7ZHJhZnQtaWV0Zi10bHMt
c3NsdjMtZGllZGllZGllLTAwLiZuYnNwOyBQbGVhc2UgcmVwbHkgdG8gdGhlIFRMUyB3b3JraW5n
IGdyb3VwIGxpc3Qgd2l0aCBhbiBpbmRpY2F0aW9uIG9mIHdoZXRoZXIgb3Igbm90IHRoZSBkcmFm
dCBpcyByZWFkeSBmb3IgcHVibGljYXRpb24gYW5kIGFueSBvdGhlciBjb21tZW50cw0KIHlvdSBt
YXkgaGF2ZS4mbmJzcDsgUGxlYXNlIHJlc3BvbmQgYnkgRmVicnVhcnkgMTYsIDIwMTUuICZuYnNw
OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+UyAmYW1wOyBKJm5ic3A7
PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K
PC9odG1sPg0K

--_000_BN3PR0301MB12503ACE01AC0CED0E73B9168C360BN3PR0301MB1250_--


From nobody Fri Jan 23 11:50:43 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA631A000C for ; Fri, 23 Jan 2015 11:50:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Level: 
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 DyD-4qswfiGL for ; Fri, 23 Jan 2015 11:50:17 -0800 (PST)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A71A1A014E for ; Fri, 23 Jan 2015 11:50:17 -0800 (PST)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id AA7D83A33F; Fri, 23 Jan 2015 20:50:15 +0100 (CET)
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 7071D42D7A; Fri, 23 Jan 2015 20:50:15 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 65F081B118; Fri, 23 Jan 2015 20:50:15 +0100 (CET)
In-Reply-To: <36C47478-CE96-4869-AF67-B0ED1309FB65@ieca.com>
To: Sean Turner 
Date: Fri, 23 Jan 2015 20:50:15 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20150123195015.65F081B118@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: 
Cc: Paul Hoffman , "TLS@ietf.org \(tls@ietf.org\)" 
Subject: Re: [TLS] (draft final) ITU Q3/16 Liaison Response
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Jan 2015 19:50:19 -0000

Sean Turner wrote:
> Paul Hoffman  wrote:
>> 
>> These look good. However, it may be premature to say
>>    "renegotiation is being dropped in TLS 1.3"
>> since we are far from finishing TLS 1.3. Maybe change this to
>>     "renegotiation is likely to be dropped in TLS 1.3".
> 
> Yeah that's a good point, we're not done with TLS1.3 so we
> shouldn't presuppose how it's going to turn out.


You probably should also take into account that TLSv1.2 (rfc5246)
"highly recommends" supporting TLS renegotiation:

https://tools.ietf.org/html/rfc5246#appendix-D.4

   D.4.  Implementation Pitfalls

     [...]

   -  Do you support renegotiation, both client and server initiated?
      While renegotiation is an optional feature, supporting it is
      highly recommended.


While you can get away with (and are better off) with _not_ supporting
renegotiation on the server side, you may encounter frequent interop problems
when you do not implement it on the client side -- because it is used
by a lot of servers (at least in TLS).

Some TLS clients even have serious difficulties dealing properly
with a CertificateRequest handshake message in the initial handshake,
because there seem to be more sites requesting client certificates
through renegotiation than in the initial handshake.


-Martin


From nobody Fri Jan 23 11:55:09 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE24B1A0181 for ; Fri, 23 Jan 2015 11:54:50 -0800 (PST)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 M4BBKWTAQn0x for ; Fri, 23 Jan 2015 11:54:49 -0800 (PST)
Received: from mail-qg0-f43.google.com (mail-qg0-f43.google.com [209.85.192.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78B3F1A017A for ; Fri, 23 Jan 2015 11:54:49 -0800 (PST)
Received: by mail-qg0-f43.google.com with SMTP id e89so7726998qgf.2 for ; Fri, 23 Jan 2015 11:54:48 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=uPzhfGGAXYsvBJEnSzeNVz6XE2wiJJKa0nELPqP591Q=; b=cSU3f3ccSzIwKFOq93GUPiBoRemxHtsJdR+pv8vnei73VAxs+rCCXf/sfGTTWEr+qP VBBeLkKmgdwcNwsI6fHKbHKXtKEonQuPQvEN2ok6Sxf/jt79585NRvK71ATFigusb4z+ 0wuwXi/9yC43zwhDI9TAuPIbZDRW+6wJop4Ib5i7RNkSasV+6CjmflMdG6myD/3ZbGjr fANpb1FBHqW/tIps3gmo86ghxWLR9RfY3RLgwNs69dwXZx5Rr7CENTsRWLfp6P7fuifF nqQZYVdLS5HGDNJYB5n6tJUsIO0G61JgEb8jFiSfQpph2LNR9nodcK+Fs6yS9W9YnJXt ZDnQ==
X-Gm-Message-State: ALoCoQldtV7gtwqx6LzOTBAfLo3RuwEwsjAEvrhhRJJ6Wt56j7uIATaXq/kCvLT1U0rUR71zf7D9
MIME-Version: 1.0
X-Received: by 10.224.112.9 with SMTP id u9mr11254243qap.18.1422042888713; Fri, 23 Jan 2015 11:54:48 -0800 (PST)
Received: by 10.96.238.73 with HTTP; Fri, 23 Jan 2015 11:54:48 -0800 (PST)
X-Originating-IP: [50.206.82.141]
Date: Fri, 23 Jan 2015 11:54:48 -0800
Message-ID: 
From: Joseph Salowey 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11c2d62e3ce78f050d5729c2
Archived-At: 
Subject: [TLS] TLS Face-to-Facce Interim in March
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Jan 2015 19:54:51 -0000

--001a11c2d62e3ce78f050d5729c2
Content-Type: text/plain; charset=UTF-8

We'd like to have another face-to-face interim in March.  I'm proposing to
have the interim Seattle area.  The preferred dates are 3/5 and 3/6, but
3/9-3/11 are options as well.  I've set up a Doodle poll to see how many
folks can make this time.

http://doodle.com/fe84eh263zfv73rs

If you are interested in attending this meeting please enter your
availability by Friday, January 30, 2015.

Thanks,

Joe

--001a11c2d62e3ce78f050d5729c2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


We'd like to have anoth=
er face-to-face interim in March.=C2=A0 I'm proposing to have the inter=
im Seattle area.=C2=A0 The preferred dates are 3/5 and 3/6, but 3/9-3/11 ar=
e options as well.=C2=A0 I've set up a Doodle poll to see how many folk=
s can make this time. =C2=A0

=


If you are i=
nterested in attending this meeting please enter your availability by Frida=
y, January 30, 2015.=C2=A0

Thanks,

<=
/div>
Joe


--001a11c2d62e3ce78f050d5729c2--


From nobody Fri Jan 23 11:55:32 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 134611A01F0 for ; Fri, 23 Jan 2015 11:55:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 LtS8yGZWKvGR for ; Fri, 23 Jan 2015 11:55:16 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0718.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:718]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6241C1A0195 for ; Fri, 23 Jan 2015 11:55:16 -0800 (PST)
Received: from BN3PR0301MB1252.namprd03.prod.outlook.com (25.161.207.28) by BN3PR0301MB0833.namprd03.prod.outlook.com (25.160.154.143) with Microsoft SMTP Server (TLS) id 15.1.65.19; Fri, 23 Jan 2015 19:54:53 +0000
Received: from BN3PR0301MB1250.namprd03.prod.outlook.com (25.161.207.26) by BN3PR0301MB1252.namprd03.prod.outlook.com (25.161.207.28) with Microsoft SMTP Server (TLS) id 15.1.59.20; Fri, 23 Jan 2015 19:54:52 +0000
Received: from BN3PR0301MB1250.namprd03.prod.outlook.com ([25.161.207.26]) by BN3PR0301MB1250.namprd03.prod.outlook.com ([25.161.207.26]) with mapi id 15.01.0059.007; Fri, 23 Jan 2015 19:54:52 +0000
From: Andrei Popov 
To: Sean Turner , "TLS@ietf.org (tls@ietf.org)" 
Thread-Topic: [TLS] WGLC:  draft-ietf-tls-negotiated-ff-dhe-05
Thread-Index: AQHQN0MnOO68smN3ukGG1Zv1jxiD35zOG+TQ
Date: Fri, 23 Jan 2015 19:54:52 +0000
Message-ID: 
References: <3F4C76ED-4375-438F-ADC9-66E49A19574B@ieca.com>
In-Reply-To: <3F4C76ED-4375-438F-ADC9-66E49A19574B@ieca.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e8:ed31::2]
authentication-results: ieca.com; dkim=none (message not signed) header.d=none;ieca.com; dmarc=none action=none header.from=microsoft.com;
x-dmarcaction-test: None
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(3005004); SRVR:BN3PR0301MB1252; UriScan:; 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1252; 
x-forefront-prvs: 0465429B7F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(164054003)(92566002)(33656002)(86362001)(62966003)(54606007)(54356999)(76176999)(50986999)(40100003)(122556002)(2900100001)(54206007)(76576001)(15975445007)(2950100001)(77156002)(86612001)(74316001)(46102003)(2656002)(87936001)(99286002)(230783001)(102836002)(107886001)(106116001)(19580395003)(19580405001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1252; H:BN3PR0301MB1250.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jan 2015 19:54:52.5209 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1252
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB0833;
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: 
Subject: Re: [TLS] WGLC:  draft-ietf-tls-negotiated-ff-dhe-05
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Jan 2015 19:55:20 -0000

Good draft, we need strong DH groups, and a way to negotiate them is a usef=
ul, too.

One change I would suggest is to avoid special-form primes.

Thanks,

Andrei

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Sean Turner
Sent: Friday, January 23, 2015 11:31 AM
To: TLS@ietf.org (tls@ietf.org)
Subject: [TLS] WGLC: draft-ietf-tls-negotiated-ff-dhe-05

This is the WGLC (working group last call) for draft-ietf-tls-negotiated-ff=
-dhe-05:
http://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe-05/
Please send comments on this draft to the TLS list before February 16, 2015=
.

The chairs and our AD are curious about whether switching to use of "e" as =
opposed to "pi", as RFC 3526 did, is an issue.  The draft provides rational=
e for the change, but Stephen asked about this particular point @ our Hawai=
i session.

spt
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


From nobody Fri Jan 23 12:05:36 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 864C21A1ADA for ; Fri, 23 Jan 2015 12:05:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.133
X-Spam-Level: **
X-Spam-Status: No, score=2.133 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FSL_HELO_BARE_IP_2=1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 en-wwP2F_ZOv for ; Fri, 23 Jan 2015 12:05:08 -0800 (PST)
Received: from gateway14.websitewelcome.com (gateway14.websitewelcome.com [67.18.72.130]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5FBB1A1ADC for ; Fri, 23 Jan 2015 12:04:57 -0800 (PST)
Received: by gateway14.websitewelcome.com (Postfix, from userid 5007) id 2064E8F9D1C7A; Fri, 23 Jan 2015 14:04:57 -0600 (CST)
Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway14.websitewelcome.com (Postfix) with ESMTP id 0D72F8F9D1BB3 for ; Fri, 23 Jan 2015 14:04:57 -0600 (CST)
Received: from [96.231.226.60] (port=60853 helo=192.168.1.2) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1YEkTQ-0008Qn-DM; Fri, 23 Jan 2015 14:04:56 -0600
From: Sean Turner 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Date: Fri, 23 Jan 2015 15:04:54 -0500
To: "TLS@ietf.org (tls@ietf.org)" 
Message-Id: 
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator3286.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ieca.com
X-BWhitelist: no
X-Source-IP: 96.231.226.60
X-Exim-ID: 1YEkTQ-0008Qn-DM
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: (192.168.1.2) [96.231.226.60]:60853
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 6
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20=
Archived-At: 
Subject: [TLS] WG adoption of draft-agl-tls-padding
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Jan 2015 20:05:10 -0000

All,

WG adoption of draft-agl-tls-padding [0] seems to have fallen through =
the cracks.  Back in January 2014, the chairs did a call for an early =
code point assignment [1], some changes were discussed and adopted in =
-03, and an early code point assignment was made.  Early code point =
assignments are only temporary (1 year) and to get it permanently =
assigned we need to progress the draft.  Back in January 2014, there was =
a call for objections to WG adoption [2].  There were no objections and =
the draft should have been adopted, but we (the chairs) dropped the ball =
and we=92d like to remedy that by:

- Requesting that Adam submit an -00 WG draft version based on the -03
  of his individual draft to resuscitate it (i.e., change the name to
  draft-ietf-tls-padding - I=92ve already pre-approved that name)
- Adopting -00 as a WG item
- WGLCing -00 shortly thereafter

Thanks,

J&S

[0] http://www.ietf.org/archive/id/draft-agl-tls-padding-03.txt
[1] http://www.ietf.org/mail-archive/web/tls/current/msg11047.html
[2] http://www.ietf.org/mail-archive/web/tls/current/msg11219.html=


From nobody Fri Jan 23 12:46:46 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 061831A3BA2; Fri, 23 Jan 2015 12:46:13 -0800 (PST)
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 gPuaOFQhhAdr; Fri, 23 Jan 2015 12:46:11 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B46D91A212D; Fri, 23 Jan 2015 12:45:58 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.10.0.p8
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150123204558.27071.68478.idtracker@ietfa.amsl.com>
Date: Fri, 23 Jan 2015 12:45:58 -0800
Archived-At: 
Cc: tls@ietf.org
Subject: [TLS] I-D Action: draft-ietf-tls-padding-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Jan 2015 20:46:13 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Transport Layer Security Working Group of the IETF.

        Title           : A TLS padding extension
        Author          : Adam Langley
	Filename        : draft-ietf-tls-padding-00.txt
	Pages           : 4
	Date            : 2015-01-23

Abstract:
   This memo describes the a TLS extension that can be used to pad
   ClientHello messages to a desired size.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-padding/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tls-padding-00


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Fri Jan 23 12:47:20 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 709EA1A6F0E for ; Fri, 23 Jan 2015 12:47:00 -0800 (PST)
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 lLyS4yluSszq for ; Fri, 23 Jan 2015 12:46:58 -0800 (PST)
Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B7FF1A6F07 for ; Fri, 23 Jan 2015 12:46:54 -0800 (PST)
Received: by mail-la0-f50.google.com with SMTP id hs14so3028518lab.9 for ; Fri, 23 Jan 2015 12:46:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ALGZkPqZ4ko2zUV5H4T0F0gO4icsFAakD1+UOJsu/FA=; b=wMo1iyiXlcWMom2/PFkbva4omKKAEOsZQK8JO9ltFKewK/6V3DPe4wRPqiy59MIFvv Ijlg0eFnjpeSUjZ6ooHJQe7AE74rOuRqXdPpsphUjCkW8xqV8B/NtUW6WudwaWWQM3kh YU8k7gl7UddCc8RbiHgY9w2MqaM58OSavBkaHF7lXCaI4uluwCXZagKWfE/6MU9rd1/j o/NLG6PLtGkEMHBAFd0ptFOfATAtGVd7N+B5eo6AoM3gz+D9QvOfYiS7KMWxnvSeXFP8 sgxOp2JlaqaFw3F7wVJZ1QASingZs9iyOS+vl1+upDiKL5AU/mlOSZn6xubB9J66Uovx ftZQ==
MIME-Version: 1.0
X-Received: by 10.153.5.1 with SMTP id ci1mr9139461lad.67.1422046012641; Fri, 23 Jan 2015 12:46:52 -0800 (PST)
Sender: alangley@gmail.com
Received: by 10.112.114.225 with HTTP; Fri, 23 Jan 2015 12:46:52 -0800 (PST)
In-Reply-To: 
References: 
Date: Fri, 23 Jan 2015 12:46:52 -0800
X-Google-Sender-Auth: _pq5gYcme6OC91-XhFVEk7cNBT0
Message-ID: 
From: Adam Langley 
To: Sean Turner 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "TLS@ietf.org \(tls@ietf.org\)" 
Subject: Re: [TLS] WG adoption of draft-agl-tls-padding
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Jan 2015 20:47:00 -0000

On Fri, Jan 23, 2015 at 12:04 PM, Sean Turner  wrote:
> - Requesting that Adam submit an -00 WG draft version based on the -03
>   of his individual draft to resuscitate it (i.e., change the name to

https://datatracker.ietf.org/doc/draft-ietf-tls-padding/


Cheers

AGL

-- 
Adam Langley agl@imperialviolet.org https://www.imperialviolet.org


From nobody Fri Jan 23 13:14:30 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D34921A8AEE for ; Fri, 23 Jan 2015 13:14:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.898
X-Spam-Level: 
X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 rqQ3qgLr-H6B for ; Fri, 23 Jan 2015 13:14:08 -0800 (PST)
Received: from BAY004-OMC1S22.hotmail.com (bay004-omc1s22.hotmail.com [65.54.190.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE29E1A8B84 for ; Fri, 23 Jan 2015 13:14:08 -0800 (PST)
Received: from BAY405-EAS368 ([65.54.190.59]) by BAY004-OMC1S22.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751);  Fri, 23 Jan 2015 13:14:08 -0800
X-TMN: [YNYVM768HVErBJxXBvjffB+20iqcI0yh]
X-Originating-Email: [xiaoyin.l@outlook.com]
Message-ID: 
Content-Type: multipart/related; boundary="_b659cda7-44d5-4a35-bb1f-73ee64607e70_"
MIME-Version: 1.0
To: Joseph Salowey , "tls@ietf.org" 
From: Xiaoyin Liu 
Date: Fri, 23 Jan 2015 16:13:44 -0500
X-OriginalArrivalTime: 23 Jan 2015 21:14:08.0611 (UTC) FILETIME=[86BC4B30:01D03751]
Archived-At: 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-sslv3-diediedie-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Jan 2015 21:14:11 -0000

--_b659cda7-44d5-4a35-bb1f-73ee64607e70_
Content-Type: multipart/alternative;
	boundary="_24a0c690-05a0-4342-add0-207904cc617b_"

--_24a0c690-05a0-4342-add0-207904cc617b_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"

I support this document as well. But I have a question. Since this document=
 prohibits the negotiation of SSL 3.0 from all versions of TLS=2C should it=
 also update RFC4346 (TLS 1.1) and RFC2246 (TLS 1.0)?

Thanks=2C
Xiaoyin
________________________________
From: Joseph Salowey
Sent: =E2=80=8E1/=E2=80=8E23/=E2=80=8E2015 14:30
To: tls@ietf.org
Subject: [TLS] Working Group Last Call for draft-ietf-tls-sslv3-diediedie-0=
0

This is a working group last call for draft-ietf-tls-sslv3-diediedie-00.
Please reply to the TLS working group list with an indication of whether or
not the draft is ready for publication and any other comments you may
have.  Please respond by February 16=2C 2015.

Thanks=2C

S & J

--_24a0c690-05a0-4342-add0-207904cc617b_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="utf-8"









I su=
pport this document as well. But I have a question. Since this document pro=
hibits the negotiation of SSL 3.0 from all versions of TLS=2C should it als=
o update RFC4346 (TLS 1.1) and RFC2246 (TLS
 1.0)?



Thanks=2C

Xiaoyin 







From:
Joseph Salowey

Sent:
=E2=80=8E1/=E2=80=8E23/=E2=80=8E2015 14:30

To:
tls@ietf.org

Subject:
[TLS] Working Group Last Call for draft-ietf-tls-sslv3-diediedie-00










This is a working group last call for =3B=
draft-ietf-tls-sslv3-diediedie-00. =3B Please reply to the TLS working =
group list with an indication of whether or not the draft is ready for publ=
ication and any other comments you may have. =3B Please
 respond by February 16=2C 2015.  =3B







Thanks=2C







S &=3B J =3B








--_24a0c690-05a0-4342-add0-207904cc617b_--

--_b659cda7-44d5-4a35-bb1f-73ee64607e70_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--_b659cda7-44d5-4a35-bb1f-73ee64607e70_--


From nobody Fri Jan 23 13:23:54 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E82A81A9100 for ; Fri, 23 Jan 2015 13:23:40 -0800 (PST)
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 Eyz1LY-rMoFE for ; Fri, 23 Jan 2015 13:23:37 -0800 (PST)
Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF8681A8744 for ; Fri, 23 Jan 2015 13:23:37 -0800 (PST)
Received: by mail-qc0-f177.google.com with SMTP id p6so8405642qcv.8 for ; Fri, 23 Jan 2015 13:23:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=NMcieauDIXJ33jOPV/T1KSJhJaQOiImdSp4P1aga8jE=; b=l84nRGHTst1a4Df8fr4pINIPeXXUwujzYsFVAc1QawnqNY21b/peamcmfCcl4cCttp XKQ6mYipLedqV4W8MYuvAFfl5IzZVCpk0abTocJHuJySB0UgvT2eFPWg2CekoU5i0OeL i/4mVq8sKPwIBldFNZh0EUGqEZYdUjpzMJmNmPT+aJGE0vMqjtK91WrUp16/rVfT7SOW OZfb82gziQd9+gV+7IiE66+Xo/FyIMNLqsDrcRN039d1mPWeet+DpiVoT0wYc9faXJSc Tc+A13KfXyxGttXBb/Ft5wSRjsgc8LtRFhF5nQsrHNKTts5A6D/yZERt1cDjL6c07HQl lwjA==
X-Received: by 10.229.201.6 with SMTP id ey6mr18417754qcb.20.1422048216983; Fri, 23 Jan 2015 13:23:36 -0800 (PST)
Received: from dave-laptop.localnet ([96.245.56.59]) by mx.google.com with ESMTPSA id n4sm688814qac.30.2015.01.23.13.23.36 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 23 Jan 2015 13:23:36 -0800 (PST)
From: Dave Garrett 
To: Adam Langley 
Date: Fri, 23 Jan 2015 16:23:35 -0500
User-Agent: KMail/1.13.5 (Linux/2.6.32-70-generic-pae; KDE/4.4.5; i686; ; )
References:  
In-Reply-To: 
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201501231623.35743.davemgarrett@gmail.com>
Archived-At: 
Cc: tls@ietf.org
Subject: Re: [TLS] WG adoption of draft-agl-tls-padding
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Jan 2015 21:23:41 -0000

On Friday, January 23, 2015 03:46:52 pm Adam Langley wrote:
> On Fri, Jan 23, 2015 at 12:04 PM, Sean Turner  wrote:
> > - Requesting that Adam submit an -00 WG draft version based on the -03
> >   of his individual draft to resuscitate it (i.e., change the name to
> 
> https://datatracker.ietf.org/doc/draft-ietf-tls-padding/

A minor suggestion: rename the document to describe it more precisely. It is currently named "A TLS padding extension", however it's not an extension to add any general padding to TLS itself, rather just the ClientHello. Just changing it to "TLS ClientHello Padding Extension" would describe things better.


Dave


From nobody Fri Jan 23 13:30:32 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1F11A872F for ; Fri, 23 Jan 2015 13:30:13 -0800 (PST)
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 Uy8G8C7XK5-c for ; Fri, 23 Jan 2015 13:30:12 -0800 (PST)
Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D11A81A079D for ; Fri, 23 Jan 2015 13:30:11 -0800 (PST)
Received: by mail-lb0-f172.google.com with SMTP id l4so9239315lbv.3 for ; Fri, 23 Jan 2015 13:30:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=fnjrCpYbG7uhAmxumpfEFMMNCbXS2VTeM0ODuN7pfQQ=; b=rppF1X82NxxyszIOA8F92XZBm3C6+CQoF4L9J1s0RfraNR/i+jXhNHiX4ZgUQuOdeM h1wGCJIlYlg+YkQED1kBWdMVco8DPPvQWYIeAmo9dd1udPYvxpbhzMp65/joEtznLqax +b32N7t3VpceDnopyzTjjqvYkkb1WDaQblpkDhwPQApAbIj20CHBKVUO23d6WqW9pmVR J2+N1wZTBMf7tFVS3AGDLi1JdlC+4qOAvOwjDoJletYsDMfItPQQvgBA3gU7/WR2uIC9 Z/isLeAQTM4AQncAuqsJ+FM4n4srnLsgY36l9loaBSMo+F3tRang4nKsZU60mfUdinyP fd+g==
MIME-Version: 1.0
X-Received: by 10.152.205.75 with SMTP id le11mr9589047lac.20.1422048610361; Fri, 23 Jan 2015 13:30:10 -0800 (PST)
Sender: alangley@gmail.com
Received: by 10.112.114.225 with HTTP; Fri, 23 Jan 2015 13:30:10 -0800 (PST)
In-Reply-To: <201501231623.35743.davemgarrett@gmail.com>
References:   <201501231623.35743.davemgarrett@gmail.com>
Date: Fri, 23 Jan 2015 13:30:10 -0800
X-Google-Sender-Auth: 6LIlCeoT4nMt4_kUc8CJp0qnB9g
Message-ID: 
From: Adam Langley 
To: Dave Garrett 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] WG adoption of draft-agl-tls-padding
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Jan 2015 21:30:13 -0000

On Fri, Jan 23, 2015 at 1:23 PM, Dave Garrett  wrot=
e:
> On Friday, January 23, 2015 03:46:52 pm Adam Langley wrote:
>> On Fri, Jan 23, 2015 at 12:04 PM, Sean Turner  wrote:
>> > - Requesting that Adam submit an -00 WG draft version based on the -03
>> >   of his individual draft to resuscitate it (i.e., change the name to
>>
>> https://datatracker.ietf.org/doc/draft-ietf-tls-padding/
>
> A minor suggestion: rename the document to describe it more precisely. It=
 is currently named "A TLS padding extension", however it's not an extensio=
n to add any general padding to TLS itself, rather just the ClientHello. Ju=
st changing it to "TLS ClientHello Padding Extension" would describe things=
 better.

I think that's a good point. I've started a repo to batch up any
changes, including this one: https://github.com/agl/tls-padding


Cheers

AGL

--=20
Adam Langley agl@imperialviolet.org https://www.imperialviolet.org


From nobody Fri Jan 23 14:16:34 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BEA01AC3E4 for ; Fri, 23 Jan 2015 14:16:33 -0800 (PST)
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 nJj_n8Z8zWbM for ; Fri, 23 Jan 2015 14:16:31 -0800 (PST)
Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1AA01AC3D7 for ; Fri, 23 Jan 2015 14:16:31 -0800 (PST)
Received: by mail-ob0-f169.google.com with SMTP id va8so12346obc.0 for ; Fri, 23 Jan 2015 14:16:31 -0800 (PST)
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=UveEYnROK0/z/Vmr0mmJ2zguV13ylD+59X4edn3TmBo=; b=nKeBqaXQBCkvznUi9EmxQtm+oqAwm2FPhst+Is8BzzZYpFQpSurtlwvth5kCQ/UvhC T4Yf3iC0vi1KQokilxGht9BtTCoyCJZ29fIQ1TENY3mLrmSaJVenwC4hU15kgy4lNvRR vnQIlcPA7+r5VYppIeZRJwr3NTmxSSkb286+Z78DWuzcTkJ5NKqcIuK9gi3v7D/3B1iM 6kniViS7+QbLDzXJJX1LI2gCE56c46syMDZbO2INxWI4dXlNWEEeWGI7KcICPr+WwEm+ QUcqxwpOJjaabjREr7h2AEc65K+5roN5SSuPx+xfmzStB/LCkEHA6eKNQSZkR2PCHad/ +urw==
MIME-Version: 1.0
X-Received: by 10.202.89.213 with SMTP id n204mr5532250oib.77.1422051390943; Fri, 23 Jan 2015 14:16:30 -0800 (PST)
Received: by 10.202.226.136 with HTTP; Fri, 23 Jan 2015 14:16:30 -0800 (PST)
In-Reply-To: 
References: 
Date: Fri, 23 Jan 2015 14:16:30 -0800
Message-ID: 
From: Martin Thomson 
To: Xiaoyin Liu 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-sslv3-diediedie-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Jan 2015 22:16:33 -0000

On 23 January 2015 at 13:13, Xiaoyin Liu  wrote:
> should it also update RFC4346 (TLS 1.1) and RFC2246 (TLS 1.0)?

Those are deprecated, so I think we are safe in not doing so.  But I'm
happy to listen to arguments for that.


From nobody Fri Jan 23 14:41:23 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD1AF1A87B9 for ; Fri, 23 Jan 2015 14:41:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.295
X-Spam-Level: **
X-Spam-Status: No, score=2.295 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_HELO_PASS=-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 4yj8FWcB-MHN for ; Fri, 23 Jan 2015 14:41:17 -0800 (PST)
Received: from dragaera.releasedominatrix.com (unknown [198.0.208.83]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50BEB1A7028 for ; Fri, 23 Jan 2015 14:41:17 -0800 (PST)
Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id C34CD33D09B; Fri, 23 Jan 2015 22:40:46 +0000 (UTC)
Sender: geoffk@localhost.localdomain
To: Joseph Salowey 
References: 
From: Geoffrey Keating 
Date: 23 Jan 2015 14:40:46 -0800
In-Reply-To: 
Message-ID: 
Lines: 8
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-sslv3-diediedie-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Jan 2015 22:41:18 -0000

Joseph Salowey  writes:

> This is a working group last call for draft-ietf-tls-sslv3-diediedie-00.
> Please reply to the TLS working group list with an indication of whether or
> not the draft is ready for publication and any other comments you may
> have.  Please respond by February 16, 2015.

I believe this draft is ready to publish in the current form.


From nobody Fri Jan 23 15:31:45 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3BA21A0276 for ; Fri, 23 Jan 2015 15:31:44 -0800 (PST)
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 9B8fQzNdRH9q for ; Fri, 23 Jan 2015 15:31:42 -0800 (PST)
Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 822041A0074 for ; Fri, 23 Jan 2015 15:31:42 -0800 (PST)
Received: by mail-qa0-f52.google.com with SMTP id x12so177721qac.11 for ; Fri, 23 Jan 2015 15:31:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=9xGTL6HX72Cmqk5l/ECe3wugfJS2oFZRWgCcKWJOt/k=; b=rb51ub31unoopArGpQCOztjBo7r1W63UntXvaYS0Sn94OSZS/AYGOaRoxiCfq2KRe6 nkwNSUusbkmfGs2FMZxCncACGXcxal5HqKDh3uNoj3C4MObcYcqwrsy9eBW6OkOCyElR gQK9n3ZW+xUZjf7+seH0YZhRkfLXJd0LK+cpaMwH2HzzrlcFJSnNjlyRnAqwzDMg2q2S xzMgz2ukmVGvyLbTWyl6a/z0DBl7+mOsYsOMLUmj8/R+xGWeRXLbtfJ/CxZTqR1Wsal2 GhfRxtxe+xsFHY5ty/muU54QamltYcD1UvUqgUaptjhHZZZ26VjSE7w/KNBTurrLzybw gguw==
X-Received: by 10.224.38.71 with SMTP id a7mr13810178qae.24.1422055901736; Fri, 23 Jan 2015 15:31:41 -0800 (PST)
Received: from dave-laptop.localnet ([96.245.56.59]) by mx.google.com with ESMTPSA id 77sm2837259qgx.43.2015.01.23.15.31.41 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 23 Jan 2015 15:31:41 -0800 (PST)
From: Dave Garrett 
To: Martin Thomson 
Date: Fri, 23 Jan 2015 18:31:40 -0500
User-Agent: KMail/1.13.5 (Linux/2.6.32-70-generic-pae; KDE/4.4.5; i686; ; )
References:  
In-Reply-To: 
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201501231831.40400.davemgarrett@gmail.com>
Archived-At: 
Cc: tls@ietf.org
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-sslv3-diediedie-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Jan 2015 23:31:44 -0000

On Friday, January 23, 2015 05:16:30 pm Martin Thomson wrote:
> On 23 January 2015 at 13:13, Xiaoyin Liu  wrote:
> > should it also update RFC4346 (TLS 1.1) and RFC2246 (TLS 1.0)?
> 
> Those are deprecated, so I think we are safe in not doing so.  But I'm
> happy to listen to arguments for that.

The SSL2 prohibition RFC listed them all.

http://tools.ietf.org/html/rfc6176

Maintaining consistency for SSL3 seems logical.

If the message is that the IETF recommends against the usage of SSL for any reason, then officially updating all three probably makes sense. It's obviously not likely to affect anything in practice, though.


From nobody Fri Jan 23 15:59:24 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54C121AD1D5 for ; Fri, 23 Jan 2015 15:59:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level: 
X-Spam-Status: No, score=-1.7 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_8BIT_HEADER=0.3, 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 uQvAZMGzclUb for ; Fri, 23 Jan 2015 15:59:21 -0800 (PST)
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 78A2F1A88A7 for ; Fri, 23 Jan 2015 15:59:21 -0800 (PST)
Received: by mail-la0-f41.google.com with SMTP id gm9so287658lab.0 for ; Fri, 23 Jan 2015 15:59:19 -0800 (PST)
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:content-transfer-encoding; bh=2EuA/MpUEVzrlHfAaASBbdEVwKbefS/iQ5SWZpXmt/c=; b=gZce2+YuPvV+sBlo28/XT+W7R9jbeeVtZ5DaIkGavBsxRtL85UlFE8Ew4pvJRiThKZ HvVA2LrSGKpcjtQdCOwlRK+yGkmNI02cAqZbIbM9ppyI33tYXEnQlBQ8X7c16bmXpxIG r9wKSsif1NlUPIsSJdhgBsYlFg+I4idEJQrQjE9urX73jBaLPlKKRRhK66jID2RGsYck pGTVkNbGX9M47zNrDnmdQNLi0mzdm4DfR0rD2iAv7w6Yg0rYv09ATjIFe1snddmgCPSH cUsTsUPFfBSf560mqSjLbQYkxnQOmF55XSCcvgsxaT6zW0hBOJuITMPm3fkGcYCt4hKV MwQw==
MIME-Version: 1.0
X-Received: by 10.152.4.200 with SMTP id m8mr9888471lam.17.1422057559686; Fri, 23 Jan 2015 15:59:19 -0800 (PST)
Received: by 10.112.200.4 with HTTP; Fri, 23 Jan 2015 15:59:19 -0800 (PST)
In-Reply-To: <54C1B2EC.2060507@metaparadigm.com>
References: <40128f312378442fbd26459bf5d7593b@usma1ex-dag1mb2.msg.corp.akamai.com> <20150119192701.190C71B0FF@ld9781.wdf.sap.corp>   <04690E05-4905-4941-A60D-7BC5CDC93431@gmail.com>  <39B8BC24-D539-456F-970B-B11665B0E892@gmail.com> <54C0B783.2060604@metaparadigm.com>  <54C1B2EC.2060507@metaparadigm.com>
Date: Sat, 24 Jan 2015 00:59:19 +0100
Message-ID: 
From: =?UTF-8?Q?Henrik_Grubbstr=C3=B6m?= 
To: Michael Clark 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Jan 2015 23:59:23 -0000

On Fri, Jan 23, 2015 at 3:33 AM, Michael Clark  w=
rote:
> On 23/1/15 12:59 am, Bodo Moeller wrote:
>
> Michael Clark :
>
>> + SCSV served a purpose of a mitigation while clients downgraded
>>   due to version upgrade intolerant servers. It may have served its
>>   purpose. Don't downgrade and there is no attack vector
[...]
> A).
>
>     1). Codify use of a "Supported TLS Versions Extension" with either a
> strong recommendation for a minimum of TLSv1.0 { 3, 1 } to deprecate SSLv=
3.0
>         * Advisory to recommend the record layer ClientHello version be
> fixed to the lower bound { 3, 0 } ; which there seems to be some consensu=
s
> for
>         * In the case where the extension is echoed. i.e. supported, the
> record layer version is echoed by the server and signed in the handshake.
>         * This is TLSv1.0 through TLSv1.2 compatible via extension
> tolerance. i.e. All TLS implementations can benefit from it.

I don't see a need for this. The current SCSV in the draft seems
sufficient; it indicates to the server that the client believes that
there's some sort of problem with the connection, which not
necessarily is due to the protocol version, but that the client has
downgraded in an attempt to workaround.

Your approach risks cementing the misinterpretation of the record
layer version as the minimum protocol version, which is the cause of
many of the version-related problems.

> And in TLSv1.3, where payload can be changed, and extensions can be
> mandated, without breaking backwards compatibility, it also makes sense t=
o:
>
> B).
>
>     1). MUST Codify use of a "Supported TLS Versions Extension" with eith=
er
> a strong recommendation or MUST for a minimum of TLSv1.0 { 3, 1 } to
> deprecate SSLv3.0
>         * In the case where the extension is echoed. i.e. the lower bound=
 is
> signed in the handshake.
>         * This provides administrators with a clear indication of support=
ed
> versions and the ability to set their lower bound
>         * This is TLSv1.0 through TLSv1.2 compatible via extension
> tolerance.
>         * Complete deprecation of SSLv3.0 would like be achieved by the t=
ime
> TLSv1.3 is in the wild.

Why mess with the version negotiation? The current protocol works fine
if the parties actually implement the RFCs.

>     2). MUST tighten the wording with respect to the ClientHello record
> layer and message layer versions
>         * Fix the record layer ClientHello version to the lower bound { 3=
, 0
> } ; which there seems to be some consensus for
>         * This is TLSv1.0 through TLSv1.2 compatible via extension
> tolerance.

See above.

>     3). MUST Extend the TLSv1.3 verify_data size from 12 octets to >=3D16
> octets
>         * In the TLSv1.3 time frame we are approaching a point where (
> handshakes * ( 2^12) / ( 2^96 ) ) becomes a potentially exploitable weakn=
ess
>         * The wording that defers to the cipher suite for verify_data_len=
gth
> should be changed.

This makes some sense.

>     4). MUST Include the entire handshake record layer rather than conten=
t
> in the veryify_data hash
>         * While this is a duplication of the mitigation in A.1, it is in
> fact the real fix and the "Supported TLS Versions Extension" becomes an
> indicator
>         * "Supported TLS Versions Extension" would echoed to indicate the
> lower bound and { 3, 0 } would be fixed at record layer.
>         * Reasoning: The fact a mitigation is deployed (for backwards
> compatibility) should not prevent the standard from deploying the real fi=
x.
>         * TLSv1.3 has an opportunity to change content layer semantics of
> the handshake hash without breaking backwards compatibility
>         * It needs to be tight { 3, 1} lower bound via extension and at t=
he
> same time loose { 3, 0 } in record layer for inclusive backwards and
> forwards compatibility.

This seems stupid. There are three pieces of extra information
contained at the packet level in this case:

  * The packet content type

     This is handshake for all packets in the handshake (now that CCS
is gone in TLS 1.3), and thus contains no information.

  * The packet fragmentation.

    This is not relevant, since all payloads are concatenated before
the protocol actually looks at them.

  * The packet version number.

    This is not relevant, as either the version is 3.x in all packets
and the packets are accepted, or the version is something else and the
connection will be terminated.

/grubba

--=20
Henrik Grubbstr=C3=B6m                                       grubba@grubba.=
org
Roxen Internet Software AB                              grubba@roxen.com


From nobody Fri Jan 23 16:31:31 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7969E1A897E for ; Fri, 23 Jan 2015 16:31:30 -0800 (PST)
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 KS1WfwqiHYl7 for ; Fri, 23 Jan 2015 16:31:29 -0800 (PST)
Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D99CD1A8982 for ; Fri, 23 Jan 2015 16:31:28 -0800 (PST)
Received: by mail-oi0-f51.google.com with SMTP id x69so348783oia.10 for ; Fri, 23 Jan 2015 16:31:28 -0800 (PST)
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=l6jvzBHgLL9At7VwLTd1+C1azW6xs58WfaUI+dycJGQ=; b=nLTZAsXkxoz620pL9ViwYgaN7poU3x0dHvamAmBb0U6yMgJvjutblTnyfnedyVc5DT IVPMYZsMuEzzRWWkCKytazMJuZ8DrZgUuP6JBisQlcnWl5BmmL3q3yGeUzrLoS6buWb/ 5j2WOzepzH2wldaafsmwJD33NxgJ1u2rcbHtzb3ukCA3cK+ESSfjxg/ufj83dnxo0R+8 Jn+9i6BbC238b1NaLl2cM8dpqLwk+CJG/kqnuPEhvBTm7TLWWFe2zo44sxyyyTm2HZUl s+d/LTbm2OhUF6eHwAZpp1RafKawc1v9ypnU6peY+QClMLia2j5RcVAFq/IBr+DF6Lc9 5MqA==
MIME-Version: 1.0
X-Received: by 10.202.185.198 with SMTP id j189mr5938313oif.72.1422059488189;  Fri, 23 Jan 2015 16:31:28 -0800 (PST)
Received: by 10.202.226.136 with HTTP; Fri, 23 Jan 2015 16:31:28 -0800 (PST)
Received: by 10.202.226.136 with HTTP; Fri, 23 Jan 2015 16:31:28 -0800 (PST)
In-Reply-To: <201501231831.40400.davemgarrett@gmail.com>
References:   <201501231831.40400.davemgarrett@gmail.com>
Date: Fri, 23 Jan 2015 16:31:28 -0800
Message-ID: 
From: Martin Thomson 
To: Dave Garrett 
Content-Type: multipart/alternative; boundary=001a113ce80ea4a18c050d5b0653
Archived-At: 
Cc: tls@ietf.org
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-sslv3-diediedie-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 24 Jan 2015 00:31:30 -0000

--001a113ce80ea4a18c050d5b0653
Content-Type: text/plain; charset=UTF-8

On Jan 23, 2015 3:31 PM, "Dave Garrett"  wrote:
>
> On Friday, January 23, 2015 05:16:30 pm Martin Thomson wrote:
> > On 23 January 2015 at 13:13, Xiaoyin Liu  wrote:
> > > should it also update RFC4346 (TLS 1.1) and RFC2246 (TLS 1.0)?
> >
> > Those are deprecated, so I think we are safe in not doing so.  But I'm
> > happy to listen to arguments for that.
>
> The SSL2 prohibition RFC listed them all.
>
> http://tools.ietf.org/html/rfc6176
>
> Maintaining consistency for SSL3 seems logical.

I remember a saying about consistency.

> It's obviously not likely to affect anything in practice, though.

That is a great argument. I'm convinced.

--001a113ce80ea4a18c050d5b0653
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Jan 23, 2015 3:31 PM, "Dave Garrett" <davemgarrett@gmail.com> wrote:

>

> On Friday, January 23, 2015 05:16:30 pm Martin Thomson wrote:

> > On 23 January 2015 at 13:13, Xiaoyin Liu <xiaoyin.l@outlook.com> wrote:

> > > should it also update RFC4346 (TLS 1.1) and RFC2246 (TLS 1.0=
)?

> >

> > Those are deprecated, so I think we are safe in not doing so.=C2=
=A0 But I'm

> > happy to listen to arguments for that.

>

> The SSL2 prohibition RFC listed them all.

>

> http://tools.ietf.org/h=
tml/rfc6176

>

> Maintaining consistency for SSL3 seems logical.


I remember a saying about consistency.


> It's obviously not likely to affect anything in pra=
ctice, though.


That is a great argument. I'm convinced.




--001a113ce80ea4a18c050d5b0653--


From nobody Fri Jan 23 17:27:02 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6974C1A1A52 for ; Fri, 23 Jan 2015 17:27:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, 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 3-Rz92We8BxZ for ; Fri, 23 Jan 2015 17:26:59 -0800 (PST)
Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001: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 7C8351A19F8 for ; Fri, 23 Jan 2015 17:26:58 -0800 (PST)
Received: by mail-ie0-f169.google.com with SMTP id rl12so585046iec.0 for ; Fri, 23 Jan 2015 17:26:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kShoxzLqCWpptwsrTLaJj0t5ENtYeaHORCJQWr4BrKk=; b=WE0fvCf9+eM2XITFhkNtmNARlMoq+m3TJqfYhoUVUBsXmraLMN9Mc/kVZOle1469kh lK1I6CS9w2uNFp6gq43J2+F8m8sCz31nR8FDBcgFuqBxU4nJNQpgMA4mkDeb0Up3AESS 7R9ma6XtsvKmEg1KqLP10af7quq14n1v9gOSY=
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=kShoxzLqCWpptwsrTLaJj0t5ENtYeaHORCJQWr4BrKk=; b=NOEIZa+sVV6b3iAQ080uHRX25vPP5s8l4PR+i5LtfPfd5lpvFouIINHJwn4qaou666 kyjd81FB8m5Z3XczIucUtbmRevyAhKrC8vJ/B8nZF6uwdzG2B/OSSzB4M+CRzegEwbNz vUQJToFVhIymE1IthQpDlKmax+3082/LZRnxAFjZtWBqYNDRGPEQ+kGzu8zeYB91wJh4 Te6KRK+cbjaeMq8lyGF+Z+/fU9lY+l/AsxUeGIan0JqmL91+hg3StyHWk99bRvylKeva UQoCgFTnonNAl/nbLGt60o6A8su5dtuVmGPGnTZ9+LoDFfXsFY67t52KkJ7hVKRgvDEb 7tVQ==
X-Gm-Message-State: ALoCoQmR18mbFzqEU9n9V1OmAEAGa4BwI0rfCZu7z02LvLt1jJMbfet5UmHpYbPAUvlM6AHXmO0t
MIME-Version: 1.0
X-Received: by 10.50.79.202 with SMTP id l10mr5274115igx.24.1422062817684; Fri, 23 Jan 2015 17:26:57 -0800 (PST)
Received: by 10.64.136.209 with HTTP; Fri, 23 Jan 2015 17:26:56 -0800 (PST)
Received: by 10.64.136.209 with HTTP; Fri, 23 Jan 2015 17:26:56 -0800 (PST)
In-Reply-To: 
References: <9A043F3CF02CD34C8E74AC1594475C73AAF525B9@uxcn10-tdc05.UoA.auckland.ac.nz>  <54B54A5F.7020401@polarssl.org>      <54B65AF0.1080503@metaparadigm.com> 
Date: Fri, 23 Jan 2015 19:26:56 -0600
Message-ID: 
From: Tom Ritter 
To: Martin Thomson 
Content-Type: multipart/alternative; boundary=089e0122aaee18c8a4050d5bcd7a
Archived-At: 
Cc: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9=2DGonnard?= , tls@ietf.org
Subject: Re: [TLS] AAED ciphers: AES-GCM vs AES-EAX/AES-CCM: a meta-analysis
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 24 Jan 2015 01:27:00 -0000

--089e0122aaee18c8a4050d5bcd7a
Content-Type: text/plain; charset=ISO-8859-1

On Jan 14, 2015 11:20 AM, "Martin Thomson"  wrote:
>
> On 14 January 2015 at 04:02, Michael Clark 
wrote:
> > Interesting. Should draft-pironti-tls-length-hiding-01 be added to
> > Related Active Documents (not working group documents) section
>
> That's an automatically generated list.  I suspect the reason that it
> doesn't appear is that it is presently expired.

Something I feel very bad about. I am a big proponent of making length
hiding possible in 1.3 and need to find time to put more effort into this.
I encourage the chairs or WG to bug me if they don't see anything about
this in a timeframe they expect.

-tom

--089e0122aaee18c8a4050d5bcd7a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable




On Jan 14, 2015 11:20 AM, "Martin Thomson" <martin.thomson@gmail.com> wrote:

>

> On 14 January 2015 at 04:02, Michael Clark <michael@metaparadigm.com> wrote:

> > Interesting. Should draft-pironti-tls-length-hiding-01 be added t=
o

> > Related Active Documents (not working group documents) section
>

> That's an automatically generated list.=A0 I suspect the reason th=
at it

> doesn't appear is that it is presently expired.


Something I feel very bad about. I am a big proponent of mak=
ing length hiding possible in 1.3 and need to find time to put more effort =
into this.=A0 I encourage the chairs or WG to bug me if they don't see =
anything about this in a timeframe they expect.=A0 


-tom


--089e0122aaee18c8a4050d5bcd7a--


From nobody Fri Jan 23 21:14:52 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3381A00FA for ; Fri, 23 Jan 2015 21:14:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Level: 
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 Nz6SjcT8QELQ for ; Fri, 23 Jan 2015 21:14:46 -0800 (PST)
Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD6661A00F7 for ; Fri, 23 Jan 2015 21:14:46 -0800 (PST)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 494713A2C4; Sat, 24 Jan 2015 06:14:44 +0100 (CET)
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 3C756416B8; Sat, 24 Jan 2015 06:14:44 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 356DB1B11A; Sat, 24 Jan 2015 06:14:44 +0100 (CET)
In-Reply-To: 
To: Tom Ritter 
Date: Sat, 24 Jan 2015 06:14:44 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20150124051444.356DB1B11A@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: 
Cc: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= , tls@ietf.org
Subject: Re: [TLS] AAED ciphers: AES-GCM vs AES-EAX/AES-CCM: a meta-analysis
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 24 Jan 2015 05:14:49 -0000

Tom Ritter wrote:
> "Martin Thomson"  wrote:
>>
>> Michael Clark  wrote:
>>>
>>> Interesting. Should draft-pironti-tls-length-hiding-01 be added to
>>> Related Active Documents (not working group documents) section
>>
>> That's an automatically generated list.  I suspect the reason that it
>> doesn't appear is that it is presently expired.
> 
> Something I feel very bad about. I am a big proponent of making length
> hiding possible in 1.3 and need to find time to put more effort into this.
> I encourage the chairs or WG to bug me if they don't see anything about
> this in a timeframe they expect.

It would be easy to add length hiding (for all ciphers, STREAM, CBC, AEAD)
to all of TLSv1.x -- simply by defining a compression algorithm that
doesn't compress, but instead adds padding.  Compression algorithms
are allowed to inflate plaintext records up to a size of 2^14+1024 bytes.
And if that (anti-)compression algorithm would add random padding
on both ends of the plaintext, this could also frustrate attacks on
CBC padding and RC4 bias...


-Martin


From nobody Fri Jan 23 23:49:12 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6F51A0143 for ; Fri, 23 Jan 2015 23:49:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Level: 
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 Kl2ZbxfnBEZZ for ; Fri, 23 Jan 2015 23:49:10 -0800 (PST)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2A101A0130 for ; Fri, 23 Jan 2015 23:49:09 -0800 (PST)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id EBCF13A132 for ; Sat, 24 Jan 2015 08:49:07 +0100 (CET)
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id A2A7E41F64 for ; Sat, 24 Jan 2015 08:49:07 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 9928B1B0D1; Sat, 24 Jan 2015 08:49:07 +0100 (CET)
To: tls@ietf.org
Date: Sat, 24 Jan 2015 08:49:07 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20150124074907.9928B1B0D1@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: 
Subject: [TLS] ClientHello and record layer version interop
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 24 Jan 2015 07:49:11 -0000

I'm seeing an increase in customer messages about newly
appearing TLS interop problems.  There seem to be TLSv1.0 servers
who threw out the baby with the bathtub and started rejecting
ClientHellos with client_version = (3,1) that come in SSLv3 records.


One of the servers identifies itself as "Sun-ONE-Web-Server/6.1"
and exhibits the following crazy behaviour:


   SSLv2-record with SSLv2 CLIENT-HELLO offering TLSv1.0:  TLSv1.0 ServerHello
*> SSLv3-record   with ClientHello offering TLSv1.0 ==>  Handshake failure
   TLSv1.0-record with ClientHello offering TLSv1.0 ==>  TLSv1.0 ServerHello
   TLSv1.2-record with ClientHello offering TLSv1.2 ==>  TLSv1.0 ServerHello


How widespread is that disease?  Does anyone know which kind of
servers/software exhibit this flaw and how many of them exist?

Server configuration changes (disabling SSLv3) in "response" to Poodle
seem to get applied slowly to production servers. 


-Martin


From nobody Sat Jan 24 00:25:23 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9C671A014C for ; Sat, 24 Jan 2015 00:25:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level: 
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_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 LBK58LRsld9b for ; Sat, 24 Jan 2015 00:25:19 -0800 (PST)
Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E2161A0119 for ; Sat, 24 Jan 2015 00:25:19 -0800 (PST)
Received: from zmail22.collab.prod.int.phx2.redhat.com (zmail22.collab.prod.int.phx2.redhat.com [10.5.83.26]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id t0O8PILY032465; Sat, 24 Jan 2015 03:25:18 -0500
Date: Sat, 24 Jan 2015 03:25:17 -0500 (EST)
From: Nikos Mavrogiannopoulos 
To: mrex@sap.com
Message-ID: <535593779.25084.1422087917445.JavaMail.zimbra@redhat.com>
In-Reply-To: <20150124074907.9928B1B0D1@ld9781.wdf.sap.corp>
References: <20150124074907.9928B1B0D1@ld9781.wdf.sap.corp>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.5.82.6]
X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF31 (Linux)/8.0.6_GA_5922)
Thread-Topic: ClientHello and record layer version interop
Thread-Index: fIiltmAzwBjDHwsSYN0TI6RoO+Uujg==
Archived-At: 
Cc: tls@ietf.org
Subject: Re: [TLS] ClientHello and record layer version interop
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 24 Jan 2015 08:25:21 -0000

----- Original Message -----
> I'm seeing an increase in customer messages about newly
> appearing TLS interop problems.  There seem to be TLSv1.0 servers
> who threw out the baby with the bathtub and started rejecting
> ClientHellos with client_version = (3,1) that come in SSLv3 records.
[...]
> How widespread is that disease?  Does anyone know which kind of
> servers/software exhibit this flaw and how many of them exist?

I got reported the same behavior for few servers as well.

The worst case server had:
    SSLv3-record   with ClientHello offering TLSv1.0 ==>  Handshake failure
    TLSv1.0-record with ClientHello offering TLSv1.0 ==>  TLSv1.0 ServerHello
    TLSv1.2-record with ClientHello offering TLSv1.2 ==>  Handshake failure

I eventually switched gnutls to send TLS 3.1 in the client hello record's version.
http://lists.gnutls.org/pipermail/gnutls-devel/2015-January/007403.html
http://lists.gnutls.org/pipermail/gnutls-help/2014-November/003673.html

regards,
Nikos


From nobody Sat Jan 24 00:28:49 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A654F1A0154 for ; Sat, 24 Jan 2015 00:28:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.212
X-Spam-Level: 
X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, 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 LqeLqipFMTVv for ; Sat, 24 Jan 2015 00:28:46 -0800 (PST)
Received: from mx6-phx2.redhat.com (mx6-phx2.redhat.com [209.132.183.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A6C81A0151 for ; Sat, 24 Jan 2015 00:28:46 -0800 (PST)
Received: from zmail22.collab.prod.int.phx2.redhat.com (zmail22.collab.prod.int.phx2.redhat.com [10.5.83.26]) by mx6-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t0O8ShHn018092; Sat, 24 Jan 2015 03:28:43 -0500
Date: Sat, 24 Jan 2015 03:28:43 -0500 (EST)
From: Nikos Mavrogiannopoulos 
To: Michael Clark 
Message-ID: <1551425826.25208.1422088122993.JavaMail.zimbra@redhat.com>
In-Reply-To: <54C1C47F.1010605@metaparadigm.com>
References: <40128f312378442fbd26459bf5d7593b@usma1ex-dag1mb2.msg.corp.akamai.com> <04690E05-4905-4941-A60D-7BC5CDC93431@gmail.com>  <39B8BC24-D539-456F-970B-B11665B0E892@gmail.com> <54C0B783.2060604@metaparadigm.com>  <54C1B2EC.2060507@metaparadigm.com> <54C1C47F.1010605@metaparadigm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.5.82.6]
X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF31 (Linux)/8.0.6_GA_5922)
Thread-Topic: Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
Thread-Index: 3a6YJq2lvQ4CcE4fAGLi3QG0dEmXOQ==
Archived-At: 
Cc: tls@ietf.org
Subject: Re: [TLS] Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 24 Jan 2015 08:28:47 -0000

----- Original Message -----
> From my read, it seems in the time frame of current mitigations (SVSC in
> the field or Nikos's "Supported Versions Extension" as a more elegant
> forwards and backwards compatible version signalling mechanism). Nikos
> was pushing on { 3, 0 } for a current lower bound (at the record layer)
> for TLSv1.0 through TLSv1.2 as { 3, 1 } at the record layer in the
> current time-frame *allegedly* causes dancing for a few remaining
> upgrade recalcitrant servers. i.e. causing problems in the wild. This
> was my read.
> So the decision remains whether { 3, 0 } or { 3, 1 } is the "record
> layer" lower bound in TLSv1.3;

Note that I was not pushing for anything. I merely presented my interpretation 
of what the record version numbers mean. As it is now, using { 3, 0 } in the
record version causes connections to fail to several web sites (see Martin's mail
on 'ClientHello and record layer version interop'), so it's not much of an
option.

regards,
Nikos


From nobody Sat Jan 24 11:31:15 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 296DA1A1A95 for ; Sat, 24 Jan 2015 11:31:14 -0800 (PST)
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 cTX3kza9OZmJ for ; Sat, 24 Jan 2015 11:31:12 -0800 (PST)
Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77BE31A1B01 for ; Sat, 24 Jan 2015 11:31:12 -0800 (PST)
Received: by mail-wg0-f48.google.com with SMTP id x12so2909688wgg.7 for ; Sat, 24 Jan 2015 11:31:11 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=e6Xmbcg9Ckok2rUOGCO35CwiQnQPYLw+C149mLwqMEs=; b=Idte3I16oX/MxuqH1cJJz4fKGxEpr9/bX+C2wGQicT80X7WHMwmcSw/caSzq/+EaRf 7v/NfJusxONSIOEeok/e6eT9MF0hxyWrT/D3A4Tx0uUw0ecPr5/NZfv97sSiB7IeEQcm Xou+e5P+vlu65XNTsk8Equ2AmS0isLvsZZMGaHuhXcv6odMBfR21kkeXh9XYwMNvY/H9 8v5eufgHrTjmBgFtVuGluedq6W9+qG/0pgAN3fBBR88V+W3w4P+6m2DKdBxmxYRSf2kc O73y9c9ZkYXG959lG/l5CM21BOxST5LK6JjfZatogUJMryNMrxUYqt+jrtNinPbukhIE cf8g==
X-Gm-Message-State: ALoCoQmRHfBvpvPy/8G18pN1o4Dj5vaoiZjSzUnjUy+0lEFRUaj25OO3JgMk0klM1YJ1mIVJgORN
X-Received: by 10.180.106.5 with SMTP id gq5mr12719340wib.34.1422127871284; Sat, 24 Jan 2015 11:31:11 -0800 (PST)
Received: from [10.0.0.142] (chello080108032135.14.11.univie.teleweb.at. [80.108.32.135]) by mx.google.com with ESMTPSA id p6sm7332145wjf.39.2015.01.24.11.31.10 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 24 Jan 2015 11:31:10 -0800 (PST)
Message-ID: <54C3F307.7090009@azet.org>
Date: Sat, 24 Jan 2015 20:31:19 +0100
From: Aaron Zauner 
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: Peter Gutmann 
References: <9A043F3CF02CD34C8E74AC1594475C73AAF626ED@uxcn10-tdc05.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAF626ED@uxcn10-tdc05.UoA.auckland.ac.nz>
X-Enigmail-Version: 1.2.3
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigD51CBA086454BF6D125F078B"
Archived-At: 
Cc: "" 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 24 Jan 2015 19:31:14 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigD51CBA086454BF6D125F078B
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Peter,

Peter Gutmann wrote:
> Not necessarily.  When I did my PSK draft I added the discussion of emb=
edded
> systems use mostly as a red herring to deal with the people who complai=
ned
> that since we already have PKI in all its infinite wonder and perfectio=
n to
> secure TLS, there's no need for anything involving shared secrets.  The=

> mention of use in embedded systems was to deal with the PKI zombies, no=
t
> embedded systems.  RFC 4279 doesn't mention embedded systems at all.
>=20
>> It would be really good to have someone doing TLS crypto in the embedd=
ed
>> world comment on this topic.
>=20
> I've got lots of TLS running in embedded systems.  I'm not aware of any=
thing
> currently using pure PSK, it's always DHE with PSK.  To deal with lower=
-power
> CPUs, you use smaller DH parameters.  Even for older stuff from before =
it was
> ARM everywhere (with a side order of MIPS, PPC, NIOS, and whatnot every=
where),
> the standard approach was still to use smaller RSA/DH values rather tha=
n pure
> PSK.  I support non-PFS PSK, but only after all of the PFS PSK suites, =
so I
> doubt that ever gets used.

Thanks for your commentary and insight. I find this (personally) very
interesting. As I've pointed out in private correspondence: all the PSK
ciphersuites will stay in the document unchanged. Due to good points
being raised during the discussion for them not to be removed.

> At a pinch you can even do DHE-RSA in an embedded device, you just memc=
py()
> out a pre-encoded certificate chain that's generated on install so you =
don't
> have to have any certificate-processing code present.  Problem is that =
(a)
> this doesn't give you mutual auth and (b) more importantly certificates=

> inherently don't work with embedded devices which can't be identified o=
r
> provisioned in any manner that's expected for certificates.  At best yo=
u can
> hardcode in a fixed certificate with a meaningless identifier and infin=
ite
> lifetime at system build time, but that's just going through the motion=
s of
> using certs.

That's a nice trick but as you point out pretty useless in terms of a
PKI. Although I'm pretty sure some vendors will ship uniform client
certificates on devices; that /really/ should not be recommended anywhere=
 :)


I've still gotten no feedback if SRP will still be supported with TLS
1.3. I really think SRP is a valuable protocol but rarely used. I have
not included SRP ciphersuites in my ID so far.

Aaron



--------------enigD51CBA086454BF6D125F078B
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUw/MIAAoJEOTbZJL9ubXVxfcQAM3xiiapebK1QaqOk9UYxspn
FWSlrpKC+wKkemBW0T/f8YMu4yJnablAzY4YIYJoRMWB8ftwritqeoqybwMAiEfF
tv9/suBtwkQrWZZ7nRvj2bn/9flxpjHckuqnzg/0D/WsdSrEB+Z9hmVr2VgBON2n
smJ0I9LJ0z0KWTokahn7yYNKvA4dPn3X2DT9ca9xA0h0VTN1cGbuYEdr5UWP27zR
ci6uYhdo4nmZvbSzFvUS0IFLVujHQUUaWdiRsKOrE+9cPjw1ZV8KHbw7YmW4Z0jO
iRmgR0/kOYHQUm+Ypz/Vj1DlK9BLChU3GN/VJa9QmB7n9ypc2vy1yisjSuwoaAvE
9gpErHmCkMYN8GAbPUhNdlbtm+NHncWfYLwW6xF8psB/B5wR+oKor2g2SgxcfP+v
uqx9Iy8pp9GwmYa8ngoNjyLkcdQOuVyB3Pp0qpl5rHIb6D+djCyEYKgPKF+RItdn
TwUNR/wFJ+bkKqY4MSXxcEusJWp28bHG9LRJbJKMa6uWfTEcgI4YTsTtbhdO1S7R
ksKqQWE05KHA0/JaNwkUW2b1USsObWGd5YMcEk9e4B+wRylR6xUS89w/fbsEXqFj
Vhqdv/mbLif+Ok7VTdPY1Cr4KRFhi0AxiXcJRItplf2lkk10XRQZcdjGZvmROBq2
/JhZc7W15h2m/G2w/YjI
=ENgZ
-----END PGP SIGNATURE-----

--------------enigD51CBA086454BF6D125F078B--


From nobody Sat Jan 24 13:25:37 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D55C91A007A for ; Sat, 24 Jan 2015 13:25:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level: 
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 XYgZ6CxhdPOv for ; Sat, 24 Jan 2015 13:25:33 -0800 (PST)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 0E51F1A0079 for ; Sat, 24 Jan 2015 13:25:32 -0800 (PST)
Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id F01C8F984 for ; Sat, 24 Jan 2015 16:25:30 -0500 (EST)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 36211201F8; Fri, 23 Jan 2015 19:23:38 -0500 (EST)
From: Daniel Kahn Gillmor 
To: tls@ietf.org
In-Reply-To: <3F4C76ED-4375-438F-ADC9-66E49A19574B@ieca.com>
References: <3F4C76ED-4375-438F-ADC9-66E49A19574B@ieca.com>
User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu)
Date: Fri, 23 Jan 2015 19:23:34 -0500
Message-ID: <87fvb1hvqx.fsf@alice.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Archived-At: 
Subject: Re: [TLS] WGLC:  draft-ietf-tls-negotiated-ff-dhe-05
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 24 Jan 2015 21:25:36 -0000

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Fri 2015-01-23 14:30:42 -0500, Sean Turner wrote:
> This is the WGLC (working group last call) for draft-ietf-tls-negotiated-=
ff-dhe-05:
> http://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe-05/
> Please send comments on this draft to the TLS list before February 16, 20=
15.

Off-list, i've recieved a handful of requests for changes in the last
couple weeks that i've been remiss in processing.  I list them below,
From=20least controversial to most controversial in my estimation.

My biggest fear is that the last two points on the list of 5 below
threaten to be a repeat of the current CFRG curve selection morass.  I
really do not want to see that happen.


Adding back ffdhe6144
=2D--------------------
=20=20
I had ffdhe6144 in the earlier draft, and had removed it to reduce the
number of groups to minimize fingerprintability of the handshake, but
have no strong feelings here.

The argument was that the cost increase jumping from a 4kib group to an
8kib group could be seen as prohibitive, and if we ever need to
encourage people to move up from the 4kib group due to a cryptanalytic
advance that puts that range in question, we'd like to offer something
with less of a cost increase.
=20=20=20=20
I'm not convinced i buy the argument: anything that makes folks think
4kib groups are seriously dangerous seems like it could also cause worry
at the 6kib level, but i can also imagine a DLOG work-factor reduction
of modest size that makes this argument seem plausible.  I don't
particularly mind putting 6144 back in unless there are objections.


Increasing the size of the short exponent recommendation
=2D-------------------------------------------------------

The estimates of the group strength come from ECRYPT, and the short
exponent sizes are recommended based on this group strength.  But some
other strength estimates suggest groups of this size are slightly
stronger.  If ECRYPT is wrong, and we base our short exponent length on
its estimates, then we might weaken the system below the actual strength
of the group.  Also, attacking the DLOG problem requires different
resources and precomputation from attacking the stream ciphers.

So the proposal is to leave the estimates based on ECRYPT estimates, but
to increase the size of the recommended short exponents per group.

This only slightly reduces the extra efficiency provided by the short
expoenents, and seems like the right choice to make.


Designating private-use pre-agreed ffdhe groups
=2D----------------------------------------------

A request was made to set aside one (or a few) codepoint(s) for TLS
endpoints that have pre-agreed on a group together.  It's not clear to
me exactly how many "private use" codepoints would be needed.  But two
would allow a large deployment to implement a smooth transition between
two different private groups, which seems like a reasonable goal.

I'll probably designate 510 and 511 ( 0x01fe and 0x01ff ) as these
private-use codepoints for deployments that want this capability.

If anyone has objections, or wants more or less than 2 private-use
codepoints, please speak up.


Using a keyed PRF instead of e
=2D-----------------------------

Two objections were made about the use of e --

(a) because of its definition as the base of the natural log, e has some
    sort of special internal structure that might make FFDH groups
    derived from it more vulnerable to analysis.

(b) that starting from e and counting up biases the randomized prime
    selection by only fiddling certain bits in the prime while counting.

I've spoken with several cryptographers about (a) who dismissed it as
totally implausible.  I haven't gotten much feedback about (b).

The proposed change is to select the "random" bits by using a keyed PRF,
or KDF, with the seed or additional input incrementing until a safe
prime is found.

I confess this sounds better than using e to me, simply because the
construction avoids any claims about (a) and (b).

One approach would be to use [HKDF] with SHA-512, with the initial key
material ("IKM") and info parameter both set to "TLS-ffdheNNNN" (where
ffdheNNNN is the ASCII name of the group), and a salt that we increment
until a safe prime is found at the right length.

  [HKDF] https://tools.ietf.org/html/rfc5869


Avoiding the high-64 and low-64 bits set to 1
=2D--------------------------------------------

The high 64 bits and the low 64 bits of these primes are set to 1
specifically to facilitate Montgomery and Barrett reduction.  This is
similar to the choices made in the MODP FFDHE groups.

The objection to this is that the special structure may make these
groups more vulnerable to attacks that we don't know about, potentially
making them equivalent to groups the size of the inner bits or
something.

I'd like to think that if any advances had been made against the DLOG
problem for groups with this special form, they would be published
already, since the first Oakley group is 768 bits, with the top and
bottom 64 bits all set to 0xff, so this should be in-range and
high-profile for anyone who wants to take a crack at it:

  https://tools.ietf.org/html/rfc2409#section-6.1

But i'm not a cryptographer, i know of no such attack, and i have no
idea how to judge the likelihood of something like this existing.

I also don't know how widespread or desirable Barrett and Montgomery
reductions are: if these reduction methods are unlikely to be actually
used in the field, or offer only insignificant efficiency incentives for
adoption, then we might not need to maintain them.

Another argument here is that if efficiency is paramount, most people
will choose ECDHE instead of FFDHE.  So if we're proposing FFDHE groups
as a bulwark against some future failure of ECDHE, we might as well
accept that performance efficiency isn't the highest priority.



These last two points are what Andrei is referring to when he says
"avoid special-form primes", fwiw.


Thoughts, feedback?

          --dkg

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQJ8BAEBCgBmBQJUwuYHXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB
NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpco6IP/RpkdNR84j8HLtM7tajjr0Bp
Is93BCDaTDcnNbUga7FZ5KaulicdFwfdLGetsR6hY9tFtCiFUgK6R4X2laP0QZ37
qVF9sbp5YkhxPppEjcIFAgFbFLkDnQ7gEFM3FNq+ynZi7nE8JTsVlGXrQZ9TO8E5
47HyUQm/7p+sc7/ebRQNSUWlybxXZHwWUlssToStkNzP7qdUtWmKXVPCUzFPWwrq
hUwCICVRRVKaqIKz+gaZcPulu6/eHKaRWLTpODFADgR80OuZlF/z3shnoBySNhSN
bU77KQ11J4JTuwG7Gd6JCzxYpd1GZFRNuBQ8oY0kC4SNiBpDjZLU4raiYiCUspD1
C+hHq4fg3o2RiKiXprxAC4SAYimORLtQ05GksjDqUHdlY4CmILGtNBVwFTcb9kaT
Uu9+C2q9iGdYGXt08mwz1eCMmGN5hLAJgNTOzVmwWPZ5t+Ttyx9YKw2n0Ght9A0x
oWNEUO0efTYrmFKjvEoUY5qPuOzzxdujvfj3YDDPIds/qdM7Rr/otmeBfTbRq/+q
agSv56LztygFG7wJWxMQ4QH4OmLEJXcFAE6ZRuQbfRFLT6k+jhZdYNcr7HmhFV4N
qkDqa7GubevVGZfERFPVGkgh28qMKEsWdAUnqELkIcg9Dy5rSPc2iPKb3DJVWwFY
RKBa2KqQw8s59osJXCbN
=fXZ0
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Sat Jan 24 20:05:14 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B76521A1EF1 for ; Sat, 24 Jan 2015 20:05:12 -0800 (PST)
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 tEfyMuP93EhR for ; Sat, 24 Jan 2015 20:05:11 -0800 (PST)
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 3177C1A1EEF for ; Sat, 24 Jan 2015 20:05:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1422158711; x=1453694711; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=5rWgYYU6AHK1hu4019Q28TTTD3hRj43nMsk06EKHVXM=; b=oYH5mQL2U8Z86SB4GHLbdDmnuP8d5V+IsAeVz5r82dLZcTCfqj9hxYDl qwUonDAiRw72GdtXsJTdxshoCWJxFqp3Xrpen4zfeeoJeWkXE7WppYev+ cyHAPmkC7GOPl4vP1U8KPwnhtg18jKriQmTmd88os82sOmWNZ0Fsnny3S 4=;
X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="303475077"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing
Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 25 Jan 2015 17:05:10 +1300
Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.148]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Sun, 25 Jan 2015 17:05:09 +1300
From: Peter Gutmann 
To: "" 
Thread-Topic: [TLS] Inclusion of OCB mode in TLS 1.3
Thread-Index: AdA4VBwK0FPWNrzkQM+LIdaA1EalXg==
Date: Sun, 25 Jan 2015 04:05:09 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAF64DCA@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: 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 25 Jan 2015 04:05:12 -0000

Aaron Zauner  writes:=0A=
=0A=
>That's a nice trick but as you point out pretty useless in terms of a PKI.=
=0A=
=0A=
It's done solely to deal with browsers, which demand to see a certificate w=
hen=0A=
they're connecting to something via TLS.=0A=
=0A=
(Aside: You can see why some people think the CA/Browser forum as a conspir=
acy=0A=
 to force the use of certs, despite there being very good alternatives=0A=
 available browsers force you to use certificates whether they're appropria=
te=0A=
 or not).=0A=
=0A=
More generally, PKI is pretty much useless for many SCADA situations.  Take=
=0A=
for example IEDs, the unfortunately-named Intelligent Electronic Devices us=
ed=0A=
in the power industry.  These talk something like GOOSE/GSSE or MMS running=
=0A=
over DNP3 or switched Ethernet, or maybe Modbus, for which PKI makes no sen=
se=0A=
whatsoever (both because the way things are identified don't work with=0A=
certificates, and because the concept of doing cert-provisioning and=0A=
revocation checking and whatnot in an IED like an on-load tap changer=0A=
controller is just bizarre).=0A=
=0A=
What I've seen so far (and things are in a state of change at the moment=0A=
because there are standards that say you have to use TLS with certificates =
and=0A=
whatnot and the industry is realising that while it's fine to say that in a=
=0A=
spec, it doesn't work in practice) is a management interface using hardwire=
d=0A=
certs (the memcpy()-a-blob system) and then the control interfaces using PS=
K=0A=
or who knows what else (there are vast numbers of protocols used, it's a=0A=
headache to untangle them).=0A=
=0A=
Peter.=


From nobody Sun Jan 25 06:27:30 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E69181A1A6A for ; Sun, 25 Jan 2015 06:27:27 -0800 (PST)
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, 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 cp76t2mEooob for ; Sun, 25 Jan 2015 06:27:26 -0800 (PST)
Received: from maple.randombit.net (maple.randombit.net [66.228.45.112]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 686F21A1A64 for ; Sun, 25 Jan 2015 06:27:26 -0800 (PST)
Received: from oak.randombit.net (oak.randombit.net [50.116.63.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by maple.randombit.net (Postfix) with ESMTPS id A01B6A09E3 for ; Sun, 25 Jan 2015 09:27:24 -0500 (EST)
Received: by oak.randombit.net (sSMTP sendmail emulation); Sun, 25 Jan 2015 09:27:24 -0500
From: "Jack Lloyd" 
Date: Sun, 25 Jan 2015 09:27:24 -0500
To: tls@ietf.org
Message-ID: <20150125142724.GA4178@randombit.net>
Mail-Followup-To: tls@ietf.org
References: <9A043F3CF02CD34C8E74AC1594475C73AAF626ED@uxcn10-tdc05.UoA.auckland.ac.nz> <54C3F307.7090009@azet.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <54C3F307.7090009@azet.org>
X-PGP-Fingerprint: 3F69 2E64 6D92 3BBE E7AE 9258 5C0F 96E8 4EC1 6D6B
X-PGP-Key: http://www.randombit.net/pgpkey.html
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 25 Jan 2015 14:27:28 -0000

On Sat, Jan 24, 2015 at 08:31:19PM +0100, Aaron Zauner wrote:

> I've still gotten no feedback if SRP will still be supported with TLS
> 1.3. I really think SRP is a valuable protocol but rarely used. I have
> not included SRP ciphersuites in my ID so far.

I believe SRP is, like PSK, useful in protocols outside of IETF scope and
would love for there to be an SRP ciphersuite option that wasn't AES/CBC.

Cheers,
  Jack


From nobody Sun Jan 25 11:37:00 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B2A41A1A30 for ; Sun, 25 Jan 2015 11:36:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 6TWRAdQR-Xfd for ; Sun, 25 Jan 2015 11:36:56 -0800 (PST)
Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37A631A1A2F for ; Sun, 25 Jan 2015 11:36:56 -0800 (PST)
Received: by mail-wg0-f52.google.com with SMTP id y19so5745332wgg.11 for ; Sun, 25 Jan 2015 11:36:55 -0800 (PST)
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:from:date :message-id:subject:to:cc:content-type; bh=UWdXYsOmqpZq7aUvmj3YPyfctqovZo9qqyWc9w+wtEM=; b=RKXCcMtrM0LD+jSdIkz1Xhu/hzS7nqUTOXPRM3JV1bcu9F7ZEEKbLTZBNYY1WhbSyR U8u7fs2OyIEICcl9aHG7n7OJDM8OuhYpaJtNSLTTtbAOJc9I/QbsS/puF1jmDlmDcbXi HvYmUvJMecACq+HhRHPQHMar4CFIA2Tjx/ZzZ7wLjbTOz2Mc8SPZdTXoxa+CWU/yJ9Ry Pk0dUbWfU+TiFno85nOEBcbEZziDtPgPFMxQpY2EbfxgJXJpLkwhUKlAYkaeqdkjiq5w iZawsUDhFK1A1KzmKamfsQBTLUp+Ox7CpvwTekC1X7gKDpIBk4Q/qIX+Hs9rSV4b9gFk IWMg==
X-Gm-Message-State: ALoCoQnBZgMPY/cVwsa8Ssi1GolxP6JIugfa7m3WicVubHBZApn3dNB3yk221FD1k+LrauRI2pEP
X-Received: by 10.180.98.162 with SMTP id ej2mr25385180wib.39.1422214614955; Sun, 25 Jan 2015 11:36:54 -0800 (PST)
MIME-Version: 1.0
Received: by 10.27.142.215 with HTTP; Sun, 25 Jan 2015 11:36:14 -0800 (PST)
In-Reply-To: <201412300503.03923.davemgarrett@gmail.com>
References: <201412300503.03923.davemgarrett@gmail.com>
From: Eric Rescorla 
Date: Sun, 25 Jan 2015 11:36:14 -0800
Message-ID: 
To: Dave Garrett 
Content-Type: multipart/alternative; boundary=f46d04428274eb4efc050d7f24d0
Archived-At: 
Cc: "TLS@ietf.org \(tls@ietf.org\)" 
Subject: Re: [TLS] consensus on backwards compatibility changes
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 25 Jan 2015 19:36:58 -0000

--f46d04428274eb4efc050d7f24d0
Content-Type: text/plain; charset=UTF-8

Based on reading the mailing list, it seems to me that there is rough
consensus
on PR#105, but not (yet?) on PR#107.

Chairs,
I'd like to merge PR#105. Do you agree that there is consensus? If so,
I will merge.

Can you please advise on how you would like to proceed on PR#107?

-Ekr




On Tue, Dec 30, 2014 at 2:03 AM, Dave Garrett 
wrote:

> Per Brian's suggestion, I've split the topic of full prohibition of SSL v2
> CLIENT-HELLO usage into its own issue, as there is clearly no consensus on
> this
> yet. It would be really nice if some real-world stats on how much this is
> actually used could be provided. (I think continued acceptance of it is
> illegitimate, but hard data is harder to argue with)
>
> Issue #113 Prohibit SSL v2 CLIENT-HELLO entirely
> https://github.com/tlswg/tls13-spec/issues/113
>
> I have heard notable support for this, including Eric, but I do concede
> there
> might be too much desire for infinite backwards compatibility to reach
> consensus.
> I'm still hopeful we can come to an agreement that two decades is a
> sufficient
> deprecation period. :/
>
> I have two PRs for the backwards compatibility section.
>
> The first has all SSL backwards compatibility changes. In addition to RFC
> 6176
> SSL 2 language, I've added SSL 3 negotiation prohibition as per Martin's
> suggestion (based on the current I-D). The v2 hello documentation is cut
> out,
> but seeing as it's only valid for prior versions, prior RFCs can be
> referenced
> if needed.
>
> PR #105 remove SSL 2 backwards compatibility section & prohibit SSL
> negotiation
> https://github.com/tlswg/tls13-spec/pull/105
>
> The second PR has more general backwards compatibility section
> improvements,
> prohibition of RC4 (also based on its current I-D), and Brian's ClientHello
> version freeze proposal. Currently, I have the ClientHello version listed
> as a
> "MUST", but I leave for the possibility that a "SHOULD" might be
> appropriate if
> other tactics for dealing with buggy servers should continue to be
> permitted.
> Feedback from Microsoft, Oracle, or anyone else implementing alternate
> workarounds here would be greatly appreciated.
>
> PR #107 revise backwards compatibility & fix ClientHello version
> https://github.com/tlswg/tls13-spec/pull/107
>
> Note that the SSL3 & RC4 language based on current drafts is of course
> contingent on those being passed successfully, though this is generally
> expected.
>
> Both PRs update the Informative References as needed, which I've hopefully
> done
> correctly.
>
>
> Dave
>

--f46d04428274eb4efc050d7f24d0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Based on reading the mailing list, it seems to me tha=
t there is rough consensus
on PR#105, but not (yet?) on PR#10=
7.

Chairs,
I'd like to merge PR#105.=
 Do you agree that there is consensus? If so,
I will merge.

Can you please advise on how you would like to proc=
eed on PR#107?

-Ekr


<=
/div>


On Tue, Dec 30, 2014 at 2:03 AM, Dave Garrett &l=
t;davemgarrett@=
gmail.com> wrote:
Per Bria=
n's suggestion, I've split the topic of full prohibition of SSL v2<=
br>
CLIENT-HELLO usage into its own issue, as there is clearly no consensus on =
this

yet. It would be really nice if some real-world stats on how much this is
actually used could be provided. (I think continued acceptance of it is

illegitimate, but hard data is harder to argue with)



Issue #113 Prohibit SSL v2 CLIENT-HELLO entirely

https://github.com/tlswg/tls13-spec/issues/113



I have heard notable support for this, including Eric, but I do concede the=
re

might be too much desire for infinite backwards compatibility to reach cons=
ensus.

I'm still hopeful we can come to an agreement that two decades is a suf=
ficient

deprecation period. :/



I have two PRs for the backwards compatibility section.



The first has all SSL backwards compatibility changes. In addition to RFC 6=
176

SSL 2 language, I've added SSL 3 negotiation prohibition as per Martin&=
#39;s

suggestion (based on the current I-D). The v2 hello documentation is cut ou=
t,

but seeing as it's only valid for prior versions, prior RFCs can be ref=
erenced

if needed.



PR #105 remove SSL 2 backwards compatibility section & prohibit SSL neg=
otiation

=
https://github.com/tlswg/tls13-spec/pull/105



The second PR has more general backwards compatibility section improvements=
,

prohibition of RC4 (also based on its current I-D), and Brian's ClientH=
ello

version freeze proposal. Currently, I have the ClientHello version listed a=
s a

"MUST", but I leave for the possibility that a "SHOULD"=
 might be appropriate if

other tactics for dealing with buggy servers should continue to be permitte=
d.

Feedback from Microsoft, Oracle, or anyone else implementing alternate

workarounds here would be greatly appreciated.



PR #107 revise backwards compatibility & fix ClientHello version

=
https://github.com/tlswg/tls13-spec/pull/107



Note that the SSL3 & RC4 language based on current drafts is of course<=
br>
contingent on those being passed successfully, though this is generally

expected.



Both PRs update the Informative References as needed, which I've hopefu=
lly done

correctly.





Dave





--f46d04428274eb4efc050d7f24d0--


From nobody Sun Jan 25 12:03:33 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA871A1B2D for ; Sun, 25 Jan 2015 12:03:32 -0800 (PST)
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_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 Din3rLt2jbHi for ; Sun, 25 Jan 2015 12:03:30 -0800 (PST)
Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6A121A1B06 for ; Sun, 25 Jan 2015 12:03:29 -0800 (PST)
Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 8D4311C204A; Sun, 25 Jan 2015 21:03:27 +0100 (CET)
Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 4A08A1FE01E6; Sun, 25 Jan 2015 21:03:27 +0100 (CET)
Date: Sun, 25 Jan 2015 21:03:27 +0100
From: Kurt Roeckx 
To: Dave Garrett 
Message-ID: <20150125200326.GA27020@roeckx.be>
References: <201412300503.03923.davemgarrett@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <201412300503.03923.davemgarrett@gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Cc: "TLS@ietf.org \(tls@ietf.org\)" 
Subject: Re: [TLS] consensus on backwards compatibility changes
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 25 Jan 2015 20:03:32 -0000

On Tue, Dec 30, 2014 at 05:03:03AM -0500, Dave Garrett wrote:
> PR #105 remove SSL 2 backwards compatibility section & prohibit SSL negotiation
> https://github.com/tlswg/tls13-spec/pull/105

I have a small problem with it.  It says:
| Implementations MUST NOT send an SSL version 2.0 compatible CLIENT-HELLO.
| Implementations MUST NOT negotiate TLS 1.3 or later using an SSL version 2.0 compatible
| CLIENT-HELLO. Implementations MAY accept an SSL version 2.0 compatible CLIENT-HELLO in
| order to negotiate older versions of TLS, however this is not recommended.
| Implementations MUST NOT send or accept any records with a version less than { 3, 0 }.

Doesn't that "or accept" prevent the previous sentence?  And isn't
the rest already covered by the first sentence?


Kurt


From nobody Sun Jan 25 15:14:42 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4D71A011B for ; Sun, 25 Jan 2015 15:14:41 -0800 (PST)
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 TrNRX2NW0isi for ; Sun, 25 Jan 2015 15:14:39 -0800 (PST)
Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B1AB1A00A3 for ; Sun, 25 Jan 2015 15:14:39 -0800 (PST)
Received: by mail-qg0-f45.google.com with SMTP id q107so4786778qgd.4 for ; Sun, 25 Jan 2015 15:14:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=gFc5/aObv5L+fWenRThnx50RtgGVz1baXszCMMDHDsg=; b=JcerUYQgASUf8ctUsfJPQS7FnHSTH5Ns+3RvUXmiPusvHYlR7yKQsXSciQdiyLSQmM A7SqRbfGAxJJKhmbIy3MTTl+x5MVSr2fWXelPeTDCAnCJRtw8sNKSxOS6W/RqjyhTIGK h0xJK5OKPiNahVRT/WDz9uICNSldYL4rM/g2b9n3HmqTeoNFsZZRnYKAPzAxeHjvRZLL ajud9N+Bau7qb34Wh6+nRApWl1VpjaZ4X+4idfJP+OJMJH7d7e8zEC5rmo3++dHu0Auq FAm2p5KWlJfldzRpDFIYtaYpgkHYyxFETUKscNs9Yan6RwTrrt8FK403f87BJelxiaEk 5xaw==
X-Received: by 10.140.19.139 with SMTP id 11mr35327254qgh.14.1422227678449; Sun, 25 Jan 2015 15:14:38 -0800 (PST)
Received: from dave-laptop.localnet ([96.245.56.59]) by mx.google.com with ESMTPSA id h34sm8316944qge.6.2015.01.25.15.14.37 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 25 Jan 2015 15:14:38 -0800 (PST)
From: Dave Garrett 
To: Kurt Roeckx 
Date: Sun, 25 Jan 2015 18:14:36 -0500
User-Agent: KMail/1.13.5 (Linux/2.6.32-70-generic-pae; KDE/4.4.5; i686; ; )
References: <201412300503.03923.davemgarrett@gmail.com> <20150125200326.GA27020@roeckx.be>
In-Reply-To: <20150125200326.GA27020@roeckx.be>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201501251814.36985.davemgarrett@gmail.com>
Archived-At: 
Cc: "TLS@ietf.org \(tls@ietf.org\)" 
Subject: Re: [TLS] consensus on backwards compatibility changes
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 25 Jan 2015 23:14:41 -0000

On Sunday, January 25, 2015 03:03:27 pm Kurt Roeckx wrote:
> On Tue, Dec 30, 2014 at 05:03:03AM -0500, Dave Garrett wrote:
> > PR #105 remove SSL 2 backwards compatibility section & prohibit SSL negotiation
> > https://github.com/tlswg/tls13-spec/pull/105
> 
> Doesn't that "or accept" prevent the previous sentence?  And isn't
> the rest already covered by the first sentence?

The SSL2 CLIENT-HELLO format can be used with TLS 1.0 (version {3,1}).

Explaining each part:

> | Implementations MUST NOT send an SSL version 2.0 compatible CLIENT-HELLO.

Regardless of what versions are in play, the SSL2 format is not allowed to be sent.
It can optionally still be accepted by servers, however, only for backwards compatibility.

> | Implementations MUST NOT negotiate TLS 1.3 or later using an SSL version 2.0 compatible
> | CLIENT-HELLO. Implementations MAY accept an SSL version 2.0 compatible CLIENT-HELLO in
> | order to negotiate older versions of TLS, however this is not recommended.

The old format can be used to negotiate TLS 1.0-1.2, but not 1.3+ or SSL.
Servers are not required to support this and can ignore them if preferred.

> | Implementations MUST NOT send or accept any records with a version less than { 3, 0 }.

Nothing stating a version for SSL2 or any bogus versions below SSL3 are allowed.
A v2 format hello with a TLS 1.0 version is unfortunately permitted.
Dropping support for this is an open issue:
https://github.com/tlswg/tls13-spec/issues/113

The minimum version tolerated here is for SSL3 due to the requirement to accept
record layer versions of any {3,X} for backwards compatibility. Hello record layer
versions mean pretty much nothing in current practice.


Dave


From nobody Sun Jan 25 15:34:24 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 233371A0264 for ; Sun, 25 Jan 2015 15:34:23 -0800 (PST)
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 J3Zqj2WW6_BG for ; Sun, 25 Jan 2015 15:34:21 -0800 (PST)
Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d: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 465981A023E for ; Sun, 25 Jan 2015 15:34:21 -0800 (PST)
Received: by mail-qg0-f49.google.com with SMTP id i50so4806947qgf.8 for ; Sun, 25 Jan 2015 15:34:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=QG8HMWcify1SRmdpTq0M5EowGEHqhxwZu85dX2w4oks=; b=0PFKe66yFyNR7YrEolSvXMdBm1LI2rxbhNSu7hsOdkeKa6G00BlaLXyWkJ2DEi2rMB vd27u66opMFPONFq8X52NeCjf5uZyTwqUtUn/Y9j4SyDFdRRzbEhUVY8dc+AvObN2gtV Kbhg43heg7NeEdJ+k8ohX9ounpJBx/xV4iPBS1l+CViynGLIrS9Mpl7jhsscFAjjQsTa NU5pBMbOt+bTxUyZsNq39gdOQcN0lzQF/vok/PAUvLPJ63NloBryxmeVLeUfyUpETvAF C65jmmseDptqqoGpBZ6w89KOLmLf3PHpUkSfz2WUAiJ66Mj5BOU7ACwSeykib3h/4dUQ sOdA==
X-Received: by 10.140.48.197 with SMTP id o63mr34624029qga.81.1422228860496; Sun, 25 Jan 2015 15:34:20 -0800 (PST)
Received: from dave-laptop.localnet ([96.245.56.59]) by mx.google.com with ESMTPSA id c3sm8335750qan.45.2015.01.25.15.34.19 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 25 Jan 2015 15:34:19 -0800 (PST)
From: Dave Garrett 
To: Eric Rescorla 
Date: Sun, 25 Jan 2015 18:33:50 -0500
User-Agent: KMail/1.13.5 (Linux/2.6.32-70-generic-pae; KDE/4.4.5; i686; ; )
References: <201412300503.03923.davemgarrett@gmail.com> 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <201501251833.50963.davemgarrett@gmail.com>
Archived-At: 
Cc: "TLS@ietf.org \(tls@ietf.org\)" 
Subject: Re: [TLS] consensus on backwards compatibility changes
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 25 Jan 2015 23:34:23 -0000

On Sunday, January 25, 2015 02:36:14 pm Eric Rescorla wrote:
> Based on reading the mailing list, it seems to me that there is rough
> consensus on PR#105, but not (yet?) on PR#107.

I don't recall any objections to #107, but not much discussion either.

To sum it up here, in addition to some editorial changes:

1) Fixes initial ClientHello record layer version to { 3, 1 } (TLS 1.0) & mandates
all other record layer versions to match negotiated version.
(Brian's suggestion)

In SCSV discussion, evidence was given that this improves interop by 5.3%
for TLS 1.3 & an additional 1.5% for TLS 1.2:
http://www.ietf.org/mail-archive/web/tls/current/msg15141.html

2) Mention some other interop concerns along side existing notes.

3) Cite RC4 prohibition pending RFC.

4) "If an implementation negotiates usage of TLS 1.2, then negotiation of cipher
suites also supported by TLS 1.3 SHOULD be preferred, if available."
(only a SHOULD, and only if available; language up for negotiation if needed)

5) Explicitly prohibit EXPORT ciphers and any others <100 bits.
(100 bit line is arbitrary; could be 112 if preferred)


Dave


From nobody Mon Jan 26 01:43:40 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 405EC1A701E for ; Mon, 26 Jan 2015 01:43:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level: 
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35, HTML_MESSAGE=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 SqfaFf_kffwA for ; Mon, 26 Jan 2015 01:43:37 -0800 (PST)
Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::12]) (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 274921A1B87 for ; Mon, 26 Jan 2015 01:43:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1422265414; l=3093; s=domk; d=zinks.de; h=Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From: Date; bh=OV8ozPqozhDTpiyRLbdUGK/oblkAbvLTtnNVzyHYiH4=; b=Eeg5IFJgDm82SlpL8+F/+i/ZiX/kOq70Lgg8OMz1TB1n6oqjfgScZABENJh/MoohTxz unj9nKEQwNnmRGpsRxY4G8fHfywlKR664LRx0AgeAfRMvto2o4GDoEq3WRXpdyy1p2YSM VS58YF6froDIZY/4GFttuDF7f8fm/Aa2FYU=
X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9KAK33vRJaCwLQNJU2mlIkBC0t1G+0bSVECAiLyJNOICzXh2STKTH/g8cJoUPuG6
X-RZG-CLASS-ID: mo00
Received: from [IPv6:2001:4dd0:ff67:0:8f9:68cf:6224:1b5b] ([2001:4dd0:ff67:0:8f9:68cf:6224:1b5b]) by smtp.strato.de (RZmta 37.1 AUTH) with ESMTPSA id L04136r0Q9hY0Sv (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) for ; Mon, 26 Jan 2015 10:43:34 +0100 (CET)
Message-ID: <54C60C45.3070407@zinks.de>
Date: Mon, 26 Jan 2015 10:43:33 +0100
From: Roland Zink 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: tls@ietf.org
References: <9A043F3CF02CD34C8E74AC1594475C73AAF64DCA@uxcn10-tdc05.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAF64DCA@uxcn10-tdc05.UoA.auckland.ac.nz>
Content-Type: multipart/alternative; boundary="------------050804060602050404060408"
Archived-At: 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Jan 2015 09:43:39 -0000

This is a multi-part message in MIME format.
--------------050804060602050404060408
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

On 25.01.2015 05:05, Peter Gutmann wrote:
> Aaron Zauner  writes:
>
>> That's a nice trick but as you point out pretty useless in terms of a PKI.
> It's done solely to deal with browsers, which demand to see a certificate when
> they're connecting to something via TLS.
>
> (Aside: You can see why some people think the CA/Browser forum as a conspiracy
>   to force the use of certs, despite there being very good alternatives
>   available browsers force you to use certificates whether they're appropriate
>   or not).
You probably need to blame IETF for this, for example RFC2818 (HTTP Over 
TLS) states:


      3.1 . Server Identity

In general, HTTP/TLS requests are generated by dereferencing a URI. As a 
consequence, the hostname for the server is known to the client. If the 
hostname is available, the client MUST check it against the server's 
identity as presented in the server's Certificate message, in order to 
prevent man-in-the-middle attacks.

Regards,
Roland


--------------050804060602050404060408
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 25.01.2015 05:05, Peter Gutmann
      wrote:

    

    

      
Aaron Zauner <azet@azet.org> writes:



      

        
That's a nice trick but as you point out pretty useless in terms of a PKI.


      

      
It's done solely to deal with browsers, which demand to see a certificate when
they're connecting to something via TLS.

(Aside: You can see why some people think the CA/Browser forum as a conspiracy
 to force the use of certs, despite there being very good alternatives
 available browsers force you to use certificates whether they're appropriate
 or not).


    

    You probably need to blame IETF for this, for example RFC2818 (HTTP
    Over TLS) states:

    

    
      
3.1.
        Server Identity

     In general, HTTP/TLS requests are generated by dereferencing
    a URI. As a consequence, the hostname for the server is known to the
    client. If the hostname is available, the client MUST check it
    against the server's identity as presented in the server's
    Certificate message, in order to prevent man-in-the-middle attacks.

    

    Regards,

    Roland

    

  


--------------050804060602050404060408--


From nobody Mon Jan 26 08:42:14 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8ED1AC40F for ; Mon, 26 Jan 2015 08:42:11 -0800 (PST)
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 JgC9wM5nqDC8 for ; Mon, 26 Jan 2015 08:42:07 -0800 (PST)
Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50FF01AC3FC for ; Mon, 26 Jan 2015 08:42:07 -0800 (PST)
Received: by mail-wi0-f173.google.com with SMTP id r20so11267833wiv.0 for ; Mon, 26 Jan 2015 08:42:06 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=qH94cotm2NZspQva6sBy/uFonR3w0sCV1QP7xHv3ipo=; b=j2JSvegGLPtsuGuvWuOWW6AWjBGRYBGM1PxjU4oIERnLqRgyaMvR3Tn4dy8ufz7Mhx 8xIJQXAOi6Ff92XhwttmYHm5a8CdzZE4ySovfb0I3FtqmiofBZPC3jPjYpwhwtZagTu1 EkJV+Giq2IgozUU+fGhOYu/Ot+zB+MXCcJnIN4dNAh6gX62DwMF/LFa08BxDxpJyaeTQ Xa021XjEs0UaM6UNASodZg12BRjqg95ThI1Tkg0y6+2VQuogexJAr5rIWv/RCWQx870h VZeshA75+ryiCyukAw2F5Cq5xh3+tDCjL9rKWMZ5k7vcjJG3We6yOHyNEC/p8E8pmDpY IlTw==
X-Gm-Message-State: ALoCoQkVqVPA+Crvhi7JYGwuOqoyHtgk/mDGYxCdUKXwNn9KuF8s64Z8o8DbdtJNiWB+N/gqkO2B
X-Received: by 10.180.20.141 with SMTP id n13mr34437186wie.73.1422290525257; Mon, 26 Jan 2015 08:42:05 -0800 (PST)
Received: from [10.0.0.142] (chello080108032135.14.11.univie.teleweb.at. [80.108.32.135]) by mx.google.com with ESMTPSA id e18sm15004475wjz.27.2015.01.26.08.42.04 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 26 Jan 2015 08:42:04 -0800 (PST)
Message-ID: <54C66E6C.9020607@azet.org>
Date: Mon, 26 Jan 2015 17:42:20 +0100
From: Aaron Zauner 
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: tls@ietf.org
References: <54B5501A.4070402@azet.org> <20150120191819.GA8165@typhoon.azet.org> <20150121222748.GA30732@randombit.net> <54C03D10.1090201@azet.org> <20150123153711.GA2758@randombit.net> <54C26FF5.8040506@azet.org>
In-Reply-To: <54C26FF5.8040506@azet.org>
X-Enigmail-Version: 1.2.3
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig56B7CD1DC4B4C7F328249854"
Archived-At: 
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Jan 2015 16:42:11 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig56B7CD1DC4B4C7F328249854
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi TLS-WG,

I've uploaded a new revision of my ID to the IETF website.

All suggested changes have been made. Further discussion and review is
very welcome.

```
Name:		draft-zauner-tls-aes-ocb
Revision:	02
Title:		AES-OCB (Offset Codebook Mode) Ciphersuites for Transport Layer
Security (TLS)
Document date:	2015-01-26
Group:		Individual Submission
Pages:		7
URL:
http://www.ietf.org/internet-drafts/draft-zauner-tls-aes-ocb-02.txt
Status:         https://datatracker.ietf.org/doc/draft-zauner-tls-aes-ocb=
/
Htmlized:       http://tools.ietf.org/html/draft-zauner-tls-aes-ocb-02
Diff:           http://www.ietf.org/rfcdiff?url2=3Ddraft-zauner-tls-aes-o=
cb-02
```

So far I've seen quite some support for this document and only a few
people disagreeing with -- in particular -- adding more ciphersuites to
the registry. I think OCB is a very good alternative to CCM and also
GCM. Would the WG be willing to take it on as a WG item/document?

Thanks,
Aaron



--------------enig56B7CD1DC4B4C7F328249854
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUxm5tAAoJEOTbZJL9ubXV46QQALOCZRqW9Z9dhT+3ZHXvDvtH
QxBMFZKsQkjwZB9p/UpPJaiJhWvn/pCWnuMN/qRfSVN6tZNoamvcenmcSxhDNofH
BJbuk5QMHhaGC3ezOZwNYP6dzTjCswWph+fljaP14WPGeyN1wXNFYJFmeHwuhasL
oG5eAGuICpBxLBORYLmosr/aE747NoJqTSU4xUy5bRt2mUlN80vLwJ9vtPENq9jL
7jW+8TnDhB8v3YW5XGV56sj70Aa50ZfUGmN5NeTsoqNhE9qYnz6ANgw+9XsERz5N
naLEgy4gvrvS/ufHKNnFr4MqxPfBG87LruMNBchwrrb2j7Z4pEJxYTJZAWboUq7a
Uq5upfsXZBCdk8ybwtQ8abSvaWwuB7moye19yQIBbYd62iRos3HaER6Dd1A9Js4K
tSA+Rb6Tb1Bzpw5W0mkEfCnbQiyYxKa2UpDp7U6Wmt4SFJfgMiPf5SzwrKEYuaFd
2HEqy3yTtougAlkchyQN7RfK0yssGEOb4j6ZzkK/A5Emh2Id9NStBQk4mnp02DDq
XVKyGt7jMYx3KvTtwCjd2RAytSYr0ZKiOpU1rUGswu7bHLTYgH/EfagOJqzFYymC
g5X9gihpCJ2suysyNN9oNbiE9JqTo9M2rmMcK8p5pupFEurju4slGpaEyxvuw3pM
ujsMQu61h0RciVv8tIJ6
=9GdV
-----END PGP SIGNATURE-----

--------------enig56B7CD1DC4B4C7F328249854--


From nobody Mon Jan 26 10:47:15 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9332C1ACDDC for ; Mon, 26 Jan 2015 10:47:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Level: 
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] 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 dtrD78S6FWYe for ; Mon, 26 Jan 2015 10:47:12 -0800 (PST)
Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AFA41ACDDB for ; Mon, 26 Jan 2015 10:47:12 -0800 (PST)
Received: by mail-la0-f50.google.com with SMTP id hs14so9258835lab.9 for ; Mon, 26 Jan 2015 10:47:10 -0800 (PST)
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:from:date :message-id:subject:to:cc:content-type; bh=PAl9Lc/NbT3zQMHHAEu5KcOnx2iBlNZ5se3tuATr2bo=; b=WNJJYGRGQ6hWywp1Ki5ye9GyO+HzaX594ypPFnxEslFYXBIC0wWFnh8w4V0Q5p/Iv/ r0iREsME/kh0o/k7Fu8PIJpmJLYuMTMIMGObJNxNXtZYFvJ+qQptiqOhw/jz3vgwnfRo iZnGCkovpNkWZaS6KiuCw7Qe0JjjRtApJC5OrdKPiaSzMJeck7wATaSbZkVRwdB9MfHl OVT7vLM1lvyWN0IJNJHMO2W5lHCWo3bVg4fFqulRMOKnHlSGrP81PLpMVQy3XmtWvhq7 Vj3NU6KoVHCrELZThjH8B0DgqjjhmxJg0IPH74ySFrxai1rHoAKPc9U/6rSaR0P+uynZ kvlg==
X-Gm-Message-State: ALoCoQnjPJ6XVTWMbjbEH6YamTLWwFqWmdL7PqZLVWkPFkg1SBf8CgFKqmk4zL79ghT32hmeHnHF
X-Received: by 10.152.88.44 with SMTP id bd12mr3232792lab.86.1422298030726; Mon, 26 Jan 2015 10:47:10 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.211.132 with HTTP; Mon, 26 Jan 2015 10:46:49 -0800 (PST)
In-Reply-To: 
References: <9A043F3CF02CD34C8E74AC1594475C73AAF525B9@uxcn10-tdc05.UoA.auckland.ac.nz>  <54B54A5F.7020401@polarssl.org>      <54B65AF0.1080503@metaparadigm.com>  
From: Joe Hall 
Date: Mon, 26 Jan 2015 13:46:49 -0500
Message-ID: 
To: Tom Ritter 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: =?UTF-8?Q?Manuel_P=C3=A9gouri=C3=A9=2DGonnard?= , tls@ietf.org
Subject: Re: [TLS] AAED ciphers: AES-GCM vs AES-EAX/AES-CCM: a meta-analysis
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Jan 2015 18:47:13 -0000

On Fri, Jan 23, 2015 at 8:26 PM, Tom Ritter  wrote:
>
> On Jan 14, 2015 11:20 AM, "Martin Thomson"  wrote:
>>
>> On 14 January 2015 at 04:02, Michael Clark 
>> wrote:
>> > Interesting. Should draft-pironti-tls-length-hiding-01 be added to
>> > Related Active Documents (not working group documents) section
>>
>> That's an automatically generated list.  I suspect the reason that it
>> doesn't appear is that it is presently expired.
>
> Something I feel very bad about. I am a big proponent of making length
> hiding possible in 1.3 and need to find time to put more effort into this.
> I encourage the chairs or WG to bug me if they don't see anything about this
> in a timeframe they expect.

Wasn't the discussion in Denver of the flavor that applications will
have to do length-hiding right if they want it to be secure so it
doesn't make sense to do it in TLS? I'm probably mischaracterizing
that, but I thought the outcome was more definitive than "maybe
someone will get to it". (i.e., some thought it would be a bad idea to
do it at all as it would be easy for applications to use it in an
insecure manner)

Apologies if this question is horribly naive. best, Joe

-- 
Joseph Lorenzo Hall
Chief Technologist
Center for Democracy & Technology
1634 I ST NW STE 1100
Washington DC 20006-4011
(p) 202-407-8825
(f) 202-637-0968
joe@cdt.org
PGP: https://josephhall.org/gpg-key
fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871


From nobody Mon Jan 26 11:08:52 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73D651ACEA5 for ; Mon, 26 Jan 2015 11:08:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, 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 tQ16pbvg9xiJ for ; Mon, 26 Jan 2015 11:08:47 -0800 (PST)
Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001: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 187FC1ACE9E for ; Mon, 26 Jan 2015 11:08:44 -0800 (PST)
Received: by mail-ig0-f173.google.com with SMTP id a13so11389igq.0 for ; Mon, 26 Jan 2015 11:08:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=TbZbY+O0fUVypHQzMBqRaMb5fvZaSvb6gUk8WuNFYgA=; b=QhJpAavKLCmFsnbUOH/Iqikh8/ExBfSVrv1YFFrNrKt7SYIkp29245y6wFwExpFMAQ 9kHfQIes3+P0HJk1JAQ2wCqCqNtoGY08cATFGt05bKFPrqgWD9oN16lPux7I/wjUWlXl OZ2GApBmNIAieMpBjwt8J9hKZp0ZgSgckHXiI=
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:from:date :message-id:subject:to:cc:content-type; bh=TbZbY+O0fUVypHQzMBqRaMb5fvZaSvb6gUk8WuNFYgA=; b=Zkkd4iEEI4UCJGvx8FGbjF1LC2hLc3veHTxk6CENkdl7q72cO8g2eA3xmZ8ULrsjfA EywKuO4ripl+ddwFTOrh9mkVYh7jI9gzaHAuBcF4tbiwfGwwvtMELYlJrnC/ImcfASXs RJtp0epJ5wavEeECozkS1hytV/JkWHr4uoznpIwp8ZvqJQVV47FQg6hgM6zgHhaOKUAH +KBQRzHaKegpR8QjI0OpS7ISV731qK9Itl4lR/7eVwRR/Z4NrklACftEG3yNvzzclhTD bxvNC6U5kLm2eK3c1a9tImyWGiP6y9EurJYNu6jspgJTiRHCHPH137uDDBBBiZMOhe/N L+cg==
X-Gm-Message-State: ALoCoQk2n1XyhokiiaQQhnmD9icWYCHQTNnC5QP5/WNTGV0hZ5LZJIiJy/3azaQGJtZhgKyvqONn
X-Received: by 10.107.40.69 with SMTP id o66mr19609978ioo.86.1422299322936; Mon, 26 Jan 2015 11:08:42 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.136.209 with HTTP; Mon, 26 Jan 2015 11:08:22 -0800 (PST)
In-Reply-To: 
References: <9A043F3CF02CD34C8E74AC1594475C73AAF525B9@uxcn10-tdc05.UoA.auckland.ac.nz>  <54B54A5F.7020401@polarssl.org>      <54B65AF0.1080503@metaparadigm.com>   
From: Tom Ritter 
Date: Mon, 26 Jan 2015 13:08:22 -0600
Message-ID: 
To: Joe Hall 
Content-Type: text/plain; charset=ISO-8859-1
Archived-At: 
Cc: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9=2DGonnard?= , "tls@ietf.org" 
Subject: Re: [TLS] AAED ciphers: AES-GCM vs AES-EAX/AES-CCM: a meta-analysis
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Jan 2015 19:08:49 -0000

On 26 January 2015 at 12:46, Joe Hall  wrote:
> Wasn't the discussion in Denver of the flavor that applications will
> have to do length-hiding right if they want it to be secure so it
> doesn't make sense to do it in TLS? I'm probably mischaracterizing
> that, but I thought the outcome was more definitive than "maybe
> someone will get to it". (i.e., some thought it would be a bad idea to
> do it at all as it would be easy for applications to use it in an
> insecure manner)

Length hiding in the application will be able provide more nuanced and
context-dependent protection, no doubt.  But that doesn't mean
providing it as a feature in the protocol is without merit.
Application-specific protection is more robust against adaptive query
attacks whether the adversary is measuring response time.  But for
response times visible in passive captures, an application is usually
not going to leak enough timing information for a reasonable guess on
a single query.  (Think an application taking more or less time to
process a small image versus a larger image - the "proper" way to do
this is inside the application, and have it adjust it's processing
time accordingly to not leak timing information.)

Length Hiding in TLS gets you good protection against passive captures
and lets you deploy the mechanism independent of building in the
feature at Layer 7 or above in multiple applications, application
protocols, web frameworks, etc.  (Some of which may be old and
unmaintained, but still running lots of services on the Internet.)

>From my recollection at Denver:
 - Consensus was we didn't want to pay a 2-byte penalty to put padding
in everywhere by default
 - Rough Consensus was padding without paying a penalty was something
reasonable to pursue
 - A few of us (dkg, myself, Alfonso) were going to think about how to
do that and also consider writing a BCP on why padding is useful, when
it makes sense, and rough strategies for doing it

-tom


From nobody Mon Jan 26 11:18:20 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D427B1ACEA3 for ; Mon, 26 Jan 2015 11:18:18 -0800 (PST)
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 KjeicjO-u0DV for ; Mon, 26 Jan 2015 11:18:17 -0800 (PST)
Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 947F61A8BC2 for ; Mon, 26 Jan 2015 11:18:17 -0800 (PST)
Received: by mail-oi0-f48.google.com with SMTP id v63so8795602oia.7 for ; Mon, 26 Jan 2015 11:18:17 -0800 (PST)
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=TqyeydooL6ckAzkEmurqMeovkN5PhiRAtS0GQYXDK5g=; b=qZeMOS24VMpcLImRTyLo9KDYM4QD2ceUxi9ealmyaYKL6wV4RAb67tf6f1NdZK9P43 2N1MMgg8WKeUAxnG/MMls4rbOIePU9FDywlnnLFdCfGl2DsyuaSye/IsW/3PLR6yKW0k VTrsMN2ptOwbdPBDvgF90Wtv/tX0/rUTLAf0E+lGWJubfKOhJ4O7NNXEmij7lYoKk16x SsWRIAMAAQe18x5Ni4okcC7pTALVFfcc2uPLODg9LFaaKrVJ2wv9hgp8g5rfnqg8FPQX V19zCZHfFEjU6Xz33R0/X0yJwzUQRUy+YKtEbrjaqACT42w8M1QAE0RdWeWUDnyccTK5 Kvlw==
MIME-Version: 1.0
X-Received: by 10.182.108.194 with SMTP id hm2mr13735948obb.85.1422299896974;  Mon, 26 Jan 2015 11:18:16 -0800 (PST)
Received: by 10.202.226.136 with HTTP; Mon, 26 Jan 2015 11:18:16 -0800 (PST)
In-Reply-To: 
References: <9A043F3CF02CD34C8E74AC1594475C73AAF525B9@uxcn10-tdc05.UoA.auckland.ac.nz>  <54B54A5F.7020401@polarssl.org>      <54B65AF0.1080503@metaparadigm.com>    
Date: Mon, 26 Jan 2015 11:18:16 -0800
Message-ID: 
From: Martin Thomson 
To: Tom Ritter 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: =?UTF-8?Q?Manuel_P=C3=A9gouri=C3=A9=2DGonnard?= , "tls@ietf.org" 
Subject: Re: [TLS] AAED ciphers: AES-GCM vs AES-EAX/AES-CCM: a meta-analysis
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Jan 2015 19:18:19 -0000

On 26 January 2015 at 11:08, Tom Ritter  wrote:
> From my recollection at Denver:
>  - Consensus was we didn't want to pay a 2-byte penalty to put padding
> in everywhere by default
>  - Rough Consensus was padding without paying a penalty was something
> reasonable to pursue
>  - A few of us (dkg, myself, Alfonso) were going to think about how to
> do that and also consider writing a BCP on why padding is useful, when
> it makes sense, and rough strategies for doing it

That matches my recollection.  I think that it was deferred so that we
could pay more attention to the handshake.  I'm hoping that we can
start nailing down the macro-level handshake details in the next
couple of months, allowing us to get to this, content-type encryption,
removal of the version number from the record layer, and various other
interesting proposals that have been on hold.


From nobody Mon Jan 26 12:25:30 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E66301A1B0C for ; Mon, 26 Jan 2015 12:25:27 -0800 (PST)
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_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 9WZgfdZwptHk for ; Mon, 26 Jan 2015 12:25:24 -0800 (PST)
Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DD3D1A1A8F for ; Mon, 26 Jan 2015 12:25:24 -0800 (PST)
Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 4F43B1C213A; Mon, 26 Jan 2015 21:25:22 +0100 (CET)
Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 2BF601FE01D3; Mon, 26 Jan 2015 21:25:22 +0100 (CET)
Date: Mon, 26 Jan 2015 21:25:22 +0100
From: Kurt Roeckx 
To: Dave Garrett 
Message-ID: <20150126202521.GA12484@roeckx.be>
References: <201412300503.03923.davemgarrett@gmail.com> <20150125200326.GA27020@roeckx.be> <201501251814.36985.davemgarrett@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <201501251814.36985.davemgarrett@gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Cc: "TLS@ietf.org \(tls@ietf.org\)" 
Subject: Re: [TLS] consensus on backwards compatibility changes
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Jan 2015 20:25:28 -0000

On Sun, Jan 25, 2015 at 06:14:36PM -0500, Dave Garrett wrote:
> On Sunday, January 25, 2015 03:03:27 pm Kurt Roeckx wrote:
> > On Tue, Dec 30, 2014 at 05:03:03AM -0500, Dave Garrett wrote:
> > > PR #105 remove SSL 2 backwards compatibility section & prohibit SSL negotiation
> > > https://github.com/tlswg/tls13-spec/pull/105
> > 
> > Doesn't that "or accept" prevent the previous sentence?  And isn't
> > the rest already covered by the first sentence?
> 
> The SSL2 CLIENT-HELLO format can be used with TLS 1.0 (version {3,1}).

I think there is some misunderstanding of how an SSLv2 client
hello works, or I'm not understanding what you're trying to say.

In SSLv2 the bytes of the record header are:
0: record length MSB, & 0x7f (or & 0x3f)
1: record length LSB


And for the record data:

0: message type (1, client hello)
1: highest supported version MSB
2: highest supported version LSB
[...]


Since SSLv3 this has changed.  It looks like:
0: record content type (22, handshake)
1: record protocol version major
2: record protocol version minor
3: record length msb
4: record length lsb

And then in the fragment you have:
0: handshake type (1, client hello)
1: handshake length MSB
2: handshake length
3: handshake length LSB
4: highest supported version major
5: highest supported version minor
[...]

I don't see how you're going to fit an SSLv2 client hello in an
SSLv3 or TLSv1 record.  Please note that for SSLv2 there is only 1
version field while with SSLv3 there are 2.

You could of course argue that there is no record protocol version
in SSLv2.

> > | Implementations MUST NOT send or accept any records with a version less than { 3, 0 }.
> 
> Nothing stating a version for SSL2 or any bogus versions below SSL3 are allowed.
> A v2 format hello with a TLS 1.0 version is unfortunately permitted.

So you're saying that things that implement TLS 1.3 MUST NOT
support negiotating SSLv2?  If that it what you mean, please say
that instead.


Kurt


From nobody Mon Jan 26 15:31:43 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 732A01A0079 for ; Mon, 26 Jan 2015 15:31:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1
X-Spam-Level: 
X-Spam-Status: No, score=-1 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, GB_SUMOF=1, 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 CgMPNYWw6BdZ for ; Mon, 26 Jan 2015 15:31:40 -0800 (PST)
Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18E301A0067 for ; Mon, 26 Jan 2015 15:31:40 -0800 (PST)
Received: by mail-qa0-f54.google.com with SMTP id w8so9182434qac.13 for ; Mon, 26 Jan 2015 15:31:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=k2RyXZynlBGonA5zEg1h6UKyBgstoGZu9JuabMwtFGQ=; b=HR2z4pzynfq8A98JUV8eicQDPhEwz8NFXyC83KmFaIZ0hMf7nbpkdQGjDL/w00etN9 xo28HS1oTXhShLYPXGLLJls3tGjsao+Tl7yu/pdNa0gddpDcq5/1YEnxIwSNaMe8YCmo bt+y7MDXVcXtgOcBXR8x3aj/Qg1dbnxi1V8ROPqTiZyPAhrqzo5mtU9hE63OZN/YZNpH UZrBUDTerDjXuVnhx6vVGxFNoe/8DFRj1+X/SCxtmCv8vc/W/MPqoiQhnCK1q7wdXPHY CPk0wJH2d16YFhhjrlARteg2oW3vxsiRqj9r6EUcxJCjqEoH7rWcHhUXMip6d2AAdv0k qmZw==
X-Received: by 10.140.23.84 with SMTP id 78mr1928533qgo.93.1422315099359; Mon, 26 Jan 2015 15:31:39 -0800 (PST)
Received: from dave-laptop.localnet (pool-72-92-42-38.phlapa.fios.verizon.net. [72.92.42.38]) by mx.google.com with ESMTPSA id 50sm7007930qgj.12.2015.01.26.15.31.38 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 26 Jan 2015 15:31:38 -0800 (PST)
From: Dave Garrett 
To: Kurt Roeckx 
Date: Mon, 26 Jan 2015 18:31:36 -0500
User-Agent: KMail/1.13.5 (Linux/2.6.32-70-generic-pae; KDE/4.4.5; i686; ; )
References: <201412300503.03923.davemgarrett@gmail.com> <201501251814.36985.davemgarrett@gmail.com> <20150126202521.GA12484@roeckx.be>
In-Reply-To: <20150126202521.GA12484@roeckx.be>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201501261831.36832.davemgarrett@gmail.com>
Archived-At: 
Cc: "TLS@ietf.org \(tls@ietf.org\)" 
Subject: Re: [TLS] consensus on backwards compatibility changes
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Jan 2015 23:31:41 -0000

On Monday, January 26, 2015 03:25:22 pm Kurt Roeckx wrote:
> I don't see how you're going to fit an SSLv2 client hello in an
> SSLv3 or TLSv1 record.

You don't. Please see the TLS 1.2 spec, RFC 5246 E.2. The deprecated
format is specified and instructed to be sent "directly on the wire, not
wrapped as a TLS record".

http://tools.ietf.org/html/rfc5246#appendix-E.2

These changes are in direct reference to that existing spec.

> So you're saying that things that implement TLS 1.3 MUST NOT
> support negiotating SSLv2?  If that it what you mean, please say
> that instead.

| Implementations MUST NOT send an SSL version 2.0 compatible CLIENT-HELLO.

The first sentence is sufficient to prohibit negotiating SSL2 entirely. I've also cited RFC 6176.
If you think this needs yet more, I guess I could stick a "and must not be negotiated"
onto the two lines citing RFC/I-D prohibitions, if you think it needs to be more clear. I have
nothing against adding redundancy here.

With regard to this topic, please see the previous discussion on list. (the "drop obsolete
SSL 2 backwards compatibility" thread) Implementers have specifically pushed back against
dropping all SSL 2 stuff, in particular because they think it is valid to still negotiate TLS 1.2
using an SSL version 2.0 client hello. I can understand why you'd have trouble
understanding this; I do too. :/

I'd much rather have an even simpler SSL backwards compatibility section with the sum
of the text being "NO", but there is not yet consensus on this.


Dave


From nobody Mon Jan 26 16:50:44 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 678271A1A33 for ; Mon, 26 Jan 2015 16:50:35 -0800 (PST)
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_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 q0z8BGw2M7HW for ; Mon, 26 Jan 2015 16:50:32 -0800 (PST)
Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 711041A1A29 for ; Mon, 26 Jan 2015 16:50:32 -0800 (PST)
Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id E6ECB1C213A; Tue, 27 Jan 2015 01:50:29 +0100 (CET)
Received: by intrepid.roeckx.be (Postfix, from userid 1000) id C3C751FE0576; Tue, 27 Jan 2015 01:50:29 +0100 (CET)
Date: Tue, 27 Jan 2015 01:50:29 +0100
From: Kurt Roeckx 
To: Dave Garrett 
Message-ID: <20150127005029.GA17682@roeckx.be>
References: <201412300503.03923.davemgarrett@gmail.com> <201501251814.36985.davemgarrett@gmail.com> <20150126202521.GA12484@roeckx.be> <201501261831.36832.davemgarrett@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <201501261831.36832.davemgarrett@gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Cc: "TLS@ietf.org \(tls@ietf.org\)" 
Subject: Re: [TLS] consensus on backwards compatibility changes
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Jan 2015 00:50:37 -0000

On Mon, Jan 26, 2015 at 06:31:36PM -0500, Dave Garrett wrote:
> > So you're saying that things that implement TLS 1.3 MUST NOT
> > support negiotating SSLv2?  If that it what you mean, please say
> > that instead.
> 
> | Implementations MUST NOT send an SSL version 2.0 compatible CLIENT-HELLO.
> 
> The first sentence is sufficient to prohibit negotiating SSL2 entirely. I've also cited RFC 6176.
> If you think this needs yet more, I guess I could stick a "and must not be negotiated"
> onto the two lines citing RFC/I-D prohibitions, if you think it needs to be more clear. I have
> nothing against adding redundancy here.

I guess if you really want you could go and put {3, 0} in the
record layer (so an SSLv3 client hello) and put {2, 0} in the
Client Hello.  In theory that should work if both support SSLv3
but for some reason want to talk SSLv2, but I doubt that it's
going to work in practice.  I also don't think that anybody is
going to do that.  I'm perfectly happy with that part of the
current text, and I did already interprete that as not allowing
the negiotation of SSLv2.

> With regard to this topic, please see the previous discussion on list. (the "drop obsolete
> SSL 2 backwards compatibility" thread) Implementers have specifically pushed back against
> dropping all SSL 2 stuff, in particular because they think it is valid to still negotiate TLS 1.2
> using an SSL version 2.0 client hello. I can understand why you'd have trouble
> understanding this; I do too. :/

I was part of that thread.  I think we need to support the SSLv2
client hello because their are still too many clients out there
that use it to set up TLS 1.0.  If you say we should drop TLS 1.0
support I'm happy to also drop the SSLv2 client hello support.

Anyway, I only had a problem understanding what you mean with:
| Implementations MUST NOT send or accept any records with a version less than { 3, 0 }.

So now I'm thinking that you're saying that you're not allowed to
use the SSLv3 record format and put SSLv2 in the record layer
version.  I'm not sure why you think anybody would do that or that
it's going to work, it's clearly not what you want to do in case
you want to send an SSLv2 compatible client hello.  But then
people might do all kinds of strange things and I doubt that will
stop them from doing it.


Kurt


From nobody Tue Jan 27 00:33:50 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5607A1A1B43 for ; Tue, 27 Jan 2015 00:33:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level: 
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, 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 6xgm2v-DTij3 for ; Tue, 27 Jan 2015 00:33:44 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31DD31A700B for ; Tue, 27 Jan 2015 00:33:44 -0800 (PST)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t0R8Xf7U004959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 27 Jan 2015 03:33:41 -0500
Received: from dhcp-2-127.brq.redhat.com (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t0R8XcOQ030165 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 27 Jan 2015 03:33:39 -0500
Message-ID: <1422347617.16764.4.camel@redhat.com>
From: Nikos Mavrogiannopoulos 
To: Tom Ritter 
Date: Tue, 27 Jan 2015 09:33:37 +0100
In-Reply-To: 
References: <9A043F3CF02CD34C8E74AC1594475C73AAF525B9@uxcn10-tdc05.UoA.auckland.ac.nz>  <54B54A5F.7020401@polarssl.org>      <54B65AF0.1080503@metaparadigm.com>    
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Archived-At: 
Cc: Manuel =?ISO-8859-1?Q?P=E9gouri=E9-Gonnard?= , "tls@ietf.org" 
Subject: Re: [TLS] AAED ciphers: AES-GCM vs AES-EAX/AES-CCM: a meta-analysis
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Jan 2015 08:33:47 -0000

On Mon, 2015-01-26 at 13:08 -0600, Tom Ritter wrote:

> Length Hiding in TLS gets you good protection against passive captures
> and lets you deploy the mechanism independent of building in the
> feature at Layer 7 or above in multiple applications, application
> protocols, web frameworks, etc.  (Some of which may be old and
> unmaintained, but still running lots of services on the Internet.)
> 
> >From my recollection at Denver:
>  - Consensus was we didn't want to pay a 2-byte penalty to put padding
> in everywhere by default
> - Rough Consensus was padding without paying a penalty was something
> reasonable to pursue
 
If that refers to draft-pironti-tls-length-hiding-02, I believe these
comments are mislead. There is no penalty "everywhere" as you pose it.
Peers who need no padding don't use the additional length bytes. Only
peers who need to hide length use these two bytes. This is not a
penalty, as it can simply be considered part of the pad (min size of pad
= 2).

regards,
Nikos



From nobody Tue Jan 27 03:58:48 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E23291A879E for ; Tue, 27 Jan 2015 03:58:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, 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 4xsRq4lcBp7W for ; Tue, 27 Jan 2015 03:58:45 -0800 (PST)
Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B9471A876C for ; Tue, 27 Jan 2015 03:58:45 -0800 (PST)
Received: by mail-ig0-f172.google.com with SMTP id l13so3814389iga.5 for ; Tue, 27 Jan 2015 03:58:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=24jOQwJ8aGzXnSSEQCPBW/uSvSRr3tCgCgSaiu7ESRI=; b=zO9ycBVgYw/+mhHIka/kD9KdF1gmEoS/7Cur2FnotLyug6vzH2envLlirV81sqKFIU DENhBjPj0fNAd5GtY6ykuyTcy1sezdObg3MKO7L1fldsd879ckG/LcgnQKO4xu8zXIGb PpnZvJ8OkLoqRGChKwhs/80K6YW9y1+W97Ly0=
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:from:date :message-id:subject:to:cc:content-type; bh=24jOQwJ8aGzXnSSEQCPBW/uSvSRr3tCgCgSaiu7ESRI=; b=McsCOo/uQETuQNVH04xiN7KXE0Ethwfou9smIRn3eH5kFs931SiHMtv0Z+/6J6DMNn ET+hPOrJgTH7Ty5SdTG19IE4RlTk2Jff3ZmVdHkiRzgOU6phJjMHMOmF6adf733R46A1 qez4jKozNAj4KunkXHx1Z5AybILcvefI3XieEOMJcl7Fh18KpO4t7RvAZFZmzm+YF/kk XTFlADiYVqOGtdjztZ9x2QEb8xxeIEikT9fSb3I1f00sQIScrWcVH0vn5eBRVXbM+9rl sW69O2tuT7ocrmQFMN6wFLjBplCL/eQwnbm5jLuN2hzQrROeCSYzFNecAg8gwyZwu8/D SioA==
X-Gm-Message-State: ALoCoQkTQe+faKvbG5xeD3EMWieOv2AolZUpw42UMkiZFwsX7Xr4ksEPtM5b2lmeHqTkUalBl5A8
X-Received: by 10.107.137.77 with SMTP id l74mr891811iod.9.1422359924776; Tue, 27 Jan 2015 03:58:44 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.136.209 with HTTP; Tue, 27 Jan 2015 03:58:24 -0800 (PST)
In-Reply-To: <1422347617.16764.4.camel@redhat.com>
References: <9A043F3CF02CD34C8E74AC1594475C73AAF525B9@uxcn10-tdc05.UoA.auckland.ac.nz>  <54B54A5F.7020401@polarssl.org>      <54B65AF0.1080503@metaparadigm.com>     <1422347617.16764.4.camel@redhat.com>
From: Tom Ritter 
Date: Tue, 27 Jan 2015 03:58:24 -0800
Message-ID: 
To: Nikos Mavrogiannopoulos 
Content-Type: text/plain; charset=ISO-8859-1
Archived-At: 
Cc: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9=2DGonnard?= , "tls@ietf.org" 
Subject: Re: [TLS] AAED ciphers: AES-GCM vs AES-EAX/AES-CCM: a meta-analysis
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Jan 2015 11:58:47 -0000

On 27 January 2015 at 00:33, Nikos Mavrogiannopoulos  wrote:
> On Mon, 2015-01-26 at 13:08 -0600, Tom Ritter wrote:
>
>> Length Hiding in TLS gets you good protection against passive captures
>> and lets you deploy the mechanism independent of building in the
>> feature at Layer 7 or above in multiple applications, application
>> protocols, web frameworks, etc.  (Some of which may be old and
>> unmaintained, but still running lots of services on the Internet.)
>>
>> >From my recollection at Denver:
>>  - Consensus was we didn't want to pay a 2-byte penalty to put padding
>> in everywhere by default
>> - Rough Consensus was padding without paying a penalty was something
>> reasonable to pursue
>
> If that refers to draft-pironti-tls-length-hiding0-2, I believe these
> comments are mislead. There is no penalty "everywhere" as you pose it.
> Peers who need no padding don't use the additional length bytes. Only
> peers who need to hide length use these two bytes. This is not a
> penalty, as it can simply be considered part of the pad (min size of pad
> = 2).

Yes, draft-pironti-tls-length-hiding-02 does not put a penalty
everywhere. One of the initial discussions was "Let's not make it an
option, let's just have padding by default, and the folks who don't
want to use it will put a zero-length pad".  But to do so, AIUI, we
needed to stash a 2 byte padding length somewhere. (Hence paying the
cost.) People didn't want to pay the extra two bytes all the time, so
we started looking at using an alternate record type (possibly
encrypting them), or an extension as in the draft...

-tom


From nobody Tue Jan 27 08:45:19 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32C161A8974 for ; Tue, 27 Jan 2015 08:45:10 -0800 (PST)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 Q94KfGSoOcs9 for ; Tue, 27 Jan 2015 08:45:04 -0800 (PST)
Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D86751A1BF5 for ; Tue, 27 Jan 2015 08:42:23 -0800 (PST)
Received: by mail-qc0-f181.google.com with SMTP id l6so12808959qcy.12 for ; Tue, 27 Jan 2015 08:42:23 -0800 (PST)
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=WoPQ7vrphVp7q99gVAfJxtg5fsn4jV9r1gRVBYUOtwg=; b=UIr8ULNl5kNR68pNs0mbx9IANXmxq5OHi5S5rJlcbWAQ9wei0kYmzTg1qNxEPlLqMG geppOQWAYHuXj5rnSJ6AlHw2zUE6WbW59Bw/oqx3jJyV0FHOWZ18vsCjanJYkwd6fxSq PGylcm86K6y+4cKJcrm+jkNL85Q5skIYGh9Rz0fcClBk3r7Z8idgNBo9u8TpuBMDL03q ekBkYEFJJVWWFIZrSCItfVpZFkXSJDzaiKJ926F0Ht7e1DtSrXh8tcRaDEek5XIlMpqm Ek7X3Y6xorJfRc/mj02XBq+KiFNKbchplU9Ufjf8vFKzVfgm2rWtHGMTlRgPulG8gyw4 EnRQ==
X-Gm-Message-State: ALoCoQlfRI8v/J4yp2t2rIyVqnuEkZ8XKTydNVsddZgwmXThNG33eZ2wJf8CLaT+We1sg3YlqM3L
MIME-Version: 1.0
X-Received: by 10.229.80.3 with SMTP id r3mr1792058qck.23.1422376943017; Tue, 27 Jan 2015 08:42:23 -0800 (PST)
Received: by 10.96.238.73 with HTTP; Tue, 27 Jan 2015 08:42:22 -0800 (PST)
X-Originating-IP: [50.206.82.141]
In-Reply-To: <201501251833.50963.davemgarrett@gmail.com>
References: <201412300503.03923.davemgarrett@gmail.com>  <201501251833.50963.davemgarrett@gmail.com>
Date: Tue, 27 Jan 2015 08:42:22 -0800
Message-ID: 
From: Joseph Salowey 
To: Dave Garrett 
Content-Type: multipart/alternative; boundary=001a1133cb786cf476050da4f0b8
Archived-At: 
Cc: "TLS@ietf.org \(tls@ietf.org\)" 
Subject: Re: [TLS] consensus on backwards compatibility changes
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Jan 2015 16:45:10 -0000

--001a1133cb786cf476050da4f0b8
Content-Type: text/plain; charset=UTF-8

On Sun, Jan 25, 2015 at 3:33 PM, Dave Garrett 
wrote:

> On Sunday, January 25, 2015 02:36:14 pm Eric Rescorla wrote:
> > Based on reading the mailing list, it seems to me that there is rough
> > consensus on PR#105, but not (yet?) on PR#107.
>
> I don't recall any objections to #107, but not much discussion either.
>
> To sum it up here, in addition to some editorial changes:
>
> 1) Fixes initial ClientHello record layer version to { 3, 1 } (TLS 1.0) &
> mandates
> all other record layer versions to match negotiated version.
> (Brian's suggestion)
>
>
[Joe] I think this makes sense.  I added to comments to the PR.  I propose
to move the bit about the server accepting versions {3,x} to the same place
and change the wording of the existing test to say:

"The client MUST set the version to {3, 1} for the initial ClientHello."



> In SCSV discussion, evidence was given that this improves interop by 5.3%
> for TLS 1.3 & an additional 1.5% for TLS 1.2:
> http://www.ietf.org/mail-archive/web/tls/current/msg15141.html
>
> 2) Mention some other interop concerns along side existing notes.
>
> 3) Cite RC4 prohibition pending RFC.
>
> 4) "If an implementation negotiates usage of TLS 1.2, then negotiation of
> cipher
> suites also supported by TLS 1.3 SHOULD be preferred, if available."
> (only a SHOULD, and only if available; language up for negotiation if
> needed)
>
> 5) Explicitly prohibit EXPORT ciphers and any others <100 bits.
> (100 bit line is arbitrary; could be 112 if preferred)
>
>
[Joe] draft-ietf-uta-tls-bcp-08 recommends 112 so we probably would match
that.


>
> Dave
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--001a1133cb786cf476050da4f0b8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Sun, Jan 25, 2015 at 3:33 PM, Dave Garrett <davemgarrett@gmail=
.com> wrote:
On Sunday, January 25,=
 2015 02:36:14 pm Eric Rescorla wrote:

> Based on reading the mailing list, it seems to me that there is rough<=
br>
> consensus on PR#105, but not (yet?) on PR#107.



I don't recall any objections to #107, but not much discussion e=
ither.



To sum it up here, in addition to some editorial changes:



1) Fixes initial ClientHello record layer version to { 3, 1 } (TLS 1.0) &am=
p; mandates

all other record layer versions to match negotiated version.

(Brian's suggestion)



[Joe] I think this makes sense.=C2=A0 =
I added to comments to the PR.=C2=A0 I propose to move the bit about the se=
rver accepting versions {3,x} to the same place and change the wording of t=
he existing test to say:

"The clien=
t MUST set the version to {3, 1} for the initial ClientHello."<=
br>

=C2=A0

In SCSV discussion, evidence was given that this improves interop by 5.3%
for TLS 1.3 & an additional 1.5% for TLS 1.2:

http://www.ietf.org/mail-archive/web/tls/current/msg15141=
.html



2) Mention some other interop concerns along side existing notes.



3) Cite RC4 prohibition pending RFC.



4) "If an implementation negotiates usage of TLS 1.2, then negotiation=
 of cipher

suites also supported by TLS 1.3 SHOULD be preferred, if available."
(only a SHOULD, and only if available; language up for negotiation if neede=
d)



5) Explicitly prohibit EXPORT ciphers and any others <100 bits.

(100 bit line is arbitrary; could be 112 if preferred)




[Joe]=C2=A0draft=
-ietf-uta-tls-bcp-08 recommends 112 so we probably would match that. =C2=A0=

=C2=A0



Dave



_______________________________________________

TLS mailing list

TLS@ietf.org

htt=
ps://www.ietf.org/mailman/listinfo/tls





--001a1133cb786cf476050da4f0b8--


From nobody Tue Jan 27 09:21:21 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AEFE1A88A7 for ; Tue, 27 Jan 2015 09:21:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.567
X-Spam-Level: 
X-Spam-Status: No, score=-0.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_BARE_IP_2=1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 pTS0H1jkctls for ; Tue, 27 Jan 2015 09:21:09 -0800 (PST)
Received: from gateway13.websitewelcome.com (gateway13.websitewelcome.com [67.18.71.14]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA0691A889D for ; Tue, 27 Jan 2015 09:21:07 -0800 (PST)
Received: by gateway13.websitewelcome.com (Postfix, from userid 5007) id 01B1866F4476A; Tue, 27 Jan 2015 11:21:07 -0600 (CST)
Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway13.websitewelcome.com (Postfix) with ESMTP id D8B2566F446E4 for ; Tue, 27 Jan 2015 11:21:06 -0600 (CST)
Received: from [96.231.226.60] (port=65043 helo=192.168.1.2) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1YG9p3-0007FD-Vv; Tue, 27 Jan 2015 11:21:06 -0600
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Sean Turner 
In-Reply-To: 
Date: Tue, 27 Jan 2015 12:21:03 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <83CBC7E2-CDC9-4EDD-8648-8C80EE588343@ieca.com>
References: <201412300503.03923.davemgarrett@gmail.com> 
To: Eric Rescorla 
X-Mailer: Apple Mail (2.1878.6)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator3286.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ieca.com
X-BWhitelist: no
X-Source-IP: 96.231.226.60
X-Exim-ID: 1YG9p3-0007FD-Vv
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: (192.168.1.2) [96.231.226.60]:65043
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 3
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20=
Archived-At: 
Cc: "TLS@ietf.org \(tls@ietf.org\)" 
Subject: Re: [TLS] consensus on backwards compatibility changes
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Jan 2015 17:21:11 -0000

We believe that what=92s reflected in PR #105 reflects list consensus.  =
But, we (as chairs) have a couple of thoughts:

0) We both hate =93MAY=94 requirements language.  We=92d prefer that the =
following be reworded (this is just a starting point):

OLD:

 Implementations MAY accept an SSL version 2.0 compatible
 CLIENT-HELLO in order to negotiate older versions of TLS,
 however this is not recommended.

NEW:

 Implementations are NOT RECOMMENDED to accept an
 SSL version 2.0 compatible CLIENT-HELLO in order to
 negotiate older versions of TLS.

note that the using =93NOT RECOMMENDED=94 also means we need to add that =
to the 2119 language clause but we can do that later.  Basically:

s1.1: OLD:

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in RFC 2119 [RFC2119].

NEW:

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", =93SHALL NOT=94,
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED=94,
 "MAY", and "OPTIONAL" in this document are to be interpreted as =
described
 in RFC 2119 [RFC2119].

1) We=92d like to make it crystal clear in the SSL3.0 text whether =
you=92re talking about the hello version or record version. We=92re =
pretty sure that =93protocol version=94 in the following is the hello =
version but we think that should be made clear.

 Implementations MUST NOT send a ClientHello or ServerHello with
 the protocol version set to { 3, 0 } or less. Any endpoint receiving a
 Hello message with the protocol version set to { 3, 0 } MUST respond
 with a "protocol_version" alert message and close the connection.

spt

On Jan 25, 2015, at 14:36, Eric Rescorla  wrote:

> Based on reading the mailing list, it seems to me that there is rough =
consensus
> on PR#105, but not (yet?) on PR#107.
>=20
> Chairs,
> I'd like to merge PR#105. Do you agree that there is consensus? If so,
> I will merge.
>=20
> Can you please advise on how you would like to proceed on PR#107?
>=20
> -Ekr
>=20
>=20
>=20
>=20
> On Tue, Dec 30, 2014 at 2:03 AM, Dave Garrett  =
wrote:
> Per Brian's suggestion, I've split the topic of full prohibition of =
SSL v2
> CLIENT-HELLO usage into its own issue, as there is clearly no =
consensus on this
> yet. It would be really nice if some real-world stats on how much this =
is
> actually used could be provided. (I think continued acceptance of it =
is
> illegitimate, but hard data is harder to argue with)
>=20
> Issue #113 Prohibit SSL v2 CLIENT-HELLO entirely
> https://github.com/tlswg/tls13-spec/issues/113
>=20
> I have heard notable support for this, including Eric, but I do =
concede there
> might be too much desire for infinite backwards compatibility to reach =
consensus.
> I'm still hopeful we can come to an agreement that two decades is a =
sufficient
> deprecation period. :/
>=20
> I have two PRs for the backwards compatibility section.
>=20
> The first has all SSL backwards compatibility changes. In addition to =
RFC 6176
> SSL 2 language, I've added SSL 3 negotiation prohibition as per =
Martin's
> suggestion (based on the current I-D). The v2 hello documentation is =
cut out,
> but seeing as it's only valid for prior versions, prior RFCs can be =
referenced
> if needed.
>=20
> PR #105 remove SSL 2 backwards compatibility section & prohibit SSL =
negotiation
> https://github.com/tlswg/tls13-spec/pull/105
>=20
> The second PR has more general backwards compatibility section =
improvements,
> prohibition of RC4 (also based on its current I-D), and Brian's =
ClientHello
> version freeze proposal. Currently, I have the ClientHello version =
listed as a
> "MUST", but I leave for the possibility that a "SHOULD" might be =
appropriate if
> other tactics for dealing with buggy servers should continue to be =
permitted.
> Feedback from Microsoft, Oracle, or anyone else implementing alternate
> workarounds here would be greatly appreciated.
>=20
> PR #107 revise backwards compatibility & fix ClientHello version
> https://github.com/tlswg/tls13-spec/pull/107
>=20
> Note that the SSL3 & RC4 language based on current drafts is of course
> contingent on those being passed successfully, though this is =
generally
> expected.
>=20
> Both PRs update the Informative References as needed, which I've =
hopefully done
> correctly.
>=20
>=20
> Dave
>=20
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


From nobody Tue Jan 27 09:33:40 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DDA01A8854 for ; Tue, 27 Jan 2015 09:33:39 -0800 (PST)
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 Z78MYoe18djI for ; Tue, 27 Jan 2015 09:33:36 -0800 (PST)
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 5395B1A1A94 for ; Tue, 27 Jan 2015 09:33:36 -0800 (PST)
Received: by mail-wi0-f180.google.com with SMTP id h11so6585735wiw.1 for ; Tue, 27 Jan 2015 09:33:35 -0800 (PST)
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=jrljTCB3gzZI2++8Het9jMWoDbY7D5wQ9rX2duSyMik=; b=fVrqt7FoSkWK+1PrremMypIiyUMLAX/e9IHX//gCbjC3CIwgw0+tgeUQeu5Taa9Sem 86sVvqWEI+Lw5rhFiAPl2xoZaIcDwvsG7WjP1Lh/LGPilIHPAjkIUuqlmWnho1teBcGq UJ7rJsGRnzj8h+x/1gPtY6kq2BiGfKdC3rITpDbkTOaXoYZ3A4NeHRc1n6lRwWMGEeRz cwdjRTp3UQ5RYzvX/2AjTBGFRFyd+KAZnlici3XqVscUqaYKhdERWDt8hYM3MTG0O6zU 1CT4uDi95KTEcvMX4GiYGpKMziQ4AnpvgAl7Qkhlprtb2doOdq3zyvsDyYuRGKvOiVFL AioA==
X-Received: by 10.180.108.165 with SMTP id hl5mr39131296wib.39.1422380014992;  Tue, 27 Jan 2015 09:33:34 -0800 (PST)
MIME-Version: 1.0
Received: by 10.27.32.77 with HTTP; Tue, 27 Jan 2015 09:33:14 -0800 (PST)
In-Reply-To: <83CBC7E2-CDC9-4EDD-8648-8C80EE588343@ieca.com>
References: <201412300503.03923.davemgarrett@gmail.com>  <83CBC7E2-CDC9-4EDD-8648-8C80EE588343@ieca.com>
From: Ira McDonald 
Date: Tue, 27 Jan 2015 12:33:14 -0500
Message-ID: 
To: Sean Turner , Ira McDonald 
Content-Type: multipart/alternative; boundary=e89a8f3ba1018839ff050da5a786
Archived-At: 
Cc: "TLS@ietf.org \(tls@ietf.org\)" 
Subject: Re: [TLS] consensus on backwards compatibility changes
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Jan 2015 17:33:39 -0000

--e89a8f3ba1018839ff050da5a786
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Sean,

With respect, "are NOT RECOMMENDED" is a passive voice
synonym for active voice "SHOULD NOT" (and terrible English).

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 Tue, Jan 27, 2015 at 12:21 PM, Sean Turner  wrote:

> We believe that what=E2=80=99s reflected in PR #105 reflects list consens=
us.  But,
> we (as chairs) have a couple of thoughts:
>
> 0) We both hate =E2=80=9CMAY=E2=80=9D requirements language.  We=E2=80=99=
d prefer that the
> following be reworded (this is just a starting point):
>
> OLD:
>
>  Implementations MAY accept an SSL version 2.0 compatible
>  CLIENT-HELLO in order to negotiate older versions of TLS,
>  however this is not recommended.
>
> NEW:
>
>  Implementations are NOT RECOMMENDED to accept an
>  SSL version 2.0 compatible CLIENT-HELLO in order to
>  negotiate older versions of TLS.
>
> note that the using =E2=80=9CNOT RECOMMENDED=E2=80=9D also means we need =
to add that to
> the 2119 language clause but we can do that later.  Basically:
>
> s1.1: OLD:
>
>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>  document are to be interpreted as described in RFC 2119 [RFC2119].
>
> NEW:
>
>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", =E2=80=9CSHALL NO=
T=E2=80=9D,
>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED=E2=80=9D,
>  "MAY", and "OPTIONAL" in this document are to be interpreted as describe=
d
>  in RFC 2119 [RFC2119].
>
> 1) We=E2=80=99d like to make it crystal clear in the SSL3.0 text whether =
you=E2=80=99re
> talking about the hello version or record version. We=E2=80=99re pretty s=
ure that
> =E2=80=9Cprotocol version=E2=80=9D in the following is the hello version =
but we think that
> should be made clear.
>
>  Implementations MUST NOT send a ClientHello or ServerHello with
>  the protocol version set to { 3, 0 } or less. Any endpoint receiving a
>  Hello message with the protocol version set to { 3, 0 } MUST respond
>  with a "protocol_version" alert message and close the connection.
>
> spt
>
> On Jan 25, 2015, at 14:36, Eric Rescorla  wrote:
>
> > Based on reading the mailing list, it seems to me that there is rough
> consensus
> > on PR#105, but not (yet?) on PR#107.
> >
> > Chairs,
> > I'd like to merge PR#105. Do you agree that there is consensus? If so,
> > I will merge.
> >
> > Can you please advise on how you would like to proceed on PR#107?
> >
> > -Ekr
> >
> >
> >
> >
> > On Tue, Dec 30, 2014 at 2:03 AM, Dave Garrett 
> wrote:
> > Per Brian's suggestion, I've split the topic of full prohibition of SSL
> v2
> > CLIENT-HELLO usage into its own issue, as there is clearly no consensus
> on this
> > yet. It would be really nice if some real-world stats on how much this =
is
> > actually used could be provided. (I think continued acceptance of it is
> > illegitimate, but hard data is harder to argue with)
> >
> > Issue #113 Prohibit SSL v2 CLIENT-HELLO entirely
> > https://github.com/tlswg/tls13-spec/issues/113
> >
> > I have heard notable support for this, including Eric, but I do concede
> there
> > might be too much desire for infinite backwards compatibility to reach
> consensus.
> > I'm still hopeful we can come to an agreement that two decades is a
> sufficient
> > deprecation period. :/
> >
> > I have two PRs for the backwards compatibility section.
> >
> > The first has all SSL backwards compatibility changes. In addition to
> RFC 6176
> > SSL 2 language, I've added SSL 3 negotiation prohibition as per Martin'=
s
> > suggestion (based on the current I-D). The v2 hello documentation is cu=
t
> out,
> > but seeing as it's only valid for prior versions, prior RFCs can be
> referenced
> > if needed.
> >
> > PR #105 remove SSL 2 backwards compatibility section & prohibit SSL
> negotiation
> > https://github.com/tlswg/tls13-spec/pull/105
> >
> > The second PR has more general backwards compatibility section
> improvements,
> > prohibition of RC4 (also based on its current I-D), and Brian's
> ClientHello
> > version freeze proposal. Currently, I have the ClientHello version
> listed as a
> > "MUST", but I leave for the possibility that a "SHOULD" might be
> appropriate if
> > other tactics for dealing with buggy servers should continue to be
> permitted.
> > Feedback from Microsoft, Oracle, or anyone else implementing alternate
> > workarounds here would be greatly appreciated.
> >
> > PR #107 revise backwards compatibility & fix ClientHello version
> > https://github.com/tlswg/tls13-spec/pull/107
> >
> > Note that the SSL3 & RC4 language based on current drafts is of course
> > contingent on those being passed successfully, though this is generally
> > expected.
> >
> > Both PRs update the Informative References as needed, which I've
> hopefully done
> > correctly.
> >
> >
> > Dave
> >
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--e89a8f3ba1018839ff050da5a786
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Sean,

With respect, "are NOT RECOMMENDED" is a passive =
voice
synonym for active voice "SHOULD NOT" (and terrible Engl=
ish).

Cheers,
- Ira


Ira McDonald (Musician / Software Architec=
t)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundat=
ion Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-C=
hair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Exper=
t - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
ma=
ilto: blueroof=
music@gmail.com
Winter=C2=A0 579 Park Place=C2=A0 Saline, MI=C2=A0 4=
8176=C2=A0 734-944-0094
Summer=C2=A0 PO Box 221=C2=A0 Grand Marais, MI 4=
9839=C2=A0 906-494-2434

=



On Tue, Jan 27, 2015 at 12:21 PM, Sean Turne=
r <turners@ieca.com> wrote:
We believe that what=E2=80=99s reflected in PR #105 reflects list consensu=
s.=C2=A0 But, we (as chairs) have a couple of thoughts:



0) We both hate =E2=80=9CMAY=E2=80=9D requirements language.=C2=A0 We=E2=80=
=99d prefer that the following be reworded (this is just a starting point):=




OLD:



=C2=A0Implementations MAY accept an SSL version 2.0 compatible

=C2=A0CLIENT-HELLO in order to negotiate older versions of=
 TLS,

=C2=A0however this is not recommended.



NEW:



=C2=A0Implementations are NOT RECOMMENDED to accept an

=C2=A0SSL version 2.0 compatible CLIENT-HELLO in order to<=
br>
=C2=A0negotiate older versions of TLS.



note that the using =E2=80=9CNOT RECOMMENDED=E2=80=9D also means we need to=
 add that to the 2119 language clause but we can do that later.=C2=A0 Basic=
ally:



s1.1: OLD:



=C2=A0The key words "MUST", "MUST NOT", "REQUIRED&=
quot;, "SHALL", "SHALL NOT",

=C2=A0"SHOULD", "SHOULD NOT", "RECOMMENDED", =
"MAY", and "OPTIONAL" in this

=C2=A0document are to be interpreted as described in RFC 2119 [RFC2119].


NEW:



=C2=A0The key words "MUST", "MUST NOT", "REQUIRED&=
quot;, "SHALL", =E2=80=9CSHALL NOT=E2=80=9D,

=C2=A0"SHOULD", "SHOULD NOT", "RECOMMENDED", =
"NOT RECOMMENDED=E2=80=9D,

=C2=A0"MAY", and "OPTIONAL" in this document are to be =
interpreted as described

=C2=A0in RFC 2119 [RFC2119].



1) We=E2=80=99d like to make it crystal clear in the SSL3.0 text whether yo=
u=E2=80=99re talking about the hello version or record version. We=E2=80=99=
re pretty sure that =E2=80=9Cprotocol version=E2=80=9D in the following is =
the hello version but we think that should be made clear.



=C2=A0Implementations MUST NOT send a ClientHello or ServerHello with

=C2=A0the protocol version set to { 3, 0 } or less. Any endpoint receiving =
a

=C2=A0Hello message with the protocol version set to { 3, 0 } MUST respond<=
br>
=C2=A0with a "protocol_version" alert message and close the conne=
ction.



spt




On Jan 25, 2015, at 14:36, Eric Rescorla <ekr@rtfm.com> wrote:



> Based on reading the mailing list, it seems to me that there is rough =
consensus

> on PR#105, but not (yet?) on PR#107.

>

> Chairs,

> I'd like to merge PR#105. Do you agree that there is consensus? If=
 so,

> I will merge.

>

> Can you please advise on how you would like to proceed on PR#107?

>

> -Ekr

>

>

>

>

> On Tue, Dec 30, 2014 at 2:03 AM, Dave Garrett <davemgarrett@gmail.com> wrote:

> Per Brian's suggestion, I've split the topic of full prohibiti=
on of SSL v2

> CLIENT-HELLO usage into its own issue, as there is clearly no consensu=
s on this

> yet. It would be really nice if some real-world stats on how much this=
 is

> actually used could be provided. (I think continued acceptance of it i=
s

> illegitimate, but hard data is harder to argue with)

>

> Issue #113 Prohibit SSL v2 CLIENT-HELLO entirely

> https://github.com/tlswg/tls13-spec/issues/113

>

> I have heard notable support for this, including Eric, but I do conced=
e there

> might be too much desire for infinite backwards compatibility to reach=
 consensus.

> I'm still hopeful we can come to an agreement that two decades is =
a sufficient

> deprecation period. :/

>

> I have two PRs for the backwards compatibility section.

>

> The first has all SSL backwards compatibility changes. In addition to =
RFC 6176

> SSL 2 language, I've added SSL 3 negotiation prohibition as per Ma=
rtin's

> suggestion (based on the current I-D). The v2 hello documentation is c=
ut out,

> but seeing as it's only valid for prior versions, prior RFCs can b=
e referenced

> if needed.

>

> PR #105 remove SSL 2 backwards compatibility section & prohibit SS=
L negotiation

> https://github.com/tlswg/tls13-spec/pull/105

>

> The second PR has more general backwards compatibility section improve=
ments,

> prohibition of RC4 (also based on its current I-D), and Brian's Cl=
ientHello

> version freeze proposal. Currently, I have the ClientHello version lis=
ted as a

> "MUST", but I leave for the possibility that a "SHOULD&=
quot; might be appropriate if

> other tactics for dealing with buggy servers should continue to be per=
mitted.

> Feedback from Microsoft, Oracle, or anyone else implementing alternate=


> workarounds here would be greatly appreciated.

>

> PR #107 revise backwards compatibility & fix ClientHello version
> https://github.com/tlswg/tls13-spec/pull/107

>

> Note that the SSL3 & RC4 language based on current drafts is of co=
urse

> contingent on those being passed successfully, though this is generall=
y

> expected.

>

> Both PRs update the Informative References as needed, which I've h=
opefully done

> correctly.

>

>

> Dave

>


> __________________=
_____________________________

> TLS mailing list

> TLS@ietf.org

> https://www.ietf.org/mailman/listinfo/tls



_______________________________________________

TLS mailing list

TLS@ietf.org

htt=
ps://www.ietf.org/mailman/listinfo/tls





--e89a8f3ba1018839ff050da5a786--


From nobody Tue Jan 27 10:24:00 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 912981A1B6A for ; Tue, 27 Jan 2015 10:23:58 -0800 (PST)
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_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 ciB-EuzAxzYt for ; Tue, 27 Jan 2015 10:23:57 -0800 (PST)
Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 435561A1B42 for ; Tue, 27 Jan 2015 10:23:57 -0800 (PST)
Received: by mail-qa0-f50.google.com with SMTP id k15so12687984qaq.9 for ; Tue, 27 Jan 2015 10:23:56 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=xCqZx2fmMYPIfC3L3kWrK/ESzWKZThkN0et2mzFu5z0=; b=XiIMyLVOkan4nD3V3584QyySvp92BB9WbMumYNv/2pnNsL7cmI8o/cvsVfH1m0LjBA iSH1TxDWamrtKRnkgNohggiVtXAOP2Qxfuek03o+EeUOJl86+RRTzkAY2zRZp5onyThl KMkOCFwtyZppdc81mrW9PGOl5voLPtqHe6kIPVYcowm5nUPR7Y2v02qrhunCVnsZI6pb 4eaCp4oEtkjelgarZmv7GfAhiXjpDy/pZBbH04arSLjsPiiNkAfpz+sEU/Qoubgqm/zN FfeqqKW3SBoPKhdAyH4fa1ZB/FY3NDjKxUCBAHK4DlyZmWaOIETNdhj3zuSlDt4D6TlE ChlA==
X-Gm-Message-State: ALoCoQmg7Yrc5ckkGfj8i4T9o6FPH4sscu9FNzPeXxxx+8MxPOZb/IGDzASqw9KU28qbpd+swEE9
X-Received: by 10.140.38.114 with SMTP id s105mr4341264qgs.106.1422383036395;  Tue, 27 Jan 2015 10:23:56 -0800 (PST)
Received: from zbox.pahtak.org (c-73-213-90-80.hsd1.md.comcast.net. [73.213.90.80]) by mx.google.com with ESMTPSA id o5sm1450550qat.4.2015.01.27.10.23.54 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Jan 2015 10:23:54 -0800 (PST)
Received: from [128.220.247.217] (unknown [128.220.247.217]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by zbox.pahtak.org (Postfix) with ESMTPSA id 01FD2AC285B; Tue, 27 Jan 2015 13:23:52 -0500 (EST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Stephen Checkoway 
In-Reply-To: 
Date: Tue, 27 Jan 2015 13:23:47 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <47B6D023-437F-47E4-BC13-C773F0866288@pahtak.org>
References:  
To: Andrei Popov 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-sslv3-diediedie-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Jan 2015 18:23:58 -0000

On Jan 23, 2015, at 2:42 PM, Andrei Popov  =
wrote:

> I=92m in full support, let=92s get rid of SSL.

+1

--=20
Stephen Checkoway






From nobody Tue Jan 27 10:49:18 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB9FD1A86DE for ; Tue, 27 Jan 2015 10:49:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Level: 
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 u3-ZlIgWYOBC for ; Tue, 27 Jan 2015 10:49:08 -0800 (PST)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FB581A891E for ; Tue, 27 Jan 2015 10:49:06 -0800 (PST)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 87B1D3A29B; Tue, 27 Jan 2015 19:49:04 +0100 (CET)
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 7D00042647; Tue, 27 Jan 2015 19:49:04 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 72D211B12B; Tue, 27 Jan 2015 19:49:04 +0100 (CET)
In-Reply-To: 
To: Joseph Salowey 
Date: Tue, 27 Jan 2015 19:49:04 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20150127184904.72D211B12B@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: 
Cc: "TLS@ietf.org \(tls@ietf.org\)" 
Subject: Re: [TLS] consensus on backwards compatibility changes
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Jan 2015 18:49:16 -0000

Joseph Salowey wrote:
> Dave Garrett  wrote:
> 
> > On Sunday, January 25, 2015 02:36:14 pm Eric Rescorla wrote:
> > > Based on reading the mailing list, it seems to me that there is rough
> > > consensus on PR#105, but not (yet?) on PR#107.
> >
> > I don't recall any objections to #107, but not much discussion either.
> >
> > To sum it up here, in addition to some editorial changes:
> >
> > 1) Fixes initial ClientHello record layer version to { 3, 1 } (TLS 1.0) &
> > mandates
> > all other record layer versions to match negotiated version.
> > (Brian's suggestion)
> >
> >
> [Joe] I think this makes sense.  I added to comments to the PR.  I propose
> to move the bit about the server accepting versions {3,x} to the same place
> and change the wording of the existing test to say:
> 
> "The client MUST set the version to {3, 1} for the initial ClientHello."

The primary reason why several implementors goofed the TLS version
negotiation in TLSv1.0 is that lack of clarity in the language.

If your above statement refers to the client_version member of the
ClientHello handshake message, please say so.

The record layer version number is entirely independent from
ClientHello.client_version, and for additional safety, it should be
explicitly mentioned what requirements, if any, exist for the record
layer protocol version of a record that carries the initial ClientHello
of a connection.

The original idea behind the TLS protocol version negotiation was that
the TLS handshake hash protects the entire handshake, and dirty hacks
like the downgrade dance that contemporary browsers are doing, would
be entirely unnecessary.

It would be a pretty stupid idea for the TLSv1.3 protocol specification
to withdraw TLS protocol negotiation protection from TLS clients, that
for whatever reason, see a need to offer pre-TLSv1.0 protocols to servers.

Defining an _implied_ set of features, that a TLS client sending/using a
backwards-compatible ClientHello offering TLSv1.3 in ClientHello.client_version
(or whatever alternative negotiation scheme the TLS WG chooses to use),
would be *MUCH* more reasonable.


-Martin


From nobody Tue Jan 27 11:20:44 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5E4A1A8704 for ; Tue, 27 Jan 2015 11:20:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Level: 
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 1jb6dQTHDtpH for ; Tue, 27 Jan 2015 11:20:41 -0800 (PST)
Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 780BD1A86E9 for ; Tue, 27 Jan 2015 11:20:41 -0800 (PST)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 594BF3A26D; Tue, 27 Jan 2015 20:20:39 +0100 (CET)
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 1A62D4297A; Tue, 27 Jan 2015 20:20:39 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 0FD2A1B12B; Tue, 27 Jan 2015 20:20:39 +0100 (CET)
In-Reply-To: <83CBC7E2-CDC9-4EDD-8648-8C80EE588343@ieca.com>
To: Sean Turner 
Date: Tue, 27 Jan 2015 20:20:38 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20150127192039.0FD2A1B12B@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: 
Cc: "TLS@ietf.org \(tls@ietf.org\)" 
Subject: Re: [TLS] consensus on backwards compatibility changes
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Jan 2015 19:20:43 -0000

Sean Turner wrote:
> 
> 1) We'd like to make it crystal clear in the SSL3.0 text whether you're
> talking about the hello version or record version. We're pretty sure that
> 'protocol version' in the following is the hello version but we think
> that should be made clear.
> 
>  Implementations MUST NOT send a ClientHello or ServerHello with
>  the protocol version set to { 3, 0 } or less. Any endpoint receiving a
>  Hello message with the protocol version set to { 3, 0 } MUST respond
>  with a "protocol_version" alert message and close the connection.


A description similar to this caused the TLS version negotiation problems.
The structure members in the handshake message PDUs are called
ClientHello.client_version and ServerHello.server_version.

If the above paragraph is meant to apply to the structure members
(client_version, server_version) of the respective TLS handshake message PDUs
(ClientHello, ServerHello), then please use the names of these structure
members for disambiguation.


We really should retain the TLSv1.2 requirement that TLS v1.3 servers
MUST accept any version number (3,x) at the TLS record layer for TLS
records sent before ServerHello in a TLS handshake on a new connection.

The TLS record that carries ServerHello is the first TLS record where
the version of the protocol is well defined for the server, i.e. the sender
of the record(s) that carry ServerHello.  For the client (recipient
of the ServerHello), the version becomes known only after it has started
parsing the ServerHello handshake message.  It is still unknown to the
client when it is receiving the TLS record that carries ServerHello.


-Martin


From nobody Tue Jan 27 11:47:16 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C988B1A897F for ; Tue, 27 Jan 2015 11:47:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.609
X-Spam-Level: 
X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 mBf-BRJ9Xh80 for ; Tue, 27 Jan 2015 11:47:12 -0800 (PST)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 173B61A89AE for ; Tue, 27 Jan 2015 11:46:01 -0800 (PST)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 1CB5A4764F for ; Tue, 27 Jan 2015 19:46:01 +0000 (GMT)
Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 070D947642 for ; Tue, 27 Jan 2015 19:46:01 +0000 (GMT)
Received: from email.msg.corp.akamai.com (ustx2ex-cas4.msg.corp.akamai.com [172.27.25.33]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 8C3B92026 for ; Tue, 27 Jan 2015 19:45:55 +0000 (GMT)
Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com (172.27.27.102) by ustx2ex-dag1mb5.msg.corp.akamai.com (172.27.27.105) with Microsoft SMTP Server (TLS) id 15.0.913.22; Tue, 27 Jan 2015 13:45:54 -0600
Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com ([172.27.6.132]) by ustx2ex-dag1mb2.msg.corp.akamai.com ([172.27.6.132]) with mapi id 15.00.0913.011; Tue, 27 Jan 2015 13:45:54 -0600
From: "Salz, Rich" 
To: "TLS@ietf.org (tls@ietf.org)" 
Thread-Topic: Questions about some expired drafts
Thread-Index: AdA6aaqKiTyRPKEmSnuTPURvIxfDMA==
Date: Tue, 27 Jan 2015 19:45:54 +0000
Message-ID: <67ce141550f34f31b508c53766990e16@ustx2ex-dag1mb2.msg.corp.akamai.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.19.60.148]
Content-Type: multipart/alternative; boundary="_000_67ce141550f34f31b508c53766990e16ustx2exdag1mb2msgcorpak_"
MIME-Version: 1.0
Archived-At: 
Subject: [TLS] Questions about some expired drafts
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Jan 2015 19:47:15 -0000

--_000_67ce141550f34f31b508c53766990e16ustx2exdag1mb2msgcorpak_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

https://tools.ietf.org/html/draft-rescorla-tls-opaque-prf-input-00
https://tools.ietf.org/html/draft-rescorla-tls-extended-random-02
OpenSSL includes at least the opaque-prf one.  Any reason to keep the code?=
  (I'm ripping out all sorts of old stuff now)

--
Principal Security Engineer, Akamai Technologies
IM: rsalz@jabber.me Twitter: RichSalz

--_000_67ce141550f34f31b508c53766990e16ustx2exdag1mb2msgcorpak_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











https://tools.ietf.org/html/draft-rescorla-tls-o=
paque-prf-input-00


https://tools.ietf.org/html/draft-rescorla-tls-exten=
ded-random-02




OpenSSL includes at least the opaque-prf one.  =
Any reason to keep the code?  (I’m ripping out all sorts of old =
stuff now)


 


--  


Principal Security Engineer, Akamai Technologies


IM: rsalz@jabber.=
me Twitter: RichSalz






--_000_67ce141550f34f31b508c53766990e16ustx2exdag1mb2msgcorpak_--


From nobody Tue Jan 27 12:11:45 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8961A8A3B for ; Tue, 27 Jan 2015 12:11:38 -0800 (PST)
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 KT7CAr01C4uj for ; Tue, 27 Jan 2015 12:11:35 -0800 (PST)
Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E84E1A8A4D for ; Tue, 27 Jan 2015 12:11:32 -0800 (PST)
Received: by mail-wg0-f52.google.com with SMTP id y19so16782333wgg.11 for ; Tue, 27 Jan 2015 12:11:30 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=KSH7nzmvJuByeoe+QCO6hO0Lqp2aOspKHKBCyDPHuUQ=; b=R7ElmpZGQ+7jiHTN63tH1ohkopnuTIzKwR5q+lqtSzjfGV3zVn/V+js+5+l2aGHAQI AK9uzklEhLBzIfpcVi15DLkDPPhCB7OAMVdgF4+BoUwDclD2fg87M3UqfmSRHHqMpsL7 mZ0cWB7k1Ny/RX+AYRkufba2cq4e3HWn2jfmEHEezXTXjiHrxXaKXKs+FZ1Kv2Gv9AN0 J4zOMudfNK91Y8I4ruylsFg2fzkgZH8wJyZL1lqRl3t0VjoYFNHtmSRBsUHN/pALNkNo 7evcwTzNTyKWakH4HfkWExnZ1Ym/BlOjyIpiaEPfo+rIMQ/ZS673tQJIfs3rJy5mjFHA jk+g==
X-Gm-Message-State: ALoCoQln2n06mounN2UnQzaO6VZq/Pwy7M5l+b6tuX86PwoGcanvEZeGh25x7k8VoTkT5fzeAT0J
X-Received: by 10.180.211.2 with SMTP id my2mr36932752wic.3.1422389490854; Tue, 27 Jan 2015 12:11:30 -0800 (PST)
Received: from [10.0.0.142] (chello080108032135.14.11.univie.teleweb.at. [80.108.32.135]) by mx.google.com with ESMTPSA id x18sm3554169wia.12.2015.01.27.12.11.29 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 Jan 2015 12:11:29 -0800 (PST)
Message-ID: <54C7F106.9070400@azet.org>
Date: Tue, 27 Jan 2015 21:11:50 +0100
From: Aaron Zauner 
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: Joseph Salowey 
References: 
In-Reply-To: 
X-Enigmail-Version: 1.2.3
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig1D002ADA0AF6C7DE46C38C74"
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-sslv3-diediedie-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Jan 2015 20:11:38 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig1D002ADA0AF6C7DE46C38C74
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable



Joseph Salowey wrote:
> This is a working group last call
> for draft-ietf-tls-sslv3-diediedie-00.  Please reply to the TLS working=

> group list with an indication of whether or not the draft is ready for
> publication and any other comments you may have.  Please respond by
> February 16, 2015. =20
>=20

Read a while ago. Just re-read the draft; nothing to add there. +1.

A short comment:
TLS 1.0 is only marginally different from SSLv3. I think a similar
document should exist for TLS 1.0. Yes I'm aware of the implications on
clients/servers.

Aaron


--------------enig1D002ADA0AF6C7DE46C38C74
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUx/EHAAoJEOTbZJL9ubXVnBAP+weDoWCGi02HGUZF/mP/WU3c
OmkG1hLoC47HYr0GPeEBFOcnqUzPh9hJ8Ez8HmnWubEjXnsAn8p4W4Kfx+YcYnm3
TlIZZbRN7gN1O5y5aewfEnD5XMoOF516QeaUOLypFEE0JlWx/8QB4kNtQAkC/oVv
I6f8/Go2JfruS4JRaFvXttjc9gepOKZRdSwE0+3qmRmbIPhlDGJzFSg+uDvzcA6L
HKOaTSodbpLnf5nWDox98FPizpZdbR7x3pGMoLkcuJIPEaOO8mZHZijuAWfPwXtI
USR7ui0RQERex25NMw4lwPnzkBgRK63bmlKkzkQziau1YEAxUs71nYRoGL1i3Uw0
NINcWRR/izDdunKK4lXt+2afn4ZrxSfHzf/UwF6l/Dd4eLki6PF7rCY6fsCeB+wV
ZocP3PJPpDWL0TMxUX1mOaTf681jZ3pTT1zSPdGK6a7i3aHmo5Sc64A1NY9Stgds
t+IDpbKTMuw7ia+djXG0+1xKGG8fWv+3odsWC2oDo5gb0unJBEqdebd9IX3lhByn
Lh6oGdqTBh7MflUyIMfmQdHeFmwcalvf1ypgFBhzNhbnq3IhA3tKlVjjp1uW4Yp5
tnxVkE3nL6T/EQmZ5yNz5VTNQtaBWCQUDiy7qdtsQfVIWxEqtmMC8ueW9rJPlXzu
3BQJ0OD7ciP130kUKDmV
=UeOd
-----END PGP SIGNATURE-----

--------------enig1D002ADA0AF6C7DE46C38C74--


From nobody Tue Jan 27 12:32:35 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE2F61A033B for ; Tue, 27 Jan 2015 12:32:34 -0800 (PST)
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 q6qPo7Bh68Kc for ; Tue, 27 Jan 2015 12:32:33 -0800 (PST)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC1A31A000B for ; Tue, 27 Jan 2015 12:32:32 -0800 (PST)
Received: by mail-wg0-f44.google.com with SMTP id z12so16922085wgg.3 for ; Tue, 27 Jan 2015 12:32:31 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=7ejfgqQfAC6ghFLoJngOzuRbbeihedIXHP3k20pYeVA=; b=j5q4EBvsOY4femoRfs/U16x8NL1f3lFWCSZJ9ARaqeq1WwSaAt+iCBEYInKNYlburA 9ZXcnY0uPQfy24i1BOA83EHOFJas69wesQpvOJOv9b8erN4xxF340ijlMpRBHYuvliNR cTq7gVK8IZahn2k3+abRFv+ZAVoA5Vggw5DhsEsNpkzWxnKUo45EK3KQKO4lyR+qOnOe 4PpMeCE2romb6lRxezbAi+S73HYpPkNRlpRrwWEchy7tPaZRgERRCSr8T13pJmnQc9Pv XrGfgI4wGiHpFLuwRbmhm97p8K+Ilwc1b0fvEGkVdOw8cdn5jAkTwvpZzuKn6II4ORZH SsCA==
X-Gm-Message-State: ALoCoQlj4fxIytqFHY2XSqu+T2A/ss57m06ejaMCVcjg7PFdrfkQ/CWdQmMOvnRLezOf7r3lTDdB
X-Received: by 10.194.143.12 with SMTP id sa12mr2569274wjb.101.1422390751631;  Tue, 27 Jan 2015 12:32:31 -0800 (PST)
Received: from [10.0.0.142] (chello080108032135.14.11.univie.teleweb.at. [80.108.32.135]) by mx.google.com with ESMTPSA id ud9sm3628918wib.5.2015.01.27.12.32.30 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 Jan 2015 12:32:30 -0800 (PST)
Message-ID: <54C7F5F3.9020800@azet.org>
Date: Tue, 27 Jan 2015 21:32:51 +0100
From: Aaron Zauner 
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: "TLS@ietf.org (tls@ietf.org)" 
References: <67ce141550f34f31b508c53766990e16@ustx2ex-dag1mb2.msg.corp.akamai.com>
In-Reply-To: <67ce141550f34f31b508c53766990e16@ustx2ex-dag1mb2.msg.corp.akamai.com>
X-Enigmail-Version: 1.2.3
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig771517D10FD26FFEB8E122A0"
Archived-At: 
Subject: Re: [TLS] Questions about some expired drafts
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Jan 2015 20:32:34 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig771517D10FD26FFEB8E122A0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi *,

Salz, Rich wrote:
> https://tools.ietf.org/html/draft-rescorla-tls-opaque-prf-input-00
>=20
> https://tools.ietf.org/html/draft-rescorla-tls-extended-random-02
>=20
> OpenSSL includes at least the opaque-prf one.  Any reason to keep the
> code?  (I=92m ripping out all sorts of old stuff now)
>=20
I see no value in keeping either of both drafts implemented.

* draft-rescorla-tls-opaque-prf-input-00:
Section 4. pretty much states what any reader of the document will
conclude; implementing this document will probably cause more (fatal)
implementation errors rather than adding anything useful to TLS.
Furthermore it adds unnecessary complexity on both ends.

* draft-rescorla-tls-extended-random-02:
Same as above.


Also: BULLRUN/EDGEHILL explicitly mention subversion of standards by not
only the NSA but specifically one of the authors subdivisions. Don't
want to start tinfoil-hattery here but these IDs are rather useless, and
to be honest if US Gov. really /needs/ to use these extensions they
could go ahead and use them anyway without being a standard as they do
with other crypto primitives.

Aaron


--------------enig771517D10FD26FFEB8E122A0
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUx/X0AAoJEOTbZJL9ubXVkCAP/jHkPbSlQwWkAe5Hq/5P2+a4
Eamz2tx0HHm1XGIoA+gCZCZb7DvJVEsdISoyQeKT1ck1fmBk1XlhnYoj/Tx3LGPz
4I2YrxPdYNkHin4wYV4Y7nC1x87c7B1sAJrTk+Npojr0Bc0wY7vWQ1L3y/H+/2wf
gmfbNzrVd6X350O5l4ts/3fGEWkPtW+1yybxtFV50SfD7/iL6KNQQYmnh3hC+XX+
7wcnuhPlVuV6QhrvHDMx0bKBXyA0OJY7FUluyK27h95DYtIsUD+Xl/XuTzUZVrlt
D/Jz61etWEQcKz+aar7hPjmAnU04QrRMmF0jUsq0XiiAlnQGiBGEC+HzRE0637uz
rziEQOrXDDmj03wSOKANYZ2t8ggJ5JrOlPR025vftp7dt3ElTOkwECPiGEE4i1i/
Ewi9nrXD4Sf8IuRNO/OM+U3LXZjq70B6tU+X3B7gnmsG5Pvyu7qy3M9wSi+Psgi7
Az73MmLGmNjZFzxRZ0I2zBkrdCCqnFENthwY2G98kvbfuoGyPdD1bjNN3xxwd8bw
armIoj70u7C2zfkBy/DdMOItnnJNUIc85m5O3KdZwGz7wqJCXjog6se8Sq5sxXSF
nEXN9ALhtxO0zuga8F3EC4hhxh+TmM6L6X07vobNbccYtDaSRhmpH/BhAbm8GsyJ
yA3YNXdZkkv4atOWdXbt
=pIyu
-----END PGP SIGNATURE-----

--------------enig771517D10FD26FFEB8E122A0--


From nobody Tue Jan 27 12:44:39 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B40E1A8AA0 for ; Tue, 27 Jan 2015 12:44:38 -0800 (PST)
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 w7-kue_ozqa1 for ; Tue, 27 Jan 2015 12:44:37 -0800 (PST)
Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E88AF1A0385 for ; Tue, 27 Jan 2015 12:44:36 -0800 (PST)
Received: by mail-oi0-f53.google.com with SMTP id i138so14311621oig.12 for ; Tue, 27 Jan 2015 12:44:36 -0800 (PST)
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=PZFrD/Obx5n3RiUyg/JVgvNAW9LXuH+Bxwkdytwlmdo=; b=ECizoDQfrz1rXXiDo+rtMbB4FTMmqcNBvSSt6MpX+W2thB6aI4jQXz9+GpTKNQfh7A vUflR8ZsEGSHcgVpVwm3XflqqEAaz/bIoCmEHoNowmwdjxKRAp18Z4ROK7YDu+Z8tJxJ jFV4tA57LKJf8T9AqzqpGqkiVaUdtns3VK9Q88uZXpONsZCdUqKwEYPlE+3983f1gfVi V6NEHaNiYVDZcSgGYnNHN5kxONAMup2n5mSvrOOpwssVGB5++GauGuY0f/BJDkJk/Olt l28gPnkCq2QtxZQLQiFzFf6nk2/4QrceRq3ZK2O0ttYHa+lIxKIcLLxbuKsyduUvB2lF lO0A==
MIME-Version: 1.0
X-Received: by 10.60.134.10 with SMTP id pg10mr20471oeb.0.1422391476273; Tue, 27 Jan 2015 12:44:36 -0800 (PST)
Received: by 10.202.226.136 with HTTP; Tue, 27 Jan 2015 12:44:36 -0800 (PST)
In-Reply-To: <54C7F106.9070400@azet.org>
References:  <54C7F106.9070400@azet.org>
Date: Tue, 27 Jan 2015 12:44:36 -0800
Message-ID: 
From: Martin Thomson 
To: Aaron Zauner 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-sslv3-diediedie-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Jan 2015 20:44:38 -0000

On 27 January 2015 at 12:11, Aaron Zauner  wrote:
> TLS 1.0 is only marginally different from SSLv3. I think a similar
> document should exist for TLS 1.0. Yes I'm aware of the implications on
> clients/servers.

I think that TLS 1.0 is nearing that point too.  But I'm not that
enthusiastic about being the hitman there.  Well, not yet.


From nobody Tue Jan 27 14:45:58 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D06461A701F for ; Tue, 27 Jan 2015 14:45:51 -0800 (PST)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 xsQvJSKjco49 for ; Tue, 27 Jan 2015 14:45:49 -0800 (PST)
Received: from mail-qg0-f44.google.com (mail-qg0-f44.google.com [209.85.192.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCD011A6F33 for ; Tue, 27 Jan 2015 14:45:48 -0800 (PST)
Received: by mail-qg0-f44.google.com with SMTP id l89so14137347qgf.3 for ; Tue, 27 Jan 2015 14:45:47 -0800 (PST)
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=cejkRA6s41G15b+PHnaIMBHZ0AtXBhgCUQt9T6KIvUA=; b=J6dkO4I+PAhAFF3MHAag2hDA0j2mmIc9Xb6sqza9idbuHYq3Ph2xTyqDHj8b/YkSMH lI2ebq0spAM8qV/1o1uhcu3Fln1BCRTQvoRZihq/KP8DXacxDwNGMgXP0Rf64FO+3eq3 8e21IjY5F/8uNdwOCjRivht//dfnH+M2J/BYLFZ/IsSAFFselKX5XiSQG+L8nDWFvl3Q xEKhykArRrKwNXKnN/mlIx8X3PW1cx4m7T1f5O+CEJ+oPSaK92XhSGiKXi6LpO0i6rST MLWjY6hXj6dwxDNeElCuwUuro5OnxXTxm2MjW/kcF5LdmQmEI08169YtsMCRFsAhTJXO 99Sw==
X-Gm-Message-State: ALoCoQk8J8GEGvdGkVPfFL93rwBj0xq9oBYMxMhlHJ2J8/gAcT9t3YsdKRb28ZrYVbOhW1ubG3G3
MIME-Version: 1.0
X-Received: by 10.224.69.67 with SMTP id y3mr6826875qai.59.1422398747815; Tue, 27 Jan 2015 14:45:47 -0800 (PST)
Received: by 10.96.238.73 with HTTP; Tue, 27 Jan 2015 14:45:47 -0800 (PST)
X-Originating-IP: [50.206.82.141]
In-Reply-To: <20150127184904.72D211B12B@ld9781.wdf.sap.corp>
References:  <20150127184904.72D211B12B@ld9781.wdf.sap.corp>
Date: Tue, 27 Jan 2015 14:45:47 -0800
Message-ID: 
From: Joseph Salowey 
To: mrex@sap.com
Content-Type: multipart/alternative; boundary=001a11c2d8f617c5ef050daa0423
Archived-At: 
Cc: "TLS@ietf.org \(tls@ietf.org\)" 
Subject: Re: [TLS] consensus on backwards compatibility changes
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Jan 2015 22:45:52 -0000

--001a11c2d8f617c5ef050daa0423
Content-Type: text/plain; charset=UTF-8

On Tue, Jan 27, 2015 at 10:49 AM, Martin Rex  wrote:

> Joseph Salowey wrote:
> > Dave Garrett  wrote:
> >
> > > On Sunday, January 25, 2015 02:36:14 pm Eric Rescorla wrote:
> > > > Based on reading the mailing list, it seems to me that there is rough
> > > > consensus on PR#105, but not (yet?) on PR#107.
> > >
> > > I don't recall any objections to #107, but not much discussion either.
> > >
> > > To sum it up here, in addition to some editorial changes:
> > >
> > > 1) Fixes initial ClientHello record layer version to { 3, 1 } (TLS
> 1.0) &
> > > mandates
> > > all other record layer versions to match negotiated version.
> > > (Brian's suggestion)
> > >
> > >
> > [Joe] I think this makes sense.  I added to comments to the PR.  I
> propose
> > to move the bit about the server accepting versions {3,x} to the same
> place
> > and change the wording of the existing test to say:
> >
> > "The client MUST set the version to {3, 1} for the initial ClientHello."
>
> The primary reason why several implementors goofed the TLS version
> negotiation in TLSv1.0 is that lack of clarity in the language.
>
> If your above statement refers to the client_version member of the
> ClientHello handshake message, please say so.
>
> The record layer version number is entirely independent from
> ClientHello.client_version, and for additional safety, it should be
> explicitly mentioned what requirements, if any, exist for the record
> layer protocol version of a record that carries the initial ClientHello
> of a connection.
>
>
[Joe] The text above is from the section describing the record protocol and
is referring to the version in the record layer of the protocol.  I agree
that it would be better to be explicit about this as it has generated
confusion in the past.



> The original idea behind the TLS protocol version negotiation was that
> the TLS handshake hash protects the entire handshake, and dirty hacks
> like the downgrade dance that contemporary browsers are doing, would
> be entirely unnecessary.
>
> It would be a pretty stupid idea for the TLSv1.3 protocol specification
> to withdraw TLS protocol negotiation protection from TLS clients, that
> for whatever reason, see a need to offer pre-TLSv1.0 protocols to servers.
>
>
[Joe] Agree, this is not what is being proposed.


> Defining an _implied_ set of features, that a TLS client sending/using a
> backwards-compatible ClientHello offering TLSv1.3 in
> ClientHello.client_version
> (or whatever alternative negotiation scheme the TLS WG chooses to use),
> would be *MUCH* more reasonable.
>
>
[Joe] I'm not sure what you mean.



>
> -Martin
>

--001a11c2d8f617c5ef050daa0423
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Tue, Jan 27, 2015 at 10:49 AM, Martin Rex <mrex@sap.com> w=
rote:
Joseph Salowey wro=
te:

> Dave Garrett <davemgarret=
t@gmail.com> wrote:

>

> > On Sunday, January 25, 2015 02:36:14 pm Eric Rescorla wrote:

> > > Based on reading the mailing list, it seems to me that there=
 is rough

> > > consensus on PR#105, but not (yet?) on PR#107.

> >

> > I don't recall any objections to #107, but not much discussio=
n either.

> >

> > To sum it up here, in addition to some editorial changes:

> >

> > 1) Fixes initial ClientHello record layer version to { 3, 1 } (TL=
S 1.0) &

> > mandates

> > all other record layer versions to match negotiated version.

> > (Brian's suggestion)

> >

> >

> [Joe] I think this makes sense.=C2=A0 I added to comments to the PR.=
=C2=A0 I propose

> to move the bit about the server accepting versions {3,x} to the same =
place

> and change the wording of the existing test to say:

>

> "The client MUST set the version to {3, 1} for the initial Client=
Hello."



The primary reason why several implementors goofed the TLS version
negotiation in TLSv1.0 is that lack of clarity in the language.



If your above statement refers to the client_version member of the

ClientHello handshake message, please say so.



The record layer version number is entirely independent from

ClientHello.client_version, and for additional safety, it should be

explicitly mentioned what requirements, if any, exist for the record

layer protocol version of a record that carries the initial ClientHello

of a connection.



[Joe] The text above is from the secti=
on describing the record protocol and is referring to the version in the re=
cord layer of the protocol.=C2=A0 I agree that it would be better to be exp=
licit about this as it has generated confusion in the past. =C2=A0

=C2=A0

The original idea behind the TLS protocol version negotiation was that

the TLS handshake hash protects the entire handshake, and dirty hacks

like the downgrade dance that contemporary browsers are doing, would

be entirely unnecessary.



It would be a pretty stupid idea for the TLSv1.3 protocol specification

to withdraw TLS protocol negotiation protection from TLS clients, that

for whatever reason, see a need to offer pre-TLSv1.0 protocols to servers.<=
br>


[Joe] Agree, this is not what is being=
 proposed.=C2=A0
=C2=A0

Defining an _implied_ set of features, that a TLS client sending/using a
backwards-compatible ClientHello offering TLSv1.3 in ClientHello.client_ver=
sion

(or whatever alternative negotiation scheme the TLS WG chooses to use),

would be *MUCH* more reasonable.



[Joe] I'm not sure what you mean.

=

=C2=A0



-Martin





--001a11c2d8f617c5ef050daa0423--


From nobody Tue Jan 27 15:00:24 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB0471A90CA for ; Tue, 27 Jan 2015 15:00:19 -0800 (PST)
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 FtVvVUX_MRzb for ; Tue, 27 Jan 2015 15:00:14 -0800 (PST)
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 A578B1A90CE for ; Tue, 27 Jan 2015 15:00:09 -0800 (PST)
Received: by mail-qa0-f51.google.com with SMTP id f12so13729692qad.10 for ; Tue, 27 Jan 2015 15:00:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=1tMES7vfuozJiVKhoUFPZ340HBU7fEx3EilNuC7ILN0=; b=FpHx9ft2ghgPYrmxTjgCg1l76MVHYDl244ci/r7O6BiFV65hTDmZo7BLt8nEsiH0XJ yPlrFvt03oixcpYIa6xuFONetT8xRlj5zPomctQLcFjio08OEiQC7XxoOQ82JaHQdaf5 VF35bssAWFqP+vJZd92CpfteB+o4iUjgAcHN6KR5EfusGacVmiRUVrRnziscLhM2dtFt rbWDpkY0Bv5rMMYAfXvdLPO0OxInOPSr0kSpOSHLwbTWEMSBz6k99FyADLaS+TUSvFAX nigfZ158Q/pZ0Q5494HHC4QB4HoFWQPLZhyxYuFJWA3MVcFqvix1MMDDmkFWkMcExo56 OINg==
X-Received: by 10.140.23.84 with SMTP id 78mr6434249qgo.93.1422399608839; Tue, 27 Jan 2015 15:00:08 -0800 (PST)
Received: from dave-laptop.localnet (pool-72-92-42-38.phlapa.fios.verizon.net. [72.92.42.38]) by mx.google.com with ESMTPSA id t2sm2411966qae.6.2015.01.27.15.00.08 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 27 Jan 2015 15:00:08 -0800 (PST)
From: Dave Garrett 
To: Joseph Salowey , mrex@sap.com
Date: Tue, 27 Jan 2015 18:00:06 -0500
User-Agent: KMail/1.13.5 (Linux/2.6.32-70-generic-pae; KDE/4.4.5; i686; ; )
References: <201412300503.03923.davemgarrett@gmail.com> <201501251833.50963.davemgarrett@gmail.com> 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <201501271800.06852.davemgarrett@gmail.com>
Archived-At: 
Cc: "TLS@ietf.org \(tls@ietf.org\)" 
Subject: Re: [TLS] consensus on backwards compatibility changes
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Jan 2015 23:00:20 -0000

On Tuesday, January 27, 2015 11:42:22 am Joseph Salowey wrote:
> [Joe] I think this makes sense.  I added to comments to the PR.  I propose
> to move the bit about the server accepting versions {3,x} to the same place
> and change the wording of the existing test to say:
> 
> "The client MUST set the version to {3, 1} for the initial ClientHello."

Language changed and {3,X} backward compatibility sentence added.

> > 5) Explicitly prohibit EXPORT ciphers and any others <100 bits.
> > (100 bit line is arbitrary; could be 112 if preferred)

> [Joe] draft-ietf-uta-tls-bcp-08 recommends 112 so we probably would match
> that.

No objection. Updated.

On Tuesday, January 27, 2015 01:49:04 pm Martin Rex wrote:
> > "The client MUST set the version to {3, 1} for the initial ClientHello."
>
> The primary reason why several implementors goofed the TLS version
> negotiation in TLSv1.0 is that lack of clarity in the language.
> 
> If your above statement refers to the client_version member of the
> ClientHello handshake message, please say so.

The language is proposed for within the version field definition for the record
layer version.

Would we want a paragraph somewhere explicitly mentioning possible
confusion between record layer version, hello version, & negotiated version?

On Tuesday, January 27, 2015 02:20:38 pm Martin Rex wrote:
> >  Implementations MUST NOT send a ClientHello or ServerHello with
> >  the protocol version set to { 3, 0 } or less. Any endpoint receiving a
> >  Hello message with the protocol version set to { 3, 0 } MUST respond
> >  with a "protocol_version" alert message and close the connection.
> 
> A description similar to this caused the TLS version negotiation problems.
> The structure members in the handshake message PDUs are called
> ClientHello.client_version and ServerHello.server_version.
> 
> If the above paragraph is meant to apply to the structure members
> (client_version, server_version) of the respective TLS handshake message PDUs
> (ClientHello, ServerHello), then please use the names of these structure
> members for disambiguation.

Yes, Eric asked for that same change. I updated the PR a couple days ago.


Dave


From nobody Tue Jan 27 15:15:29 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA7F1A912F for ; Tue, 27 Jan 2015 15:15:27 -0800 (PST)
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 nqJ95qOmJ8Jk for ; Tue, 27 Jan 2015 15:15:25 -0800 (PST)
Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AF6C1A9129 for ; Tue, 27 Jan 2015 15:15:25 -0800 (PST)
Received: by mail-qa0-f48.google.com with SMTP id v8so13753732qal.7 for ; Tue, 27 Jan 2015 15:15:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=Pu1wYfFd0uR0aSB3d934e/UCIsENGTQG5fxCcjYjVWI=; b=E+yEBcBD6jrf4LVxXmA4rDn3MkpcdTK4/19EvyUNZ9ZHAXeRlmLrSrhTyIP64vMJO6 djJy93K/P8+xhjr4ExOyFQRB/r6EqY3WwUOKzMgtyCAZaTLmNIywwKjLrOjrCCSKPOZb 5/LKVFVXuc4iLARl6V6yz9UIKQQr/HK4p1wgTFJ1ctKmAJ526OzvfIp2Ene7BSFMV0qb whjeAWxFmZgtAne20YaL/btfNactsNvi2mGClT8J+FBUcrbaKz/SO4/JyEvaP6cPXfZD wNQ1NAp4aQwq9rAzjAaV86NqdxYVHNZjV0JPY3459tTWaPRdvhrZWdQx38j0FZlIbn30 V3Jw==
X-Received: by 10.224.126.3 with SMTP id a3mr7182618qas.100.1422400524531; Tue, 27 Jan 2015 15:15:24 -0800 (PST)
Received: from dave-laptop.localnet (pool-72-92-42-38.phlapa.fios.verizon.net. [72.92.42.38]) by mx.google.com with ESMTPSA id q5sm2399835qat.47.2015.01.27.15.15.23 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 27 Jan 2015 15:15:24 -0800 (PST)
From: Dave Garrett 
To: tls@ietf.org
Date: Tue, 27 Jan 2015 18:15:22 -0500
User-Agent: KMail/1.13.5 (Linux/2.6.32-70-generic-pae; KDE/4.4.5; i686; ; )
References:  <54C7F106.9070400@azet.org> 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201501271815.23083.davemgarrett@gmail.com>
Archived-At: 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-sslv3-diediedie-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Jan 2015 23:15:27 -0000

On Tuesday, January 27, 2015 03:44:36 pm Martin Thomson wrote:
> On 27 January 2015 at 12:11, Aaron Zauner  wrote:
> > TLS 1.0 is only marginally different from SSLv3. I think a similar
> > document should exist for TLS 1.0. Yes I'm aware of the implications on
> > clients/servers.
> 
> I think that TLS 1.0 is nearing that point too.  But I'm not that
> enthusiastic about being the hitman there.  Well, not yet.

Is it at all practical to publish an TLS RFC stating intent to deprecate
TLS 1.0/1.1 within some fixed timeframe? I think everyone would rather
phase it out then have to "be the hitman" each time.

A straw man proposal would be something like:

1) TLS 1.0 & 1.1 SHOULD NOT be supported by servers, effective immediately.
2) TLS 1.0 & 1.1 MUST NOT be supported by servers after X months.
3) TLS 1.0 & 1.1 SHOULD NOT be supported by clients after Y months.

I know the UTA BCP I-D deals with this area too, but a specific RFC from the
TLS WG might have more impact at reducing numbers before the inevitable
catastrophic vulnerability that warrants a diediedie RFC.


Dave


From nobody Tue Jan 27 15:25:15 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E29CF1A8A0C for ; Tue, 27 Jan 2015 15:25:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.66
X-Spam-Level: 
X-Spam-Status: No, score=-1.66 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=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 zukfLgx_gUbz for ; Tue, 27 Jan 2015 15:25:02 -0800 (PST)
Received: from BLU004-OMC3S14.hotmail.com (blu004-omc3s14.hotmail.com [65.55.116.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CCC81A0089 for ; Tue, 27 Jan 2015 15:25:02 -0800 (PST)
Received: from BLU177-W3 ([65.55.116.72]) by BLU004-OMC3S14.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751);  Tue, 27 Jan 2015 15:25:01 -0800
X-TMN: [EH6E1NCwcPfz1R03aMlQ/D2bizazMVMk]
X-Originating-Email: [yuhongbao_386@hotmail.com]
Message-ID: 
From: Yuhong Bao 
To: Dave Garrett , "tls@ietf.org" 
Date: Tue, 27 Jan 2015 15:25:01 -0800
Importance: Normal
In-Reply-To: <201501271815.23083.davemgarrett@gmail.com>
References: ,  <54C7F106.9070400@azet.org>, , <201501271815.23083.davemgarrett@gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 27 Jan 2015 23:25:01.0430 (UTC) FILETIME=[79086160:01D03A88]
Archived-At: 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-sslv3-diediedie-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Jan 2015 23:25:04 -0000

> On Tuesday=2C January 27=2C 2015 03:44:36 pm Martin Thomson wrote:=0A=
>> On 27 January 2015 at 12:11=2C Aaron Zauner  wrote:=0A=
>>> TLS 1.0 is only marginally different from SSLv3. I think a similar=0A=
>>> document should exist for TLS 1.0. Yes I'm aware of the implications on=
=0A=
>>> clients/servers.=0A=
>> =0A=
>> I think that TLS 1.0 is nearing that point too.  But I'm not that=0A=
>> enthusiastic about being the hitman there.  Well=2C not yet.=0A=
> =0A=
> Is it at all practical to publish an TLS RFC stating intent to deprecate=
=0A=
> TLS 1.0/1.1 within some fixed timeframe? I think everyone would rather=0A=
> phase it out then have to "be the hitman" each time.=0A=
> =0A=
> A straw man proposal would be something like:=0A=
> =0A=
> 1) TLS 1.0 & 1.1 SHOULD NOT be supported by servers=2C effective immediat=
ely.=0A=
> 2) TLS 1.0 & 1.1 MUST NOT be supported by servers after X months.=0A=
> 3) TLS 1.0 & 1.1 SHOULD NOT be supported by clients after Y months.=0A=
> =0A=
> I know the UTA BCP I-D deals with this area too=2C but a specific RFC fro=
m the=0A=
> TLS WG might have more impact at reducing numbers before the inevitable=
=0A=
> catastrophic vulnerability that warrants a diediedie RFC.=0A=
=0A=
The timeframe would probably have to be in years=2C given that Windows Serv=
er 2008 R1 for example ends support in 2020.=0A=
=0A=
Yuhong Bao=0A=
 		 	   		  =


From nobody Tue Jan 27 15:34:12 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 026CD1A914F for ; Tue, 27 Jan 2015 15:34:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level: 
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 UwFmToGvD6Jb for ; Tue, 27 Jan 2015 15:33:59 -0800 (PST)
Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D5F31A914D for ; Tue, 27 Jan 2015 15:33:59 -0800 (PST)
Received: from pc (ip5b4003d1.dynamic.kabel-deutschland.de [::ffff:91.64.3.209]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Wed, 28 Jan 2015 00:33:57 +0100 id 0000000000000026.0000000054C82065.000002B3
Date: Wed, 28 Jan 2015 00:33:56 +0100
From: Hanno =?UTF-8?B?QsO2Y2s=?= 
To: tls@ietf.org
Message-ID: <20150128003356.41d2899b@pc>
In-Reply-To: <201501271815.23083.davemgarrett@gmail.com>
References:  <54C7F106.9070400@azet.org>  <201501271815.23083.davemgarrett@gmail.com>
X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-691-1422401637-0001-2"
Archived-At: 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-sslv3-diediedie-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Jan 2015 23:34:01 -0000

This is a MIME-formatted message.  If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--=_zucker.schokokeks.org-691-1422401637-0001-2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, 27 Jan 2015 18:15:22 -0500
Dave Garrett  wrote:

> Is it at all practical to publish an TLS RFC stating intent to
> deprecate TLS 1.0/1.1 within some fixed timeframe? I think everyone
> would rather phase it out then have to "be the hitman" each time.

I think if the deprecation of SSLv3 shows one thing it is that we need
to start now if we want to deprecate it in several years.

There are products on the market developed as late as 2011 that only
support SSLv3. I think a crucial thing would be to identify and stop
people from deploying TLS 1.0-only solutions today - so we won't have
them tomorrow when we really need to deprecate TLS 1.0.

It's a topic I've been discussing with a number of people lately. Ideas
welcome. I thought about adding something to webpages that will warn
users if they connect with anything !=3D TLS 1.2. That could at least
make people aware if they surf with deprecated technology.


P.S.: +1 from me for the sslv3-die-draft. The sooner this gets out the
better.

--=20
Hanno B=C3=B6ck
http://hboeck.de/

mail/jabber: hanno@hboeck.de
GPG: BBB51E42

--=_zucker.schokokeks.org-691-1422401637-0001-2
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJUyCBkAAoJEKWIAHK7tR5COREQAJ+bB22TPbbOfeGuYjFDlfe1
IsAIpOPZrst3S54TX34Xr6rAkbyN7V3kUa3Hn0vJsoY44Tz94f4D0BG8IX9GobQ2
CVFJz9WPu0HyCI2lvjhTyKv0sEQurjpWitcamg0mJRL3PyKTBPz55YxCbpAw8iRu
W36XMVX7yeBZx05U8Nn6H7PWIYIE7XzZlIbaUUAfr2w5OsOkAr21yKDNW7SoLaUU
9rjz9bwQcP37izJZL5+a4zjM4srq2hru0sCv350KKO69wLCUOajy7C1vCdMLMssO
HJwoE7vZwVvvtYqYR2IMc8x/Rt5TuqVDWpXRQVakkGKiJcvIg5SW3mmvLQjO+Loj
aYa6SY2My631a+2GJCAT9atZ68ki+pF9jbDt+0AKdk98SrnSo4/0nOEOlMU+/5QJ
Rn21r72oiJiXlzC+Y/8xS+26Rv+ww77LVshe8dkiMRA/S+qttvX7P1UsB2BFchYK
Q9hIrIEpHaY9y65GICWmq2BZCLg0P1uqxgsk0djRqIeQImc6aGRkN93+tp767O8P
04j89aUY5ul08kcs2McFloEu91zr89JJPWXKrCNBNp4CFEFIS/ysZpdkDhLVTb73
6KZjhsf6XysqgYDNnyBz43vEiWZXD8eF0UW+eMFs1PjVNFZ9XLwkzK08aeiu+5Xw
/8CDgR3UYBZ6vinQOZvn
=gBor
-----END PGP SIGNATURE-----

--=_zucker.schokokeks.org-691-1422401637-0001-2--


From nobody Tue Jan 27 15:43:38 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7CD1A9165 for ; Tue, 27 Jan 2015 15:43:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level: 
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 m9dqpbPYd0DH for ; Tue, 27 Jan 2015 15:43:35 -0800 (PST)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96C131A88B3 for ; Tue, 27 Jan 2015 15:43:29 -0800 (PST)
Received: by mail-we0-f172.google.com with SMTP id q59so17757183wes.3 for ; Tue, 27 Jan 2015 15:43:28 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=3M0Xw7VCwcZQzVupzAI29CRzA/jhAhe10qhuZy61yMg=; b=lf6Vjrs3n0WDtArE7FiIu0VSSaiENBVCs502vZTJ9o4d3z8z6isnroZdJlko/jkq4m CMHQHADJ/CZTdFYrX2Qn0gQfVIleqm13hPzE4pmYkPCpybHkOq4vPOTE/ETst9d1jjcl SGthrAnaKFxjxCXrGqYe2muJCbWHJlnV/QmyzB1Lnv0H+SKRD7a6ONamXe6QOG2sOwvY Q4Nf4oC12IMEI35U2NJXamBCsbt1mWXDFkOFbHvVIi0jXEF7v+CULj0keBdFazp7tifR q7bkx74gnM156XslUI7CFTWW5fiasKm5mV5Bp+4gMflbpeyX7w2PjGXqEZx1YaNcgP3l qROw==
X-Gm-Message-State: ALoCoQk2t5DAsFHip2YgqiaKsU9iQMDQ/RsxqHncqTY+Lh09oUGuYsW3ve0DwwMupE+YyV1A7+5q
X-Received: by 10.194.173.161 with SMTP id bl1mr1152647wjc.102.1422402208353;  Tue, 27 Jan 2015 15:43:28 -0800 (PST)
Received: from typhoon.azet.org (chello080108032135.14.11.univie.teleweb.at. [80.108.32.135]) by mx.google.com with ESMTPSA id x6sm3765968wjf.24.2015.01.27.15.43.27 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Jan 2015 15:43:27 -0800 (PST)
Date: Wed, 28 Jan 2015 00:43:15 +0100
From: Aaron Zauner 
To: Hanno =?utf-8?B?QsO2Y2s=?= 
Message-ID: <20150127234314.GA6124@typhoon.azet.org>
References:  <54C7F106.9070400@azet.org>  <201501271815.23083.davemgarrett@gmail.com> <20150128003356.41d2899b@pc>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Nq2Wo0NMKNjxTN9z"
Content-Disposition: inline
In-Reply-To: <20150128003356.41d2899b@pc>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Cc: tls@ietf.org
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-sslv3-diediedie-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Jan 2015 23:43:36 -0000

--Nq2Wo0NMKNjxTN9z
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* Hanno B=C3=B6ck  [28/01/2015 00:34:13] wrote:
> On Tue, 27 Jan 2015 18:15:22 -0500
> Dave Garrett  wrote:
>=20
> > Is it at all practical to publish an TLS RFC stating intent to
> > deprecate TLS 1.0/1.1 within some fixed timeframe? I think everyone
> > would rather phase it out then have to "be the hitman" each time.
>=20
> I think if the deprecation of SSLv3 shows one thing it is that we need
> to start now if we want to deprecate it in several years.
>=20

I cannot agree more.

> There are products on the market developed as late as 2011 that only
> support SSLv3. I think a crucial thing would be to identify and stop
> people from deploying TLS 1.0-only solutions today - so we won't have
> them tomorrow when we really need to deprecate TLS 1.0.
>=20
> It's a topic I've been discussing with a number of people lately. Ideas
> welcome. I thought about adding something to webpages that will warn
> users if they connect with anything !=3D TLS 1.2. That could at least
> make people aware if they surf with deprecated technology.

It's been pointed out earlier, but as not many people from TLS-WG
have been active at UTA I just want to reference those two documents
(currently WGLC and submitted for publication):

Recommendations for Secure Use of TLS and DTLS:
https://datatracker.ietf.org/doc/draft-ietf-uta-tls-bcp/

Summarizing Known Attacks on TLS and DTLS:
https://datatracker.ietf.org/doc/draft-ietf-uta-tls-attacks/

Aaron

--Nq2Wo0NMKNjxTN9z
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUyCKSAAoJEOTbZJL9ubXVg9MQAKvND+NaaLwHp7EGtaJnz0dN
4FKGoVr7YM5UDPXrKNUx1ugk/GrhBPRz91GvfLrOCZ0uF2ZSPQSKif9I+4QJduJh
/5/ccF69MTDMspFnNC55Jq4j3z0zBVBN6VtrPd1e12sIS5hO9oV+0peAjLTesx3I
KBPNFzMPYFOp3CCCQlvmIOtpQ3IrTCxmeVDpU2GYG74jvelXC+qXgmGqmmQXkArF
1wzZq4BD8hHGImh8TWQ4LOPAQSdMo+M/RRUVgov5GHLCicSiLKvwllRswmgUy86m
XQdacoEaxxi5e39whdbUwxAgba35UzdiIXdB7Kxwmot7NonajvEh1ZiOy6/Pb6z5
+1OuxocBRlJSzwCt+NY8L3QeULawtMWk0qXyYWc7LYP/btAY0x+J+r7jcByV0paQ
T05HzHwTe5aMGWfhXcS+IP3nRVKexuah4mGBSpL3uv0HcH9jVFOlPbVB/EJ8a4Q6
/BGG/D5zchQkBYBeS0pCMZV3gowhyQyAkEzuTOIveVZDnKdhq0jY19HsC22+cdfj
cVgc0ZT63SkNDV6x4LqQfyARMHboXV0FMTkmgCjkCrFPhhj/NhLDrV42tH/QVp9/
QGsUaMBKaCD+so98w8LTgnWsKh3HRy4aquh4eI4/7WCoEk+7wsLVGts8+t6wrPMK
bV605FKiSnRU9ETZUDD6
=Ak18
-----END PGP SIGNATURE-----

--Nq2Wo0NMKNjxTN9z--


From nobody Tue Jan 27 15:47:03 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 234CA1A916A for ; Tue, 27 Jan 2015 15:47:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level: 
X-Spam-Status: No, score=-1.7 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_8BIT_HEADER=0.3, 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 1WKbROVEGa_E for ; Tue, 27 Jan 2015 15:47:01 -0800 (PST)
Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d: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 D2A781A9167 for ; Tue, 27 Jan 2015 15:47:00 -0800 (PST)
Received: by mail-qg0-f51.google.com with SMTP id z107so14272743qgd.10 for ; Tue, 27 Jan 2015 15:47:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=QtXJBlFXVWGOlYTdse/w7xhUwrICMH5cBpb07H9zbkg=; b=LXyBopua5XtHwxOA0lvR0/QRpq5/WiOAtFoHoNhphhiXLXAAYFltux55zpdEG3Y23j wY4zS/2pBg/llD0/j4xp5azDUegJI7Q940d1Q0wS3nszusKPIze7IvFcF4H/dQx2JKFP YACSDoHWu9r7rJnv1kpYl5Je3vIeIc1Ta9eRIs6vpWAlrmUXjYt68B6UZJX27cvdbFsn U3XS0n7jQCoSZytOSa9b89xZqG+doqt6ZlIKVsbWzyNNPdzGFmdGce2mJqOyo06reZWL 1ek3tLUVxd4earkvVkJohxlz/cfLirG7CMK5duLPHCGmYIA1UmAhE3r1gM60Mv5Xjq3a qqbA==
X-Received: by 10.224.37.72 with SMTP id w8mr7448440qad.58.1422402420117; Tue, 27 Jan 2015 15:47:00 -0800 (PST)
Received: from dave-laptop.localnet (pool-72-92-42-38.phlapa.fios.verizon.net. [72.92.42.38]) by mx.google.com with ESMTPSA id j2sm2483199qai.34.2015.01.27.15.46.59 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 27 Jan 2015 15:46:59 -0800 (PST)
From: Dave Garrett 
To: Yuhong Bao , Hanno =?iso-8859-1?q?B=F6ck?= 
Date: Tue, 27 Jan 2015 18:46:57 -0500
User-Agent: KMail/1.13.5 (Linux/2.6.32-70-generic-pae; KDE/4.4.5; i686; ; )
References:  <201501271815.23083.davemgarrett@gmail.com> 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Message-Id: <201501271846.57646.davemgarrett@gmail.com>
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-sslv3-diediedie-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Jan 2015 23:47:02 -0000

On Tuesday, January 27, 2015 06:25:01 pm Yuhong Bao wrote:
> > On Tuesday, January 27, 2015 03:44:36 pm Martin Thomson wrote:
> >> On 27 January 2015 at 12:11, Aaron Zauner  wrote:
> >>> TLS 1.0 is only marginally different from SSLv3. I think a similar
> >>> document should exist for TLS 1.0. Yes I'm aware of the implications =
on
> >>> clients/servers.
> >>=20
> >> I think that TLS 1.0 is nearing that point too.  But I'm not that
> >> enthusiastic about being the hitman there.  Well, not yet.
> >=20
> > Is it at all practical to publish an TLS RFC stating intent to deprecate
> > TLS 1.0/1.1 within some fixed timeframe? I think everyone would rather
> > phase it out then have to "be the hitman" each time.
> >=20
> > A straw man proposal would be something like:
> >=20
> > 1) TLS 1.0 & 1.1 SHOULD NOT be supported by servers, effective immediat=
ely.
> > 2) TLS 1.0 & 1.1 MUST NOT be supported by servers after X months.
> > 3) TLS 1.0 & 1.1 SHOULD NOT be supported by clients after Y months.
> >=20
> > I know the UTA BCP I-D deals with this area too, but a specific RFC fro=
m the
> > TLS WG might have more impact at reducing numbers before the inevitable
> > catastrophic vulnerability that warrants a diediedie RFC.
>=20
> The timeframe would probably have to be in years, given that Windows Serv=
er
> 2008 R1 for example ends support in 2020.

I was thinking in the order of X=3D12 & Y=3D18, so yes, > 1 year.

The EOL date for implementations is not a barrier, however. Rather, it coul=
d be helpful. Servers could recommended to offer to comply within the "SHOU=
LD NOT" timeframe in some minor update. If some longer "MUST NOT" timeframe=
 could be agreed upon, it could be disabled automatically. (unless overridd=
en by admin against the RFC, of course) This is of course the sort of thing=
 that sounds great to some people but horrific to others. ;)

On Tuesday, January 27, 2015 06:33:56 pm Hanno B=F6ck wrote:
> There are products on the market developed as late as 2011 that only
> support SSLv3. I think a crucial thing would be to identify and stop
> people from deploying TLS 1.0-only solutions today - so we won't have
> them tomorrow when we really need to deprecate TLS 1.0.

If there is some way to define a "new" deployment, we could state separate =
expectations for existing and new deployments.

This sort of thing leaves a lot up to vendors, but the point of such a prop=
osal is to get the ball rolling rather than wait until the last second.


Dave


From nobody Tue Jan 27 17:22:23 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAEA11A011B for ; Tue, 27 Jan 2015 17:22:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.66
X-Spam-Level: 
X-Spam-Status: No, score=-1.66 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=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 igG0BFOWMeAY for ; Tue, 27 Jan 2015 17:22:21 -0800 (PST)
Received: from BLU004-OMC2S11.hotmail.com (blu004-omc2s11.hotmail.com [65.55.111.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3A701A00E2 for ; Tue, 27 Jan 2015 17:22:20 -0800 (PST)
Received: from BLU177-W3 ([65.55.111.73]) by BLU004-OMC2S11.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751);  Tue, 27 Jan 2015 17:22:19 -0800
X-TMN: [3L/RZfSNjLVW2Q5XZrbmSFaYncc5a+0X]
X-Originating-Email: [yuhongbao_386@hotmail.com]
Message-ID: 
From: Yuhong Bao 
To: Aaron Zauner , "TLS@ietf.org tls@ietf.org" 
Date: Tue, 27 Jan 2015 17:22:19 -0800
Importance: Normal
In-Reply-To: <54C7F5F3.9020800@azet.org>
References: <67ce141550f34f31b508c53766990e16@ustx2ex-dag1mb2.msg.corp.akamai.com>,  <54C7F5F3.9020800@azet.org>
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 28 Jan 2015 01:22:19.0544 (UTC) FILETIME=[DC135980:01D03A98]
Archived-At: 
Subject: Re: [TLS] Questions about some expired drafts
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Jan 2015 01:22:22 -0000

Yea=2C I believe the=A0draft-rescorla-tls-extended-random is quite famous a=
s a backdoor=2C=A0=0A=
along with Dual_EC_DRBG.=0A=
=0A=
----------------------------------------=0A=
Date: Tue=2C 27 Jan 2015 21:32:51 +0100=0A=
From: azet@azet.org=0A=
To: tls@ietf.org=0A=
Subject: Re: [TLS] Questions about some expired drafts=0A=
=0A=
=0A=
Hi *=2C=0A=
=0A=
Salz=2C Rich wrote:=0A=
> https://tools.ietf.org/html/draft-rescorla-tls-opaque-prf-input-00=0A=
>=0A=
> https://tools.ietf.org/html/draft-rescorla-tls-extended-random-02=0A=
>=0A=
> OpenSSL includes at least the opaque-prf one. Any reason to keep the=0A=
> code? (I=92m ripping out all sorts of old stuff now)=0A=
>=0A=
I see no value in keeping either of both drafts implemented.=0A=
=0A=
* draft-rescorla-tls-opaque-prf-input-00:=0A=
Section 4. pretty much states what any reader of the document will=0A=
conclude=3B implementing this document will probably cause more (fatal)=0A=
implementation errors rather than adding anything useful to TLS.=0A=
Furthermore it adds unnecessary complexity on both ends.=0A=
=0A=
* draft-rescorla-tls-extended-random-02:=0A=
Same as above.=0A=
=0A=
=0A=
Also: BULLRUN/EDGEHILL explicitly mention subversion of standards by not=0A=
only the NSA but specifically one of the authors subdivisions. Don't=0A=
want to start tinfoil-hattery here but these IDs are rather useless=2C and=
=0A=
to be honest if US Gov. really /needs/ to use these extensions they=0A=
could go ahead and use them anyway without being a standard as they do=0A=
with other crypto primitives.=0A=
=0A=
Aaron=0A=
=0A=
=0A=
_______________________________________________=0A=
TLS mailing list=0A=
TLS@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/tls=0A=
 		 	   		  =


From nobody Tue Jan 27 17:57:16 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E06F21ACC92 for ; Tue, 27 Jan 2015 17:57:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.632
X-Spam-Level: 
X-Spam-Status: No, score=0.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, MANGLED_LIST=2.3, SPF_HELO_PASS=-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 I6HeI8ce8IQu for ; Tue, 27 Jan 2015 17:57:05 -0800 (PST)
Received: from tlsx.org (tlsx.org [67.207.128.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2A0C1ACC83 for ; Tue, 27 Jan 2015 17:57:03 -0800 (PST)
Received: from monty.local (unknown.maxonline.com.sg [58.182.168.20] (may be forged)) (authenticated bits=0) by tlsx.org (8.14.4/8.14.4/Debian-4) with ESMTP id t0S2J2Yn005157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 28 Jan 2015 02:19:06 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=metaparadigm.com; s=klaatu; t=1422411548; bh=WiP8eZrbT+X4mNtccHl9xEXZHP8PEwhTvUiQf3u8SBQ=; h=Date:From:To:Subject:References:In-Reply-To:From; b=kQM6Exgl1rLolVW7YHpyCNBCye5hImROZyDI6Ve/FkCVG4o0PH02Jwj02Su2xs8iN D1PtT0PWa2EyQsH5rABqxS61l67qPSRKeuGwxB4fAr2rW9uvQJPYIuprvSUVxLVoBu s1gO19U+EYUSkR8Tahyhl+NVkeQsm3TQeq+v5zNw=
Message-ID: <54C841E3.5040208@metaparadigm.com>
Date: Wed, 28 Jan 2015 09:56:51 +0800
From: Michael Clark 
Organization: Metaparadigm
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Dave Garrett , tls@ietf.org
References:  <54C7F106.9070400@azet.org>  <201501271815.23083.davemgarrett@gmail.com>
In-Reply-To: <201501271815.23083.davemgarrett@gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.98.4 at klaatu.tlsx.org
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-sslv3-diediedie-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Jan 2015 01:57:07 -0000

On 28/1/15 7:15 am, Dave Garrett wrote:
> On Tuesday, January 27, 2015 03:44:36 pm Martin Thomson wrote:
>> On 27 January 2015 at 12:11, Aaron Zauner  wrote:
>>> TLS 1.0 is only marginally different from SSLv3. I think a similar
>>> document should exist for TLS 1.0. Yes I'm aware of the implications on
>>> clients/servers.
>>
>> I think that TLS 1.0 is nearing that point too.  But I'm not that
>> enthusiastic about being the hitman there.  Well, not yet.
> 
> Is it at all practical to publish an TLS RFC stating intent to deprecate
> TLS 1.0/1.1 within some fixed timeframe? I think everyone would rather
> phase it out then have to "be the hitman" each time.
> 
> A straw man proposal would be something like:
> 
> 1) TLS 1.0 & 1.1 SHOULD NOT be supported by servers, effective immediately.
> 2) TLS 1.0 & 1.1 MUST NOT be supported by servers after X months.
> 3) TLS 1.0 & 1.1 SHOULD NOT be supported by clients after Y months.
> 
> I know the UTA BCP I-D deals with this area too, but a specific RFC from the
> TLS WG might have more impact at reducing numbers before the inevitable
> catastrophic vulnerability that warrants a diediedie RFC.


+1x ;-) Support draft-ietf-tls-sslv3-diediedie-00


I wholeheartedly agree with the text "(including {03,00}) as the record
layer version number for ClientHello, but they MUST NOT negotiate SSLv3."

   Historically, TLS specifications were not clear on what the record
   layer version number (TLSPlaintext.version) could contain when
   sending ClientHello.  Appendix E of [RFC5246] notes that
   TLSPlaintext.version could be selected to maximize interoperability,
   though no definitive value is identified as ideal.  That guidance is
   still applicable; therefore, TLS servers MUST accept any value
   {03,XX} (including {03,00}) as the record layer version number for
   ClientHello, but they MUST NOT negotiate SSLv3.



Still considering these two drafts neutrally (having arrived at
essentially the same ideas independently before seeing these drafts)
however I have some comments in light of changes in TLSv1.3:


https://tools.ietf.org/html/draft-mavrogiannopoulos-tls-more-extensions-00
   https://tools.ietf.org/html/draft-ietf-tls-encrypt-then-mac-03


1) "Supported Protocol Versions"

"Supported Protocol Versions" could be unbundled from the draft and
taken piecemeal and/or added to the TLSv1.3 draft as a well-considered
SCSV alternative. Bundling with MACSecurityParameters makes it harder to
swallow as one piece. It's useful now for TLSv1.2, but "MAC Security
Parameter" is pork so to speak.


After consideration I would support fixing { 3, 0 } at the "record
layer" and support advertising versions via extension:

    "Supported Protocol Versions": [ { 3, 1 }, { 3, 2 }, { 3, 3 } ]

Later there can be a config change to deprecate TLS 1.0, TLS 1.1 upon
future advisories. Config changes are better than code changes:

    "Supported Protocol Versions": [ { 3, 3 }, { 3, 4 } ]

With this reasoning that the record layer can essentially be fixed at
the major wire version lower bound (which is not verified, so fixing it
makes sense). It is a good solution as it achieves version range tamper
resistance while allowing forwards and backwards compatibility. e.g.
avoiding the downgrades in the case where a client decides it still
wants to support TLS 1.0, when current practice differs from the spec.



2) "Supported MAC Security Parameter" somehow in light of TLSv1.3

    "Supported MAC Security Parameter": [ 128, 192, 256, 384 ]

This spec attempts to addresses verify_data_length issue and allows >=
128 bit tags and addresses this text (given recent cipher suites don't
seem to override verify_data_length):

      In previous versions of TLS, the verify_data was always 12 octets
      long.  In the current version of TLS, it depends on the cipher
      suite.  Any cipher suite which does not explicitly specify
      verify_data_length has a verify_data_length equal to 12.  This
      includes all existing cipher suites.  Note that this
      representation has the same encoding as with previous versions.
      Future cipher suites MAY specify other lengths but such length
      MUST be at least 12 bytes.

with

     Note: TLS 1.2 allows ciphersuites to specify individually the
     "verify_data_length".  Implementations conforming to this document
     MUST ignore the ciphersuite "verify_data_length" if a
     "MACSecurityParameter" has been selected by the server.

However see 4) where I note the undocumented implication of increasing
verify_data_length which has to be done in consideration of the
protection bits of the asymmetric encryption. Is this correct?



3) "Supported Encrypt-then-MAC" somehow in light of TLSv1.3

Changed in light of AEAD and in concert with "MAC Security Parameter"
and in concert with MAC-then-Encrypt removal.

This would require a modified version of Encrypt-then-MAC that rewords
renegotiation and mention of MAC-then-Encrypt for TLSv1.3 compatibility
and considers MAC Security Parameter.

    AEAD tag length + HMAC length = MACSecurityParameter

    ETM-AEAD[aead_cipher,hmac]

This would give you a very firm tamper-resistant handshake supporting
backwards compat to TLSv1.2 along with stronger messages authentication
tags for AEAD ciphers.



4) "Support increasing verify_data_length" somehow

The mechanism in
https://tools.ietf.org/html/draft-mavrogiannopoulos-tls-more-extensions-00
needs to consider the constraint on the asymmetric cipher or PSK
protection bits? It needs to tie the lower bound constraint of the MAC
security parameter to a constraint on the asymmetric algorithm and key
size and the security bits offered?

* We need 3072-bit RSA keys to protect 128 bit verify_data
* We need to use ECC to protect 192 or 256 bit verify_data
  (given a 15360-bit RSA key is required to protect 256 bits)
* We don't want the MAC Security mechanism to leak asymmetric key bits



We're going to need a tiny constraints solver. This is a SAT problem.


From nobody Tue Jan 27 19:13:39 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3A751A1B61 for ; Tue, 27 Jan 2015 19:13:37 -0800 (PST)
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 bb9wds1R05f6 for ; Tue, 27 Jan 2015 19:13:35 -0800 (PST)
Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 782E01A1B71 for ; Tue, 27 Jan 2015 19:13:34 -0800 (PST)
Received: by mail-yk0-f178.google.com with SMTP id q200so7919198ykb.9 for ; Tue, 27 Jan 2015 19:13:33 -0800 (PST)
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=SO1vogXI5RKXo5GKB7jgvTK4pLqlu010rxODmtd4LlA=; b=SKzRFRb/KwMhDVqV+EykCVbRer/XIjgXlyWuEOxXfT7T0fNBSN08hNekqhdGYIn/Io BDWbyD74zCSz07AqhVC1R97xk/i1/dop0glRODybLjE5cvYJihUSmMo3vEYrcIJVzYYC oPG1titNNf+gVIyK679NhnyUiFnycLX9FeFNkqaGUpuv45PXkaJgKl6HRnENAJzRuk4k aLz0I3MNewRKZVVzt+5AVlvbImQ+55QHbvGMP20d0zpJdlPIFYO+Zwhsf9NUWcJ01Vx+ pHa0/i/gMIBr35naBItQfCxlfUXtPMeYz7QZmkVwxbYbmCRCI687HVM36VkHSQLjFI/t +kdw==
MIME-Version: 1.0
X-Received: by 10.170.217.9 with SMTP id j9mr210430ykf.19.1422414813654; Tue, 27 Jan 2015 19:13:33 -0800 (PST)
Received: by 10.170.115.77 with HTTP; Tue, 27 Jan 2015 19:13:33 -0800 (PST)
In-Reply-To: <87fvb1hvqx.fsf@alice.fifthhorseman.net>
References: <3F4C76ED-4375-438F-ADC9-66E49A19574B@ieca.com> <87fvb1hvqx.fsf@alice.fifthhorseman.net>
Date: Tue, 27 Jan 2015 19:13:33 -0800
Message-ID: 
From: Watson Ladd 
To: Daniel Kahn Gillmor 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] WGLC: draft-ietf-tls-negotiated-ff-dhe-05
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Jan 2015 03:13:38 -0000



>
> Using a keyed PRF instead of e
> ------------------------------
>
> Two objections were made about the use of e --
>
> (a) because of its definition as the base of the natural log, e has some
>     sort of special internal structure that might make FFDH groups
>     derived from it more vulnerable to analysis.
>
> (b) that starting from e and counting up biases the randomized prime
>     selection by only fiddling certain bits in the prime while counting.
>
> I've spoken with several cryptographers about (a) who dismissed it as
> totally implausible.  I haven't gotten much feedback about (b).
>
> The proposed change is to select the "random" bits by using a keyed PRF,
> or KDF, with the seed or additional input incrementing until a safe
> prime is found.
>
> I confess this sounds better than using e to me, simply because the
> construction avoids any claims about (a) and (b).
>
> One approach would be to use [HKDF] with SHA-512, with the initial key
> material ("IKM") and info parameter both set to "TLS-ffdheNNNN" (where
> ffdheNNNN is the ASCII name of the group), and a salt that we increment
> until a safe prime is found at the right length.
>
>   [HKDF] https://tools.ietf.org/html/rfc5869

I don't see what the gains of this approach are over the existing one.
(b) is valid as far as it goes but I don't think it's a real concern.

>
>
> Avoiding the high-64 and low-64 bits set to 1
> ---------------------------------------------
>
> The high 64 bits and the low 64 bits of these primes are set to 1
> specifically to facilitate Montgomery and Barrett reduction.  This is
> similar to the choices made in the MODP FFDHE groups.
>
> The objection to this is that the special structure may make these
> groups more vulnerable to attacks that we don't know about, potentially
> making them equivalent to groups the size of the inner bits or
> something.
>
> I'd like to think that if any advances had been made against the DLOG
> problem for groups with this special form, they would be published
> already, since the first Oakley group is 768 bits, with the top and
> bottom 64 bits all set to 0xff, so this should be in-range and
> high-profile for anyone who wants to take a crack at it:
>
>   https://tools.ietf.org/html/rfc2409#section-6.1
>
> But i'm not a cryptographer, i know of no such attack, and i have no
> idea how to judge the likelihood of something like this existing.
>
> I also don't know how widespread or desirable Barrett and Montgomery
> reductions are: if these reduction methods are unlikely to be actually
> used in the field, or offer only insignificant efficiency incentives for
> adoption, then we might not need to maintain them.

Montgomery reduction is a very common implementation choice for RSA
and DH implementations. Barrett may get used, but requires a big table
per prime. I doubt there are going to be attacks based on this
"special" property.

>
> Another argument here is that if efficiency is paramount, most people
> will choose ECDHE instead of FFDHE.  So if we're proposing FFDHE groups
> as a bulwark against some future failure of ECDHE, we might as well
> accept that performance efficiency isn't the highest priority.
>
>
>
> These last two points are what Andrei is referring to when he says
> "avoid special-form primes", fwiw.
>
>
> Thoughts, feedback?
>
>           --dkg
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



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


From nobody Wed Jan 28 00:06:46 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07F8E1A00E9 for ; Wed, 28 Jan 2015 00:06:43 -0800 (PST)
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 4xugbEw1v1hx for ; Wed, 28 Jan 2015 00:06:35 -0800 (PST)
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 5F6C31A004C for ; Wed, 28 Jan 2015 00:06:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1422432395; x=1453968395; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=Tc+22tEYWls/nVxO5JlUbUrLDLwxVzq+uh3bVkZJYRM=; b=HcYyhixjHzL0VyGmh6M+W495kCjAVMO7bOAhQEFQHm/V2xLJvL27Sf2s foSnAl/fyQsXGlKGJ/RqaamLl5YDLghc9rI8OeEc641GtTGWkPXDdDfpJ fDq1Z26s6AWLzHlb8zMCkNu3gZVhMroSuMDMkHDDA0TcdE2Yu7Boo+vCY I=;
X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="304108544"
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/AES256-SHA; 28 Jan 2015 21:06:34 +1300
Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.148]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0174.001; Wed, 28 Jan 2015 21:06:33 +1300
From: Peter Gutmann 
To: "" 
Thread-Topic: [TLS] Working Group Last Call for draft-ietf-tls-sslv3-diediedie-00
Thread-Index: AdA60VPfS8MwK9YHRGeU1+dc4LoiMg==
Date: Wed, 28 Jan 2015 08:06:32 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAF694DD@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: 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-sslv3-diediedie-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Jan 2015 08:06:43 -0000

Dave Garrett  writes:=0A=
=0A=
>Is it at all practical to publish an TLS RFC stating intent to deprecate T=
LS=0A=
>1.0/1.1 within some fixed timeframe? I think everyone would rather phase i=
t=0A=
>out then have to "be the hitman" each time.=0A=
=0A=
I'm happy to have 1.0 phased out, but I'd make the baseline 1.1, not 1.2.  =
1.1=0A=
fixes the major issues with SSL (no support for extensions, no per-message =
IV)=0A=
without being a major rewrite like 1.2 is.  There's an awful lot of stuff=
=0A=
outside of the browser world that can move to 1.1 if it isn't there already=
,=0A=
but that's going to take a long, long time to move to 1.2 if it ever does.=
=0A=
Killing 1.0 (which is really just SSL IETF-ised) is a pretty straightforwar=
d=0A=
step if you're already getting rid of SSL because it has most of the same=
=0A=
problems, but deprecating 1.1 is going a bit too far.=0A=
=0A=
Peter.=0A=


From nobody Wed Jan 28 04:25:55 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD0611A00CD for ; Wed, 28 Jan 2015 04:25:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level: 
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, 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 CZnWsMXDIT2W for ; Wed, 28 Jan 2015 04:25:50 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 053761A1A76 for ; Wed, 28 Jan 2015 04:25:49 -0800 (PST)
Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t0SCPlmF002012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 28 Jan 2015 07:25:47 -0500
Received: from oldenburg.str.redhat.com (oldenburg.str.redhat.com [10.33.200.60]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t0SCPitn018225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 28 Jan 2015 07:25:46 -0500
Message-ID: <54C8D548.2020101@redhat.com>
Date: Wed, 28 Jan 2015 13:25:44 +0100
From: Florian Weimer 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Dave Garrett , Kurt Roeckx 
References: <201412300503.03923.davemgarrett@gmail.com> <201501251814.36985.davemgarrett@gmail.com> <20150126202521.GA12484@roeckx.be> <201501261831.36832.davemgarrett@gmail.com>
In-Reply-To: <201501261831.36832.davemgarrett@gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Archived-At: 
Cc: "TLS@ietf.org \(tls@ietf.org\)" 
Subject: Re: [TLS] consensus on backwards compatibility changes
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Jan 2015 12:25:51 -0000

On 01/27/2015 12:31 AM, Dave Garrett wrote:
> With regard to this topic, please see the previous discussion on list. (the "drop obsolete
> SSL 2 backwards compatibility" thread) Implementers have specifically pushed back against
> dropping all SSL 2 stuff, in particular because they think it is valid to still negotiate TLS 1.2
> using an SSL version 2.0 client hello.

But if you do this, the handshake uses SHA-1 only, per section 7.4.1.4.
 So while it was possible to negotiate a fully-fledged TLS 1.1
connection starting from an SSL 2.0 Client Hello, that's no longer
possible with TLS 1.2—you'll end up with likely weaker handshakes in
some cases (OID || SHA-1 in the ServerKeyExchange signature vs MD5 ||
SHA-1 in TLS 1.1 and earlier or, say, OID || SHA-256 with the extension
and TLS 1.2).  Sending the supported_signature_algorithms extension is
optional according to the specification, but not optional in the spirit.

-- 
Florian Weimer / Red Hat Product Security


From nobody Wed Jan 28 12:42:46 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7850D1A036C for ; Wed, 28 Jan 2015 12:42:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Level: 
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 gVIb2yLvtveW for ; Wed, 28 Jan 2015 12:42:39 -0800 (PST)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 238721A005C for ; Wed, 28 Jan 2015 12:42:39 -0800 (PST)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id E42513A35F; Wed, 28 Jan 2015 21:42:36 +0100 (CET)
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id D774442D63; Wed, 28 Jan 2015 21:42:36 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id CA94B1B130; Wed, 28 Jan 2015 21:42:36 +0100 (CET)
In-Reply-To: <54C8D548.2020101@redhat.com>
To: Florian Weimer 
Date: Wed, 28 Jan 2015 21:42:36 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20150128204236.CA94B1B130@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: 
Cc: "TLS@ietf.org \(tls@ietf.org\)" 
Subject: Re: [TLS] consensus on backwards compatibility changes
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Jan 2015 20:42:43 -0000

Florian Weimer wrote:
> Dave Garrett wrote:
>> With regard to this topic, please see the previous discussion on list.
>> (the "drop obsolete SSL 2 backwards compatibility" thread)
>> Implementers have specifically pushed back against dropping all
>> SSL 2 stuff, in particular because they think it is valid to still
>> negotiate TLS 1.2 using an SSL version 2.0 client hello.
> 
> But if you do this, the handshake uses SHA-1 only, per section 7.4.1.4.

rfc5246 section 7.4.1.4?
I think you are misreading the TLSv1.2 specification.

The use of SHA-256 for the TLSv1.2 PRF and for the handshake message
hash that goes into the the Finished handshake message depends only
on the chosen cipher suite and the protocol (v1.2), and is independent
from whether the client sent a signature algoritm extension and what
algorithms were listed in that extension.

https://tools.ietf.org/html/rfc5246#section-7.4.9


There are several serious design flaws (resulting in serious weaknesses)
in the TLSv1.2 signature algorithm extension, however.  TLSv1.2 is the
only TLS protocol version where (rsa,md5) is a valid signature algorithm
for creating "digitally-signed" PDUs (ServerKeyExchange and
CertificateVerify), and that was a terribly stupid decision.
Even (rsa,sha1) is significantly weaker than what every prior TLS
protocol version, including SSLv3 had been using (rsa,sha1+md5).

Since the TLSv1.2 signature algorithm extension semantics have been so
terribly misspecified, it will take quite a while before TLSv1.2 clients
can safely remove (rsa,sha1) from ClientHello (unless they continue
doing reconnect fallbacks after handshake failures, aka downgrade dances).

I would not have imagined something as broken as the TLSv1.2 signature
algorithms extension would (a) get proposed and (b) get standardized,
but it happened, as you can see in rfc5246.  When I noticed the
brokenness when reading rfc5246, I hoped that implementors would
recognize the obvious security problem and refuse to implement it.
Well, some hearts don't miss a single bleed.


-Martin


From nobody Wed Jan 28 15:10:32 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2BDE1A1BFC for ; Wed, 28 Jan 2015 15:10:22 -0800 (PST)
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_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 DwafkeugG6_u for ; Wed, 28 Jan 2015 15:10:15 -0800 (PST)
Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 264571A1C04 for ; Wed, 28 Jan 2015 15:10:12 -0800 (PST)
Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id D992D1C2140; Thu, 29 Jan 2015 00:10:09 +0100 (CET)
Received: by intrepid.roeckx.be (Postfix, from userid 1000) id A6FFA1FE0108; Thu, 29 Jan 2015 00:10:09 +0100 (CET)
Date: Thu, 29 Jan 2015 00:10:09 +0100
From: Kurt Roeckx 
To: Peter Gutmann 
Message-ID: <20150128231009.GA25284@roeckx.be>
References: <9A043F3CF02CD34C8E74AC1594475C73AAF694DD@uxcn10-tdc05.UoA.auckland.ac.nz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAF694DD@uxcn10-tdc05.UoA.auckland.ac.nz>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Cc: "" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-sslv3-diediedie-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Jan 2015 23:10:23 -0000

On Wed, Jan 28, 2015 at 08:06:32AM +0000, Peter Gutmann wrote:
> Dave Garrett  writes:
> 
> >Is it at all practical to publish an TLS RFC stating intent to deprecate TLS
> >1.0/1.1 within some fixed timeframe? I think everyone would rather phase it
> >out then have to "be the hitman" each time.
> 
> I'm happy to have 1.0 phased out, but I'd make the baseline 1.1, not 1.2.  1.1
> fixes the major issues with SSL (no support for extensions, no per-message IV)
> without being a major rewrite like 1.2 is.  There's an awful lot of stuff
> outside of the browser world that can move to 1.1 if it isn't there already,
> but that's going to take a long, long time to move to 1.2 if it ever does.
> Killing 1.0 (which is really just SSL IETF-ised) is a pretty straightforward
> step if you're already getting rid of SSL because it has most of the same
> problems, but deprecating 1.1 is going a bit too far.

TLS 1.1 and 1.2 have only seen widespread adoption recently
because the major libraries only implemented it recently.  For
some reason 1.2 actually seems to better support than 1.1.  There
are a strange set of servers out there that support 1.0 and 1.2
but not 1.1.

Here is an overview of when I know they get implemented:
library  | TLS 1.1 | TLS 1.2
---------+---------+--------
openssl  | 2012-03 | 2012-03
nss      | 2012-10 | 2013-06
gnutls   | 2004-02 | 2006-11 (like 2 years before they got published)
schannel | 2009-07 | 2009-07

But was is more important I think is when they actually got
enabled by default in applications:
application | TLS 1.1 | TLS 1.2
------------+---------+--------
firefox     | 2013-09 | 2013-09
chrome      | 2012-09 | 2013-08
ie          | 2013-10 | 2013-10
safari      | 2013-10 | 2013-10
opera       | 2013-07 | 2013-10

On the server side it's a little harder to tell since I guess they
just get enabled but not used and servers don't get upgraded that
much.  But there we can instead just try to connect to it and see
the progress.  We're now between 50% and 70% that support TLS 1.2
depending on who you ask.  But there is also still around 10% that
support SSLv2.

My best guess is that around 85% of the clients support TLS 1.2 by
now, but I guess there are some people here who can do better then
guess.  It's unfortunate that we see this monthly stats for
servers but not for clients.

My current expectation is that it's most likely going to take
until 2020 to actually get TLS 1.2 support to the level we now see
for TLS 1.0 (around 99.5%) for both client and server.


Kurt


From nobody Wed Jan 28 15:31:49 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2B6B1A7022 for ; Wed, 28 Jan 2015 15:31:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Level: 
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 DdCOvl5OaGnN for ; Wed, 28 Jan 2015 15:31:40 -0800 (PST)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D7841A701F for ; Wed, 28 Jan 2015 15:31:40 -0800 (PST)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id BE0DE3A2C4; Thu, 29 Jan 2015 00:31:37 +0100 (CET)
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 488EF42D98; Thu, 29 Jan 2015 00:31:37 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 3F8781B132; Thu, 29 Jan 2015 00:31:37 +0100 (CET)
In-Reply-To: <20150128231009.GA25284@roeckx.be>
To: Kurt Roeckx 
Date: Thu, 29 Jan 2015 00:31:37 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20150128233137.3F8781B132@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: 
Cc: "" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-sslv3-diediedie-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Jan 2015 23:31:46 -0000

Kurt Roeckx wrote:
> Peter Gutmann wrote:
>>
>> There's an awful lot of stuff outside of the browser world that can
>> move to 1.1 if it isn't there already,

The differences between TLSv1.0 and TLSv1.1 are marginal, and when
TLSv1.0 is used with 1/(n-1) record splitting, they provide essentially
the same security -- but TLSv1.1 is *MUCH* less interoperable.


That's not quite true.  There es little, if any stuff outside of the
browser world that could go to > extension-less TLSv1.0, because there
are still too many servers out there that will abort the handshake
when extensions are present or when the version is > TLSv1.0.

Adding insecure reconnect fallbacks, aka "downgrade dance" to each and
every application caller is a complete non-starter.

If there was a standardized fashion how to upgrade from an
extensionless TLSv1.0 ClientHello to an extension-bloated TLSv1.2
ClientHello that works in-band and is completely transparent to the
application caller, then I would gladly add this to both, our
clients and our servers.



>> but that's going to take a long, long time to move to 1.2 if it ever does.
>> Killing 1.0 (which is really just SSL IETF-ised) is a pretty straightforward
>> step if you're already getting rid of SSL because it has most of the same
>> problems, but deprecating 1.1 is going a bit too far.
> 
> TLS 1.1 and 1.2 have only seen widespread adoption recently
> because the major libraries only implemented it recently.  For
> some reason 1.2 actually seems to better support than 1.1.  There
> are a strange set of servers out there that support 1.0 and 1.2
> but not 1.1.

Yes, I've seen those servers.  One of them is:

https://www.portaldasfinancas.gov.pt/

>From what I've been told, they're using an SSL accellerator.  Might be A10.
Will negotiate TLSv1.2 or TLSv1.0, but not TLSv1.1.

They run a few WebServices on related servers with similar configuration
for a legally required data exchange with the portuguese tax authorities.


-Martin


From nobody Wed Jan 28 19:40:28 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46FC41A8AED for ; Wed, 28 Jan 2015 19:40:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Level: 
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] 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 UOwTIcHDqmgY for ; Wed, 28 Jan 2015 19:40:25 -0800 (PST)
Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 871E11A8BB0 for ; Wed, 28 Jan 2015 19:40:12 -0800 (PST)
Received: by mail-lb0-f179.google.com with SMTP id 10so23788617lbg.10 for ; Wed, 28 Jan 2015 19:40:11 -0800 (PST)
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:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=qfEvz/N4l5QDBHcDwZk+eiEp++Y1dYxibYMwFO4KCeI=; b=YAmRFiU1J2Tz5I7L6dwTkewSKfK+QdS4DtyrScFtqsY3PkaH9MvuHX3zXSLvbUh2Hg nlIKXWUfdovQoH6xt3GSrE3lV/x19xglkgx1wV+hOCBVFMVjy/6/AbWf5p3eMAnXIYry Avv5wCdyxasAjM/T1+uTtrFnKPwDnsGMGUrFrXjP5TzCZQAsDIlEvy2f9WC4J0fxQ7YK +69vvVOJ3J+0VR1BeXH+MPa9Rceh0cxSztExyLTI30zDBgl+g7HCJ3OsQrCiXbfxqtBg gLNje2O3at8GAgdgrCIFXevoK7pasKZWfpkD92474Hq1sc7Atz9vsjdaDwFuGnhsR6BS 4u4A==
X-Gm-Message-State: ALoCoQn1oe5YTkjhQlOKQ9683ld/0UtP6GCYeuXmrBsqsFrXwPzwDOBvVUKVkvra737qWXUDb0gs
X-Received: by 10.112.252.42 with SMTP id zp10mr11923728lbc.51.1422502810878;  Wed, 28 Jan 2015 19:40:10 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.211.132 with HTTP; Wed, 28 Jan 2015 19:39:50 -0800 (PST)
In-Reply-To: <47B6D023-437F-47E4-BC13-C773F0866288@pahtak.org>
References:   <47B6D023-437F-47E4-BC13-C773F0866288@pahtak.org>
From: Joe Hall 
Date: Wed, 28 Jan 2015 22:39:50 -0500
Message-ID: 
To: Stephen Checkoway 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-sslv3-diediedie-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Jan 2015 03:40:26 -0000

On Tue, Jan 27, 2015 at 1:23 PM, Stephen Checkoway  wrote:
>
> On Jan 23, 2015, at 2:42 PM, Andrei Popov  wr=
ote:
>
>> I=E2=80=99m in full support, let=E2=80=99s get rid of SSL.
>
> +1

+1

hear hear

--=20
Joseph Lorenzo Hall
Chief Technologist
Center for Democracy & Technology
1634 I ST NW STE 1100
Washington DC 20006-4011
(p) 202-407-8825
(f) 202-637-0968
joe@cdt.org
PGP: https://josephhall.org/gpg-key
fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871


From nobody Wed Jan 28 21:05:08 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDA101A8BB5 for ; Wed, 28 Jan 2015 21:05:04 -0800 (PST)
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 10Dv0OZ7iLjx for ; Wed, 28 Jan 2015 21:05:02 -0800 (PST)
Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 903D01A1BB3 for ; Wed, 28 Jan 2015 21:05:02 -0800 (PST)
Received: by mail-oi0-f49.google.com with SMTP id a3so23261018oib.8 for ; Wed, 28 Jan 2015 21:04:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:date:message-id:subject:from:to:cc:content-type;  bh=ycRglzXhn8s/cFCFYL0atbCbzkGF1EP3672W772a57Q=; b=flloKY/n5t4ZMrh0qRC4b3VBAw5g+t4Z1snLVD29MiKO3XLo+oRl/Bm7mf8DBoW3hX fXBHGcq5KyGZ72pDiltz9+vjXBlwZO4zmAZER0cODBAooz4PnpO2kxI+lkYEj0trMgZ5 BGyZTHXPK0ZJUlonyNxFK1oxbxiNgRfwB79pj6hgMzEXSu6A8cGutk5BfgsIkFKpov58 Kz5vtR1nqZ/fZqgEoSNBwSk+aHLUY7RRZ+/7BHSEXacPbFutjc8VaWkA5DV0i+FQNkfB lPWYjvubaPMSXMzCUpanXY3VgjuBN5LVvSh8KLUMN6yndceFxpTHOk6IgdS6S2PPnyUi lzqA==
MIME-Version: 1.0
X-Received: by 10.202.89.213 with SMTP id n204mr4153599oib.77.1422507899638; Wed, 28 Jan 2015 21:04:59 -0800 (PST)
Received: by 10.202.226.136 with HTTP; Wed, 28 Jan 2015 21:04:59 -0800 (PST)
Date: Wed, 28 Jan 2015 21:04:59 -0800
Message-ID: 
From: Martin Thomson 
To: "mrex@sap.com" 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "" 
Subject: [TLS] 1.0 or else (was Re: Working Group Last Call for draft-ietf-tls-sslv3-diediedie-00)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Jan 2015 05:05:05 -0000

On 28 January 2015 at 15:31, Martin Rex  wrote:
> That's not quite true.  There es little, if any stuff outside of the
> browser world that could go to > extension-less TLSv1.0, because there
> are still too many servers out there that will abort the handshake
> when extensions are present or when the version is > TLSv1.0.

Our limited survey thus far has identified only a small number (0.27%)
of sites [1][2] that can't handle our TLS 1.2 handshake [3], even
though they will tolerate our TLS 1.0 handshake.  In contrast,
disabling SSL3 affected more than twice this amount.

Note that we don't drop extensions now that SSL3 is disabled, so we
have no information on Martin's claims of extension intolerance.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1084025#c96
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1084025#c99
[3] We use a TLS 1.0 record layer, 1.2 ClientHello and a modest set of
extensions.


From nobody Thu Jan 29 02:02:15 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 135071A0126 for ; Thu, 29 Jan 2015 02:02:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level: 
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, 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 SL9mQOpS4sX9 for ; Thu, 29 Jan 2015 02:02:02 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D68781A007A for ; Thu, 29 Jan 2015 02:02:02 -0800 (PST)
Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t0TA20gv018771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 29 Jan 2015 05:02:00 -0500
Received: from oldenburg.str.redhat.com (oldenburg.str.redhat.com [10.33.200.60]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t0TA1v1Y026445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 29 Jan 2015 05:01:59 -0500
Message-ID: <54CA0515.5090506@redhat.com>
Date: Thu, 29 Jan 2015 11:01:57 +0100
From: Florian Weimer 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: mrex@sap.com
References: <20150128204236.CA94B1B130@ld9781.wdf.sap.corp>
In-Reply-To: <20150128204236.CA94B1B130@ld9781.wdf.sap.corp>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Archived-At: 
Cc: "TLS@ietf.org \(tls@ietf.org\)" 
Subject: Re: [TLS] consensus on backwards compatibility changes
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Jan 2015 10:02:08 -0000

On 01/28/2015 09:42 PM, Martin Rex wrote:
> There are several serious design flaws (resulting in serious weaknesses)
> in the TLSv1.2 signature algorithm extension, however.  TLSv1.2 is the
> only TLS protocol version where (rsa,md5) is a valid signature algorithm
> for creating "digitally-signed" PDUs (ServerKeyExchange and
> CertificateVerify), and that was a terribly stupid decision.
> Even (rsa,sha1) is significantly weaker than what every prior TLS
> protocol version, including SSLv3 had been using (rsa,sha1+md5).

Yes, that's what I meant, or more precisely, the {rsa,sha1} default in
case of a missing TLS extension (which includes SSLv2 Client Hello case).

-- 
Florian Weimer / Red Hat Product Security


From nobody Thu Jan 29 02:18:53 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D25E1A0149 for ; Thu, 29 Jan 2015 02:18:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level: 
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, 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 NuZ7GPxtWbXS for ; Thu, 29 Jan 2015 02:18:47 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 524C91A00E4 for ; Thu, 29 Jan 2015 02:18:47 -0800 (PST)
Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t0TAIkg2004295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 29 Jan 2015 05:18:46 -0500
Received: from pintsize.usersys.redhat.com (dhcp-0-172.brq.redhat.com [10.34.0.172]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t0TAIjZN016530 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 29 Jan 2015 05:18:46 -0500
From: Hubert Kario 
To: tls@ietf.org
Date: Thu, 29 Jan 2015 11:18:44 +0100
Message-ID: <1504300.ArI2OzS8We@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.3 (Linux/3.17.8-200.fc20.x86_64; KDE/4.14.3; x86_64; ; )
In-Reply-To: <20150128231009.GA25284@roeckx.be>
References: <9A043F3CF02CD34C8E74AC1594475C73AAF694DD@uxcn10-tdc05.UoA.auckland.ac.nz> <20150128231009.GA25284@roeckx.be>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
Archived-At: 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-sslv3-diediedie-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Jan 2015 10:18:49 -0000

On Thursday 29 January 2015 00:10:09 Kurt Roeckx wrote:
> On Wed, Jan 28, 2015 at 08:06:32AM +0000, Peter Gutmann wrote:
> > Dave Garrett  writes:
> > >Is it at all practical to publish an TLS RFC stating intent to deprecate
> > >TLS 1.0/1.1 within some fixed timeframe? I think everyone would rather
> > >phase it out then have to "be the hitman" each time.
> > 
> > I'm happy to have 1.0 phased out, but I'd make the baseline 1.1, not 1.2. 
> > 1.1 fixes the major issues with SSL (no support for extensions, no
> > per-message IV) without being a major rewrite like 1.2 is.  There's an
> > awful lot of stuff outside of the browser world that can move to 1.1 if
> > it isn't there already, but that's going to take a long, long time to
> > move to 1.2 if it ever does. Killing 1.0 (which is really just SSL
> > IETF-ised) is a pretty straightforward step if you're already getting rid
> > of SSL because it has most of the same problems, but deprecating 1.1 is
> > going a bit too far.
> 
> For
> some reason 1.2 actually seems to better support than 1.1.  There
> are a strange set of servers out there that support 1.0 and 1.2
> but not 1.1.

bug in openssl, SSL_OP_ALL from OpenSSL 1.0.0 did include SSL_OP_NO_TLSv1_1 
when run against OpenSSL 1.0.1:
https://rt.openssl.org/Ticket/Display.html?id=2802&user=guest&pass=guest

which you should know, given that you have submitted the above bug report ;)

-- 
Regards,
Hubert Kario


From nobody Thu Jan 29 10:00:40 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91EE11A1B4F for ; Thu, 29 Jan 2015 10:00:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.55
X-Spam-Level: 
X-Spam-Status: No, score=-6.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, WEIRD_PORT=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 eIE52pF2N21M for ; Thu, 29 Jan 2015 10:00:36 -0800 (PST)
Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96E431A1B6C for ; Thu, 29 Jan 2015 10:00:35 -0800 (PST)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 48DAB3A3BF; Thu, 29 Jan 2015 19:00:33 +0100 (CET)
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 3D57342157; Thu, 29 Jan 2015 19:00:33 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 332D71B137; Thu, 29 Jan 2015 19:00:33 +0100 (CET)
In-Reply-To: 
To: Martin Thomson 
Date: Thu, 29 Jan 2015 19:00:33 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20150129180033.332D71B137@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: 
Cc: "" 
Subject: Re: [TLS] 1.0 or else (was Re: Working Group Last Call for draft-ietf-tls-sslv3-diediedie-00)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Jan 2015 18:00:38 -0000

Martin Thomson wrote:
> Martin Rex  wrote:
>> That's not quite true.  There es little, if any stuff outside of the
>> browser world that could go to > extension-less TLSv1.0, because there
>> are still too many servers out there that will abort the handshake
>> when extensions are present or when the version is > TLSv1.0.
> 
> Our limited survey thus far has identified only a small number (0.27%)
> of sites [1][2] that can't handle our TLS 1.2 handshake [3], even
> though they will tolerate our TLS 1.0 handshake.  In contrast,
> disabling SSL3 affected more than twice this amount.


For our TLS client and our customers, the amount of public Websites
with TLS extension or TLS version intolerance is not very meaningful.

We do _not_ provide a browser.  Our customers are using our TLS client
for programmatic data exchange scenarios.  Historically most was PKCS7,
but newer scenarios often use WebService/SOAP.  However, we know very
little about our customers' usage scenarios, except that we are
not permitted to break it with software updates.


A while ago I mentioned this site:
http://www.elemica.com/

which uses TLS-protected data exchange, authenticated by SSL client certs,
on the following endpoints:
     https://preprod.connect.elemica.com:5443
     https://connect.elemica.com:5443

both of these (TLSv1.0) services are TLS version tolerant,
but will abort the handshake with a fatal unexpected_message alert
when the ClientHello contains *any* TLS extensions.

This server/service became known to me only by coincidence.  For a short
time, the service seems to have been selecting a TLS cipher suite that
our TLS client did not propose.  A customer reported the interop problem
because it affected a production scenario. But when I analyzed the
scenario, I could no longer reproduce that handshake failure with our
client.

Reproducing handshake failures with OpenSSL is trivial, though.
It seems impossible to have the openssl 1.0.1 s_client send an
extension-less TLS ClientHello. (only 0.9.8 s_client with "-no_ticket").


We will not be able to ship any substantial change in client behaviour
as default behaviour, but will have to limit it to "explicit customer opt-in"
-- which means that the vast majority of customers will not use it.

Substantial changes that are well known to cause interop problems are
 - use of TLS extensions in initial ClientHello
 - use of ClientHello.client_version > (3,1) for initial ClientHello
 - use of record layer protocol version other than (3,0) or (3,1)
   for initial ClientHello

adding a small number of TLS cipher suites IDs to ClientHello creates
only a manageable risk (rfc5746 did not cause any interop problems).


This is why I would really appreciate a mechanism bein standardized
similar to the one described in this message:

http://www.ietf.org/mail-archive/web/tls/current/msg11238.html

One additional round-trip is a completely negligent price for
full interop.  Heavily used communication links see a
ratio of session resumes vs full handshakes of 10:1 to 50:1,
so most of the time, the additional round trip on a clean
initial handshake will not matter anyway.  With the information
stored in the existing regular client-side TLS session cache,
the fall-forward strategy can also be avoided.  No additional
heuristics nor additoinal per-server caching of meta-data necessary.


-Martin


From nobody Thu Jan 29 10:19:12 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2951A0019 for ; Thu, 29 Jan 2015 10:19:05 -0800 (PST)
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_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 SXtp7WnBlcDe for ; Thu, 29 Jan 2015 10:19:00 -0800 (PST)
Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 102B91A1A58 for ; Thu, 29 Jan 2015 10:18:53 -0800 (PST)
Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 3333C1C2153; Thu, 29 Jan 2015 19:18:51 +0100 (CET)
Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 1056B1FE0177; Thu, 29 Jan 2015 19:18:50 +0100 (CET)
Date: Thu, 29 Jan 2015 19:18:50 +0100
From: Kurt Roeckx 
To: Hubert Kario 
Message-ID: <20150129181850.GA9608@roeckx.be>
References: <9A043F3CF02CD34C8E74AC1594475C73AAF694DD@uxcn10-tdc05.UoA.auckland.ac.nz> <20150128231009.GA25284@roeckx.be> <1504300.ArI2OzS8We@pintsize.usersys.redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1504300.ArI2OzS8We@pintsize.usersys.redhat.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Cc: tls@ietf.org
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-sslv3-diediedie-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Jan 2015 18:19:06 -0000

On Thu, Jan 29, 2015 at 11:18:44AM +0100, Hubert Kario wrote:
> > For
> > some reason 1.2 actually seems to better support than 1.1.  There
> > are a strange set of servers out there that support 1.0 and 1.2
> > but not 1.1.
> 
> bug in openssl, SSL_OP_ALL from OpenSSL 1.0.0 did include SSL_OP_NO_TLSv1_1 
> when run against OpenSSL 1.0.1:
> https://rt.openssl.org/Ticket/Display.html?id=2802&user=guest&pass=guest
> 
> which you should know, given that you have submitted the above bug report ;)

I do know about that bug report.  The only people that should have
been affected by it were those that compiled against 1.0.1 and not
against ealier or later releases like any 1.0.0* or 1.0.1[a-l].

The sites that have this behaviour are also larger sites that
probably use some kind of accelator hardware, and I suspect it's
that hardware that doesn't do TLS 1.1.  At least 1 site I know
about that doesn't know TLS 1.1 but does TLS 1.2 is also
vulnerable to poodle in TLS, so they can't be using openssl.


Kurt


From nobody Thu Jan 29 22:06:30 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55E0C1A890B for ; Thu, 29 Jan 2015 22:06:26 -0800 (PST)
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_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 M-QFzya5Lmi3 for ; Thu, 29 Jan 2015 22:06:23 -0800 (PST)
Received: from mail-qc0-f175.google.com (mail-qc0-f175.google.com [209.85.216.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 038121A8905 for ; Thu, 29 Jan 2015 22:06:22 -0800 (PST)
Received: by mail-qc0-f175.google.com with SMTP id c9so19140864qcz.6 for ; Thu, 29 Jan 2015 22:06:22 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=Wp2nM0K/ntEyO3BUHcN1T2sagsIUyaUgzISFChHwPz8=; b=FB/3kN1TZr78id4X5hE9xnxPWmKdPiisrHnHMhKOi97gjXovWBRYdhGCbD4/qrKkeJ h6Ye6/SdCa+Hzz044z98nQg8jjfSXvECVNVIH93qSp8Ia6GHY2Mbb9c2qCJsyzog/VcF DAYKb9ChgUOWlo6IdkLubXkNkCtHSIoM0upAB4xrpWLONPvvcIWrTC0meXtIapsRfeFh Y32L22OGDG/PfYx8AF56sC0hb9Uj2uDq0C2dykoOcgtkdnWBjbaCGH8FM4tinB60Bday i1oO4H3z9Et6I0FuOcswI4QGqDXznTO5aXspwI6xOpNS85T83z3KBc3pdfTjakro3xSD zcyg==
X-Gm-Message-State: ALoCoQmijgP6GZBfSAuN2q6JPJW1ZYegVQWT+Ok97DwpKn3zyrTGQFUPrNulcFYzkqRGSx9Ez7s9
X-Received: by 10.224.129.202 with SMTP id p10mr9032856qas.54.1422597982029; Thu, 29 Jan 2015 22:06:22 -0800 (PST)
Received: from zbox.pahtak.org (c-73-213-90-80.hsd1.md.comcast.net. [73.213.90.80]) by mx.google.com with ESMTPSA id q15sm9188262qak.41.2015.01.29.22.06.19 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Jan 2015 22:06:20 -0800 (PST)
Received: from [192.168.1.7] (hackintosh.local [192.168.1.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by zbox.pahtak.org (Postfix) with ESMTPSA id 5928CAC2866; Fri, 30 Jan 2015 01:06:17 -0500 (EST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Stephen Checkoway 
In-Reply-To: 
Date: Fri, 30 Jan 2015 01:06:16 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <67ce141550f34f31b508c53766990e16@ustx2ex-dag1mb2.msg.corp.akamai.com>,  <54C7F5F3.9020800@azet.org> 
To: Yuhong Bao 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Cc: "TLS@ietf.org tls@ietf.org" 
Subject: Re: [TLS] Questions about some expired drafts
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Jan 2015 06:06:26 -0000

On Jan 27, 2015, at 8:22 PM, Yuhong Bao  =
wrote:

> Yea, I believe the draft-rescorla-tls-extended-random is quite famous =
as a backdoor,=20
> along with Dual_EC_DRBG.

Well, it makes attacks easier by exposing more consecutive raw Dual EC =
output bits. For P-384 and P-521, it makes the attack doable at all (at =
least in theory, I didn't actually validate that against an =
implementation that supported extended random like RSA's BSAFE =
libraries).

--=20
Stephen Checkoway




From nobody Fri Jan 30 02:32:41 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA3311A8AC5 for ; Fri, 30 Jan 2015 02:32:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level: 
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, 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 RHcwDL0zyju5 for ; Fri, 30 Jan 2015 02:32:37 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DAEA1A8AB7 for ; Fri, 30 Jan 2015 02:32:36 -0800 (PST)
Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t0UAWZKG022772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 30 Jan 2015 05:32:35 -0500
Received: from pintsize.usersys.redhat.com (vpn1-5-211.ams2.redhat.com [10.36.5.211]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t0UAWVNK021378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2015 05:32:34 -0500
From: Hubert Kario 
To: Kurt Roeckx 
Date: Fri, 30 Jan 2015 11:32:31 +0100
Message-ID: <3944737.Vi3xPCYbBb@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.3 (Linux/3.17.8-200.fc20.x86_64; KDE/4.14.3; x86_64; ; )
In-Reply-To: <20150129181850.GA9608@roeckx.be>
References: <9A043F3CF02CD34C8E74AC1594475C73AAF694DD@uxcn10-tdc05.UoA.auckland.ac.nz> <1504300.ArI2OzS8We@pintsize.usersys.redhat.com> <20150129181850.GA9608@roeckx.be>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Archived-At: 
Cc: tls@ietf.org
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-sslv3-diediedie-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Jan 2015 10:32:39 -0000

On Thursday 29 January 2015 19:18:50 Kurt Roeckx wrote:
> On Thu, Jan 29, 2015 at 11:18:44AM +0100, Hubert Kario wrote:
> > > For
> > > some reason 1.2 actually seems to better support than 1.1.  There
> > > are a strange set of servers out there that support 1.0 and 1.2
> > > but not 1.1.
> > 
> > bug in openssl, SSL_OP_ALL from OpenSSL 1.0.0 did include
> > SSL_OP_NO_TLSv1_1
> > when run against OpenSSL 1.0.1:
> > https://rt.openssl.org/Ticket/Display.html?id=2802&user=guest&pass=guest
> > 
> > which you should know, given that you have submitted the above bug report
> > ;)
> I do know about that bug report.  The only people that should have
> been affected by it were those that compiled against 1.0.1 and not
> against ealier or later releases like any 1.0.0* or 1.0.1[a-l].
> 
> The sites that have this behaviour are also larger sites that
> probably use some kind of accelator hardware, 

well, one thing doesn't exclude the other - especially given the support for 
`engine` in OpenSSL

> and I suspect it's
> that hardware that doesn't do TLS 1.1.  At least 1 site I know
> about that doesn't know TLS 1.1 but does TLS 1.2 is also
> vulnerable to poodle in TLS, so they can't be using openssl.

interesting...
-- 
Regards,
Hubert Kario


From nobody Fri Jan 30 09:15:34 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D5A61A8702 for ; Fri, 30 Jan 2015 09:15:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level: 
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, 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 GWL9SXrp2xjw for ; Fri, 30 Jan 2015 09:15:29 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C78901A6EDA for ; Fri, 30 Jan 2015 09:15:29 -0800 (PST)
Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t0UHFPYV005710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 30 Jan 2015 12:15:26 -0500
Received: from pintsize.usersys.redhat.com (vpn1-5-211.ams2.redhat.com [10.36.5.211]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t0UHFM4a025705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2015 12:15:24 -0500
From: Hubert Kario 
To: tls@ietf.org, mrex@sap.com
Date: Fri, 30 Jan 2015 18:15:21 +0100
Message-ID: <59280567.z7RHC5U6jC@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.3 (Linux/3.17.8-200.fc20.x86_64; KDE/4.14.3; x86_64; ; )
In-Reply-To: <20150129180033.332D71B137@ld9781.wdf.sap.corp>
References: <20150129180033.332D71B137@ld9781.wdf.sap.corp>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Archived-At: 
Subject: Re: [TLS] 1.0 or else (was Re: Working Group Last Call for draft-ietf-tls-sslv3-diediedie-00)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Jan 2015 17:15:32 -0000

On Thursday 29 January 2015 19:00:33 Martin Rex wrote:
> Martin Thomson wrote:
> > Martin Rex  wrote:
> >> That's not quite true.  There es little, if any stuff outside of the
> >> browser world that could go to > extension-less TLSv1.0, because there
> >> are still too many servers out there that will abort the handshake
> >> when extensions are present or when the version is > TLSv1.0.
> > 
> > Our limited survey thus far has identified only a small number (0.27%)
> > of sites [1][2] that can't handle our TLS 1.2 handshake [3], even
> > though they will tolerate our TLS 1.0 handshake.  In contrast,
> > disabling SSL3 affected more than twice this amount.
> 
> For our TLS client and our customers, the amount of public Websites
> with TLS extension or TLS version intolerance is not very meaningful.

the point of those studies is not to test the whole TLS ecosystem - that's 
simply impossible

the point is to have at least /some/ reference point

also, HTTPS is the biggest user of TLS so it's likely that if there is a TLS 
implementation it is used by somebody to encrypt web traffic. HTTPS is also 
basically the only one that gets any kind of scrutiny wrt. used 
configurations.

if you have different statistics, please share them

> adding a small number of TLS cipher suites IDs to ClientHello creates
> only a manageable risk (rfc5746 did not cause any interop problems).

It probably did not, but tests done by Yngve say something different wrt to 
cipher id selected for fallback scsv

-- 
Regards,
Hubert Kario


From nobody Fri Jan 30 11:15:19 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 178FF1A0021 for ; Wed, 28 Jan 2015 22:38:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level: 
X-Spam-Status: No, score=-2.01 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable
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 1cyqZy6dtZTb for ; Wed, 28 Jan 2015 22:38:09 -0800 (PST)
Received: from nm2-vm6.bullet.mail.gq1.yahoo.com (nm2-vm6.bullet.mail.gq1.yahoo.com [98.136.218.133]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 561CB1A8F41 for ; Wed, 28 Jan 2015 22:38:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1422513487; bh=XtQEFzNVZTvhD+SEMTc2HjYXVg9v9cEWzhWQLiufdG8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject; b=KCf86FqQ3du5Z8OKwFtCMmBMmZxu8vk143IZOoKxBOMUR8ozNo5cC4dXbodkvE2nSl3l1HKCtBzvmr1EKNjBhp54GFDVTlN2znr1DRZ3QCSP5DVeE9OOrjN8mDNQxzHBK2nkO3COsL8Ttoe4JkG7eVcwXxMcN1A6dYxnYFk19hASKKo09uLZHBASoJN2By+VcTIP54K332mymgTPQcgbuZEubKUBruZY4lFYwvNqFh+BNv56rY+4NRMM2kK3/5YHPrTpHRo4ViRryZATuE2uo4PL2OwVLVpRy9ymIP1EVwRUbl2Uq98NuiDq/vk5QGwBh2Ipu7LmjJpGhPZ46mfasw==
Received: from [98.137.12.58] by nm2.bullet.mail.gq1.yahoo.com with NNFMP; 29 Jan 2015 06:38:07 -0000
Received: from [98.136.164.74] by tm3.bullet.mail.gq1.yahoo.com with NNFMP; 29 Jan 2015 06:38:07 -0000
Received: from [127.0.0.1] by smtp236.mail.gq1.yahoo.com with NNFMP; 29 Jan 2015 06:38:07 -0000
X-Yahoo-Newman-Id: 734105.77297.bm@smtp236.mail.gq1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: tjJXRqoVM1lenUA4Rnwj3tIKMVNPqxvWdO95p8BR8KUve5P Xz2kflu0PIQE5HF2Vv_NEjQsXJZCeg0pegC_.TLUtD3U9QQE3OcJDCAhYNn3 .iwnuXV8p3e.emFaidctb9oAa4j0NmlH1tLcHGhIfb8sVaKRrtv3.508FPDK eRwG0fPPLlwfKQmVes84tzv1Pt9__PNYfgYZ7XjVRAV49_SYZIaBKT2o0nL2 I0wAfnSIIZp6rFG3eVBay2YPV5MnGAL8CNPBx84PnXAqCKIu.5wEz1vl8P7T FLhY7ow3QS964eO4PzoWUYei7NmknTAwjUwykeOycHmrtst_6KOUNJYgPdm5 COEit4_h9MGz.P0.RenXEocpgRcsQKufADtE7EovtPTExPdmIoBhqZ_NoNMx uC06Hoo4XRh2ztg8ManBW2.PBWDUPF9BrkdtztNBjRobZg5k1gLvPqc71_XR jvFcrYU_OGZtPP9hp0jkjSMN4qlPRlklaHZp4O_kZn2M7kBhnH7CuD60axzz KUdHK6S.wzXB2IjyJ.Q_xpxMdDKwiMf9pZQ--
X-Yahoo-SMTP: wgdooiaswBDebjkzZfF3YfFOtEw-
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_D1A45340-026A-4486-9BCB-971E786EF32A"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5b4
From: Nex6|Bill 
In-Reply-To: <20150101203734.GF24442@localhost>
Date: Wed, 28 Jan 2015 22:37:58 -0800
Message-Id: <493F162A-E924-49C9-A5B6-D169CFED7DD0@yahoo.com>
References:  <1420033807.4638.16.camel@scientia.net>  <1420042774.10106.10.camel@scientia.net>  <20141231221420.GX24442@localhost>  <20150101203734.GF24442@localhost>
To: tls@ietf.org
X-Mailer: Apple Mail (2.2070.6)
Archived-At: 
X-Mailman-Approved-At: Fri, 30 Jan 2015 11:15:17 -0800
Cc: "cfrg@irtf.org" , ietf@ietf.org
Subject: Re: [TLS] [Cfrg] Reconsider TLS/CFRG relationship (Re: should the CFRG really strive for consensus?)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Jan 2015 06:38:11 -0000

--Apple-Mail=_D1A45340-026A-4486-9BCB-971E786EF32A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Jan 1, 2015, at 12:37 PM, Nico Williams  =
wrote:
>=20
> [Reply-To set to tls@ietf.org.]
>=20
> On Thu, Jan 01, 2015 at 05:52:55PM +0000, Alexey Melnikov wrote:
>>> On 31 Dec 2014, at 22:14, Nico Williams  =
wrote:
>=20
> [Elided here is a sub-thread about how much trouble CFRG has had =
making
> decisions, and how unsuited they are to the task.  These were opinions
> stated by others.  My response was that if CFRG can't choose, that's
> fine, let CFRG do what it's good at (cryptology), and let the IETF do
> what it's good at (engineering).
>=20
> For the benefit of ietf@ietf.org readers, the context is that CFRG was
> tasked with producing recommendations for the TLS WG, but CFRG seems
> mired in debate about them.  =46rom my point of view the risk is that =
the
> logjam won't soon be broken.]
>=20
>>> Let the IRTF publish one or more documents describing various curves
>>> suitable for use in Internet protocols.  The IETF can pick from =
among
>>> those.
>>=20
>> That is not what TLS WG /SEC AD asked for. They would rather CFRG =
make
>> a choice that can be used in TLS and other places, instead of letting
>> each IETF WG make their own different choice.
>=20
> We may have to reconsider this then.
>=20
> If it is really true that CFRG is not adept at making choices, then =
let
> the cryptologists document algorithms (including their cryptographic
> attributes, pros, cons, cryptanalysis, general performance analysis,
> security considerations, and an overall assessment), and let the
> engineers pick from among them.  I.e., what we've always done at the
> IETF.
>=20
> This might require some process (a call for consensus in the TLS WG?),
> but once done CFRG will be freed to do what it's good at, and to do it
> more quickly because there will be no more lengthy arguments about =
what
> to choose.  Authors will publish I-Ds, reviewers will review them, and
> barring any serious problems, CFRG will progress those I-Ds.  The TLS
> (and other) WGs can then choose what they like.
>=20
> I don't mean to start a debate about this _now_.  Rather, now is the
> time point out that we may have to have this debate, possibly before =
the
> next time we ask the IRTF for recommendations.
>=20
> Nico
>=20

I have been following this list for awhile, but have not posted =
anything, but; I am not sure I agree with the above.
if the CFRG does not =E2=80=9Cpick=E2=80=9D or recommend, and instead =
just publish about said algorithms, and IETF then just picks
whatever they want, not sure how that would ensure the best algorithms =
get picked and put into standards.

would it not be better, to work on CFRG processess so it can produce a =
recommendation? is not good debate good?
why would it be better to have less debate?

I think in this day and age, we need to be careful and which algortithms =
get into standards.

-Nex6



--Apple-Mail=_D1A45340-026A-4486-9BCB-971E786EF32A
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJUydVMAAoJEBr/3kncCBhnR08QAJLJe5Yt1Md+cuFtCJZtKXYY
hj0QTb6BtwBNJ5Dcd+aJBAbVsmwJqBi7B5AqioAThZnvuypJ7p7gyFi4HbMcaT8Q
OA/zFwQTjMh/o1WcvLpin57Acda5ihaS7wZG/i97VKS+o45JBzSLk/tHrIZuzroR
BA5TvhP9/f9zAOiMvuOW+eJTpCpHPoxDS0hKSGzddIBVER2ingUvkdezwHnWA0R/
uu9uAHK/tZWNcqO4VUj9jAUNQDNkhvgKwVBv8OB0NnqpxLslEnzM32nczto5YTh3
iFOD0n0YMF3yal5GK0vXCP0+heK8lujL4nt6aTdU7Vr5fdxD5ULQaNzWR8on7rX3
1gYLMKw7G6JS5AIeZRHFwLPC7ujbuToPc+LRL0d1hq1DCovum9zK1fsUa/7ELvuE
N2ihnVjy0wxGEYqOjapct0rUAa69Cou41UKQfX68Uc70Ba/HMIL1M8DMmTUPvueW
YRKUlbDwTRel+zk41sywPVcY8r0NUqHKZSalrVLGRTBN4VYFltW44ptvgza9bnmw
c7lIQCwKtCtLi5xrx+ExLLyTJgUAXnYHNXXOBW+cF5C8crxyVTVxjs6kUhwq+dvS
rFDYjtI+JSpmoTnJUCkb92YxwgO84bJ93i4Lt148Pd0fxV/wGADf7LrkQKGgLvkB
QwgM7DS5X1DrqOPPrN1M
=K5HW
-----END PGP SIGNATURE-----

--Apple-Mail=_D1A45340-026A-4486-9BCB-971E786EF32A--