From nobody Mon Jun 1 03: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 DB3AF1A9166 for ; Mon, 1 Jun 2015 03:03:10 -0700 (PDT) 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 4RQOaqWUqs5z for ; Mon, 1 Jun 2015 03:03:07 -0700 (PDT) Received: from mmextmx2.mcr.colo.comodoca.net (mmextmx2.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd6]) (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 61AB81A9154 for ; Mon, 1 Jun 2015 03:03:07 -0700 (PDT) Received: (qmail 5930 invoked by uid 1004); 1 Jun 2015 10:03:05 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx2.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Mon, 01 Jun 2015 11:03:05 +0100 Received: (qmail 9026 invoked by uid 1000); 1 Jun 2015 10:03:00 -0000 Received: from Unknown (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Mon, 01 Jun 2015 11:02:59 +0100 Message-ID: <556C2DC7.1050309@comodo.com> Date: Mon, 01 Jun 2015 11:02:47 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Simon Josefsson , Peter Bowen , Yoav Nir References: <1432142087.2946.11.camel@josefsson.org> <20150520190727.GD19183@localhost> <87lhg7w091.fsf@latte.josefsson.org> In-Reply-To: <87lhg7w091.fsf@latte.josefsson.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Strawman on EdDSA/Ed25519 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: Mon, 01 Jun 2015 10:03:11 -0000 On 29/05/15 22:18, Simon Josefsson wrote: > Peter Bowen writes: >> I'll donate a short OID to the cause if that will help move things >> forward. We have the 1.3.187 arc which is only three bytes DER. If >> someone has a smaller arc (third node would be 127 or lower) and would >> offer an OID from their arc we can shave off another couple of bytes. > > Anyone? I have 1.3.6.1.4.1.11591 but it is much longer. > > If you can allocate one OID for PKIX-EdDSA and one for PKIX-Ed25519 we > have two values to work with for doing a PKIX EdDSA or Ed25519 draft. > It is not clear to me which approach is best, and if you have room for > two OIDs let have two different from the start in case people want to > experiment with both. > > Thank you for thinking of saving bytes here! :-) > > /Simon http://www.alvestrand.no/objectid/1.3.html "1.3.114 - Check Point's registered prefix" Yoav? -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Mon Jun 1 03:47: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 791D81AC406 for ; Mon, 1 Jun 2015 03:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AwWVAkJW0t8V for ; Mon, 1 Jun 2015 03:46:55 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::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 EE4801AC402 for ; Mon, 1 Jun 2015 03:46:54 -0700 (PDT) Received: by wicmx19 with SMTP id mx19so71274835wic.0 for ; Mon, 01 Jun 2015 03:46:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ccvjqFsEH2lAr5GAPK++PMuLUUUiBsvyWc5xyQMUmiE=; b=hi0nV4yCI+OY4klt1f4/hKmQD0daJZPtW0W0G+MsO/BM+ieKsAVvpGelQbYllxm7J1 4DY4dnxPEtGryZlEqerfpmEU5Q2nCRow8JA5dxc34JwGrRvhCvHWnOXdo95IxcT/p6c6 nMyD5H94XfDV++Z8297WWgjGHZlV0Fqx+8wob9R3ATx053ZuGmSw895O1tTilChJBgMP YxnFXxmDqPiTD6WD6+n3CasRFtPv4y7ubaDeL5F6xQDXITeCLJhw9GTXSKnunLmC/f48 chGcG4CpmFA1C8cMiw4k0BK1L6jVid6+JkC/yjy66EYA5SIyIgbYEF07QTHZfGGoWdQs 1b9w== X-Received: by 10.180.82.6 with SMTP id e6mr19930238wiy.84.1433155613729; Mon, 01 Jun 2015 03:46:53 -0700 (PDT) Received: from [172.24.251.210] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id um5sm21290980wjc.1.2015.06.01.03.46.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Jun 2015 03:46:52 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Yoav Nir In-Reply-To: <556C2DC7.1050309@comodo.com> Date: Mon, 1 Jun 2015 13:46:50 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1432142087.2946.11.camel@josefsson.org> <20150520190727.GD19183@localhost> <87lhg7w091.fsf@latte.josefsson.org> <556C2DC7.1050309@comodo.com> To: Rob Stradling X-Mailer: Apple Mail (2.2098) Archived-At: Cc: Simon Josefsson , "tls@ietf.org" Subject: Re: [TLS] Strawman on EdDSA/Ed25519 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: Mon, 01 Jun 2015 10:46:57 -0000 > On Jun 1, 2015, at 1:02 PM, Rob Stradling = wrote: >=20 > On 29/05/15 22:18, Simon Josefsson wrote: >> Peter Bowen writes: > >>> I'll donate a short OID to the cause if that will help move things >>> forward. We have the 1.3.187 arc which is only three bytes DER. If >>> someone has a smaller arc (third node would be 127 or lower) and = would >>> offer an OID from their arc we can shave off another couple of = bytes. >>=20 >> Anyone? I have 1.3.6.1.4.1.11591 but it is much longer. >>=20 >> If you can allocate one OID for PKIX-EdDSA and one for PKIX-Ed25519 = we >> have two values to work with for doing a PKIX EdDSA or Ed25519 draft. >> It is not clear to me which approach is best, and if you have room = for >> two OIDs let have two different from the start in case people want to >> experiment with both. >>=20 >> Thank you for thinking of saving bytes here! :-) >>=20 >> /Simon >=20 > http://www.alvestrand.no/objectid/1.3.html >=20 > "1.3.114 - Check Point's registered prefix" >=20 > Yoav? That=92s interesting. I=92ll ask around. It=92s surprising to me, = because every time in the past that I needed an OID, we allocated it out = of 1.3.6.1.4.1.2620.x. http://www.alvestrand.no/objectid/1.3.6.1.4.1.2620.html I didn=92t think we=92d want 1.3.6.1.4.1.2620.4.1, so I didn=92t speak = up. I=92ll find out where this 1.3.114 came from, and why we=92re not using = it. Yoav From nobody Mon Jun 1 04:26: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 DA2CC1A00F7 for ; Mon, 1 Jun 2015 04:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_35=0.6] 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 j4dWo8vJDh85 for ; Mon, 1 Jun 2015 04:26:08 -0700 (PDT) Received: from mmextmx2.mcr.colo.comodoca.net (mmextmx2.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd6]) (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 8F24F1A00F6 for ; Mon, 1 Jun 2015 04:26:07 -0700 (PDT) Received: (qmail 8974 invoked by uid 1004); 1 Jun 2015 11:26:05 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx2.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Mon, 01 Jun 2015 12:26:05 +0100 Received: (qmail 2751 invoked by uid 1000); 1 Jun 2015 11:26:00 -0000 Received: from Unknown (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Mon, 01 Jun 2015 12:26:00 +0100 Message-ID: <556C413D.10209@comodo.com> Date: Mon, 01 Jun 2015 12:25:49 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Yoav Nir , Simon Josefsson , Peter Bowen References: <1432142087.2946.11.camel@josefsson.org> <20150520190727.GD19183@localhost> <87lhg7w091.fsf@latte.josefsson.org> <556C2DC7.1050309@comodo.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Strawman on EdDSA/Ed25519 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: Mon, 01 Jun 2015 11:26:11 -0000 On 01/06/15 11:46, Yoav Nir wrote: >> "1.3.114 - Check Point's registered prefix" >> >> Yoav? > > Thats interesting. Ill ask around. Thanks Yoav. Another candidate to ask... http://www.alvestrand.no/objectid/1.3.101.html Thawte are a commercial CA (owned by Symantec these days), so I expect they'll want to use EdDSA for TLS server certs at some point. 101 could create some nice OID encodings for EC, Ed*, Ed25519 and Ed448. :-D $ echo "06032b6563" | xxd -r -ps | openssl asn1parse -inform der -i 0:d=0 hl=2 l= 3 prim: OBJECT :1.3.101.99 $ echo "06032b6563" | xxd -r -ps | xxd 0000000: 0603 2b65 63 ..+ec $ echo "06032b6564" | xxd -r -ps | openssl asn1parse -inform der -i 0:d=0 hl=2 l= 3 prim: OBJECT :1.3.101.100 $ echo "06032b6564" | xxd -r -ps | xxd 0000000: 0603 2b65 64 ..+ed $ echo "06032b6532" | xxd -r -ps | openssl asn1parse -inform der -i 0:d=0 hl=2 l= 3 prim: OBJECT :1.3.101.50 $ echo "06032b6532" | xxd -r -ps | xxd 0000000: 0603 2b65 32 ..+e2 $ echo "06032b6534" | xxd -r -ps | openssl asn1parse -inform der -i 0:d=0 hl=2 l= 3 prim: OBJECT :1.3.101.52 $ echo "06032b6534" | xxd -r -ps | xxd 0000000: 0603 2b65 34 ..+e4 -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. From nobody Mon Jun 1 05:06: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 8E0751A1AAD for ; Mon, 1 Jun 2015 05:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MklSJmStfaI for ; Mon, 1 Jun 2015 05:06:43 -0700 (PDT) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (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 8A0901A1A99 for ; Mon, 1 Jun 2015 05:06:43 -0700 (PDT) Received: by wibut5 with SMTP id ut5so36321756wib.1 for ; Mon, 01 Jun 2015 05:06:42 -0700 (PDT) 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:content-type; bh=WD2UO5UFnk142DIpCbHlRS3H6vZpjFbWWkSgqxCtWYQ=; b=IrhLUdZ7bQj9Qw/iR5CHuFJh3N0E/s6nI0fAGxo75cHFIZvtGCy2vAGWfrCpGGY59S F4MdjUexDVxbG9GYRmLZ1DuRowVRGdapvsWyXeTHqBIic5E4UquCmS00falHCHVhXmbq qjCGbxbRjX817ev6JUP1/JZkL7uCH5AREDJ47k4spy0g6NyVzKbeVyW1n6Cp6ktovP5W r5T4wUNMXbxpiSUvwaYeSdbLqP53yIZC+PdSvPFyeb8W77iMwKEQRSYRHQFuAHpIAM5X KhEnmkno1vcy+UGXnrPak6E1eUr8Gp2rtGg2ngRoV8hbmokoDKKavFIQgyrknIq9ffAM zkbw== X-Gm-Message-State: ALoCoQnadupgMJPOdSU+8mQTg1jhIKAKJDiWSiOwTRlM87f77AGn3lnwQdPoutBblo8Iida/MVm6 X-Received: by 10.181.13.5 with SMTP id eu5mr19610380wid.37.1433160402275; Mon, 01 Jun 2015 05:06:42 -0700 (PDT) Received: from [192.168.23.81] (chello212017113090.11.11.vie.surfer.at. [212.17.113.90]) by mx.google.com with ESMTPSA id vz2sm12323214wjc.18.2015.06.01.05.06.39 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Jun 2015 05:06:41 -0700 (PDT) Message-ID: <556C4ACD.9040002@azet.org> Date: Mon, 01 Jun 2015 14:06:37 +0200 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="------------enigE7E75F865B1E5F1A55A8929F" Archived-At: Cc: Phillip Rogaway , Charanjit Jutla Subject: [TLS] AES-OCB in TLS [New Version Notification for draft-zauner-tls-aes-ocb-03.txt] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Jun 2015 12:06:46 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE7E75F865B1E5F1A55A8929F Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, With renewed interest on-list w.r.t. efficient single pass AEAD schemes, I'm happy to update you on the work done for this document. I'm told over the last couple of months IBM lawyers have been working hard to come to a consensus if they're willing to exempt IAPM (a technique OCB mode is based on) from patents for use in TLS. They've agreed to do this. We've since included all active patents on OCB and IAPM in the document with a section detailing the current patent situation of OCB mode for potential use in TLS. I could not reach Rogaway within the last two weeks so I've included his patents to the best of my knowledge. This update also features a couple of small editorial corrections. There're a few things I'd like to change: * I totally agree that having to many ciphersuites is counterproductive so I'd like to propose to get rid of PSK ciphersuites in general within this document * I'd also like to get rid of ECDSA ciphersuites alltogether, ideally leaving a few real-world, high-performance ciphersuites to use Thoughts and feedback apprechiated, diff, HTML et cetera can be accessed via the quoted mail below. GitHub: https://github.com/azet/draft-zauner-tls-aes-ocb Thanks, Aaron internet-drafts@ietf.org wrote: > A new version of I-D, draft-zauner-tls-aes-ocb-03.txt > has been successfully submitted by Aaron Zauner and posted to the > IETF repository. >=20 > Name: draft-zauner-tls-aes-ocb > Revision: 03 > Title: AES-OCB (Offset Codebook Mode) Ciphersuites for Transport Layer= Security (TLS) > Document date: 2015-06-01 > Group: Individual Submission > Pages: 7 > URL: https://www.ietf.org/internet-drafts/draft-zauner-tls-a= es-ocb-03.txt > Status: https://datatracker.ietf.org/doc/draft-zauner-tls-aes-o= cb/ > Htmlized: https://tools.ietf.org/html/draft-zauner-tls-aes-ocb-03= > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-zauner-tls-ae= s-ocb-03 >=20 > Abstract: > This memo describes the use of the Advanced Encryption Standard (AES= ) > in the Offset Codebook Mode (OCB) of operation within Transport Laye= r > Security (TLS) and Datagram TLS (DTLS) to provide confidentiality an= d > data origin authentication. The AES-OCB algorithm is highly > parallelizable, provable secure and can be efficiently implemented i= n > software and hardware providing high performance. Furthermore, use > of AES-OCB in TLS is exempt from past IPR claims by various parties.= >=20 > = =20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submi= ssion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --------------enigE7E75F865B1E5F1A55A8929F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVbErNAAoJEOTbZJL9ubXVXb8P/jhwrmmDXbwBVI5j2kFvGiIn O24nUVpIBcCULfH6ISA8JY4z4TScUbtzQVhvxxbtM01llC/sZboJQ1wej86KQs1U aWq4RFksdI90jI55EXgZVb0rqZM46aX7PwKGFitdRoj0F08a9DBh+6J7M2veNdD+ 3Nrw/9cMnqzdfphW2Ia531exsXpKcJigYpHQdshCz/fhhhu5lUipOjqfzt5/mhw3 hGh4ETTz5vhMOT+eMzJccblIcppAyP1VRGKC+L8PqjSRkRfhC/9VnMx2Uayw29uG axqy8b6ch4XIwiU5EPRaDQBLOZX6gXMpnv2JzvJSd4Pet+zx5yEW5N3o3lW9eFxc Rs6NVkHEQ4sCaYiSxt7HCKBkXE6Ro7yEu1jlYsd1NfFqen5hvulE+2fCuGo/bDK1 JL3BUKFBkCMNBXx0D80yPG6gLlEMCgMJvsCk2bR3aaJy8q5aAiiNzUkFp2uYplbw UqqrOiRKYYOtgAxjXH8c5Lyq+P8c3WThIyN4FnWUbrcikTmcnL1YJAe+6eoRLJig eAGSqpx+P00TkVZhB7bp6zaT7tYekDxkUB3PDVpu7KS7wvDIkvIgNAY0FmiEvPSL r5G9IwM7OL8sl7K7hlWaOQWRuv/ZLEertJHD83xXsBg3eUml5ImL/Rx7+AyzeGQu 1bq/TPio9AzLLbVh7S0J =Gumd -----END PGP SIGNATURE----- --------------enigE7E75F865B1E5F1A55A8929F-- From nobody Mon Jun 1 05:30: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 370C81A9047 for ; Mon, 1 Jun 2015 05:30:36 -0700 (PDT) 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 Jl49Q24N0B1f for ; Mon, 1 Jun 2015 05:30:34 -0700 (PDT) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (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 DCD211A9036 for ; Mon, 1 Jun 2015 05:30:33 -0700 (PDT) Received: by wizo1 with SMTP id o1so102854794wiz.1 for ; Mon, 01 Jun 2015 05:30:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=99CN3GKXaZxjmwKT4ZNNofEDAnxNrwDHYGyb4iNZJfE=; b=jDTjG1Kk4HHGI7FPzt+FE1mu5Jcz+c73bQl15gZcm80LE8YLUXnk71N+V2tRyQ+yG7 oQYGy+bZb+1lz/8FYdt36CXeY1ztiBawgsdifCx2RF/xEbUnIpYUDzL75vKwGLqS+klA J6VBzRIUeb5U1Zol6y7IAX2bHQ7WLlxbCM7EkD5B6jGpb73lfURDO+aitW/2fonG6nZo eKWcgAhedF2NZdTVkfLsKz3amuOQA5Y4jKZpOnXFTOtynP1ABAMZoKE+2iaOKcY7J7iA 6lUvgLoFN3DWoEWnwONPQP7VBvDlbAPjFRGtXLgSSAdOcqoICkBqergbgKvTfOMH0RVJ X3dw== X-Gm-Message-State: ALoCoQmb+59/Mnf7Tht07vuRKKyJ+X4/JSF6FFe33G4Q6CTorm7TQFlYdW3Turl6EteU9ZX7TgVK X-Received: by 10.194.59.79 with SMTP id x15mr24062067wjq.81.1433161832617; Mon, 01 Jun 2015 05:30:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.225.14 with HTTP; Mon, 1 Jun 2015 05:29:52 -0700 (PDT) In-Reply-To: <556C4ACD.9040002@azet.org> References: <556C4ACD.9040002@azet.org> From: Eric Rescorla Date: Mon, 1 Jun 2015 05:29:52 -0700 Message-ID: To: Aaron Zauner Content-Type: multipart/alternative; boundary=047d7b8737aef0700b051773fd88 Archived-At: Cc: Phillip Rogaway , TLS Mailing List , Charanjit Jutla Subject: Re: [TLS] AES-OCB in TLS [New Version Notification for draft-zauner-tls-aes-ocb-03.txt] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Jun 2015 12:30:36 -0000 --047d7b8737aef0700b051773fd88 Content-Type: text/plain; charset=UTF-8 On Mon, Jun 1, 2015 at 5:06 AM, Aaron Zauner wrote: > > * I'd also like to get rid of ECDSA ciphersuites alltogether, ideally > leaving a few real-world, high-performance ciphersuites to use > I don't understand this point: ECDSA cipher suites are the ones with the best performance at present. -Ekr > Thoughts and feedback apprechiated, diff, HTML et cetera can be accessed > via the quoted mail below. > > GitHub: https://github.com/azet/draft-zauner-tls-aes-ocb > > Thanks, > Aaron > > internet-drafts@ietf.org wrote: > > A new version of I-D, draft-zauner-tls-aes-ocb-03.txt > > has been successfully submitted by Aaron Zauner and posted to the > > IETF repository. > > > > Name: draft-zauner-tls-aes-ocb > > Revision: 03 > > Title: AES-OCB (Offset Codebook Mode) Ciphersuites for > Transport Layer Security (TLS) > > Document date: 2015-06-01 > > Group: Individual Submission > > Pages: 7 > > URL: > https://www.ietf.org/internet-drafts/draft-zauner-tls-aes-ocb-03.txt > > Status: > https://datatracker.ietf.org/doc/draft-zauner-tls-aes-ocb/ > > Htmlized: https://tools.ietf.org/html/draft-zauner-tls-aes-ocb-03 > > Diff: > https://www.ietf.org/rfcdiff?url2=draft-zauner-tls-aes-ocb-03 > > > > Abstract: > > This memo describes the use of the Advanced Encryption Standard (AES) > > in the Offset Codebook Mode (OCB) of operation within Transport Layer > > Security (TLS) and Datagram TLS (DTLS) to provide confidentiality and > > data origin authentication. The AES-OCB algorithm is highly > > parallelizable, provable secure and can be efficiently implemented in > > software and hardware providing high performance. Furthermore, use > > of AES-OCB in TLS is exempt from past IPR claims by various parties. > > > > > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > The IETF Secretariat > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --047d7b8737aef0700b051773fd88 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jun 1, 2015 at 5:06 AM, Aaron Zauner <azet@azet.org> wrote:<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> =C2=A0* I'd also like to get rid of ECDSA ciphersuites alltogether, ide= ally
=C2=A0 =C2=A0leaving a few real-world, high-performance ciphersuites to use=

I don't understand this point: ECD= SA cipher suites are the ones with the
best performance at presen= t.

-Ekr

=C2=A0
Thoughts and feedback apprechiated, diff, HTML et cetera can be accessed via the quoted mail below.

GitHub: https://github.com/azet/draft-zauner-tls-aes-ocb

Thanks,
Aaron

internet-drafts@ietf.org wr= ote:
> A new version of I-D, draft-zauner-tls-aes-ocb-03.txt
> has been successfully submitted by Aaron Zauner and posted to the
> IETF repository.
>
> Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-zauner-tls-aes-ocb
> Revision:=C2=A0 =C2=A0 =C2=A003
> Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 AES-OCB = (Offset Codebook Mode) Ciphersuites for Transport Layer Security (TLS)
> Document date:=C2=A0 =C2=A0 =C2=A0 =C2=A0 2015-06-01
> Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individu= al Submission
> Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 7
> URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = https://www.ietf.org/internet-drafts/draft-zauner-tls-aes-ocb-03.txt > Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatra= cker.ietf.org/doc/draft-zauner-tls-aes-ocb/
> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/= html/draft-zauner-tls-aes-ocb-03
> Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https= ://www.ietf.org/rfcdiff?url2=3Ddraft-zauner-tls-aes-ocb-03
>
> Abstract:
>=C2=A0 =C2=A0 This memo describes the use of the Advanced Encryption St= andard (AES)
>=C2=A0 =C2=A0 in the Offset Codebook Mode (OCB) of operation within Tra= nsport Layer
>=C2=A0 =C2=A0 Security (TLS) and Datagram TLS (DTLS) to provide confide= ntiality and
>=C2=A0 =C2=A0 data origin authentication.=C2=A0 The AES-OCB algorithm i= s highly
>=C2=A0 =C2=A0 parallelizable, provable secure and can be efficiently im= plemented in
>=C2=A0 =C2=A0 software and hardware providing high performance.=C2=A0 F= urthermore, use
>=C2=A0 =C2=A0 of AES-OCB in TLS is exempt from past IPR claims by vario= us parties.
>
>
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>


_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls


--047d7b8737aef0700b051773fd88-- From nobody Mon Jun 1 05:37: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 3C4111A90FE for ; Mon, 1 Jun 2015 05:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugkgYA5JrWzO for ; Mon, 1 Jun 2015 05:37:30 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.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 507321A90EC for ; Mon, 1 Jun 2015 05:37:22 -0700 (PDT) Received: by wicmx19 with SMTP id mx19so69504588wic.0 for ; Mon, 01 Jun 2015 05:37:21 -0700 (PDT) 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=wrcAYLyNpJ7VIZt3c+z+fNsrrN4wBT09XpI9x37xijw=; b=A02XjmvhouA+axTzhU3Zb9ON3H9KqEBKgNDl1rTkksQejQ8jYCGFRDhiB39nc3l5Ss Y7+H2PPLwglhPl6g9TImDffqPipzG3NGUV7ow3ESwFbhsE5TnnP07lOZHocLI0ZtLkyW sqmxOIjOaDMMnmMQiBf0oIqZXngeA5aQGo7LFmaAEJQxbxmiy0T6nf6+4WQmschOZ+Rz LuDiSnrEzW69jeAeJf0Rlp7HWlPlvKJSxY9FwwnA/wa8mFUQ3qUaMStt+h6BFg/OyLk2 /FTVhkqgNsJmjo+2nDQnfOCY88ll9pNr5a0mWvOOJmfa33w3hfkTnGg1XWNjKI+/OM8U UZow== X-Gm-Message-State: ALoCoQmTNOUO822oJBCnpsU7NyMpIYLU9zwM6KMM8+z7cO6u+zX4MrXQ1C+ykCJpBiXeXGUOrIoa X-Received: by 10.194.104.71 with SMTP id gc7mr39150750wjb.114.1433162241078; Mon, 01 Jun 2015 05:37:21 -0700 (PDT) Received: from [192.168.23.81] (chello212017113090.11.11.vie.surfer.at. [212.17.113.90]) by mx.google.com with ESMTPSA id ju2sm16489860wid.12.2015.06.01.05.37.18 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Jun 2015 05:37:19 -0700 (PDT) Message-ID: <556C51FC.807@azet.org> Date: Mon, 01 Jun 2015 14:37:16 +0200 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Eric Rescorla References: <556C4ACD.9040002@azet.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig874382EB8C9709A4A7CD3FF5" Archived-At: Cc: Phillip Rogaway , TLS Mailing List , Charanjit Jutla Subject: Re: [TLS] AES-OCB in TLS [New Version Notification for draft-zauner-tls-aes-ocb-03.txt] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Jun 2015 12:37:31 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig874382EB8C9709A4A7CD3FF5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Ekr, Eric Rescorla wrote: > On Mon, Jun 1, 2015 at 5:06 AM, Aaron Zauner > wrote: >=20 > * I'd also like to get rid of ECDSA ciphersuites alltogether, idea= lly > leaving a few real-world, high-performance ciphersuites to use >=20 >=20 > I don't understand this point: ECDSA cipher suites are the ones with th= e > best performance at present. >=20 Firstly, as far as I know it's also quite difficult to get ECDSA certificates in the wild. Has this changed significantly over the past couple of months? Second - there's a current draft on EdDSA, which I'd prefer over ECDSA, if somehow possible. I'm more about minimizing the list of cipher-suites this draft introduces than to point out that I dislike a particular signature schemes. Aaron --------------enig874382EB8C9709A4A7CD3FF5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVbFH8AAoJEOTbZJL9ubXVkSIP/0VZ/5JeOMlvxuzJw0k057fp PTsHOFoitw7ysI9ys7Ok7vFKN7+zyONX/OtTRATPVUkWvWOUM219RudAe6CSIsuy 3ddZAvjuPnZ5ELsjwUCiioHiicKalXlRe3TCuqVQ9FIbKoDieeAP7ZXYbNcX/xue 5MfOe6e+rYsS9lz9OMhK5fQNoyzczQ/zytLvL9hEK+84Hr/ZF7lcaR+QaZYDImQF +x9tnmqc0ou4kYcdDD10fsUQjFPYALPv/ddM1vE5v35x4eujCnphdzpWziETT7O2 j4ysXycoWIK4cCSxCxf7kYIyHUQt4k4fWNv2LqHPNM6B2aWiQ8FWyRNCnQWPGDlP QBHPUcAckC3/MFzdth2iukkZLsmGYY64ZFnoePGJLRt0axYjUrU98N1wav7GcKuG 22EgPOaYM3eScQJJCt7IxCMEpZGLdcOOP2AKjoiIVhf70Ps4zm7Ype7vxsl0sW0B qTV7kjauPNQKUdZ+Jalla+pyjmVO2PeyqxtkiiUlaYkt5zHdZmqbmzOxzFXPgSeN jqv0O3t58ZcDTfFkhQ8Lr4z44J75L42Veu3K4ixE+ZVk2c7N2du0iTTR87AMdDxj YltHk4CCIbp0Dut0x0JnP/UkWdwZBxBbR/Ms+ZyDxayGcBqoRycQ4OlI8AmlCpbz lccYKsn1g20/CB91zAU3 =S9zb -----END PGP SIGNATURE----- --------------enig874382EB8C9709A4A7CD3FF5-- From nobody Mon Jun 1 05:47: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 736361AC3DC for ; Mon, 1 Jun 2015 05:47:51 -0700 (PDT) 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 ZxczeS8Pry_I for ; Mon, 1 Jun 2015 05:47:50 -0700 (PDT) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) (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 D21E81A92F0 for ; Mon, 1 Jun 2015 05:47:49 -0700 (PDT) Received: by wgv5 with SMTP id 5so113311488wgv.1 for ; Mon, 01 Jun 2015 05:47:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=XujQzlPzzFTX8MS8ga7EdWJfJsyaeFh1QjehZjrzCgc=; b=K7vh5VlIpV9P8fuYIXRHOimrLlyfr+GpgCJKD+Ge7kbqlYC2sMOkKzaSpnezMKB/2P ktD/QIMqZvL63T7N9MZPXWwe0a6I1tMAfK7LfD46Tb/g258LoWOu+//d+MEHTvB4LDje WEuiTliafbvFmqPL1HKnplYUiHPqIGrizkklYdbpY2dON3KMxjsAS0qAvMfkryP/tY3n Wn67umnucwqs/aH4j/0eatLIsLOrKm1100a+07ttttkBUlm8KMsdSjaS17mzNBGrh3Xw 3itnxZm62Cahf3ey7Py5iD1xJULmtwTPFRjMb+0iaCdsfULIeOwiLt9TuB8cUrLNl45J nU8g== X-Gm-Message-State: ALoCoQn90JO1+p2TYRC91mCYyejzQIo8Ko7qFdcjCeqySdhD26Lzf7AChNDPWsFJ9C2W2db+EtlC X-Received: by 10.194.59.79 with SMTP id x15mr24186865wjq.81.1433162868567; Mon, 01 Jun 2015 05:47:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.225.14 with HTTP; Mon, 1 Jun 2015 05:47:08 -0700 (PDT) In-Reply-To: <556C51FC.807@azet.org> References: <556C4ACD.9040002@azet.org> <556C51FC.807@azet.org> From: Eric Rescorla Date: Mon, 1 Jun 2015 05:47:08 -0700 Message-ID: To: Aaron Zauner Content-Type: multipart/alternative; boundary=047d7b8737aeafbbe60517743b0b Archived-At: Cc: Phillip Rogaway , TLS Mailing List , Charanjit Jutla Subject: Re: [TLS] AES-OCB in TLS [New Version Notification for draft-zauner-tls-aes-ocb-03.txt] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Jun 2015 12:47:51 -0000 --047d7b8737aeafbbe60517743b0b Content-Type: text/plain; charset=UTF-8 On Mon, Jun 1, 2015 at 5:37 AM, Aaron Zauner wrote: > Hi Ekr, > > Eric Rescorla wrote: > > On Mon, Jun 1, 2015 at 5:06 AM, Aaron Zauner > > wrote: > > > > * I'd also like to get rid of ECDSA ciphersuites alltogether, > ideally > > leaving a few real-world, high-performance ciphersuites to use > > > > > > I don't understand this point: ECDSA cipher suites are the ones with the > > best performance at present. > > > > Firstly, as far as I know it's also quite difficult to get ECDSA > certificates in the wild. Has this changed significantly over the past > couple of months? They certainly do exist. For instance, I'm connected to Google with one now. I believe Let's Encrypt also intends to issue for ECDSA. > Second - there's a current draft on EdDSA, which I'd > prefer over ECDSA, if somehow possible. Well, the CFRG hasn't decided on next-gen signature schemes, so I expect that any standardization of EdDSA is going to take a while. Also, it seems at least possible that it will still use an ECDSA cipher suite name. -Ekr I'm more about minimizing the > list of cipher-suites this draft introduces than to point out that I > dislike a particular signature schemes. > > Aaron > > --047d7b8737aeafbbe60517743b0b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jun 1, 2015 at 5:37 AM, Aaron Zauner <azet@azet.org>= wrote:
Hi Ekr,

Eric Rescorla wrote:
> On Mon, Jun 1, 2015 at 5:06 AM, Aaron Zauner <azet@azet.org
> <mailto:az= et@azet.org>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0 * I'd also like to get rid of ECDSA ciphersuit= es alltogether, ideally
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaving a few real-world, high-performance = ciphersuites to use
>
>
> I don't understand this point: ECDSA cipher suites are the ones wi= th the
> best performance at present.
>

Firstly, as far as I know it's also quite difficult to get ECDSA=
certificates in the wild. Has this changed significantly over the past
couple of months?

They certainly do exist. = For instance, I'm connected to Google with one now.
I believe= Let's Encrypt also intends to issue for ECDSA.

=C2=A0
Second - there's a cu= rrent draft on EdDSA, which I'd
prefer over ECDSA, if somehow possible.

Wel= l, the CFRG hasn't decided on next-gen signature schemes, so I expect
that any standardization of EdDSA is going to take a while. Also, = it seems
at least possible that it will still use an ECDSA cipher= suite name.

-Ekr


I'm more about minimizing the
list of cipher-suites this draft introduces than to point out that I
dislike a particular signature schemes.

Aaron


--047d7b8737aeafbbe60517743b0b-- From nobody Mon Jun 1 05:53: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 9E3801AC529 for ; Mon, 1 Jun 2015 05:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 jdgzWdDhxV2E for ; Mon, 1 Jun 2015 05:53:05 -0700 (PDT) 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 C286F1ACD35 for ; Mon, 1 Jun 2015 05:53:04 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id 4C617900DD; Mon, 1 Jun 2015 15:53:02 +0300 (EEST) Date: Mon, 1 Jun 2015 15:53:02 +0300 From: Ilari Liusvaara To: Aaron Zauner Message-ID: <20150601125302.GA19269@LK-Perkele-VII> References: <556C4ACD.9040002@azet.org> <556C51FC.807@azet.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <556C51FC.807@azet.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: TLS Mailing List Subject: Re: [TLS] AES-OCB in TLS [New Version Notification for draft-zauner-tls-aes-ocb-03.txt] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Jun 2015 12:53:07 -0000 On Mon, Jun 01, 2015 at 02:37:16PM +0200, Aaron Zauner wrote: > Hi Ekr, > > Eric Rescorla wrote: > > On Mon, Jun 1, 2015 at 5:06 AM, Aaron Zauner > > wrote: > > > > * I'd also like to get rid of ECDSA ciphersuites alltogether, ideally > > leaving a few real-world, high-performance ciphersuites to use > > > > > > I don't understand this point: ECDSA cipher suites are the ones with the > > best performance at present. > > > > Firstly, as far as I know it's also quite difficult to get ECDSA > certificates in the wild. Has this changed significantly over the past > couple of months? Second - there's a current draft on EdDSA, which I'd > prefer over ECDSA, if somehow possible. I'm more about minimizing the > list of cipher-suites this draft introduces than to point out that I > dislike a particular signature schemes. Well, in TLS 1.2 (and editor's copy 1.3), one could maybe get away with just specifiying (EC)DHE_CERT ciphersuites, leaving certificate negotiation to extension. I think the current plan with EdDSA and related certficates are to reuse ECDSA codepoints, relying on extension (defined by RFC5246) to negotiate. With DH and ECDH codepoints, merging those is not possible in TLS 1.2. This is because DH would need parameters which don't exist for ECDH, and ECDH length field is insufficient for DH. Such merger could be possible for TLS 1.3, since DH has sufficient length field and does not require parameters not present for ECDH. -Ilari From nobody Mon Jun 1 05:54: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 1E28E1ACD32 for ; Mon, 1 Jun 2015 05:54:11 -0700 (PDT) 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 RQGJQTP03SnV for ; Mon, 1 Jun 2015 05:54:09 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5158C1ACD3A for ; Mon, 1 Jun 2015 05:54:09 -0700 (PDT) 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 (Postfix) with ESMTPS id F34F33679EC; Mon, 1 Jun 2015 12:54:08 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-110.brq.redhat.com [10.34.0.110]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t51Cs7oC007569 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 1 Jun 2015 08:54:08 -0400 From: Hubert Kario To: tls@ietf.org Date: Mon, 01 Jun 2015 14:54:06 +0200 Message-ID: <5878037.eTrqDl0Ll5@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.7 (Linux/3.19.7-200.fc21.x86_64; KDE/4.14.7; x86_64; ; ) In-Reply-To: <556C51FC.807@azet.org> References: <556C4ACD.9040002@azet.org> <556C51FC.807@azet.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3073290.43Ogfoc5Fu"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: Cc: Phillip Rogaway , Charanjit Jutla Subject: Re: [TLS] AES-OCB in TLS [New Version Notification for draft-zauner-tls-aes-ocb-03.txt] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Jun 2015 12:54:11 -0000 --nextPart3073290.43Ogfoc5Fu Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Monday 01 June 2015 14:37:16 Aaron Zauner wrote: > Hi Ekr, >=20 > Eric Rescorla wrote: > > On Mon, Jun 1, 2015 at 5:06 AM, Aaron Zauner >=20 > > > wrote: > > * I'd also like to get rid of ECDSA ciphersuites alltogether, = ideally > > =20 > > leaving a few real-world, high-performance ciphersuites to u= se > >=20 > > I don't understand this point: ECDSA cipher suites are the ones wit= h the > > best performance at present. >=20 > Firstly, as far as I know it's also quite difficult to get ECDSA > certificates in the wild. Has this changed significantly over the pas= t > couple of months?=20 yes, it has. If you ask specifically for them, you can get ECDSA certs = signed=20 by ECDSA roots. About 5% of servers in Alexa top 1 million use ECDSA ce= rts=20 trusted by Firefox. > Second - there's a current draft on EdDSA, which I'd > prefer over ECDSA, if somehow possible. I'm more about minimizing the= > list of cipher-suites this draft introduces than to point out that I > dislike a particular signature schemes. for now it looks like it will use ECDSA codepoints, it will just use si= gnature=20 algorithms extension to switch ECDSA to EdDSA. =2D-=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 --nextPart3073290.43Ogfoc5Fu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJVbFXuAAoJEJKo0bgB0vX1agwP/2dU7uPQwpeE9215gbDv9K9i Z9Ug9uCbpWoH5fGN9Ds22FVPXTp1pgR9TDX0eLkXSiuNU2DmRzZuDW1/9q/fQN6m GD19Uof+GdPCv1CQRTzdP3M+wLeQ8Kiiveo64scbmfo34EabgeelCAGfqCb6gSKG m0YXaAQgQ/sWDY4dC/DMWkxXG8jxXODPCWpJlUgI9ZeoPDJeN2OLivc30x1NBoK4 /ApF1Zc0sEJigzdG/SaZVlYsKqOtu6U87BfQas2N7XUpJIo1FPWUOWMbPcp6qiqQ rMcpAyrLxqv6R9Y9Mo+3TbshuiUODFReilerx4xdVLg2rQKfuIMmqKzgNy5NoDcN IVG2PkcGN//FNreTQLcYYb1ymewIlj3oZYK8Syh4d53x/GqGBLhqvL7IAoctkF2q 7pI3rC6RP9AvgXeyvFPxhQtOhL3YL/f8n1fh/cIbAt6eGvAjDuLMD7f4y5UnAo8J bmdY8sORvLUdN50RjpUwH8HL3CJqcY/+Ztzy7FlPvVnj5EVg4aaU4ZNsMuZ5bXVp /lIvbhDebnXvDFO83c5I3EAFzasqMqgbAGFmPwpp0LC/SuOeGtqIsUH6O0v0BUoF Ns/juZ8Z7qV1vUiwxciBlXV9vFr2mk+ZGsYO2b3gyTxzuaI5yHIYF5dDhA9Y25yK kgcJnzw62vWPxjpQt6U7 =hXIV -----END PGP SIGNATURE----- --nextPart3073290.43Ogfoc5Fu-- From nobody Mon Jun 1 06: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 2378A1ACD86 for ; Mon, 1 Jun 2015 06:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTq690tiZgSH for ; Mon, 1 Jun 2015 06:05:14 -0700 (PDT) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) (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 B46F21ACD84 for ; Mon, 1 Jun 2015 06:05:13 -0700 (PDT) Received: by wgez8 with SMTP id z8so113730210wge.0 for ; Mon, 01 Jun 2015 06:05:12 -0700 (PDT) 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=BCe13gMXgmS9NuUOkjFdMfGmDEsUkbhYQ9bsoqtd2Do=; b=AOHuKvQlSCcIOwzYnVD6TQrokEC8tMn/6uywPX4XFEysGLgSisQUUbef5UqF48R6CI OZWo3UJXI+FZb7ha4o+6OmWJ1BKaOqZM0yDhhnmQhSRPaTkLL9FEEQBUTrd5dRoN322P qLjWUQPFr4hzClQ6EAY5K+RjwvumNQSAju/zeJ120BJpvLJ22ptzNRTL8xA0NJwZrIZX w9Z3ylfgRj75lfpXbxkvV4quyK02cP9Xu+B1chdgAdUZGPomXDQDy0hbMTa+OQXBO+kP MDS4YmBgNPARcHalVI7rmDJ4NCrgb5jkWXUt5qx2+LzYLPT3vp3+A8cIAvymRtdFhqF4 mQCw== X-Gm-Message-State: ALoCoQnCXuQlWqLcqPy92IgoTQz19kzPhzV2WMtJQ1Fuv8UvOqmMtnuK+RzK2OkS4iLN3ZX+96L6 X-Received: by 10.180.89.234 with SMTP id br10mr20606860wib.86.1433163911445; Mon, 01 Jun 2015 06:05:11 -0700 (PDT) Received: from [192.168.23.81] (chello212017113090.11.11.vie.surfer.at. [212.17.113.90]) by mx.google.com with ESMTPSA id kc4sm21848431wjc.2.2015.06.01.06.05.09 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Jun 2015 06:05:10 -0700 (PDT) Message-ID: <556C5881.4080902@azet.org> Date: Mon, 01 Jun 2015 15:05:05 +0200 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Hubert Kario References: <556C4ACD.9040002@azet.org> <556C51FC.807@azet.org> <5878037.eTrqDl0Ll5@pintsize.usersys.redhat.com> In-Reply-To: <5878037.eTrqDl0Ll5@pintsize.usersys.redhat.com> X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig4DFC103E5AD18FF1E7067B40" Archived-At: Cc: Phillip Rogaway , tls@ietf.org, Charanjit Jutla Subject: Re: [TLS] AES-OCB in TLS [New Version Notification for draft-zauner-tls-aes-ocb-03.txt] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Jun 2015 13:05:20 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4DFC103E5AD18FF1E7067B40 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Thanks for all the fast replies. Ok. I won't touch ECDSA in my document for the time being. The PSK cipher-suites still bother me. I'm not sure I want to support them. While RFC6655 (CCM) specifies PSK cipher-suites, RFC5288 (GCM) does not. These are currently included in my draft because Nikos and Peter Gutmann suggested including them. Aaron --------------enig4DFC103E5AD18FF1E7067B40 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVbFiCAAoJEOTbZJL9ubXVi38P/A/zxKZiHnlYg+SaMfgaUjhS xK/ms4aAFfhgpEoDWQdntdkAI/b11sbwY9tshWveMLYZygAJBQ4o4zluBky0F+kR ZsQKP0atDScVgwxyvL+QeyoLDD7COcSrCQlFGh5zWfB+bsRxTluaZEh8w+D8UKBK QhSCsg/RKf4NtE1pFiHRn4/RFkSP/DgeyZ+S5NQ76XOiDaj5IeGcPgFTWIhglS2F CyRQJ7h4jbbKc+MifoBOzGH+QhvP4eI6TEiad0BFIz+zwNmIc7J3PnIpNRWwRmYs BSdg8tnWnSiWFH430U72OJloxwcw/rf1yF28fDslmC09UHDIDv0tREmpd9SG6Yrl Q2Sdn9TFuaKkXVdFO1LhxA1elXsfjhPKABM7igkXgsNMRnJdhpP/03ey2dzmkJJy rk4w4mxbarBRWzTQgkI0tzWTYm6DIWlCkLdjoWqDQI6QJSNRlcWTgeCbsi/k2QHo 8GwZBhW0ec1QeTFL8AHRoPsAwHOlHkvRDrEDfM0IKYvUUl7MRlh4I6fkRlp1IlSx +3fq2i0qfI/TMpASzNS+7mPE/KE2WBwFU437P1yuass9EKV9QH6D9u5/7NgqT88n PIIlX4pBKyriM36IZgoTTXChK1mFkG9WeWfeh7YyYUOm1SLR42hLu82OGMpxenvR d2E7hzJWxwtwpO9e/ejG =FCfm -----END PGP SIGNATURE----- --------------enig4DFC103E5AD18FF1E7067B40-- From nobody Mon Jun 1 09: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 72A361B2B96 for ; Mon, 1 Jun 2015 09:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwqb-RzDQCFk for ; Mon, 1 Jun 2015 09:05:17 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (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 B3C161B2CC0 for ; Mon, 1 Jun 2015 08:53:47 -0700 (PDT) Received: by ieclw1 with SMTP id lw1so17118347iec.3 for ; Mon, 01 Jun 2015 08:53:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=H5TB99ljP6WIA5GGJBI7Vfmg8Y6vWiMCfmxpm7THR/E=; b=mk6ASmA+FykEDw4O4Sm7QFekKUhCGIdTX+yjqDUeTKRi8GmTDQSXyF5VYRJ0Qrdrmz 4eMOuEzxFJfmXwDTEy1cltwJS2oUJEmMP0dSCHqo0lREmPBP5gYpKEBi8AwKYDCAh/oA IseMJqn/pglH5DSWT6ZjfQrhntFfPvbjyP+27CBn+iLBIAVfNQPiJpAOAsAMnlYQCzot 1NjqAwrUemE67nlq+elfWWC7S4dAyVtMtD5YEGjlsGbv7HYGnNE51kEQdRqJRDNuTmrh efiVGVCoHp51vfcf71sAZW5fjgNF7AiIR3qWlfDg2t9TvgDjg8HkP1xIdZIy+hWhgGSB gl+w== MIME-Version: 1.0 X-Received: by 10.42.176.8 with SMTP id bc8mr18949914icb.22.1433174027100; Mon, 01 Jun 2015 08:53:47 -0700 (PDT) Received: by 10.36.77.15 with HTTP; Mon, 1 Jun 2015 08:53:47 -0700 (PDT) In-Reply-To: <556C5881.4080902@azet.org> References: <556C4ACD.9040002@azet.org> <556C51FC.807@azet.org> <5878037.eTrqDl0Ll5@pintsize.usersys.redhat.com> <556C5881.4080902@azet.org> Date: Mon, 1 Jun 2015 11:53:47 -0400 Message-ID: From: Jeffrey Walton To: Aaron Zauner Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] AES-OCB in TLS [New Version Notification for draft-zauner-tls-aes-ocb-03.txt] 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: Mon, 01 Jun 2015 16:05:19 -0000 On Mon, Jun 1, 2015 at 9:05 AM, Aaron Zauner wrote: > ... > Ok. I won't touch ECDSA in my document for the time being. > > The PSK cipher-suites still bother me. I'm not sure I want to support > them. While RFC6655 (CCM) specifies PSK cipher-suites, RFC5288 (GCM) > does not. These are currently included in my draft because Nikos and > Peter Gutmann suggested including them. > What do you suggest for resource constrained devices? What are the remaining choices? When the device cannot do public key, they often use PSK. PSK also has two desirable properties: channel binding and mutual authentication, and most other cipher suites don't provide them. Jeff From nobody Mon Jun 1 09:12: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 DB5661B2C81 for ; Mon, 1 Jun 2015 09:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hYs9D2JXwANe for ; Mon, 1 Jun 2015 09:12:37 -0700 (PDT) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) (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 9CC091B2C61 for ; Mon, 1 Jun 2015 09:07:02 -0700 (PDT) Received: by wgv5 with SMTP id 5so118688456wgv.1 for ; Mon, 01 Jun 2015 09:07:01 -0700 (PDT) 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=Ww8h7Tm2h//S/RSn4RUuzlO46IatuTwjE/YLtCFThm8=; b=D/5MjTqvY7E7quWtgaySqdXcJGjuRJvm1gL5w88HxoUE5NI5gFQzSjiAa32sTzdHWv LR6aVwZOsyQMd1DXEs7ORzBZGMjmhIpKi7r1UoN0ufgVoO3U0RnbtJY7JARpgaQBbAHK IYsF4NiyuYakN2KFoqrOTVCtHZIE+cNtVMQddHj3/BDs++tjg8TFiVaPRVTTg19L0TGi 2RQOjc7veC34ket5NzY1yhZaz82pQJLr/dqsbRAcADQudFG3nWg/kOHFSFXwX/sh8tRm x9P+W4pEscAURlRubU+JftkDZnQLYC58Q+qVvPOkuJLyj8/GKCtPx+Kh/Ao5OjQg10QI boOQ== X-Gm-Message-State: ALoCoQk9DgMYpD0MtYQmu8QLBmWkYBeRK+tbiHvkiHa3HIuJDnpHl1q2LKxQqpDb+TevsMzu3qXc X-Received: by 10.180.90.73 with SMTP id bu9mr22268051wib.88.1433174821389; Mon, 01 Jun 2015 09:07:01 -0700 (PDT) Received: from [10.0.0.142] (chello080108032135.14.11.univie.teleweb.at. [80.108.32.135]) by mx.google.com with ESMTPSA id n1sm17341354wix.0.2015.06.01.09.06.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Jun 2015 09:07:00 -0700 (PDT) Message-ID: <556C8320.2010705@azet.org> Date: Mon, 01 Jun 2015 18:06:56 +0200 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: noloader@gmail.com References: <556C4ACD.9040002@azet.org> <556C51FC.807@azet.org> <5878037.eTrqDl0Ll5@pintsize.usersys.redhat.com> <556C5881.4080902@azet.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig44E65CF632907CF32CB41A1D" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] AES-OCB in TLS [New Version Notification for draft-zauner-tls-aes-ocb-03.txt] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Jun 2015 16:12:39 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig44E65CF632907CF32CB41A1D Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Jeffrey Walton wrote: > What do you suggest for resource constrained devices? What are the > remaining choices? There're none. > When the device cannot do public key, they often use PSK. >=20 > PSK also has two desirable properties: channel binding and mutual > authentication, and most other cipher suites don't provide them. >=20 I agree, but am unsure to what extent they are used in real life. I'm trying to reduce the number of cipher-suites that would have to be added to the IANA TLS parameter list; since PSK is unsupported with GCM cipher-suites it seems only logical to exclude them here as well. Because I regularly receive off-list mail that PSK is indeed wanted, I've not yet removed those cipher-suites. RFC3268 (CBC modes) also excludes TLS-PSK ciphersuites. There seems to be a seperate document that deals with TLS-PSK namely RFC5487 (defines GCM and CBC PSK cipher-suites). It might make sense to update this document in case OCB mode get's accepted by the TLS-WG instead. BTW: is TLS-SRP in use anywhere? Aaron --------------enig44E65CF632907CF32CB41A1D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVbIMhAAoJEOTbZJL9ubXVZMkQAO/61dFuDAL9tKo7XWTVL+m6 na7DeCRPX8gwv1aDX2H/wrhyzNtY1Bz4NEJYMMONPLCdsO52WS0KJH+T0ztNrazd fulUJZXStvZ1QfF0JhaEvfHcmvucNtjLe7FbHx61TX4m26X7oRZ41eLhCZEvNRVu G673rKn/OjM5qOJTT8DFLVAzcvZS4nAK1Q0epHcwCxL+8rZEUo1AVUHqFTpcf2LH m1xZlGIscu1p29a451+WDoE8dTzoaeL67RMoHwIhflnlChiyJbgAyudWSABr5TAk lnPAay1ut+jN9YzOw2urvxl7aYdefQGyMX0AOd3a0LlVroXYziiDqhX+t5CoqRsh 1Hi2/69AqnfsZaffXBbBnG/FDLBnD/7SDzVkhdMdLum/jI/rClDnM3CyA7LdZaf8 7R3R2K74l9/vL0KZRDJXfkXiK1Rpng2dSBzCBt3vubm3GiAmhi65R+JOwSL5NMUd JjtPdI7SqzHE7QlZeyEvqc6xPbHtZvMMimcx1nE8U1Y4jaSSjX3oYcqX6xT1bREZ L96Z7wOeOFNusf3xthUA426Pkujd4E+79d5ZsnFYz00C2Mb8SCcOPV1QXSDuvi9X 3i1uE1S1v7uTLfKxKWcRvsPzkUN8sAA/3pqPXjI4C1PqYxIA0wujJIJtKRdTB1ZI lEM6+TXRXT9SpYQuAvXA =u2wy -----END PGP SIGNATURE----- --------------enig44E65CF632907CF32CB41A1D-- From nobody Mon Jun 1 09:18: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 C97E91B2BF6 for ; Mon, 1 Jun 2015 09:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VvuG8BzCOJC9 for ; Mon, 1 Jun 2015 09:18:34 -0700 (PDT) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (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 3A7E21B2B31 for ; Mon, 1 Jun 2015 09:16:00 -0700 (PDT) Received: by pdbki1 with SMTP id ki1so111244976pdb.1 for ; Mon, 01 Jun 2015 09:15:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nhJp8+uYg42nbct9Wc/iCJRjtr6f1CFm0IEhnLEzfZo=; b=fub0wVDrZ3gm6sdSex6FE/YQU64q4ul7xp47CE2wfWnKiNFaixm5w9wyZkrUqGwSQr js+OCOb71eycunQcnWjx/hTOohZDuEhTfJq6ab1HJqwNnqdJtKcxPd4kk0r9qjxXxBBq QUlDUB22MSWMnVOZYGZASOz8yKXhjqH8x2uTr5mHshQRLoXJvAgaiPo+1QU+FWRq2Xe6 0FJkC9r+MlxVPEdzZjYm+PZl7fQgJXodDdzEBVlMEgtI/uJXqoV4hLQdxs+zZhVRIYA4 ue/MhhNLoNw7okUtrUHYzsgs1FFjKizyUZSWzec6AbFLPxKVKIONAtxFZTg+AIPrtHj9 Dplw== MIME-Version: 1.0 X-Received: by 10.66.252.227 with SMTP id zv3mr42710145pac.154.1433175359920; Mon, 01 Jun 2015 09:15:59 -0700 (PDT) Received: by 10.70.66.5 with HTTP; Mon, 1 Jun 2015 09:15:59 -0700 (PDT) In-Reply-To: <556C8320.2010705@azet.org> References: <556C4ACD.9040002@azet.org> <556C51FC.807@azet.org> <5878037.eTrqDl0Ll5@pintsize.usersys.redhat.com> <556C5881.4080902@azet.org> <556C8320.2010705@azet.org> Date: Mon, 1 Jun 2015 09:15:59 -0700 Message-ID: From: Peter Bowen To: Aaron Zauner Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] AES-OCB in TLS [New Version Notification for draft-zauner-tls-aes-ocb-03.txt] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Jun 2015 16:18:36 -0000 On Mon, Jun 1, 2015 at 9:06 AM, Aaron Zauner wrote: > I agree, but am unsure to what extent they are used in real life. I'm > trying to reduce the number of cipher-suites that would have to be added > to the IANA TLS parameter list; since PSK is unsupported with GCM > cipher-suites it seems only logical to exclude them here as well. Some TLS implementations (notably BoringSSL) have ended up assigning non-standard ciphersuites ECDHE+PSK+AES-GCM for this very reason. I think the lack of this combination is more of an oversight than anything. Thanks, Peter From nobody Mon Jun 1 09:24: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 9780F1B2C00 for ; Mon, 1 Jun 2015 09:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTWHYAFlHyAJ for ; Mon, 1 Jun 2015 09:23:56 -0700 (PDT) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.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 EBD6E1A015F for ; Mon, 1 Jun 2015 09:23:28 -0700 (PDT) Received: by wgme6 with SMTP id e6so119026774wgm.2 for ; Mon, 01 Jun 2015 09:23:27 -0700 (PDT) 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=a7Gpk4TqqnVF00ddWnFuDz39PISwx0lC0KVMDjez1Gs=; b=UdMrxv4cEX6d7QtWSDvEwMrhQYKXTzpA+/D/uTQ37YYqgFIVk1TgoBsN3ItLUctlRw nMGGUqB4NYNgN1O9LLj8vADaIq8NumXafdSmc7rTu5qvluSzC/Sf0achHcZ8s6lj1UNJ b9gfulLx5/4dMmaU31bZiCuJmblcHFdnwsbUXPs0QIqFPMsRYWyQcVfHbuPkbxSI7X+y n44tK/o6uA0R0QCQzNINZ4Nx4x3PjWz6t4FMC72lqfSwDF4TQazLpwMen3b069rJdoPG 04JMq+uuRI89TgOo9d4N4JNnYQUSL+G2EB8d2TCmYcW45f5Cs4RGMHz3nTpHzulAaYT0 hwWQ== X-Gm-Message-State: ALoCoQlPAOE4vxRxPMy/gU8iEtDJ0b7TJf1U6yP4a6SNp3p28YnvcJX5NQ+cNNvAl46ESZNMOSN/ X-Received: by 10.180.211.196 with SMTP id ne4mr11178719wic.23.1433175807716; Mon, 01 Jun 2015 09:23:27 -0700 (PDT) Received: from [10.0.0.142] (chello080108032135.14.11.univie.teleweb.at. [80.108.32.135]) by mx.google.com with ESMTPSA id k2sm17396548wix.4.2015.06.01.09.23.25 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Jun 2015 09:23:26 -0700 (PDT) Message-ID: <556C86FA.3000901@azet.org> Date: Mon, 01 Jun 2015 18:23:22 +0200 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Peter Bowen References: <556C4ACD.9040002@azet.org> <556C51FC.807@azet.org> <5878037.eTrqDl0Ll5@pintsize.usersys.redhat.com> <556C5881.4080902@azet.org> <556C8320.2010705@azet.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig2CF0548FCBE49F65B449E3B8" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] AES-OCB in TLS [New Version Notification for draft-zauner-tls-aes-ocb-03.txt] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Jun 2015 16:23:57 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2CF0548FCBE49F65B449E3B8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Peter Bowen wrote: > On Mon, Jun 1, 2015 at 9:06 AM, Aaron Zauner wrote: >> I agree, but am unsure to what extent they are used in real life. I'm >> trying to reduce the number of cipher-suites that would have to be add= ed >> to the IANA TLS parameter list; since PSK is unsupported with GCM >> cipher-suites it seems only logical to exclude them here as well. >=20 > Some TLS implementations (notably BoringSSL) have ended up assigning > non-standard ciphersuites ECDHE+PSK+AES-GCM for this very reason. I > think the lack of this combination is more of an oversight than > anything. >=20 Unsure if RFC5478 got introduced after the fact, but this document seems to be the one defining those cipher-suites. In addition it defines PSK cipher-suites in CBC-mode using SHA256+. https://tools.ietf.org/html/rfc5487 This is all quite confusing and spread over a lot of different documents. PSK in CBC-mode (with < SHA256) for example is a different document (RFC4279). I'll leave it up to long-time TLS-WG members to decide where these PSK cipher-suites /would/ fit best. I'm not sure that this document is the right place -- but that's only because, in the past, PSK cipher-suite were dealt with exclusively in separate documents as it seems. Aaron --------------enig2CF0548FCBE49F65B449E3B8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVbIb6AAoJEOTbZJL9ubXVIuAP/0G3J+Czt0zDyCI3n1vELC12 L5Uf+aNLtu8uZYKoETowROLPG6EGhrWvlDdHCm67tZPkCrWnpW9Ejtn4DHJWrKL5 jD0cSRPH+pkKK6fdDLWPX1BHPHQQ1UXFi5RUoLOshUrBlgIOCF5+XD0Gjbw+2Ykz W8/5/XmB1CEJ92w11qAgFsas5E7iyn/MHVZb+fL7ws4VAUs6DhUqBtk3XtYLWQxo tFZ1pY2TzLBCLUT1HdWzrkkCQdf0qINUgP5uE+k/DgTGwo9MFpzwQC9AcEyBT4OV hcm+6aqzFVl0rUjuy/4PmX67JHOrS5PLJJcXbMTwlVTnets73+E6qHDaRst5LNmU 9iKK8agulbXtxpmbMBbA4N+jeIWNtJTX0Yo6CdxObSMLN0SBkiqfTNB52AhDXdGj qeKFzAkEW/k6xGDPSdAOsaOKM4hMF+JjJSDMdIb/AbsR3wTNIgRO9sHOTfU5kuLE 2SoEvoktyLiJO66X+28A8Hr/2hI/KrvRVYD0NK9qjHI0HpGb+jTaRoJA11Ycpl+H ILqkYK3NfbcNf+iNhjeSGcLA8KtjLu35tROgImtMl404ZyWSad4+yo3w6cR6S3li VHD4N9F77DgsIByqrWnnUVxWTUAYJsSNRz/4PK8S7SayGgDRQfB0yUurLEpf7z/M ujUNASP0a5buUVjsCeat =AwD7 -----END PGP SIGNATURE----- --------------enig2CF0548FCBE49F65B449E3B8-- From nobody Mon Jun 1 09:30: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 8F1BA1B2CE3 for ; Mon, 1 Jun 2015 09:30:04 -0700 (PDT) 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 Aw2udW0kvFfK for ; Mon, 1 Jun 2015 09:30:01 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 69A521B2CE2 for ; Mon, 1 Jun 2015 09:30:01 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id C3AB59A404B; Mon, 1 Jun 2015 12:29:50 -0400 (EDT) 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 9U8Qoe8UFaia; Mon, 1 Jun 2015 12:28:30 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 26DA89A404C; Mon, 1 Jun 2015 12:29:30 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <20150601125302.GA19269@LK-Perkele-VII> Date: Mon, 1 Jun 2015 12:29:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <556C4ACD.9040002@azet.org> <556C51FC.807@azet.org> <20150601125302.GA19269@LK-Perkele-VII> To: Ilari Liusvaara X-Mailer: Apple Mail (2.1085) Archived-At: Cc: TLS Mailing List Subject: Re: [TLS] AES-OCB in TLS [New Version Notification for draft-zauner-tls-aes-ocb-03.txt] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Jun 2015 16:30:04 -0000 Ilari: > I think the current plan with EdDSA and related certficates are to = reuse > ECDSA codepoints, relying on extension (defined by RFC5246) to = negotiate. When we were doing to work for RSA PKCS #1 v1.5, OAEP, and PSS, it was = unclear whether using the same key pair with all of these schemes would = lead to trouble. For this reason, the certificate can allow the key = pair to be used for just on or all of them. The same question needs to be asked here. I hope a more definitive = answer becomes available this time. Russ From nobody Mon Jun 1 09:30: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 D835A1B2CB6 for ; Mon, 1 Jun 2015 09:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_52=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffClobf_dB9E for ; Mon, 1 Jun 2015 09:30:52 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001: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 97C131B2CC8 for ; Mon, 1 Jun 2015 09:30:50 -0700 (PDT) Received: by iesa3 with SMTP id a3so113283546ies.2 for ; Mon, 01 Jun 2015 09:30:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=lvn8OAFzIjZ+1G3+6aVZS1ekBgQbNsBfqZuvmfus2Qk=; b=LOLVRJr7xDOLx6OLrocBE35QzgOSPkvPjt3S0O9biFXhoSyBY2gGjkkzO++bUTLydO yrgGBqq6UURbwrUvv9ZplSqn9QERtpRmQzzX4orP0cN5NqSPAmgCR2Dlu3G5d4N7w8qi eaWScRf6LrvYHa01TN8Gc6wm/CBJeG99c/a0qn9tanSnkTlB9FZ73ffTaXqZfxrqsiJQ nUZKmVjsq+lRs673UDHaaW/isvzw/H5PapCuTMJVdfCOFeLe6nTNt2NVyljgdfSXXXD9 I2v7eO2GBrdBETbCSwaGjkeymeKl0ujY6eVbLTDjKnfaBI+hIZyw2CmFgf8yvnN6aIrL kdRA== MIME-Version: 1.0 X-Received: by 10.42.176.8 with SMTP id bc8mr19150868icb.22.1433176250048; Mon, 01 Jun 2015 09:30:50 -0700 (PDT) Received: by 10.36.77.15 with HTTP; Mon, 1 Jun 2015 09:30:49 -0700 (PDT) In-Reply-To: <556C8320.2010705@azet.org> References: <556C4ACD.9040002@azet.org> <556C51FC.807@azet.org> <5878037.eTrqDl0Ll5@pintsize.usersys.redhat.com> <556C5881.4080902@azet.org> <556C8320.2010705@azet.org> Date: Mon, 1 Jun 2015 12:30:49 -0400 Message-ID: From: Jeffrey Walton To: Aaron Zauner Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] AES-OCB in TLS [New Version Notification for draft-zauner-tls-aes-ocb-03.txt] 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: Mon, 01 Jun 2015 16:30:54 -0000 On Mon, Jun 1, 2015 at 12:06 PM, Aaron Zauner wrote: > Hi, > > Jeffrey Walton wrote: >> What do you suggest for resource constrained devices? What are the >> remaining choices? > > There're none. > >> When the device cannot do public key, they often use PSK. >> >> PSK also has two desirable properties: channel binding and mutual >> authentication, and most other cipher suites don't provide them. >> > > I agree, but am unsure to what extent they are used in real life. I'm > trying to reduce the number of cipher-suites that would have to be added > to the IANA TLS parameter list; since PSK is unsupported with GCM > cipher-suites it seems only logical to exclude them here as well. > Because I regularly receive off-list mail that PSK is indeed wanted, > I've not yet removed those cipher-suites. I know hoteliers are working with lock vendors on the next generation of locks. These are the online, no-mag-and-stripe keys and locks. I imagine PSK is going to be one of their expected choices due to constraints. Folks like Dr. Gutmann have use cases I am not familiar with. (or have not yet suffered). > RFC3268 (CBC modes) also excludes TLS-PSK ciphersuites. There seems to > be a seperate document that deals with TLS-PSK namely RFC5487 (defines > GCM and CBC PSK cipher-suites). It might make sense to update this > document in case OCB mode get's accepted by the TLS-WG instead. > > BTW: is TLS-SRP in use anywhere? I believe so. It looks like World of Warcraft/Blizzard uses them (http://arstechnica.com/security/2012/08/hacked-blizzard-passwords-not-hard-to-crack/). I also believe Cupid Media was using them (https://news.ycombinator.com/item?id=6767152). If PSK is going to be yanked, then there should probably be an non-public-key PAKE alternative. Jeff From nobody Mon Jun 1 10:07: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 1FA1D1B2CBB for ; Mon, 1 Jun 2015 10:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lO7v5KcSRgPZ for ; Mon, 1 Jun 2015 10:07:42 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (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 9E23C1B2CCE for ; Mon, 1 Jun 2015 10:07:40 -0700 (PDT) Received: by wizo1 with SMTP id o1so113523195wiz.1 for ; Mon, 01 Jun 2015 10:07:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=8ZSeerlgnu3NYSJ0eY5uMZWDN4+LzeeR/Ax0FQCKoro=; b=MHy01xqW7Tkxb7yNYAu6JGK9xMDAS1rGHefseRHJP8OHpPNMDx5EY/lW1ajICdrh8/ hJU/3RjtJlJAH5AcRoF3cNnOm+I0tYCWhJVP0nzYIYeVhy+ta0GgAX2LC/pI+NB3xsKq qGBHp/CrRmWnGWmvWdF3Yd/UP3a304jZzC2KCEFz61AAgygEmGgn1hT0ay5FTnlSezrp GKMLqVRH3SDCksDs6scoG7nONd8fQGeu9EA1lEpbvPVLlMzsESc5aPz9MD1lauWVpKTl zz4BsqR3JK/aUJA1Y5rDoTHinalzu52PsDc9atDkvEebGMNXlDFeSe+l1R9f4PmchPSz d7lA== X-Received: by 10.180.72.198 with SMTP id f6mr22253489wiv.21.1433178459440; Mon, 01 Jun 2015 10:07:39 -0700 (PDT) Received: from [10.0.0.5] (bzq-79-181-148-147.red.bezeqint.net. [79.181.148.147]) by mx.google.com with ESMTPSA id b7sm9567879wjx.47.2015.06.01.10.07.37 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Jun 2015 10:07:37 -0700 (PDT) Message-ID: <556C9157.4030409@gmail.com> Date: Mon, 01 Jun 2015 20:07:35 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: noloader@gmail.com, Aaron Zauner References: <556C4ACD.9040002@azet.org> <556C51FC.807@azet.org> <5878037.eTrqDl0Ll5@pintsize.usersys.redhat.com> <556C5881.4080902@azet.org> <556C8320.2010705@azet.org> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] AES-OCB in TLS [New Version Notification for draft-zauner-tls-aes-ocb-03.txt] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Jun 2015 17:07:44 -0000 On 06/01/2015 07:30 PM, Jeffrey Walton wrote: > > If PSK is going to be yanked, then there should probably be an > non-public-key PAKE alternative. > > Jeff > Hi Jeff, PAKE means password-authenticated key exchange, and TLS-PSK is not suitable for use with (short, memorable) passwords. See https://tools.ietf.org/html/rfc4279#section-7.2 TLS-SRP is the right tool for that. It is public key based but does not require the whole PKI code bloat, so may be a good fit for resource-constrained devices. Thanks, Yaron From nobody Mon Jun 1 10:22: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 36E331B2F53 for ; Mon, 1 Jun 2015 10:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3uNKiYygJ2NX for ; Mon, 1 Jun 2015 10:22:04 -0700 (PDT) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001: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 D7DA31B2A6E for ; Mon, 1 Jun 2015 10:22:03 -0700 (PDT) Received: by igbhj9 with SMTP id hj9so66878380igb.1 for ; Mon, 01 Jun 2015 10:22:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=hTKreCaRtNzWhSWVfTXnJ3oIC8+BYQSsiX7yTPy2jOA=; b=JsSkcmSuyg/9fR6T+96pFjvG0duAldv1Ce3QeqYnMWDMLG4naRNqaQ0VT9g9IOjmOa lyk5YbcqRVGR+2M/MW6GtwpFbVNU21uvdHmun7r+T9Xqr5ZFlP5IRjW7Ebp1ZpCGy3Pd 6RQbadnwRrjq2ER9+6HgCwLrmlKt+EnRmqw8poTWJu3A54ic9KAn5fUnDTf6pJHIp9rM lKR76xOo1aIJkLPy0VK/RBe9QtywOPydYGd/oSZouT60jgJFIMq6jZYEU+hSSO8XVUqB 75bE5dlL/B2dy8svDD0UsxB4N2zvoH2yk7ZvGQd87Cxo/E0uZwhpcaR2gIvCopE3uJZb vhbQ== MIME-Version: 1.0 X-Received: by 10.50.30.105 with SMTP id r9mr15063331igh.11.1433179323365; Mon, 01 Jun 2015 10:22:03 -0700 (PDT) Received: by 10.36.77.15 with HTTP; Mon, 1 Jun 2015 10:22:03 -0700 (PDT) In-Reply-To: <556C9157.4030409@gmail.com> References: <556C4ACD.9040002@azet.org> <556C51FC.807@azet.org> <5878037.eTrqDl0Ll5@pintsize.usersys.redhat.com> <556C5881.4080902@azet.org> <556C8320.2010705@azet.org> <556C9157.4030409@gmail.com> Date: Mon, 1 Jun 2015 13:22:03 -0400 Message-ID: From: Jeffrey Walton To: Yaron Sheffer Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] AES-OCB in TLS [New Version Notification for draft-zauner-tls-aes-ocb-03.txt] 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: Mon, 01 Jun 2015 17:22:05 -0000 On Mon, Jun 1, 2015 at 1:07 PM, Yaron Sheffer wrote: > On 06/01/2015 07:30 PM, Jeffrey Walton wrote: >> >> >> If PSK is going to be yanked, then there should probably be an >> non-public-key PAKE alternative. >> > PAKE means password-authenticated key exchange, and TLS-PSK is not suitable > for use with (short, memorable) passwords. See > https://tools.ietf.org/html/rfc4279#section-7.2 > > TLS-SRP is the right tool for that. It is public key based but does not > require the whole PKI code bloat, so may be a good fit for > resource-constrained devices. > Indeed, thanks. Sorry about that. Jeff From nobody Mon Jun 1 10:28: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 526751B2F70 for ; Mon, 1 Jun 2015 10:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHz6Brb1gFRg for ; Mon, 1 Jun 2015 10:28:49 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id DD33F1B2F6C for ; Mon, 1 Jun 2015 10:28:48 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 10322F984; Mon, 1 Jun 2015 13:28:44 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 052BC1FF76; Mon, 1 Jun 2015 13:28:23 -0400 (EDT) From: Daniel Kahn Gillmor To: Aaron Zauner , Eric Rescorla In-Reply-To: <556C51FC.807@azet.org> References: <556C4ACD.9040002@azet.org> <556C51FC.807@azet.org> User-Agent: Notmuch/0.20 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Mon, 01 Jun 2015 13:28:22 -0400 Message-ID: <87pp5fe3t5.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: Phillip Rogaway , TLS Mailing List , Charanjit Jutla Subject: Re: [TLS] AES-OCB in TLS [New Version Notification for draft-zauner-tls-aes-ocb-03.txt] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Jun 2015 17:28:50 -0000 On Mon 2015-06-01 08:37:16 -0400, Aaron Zauner wrote: > Firstly, as far as I know it's also quite difficult to get ECDSA > certificates in the wild. Has this changed significantly over the past > couple of months? I've heard this claim in the past, but i'm not sure what it is based on. AFAICT, there are several public CAs who are happy to issue ECDSA certificates if you ask them for them. In November 2014, i managed to get one from Comodo (or a Comodo reseller, i can't keep all the "imprints" and "branding" straight) and it took about 20 minutes from start to finish. Can you describe how you have tried to get an ECDSA cert, and how those attempts failed? --dkg From nobody Mon Jun 1 10:48: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 4450F1B2FEC for ; Mon, 1 Jun 2015 10:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2wTEwR3dc1O for ; Mon, 1 Jun 2015 10:48:46 -0700 (PDT) Received: from mail-vn0-f48.google.com (mail-vn0-f48.google.com [209.85.216.48]) (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 5F3511B2FD3 for ; Mon, 1 Jun 2015 10:48:38 -0700 (PDT) Received: by vnbg129 with SMTP id g129so17122642vnb.11 for ; Mon, 01 Jun 2015 10:48:37 -0700 (PDT) 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 :content-transfer-encoding; bh=pJI7h/6Rs2PiI3d80gxmYOkXzJiJ1KEz658VoAdRKgA=; b=ipwUyDak6kA4U0nfR2gWxj+oNxEwSyqUlTzw+0aNndYL5aZf2kbuZKNFC8in5K9zC6 0X6rc8f/PAyDk+02tFATfnCK2MrdNlrA/2+AZTqPSdA/x4LvIYaHvDjnDS6Dlia/D1El hL6lTN9jI9tXMK6NDGNZw1ITmpPmqiubqaTb9zJ+KNAIoOieH8qOQLorZC2bYy3SQ9HK 9hLdcXdFkN19OnlG2fxIQdUAicnH+Ws+TS29im9f/IzOqG2t5CCaFglvOxvuCRdHlDfv jCKkI46lo2QHi+Z2clkPtFn6KEllim3HpIEWld/EBU8f1MVT32w8QcVXwu+glwgSE/Xn xMKA== X-Gm-Message-State: ALoCoQlme2ntDZ/yQyWGAlkfEfjEl25F4QmRId1l48mJOqxoTgwZlz7rimr5qM8N4cInZN9nX2Xz X-Received: by 10.52.75.170 with SMTP id d10mr30032063vdw.49.1433180917325; Mon, 01 Jun 2015 10:48:37 -0700 (PDT) Received: from ?IPv6:2601:a:2a00:84:6116:7309:4731:ca15? ([2601:a:2a00:84:6116:7309:4731:ca15]) by mx.google.com with ESMTPSA id de3sm22419766vdc.17.2015.06.01.10.48.36 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Jun 2015 10:48:36 -0700 (PDT) Message-ID: <556C9AF4.7030607@nthpermutation.com> Date: Mon, 01 Jun 2015 13:48:36 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: tls@ietf.org References: <556C4ACD.9040002@azet.org> <556C51FC.807@azet.org> <20150601125302.GA19269@LK-Perkele-VII> In-Reply-To: <20150601125302.GA19269@LK-Perkele-VII> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [TLS] EDDSA/Curve25519 identifiers: Was Re: AES-OCB 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: Mon, 01 Jun 2015 17:48:50 -0000 On 6/1/2015 8:53 AM, Ilari Liusvaara wrote: > I think the current plan with EdDSA and related certficates are to reuse > ECDSA codepoints, relying on extension (defined by RFC5246) to negotiate. > > I may be misreading this and all you're talking about are code points for TLS, but in case you're talking about the more specific issue of reusing the current SubjectPublicKeyInfo definitions of id-ecPublicKey for certificates containing EdDSA public keys: RFC 5480 defines the format of an EC public key (as identified by 1.2.840.10045.2.1 and for that matter by 1.3.132.1.12 and 1.3.123.1.13). Note specifically the second bullet on the format of the ECPoint octet string. > 2.2. Subject Public Key > > The subjectPublicKey from SubjectPublicKeyInfo is the ECC public key. > ECC public keys have the following syntax: > > ECPoint ::= OCTET STRING > > Implementations of Elliptic Curve Cryptography according to this > document MUST support the uncompressed form and MAY support the > compressed form of the ECC public key. The hybrid form of the ECC > public key from [X9.62] MUST NOT be used. As specified in [SEC1]: > > o The elliptic curve public key (a value of type ECPoint that is > an OCTET STRING) is mapped to a subjectPublicKey (a value of > type BIT STRING) as follows: the most significant bit of the > OCTET STRING value becomes the most significant bit of the BIT > STRING value, and so on; the least significant bit of the OCTET > STRING becomes the least significant bit of the BIT STRING. > Conversion routines are found in Sections 2.3.1 and 2.3.2 of > [SEC1]. > > o The first octet of the OCTET STRING indicates whether the key is > compressed or uncompressed. The uncompressed form is indicated > by 0x04 and the compressed form is indicated by either 0x02 or > 0x03 (see 2.3.3 in [SEC1]). The public key MUST be rejected if > any other value is included in the first octet. This RFC mirrors equivalent language in both X9.62/63 and the SecG stuff (and for that matter NIST). So, don't try and overload the current meaning of id-ecPublicKey - you'll break a *lot* of things. And we (the IETF that is) don't actually have change control over what that OID means. Instead, get a new allocation and write a document that looks like RFC5480 for the ED and Curve public keys. You want certificate representations for *both*. Later, Mike From nobody Mon Jun 1 11: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 3A3A01B30E8 for ; Mon, 1 Jun 2015 11:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.955 X-Spam-Level: ** X-Spam-Status: No, score=2.955 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.982, 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 n_YCeeKqZBXD for ; Mon, 1 Jun 2015 11:33:47 -0700 (PDT) Received: from aspartame.shiftleft.org (199-116-74-168-v301.PUBLIC.monkeybrains.net [199.116.74.168]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF46A1B30D3 for ; Mon, 1 Jun 2015 11:33:43 -0700 (PDT) Received: from [172.20.10.9] (unknown [166.170.39.238]) by aspartame.shiftleft.org (Postfix) with ESMTPSA id 89908F211E; Mon, 1 Jun 2015 11:31:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shiftleft.org; s=sldo; t=1433183523; bh=Xk1kfa8M/IYOZ9h0Zx+p/pE1gPFwqX3+YCBp4NOhcCA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=DfxJTWSMZjmUhuFmHD1NlVCmQhVnHFOSQ24jG59ndyGL6NsiHYXGyS5RklgBPg/xI ZF0ky9FxZiIVOUFbGjizv220ERAGgXD4wbyAIyXEQijl29A7occkBEZZo5dEcobqs5 qBPaAnGU88wD47cNcuzzHd6NaXYJ9S5FpUN5qNQ8= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2100\)) From: Michael Hamburg In-Reply-To: <87pp5fe3t5.fsf@alice.fifthhorseman.net> Date: Mon, 1 Jun 2015 11:33:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <556C4ACD.9040002@azet.org> <556C51FC.807@azet.org> <87pp5fe3t5.fsf@alice.fifthhorseman.net> To: Daniel Kahn Gillmor X-Mailer: Apple Mail (2.2100) Archived-At: Cc: Phillip Rogaway , TLS Mailing List , Charanjit Jutla Subject: Re: [TLS] AES-OCB in TLS [New Version Notification for draft-zauner-tls-aes-ocb-03.txt] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Jun 2015 18:33:48 -0000 > On Jun 1, 2015, at 10:28 AM, Daniel Kahn Gillmor = wrote: >=20 > On Mon 2015-06-01 08:37:16 -0400, Aaron Zauner wrote: >> Firstly, as far as I know it's also quite difficult to get ECDSA >> certificates in the wild. Has this changed significantly over the = past >> couple of months? >=20 > I've heard this claim in the past, but i'm not sure what it is based = on. > AFAICT, there are several public CAs who are happy to issue ECDSA > certificates if you ask them for them. >=20 > In November 2014, i managed to get one from Comodo (or a Comodo > reseller, i can't keep all the "imprints" and "branding" straight) and > it took about 20 minutes from start to finish. >=20 > Can you describe how you have tried to get an ECDSA cert, and how = those > attempts failed? >=20 > --dkg I tried to get one from Comodo about a year ago. It wasn=E2=80=99t = advertised on their website but I asked one of their tech support folks. = They said that it was an experimental feature for business customers = only, and would cost me something like $600. I don=E2=80=99t remember = if that was a 1-year or 3-year cert. I looked at Verisign=E2=80=99s catalog as well, and it was labeled as an = enterprise feature with an even higher price tag. Low thousands I = think. I asked the guys at BaySec and they said that this was the shape = of the market at that time. I also looked at StartSSL. They are free, but only offer RSA certs. I = mostly wanted ECDSA for performance on a super slow home server, and I = figured $600 in hardware upgrades would go a lot further than $600 in = certs. Anyway you can get ECDSA certs relatively easily, but not cheaply; or at = least, that=E2=80=99s how it was a year ago. =E2=80=94 Mike= From nobody Mon Jun 1 12:13: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 0A4AC1B3233 for ; Mon, 1 Jun 2015 12:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PlTJhsQCk_TY for ; Mon, 1 Jun 2015 12:13:28 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5961B3231 for ; Mon, 1 Jun 2015 12:13:28 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 91A07F984; Mon, 1 Jun 2015 15:13:24 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 7CFEB1FF76; Mon, 1 Jun 2015 15:13:02 -0400 (EDT) From: Daniel Kahn Gillmor To: Michael Hamburg In-Reply-To: References: <556C4ACD.9040002@azet.org> <556C51FC.807@azet.org> <87pp5fe3t5.fsf@alice.fifthhorseman.net> User-Agent: Notmuch/0.20 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Mon, 01 Jun 2015 15:13:02 -0400 Message-ID: <87zj4jcke9.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Phillip Rogaway , TLS Mailing List , Charanjit Jutla Subject: Re: [TLS] AES-OCB in TLS [New Version Notification for draft-zauner-tls-aes-ocb-03.txt] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Jun 2015 19:13:30 -0000 On Mon 2015-06-01 14:33:16 -0400, Michael Hamburg wrote: > I tried to get one from Comodo about a year ago. It wasn’t advertised > on their website but I asked one of their tech support folks. They > said that it was an experimental feature for business customers only, > and would cost me something like $600. I don’t remember if that was a > 1-year or 3-year cert. I just went back through my notes: in November 2014, i used a small (~$5?) credit i had with https://ssls.com/ to get a PositiveSSL Comodo cert with ECC. I couldn't figure out how to submit the ECC cert through the https://ssls.com/ web interface, so i opened their "live support" chat, and got this suggestion: >>> Unfortunately our system cannot parse ECDSA public keys. As an >>> option you can purchase the cert here and you would need to submit a >>> ticket to us for the manual cert activation. >>> To submit a ticket, please follow this link: >>> https://support.cheapssl.com/index.php?/cheapssl/Tickets/Submit >>> Please provide the cert or order ID, the request and approver and >>> admin contacts in the ticket I did that, and the confirmation e-mail came through about a half-hour later. > Anyway you can get ECDSA certs relatively easily, but not cheaply; or > at least, that’s how it was a year ago. I found it was quick and cheap, but the UI/UX was not as streamlined as I wanted it to be for a DV cert (i had to nag two humans, via chat and the ticket system to make it happen, but it did happen promptly). ymmv, of course, --dkg From nobody Mon Jun 1 13:12: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 0B5361B3379 for ; Mon, 1 Jun 2015 13:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C45Y9cVYs5My for ; Mon, 1 Jun 2015 13:12:51 -0700 (PDT) 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 9F81E1A904B for ; Mon, 1 Jun 2015 13:12:50 -0700 (PDT) Received: by wizo1 with SMTP id o1so118943568wiz.1 for ; Mon, 01 Jun 2015 13:12:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=gN5A8JKQhtZgrGyrGxTxa4AqN2vxTOnW0fuVuWjepgI=; b=H8oj508C0Q+EAajE3M7pwF41ZqfDy2SKzA6azhDO3Rd5LPs+67Fmfgr5qLhHrDl50O X81+eT2uT28T0qer7pFN+jAZxn6iGjpZGIKiWaOPZhLzSqKfwAr8txX2/eZZEgArOfXr GnZhmU3TrtxP96Xq1XKvYyD0TwOgOAlRXdLRAHVb9IdJNaIvlaGuKOTBNpQS3l33qPoe OPLXT39kesiKWnQTwCS2Icc0z4t7UqITImYX6+V8CP99Ow14i0dEer6ZiiY3IjEx8hgg oQE2NA9Xwky7WCGE4uZrZ+ezDi5VKp/ZuLlHAm6P6QtJjVguBlNVty3OTvjZjD16SEir u50g== X-Gm-Message-State: ALoCoQmdj55CqYrYIGf3PUR2od89K04IPHwtjO68h4dnOnnypGjDxtgaeQxMfMd/oNPDTAmNakFa X-Received: by 10.194.186.145 with SMTP id fk17mr44237267wjc.156.1433189569317; Mon, 01 Jun 2015 13:12:49 -0700 (PDT) Received: from [10.0.0.142] (chello080108032135.14.11.univie.teleweb.at. [80.108.32.135]) by mx.google.com with ESMTPSA id u9sm23440298wju.44.2015.06.01.13.12.45 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Jun 2015 13:12:48 -0700 (PDT) Message-ID: <556CBCBA.2090109@azet.org> Date: Mon, 01 Jun 2015 22:12:42 +0200 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Daniel Kahn Gillmor References: <556C4ACD.9040002@azet.org> <556C51FC.807@azet.org> <87pp5fe3t5.fsf@alice.fifthhorseman.net> In-Reply-To: <87pp5fe3t5.fsf@alice.fifthhorseman.net> X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigE53EC4576D0ECC31C1247F15" Archived-At: Cc: Phillip Rogaway , TLS Mailing List , Charanjit Jutla Subject: Re: [TLS] AES-OCB in TLS [New Version Notification for draft-zauner-tls-aes-ocb-03.txt] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Jun 2015 20:12:52 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE53EC4576D0ECC31C1247F15 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi dkg, Daniel Kahn Gillmor wrote: > On Mon 2015-06-01 08:37:16 -0400, Aaron Zauner wrote: >> Firstly, as far as I know it's also quite difficult to get ECDSA >> certificates in the wild. Has this changed significantly over the past= >> couple of months? >=20 > I've heard this claim in the past, but i'm not sure what it is based on= =2E > AFAICT, there are several public CAs who are happy to issue ECDSA > certificates if you ask them for them. >=20 > In November 2014, i managed to get one from Comodo (or a Comodo > reseller, i can't keep all the "imprints" and "branding" straight) and > it took about 20 minutes from start to finish. >=20 > Can you describe how you have tried to get an ECDSA cert, and how those= > attempts failed? >=20 My last attempt must have been a year or more ago. That's absolutely subjective and from what I've heard from other operators (similar experiences to those described by mike hamburg). Since people were nice enough to inform me in this thread that, indeed, ECDSA is getting deployed (as seen in Kario's statistics) and will be used for let's encrypt - I have no problem keeping it in the document! Aaron --------------enigE53EC4576D0ECC31C1247F15 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVbLy7AAoJEOTbZJL9ubXV4gIP/19VlfyuEHeiAHjVOGm6SWBD +Nqlb1jUj8uX+QnUMUx3Mfu4YIGfuacScLIf2Hgg3esxtIahM7hTjeSAs3HydPbQ s+fB6Bt2KAGHH46bxyLYlroyb0GpOGMBJD9PVCtbv5sR11gpm9z7Im5eQJq9UhBb BjdyGWSCZPGjtZ11CWPQHxqH5BqJcXiWNKv7mYCOASxGJ6DS37wrcHCLXAY537eR bsdGYMdP9ubADc8Dp6ybql6mKFlo1jEhkXl2frq+KDCo5zAHn5hRHxCQkDvhsV7B bNZKdqRc5HH7mwg5TVFBOIj4C2m8u3vI80SidP/BI9KyiRbCK9g7Wqpx0vDIwoTd KkItX1+CPwMSmDEoxOqSrEKPiQYZx5szjC8yIdEUOYIE8nvh40lbvHTd2NDKeCmn eEAbqDKub8CR93o4MLnwtq7HdxIn9saSiE1CNL2WXFCw14om5sqh2rT+PraSDM15 0Nakqih54mIURE3U44OutXABu02+vuxMzgELD0mxutIrg0YC+MrIVgb0EFXS8Igm 5rbKR531H/4LSq1eJ3rAUTNLjVl2Wpue9hSQrkm0fMhuJbNV8fpOcoSE+6b9CMwL hqKDoCfKSNalSws8H9yx7toRkeSGvdrkfhjm0Gh2v7CJ0RdOZyA8XOIhtWmVgZXM p2LZOYDCXUEEKEM0Qxy+ =BoIo -----END PGP SIGNATURE----- --------------enigE53EC4576D0ECC31C1247F15-- From nobody Mon Jun 1 13:46: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 C2D491A8AC4 for ; Mon, 1 Jun 2015 13:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64mjoYi1gqWO for ; Mon, 1 Jun 2015 13:46:09 -0700 (PDT) Received: from mmextmx2.mcr.colo.comodoca.net (mmextmx2.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd6]) (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 61EC21A9025 for ; Mon, 1 Jun 2015 13:46:08 -0700 (PDT) Received: (qmail 5272 invoked by uid 1004); 1 Jun 2015 20:46:06 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx2.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Mon, 01 Jun 2015 21:46:06 +0100 Received: (qmail 16989 invoked by uid 1000); 1 Jun 2015 20:46:06 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Mon, 01 Jun 2015 21:46:06 +0100 Message-ID: <556CC48C.9080306@comodo.com> Date: Mon, 01 Jun 2015 21:46:04 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Michael Hamburg , Daniel Kahn Gillmor References: <556C4ACD.9040002@azet.org> <556C51FC.807@azet.org> <87pp5fe3t5.fsf@alice.fifthhorseman.net> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Phillip Rogaway , TLS Mailing List , Charanjit Jutla Subject: Re: [TLS] AES-OCB in TLS [New Version Notification for draft-zauner-tls-aes-ocb-03.txt] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Jun 2015 20:46:12 -0000 On 01/06/15 19:33, Michael Hamburg wrote: > I tried to get one from Comodo about a year ago. It wasn’t advertised on their website but I asked one of their tech support folks. They said that it was an experimental feature for business customers only, and would cost me something like $600. I don’t remember if that was a 1-year or 3-year cert. Hi Mike. It's true that we haven't made a big deal of advertising the fact that we are happy to certify EC public keys and sign using ECDSA these days. I'm rather puzzled by your experience with our tech support guys though. It's never been an "experimental feature for business customers only". And we don't set different prices for EC certs compared to RSA certs. If you place an order directly with Comodo, and provide a CSR containing an EC public key (secp256r1, secp384r1 or secp521r1), then the resulting cert will be signed using ECDSA. Simple as that. It should be equally simple if you order via a Comodo reseller, but as DKG said, YMMV. (I'm guessing that some reseller systems might feel the need to attempt to parse the CSR...and fail because they're not ECC-ready). > I looked at Verisign’s catalog as well, and it was labeled as an enterprise feature with an even higher price tag. Low thousands I think. I asked the guys at BaySec and they said that this was the shape of the market at that time. > > I also looked at StartSSL. They are free, but only offer RSA certs. I mostly wanted ECDSA for performance on a super slow home server, and I figured $600 in hardware upgrades would go a lot further than $600 in certs. > > Anyway you can get ECDSA certs relatively easily, but not cheaply; or at least, that’s how it was a year ago. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Mon Jun 1 14:20: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 78B3C1A0013 for ; Mon, 1 Jun 2015 14:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0t6v00svVaH6 for ; Mon, 1 Jun 2015 14:20:40 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 074BA1A000E for ; Mon, 1 Jun 2015 14:20:39 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id A8AB8F984; Mon, 1 Jun 2015 17:20:36 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 861331FF5D; Mon, 1 Jun 2015 17:20:14 -0400 (EDT) From: Daniel Kahn Gillmor To: Peter Gutmann , "noloader\@gmail.com" In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AB02AA8F@uxcn10-tdc05.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73AB029727@uxcn10-tdc05.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73AB02AA8F@uxcn10-tdc05.UoA.auckland.ac.nz> User-Agent: Notmuch/0.20 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Mon, 01 Jun 2015 17:20:14 -0400 Message-ID: <87k2vncei9.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "" Subject: Re: [TLS] Another IRINA bug 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: Mon, 01 Jun 2015 21:20:41 -0000 On Sun 2015-05-24 03:12:00 -0400, Peter Gutmann wrote: > Jeffrey Walton writes: > >>GnuTLS with its Lim-Lee primes causes me a lot of problems because they >>cannot be validated. > > Actually the problem isn't GnuTLS (hey, I use Lim-Lee primes as well!), it's > the fact that TLS uses the PKCS #3 format rather than the DSA format, so > you've got nice verifiable values for which you have to throw away the > parameter used to verify them and send them in an unverifiable format. Having > said that, there's a pretty simple fix, define an extension that acts like the > existing propose/accept extensions that signals a change in DH values to the > DSA form (p, q, g) rather than PKCS #3 form (p, g). And for TLS 1.3, use the > DSA form by default, not the PKCS #3 form. If we're still shipping arbitrary groups across the wire, then adding (q) to the data over the wire not only increases the size of the handshake (by the size of q) but now the receiving peer has to verify that: (a) p is prime (b) q itself is prime (c) p is actually a Lim-Lee prime either that, or they can skip the checks and cross their fingers. Standardizing on known safe prime moduli seems simpler and easier and less likely to include some steps that people will be tempted to skip for speed. --dkg From nobody Mon Jun 1 14:25: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 CC9E31A0035 for ; Mon, 1 Jun 2015 14:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 vPhWkQ1sMpbg for ; Mon, 1 Jun 2015 14:25:41 -0700 (PDT) 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 764A11A002F for ; Mon, 1 Jun 2015 14:25:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 11825BED3; Mon, 1 Jun 2015 22:25:40 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nM9RL2LpyqsD; Mon, 1 Jun 2015 22:25:38 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.31.250]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id ACFFFBED2; Mon, 1 Jun 2015 22:25:38 +0100 (IST) Message-ID: <556CCDD2.7050006@cs.tcd.ie> Date: Mon, 01 Jun 2015 22:25:38 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Xiaoyin Liu , Roland Zink , "tls@ietf.org" References: <201504292035.21721.davemgarrett@gmail.com>, <5541E286.2090001@cs.tcd.ie> <5542303D.2080604@zinks.de>, <5542330A.3060605@cs.tcd.ie> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] who do I poke to fix the URLs in the header? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Jun 2015 21:25:43 -0000 Hiya, On 22/05/15 07:18, Xiaoyin Liu wrote: >>> On 30.04.2015 10:06, Stephen Farrell wrote: >>>> Hi Dave, >>>> >>>> That brings in a bunch of things including tools, boilerplate >>>> issues and policy stuff ("do we want an https-everything like >>>> thing for the IETF?"). Good questions to ask though so I'll put >>>> that on the IESG's agenda for some meetings we're having next >>>> week. Please hassle me in 2-3 weeks if you don't hear something >>>> back. >>>> >>>> Cheers, >>>> S. >>>> > > Hi Stephen, > > What's the result of the discussion in IESG on using HTTPS? Please see [1]. Comments welcome but please do send them to the addresses listed and not to the TLS WG list. Thanks, S. [1] https://www.ietf.org/mail-archive/web/ietf-announce/current/msg14190.html > > Best, > Xiaoyin > > > From nobody Mon Jun 1 14:34: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 27D9D1A006F for ; Mon, 1 Jun 2015 14:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bz3gz9WH5LVF for ; Mon, 1 Jun 2015 14:34:01 -0700 (PDT) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::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 409DA1A0063 for ; Mon, 1 Jun 2015 14:34:01 -0700 (PDT) Received: by igbpi8 with SMTP id pi8so72324934igb.1 for ; Mon, 01 Jun 2015 14:34:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=aXqvmzOxhLlnQsmBmFAj3oYQVSaja8lDMZggEx/metY=; b=0Pf9pNc9g69nOtXbeknZHb8M4J0hD519SSAhTrriYC7k4KNXSHZPSIU0Hk+hn9yk2e WlSsKpKxbiCl7Yz8G0Z57SxvM8eB7V7KDrf8YcBIbsyBRORpxDrQooJiwIEW03OuYkQN blVvB7PxCQzKnHuWSg0PMlGrqSJoC/glltfFAAkSPIvnN/jK5/Q47iBvRhdQQrFw/h2c lKGE6+bh40lnn+FhfXOqEf5fTC90qWQacN1XJW+Om0fuZ6azcpBfvRXULQFtFR9kJ3aD JnFlbPUCfQBT4DGamG1h7xLUjZCu4dsPPdFxnjcRLTg3GuYu1SN+qHuePP5sKxnlpjQe TRLQ== MIME-Version: 1.0 X-Received: by 10.50.30.197 with SMTP id u5mr16456346igh.9.1433194440793; Mon, 01 Jun 2015 14:34:00 -0700 (PDT) Received: by 10.36.77.15 with HTTP; Mon, 1 Jun 2015 14:34:00 -0700 (PDT) In-Reply-To: <87k2vncei9.fsf@alice.fifthhorseman.net> References: <9A043F3CF02CD34C8E74AC1594475C73AB029727@uxcn10-tdc05.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73AB02AA8F@uxcn10-tdc05.UoA.auckland.ac.nz> <87k2vncei9.fsf@alice.fifthhorseman.net> Date: Mon, 1 Jun 2015 17:34:00 -0400 Message-ID: From: Jeffrey Walton To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] Another IRINA bug in TLS 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: Mon, 01 Jun 2015 21:34:03 -0000 On Mon, Jun 1, 2015 at 5:20 PM, Daniel Kahn Gillmor wrote: > On Sun 2015-05-24 03:12:00 -0400, Peter Gutmann wrote: >> Jeffrey Walton writes: >> >>>GnuTLS with its Lim-Lee primes causes me a lot of problems because they >>>cannot be validated. >> >> Actually the problem isn't GnuTLS (hey, I use Lim-Lee primes as well!), it's >> the fact that TLS uses the PKCS #3 format rather than the DSA format, so >> you've got nice verifiable values for which you have to throw away the >> parameter used to verify them and send them in an unverifiable format. Having >> said that, there's a pretty simple fix, define an extension that acts like the >> existing propose/accept extensions that signals a change in DH values to the >> DSA form (p, q, g) rather than PKCS #3 form (p, g). And for TLS 1.3, use the >> DSA form by default, not the PKCS #3 form. > > If we're still shipping arbitrary groups across the wire, then adding > (q) to the data over the wire not only increases the size of the > handshake (by the size of q) but now the receiving peer has to verify > that: > > (a) p is prime > > (b) q itself is prime > > (c) p is actually a Lim-Lee prime > > either that, or they can skip the checks and cross their fingers. > > Standardizing on known safe prime moduli seems simpler and easier and > less likely to include some steps that people will be tempted to skip > for speed. > Yeah, agreed. The little voice in the back of my mind is saying the NSA would love to see standard groups so they can build those big tables and store them in Utah in its new data center with shiny new floors. But I'll resist the urge (until Karthikeyan's next paper).... Jeff From nobody Mon Jun 1 15:27: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 C036F1A0389 for ; Mon, 1 Jun 2015 15:27:26 -0700 (PDT) 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, 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 C0epYV9gGuAz for ; Mon, 1 Jun 2015 15:27:25 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0113.outbound.protection.outlook.com [207.46.100.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB0751A0393 for ; Mon, 1 Jun 2015 15:27:24 -0700 (PDT) Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1393.namprd03.prod.outlook.com (10.163.81.14) with Microsoft SMTP Server (TLS) id 15.1.172.22; Mon, 1 Jun 2015 22:27:23 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0172.012; Mon, 1 Jun 2015 22:27:23 +0000 From: Andrei Popov To: Daniel Kahn Gillmor , Peter Gutmann , "noloader@gmail.com" Thread-Topic: [TLS] Another IRINA bug in TLS Thread-Index: AdCUn0KvGK03Jhi6XU6uOngiFXH3wAAEj+eAAE/awQABr/SgAAAB6bow Date: Mon, 1 Jun 2015 22:27:23 +0000 Message-ID: References: <9A043F3CF02CD34C8E74AC1594475C73AB029727@uxcn10-tdc05.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73AB02AA8F@uxcn10-tdc05.UoA.auckland.ac.nz> <87k2vncei9.fsf@alice.fifthhorseman.net> In-Reply-To: <87k2vncei9.fsf@alice.fifthhorseman.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:ed31::2] x-microsoft-exchange-diagnostics: 1; BLUPR03MB1393; 3:IYICH0prH2bOFnpif7RAJGUaTbWZHThFUPCmbxRrByZhVtccYRq4nLcWpIQOah6K9bQa3n2IE5s3u2Wcrbhd+PriqeQtZauJHCN7Pj/yF3GSG/P1cSNfLRlDdwO8woqq7Ptt7Pjnb0Og7fVxX7EcNQ==; 10:Vc3lvlF624UpOa3YoKZ3dGM0Bd+Xz7AT2Jln43gsTqc3RIoCKj53pQTrNQdDMvxpRXr2CgUJ8CWfDzlTNRcVDy1665BzCJLwDNagdWdD+Eg=; 6:1jB3KTT6FZWoNfAn3ktcpZ7ESxLQV4y5nv/e5HAOtH6Hth9UZlwTatoQAilhzf0P x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1393; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(520003)(3002001); SRVR:BLUPR03MB1393; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1393; x-forefront-prvs: 05947791E4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(13464003)(51704005)(377424004)(24454002)(377454003)(189002)(64706001)(86612001)(2656002)(62966003)(19580405001)(87936001)(19580395003)(77156002)(40100003)(33656002)(5001770100001)(5002640100001)(97736004)(86362001)(122556002)(105586002)(99286002)(74316001)(46102003)(81156007)(93886004)(4001540100001)(101416001)(106356001)(5001960100002)(50986999)(5001920100001)(5001830100001)(5001860100001)(54356999)(76176999)(2950100001)(189998001)(68736005)(2900100001)(77096005)(15975445007)(92566002)(76576001)(2501003)(102836002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1393; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jun 2015 22:27:23.1591 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1393 Archived-At: Cc: "" Subject: Re: [TLS] Another IRINA bug 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: Mon, 01 Jun 2015 22:27:26 -0000 > Standardizing on known safe prime moduli seems simpler and easier and les= s likely to include some steps that people will be tempted to skip for spee= d. Using known safe DH parameters makes sense to me. Besides, if we want clien= ts to validate arbitrary DH parameters, then we have to standardize the exa= ct verification steps, otherwise we'll get interop issues. Cheers, Andrei -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Daniel Kahn Gillmor Sent: Monday, June 1, 2015 2:20 PM To: Peter Gutmann; noloader@gmail.com Cc: Subject: Re: [TLS] Another IRINA bug in TLS On Sun 2015-05-24 03:12:00 -0400, Peter Gutmann wrote: > Jeffrey Walton writes: > >>GnuTLS with its Lim-Lee primes causes me a lot of problems because=20 >>they cannot be validated. > > Actually the problem isn't GnuTLS (hey, I use Lim-Lee primes as=20 > well!), it's the fact that TLS uses the PKCS #3 format rather than the=20 > DSA format, so you've got nice verifiable values for which you have to=20 > throw away the parameter used to verify them and send them in an=20 > unverifiable format. Having said that, there's a pretty simple fix,=20 > define an extension that acts like the existing propose/accept=20 > extensions that signals a change in DH values to the DSA form (p, q,=20 > g) rather than PKCS #3 form (p, g). And for TLS 1.3, use the DSA form by= default, not the PKCS #3 form. If we're still shipping arbitrary groups across the wire, then adding (q) to the data over the wire not only increases the size of the handshake = (by the size of q) but now the receiving peer has to verify that: (a) p is prime (b) q itself is prime (c) p is actually a Lim-Lee prime either that, or they can skip the checks and cross their fingers. Standardizing on known safe prime moduli seems simpler and easier and less = likely to include some steps that people will be tempted to skip for speed. --dkg _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Mon Jun 1 15:51: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 076F51A1A97; Mon, 1 Jun 2015 15:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GH6C2QO9IXc; Mon, 1 Jun 2015 15:50:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BAA21A1A98; Mon, 1 Jun 2015 15:50:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150601225057.17500.96911.idtracker@ietfa.amsl.com> Date: Mon, 01 Jun 2015 15:50:57 -0700 Archived-At: Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.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, 01 Jun 2015 22:51:05 -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 : Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS Author : Daniel Kahn Gillmor Filename : draft-ietf-tls-negotiated-ff-dhe-10.txt Pages : 26 Date : 2015-06-01 Abstract: Traditional finite-field-based Diffie-Hellman (DH) key exchange during the TLS handshake suffers from a number of security, interoperability, and efficiency shortcomings. These shortcomings arise from lack of clarity about which DH group parameters TLS servers should offer and clients should accept. This document offers a solution to these shortcomings for compatible peers by using a section of the TLS "EC Named Curve Registry" to establish common finite-field DH parameters with known structure and a mechanism for peers to negotiate support for these groups. This draft updates TLS versions 1.0 [RFC2246], 1.1 [RFC4346], and 1.2 [RFC5246], as well as the TLS ECC extensions [RFC4492]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-negotiated-ff-dhe-10 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 Mon Jun 1 16:02: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 4F8631A1AFF for ; Mon, 1 Jun 2015 16:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNrncgo03bSs for ; Mon, 1 Jun 2015 16:02:45 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (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 289781A1B15 for ; Mon, 1 Jun 2015 16:02:45 -0700 (PDT) Received: by oiww2 with SMTP id w2so113229116oiw.0 for ; Mon, 01 Jun 2015 16:02:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=BmIXmuae13Nx36s4VFpF6DpTa6R4/LqtiaakHNaTO50=; b=nRNKfniewEmVx8QYSgnxzaWjBhvrIba1BUwyL1CPJwr2L0yAWGMXCfGMsyMnlsmvpE kljK11YijEfde5jN1OxkIv09068MdoqcNrPeqZVk1OOvUwp4KKD+HO0EGxTgyTs7T5xz q79prqfOXKleMYPFk4z/pF3abUdXQCwTYTaVXrcl8cXCLj8slb24GGDYXn3voGCXDXFY Au2+mJFgB0FozdvG1OxQ+iMAb8lIomCIyQHEqg5ucMW6c1gqFBPm5DSZscqU9PTITyNA vLb/a1DN16sAdo2rkGJcvF6wlWF6Kc2mRTTsNTcdN3Csz66tjoHru3qhcyGLwiWX5NcP 6TDg== X-Received: by 10.60.92.198 with SMTP id co6mr14533565oeb.3.1433199764561; Mon, 01 Jun 2015 16:02:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.110.241 with HTTP; Mon, 1 Jun 2015 16:02:24 -0700 (PDT) In-Reply-To: <20150601225057.17500.96911.idtracker@ietfa.amsl.com> References: <20150601225057.17500.96911.idtracker@ietfa.amsl.com> From: Tony Arcieri Date: Mon, 1 Jun 2015 16:02:24 -0700 Message-ID: To: "" Content-Type: multipart/alternative; boundary=047d7b33d544dbe50605177cd261 Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Jun 2015 23:02:47 -0000 --047d7b33d544dbe50605177cd261 Content-Type: text/plain; charset=UTF-8 Alternative suggestion: DHE diediedie Is there really a compelling reason to keep it around? I expect the response is going to be "What if there's some catastrophic failure of ECC?" but if that really happens, can't we just temporarily forego forward secrecy rather than further complecting TLS with a backup we probably won't need? On Mon, Jun 1, 2015 at 3:50 PM, wrote: > > 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 : Negotiated Finite Field Diffie-Hellman Ephemeral > Parameters for TLS > Author : Daniel Kahn Gillmor > Filename : draft-ietf-tls-negotiated-ff-dhe-10.txt > Pages : 26 > Date : 2015-06-01 > > Abstract: > Traditional finite-field-based Diffie-Hellman (DH) key exchange > during the TLS handshake suffers from a number of security, > interoperability, and efficiency shortcomings. These shortcomings > arise from lack of clarity about which DH group parameters TLS > servers should offer and clients should accept. This document offers > a solution to these shortcomings for compatible peers by using a > section of the TLS "EC Named Curve Registry" to establish common > finite-field DH parameters with known structure and a mechanism for > peers to negotiate support for these groups. > > This draft updates TLS versions 1.0 [RFC2246], 1.1 [RFC4346], and 1.2 > [RFC5246], as well as the TLS ECC extensions [RFC4492]. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-10 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-negotiated-ff-dhe-10 > > > 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/ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Tony Arcieri --047d7b33d544dbe50605177cd261 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Alternative suggestion: DHE diediedie

Is there rea= lly a compelling reason to keep it around? I expect the response is going t= o be "What if there's some catastrophic failure of ECC?" but = if that really happens, can't we just temporarily forego forward secrec= y rather than further complecting TLS with a backup we probably won't n= eed?

O= n Mon, Jun 1, 2015 at 3:50 PM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Transport Layer Security Working Gro= up of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Dani= el Kahn Gillmor
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-tls-negotiated-ff-dhe-10.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 26
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-06-01

Abstract:
=C2=A0 =C2=A0Traditional finite-field-based Diffie-Hellman (DH) key exchang= e
=C2=A0 =C2=A0during the TLS handshake suffers from a number of security, =C2=A0 =C2=A0interoperability, and efficiency shortcomings.=C2=A0 These sho= rtcomings
=C2=A0 =C2=A0arise from lack of clarity about which DH group parameters TLS=
=C2=A0 =C2=A0servers should offer and clients should accept.=C2=A0 This doc= ument offers
=C2=A0 =C2=A0a solution to these shortcomings for compatible peers by using= a
=C2=A0 =C2=A0section of the TLS "EC Named Curve Registry" to esta= blish common
=C2=A0 =C2=A0finite-field DH parameters with known structure and a mechanis= m for
=C2=A0 =C2=A0peers to negotiate support for these groups.

=C2=A0 =C2=A0This draft updates TLS versions 1.0 [RFC2246], 1.1 [RFC4346], = and 1.2
=C2=A0 =C2=A0[RFC5246], as well as the TLS ECC extensions [RFC4492].


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-negot= iated-ff-dhe/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff= -dhe-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-t= ls-negotiated-ff-dhe-10


Please note that it may take a couple of minutes from the time of submissio= n
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/

_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls



--
Tony Arcieri
--047d7b33d544dbe50605177cd261-- From nobody Mon Jun 1 16:03: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 19D471A1A7E for ; Mon, 1 Jun 2015 16:03:37 -0700 (PDT) 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 FIzxg9vt0IaA for ; Mon, 1 Jun 2015 16:03:36 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id D1E261A1B0E for ; Mon, 1 Jun 2015 16:03:30 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id 9374035009A; Mon, 1 Jun 2015 16:03:30 -0700 (PDT) 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=M5S/wvYZOT/a3d 9n/N5wHDEfMTg=; b=tx/jqkTVFW/gFx8CSMQiP4RgCbM32oRh7AG5MhdLhh9g3M OF2/SZVfxeso0LDrFYdfhiy9Hckg+jtfUQAAOQ+Kk9cLeKSXSJfrAEcQg1LJ1xGU 3XjTeHi4O6IhFEueUC6f9XDwwl8D1GKOCCsFbYMh8ecvHoTUKeKXoN1D+bFd0= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPA id 2032B35008A; Mon, 1 Jun 2015 16:03:30 -0700 (PDT) Date: Mon, 1 Jun 2015 18:03:29 -0500 From: Nico Williams To: Daniel Kahn Gillmor Message-ID: <20150601230328.GD17122@localhost> References: <9A043F3CF02CD34C8E74AC1594475C73AB029727@uxcn10-tdc05.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73AB02AA8F@uxcn10-tdc05.UoA.auckland.ac.nz> <87k2vncei9.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87k2vncei9.fsf@alice.fifthhorseman.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "" Subject: Re: [TLS] Another IRINA bug 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: Mon, 01 Jun 2015 23:03:37 -0000 On Mon, Jun 01, 2015 at 05:20:14PM -0400, Daniel Kahn Gillmor wrote: > If we're still shipping arbitrary groups across the wire, then adding > (q) to the data over the wire not only increases the size of the > handshake (by the size of q) but now the receiving peer has to verify > that: > > (a) p is prime > > (b) q itself is prime > > (c) p is actually a Lim-Lee prime > > either that, or they can skip the checks and cross their fingers. > > Standardizing on known safe prime moduli seems simpler and easier and > less likely to include some steps that people will be tempted to skip > for speed. +1. Pick standard groups large enough to put DLP out of reach of all adversaries, with Moore's law in mind, with groups having a not-after date. As time passes these not-after dates should be revised, perhaps periodically, to account for any improvements in DLP technology, or slight deviations from [Moore's law's] predictions of chip transistor count doubling times. Nico -- From nobody Mon Jun 1 16:19: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 E438E1A1B30; Mon, 1 Jun 2015 16:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.3 X-Spam-Level: X-Spam-Status: No, score=-101.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_42=0.6, USER_IN_WHITELIST=-100] 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 QbeiMURuJmrC; Mon, 1 Jun 2015 16:19:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 688351A1B45; Mon, 1 Jun 2015 16:19:37 -0700 (PDT) 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: 6.0.3.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150601231937.5341.24525.idtracker@ietfa.amsl.com> Date: Mon, 01 Jun 2015 16:19:37 -0700 Archived-At: Cc: tls mailing list , tls chair , RFC Editor Subject: [TLS] Protocol Action: 'Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS' to Proposed Standard (draft-ietf-tls-negotiated-ff-dhe-10.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, 01 Jun 2015 23:19:40 -0000 The IESG has approved the following document: - 'Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS' (draft-ietf-tls-negotiated-ff-dhe-10.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: https://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/ Technical Summary Traditional finite-field-based Diffie-Hellman (DH) key exchange during the TLS handshake suffers from a number of security, interoperability, and efficiency shortcomings. These shortcomings arise from lack of clarity about which DH group parameters TLS servers should offer and clients should accept. This document offers a solution to these shortcomings for compatible peers by using a section of the TLS "EC Named Curve Registry" to establish common finite-field DH parameters with known structure and a mechanism for peers to negotiate support for these groups. Working Group Summary This was well debated in the WG and the idea is very well supported as it's a useful security improvement. Document Quality This has had plenty of review. I'm not sure if there are current implementations, but TLS1.3 will also adopt this approach so it will be implemented then at least and likely backported if that'st still needed. Personnel Sean Turner is the highly experienced document shepherd. Stephen Farrell is the irresponsible AD. From nobody Mon Jun 1 16:34: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 1587B1A1BD7 for ; Mon, 1 Jun 2015 16:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.555 X-Spam-Level: * X-Spam-Status: No, score=1.555 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.982, 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 VWu0jNJFcqtf for ; Mon, 1 Jun 2015 16:34:50 -0700 (PDT) Received: from aspartame.shiftleft.org (199-116-74-168-v301.PUBLIC.monkeybrains.net [199.116.74.168]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F37CD1A1BD4 for ; Mon, 1 Jun 2015 16:34:49 -0700 (PDT) Received: from [172.20.10.9] (unknown [166.170.39.238]) by aspartame.shiftleft.org (Postfix) with ESMTPSA id 96EEB3A9C3; Mon, 1 Jun 2015 16:33:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shiftleft.org; s=sldo; t=1433201590; bh=zXSvvvrFrdnsU4mONjRoToeuNNT4JwSyQ8NMX+tfHNI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=kNJ+kIfYiDJjkjwPuBC+GJKCavMmpAH4oQFZJE4lDomXOluh4TG3z5pniPpFIXS0h t+V5QgKIE2tAZYl/aY5CYGl3yS+kk6qbkM7Pn9eWdF94tLuLzh3ObZParhKI0TQach EJgCQcv6I2BKHpkD5x2C2dkIkjrERJ6zlAeeEfbQ= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2100\)) From: Michael Hamburg In-Reply-To: <556CC48C.9080306@comodo.com> Date: Mon, 1 Jun 2015 16:34:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <556C4ACD.9040002@azet.org> <556C51FC.807@azet.org> <87pp5fe3t5.fsf@alice.fifthhorseman.net> <556CC48C.9080306@comodo.com> To: Rob Stradling X-Mailer: Apple Mail (2.2100) Archived-At: Cc: Phillip Rogaway , TLS Mailing List , Charanjit Jutla Subject: Re: [TLS] AES-OCB in TLS [New Version Notification for draft-zauner-tls-aes-ocb-03.txt] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Jun 2015 23:34:51 -0000 Hi Rob, I guess I=E2=80=99m misremembering my interaction with another CA as = Comodo. Sorry about that. I don=E2=80=99t have a note of which CAs I = tried other than Verisign and StartSSL, so I can=E2=80=99t check for = sure. =E2=80=94 Mike > On Jun 1, 2015, at 1:46 PM, Rob Stradling = wrote: >=20 > On 01/06/15 19:33, Michael Hamburg wrote: > >> I tried to get one from Comodo about a year ago. It wasn=E2=80=99t = advertised on their website but I asked one of their tech support folks. = They said that it was an experimental feature for business customers = only, and would cost me something like $600. I don=E2=80=99t remember = if that was a 1-year or 3-year cert. >=20 > Hi Mike. It's true that we haven't made a big deal of advertising the = fact that we are happy to certify EC public keys and sign using ECDSA = these days. >=20 > I'm rather puzzled by your experience with our tech support guys = though. It's never been an "experimental feature for business customers = only". And we don't set different prices for EC certs compared to RSA = certs. >=20 > If you place an order directly with Comodo, and provide a CSR = containing an EC public key (secp256r1, secp384r1 or secp521r1), then = the resulting cert will be signed using ECDSA. Simple as that. It = should be equally simple if you order via a Comodo reseller, but as DKG = said, YMMV. (I'm guessing that some reseller systems might feel the = need to attempt to parse the CSR...and fail because they're not = ECC-ready). >=20 >> I looked at Verisign=E2=80=99s catalog as well, and it was labeled as = an enterprise feature with an even higher price tag. Low thousands I = think. I asked the guys at BaySec and they said that this was the shape = of the market at that time. >>=20 >> I also looked at StartSSL. They are free, but only offer RSA certs. = I mostly wanted ECDSA for performance on a super slow home server, and I = figured $600 in hardware upgrades would go a lot further than $600 in = certs. >>=20 >> Anyway you can get ECDSA certs relatively easily, but not cheaply; or = at least, that=E2=80=99s how it was a year ago. >=20 > --=20 > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online From nobody Mon Jun 1 16:40: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 092D21A1BE9 for ; Mon, 1 Jun 2015 16:40:19 -0700 (PDT) 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 C0DzAOinmAs3 for ; Mon, 1 Jun 2015 16:40:18 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 29C911A1BCD for ; Mon, 1 Jun 2015 16:40:18 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id 05F71318096; Mon, 1 Jun 2015 16:40:18 -0700 (PDT) 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:content-transfer-encoding; s= cryptonector.com; bh=fiPNLwd3t2q6bhy5cd2fZeKRMtg=; b=JeSaJcD/ptT wvGCv4rENee+viVLF4M2ycEaiId1ODSTjuVUTBpj446xuQpLoKFm25KP+YWwRWpC vnmMMVn5yysLTKvqbk3+g6Q3ksRWvD3OiRhOjCMEIgqSp+f70anNhIIOiGy6dq6A Jo0iIRxfARpI/mgCbc/aD2sZVUD43FtY= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPA id 70996318095; Mon, 1 Jun 2015 16:40:17 -0700 (PDT) Date: Mon, 1 Jun 2015 18:40:16 -0500 From: Nico Williams To: Santiago Zanella-Beguelin Message-ID: <20150601234015.GF17122@localhost> References: <9A043F3CF02CD34C8E74AC1594475C73AB029727@uxcn10-tdc05.UoA.auckland.ac.nz> <1432317148442.5357@microsoft.com> <87pp5snxha.fsf@alice.fifthhorseman.net> <578DE2AF-A139-4CDC-B71C-C67C28267FCB@inria.fr> <556072C3.9010808@cs.tcd.ie> <1432386773128.94453@microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1432386773128.94453@microsoft.com> User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Another INRIA bug 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: Mon, 01 Jun 2015 23:40:19 -0000 On Sat, May 23, 2015 at 01:12:53PM +0000, Santiago Zanella-Beguelin wrote= : > > From: TLS on behalf of Stephen Farrell > >=20 > > On 23/05/15 07:21, Karthikeyan Bhargavan wrote: > > > The =E2=80=9Cavoid fixed groups=E2=80=9D recommendation applies to = 1024 bits (and any > > > other group-size for which precomputation becomes feasible.) > >=20 > > It's a really good paper, but if you have the chance I > > think adding the above clarification would be very good. >=20 > Thanks!=20 > We're working on that. This is important. It would be easier to have standard groups large enough and don't require run-time validation (being standard...) than to use arbitrary groups that require run-time validation. Don't thow the baby out with the bath water and all that. Nico --=20 From nobody Mon Jun 1 18:46: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 59BD51A882C for ; Mon, 1 Jun 2015 18:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.665 X-Spam-Level: X-Spam-Status: No, score=-3.665 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MX=0.535, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-WcSEwoYDQU for ; Mon, 1 Jun 2015 18:46:57 -0700 (PDT) Received: from mail.iiec.unam.mx (mail.iiec.unam.mx [132.248.241.1]) by ietfa.amsl.com (Postfix) with ESMTP id 235251A8829 for ; Mon, 1 Jun 2015 18:46:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.iiec.unam.mx (Postfix) with ESMTP id E14F017854E; Mon, 1 Jun 2015 20:46:53 -0500 (CDT) Received: from mail.iiec.unam.mx ([127.0.0.1]) by localhost (mail.iiec.unam.mx [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WU9_J1KZap5K; Mon, 1 Jun 2015 20:46:53 -0500 (CDT) Received: from v.gwolf.org (unknown [132.248.72.123]) by mail.iiec.unam.mx (Postfix) with ESMTP id AECDD17844B; Mon, 1 Jun 2015 20:46:53 -0500 (CDT) Received: by v.gwolf.org (Postfix, from userid 1000) id 75EEB2B4E4; Mon, 1 Jun 2015 20:46:53 -0500 (CDT) Date: Mon, 1 Jun 2015 20:46:53 -0500 From: Gunnar Wolf To: Aaron Zauner Message-ID: <20150602014653.GB56774@gwolf.org> References: <556C4ACD.9040002@azet.org> <556C51FC.807@azet.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <556C51FC.807@azet.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: Phillip Rogaway , TLS Mailing List , Charanjit Jutla Subject: Re: [TLS] AES-OCB in TLS [New Version Notification for draft-zauner-tls-aes-ocb-03.txt] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Jun 2015 01:46:58 -0000 Aaron Zauner dijo [Mon, Jun 01, 2015 at 02:37:16PM +0200]: > > * I'd also like to get rid of ECDSA ciphersuites alltogether, ideally > > leaving a few real-world, high-performance ciphersuites to use > > > > > > I don't understand this point: ECDSA cipher suites are the ones with the > > best performance at present. > > > > Firstly, as far as I know it's also quite difficult to get ECDSA > certificates in the wild. Has this changed significantly over the past > couple of months? Second - there's a current draft on EdDSA, which I'd > prefer over ECDSA, if somehow possible. I'm more about minimizing the > list of cipher-suites this draft introduces than to point out that I > dislike a particular signature schemes. I'd venture to say that's a consequence of them having been around much less time than the other schemes; not only have had crypto libraries to gain widespread support for them to be interoperable enough, but also the involved individuals/companies (mostly thinking about CAs. From nobody Tue Jun 2 01:26: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 D2A5C1A879E for ; Tue, 2 Jun 2015 01:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 WBueXCg069qe for ; Tue, 2 Jun 2015 01:26:07 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E1731A8868 for ; Tue, 2 Jun 2015 01:25:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1433233554; x=1464769554; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=2765ikHOBUkSbwk2o+XV8GTsMXd7zFPr6rZDFc489go=; b=25Zp5LyH4rjAzpQva0lbkgHlvQFMfljuzocNtCe3Xcynmb7AE80HhIOV s+J4xCykMedJMrWd9nifINoFS9a0Y7DA+EIAzhevHTh1sIMd7hGAOukBd GZTj5+ySfHomAzDwX6RQSVLyEegJ2UsYxiGfNJ4clTsPE2n7xtggLtPG1 QnSRuJ/rgZbc8S9J3NRXS4DlnQMuAoo9aM+95VOHKu1x175NkvJBf4xan mL7lBDwgNinP+V7yOA6y+6T36wLbzU+JVKIUcv8EcpqQLIyuTjQrpQtNP Jcsu3DyB3i/cpeh3TNrNLXRSVz3RsP8ScBelVlRzYCUUmqjSG5rDrVUe+ w==; X-IronPort-AV: E=Sophos;i="5.13,538,1427713200"; d="scan'208";a="20230710" 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 mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 02 Jun 2015 20:25:36 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.151]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Tue, 2 Jun 2015 20:25:35 +1200 From: Peter Gutmann To: "" Thread-Topic: [TLS] AES-OCB in TLS [New Version Notification for draft-zauner-tls-aes-ocb-03.txt] Thread-Index: AdCdDbLK8IPR3MEUSzmiVs+jaawzLw== Date: Tue, 2 Jun 2015 08:25:35 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AB03433A@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] AES-OCB in TLS [New Version Notification for draft-zauner-tls-aes-ocb-03.txt] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Jun 2015 08:26:12 -0000 Yaron Sheffer writes:=0A= =0A= > PAKE means password-authenticated key exchange, and TLS-PSK is not suitab= le=0A= > for use with (short, memorable) passwords. See=0A= > https://tools.ietf.org/html/rfc4279#section-7.2=0A= =0A= Sure, but then neither is OpenPGP, S/MIME, WPA2, or pretty much anything el= se=0A= for that matter, which is why you use a salted iterated hash for all of the= m.=0A= One of the PHC docs, which talks about implementation suggestions for use w= ith=0A= other protocols, will address use with TLS.=0A= =0A= Peter.=0A= From nobody Tue Jun 2 05:54: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 07B791A006D for ; Tue, 2 Jun 2015 05:54:22 -0700 (PDT) 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 I5OZjYt7JrA5 for ; Tue, 2 Jun 2015 05:54:20 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 308B31A006C for ; Tue, 2 Jun 2015 05:54:20 -0700 (PDT) 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 (Postfix) with ESMTPS id 82F33B6A32; Tue, 2 Jun 2015 12:54:19 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-110.brq.redhat.com [10.34.0.110]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t52CsHDQ030500 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 2 Jun 2015 08:54:19 -0400 From: Hubert Kario To: tls@ietf.org Date: Tue, 02 Jun 2015 14:54:11 +0200 Message-ID: <1474500.r0W7gM0pAO@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.7 (Linux/4.0.4-201.fc21.x86_64; KDE/4.14.7; x86_64; ; ) In-Reply-To: References: <20150601225057.17500.96911.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart13275331.7GbVdoEhZl"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Jun 2015 12:54:22 -0000 --nextPart13275331.7GbVdoEhZl Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Monday 01 June 2015 16:02:24 Tony Arcieri wrote: > Alternative suggestion: DHE diediedie >=20 > Is there really a compelling reason to keep it around? I expect the > response is going to be "What if there's some catastrophic failure of= ECC?" > but if that really happens, can't we just temporarily forego forward > secrecy rather than further complecting TLS with a backup we probably= won't > need? as it was pointed out many times: adding support for this extension and= groups=20 to implementations that already support FF DHE is rather trivial, addin= g=20 support for ECC is complex (both because of compexity of ECC and becaus= e it's=20 a completely new set of algorithms) This allows us to move away from defaulting to 1024bit or 2048bit on se= rver=20 side in fear of breaking, for example, Java based clients > On Mon, Jun 1, 2015 at 3:50 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > >=20 > > This draft is a work item of the Transport Layer Security Working = Group > >=20 > > of the IETF. > >=20 > > Title : Negotiated Finite Field Diffie-Hellman Ep= hemeral > >=20 > > Parameters for TLS > >=20 > > Author : Daniel Kahn Gillmor > > Filename : draft-ietf-tls-negotiated-ff-dhe-10.txt > > Pages : 26 > > Date : 2015-06-01 > >=20 > > Abstract: > > Traditional finite-field-based Diffie-Hellman (DH) key exchange > > during the TLS handshake suffers from a number of security, > > interoperability, and efficiency shortcomings. These shortcomin= gs > > arise from lack of clarity about which DH group parameters TLS > > servers should offer and clients should accept. This document o= ffers > > a solution to these shortcomings for compatible peers by using a= > > section of the TLS "EC Named Curve Registry" to establish common= > > finite-field DH parameters with known structure and a mechanism = for > > peers to negotiate support for these groups. > > =20 > > This draft updates TLS versions 1.0 [RFC2246], 1.1 [RFC4346], an= d 1.2 > > [RFC5246], as well as the TLS ECC extensions [RFC4492]. > >=20 > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/ > >=20 > > There's also a htmlized version available at: > > https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-10 > >=20 > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-negotiated-ff-dh= e-10 > >=20 > >=20 > > 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= . > >=20 > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > >=20 > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls =2D-=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 --nextPart13275331.7GbVdoEhZl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJVbad5AAoJEJKo0bgB0vX1cHAQAIOnk7viQe7z+hWfi/WGr3xZ ENhv3LSpC/rx68i4cGTbLDDT+VaEYY5i4WCZmfPBgYKg/tllpAs1tXzTe0zfKQv7 5i0xc2HR4SPypvT8hVKOsOpkwd4MOaxuyQXEk4CMk3xUD4SnEXvagSE2nOUdl2HR wQCJD+H4JrKba+PCZCwU0EiozPqv6YMq55yCawNkp2yvO/OXwVhY5Qv5JXFYR3EE ksnJrq4cjMlc7JLEk3N/h5pTiWuzKBRi6mLtfYhQe96DucrkdtJGk1Bbx4RCp4vz fDmEQBQmoCVDyRuzufzY51RH8i4/q/BMfzzAzR/POgpDO6ln1e8mTmtzEkXIrNbH lQem45vHEC+RgP/ShbFh/xl0qozAi7CRJSoB2jOR0eWhLzXFKklu43VnOuVKkQ7H b6wdotB8Iz3LfcEoLXSnteNrg4SaXbxoYNIFsnwsBv8OftcbC9dCyjQ5OZU5G94O bgmx6kaK7fP9AIL0y83ADTaWec3OhMJlzY19FNW1GbxpQs/jgtEW5pY83HvHM94p MUbogWGEuo1mo5UbsxlqpWPgMHBgcaWsyB0e/5FLGY1mt4LfwheKrWTfz7d2LVrG T+c+6nuyw7r5AZaYcUeuxzRhsWZLt/axKkNvwIF2W4DH9kFXR1JeDTCqv6Gza2M8 PozjAdBc2mtrxQcB7IsL =WSPf -----END PGP SIGNATURE----- --nextPart13275331.7GbVdoEhZl-- From nobody Tue Jun 2 23:00: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 625551B356D for ; Tue, 2 Jun 2015 23:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.598 X-Spam-Level: X-Spam-Status: No, score=-0.598 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, LOTS_OF_MONEY=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 OupZWnLxYbGJ for ; Tue, 2 Jun 2015 23:00:35 -0700 (PDT) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::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 E13541B3564 for ; Tue, 2 Jun 2015 23:00:34 -0700 (PDT) Received: by obbea3 with SMTP id ea3so4651640obb.0 for ; Tue, 02 Jun 2015 23:00:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=yAIMpXyaXuP/EwOrAs52VZ2EArPQSwNzc3owl+eGbL8=; b=xW6FnwfpmiVUdkfJtuzNqlcocPOMbr1Wf0HnlZYMLRdDCd6CtmeJu7pBfUaAhSHuna /1LQQhrRj6wY7DtFWwoc1KB5gzIArth2W/uN9Q+DtNmnUo8Ih3JiKUKBnY4mG8uJKaFP dp0YU/VZuRMyV3bQ+v/SJCUmiz75+qTGL3bVPljYMgcGvRfs//w5GbmQrTg1sqp5ZSx8 A8xPCTI0l+at9CZ1ydbeV0nR95vk1NjiYAOuPNlzhYxrKUKDvk9s81owJejvr5ZFA+NR K86DSeGo48V8JAlBusfYW6S7BmQ4gV/+r6N4gD77nyLE8TwzJwp9W9TWrlYfEtHIzxk4 O09w== X-Received: by 10.202.1.197 with SMTP id 188mr23947248oib.13.1433311234393; Tue, 02 Jun 2015 23:00:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.110.241 with HTTP; Tue, 2 Jun 2015 23:00:14 -0700 (PDT) In-Reply-To: <1474500.r0W7gM0pAO@pintsize.usersys.redhat.com> References: <20150601225057.17500.96911.idtracker@ietfa.amsl.com> <1474500.r0W7gM0pAO@pintsize.usersys.redhat.com> From: Tony Arcieri Date: Tue, 2 Jun 2015 23:00:14 -0700 Message-ID: To: Hubert Kario Content-Type: multipart/alternative; boundary=001a1137c6b6fa8d2c051796c62a Archived-At: Cc: "" Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Jun 2015 06:00:37 -0000 --001a1137c6b6fa8d2c051796c62a Content-Type: text/plain; charset=UTF-8 On Tue, Jun 2, 2015 at 5:54 AM, Hubert Kario wrote: > as it was pointed out many times: adding support for this extension and > groups > to implementations that already support FF DHE is rather trivial, adding > support for ECC is complex (both because of compexity of ECC and because > it's > a completely new set of algorithms) > > This allows us to move away from defaulting to 1024bit or 2048bit on server > side in fear of breaking, for example, Java based clients > Hi there, Some context. I typically don't go "full blowhard". That's something I actively avoid. But I feel it's warranted here. I am responsible for the external ciphersuites configuration for a site that moves over a hundred million dollars per day supporting millions of users. I have also spent what I feel are undue amounts of my own time (probably at least 10 hours in the past month) chasing down DHE problems with Java stacks, trying to solve problems where entire language ecosystems had a total outage of their packaging systems due to Java DHE issues. My opinion is DHE diediedie. I am sorry if I didn't participate when it was "pointed out many times". But this is a draft, and I feel like now isn't an undue time to make a counterargument? Even having DHE enabled when 4096-bit DHE ciphersuites are configured completely blocks Java from completing a TLS handshake. Depending on what Java version, having 2048-bit DHE ciphersuites enabled does the same thing. There were two solutions: get the upstream service to eliminate the problematic ciphersuites, or have the Java client disable DHE. In hopes of getting traffic flowing again, I have told both sides to shut off DHE, and as soon as either side complied, the handshake could complete. What problem do you think this draft is solving? How will it fix older Java clients? So far my experience has been that shutting off DHE solves the problem. If you want ECC, use BouncyCastle as your JCE provider. Anyway, I am responsible for supporting legacy Java 7 (and Java 6!) clients and my opinion is that DHE is actively detrimental to the TLS ecosystem, *especially* where Java is involved. So I am very, very, very confused about what argument you're trying to make about Java here. As far as I'm concerned the *only* workable solution for older Java clients is to shut DHE off. Can you please explain to me where in this draft I can locate the part about how it will help older Java clients better participate in the TLS ecosystem, because I can't find it. -- Tony Arcieri --001a1137c6b6fa8d2c051796c62a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jun 2, 2015 at 5:54 AM, Hubert Kario <hkario@redhat.com> wrote:
as it was pointed out many times: adding support for this extension and= groups
to implementations that already support FF DHE is rather trivial, adding support for ECC is complex (both because of compexity of ECC and because it= 's
a completely new set of algorithms)

This allows us to move away from defaulting to 1024bit or 2048bit on server=
side in fear of breaking, for example, Java based clients
<= div>
Hi there,

Some context. I typic= ally don't go "full blowhard". That's something I activel= y avoid. But I feel it's warranted here.

I am = responsible for the external ciphersuites configuration for a site that mov= es over a hundred million dollars per day supporting millions of users.

I have also spent what I feel are undue amounts of my= own time (probably at least 10 hours in the past month) chasing down DHE p= roblems with Java stacks, trying to solve problems where entire language ec= osystems had a total outage of their packaging systems due to Java DHE issu= es.

My opinion is DHE diediedie. I am sorry if I d= idn't participate when it was "pointed out many times". But t= his is a draft, and I feel like now isn't an undue time to make a count= erargument?

Even having DHE enabled when 4096-bit = DHE ciphersuites are configured completely blocks Java from completing a TL= S handshake. Depending on what Java version, having 2048-bit DHE ciphersuit= es enabled does the same thing.

There were two sol= utions: get the upstream service to eliminate the problematic ciphersuites,= or have the Java client disable DHE. In hopes of getting traffic flowing a= gain, I have told both sides to shut off DHE, and as soon as either side co= mplied, the handshake could complete.

What problem= do you think this draft is solving? How will it fix older Java clients?

So far my experience has been that shutting off DHE = solves the problem. If you want ECC, use BouncyCastle as your JCE provider.=

Anyway, I am responsible for supporting legacy Ja= va 7 (and Java 6!) clients and my opinion is that DHE is actively detriment= al to the TLS ecosystem, *especially* where Java is involved.
So I am very, very, very confused about what argument you'r= e trying to make about Java here. As far as I'm concerned the *only* wo= rkable solution for older Java clients is to shut DHE off.

Can you please explain to me where in this draft I can locate the = part about how it will help older Java clients better participate in the TL= S ecosystem, because I can't find it.

--
=
Tony Arcieri
--001a1137c6b6fa8d2c051796c62a-- From nobody Tue Jun 2 23:15: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 D97531B3581 for ; Tue, 2 Jun 2015 23:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.659 X-Spam-Level: X-Spam-Status: No, score=-0.659 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, LOTS_OF_MONEY=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 HZC1xXKJcuGI for ; Tue, 2 Jun 2015 23:15:19 -0700 (PDT) Received: from BLU004-OMC2S13.hotmail.com (blu004-omc2s13.hotmail.com [65.55.111.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBDC51B3586 for ; Tue, 2 Jun 2015 23:15:18 -0700 (PDT) Received: from BLU177-W42 ([65.55.111.71]) by BLU004-OMC2S13.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Tue, 2 Jun 2015 23:15:18 -0700 X-TMN: [2siJtrRqD9AL8pYaRwqiGaZx2+7EI9aq] X-Originating-Email: [yuhongbao_386@hotmail.com] Message-ID: From: Yuhong Bao To: Tony Arcieri , Hubert Kario Date: Tue, 2 Jun 2015 23:15:17 -0700 Importance: Normal In-Reply-To: References: <20150601225057.17500.96911.idtracker@ietfa.amsl.com>, , <1474500.r0W7gM0pAO@pintsize.usersys.redhat.com>, Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 03 Jun 2015 06:15:18.0326 (UTC) FILETIME=[A9E51D60:01D09DC4] Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Jun 2015 06:15:21 -0000 These older versions of Java don't support FF-DHE=2C and the server can sen= d a different weaker DHE key to older clients.=0A= =0A= ________________________________=0A= > From: bascule@gmail.com =0A= > Date: Tue=2C 2 Jun 2015 23:00:14 -0700 =0A= > To: hkario@redhat.com =0A= > CC: tls@ietf.org =0A= > Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt = =0A= > =0A= > On Tue=2C Jun 2=2C 2015 at 5:54 AM=2C Hubert Kario =0A= > > wrote: =0A= > as it was pointed out many times: adding support for this extension and = =0A= > groups =0A= > to implementations that already support FF DHE is rather trivial=2C addin= g =0A= > support for ECC is complex (both because of compexity of ECC and because = it's =0A= > a completely new set of algorithms) =0A= > =0A= > This allows us to move away from defaulting to 1024bit or 2048bit on serv= er =0A= > side in fear of breaking=2C for example=2C Java based clients =0A= > =0A= > Hi there=2C =0A= > =0A= > Some context. I typically don't go "full blowhard". That's something I = =0A= > actively avoid. But I feel it's warranted here. =0A= > =0A= > I am responsible for the external ciphersuites configuration for a site = =0A= > that moves over a hundred million dollars per day supporting millions =0A= > of users. =0A= > =0A= > I have also spent what I feel are undue amounts of my own time =0A= > (probably at least 10 hours in the past month) chasing down DHE =0A= > problems with Java stacks=2C trying to solve problems where entire =0A= > language ecosystems had a total outage of their packaging systems due =0A= > to Java DHE issues. =0A= > =0A= > My opinion is DHE diediedie. I am sorry if I didn't participate when it = =0A= > was "pointed out many times". But this is a draft=2C and I feel like now = =0A= > isn't an undue time to make a counterargument? =0A= > =0A= > Even having DHE enabled when 4096-bit DHE ciphersuites are configured =0A= > completely blocks Java from completing a TLS handshake. Depending on =0A= > what Java version=2C having 2048-bit DHE ciphersuites enabled does the = =0A= > same thing. =0A= > =0A= > There were two solutions: get the upstream service to eliminate the =0A= > problematic ciphersuites=2C or have the Java client disable DHE. In hopes= =0A= > of getting traffic flowing again=2C I have told both sides to shut off = =0A= > DHE=2C and as soon as either side complied=2C the handshake could complet= e. =0A= > =0A= > What problem do you think this draft is solving? How will it fix older = =0A= > Java clients? =0A= > =0A= > So far my experience has been that shutting off DHE solves the problem. = =0A= > If you want ECC=2C use BouncyCastle as your JCE provider. =0A= > =0A= > Anyway=2C I am responsible for supporting legacy Java 7 (and Java 6!) =0A= > clients and my opinion is that DHE is actively detrimental to the TLS =0A= > ecosystem=2C *especially* where Java is involved. =0A= > =0A= > So I am very=2C very=2C very confused about what argument you're trying t= o =0A= > make about Java here. As far as I'm concerned the *only* workable =0A= > solution for older Java clients is to shut DHE off. =0A= > =0A= > Can you please explain to me where in this draft I can locate the part = =0A= > about how it will help older Java clients better participate in the TLS = =0A= > ecosystem=2C because I can't find it. =0A= > =0A= > -- =0A= > Tony Arcieri =0A= > =0A= > _______________________________________________ TLS mailing list =0A= > TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls =0A= = From nobody Tue Jun 2 23:17: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 2AE5B1B3584 for ; Tue, 2 Jun 2015 23:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, LOTS_OF_MONEY=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 SxxNZ-xUYELy for ; Tue, 2 Jun 2015 23:17:11 -0700 (PDT) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::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 849F31B3569 for ; Tue, 2 Jun 2015 23:17:11 -0700 (PDT) Received: by obbea3 with SMTP id ea3so175494obb.0 for ; Tue, 02 Jun 2015 23:17:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=9EOWWXo1KSy70q3r+YuW5AR4LqIMQ7ruepdAExg+Rh0=; b=OgrjC+OQeDDQYpylVw1Mgy2yaSq1a7k8UETNTeZn213KfldZ6uBHG3oXSEuh73I+Su lYa9L2Q6rrM658AWgPrYwxmGwrO0a9otcGtCCHnyAqjnmUZIhxnbyvI9kfONjGos5CaR hi9bFZIWzIO5jnXCXMI4PY1oXcpUdHTzNk9kw95Dk5UwzrdGLyyvhK1chI58eKTyMpX4 mQOOp1cf1RVO9qJ5T+Q+URkM8sUgtcaz9nqLzT0Q3pyIOT2iAcya7r+92xcUXr6GV8td HNHsOTNGCe6Qt+99cSfHKaITr64A7atxabvT3PTbffXdaW30G9tZEwe/nfgN2m9kCTog HIHw== X-Received: by 10.182.102.2 with SMTP id fk2mr26255813obb.35.1433312231091; Tue, 02 Jun 2015 23:17:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.110.241 with HTTP; Tue, 2 Jun 2015 23:16:50 -0700 (PDT) In-Reply-To: References: <20150601225057.17500.96911.idtracker@ietfa.amsl.com> <1474500.r0W7gM0pAO@pintsize.usersys.redhat.com> From: Tony Arcieri Date: Tue, 2 Jun 2015 23:16:50 -0700 Message-ID: To: Hubert Kario Content-Type: multipart/alternative; boundary=089e013a042062f69a0517970293 Archived-At: Cc: "" Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Jun 2015 06:17:14 -0000 --089e013a042062f69a0517970293 Content-Type: text/plain; charset=UTF-8 Here is what I've observed: Logjam made a lot of people aware of the problem of weak D-H groups. Because of that, people have been trying to enable stronger D-H groups. Unfortunately, exactly as you've pointed out, legacy clients are incompatible with these stronger D-H groups. For legacy Java clients, it catastrophically completely prevents the TLS handshake from succeeding if any such ciphersuite is even present in the ServerHello. My experience has been, and correct me if I'm wrong, that the only two ways to fix this are for the Java client to disable all DHE ciphersuites, or for the server to not offer them. Depend on the Java version, DHE with 2048-bit keys can break it, and for newer versions of Java, the problem persists for 4096-bit DHE. The result I've seen has been people hardening their DH groups in response to Logjam, and inadvertently breaking Java clients... for more than one entire language ecosystem temporarily. On Tue, Jun 2, 2015 at 11:00 PM, Tony Arcieri wrote: > On Tue, Jun 2, 2015 at 5:54 AM, Hubert Kario wrote: > >> as it was pointed out many times: adding support for this extension and >> groups >> to implementations that already support FF DHE is rather trivial, adding >> support for ECC is complex (both because of compexity of ECC and because >> it's >> a completely new set of algorithms) >> >> This allows us to move away from defaulting to 1024bit or 2048bit on >> server >> side in fear of breaking, for example, Java based clients >> > > Hi there, > > Some context. I typically don't go "full blowhard". That's something I > actively avoid. But I feel it's warranted here. > > I am responsible for the external ciphersuites configuration for a site > that moves over a hundred million dollars per day supporting millions of > users. > > I have also spent what I feel are undue amounts of my own time (probably > at least 10 hours in the past month) chasing down DHE problems with Java > stacks, trying to solve problems where entire language ecosystems had a > total outage of their packaging systems due to Java DHE issues. > > My opinion is DHE diediedie. I am sorry if I didn't participate when it > was "pointed out many times". But this is a draft, and I feel like now > isn't an undue time to make a counterargument? > > Even having DHE enabled when 4096-bit DHE ciphersuites are configured > completely blocks Java from completing a TLS handshake. Depending on what > Java version, having 2048-bit DHE ciphersuites enabled does the same thing. > > There were two solutions: get the upstream service to eliminate the > problematic ciphersuites, or have the Java client disable DHE. In hopes of > getting traffic flowing again, I have told both sides to shut off DHE, and > as soon as either side complied, the handshake could complete. > > What problem do you think this draft is solving? How will it fix older > Java clients? > > So far my experience has been that shutting off DHE solves the problem. If > you want ECC, use BouncyCastle as your JCE provider. > > Anyway, I am responsible for supporting legacy Java 7 (and Java 6!) > clients and my opinion is that DHE is actively detrimental to the TLS > ecosystem, *especially* where Java is involved. > > So I am very, very, very confused about what argument you're trying to > make about Java here. As far as I'm concerned the *only* workable solution > for older Java clients is to shut DHE off. > > Can you please explain to me where in this draft I can locate the part > about how it will help older Java clients better participate in the TLS > ecosystem, because I can't find it. > > -- > Tony Arcieri > -- Tony Arcieri --089e013a042062f69a0517970293 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Here is what I've observed:

Logjam = made a lot of people aware of the problem of weak D-H groups. Because of th= at, people have been trying to enable stronger D-H groups.

Unfortunately, exactly as you've pointed out, legacy clients a= re incompatible with these stronger D-H groups. For legacy Java clients, it= catastrophically completely prevents the TLS handshake from succeeding if = any such ciphersuite is even present in the ServerHello.

My experience has been, and correct me if I'm wrong, that the on= ly two ways to fix this are for the Java client to disable all DHE ciphersu= ites, or for the server to not offer them. Depend on the Java version, DHE = with 2048-bit keys can break it, and for newer versions of Java, the proble= m persists for 4096-bit DHE.

The result I've s= een has been people hardening their DH groups in response to Logjam, and in= advertently breaking Java clients... for more than one entire language ecos= ystem temporarily.



On Tue, Jun 2, 2015 at 11:00 PM,= Tony Arcieri <bascule@gmail.com> wrote:
On Tue, Jun 2, 2015 at 5:54 AM, Hubert Kario <= hkario@redhat.com> wrote:
a= s it was pointed out many times: adding support for this extension and grou= ps
to implementations that already support FF DHE is rather trivial, adding support for ECC is complex (both because of compexity of ECC and because it= 's
a completely new set of algorithms)

This allows us to move away from defaulting to 1024bit or 2048bit on server=
side in fear of breaking, for example, Java based clients
<= div>
Hi there,

Some context. = I typically don't go "full blowhard". That's something I = actively avoid. But I feel it's warranted here.

I am responsible for the external ciphersuites configuration for a site t= hat moves over a hundred million dollars per day supporting millions of use= rs.

I have also spent what I feel are undue amount= s of my own time (probably at least 10 hours in the past month) chasing dow= n DHE problems with Java stacks, trying to solve problems where entire lang= uage ecosystems had a total outage of their packaging systems due to Java D= HE issues.

My opinion is DHE diediedie. I am sorry= if I didn't participate when it was "pointed out many times"= . But this is a draft, and I feel like now isn't an undue time to make = a counterargument?

Even having DHE enabled when 40= 96-bit DHE ciphersuites are configured completely blocks Java from completi= ng a TLS handshake. Depending on what Java version, having 2048-bit DHE cip= hersuites enabled does the same thing.

There were = two solutions: get the upstream service to eliminate the problematic cipher= suites, or have the Java client disable DHE. In hopes of getting traffic fl= owing again, I have told both sides to shut off DHE, and as soon as either = side complied, the handshake could complete.

What = problem do you think this draft is solving? How will it fix older Java clie= nts?

So far my experience has been that shutting o= ff DHE solves the problem. If you want ECC, use BouncyCastle as your JCE pr= ovider.

Anyway, I am responsible for supporting le= gacy Java 7 (and Java 6!) clients and my opinion is that DHE is actively de= trimental to the TLS ecosystem, *especially* where Java is involved.
<= div>
So I am very, very, very confused about what argument yo= u're trying to make about Java here. As far as I'm concerned the *o= nly* workable solution for older Java clients is to shut DHE off.

Can you please explain to me where in this draft I can loca= te the part about how it will help older Java clients better participate in= the TLS ecosystem, because I can't find it.

--
Tony Arcieri



--
Tony Arcieri
--089e013a042062f69a0517970293-- From nobody Tue Jun 2 23:20: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 A15C91B358B for ; Tue, 2 Jun 2015 23:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QEGsb2snmjW for ; Tue, 2 Jun 2015 23:20:24 -0700 (PDT) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003: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 388BC1B357E for ; Tue, 2 Jun 2015 23:20:24 -0700 (PDT) Received: by obbea3 with SMTP id ea3so220082obb.0 for ; Tue, 02 Jun 2015 23:20:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=9gyxAX+xHSOj3V7c7IiYkOaKxC/BKDdqLQGpNOz/clE=; b=kvTEfXIy4M2hQhNF7Bdw9NASzfojPyUBynEyVW9SniFfOHwsAj/RVIiSs7HQXkd7cq oMD+8TF6aeDOhUVZtvuPdaJLir5D3gbNsr1hE1Bf/qIsUIm4XAInlFiuoubUd3MLoXaw sNisZvU4o65Bnp2BRLbVrG515DR7e7aiwbyXcldXnCNwcFhLKD0UJeD1ujRca0CrDTat rXQjHMiwrLOGClV9iGuMMmZTpGYbyEi+PjJe0lupXKg8WC412n3YcWzywGB+HQg5W0Nj 2//MiXBeEKE/d1pm0iG1Fgs6SZ5iqr21iA22Ub4tGvmxEnyxFaJ2h/UHT5rR+tSSvCtd NRXQ== X-Received: by 10.202.52.138 with SMTP id b132mr24521371oia.125.1433312423686; Tue, 02 Jun 2015 23:20:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.110.241 with HTTP; Tue, 2 Jun 2015 23:20:03 -0700 (PDT) In-Reply-To: References: <20150601225057.17500.96911.idtracker@ietfa.amsl.com> <1474500.r0W7gM0pAO@pintsize.usersys.redhat.com> From: Tony Arcieri Date: Tue, 2 Jun 2015 23:20:03 -0700 Message-ID: To: Yuhong Bao Content-Type: multipart/alternative; boundary=001a113d3e02ddb9b00517970d63 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Jun 2015 06:20:25 -0000 --001a113d3e02ddb9b00517970d63 Content-Type: text/plain; charset=UTF-8 On Tue, Jun 2, 2015 at 11:15 PM, Yuhong Bao wrote: > These older versions of Java don't support FF-DHE, and the server can send > a different weaker DHE key to older clients. As I have "pointed out many times", yes there are ways to work around these problems, but DHE hardening is presently actively breaking TLS ecosystem. And for what? Finite field D-H is taking attention away from ECC, and I think ECC is clearly the future. What good reason is there for continuing to support it instead of focusing on ECDH? I want a TLS ecosystem with less workarounds, less errata, and less complexity. I see no reason to keep DHE around. -- Tony Arcieri --001a113d3e02ddb9b00517970d63 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jun 2, 2015 at 11:15 PM, Yuhong Bao <yuhongbao_386@hotmail.com> wrote:
These older versions of Java don't support FF-DHE, and the= server can send a different weaker DHE key to older clients.<= div>
As I have "pointed out many times", yes there are ways to work around these = problems, but DHE hardening is presently actively breaking TLS ecosystem. A= nd for what?
=
Finite f= ield D-H is taking attention away from ECC, and I think ECC is clearly the = future. What good reason is there for continuing to support it instead of f= ocusing on ECDH?

I wa= nt a TLS ecosystem with less workarounds, less errata, and less complexity.= I see no reason to keep DHE around.

--
Tony Arcieri
--001a113d3e02ddb9b00517970d63-- From nobody Tue Jun 2 23:32: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 39E841B359A for ; Tue, 2 Jun 2015 23:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-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 mABjz9KBVRvv for ; Tue, 2 Jun 2015 23:32:12 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [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 2BB461B357A for ; Tue, 2 Jun 2015 23:32:12 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 6D24233D1E3; Wed, 3 Jun 2015 06:32:11 +0000 (UTC) Sender: geoffk@localhost.localdomain To: Tony Arcieri References: <20150601225057.17500.96911.idtracker@ietfa.amsl.com> <1474500.r0W7gM0pAO@pintsize.usersys.redhat.com> From: Geoffrey Keating Date: 02 Jun 2015 23:32:11 -0700 In-Reply-To: Message-ID: Lines: 31 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 WG Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Jun 2015 06:32:13 -0000 Tony Arcieri writes: > So I am very, very, very confused about what argument you're trying to make > about Java here. As far as I'm concerned the *only* workable solution for > older Java clients is to shut DHE off. > > Can you please explain to me where in this draft I can locate the part > about how it will help older Java clients better participate in the TLS > ecosystem, because I can't find it. It's covered in section 4: If at least one FFDHE ciphersuite is present in the client ciphersuite list, and the Supported Groups extension is either absent from the ClientHello entirely or contains no FFDHE groups (i.e. no codepoints between 256 and 511 inclusive), then the server knows that the client is not compatible with this document. In this scenario, a server MAY select a non-FFDHE ciphersuite, or MAY select an FFDHE ciphersuite and offer an FFDHE group of its choice to the client as part of a traditional ServerKeyExchange. In this case, and I think most of the time, a server should choose the first of the two MAYs: offer a non-FFDHE ciphersuite. This has the effect of shutting FFDHE off for those older clients but allows you to continue to offer stronger FFDHE to newer clients (if they for some reason won't do ECDHE). The old-client compatibility story with this draft is quite strong. Alas the old-server compatibility story is not so strong; a new client with an old server might get proposed an insecurely small FFDHE field, and have to reject it and reconnect. From nobody Tue Jun 2 23:36: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 A73291B35A6 for ; Tue, 2 Jun 2015 23:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6LSOMuHxnTW for ; Tue, 2 Jun 2015 23:36:09 -0700 (PDT) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (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 65DA61B35A7 for ; Tue, 2 Jun 2015 23:36:07 -0700 (PDT) Received: by obcnx10 with SMTP id nx10so390296obc.2 for ; Tue, 02 Jun 2015 23:36:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=oaBeM0OxZH5hWHtPcsXq5wH9FwwTGgqj7qO9gvTiAfY=; b=iK9QWGs/YNigN2mLjPr+s6/UCtSpFUC/BQB9r3CFOs6ttNMP4TCuyPeoqwOvejvX/n Llg+c17kHqlTSpOX/f6KFXr8G66y8ALpCk5L3J86LAWlHkG1wzSM15MKkBgfvqjZ8hFN jYPDZn33voy80/tbfIisp1145n5pBDKApa9Z9WfP0PfKNyXAsyqvc4KVlrlgpcalYFSh cZNfEveO7tkcMihkn3WOMLs8kEM0NIguP9ZLu7cNJ6fODxZDxVuNFrOxZ+eWUj/DlTOG DufiKYW7GEY6rqMLBmfNhAVlYbaliBABxPtx3MTMvt2FJDfTgqEWf7zq125WpuR0ShRg L/kQ== X-Received: by 10.202.210.80 with SMTP id j77mr24458983oig.68.1433313366901; Tue, 02 Jun 2015 23:36:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.110.241 with HTTP; Tue, 2 Jun 2015 23:35:46 -0700 (PDT) In-Reply-To: References: <20150601225057.17500.96911.idtracker@ietfa.amsl.com> <1474500.r0W7gM0pAO@pintsize.usersys.redhat.com> From: Tony Arcieri Date: Tue, 2 Jun 2015 23:35:46 -0700 Message-ID: To: Geoffrey Keating Content-Type: multipart/alternative; boundary=001a113d2656160c4705179746fb Archived-At: Cc: TLS WG Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Jun 2015 06:36:10 -0000 --001a113d2656160c4705179746fb Content-Type: text/plain; charset=UTF-8 On Tue, Jun 2, 2015 at 11:32 PM, Geoffrey Keating wrote: > It's covered in section 4: > > If at least one FFDHE ciphersuite is present in the client > ciphersuite list, and the Supported Groups extension is either absent > from the ClientHello Unless I'm mistaken, unless you configure the jdk.tls.disabledAlgorithms property explicitly (with e.g. "DHE keySize > 2048"), Java clients are aborting *before* they send the ClientHello. Please let me know if you're seeing otherwise. I could be mistaken and perhaps there's a server-side workaround for this that isn't "disable all DHE ciphersuites". But this is what I've personally observed and have been advising people about. I'm not saying it can't be fixed with additional configuration/errata/etc, I'm arguing that it's *breaking clients in the field right now* tl;dr: I am seeing *widespread TLS breakages* because of this resulting in *huge outages* for Java clients -- Tony Arcieri --001a113d2656160c4705179746fb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jun 2, 2015 at 11:32 PM, Geoffrey Keating <geoffk@geoffk.org> wrote:
It= 9;s covered in section 4:

=C2=A0 =C2=A0If at least one FFDHE ciphersuite is present in the client
=C2=A0 =C2=A0ciphersuite list, and the Supported Groups extension is either= absent
=C2=A0 =C2=A0from the ClientHello

Unless I&= #39;m mistaken, unless you configure the jdk.tls.disabledAlgorithms propert= y explicitly (with e.g.=C2=A0"DHE keySize > 2048"), Java clien= ts are aborting *before* they send the ClientHello. Please let me know if y= ou're seeing otherwise. I could be mistaken and perhaps there's a s= erver-side workaround for this that isn't "disable all DHE ciphers= uites". But this is what I've personally observed and have been ad= vising people about.

I'm not saying it can'= ;t be fixed with additional configuration/errata/etc, I'm arguing that = it's *breaking clients in the field right now*

tl;dr: I am seeing *widespread TLS breakages* because of this result= ing in *huge outages* for Java clients

--
Tony Arcieri
--001a113d2656160c4705179746fb-- From nobody Tue Jun 2 23:38: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 927F11B35B9 for ; Tue, 2 Jun 2015 23:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKvH0d5_WwQl for ; Tue, 2 Jun 2015 23:38:19 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::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 1FF4A1B35B6 for ; Tue, 2 Jun 2015 23:38:19 -0700 (PDT) Received: by oifu123 with SMTP id u123so424233oif.1 for ; Tue, 02 Jun 2015 23:38:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=6Ur/vP2QL0dZsjL8AOLhvYLa1mFHlxEw8G4GRFSMjzA=; b=xuCbqUusPZtXDDJEfYcXL9BtarA2RdLurYXnKigv28P4hYbZQfFoDcbi0+lkrMiyw4 NBdjouWvIez06Y8zTIk0S4GSO4NUEcy27cjlcgTpJKBOnta+pT0v0pJY1xvMEh8Igiut YFaENB2+EmXuT5wcNZy/WSNOjJA1b1DNVe2qYRlfk8WGWGxSDAO0VgHuM3doOcfOy4iL RzR8AliAchJYpCRxmPIONsOXbbddmah2Nae3cQ9DsUsywYmtfjv21WzU8u/Ij3YvjKLi hyzVAeTT1UWnMd5T9y79ljWyTom4LZZmnUDFwhHXv7equDvUtBlygCMAnorzl0k0halu iiPg== X-Received: by 10.202.1.197 with SMTP id 188mr24054307oib.13.1433313498609; Tue, 02 Jun 2015 23:38:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.110.241 with HTTP; Tue, 2 Jun 2015 23:37:24 -0700 (PDT) In-Reply-To: References: <20150601225057.17500.96911.idtracker@ietfa.amsl.com> <1474500.r0W7gM0pAO@pintsize.usersys.redhat.com> From: Tony Arcieri Date: Tue, 2 Jun 2015 23:37:24 -0700 Message-ID: To: Geoffrey Keating Content-Type: multipart/alternative; boundary=001a1137c6b6efbe2b0517974dce Archived-At: Cc: TLS WG Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Jun 2015 06:38:20 -0000 --001a1137c6b6efbe2b0517974dce Content-Type: text/plain; charset=UTF-8 The error is specifically: Java::JavaLang::RuntimeException: Could not generate DH keypair On Tue, Jun 2, 2015 at 11:35 PM, Tony Arcieri wrote: > On Tue, Jun 2, 2015 at 11:32 PM, Geoffrey Keating > wrote: > >> It's covered in section 4: >> >> If at least one FFDHE ciphersuite is present in the client >> ciphersuite list, and the Supported Groups extension is either absent >> from the ClientHello > > > Unless I'm mistaken, unless you configure the jdk.tls.disabledAlgorithms > property explicitly (with e.g. "DHE keySize > 2048"), Java clients are > aborting *before* they send the ClientHello. Please let me know if you're > seeing otherwise. I could be mistaken and perhaps there's a server-side > workaround for this that isn't "disable all DHE ciphersuites". But this is > what I've personally observed and have been advising people about. > > I'm not saying it can't be fixed with additional configuration/errata/etc, > I'm arguing that it's *breaking clients in the field right now* > > tl;dr: I am seeing *widespread TLS breakages* because of this resulting in > *huge outages* for Java clients > > -- > Tony Arcieri > -- Tony Arcieri --001a1137c6b6efbe2b0517974dce Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The error is specifically:

Java::JavaLa=
ng::RuntimeException: Could not generate DH keypair

On Tue, Jun 2, 2= 015 at 11:35 PM, Tony Arcieri <bascule@gmail.com> wrote:
=
=
On Tue, Jun 2, 2015 at 11:32 PM= , Geoffrey Keating <geoffk@geoffk.org> wrote:
It's covered in section 4:

=C2=A0 =C2=A0If at least one FFDHE ciphersuite is present in the client
=C2=A0 =C2=A0ciphersuite list, and the Supported Groups extension is either= absent
=C2=A0 =C2=A0from the ClientHello

Un= less I'm mistaken, unless you configure the jdk.tls.disabledAlgorithms = property explicitly (with e.g.=C2=A0"DHE keySize > 2048"), Jav= a clients are aborting *before* they send the ClientHello. Please let me kn= ow if you're seeing otherwise. I could be mistaken and perhaps there= 9;s a server-side workaround for this that isn't "disable all DHE = ciphersuites". But this is what I've personally observed and have = been advising people about.

I'm not saying it = can't be fixed with additional configuration/errata/etc, I'm arguin= g that it's *breaking clients in the field right now*
<= br>
tl;dr: I am seeing *widespread TLS breakages* because of this= resulting in *huge outages* for Java clients
<= font color=3D"#888888">

--
Tony Arcieri



--
Tony Arcieri
--001a1137c6b6efbe2b0517974dce-- From nobody Tue Jun 2 23:44: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 301E21B35C7 for ; Tue, 2 Jun 2015 23:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0a6cVm7c7YDk for ; Tue, 2 Jun 2015 23:44:09 -0700 (PDT) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003: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 959A81B35C3 for ; Tue, 2 Jun 2015 23:44:09 -0700 (PDT) Received: by obcnx10 with SMTP id nx10so503564obc.2 for ; Tue, 02 Jun 2015 23:44:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=7h859DlhjQXbkbcW6mpqlrqKNMDhbSep8L1KtfU0FUQ=; b=DIDFrXUIXLxsC1Dlrcom7kCvhi1EwTZWqh8qkxLZjFZuD3qVUd1SmQNOSuec5395NT wlf1SlpKVTlINMMxtWTjxUl2WB9zbT8Dbcz7a2ljsoMI1rG35ahwT7ku8gyhsCvILlYA zaG/9hnXP2Y0zN0YEXvk0WC9VzwoPPqx30RWFWFsE/VJ/6cVgFV5oxCwJfhU/cJOZppu vDIVKI+1L2p5zC+B2X6U+i7mm3sWJzg3VG2Q8unmBQGy2Uy2QWvwpIz/Dmbt5jVIXKrF dFWS4Y3NGPkvD0WrVmOI60WiMfPvqcipqhAaDpVQynZiWOit3zTEs3I/WwPGGMuCoO8y SbMA== X-Received: by 10.202.52.138 with SMTP id b132mr24588746oia.125.1433313849176; Tue, 02 Jun 2015 23:44:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.110.241 with HTTP; Tue, 2 Jun 2015 23:43:48 -0700 (PDT) In-Reply-To: References: <20150601225057.17500.96911.idtracker@ietfa.amsl.com> <1474500.r0W7gM0pAO@pintsize.usersys.redhat.com> From: Tony Arcieri Date: Tue, 2 Jun 2015 23:43:48 -0700 Message-ID: To: Geoffrey Keating Content-Type: multipart/alternative; boundary=001a113d3e02d4f8080517976241 Archived-At: Cc: TLS WG Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Jun 2015 06:44:11 -0000 --001a113d3e02d4f8080517976241 Content-Type: text/plain; charset=UTF-8 A more typical Java stack trace for this problem: Caused by: java.lang.RuntimeException: Could not generate DH keypair at com.sun.net.ssl.internal.ssl.DHCrypt.(DHCrypt.java:106) at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverKeyExchange(ClientHandshaker.java:556) On Tue, Jun 2, 2015 at 11:37 PM, Tony Arcieri wrote: > The error is specifically: > > Java::JavaLang::RuntimeException: Could not generate DH keypair > > > On Tue, Jun 2, 2015 at 11:35 PM, Tony Arcieri wrote: > >> On Tue, Jun 2, 2015 at 11:32 PM, Geoffrey Keating >> wrote: >> >>> It's covered in section 4: >>> >>> If at least one FFDHE ciphersuite is present in the client >>> ciphersuite list, and the Supported Groups extension is either absent >>> from the ClientHello >> >> >> Unless I'm mistaken, unless you configure the jdk.tls.disabledAlgorithms >> property explicitly (with e.g. "DHE keySize > 2048"), Java clients are >> aborting *before* they send the ClientHello. Please let me know if you're >> seeing otherwise. I could be mistaken and perhaps there's a server-side >> workaround for this that isn't "disable all DHE ciphersuites". But this is >> what I've personally observed and have been advising people about. >> >> I'm not saying it can't be fixed with additional >> configuration/errata/etc, I'm arguing that it's *breaking clients in the >> field right now* >> >> tl;dr: I am seeing *widespread TLS breakages* because of this resulting >> in *huge outages* for Java clients >> >> -- >> Tony Arcieri >> > > > > -- > Tony Arcieri > -- Tony Arcieri --001a113d3e02d4f8080517976241 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
A more typical Java stack trace for this problem:

=
Caused by: java.lang.RuntimeException: Could not generate DH keypair<= br>=C2=A0 =C2=A0 at com.sun.net.ssl.internal.ssl.DHCrypt.<init>(DHCry= pt.java:106)
=C2=A0 =C2=A0 at com.sun.net.ssl.internal.ssl.ClientHandsha= ker.serverKeyExchange(ClientHandshaker.java:556)

On Tue, Jun 2, 2015 at 11:37 PM, T= ony Arcieri <bascule@gmail.com> wrote:
The error is specifically:

=
Java::JavaLang::RuntimeException: Could not generate DH keypair

On Tue, Jun 2, 2015 at 11:35 PM, Tony Arcieri <bascule= @gmail.com> wrote:
On Tue= , Jun 2, 2015 at 11:32 PM, Geoffrey Keating <geoffk@geoffk.org> wrote:
It's covered in section 4:

=C2=A0 =C2=A0If at least one FFDHE ciphersuite is present in the client
=C2=A0 =C2=A0ciphersuite list, and the Supported Groups extension is either= absent
=C2=A0 =C2=A0from the ClientHello

Un= less I'm mistaken, unless you configure the jdk.tls.disabledAlgorithms = property explicitly (with e.g.=C2=A0"DHE keySize > 2048"), Jav= a clients are aborting *before* they send the ClientHello. Please let me kn= ow if you're seeing otherwise. I could be mistaken and perhaps there= 9;s a server-side workaround for this that isn't "disable all DHE = ciphersuites". But this is what I've personally observed and have = been advising people about.

I'm not saying it = can't be fixed with additional configuration/errata/etc, I'm arguin= g that it's *breaking clients in the field right now*
<= br>
tl;dr: I am seeing *widespread TLS breakages* because of this= resulting in *huge outages* for Java clients

--
Tony Arcieri



--
Tony Arcieri



--
Tony Arcieri
--001a113d3e02d4f8080517976241-- From nobody Tue Jun 2 23:52: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 B79D41B35D9 for ; Tue, 2 Jun 2015 23:52:10 -0700 (PDT) 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 8-wn3hGsYGWQ for ; Tue, 2 Jun 2015 23:52:09 -0700 (PDT) Received: from BLU004-OMC2S23.hotmail.com (blu004-omc2s23.hotmail.com [65.55.111.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F57A1B35CD for ; Tue, 2 Jun 2015 23:52:08 -0700 (PDT) Received: from BLU177-W1 ([65.55.111.72]) by BLU004-OMC2S23.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Tue, 2 Jun 2015 23:52:07 -0700 X-TMN: [lzO4GMUdV33WUHBy+khQZb37eFHtyoIo] X-Originating-Email: [yuhongbao_386@hotmail.com] Message-ID: From: Yuhong Bao To: Tony Arcieri , Geoffrey Keating Date: Tue, 2 Jun 2015 23:52:07 -0700 Importance: Normal In-Reply-To: References: <20150601225057.17500.96911.idtracker@ietfa.amsl.com>, , <1474500.r0W7gM0pAO@pintsize.usersys.redhat.com>, , , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 03 Jun 2015 06:52:07.0450 (UTC) FILETIME=[CEA2AFA0:01D09DC9] Archived-At: Cc: TLS WG Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Jun 2015 06:52:10 -0000 The client don't receive the ServerKeyExchange message containing the DHE k= ey at all until after they sent the ClientHello.=0A= =0A= ________________________________=0A= > From: bascule@gmail.com =0A= > Date: Tue=2C 2 Jun 2015 23:35:46 -0700 =0A= > To: geoffk@geoffk.org =0A= > CC: tls@ietf.org =0A= > Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt = =0A= > =0A= > On Tue=2C Jun 2=2C 2015 at 11:32 PM=2C Geoffrey Keating =0A= > > wrote: =0A= > It's covered in section 4: =0A= > =0A= > If at least one FFDHE ciphersuite is present in the client =0A= > ciphersuite list=2C and the Supported Groups extension is either absent = =0A= > from the ClientHello =0A= > =0A= > Unless I'm mistaken=2C unless you configure the =0A= > jdk.tls.disabledAlgorithms property explicitly (with e.g. "DHE keySize = =0A= >> 2048")=2C Java clients are aborting *before* they send the ClientHello. = =0A= > Please let me know if you're seeing otherwise. I could be mistaken and = =0A= > perhaps there's a server-side workaround for this that isn't "disable =0A= > all DHE ciphersuites". But this is what I've personally observed and =0A= > have been advising people about. =0A= > =0A= > I'm not saying it can't be fixed with additional =0A= > configuration/errata/etc=2C I'm arguing that it's *breaking clients in = =0A= > the field right now* =0A= > =0A= > tl=3Bdr: I am seeing *widespread TLS breakages* because of this resulting= =0A= > in *huge outages* for Java clients =0A= > =0A= > -- =0A= > Tony Arcieri =0A= > =0A= > _______________________________________________ TLS mailing list =0A= > TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls =0A= = From nobody Tue Jun 2 23:53: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 26BB61B35D8 for ; Tue, 2 Jun 2015 23:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5WzoLhq1VAY for ; Tue, 2 Jun 2015 23:52:57 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (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 491001B35DB for ; Tue, 2 Jun 2015 23:52:57 -0700 (PDT) Received: by oiww2 with SMTP id w2so643268oiw.0 for ; Tue, 02 Jun 2015 23:52:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=qkAXF8DhEtw4E5In0t/YvWQmCxw81kIG+etI4eOUJxA=; b=hOe+BHaIBPe2MLqWvvH1THK2I5+hiT0GnuZVoCv5ySCFECJ6uVVa+yZHCq3zCOGvZ1 I5lLuiZA/8j6/wMP9ZVIuhEocHoZVFJflyjmApzw9dyDBSR2qRat0O0oX1HjqNNQYIrW Hzpnj4ZqBH+TGtVtJG/ABYGr5MDvAQ0KqzJ9SjEhIhA73/7mDPZq8MZnkBNNLiGpqlPx fQ/XrmBElXzZVa3qEHGlyLEbM6bMdMHuMa4Feo7ILnWw+MVpAMYf40BDN4sn6LKpX420 41yzRk+6XX0U5L5KR4u3PvxF7sOZKmyOFDVIIT+zPGWsxOyenUytYMoLPEEP6CwYIQlH r/Pw== X-Received: by 10.202.210.80 with SMTP id j77mr24505782oig.68.1433314376652; Tue, 02 Jun 2015 23:52:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.110.241 with HTTP; Tue, 2 Jun 2015 23:52:36 -0700 (PDT) In-Reply-To: References: <20150601225057.17500.96911.idtracker@ietfa.amsl.com> <1474500.r0W7gM0pAO@pintsize.usersys.redhat.com> From: Tony Arcieri Date: Tue, 2 Jun 2015 23:52:36 -0700 Message-ID: To: Yuhong Bao Content-Type: multipart/alternative; boundary=001a113d2656459ef305179782ac Archived-At: Cc: Geoffrey Keating , TLS WG Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Jun 2015 06:52:59 -0000 --001a113d2656459ef305179782ac Content-Type: text/plain; charset=UTF-8 Yes sorry I meant ClientKeyExchange... But can you explain to me how this solves the problem for legacy clients? On Tue, Jun 2, 2015 at 11:52 PM, Yuhong Bao wrote: > The client don't receive the ServerKeyExchange message containing the DHE > key at all until after they sent the ClientHello. > > ________________________________ > > From: bascule@gmail.com > > Date: Tue, 2 Jun 2015 23:35:46 -0700 > > To: geoffk@geoffk.org > > CC: tls@ietf.org > > Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt > > > > On Tue, Jun 2, 2015 at 11:32 PM, Geoffrey Keating > > > wrote: > > It's covered in section 4: > > > > If at least one FFDHE ciphersuite is present in the client > > ciphersuite list, and the Supported Groups extension is either absent > > from the ClientHello > > > > Unless I'm mistaken, unless you configure the > > jdk.tls.disabledAlgorithms property explicitly (with e.g. "DHE keySize > >> 2048"), Java clients are aborting *before* they send the ClientHello. > > Please let me know if you're seeing otherwise. I could be mistaken and > > perhaps there's a server-side workaround for this that isn't "disable > > all DHE ciphersuites". But this is what I've personally observed and > > have been advising people about. > > > > I'm not saying it can't be fixed with additional > > configuration/errata/etc, I'm arguing that it's *breaking clients in > > the field right now* > > > > tl;dr: I am seeing *widespread TLS breakages* because of this resulting > > in *huge outages* for Java clients > > > > -- > > Tony Arcieri > > > > _______________________________________________ TLS mailing list > > TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls > > -- Tony Arcieri --001a113d2656459ef305179782ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes sorry I meant ClientKeyExchange...

= But can you explain to me how this solves the problem for legacy clients?

On Tue,= Jun 2, 2015 at 11:52 PM, Yuhong Bao <yuhongbao_386@hotmail.com> wrote:
The client don't = receive the ServerKeyExchange message containing the DHE key at all until a= fter they sent the ClientHello.

________________________________
> From: bascule@gmail.com
> Date: Tue, 2 Jun 2015 23:35:46 -0700
> To: geoffk@geoffk.org
> CC: tls@ietf= .org
> Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt=
>
> On Tue, Jun 2, 2015 at 11:32 PM, Geof= frey Keating
> <geoffk@geoffk.org<mailto:geoffk@geoffk.org>> wrote:
> It's covered in section 4:
>
> If at least one FFDHE ciphersuite is present in the client
> ciphersuite list, and the Supported Groups extension is either absent<= br> > from the ClientHello
>
> Unless I'm mistaken, unless you configure the
> jdk.tls.disabledAlgorithms property explicitly (with e.g. "DHE ke= ySize
>> 2048"), Java clients are aborting *before* they send the Clie= ntHello.
> Please let me know if you're seeing otherwise. I could be mistaken= and
> perhaps there's a server-side workaround for this that isn't &= quot;disable
> all DHE ciphersuites". But this is what I've personally obser= ved and
> have been advising people about.
>
> I'm not saying it can't be fixed with additional
> configuration/errata/etc, I'm arguing that it's *breaking clie= nts in
> the field right now*
>
> tl;dr: I am seeing *widespread TLS breakages* because of this resultin= g
> in *huge outages* for Java clients
>
> --
> Tony Arcieri
>
> __________________= _____________________________ TLS mailing list
> TLS@ietf.org https://www.ietf.org/mai= lman/listinfo/tls
=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=A0 =C2=A0 <= /div>



--
<= div class=3D"gmail_signature">Tony Arcieri
--001a113d2656459ef305179782ac-- From nobody Tue Jun 2 23:53: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 24F381B35DD for ; Tue, 2 Jun 2015 23:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRFSZRwm-44d for ; Tue, 2 Jun 2015 23:53:52 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (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 065F01B35D6 for ; Tue, 2 Jun 2015 23:53:52 -0700 (PDT) Received: by oiww2 with SMTP id w2so655180oiw.0 for ; Tue, 02 Jun 2015 23:53:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=SWtbzHOcLnaL2/tYE1FSy2GoLAXfwj44myb1f04yTGo=; b=o6JiaW96MY4gqDJ4okLl8ffuSienu+b8fEER64XXu6cVUUr2tKqJgd6audRej9msJl 8EwZT5wIxKNpgKPy7AqWyrt/K29vYwsBoyxO6/r6uR/yu8vyZmW01Cstz4RtGHxcKFAC Lu6UDMS/3s/Y13Vz+YX7DX15mDdJ1ZeD++cB7yIHmMI6pCPQzm1ztjtaiWZO28LRruBU qzro4POXcBx/P7lEKV3c2ei0rywsBnS/xOm4CRIFRXPNgopBhVVkgSCam6cxZOGOMCc6 5uYQn1h/ZgrcVE0LwwZsULtX6p6NWshIRgdLeJiEQzqYKSfc4Lqk9iGaVRmcDW2wcG2H NIpA== X-Received: by 10.60.123.116 with SMTP id lz20mr10904612oeb.82.1433314431544; Tue, 02 Jun 2015 23:53:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.110.241 with HTTP; Tue, 2 Jun 2015 23:53:31 -0700 (PDT) In-Reply-To: References: <20150601225057.17500.96911.idtracker@ietfa.amsl.com> <1474500.r0W7gM0pAO@pintsize.usersys.redhat.com> From: Tony Arcieri Date: Tue, 2 Jun 2015 23:53:31 -0700 Message-ID: To: Yuhong Bao Content-Type: multipart/alternative; boundary=047d7b5d60068b314d051797851c Archived-At: Cc: Geoffrey Keating , TLS WG Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Jun 2015 06:53:57 -0000 --047d7b5d60068b314d051797851c Content-Type: text/plain; charset=UTF-8 Perhaps you have a test case with a Java 6 or 7 client using the Sun/Oracle JCE provider? What *actually* happens there? On Tue, Jun 2, 2015 at 11:52 PM, Tony Arcieri wrote: > Yes sorry I meant ClientKeyExchange... > > But can you explain to me how this solves the problem for legacy clients? > > On Tue, Jun 2, 2015 at 11:52 PM, Yuhong Bao > wrote: > >> The client don't receive the ServerKeyExchange message containing the DHE >> key at all until after they sent the ClientHello. >> >> ________________________________ >> > From: bascule@gmail.com >> > Date: Tue, 2 Jun 2015 23:35:46 -0700 >> > To: geoffk@geoffk.org >> > CC: tls@ietf.org >> > Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt >> > >> > On Tue, Jun 2, 2015 at 11:32 PM, Geoffrey Keating >> > > wrote: >> > It's covered in section 4: >> > >> > If at least one FFDHE ciphersuite is present in the client >> > ciphersuite list, and the Supported Groups extension is either absent >> > from the ClientHello >> > >> > Unless I'm mistaken, unless you configure the >> > jdk.tls.disabledAlgorithms property explicitly (with e.g. "DHE keySize >> >> 2048"), Java clients are aborting *before* they send the ClientHello. >> > Please let me know if you're seeing otherwise. I could be mistaken and >> > perhaps there's a server-side workaround for this that isn't "disable >> > all DHE ciphersuites". But this is what I've personally observed and >> > have been advising people about. >> > >> > I'm not saying it can't be fixed with additional >> > configuration/errata/etc, I'm arguing that it's *breaking clients in >> > the field right now* >> > >> > tl;dr: I am seeing *widespread TLS breakages* because of this resulting >> > in *huge outages* for Java clients >> > >> > -- >> > Tony Arcieri >> > >> > _______________________________________________ TLS mailing list >> > TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls >> >> > > > > -- > Tony Arcieri > -- Tony Arcieri --047d7b5d60068b314d051797851c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Perhaps you have a test case with a Java 6 or 7 client usi= ng the Sun/Oracle JCE provider? What *actually* happens there?

On Tue, Jun 2, 2015 at 1= 1:52 PM, Tony Arcieri <bascule@gmail.com> wrote:
Yes sorry I meant ClientKeyExchange= ...

But can you explain to me how this solves the proble= m for legacy clients?

On Tue, Jun 2, 2015 at 11:52 PM, Yuh= ong Bao <yuhongbao_386@hotmail.com> wrote:
The client don't receive the ServerKeyExchange= message containing the DHE key at all until after they sent the ClientHell= o.

________________________________
> From: bascule@g= mail.com
> Date: Tue, 2 Jun 2015 23:35:46 -0700
> To: geoffk@geof= fk.org
> CC: tls@ietf.o= rg
> Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt=
>
> On Tue, Jun 2, 2015 at 11:32 PM, Geoffrey Keating
> <geoffk@geoffk.org<mailto:geoffk@geoffk.org>> wrote:
> It's covered in section 4:
>
> If at least one FFDHE ciphersuite is present in the client
> ciphersuite list, and the Supported Groups extension is either absent<= br> > from the ClientHello
>
> Unless I'm mistaken, unless you configure the
> jdk.tls.disabledAlgorithms property explicitly (with e.g. "DHE ke= ySize
>> 2048"), Java clients are aborting *before* they send the Clie= ntHello.
> Please let me know if you're seeing otherwise. I could be mistaken= and
> perhaps there's a server-side workaround for this that isn't &= quot;disable
> all DHE ciphersuites". But this is what I've personally obser= ved and
> have been advising people about.
>
> I'm not saying it can't be fixed with additional
> configuration/errata/etc, I'm arguing that it's *breaking clie= nts in
> the field right now*
>
> tl;dr: I am seeing *widespread TLS breakages* because of this resultin= g
> in *huge outages* for Java clients
>
> --
> Tony Arcieri
>
> _______________________________________________ = TLS mailing list
> TLS@ietf.org https:= //www.ietf.org/mailman/listinfo/tls
=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=A0 =C2=A0 <= /div>



--
Tony Arcieri=



--
Tony Arcieri
--047d7b5d60068b314d051797851c-- From nobody Tue Jun 2 23:54: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 9EDE71B35E6 for ; Tue, 2 Jun 2015 23:54:53 -0700 (PDT) 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 RqyIKXaHB--t for ; Tue, 2 Jun 2015 23:54:52 -0700 (PDT) Received: from BLU004-OMC2S5.hotmail.com (blu004-omc2s5.hotmail.com [65.55.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5060A1B35D6 for ; Tue, 2 Jun 2015 23:54:52 -0700 (PDT) Received: from BLU177-W1 ([65.55.111.71]) by BLU004-OMC2S5.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Tue, 2 Jun 2015 23:54:51 -0700 X-TMN: [sOYE/sM98Z8LtlkiTVsume11ri+nNqDt] X-Originating-Email: [yuhongbao_386@hotmail.com] Message-ID: From: Yuhong Bao To: Tony Arcieri Date: Tue, 2 Jun 2015 23:54:50 -0700 Importance: Normal In-Reply-To: References: <20150601225057.17500.96911.idtracker@ietfa.amsl.com>, , <1474500.r0W7gM0pAO@pintsize.usersys.redhat.com> , , , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 03 Jun 2015 06:54:51.0110 (UTC) FILETIME=[302F3860:01D09DCA] Archived-At: Cc: Geoffrey Keating , TLS WG Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Jun 2015 06:54:53 -0000 The idea is that the server can send a different weaker DHE key in the Serv= erKeyExchange=2C or not use DHE suites at all.=0A= =0A= ________________________________=0A= > From: bascule@gmail.com =0A= > Date: Tue=2C 2 Jun 2015 23:52:36 -0700 =0A= > Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt = =0A= > To: yuhongbao_386@hotmail.com =0A= > CC: geoffk@geoffk.org=3B tls@ietf.org =0A= > =0A= > Yes sorry I meant ClientKeyExchange... =0A= > =0A= > But can you explain to me how this solves the problem for legacy clients?= =0A= > =0A= > On Tue=2C Jun 2=2C 2015 at 11:52 PM=2C Yuhong Bao =0A= > > wrote: =0A= > The client don't receive the ServerKeyExchange message containing the =0A= > DHE key at all until after they sent the ClientHello. =0A= > =0A= > ________________________________ =0A= >> From: bascule@gmail.com =0A= >> Date: Tue=2C 2 Jun 2015 23:35:46 -0700 =0A= >> To: geoffk@geoffk.org =0A= >> CC: tls@ietf.org =0A= >> Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt = =0A= >> =0A= >> On Tue=2C Jun 2=2C 2015 at 11:32 PM=2C Geoffrey Keating =0A= >> =0A= > >> =0A= > wrote: =0A= >> It's covered in section 4: =0A= >> =0A= >> If at least one FFDHE ciphersuite is present in the client =0A= >> ciphersuite list=2C and the Supported Groups extension is either absent = =0A= >> from the ClientHello =0A= >> =0A= >> Unless I'm mistaken=2C unless you configure the =0A= >> jdk.tls.disabledAlgorithms property explicitly (with e.g. "DHE keySize = =0A= >>> 2048")=2C Java clients are aborting *before* they send the ClientHello.= =0A= >> Please let me know if you're seeing otherwise. I could be mistaken and = =0A= >> perhaps there's a server-side workaround for this that isn't "disable = =0A= >> all DHE ciphersuites". But this is what I've personally observed and =0A= >> have been advising people about. =0A= >> =0A= >> I'm not saying it can't be fixed with additional =0A= >> configuration/errata/etc=2C I'm arguing that it's *breaking clients in = =0A= >> the field right now* =0A= >> =0A= >> tl=3Bdr: I am seeing *widespread TLS breakages* because of this resultin= g =0A= >> in *huge outages* for Java clients =0A= >> =0A= >> -- =0A= >> Tony Arcieri =0A= >> =0A= >> _______________________________________________ TLS mailing list =0A= >> TLS@ietf.org https://www.ietf.org/mailman/listinfo/= tls =0A= > =0A= > =0A= > =0A= > =0A= > -- =0A= > Tony Arcieri =0A= = From nobody Wed Jun 3 00:00: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 9D7B71A6FF9 for ; Wed, 3 Jun 2015 00:00:30 -0700 (PDT) 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 4d97LaHOYI3u for ; Wed, 3 Jun 2015 00:00:28 -0700 (PDT) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::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 8C5BC1A1AA9 for ; Wed, 3 Jun 2015 00:00:28 -0700 (PDT) Received: by objn8 with SMTP id n8so725669obj.3 for ; Wed, 03 Jun 2015 00:00:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=xl6Z9VT7R7k5Q5JT0dg3c3Xn61aWFHfSQ87h/J92twE=; b=gbdT5hbokYlqpc5Oe3Mk5rQnexeHClHWm3oQsZQFO8Z3DLFPaKzNypFCCCu7VqNH+w G1u6FSyPzTDLTss7/uirbUKOKtZDGHNKhcdSAEJt45KlqWNhEP2K/Rjo0ckNayg8FQCw az/4o/cZK0JUuhrxLGNye+27hpkmPVgh78zwVJABQf7UAhxbXnMriM+NQxdhFjgvQ8LC 9PFAcRA3vgvGODQC2n/ruuj5+qo22Sq7so5P0IemwLOd4z0XKMWHtghPEnsYv28s6UaS ckqmf6QFHq02Y0clPTjJ5qzM5hWm7tUVOuOjwdOmah72QEucKdbxVIT8yOInj+E75ty7 5iwg== X-Received: by 10.202.210.80 with SMTP id j77mr24526680oig.68.1433314827973; Wed, 03 Jun 2015 00:00:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.110.241 with HTTP; Wed, 3 Jun 2015 00:00:07 -0700 (PDT) In-Reply-To: References: <20150601225057.17500.96911.idtracker@ietfa.amsl.com> <1474500.r0W7gM0pAO@pintsize.usersys.redhat.com> From: Tony Arcieri Date: Wed, 3 Jun 2015 00:00:07 -0700 Message-ID: To: Yuhong Bao Content-Type: multipart/alternative; boundary=001a113d26562c3e0d0517979d94 Archived-At: Cc: Geoffrey Keating , TLS WG Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Jun 2015 07:00:30 -0000 --001a113d26562c3e0d0517979d94 Content-Type: text/plain; charset=UTF-8 So this is the exact problem I've been talking about. After this draft is actually implemented in all TLS servers everywhere, server operators can add Java-specific errata to their configuration to work around the fundamental problem that DHE is breaking Java TLS handshakes. Or you can just add the Java property I cited above. Which is total oddball errata. Nobody should have to worry about jdk.tls.disabledAlgorithms="DHE keySize > 2048" This is just adding to the "headache" of maintaining a modern TLS stack. I'll freely admit I just made mistakes trying to diagnose this problem but as a practitioner I seriously don't care about supporting these things and want them to just go away and for TLS handshakes to just work and not spontaneously break because of misconfigurations. I don't see how adding more complexity fixes the problem. I just want DHE to diediedie. Perhaps someone can explain how keeping DHE around is actually beneficial in any way whatsover? Right now it's just giving me a headache and making me angry. On Tue, Jun 2, 2015 at 11:54 PM, Yuhong Bao wrote: > The idea is that the server can send a different weaker DHE key in the > ServerKeyExchange, or not use DHE suites at all. > > ________________________________ > > From: bascule@gmail.com > > Date: Tue, 2 Jun 2015 23:52:36 -0700 > > Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt > > To: yuhongbao_386@hotmail.com > > CC: geoffk@geoffk.org; tls@ietf.org > > > > Yes sorry I meant ClientKeyExchange... > > > > But can you explain to me how this solves the problem for legacy clients? > > > > On Tue, Jun 2, 2015 at 11:52 PM, Yuhong Bao > > > wrote: > > The client don't receive the ServerKeyExchange message containing the > > DHE key at all until after they sent the ClientHello. > > > > ________________________________ > >> From: bascule@gmail.com > >> Date: Tue, 2 Jun 2015 23:35:46 -0700 > >> To: geoffk@geoffk.org > >> CC: tls@ietf.org > >> Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt > >> > >> On Tue, Jun 2, 2015 at 11:32 PM, Geoffrey Keating > >> > > >> > > wrote: > >> It's covered in section 4: > >> > >> If at least one FFDHE ciphersuite is present in the client > >> ciphersuite list, and the Supported Groups extension is either absent > >> from the ClientHello > >> > >> Unless I'm mistaken, unless you configure the > >> jdk.tls.disabledAlgorithms property explicitly (with e.g. "DHE keySize > >>> 2048"), Java clients are aborting *before* they send the ClientHello. > >> Please let me know if you're seeing otherwise. I could be mistaken and > >> perhaps there's a server-side workaround for this that isn't "disable > >> all DHE ciphersuites". But this is what I've personally observed and > >> have been advising people about. > >> > >> I'm not saying it can't be fixed with additional > >> configuration/errata/etc, I'm arguing that it's *breaking clients in > >> the field right now* > >> > >> tl;dr: I am seeing *widespread TLS breakages* because of this resulting > >> in *huge outages* for Java clients > >> > >> -- > >> Tony Arcieri > >> > >> _______________________________________________ TLS mailing list > >> TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > > > > > > > > -- > > Tony Arcieri > -- Tony Arcieri --001a113d26562c3e0d0517979d94 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
So this is the exact problem I've been talking about.<= div>
After this draft is actually implemented in all TLS serv= ers everywhere, server operators can add Java-specific errata to their conf= iguration to work around the fundamental problem that DHE is breaking Java = TLS handshakes.

Or you can just add the Java prope= rty I cited above. Which is total oddball errata. Nobody should have to wor= ry about jdk.tls.disabledAlgor= ithms=3D"DHE keySize > 2048"

T= his is just adding to the "headache" of maintaining a modern TLS = stack.

I'll freely admit I just made mistakes = trying to diagnose this problem but as a practitioner I seriously don't= care about supporting these things and want them to just go away and for T= LS handshakes to just work and not spontaneously break because of misconfig= urations.

I don't see how adding more complexi= ty fixes the problem.

I just want DHE to diediedie= .

Perhaps someone can explain how keeping DHE arou= nd is actually beneficial in any way whatsover? Right now it's just giv= ing me a headache and making me angry.


On Tue, Jun 2, 2015 at 11:5= 4 PM, Yuhong Bao <yuhongbao_386@hotmail.com> wrote:<= br>
The idea is that the server can send a di= fferent weaker DHE key in the ServerKeyExchange, or not use DHE suites at a= ll.

________________________________
> From: bascule@gmail.com
> Date: Tue, 2 Jun 2015 23:52:36 -0700
> Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotia= ted-ff-dhe-10.txt
> To: yuhongbao_386@= hotmail.com
> CC: geoffk@geoffk.org; tls@ietf.org
>
> Yes sorry I meant ClientKeyExchange...
>
> But can you explain to me how this solves the problem for legacy clien= ts?
>
> On Tue, Jun 2, 2015 at 11:52 PM, Yuhong Bao
> <yuhongbao_386@hotmail.com<mailto:yuhongbao_386@hotmail.com>> wrote:
> The client don't receive the ServerKeyExchange message containing = the
> DHE key at all until after they sent the ClientHello.
>
> ________________________________
>> From: bascule@gmail.co= m<mailto:bascule@gmail.com&= gt;
>> Date: Tue, 2 Jun 2015 23:35:46 -0700
>> To: geoffk@geoffk.org<= /a><mailto:geoffk@geoffk.org>= ;
>> CC: tls@ietf.org<mailto:tls@ietf.org>
>> Subject: Re: [TLS] I-D Action: draft-ietf-tls-neg= otiated-ff-dhe-10.txt
>>
>> On Tue, Jun 2, 2015 at 11:32 PM, Geoffrey Keating
>>
> <geoffk@geoffk.org&= lt;mailto:geoffk@geoffk.org><= ;mailto:geoffk@geoffk.org<mailt= o:geoffk@geoffk.org>>> > wrote:
>> It's covered in section 4:
>>
>> If at least one FFDHE ciphersuite is present in the client
>> ciphersuite list, and the Supported Groups extension is either abs= ent
>> from the ClientHello
>>
>> Unless I'm mistaken, unless you configure the
>> jdk.tls.disabledAlgorithms property explicitly (with e.g. "DH= E keySize
>>> 2048"), Java clients are aborting *before* they send the = ClientHello.
>> Please let me know if you're seeing otherwise. I could be mist= aken and
>> perhaps there's a server-side workaround for this that isn'= ;t "disable
>> all DHE ciphersuites". But this is what I've personally o= bserved and
>> have been advising people about.
>>
>> I'm not saying it can't be fixed with additional
>> configuration/errata/etc, I'm arguing that it's *breaking = clients in
>> the field right now*
>>
>> tl;dr: I am seeing *widespread TLS breakages* because of this resu= lting
>> in *huge outages* for Java clients
>>
>> --
>> Tony Arcieri
>>
>> _______________________________________________ TLS mailing list >> TLS@ietf.org<mailto:= TLS@ietf.org> https://www.ietf.org/mail= man/listinfo/tls
>
>
>
>
> --
> Tony Arcieri
=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=A0 =C2=A0 <= /font>



--
Tony Arcieri
--001a113d26562c3e0d0517979d94-- From nobody Wed Jun 3 00:33: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 438B81B35EF for ; Wed, 3 Jun 2015 00:33:30 -0700 (PDT) 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 9KzgiKSEUpNQ for ; Wed, 3 Jun 2015 00:33:28 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::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 2F0491B35EE for ; Wed, 3 Jun 2015 00:33:28 -0700 (PDT) Received: by oifu123 with SMTP id u123so1196692oif.1 for ; Wed, 03 Jun 2015 00:33:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=1nVOGm/RA/UYFrZnPhTif3af0aWZ3tEG7ebE8awgvGk=; b=jTqOe5Svy3+Gbyl9K2ET0k6gP5+PnRXiK4PgP4ziPJHRx8M2frva2d48bT5leb01Ds ySA3aJ9yz/OKztEdDitU8WktvHmj3ZRC6t7JayUqTBdgRo2rGxZ5HvEtDvSxrJevjJ/Q cm66DVCoGwu5FyMk/pheAnd0tywMlHxwwGyxcuiXF1vDDkN+SfHvrf/VB68Hxnj9dar3 DTixJticKcqBSKHwsUO/e0wRz55Jcm2pfSSu+alZKZCFmrvB/YxoUYJo5Y1lPbkiqKR7 n+9eIJlPUEpN/3ihfi4LAfLfiaYhmzhbJTM0azXXnr/7AWOZFJ9nP7t1qRPkhEpQR7xW 7Edg== X-Received: by 10.182.115.161 with SMTP id jp1mr26640950obb.53.1433316807537; Wed, 03 Jun 2015 00:33:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.110.241 with HTTP; Wed, 3 Jun 2015 00:33:07 -0700 (PDT) In-Reply-To: References: <20150601225057.17500.96911.idtracker@ietfa.amsl.com> <1474500.r0W7gM0pAO@pintsize.usersys.redhat.com> From: Tony Arcieri Date: Wed, 3 Jun 2015 00:33:07 -0700 Message-ID: To: Yuhong Bao Content-Type: multipart/alternative; boundary=089e01182cf229fb4105179813a0 Archived-At: Cc: Geoffrey Keating , TLS WG Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Jun 2015 07:33:30 -0000 --089e01182cf229fb4105179813a0 Content-Type: text/plain; charset=UTF-8 Here's a real-world example of what I've just been going through with regard to Java and DHE: https://github.com/jruby/jruby/issues/2872 Note the ticket is about the general problem, and in the course of it there have been multiple manifestations of the problem. On Wed, Jun 3, 2015 at 12:00 AM, Tony Arcieri wrote: > So this is the exact problem I've been talking about. > > After this draft is actually implemented in all TLS servers everywhere, > server operators can add Java-specific errata to their configuration to > work around the fundamental problem that DHE is breaking Java TLS > handshakes. > > Or you can just add the Java property I cited above. Which is total > oddball errata. Nobody should have to worry about jdk.tls.disabledAlgorithms="DHE > keySize > 2048" > > This is just adding to the "headache" of maintaining a modern TLS stack. > > I'll freely admit I just made mistakes trying to diagnose this problem but > as a practitioner I seriously don't care about supporting these things and > want them to just go away and for TLS handshakes to just work and not > spontaneously break because of misconfigurations. > > I don't see how adding more complexity fixes the problem. > > I just want DHE to diediedie. > > Perhaps someone can explain how keeping DHE around is actually beneficial > in any way whatsover? Right now it's just giving me a headache and making > me angry. > > > On Tue, Jun 2, 2015 at 11:54 PM, Yuhong Bao > wrote: > >> The idea is that the server can send a different weaker DHE key in the >> ServerKeyExchange, or not use DHE suites at all. >> >> ________________________________ >> > From: bascule@gmail.com >> > Date: Tue, 2 Jun 2015 23:52:36 -0700 >> > Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt >> > To: yuhongbao_386@hotmail.com >> > CC: geoffk@geoffk.org; tls@ietf.org >> > >> > Yes sorry I meant ClientKeyExchange... >> > >> > But can you explain to me how this solves the problem for legacy >> clients? >> > >> > On Tue, Jun 2, 2015 at 11:52 PM, Yuhong Bao >> > > wrote: >> > The client don't receive the ServerKeyExchange message containing the >> > DHE key at all until after they sent the ClientHello. >> > >> > ________________________________ >> >> From: bascule@gmail.com >> >> Date: Tue, 2 Jun 2015 23:35:46 -0700 >> >> To: geoffk@geoffk.org >> >> CC: tls@ietf.org >> >> Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt >> >> >> >> On Tue, Jun 2, 2015 at 11:32 PM, Geoffrey Keating >> >> >> > > >> >> > wrote: >> >> It's covered in section 4: >> >> >> >> If at least one FFDHE ciphersuite is present in the client >> >> ciphersuite list, and the Supported Groups extension is either absent >> >> from the ClientHello >> >> >> >> Unless I'm mistaken, unless you configure the >> >> jdk.tls.disabledAlgorithms property explicitly (with e.g. "DHE keySize >> >>> 2048"), Java clients are aborting *before* they send the ClientHello. >> >> Please let me know if you're seeing otherwise. I could be mistaken and >> >> perhaps there's a server-side workaround for this that isn't "disable >> >> all DHE ciphersuites". But this is what I've personally observed and >> >> have been advising people about. >> >> >> >> I'm not saying it can't be fixed with additional >> >> configuration/errata/etc, I'm arguing that it's *breaking clients in >> >> the field right now* >> >> >> >> tl;dr: I am seeing *widespread TLS breakages* because of this resulting >> >> in *huge outages* for Java clients >> >> >> >> -- >> >> Tony Arcieri >> >> >> >> _______________________________________________ TLS mailing list >> >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > >> > >> > >> > >> > -- >> > Tony Arcieri >> > > > > > -- > Tony Arcieri > -- Tony Arcieri --089e01182cf229fb4105179813a0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Here's a real-world example of what I've just been= going through with regard to Java and DHE:


Note the ticket is about the ge= neral problem, and in the course of it there have been multiple manifestati= ons of the problem.

On Wed, Jun 3, 2015 at 12:00 AM, Tony Arcieri <bascule@gmail= .com> wrote:
So this is the exact problem I've been talking about.

=
After this draft is actually implemented in all TLS servers everywhere= , server operators can add Java-specific errata to their configuration to w= ork around the fundamental problem that DHE is breaking Java TLS handshakes= .

Or you can just add the Java property I cited ab= ove. Which is total oddball errata. Nobody should have to worry about jdk.tls.disabledAlgorithms=3D"= DHE keySize > 2048"

This is just ad= ding to the "headache" of maintaining a modern TLS stack.

I'll freely admit I just made mistakes trying to diag= nose this problem but as a practitioner I seriously don't care about su= pporting these things and want them to just go away and for TLS handshakes = to just work and not spontaneously break because of misconfigurations.

I don't see how adding more complexity fixes the p= roblem.

I just want DHE to diediedie.
Perhaps someone can explain how keeping DHE around is actually= beneficial in any way whatsover? Right now it's just giving me a heada= che and making me angry.


On Tue, Jun 2, 201= 5 at 11:54 PM, Yuhong Bao <yuhongbao_386@hotmail.com> wrote:
The idea is that the server can = send a different weaker DHE key in the ServerKeyExchange, or not use DHE su= ites at all.

________________________________
> From: bascule@g= mail.com
> Date: Tue, 2 Jun 2015 23:52:36 -0700
> Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-= 10.txt
> To: yuhongbao_386@hotmail.com
> CC: geoffk@geof= fk.org; tls@ietf.org<= /a>
>
> Yes sorry I meant ClientKeyExchange...
>
> But can you explain to me how this solves the problem for legacy clien= ts?
>
> On Tue, Jun 2, 2015 at 11:52 PM, Yuhong Bao
> <yuhongbao_386@hotmail.com<mailto:yuhongbao_386@hotmail.com>&g= t; wrote:
> The client don't receive the ServerKeyExchange message containing = the
> DHE key at all until after they sent the ClientHello.
>
> ________________________________
>> From: bascule@gmail.com<mailto:bascule@gmail.com>
>> Date: Tue, 2 Jun 2015 23:35:46 -0700
>> To: = geoffk@geoffk.org<mailto:geoffk@geoffk.org>
>> CC: tls@ietf.org= <mailto:tls@ietf.o= rg>
>> Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-= dhe-10.txt
>>
>> On Tue, Jun 2, 2015 at 11:32 PM, Geoffrey Keating
>>
> <geof= fk@geoffk.org<mailto:geoffk@geoffk.org><mailto:geoffk@geoffk.org<mailto:geoffk@geoffk.org>>>
> wrote:
>> It's covered in section 4:
>>
>> If at least one FFDHE ciphersuite is present in the client
>> ciphersuite list, and the Supported Groups extension is either abs= ent
>> from the ClientHello
>>
>> Unless I'm mistaken, unless you configure the
>> jdk.tls.disabledAlgorithms property explicitly (with e.g. "DH= E keySize
>>> 2048"), Java clients are aborting *before* they send the = ClientHello.
>> Please let me know if you're seeing otherwise. I could be mist= aken and
>> perhaps there's a server-side workaround for this that isn'= ;t "disable
>> all DHE ciphersuites". But this is what I've personally o= bserved and
>> have been advising people about.
>>
>> I'm not saying it can't be fixed with additional
>> configuration/errata/etc, I'm arguing that it's *breaking = clients in
>> the field right now*
>>
>> tl;dr: I am seeing *widespread TLS breakages* because of this resu= lting
>> in *huge outages* for Java clients
>>
>> --
>> Tony Arcieri
>>
>> _______________________________________________ TLS mailing list >> TLS@ietf.= org<mailto:TLS@iet= f.org> https://www.ietf.org/mailman/listinfo/tls
>
>
>
>
> --
> Tony Arcieri
=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=A0 =C2=A0 <= /font>



=
--
Tony Arcie= ri



--
Tony Arcieri
--089e01182cf229fb4105179813a0-- From nobody Wed Jun 3 01:05: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 6ABEF1B360C for ; Wed, 3 Jun 2015 01:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCdI9F8lqk4M for ; Wed, 3 Jun 2015 01:05:51 -0700 (PDT) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (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 DA3EA1ACEF4 for ; Wed, 3 Jun 2015 01:05:50 -0700 (PDT) Received: by qgg60 with SMTP id 60so730875qgg.2 for ; Wed, 03 Jun 2015 01:05:50 -0700 (PDT) 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=PDSt0SNtdGdJIPGavmrg+s7UIK/5uKA7rQ1S6Mel0P0=; b=P+uoyvOxYBF9FW9b6E2fRjVfioNCw5bp5vxVSLgRFs1XUkOqtV5GmTV7/HUZpXvj0u q/duNHqZsTWC0E8sgNbfgMFKYT8YeOuFZ2657NX9AXBkc7rO8hlyJUm9cKOzFrdPn9fp jRAgkRwnIuhRuFG85jfaGQRfipCRK0MFZ3Se3AD3tqXj8waI641W5rN00VgEX/SMp3Ob BRxX6wiZ3vudeb+pFn6TY+E+7mQiATxdJ39XM6a/7XOMtp1aonP9D6FaP99PLYxFmFXg bhdlknTdXKJs+/1yrle8QktBmEQiFFU8Jj5ZubT04r7jxE8L1/lnJd2bir5JgFadsjCw FH7Q== X-Received: by 10.55.51.78 with SMTP id z75mr37581004qkz.101.1433318750164; Wed, 03 Jun 2015 01:05:50 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id i197sm8546633qhc.36.2015.06.03.01.05.49 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 03 Jun 2015 01:05:49 -0700 (PDT) From: Dave Garrett To: tls@ietf.org, Tony Arcieri Date: Wed, 3 Jun 2015 04:05:47 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <20150601225057.17500.96911.idtracker@ietfa.amsl.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201506030405.47936.davemgarrett@gmail.com> Archived-At: Cc: Geoffrey Keating Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Jun 2015 08:05:52 -0000 On Wednesday, June 03, 2015 02:16:50 am Tony Arcieri wrote: > Unfortunately, exactly as you've pointed out, legacy clients are > incompatible with these stronger D-H groups. For legacy Java clients, it > catastrophically completely prevents the TLS handshake from succeeding if > any such ciphersuite is even present in the ServerHello. > > My experience has been, and correct me if I'm wrong, that the only two ways > to fix this are for the Java client to disable all DHE ciphersuites, or for > the server to not offer them. Depend on the Java version, DHE with 2048-bit > keys can break it, and for newer versions of Java, the problem persists for > 4096-bit DHE. On Wednesday, June 03, 2015 03:00:07 am Tony Arcieri wrote: > I just want DHE to diediedie. > > Perhaps someone can explain how keeping DHE around is actually beneficial > in any way whatsover? Right now it's just giving me a headache and making > me angry. People want a backup to deal with mistrust of ECC curves and general paranoia. Though, with issues this bad, yeah, killing it seems like a sensible option. I don't think the paranoia is unwarranted, however. > I don't see how adding more complexity fixes the problem. Well... here's a way it could: 1) Deprecate/prohibit all "DH(E)_*" cipher suites 2) Create a new set of "FFDHE_*" cipher suites to replace them that only allow strong groups (3072+) I'm not saying this is the best idea, but it is _an_ idea. ;) Dave From nobody Wed Jun 3 01:07: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 BDD981B3616 for ; Wed, 3 Jun 2015 01:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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 b5rhCi815YOC for ; Wed, 3 Jun 2015 01:07:39 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B246F1B360E for ; Wed, 3 Jun 2015 01:07:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1433318858; x=1464854858; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ZZ6bnLHOyCLEapsgrZ+eU4UUDljqt9lts6fsdb3U2Vg=; b=Rl+zUBI1Cgldxak/RpSlo2yqzLTzx972Stn/olTsOiP2UGpzJ0chJgYL 3HlPKX89n/3vPpNPcZTtXfpGZsZFjwfCu5M4Ouv/o4niHGd901dOkt84i nzGMvbHZH05AjfJQcJbl40D1tLi7hN31XtxXEBuK24ZzWjCa47CnVTxia DhCKCa+4Ow6ejCXNJ8vB94lJfjAufIzyZypZydf/3UwA1oqddJ7PqUhDs URdrvQuPGdimmK1RiFIoBuZs8ABcdUUo0XPahYZsJV7CImDM720Al/+px yJ6wj9TINki7mcQxXE4sCvaIRiTEOFxRu+VuDfBNdCRDy0t6QvKMAstWi g==; X-IronPort-AV: E=Sophos; i="5.13,546,1427713200"; d="scan'208,217"; a="20499231" 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 mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 03 Jun 2015 20:07:37 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.151]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Wed, 3 Jun 2015 20:07:37 +1200 From: Peter Gutmann To: Tony Arcieri , Yuhong Bao Thread-Topic: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt Thread-Index: AQHQnL2L68T3AffyvEqgspEWfVqhMZ2Xe2UAgADoZoCAAR6tAIAACO2AgAABAACAAASSgIAAACIAgAAAoACAAAF6gIAA26vr Date: Wed, 3 Jun 2015 08:07:36 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AB034F5F@uxcn10-tdc05.UoA.auckland.ac.nz> References: <20150601225057.17500.96911.idtracker@ietfa.amsl.com> <1474500.r0W7gM0pAO@pintsize.usersys.redhat.com> , In-Reply-To: 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: multipart/alternative; boundary="_000_9A043F3CF02CD34C8E74AC1594475C73AB034F5Fuxcn10tdc05UoAa_" MIME-Version: 1.0 Archived-At: Cc: Geoffrey Keating , TLS WG Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Jun 2015 08:07:44 -0000 --_000_9A043F3CF02CD34C8E74AC1594475C73AB034F5Fuxcn10tdc05UoAa_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Tony Arcieri writes: >After this draft is actually implemented in all TLS servers everywhere, >server operators can add Java-specific errata to their configuration to wo= rk >around the fundamental problem that DHE is breaking Java TLS handshakes. You've got that exactly reversed, it's not "DHE is breaking Java handshakes= ", it's "(Sun/Oracle's) Java is breaking DHE handshakes". Their Java's broken handling of DLP key sizes has been a known problem for years (and years, an= d years, and years). First Sun and then Oracle have chosen to ignore the problem despite repeated complaints by users over a long period of time. I= t is not the IETF's job to fix a particular vendor's broken, buggy code. >I just want DHE to diediedie. I just want Sun/Oracle Java's broken handling of this to diediedie. Let's = see which one happens first. Peter. --_000_9A043F3CF02CD34C8E74AC1594475C73AB034F5Fuxcn10tdc05UoAa_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Tony Arcieri <bascule@gmail= .com> writes:
>After this draft is actually= implemented in all TLS servers everywhere,
>server operators can add Java-specific errata to their configuration to= work
>around the fundamental problem that DHE is breaking Java TLS handshakes= .

You've got that exactly reversed, it's not "DHE is breaking Java hands= hakes",
it's "(Sun/Oracle's) Java is breaking DHE handshakes".  Thei= r Java's broken
handling of DLP key sizes has been a known problem for years (and years, an= d
years, and years).  First Sun and then Oracle have chosen to ignore th= e
problem despite repeated complaints by users over a long period of time.&nb= sp; It
is not the IETF's job to fix a particular vendor's broken, buggy code.

>I just want DHE to diediedie.

I just want Sun/Oracle Java's broken handling of this to diediedie.  L= et's see
which one happens first.

Peter.

--_000_9A043F3CF02CD34C8E74AC1594475C73AB034F5Fuxcn10tdc05UoAa_-- From nobody Wed Jun 3 01:20: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 059041B3630 for ; Wed, 3 Jun 2015 01:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3hlGugy76l0E for ; Wed, 3 Jun 2015 01:20:36 -0700 (PDT) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) (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 236921B362E for ; Wed, 3 Jun 2015 01:20:36 -0700 (PDT) Received: by obcnx10 with SMTP id nx10so1992955obc.2 for ; Wed, 03 Jun 2015 01:20:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=g+PuIuxdD3U9d1ePH4Zx03gs6weLNjHXDFl7KUzPfdw=; b=GhzAuPTMHybhA2ZlE9CLqaTe0RzHN9TSRO23SUb+jGL0SOyEUPbJIDFmk//c7gOivL uBU1XYSmwV6BgOiQLvh23rWHiYGpGut+sP1klHA/KeaxOXnEElWnYd8GD9P3lDSwH1Ut b4Fi5DOZhIyLwDxHTkR0zlQHhPisqmq4+BknYVH0O0TOk2Q3Rqae2Za2hozzCT2Bj++w gfR723kKr44s+rxEojjEz1/Wf8pek/h0mU2Z285gi7dBPIeQHSnsV8FkJisJdNk/6uvQ Av71f29iVNLprX/rQNgP2YlQjyqZod2zJvH7Dwracv3ASg60YbD+3NvunlA6MaOvIuGZ 6UFQ== X-Received: by 10.182.76.100 with SMTP id j4mr2990533obw.14.1433319635640; Wed, 03 Jun 2015 01:20:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.110.241 with HTTP; Wed, 3 Jun 2015 01:20:15 -0700 (PDT) In-Reply-To: <201506030405.47936.davemgarrett@gmail.com> References: <20150601225057.17500.96911.idtracker@ietfa.amsl.com> <201506030405.47936.davemgarrett@gmail.com> From: Tony Arcieri Date: Wed, 3 Jun 2015 01:20:15 -0700 Message-ID: To: Dave Garrett , "" , Yuhong Bao , Geoffrey Keating Content-Type: multipart/alternative; boundary=047d7b672924bb69ea051798bb7e Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Jun 2015 08:20:38 -0000 --047d7b672924bb69ea051798bb7e Content-Type: text/plain; charset=UTF-8 On Wed, Jun 3, 2015 at 1:05 AM, Dave Garrett wrote: > People want a backup to deal with mistrust of ECC curves and general > paranoia. I'll refer to my first response to this thread: On Mon, Jun 1, 2015 at 4:02 PM, Tony Arcieri wrote: > I expect the response is going to be "What if there's some catastrophic > failure of ECC?" > The reality is DHE hardening attempts are breaking Java 6, 7, and in some cases 8 clients from negotiating TLS connections in the field right now, today. To me that's worse than an ECC failure. I'll go out on a limb and say that "it doesn't work" is a worse problem than "it's insecure". Java 7 and 8 clients can negotiate ECDHE instead of DHE, so what we're seeing here is legacy cruft preventing the use of an otherwise semi-modern configuration (for relative values of modern). If we simply shut the cruft off, everything is great, and the handshake succeeds using a key exchange facilitated by modern algorithms. I feel like I'm dealing with legacy knobs that nobody in their right mind would turn, but simply by existing are breaking the entire TLS communication channel from being established. Java 6 can't negotiate DHE with a "secure" key size. The best it can do is 1024-bit. Both Java 6 and 7 are already EOL so there's little chance of IETF drafts affecting them unless there's a server-side workaround that isn't "shut off DHE". Has someone actually implemented what's described in this draft and shown it allows legacy Java clients to negotiate a secure DHE handshake? And even if that's the case, why care about DHE instead of moving clients to ECDHE? Who is this draft actually helping? Well... here's a way it could: > 1) Deprecate/prohibit all "DH(E)_*" cipher suites I'm a bit unclear on this, but I think that's actually happening as part of TLS 1.3? -- Tony Arcieri --047d7b672924bb69ea051798bb7e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jun 3, 2015 at 1:05 AM, Dave Garrett <davemgarrett@gmail.com> wrote:
People want a backup to deal with mistrust of ECC curves and general p= aranoia.

I'll refer to my first respons= e to this thread:






Well... here'= s a way it could:
1)= Deprecate/prohibit all "DH(E)_*" cipher suites

I'm a bit unclear on this, but I think that's= actually happening as part of TLS 1.3?

--
Tony Arcieri
--047d7b672924bb69ea051798bb7e-- From nobody Wed Jun 3 01:23: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 71ABA1B3638 for ; Wed, 3 Jun 2015 01:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FrltmCPIaDFn for ; Wed, 3 Jun 2015 01:23:18 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (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 057041B3636 for ; Wed, 3 Jun 2015 01:23:18 -0700 (PDT) Received: by oihb142 with SMTP id b142so1893858oih.3 for ; Wed, 03 Jun 2015 01:23:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=SxyWm1TsqCL3edntZH01IW6ebxDPEieb8l2cUrKV/K4=; b=gbYZd0wnT1FP22UI/UPcMtOv1i2aiI8iTAxTy85Xv+ltOrs7NgPnaDU2N8ml30ZbDQ 2KxqQsck35qxApErCcUVZj/Lyc7W6+vsVd/vbrerOTFsaf3/uOXU1498KKErHlth1U+q 4WatC4CToXhwBtbf9RieVvT9SF9ptnXSPKHk7zdwZ8RFSbbszjZTKf9qyF+U+ZXqqITg 8OyhRlHfpycKNC98RbS1qeQKNWAITj9bPNygezE7fNVJLGOk+sab1G41K9t6iCsuXAuk OLR54iipQwftJ7YSHFqf+Ken6yNzd4IB0CUCtt+twg1ihjbOAwKWGvE42WNHV85d8UPi XKfA== X-Received: by 10.60.79.193 with SMTP id l1mr18819542oex.60.1433319797559; Wed, 03 Jun 2015 01:23:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.110.241 with HTTP; Wed, 3 Jun 2015 01:22:57 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AB034F5F@uxcn10-tdc05.UoA.auckland.ac.nz> References: <20150601225057.17500.96911.idtracker@ietfa.amsl.com> <1474500.r0W7gM0pAO@pintsize.usersys.redhat.com> <9A043F3CF02CD34C8E74AC1594475C73AB034F5F@uxcn10-tdc05.UoA.auckland.ac.nz> From: Tony Arcieri Date: Wed, 3 Jun 2015 01:22:57 -0700 Message-ID: To: Peter Gutmann Content-Type: multipart/alternative; boundary=089e011773736217cc051798c593 Archived-At: Cc: Geoffrey Keating , TLS WG Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Jun 2015 08:23:19 -0000 --089e011773736217cc051798c593 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 3, 2015 at 1:07 AM, Peter Gutmann wrote: > > *You've got that exactly reversed, it's not "DHE is breaking Java > handshakes", it's "(Sun/Oracle's) Java is breaking DHE handshakes".* > Here in the real world things are written in Java and we have to deal with that. Idealistically I'd wave a magic wand and all of the legacy cruft would go away. Unfortunately I don't have that magic wand. I have to keep the real-world systems talking to each other. I want real-world solutions to real-world problems, not idealistic zealotry. -- Tony Arcieri --089e011773736217cc051798c593 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jun 3, 2015 at 1:07 AM, Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:
<= font face=3D"Courier New" size=3D"2">You've got that exactly reverse= d, it's not "DHE is breaking Java handshakes",
it's "(Sun/Oracle's) Java is breaking DHE handshakes".

Here in the real= world things are written in Java and we have to deal with that. Idealistic= ally I'd wave a magic wand and all of the legacy cruft would go away. U= nfortunately I don't have that magic wand. I have to keep the real-worl= d systems talking to each other.

I want real-world= solutions to real-world problems, not idealistic zealotry.

--
Tony Arcieri
--089e011773736217cc051798c593-- From nobody Wed Jun 3 01: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 770691B364B for ; Wed, 3 Jun 2015 01:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtYeKFKQa_vD for ; Wed, 3 Jun 2015 01:28:20 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (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 855A51B364A for ; Wed, 3 Jun 2015 01:28:20 -0700 (PDT) Received: by obew15 with SMTP id w15so2162250obe.1 for ; Wed, 03 Jun 2015 01:28:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=cYhwXl8R+kHyniDIp5OS+qSqwKuy1yU87W6kok4SVaU=; b=WowfzJmwo1cI3nzEtqnxATk83F+pz0VFOsSN8COPGL0KjBv1OZRR2yBKtvutpZruQm p1OL6g06cLXN91uw5UaBjlVVXMr6otQEhLjNt6PqgkP0vo40sJk1zwx5py7yU9XfySYD SjJySPKkS0MWCvLCcnQrDocw850VB+zQmKkCQv+td/mkJh4TwckS3SU8MX8OF6E+TbTB TeP6+28prMP37LGm4LepuZUjyv16EZomro6p+/vDv9U2MkDa5AZcMiJQt00geCp7i4LT cqvH198lYA7z/7oh+9uE2yKAVlDKk69+28sG9hes7MDGRMjU61LGbRi1IfNM1TBYdRIv SSsw== X-Received: by 10.182.102.2 with SMTP id fk2mr26671150obb.35.1433320099950; Wed, 03 Jun 2015 01:28:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.110.241 with HTTP; Wed, 3 Jun 2015 01:27:59 -0700 (PDT) In-Reply-To: References: <20150601225057.17500.96911.idtracker@ietfa.amsl.com> <1474500.r0W7gM0pAO@pintsize.usersys.redhat.com> <9A043F3CF02CD34C8E74AC1594475C73AB034F5F@uxcn10-tdc05.UoA.auckland.ac.nz> From: Tony Arcieri Date: Wed, 3 Jun 2015 01:27:59 -0700 Message-ID: To: Peter Gutmann Content-Type: multipart/alternative; boundary=089e013a0420683559051798d738 Archived-At: Cc: Geoffrey Keating , TLS WG Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Jun 2015 08:28:22 -0000 --089e013a0420683559051798d738 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 3, 2015 at 1:22 AM, Tony Arcieri wrote: > On Wed, Jun 3, 2015 at 1:07 AM, Peter Gutmann > wrote: > >> >> *You've got that exactly reversed, it's not "DHE is breaking Java >> handshakes", it's "(Sun/Oracle's) Java is breaking DHE handshakes".* >> > > Here in the real world things are written in Java and we have to deal with > that. Idealistically I'd wave a magic wand and all of the legacy cruft > would go away. Unfortunately I don't have that magic wand. I have to keep > the real-world systems talking to each other. > > I want real-world solutions to real-world problems, not idealistic > zealotry. > Worse, I didn't bring up Java. Java was specifically cited in argument of this draft: On Tue, Jun 2, 2015 at 5:54 AM, Hubert Kario wrote: > as it was pointed out many times > ^^^ perhaps this was the line that set me off, but this is painfully antagonistic to me especially given what I've been dealing with recently. Saying things like this is tantamount to a personal attack and if you have a technical argument to make this is possibly the worst way you can prefix it. Dear Hubert, don't frame your argument this way, it just makes me dislike you. adding support for ECC is complex (both because of compexity of ECC and > because it's > a completely new set of algorithms) > Many JCE providers already support ECC including BouncyCastle and the default JCE providers in Java 7 and 8 so this statement is just wrong. Modern Java implementations just won't negotiate DHE unless the server can't speak ECDHE. > This allows us to move away from defaulting to 1024bit or 2048bit on server > side in fear of breaking, for example, Java based clients Please show me an HTTPS server I can point my DHE-enabled Java 6 and 7 clients at and have them successfully negotiate a TLS session. I dare you. -- Tony Arcieri --089e013a0420683559051798d738 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jun 3, 2015 at 1:22 AM, Tony Arcieri <bascule@gmail.com> wrote:
On Wed, Jun 3, 2015 at 1:07 AM, Peter Gutmann <<= a href=3D"mailto:pgut001@cs.auckland.ac.nz" target=3D"_blank" onclick=3D"wi= ndow.open('https://mail.google.com/mail/?view=3Dcm&tf=3D1&to=3D= pgut001@cs.auckland.ac.nz&cc=3D&bcc=3D&su=3D&body=3D',&= #39;_blank');return false;">pgut001@cs.auckland.ac.nz> wr= ote:
You've got that= exactly reversed, it's not "DHE is breaking Java handshakes"= ,
it's "(Sun/Oracle's) Java is breaking DHE handshakes".

Here in t= he real world things are written in Java and we have to deal with that. Ide= alistically I'd wave a magic wand and all of the legacy cruft would go = away. Unfortunately I don't have that magic wand. I have to keep the re= al-world systems talking to each other.

I want rea= l-world solutions to real-world problems, not idealistic zealotry.

Worse, I didn't bring u= p Java. Java was specifically cited in argument of this draft:
On Tue, Jun 2, 2015 at 5:54 AM, Hubert Kario=C2=A0<hkario@redhat.com>=C2=A0wrote:
=
as it was pointed out many times

=
^^^ perhaps this was the line that set me off, but this is painf= ully antagonistic to me especially given what I've been dealing with re= cently. Saying things like this is tantamount to a personal attack and if y= ou have a technical argument to make this is possibly the worst way you can= prefix it. Dear Hubert, don't frame your argument this way, it just ma= kes me dislike you.

adding=C2=A0suppor= t for ECC is complex (both because of compexity of ECC and because it's=
a completely new set of algorithms)

Many JCE providers already support ECC inclu= ding BouncyCastle and the default JCE providers in Java 7 and 8 so this sta= tement is just wrong. Modern Java implementations just won't negotiate = DHE unless the server can't speak ECDHE.
=C2=A0
This allows us to move away from defaulting to 1024bit or 2048bit = on server
side in fear of breaking, for example, Java based clients

Please show me an HTTPS server I can point my D= HE-enabled Java 6 and 7 clients at and have them successfully negotiate a T= LS session. I dare you.=C2=A0

--=C2=A0
=
Tony Arcieri
--089e013a0420683559051798d738-- From nobody Wed Jun 3 01:43: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 AAD211A88D7 for ; Wed, 3 Jun 2015 01:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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 WVefxhnkzIge for ; Wed, 3 Jun 2015 01:43:40 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB9DA1A88E0 for ; Wed, 3 Jun 2015 01:43:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1433321020; x=1464857020; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=m5K2P8drx0PgRMbhC/rWa1FmnHY91YKS0P28KVy/syU=; b=xhrvLiRkMz/PJWry2ex164Ni1hzTXRGkNjN4L//a4vzquRcJXaq0/OHt svKBunsjdRXVbSOckU2vA3kItX4h99MgkoXNLibgCgvXGzTFX44wjofHW NzWfeDGFEAhMAHXS6CM3FHm/YxUXBGOCQ2n0eXG8G+yJuydvnBItHUKJx a2tYs5X7qozFCMpUCwQ6RwjApZY2aSfS6PeAS87lk5Th+sAIzEV4DrdZM LdD/Uq+6S23rAiAaqe3IkrR7vcDlJFIHt+xHFCvNHQm8xvPlQKFesLAbf jzyDsk2H/YHyrIqy4LF/HPxtmAeW2qpCxP5LIN+n+7zOxLxJl2r6OeOCH g==; X-IronPort-AV: E=Sophos; i="5.13,546,1427713200"; d="scan'208,217"; a="20503022" 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 mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 03 Jun 2015 20:43:38 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.151]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Wed, 3 Jun 2015 20:43:32 +1200 From: Peter Gutmann To: Tony Arcieri Thread-Topic: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt Thread-Index: AQHQnL2L68T3AffyvEqgspEWfVqhMZ2Xe2UAgADoZoCAAR6tAIAACO2AgAABAACAAASSgIAAACIAgAAAoACAAAF6gIAA26vr//87eoCAAM5LVQ== Date: Wed, 3 Jun 2015 08:43:31 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AB034FEB@uxcn10-tdc05.UoA.auckland.ac.nz> References: <20150601225057.17500.96911.idtracker@ietfa.amsl.com> <1474500.r0W7gM0pAO@pintsize.usersys.redhat.com> <9A043F3CF02CD34C8E74AC1594475C73AB034F5F@uxcn10-tdc05.UoA.auckland.ac.nz>, In-Reply-To: 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: multipart/alternative; boundary="_000_9A043F3CF02CD34C8E74AC1594475C73AB034FEBuxcn10tdc05UoAa_" MIME-Version: 1.0 Archived-At: Cc: Geoffrey Keating , TLS WG Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Jun 2015 08:43:41 -0000 --_000_9A043F3CF02CD34C8E74AC1594475C73AB034FEBuxcn10tdc05UoAa_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Tony Arcieri writes: >I want real-world solutions to real-world problems, not idealistic zealotr= y. You seem to want everyone to change their behaviour in order to accommodate the fact that you've chosen to use a broken, buggy implementation, one that has a well-known problem that's been documented for many, many years. You'= ll have to excuse us for not being terribly sympathetic. (Heck, just switch to something other than Sun/Oracle's broken implementati= on if it's that big a deal, try Bouncy Castle for example. The point is, this= is your problem, not the IETF's. If you want to complain to someone, take it = up with Sun/Oracle, the party responsible for the problem). Peter. --_000_9A043F3CF02CD34C8E74AC1594475C73AB034FEBuxcn10tdc05UoAa_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Tony Arcieri <bascule@gmail.com> writes:

>I want real-world solutions to real-world problems, not idealistic zeal= otry.

You seem to want everyone to change their behaviour in order to accommodate=
the fact that you've chosen to use a broken, buggy implementation, one that=
has a well-known problem that's been documented for many, many years. = You'll
have to excuse us for not being terribly sympathetic.

(Heck, just switch to something other than Sun/Oracle's broken implementati= on
if it's that big a deal, try Bouncy Castle for example.  The point is,= this is
your problem, not the IETF's.  If you want to complain to someone, tak= e it up
with Sun/Oracle, the party responsible for the problem).

Peter.

--_000_9A043F3CF02CD34C8E74AC1594475C73AB034FEBuxcn10tdc05UoAa_-- From nobody Wed Jun 3 01:49: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 E433C1B366F for ; Wed, 3 Jun 2015 01:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDqNYFmQ_VvY for ; Wed, 3 Jun 2015 01:49:17 -0700 (PDT) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::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 0E3851B366E for ; Wed, 3 Jun 2015 01:49:16 -0700 (PDT) Received: by objn8 with SMTP id n8so2440041obj.3 for ; Wed, 03 Jun 2015 01:49:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=/GsP17QBnpODNli5KU9o/f4v2o7JNJjSs28ztdPkyN4=; b=ftLtAeZyq0YEOCXASAkohJwFpbNatk5IHIJLU324FrDFNsHcO2GvVG+lX7KtHrsNpN h9oIjCC7PxYegaN2Pxod/U0Zu+waClwK7lcZE/kSSGyWoQ/HePE9AbciGKbRHQbk2lyl gU/w7xYvIbjLy2pWL0ILAJswfx6geEzMuz/8Vx1w9vkZu2juULZEJdsWCx/33GgCdbz5 e+zOgTIdgeY5sQvXOac/2jTjqGmRe5xsV8v1EyA/P2Xio7JALpQGknZwxM7b+0VXWBEz RitqgYinqxUceZcN/pdvGL1CFxLm1pAroC8l5ND/Jxi98AqBvXCJrz/bGRkUeRuic6M4 Ysiw== X-Received: by 10.202.174.67 with SMTP id x64mr24877828oie.50.1433321356550; Wed, 03 Jun 2015 01:49:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.110.241 with HTTP; Wed, 3 Jun 2015 01:48:56 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AB034FEB@uxcn10-tdc05.UoA.auckland.ac.nz> References: <20150601225057.17500.96911.idtracker@ietfa.amsl.com> <1474500.r0W7gM0pAO@pintsize.usersys.redhat.com> <9A043F3CF02CD34C8E74AC1594475C73AB034F5F@uxcn10-tdc05.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73AB034FEB@uxcn10-tdc05.UoA.auckland.ac.nz> From: Tony Arcieri Date: Wed, 3 Jun 2015 01:48:56 -0700 Message-ID: To: Peter Gutmann Content-Type: multipart/alternative; boundary=001a113cefa44e695f05179922c9 Archived-At: Cc: Geoffrey Keating , TLS WG Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Jun 2015 08:49:19 -0000 --001a113cefa44e695f05179922c9 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 3, 2015 at 1:43 AM, Peter Gutmann wrote: > You seem to want everyone to change their behaviour in order to > accommodate > the fact that you've chosen to use a broken, buggy implementation > These aren't clients under my control. I am talking about an entire language ecosystem here, not just my little corner of the world. But even if they were my clients, they wouldn't negotiate DHE anyway, because most configurations would prefer ECDHE. The "accommodation" you're defending is using finite-field Diffie-Hellman. Most clients support ECDH(E) and don't need to support finite-field Diffie-Hellman. Finite field Diffie-Hellman is a slow, outmoded legacy key exchange algorithm that in my opinion should completely be abandoned. I didn't even bring up Java, but it was cited as a reason for FFDHE to exist. However Java 7 and 8 clients would prefer ECDHE anyway. As they should, it's faster and uses smaller keys. This is a case of some legacy gunk left over from the early days of TLS breaking key exchange for clients that support better algorithms. We can either double down on the gunk, or shut it off. *In practice* I have been telling people to shut it off and so far it's been a successful solution to the problem. Why should we keep this legacy gunk around? Who is it helping? -- Tony Arcieri --001a113cefa44e695f05179922c9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jun 3, 2015 at 1:43 AM, Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:
You seem to want everyone to change their behaviour in order to accommoda= te
the fact that you've chosen to use a broken, buggy implementation
=

These aren't clients under my co= ntrol. I am talking about an entire language ecosystem here, not just my li= ttle corner of the world. But even if they were my clients, they wouldn'= ;t negotiate DHE anyway, because most configurations would prefer ECDHE.

The "accommodation" you're defending i= s using finite-field Diffie-Hellman. Most clients support ECDH(E) and don&#= 39;t need to support finite-field Diffie-Hellman.

= Finite field Diffie-Hellman is a slow, outmoded legacy key exchange algorit= hm that in my opinion should completely be abandoned.

<= div>I didn't even bring up Java, but it was cited as a reason for FFDHE= to exist. However Java 7 and 8 clients would prefer ECDHE anyway. As they = should, it's faster and uses smaller keys.

Thi= s is a case of some legacy gunk left over from the early days of TLS breaki= ng key exchange for clients that support better algorithms.

<= /div>
We can either double down on the gunk, or shut it off.
=
*In practice* I have been telling people to shut it off and = so far it's been a successful solution to the problem.

Why should we keep this legacy gunk around? Who is it helping?

--
Tony Arcieri
--001a113cefa44e695f05179922c9-- From nobody Wed Jun 3 03:05: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 9CE511A00F4 for ; Wed, 3 Jun 2015 03:05:57 -0700 (PDT) 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 9Q2aMmVLJp6B for ; Wed, 3 Jun 2015 03:05:56 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6635C1A00E1 for ; Wed, 3 Jun 2015 03:05:56 -0700 (PDT) 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 (Postfix) with ESMTPS id DF70ABF9DF; Wed, 3 Jun 2015 10:05:55 +0000 (UTC) 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 t53A5rUq008284 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 3 Jun 2015 06:05:54 -0400 Message-ID: <1433325951.10465.9.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Tony Arcieri Date: Wed, 03 Jun 2015 12:05:51 +0200 In-Reply-To: References: <20150601225057.17500.96911.idtracker@ietfa.amsl.com> <1474500.r0W7gM0pAO@pintsize.usersys.redhat.com> <9A043F3CF02CD34C8E74AC1594475C73AB034F5F@uxcn10-tdc05.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73AB034FEB@uxcn10-tdc05.UoA.auckland.ac.nz> 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 WG , Geoffrey Keating Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Jun 2015 10:05:57 -0000 On Wed, 2015-06-03 at 01:48 -0700, Tony Arcieri wrote: > We can either double down on the gunk, or shut it off. > *In practice* I have been telling people to shut it off and so far > it's been a successful solution to the problem. > Why should we keep this legacy gunk around? Who is it helping? I agree that DHE is old and slow comparing to ECDHE and typically you wouldn't want it. However, it is one question to disable the ciphersuites you don't want, and another to remove DHE as a negotiation option for TLS. Removing the negotiation option means there there will be no backup at all in case of a flaw in the existing ECDHE ciphersuites. If you plan to serve buggy clients with broken DHE support, then the simplest approach is not to offer DHE to them. If you are in control of these broken clients, then disable DHE support in them. The draft is only slightly related to the issues you present on this thread. regards, Nikos From nobody Wed Jun 3 03:28: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 990FE1A0276 for ; Wed, 3 Jun 2015 03:28:45 -0700 (PDT) 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 VeJ9VSY2WsON for ; Wed, 3 Jun 2015 03:28:44 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 575A51A026A for ; Wed, 3 Jun 2015 03:28:44 -0700 (PDT) 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 (Postfix) with ESMTPS id B2CA4C9B28; Wed, 3 Jun 2015 10:28:43 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-112-73.ams2.redhat.com [10.36.112.73]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t53ASdto011279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Jun 2015 06:28:42 -0400 From: Hubert Kario To: Tony Arcieri Date: Wed, 03 Jun 2015 12:28:32 +0200 Message-ID: <1652097.MgMxVmTzFO@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.7 (Linux/4.0.4-202.fc21.x86_64; KDE/4.14.7; x86_64; ; ) In-Reply-To: References: <20150601225057.17500.96911.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3964062.8r4PniC4kr"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: Cc: Geoffrey Keating , TLS WG Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Jun 2015 10:28:45 -0000 --nextPart3964062.8r4PniC4kr Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Tuesday 02 June 2015 23:35:46 Tony Arcieri wrote: > On Tue, Jun 2, 2015 at 11:32 PM, Geoffrey Keating = wrote: > > It's covered in section 4: > > If at least one FFDHE ciphersuite is present in the client > > ciphersuite list, and the Supported Groups extension is either a= bsent > > from the ClientHello >=20 > Unless I'm mistaken, unless you configure the jdk.tls.disabledAlgorit= hms > property explicitly (with e.g. "DHE keySize > 2048"), Java clients ar= e > aborting *before* they send the ClientHello. sorry, that would be Spooky Action at a Distance... > Please let me know if you're > seeing otherwise. I could be mistaken and perhaps there's a server-si= de > workaround for this that isn't "disable all DHE ciphersuites". But th= is is > what I've personally observed and have been advising people about. >=20 > I'm not saying it can't be fixed with additional configuration/errata= /etc, > I'm arguing that it's *breaking clients in the field right now* >=20 > tl;dr: I am seeing *widespread TLS breakages* because of this resulti= ng in > *huge outages* for Java clients as it was pointed out - if the client doesn't see a ff-dhe extension it= should=20 either default to non-dhe ciphersuite or a legacy key size (2048 bit or= a=20 dynamically generated 1024 bit one if compatibility with very old Java = is=20 required) either of those solutions will make it possible to handle Java clients=20= smoothly Java clients get broken *because* we don't have this extension in wides= pread=20 use =2D-=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 --nextPart3964062.8r4PniC4kr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJVbtbWAAoJEJKo0bgB0vX1PwcP/3DwVABkmBqACIvZzbnZUVGc Mtzy8QlgZMO6ohGDL1E6+6VE6RFC8SLZrokR2iIRNWBchlz+Jy4YLrCg2g8OEnU0 9g1q28iD9z9QyD4+On/h//6JUPAvY7E/aNrqhQM2i84ATZwb7hccx1Go1w4bUsS/ n+hJMCg3dKHKKehzbeg2+ULF2qvP0I32a0dqeaEHw51Kxm7qGupscXq1poz5A1S0 +8vgjpDLLCMPOIz3GTkBPbVcimkp0LXBfToqYM71OEnvFFHifvIk4hHHXcwyvjNj ZYwrDaKtiIVPiQPibe56lcqkuxhn3j00jRNoRr1L/h3DRZgm/nfwYAHS/rrr24sn qg8b2TfGLC99aKcKyyjUbHuMiqVDwOua4M/XAyYvFm7z8B7/5zrgs0A4G9QAT3LY zm6CQItL9RdzbMtJQB0yJZlj45Oi85COocZcFNkfN1BLr3B9K+Yh7TbvqJ7jqXJI UkAdwiai35axRql5JQclFzCK1mJyMAD9ZOY1Y9Oa6qXke1fpBIHunGRGiqpDARui gxosBipOJ6Z+8AUcT/cCHe8vHPpxbWAUqCwsdBgyEdI3j7kQX/o5hLVNhl6XsfDt PdkuxgsqryuDzA3pcrin9bEhjmNwbTcJ63/o6iogcRX509wdEwCsEy67OQgIWLcN /Oip3Qmkn0JQ8Nli62mG =lpwm -----END PGP SIGNATURE----- --nextPart3964062.8r4PniC4kr-- From nobody Wed Jun 3 08:47: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 0A80E1A90A7 for ; Wed, 3 Jun 2015 08:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_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 c4SRdfjaeYum for ; Wed, 3 Jun 2015 08:47:55 -0700 (PDT) Received: from sasl.smtp.pobox.com (pb-sasl1.int.icgroup.com [208.72.237.25]) by ietfa.amsl.com (Postfix) with ESMTP id D593C1A90A4 for ; Wed, 3 Jun 2015 08:47:55 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-sasl1.pobox.com (Postfix) with ESMTP id B191050AD1; Wed, 3 Jun 2015 11:47:49 -0400 (EDT) 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=iJCDDCi8XEeE zStwycWg2pMgAm8=; b=J/MhmhQ0D7+G+PDpSZhXV7wQu5l02OMk1YD7EJvwNwia OvrfZpO2efBS0PFicvwEojL/bKhBvORc5ZKxWBvGcdC9y6w52vwk4PinmwLCbEh7 vlft+ATXVVt6rg+29E1ZZY5+nv+e9H0EEdtBZP7I71RWHbdDTXzvDBrFRE8t3eU= 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=J1IbMP pIKB/O+1/MSn5s075JyS2YU/eaWi1d0J75Ce1c/qUnAHwHiwsUpIcurX1/vVJzEw tIMf0e+3OGswm8TVwh0IPczEKFckRrO4q9QIM5ztPVhObyece0kWYZ5GaNo+jAiz K0K+ewLdFav8Gh04iXjSiva1ywlRGXXbrawjI= Received: from pb-sasl1.int.icgroup.com (unknown [127.0.0.1]) by pb-sasl1.pobox.com (Postfix) with ESMTP id AAE9D50AD0; Wed, 3 Jun 2015 11:47:49 -0400 (EDT) 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 0BD1250ACF; Wed, 3 Jun 2015 11:47:48 -0400 (EDT) Message-ID: <556F21A2.6010303@pobox.com> Date: Wed, 03 Jun 2015 08:47:46 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Tony Arcieri References: <20150601225057.17500.96911.idtracker@ietfa.amsl.com> <1474500.r0W7gM0pAO@pintsize.usersys.redhat.com> <9A043F3CF02CD34C8E74AC1594475C73AB034F5F@uxcn10-tdc05.UoA.auckland.ac.nz> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: E2E49DDE-0A07-11E5-94A6-B18815BAEDE0-38729857!pb-sasl1.pobox.com Archived-At: Cc: TLS WG Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Jun 2015 15:47:57 -0000 Tony Arcieri wrote: > On Wed, Jun 3, 2015 at 1:07 AM, Peter Gutmann wrote: > > *You've got that exactly reversed, it's not "DHE is breaking > Java handshakes", it's "(Sun/Oracle's) Java is breaking DHE > handshakes".* > > Here in the real world things are written in Java and we have to deal > with that. Idealistically I'd wave a magic wand and all of the legacy > cruft would go away. Unfortunately I don't have that magic wand. I have > to keep the real-world systems talking to each other. > > I want real-world solutions to real-world problems, not idealistic zealotry. I recently added version-specific DH parameter sizes to my server code. When a client supports TLS 1.2, 2048-bit (or larger) parameters are used, otherwise 1024-bit parameters are sent. Legacy Java clients won't be negotiating version 1.2 so they are still able to connect. Unfortunately this feature fairs poorly when graded by SSL Labs because it is currently unaware of version-specific DH parameters, though I hear they are working on it. Mike From nobody Wed Jun 3 09:44: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 BE3861ACE9C for ; Wed, 3 Jun 2015 09:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72Q8heKq7lyf for ; Wed, 3 Jun 2015 09:44:08 -0700 (PDT) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) (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 795771ACF57 for ; Wed, 3 Jun 2015 09:44:08 -0700 (PDT) Received: by pdbki1 with SMTP id ki1so11243539pdb.1 for ; Wed, 03 Jun 2015 09:44:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AwIRa24u/LMBtOYz6hu7Hvg1h9mBtNlONfE03nClxLk=; b=TxSA0iQJsi1JcCCL4sojCm0/dJE6vG3/FqP2acG+cSePShJf0lzIlf9QQC47gZKMTm NRURfBdGED0ex4zDmZuvcyXdfhQmfnxKRe+hB/KOXA32pf1K/v0h43ZB+/X3/srBep3n vvwHURlrPdTAZ959dM8RFZXUHtWDXZMhOoT0ncMfwHlkhudm7BJFFlBrBQMkpkzW2ugP pl4En2Tkhw608LugEWN0qJ6QZXwWVjUTboAxvm6aFoC/dhYzs107l9lovduvxtsDQ3pS F5hhMDHeFDzwry7Bu04U7PVUFEArqq/Yx/VA+1Kp6ML272j8pSC+t/ZPxWo55qM5vKKb D6lA== MIME-Version: 1.0 X-Received: by 10.68.57.136 with SMTP id i8mr23857956pbq.74.1433349848191; Wed, 03 Jun 2015 09:44:08 -0700 (PDT) Received: by 10.70.66.5 with HTTP; Wed, 3 Jun 2015 09:44:08 -0700 (PDT) In-Reply-To: References: <20150601225057.17500.96911.idtracker@ietfa.amsl.com> <1474500.r0W7gM0pAO@pintsize.usersys.redhat.com> <9A043F3CF02CD34C8E74AC1594475C73AB034F5F@uxcn10-tdc05.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73AB034FEB@uxcn10-tdc05.UoA.auckland.ac.nz> Date: Wed, 3 Jun 2015 09:44:08 -0700 Message-ID: From: Peter Bowen To: Tony Arcieri Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: TLS WG , Geoffrey Keating Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Jun 2015 16:44:10 -0000 On Wed, Jun 3, 2015 at 1:48 AM, Tony Arcieri wrote: > On Wed, Jun 3, 2015 at 1:43 AM, Peter Gutmann > wrote: >> >> You seem to want everyone to change their behaviour in order to >> accommodate >> the fact that you've chosen to use a broken, buggy implementation > > > These aren't clients under my control. I am talking about an entire language > ecosystem here, not just my little corner of the world. But even if they > were my clients, they wouldn't negotiate DHE anyway, because most > configurations would prefer ECDHE. > > The "accommodation" you're defending is using finite-field Diffie-Hellman. > Most clients support ECDH(E) and don't need to support finite-field > Diffie-Hellman. > > I didn't even bring up Java, but it was cited as a reason for FFDHE to > exist. However Java 7 and 8 clients would prefer ECDHE anyway. As they > should, it's faster and uses smaller keys. > > This is a case of some legacy gunk left over from the early days of TLS > breaking key exchange for clients that support better algorithms. There are three classes of clients today: 1) Clients that support ECDH key exchange (with at least the NIST P-256 and NIST P-384 curves) 2) Clients that do not support ECDH but support FFDH with larger modp sizes 3) Clients that do not support ECDH but support FFDH only with smaller modp sizes (e.g. max size is only 1024 bits or 2048 bits) This draft supposes that there will continue to be clients that fall into the second class for the foreseeable future and given them a way to declare that they are not in the third class. While we would all like to see every client in the first class, I don't think that is a real option for a few more years. Until then, we should allow clients to indicate that they will accept reasonable modp sizes. That was a server can choose to allow them to use FFDH for key exchange but not offer FFDH for other clients. Thanks, Peter From nobody Wed Jun 3 10:23: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 C09391ACDB6 for ; Wed, 3 Jun 2015 10:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HyVnrx78ixp2 for ; Wed, 3 Jun 2015 10:23:40 -0700 (PDT) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::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 4352E1ACC8C for ; Wed, 3 Jun 2015 10:23:40 -0700 (PDT) Received: by qgep100 with SMTP id p100so6795661qge.3 for ; Wed, 03 Jun 2015 10:23:39 -0700 (PDT) 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=veY5fQi4NxAlsgXrdc16vPU7Ec55HBiNRJYyMW1iK58=; b=tMZqS8MV8m2ibaBnQqURRQq0tuLDWiNaTeGH6/j2o1T3pc5Z4+Wr7SLnab94Y4DDKZ wiKN34SVZcg9t0H8EqW1GHIbTui64mAp9EmQI/EK3Mi8lBzVTFe4ZDJ8gurKAyTePjic x2MO6mpPC54S9Gk8Q0DwYYq2DUzvSblI42szhb+s8FYzzk2FHXY0er6A2XFjADczJjtd gtjZe25oGuFcdT9/vWykg5omsUWt2ceheZBUd4Pihx5RmaZbzxILxiZrV8ujvOwP3fPZ i6+Gdf0C0fHVu48cPCrfEw+9LThDB/9sA+DkwOF6/fTKWFNBhKkIVRZgfQO+bZiww9ib NjCw== X-Received: by 10.55.49.73 with SMTP id x70mr18117001qkx.49.1433352219477; Wed, 03 Jun 2015 10:23:39 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id p59sm727705qga.1.2015.06.03.10.23.38 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 03 Jun 2015 10:23:38 -0700 (PDT) From: Dave Garrett To: Tony Arcieri Date: Wed, 3 Jun 2015 13:23:36 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <20150601225057.17500.96911.idtracker@ietfa.amsl.com> <201506030405.47936.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201506031323.37163.davemgarrett@gmail.com> Archived-At: Cc: "" , Geoffrey Keating Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Jun 2015 17:23:41 -0000 On Wednesday, June 03, 2015 04:20:15 am Tony Arcieri wrote: > On Wed, Jun 3, 2015 at 1:05 AM, Dave Garrett wrote: > > Well... here's a way it could: > > 1) Deprecate/prohibit all "DH(E)_*" cipher suites > > I'm a bit unclear on this, but I think that's actually happening as part of TLS 1.3? No, that's what you're proposing with a diediedie. (seems to have been a miscommunication here) DH_* (non-ephemeral) are being deprecated in TLS 1.3. DHE_* are still in TLS 1.3. You're argument is that non-ECC DH(E) is harmful because Java is crap and chokes on it. (yeah, Java should be fixed, but it is crap and out there and breaking, and getting rid of DH(E) would fix that) What I said was: > 1) Deprecate/prohibit all "DH(E)_*" cipher suites > 2) Create a new set of "FFDHE_*" cipher suites to replace them that only allow strong groups (3072+) My suggestion is to do exactly what you propose, publish a DH(E) diediedie, but in the same RFC standardize a new set of DHE cipher suites with strong requirements using a new prefix (e.g. FFDHE) and new codepoint assignments. Servers supporting these new suites will never negotiate them with old clients that don't support them, but newer clients that add support will be able to negotiate DHE using the new cipher suites. It's a cake-and-eat-it-too suggestion. Kill old DH(E) and replace it with a limited set of new suites that are only usable with strong groups and only supported by new clients. Dave From nobody Wed Jun 3 10:49: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 B3AC81ACCFB for ; Wed, 3 Jun 2015 10:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wbh4YgNvEV1K for ; Wed, 3 Jun 2015 10:49:04 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id E18D01A9236 for ; Wed, 3 Jun 2015 10:49:03 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 7D90BF984; Wed, 3 Jun 2015 13:49:01 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 51C2D1FF76; Wed, 3 Jun 2015 13:48:39 -0400 (EDT) From: Daniel Kahn Gillmor To: Dave Garrett , Tony Arcieri In-Reply-To: <201506031323.37163.davemgarrett@gmail.com> References: <20150601225057.17500.96911.idtracker@ietfa.amsl.com> <201506030405.47936.davemgarrett@gmail.com> <201506031323.37163.davemgarrett@gmail.com> User-Agent: Notmuch/0.20 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Wed, 03 Jun 2015 13:48:39 -0400 Message-ID: <877frk7keg.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "" , Geoffrey Keating Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Jun 2015 17:49:05 -0000 On Wed 2015-06-03 13:23:36 -0400, Dave Garrett wrote: > On Wednesday, June 03, 2015 04:20:15 am Tony Arcieri wrote: >> On Wed, Jun 3, 2015 at 1:05 AM, Dave Garrett wrote: >> > Well... here's a way it could: >> > 1) Deprecate/prohibit all "DH(E)_*" cipher suites >> >> I'm a bit unclear on this, but I think that's actually happening as part of TLS 1.3? > > No, that's what you're proposing with a diediedie. (seems to have been a miscommunication here) > > DH_* (non-ephemeral) are being deprecated in TLS 1.3. DHE_* are still > in TLS 1.3. You're argument is that non-ECC DH(E) is harmful because > Java is crap and chokes on it. (yeah, Java should be fixed, but it is > crap and out there and breaking, and getting rid of DH(E) would fix > that) > > What I said was: >> 1) Deprecate/prohibit all "DH(E)_*" cipher suites >> 2) Create a new set of "FFDHE_*" cipher suites to replace them that only allow strong groups (3072+) > > My suggestion is to do exactly what you propose, publish a DH(E) > diediedie, but in the same RFC standardize a new set of DHE cipher > suites with strong requirements using a new prefix (e.g. FFDHE) and > new codepoint assignments. Servers supporting these new suites will > never negotiate them with old clients that don't support them, but > newer clients that add support will be able to negotiate DHE using the > new cipher suites. > > It's a cake-and-eat-it-too suggestion. Kill old DH(E) and replace it > with a limited set of new suites that are only usable with strong > groups and only supported by new clients. Alternately, we can get the same functionality with the negotiated-ff-dhe draft: * servers compatible with the draft can choose to never negotiate ffdhe with clients that don't advertise support. * newer client will be able to negotiate ffdhe with these servers by advertising support. The main difference depends on what newer clients want old servers to do: If clients are willing for old servers to go ahead and negotiate FFDHE ciphersuites even if their parameters might be dubious, then in your proposal they need to offer both sets of ciphersuites (possibly increasing the list of ciphersuites beyond 64, which may tickle other bugs [0]) If clients want old servers to never negotiate an FFDHE ciphersuite unless they're offering good parameters, then under your proposal they simply offer the new ciphersuites. Under the current negotiated-ff-dhe draft, a client receiving bad parameters from the server has to abort a connection (and can subsequently re-try without listing any FFDHE ciphersuites if it wants). For TLS 1.3, i'm expecting that any FFDHE ciphersuites will have a radically different handshake, so very little of this is relevant (plus, it will be TLS 1.3, so we can treat the existing ciphersuites differently based on the version of the protocol in use). So the negotiated-ff-dhe draft aimed for the simplest, most minimal change for 1.2 and earlier. Regards, --dkg [0] e.g. see Message-ID: 20131107213744.GQ18713@localhost on this mailing list, "Windows 2003 TLS 64 ciphersuite limit" from Nico Williams, 2013-11-07 From nobody Wed Jun 3 10:57: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 7ACE61A8F43 for ; Wed, 3 Jun 2015 10:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 a7FOajW70n-W for ; Wed, 3 Jun 2015 10:57:16 -0700 (PDT) Received: from emh07.mail.saunalahti.fi (emh07.mail.saunalahti.fi [62.142.5.117]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 177981A0167 for ; Wed, 3 Jun 2015 10:57:16 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id BF3443FC3; Wed, 3 Jun 2015 20:57:13 +0300 (EEST) Date: Wed, 3 Jun 2015 20:57:13 +0300 From: Ilari Liusvaara To: Daniel Kahn Gillmor Message-ID: <20150603175713.GA15962@LK-Perkele-VII> References: <20150601225057.17500.96911.idtracker@ietfa.amsl.com> <201506030405.47936.davemgarrett@gmail.com> <201506031323.37163.davemgarrett@gmail.com> <877frk7keg.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <877frk7keg.fsf@alice.fifthhorseman.net> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: "" Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Jun 2015 17:57:21 -0000 On Wed, Jun 03, 2015 at 01:48:39PM -0400, Daniel Kahn Gillmor wrote: > > For TLS 1.3, i'm expecting that any FFDHE ciphersuites will have a > radically different handshake, so very little of this is relevant (plus, > it will be TLS 1.3, so we can treat the existing ciphersuites > differently based on the version of the protocol in use). So the > negotiated-ff-dhe draft aimed for the simplest, most minimal change for > 1.2 and earlier. On protocol level, in TLS 1.3-latest, the only difference between DHE and ECDHE appears to be that DHE has 2-byte length filed, while ECDHE has 1-byte length field (and both then are packed alone into variable- length field with redundant 2-byte length field...). -Ilari From nobody Wed Jun 3 13:04: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 3E27B1B2A87 for ; Wed, 3 Jun 2015 13:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.41 X-Spam-Level: X-Spam-Status: No, score=-6.41 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, GB_I_LETTER=-2, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.723, 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 w-yA914I-onw for ; Wed, 3 Jun 2015 13:04:44 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) (using TLSv1 with cipher CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB8F61B2A91 for ; Wed, 3 Jun 2015 13:04:44 -0700 (PDT) Received: from /spool/local by e32.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 3 Jun 2015 14:04:44 -0600 Received: from d03dlp01.boulder.ibm.com (9.17.202.177) by e32.co.us.ibm.com (192.168.1.132) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 3 Jun 2015 14:04:43 -0600 Received: from b03cxnp07028.gho.boulder.ibm.com (b03cxnp07028.gho.boulder.ibm.com [9.17.130.15]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id 84AC21FF0030 for ; Wed, 3 Jun 2015 13:55:52 -0600 (MDT) Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by b03cxnp07028.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t53K2F2022413548 for ; Wed, 3 Jun 2015 13:02:16 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t53K4Uan006960 for ; Wed, 3 Jun 2015 14:04:30 -0600 Received: from d40lp02.lotus.com ([9.32.8.79]) by d03av04.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id t53K4TGw006874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 3 Jun 2015 14:04:30 -0600 Received: from /spool/local by d40lp02.lotus.com with XMail ESMTP for from ; Wed, 3 Jun 2015 15:22:24 -0400 Received: from smtp.notes.scniris.com (173.192.202.219) by d40lp02.lotus.com (192.147.107.239) with XMail ESMTP; (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256/256) Wed, 3 Jun 2015 15:22:22 -0400 Received: from /spool/local by smtp.notes.scniris.com with ESMTP for from ; Wed, 3 Jun 2015 20:04:54 -0000 Received: from irisa-smtp01.ir3.wdc01.isc4sb.com (10.102.14.125) by smtp.notes.scniris.com (10.102.16.160) with ESMTP; Wed, 3 Jun 2015 20:04:52 -0000 Received: from irisa-mail02.ir3.wdc01.isc4sb.com ([10.102.14.98]) by irisa-smtp01.ir3.wdc01.isc4sb.com with ESMTP id 2015060320083449-25 ; Wed, 3 Jun 2015 20:08:34 +0000 Sensitivity: In-Reply-To: References: MIME-Version: 1.0 Importance: Normal X-Priority: 3 (Normal) From: "Dave Kern" To: tls@ietf.org Date: Wed, 3 Jun 2015 20:04:23 +0000 X-Mailer: Lotus Domino Web Server Build V851SAAS_05262015_FP1 May 29, 2015 X-LLNOutbound: False X-TNEFEvaluated: 1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 x-cbid: 15060320-0005-0000-0000-00000FA31F25 X-IBM-ISS-SpamDetectors: Score=0.397008; BY=0; FL=0; FP=0; FZ=0; HX=0; KW=0; PH=0; SC=0.397008; ST=0; TS=0; UL=0; ISC= X-IBM-ISS-DetailInfo: BY=3.00003991; HX=3.00000235; KW=3.00000007; PH=3.00000003; SC=3.00000107; SDB=6.00539884; UDB=6.00227219; UTC=2015-06-03 20:04:53 x-cbparentid: 15060320-0466-0000-0000-0000012F81EB Message-Id: X-IBM-ISS-SpamDetectors: ISC= X-IBM-ISS-DetailInfo: BY=3.00003991; HX=3.00000235; KW=3.00000007; PH=3.00000003; SC=3.00000107; SDB=6.00539883; UDB=6.00227218; UTC=2015-06-03 19:22:23 X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Jun 2015 20:04:46 -0000
=0A
=0A
>
=0A> Please show m= e an HTTPS server I can point my DHE-enabled Java 6 and 7
=0A> client= s at and have them successfully negotiate a TLS session. I dare you.
= =0A=0A
>
=0A
=0A=0A
 
=0A=0AI'll rise to the bait. Point your Java client at any current= IBM Domino server that is configured according to the current recommendati= ons:
=0A=0A
 
=0A=0A=0A=0A
 
=0A=0A
The only DHE cipher supported by Java 6 and 7 is TLS=5FDHE=5FRSA=5FWITH= =5FAES=5F128=5FCBC=5FSHA (0x0033), so as long as that one cipher is not ena= bled Java 6 and 7 will end up with something they can handle, such as TLS= =5FRSA=5FWITH=5FAES=5F128=5FCBC=5FSHA (0x002F) and modern clients will end = up with something stronger.
=0A=0A
 
=0A=0A=
We also have changes in the current development stream to= prioritize 0x0033 below 0x002F as the last of the AES ciphers -- submitted= post-Logjam -- and to always use a 1024 bit DH group with 0x0033 instead o= f the default or configured stronger DH group -- submited pre-Logjam but le= ft in place because being potentially vulnerable to Three Letter Agencies i= s still better than failing the handshake and transmitting data in the clea= r.
=0A=0A
 
=0A=0A
Servers= *can* provide strong DHE groups to modern browsers and avoid loss of compa= tibility with Java 6 and 7, and it's not even very much work to do so.=0A=0A
 
=0A=0A
Hope that help= s,
=0A=0A
 
=0A=0A
dave=0A 
=0A=0A
 
=0A
=0A From nobody Wed Jun 3 13:13: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 AEF561ACE7F for ; Wed, 3 Jun 2015 13:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yylymRUvhNfU for ; Wed, 3 Jun 2015 13:13:16 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 12ABE1ACD58 for ; Wed, 3 Jun 2015 13:13:16 -0700 (PDT) Received: by qkhq76 with SMTP id q76so12443913qkh.2 for ; Wed, 03 Jun 2015 13:13:15 -0700 (PDT) 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=BalzGi3XsP1zT4Xmi3BIdWKuE0sCTRjeUQpOc5TBOSQ=; b=dtKT+10hlwR8FQGwzJhpIvGVdx62bjljthz9BBdLkTZpbBvAmtQ1D8IHov3yWy6ws+ mQ/m9LEL90HCfs4D6V1foI18ijxwggvmmWMbgN1uAdwePn2t0GLUrG6EpJerGKqUKrSI 93uuVgHdFjo9wcsrLH8eazoFyIhqZ185tLTImZ+8F2dXeUNXAdpGX4KzGEyDWqrpCYZF Wrqcwkf5sV9SBH2Z5loPkwZomN4rBDUaRA2h6r8hSrsfA3bUZMeeAfAuy60w/iIHNVAB cfCXerxfL7jt9IQhWljT1aGyPZK39TP9aWnDwNwd9y0d6J7ruanoFyQJQkYGZS/GTJ2U dwew== X-Received: by 10.55.27.78 with SMTP id b75mr63448790qkb.7.1433362395294; Wed, 03 Jun 2015 13:13:15 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id f192sm1011315qhc.37.2015.06.03.13.13.14 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 03 Jun 2015 13:13:14 -0700 (PDT) From: Dave Garrett To: Daniel Kahn Gillmor , Tony Arcieri Date: Wed, 3 Jun 2015 16:13:13 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <20150601225057.17500.96911.idtracker@ietfa.amsl.com> <201506031323.37163.davemgarrett@gmail.com> <877frk7keg.fsf@alice.fifthhorseman.net> In-Reply-To: <877frk7keg.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201506031613.13571.davemgarrett@gmail.com> Archived-At: Cc: "" , Geoffrey Keating Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Jun 2015 20:13:17 -0000 On Wednesday, June 03, 2015 01:48:39 pm Daniel Kahn Gillmor wrote: > On Wed 2015-06-03 13:23:36 -0400, Dave Garrett wrote: > > My suggestion is to do exactly what you propose, publish a DH(E) > > diediedie, but in the same RFC standardize a new set of DHE cipher > > suites with strong requirements using a new prefix (e.g. FFDHE) and > > new codepoint assignments. Servers supporting these new suites will > > never negotiate them with old clients that don't support them, but > > newer clients that add support will be able to negotiate DHE using the > > new cipher suites. > > Alternately, we can get the same functionality with the > negotiated-ff-dhe draft: > > * servers compatible with the draft can choose to never negotiate ffdhe > with clients that don't advertise support. > > * newer client will be able to negotiate ffdhe with these servers by > advertising support. > > The main difference depends on what newer clients want old servers to do: > > If clients are willing for old servers to go ahead and negotiate > FFDHE ciphersuites even if their parameters might be dubious, then in > your proposal they need to offer both sets of ciphersuites (possibly > increasing the list of ciphersuites beyond 64, which may tickle other > bugs [0]) > > If clients want old servers to never negotiate an FFDHE ciphersuite > unless they're offering good parameters, then under your proposal > they simply offer the new ciphersuites. Under the current > negotiated-ff-dhe draft, a client receiving bad parameters from the > server has to abort a connection (and can subsequently re-try without > listing any FFDHE ciphersuites if it wants). Yes, exactly. > For TLS 1.3, i'm expecting that any FFDHE ciphersuites will have a > radically different handshake, so very little of this is relevant (plus, > it will be TLS 1.3, so we can treat the existing ciphersuites > differently based on the version of the protocol in use). So the > negotiated-ff-dhe draft aimed for the simplest, most minimal change for > 1.2 and earlier. The topic brought up by Tony Arcieri was the apparent plague of old Java clients using TLS currently. A replacement set of cipher suites would transparently fix this in a simpler way. It adds more suites, yes, but it would ensure that this is only ever even _attempted_ to be negotiated between clients and servers that both support them properly. A replacement set of FFDHE cipher suites would also be useful to more clearly segregate the clients and servers that support strong FFDHE from those that support weak parameters. A server supported suites scan would very clearly show the capabilities without having to check the extension for more detail. Even if this could all be technically implemented without new suite names/codepoints, doing so could be safer to manage and a bit more mistake-resistant. Dave From nobody Wed Jun 3 13:51: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 857D41B2B48 for ; Wed, 3 Jun 2015 13:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.5 X-Spam-Level: X-Spam-Status: No, score=0.5 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, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-0iFqz8bPZI for ; Wed, 3 Jun 2015 13:51:00 -0700 (PDT) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (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 1101F1B2B45 for ; Wed, 3 Jun 2015 13:51:00 -0700 (PDT) Received: by objn8 with SMTP id n8so17944728obj.3 for ; Wed, 03 Jun 2015 13:50:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VG0FfVU6sA6dOL4DdFKKtNJr5Au3tzODNF7R/O1xzd0=; b=ww4Q4XpjC2LnOqJUDhu2nbtf+I7la6V7br/o0GYe8CK5a9MgAz5u3YH5kKjcB/D7vt yRGkCDA12ozbW09dEJQUPt7vHoEUf1jKN01G0OPWCgeOonrL25oW7XHK+xcAwSf45Sju lmYLC4Fwbpq12HtLgice74UpqfL5SF4mb2l4aj9RmIRVhHNdpr6/gy2Hu7YHwjVPZ93m AJQveKZ6JX0Ps3FvZ8+AfmfxJToAOqJ7Uv/FLnvR7UMz5NEHVjnv+lE4enoxJN7h0GTe 6Xv3IIukZPQLoAXxbItAHZKtOnXR6yCBY+oYWlMOuQj5z+KaXdSPPx5jnJMlIKBs5jf5 GzvA== MIME-Version: 1.0 X-Received: by 10.60.79.193 with SMTP id l1mr21511373oex.60.1433364659503; Wed, 03 Jun 2015 13:50:59 -0700 (PDT) Received: by 10.76.110.241 with HTTP; Wed, 3 Jun 2015 13:50:59 -0700 (PDT) In-Reply-To: <201506031613.13571.davemgarrett@gmail.com> References: <20150601225057.17500.96911.idtracker@ietfa.amsl.com> <201506031323.37163.davemgarrett@gmail.com> <877frk7keg.fsf@alice.fifthhorseman.net> <201506031613.13571.davemgarrett@gmail.com> Date: Wed, 3 Jun 2015 13:50:59 -0700 Message-ID: From: Tony Arcieri To: Dave Garrett Content-Type: multipart/alternative; boundary=089e011773735d0bcf0517a3379c Archived-At: Cc: "" , Geoffrey Keating Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Jun 2015 20:51:01 -0000 --089e011773735d0bcf0517a3379c Content-Type: text/plain; charset=UTF-8 On Wednesday, June 3, 2015, Dave Garrett wrote: > The topic brought up by Tony Arcieri was the apparent plague of old Java > clients using TLS currently. A replacement set of cipher suites would > transparently fix this in a simpler way. It adds more suites, yes, but it > would ensure that this is only ever even _attempted_ to be negotiated > between clients and servers that both support them properly. That's "half the battle", IMO, and I think the other half of my argument was lost in a swarm of "LOL Java, there's your problem" responses. I also called out the "what about a catastrophic ECC failure?" in advance and yet that is somehow the main "pedantic" response I've been receiving to my complaints. I get it. I get it so much I predicted people would say it in my very first post to this thread. Then they confirmed my hypothesis. But if we're switching to ECC for certificates too, what hypothetical attack breaks ECDH but not ECDSA/EdDSA/etc, and is it really worth convoluting TLS with extra baggage in preparation of a hypothetical attack? Should everyone continue to obtain RSA certs i. the event of an ECCpocalypse? I'm pretty firmly convinced people aren't really fully thinking through. The pat-on-the-head "you don't understand we need this if ECC breaks" responses are myopic, insulting, and an indicator that people aren't actually reading/comprehending my arguments here (the same goes for "that's just a Java problem" reaponses) The main thing I'ge observed as an SSL/TLS practicioner is extra bells and whistles that aren't commonly used leading to practial attacks, and people making haphazard changes to defend against these attacks breaking clients in the process. I care a lot more about the attacks and breakages happening in the real world *right now* than extremely speculative future attacks for which we're pre-emptively adding additional baggage/attack surface. That said, I think everyone is convincing me FFDHE *might* be a good idea. Particularly persuasive is Ilari's argument that with some tiny changes, ECDHE and FFDHE can be unified. -- Tony Arcieri --089e011773735d0bcf0517a3379c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wednesday, June 3, 2015, Dave Garrett <davemgarrett@gmail.com> wrote:
The topic brought up by Tony Arcieri was the apparent plag= ue of old Java clients using TLS currently. A replacement set of cipher sui= tes would transparently fix this in a simpler way. It adds more suites, yes= , but it would ensure that this is only ever even _attempted_ to be negotia= ted between clients and servers that both support them properly.

That'= s "half the battle", IMO, and I think the other half of my argume= nt was lost in a swarm of "LOL Java, there's your problem" re= sponses. I also called out the "what about a catastrophic ECC failure?= " in advance and yet that is somehow the main "pedantic" res= ponse I've been receiving to my complaints.

I = get it. I get it so much I predicted people would say it in my very first p= ost to this thread. Then they confirmed my hypothesis. But if we're swi= tching to ECC for certificates too, what hypothetical attack breaks ECDH bu= t not ECDSA/EdDSA/etc, and is it really worth convoluting TLS with extra ba= ggage=C2=A0in preparation of a hypothetical attack? Should everyone continu= e to obtain RSA certs i. the event of an ECCpocalypse?=C2=A0=C2=A0I'm p= retty firmly convinced people aren't really fully thinking through. The= pat-on-the-head "you don't understand we need this if ECC breaks&= quot; responses are myopic, insulting, and an indicator that people aren= 9;t actually reading/comprehending my arguments here (the same goes for &qu= ot;that's just a Java problem" reaponses)
<= br>
The main thing I'ge observed as an SSL/TLS practicioner i= s extra bells and whistles that aren't commonly used leading to practia= l attacks, and people making haphazard changes to defend against these atta= cks breaking clients in the process. I care a lot more about the attacks an= d breakages happening in the real world *right now* than extremely speculat= ive future attacks for which=C2=A0we're pre-emptively adding additional= baggage/attack surface.

That said, I think everyo= ne is convincing me FFDHE *might* be a good idea. Particularly persuasive i= s Ilari's argument that with some tiny changes, ECDHE and FFDHE can be = unified.


--
Tony Arcieri

--089e011773735d0bcf0517a3379c-- From nobody Wed Jun 3 14:02: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 796E11B2D87 for ; Wed, 3 Jun 2015 14:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iHNJaywy2qj3 for ; Wed, 3 Jun 2015 14:02:35 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 069A01B2D85 for ; Wed, 3 Jun 2015 14:02:35 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 33754F984; Wed, 3 Jun 2015 17:02:32 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 46EF120139; Wed, 3 Jun 2015 17:02:10 -0400 (EDT) From: Daniel Kahn Gillmor To: Tony Arcieri , Dave Garrett In-Reply-To: References: <20150601225057.17500.96911.idtracker@ietfa.amsl.com> <201506031323.37163.davemgarrett@gmail.com> <877frk7keg.fsf@alice.fifthhorseman.net> <201506031613.13571.davemgarrett@gmail.com> User-Agent: Notmuch/0.20.1 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Wed, 03 Jun 2015 17:02:10 -0400 Message-ID: <87fv685wvh.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "" , Geoffrey Keating Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Jun 2015 21:02:36 -0000 On Wed 2015-06-03 16:50:59 -0400, Tony Arcieri wrote: > That said, I think everyone is convincing me FFDHE *might* be a good idea. > Particularly persuasive is Ilari's argument that with some tiny changes, > ECDHE and FFDHE can be unified. I think this is the biggest reason as well. Dropping FFDHE with the idea that we would fall back to RSA for key exchange would mean breaking with our goal of moving to all PFS handshakes for TLS 1.3 (modulo PSK, resumption, etc). Keeping FFDHE allows us an ECC fallback (should we need it) while keeping an otherwise unified framework for the newer version of the protocol. It also means that existing clients and servers that do FFDHE properly (not older java, as you note) can continue to work without requiring cutover immediately. --dkg From nobody Wed Jun 3 14:14: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 C2C401B2F19 for ; Wed, 3 Jun 2015 14:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4b4yIyl4OfeG for ; Wed, 3 Jun 2015 14:14:53 -0700 (PDT) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::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 51A771B2F1C for ; Wed, 3 Jun 2015 14:14:53 -0700 (PDT) Received: by igbyr2 with SMTP id yr2so123680156igb.0 for ; Wed, 03 Jun 2015 14:14:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=pv4UhhH3DWQ3j/+k6NWNTsPcJ4Db3BFLYzdY9Ighbzo=; b=BHfUv07oqTOFUWeKCBBoHAXtdZ5mlbAdCSaH3zCm+9c6OcovZNjTtWPkEumxYYWKmX beWb6avuAbGUoa+Svw+wISAl2QE/JKZ5kUcn3pBey8ALqU58cnBApp/2kwYhDVyP5OtR +xzvv/cw7raS1xJr+MAvzs3Ps1EZF5B061Wq3VQjRv0P5Y30ejYrXGQKkh6TAKI/DMz/ n6ZdxuQ2tuDcSwUEWNIvHcTPC9/A7aaEVhSxPg5RG86moB/+WQx4Y8U1eaQ9VfFCq6LS 9WPMeqj4to7I/98Zy7sAzajqPFnUC5hco7803bBm7EzBg/tvfEFuZKooTmbkJ4HTvT0B cMGg== MIME-Version: 1.0 X-Received: by 10.50.25.162 with SMTP id d2mr880199igg.11.1433366092764; Wed, 03 Jun 2015 14:14:52 -0700 (PDT) Received: by 10.36.77.15 with HTTP; Wed, 3 Jun 2015 14:14:52 -0700 (PDT) In-Reply-To: References: <20150601225057.17500.96911.idtracker@ietfa.amsl.com> <201506031323.37163.davemgarrett@gmail.com> <877frk7keg.fsf@alice.fifthhorseman.net> <201506031613.13571.davemgarrett@gmail.com> Date: Wed, 3 Jun 2015 17:14:52 -0400 Message-ID: From: Jeffrey Walton To: Tony Arcieri Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt 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: Wed, 03 Jun 2015 21:14:54 -0000 On Wed, Jun 3, 2015 at 4:50 PM, Tony Arcieri wrote: > > > On Wednesday, June 3, 2015, Dave Garrett wrote: >> >> The topic brought up by Tony Arcieri was the apparent plague of old Java >> clients using TLS currently. A replacement set of cipher suites would >> transparently fix this in a simpler way. It adds more suites, yes, but it >> would ensure that this is only ever even _attempted_ to be negotiated >> between clients and servers that both support them properly. > > > That's "half the battle", IMO, and I think the other half of my argument was > lost in a swarm of "LOL Java, there's your problem" responses. I also called > out the "what about a catastrophic ECC failure?" in advance and yet that is > somehow the main "pedantic" response I've been receiving to my complaints. > One thing to keep in mind with the Java clients... SSLSocketFactory.getInstance("TLS"); will return a socket with SSLv3 and TLS 1.0 enabled. You will also get the cipher suite zoo enabled. TLS 1.1 and 1.2 were even disabled for Java 7 (Java 8 finally enabled them). You have to jump through hoops to get something sane, like "TLS 1.0 and above with reasonable cipher suites". See, for example, http://stackoverflow.com/a/23365536/608639. So its not clear you would get desired behavior regardless of what happens. Old clients won't get the updates, and old and new code often won't utilize seek out desired socket behavior. Jeff From nobody Wed Jun 3 14:36: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 7A7371B2A70 for ; Wed, 3 Jun 2015 14:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AikpOmk7GF0U for ; Wed, 3 Jun 2015 14:36:34 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 CC1561AD0D2 for ; Wed, 3 Jun 2015 14:36:33 -0700 (PDT) Received: by qkx62 with SMTP id 62so13762912qkx.3 for ; Wed, 03 Jun 2015 14:36:33 -0700 (PDT) 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=aE2LFyjIYzlfYqFRxKMNont5S8wIk4Z7NKAmFO6cQ5Y=; b=zYK3O7gFCGutTaSuiMyJc4o10R2NRW9SB312Puf9IN+GBxSk9TeL9P8HodDXcV5Wqq GPamnAG/cB1EsznepXjcYwf9PZY4nq7W+UGGO/qpDlpDLE+1n9HTHXq8CrsSyHDtsKln VTPQTOs6XtIjsRlw0V9domiVfzSh+YxVyJAqkGpAhv5chZT3a9ALUN4zAT3biRkikGoQ 2aGe8sx46UWc1AS2Q+8qwOsjmhmPbH6WDeouqp0H6w+HTypeslOH5bwfZgXip3eSJu5h ELRfH8KCtEy5uVYD74l6NK+XijrMOsv3N05tj+weln1W53wutyS6eejG0a6deI/Gq5ZX pqDw== X-Received: by 10.55.25.134 with SMTP id 6mr63881282qkz.13.1433367393044; Wed, 03 Jun 2015 14:36:33 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id 9sm1148426qhy.1.2015.06.03.14.36.32 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 03 Jun 2015 14:36:32 -0700 (PDT) From: Dave Garrett To: Tony Arcieri , Daniel Kahn Gillmor Date: Wed, 3 Jun 2015 17:36:30 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <20150601225057.17500.96911.idtracker@ietfa.amsl.com> <201506031613.13571.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201506031736.31468.davemgarrett@gmail.com> Archived-At: Cc: "" , Geoffrey Keating Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Jun 2015 21:36:35 -0000 On Wednesday, June 03, 2015 04:50:59 pm Tony Arcieri wrote: > That said, I think everyone is convincing me FFDHE *might* be a good idea. > Particularly persuasive is Ilari's argument that with some tiny changes, > ECDHE and FFDHE can be unified. Actually, doing that completely is probably better than adding new suites. = Just do "DH(E)_*" diediedie and allow new implementations that negotiate "E= CDHE_*" to pick either a strong curve to do ECDHE or a strong group to do F= =46DHE, without needing to specify it in the suite. Back in the discussion about ways to improve negotiation of capabilities to= deal with the suite combinatorial explosion, the general consensus was tha= t the simplest a la cart route would be to only negotiate symmetric ciphers= via the suites and pick the rest via extensions, ignoring the parts in the= suite. The usage of FFDHE or ECDHE would be based on what gets negotiated = via the =E2=80=9Csupported_groups=E2=80=9D extension. This could be the gen= eral way forward for TLS 1.3+ and for older TLS clients that want to deprec= ate "DH(E)_*" suites as well. With this route, all endpoints that negotiate the use of the =E2=80=9Csuppo= rted_groups=E2=80=9D extension would: 1) Consider all "(EC)DHE_*" suites to be equivalent; any *DHE* suite would = use the same negotiation algorithm. (ephemeral only might be simplest; just= ditch non-FS) 2) Usage of FFDHE or ECDHE would be chosen based on the negotiated named gr= oup/curve based on client priority. 3) Endpoints that no longer wish to ever negotiate any weak DHE would stop = offering all "DHE_*" suites, which would now be considered deprecated. 4) The "ECDHE" prefix on suites would now essentially mean "ECC capable", r= ather than "only ECC". Dave From nobody Wed Jun 3 14:52: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 7F9E61B2C58 for ; Wed, 3 Jun 2015 14:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbvErn-JYDcW for ; Wed, 3 Jun 2015 14:52:13 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 1AB261B2C38 for ; Wed, 3 Jun 2015 14:52:13 -0700 (PDT) Received: by qkhq76 with SMTP id q76so13980414qkh.2 for ; Wed, 03 Jun 2015 14:52:12 -0700 (PDT) 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=jo436zGDe17SMYwcvsvdd1bo35uX0TOadZRaiGGmjrw=; b=s9B8KP5a5Li1h640lbkwF8eSO/6adObeXZgIoNM986u8zHjSppbpbxa5XlStQvgjnr ApaubOAgajxo0lNFVeDgm7ZofD86J8kYuKqwg5yN54r85ELGbvEAIBVwwh1CvDIRHKr2 7PgJOtgDn7miaAQamcN5nsoAYRxa3ARCAlMkZWdKt/yHjEZpIJJKpCQ3h/8Pgnc/hFvy ITcr2K/nDc6/iHzvHSSvy6CoHYra3dRsvfV4ynxg821+0kXj+O9ZPASbtQslzDKFLplY jFemf7hG4nZDle3f6Lu8TfCNa+OK6oysy8J+wOQdHiAloe+nd6rzNqWKFMEHh8dCmDIw 82jQ== X-Received: by 10.140.18.141 with SMTP id 13mr38466683qgf.96.1433368332440; Wed, 03 Jun 2015 14:52:12 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id 195sm1172553qhr.13.2015.06.03.14.52.11 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 03 Jun 2015 14:52:11 -0700 (PDT) From: Dave Garrett To: Daniel Kahn Gillmor Date: Wed, 3 Jun 2015 17:52:10 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <20150601225057.17500.96911.idtracker@ietfa.amsl.com> <201506031736.31468.davemgarrett@gmail.com> In-Reply-To: <201506031736.31468.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201506031752.10769.davemgarrett@gmail.com> Archived-At: Cc: "" Subject: [TLS] drop ffdhe2048? (was: I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Jun 2015 21:52:14 -0000 On Wednesday, June 03, 2015 05:36:30 pm Dave Garrett wrote: > pick either a strong curve to do ECDHE or a strong group to do FFDHE On the topic of "strong": https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-10#appendix-A.1 estimated symmetric-equivalent strengths: ffdhe2048: 103 bits ffdhe3072: 125 bits ffdhe4096: 150 bits ffdhe6144: 175 bits ffdhe8192: 192 bits If we only wish to support strong groups, then we should consider dropping ffdhe2048 and require ffdhe3072 or higher. (likewise, prohibit all curves under a ~128 bit security level) Also, a ~256 bit security level FFDHE group should probably be in the list, even if its performance is crap. Dave From nobody Wed Jun 3 15:04: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 86E151B2F61 for ; Wed, 3 Jun 2015 15:04:38 -0700 (PDT) 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 UEpPYlBM7s7m for ; Wed, 3 Jun 2015 15:04:37 -0700 (PDT) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) (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 A90771B2AE0 for ; Wed, 3 Jun 2015 15:04:36 -0700 (PDT) Received: by wgez8 with SMTP id z8so20110304wge.0 for ; Wed, 03 Jun 2015 15:04:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=+J/BQzx/LWwYKE4SCIvTeBwRjqqHhYu/z0gMYIhGyIE=; b=APen0uVtm0l2UqllWfjiAQ/csBmO398k23DWZM9VRq4FVoAfdq8Ag0SASqMbCn6YPZ t2BH0oN7s2GgVO+/R0e1Ues3D4hNn9Ns6ngwQz/4gFmZuxEVHAN4FaqOIdbdFk+Eg4Ax JmbO+3Q5DV5cu1UYKsxCejoyRn4+dcAEeWnzkjNrpD1tzpljrlgN3fcN+pRWnlsfJn1r Ksn4FubazBQN+AlIJmuQcHdxcfAUQ+zMG6K1qSGjI9JNIi4eWly8o/6racareckfAebU izM2DUvm822Yrzx+ABR91sd39WndTkaw5Gd0KvJ7Q0h2fuFera18wAoxqnWX3yHC6Key 46nQ== X-Gm-Message-State: ALoCoQmrHg39V0lXmtDfe+cF4m/fiEyYQ8zs3UpGGnMjmvN02jdMnIc3x2ysZGmItwTM2Mlz09ZH X-Received: by 10.180.75.8 with SMTP id y8mr1474625wiv.31.1433369075375; Wed, 03 Jun 2015 15:04:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.225.14 with HTTP; Wed, 3 Jun 2015 15:03:54 -0700 (PDT) In-Reply-To: <201506031752.10769.davemgarrett@gmail.com> References: <20150601225057.17500.96911.idtracker@ietfa.amsl.com> <201506031736.31468.davemgarrett@gmail.com> <201506031752.10769.davemgarrett@gmail.com> From: Eric Rescorla Date: Wed, 3 Jun 2015 15:03:54 -0700 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=f46d043c7b9c91f4aa0517a43e16 Archived-At: Cc: "" Subject: Re: [TLS] drop ffdhe2048? (was: I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Jun 2015 22:04:38 -0000 --f46d043c7b9c91f4aa0517a43e16 Content-Type: text/plain; charset=UTF-8 Please see: http://www.ietf.org/mail-archive/web/tls/current/msg14438.html On Wed, Jun 3, 2015 at 2:52 PM, Dave Garrett wrote: > On Wednesday, June 03, 2015 05:36:30 pm Dave Garrett wrote: > > pick either a strong curve to do ECDHE or a strong group to do FFDHE > > On the topic of "strong": > > > https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-10#appendix-A.1 > > estimated symmetric-equivalent strengths: > ffdhe2048: 103 bits > ffdhe3072: 125 bits > ffdhe4096: 150 bits > ffdhe6144: 175 bits > ffdhe8192: 192 bits > > If we only wish to support strong groups, then we should consider dropping > ffdhe2048 and require ffdhe3072 or higher. (likewise, prohibit all curves > under a ~128 bit security level) > > Also, a ~256 bit security level FFDHE group should probably be in the > list, even if its performance is crap. > > > Dave > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --f46d043c7b9c91f4aa0517a43e16 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Jun 3, 2015 at 2:52 PM, Dave = Garrett <davemgarrett@gmail.com> wrote:
On Wednesday, June 03, 2015 05:36:30 pm Dave Garrett wro= te:
> pick either a strong curve to do ECDHE or a strong group to do FFDHE
On the topic of "strong":

https://tools.ietf.org/html/draft-ietf-tls-= negotiated-ff-dhe-10#appendix-A.1

estimated symmetric-equivalent strengths:
ffdhe2048:=C2=A0 103 bits
ffdhe3072:=C2=A0 125 bits
ffdhe4096:=C2=A0 150 bits
ffdhe6144:=C2=A0 175 bits
ffdhe8192:=C2=A0 192 bits

If we only wish to support strong groups, then we should consider dropping = ffdhe2048 and require ffdhe3072 or higher. (likewise, prohibit all curves u= nder a ~128 bit security level)

Also, a ~256 bit security level FFDHE group should probably be in the list,= even if its performance is crap.


Dave

_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls

--f46d043c7b9c91f4aa0517a43e16-- From nobody Wed Jun 3 15:20: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 C975E1B3002 for ; Wed, 3 Jun 2015 15:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdbOY5Zs9J2s for ; Wed, 3 Jun 2015 15:20:53 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::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 41EB31B2FFF for ; Wed, 3 Jun 2015 15:20:53 -0700 (PDT) Received: by labpy14 with SMTP id py14so19025877lab.0 for ; Wed, 03 Jun 2015 15:20:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Cf8QsoArEvkSoB3UEDwk4r9H/h7zW5socnDuWCcGCrQ=; b=DiLN6GyofPIz7Cild74T1xF2jIo/qGtC63qtzmHnyn3NbRsV1cKjFDvIqz57Nm82V1 mrBaLgbjay8IWek0aZrg3zh5YluBuwJuCIa9DSdpT49llwP5D1209DD+LsWRw1cQW7g4 Ln8P/8wdmiM3jyqbzM+urzldlprK0dsJkLoqQOmb/RQT+NkVpuI355eOKxACC1Oq00ge 1avSKYvVRM3QTDJiBbFK5sQf8UCYoueBxiE9t1YmsNt4eIwpL0MtBmXQeRoEKH/IpMgx rp8NNkj/DRr1kikwQQIVTpSkzzOyxl1nwuzRYOzuXSKh39+3Vnd28/CLY5IiakZPVxZO FK+A== MIME-Version: 1.0 X-Received: by 10.112.220.7 with SMTP id ps7mr33707374lbc.72.1433370051665; Wed, 03 Jun 2015 15:20:51 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.112.89.69 with HTTP; Wed, 3 Jun 2015 15:20:51 -0700 (PDT) In-Reply-To: References: <20150527172329.GI27628@localhost> Date: Wed, 3 Jun 2015 15:20:51 -0700 X-Google-Sender-Auth: _3A4pKj3mneTWHnJPXzHN75DbLE Message-ID: From: Adam Langley To: David Benjamin Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] More clarity on resumption and 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: Wed, 03 Jun 2015 22:20:54 -0000 I've landed a change[1] in BoringSSL which enforces connection aborts in three cases: a) as a client: a session without EMS is resumed with a ServerHello that supports it. b) as a server or client: a session with EMS is resumed on a connection without EMS negotiated. It also causes servers not to resume sessions without EMS if the client offers EMS in the resumption ClientHello. Chrome will implement these behaviours in a future version and hopefully that's enough to ensure good behaviour in the ecosystem as a whole. [1] https://boringssl.googlesource.com/boringssl/+/ba5934b77f0058dc963b075e0ec1f401a24c0b2b Cheers AGL From nobody Thu Jun 4 10:51: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 70A061A6F3A for ; Thu, 4 Jun 2015 10:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.911 X-Spam-Level: X-Spam-Status: No, score=-8.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, 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 XhVTgDLfJCQ0 for ; Thu, 4 Jun 2015 10:51:45 -0700 (PDT) Received: from e38.co.us.ibm.com (e38.co.us.ibm.com [32.97.110.159]) (using TLSv1 with cipher CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EDDF1A6EFC for ; Thu, 4 Jun 2015 10:51:45 -0700 (PDT) Received: from /spool/local by e38.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 4 Jun 2015 11:51:45 -0600 Received: from d03dlp01.boulder.ibm.com (9.17.202.177) by e38.co.us.ibm.com (192.168.1.138) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 4 Jun 2015 11:51:43 -0600 Received: from b03cxnp08028.gho.boulder.ibm.com (b03cxnp08028.gho.boulder.ibm.com [9.17.130.20]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id DDD911FF004B for ; Thu, 4 Jun 2015 11:42:52 -0600 (MDT) Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by b03cxnp08028.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t54HpALH31064176 for ; Thu, 4 Jun 2015 10:51:10 -0700 Received: from d03av01.boulder.ibm.com (localhost [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t54Hpgd5005534 for ; Thu, 4 Jun 2015 11:51:42 -0600 Received: from d40lp02.lotus.com ([9.32.8.79]) by d03av01.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id t54Hpdro005163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 4 Jun 2015 11:51:40 -0600 Received: from /spool/local by d40lp02.lotus.com with XMail ESMTP for from ; Thu, 4 Jun 2015 13:09:32 -0400 Received: from smtp.notes.scniris.com (173.192.202.220) by d40lp02.lotus.com (192.147.107.239) with XMail ESMTP; (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256/256) Thu, 4 Jun 2015 13:09:29 -0400 Received: from /spool/local by smtp.notes.scniris.com with ESMTP for from ; Thu, 4 Jun 2015 17:52:17 -0000 Received: from irisa-smtp01.ir3.wdc01.isc4sb.com (10.102.14.125) by smtp.notes.scniris.com (10.102.16.161) with ESMTP; Thu, 4 Jun 2015 17:52:16 -0000 Received: from irisa-mail02.ir3.wdc01.isc4sb.com ([10.102.14.98]) by irisa-smtp01.ir3.wdc01.isc4sb.com with ESMTP id 2015060417554753-2272 ; Thu, 4 Jun 2015 17:55:47 +0000 To: tls@ietf.org MIME-Version: 1.0 X-KeepSent: 5946FEC0:7A8649FE-00257E5A:006179A2; type=4; name=$KeepSent X-Mailer: IBM Notes Release 9.0.1FP3 Octobe4, 2013 From: "Dave Kern" Date: Thu, 4 Jun 2015 13:51:33 -0400 X-LLNOutbound: False X-TNEFEvaluated: 1 Content-Type: text/plain; charset="US-ASCII" x-cbid: 15060417-0029-0000-0000-00000A4D7BE2 X-IBM-ISS-SpamDetectors: Score=0.388783; FL=0; FP=0; FZ=0; HX=0; KW=0; PH=0; SC=0.388783; ST=0; TS=0; UL=0; ISC= X-IBM-ISS-DetailInfo: BY=3.00003994; HX=3.00000235; KW=3.00000007; PH=3.00000003; SC=3.00000107; SDB=6.00540316; UDB=6.00227479; UTC=2015-06-04 17:52:16 x-cbparentid: 15060417-6194-0000-0000-0000003C9163 Message-Id: X-IBM-ISS-SpamDetectors: ISC= X-IBM-ISS-DetailInfo: BY=3.00003993; HX=3.00000235; KW=3.00000007; PH=3.00000003; SC=3.00000107; SDB=6.00540316; UDB=6.00227479; UTC=2015-06-04 17:09:30 X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Jun 2015 17:51:47 -0000 > > Please show me an HTTPS server I can point my DHE-enabled Java 6 and 7 > clients at and have them successfully negotiate a TLS session. I dare you. > I'll rise to the bait. Point your Java client at any current IBM Domino server that is configured according to the current recommendations: http://www-10.lotus.com/ldd/dominowiki.nsf/dx/TLS_Cipher_Configuration The only DHE cipher supported by Java 6 and 7 is TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033), so as long as that one cipher is not enabled Java 6 and 7 will probably end up with something they can handle, such as TLS_RSA_WITH_AES_128_CBC_SHA (0x002F) and modern clients will end up with a stronger DHE-RSA cipher. We also have changes in the current development stream to prioritize 0x0033 below 0x002F as the last of the AES ciphers -- submitted post-Logjam -- and to always use a 1024 bit DH group with 0x0033 instead of the (default or configured) stronger DH group -- submited pre-Logjam but left in place because being potentially vulnerable to Three Letter Agencies is still better than failing the handshake and transmitting data in the clear. Servers *can* provide strong DHE groups to modern browsers and avoid loss of compatibility with Java 6 and 7, and it's not even that much work to do so. Hope that helps, dave From nobody Thu Jun 4 18: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 D28B71ACDDB for ; Thu, 4 Jun 2015 18:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7sQ0LjwyT_Vf for ; Thu, 4 Jun 2015 18:02:55 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (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 181121A8AD0 for ; Thu, 4 Jun 2015 18:02:55 -0700 (PDT) Received: by obbir4 with SMTP id ir4so2250172obb.1 for ; Thu, 04 Jun 2015 18:02:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=LpLfcWFAowtPWziFLF3WUYV1zo27h8LDMrmTy+n32tA=; b=BAHTWQDh8f4VU39R/yf2fZUQpRZcrtC2QDDnFROEwyhW9p3uiB/5aS7vNvJW03mA+E yP8YXcHmQXBvflp9bN2UP8UEcPjrONbPIEAnrn4ngNm9aQ1CYE59Bm+8NP5F19oYvmUH U1OCypaFpI/BwfSAD7AuePCFnd+j4YtwRqGR5j+N2I1Bkai/eRr91+9XS3SlhtmS9rvM E52nnLzeWnO+kalHSxK/SmTMTLtOe4RhUbx0H+W8Z+1Nu+o2H7l6Vwe6agewB0YaGGVC q/JMkHmr6PXW+i2LUWw2jfmBdbNEVUs6Fe+8Oh09AdYYsXwZhR/RaQ3TOpRvE8E12TQW 8n2w== X-Received: by 10.202.174.67 with SMTP id x64mr638402oie.50.1433466174550; Thu, 04 Jun 2015 18:02:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.110.241 with HTTP; Thu, 4 Jun 2015 18:02:33 -0700 (PDT) In-Reply-To: References: <20150601225057.17500.96911.idtracker@ietfa.amsl.com> From: Tony Arcieri Date: Thu, 4 Jun 2015 18:02:33 -0700 Message-ID: To: "" Content-Type: multipart/alternative; boundary=001a113cefa421c2a50517bada8f Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 05 Jun 2015 01:02:57 -0000 --001a113cefa421c2a50517bada8f Content-Type: text/plain; charset=UTF-8 As I expected, one of the major issues seems to be having a backup in the event of a catastrophic failure of ECC: On Mon, Jun 1, 2015 at 4:02 PM, Tony Arcieri wrote: > I expect the response is going to be "What if there's some catastrophic > failure of ECC?" > On Wed, Jun 3, 2015 at 1:05 AM, Dave Garrett wrote: > People want a backup to deal with mistrust of ECC curves On Wed, Jun 3, 2015 at 3:05 AM, Nikos Mavrogiannopoulos wrote: > Removing the negotiation option means there there will > be no backup at all in case of a flaw in the existing ECDHE > ciphersuites. When I did a quick straw poll of the CFRG about this, the seemingly unanimous preference was if we do want to solve the general problem of an "ECC backup", we should be focusing on post-quantum algorithms, not shoring up FFDHE. I get the "RHEL5 problem" but I really don't care (sorry RedHat). It's basically the opposite of the kind of legacy support I was asking for, where we solve problems by *shutting off* legacy ciphers. Instead, to solve the "RHEL5 problem" we have to *further complicate TLS*. It seems people are colluding support for ancient clients with the need for a backup in the event of an ECC disaster. I think the matter of what to do about a backup option in the event of an ECCpocalypse is a question for the CFRG, not the TLS mailing list. -- Tony Arcieri --001a113cefa421c2a50517bada8f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As I= expected, one of the major issues seems to be having a backup in the event= of a catastrophic failure of ECC:

On Mon, Jun 1, 2015 at 4:02 PM, Tony Arcieri <= span dir=3D"ltr"><bascule@gmail.com> wrote:
I expect the response is going to be "What if there's some= catastrophic failure of ECC?"

=
On Wed, Jun 3, 2015 at 1:05 AM, Dave Garrett=C2=A0&l= t;davemgarrett@= gmail.com>=C2=A0wrote:
People want a back= up to deal with mistrust of ECC curves

On Wed, J= un 3, 2015 at 3:05 AM, Nikos Mavrogiannopoulos=C2=A0<<= a href=3D"mailto:nmav@redhat.com" target=3D"_blank">nmav@redhat.com>= =C2=A0wrote:
Removing the negotiation option mea= ns there there will
be no backup at all in case of a flaw in the existin= g ECDHE
ciphersuites.

When I did a quick= straw poll of the CFRG about this, the seemingly unanimous preference was = if we do want to solve the general problem of an "ECC backup", we= should be focusing on post-quantum algorithms, not shoring up FFDHE.
=

I get the "RHEL5 problem" but I really = don't care (sorry RedHat). It's basically the opposite of the kind = of legacy support I was asking for, where we solve problems by *shutting of= f* legacy ciphers. Instead, to solve the "RHEL5 problem" we have = to *further complicate TLS*.

It seems people are c= olluding support for ancient clients with the need for a backup in the even= t of an ECC disaster.

I think the matter of what t= o do about a backup option in the event of an ECCpocalypse is a question fo= r the CFRG, not the TLS mailing list.

--
Tony Arcieri
--001a113cefa421c2a50517bada8f-- From nobody Thu Jun 4 18:03: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 388041ACE69 for ; Thu, 4 Jun 2015 18:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A6RH5nyppv44 for ; Thu, 4 Jun 2015 18:03:37 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (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 302A51ACE68 for ; Thu, 4 Jun 2015 18:03:37 -0700 (PDT) Received: by oihb142 with SMTP id b142so43317276oih.3 for ; Thu, 04 Jun 2015 18:03:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=jClg4RImd5SmgbLARS8HfXxUs+0dlaB3LQPPExmmOhw=; b=AjAIIa8S6+w3iE6mYxmOZZ5ClMaFfPkF1jqdPIoTiFZGC9dYOZKwBDZpNcnD0i0mGj UjgZ4O8DR5gM4jMYVVBD5vcdoHevKZlLVHr2o9/wn6TPfeiByfVE1xCajbhaKwM5dZ8l JagGWuQExilNINXA6Mqq9o1m7tR/9s5Jp/H56J2XW5H9nGwAZhUPwMPDdDWrl8n8a9Bl McGPjfVaqIhwUXKGeYxQlT8eGb+6EMrEnh4IP9dun2pJKiCCpK9axPxjK0P05AuIC8YT UOSla/8HWAfNuZL5ecv2zSWmwKWoGbhqWiK8/zVS1P4rJ0Yz/cVQq6Sn2ArA8PcMgRO+ Kfcw== X-Received: by 10.202.52.138 with SMTP id b132mr577274oia.125.1433466216591; Thu, 04 Jun 2015 18:03:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.110.241 with HTTP; Thu, 4 Jun 2015 18:03:15 -0700 (PDT) In-Reply-To: References: From: Tony Arcieri Date: Thu, 4 Jun 2015 18:03:15 -0700 Message-ID: To: Dave Kern Content-Type: multipart/alternative; boundary=001a113d3e02a336620517badc40 Archived-At: Cc: "" Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 05 Jun 2015 01:03:38 -0000 --001a113d3e02a336620517badc40 Content-Type: text/plain; charset=UTF-8 On Thu, Jun 4, 2015 at 10:51 AM, Dave Kern wrote: > I'll rise to the bait. Thanks for taking my challenge, and mea culpa for being wrong. -- Tony Arcieri --001a113d3e02a336620517badc40 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jun 4, 2015 at 10:51 AM, Dave Kern <dskern@us.ibm.com> w= rote:
I'll rise to t= he bait.

Thanks for taking my challe= nge, and mea culpa for being wrong.=C2=A0

--
=
Tony Arcieri
--001a113d3e02a336620517badc40-- From nobody Fri Jun 5 01:44: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 88A581B2DDD for ; Fri, 5 Jun 2015 01:44:52 -0700 (PDT) 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 pYHXS0ha84rh for ; Fri, 5 Jun 2015 01:44:51 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 533401B2DDC for ; Fri, 5 Jun 2015 01:44:51 -0700 (PDT) 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 (Postfix) with ESMTPS id 8416FB5E91; Fri, 5 Jun 2015 08:44:50 +0000 (UTC) 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 t558imOw008518 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 5 Jun 2015 04:44:49 -0400 Message-ID: <1433493887.3170.5.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Tony Arcieri Date: Fri, 05 Jun 2015 10:44:47 +0200 In-Reply-To: References: <20150601225057.17500.96911.idtracker@ietfa.amsl.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: Cc: "" Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 05 Jun 2015 08:44:52 -0000 On Thu, 2015-06-04 at 18:02 -0700, Tony Arcieri wrote: > As I expected, one of the major issues seems to be having a backup in > the event of a catastrophic failure of ECC: > On Mon, Jun 1, 2015 at 4:02 PM, Tony Arcieri > wrote: > > I expect the response is going to be "What if there's some > > catastrophic failure of ECC?" > > > On Wed, Jun 3, 2015 at 1:05 AM, Dave Garrett > wrote: > > People want a backup to deal with mistrust of ECC curves > On Wed, Jun 3, 2015 at 3:05 AM, Nikos Mavrogiannopoulos < > nmav@redhat.com> wrote: > > Removing the negotiation option means there there will > > be no backup at all in case of a flaw in the existing ECDHE > > ciphersuites. > When I did a quick straw poll of the CFRG about this, the seemingly > unanimous preference was if we do want to solve the general problem > of an "ECC backup", we should be focusing on post-quantum algorithms, > not shoring up FFDHE. I agree, but I don't see any proposals so far. Once we have such an algorithm as backup we can drop FFDHE. regards, Nikos From nobody Fri Jun 5 05:46: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 71A0B1B2D9E for ; Fri, 5 Jun 2015 05:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 5BOQr0SAE5wd for ; Fri, 5 Jun 2015 05:46:45 -0700 (PDT) Received: from emh02.mail.saunalahti.fi (emh02.mail.saunalahti.fi [62.142.5.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4B9F1ACEEC for ; Fri, 5 Jun 2015 05:46:44 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id 9A8CD81873; Fri, 5 Jun 2015 15:46:41 +0300 (EEST) Date: Fri, 5 Jun 2015 15:46:41 +0300 From: Ilari Liusvaara To: Nikos Mavrogiannopoulos Message-ID: <20150605124641.GA13852@LK-Perkele-VII> References: <20150601225057.17500.96911.idtracker@ietfa.amsl.com> <1433493887.3170.5.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1433493887.3170.5.camel@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: "" Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 05 Jun 2015 12:46:47 -0000 On Fri, Jun 05, 2015 at 10:44:47AM +0200, Nikos Mavrogiannopoulos wrote: > On Thu, 2015-06-04 at 18:02 -0700, Tony Arcieri wrote: > > As I expected, one of the major issues seems to be having a backup in > > the event of a catastrophic failure of ECC: > > On Mon, Jun 1, 2015 at 4:02 PM, Tony Arcieri > > wrote: > > > I expect the response is going to be "What if there's some > > > catastrophic failure of ECC?" > > > > > On Wed, Jun 3, 2015 at 1:05 AM, Dave Garrett > > wrote: > > > People want a backup to deal with mistrust of ECC curves > > On Wed, Jun 3, 2015 at 3:05 AM, Nikos Mavrogiannopoulos < > > nmav@redhat.com> wrote: > > > Removing the negotiation option means there there will > > > be no backup at all in case of a flaw in the existing ECDHE > > > ciphersuites. > > When I did a quick straw poll of the CFRG about this, the seemingly > > unanimous preference was if we do want to solve the general problem > > of an "ECC backup", we should be focusing on post-quantum algorithms, > > not shoring up FFDHE. > > I agree, but I don't see any proposals so far. Once we have such an > algorithm as backup we can drop FFDHE. Unfortunately, PQ algorithms (and there do seem to be PQ key agreement algorithms that look sufficiently like Diffie-Hellman) are much less understood than DH or ECDH. Some relevant questions: - How much assurance there is to security of such scheme in general? - Approximately how fast the scheme runs (at least that it isn't hopelessly slow)? - How does exchange key size scale as function of estimated security level (especially as TLS is currently limited to 64kB keys, and PQ schemes tend to have very large keys)? - What mesages does the scheme need (especially, is it one from each in either order DH/ECDH has)? - Can the scheme use fixed sets of public paramters (especially as TLS 1.3 key exchange has that limit)? - How to perform trustworthy generation of the public parameters (some schemes have serious problems there)? - What regions of public parameters to avoid because of security issues? I don't know if this is even CFRG material at this point, let alone material for TLS WG. -Ilari From nobody Fri Jun 5 13:49: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 F3FFE1B3212 for ; Fri, 5 Jun 2015 13:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WS9gEqrlyKQt for ; Fri, 5 Jun 2015 13:49:18 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003: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 B4A001B320A for ; Fri, 5 Jun 2015 13:49:18 -0700 (PDT) Received: by obbgp2 with SMTP id gp2so40585311obb.2 for ; Fri, 05 Jun 2015 13:49:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=IWBn0dKZ0JPDkUeoubS7GBAc/AqKyJX3fxgo5oRkU/g=; b=daIjwgTrxkJGmU+L5Jriya5Bw0I1gz9Ey/GgcKUX0edsV3FZ2t9xWeKrXCHMgIE1YH LTrAGh0fxLvpKRq+66D0wGf1L1Iwq66UMlmcy7svdnO0pIJVcVVqwZdIyPN4C7pB35SB wPXvMk9PlHXt+nXkJ93CXVwqsdui13tfnxdpdbi3UL3/KxKgDLSSMYzeQnOoVgMiTv54 H55ghitZZL6LR9I3spVWgzMnbrPw3GZz+UPpLtJK5ryHxOCh8cBeJauFpj0Wbu5Cka6W eqk6T/vNGa6RxcJRN6N44sUjAEGHjGuFq94iDc4r/bhpAesLuydDIP6CM3xIKgkfT2bm NZuw== X-Received: by 10.182.115.161 with SMTP id jp1mr4630688obb.53.1433537358236; Fri, 05 Jun 2015 13:49:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.110.241 with HTTP; Fri, 5 Jun 2015 13:48:57 -0700 (PDT) In-Reply-To: <20150605124641.GA13852@LK-Perkele-VII> References: <20150601225057.17500.96911.idtracker@ietfa.amsl.com> <1433493887.3170.5.camel@redhat.com> <20150605124641.GA13852@LK-Perkele-VII> From: Tony Arcieri Date: Fri, 5 Jun 2015 13:48:57 -0700 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=089e01182cf202909a0517cb6d6f Archived-At: Cc: "" Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 05 Jun 2015 20:49:20 -0000 --089e01182cf202909a0517cb6d6f Content-Type: text/plain; charset=UTF-8 On Fri, Jun 5, 2015 at 5:46 AM, Ilari Liusvaara wrote: > I don't know if this is even CFRG material at this point, let alone > material for TLS WG. I don't know if the CFRG is ready to tackle this problem at this point, but I think the TLS WG is definitely the wrong place to tackle it. -- Tony Arcieri --089e01182cf202909a0517cb6d6f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jun 5, 2015 at 5:46 AM, Ilari Liusvaara <ilari.liusvaara@e= lisanet.fi> wrote:
I don&#= 39;t know if this is even CFRG material at this point, let alone
=
material for TLS WG.

I don't know if th= e CFRG is ready to tackle this problem at this point, but I think the TLS W= G is definitely the wrong place to tackle it.=C2=A0

--
Tony Arcieri
--089e01182cf202909a0517cb6d6f-- From nobody Fri Jun 5 19: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 DA2531ACDC7 for ; Fri, 5 Jun 2015 19:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 tAZF_h17RHTC for ; Fri, 5 Jun 2015 19:04:35 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 E0C631ACDB0 for ; Fri, 5 Jun 2015 19:04:34 -0700 (PDT) Received: from latte.josefsson.org ([216.55.31.130]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t5624Guv032532 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Sat, 6 Jun 2015 04:04:19 +0200 From: Simon Josefsson To: Russ Housley References: <556C4ACD.9040002@azet.org> <556C51FC.807@azet.org> <20150601125302.GA19269@LK-Perkele-VII> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:150606:housley@vigilsec.com::JASG3zg9/aNCS0/G:TXux X-Hashcash: 1:22:150606:tls@ietf.org::k2VipjCGa5YRgsHQ:aRLi X-Hashcash: 1:22:150606:ilari.liusvaara@elisanet.fi::tBtYPBMzZpXPKVxK:fyxi Date: Sat, 06 Jun 2015 04:04:09 +0200 In-Reply-To: (Russ Housley's message of "Mon, 1 Jun 2015 12:29:19 -0400") Message-ID: <87vbf1384m.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: TLS Mailing List Subject: Re: [TLS] AES-OCB in TLS [New Version Notification for draft-zauner-tls-aes-ocb-03.txt] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Jun 2015 02:04:36 -0000 --=-=-= Content-Type: text/plain Russ Housley writes: > Ilari: > >> I think the current plan with EdDSA and related certficates are to reuse >> ECDSA codepoints, relying on extension (defined by RFC5246) to negotiate. > > When we were doing to work for RSA PKCS #1 v1.5, OAEP, and PSS, it was > unclear whether using the same key pair with all of these schemes > would lead to trouble. For this reason, the certificate can allow the > key pair to be used for just on or all of them. > > The same question needs to be asked here. I hope a more definitive > answer becomes available this time. Is that really comparable? All RSA signature schemes use the same RSA private keys. For ECDSA and EdDSA this is not the case. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJVclUZAAoJEIYLf7sy+BGdgJcH/38nmAhY5gT846spcwaxTUCg 2HeBhk711YCLmQZjCD1otDvPPnEbTE2EwexfXAt8lxpex7TPiC21aqRlaVW3sPys T9+X2XCFBV901Ji7DxhhB7WqDo1jF8FTqJt1rup0jwCA1FEQYyawsARSNf/6X16Y hfojDtyHnWUG5L0H0U1NhUtlag9C7s/KEzDbJ5Q7Dm6jTI56wUn7sjc8kQmE5Fn2 tmHGKHH86doavTc0IFO4EO6wSrnUpAWFWJ3NY7zzcagluGhx07nGbRFsqaRff+hs UDfK8A7/63t6JfpsSOP7gh27F4QyfPEagy4weuY2/fIYK+NALQAWjGlS02Adfz0= =LAW1 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jun 5 19:07: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 24AEF1A02F1 for ; Fri, 5 Jun 2015 19:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 tYjQbVRZ-sVA for ; Fri, 5 Jun 2015 19:07:11 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 07BAA1A0021 for ; Fri, 5 Jun 2015 19:07:10 -0700 (PDT) Received: from latte.josefsson.org ([216.55.31.130]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t5626vh3000735 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Sat, 6 Jun 2015 04:07:00 +0200 From: Simon Josefsson To: Michael StJohns References: <556C4ACD.9040002@azet.org> <556C51FC.807@azet.org> <20150601125302.GA19269@LK-Perkele-VII> <556C9AF4.7030607@nthpermutation.com> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:150606:tls@ietf.org::ydeKnh0d6ZO/ccO1:0bnx X-Hashcash: 1:22:150606:msj@nthpermutation.com::pBYLo20Nalaoy+8K:nl6z Date: Sat, 06 Jun 2015 04:06:52 +0200 In-Reply-To: <556C9AF4.7030607@nthpermutation.com> (Michael StJohns's message of "Mon, 01 Jun 2015 13:48:36 -0400") Message-ID: <87r3pp3803.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] EDDSA/Curve25519 identifiers: Was Re: AES-OCB 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: Sat, 06 Jun 2015 02:07:12 -0000 --=-=-= Content-Type: text/plain Michael StJohns writes: > Instead, get a new allocation and write a document that looks like > RFC5480 for the ED and Curve public keys. You want certificate > representations for *both*. I've started this for EdDSA: https://tools.ietf.org/html/draft-josefsson-tls-ed25519-00 Are you saying it would be useful to also specify certificate formats for Curve25519 ECDH keys? /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJVclW8AAoJEIYLf7sy+BGd0nQIAK1eWqtr/5i4hrF5Iq/6ai06 ZF0c3obxHnqz9pO7rJ3vD56UKKvbpb82B+I/lGwbv7uMqu0KrfShaBFp39hnxNQS LUeCnCRZI3r69BC/El8BbMGQeAOmWxXq1c3T2TWo8jZy3leD3/6RVxBD7T/QoGzM PKvm9HNwFlFdWhieSj9ddAWktAOBOfK4411c0xJaQYvAM94IGdcE2RdNWAa6HtfM XpjC5qKt2G34Zlh8yjfZefGACJ1GE+rEBlFxRZBiabOLhKr0RMLE/CuBHxcHFD1D ++XAvqjvofLUMXwVWBgA4wgBozgjhsh3WebpPv5yPMVD2p2jPSpLD1cnLv+bNe4= =eG75 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jun 5 19:21: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 B52651A8955 for ; Fri, 5 Jun 2015 19:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 szcW-rI9ZcdS for ; Fri, 5 Jun 2015 19:21:20 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 28F231A6F20 for ; Fri, 5 Jun 2015 19:21:19 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 1DF7E4939B; Sat, 6 Jun 2015 02:21:19 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 0CE1E49399; Sat, 6 Jun 2015 02:21:19 +0000 (GMT) Received: from email.msg.corp.akamai.com (ustx2ex-cas1.msg.corp.akamai.com [172.27.25.30]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 08CF91E07C; Sat, 6 Jun 2015 02:21:19 +0000 (GMT) Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com (172.27.27.102) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.27.102) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Fri, 5 Jun 2015 21:21:18 -0500 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.1076.000; Fri, 5 Jun 2015 21:21:18 -0500 From: "Salz, Rich" To: Simon Josefsson , Michael StJohns Thread-Topic: [TLS] EDDSA/Curve25519 identifiers: Was Re: AES-OCB in TLS Thread-Index: AQHQnJNozMMynb9tVEy+aOiDzWwmmp2eweL6gAADTkA= Date: Sat, 6 Jun 2015 02:21:17 +0000 Message-ID: <21e22b642f634e01a27893ec9069a25c@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <556C4ACD.9040002@azet.org> <556C51FC.807@azet.org> <20150601125302.GA19269@LK-Perkele-VII> <556C9AF4.7030607@nthpermutation.com> <87r3pp3803.fsf@latte.josefsson.org> In-Reply-To: <87r3pp3803.fsf@latte.josefsson.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.56.138] 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] EDDSA/Curve25519 identifiers: Was Re: AES-OCB 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: Sat, 06 Jun 2015 02:21:21 -0000 > Are you saying it would be useful to also specify certificate formats for > Curve25519 ECDH keys? It's probably just me being dumb, but how could this be useful? From nobody Fri Jun 5 20:00: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 D36AD1ACD1C for ; Fri, 5 Jun 2015 20:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5XxHT-UU26ZQ for ; Fri, 5 Jun 2015 20:00:19 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (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 B60631ACD11 for ; Fri, 5 Jun 2015 20:00:19 -0700 (PDT) Received: by pabqy3 with SMTP id qy3so60597844pab.3 for ; Fri, 05 Jun 2015 20:00:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ePP9I3GvecRCFTq3B8FxpqkVNwmwbLFCUUSXUZDFuoc=; b=fl0f0jYuq2kJPxmQvkPg3QI5VLrYW3XwnN0FXtzoPIqXAgN2gI5yAnZI6s+QdtL7Ng AfDxmlE+zayakKHeQmVUTDM77JYOdvZUS2U8ilvlDRXyV66+29H8Bq4nZvDbP+/sIa8F R1GWGZyvj86Bqe4p51yemkfvQYJs89HM1PCE2WfDwzp93Ozq+W1ygQCY6Q+5b7Qs20GZ 6OXjCKEW5iL6BcGeyVu8I5TUjH54CkIVFPU2WgEWVQErzsXGJRNiEmCHKWdpADsi+hLg q++3wrAYllVT1rINjkiQdQRDzWnmBR/7+buEuRU3QhfFj8VSkT9pGQB/BLOHvrGIy+9r xK4A== MIME-Version: 1.0 X-Received: by 10.66.63.8 with SMTP id c8mr10922389pas.122.1433559619477; Fri, 05 Jun 2015 20:00:19 -0700 (PDT) Received: by 10.70.66.5 with HTTP; Fri, 5 Jun 2015 20:00:19 -0700 (PDT) In-Reply-To: <21e22b642f634e01a27893ec9069a25c@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <556C4ACD.9040002@azet.org> <556C51FC.807@azet.org> <20150601125302.GA19269@LK-Perkele-VII> <556C9AF4.7030607@nthpermutation.com> <87r3pp3803.fsf@latte.josefsson.org> <21e22b642f634e01a27893ec9069a25c@ustx2ex-dag1mb2.msg.corp.akamai.com> Date: Fri, 5 Jun 2015 20:00:19 -0700 Message-ID: From: Peter Bowen To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Simon Josefsson , "tls@ietf.org" Subject: Re: [TLS] EDDSA/Curve25519 identifiers: Was Re: AES-OCB 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: Sat, 06 Jun 2015 03:00:21 -0000 On Fri, Jun 5, 2015 at 7:21 PM, Salz, Rich wrote: > >> Are you saying it would be useful to also specify certificate formats for >> Curve25519 ECDH keys? > > It's probably just me being dumb, but how could this be useful? I think the topic was not ECDH keys but documenting how to use EdDSA to sign PKIX/X.509 certificates and to have Curve25519 public keys in certificates to use with EdDSA in TLS (for auth). So something analogous to RFC 3279 sections 2.2.3 and 2.3.5. From nobody Mon Jun 8 01:46: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 07D2F1B2D91 for ; Mon, 8 Jun 2015 01:46:28 -0700 (PDT) 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_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrAoB5kganFm for ; Mon, 8 Jun 2015 01:46:27 -0700 (PDT) Received: from out4133-18.mail.aliyun.com (out4133-18.mail.aliyun.com [42.120.133.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0A91B2D75 for ; Mon, 8 Jun 2015 01:46:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1433753185; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; bh=mL6Zeq9i+zJ2b33lmCjNN8au6G+gxGLCxztsxSfEkUs=; b=SJn7s9LHSXN8rpr+gGsXWQsPETnp4xh4Eq1LZMOyHSkvJs8HoFr/DPpz3+NzPQnafYfuUE33xEoItV8S1xVSGHNjDq5NRZhpyzMPNJLyqORJbqkiPzICaW0rz6i9hrtZqWlOTXH2tvzx84HJUAFiKtuJVWrlnxLiAzakwMQpssI= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R431e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r46d02003; MF=bingzheng.wbz@alibaba-inc.com; PH=DW; RN=1; RT=1; SR=0; Received: from WS-web (bingzheng.wbz@alibaba-inc.com[42.120.74.182]) by r41g03021.xy2.aliyun.com at Mon, 08 Jun 2015 16:46:18 +0800 Date: Mon, 08 Jun 2015 16:46:18 +0800 From: "Bingzheng Wu" To: "tls" Message-ID: <----3-------MPf3-$0147073b-d557-427b-a8c7-d3dd80aef07b@alibaba-inc.com> X-Mailer: Alimail-Mailagent revision 2695336 MIME-Version: 1.0 x-aliyun-mail-creator: W4_2696684_IChTW96aWxsYS81LjAgKFdpbmRvd3MgTlQgNi4xOyBXT1c2NCkgQXBwbGVXZWJLaXQvNTM3LjM2IChLSFRNTCwgbGlrZSBHZWNrbykgQ2hyb21lLzQzLjAuMjM1Ny44MSBTYWZhcmkvNTM3LjM2jM Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [TLS] =?utf-8?q?add_challenge_in_TLS_v1=2E3_to_prevent_DDOS_attac?= =?utf-8?q?k=3F?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bingzheng Wu List-Id: "This is the mailing list 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, 08 Jun 2015 08:46:28 -0000 Hi all,=0A=0ATLS is susceptible to DDOS attack.=0AIn TLS v1.3, attackers can g= enerate ClientHello and ClientKeyshare messages easily,=0Awhile the server has= to consume large amounts of CPU doing asymmetric crypto operations to generat= e ServerKeyshare and ServerCertificateVerify messages.=0A=0ASo, could we add a= challenge-response mode in TLS v1.3 to increase the attacker's cost ?=0A=0ATh= e mode is disable in usual.=0AIf the server think it's under attack (e.g. >100= 0 qps), it could enable this mode by responding a HelloRetryRequest (or a new = type) message to the client with a challenge.=0AThe client receiving the chall= enge must solve the challenge which is expensive in CPU, and continue the hand= shake by carrying the challenge's answer.=0A=0AFor example, server could make = the challenge by encrypting an random number by a RSA public key (which is sho= rt), and send the private key (which is long) and cipher text to client.=0A=0A= This challenge mode may bring extra CPU consumption for normal clients when th= e server is under attack, but it can reduce the attack's influence for server,= to prevent DDOS attack.=0A=0AObviously, this mode must be a part of TLS's mai= n body, while being an extension dose not work.=0A=0A=0AIs this a feasible ide= a?=0A=0ARegards,=0ABingzheng Wu From nobody Mon Jun 8 02:17: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 CFCE21B2DD5 for ; Mon, 8 Jun 2015 02:17:24 -0700 (PDT) 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_50=0.8, 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 Y2pBeEIIlugx for ; Mon, 8 Jun 2015 02:17:23 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (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 3282C1B2DCE for ; Mon, 8 Jun 2015 02:17:23 -0700 (PDT) Received: by igbsb11 with SMTP id sb11so52702045igb.0 for ; Mon, 08 Jun 2015 02:17:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GVfHGvEVZENG9w1OUX0x6pPywZnihiE3QwQ1bpWcjrc=; b=EXJcyHufB9HVKOmUIbycc0qyHJbECL+/hzlFRKQiOX3RxCahOFqNLXNNMtRzFPB1Ha iHgKqfYCxyb19bAJtQONYiFKCTP4lJKinlYK9IB7WI49vDg3+wW6yB6Y4iANV65BBzhv zk6N886AHrybLiVerJPDb070bwk0nxR3zG5OKuzRA603j1oKhksOJZIjpmz30vytBTqe Og2VRWgewC1/OjCBDX6lCfDIAGSaFEbQLN4T5+A/CMvwy+NEc2Sd6AbWMM1RVeg28GNR Pj69vhSHoSNzv/3qVnonMeDtEM4QCnkUZYpve1gUgA46wvxcfhYg3YdMl8Oyydjljp1d POOQ== MIME-Version: 1.0 X-Received: by 10.50.39.105 with SMTP id o9mr12134779igk.39.1433755042598; Mon, 08 Jun 2015 02:17:22 -0700 (PDT) Received: by 10.107.135.207 with HTTP; Mon, 8 Jun 2015 02:17:22 -0700 (PDT) In-Reply-To: <----3-------MPf3-$0147073b-d557-427b-a8c7-d3dd80aef07b@alibaba-inc.com> References: <----3-------MPf3-$0147073b-d557-427b-a8c7-d3dd80aef07b@alibaba-inc.com> Date: Mon, 8 Jun 2015 11:17:22 +0200 Message-ID: From: CodesInChaos To: Bingzheng Wu Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: tls Subject: Re: [TLS] add challenge in TLS v1.3 to prevent DDOS attack? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Jun 2015 09:17:25 -0000 Not sure if this is a practical concern. If an attacker has so many computers/IPs that IP blacklisting doesn't help anymore (TCP makes IP spoofing difficult), they probably could simply flood the victim's connection instead of relying on expensive crypto operations for DoS. Your proposed proof-of-work doesn't look ideal either, since the cost is fixed at a low value. Some variant of hashcash is clearly better. From nobody Mon Jun 8 02:20: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 D12A31B2DE2 for ; Mon, 8 Jun 2015 02:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 LSJsx8bHAbNS for ; Mon, 8 Jun 2015 02:19:59 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C43FF1B2DD1 for ; Mon, 8 Jun 2015 02:19:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1433755199; x=1465291199; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=rBbumzfst9BJKfwbUT6jWsIE5X4eEvMyRCI2GPqbUfk=; b=kqgbN1FKtuqh/ws7PggZuek2paMaqtJDTRhtNnOtMEw1g2ymeeFFG38u TSj72CbrmSz8QRPFphHY07u29asNjHZnH11dVU5M84jJY9Zzi7NgJyqnU HL9PrB1nIY2OaKjMLrInDwzqBvA5uRLidtuSIzTRhTTEFU4WR71AKC8Us REgBWIrvD5WH7QLdOJn7hMiIGdT6qZ5JmbfWVfAQOPY48iM4tG1OSFTlz GY6aDIQWNF+mKo0nCadcMUwLFiBikymP8xMa+jqcul8JWiIU8r4NgVMtb t11ZX5JrYtNH2Z5VrOr0ZeuswD19NYjJC3U1tb+LQ4lCXeRAkoCl0nyvs A==; X-IronPort-AV: E=Sophos;i="5.13,573,1427713200"; d="scan'208";a="21530346" 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 mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 08 Jun 2015 21:19:57 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.151]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0174.001; Mon, 8 Jun 2015 21:19:56 +1200 From: Peter Gutmann To: Bingzheng Wu , tls Thread-Topic: [TLS] add challenge in TLS v1.3 to prevent DDOS attack? Thread-Index: AQHQoceuLXfEop8B+kSbMbpiYwOh352iVK20 Date: Mon, 8 Jun 2015 09:19:56 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AB039DA4@uxcn10-tdc05.UoA.auckland.ac.nz> References: <----3-------MPf3-$0147073b-d557-427b-a8c7-d3dd80aef07b@alibaba-inc.com> In-Reply-To: <----3-------MPf3-$0147073b-d557-427b-a8c7-d3dd80aef07b@alibaba-inc.com> 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] add challenge in TLS v1.3 to prevent DDOS attack? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Jun 2015 09:20:03 -0000 Bingzheng Wu writes:=0A= =0A= >So, could we add a challenge-response mode in TLS v1.3 to increase the att= acker's cost ?=0A= =0A= You don't need anything that complex, OpenVPN has for a number of years=0A= supported a very effective way of dealing with this, all you need to do is= =0A= formalise that. It doesn't really need TLS 1.3 either, since you can do it= in=0A= a standard extension. OpenVPN gives it the very misleading name tls-auth,= =0A= it's just a use of a PSK to MAC incoming packets, so the client-hello is=0A= authenticated and dropped unless it has a valid MAC signature. This has=0A= protected OpenVPN against a number of OpenSSL vulnerabilities (as well as= =0A= generic port-scanning and similar), most notably Heartbleed, where any atte= mpt=0A= to exploit the vuln just bounced off, because unless you have the MAC key y= ou=0A= can't get past even the first hello message.=0A= =0A= I started work on an RFC draft for this a while back, but it got shelved=0A= because of conflicts over making it OpenVPN-compatible or not, it shouldn't= be=0A= too much work to dig it out and finish it (albeit in a non-OpenVPN-compatib= le=0A= manner).=0A= =0A= Peter.= From nobody Mon Jun 8 02:32: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 D28C71B2DDA for ; Mon, 8 Jun 2015 02:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 I5l2GjDR7Znh for ; Mon, 8 Jun 2015 02:31:58 -0700 (PDT) Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 324101B2DF1 for ; Mon, 8 Jun 2015 02:31:58 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id 061281A25E4; Mon, 8 Jun 2015 12:31:56 +0300 (EEST) Date: Mon, 8 Jun 2015 12:31:55 +0300 From: Ilari Liusvaara To: Bingzheng Wu Message-ID: <20150608093155.GA24860@LK-Perkele-VII> References: <----3-------MPf3-$0147073b-d557-427b-a8c7-d3dd80aef07b@alibaba-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <----3-------MPf3-$0147073b-d557-427b-a8c7-d3dd80aef07b@alibaba-inc.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: tls Subject: Re: [TLS] add challenge in TLS v1.3 to prevent DDOS attack? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Jun 2015 09:32:01 -0000 On Mon, Jun 08, 2015 at 04:46:18PM +0800, Bingzheng Wu wrote: > Hi all, > > TLS is susceptible to DDOS attack. > In TLS v1.3, attackers can generate ClientHello and > ClientKeyshare messages easily, while the server has to > consume large amounts of CPU doing asymmetric crypto operations > to generate ServerKeyshare and ServerCertificateVerify messages. Note that this type of attack already works in TLS 1.2. > So, could we add a challenge-response mode in TLS v1.3 to > increase the attacker's cost ? There is already an issue about this (but given nature of that issue, it should be discussed on this ML, especially as it still seems to be open). > The mode is disable in usual. > If the server think it's under attack (e.g. >1000 qps), it > could enable this mode by responding a HelloRetryRequest (or > a new type) message to the client with a challenge. > The client receiving the challenge must solve the challenge > which is expensive in CPU, and continue the handshake by > carrying the challenge's answer. One has to be careful that this kind of thing doesn't introduce security issues. E.g. Proper implementations can not restart handshake, and repeating yourself is legendary source of bugs. > For example, server could make the challenge by encrypting an > random number by a RSA public key (which is short), and send > the private key (which is long) and cipher text to client. The usual way things like this are done is via hashes. TLS13 github issue #9 has link to a ML post describing one scheme: https://www.ietf.org/mail-archive/web/tls/current/msg11763.html -Ilari From nobody Mon Jun 8 02:52: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 9D36D1B2E2B for ; Mon, 8 Jun 2015 02:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.348 X-Spam-Level: X-Spam-Status: No, score=0.348 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_SE=0.35, 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 rmr7rTQxIJ_4 for ; Mon, 8 Jun 2015 02:52:38 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 3E8821B2E27 for ; Mon, 8 Jun 2015 02:52:38 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t589qOIW028512 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 8 Jun 2015 11:52:26 +0200 X-Hashcash: 1:22:150608:tls@ietf.org::oxpY4bfVbJolOq6Z:0xYe From: Simon Josefsson To: tls@ietf.org OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt Date: Mon, 08 Jun 2015 11:52:23 +0200 Message-ID: <87zj4ah6i0.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Subject: [TLS] Updated EdDSA in TLS 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: Mon, 08 Jun 2015 09:52:39 -0000 --=-=-= Content-Type: text/plain Hello. I've updated my EdDSA-in-TLS draft to clarify the choice of HashAlgorithm that goes together with the EdDSA SignatureAlgorithm, please see: https://tools.ietf.org/html/draft-josefsson-tls-eddsa-01 The other feedback I have received is to reuse the existing ECDSA ciphersuites. I think this is a good idea, and believe it would likely work, but it is a fundamentally different approach. I created another draft to describe that approach, now published as: https://tools.ietf.org/html/draft-josefsson-tls-eddsa2-00 Having these two approaches described separately allows us to review both and decide which is the better approach. More feedback is appreciated! Some issues that is not clear to me includes: * Is it a good idea to reuse the NamedCurve value for Curve25519 for Ed25519 too? * Similar question for ECPointFormat. Maybe EdDSA should use a different definition here. For more context, related to the above is a draft describing OIDs for EdDSA for use in PKIX certificates as public keys and a signature algorithm: https://tools.ietf.org/html/draft-josefsson-pkix-eddsa-00 Cheers, /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJVdWXXAAoJEIYLf7sy+BGdi1EIAIVJ2kK3AxwSIpVej2Cy6uHp Ge7vUKFq7Eype7asvz6VrFmWun8Af0LXVYFu5/X4moidh4Qs92fJCDwOfqtWN1fJ aEQdyd11sDYxc9LsMIiyfFhQIO/1MRFQipPSiYxxTdCMUHZ7mSt7654lJ7W0Kz28 vU9M85EYoiIT33Bj5GgDAZx360lUJa4RylGqMwJgAJ8fScst7ONehmMPQj4fv5kD LV3nZ3K9rbhMTm9LYKOm7R9uo6weGXk7c74RI6SWr/oaoTcS5tmGJULzuaS0sDiE AinxXCoK1KWjXfc9jLuLaO7+JEE8fMV/v2hntOkZP0zMCokGNJ6A4eKbnHvs7bs= =VUPm -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 8 03:16: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 3CC251A0021 for ; Mon, 8 Jun 2015 03:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 FokEki2WRR-g for ; Mon, 8 Jun 2015 03:16:27 -0700 (PDT) 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 665661A0019 for ; Mon, 8 Jun 2015 03:16:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 98610BE5D; Mon, 8 Jun 2015 11:16:24 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9Ue7qCP55F9; Mon, 8 Jun 2015 11:16:23 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.23.15]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7A76DBE53; Mon, 8 Jun 2015 11:16:23 +0100 (IST) Message-ID: <55756B76.4070103@cs.tcd.ie> Date: Mon, 08 Jun 2015 11:16:22 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Simon Josefsson , tls@ietf.org References: <87zj4ah6i0.fsf@latte.josefsson.org> In-Reply-To: <87zj4ah6i0.fsf@latte.josefsson.org> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cAkMttXvRBvsgQ8vJ34EjMUCtivv0eIcv" Archived-At: Subject: Re: [TLS] Updated EdDSA in TLS 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: Mon, 08 Jun 2015 10:16:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cAkMttXvRBvsgQ8vJ34EjMUCtivv0eIcv Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 08/06/15 10:52, Simon Josefsson wrote: > More feedback is appreciated! My v. high level feedback is that we really don't want to get too far ahead of cfrg here. They've not yet got all details of their preferred signature scheme using that curve defined and it'd be really dumb for any IETF WG to get ahead of that by accident. So while working on this draft is a fine thing, I don't think we want to get to IETF LC for things like this until after cfrg have figured out their preferred signature scheme. (And the cfrg chairs tell me that ought be done soon - in a few months.) Note that waiting until the cfrg position is clear does not mean that the IETF has to mindlessly adopt what cfrg have done, but we won't want to ignore their work either. And fwiw, I guess I'd take the same position for any work item for almost any new ECC work for the moment. Since cfrg are nearly done and seem to be making progress now, pre-empting their decisions wouldn't be a good plan. Cheers, S. --cAkMttXvRBvsgQ8vJ34EjMUCtivv0eIcv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVdWt3AAoJEC88hzaAX42ik20H/iiDo3U5QPZBtJbdbOHbWHEN evKCAZNr+lSKIa1ap6FeP9yHmjMyUeTyc27JOFj9HCJB1lWOYWvuykf2khRknc6Q S76vKgYVDAzpe+mQSgYOynDx+jfvLvXwB2QBRfwKB+FeLPCrRKOoqehUhlQi1C9g WUhI51UtwUWBcsvfvqT+tWmT4dikHi//w1zP0PCiti4V2Bm6RQVdwSkM/mAPFROW Y96jMzfMvc1jZ0jyr/wkhtNyx72wcvmypOdZ4Hy4SPlLvQhIp7idcTC46pMEdVD0 crP0PHBz5hp4HPmRlgUZWkj8EpSFq6LUuaRb41qBK0nqqMnZFCkm/UXVPiPtj+Y= =FM5F -----END PGP SIGNATURE----- --cAkMttXvRBvsgQ8vJ34EjMUCtivv0eIcv-- From nobody Mon Jun 8 03:39: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 2B4F41A1A2E for ; Mon, 8 Jun 2015 03:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 zGzjlMe50kHD for ; Mon, 8 Jun 2015 03:39:43 -0700 (PDT) Received: from emh07.mail.saunalahti.fi (emh07.mail.saunalahti.fi [62.142.5.117]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 684ED1A038E for ; Mon, 8 Jun 2015 03:39:43 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id F2DD1404E; Mon, 8 Jun 2015 13:39:40 +0300 (EEST) Date: Mon, 8 Jun 2015 13:39:40 +0300 From: Ilari Liusvaara To: Simon Josefsson Message-ID: <20150608103940.GA25285@LK-Perkele-VII> References: <87zj4ah6i0.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87zj4ah6i0.fsf@latte.josefsson.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Updated EdDSA in TLS 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: Mon, 08 Jun 2015 10:39:46 -0000 On Mon, Jun 08, 2015 at 11:52:23AM +0200, Simon Josefsson wrote: > Hello. > > I've updated my EdDSA-in-TLS draft to clarify the choice of > HashAlgorithm that goes together with the EdDSA SignatureAlgorithm, > please see: > > https://tools.ietf.org/html/draft-josefsson-tls-eddsa-01 What hash algorithm is internally used? EdDSA does not fix that (Ed25519 does fix it to SHA-512). Does more need to be said about how R and S are packed into single blob for signature (concatenate)? More ciphersuites. Eew. Also, in TLS 1.2 Client CertificateVerify (does not apply to server certificate, nor either certificate in TLS 1.3) signs the entiere handshake so far. That could be many kilobytes in size, spread over multiple message. > The other feedback I have received is to reuse the existing ECDSA > ciphersuites. I think this is a good idea, and believe it would likely > work, but it is a fundamentally different approach. I created another > draft to describe that approach, now published as: > > https://tools.ietf.org/html/draft-josefsson-tls-eddsa2-00 TLS 1.0 and 1.1 lack algorithm specification for signature, which is very useful for merging ciphersuites like this. In theory, one could infer the algorithm from certificate, but I don't think that kind of tricks are very often pulled off. I don't know if mixing curves used for key exchange and curves used for signing is a good idea. Signing is much more complicated than ECDH. The point format used by EdDSA has very little to do with montgomery X (it does not have the same number of bits). The point format is little- endian encoding of 2^(b-1)*lsb(x)+y, b is 256 for Curve25519, and lsb(x) is x mod p mod 2. X and Y are edwards coordinates. Also, notes about not seemingly fixing the hash, encoding of signature and TLS 1.2 client certs apply. > For more context, related to the above is a draft describing OIDs for > EdDSA for use in PKIX certificates as public keys and a signature > algorithm: > > https://tools.ietf.org/html/draft-josefsson-pkix-eddsa-00 Repeating the definitions sounds bit odd, one could presumably just state what to put in each field. Public key encoding? Edwards points have two coordinates. The usual EdDSA encoding (32 octets for Curve25519)? Hash algorithm? Note that public keys are not compatible across hash algoritmhs. Fixed to SHA-512? Signature encoding? Presumably the same as on TLS side. -Ilari From nobody Mon Jun 8 03:59: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 49DB81A1A37 for ; Mon, 8 Jun 2015 03:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, 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 ft0ZrRmeelMi for ; Mon, 8 Jun 2015 03:59:28 -0700 (PDT) Received: from out4133-18.mail.aliyun.com (out4133-18.mail.aliyun.com [42.120.133.18]) by ietfa.amsl.com (Postfix) with ESMTP id EF9D91A008F for ; Mon, 8 Jun 2015 03:59:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1433761167; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; bh=/YLDd0n9seoQ9uNLpeydMZvnQLyelRJBceeIiApkyQ4=; b=olrnuO/ahTAIIcWGTeR63vM3BelvDyHqfKJqJ3/Jstv2rGyUsnJs5hklQPR49Jwh2sp9tSiTLT98mIvVVtOaWkBtwYO+qfdX2icxA9qWN2lzlKu7aiRe8Wm6XD3wgoAn1C2WNKSM1yDQApcANkumiUttkRZAkeADj8LIvAiIIwM= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R181e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r41g03020; MF=bingzheng.wbz@alibaba-inc.com; PH=DS; RN=2; RT=2; SR=0; Received: from ali074145n(mailfrom:bingzheng.wbz@alibaba-inc.com ip:42.120.74.158) by smtp.aliyun-inc.com(127.0.0.1); Mon, 08 Jun 2015 18:59:21 +0800 From: "Bingzheng Wu" To: "'CodesInChaos'" References: <----3-------MPf3-$0147073b-d557-427b-a8c7-d3dd80aef07b@alibaba-inc.com> In-Reply-To: Date: Mon, 08 Jun 2015 18:59:21 +0800 Message-ID: <008c01d0a1da$2c9921c0$85cb6540$@alibaba-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJM1bQwrAdL2mUOwfD9yh9pSzi+dQJ00LiZnJZeLnA= Content-Language: zh-cn Archived-At: Cc: 'tls' Subject: Re: [TLS] add challenge in TLS v1.3 to prevent DDOS attack? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bingzheng Wu List-Id: "This is the mailing list 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, 08 Jun 2015 10:59:29 -0000 I talked about TLS level DDOS only, but not TCP level DDOS. I think they = focus on different aspects. I learned about the hash way of challenge from the link in Ilari's mail. = It's better than my proposed way indeed. thanks. > -----Original Message----- > From: CodesInChaos [mailto:codesinchaos@gmail.com] > Sent: Monday, June 08, 2015 5:17 PM > To: Bingzheng Wu > Cc: tls > Subject: Re: [TLS] add challenge in TLS v1.3 to prevent DDOS attack? >=20 > Not sure if this is a practical concern. If an attacker has so many = computers/IPs > that IP blacklisting doesn't help anymore (TCP makes IP spoofing = difficult), they > probably could simply flood the victim's connection instead of relying = on > expensive crypto operations for DoS. >=20 > Your proposed proof-of-work doesn't look ideal either, since the cost = is fixed at > a low value. Some variant of hashcash is clearly better. From nobody Mon Jun 8 04:06: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 CC3801A1B8A for ; Mon, 8 Jun 2015 04:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, 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 jIx5Fz67jNNn for ; Mon, 8 Jun 2015 04:05:57 -0700 (PDT) Received: from out4133-66.mail.aliyun.com (out4133-66.mail.aliyun.com [42.120.133.66]) by ietfa.amsl.com (Postfix) with ESMTP id CA5331A1B87 for ; Mon, 8 Jun 2015 04:05:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1433761556; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; bh=ujVd0lumJ074MFH6u1bxhdrxmV8JQtDwl2XY6N+uE38=; b=SGejZC8gZv5o1iE5EJC7x8WwdlXeOwfjRewfPFzcQ7YUPk8YZV1hk2Y2KE/pMuW7yXbHPYx4z97Thok8PH0gs6bgievuUoAyQhe0zoAI91EXQNvzD2R+pIN9yPgmDEFoYZxS26Hp49Vc8yHesTQrA+WjcedyP4+bjKhPp+IfNjg= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R841e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r41g03025; MF=bingzheng.wbz@alibaba-inc.com; PH=DS; RN=2; RT=2; SR=0; Received: from ali074145n(mailfrom:bingzheng.wbz@alibaba-inc.com ip:42.120.74.159) by smtp.aliyun-inc.com(127.0.0.1); Mon, 08 Jun 2015 19:05:49 +0800 From: "Bingzheng Wu" To: "'Peter Gutmann'" , "'tls'" References: <----3-------MPf3-$0147073b-d557-427b-a8c7-d3dd80aef07b@alibaba-inc.com> <9A043F3CF02CD34C8E74AC1594475C73AB039DA4@uxcn10-tdc05.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AB039DA4@uxcn10-tdc05.UoA.auckland.ac.nz> Date: Mon, 08 Jun 2015 19:05:49 +0800 Message-ID: <008d01d0a1db$13db18e0$3b914aa0$@alibaba-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJM1bQwrAdL2mUOwfD9yh9pSzi+dQIFyyjFnJnaxDA= Content-Language: zh-cn Archived-At: Subject: Re: [TLS] add challenge in TLS v1.3 to prevent DDOS attack? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bingzheng Wu List-Id: "This is the mailing list 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, 08 Jun 2015 11:05:59 -0000 Thanks for your information. I didn't know this before. However I don't think this match my original purpose. The tls-auth requires the client and server have PSK. But I want an general anti-DDOS method. For example, this method could be used by general web browser to visit any web sites. Please fix me if I misunderstand the OpenVPN's method. Thanks, Bingzheng > -----Original Message----- > From: Peter Gutmann [mailto:pgut001@cs.auckland.ac.nz] > Sent: Monday, June 08, 2015 5:20 PM > To: Bingzheng Wu; tls > Subject: RE: [TLS] add challenge in TLS v1.3 to prevent DDOS attack? > > Bingzheng Wu writes: > > >So, could we add a challenge-response mode in TLS v1.3 to increase the > attacker's cost ? > > You don't need anything that complex, OpenVPN has for a number of years > supported a very effective way of dealing with this, all you need to do is > formalise that. It doesn't really need TLS 1.3 either, since you can do it in a > standard extension. OpenVPN gives it the very misleading name tls-auth, it's > just a use of a PSK to MAC incoming packets, so the client-hello is > authenticated and dropped unless it has a valid MAC signature. This has > protected OpenVPN against a number of OpenSSL vulnerabilities (as well as > generic port-scanning and similar), most notably Heartbleed, where any > attempt to exploit the vuln just bounced off, because unless you have the MAC > key you can't get past even the first hello message. > > I started work on an RFC draft for this a while back, but it got shelved because > of conflicts over making it OpenVPN-compatible or not, it shouldn't be too much > work to dig it out and finish it (albeit in a non-OpenVPN-compatible manner). > > Peter.= From nobody Mon Jun 8 04:30: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 E49991A1BCF for ; Mon, 8 Jun 2015 04:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 JNGeMQ_pkth3 for ; Mon, 8 Jun 2015 04:30:53 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B6CF1A1BCD for ; Mon, 8 Jun 2015 04:30:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1433763053; x=1465299053; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ItZj3qq0BwDisGA3G786Rl2VClagmonZryiKT3jXcYU=; b=ibzjfhU0BdY/myGmy52i5WiNzn5wFVds48pADL46OM6Ggz8k8tOoF2s6 XH2LjguB8/Ff+PkEvcPPUlRgW+XfrA4kTT8Jfwk6h52u0pwtFdFhRyJjd g2ClpouPTt3qUESWoDJTXigdNSacoE6PJeOFXgEP8/neOpu9KmfVizV/J SKH1maDy1J88TMFjhehwr88p0pFddeqMGhZSe29YACfRkfXGgPklipOfJ spWTKI8IjOlB1+tInLuYUG9qp0YyeNpkfwQrhJKoQW9bciCaCzn2grb7t vEJvqZh5g8SSQ5bU9jFDnzEH1dF6zpKqA5DVfUgKILRL/D42TXz7PZ2kY g==; X-IronPort-AV: E=Sophos;i="5.13,573,1427713200"; d="scan'208";a="21545456" 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 mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 08 Jun 2015 23:30:51 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.151]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Mon, 8 Jun 2015 23:30:51 +1200 From: Peter Gutmann To: Bingzheng Wu , 'tls' Thread-Topic: [TLS] add challenge in TLS v1.3 to prevent DDOS attack? Thread-Index: AQHQoceuLXfEop8B+kSbMbpiYwOh352iVK20//9UwICAAM9UfA== Date: Mon, 8 Jun 2015 11:30:50 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AB039EBF@uxcn10-tdc05.UoA.auckland.ac.nz> References: <----3-------MPf3-$0147073b-d557-427b-a8c7-d3dd80aef07b@alibaba-inc.com> <9A043F3CF02CD34C8E74AC1594475C73AB039DA4@uxcn10-tdc05.UoA.auckland.ac.nz>, <008d01d0a1db$13db18e0$3b914aa0$@alibaba-inc.com> In-Reply-To: <008d01d0a1db$13db18e0$3b914aa0$@alibaba-inc.com> 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] add challenge in TLS v1.3 to prevent DDOS attack? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Jun 2015 11:30:55 -0000 Bingzheng Wu writes:=0A= =0A= >The tls-auth requires the client and server have PSK.=0A= =0A= Sure, this is for the situation where you have known clients connecting to = a=0A= server (e.g. SCADA devices), not for general-purpose web use where you have= an=0A= arbitrary number of unknown clients connecting. So that's one more note fo= r=0A= the RFC draft, be explicit about the scope...=0A= =0A= Peter.=0A= =0A= From nobody Mon Jun 8 04:32: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 5DECF1A1BCF for ; Mon, 8 Jun 2015 04:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, 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 LbW0RXiB7L9B for ; Mon, 8 Jun 2015 04:32:10 -0700 (PDT) Received: from out4133-34.mail.aliyun.com (out4133-34.mail.aliyun.com [42.120.133.34]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8FB1A1BCD for ; Mon, 8 Jun 2015 04:32:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1433763128; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; bh=ge57TBFSwwHRg20YJtWmGxmW8e6BKkl2B5qNSKLaFzU=; b=msA3ifMc5UIM7px+g8YhAYqaiFy53N3/Mnv00HVjcz1bUdMa/RgVwlWXWZUkMxq4K/nf9aHmgZOccZnOx3PtBYs6XfN69mGWboO1PlL0Y76Hx1ni3kYkBdMyJWqn7/57kCMeXfWU0EBdGQgnHBVNCagVNmuifOmtzZQTZDU8an4= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R761e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r41g03024; MF=bingzheng.wbz@alibaba-inc.com; PH=DS; RN=2; RT=2; SR=0; Received: from ali074145n(mailfrom:bingzheng.wbz@alibaba-inc.com ip:42.120.74.161) by smtp.aliyun-inc.com(127.0.0.1); Mon, 08 Jun 2015 19:32:04 +0800 From: "Bingzheng Wu" To: "'Ilari Liusvaara'" References: <----3-------MPf3-$0147073b-d557-427b-a8c7-d3dd80aef07b@alibaba-inc.com> <20150608093155.GA24860@LK-Perkele-VII> In-Reply-To: <20150608093155.GA24860@LK-Perkele-VII> Date: Mon, 08 Jun 2015 19:32:04 +0800 Message-ID: <009101d0a1de$be9a76b0$3bcf6410$@alibaba-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJM1bQwrAdL2mUOwfD9yh9pSzi+dQGfXzEVnJ0QkBA= Content-Language: zh-cn Archived-At: Cc: 'tls' Subject: Re: [TLS] add challenge in TLS v1.3 to prevent DDOS attack? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bingzheng Wu List-Id: "This is the mailing list 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, 08 Jun 2015 11:32:16 -0000 I am sorry that I did not search the list archive thoroughly. The scheme in your link is what I wanted (and the hash-challenge is = better than my propose). But I have one question still. It's said that this scheme can be = implemented as an extension. If a client who dose not support this extension receives the challenge, = what should it do? Just abort the connection? Then some servers who provide important services may dare not to enable = this scheme, to avoid impacting the users who use TLS client not = supporting this extension. Please fix me if I misunderstand that propose. Thanks, Bingzheng > -----Original Message----- > From: Ilari Liusvaara [mailto:ilari.liusvaara@elisanet.fi] > Sent: Monday, June 08, 2015 5:32 PM > To: Bingzheng Wu > Cc: tls > Subject: Re: [TLS] add challenge in TLS v1.3 to prevent DDOS attack? >=20 > On Mon, Jun 08, 2015 at 04:46:18PM +0800, Bingzheng Wu wrote: > > Hi all, > > > > TLS is susceptible to DDOS attack. > > In TLS v1.3, attackers can generate ClientHello and ClientKeyshare > > messages easily, while the server has to consume large amounts of = CPU > > doing asymmetric crypto operations to generate ServerKeyshare and > > ServerCertificateVerify messages. >=20 > Note that this type of attack already works in TLS 1.2. >=20 > > So, could we add a challenge-response mode in TLS v1.3 to increase = the > > attacker's cost ? >=20 > There is already an issue about this (but given nature of that issue, = it should be > discussed on this ML, especially as it still seems to be open). >=20 > > The mode is disable in usual. > > If the server think it's under attack (e.g. >1000 qps), it could > > enable this mode by responding a HelloRetryRequest (or a new type) > > message to the client with a challenge. > > The client receiving the challenge must solve the challenge which is > > expensive in CPU, and continue the handshake by carrying the > > challenge's answer. >=20 > One has to be careful that this kind of thing doesn't introduce = security issues. > E.g. Proper implementations can not restart handshake, and repeating = yourself > is legendary source of bugs. >=20 > > For example, server could make the challenge by encrypting an random > > number by a RSA public key (which is short), and send the private = key > > (which is long) and cipher text to client. >=20 > The usual way things like this are done is via hashes. >=20 > TLS13 github issue #9 has link to a ML post describing one scheme: > https://www.ietf.org/mail-archive/web/tls/current/msg11763.html >=20 >=20 > -Ilari From nobody Mon Jun 8 05:38: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 55A771A6F01 for ; Mon, 8 Jun 2015 05:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.474 X-Spam-Level: ** X-Spam-Status: No, score=2.474 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FSL_HELO_BARE_IP_2=1.675, 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 DhVpLrXPLGHQ for ; Mon, 8 Jun 2015 05:38:12 -0700 (PDT) Received: from gateway06.websitewelcome.com (gateway06.websitewelcome.com [64.5.38.4]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADAA91A6EDC for ; Mon, 8 Jun 2015 05:38:11 -0700 (PDT) Received: by gateway06.websitewelcome.com (Postfix, from userid 5007) id 00A8A5CE94078; Mon, 8 Jun 2015 07:38:11 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway06.websitewelcome.com (Postfix) with ESMTP id E1A085CE94057 for ; Mon, 8 Jun 2015 07:38:10 -0500 (CDT) Received: from [96.231.216.136] (port=50334 helo=192.168.1.7) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Z1wJe-0003uM-7W; Mon, 08 Jun 2015 07:38:10 -0500 From: Sean Turner Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Mon, 8 Jun 2015 08:38:08 -0400 Message-Id: <199A7C31-5C8C-459C-8A74-72D7BECA890F@ieca.com> To: IETF TLS Working Group 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.216.136 X-Exim-ID: 1Z1wJe-0003uM-7W X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.7) [96.231.216.136]:50334 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Cc: draft-mavrogiannopoulos-chacha-tls@tools.ietf.org Subject: [TLS] adopted: draft-mavrogiannopoulos-chacha-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: Mon, 08 Jun 2015 12:38:13 -0000 We=92ve verified on the list that there is WG consensus to adopt = draft-mavrogiannopoulos-chacha-tls [0]. =20 But, we=92re going to hold off the early code point assignment request. = There were some issues about the number of code points and what I=92d = characterize as semantic issues that still need to be ironed out. I=92m = hoping we can address these comments/issues and revisit early assignment = in the not too distant future (we're not promising anything but we=92ll = see how the discussion goes). Authors, If draft-ietf-tls-chacha20-poly1305 works as a draft name let us know = and one of us can pre-approve the draft so we can start moving this = draft through the process. Thanks!=20 J&S [0] http://www.ietf.org/mail-archive/web/tls/current/msg16345.html= From nobody Mon Jun 8 05:58: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 D263E1A7D84 for ; Mon, 8 Jun 2015 05:58:24 -0700 (PDT) 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 mZcsw2SAMas5 for ; Mon, 8 Jun 2015 05:58:22 -0700 (PDT) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (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 1A8DA1A7D82 for ; Mon, 8 Jun 2015 05:58:22 -0700 (PDT) Received: by wifx6 with SMTP id x6so85832932wif.0 for ; Mon, 08 Jun 2015 05:58:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=THm7YwW4y7d9wE2G3fwvb7EU1tc5E+wvPafk2lSiawU=; b=DIaUmVRm36+nk0vq+XI92HFHny7U5z58jhuNllWSjhCxAPkPt08/l+AKwup1olZARN lVjcSN6/Z/dDmTNlIf8IGW+jDLdTXrmDrsX4mmk9PqjWmeX7iQ2Q/7yqVuCRsJi2Hgk0 ypH0SLBNcbGpFsvLZ8BP0bLalMtTzyDr+Yu7JAnLvjjWOd2xH0oj1YglPhAr6JcWjg/W kjVsShiYotwCVElAuCJRHf8EoiIbrPZKSCi6f8THqDFPKzVLTJc3A8DWtfAEYTmk7JI0 DtAe8BV51b7huSQckdRoGb5PJSTXoq/QUFwO9DSa5lU6FLT6q8eSQyYR1iHat8WQijYy kzYA== X-Gm-Message-State: ALoCoQn3N8pZeLtPLEj6pZhE5lFfZOX3Sdc0L8keY/DHbegW2eiRPs70SURZniylkdwr4wmBSPKi X-Received: by 10.180.75.8 with SMTP id y8mr21924799wiv.31.1433768300831; Mon, 08 Jun 2015 05:58:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.225.14 with HTTP; Mon, 8 Jun 2015 05:57:40 -0700 (PDT) In-Reply-To: <199A7C31-5C8C-459C-8A74-72D7BECA890F@ieca.com> References: <199A7C31-5C8C-459C-8A74-72D7BECA890F@ieca.com> From: Eric Rescorla Date: Mon, 8 Jun 2015 05:57:40 -0700 Message-ID: To: Sean Turner Content-Type: multipart/alternative; boundary=f46d043c7b9c4303a1051801326b Archived-At: Cc: draft-mavrogiannopoulos-chacha-tls@tools.ietf.org, IETF TLS Working Group Subject: Re: [TLS] adopted: draft-mavrogiannopoulos-chacha-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: Mon, 08 Jun 2015 12:58:25 -0000 --f46d043c7b9c4303a1051801326b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 On Mon, Jun 8, 2015 at 5:38 AM, Sean Turner wrote: > We=E2=80=99ve verified on the list that there is WG consensus to adopt > draft-mavrogiannopoulos-chacha-tls [0]. > > But, we=E2=80=99re going to hold off the early code point assignment requ= est. > There were some issues about the number of code points and what I=E2=80= =99d > characterize as semantic issues that still need to be ironed out. I=E2= =80=99m > hoping we can address these comments/issues and revisit early assignment = in > the not too distant future (we're not promising anything but we=E2=80=99l= l see how > the discussion goes). > > Authors, > > If draft-ietf-tls-chacha20-poly1305 works as a draft name let us know and > one of us can pre-approve the draft so we can start moving this draft > through the process. > > Thanks! > > J&S > > [0] http://www.ietf.org/mail-archive/web/tls/current/msg16345.html > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --f46d043c7b9c4303a1051801326b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

On Mon, Jun 8, 2015 at 5:38 AM, Sean Turner <<= a href=3D"mailto:turners@ieca.com" target=3D"_blank">turners@ieca.com&g= t; wrote:
We=E2=80=99ve verified o= n the list that there is WG consensus to adopt draft-mavrogiannopoulos-chac= ha-tls [0].

But, we=E2=80=99re going to hold off the early code point assignment reques= t. There were some issues about the number of code points and what I=E2=80= =99d characterize as semantic issues that still need to be ironed out.=C2= =A0 I=E2=80=99m hoping we can address these comments/issues and revisit ear= ly assignment in the not too distant future (we're not promising anythi= ng but we=E2=80=99ll see how the discussion goes).

Authors,

If draft-ietf-tls-chacha20-poly1305 works as a draft name let us know and o= ne of us can pre-approve the draft so we can start moving this draft throug= h the process.

Thanks!

J&S

[0] http://www.ietf.org/mail-archive/web/tls/current/msg1= 6345.html
_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls

--f46d043c7b9c4303a1051801326b-- From nobody Mon Jun 8 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 BCBBF1A1B2D for ; Mon, 8 Jun 2015 10:38:49 -0700 (PDT) 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_50=0.8, 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 Ysml3BgfPght for ; Mon, 8 Jun 2015 10:38:48 -0700 (PDT) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (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 76A871A1ADB for ; Mon, 8 Jun 2015 10:38:48 -0700 (PDT) Received: by ykfl8 with SMTP id l8so55454522ykf.1 for ; Mon, 08 Jun 2015 10:38:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bsikYJoK1816nFoUVgWo9FP6EWjJ4rVP3vJKEePgDrw=; b=fZljSLsfdAjHLp+r7sS17aFywjhLydGmqYT6a5h4yaCl8OWGd/Sdmj7Uowu4BL0+Nm Y/ZwWw4ZhWn5a4UheWOf6svWbbwlMm32yZzj2E2LG57Ifad064XzqnE3haXN/h98f+HB 0kAaGCXBBUfNw8IE7F1h8Qcr6YCGjFkMQ3eeSvwdV3zbKwSMHQzB6GCCCmLtL+WVyI7u QjUJ8dwGMEltVw34qdebQlVF/+0UC0ahNC2CKJNGMKl6WGT/y06lCt9wkz/eKtqPdJXp +Yisve1qeG//bCNUNAmbIxHADHV3VCynN1JYDJlhxYYa9MHECFA7+KzkciwsrGq5jgK+ yh+w== MIME-Version: 1.0 X-Received: by 10.13.226.75 with SMTP id l72mr17371844ywe.89.1433785127798; Mon, 08 Jun 2015 10:38:47 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Mon, 8 Jun 2015 10:38:47 -0700 (PDT) In-Reply-To: <87zj4ah6i0.fsf@latte.josefsson.org> References: <87zj4ah6i0.fsf@latte.josefsson.org> Date: Mon, 8 Jun 2015 10:38:47 -0700 Message-ID: From: Martin Thomson To: Simon Josefsson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Updated EdDSA in TLS 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: Mon, 08 Jun 2015 17:38:49 -0000 On 8 June 2015 at 02:52, Simon Josefsson wrote: > * Is it a good idea to reuse the NamedCurve value for Curve25519 for > Ed25519 too? I don't think so. I understand that there might be some shared code, but we are likely to see implementation of DH on 25519 long before signatures. From nobody Mon Jun 8 17:42: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 EA1011A005F for ; Mon, 8 Jun 2015 17:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PgIOIaatQb5l for ; Mon, 8 Jun 2015 17:42:22 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 182691A005C for ; Mon, 8 Jun 2015 17:42:21 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 1BEFF2868B; Tue, 9 Jun 2015 00:42:21 +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 0898528688; Tue, 9 Jun 2015 00:42:21 +0000 (GMT) Received: from email.msg.corp.akamai.com (ustx2ex-cas5.msg.corp.akamai.com [172.27.25.34]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 9F5BE202C; Tue, 9 Jun 2015 00:42:20 +0000 (GMT) Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com (172.27.27.102) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.27.104) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 8 Jun 2015 19:42:19 -0500 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.1076.000; Mon, 8 Jun 2015 19:42:20 -0500 From: "Salz, Rich" To: Martin Thomson , Simon Josefsson Thread-Topic: [TLS] Updated EdDSA in TLS drafts Thread-Index: AQHQodDeOhc2jG8KIEC2mh1mZNVXYZ2jNCKAgAAh7aA= Date: Tue, 9 Jun 2015 00:42:19 +0000 Message-ID: References: <87zj4ah6i0.fsf@latte.josefsson.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.57.194] 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] Updated EdDSA in TLS 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, 09 Jun 2015 00:42:25 -0000 > I don't think so. I understand that there might be some shared code, but= we > are likely to see implementation of DH on 25519 long before signatures. Agree, use distinct identifiers; djb thinks they are fundamentally differen= t, and calls them X25519 and Ed25519. (And of course the point format is d= ifferent :) From nobody Tue Jun 9 01: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 428831B2A52 for ; Tue, 9 Jun 2015 01:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 akG7hxpr8E3R for ; Tue, 9 Jun 2015 01:07:30 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 83CBF1B2A51 for ; Tue, 9 Jun 2015 01:07:30 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t5987Ifs027025 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 9 Jun 2015 10:07:19 +0200 From: Simon Josefsson To: Stephen Farrell References: <87zj4ah6i0.fsf@latte.josefsson.org> <55756B76.4070103@cs.tcd.ie> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:150609:stephen.farrell@cs.tcd.ie::FI5F3sah9MH+8vLe:0PFX X-Hashcash: 1:22:150609:tls@ietf.org::+UGDvAdRp3KCNjtf:C/EE Date: Tue, 09 Jun 2015 10:07:17 +0200 In-Reply-To: <55756B76.4070103@cs.tcd.ie> (Stephen Farrell's message of "Mon, 08 Jun 2015 11:16:22 +0100") Message-ID: <87wpzdjoei.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Updated EdDSA in TLS 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, 09 Jun 2015 08:07:32 -0000 --=-=-= Content-Type: text/plain Stephen Farrell writes: > Hiya, > > On 08/06/15 10:52, Simon Josefsson wrote: >> More feedback is appreciated! > > My v. high level feedback is that we really don't want > to get too far ahead of cfrg here. They've not yet got > all details of their preferred signature scheme using > that curve defined and it'd be really dumb for any IETF > WG to get ahead of that by accident. > > So while working on this draft is a fine thing, I don't > think we want to get to IETF LC for things like this until > after cfrg have figured out their preferred signature > scheme. (And the cfrg chairs tell me that ought be done > soon - in a few months.) Thanks for feedback. I believe these documents are quite far away from LC-ready so that this aspect shouldn't be a problem. I view the EdDSA/Ed25519 effort similar to the Brainpool/GOST efforts. If CFRG happens to pick EdDSA, then fine, but that isn't the motivational factor here. /Simon > Note that waiting until the cfrg position is clear > does not mean that the IETF has to mindlessly adopt what > cfrg have done, but we won't want to ignore their work > either. And fwiw, I guess I'd take the same position for > any work item for almost any new ECC work for the moment. > Since cfrg are nearly done and seem to be making progress > now, pre-empting their decisions wouldn't be a good plan. > > Cheers, > S. > > > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJVdp61AAoJEIYLf7sy+BGdVQ8IAK+U4JFonz9rOmdnumzLckxV rRsCqCMSZ8sTiEB+0vgYgVNOs8tupNO3lZDov+8s+g3oW3Wif24n8dtBaoXing7F xIiNr1/M6NewlQCzTpkjNpD1fIrKQMLCQTcKcUNtXGfDrM2MyhigPbQ+QWmdTKdz tTeT/06ZTMYHD49C8SAnigs9Mv/zHavN2ocRUpZx4tyudco/elqz352RvCAm2qf9 EGKO5Oqi5jc2urBDaeToi6b4XQT99xz0V2M1Hjgwk5g+bM+u9ToX57xCiCC/UyXG e6OZnopwKkp7ogo3lksg7z1pewevTTjb5N9dBZo5RvJ9lbOqX9o0isUlKiSvI7k= =/DqR -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jun 9 01:33: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 8B4861B2A8D for ; Tue, 9 Jun 2015 01:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 PiqRCYvXoomD for ; Tue, 9 Jun 2015 01:33:54 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 C6C041B2A8B for ; Tue, 9 Jun 2015 01:33:53 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t598XYdv029428 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 9 Jun 2015 10:33:35 +0200 From: Simon Josefsson To: Ilari Liusvaara References: <87zj4ah6i0.fsf@latte.josefsson.org> <20150608103940.GA25285@LK-Perkele-VII> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:150609:tls@ietf.org::JWwSvmig6mIFRYvK:Di2x X-Hashcash: 1:22:150609:ilari.liusvaara@elisanet.fi::3nFYMXV5RaLTUWr1:Mvl/ Date: Tue, 09 Jun 2015 10:33:33 +0200 In-Reply-To: <20150608103940.GA25285@LK-Perkele-VII> (Ilari Liusvaara's message of "Mon, 8 Jun 2015 13:39:40 +0300") Message-ID: <87sia1jn6q.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Updated EdDSA in TLS 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, 09 Jun 2015 08:33:55 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Again, many thanks for feedback Ilari! Ilari Liusvaara writes: > On Mon, Jun 08, 2015 at 11:52:23AM +0200, Simon Josefsson wrote: >> Hello. >>=20 >> I've updated my EdDSA-in-TLS draft to clarify the choice of >> HashAlgorithm that goes together with the EdDSA SignatureAlgorithm, >> please see: >>=20 >> https://tools.ietf.org/html/draft-josefsson-tls-eddsa-01 > > What hash algorithm is internally used? EdDSA does not fix that > (Ed25519 does fix it to SHA-512). Yeah. I think this is actually a larger question: will EdDSA be defined with other curves than Ed25519? If no, the only interesting algorithm to specify is Ed25519. If yes, the parameter choices needs to be encoded somehow. The hash isn't the only parameter to EdDSA. > Does more need to be said about how R and S are packed into single > blob for signature (concatenate)? I'm hoping draft-josefsson-eddsa-ed25519 already covers that. > More ciphersuites. Eew. Yeah. I offer this approach in the rare case that it might actually prove less complex to implement, and that some might find it useful. I suspect it might get shot down during further discussions. > Also, in TLS 1.2 Client CertificateVerify (does not apply to server > certificate, nor either certificate in TLS 1.3) signs the entiere > handshake so far. That could be many kilobytes in size, spread over > multiple message. Some implementations buffer the entire handshake to deal with this problem. I'm not sure what to recommend generally, or if this document has to care about this. >> The other feedback I have received is to reuse the existing ECDSA >> ciphersuites. I think this is a good idea, and believe it would likely >> work, but it is a fundamentally different approach. I created another >> draft to describe that approach, now published as: >>=20 >> https://tools.ietf.org/html/draft-josefsson-tls-eddsa2-00 > > TLS 1.0 and 1.1 lack algorithm specification for signature, which is > very useful for merging ciphersuites like this. In theory, one could > infer the algorithm from certificate, but I don't think that kind > of tricks are very often pulled off. RFC 4492 defines SignatureAlgorithm for TLS 1.0 and 1.1, or am I misunderstanding what you are saying? > I don't know if mixing curves used for key exchange and curves used > for signing is a good idea. Signing is much more complicated than > ECDH. Agreed. I've changed to use a separated NamedCurve registration. > The point format used by EdDSA has very little to do with montgomery X > (it does not have the same number of bits). The point format is little- > endian encoding of 2^(b-1)*lsb(x)+y, b is 256 for Curve25519, and lsb(x) > is x mod p mod 2. X and Y are edwards coordinates. Right, this was just broken. I've changed it to use a separate ECPointFormat registration for EdDSA public keys. > Also, notes about not seemingly fixing the hash, encoding of signature > and TLS 1.2 client certs apply. I've changed to use "sha512" instead of "none" in the latest update. >> For more context, related to the above is a draft describing OIDs for >> EdDSA for use in PKIX certificates as public keys and a signature >> algorithm: >>=20 >> https://tools.ietf.org/html/draft-josefsson-pkix-eddsa-00 > > Repeating the definitions sounds bit odd, one could presumably just > state what to put in each field. I find repeating this establish the terminology a bit better. There are so many structures in RFC 5280 that it is hard to find the right one. Also, I mostly stole this text from some other RFC. > Public key encoding? Edwards points have two coordinates. The usual > EdDSA encoding (32 octets for Curve25519)? I was hoping draft-josefsson-eddsa-ed25519 takes care of define a canonical public key encoding. > Hash algorithm? Note that public keys are not compatible across hash > algoritmhs. Fixed to SHA-512? Yes, I've changed my opinion and think that the HashAlgorithm should probably be sha512 to indicate Ed25519-SHA-512. > Signature encoding? Presumably the same as on TLS side. Again, hoping to shift this burden on draft-josefsson-eddsa-ed25519. I agree there could be clearer text on this. Cheers, /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJVdqTdAAoJEIYLf7sy+BGdAAAH+wTm2BOW9Pu4r9PipjOcqpoS XL8xSAdJK3HjVEI/BxQcW2+I8zB75PJ5TZVOHVYT1niJw+VQ/zODZEYDgoS9/xSz AYt0tUyrnM/rayqUiUoqsUNe4hdHSmKPrHnBM10CxKbYlZXlAzfgwVuPRVYVAwYh 2Y4ouguOpyNQfSQ4whWU0xU0aCoJYSILLKcUr0xpmE8L+JXyBNPbLSNxqM2rpNW6 4SjslIrSisXNNzb50tue0reQ2i14+XdUkHZ/XKfOGrVxQywQemcH3t//jaVXil44 wYalBGODZiI0CP4Aw8EwXgZ2T0iXo8pfe+X1WMXQggZAGk0IfwWeNn2SizCi6UI= =lkvR -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jun 9 01:37: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 19DFD1B2A95 for ; Tue, 9 Jun 2015 01:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.151 X-Spam-Level: X-Spam-Status: No, score=-0.151 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_SE=0.35, 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 OOlN0YoIO65k for ; Tue, 9 Jun 2015 01:37:05 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 D3A141B2A93 for ; Tue, 9 Jun 2015 01:37:04 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t598atmY029884 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 9 Jun 2015 10:36:56 +0200 From: Simon Josefsson To: tls@ietf.org References: <87zj4ah6i0.fsf@latte.josefsson.org> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:150609:tls@ietf.org::C3F5LjJBzYGnZp3K:71pF Date: Tue, 09 Jun 2015 10:36:53 +0200 In-Reply-To: <87zj4ah6i0.fsf@latte.josefsson.org> (Simon Josefsson's message of "Mon, 08 Jun 2015 11:52:23 +0200") Message-ID: <87oakpjn16.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Subject: Re: [TLS] Updated EdDSA in TLS 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, 09 Jun 2015 08:37:08 -0000 --=-=-= Content-Type: text/plain I made the NamedCurve/ECPointFormat registrations stand on their own, please see updated draft here: https://tools.ietf.org/html/draft-josefsson-tls-eddsa2-01 I'm hoping this version is a bit easier to read since everything it uses is defined in the document. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJVdqWmAAoJEIYLf7sy+BGdlZMIAJbADG2cAOc0hQ2X6YCyW8tS kE4Xs1diu1k5nvu8AW3KU4GEaN78l+bNK9rmL2tVMaUARKJ4Up96xRQFi/Mtxdob Lg601qmm5QTMUQNuslp3NPP/9/qpeZLvlQWjiFSW5tntynfI3dVdVClurjnM7k9n oDDVnQdxJ8oXlJvbbkxWu+OCgRngmTg/t3Y38MeWilQ++Z57ONhqXn6YaPC1RnXE tXMoJt3ic8Deh8N+/269BZtpvIjSPNcix1r26RskypcvwREB/OpvTw3RN3QqYVAe ZTD4QUy1dkYHsiWKcBGFXBJ6a/x38mywR6uzI6NXNeL6nZf4KTrryBWl8SgQGeE= =hntj -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jun 9 02: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 673F11B2B27 for ; Tue, 9 Jun 2015 02:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 KVtJstXFP1lZ for ; Tue, 9 Jun 2015 02:43:43 -0700 (PDT) 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 86FAE1B2B3D for ; Tue, 9 Jun 2015 02:43:43 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id 70EEB900B8; Tue, 9 Jun 2015 12:43:41 +0300 (EEST) Date: Tue, 9 Jun 2015 12:43:41 +0300 From: Ilari Liusvaara To: Simon Josefsson Message-ID: <20150609094341.GA11347@LK-Perkele-VII> References: <87zj4ah6i0.fsf@latte.josefsson.org> <20150608103940.GA25285@LK-Perkele-VII> <87sia1jn6q.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87sia1jn6q.fsf@latte.josefsson.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Updated EdDSA in TLS 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, 09 Jun 2015 09:43:49 -0000 On Tue, Jun 09, 2015 at 10:33:33AM +0200, Simon Josefsson wrote: > Again, many thanks for feedback Ilari! > > Ilari Liusvaara writes: > > > On Mon, Jun 08, 2015 at 11:52:23AM +0200, Simon Josefsson wrote: > >> Hello. > >> > >> I've updated my EdDSA-in-TLS draft to clarify the choice of > >> HashAlgorithm that goes together with the EdDSA SignatureAlgorithm, > >> please see: > >> > >> https://tools.ietf.org/html/draft-josefsson-tls-eddsa-01 > > > > What hash algorithm is internally used? EdDSA does not fix that > > (Ed25519 does fix it to SHA-512). > > Yeah. I think this is actually a larger question: will EdDSA be defined > with other curves than Ed25519? If no, the only interesting algorithm > to specify is Ed25519. If yes, the parameter choices needs to be > encoded somehow. The hash isn't the only parameter to EdDSA. The requirements of EdDSA are so bizarre that I don't think there are realistic curves to use with that besides Edwards form of Curve25519. (Edwards form of M-379 might come the closest, but the needed 760-bit(!) hash function is pretty much unobtabnium). > > Does more need to be said about how R and S are packed into single > > blob for signature (concatenate)? > > I'm hoping draft-josefsson-eddsa-ed25519 already covers that. Oh yeah. > > More ciphersuites. Eew. > > Yeah. I offer this approach in the rare case that it might actually > prove less complex to implement, and that some might find it useful. I > suspect it might get shot down during further discussions. I checked the TLS 1.2 spec: - If advertised ciphersuites and signature_algorithms conflict, latter takes precedence. - If selected ciphersuite and signature algorithm in struct DigitallySigned conflict, latter takes percedence. This means TLS_DHE_RSA_* key exchange can end up being signed with ECDSA, if client told it supports ECDSA. > > Also, in TLS 1.2 Client CertificateVerify (does not apply to server > > certificate, nor either certificate in TLS 1.3) signs the entiere > > handshake so far. That could be many kilobytes in size, spread over > > multiple message. > > Some implementations buffer the entire handshake to deal with this > problem. I'm not sure what to recommend generally, or if this document > has to care about this. I was thinking maybe PRF-hash, since one has that running anyway (for session_hash and finished) and it better be secure enough. Or maybe buffering doesn't really matter. > >> The other feedback I have received is to reuse the existing ECDSA > >> ciphersuites. I think this is a good idea, and believe it would likely > >> work, but it is a fundamentally different approach. I created another > >> draft to describe that approach, now published as: > >> > >> https://tools.ietf.org/html/draft-josefsson-tls-eddsa2-00 > > > > TLS 1.0 and 1.1 lack algorithm specification for signature, which is > > very useful for merging ciphersuites like this. In theory, one could > > infer the algorithm from certificate, but I don't think that kind > > of tricks are very often pulled off. > > RFC 4492 defines SignatureAlgorithm for TLS 1.0 and 1.1, or am I > misunderstanding what you are saying? I mean the explicit signature algorithm in struct DigitallySigned. That was new in TLS 1.2. Without that, one is left guessing the algorithm from the certificate, which is quite unclean. -Ilari From nobody Tue Jun 9 02:59: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 D05811B2B55 for ; Tue, 9 Jun 2015 02:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 MJkG8u_FZwTP for ; Tue, 9 Jun 2015 02:59:11 -0700 (PDT) Received: from emh03.mail.saunalahti.fi (emh03.mail.saunalahti.fi [62.142.5.109]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 293301B2B54 for ; Tue, 9 Jun 2015 02:59:11 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id 2B796188832; Tue, 9 Jun 2015 12:59:09 +0300 (EEST) Date: Tue, 9 Jun 2015 12:59:09 +0300 From: Ilari Liusvaara To: Simon Josefsson Message-ID: <20150609095909.GA11494@LK-Perkele-VII> References: <87zj4ah6i0.fsf@latte.josefsson.org> <87oakpjn16.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87oakpjn16.fsf@latte.josefsson.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Updated EdDSA in TLS 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, 09 Jun 2015 09:59:13 -0000 On Tue, Jun 09, 2015 at 10:36:53AM +0200, Simon Josefsson wrote: > I made the NamedCurve/ECPointFormat registrations stand on their own, > please see updated draft here: > > https://tools.ietf.org/html/draft-josefsson-tls-eddsa2-01 > > I'm hoping this version is a bit easier to read since everything it uses > is defined in the document. > > /Simon Eeh... "enum { ed25519(5) } NamedCurve;" NamedCurve 5 is already assigned to some (too weak) elliptic curve. The currently free named groups are 0x1D-0xFF and 0x0200-FDFF (don't use other ones, those have special meaning, and 0xFExx is private use). "When included in a ServerKeyExchange or ClientKeyExchange message," AFAIK, SKE or CKE never carry signature keys. The signature keys are sent inside Certificate messages (usually as PKIX SubjectPublicKeyInfo, but also OpenPGP format is defined). -Ilari From nobody Tue Jun 9 03:14: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 17DF21B2B78 for ; Tue, 9 Jun 2015 03:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 wpKoWkLsecoQ for ; Tue, 9 Jun 2015 03:14:17 -0700 (PDT) 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 928B31B2B73 for ; Tue, 9 Jun 2015 03:14:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5517DBEE6; Tue, 9 Jun 2015 11:14:15 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id haw4my31WTDn; Tue, 9 Jun 2015 11:14:12 +0100 (IST) Received: from [172.16.20.132] (62-50-200-74.client.stsn.net [62.50.200.74]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 23281BE49; Tue, 9 Jun 2015 11:14:11 +0100 (IST) Message-ID: <5576BC72.2090507@cs.tcd.ie> Date: Tue, 09 Jun 2015 11:14:10 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Simon Josefsson References: <87zj4ah6i0.fsf@latte.josefsson.org> <55756B76.4070103@cs.tcd.ie> <87wpzdjoei.fsf@latte.josefsson.org> In-Reply-To: <87wpzdjoei.fsf@latte.josefsson.org> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="grcVuv40sDoDGlpb2lIk9e4U1un3iSqKM" Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Updated EdDSA in TLS 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, 09 Jun 2015 10:14:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --grcVuv40sDoDGlpb2lIk9e4U1un3iSqKM Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Simon, On 09/06/15 09:07, Simon Josefsson wrote: > Stephen Farrell writes: >=20 >> Hiya, >> >> On 08/06/15 10:52, Simon Josefsson wrote: >>> More feedback is appreciated! >> >> My v. high level feedback is that we really don't want >> to get too far ahead of cfrg here. They've not yet got >> all details of their preferred signature scheme using >> that curve defined and it'd be really dumb for any IETF >> WG to get ahead of that by accident. >> >> So while working on this draft is a fine thing, I don't >> think we want to get to IETF LC for things like this until >> after cfrg have figured out their preferred signature >> scheme. (And the cfrg chairs tell me that ought be done >> soon - in a few months.) >=20 > Thanks for feedback. I believe these documents are quite far away from= > LC-ready so that this aspect shouldn't be a problem. Yep, I think that's correct. But I'd be somewhat wary of making design decisions in the meantime - we really don't want to end up with a cfrg-annointed signature scheme that ends up being hard to integrate because of decisions made now. (And folks who care about what cfrg are doing on that should get involved on the cfrg list.) >=20 > I view the EdDSA/Ed25519 effort similar to the Brainpool/GOST efforts. > If CFRG happens to pick EdDSA, then fine, but that isn't the > motivational factor here. Well, maybe. With no hats, I personally don't think we want more unused ciphersuites, and especially not ones that are almost-but-not-quite the same as one that uses the eventual cfrg-annointed signature scheme. (Unless there's a good reason to not use the cfrg stuff of course, in which case we're in a different situation.) But so long as the TLS WG don't bake in too much stuff and so long as cfrg continue to make progress in a timely fashion it should all work out. Cheers, S. >=20 > /Simon >=20 >> Note that waiting until the cfrg position is clear >> does not mean that the IETF has to mindlessly adopt what >> cfrg have done, but we won't want to ignore their work >> either. And fwiw, I guess I'd take the same position for >> any work item for almost any new ECC work for the moment. >> Since cfrg are nearly done and seem to be making progress >> now, pre-empting their decisions wouldn't be a good plan. >> >> Cheers, >> S. >> >> >> >> >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> --grcVuv40sDoDGlpb2lIk9e4U1un3iSqKM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVdrxzAAoJEC88hzaAX42iZfoH/2L2I2sFNcIhNpUaGxdD+HBj EnrI7FIeXlgxQkh8VWEk4enNPjSc+yGaL6RwZvaNGe0QMt6GqV2iRMC9RuXOoZlM 9caIscyK5D+RGGfKMq7BQL6jFde+sovo9bZVOWpag4ng07TQXnM6GnZX5e8RsnJ0 btCiBkvZrkakS4eFdwySCnhbsSUtPrXRzbbGmb60q+1aXPHGtg/s6vnkv4CMBIxd +4WnYyCGYnSpy7nVxCCyKTu9IBTOIdO7HKhpgWGbOPbvmdAq3TquYMoGS31ejjph 2g3sIlkEwNKdEEZijg6C6yg3q4EC1XnSKzE4ah2UxOrIBZsZBySAI3KQe10zILM= =RpLb -----END PGP SIGNATURE----- --grcVuv40sDoDGlpb2lIk9e4U1un3iSqKM-- From nobody Tue Jun 9 03:43: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 8EEC41B2BB5 for ; Tue, 9 Jun 2015 03:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.151 X-Spam-Level: X-Spam-Status: No, score=-0.151 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_SE=0.35, 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 MDvDBQ7lzcqS for ; Tue, 9 Jun 2015 03:43:02 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 680011B2BB3 for ; Tue, 9 Jun 2015 03:43:02 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t59Agu4u009520 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 9 Jun 2015 12:42:57 +0200 Date: Tue, 9 Jun 2015 12:42:54 +0200 From: Simon Josefsson To: Stephen Farrell Message-ID: <20150609124254.1693d252@latte.josefsson.org> In-Reply-To: <5576BC72.2090507@cs.tcd.ie> References: <87zj4ah6i0.fsf@latte.josefsson.org> <55756B76.4070103@cs.tcd.ie> <87wpzdjoei.fsf@latte.josefsson.org> <5576BC72.2090507@cs.tcd.ie> 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-sha256; boundary="Sig_/ANt2t6e.yVvVDN53Syv1J/z"; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Updated EdDSA in TLS 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, 09 Jun 2015 10:43:03 -0000 --Sig_/ANt2t6e.yVvVDN53Syv1J/z Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable > >> My v. high level feedback is that we really don't want > >> to get too far ahead of cfrg here. They've not yet got > >> all details of their preferred signature scheme using > >> that curve defined and it'd be really dumb for any IETF > >> WG to get ahead of that by accident. > >> > >> So while working on this draft is a fine thing, I don't > >> think we want to get to IETF LC for things like this until > >> after cfrg have figured out their preferred signature > >> scheme. (And the cfrg chairs tell me that ought be done > >> soon - in a few months.) > >=20 > > Thanks for feedback. I believe these documents are quite far away > > from LC-ready so that this aspect shouldn't be a problem. >=20 > Yep, I think that's correct. But I'd be somewhat wary of > making design decisions in the meantime - we really don't > want to end up with a cfrg-annointed signature scheme that > ends up being hard to integrate because of decisions made > now. (And folks who care about what cfrg are doing on that > should get involved on the cfrg list.) Hi Stephen. Sure. I don't think any decisions are or will be made here now. This is brainstorming about how to approach adding a new signature algorithm to TLS. There are no changes to any TLS version proposed that could cause integration problems for a future CFRG-blessed signature scheme. > > I view the EdDSA/Ed25519 effort similar to the Brainpool/GOST > > efforts. If CFRG happens to pick EdDSA, then fine, but that isn't > > the motivational factor here. >=20 > Well, maybe. With no hats, I personally don't think we want > more unused ciphersuites, and especially not ones that are > almost-but-not-quite the same as one that uses the eventual > cfrg-annointed signature scheme. (Unless there's a good > reason to not use the cfrg stuff of course, in which case > we're in a different situation.) >=20 > But so long as the TLS WG don't bake in too much stuff and > so long as cfrg continue to make progress in a timely fashion > it should all work out. Agreed. Btw, it seems that no new ciphersuites will have to be allocated anyway, and that the existing ECDSA ciphersuites can be reused. /Simon --Sig_/ANt2t6e.yVvVDN53Syv1J/z Content-Type: application/pgp-signature Content-Description: OpenPGP digital signatur -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVdsMuAAoJEIYLf7sy+BGdFFIH/ix3nTRLfb8N4tVf38Q0VTPy 8hthvs66+g/NnZrDwrGwFzfOF4BDVuWWokG8CjdVTjcdZ5gp8y64Nqs9ZwHtguFg ZAJUhPb2HUl13DCF8woo678eNRNFfUjxFLyDKsq1HzfZ+TaW4952iVEGZGJB6mDS kdf0i+mi3HhzZsIvIdGlz0NKcJVSjJCV+5PGw4HAddhRxw8YaopMzocNmd1YFyru K2hWL8k70M2l0fRJyRVdOLbuYXcr42jeRagn4u4Q3AMzVie8Vpr2CUBjw0ErQ5w4 MlAaeJ9iNOQ7YmKfdOWC2VhoMXI5msXwcDpwK+WH9US3GRLWhLNoQw3TyFmM+44= =53Hr -----END PGP SIGNATURE----- --Sig_/ANt2t6e.yVvVDN53Syv1J/z-- From nobody Tue Jun 9 03:47: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 8F2E11B2BB1 for ; Tue, 9 Jun 2015 03:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 6SVtfEO4YAPh for ; Tue, 9 Jun 2015 03:47:25 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 DBFEE1B2BAC for ; Tue, 9 Jun 2015 03:47:24 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t59Al69N009976 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 9 Jun 2015 12:47:07 +0200 Date: Tue, 9 Jun 2015 12:47:04 +0200 From: Simon Josefsson To: Ilari Liusvaara Message-ID: <20150609124704.051b23b6@latte.josefsson.org> In-Reply-To: <20150609095909.GA11494@LK-Perkele-VII> References: <87zj4ah6i0.fsf@latte.josefsson.org> <87oakpjn16.fsf@latte.josefsson.org> <20150609095909.GA11494@LK-Perkele-VII> 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-sha256; boundary="Sig_/bviBt+dmjeRWn.0o3UHOC5J"; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Updated EdDSA in TLS 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, 09 Jun 2015 10:47:26 -0000 --Sig_/bviBt+dmjeRWn.0o3UHOC5J Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Den Tue, 9 Jun 2015 12:59:09 +0300 skrev Re: [TLS] Updated EdDSA in TLS drafts: > On Tue, Jun 09, 2015 at 10:36:53AM +0200, Simon Josefsson wrote: > > I made the NamedCurve/ECPointFormat registrations stand on their > > own, please see updated draft here: > >=20 > > https://tools.ietf.org/html/draft-josefsson-tls-eddsa2-01 > >=20 > > I'm hoping this version is a bit easier to read since everything it > > uses is defined in the document. > >=20 > > /Simon >=20 > Eeh... >=20 > "enum { ed25519(5) } NamedCurve;" >=20 > NamedCurve 5 is already assigned to some (too weak) elliptic curve. >=20 > The currently free named groups are 0x1D-0xFF and 0x0200-FDFF (don't > use other ones, those have special meaning, and 0xFExx is private > use). >=20 >=20 > "When included in a ServerKeyExchange or ClientKeyExchange message," >=20 > AFAIK, SKE or CKE never carry signature keys. The signature keys are > sent inside Certificate messages (usually as PKIX > SubjectPublicKeyInfo, but also OpenPGP format is defined). Should be fixed in working copy, thank you! https://gitlab.com/jas/ietf-tls-eddsa/blob/master/draft-josefsson-tls-eddsa= 2.txt /Simon --Sig_/bviBt+dmjeRWn.0o3UHOC5J Content-Type: application/pgp-signature Content-Description: OpenPGP digital signatur -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVdsQoAAoJEIYLf7sy+BGd6wEIAJrVa4JkQf7M4xuHMAK+BsSU e27HiCK4qQLSUavdabgct6IGpNMxqCxmA/9TcgJmegReOY776QsCJqWntbmE6HvY 9WqqsdJyazK1LN1gMWNjbyytUuj+F0RyebJeO33xST9OVCJgL17fSH+0Rh2ViPsl ov5nGSDky93+E8h0kaBuAa6MMleEI/DALpC2eKCXm6O+bvEZgpwupi2HzyvipvIF dTPlC31Nbm+00RsxjSnb3MZkROaHYtvbk47N/R9Qrnnl+66MNTfgcd2vufOaH10B RwURci+ixEb4bxT340W/fzwxdnZFJsT3jN4boOPdZiQd2NcbFwEQvrFMnJZ75gc= =Mdlp -----END PGP SIGNATURE----- --Sig_/bviBt+dmjeRWn.0o3UHOC5J-- From nobody Tue Jun 9 03:48: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 812991B2BBC for ; Tue, 9 Jun 2015 03:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 0s04xuo9FRR7 for ; Tue, 9 Jun 2015 03:48:22 -0700 (PDT) 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 ABB301B2BB5 for ; Tue, 9 Jun 2015 03:48:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7C62ABE53; Tue, 9 Jun 2015 11:48:21 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bTBzPyAQkbV3; Tue, 9 Jun 2015 11:48:20 +0100 (IST) Received: from [172.16.20.132] (62-50-200-74.client.stsn.net [62.50.200.74]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 30002BE3F; Tue, 9 Jun 2015 11:48:20 +0100 (IST) Message-ID: <5576C472.4000707@cs.tcd.ie> Date: Tue, 09 Jun 2015 11:48:18 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Simon Josefsson References: <87zj4ah6i0.fsf@latte.josefsson.org> <55756B76.4070103@cs.tcd.ie> <87wpzdjoei.fsf@latte.josefsson.org> <5576BC72.2090507@cs.tcd.ie> <20150609124254.1693d252@latte.josefsson.org> In-Reply-To: <20150609124254.1693d252@latte.josefsson.org> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="RqpB9J7oKFUDl4MRjpNlAgLaL7CGilxLW" Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Updated EdDSA in TLS 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, 09 Jun 2015 10:48:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RqpB9J7oKFUDl4MRjpNlAgLaL7CGilxLW Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 09/06/15 11:42, Simon Josefsson wrote: > Hi Stephen. Sure. I don't think any decisions are or will be made > here now. This is brainstorming about how to approach adding a new > signature algorithm to TLS. There are no changes to any TLS version > proposed that could cause integration problems for a future CFRG-blesse= d > signature scheme. Cool, thanks, S. --RqpB9J7oKFUDl4MRjpNlAgLaL7CGilxLW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVdsRzAAoJEC88hzaAX42ihDoH/0mFILDNxqtRWXmylN86A2iE BY6VAQJpaFOQRdUquaioRrCx7DA81hb80zl9hLk8EAO4t8Qz0EeyrC4gnvZYhsmD JcN57TmlbZIksLYyss/vWUsErKSqSMhb3mZPLtqvR0sf6lXBHwAZMwHNp46UjJ6x q81MJ2AOo/0ehivUvxcnlpnqKIrX/1/ExOGDHTUp9cVkm5AYphGFKRRmDnraNMN2 AYE3jFWBTcg1ueVBOYp3tkGBIfXGErjseoje/EXQHWYlKtbIb0BF4tWeIiP8r7Gt 2owKqflIuu9CvzDe7ZmVNbJ//K0JDsUHElNQAJJL1GIZEtr9blPtLesZpL4lAIk= =jhu8 -----END PGP SIGNATURE----- --RqpB9J7oKFUDl4MRjpNlAgLaL7CGilxLW-- From nobody Tue Jun 9 04:10: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 181631A00D4 for ; Tue, 9 Jun 2015 04:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 a_MN5OiR_pvA for ; Tue, 9 Jun 2015 04:10:11 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 42F541A00CA for ; Tue, 9 Jun 2015 04:10:11 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t59B9u8Q011913 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 9 Jun 2015 13:09:57 +0200 From: Simon Josefsson To: Ilari Liusvaara References: <87zj4ah6i0.fsf@latte.josefsson.org> <20150608103940.GA25285@LK-Perkele-VII> <87sia1jn6q.fsf@latte.josefsson.org> <20150609094341.GA11347@LK-Perkele-VII> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:150609:ilari.liusvaara@elisanet.fi::5+rd2GXnZFzUR79u:Dj1H X-Hashcash: 1:22:150609:tls@ietf.org::Asa22/REGgCrytvo:wHPB Date: Tue, 09 Jun 2015 13:09:55 +0200 In-Reply-To: <20150609094341.GA11347@LK-Perkele-VII> (Ilari Liusvaara's message of "Tue, 9 Jun 2015 12:43:41 +0300") Message-ID: <87k2vddtoc.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Updated EdDSA in TLS 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, 09 Jun 2015 11:10:13 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Ilari Liusvaara writes: >> Yeah. I think this is actually a larger question: will EdDSA be defined >> with other curves than Ed25519? If no, the only interesting algorithm >> to specify is Ed25519. If yes, the parameter choices needs to be >> encoded somehow. The hash isn't the only parameter to EdDSA. > > The requirements of EdDSA are so bizarre that I don't think there are > realistic curves to use with that besides Edwards form of Curve25519. Okay. If that is really the case, we should specify Ed25519 directly and don't bother with EdDSA. But if there is a chance that we'll see other curves used with EdDSA, then it would be better to specify EdDSA and instantiate it for Ed25519 with some parameter choice. I believe this is an important question, but I lack knowledge to make a decision. > (Edwards form of M-379 might come the closest, but the needed 760-bit(!) > hash function is pretty much unobtabnium). Can't you build one with a keyed PRF? >> > More ciphersuites. Eew. >>=20 >> Yeah. I offer this approach in the rare case that it might actually >> prove less complex to implement, and that some might find it useful. I >> suspect it might get shot down during further discussions. > > I checked the TLS 1.2 spec: > - If advertised ciphersuites and signature_algorithms conflict, latter > takes precedence. > - If selected ciphersuite and signature algorithm in struct > DigitallySigned conflict, latter takes percedence. > > This means TLS_DHE_RSA_* key exchange can end up being signed with ECDSA, > if client told it supports ECDSA. While a bit ugly, language could be added to the TLS-Ed25519 document saying what to do in each case. I don't propose to do this, though, just saying that the problem above could be solved if it was really important. >> > Also, in TLS 1.2 Client CertificateVerify (does not apply to server >> > certificate, nor either certificate in TLS 1.3) signs the entiere >> > handshake so far. That could be many kilobytes in size, spread over >> > multiple message. >>=20 >> Some implementations buffer the entire handshake to deal with this >> problem. I'm not sure what to recommend generally, or if this document >> has to care about this. > > I was thinking maybe PRF-hash, since one has that running anyway (for > session_hash and finished) and it better be secure enough. Ah. Would you then sign the PRF-hash with SHA-512 for Ed25519? > Or maybe buffering doesn't really matter. I think not. Let's see. >> >> The other feedback I have received is to reuse the existing ECDSA >> >> ciphersuites. I think this is a good idea, and believe it would like= ly >> >> work, but it is a fundamentally different approach. I created another >> >> draft to describe that approach, now published as: >> >>=20 >> >> https://tools.ietf.org/html/draft-josefsson-tls-eddsa2-00 >> > >> > TLS 1.0 and 1.1 lack algorithm specification for signature, which is >> > very useful for merging ciphersuites like this. In theory, one could >> > infer the algorithm from certificate, but I don't think that kind >> > of tricks are very often pulled off. >>=20 >> RFC 4492 defines SignatureAlgorithm for TLS 1.0 and 1.1, or am I >> misunderstanding what you are saying? > > I mean the explicit signature algorithm in struct DigitallySigned. That > was new in TLS 1.2. > > Without that, one is left guessing the algorithm from the certificate, > which is quite unclean. Ah, right. Maybe there should be words to that effect: If TLS 1.0 or 1.1 then look at the certificate to find out the algorithm to use. Thanks again, /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJVdsmDAAoJEIYLf7sy+BGdesoH/i0h6jr6wH7Q52L2S/9YO3Oh /zVkNHnwXEz7Q503eBo54Xj4T4y1cILvKI2caXnQ4Q3oKXA7oY07e4WQOldtofyU sK/KE0MUTvn8wEzJKqsVldXB7YPOp0nm+b97GCjDe2AIeIfQtlgqMld1jxxu7xoN EqHl3+r1LY9rfP3UyJ4a9wewaI5fpdxQkR2wdShSiAEu64vO2yl/c7So5QfUQYJL DTD/aj0bpB3hMr7AJNbJ0k73kUXbRgqZA2/DUYoarZRCNQAzW3VGdV2YTHmDmi4l a/3Qoy3nfeYkgXX4rYWO+J2rFRUWiulwYC8t4C8dVLoOVWAn++nz+AgvUJDhsQU= =qkC8 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jun 9 04:39: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 3F4111A88F3 for ; Tue, 9 Jun 2015 04:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 RenJcHNMextZ for ; Tue, 9 Jun 2015 04:38:59 -0700 (PDT) Received: from emh03.mail.saunalahti.fi (emh03.mail.saunalahti.fi [62.142.5.109]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 973191A1A82 for ; Tue, 9 Jun 2015 04:38:58 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id 9AF2E188878; Tue, 9 Jun 2015 14:38:56 +0300 (EEST) Date: Tue, 9 Jun 2015 14:38:56 +0300 From: Ilari Liusvaara To: Simon Josefsson Message-ID: <20150609113856.GA12380@LK-Perkele-VII> References: <87zj4ah6i0.fsf@latte.josefsson.org> <20150608103940.GA25285@LK-Perkele-VII> <87sia1jn6q.fsf@latte.josefsson.org> <20150609094341.GA11347@LK-Perkele-VII> <87k2vddtoc.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87k2vddtoc.fsf@latte.josefsson.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Updated EdDSA in TLS 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, 09 Jun 2015 11:39:01 -0000 On Tue, Jun 09, 2015 at 01:09:55PM +0200, Simon Josefsson wrote: > Ilari Liusvaara writes: > > >> Yeah. I think this is actually a larger question: will EdDSA be defined > >> with other curves than Ed25519? If no, the only interesting algorithm > >> to specify is Ed25519. If yes, the parameter choices needs to be > >> encoded somehow. The hash isn't the only parameter to EdDSA. > > > > The requirements of EdDSA are so bizarre that I don't think there are > > realistic curves to use with that besides Edwards form of Curve25519. > > Okay. If that is really the case, we should specify Ed25519 directly > and don't bother with EdDSA. But if there is a chance that we'll see > other curves used with EdDSA, then it would be better to specify EdDSA > and instantiate it for Ed25519 with some parameter choice. > > I believe this is an important question, but I lack knowledge to make a > decision. Also, since this is also brainstorming about adding a new signature primitive (post-RFC5246). The CFRG signature primitive probably will be parameterized by curve and hash function (maybe with restrictions on minimum hash length for each curve). > > (Edwards form of M-379 might come the closest, but the needed 760-bit(!) > > hash function is pretty much unobtabnium). > > Can't you build one with a keyed PRF? Maybe. But that's something I'd rather not mess with. > >> > More ciphersuites. Eew. > >> > >> Yeah. I offer this approach in the rare case that it might actually > >> prove less complex to implement, and that some might find it useful. I > >> suspect it might get shot down during further discussions. > > > > I checked the TLS 1.2 spec: > > - If advertised ciphersuites and signature_algorithms conflict, latter > > takes precedence. > > - If selected ciphersuite and signature algorithm in struct > > DigitallySigned conflict, latter takes percedence. > > > > This means TLS_DHE_RSA_* key exchange can end up being signed with ECDSA, > > if client told it supports ECDSA. > > While a bit ugly, language could be added to the TLS-Ed25519 document > saying what to do in each case. I don't propose to do this, though, > just saying that the problem above could be solved if it was really > important. Why not just follow standard TLS 1.2 rules (which are a bit odd as noted above, but look to be workable)? > >> > Also, in TLS 1.2 Client CertificateVerify (does not apply to server > >> > certificate, nor either certificate in TLS 1.3) signs the entiere > >> > handshake so far. That could be many kilobytes in size, spread over > >> > multiple message. > >> > >> Some implementations buffer the entire handshake to deal with this > >> problem. I'm not sure what to recommend generally, or if this document > >> has to care about this. > > > > I was thinking maybe PRF-hash, since one has that running anyway (for > > session_hash and finished) and it better be secure enough. > > Ah. Would you then sign the PRF-hash with SHA-512 for Ed25519? Yup (if avoiding buffering is important). -Ilari From nobody Tue Jun 9 16:25: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 BEBF61A8A4A for ; Tue, 9 Jun 2015 16:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JhGu2qKiFIm3 for ; Tue, 9 Jun 2015 16:25:16 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::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 C0F1B1A8A47 for ; Tue, 9 Jun 2015 16:25:15 -0700 (PDT) Received: by igbhj9 with SMTP id hj9so23721887igb.1 for ; Tue, 09 Jun 2015 16:25:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=HrAeof/otPMWPaknyZ/kg46Nuk9+BEJivIkHq8AbNlo=; b=Hz8VMHrEZ69Lr4jhewxHOw/adDMRzXhkeZbhGYeIBDz9OlsMhulbVyI/YpRSTvT49v FpcG4VtFGan+qA/KUAbnSa2o7VdBHuj43YD8Xp4N3riGieJKe6DcmReyuAXK6gjdUcgU bKa4+1nWd6Uubr8X3IXI88ppTKq2RkYKvaVTD5USDiQeBwwTUFoM7+flHwnr9mbTY4WC jaC3eW2HgG2aJq65vGqIBM8S/15cKDEiiYlaqJneQG3mCWDWMl7teNl9o+uqdStCsEYs uvGMM10rwIGJD/7bCfAzuYpu5+j9ANVk9RAY2KgPn+XtlCcpV6nV8RfS1zs7RRTk6o6T JhVQ== MIME-Version: 1.0 X-Received: by 10.107.32.73 with SMTP id g70mr294182iog.23.1433892314210; Tue, 09 Jun 2015 16:25:14 -0700 (PDT) Sender: nygren@gmail.com Received: by 10.79.35.193 with HTTP; Tue, 9 Jun 2015 16:25:14 -0700 (PDT) In-Reply-To: <009101d0a1de$be9a76b0$3bcf6410$@alibaba-inc.com> References: <----3-------MPf3-$0147073b-d557-427b-a8c7-d3dd80aef07b@alibaba-inc.com> <20150608093155.GA24860@LK-Perkele-VII> <009101d0a1de$be9a76b0$3bcf6410$@alibaba-inc.com> Date: Tue, 9 Jun 2015 19:25:14 -0400 X-Google-Sender-Auth: ha9ydbEbe_IN45xDDSt9-PrkUY8 Message-ID: From: Erik Nygren To: Bingzheng Wu Content-Type: multipart/alternative; boundary=001a1140407808e7f205181e1276 Archived-At: Cc: tls Subject: Re: [TLS] add challenge in TLS v1.3 to prevent DDOS attack? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Jun 2015 23:25:18 -0000 --001a1140407808e7f205181e1276 Content-Type: text/plain; charset=UTF-8 We talked about this some at the TLS interim in Denver last year. Yoav Nir even wrote up one variation: https://tools.ietf.org/html/draft-nir-tls-puzzles-00 (and this idea even goes way back to https://www.usenix.org/legacy/events/sec2001/full_papers/dean/dean.pdf in 2001). There was some desire to take an approach and try and get it to look as close as possible to what DTLS is already doing with HelloVerifyRequest to try and reduce the number of different handshake flows. The primary outcome of the discussion in Denver was a desire to understand how a client puzzles scheme like this would help over simply doing intelligent server-side rate-limiting, especially as the two would likely need to be used together. In cases where a small number of IPs are flooding in connections, server-side rate-limiting can be used to defend already today (although it may not differentiate between different users behind a CGNAT or proxy). This then leaves more distributed attacks (eg, large bot nets with many nodes) in which case the challenge is to generate puzzles hard enough to slow down the attackers while not stalling out mobile clients. Giving the complexity (and associated risks) involved in adding in this functionality, people seemed to want better models or simulations for what attacks it actually helped with vs other simpler approaches. Erik On Mon, Jun 8, 2015 at 7:32 AM, Bingzheng Wu wrote: > I am sorry that I did not search the list archive thoroughly. > The scheme in your link is what I wanted (and the hash-challenge is better > than my propose). > > But I have one question still. It's said that this scheme can be > implemented as an extension. > If a client who dose not support this extension receives the challenge, > what should it do? > Just abort the connection? > Then some servers who provide important services may dare not to enable > this scheme, to avoid impacting the users who use TLS client not supporting > this extension. > > Please fix me if I misunderstand that propose. > > Thanks, > Bingzheng > > > -----Original Message----- > > From: Ilari Liusvaara [mailto:ilari.liusvaara@elisanet.fi] > > Sent: Monday, June 08, 2015 5:32 PM > > To: Bingzheng Wu > > Cc: tls > > Subject: Re: [TLS] add challenge in TLS v1.3 to prevent DDOS attack? > > > > On Mon, Jun 08, 2015 at 04:46:18PM +0800, Bingzheng Wu wrote: > > > Hi all, > > > > > > TLS is susceptible to DDOS attack. > > > In TLS v1.3, attackers can generate ClientHello and ClientKeyshare > > > messages easily, while the server has to consume large amounts of CPU > > > doing asymmetric crypto operations to generate ServerKeyshare and > > > ServerCertificateVerify messages. > > > > Note that this type of attack already works in TLS 1.2. > > > > > So, could we add a challenge-response mode in TLS v1.3 to increase the > > > attacker's cost ? > > > > There is already an issue about this (but given nature of that issue, it > should be > > discussed on this ML, especially as it still seems to be open). > > > > > The mode is disable in usual. > > > If the server think it's under attack (e.g. >1000 qps), it could > > > enable this mode by responding a HelloRetryRequest (or a new type) > > > message to the client with a challenge. > > > The client receiving the challenge must solve the challenge which is > > > expensive in CPU, and continue the handshake by carrying the > > > challenge's answer. > > > > One has to be careful that this kind of thing doesn't introduce security > issues. > > E.g. Proper implementations can not restart handshake, and repeating > yourself > > is legendary source of bugs. > > > > > For example, server could make the challenge by encrypting an random > > > number by a RSA public key (which is short), and send the private key > > > (which is long) and cipher text to client. > > > > The usual way things like this are done is via hashes. > > > > TLS13 github issue #9 has link to a ML post describing one scheme: > > https://www.ietf.org/mail-archive/web/tls/current/msg11763.html > > > > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a1140407808e7f205181e1276 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We talked about this some at the = TLS interim in Denver last year.
Yoav Nir even wrote up one varia= tion:=C2=A0 https://tools.ietf.org/html/draft-nir-tls-puzzles-00
in 2001).=C2=A0 Th= ere was some desire to take an approach and try and get
it t= o look as close as possible to what DTLS is already doing with HelloVerifyR= equest
to try and reduce the number of different handshake flows.<= br>
The primary outcome of the discussion in Denver was a desire t= o understand
how a client puzzles scheme like this would help over = simply doing intelligent
server-side rate-limiting, especially as the t= wo would likely need to be used
together.=C2=A0 In cases whe= re a small number of IPs are flooding in connections,
server-side rate-= limiting can be used to defend already today (although it may
not differ= entiate between different users behind a CGNAT or proxy).
Thi= s then leaves more distributed attacks (eg, large bot nets with many nodes)=
in which case the challenge is to generate puzzles hard enou= gh to slow down
the attackers while not stalling out mobile c= lients.=C2=A0 Giving the complexity
(and associated risks) in= volved in adding in this functionality, people seemed
to want= better models or simulations for what attacks it actually helped with
<= /div>
vs other simpler approaches.

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Erik




On Mon, Jun 8, 2015 at 7:32 AM= , Bingzheng Wu <bingzheng.wbz@alibaba-inc.com> w= rote:
I am sorry that I did not search th= e list archive thoroughly.
The scheme in your link is what I wanted (and the hash-challenge is better = than my propose).

But I have one question still. It's said that this scheme can be implem= ented as an extension.
If a client who dose not support this extension receives the challenge, wha= t should it do?
Just abort the connection?
Then some servers who provide important services may dare not to enable thi= s scheme, to avoid impacting the users who use TLS client not supporting th= is extension.

Please fix me if I misunderstand that propose.

Thanks,
Bingzheng

> -----Original Message-----
> From: Ilari Liusvaara [mailto:ilari.liusvaara@elisanet.fi]
> Sent: Monday, June 08, 2015 5:32 PM
> To: Bingzheng Wu
> Cc: tls
> Subject: Re: [TLS] add = challenge in TLS v1.3 to prevent DDOS attack?
>
> On Mon, Jun 08, 2015 at 04:46:18PM +0800, Bingzheng Wu wrote:
> > Hi all,
> >
> > TLS is susceptible to DDOS attack.
> > In TLS v1.3, attackers can generate ClientHello and ClientKeyshar= e
> > messages easily, while the server has to consume large amounts of= CPU
> > doing asymmetric crypto operations to generate ServerKeyshare and=
> > ServerCertificateVerify messages.
>
> Note that this type of attack already works in TLS 1.2.
>
> > So, could we add a challenge-response mode in TLS v1.3 to increas= e the
> > attacker's cost ?
>
> There is already an issue about this (but given nature of that issue, = it should be
> discussed on this ML, especially as it still seems to be open).
>
> > The mode is disable in usual.
> > If the server think it's under attack (e.g. >1000 qps), it= could
> > enable this mode by responding a HelloRetryRequest (or a new type= )
> > message to the client with a challenge.
> > The client receiving the challenge must solve the challenge which= is
> > expensive in CPU, and continue the handshake by carrying the
> > challenge's answer.
>
> One has to be careful that this kind of thing doesn't introduce se= curity issues.
> E.g. Proper implementations can not restart handshake, and repeating y= ourself
> is legendary source of bugs.
>
> > For example, server could make the challenge by encrypting an ran= dom
> > number by a RSA public key (which is short), and send the private= key
> > (which is long) and cipher text to client.
>
> The usual way things like this are done is via hashes.
>
> TLS13 github issue #9 has link to a ML post describing one scheme:
> https://www.ietf.org/mail-archive/web/tls/current/m= sg11763.html
>
>
> -Ilari

_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls

--001a1140407808e7f205181e1276-- From nobody Wed Jun 10 10:27: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 ECDA11ACE6B for ; Wed, 10 Jun 2015 10:27:19 -0700 (PDT) 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=[BAYES_50=0.8, 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 Fwl4LboSnyvL for ; Wed, 10 Jun 2015 10:27:18 -0700 (PDT) Received: from mail-qk0-f173.google.com (mail-qk0-f173.google.com [209.85.220.173]) (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 4739F1B2EFB for ; Wed, 10 Jun 2015 10:27:18 -0700 (PDT) Received: by qkx62 with SMTP id 62so28721194qkx.3 for ; Wed, 10 Jun 2015 10:27:17 -0700 (PDT) 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 :content-transfer-encoding; bh=Y7HL+QVdAy5iYy9Qc+aTdbn8t0dt2rmLjkSQ6dEb0Ms=; b=fnwCbibgq3Lh53SWQIivsMatHQcGlTg8/6W31LUaiKU9PLtDg/LVwNJqUfjCNMZcCd bRqvROQGRGmqXZP1KgHefvExygamI3AorCwM7CKAR4Byu1JIcHCFMCvA8JKPkt1tJMMh DaLfM+2rj6zVk6zDfQ718U7mZ5HOcq2ajUlsOZSHv97BbseLLyLnqqDJkJcZzFLiCs1l ig5pA5w0pR2wNDrnrxNryXDBN4SPnacdwFfH6zYz3uhxxMMtmSeYY7Qy3WGOv1KY9DII swotAWUfA40pZ6MICEpOd1D0eWkha62ahgNFeTuVoM57TwyEBVBirT/eMEuQ+NdM97Ca 5q1g== X-Gm-Message-State: ALoCoQkT9WXmnDWrL/zFVJ0yWSLVP/86OVn5nnHY4Qc/GBmYB9OfTy2r9jnWww/kSSc9/21zNqat X-Received: by 10.140.146.138 with SMTP id 132mr5849949qhs.2.1433957237530; Wed, 10 Jun 2015 10:27:17 -0700 (PDT) Received: from [192.168.1.110] (c-69-255-115-150.hsd1.md.comcast.net. [69.255.115.150]) by mx.google.com with ESMTPSA id 106sm4410855qge.22.2015.06.10.10.27.16 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Jun 2015 10:27:16 -0700 (PDT) Message-ID: <55787375.7040808@nthpermutation.com> Date: Wed, 10 Jun 2015 13:27:17 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Simon Josefsson References: <556C4ACD.9040002@azet.org> <556C51FC.807@azet.org> <20150601125302.GA19269@LK-Perkele-VII> <556C9AF4.7030607@nthpermutation.com> <87r3pp3803.fsf@latte.josefsson.org> In-Reply-To: <87r3pp3803.fsf@latte.josefsson.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] EDDSA/Curve25519 identifiers: Was Re: AES-OCB 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, 10 Jun 2015 17:27:20 -0000 On 6/5/2015 10:06 PM, Simon Josefsson wrote: > Michael StJohns writes: > >> Instead, get a new allocation and write a document that looks like >> RFC5480 for the ED and Curve public keys. You want certificate >> representations for *both*. > I've started this for EdDSA: > https://tools.ietf.org/html/draft-josefsson-tls-ed25519-00 > > Are you saying it would be useful to also specify certificate formats > for Curve25519 ECDH keys? > > /Simon Sorry - I missed this in the pile. And yes for Curve25519. Here's my thoughts: Usually, you have a certificate with a public key in it that's used to sign an ephemeral (EC)DH public key. The EPK is used to derive a shared secret and everything downstream is derived from that. The session keys trace their authentication back through the shared secret, through the EPK and through the signature over the EPK to the certificate's public key. And the public key in the certificate chains back to some root. With key agreement keys such as ECDH, Curve25519 or DH, what you can do instead is to use the key in the certificate with the other side's certificate key, to derive one half of the total shared secret and the senders EPK with the receiver's ephemeral private key to derive the second half. Concatenate those and then derive your downstream keys from them. (e.g. ECDH (PermPrivate1, PermPublic2) || ECDH (EphemPrivate1, EphemPublic2) ) The certificate keys chain as before, so that you know that the first half of the shared secret is derived from authentic data and is itself authentic. Combining the first half of the shared secret with the second half still gives you authentic data (but results in a varied shared secret for each call). And that means downstream keys derived from the combined shared secrets can still be traced back to the certificate authentication root. The nice thing about this scheme (It's called a C(2,2) scheme in NISP SP800-56A parlance), is that you don't need to sign anything during a key agreement handshake. You still need traditional signature schemes over the certificates, but you don't actually need them in the handshake. There are other schemes where one side only has ephemeral keys (e.g. client without cert) where this still works - you end up with: ECDH (PermPrivate1, EphemPublic2) || ECDH (EphemPrivate1, EphemPublic2) This just works with the existing EC Prime and F2M curves as the key pairs can be used with both ECDSA and ECDH. In any event, going ahead and creating a certificate format for Curve25519 at the same time you do ED25519 probably makes sense given the two algorithms are family members and appear to share a representation. Mike From nobody Wed Jun 10 20:20: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 B9C761A8AC7 for ; Wed, 10 Jun 2015 20:20:23 -0700 (PDT) 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 zeAT5EwtsBMf for ; Wed, 10 Jun 2015 20:20:22 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id CC71C1A8ACC for ; Wed, 10 Jun 2015 20:20:22 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id AB13C31809F; Wed, 10 Jun 2015 20:20:22 -0700 (PDT) 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=KJRasAXopaZVw5 QFF+SgXn+NSfg=; b=o+ou9kAdpW7a9v3zIB9gT/aBQ0l4GJEeMUTevIKOVVExYI z/XiVbm5x2lx14Z3bEitzEm47dT3TxRy2HQEpyZddgOF156AMc3y3tXEg937T1kg k1VpHbHQ3cv5Wx3z1CccR5PiLcFxI7YhuPpiC9M7U/z7Ski01wrmejVmjah/M= Received: from localhost (unknown [172.56.18.136]) (Authenticated sender: nico@cryptonector.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPA id 25194318095; Wed, 10 Jun 2015 20:20:22 -0700 (PDT) Date: Wed, 10 Jun 2015 22:20:21 -0500 From: Nico Williams To: Michael StJohns Message-ID: <20150611032020.GB4007@localhost> References: <556C4ACD.9040002@azet.org> <556C51FC.807@azet.org> <20150601125302.GA19269@LK-Perkele-VII> <556C9AF4.7030607@nthpermutation.com> <87r3pp3803.fsf@latte.josefsson.org> <55787375.7040808@nthpermutation.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55787375.7040808@nthpermutation.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: Simon Josefsson , tls@ietf.org Subject: Re: [TLS] EDDSA/Curve25519 identifiers: Was Re: AES-OCB 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, 11 Jun 2015 03:20:23 -0000 On Wed, Jun 10, 2015 at 01:27:17PM -0400, Michael StJohns wrote: > On 6/5/2015 10:06 PM, Simon Josefsson wrote: > >Are you saying it would be useful to also specify certificate formats > >for Curve25519 ECDH keys? > > Sorry - I missed this in the pile. > > And yes for Curve25519. > > Here's my thoughts: > > [...] > > The nice thing about this scheme (It's called a C(2,2) scheme in > NISP SP800-56A parlance), is that you don't need to sign anything > during a key agreement handshake. You still need traditional > signature schemes over the certificates, but you don't actually need > them in the handshake. RSA key transport was nice because it was faster than DH + signatures. Now that PFS matters that consideration goes the way of the dodo. It's got to be key agreement + authentication, which means either key agreement with signatures, or two key agreements. (Using DH with fixed public keys goes back to the invention of DH itself, and this was deployed way back when. E.g., AUTH_DH. This is why PKIX supports key agreement certificates. Combining DH for authentication with DH for PFS is an obvious idea.) And besides, with ECC and curves like Curve25519, *two* ECDH exchanges, one of which has a certified public key on the server side (the other being ephemeral, for some value of "ephemeral"), can go faster than one signed ECDH exchange. How much, if at all, may depend on what curves and implementations. > There are other schemes where one side only has ephemeral keys (e.g. > client without cert) where this still works - you end up with: Right, and which would be the common case on the Internet. > This just works with the existing EC Prime and F2M curves as the key > pairs can be used with both ECDSA and ECDH. Is that safe? > In any event, going ahead and creating a certificate format for > Curve25519 at the same time you do ED25519 probably makes sense > given the two algorithms are family members and appear to share a > representation. Sure, but doing it separately works too. Whatever makes the spec go faster. Nico -- From nobody Thu Jun 11 10:03: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 451E31B31A5; Thu, 11 Jun 2015 10:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZlsZeWM-Q5t; Thu, 11 Jun 2015 10:03:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ACA31B318D; Thu, 11 Jun 2015 10:03:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150611170317.13732.72719.idtracker@ietfa.amsl.com> Date: Thu, 11 Jun 2015 10:03:17 -0700 Archived-At: Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-chacha20-poly1305-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: Thu, 11 Jun 2015 17:03:18 -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 ChaCha20-Poly1305 AEAD Cipher for Transport Layer Security Authors : Adam Langley Wan-Teh Chang Nikos Mavrogiannopoulos Joachim Strombergson Simon Josefsson Filename : draft-ietf-tls-chacha20-poly1305-00.txt Pages : 7 Date : 2015-06-11 Abstract: This document describes the use of the ChaCha stream cipher with Poly1305 in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-chacha20-poly1305/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tls-chacha20-poly1305-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 Thu Jun 11 12:58: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 437B81B3118 for ; Thu, 11 Jun 2015 12:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_35=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o_iHFXhnmQ6W for ; Thu, 11 Jun 2015 12:58:24 -0700 (PDT) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) (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 040A51B311A for ; Thu, 11 Jun 2015 12:58:24 -0700 (PDT) Received: by qcej9 with SMTP id j9so5125851qce.1 for ; Thu, 11 Jun 2015 12:58:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:mime-version:content-type :content-transfer-encoding:message-id; bh=CQ4dw6vFZnHPnXmVkUrRJpX5NZXJYNdCw7y96ReHDXE=; b=AUIn4KPNOlZgPe8R1FuHR+Vdo0ccVbqSvJ5qghOoZVY0JzclJPoE0mq9+vuU5nyYay PmFpt4SyLX9MSM04qtcD7DQuSWMSG5w19B/gM/3r2JzL7OzJQ4zKh4eaI31W3da+flRc n13rybhFw+/aP/UeVOFFYJ5otbYovJ3qFdc6ZqcJ7J4WllgVQq/P5MZze0bTKOrTm/G4 0ixD2q4s5cCI7mRf/chmQNDPuiIwLgqzfXKZYGdU0YMurNaTnT88zkganrIWvpO5u+Tt m6ivmt8KPt1Ds6MtGMVD2knLIhwFjesnNtwXMEXV+yeFWx7/oVMw3DREbJoSFT2g2MVk E0Hw== X-Received: by 10.140.33.227 with SMTP id j90mr13881582qgj.6.1434052703341; Thu, 11 Jun 2015 12:58:23 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id c38sm695145qgd.33.2015.06.11.12.58.22 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 11 Jun 2015 12:58:22 -0700 (PDT) From: Dave Garrett To: "" Date: Thu, 11 Jun 2015 15:58:21 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201506111558.21577.davemgarrett@gmail.com> Archived-At: Subject: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Jun 2015 19:58:25 -0000 Here is a branch with a rough draft of an a la carte handshake algorithm negotiation scheme for TLS 1.3, based on discussions on this list. https://github.com/davegarrett/tls13-spec/compare/updateciphersuites...davegarrett:alacarte TL:DR: * Deprecate all suites with any of: DH, DHE, ECDH, RSA, DSS * Deployments may continue to offer deprecated suites for TLS 1.0-1.2 negotiation. * TLS 1.3 would only negotiate suites prefixed with ECDHE_ECDSA or ECDHE_PSK. * TLS 1.3 implementations negotiate ECDHE/DHE & RSA/DSS/ECDSA solely via the "supported_groups" & "signature_algorithms" extensions. * No change to bulk cipher negotiation. To be clear, this would mean a connection could negotiate usage of a ECDHE_ECDSA suite and negotiate ECDHE+RSA. It doesn't say anything about DHE+ECDSA yet, but I think that combination is fine if negotiated. Benefits: 1) Old DH(E) suites are replaced by a system which only negotiates strong FFDHE groups. 2) The combinatorial explosion of suites that need to be offered in a ClientHello is reduced. 3) Accidental interop failure due to a missing combination is avoided. 4) All TLS 1.3 implementations are expected to be able to handle ECC, but are not required to offer or negotiate it. (at least, here) 5) EdDSA can easily be added to the list as a variation of ECDSA without new suites. 6) No more confusing double negotiation of signature algorithms. Just extensions, instead of many suites and extensions. 7) The default usage of SHA1 for the "signature_algorithms" extension can be removed, as all TLS 1.3 clients would be required to send it. The branch is a WIP to resume discussion on this topic. Probably needs some significant additional changes. Dave From nobody Thu Jun 11 16:26: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 DABD81B2B60 for ; Thu, 11 Jun 2015 16:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.04 X-Spam-Level: ** X-Spam-Status: No, score=2.04 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 rsl5H7G5bFc0 for ; Thu, 11 Jun 2015 16:26:17 -0700 (PDT) Received: from BLU004-OMC3S25.hotmail.com (blu004-omc3s25.hotmail.com [65.55.116.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 8C7341B2B5A for ; Thu, 11 Jun 2015 16:26:17 -0700 (PDT) Received: from BLU177-W45 ([65.55.116.74]) by BLU004-OMC3S25.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Thu, 11 Jun 2015 16:26:16 -0700 X-TMN: [4S8sKLXJvkMGX/5ygNXR+ArjiJarp+gn] X-Originating-Email: [yuhongbao_386@hotmail.com] Message-ID: From: Yuhong Bao To: Xiaoyin Liu , Aaron Zauner , Dave Garrett Date: Thu, 11 Jun 2015 16:26:15 -0700 Importance: Normal In-Reply-To: References: <201505211210.43060.davemgarrett@gmail.com>, , <20150522025214.GA21141@typhoon.azet.org>, , , , <201505212304.11513.davemgarrett@gmail.com>, , <20150522032029.GA24064@typhoon.azet.org>, Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 11 Jun 2015 23:26:16.0336 (UTC) FILETIME=[03726100:01D0A49E] Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] prohibit <1.2 on clients (but allow servers) (was: prohibit <1.2 support on 1.3+ servers (but allow clients)) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Jun 2015 23:26:19 -0000 I think disabling TLS 1.0 on servers is probably easier.=0A= Remember that TLS 1.0 lasted for more than a decade.=A0=0A= The reason disabling SSLv3 was trivial was that TLS 1.0 was already support= ed and enabled by default on most servers.=0A= Even then there was the problem of extension intolerant and version intoler= ant servers that had to be upgraded.=0A= =0A= Yuhong Bao=0A= ________________________________=0A= > From: xiaoyin.l@outlook.com =0A= > To: azet@azet.org=3B davemgarrett@gmail.com =0A= > Date: Fri=2C 22 May 2015 01:25:41 -0400 =0A= > CC: tls@ietf.org =0A= > Subject: Re: [TLS] prohibit <1.2 on clients (but allow servers) (was: =0A= > prohibit <1.2 support on 1.3+ servers (but allow clients)) =0A= > =0A= > Hi=2C =0A= > =0A= > Instead of prohibiting bad crypto on the server side=2C I would like to = =0A= > propose a BCP which prohibits TLS 1.1- on the clients=2C but allows =0A= > servers to keep supporting TLS 1.0+. The simple reason is that we =0A= > should allow normal users to gradually upgrade their old =0A= > browsers/operating systems=2C but should encourage (or =0A= > require) webmasters to upgrade their servers as soon as possible in =0A= > order to protect their users' security and privacy. I believe phasing =0A= > out insecure web technology should be promoted by browsers. Microsoft's = =0A= > plan to phase out SHA-1 certificates has been quite effective so far=2C = =0A= > and I suggest we do the same for old TLS protocols and old cipher =0A= > suites. =0A= > =0A= > I do understand that=2C as many have pointed out=2C upgrading servers is = =0A= > not an easy task for some companies. But if not now=2C they have to be = =0A= > upgraded sometime. Is 2-3 years enough for all servers to be upgraded? = =0A= > So what about specifying the following in tls1-diediedie doc: =0A= > =0A= > 1) (Already required in RFC 7525) TLS servers MUST support TLS 1.3 (if = =0A= > TLS 1.3 RFC has been published=2C otherwise TLS 1.2). =0A= > 2) (Already required in RFC 7525) If ClientHello.client_version is =0A= > 0x0303 (TLS 1.2) or above=2C then TLS servers MUST negotiate that =0A= > version. =0A= > 3) TLS servers MAY support TLS 1.0 and TLS 1.1 to support old TLS clients= . =0A= > 4) (New requirement!) Starting from January 1=2C 2018=2C TLS clients MUST= =0A= > terminate the handshake if serverHello.server_version is 0x0302 (TLS =0A= > 1.1) or below. =0A= > 5) (New requirement!) Starting from January 1=2C 2018=2C TLS clients MUST= =0A= > NOT include cipher suites that do not provide forward secrecy in the =0A= > ClientHello message. =0A= > 6) (Same as RFC 7525) The requirements above do not apply to =0A= > opportunistic encryptions=2C like STARTTLS. =0A= > =0A= > The date specified in 4) and 5) can be discussed later. It is =0A= > important that all major browser vendors agree to enforce 4) and 5) =0A= > after this specific date=2C and that this date is widely known by website= =0A= > operators. The goal of my proposal is to eliminate TLS 1.0-only =0A= > and non-PFS TLS servers before the next decade. =0A= > =0A= > Best=2C =0A= > Xiaoyin =0A= > =0A= > _______________________________________________ TLS mailing list =0A= > TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls =0A= = From nobody Fri Jun 12 01:32: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 CD41C1A88C7 for ; Fri, 12 Jun 2015 01:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_35=0.6, 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 og4qhBflpZSx for ; Fri, 12 Jun 2015 01:31:57 -0700 (PDT) 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 7A1AA1A88A0 for ; Fri, 12 Jun 2015 01:31:56 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id F09779023B; Fri, 12 Jun 2015 11:31:53 +0300 (EEST) Date: Fri, 12 Jun 2015 11:31:53 +0300 From: Ilari Liusvaara To: Dave Garrett Message-ID: <20150612083153.GA24990@LK-Perkele-VII> References: <201506111558.21577.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <201506111558.21577.davemgarrett@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: "" Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Jun 2015 08:32:00 -0000 On Thu, Jun 11, 2015 at 03:58:21PM -0400, Dave Garrett wrote: > Here is a branch with a rough draft of an a la carte handshake algorithm negotiation scheme for TLS 1.3, based on discussions on this list. > > https://github.com/davegarrett/tls13-spec/compare/updateciphersuites...davegarrett:alacarte Interesting... > TL:DR: > * Deprecate all suites with any of: DH, DHE, ECDH, RSA, DSS > * Deployments may continue to offer deprecated suites for TLS 1.0-1.2 negotiation. > * TLS 1.3 would only negotiate suites prefixed with ECDHE_ECDSA or ECDHE_PSK. > * TLS 1.3 implementations negotiate ECDHE/DHE & RSA/DSS/ECDSA solely via the "supported_groups" & "signature_algorithms" extensions. > * No change to bulk cipher negotiation. > > To be clear, this would mean a connection could negotiate usage of a ECDHE_ECDSA suite and negotiate ECDHE+RSA. It doesn't say anything about DHE+ECDSA yet, but I think that combination is fine if negotiated. AFAICT, In TLS 1.2, DHE+ECDSA is legal, if client signals support for both DHE (via ciphersuites) and ECDSA (via (possibly implicit default) signature_algorithms). (In TLS 1.1 and earlier, there is seemingly no way to use DHE+ECDSA) The main pitfall I see for unifying DH is that ECDHE nested length byte (which is insufficient for DHE). One would have to either expand that to 2 bytes, or better yet, dump it entierely (as it is seemingly useless). > Benefits: > 1) Old DH(E) suites are replaced by a system which only negotiates strong FFDHE groups. > 2) The combinatorial explosion of suites that need to be offered in a ClientHello is reduced. > 3) Accidental interop failure due to a missing combination is avoided. > 4) All TLS 1.3 implementations are expected to be able to handle ECC, but are not required to offer or negotiate it. (at least, here) > 5) EdDSA can easily be added to the list as a variation of ECDSA without new suites. > 6) No more confusing double negotiation of signature algorithms. Just extensions, instead of many suites and extensions. > 7) The default usage of SHA1 for the "signature_algorithms" extension can be removed, as all TLS 1.3 clients would be required to send it. Also, there is no "double negotiation" in TLS 1.2 either. TLS 1.2 is quite clear about interaction of signature algorithms in ciphersuites and explicit signature negotiation (explicit negotiation always takes percedence). Of course, I wouldn't be surprised if there was fair bit of software that got those rules wrong... -Ilari From nobody Fri Jun 12 07:51: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 43EAB1ACCF5 for ; Fri, 12 Jun 2015 07:51:43 -0700 (PDT) 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_35=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 uX4Zmh0P_yQ4 for ; Fri, 12 Jun 2015 07:51:41 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D02861ACCF3 for ; Fri, 12 Jun 2015 07:51:41 -0700 (PDT) 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 (Postfix) with ESMTPS id 88ABD374A0D; Fri, 12 Jun 2015 14:51:41 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-113.brq.redhat.com [10.34.0.113]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t5CEpecg012417 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 12 Jun 2015 10:51:41 -0400 From: Hubert Kario To: tls@ietf.org Date: Fri, 12 Jun 2015 16:51:35 +0200 Message-ID: <3403191.8nzrJevc4J@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.7 (Linux/4.0.4-202.fc21.x86_64; KDE/4.14.7; x86_64; ; ) In-Reply-To: <201506111558.21577.davemgarrett@gmail.com> References: <201506111558.21577.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1720256.qjcg18W6X8"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Jun 2015 14:51:43 -0000 --nextPart1720256.qjcg18W6X8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Thursday 11 June 2015 15:58:21 Dave Garrett wrote: > Here is a branch with a rough draft of an a la carte handshake algori= thm > negotiation scheme for TLS 1.3, based on discussions on this list. >=20 > https://github.com/davegarrett/tls13-spec/compare/updateciphersuites.= ..daveg > arrett:alacarte >=20 > TL:DR: > * Deprecate all suites with any of: DH, DHE, ECDH, RSA, DSS > * Deployments may continue to offer deprecated suites for TLS 1.0-1.2= > negotiation.=20 > * TLS 1.3 would only negotiate suites prefixed with > ECDHE_ECDSA or ECDHE_PSK.=20 > * TLS 1.3 implementations negotiate ECDHE/DHE & > RSA/DSS/ECDSA solely via the "supported_groups" & "signature_algorith= ms" > extensions.=20 > * No change to bulk cipher negotiation. >=20 > To be clear, this would mean a connection could negotiate usage of a > ECDHE_ECDSA suite and negotiate ECDHE+RSA. It doesn't say anything ab= out > DHE+ECDSA yet, but I think that combination is fine if negotiated. that would require definition of TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 TLS_ECDHE_PSK_WITH_256_GCM_SHA384 to keep parity with already existing TLS_DHE_PSK_* =2D-=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 --nextPart1720256.qjcg18W6X8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJVevH7AAoJEJKo0bgB0vX1S58P/07gdzFds4gWKVrWWyqPo7Xt Az+Hkz98fWgrj+h/9+BmfiqMmGIQlBkvJoKOTvbVcpswMmXLqJeE6MG8f7DFeGDG BQSAOHP1EJNFDaTqTf+yx+BdVSUL8U7vO8NlAhqj8eDErKcWf5AkjrVY42OjIYUh rVixwj6NTBQjBphemFfbu3CzlCO1oyNyzWOGpk4duMA7Indo7KRcu7rURy2X/TBk ozlnNBNJ6gdwNvgIDCkIstM2vLhmb+itxMNsSYFX/OHZfPnBA/+ssYfKzAiz4eRw HxSoiIDGcFxJf7n4ynPr6z0/sf1Ftt4v6U6XxuUTo0GwO5D0zal2Y4MqmRhMhI0Q HMaIfXAs4JAyxgvdGp/8BVmzRjPz1ZWLnJ+cvoOZy5ef/4agV3YKtb4lTy/pqNdd 5teC0UcR65EWMqNH1ami6VrqKmrI66plTIBM65/8X7xLs0n77ao3PFHU878VkzIR gidB76rcfMmsbFYofeFmKi3GUH9DOdCAoIWp/D7JBU7JkE0a4ovh/wJl2GZx7EAw qlI1ocZboRRzpiYtZ5wBs2X0tlQ9bUac+i/vPSkPXtTdrCiLK0Jj3Q3lh/McL5Iu wCjfuyU3fSwzF5f3jwNTI7yor6Z+D/uFzan+KGWj2qTVDwkvJlzHU1nMWCnnlA2g H2kQ50CacUQX0YoY8Ksv =Db+x -----END PGP SIGNATURE----- --nextPart1720256.qjcg18W6X8-- From nobody Fri Jun 12 07:58: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 E82A41ACD36 for ; Fri, 12 Jun 2015 07:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Z4jmgLbYP1zk for ; Fri, 12 Jun 2015 07:58:21 -0700 (PDT) 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 6444F1ACD2F for ; Fri, 12 Jun 2015 07:58:21 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 5690428494C; Fri, 12 Jun 2015 14:58:20 +0000 (UTC) Date: Fri, 12 Jun 2015 14:58:20 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150612145820.GR2050@mournblade.imrryr.org> References: <201506111558.21577.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201506111558.21577.davemgarrett@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] A la carte handshake negotiation 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: Fri, 12 Jun 2015 14:58:23 -0000 On Thu, Jun 11, 2015 at 03:58:21PM -0400, Dave Garrett wrote: > * TLS 1.3 would only negotiate suites prefixed with ECDHE_ECDSA or ECDHE_PSK. Where are anonymous (ADH and AECDH) suites? > * TLS 1.3 implementations negotiate ECDHE/DHE & RSA/DSS/ECDSA solely via > the "supported_groups" & "signature_algorithms" extensions. Why include DSS? It seems rather obsolete, and little used, at this time. -- Viktor. From nobody Fri Jun 12 08: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 24B801A0074 for ; Fri, 12 Jun 2015 08:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lR4zIG0l0Lfw for ; Fri, 12 Jun 2015 08:14:49 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::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 96DBF1A0046 for ; Fri, 12 Jun 2015 08:14:49 -0700 (PDT) Received: by qkhq76 with SMTP id q76so18614455qkh.2 for ; Fri, 12 Jun 2015 08:14:48 -0700 (PDT) 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=9o2vJvb6b52vFZ1QG9MTPPY8dyhtI5uKkxE0eTjX9Mk=; b=HjIRJrTT1SG3x+3PV7waet5cvKXj3pZyoqDvk/jR1rElXEhPxUmpha6xBQ0Ibkj0iz YNmllay1eOfCCGkL2TTGd9A2wIGQ1WdspeJy4FjGMp/ECOMSOlyA30nROMPKCnPxlj6f 4QqwBgPYAHz3Ur8KW834xZQulOSlfyfvBNI5iKHo02bD4wPMtfIBxVDpr0iUXsQsqem5 HSKlv3QxXWJ5se3e9vYRsSqg/qn23z/WcjCFQRSW5++0mK2iRINfTe9B9vn/UdGMipA+ qOlBsf4+Lxrwdi6U+5Pq1O0nSDs9HM/xeuIlxO9EIU7XTeJ76eDav0kguMBaKlgIxfjd 4klA== X-Received: by 10.55.22.167 with SMTP id 39mr2723510qkw.42.1434122088926; Fri, 12 Jun 2015 08:14:48 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id f137sm1768880qhc.41.2015.06.12.08.14.48 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 12 Jun 2015 08:14:48 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Fri, 12 Jun 2015 11:14:47 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201506111558.21577.davemgarrett@gmail.com> <20150612145820.GR2050@mournblade.imrryr.org> In-Reply-To: <20150612145820.GR2050@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201506121114.47527.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Jun 2015 15:14:51 -0000 On Friday, June 12, 2015 10:58:20 am Viktor Dukhovni wrote: > On Thu, Jun 11, 2015 at 03:58:21PM -0400, Dave Garrett wrote: > > * TLS 1.3 would only negotiate suites prefixed with ECDHE_ECDSA or ECDHE_PSK. > > Where are anonymous (ADH and AECDH) suites? Still in the spec. I currently have usage of ECDHE_ECDSA or ECDHE_PSK as a "SHOULD", with "MUST NOT" for the explicitly deprecated bits. Anon is effectively a "SHOULD NOT". I don't think we can have an absolute mandate for only certain prefixes with a "MUST", as that would exclude new ones in the future. (e.g. a post-quantum key exchange will likely want to be negotiated with a separate cipher suite) > > * TLS 1.3 implementations negotiate ECDHE/DHE & RSA/DSS/ECDSA solely via > > the "supported_groups" & "signature_algorithms" extensions. > > Why include DSS? It seems rather obsolete, and little used, at this > time. It's in there because there's no reason to explicitly cut it out completely. This proposal gets rid of all of the DSS cipher suites, however the extension already has DSS/DSA in there. This shifts signature negotiation to the extension; it doesn't actually change the extension. (though, it's possible a change of some kind will be needed) Removing support entirely is outside of the scope of this proposed change. I'm not against restricting/prohibiting its use, if that's the consensus. Dave From nobody Fri Jun 12 08:21: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 403361A036C for ; Fri, 12 Jun 2015 08:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nKTEWgb_pnSO for ; Fri, 12 Jun 2015 08:21:08 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (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 0E8311A0181 for ; Fri, 12 Jun 2015 08:20:18 -0700 (PDT) Received: by qkhg32 with SMTP id g32so18740642qkh.0 for ; Fri, 12 Jun 2015 08:20:17 -0700 (PDT) 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=peYDCYwpuv3vtHroNDM53rIS2WJJCcEtz4xhwAWOm8M=; b=eT3EazbS53kFYTXAtNrEif1XKd8MTycrbzO0kKgjhSGB5vpT9cZTabFTIQU7PHc7l9 imCWBOusydRaXCLb2BHEyyFG1oFCmA7CLmnFeEjPU9uvlyVCwa8C2avAtevpYO98YFGl zi7HUNbjc4wT+y1aNRtkB0C3hfy4QFeCjXLF5Yl9ecdUhR9MsJS50TPjc7xWMskM2IqS r7nddKF3B6gck4sgimCGD9hI0oja5kpTqfSuLlVoG8XWuAQj7syXdl94uxP0Z3q+ljii 3d+16wc2iiI4vASQHcZq/sai1kmf7jaOWQcbbRQzcyxBBeuy7sJzA3LeQ8Vm/EixwwOw gYCw== X-Received: by 10.140.20.150 with SMTP id 22mr19436490qgj.26.1434122417313; Fri, 12 Jun 2015 08:20:17 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id j44sm1796658qgd.28.2015.06.12.08.20.16 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 12 Jun 2015 08:20:16 -0700 (PDT) From: Dave Garrett To: Hubert Kario Date: Fri, 12 Jun 2015 11:20:15 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201506111558.21577.davemgarrett@gmail.com> <3403191.8nzrJevc4J@pintsize.usersys.redhat.com> In-Reply-To: <3403191.8nzrJevc4J@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201506121120.16067.davemgarrett@gmail.com> Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Jun 2015 15:21:09 -0000 On Friday, June 12, 2015 10:51:35 am Hubert Kario wrote: > that would require definition of > TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 > TLS_ECDHE_PSK_WITH_256_GCM_SHA384 > > to keep parity with already existing TLS_DHE_PSK_* Yes, all PSK would need ECDHE suites specified to be used with TLS 1.3+ under this proposal, as-is. I think that would in general already be desired for PSK use-cases. Dave From nobody Fri Jun 12 08:23: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 CF4341A00E7 for ; Fri, 12 Jun 2015 08:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHmEu3kMmbaD for ; Fri, 12 Jun 2015 08:23:02 -0700 (PDT) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (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 8DD821A0052 for ; Fri, 12 Jun 2015 08:23:02 -0700 (PDT) Received: by qgep100 with SMTP id p100so12502299qge.3 for ; Fri, 12 Jun 2015 08:23:01 -0700 (PDT) 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=BN4lyK87TMdu/+G8xGZTec4/j2yVDjVtUUBdnM4n5YQ=; b=x/WKfhLdMShaFH9VfFPu6EWPLJa2Nm70qxT+0ydrLtg2IM9vBTc+UPlBIwpXHa3+Gp r25JyO5m/LBOX507bKmumUUeeiWfniNIgVdXPSsUhVk/Hb1MTwPZ4PJ4Hg94LOMqoP4y 0NrVBvowt/v89PZ+wFGdIl23u6eBj+h11vGKatmkliArQIHDiR+foEPpgyRxwI4TEYzg tz3Hipp+BHDfcInP7Qs79JL+CLPf2ojQrfQk0k7sloC3LmBTnpiMTQg9vm7OZ9OGaA88 AhgfAXbZORb0rgRr2OYBhVx7Zi0yjmK4dp8lFr9N7LA3WdvQTZFky/TNFSu/gvbQadkF FcoQ== X-Received: by 10.140.95.204 with SMTP id i70mr18643985qge.51.1434122581881; Fri, 12 Jun 2015 08:23:01 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id 139sm1780484qhx.22.2015.06.12.08.23.01 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 12 Jun 2015 08:23:01 -0700 (PDT) From: Dave Garrett To: Ilari Liusvaara Date: Fri, 12 Jun 2015 11:23:00 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201506111558.21577.davemgarrett@gmail.com> <20150612083153.GA24990@LK-Perkele-VII> In-Reply-To: <20150612083153.GA24990@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201506121123.00732.davemgarrett@gmail.com> Archived-At: Cc: "" Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Jun 2015 15:23:04 -0000 On Friday, June 12, 2015 04:31:53 am Ilari Liusvaara wrote: > On Thu, Jun 11, 2015 at 03:58:21PM -0400, Dave Garrett wrote: > > 6) No more confusing double negotiation of signature algorithms. Just extensions, instead of many suites and extensions. > > Also, there is no "double negotiation" in TLS 1.2 either. TLS 1.2 is > quite clear about interaction of signature algorithms in ciphersuites > and explicit signature negotiation (explicit negotiation always takes > percedence). One of the two takes precedence, yes, but there's still two. > Of course, I wouldn't be surprised if there was fair bit of software > that got those rules wrong... I'd be surprised if there wasn't. :/ Dave From nobody Fri Jun 12 08: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 AECE61A0338 for ; Fri, 12 Jun 2015 08:23:49 -0700 (PDT) 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 P99qDnsnV3hW for ; Fri, 12 Jun 2015 08:23:48 -0700 (PDT) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (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 D1E941A0218 for ; Fri, 12 Jun 2015 08:23:47 -0700 (PDT) Received: by wgv5 with SMTP id 5so27162511wgv.1 for ; Fri, 12 Jun 2015 08:23:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=XkIEyyUC+6NpCqz967vJix1D1wXPGt2Z3tQFG0bTs0c=; b=EdGgiwpn61PCWiDcQYQ0I3+Ec2Wr2567VAcCrCsNXIAy+xeh74Zg81T2gXOsFxCdVp ywWGRakpUODf5lWjHdLjNc0wFKTVq//rjP1zgYrUU1Bug12EZ5fDLhPEZ8/9661t/8vX KVERGpp5X0X6lD/btoLtQ4IF8vGIHqdU3AXpp7V1QbfERb6yv5NfbHQR4mhes+wPO0HQ vy+HPAD8KRnqeTICwIBA+ieKA3o+y7UZvRMV0rYcvNrw0zEaENJbVwzwaz5YHXJCDvAe oSDr0MbP8+cunf68Ut478MmSws/y26cgSvwN4IDQSH7llNdYhcrNDZ8Ifg/K5yH6Uq6F RG0A== X-Gm-Message-State: ALoCoQkL+42Ydd3Nc82pbUBEe4tHDgYDdiv0eIWGIt+Xu5mYnYIalciqnn2+PCStNTJV3B4jNdY0 X-Received: by 10.180.99.39 with SMTP id en7mr7941991wib.31.1434122626588; Fri, 12 Jun 2015 08:23:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.225.14 with HTTP; Fri, 12 Jun 2015 08:23:06 -0700 (PDT) In-Reply-To: <201506121120.16067.davemgarrett@gmail.com> References: <201506111558.21577.davemgarrett@gmail.com> <3403191.8nzrJevc4J@pintsize.usersys.redhat.com> <201506121120.16067.davemgarrett@gmail.com> From: Eric Rescorla Date: Fri, 12 Jun 2015 11:23:06 -0400 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=f46d04182808b8f277051853b1f9 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Jun 2015 15:23:49 -0000 --f46d04182808b8f277051853b1f9 Content-Type: text/plain; charset=UTF-8 On Fri, Jun 12, 2015 at 11:20 AM, Dave Garrett wrote: > On Friday, June 12, 2015 10:51:35 am Hubert Kario wrote: > > that would require definition of > > TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 > > TLS_ECDHE_PSK_WITH_256_GCM_SHA384 > > > > to keep parity with already existing TLS_DHE_PSK_* > > Yes, all PSK would need ECDHE suites specified to be used with TLS 1.3+ > under this proposal, as-is. I think that would in general already be > desired for PSK use-cases. Sorry, do you mean that you couldn't use PSK without a public key key exchange? If so that's not going to work. -Ekr > > Dave > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --f46d04182808b8f277051853b1f9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jun 12, 2015 at 11:20 AM, Dave Garrett <davemgarrett@gmai= l.com> wrote:
On Friday, June 12, 2015 10:51:35 am Hubert Kario wrote:
> that would require definition of
> TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256
> TLS_ECDHE_PSK_WITH_256_GCM_SHA384
>
> to keep parity with already existing TLS_DHE_PSK_*

Yes, all PSK would need ECDHE suites specified to be used with TLS 1= .3+ under this proposal, as-is. I think that would in general already be de= sired for PSK use-cases.

Sorry, do you mean= that you couldn't use PSK without a public key key exchange?
If so that's not going to work.

-Ekr
=C2=A0

Dave

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

--f46d04182808b8f277051853b1f9-- From nobody Fri Jun 12 08: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 496FA1A1A02 for ; Fri, 12 Jun 2015 08:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 i_xgSYuoAitr for ; Fri, 12 Jun 2015 08:38:46 -0700 (PDT) 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 B2B891A1A8B for ; Fri, 12 Jun 2015 08:38:06 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id A1BF728494C; Fri, 12 Jun 2015 15:38:05 +0000 (UTC) Date: Fri, 12 Jun 2015 15:38:05 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150612153805.GS2050@mournblade.imrryr.org> References: <201506111558.21577.davemgarrett@gmail.com> <20150612145820.GR2050@mournblade.imrryr.org> <201506121114.47527.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201506121114.47527.davemgarrett@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] A la carte handshake negotiation 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: Fri, 12 Jun 2015 15:38:48 -0000 On Fri, Jun 12, 2015 at 11:14:47AM -0400, Dave Garrett wrote: > > > * TLS 1.3 would only negotiate suites prefixed with ECDHE_ECDSA or ECDHE_PSK. > > > > Where are anonymous (ADH and AECDH) suites? > > Still in the spec. I currently have usage of ECDHE_ECDSA or ECDHE_PSK as > a "SHOULD", with "MUST NOT" for the explicitly deprecated bits. Anon is > effectively a "SHOULD NOT". I don't think we can have an absolute mandate > for only certain prefixes with a "MUST", as that would exclude new ones > in the future. (e.g. a post-quantum key exchange will likely want to be > negotiated with a separate cipher suite) Just to confirm, it will be possible to negotiate AECDH and ADH key exchange ala carte, separately from the bulk cipher, right? -- Viktor. From nobody Fri Jun 12 08:40: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 D4B801A1A32 for ; Fri, 12 Jun 2015 08:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxCdPHxJXZ-A for ; Fri, 12 Jun 2015 08:40:14 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 ADBA31A19E4 for ; Fri, 12 Jun 2015 08:40:06 -0700 (PDT) Received: by qkhq76 with SMTP id q76so18912637qkh.2 for ; Fri, 12 Jun 2015 08:40:06 -0700 (PDT) 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=IeNaXA6hwXhnuvTNfhojsnnH1vGKdiG6jQZ8nNF4Ijw=; b=aUq8Z+6B+jkjbYUJFcYgk0eG998C+DRbNeOLu5xTunq9vd6O07jhHc6EgJQAO95qYy +V0aWVVRR/QchpLStm7SQtERMu0ocRkK3/AVOt1mFV43G9VEwXChjGdkU+iZcix07iUg icSFeJHyg1D6BcbeJQdYus1O+IiTszKOAFZ/EQc3GEjG0MLCogV+aLfzBePayMj7zmoh vj/P4V/Kn8yZM7/A6DoXyjfhAWzcj0mk6x1IEBU3HEaKsosfCSWJC7EsqnWSut9J97ks BmyHQ25hL5HxmpyeWGEvW2Dv5kHoTYaZMR0y7zb8UgtffxZBDAL2rX2tDNzlPN/FDVn3 mvtw== X-Received: by 10.55.40.42 with SMTP id o42mr31772906qkh.73.1434123606010; Fri, 12 Jun 2015 08:40:06 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id a15sm1821516qge.3.2015.06.12.08.40.05 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 12 Jun 2015 08:40:05 -0700 (PDT) From: Dave Garrett To: Eric Rescorla Date: Fri, 12 Jun 2015 11:40:04 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201506111558.21577.davemgarrett@gmail.com> <201506121120.16067.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201506121140.04897.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Jun 2015 15:40:16 -0000 On Friday, June 12, 2015 11:23:06 am Eric Rescorla wrote: > On Fri, Jun 12, 2015 at 11:20 AM, Dave Garrett > wrote: > > On Friday, June 12, 2015 10:51:35 am Hubert Kario wrote: > > > that would require definition of > > > TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 > > > TLS_ECDHE_PSK_WITH_256_GCM_SHA384 > > > > > > to keep parity with already existing TLS_DHE_PSK_* > > > > Yes, all PSK would need ECDHE suites specified to be used with TLS 1.3+ > > under this proposal, as-is. I think that would in general already be > > desired for PSK use-cases. > > Sorry, do you mean that you couldn't use PSK without a public key key > exchange? If so that's not going to work. There's nothing explicitly prohibiting that in my proposal. TLS_DHE_PSK would need a TLS_ECDHE_PSK, but plain TLS_PSK is a separate issue. It's be effectively a "SHOULD NOT", though there was discussion of a separate application profile for IoT and the like which could say otherwise. Dave From nobody Fri Jun 12 08:45: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 602A71A1A6D for ; Fri, 12 Jun 2015 08:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V90guJfLUXpa for ; Fri, 12 Jun 2015 08:45:52 -0700 (PDT) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) (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 8A2821A1A6E for ; Fri, 12 Jun 2015 08:45:41 -0700 (PDT) Received: by qcjl8 with SMTP id l8so11729801qcj.3 for ; Fri, 12 Jun 2015 08:45:40 -0700 (PDT) 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=ICldv/y7tP0mKKFXrBbobsLV9WkL0EPd2WdjlNSgysU=; b=McUzSRlaO6jwSZ22+Upg0oTg3GRmWxCXq9ndY/aCSZ2bJdpBCFb8U4GfTAW8L/N6Mz NJR2W3tQmtSFgjboADENruOKvt+vwPWKYgQxmSYHevWx1zeGDxMTmuVO2m269AeicChF cqcyw7jK0IAAelYgwBMkMsyqc55QCHhi2mnvmwtCrtM+ItQJ/bFH7M4dIYrMqrZw2rZj YZ0MvfxCuPxUyFS8931NS2c/n7RYTKD37Ay2DZ2yl2UQkeg6rHQckXfZLQYtJv0jFmrg ewfLrsA0b/ly43ZDoOVdsuYPPuhCf9UokhdHhacG9qPrlXcXbbcRpzxgKc5Upvqf2PZh Ow2Q== X-Received: by 10.140.235.71 with SMTP id g68mr19742565qhc.41.1434123940882; Fri, 12 Jun 2015 08:45:40 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id b29sm1815403qkb.33.2015.06.12.08.45.40 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 12 Jun 2015 08:45:40 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Fri, 12 Jun 2015 11:45:38 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201506111558.21577.davemgarrett@gmail.com> <201506121114.47527.davemgarrett@gmail.com> <20150612153805.GS2050@mournblade.imrryr.org> In-Reply-To: <20150612153805.GS2050@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201506121145.39429.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Jun 2015 15:45:53 -0000 On Friday, June 12, 2015 11:38:05 am Viktor Dukhovni wrote: > On Fri, Jun 12, 2015 at 11:14:47AM -0400, Dave Garrett wrote: > > > > * TLS 1.3 would only negotiate suites prefixed with ECDHE_ECDSA or ECDHE_PSK. > > > > > > Where are anonymous (ADH and AECDH) suites? > > > > Still in the spec. I currently have usage of ECDHE_ECDSA or ECDHE_PSK as > > a "SHOULD", with "MUST NOT" for the explicitly deprecated bits. Anon is > > effectively a "SHOULD NOT". I don't think we can have an absolute mandate > > for only certain prefixes with a "MUST", as that would exclude new ones > > in the future. (e.g. a post-quantum key exchange will likely want to be > > negotiated with a separate cipher suite) > > Just to confirm, it will be possible to negotiate AECDH and ADH > key exchange ala carte, separately from the bulk cipher, right? Sure, no reason why it couldn't be negotiated via the extension for anon. It's not addressed in my draft for this proposal, but that seems like it should be the case. Applying the same logic, only ECDH_anon would be valid as a suite for TLS 1.3+, but EC/FF would be negotiated via the extension. Dave From nobody Fri Jun 12 08:53: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 818BE1A1B1B for ; Fri, 12 Jun 2015 08:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 9omc8MPzUrxG for ; Fri, 12 Jun 2015 08:53:13 -0700 (PDT) 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 BC2561A1AC6 for ; Fri, 12 Jun 2015 08:53:13 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 68137284B67; Fri, 12 Jun 2015 15:53:12 +0000 (UTC) Date: Fri, 12 Jun 2015 15:53:12 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150612155312.GU2050@mournblade.imrryr.org> References: <201506111558.21577.davemgarrett@gmail.com> <201506121114.47527.davemgarrett@gmail.com> <20150612153805.GS2050@mournblade.imrryr.org> <201506121145.39429.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201506121145.39429.davemgarrett@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] A la carte handshake negotiation 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: Fri, 12 Jun 2015 15:53:15 -0000 On Fri, Jun 12, 2015 at 11:45:38AM -0400, Dave Garrett wrote: > > Just to confirm, it will be possible to negotiate AECDH and ADH > > key exchange ala carte, separately from the bulk cipher, right? > > Sure, no reason why it couldn't be negotiated via the extension for anon. > It's not addressed in my draft for this proposal, but that seems like it > should be the case. Applying the same logic, only ECDH_anon would be valid > as a suite for TLS 1.3+, but EC/FF would be negotiated via the extension. That would be great. Please add it to the draft if/when possible. Right now, there are many "missing" combinations of AECDH with more modern bulk ciphers. If AECDH/ADH key exchange becomes ala carte, then the problem is solved (for TLS 1.3). -- Viktor. From nobody Fri Jun 12 09:13: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 2CDC81A6EE8 for ; Fri, 12 Jun 2015 09:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LU0mOsVCmIP for ; Fri, 12 Jun 2015 09:13:04 -0700 (PDT) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) (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 7135D1A6F30 for ; Fri, 12 Jun 2015 09:13:04 -0700 (PDT) Received: by qcnj1 with SMTP id j1so11964647qcn.0 for ; Fri, 12 Jun 2015 09:13:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:message-id; bh=RSB5a3GO1OjNq4n5QqS49Mwv34GbNX5gLIhZjp4m43U=; b=G3tdFrf/vn/UvzHjf48xU/oKcne6CvUYuhCu2rJewyhGGFn1crBQHSyoSUwHJn+AYc H1MN0xidWUZ0m9au98Atu96bUY/tPVCYdtBXsiBQDJrBcU7vzudjmiwD0eB6/bzUOjJ3 p6vRqGYcINm8biYPmfxbBZvhJ5uIK2UZOP0rWZ4LIHW8yEsDk0zKcibY0qdVh5OdcLWr jDcKTIJbAu2TOAfjQSXIVraxycZZ/7KPJc6lm1hqJzaSenB88MS6cF3eES7Y/wYsYHO1 6hDtIGqdIXx4ekiuIlBxI/KbkcpwJXdYhNY6J5oFqZYtDG3bUfLbC9UuY15gBrFjRF1U a5gg== X-Received: by 10.55.23.7 with SMTP id i7mr32103131qkh.26.1434125583721; Fri, 12 Jun 2015 09:13:03 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id n132sm1838430qhb.12.2015.06.12.09.13.03 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 12 Jun 2015 09:13:03 -0700 (PDT) From: Dave Garrett To: "" Date: Fri, 12 Jun 2015 12:13:02 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201506111558.21577.davemgarrett@gmail.com> In-Reply-To: <201506111558.21577.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201506121213.02446.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Jun 2015 16:13:06 -0000 On Thursday, June 11, 2015 03:58:21 pm Dave Garrett wrote: > Here is a branch with a rough draft of an a la carte handshake algorithm negotiation scheme for TLS 1.3, based on discussions on this list. > > https://github.com/davegarrett/tls13-spec/compare/updateciphersuites...davegarrett:alacarte > > * TLS 1.3 would only negotiate suites prefixed with ECDHE_ECDSA or ECDHE_PSK. The wording in my summary appears to have been not precise enough. Quoting what's in the full draft, at the moment: ============================== In TLS 1.3, the semantics of the handshake portion of cipher suites SHALL be interpreted as indicative of the newest standardized algorithm which is supported, rather than indicative of an exact combination which is offered. All implementations of this specification SHOULD only negotiate the usage of cipher suites with a handshake portion of "ECDHE_ECDSA" or "ECDHE_PSK". Implementations MUST NOT negotiate the usage of cipher suites with a "KEA" of "DHE", "DH", or "ECDH". Implementations MUST NOT negotiate the usage of cipher suites with a "SIGN" of "RSA" or "DSS", including cipher suites which do not have separate "KEA" and "SIGN" components. ============================== "KEA", "SIGN", and "handshake portion" are defined in the same section as part of a generalized description of the de facto suite naming convention. This draft is based on PR #180, which doesn't change any spec/policy; just updates the section. A link to the current draft of this in full, rather than just the changes: https://github.com/davegarrett/tls13-spec/blob/alacarte/draft-ietf-tls-tls13.md#cipher-suites So, to be more clear (repeating what I clarified in replies to specific questions): in cipher suites: ECDHE_ECDSA or ECDHE_PSK -> SHOULD (not proposing a MUST, here) DHE, DH, ECDH, RSA, DSS -> MUST NOT this does not preclude the allowance of: plain PSK anon anything fundamentally new (e.g. post-quantum key exchange) something else obscure, but not generally recommended The goal here is to collapse the zoo of older suites under a small set of valid ones for TLS 1.3, and use the existing extensions to negotiate those capabilities instead. Actually dropping capabilities is not part of this, so even if doing so might be warranted, it would be part of another changeset and not this. As separately replied to Viktor, yes, the anon issue needs updating in the draft. It might even be warranted to use only DH_anon suites instead of ECDH_anon due to its more widespread use. This would allow usage of ECC without having to specify any new ECDH_anon suites for those lacking them but already having DH_anon suites. Dave From nobody Fri Jun 12 09:22: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 AFFC71A8ACB for ; Fri, 12 Jun 2015 09:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 We7q4iGWa_E6 for ; Fri, 12 Jun 2015 09:22:38 -0700 (PDT) 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 15C771A891D for ; Fri, 12 Jun 2015 09:22:38 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 2C1D428494C; Fri, 12 Jun 2015 16:22:37 +0000 (UTC) Date: Fri, 12 Jun 2015 16:22:37 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150612162236.GW2050@mournblade.imrryr.org> References: <201506111558.21577.davemgarrett@gmail.com> <201506121213.02446.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201506121213.02446.davemgarrett@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] A la carte handshake negotiation 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: Fri, 12 Jun 2015 16:22:39 -0000 On Fri, Jun 12, 2015 at 12:13:02PM -0400, Dave Garrett wrote: > It might even be warranted to use only DH_anon suites instead > of ECDH_anon due to its more widespread use. This would allow usage of > ECC without having to specify any new ECDH_anon suites for those lacking > them but already having DH_anon suites. I'm afraid I don't understand the above. Also AECDH (ECDH_anon) is not particularly rare: Jun 12 15:48:16 mournblade postfix/smtpd[25717]: Anonymous TLS connection established from xmpp.openssl.org[194.97.150.230]: TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits) Jun 12 15:49:59 mournblade postfix/smtpd[10257]: Anonymous TLS connection established from xmpp.openssl.org[194.97.150.230]: TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits) Jun 12 15:53:13 mournblade postfix/smtp[4626]: Anonymous TLS connection established to mail.ietf.org[4.31.198.44]:25: TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits) Jun 12 15:53:17 mournblade postfix/smtpd[29043]: Anonymous TLS connection established from mail.ietf.org[4.31.198.44]: TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits) Jun 12 16:01:15 mournblade postfix/smtpd[7342]: Anonymous TLS connection established from xmpp.openssl.org[194.97.150.230]: TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits) Jun 12 16:05:29 mournblade postfix/smtpd[21581]: Anonymous TLS connection established from xmpp.openssl.org[194.97.150.230]: TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits) Jun 12 16:07:14 mournblade postfix/smtpd[23383]: Anonymous TLS connection established from xmpp.openssl.org[194.97.150.230]: TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits) Jun 12 16:08:56 mournblade postfix/smtpd[23383]: Anonymous TLS connection established from xmpp.openssl.org[194.97.150.230]: TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits) Jun 12 16:09:47 mournblade postfix/smtpd[23383]: Anonymous TLS connection established from xmpp.openssl.org[194.97.150.230]: TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits) Jun 12 16:13:08 mournblade postfix/smtpd[27271]: Anonymous TLS connection established from mail.ietf.org[4.31.198.44]: TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits) -- Viktor. From nobody Fri Jun 12 09:36: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 BF2801A924A for ; Fri, 12 Jun 2015 09:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtg6gkA9ztia for ; Fri, 12 Jun 2015 09:36:22 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (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 864451A923E for ; Fri, 12 Jun 2015 09:36:20 -0700 (PDT) Received: by qkhq76 with SMTP id q76so19558473qkh.2 for ; Fri, 12 Jun 2015 09:36:19 -0700 (PDT) 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=rQtji1fXrVrlKfqPmtM+gzTUF6goXcihD7afGXGVi4o=; b=Jl4HEi/+rUY5wwPWJxuzVJ8AItkSehLiC6W7hSclJbzXUg/k4LIO4h1H0rRNcdP0ey CPSxxAQ7nRgAuFWWLjHBML9lBqLkEPrxKyXvuTiGqR2lkl4KzV47DGA8/dyVBuTpCEVv NPoPwYOkZ1xhmEO2DO/ySvl1ROSGgid8Y5qInUirNVmK/dDZtqNqOz8kyuc9FVPZCoV8 g92qXsgC5eAouq2fYnvLiTiRLrMQxfvY3jDwdWOhGgvFj7hZfqNU0SDmb/rA3tOPtRWV 2U7iEQPQkSH7iCFtUkHJEX3p2snI63p+m8FR/5gU2T7QewVhVPoM3YqKYIUoCj/0M/Q6 z2Zw== X-Received: by 10.55.17.75 with SMTP id b72mr31648897qkh.103.1434126979840; Fri, 12 Jun 2015 09:36:19 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id 67sm1863072qhw.43.2015.06.12.09.36.19 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 12 Jun 2015 09:36:19 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Fri, 12 Jun 2015 12:36:17 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201506111558.21577.davemgarrett@gmail.com> <201506121213.02446.davemgarrett@gmail.com> <20150612162236.GW2050@mournblade.imrryr.org> In-Reply-To: <20150612162236.GW2050@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201506121236.18304.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Jun 2015 16:36:23 -0000 On Friday, June 12, 2015 12:22:37 pm Viktor Dukhovni wrote: > On Fri, Jun 12, 2015 at 12:13:02PM -0400, Dave Garrett wrote: > > It might even be warranted to use only DH_anon suites instead > > of ECDH_anon due to its more widespread use. This would allow usage of > > ECC without having to specify any new ECDH_anon suites for those lacking > > them but already having DH_anon suites. > > I'm afraid I don't understand the above. Also AECDH (ECDH_anon) > is not particularly rare: > > Jun 12 15:48:16 mournblade postfix/smtpd[25717]: Anonymous TLS connection established from xmpp.openssl.org[194.97.150.230]: TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits) Your quote is usage of: TLS_ECDH_anon_WITH_AES_256_CBC_SHA AES CBC already cannot be used with TLS 1.3+, as it now requires AEAD ciphers only. TLS_DH_anon_WITH_AES_256_GCM_SHA384 is in: https://tools.ietf.org/html/rfc5288 TLS_ECDH_anon_WITH_AES_256_GCM_SHA384 is in this expired draft: https://tools.ietf.org/html/draft-williams-tls-anon-ecdh-modern-cipher-01 The current proposal requires all suites for TLS 1.3+ to be the ECC variants, which is not currently doable for anon AES-GCM. What I'm saying is that we could use "DH_anon" suites instead of "ECDH_anon" suites in this scheme. Just properly publishing a "ECDH_anon" RFC would be preferable, however. Dave From nobody Fri Jun 12 09:43: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 1A2E61A1BCC for ; Fri, 12 Jun 2015 09:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4sH7LMCU5kSf for ; Fri, 12 Jun 2015 09:43:30 -0700 (PDT) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (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 C2E191A8774 for ; Fri, 12 Jun 2015 09:43:27 -0700 (PDT) Received: by wifx6 with SMTP id x6so22337819wif.0 for ; Fri, 12 Jun 2015 09:43:26 -0700 (PDT) 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=jgMPcIMjAXxfADTHGqxUUQBbOQGznDUzky7lEerjb1E=; b=RfeCOm/P3Sbe+IYRABzo44Pq8+T7USIweYGfCMpS9B0rYLVd6ELIrRrsF2N+Bw1x5z /Zj8IPQHGbCk1WPWPoAWl7pJzvS1qbDffBTDv/nOomjeCQj/aZmyBzZiJ2bpgSCFd18x FQXqH6RVpBzHQxmUUJJQ/yBaiMMIxMjlx+G2m2KPY/A+y+uwfHmrYt6HqgrbKE1S4TIq Ya70uqQNmPueZmw2oagbgzOc6TmT7YPkf9hest0zcSU6hbThpnWdd2V414yftgBLSmG6 oChepRMAhy0HGVEbAtw4i6PbRXHB06SJyWL+Y4qx7jbVoDRreUsag96YcF2cuIp/1Uhb oKKw== X-Gm-Message-State: ALoCoQmKXBM4LRXu9Zmg9RCfX+HkA5Um4Jq497Rgquf0JqXiBytJEdHSBS9zlyKOhZpFNX/YPowo X-Received: by 10.194.192.33 with SMTP id hd1mr27384205wjc.96.1434127406537; Fri, 12 Jun 2015 09:43:26 -0700 (PDT) Received: from [10.0.0.142] (chello080108032135.14.11.univie.teleweb.at. [80.108.32.135]) by mx.google.com with ESMTPSA id ef10sm6616109wjd.49.2015.06.12.09.43.24 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Jun 2015 09:43:25 -0700 (PDT) Message-ID: <557B0C29.50803@azet.org> Date: Fri, 12 Jun 2015 18:43:21 +0200 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Dave Garrett References: <201506111558.21577.davemgarrett@gmail.com> In-Reply-To: <201506111558.21577.davemgarrett@gmail.com> X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigEE6F60FA606E54D3C21691C6" Archived-At: Cc: "" Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Jun 2015 16:43:32 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEE6F60FA606E54D3C21691C6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dave Garrett wrote: > Here is a branch with a rough draft of an a la carte handshake algorith= m negotiation scheme for TLS 1.3, based on discussions on this list. >=20 > https://github.com/davegarrett/tls13-spec/compare/updateciphersuites...= davegarrett:alacarte >=20 I'm supportive in general, let's see how this turns out. Not surprising though will be that I noticed additional CCM cipher-suites, as I currently have a draft on OCB mode I'm not really supportive of that. There should be a block-cipher mode that also offers considerable performance for non-AESNI architectures - CCM was introduced because of patents on OCB, we seem to have resolved this issue by now. At least for TLS. DSS should be dropped. And I figure that a PSK handshake (TLS_PSK_*) will be required by the embedded/IoT world, as noted by others before. Aaron --------------enigEE6F60FA606E54D3C21691C6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVewwqAAoJEOTbZJL9ubXVZwUP/20m3O9uoJMmnVZ4iPPrpv9r GTL4WGUS8PI2RLSD0qveL+vSe5hh25mAKkBapgmRn/Xhh6of0o0Veu6KOjEdqOz/ BqbsbMghMd/zyYLtPwCCnXOc6zA3eGUBTCK4Mrmc0lYw5q68xx1haWDjdgJGE8rU cVyXQwRjZz5XRfHYnL0COzi2y0sR77rKHMGldMy07w7mzflqA8RBBPR1ZlOn+gy/ JjKwjzY25t+qvZz9Mrag/3tN4j/OiJOiRHWtzi8Gq1+OxP5eJOgtv9728L/LJjva YbRd9tmYeEZX6JBGvK/kv+AhGTJAsBd3O4fsSy32ZjDmwkPZoYHKVyXE5b9fCLzx RCzDvO5rIWlQgoVujyWe03OEBpmN7MEEaVlaZOd0EaRVsc/kbLYCaV0Mj0xLdDsr e+d20FyPh3vaDPd7HKIv/XOc9bqtHQRIpdWz1CSM+nWUlrq06TkPBjPzcA96MYpG grzTIu0VJbRYl4gU63AErtdkgrOfLOMn6U7PxAjyEwMPZSNX3bkj+khII9YNer0I QzAHIEPjiLyRURiUaxg85cpylivl4/8sVzFM20yIlsECa4c2BF8qmH5W8wDlfX6P duQE4wr621BS6sRKon4W3+VwrR3jFeluVNYyWyFSvdRsdxlmGQzNQFJ6XMDMH8HV s+OBrBNXQ99/5K+VVQdb =8iE9 -----END PGP SIGNATURE----- --------------enigEE6F60FA606E54D3C21691C6-- From nobody Fri Jun 12 09:46: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 A290C1A87A3 for ; Fri, 12 Jun 2015 09:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecblFEc2wILs for ; Fri, 12 Jun 2015 09:46:37 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 C0C7F1A8789 for ; Fri, 12 Jun 2015 09:46:37 -0700 (PDT) Received: by qkhq76 with SMTP id q76so19668642qkh.2 for ; Fri, 12 Jun 2015 09:46:37 -0700 (PDT) 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=qEUxL7wU8QZKJkfcP3wIqZdIeUQmsaKgG8wcdzCvRgM=; b=UD/w9q+HI2eSRYSNC0zlYXNL6H9cYquAnj66uDo/s+5fct7LbIgFkGv0lgJ8g4r4Nx oPrskfcXHrtxjuRv2ZGV1H0kkS/ESTIpA2yA7YWUzHc458qAgsSKqJ/satNEXRVV9scz g7iszuQTBOAFOA/J7QdujkHuWqQaWEWnzG+KsEzpzWzNeU9C36M7QQtyqtTuZMbT4V7A QFNYHTSAqUDp0vOtZKJpVtijf5CBPBRbHSfwrOxHZWFwU/RYMO4zbnui+nc4SXOqOXqq O/UpTWIz6344DeoeZVM2bjSDjknTA5Us3/5wosqyqBWdlKvGkC8qklVh8GsjNSEXy50b D4rg== X-Received: by 10.140.92.173 with SMTP id b42mr19963537qge.54.1434127596971; Fri, 12 Jun 2015 09:46:36 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id i7sm1898025qge.32.2015.06.12.09.46.36 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 12 Jun 2015 09:46:36 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Fri, 12 Jun 2015 12:46:35 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201506111558.21577.davemgarrett@gmail.com> <20150612162236.GW2050@mournblade.imrryr.org> <201506121236.18304.davemgarrett@gmail.com> In-Reply-To: <201506121236.18304.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201506121246.35396.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Jun 2015 16:46:39 -0000 To preemptively answer a simple alternate idea for anon negotiation, no, it can't be negotiated via the extension. It needs its own cipher suites. TLS 1.2 spec section 7.4.1.4.1: Signature Algorithms https://tools.ietf.org/html/rfc5246#section-7.4.1.4.1 > The "anonymous" value is meaningless in this context but used in > Section 7.4.3. It MUST NOT appear in this extension. As this extension must be sent from clients to servers of unknown versions, changing this requirement is probably a bad idea. Dave From nobody Fri Jun 12 09:50: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 162C61A8904 for ; Fri, 12 Jun 2015 09:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mxzb3DaPvUhd for ; Fri, 12 Jun 2015 09:50:48 -0700 (PDT) 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 6E1561ABD3B for ; Fri, 12 Jun 2015 09:50:26 -0700 (PDT) Received: by wifx6 with SMTP id x6so22472723wif.0 for ; Fri, 12 Jun 2015 09:50:25 -0700 (PDT) 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=4RAoRMerE5EPZ62M0oprn9En3ozi9jPpvEAY7i5GcSg=; b=FbQGcnM5blHJvlwrUI6cnjNuk0B/Iq5CdAVSs04gJjWELtv7gm33tEjKz5i2bteUAb OXE8Ff0Gnj0K9UHPslDbyDQUOTHo89Ha9Nylq/lo831W1O4Wiyef6qmjNa9lM3poHfMP M6KfKKRyYzT04OrtJzNrIEdzOGlSpmxn/F78eHwuwlNzhQs1BIA2yfiExJ5tV5YfnFB1 i8V9OXlLmvJAkZvHceRwDY2vDp2w+azT+acrKBBn44J7GsXB96wZGpklho/60srDefVY joRVn0Hm04HYal1jPlLYsjVjQX3e7qNwWO1Htp2DcumhfIrRmNBt7Hq9hnmCxD8DI48k I4Og== X-Gm-Message-State: ALoCoQnyEleB85UeRv+zOiyM96973p1wWFIhZURHGJuaIOQe7WoadSR4zMsBO+0r3KdfDKsIYxAY X-Received: by 10.180.38.68 with SMTP id e4mr8641216wik.32.1434127825220; Fri, 12 Jun 2015 09:50:25 -0700 (PDT) Received: from [10.0.0.142] (chello080108032135.14.11.univie.teleweb.at. [80.108.32.135]) by mx.google.com with ESMTPSA id ny7sm3555395wic.11.2015.06.12.09.50.23 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Jun 2015 09:50:24 -0700 (PDT) Message-ID: <557B0DCC.5010202@azet.org> Date: Fri, 12 Jun 2015 18:50:20 +0200 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Dave Garrett References: <201506111558.21577.davemgarrett@gmail.com> <557B0C29.50803@azet.org> In-Reply-To: <557B0C29.50803@azet.org> X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig3E815E25A15C92F4CD122F64" Archived-At: Cc: "" Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Jun 2015 16:50:50 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3E815E25A15C92F4CD122F64 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Aaron Zauner wrote: >=20 > Dave Garrett wrote: >> Here is a branch with a rough draft of an a la carte handshake algorit= hm negotiation scheme for TLS 1.3, based on discussions on this list. >> >> https://github.com/davegarrett/tls13-spec/compare/updateciphersuites..= =2Edavegarrett:alacarte >> >=20 > I'm supportive in general, let's see how this turns out. Not surprising= > though will be that I noticed additional CCM cipher-suites, as I > currently have a draft on OCB mode I'm not really supportive of that. > There should be a block-cipher mode that also offers considerable > performance for non-AESNI architectures - CCM was introduced because of= > patents on OCB, we seem to have resolved this issue by now. At least fo= r > TLS. =2E.also why include both the cipher-suite with the 8-bit auth. tag and the 16-bit tag? I found this particularly confusing with the CCM draft, which is why I decided not to go for two different tag sizes. Aaron --------------enig3E815E25A15C92F4CD122F64 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVew3MAAoJEOTbZJL9ubXVU1QQAMr8v4WWJfXSm+yeon6l7y4I LUrS2dhzozZ9aPldczIpyZWaWlQkkDPl1jrLeaFcsnZaZA20kNGmJ0TLaso3tjTQ DdBtzyPJ+lrdz1l+2xb/JvccITsXAlKSO6tIUAI77bz7B3zNs7K9D/5EMUzcmIur PsECJsOEa4bvZ/6Y3mNfncFVA2WQdE8Tsna3/PNki11jON+Sd5KzkQbHv28YNUtl uy2uLqFffrDtCA1K9fzCMOe9OT2o912ZRsYb4bVmufncV49o0Wv8hlEf3A8SliQE haJQmPx7686KwRVUC6ZdlxYih32u0xmpYSSoCqW+49CkSd1rpY5ko92x4kcnoy0S pFoONbp3cGzojw72ZQEPtL633Aum+4HF1zV6ZcaSxG3RdQBiIjXGmlKCoEsOpMrJ yeaqeurCb1f4iAy5AllR3QGh2QjMqcoEOWHGguZi/BVSIXqn1khHM5WWppcNVEgB /LGADSHJC3whxVtQEUpWHRQNRUGpeZRV1fCdaP2Q+DO9L6LU5oJF9e0RAo6qc3EK NXcjL2/A9X8QHEnzlgySYqZEfsJjZZ9aNzX2b5/x5ZwTYxoa3H2P/Rxti3cukZGi 1VMede3sY3jkB2jler9i8U2h2pUxCN8j8tyxJcoE3pXkdmAQb7TVGhcWmUL18aC5 NTeTOXXt+4r5bjDJjEDM =GBa9 -----END PGP SIGNATURE----- --------------enig3E815E25A15C92F4CD122F64-- From nobody Fri Jun 12 09:56: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 BCCB71AC438 for ; Fri, 12 Jun 2015 09:56:01 -0700 (PDT) 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, J_CHICKENPOX_22=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_25=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_66=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 K-6q4R5vvHhH for ; Fri, 12 Jun 2015 09:56:00 -0700 (PDT) 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 231861AC3FD for ; Fri, 12 Jun 2015 09:56:00 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 0B8FF28494C; Fri, 12 Jun 2015 16:55:59 +0000 (UTC) Date: Fri, 12 Jun 2015 16:55:59 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150612165558.GZ2050@mournblade.imrryr.org> References: <201506111558.21577.davemgarrett@gmail.com> <201506121213.02446.davemgarrett@gmail.com> <20150612162236.GW2050@mournblade.imrryr.org> <201506121236.18304.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201506121236.18304.davemgarrett@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] A la carte handshake negotiation 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: Fri, 12 Jun 2015 16:56:01 -0000 On Fri, Jun 12, 2015 at 12:36:17PM -0400, Dave Garrett wrote: > > I'm afraid I don't understand the above. Also AECDH (ECDH_anon) > > is not particularly rare: > > > > Jun 12 15:48:16 mournblade postfix/smtpd[25717]: Anonymous TLS connection established from xmpp.openssl.org[194.97.150.230]: TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits) > > Your quote is usage of: > TLS_ECDH_anon_WITH_AES_256_CBC_SHA > > AES CBC already cannot be used with TLS 1.3+, as it now requires AEAD ciphers only. Indeed, there are at present no ciphersuite codepoints for AECDH with AEAD. That's why I'd like to see improvement in this space. If the bulk cipher were negotiated separately, I'd expect that I'd get the missing combinations "for free". $ openssl version OpenSSL 1.0.2a-dev xx XXX xxxx $ openssl ciphers -v AESGCM+kEDH DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(256) Mac=AEAD DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD ADH-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=None Enc=AESGCM(256) Mac=AEAD DHE-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(128) Mac=AEAD DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD ADH-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=None Enc=AESGCM(128) Mac=AEAD $ openssl ciphers -v AESGCM+kECDHE ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD The DH AEAD ciphersuite set includes two DH_anon members. For ECDH AEAD there are none. > TLS_ECDH_anon_WITH_AES_256_GCM_SHA384 is in this expired draft: > https://tools.ietf.org/html/draft-williams-tls-anon-ecdh-modern-cipher-01 Yes, I asked Nico to help fill the gap. I guess this did not go very far. > The current proposal requires all suites for TLS 1.3+ to be the ECC > variants, which is not currently doable for anon AES-GCM. What I'm saying > is that we could use "DH_anon" suites instead of "ECDH_anon" suites in > this scheme. Just properly publishing a "ECDH_anon" RFC would be preferable, > however. I still don't understand preclude as a matter of principle negotiation of ECDH_anon with AEAD if DH_anon with the same bulk cipher would be allowed. Once we have separate negotiation of the key exchange, surely ECDH_anon can be one of the supported key exchange variants, and then take advantage of all the available bulk ciphersuites. Or does this proposal simply compress the client HELLO message, but the server is still ultimately selecting the same all-in-one ciphersuite (thus requiring Nico's new code points for ECDH_anon with AEAD)? -- Viktor. From nobody Fri Jun 12 10:00: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 4B1A41ACD10 for ; Fri, 12 Jun 2015 10:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4apsq7QcnupC for ; Fri, 12 Jun 2015 10:00:02 -0700 (PDT) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) (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 85D9D1ACCFE for ; Fri, 12 Jun 2015 10:00:02 -0700 (PDT) Received: by qcbfb9 with SMTP id fb9so3400142qcb.1 for ; Fri, 12 Jun 2015 10:00:01 -0700 (PDT) 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=GDZBNbmIEMNTXiOXfvzz8Av+UK/KpcG+UdD1e4FwXG0=; b=ce9oJKM2aLWrRtB7h5xLDURSgG50kLQQoy0VW73oifOzgnlwutpKA6Xp8iGomXPMJY gI19Exua96ksjZCLRTFaulMHtgMibqPyJdsz/Jjq/4AkGNUBkzkroyB+p1GWNcYslG8U 840OFF2eoKz8YAU2mRQnBORzCx2bOyewAExhFf3b+yRB5aHoxwbTv3MWEIviAru8a8XG zYWcy8kt5BSocEFN2Pv6SMqq+naJg9g0E/7GYQFIJZEQricXt2IBs3CZzqd9Izmug2Tn WcN5HGZ7kjSGf+UWxPeZ9botiZ9aTvH9s2ayNVAYge6r0RPX0EH1jlSPsa9BwWtkwTxk o3kA== X-Received: by 10.55.16.74 with SMTP id a71mr32648528qkh.15.1434128401907; Fri, 12 Jun 2015 10:00:01 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id u95sm1915839qge.16.2015.06.12.10.00.01 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 12 Jun 2015 10:00:01 -0700 (PDT) From: Dave Garrett To: Aaron Zauner Date: Fri, 12 Jun 2015 13:00:00 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201506111558.21577.davemgarrett@gmail.com> <557B0C29.50803@azet.org> <557B0DCC.5010202@azet.org> In-Reply-To: <557B0DCC.5010202@azet.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201506121300.00764.davemgarrett@gmail.com> Archived-At: Cc: "" Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Jun 2015 17:00:04 -0000 On Friday, June 12, 2015 12:43:21 pm Aaron Zauner wrote: > I'm supportive in general, let's see how this turns out. Not surprising > though will be that I noticed additional CCM cipher-suites, as I > currently have a draft on OCB mode I'm not really supportive of that. > There should be a block-cipher mode that also offers considerable > performance for non-AESNI architectures - CCM was introduced because of > patents on OCB, we seem to have resolved this issue by now. At least for > TLS. The only reason OCB isn't in this draft is because I left it out of PR #180 because it doesn't have any codepoints yet. (again, this draft proposal uses that as a base) https://github.com/tlswg/tls13-spec/pull/180/files As soon as it progresses to WG adoption and codepoint assignment, then it certainly belongs in the TLS 1.3 draft. As far as I'm aware, even non-MTI suites listed in the spec need to be normative references and thus must be finalized before the full TLS 1.3 spec can be published. Just referencing the existence of others, which might be desired for the non-standards-track ones might be ok as informative, but I'm not sure on the specifics of the requirements there. Eric had said that we may want only ST listed at all, but that means that ECDHE CCM would be out but DHE CCM would be in, which is a problem. (it should probably just be promoted to ST) PR #180 just lists everything, at the moment. On Friday, June 12, 2015 12:50:20 pm Aaron Zauner wrote: > ..also why include both the cipher-suite with the 8-bit auth. tag and > the 16-bit tag? I found this particularly confusing with the CCM draft, > which is why I decided not to go for two different tag sizes. They exist, so they're included. If the WG can get consensus to mandate a one-true-tag-size, then we can prohibit the other for TLS 1.3+, but I have no opinion on the topic. Dave From nobody Fri Jun 12 10:09: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 D30F01ACD7D for ; Fri, 12 Jun 2015 10:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLliVtfa4DoQ for ; Fri, 12 Jun 2015 10:09:32 -0700 (PDT) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::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 CC1EC1ACD7E for ; Fri, 12 Jun 2015 10:09:28 -0700 (PDT) Received: by qgg3 with SMTP id 3so13368243qgg.2 for ; Fri, 12 Jun 2015 10:09:28 -0700 (PDT) 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=+nfPEXLLnGjVTWEJIIQD43D7BURn9oAjyJ+T3PMuF5k=; b=lrZ0JjuebfhRjoZT/LXwyI7IklZfpjfpE7ryEiuYb3KaJUIL+USd/e9YsC6xmRCXa6 LVAxCNsc7Nc5W9RdJKLtta6OOr81PvN95BnYEKQda1StETbZpa5Fklxzm7OcTPG2GMco qIayEc5qj/sAfGALH1djxx43VWv1kfCjTrQOnXYqvCls6ge8jGsvvqX5y0BaKthqkf+i rr1Hr1zJaXSmg9Sp2VDa5OdVnbUV83TIJpTsVnlSPt78E8DVT4rmeSjR3a+8LE8owh4G o8GJL8P+OJzo0hyvCOOPioztZrFxy2DLp9UFBJGW7XwjnHETQOfJWiSNi0AxpgBhcPAW dwlQ== X-Received: by 10.55.18.9 with SMTP id c9mr33316763qkh.50.1434128968166; Fri, 12 Jun 2015 10:09:28 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id b31sm1927029qge.5.2015.06.12.10.09.27 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 12 Jun 2015 10:09:27 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Fri, 12 Jun 2015 13:09:26 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201506111558.21577.davemgarrett@gmail.com> <201506121236.18304.davemgarrett@gmail.com> <20150612165558.GZ2050@mournblade.imrryr.org> In-Reply-To: <20150612165558.GZ2050@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201506121309.26874.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Jun 2015 17:09:35 -0000 On Friday, June 12, 2015 12:55:59 pm Viktor Dukhovni wrote: > I still don't understand preclude as a matter of principle negotiation > of ECDH_anon with AEAD if DH_anon with the same bulk cipher would > be allowed. Once we have separate negotiation of the key exchange, > surely ECDH_anon can be one of the supported key exchange variants, > and then take advantage of all the available bulk ciphersuites. EC/FF may be negotiated separately, but a suite still needs to be selected. Anon cannot be negotiated via an ECDHE_ECDSA suite, as the signatures extension explicitly prohibits proposing anon alongside actual signatures. One way or another, anon needs its own suites to be used. > Or does this proposal simply compress the client HELLO message, > but the server is still ultimately selecting the same all-in-one > ciphersuite (thus requiring Nico's new code points for ECDH_anon > with AEAD)? The server still needs to select a suite. If it selects an ECDHE_ECDSA suite, then it can negotiate EC/FF and RSA,DSA,ECDSA with extensions. It cannot negotiate anon. To do so would require either an ECDH_anon or DH_anon suite be negotiated. Yes, the preferred route is to require Nico's ECDH_anon codepoints for AEAD ciphers. With an ECDH_anon suite, the groups extension can be used to negotiate EC/FF. What I was stating earlier is that we could theoretically do so with DH_anon if we wanted to, but I would much rather the ECDH_anon draft be resurrected and passed as it would avoid confusion and the appearance of contradiction. Dave From nobody Fri Jun 12 10:17: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 E8D2B1A923D for ; Fri, 12 Jun 2015 10:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bP6EPS9Mrp22 for ; Fri, 12 Jun 2015 10:17:22 -0700 (PDT) Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) (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 1F3CA1A9170 for ; Fri, 12 Jun 2015 10:17:22 -0700 (PDT) Received: by yhid80 with SMTP id d80so16408406yhi.1 for ; Fri, 12 Jun 2015 10:17:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Nn+qGN+zH8f32UseLI8Bzt4aOATgw8d7TEil6wsgwjo=; b=f1xk+oLQx31dhaa1k3ojInX1FcNrPXu9bY+QYAIhwxd9Sc4JYO5W/KwjSsdKasbwuz L8uqCDb5U6VAqlK/rb/KNI2tk15JUm4uX24IvOCBhbeE328MQ81b5JC7Ssj5YPvXOe9j J5+ddaS+So4RNkllNJT6SNfsJcOqxBIJqnQgmwKl/dNv+y9SvSULflrmWV/cxsMQ8U/Y EM804QJzAdi7Kenh/9m59w4iPGLpuvvRsxeOFfTzDEQnIjSo4Pf1Sr/RP7w0kSoazI8C UvXqfUgCMJ3LldIrh+ZDI+HTqXnE7fep4XMh4CS6JUGG7ANfDbQD0YallyPwJp63Fnlq /d3A== MIME-Version: 1.0 X-Received: by 10.170.41.76 with SMTP id 73mr7973117ykj.101.1434129441539; Fri, 12 Jun 2015 10:17:21 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Fri, 12 Jun 2015 10:17:21 -0700 (PDT) In-Reply-To: References: <201505211210.43060.davemgarrett@gmail.com> <20150522025214.GA21141@typhoon.azet.org> <201505212304.11513.davemgarrett@gmail.com> <20150522032029.GA24064@typhoon.azet.org> Date: Fri, 12 Jun 2015 10:17:21 -0700 Message-ID: From: Martin Thomson To: Yuhong Bao Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] prohibit <1.2 on clients (but allow servers) (was: prohibit <1.2 support on 1.3+ servers (but allow clients)) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Jun 2015 17:17:24 -0000 On 11 June 2015 at 16:26, Yuhong Bao wrote: > I think disabling TLS 1.0 on servers is probably easier. That's not a terrible idea. Clients won't follow when 9% of connections still need 1.0 [1]. [1] http://telemetry.mozilla.org/#filter=release%2F38%2FSSL_HANDSHAKE_VERSION%2Fsaved_session%2FFirefox&aggregates=multiselect-all!Submissions&evoOver=Builds&locked=true&sanitize=true&renderhistogram=Graph From nobody Fri Jun 12 10:22: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 BF2571ACD9D for ; Fri, 12 Jun 2015 10:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 pzjcxT27oAAN for ; Fri, 12 Jun 2015 10:22:01 -0700 (PDT) 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 EFA211ACD45 for ; Fri, 12 Jun 2015 10:22:00 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 38EBA28494C; Fri, 12 Jun 2015 17:22:00 +0000 (UTC) Date: Fri, 12 Jun 2015 17:22:00 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150612172159.GA2050@mournblade.imrryr.org> References: <201506111558.21577.davemgarrett@gmail.com> <201506121236.18304.davemgarrett@gmail.com> <20150612165558.GZ2050@mournblade.imrryr.org> <201506121309.26874.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201506121309.26874.davemgarrett@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] A la carte handshake negotiation 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: Fri, 12 Jun 2015 17:22:02 -0000 On Fri, Jun 12, 2015 at 01:09:26PM -0400, Dave Garrett wrote: > On Friday, June 12, 2015 12:55:59 pm Viktor Dukhovni wrote: > > I still don't understand preclude as a matter of principle negotiation > > of ECDH_anon with AEAD if DH_anon with the same bulk cipher would > > be allowed. Once we have separate negotiation of the key exchange, > > surely ECDH_anon can be one of the supported key exchange variants, > > and then take advantage of all the available bulk ciphersuites. > > EC/FF may be negotiated separately, but a suite still needs to be selected. > Anon cannot be negotiated via an ECDHE_ECDSA suite, as the signatures > extension explicitly prohibits proposing anon alongside actual signatures. > One way or another, anon needs its own suites to be used. The extension definition can presumably be updated in a way that allows peers that support additional code-points to treat one of those as being "anon". Is the current definition really a serious obstacle to solving the problem in a properly orthogonal way. > > Or does this proposal simply compress the client HELLO message, > > but the server is still ultimately selecting the same all-in-one > > ciphersuite (thus requiring Nico's new code points for ECDH_anon > > with AEAD)? > > The server still needs to select a suite. If it selects an ECDHE_ECDSA > suite, then it can negotiate EC/FF and RSA,DSA,ECDSA with extensions. It > cannot negotiate anon. To do so would require either an ECDH_anon or > DH_anon suite be negotiated. Yes, the preferred route is to require Nico's > ECDH_anon codepoints for AEAD ciphers. With an ECDH_anon suite, the groups > extension can be used to negotiate EC/FF. What I was stating earlier is > that we could theoretically do so with DH_anon if we wanted to, but I > would much rather the ECDH_anon draft be resurrected and passed as it > would avoid confusion and the appearance of contradiction. So be it I guess. I wish it were simpler... -- Viktor. From nobody Fri Jun 12 10:49: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 4CEF91ACE22 for ; Fri, 12 Jun 2015 10:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZAjYMpzsiq7 for ; Fri, 12 Jun 2015 10:49:12 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::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 EF9681ACE21 for ; Fri, 12 Jun 2015 10:49:11 -0700 (PDT) Received: by qkhp85 with SMTP id p85so13036477qkh.1 for ; Fri, 12 Jun 2015 10:49:11 -0700 (PDT) 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=xbox0x3r/l6l6Tfn8EDlFYXXibjbooiFSRmtFpDBWfM=; b=UBeeAkBO1FjMhIAli3qGNeQEsW8Ear83zA21MQIl17H9avg864L7eW1LR76goMtbdx KKFZb2Ji5BXgJPAXT0a6dlqVMUaGzWP3wkdWZ2ePBHPWDR2U3L6Qn1WTLFCL4M1BQwX6 Gl39sX3WcrHuxLNhYoZPWLPT0VWbqKgbahRsg5b/0TlbJZjp2dmz+jD8FqPSCAyIYmWU n8lCSvW1IgsagVJL0ECyPQ/hGxsNA3A+Q/RpJC7GqlHOVzPCJWKQQONtPZxszD9I9YbS zb/6Dc1hH2n4BleFk8WIWWrx/zOie6LKqlH+c41Xm7KW7CCVsZHvHp71xyPh/Ubh0g7w R1Kg== X-Received: by 10.55.26.165 with SMTP id l37mr32358798qkh.88.1434131351292; Fri, 12 Jun 2015 10:49:11 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id 41sm1971330qgf.47.2015.06.12.10.49.10 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 12 Jun 2015 10:49:10 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Fri, 12 Jun 2015 13:49:09 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201506111558.21577.davemgarrett@gmail.com> <201506121309.26874.davemgarrett@gmail.com> <20150612172159.GA2050@mournblade.imrryr.org> In-Reply-To: <20150612172159.GA2050@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201506121349.09449.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Jun 2015 17:49:13 -0000 On Friday, June 12, 2015 01:22:00 pm Viktor Dukhovni wrote: > The extension definition can presumably be updated in a way that > allows peers that support additional code-points to treat one of > those as being "anon". Is the current definition really a serious > obstacle to solving the problem in a properly orthogonal way[?] Technically, the extension could be hacked to work like that by adding an `anonymous_real(4)` in addition to the existing `anonymous(0)`, but that feels like the wrong way to go about this. I generally agree that anon and authenticated should be kept separate, so I don't want to do that. The whole point of this negotiation proposal is to use _existing_ extensions to do this negotiation, rather than overhaul everything. The groups extension is already being modified to add FFDH groups alongside ECDH curves, but modifying the signatures extension to do anon would be more than just an addition; it'd overrule the previous behavior. The best route for integrating anon into this scheme for TLS 1.3+ really does seem to be to publish new ECDH_anon suites for ciphers that lack them and require those be used with EC/FF being negotiated via the extension. TLS 1.2 would benefit from adding them, anyway. Dave From nobody Fri Jun 12 11:02: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 44FB21ACE74; Fri, 12 Jun 2015 11:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOwU-4ZV_bCG; Fri, 12 Jun 2015 11:02:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 836A61ACE7A; Fri, 12 Jun 2015 11:02:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150612180230.4804.45802.idtracker@ietfa.amsl.com> Date: Fri, 12 Jun 2015 11:02:30 -0700 Archived-At: Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-curve25519-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, 12 Jun 2015 18:02:37 -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 : Curve25519 for ephemeral key exchange in Transport Layer Security (TLS) Authors : Simon Josefsson Manuel Pegourie-Gonnard Filename : draft-ietf-tls-curve25519-00.txt Pages : 12 Date : 2015-06-09 Abstract: This document specifies the use of Curve25519 for ephemeral key exchange in the Transport Layer Security (TLS) protocol, as well as its DTLS variant. It updates RFC 5246 (TLS 1.2) and RFC 4492 (Elliptic Curve Cryptography for TLS). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-curve25519/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tls-curve25519-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 Jun 12 11:12: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 0CD211ACE97 for ; Fri, 12 Jun 2015 11:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 rm6zuKiEROe4 for ; Fri, 12 Jun 2015 11:12:44 -0700 (PDT) Received: from mail-qk0-f173.google.com (mail-qk0-f173.google.com [209.85.220.173]) (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 122F51ACE94 for ; Fri, 12 Jun 2015 11:12:44 -0700 (PDT) Received: by qkhq76 with SMTP id q76so20631827qkh.2 for ; Fri, 12 Jun 2015 11:12:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=oyDKTEPx49hSMXiUszUDxcukmcRMIe2S0Sl9EJ37YHw=; b=SULR4PKhxDyL8P+9+ZjEAnk2ER8FHpofAxeNSCbx9px1YOWUczUCERts5JJWfOVRxt b2xUNymF2dZs8EpOy+YgkDcsTaYyOlkqJzwum9NDEJKKz3PSw4Pi2ZTK/C3dhikeepPY jZJzHBJxWVQ+k4gEOfp4l8wWLme1PHNhc+Jauej17NO78CmLyO2SEjEB8FjLR77Osg18 n7ZR9+E6ali12MJLAlhSzWGROuRobMtWog5wLKylRrKmZlwRSTsZBzo5yDKqc/J/maSf tlx6D1AlRzA8EC4tbLhqXWnuGgcOdjW+r6kwWftJGISI+XperaZAM4CkWdJCu64hT3db MqqA== X-Gm-Message-State: ALoCoQk6ysFzxoDSnmi0YCa5MoeKQLIOd2qpbaFKf0xe+3yX+9PHnZ+9d3u+Inc+/XPBjyDPrDmZ MIME-Version: 1.0 X-Received: by 10.55.33.30 with SMTP id h30mr32904010qkh.87.1434132763372; Fri, 12 Jun 2015 11:12:43 -0700 (PDT) Received: by 10.96.161.169 with HTTP; Fri, 12 Jun 2015 11:12:43 -0700 (PDT) In-Reply-To: References: Date: Fri, 12 Jun 2015 11:12:43 -0700 Message-ID: From: Joseph Salowey To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a114055a8ec1fd10518560d3d Archived-At: Subject: Re: [TLS] Call for WG adoption draft-josefsson-tls-curve25519 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Jun 2015 18:12:47 -0000 --001a114055a8ec1fd10518560d3d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Based on the result of this call we've accepted draft-ietf-tls-curve25519-00 as a working group item. Thanks, J/S On Wed, May 20, 2015 at 8:47 AM, Joseph Salowey wrote: > This is the WG call for adoption of: > > https://www.ietf.org/archive/id/draft-josefsson-tls-curve25519-06.txt > > This draft specifies the use of Curve25519 for ephemeral key exchange in > the TLS and DTLS. This draft serves as the starting point (it=E2=80=99s = expired > and needs to be updated in light of > http://datatracker.ietf.org/doc/draft-irtf-cfrg-curves/). If you object > to the adoption of this draft, please let us know why by 20150602. > > Note: We=E2=80=99re not doing an early code point assignment for this dra= ft, > because it clearly needs to resurrected and tweaked. Once that happens, > there=E2=80=99s nothing stopping a request from the authors for an early = code point > assignment. > > Thanks, > > J/S > --001a114055a8ec1fd10518560d3d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Based on the result of this call we've accepted=C2=A0d= raft-ietf-tls-curve25519-00 as a working group=C2=A0item. =C2=A0

Thanks,

J/S

On Wed, May 20, 2015 at 8:47 AM, Jo= seph Salowey <joe@salowey.net> wrote:
This is the WG ca= ll for adoption of:

https://www.ietf= .org/archive/id/draft-josefsson-tls-curve25519-06.txt

This= draft specifies the use of Curve25519 for ephemeral key exchange in the TL= S and DTLS.=C2=A0 This draft serves as the starting point (it=E2=80=99s exp= ired and needs to be updated in light of=C2=A0http://datatracker.ietf.org/doc/draft-irtf-cfrg-curves/).=C2=A0 If you object to the adoption of this= draft, please let us know why by 20150602.

Note: We=E2= =80=99re not doing an early code point assignment for this draft, because i= t clearly needs to resurrected and tweaked.=C2=A0 Once that happens, there= =E2=80=99s nothing stopping a request from the authors for an early code po= int assignment.

Thanks,

J/S<= br>

--001a114055a8ec1fd10518560d3d-- From nobody Fri Jun 12 11:36: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 14B061ACE91 for ; Fri, 12 Jun 2015 11:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 A4V6MTcWz6gm for ; Fri, 12 Jun 2015 11:36:17 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 95DE31ACE81 for ; Fri, 12 Jun 2015 11:36:17 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id CE9464962E; Fri, 12 Jun 2015 18:36:16 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id C362049627; Fri, 12 Jun 2015 18:36:16 +0000 (GMT) Received: from email.msg.corp.akamai.com (ustx2ex-cas3.msg.corp.akamai.com [172.27.25.32]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id C034A98092; Fri, 12 Jun 2015 18:36:16 +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.1076.9; Fri, 12 Jun 2015 13:36:16 -0500 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.1076.000; Fri, 12 Jun 2015 13:36:16 -0500 From: "Salz, Rich" To: Martin Thomson , Yuhong Bao Thread-Topic: [TLS] prohibit <1.2 on clients (but allow servers) (was: prohibit <1.2 support on 1.3+ servers (but allow clients)) Thread-Index: AQHQlE/ERbjiIZXjEUOvOTH8OrxpH52oZzeAgAErQ4D//8IWkA== Date: Fri, 12 Jun 2015 18:36:15 +0000 Message-ID: <84b3d584477349b78551d82ec749ba16@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <201505211210.43060.davemgarrett@gmail.com> <20150522025214.GA21141@typhoon.azet.org> <201505212304.11513.davemgarrett@gmail.com> <20150522032029.GA24064@typhoon.azet.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.41.180] 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] prohibit <1.2 on clients (but allow servers) (was: prohibit <1.2 support on 1.3+ servers (but allow clients)) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Jun 2015 18:36:19 -0000 When I asked Bodo if you could make an attack for TLS 1.0, he said "oh, Lab= rador?" He was joking. From nobody Fri Jun 12 11:38: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 ABB761ACE9E for ; Fri, 12 Jun 2015 11:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id de-iCMe2tbE0 for ; Fri, 12 Jun 2015 11:38:01 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (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 C5BAB1ACEA2 for ; Fri, 12 Jun 2015 11:38:00 -0700 (PDT) Received: by qkhg32 with SMTP id g32so20973682qkh.0 for ; Fri, 12 Jun 2015 11:38:00 -0700 (PDT) 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=wJZ2E+OZJZX9lVf9MmPnWqGEoCjWhVsDSgpunEWvsxs=; b=F7Eeqg+x3ho3BvBtToyowL+yyNCeC1V65jrtvk2OzXiS4/4NKNY3J5f6wmK5BcrSZE WZd4KCtMY2nzoU06Yr2dEEZBJXmurEy+RsuJyL/ZSuJlSfigYtQaWQgNcAju1CmTU4zD UkKE0fQs7cE5+KdhPEhKd41ESoaReI67oD4TlTQJWSS3QeIqKwuEUd8cGSCT4RDIp8CN y1OgTI2MvQqPhW3r4BuTgGuFTBZCHEdwCBZFuzmGKFtWBGuQmxagIYuL6HtDm+Qg1DDs 6iAuZuJA6xP9/5sCxPwXKN+0Wi7ZtfLYES2m1FU5E/s5rL1qLwyaCvp7bEi/bD3E16gU Bufw== X-Received: by 10.55.31.29 with SMTP id f29mr550514qkf.27.1434134280136; Fri, 12 Jun 2015 11:38:00 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id b191sm2014733qka.14.2015.06.12.11.37.59 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 12 Jun 2015 11:37:59 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Fri, 12 Jun 2015 14:37:57 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201506111558.21577.davemgarrett@gmail.com> <201506121236.18304.davemgarrett@gmail.com> <20150612165558.GZ2050@mournblade.imrryr.org> In-Reply-To: <20150612165558.GZ2050@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201506121437.58527.davemgarrett@gmail.com> Archived-At: Subject: [TLS] ECDH_anon I-D (was: A la carte handshake negotiation) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Jun 2015 18:38:02 -0000 On Friday, June 12, 2015 12:55:59 pm Viktor Dukhovni wrote: > On Fri, Jun 12, 2015 at 12:36:17PM -0400, Dave Garrett wrote: > > AES CBC already cannot be used with TLS 1.3+, as it now requires AEAD ciphers only. [...] > The DH AEAD ciphersuite set includes two DH_anon members. For ECDH > AEAD there are none. > > > TLS_ECDH_anon_WITH_AES_256_GCM_SHA384 is in this expired draft: > > https://tools.ietf.org/html/draft-williams-tls-anon-ecdh-modern-cipher-01 > > Yes, I asked Nico to help fill the gap. I guess this did not go > very far. [...] > > Just properly publishing a "ECDH_anon" RFC would be preferable, > > however. Resurrecting this draft seems like a good idea, regardless of TLS 1.3. https://tools.ietf.org/id/draft-williams-tls-anon-ecdh-modern-cipher-01.html It defines: ============================== TLS_ECDH_anon_WITH_AES_128_GCM_SHA256 This is anonymous key agreement with ephemeral ECDH keys, with AES-128 in GCM mode, and SHA256 as the hash function for the TLS PRF. TLS_ECDH_anon_WITH_AES_128_CCM_SHA256 This is anonymous key agreement with ephemeral ECDH keys, with AES-128 in CCM mode, and SHA256 as the hash function for the TLS PRF. TLS_ECDH_anon_WITH_AES_256_GCM_SHA384 This is anonymous key agreement with ephemeral ECDH keys, with AES-256 in GCM mode, and SHA384 as the hash function for the TLS PRF. TLS_ECDH_anon_WITH_AES_256_CCM_SHA384 This is anonymous key agreement with ephemeral ECDH keys, with AES-256 in CCM mode, and SHA384 as the hash function for the TLS PRF. ============================== If we're to update this draft, I think we should really change the "ECDH" to "ECDHE" here. It would make specifying which suite prefixes are permitted a lot simpler and less prone to confusion, as the current naming is inconsistent. All ephemeral should have the 'E' on the end, regardless of how it's provided. Also, adding new ECC anon versions for other ciphers in the same document, like ARIA-GCM [RFC6209] and CAMELLIA-GCM [RFC6367], might be warranted. Dave From nobody Fri Jun 12 12:57: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 8E6171AD362 for ; Fri, 12 Jun 2015 12:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 BjvYvRcKC_xY for ; Fri, 12 Jun 2015 12:56:57 -0700 (PDT) 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 9CE841AD066 for ; Fri, 12 Jun 2015 12:56:57 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id AC34490054 for ; Fri, 12 Jun 2015 22:56:54 +0300 (EEST) Date: Fri, 12 Jun 2015 22:56:54 +0300 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20150612195654.GA9401@LK-Perkele-VII> References: <20150612180230.4804.45802.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150612180230.4804.45802.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-curve25519-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Jun 2015 19:56:59 -0000 On Fri, Jun 12, 2015 at 11:02:30AM -0700, internet-drafts@ietf.org wrote: > Filename : draft-ietf-tls-curve25519-00.txt "Servers MUST NOT select an ECDHE_ECDSA ciphersuite if there are no common curves suitable for ECDSA." You mean MUST NOT select ECDSA certificate? Because TLS 1.2 rules seemingly allow selecting ECDHE_RSA ciphersuite with ECDSA certificate. "This section defines a new point format suitable to encode Curve25519 public keys, as well as an identifier to negotiate this new format in TLS, and includes guidance on their use." Is this format going to be the chosen one for TLS 1.3? Because TLS 1.3 can't negotiate point formats for ECDHE. Also, I don't see the value of trying to negotiate the point format, and I think that the negotiation will act as an implementation error source. -Ilari From nobody Fri Jun 12 13:05: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 D92BF1B29FA for ; Fri, 12 Jun 2015 13:05:35 -0700 (PDT) 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 vAd0wxvPQkdZ for ; Fri, 12 Jun 2015 13:05:34 -0700 (PDT) Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) (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 2B7311B2A01 for ; Fri, 12 Jun 2015 13:05:30 -0700 (PDT) Received: by wgv5 with SMTP id 5so30981383wgv.1 for ; Fri, 12 Jun 2015 13:05:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=nV1vvApIcL5VkO4mAwuAReM8tvBb5/YJ8nst7AYCIew=; b=aVNMy5MDrAZTKjorld9jg7vJnDewJvOzH+XIVzRA/Yj32kzlxcPrrTRLmBPJaHtA9t NuYssxl8VcgkHwTRN5mXFQZyAVEsUwr6yt5S7h6v8Jrx+WFcCDfPjWXA/IKLmD62EfVe 7wi62q1zqrCOSz/AEswG1YjkYXhaIj90u2+uoEaKAnR5+tnRwafdoMmgmJUszCn/UHv7 sQeIhRddoEulDvpqZmZvjNgQcateLbr37N/rvMjzHtxwxGLoIR40ZPF3WzTyiAj/Rnrc 1oWyXsp/Vwr51e8AmjiKnP8gVqe5tZb0/qxqiicKg/V3zFr/sFP75jGH4B5GnceA7w6h IHfg== X-Gm-Message-State: ALoCoQmuUwzW9o69p5Sy7KRE3eQ7LaOZ4jRlU7r3Fcbw7rV9icBXmc5Jtb5wWw7iQqhG9KscU3TI X-Received: by 10.180.99.39 with SMTP id en7mr10002573wib.31.1434139528912; Fri, 12 Jun 2015 13:05:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.225.14 with HTTP; Fri, 12 Jun 2015 13:04:48 -0700 (PDT) In-Reply-To: <20150612195654.GA9401@LK-Perkele-VII> References: <20150612180230.4804.45802.idtracker@ietfa.amsl.com> <20150612195654.GA9401@LK-Perkele-VII> From: Eric Rescorla Date: Fri, 12 Jun 2015 16:04:48 -0400 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=f46d041828082df9dd051857a14e Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] I-D Action: draft-ietf-tls-curve25519-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Jun 2015 20:05:36 -0000 --f46d041828082df9dd051857a14e Content-Type: text/plain; charset=UTF-8 On Fri, Jun 12, 2015 at 3:56 PM, Ilari Liusvaara < ilari.liusvaara@elisanet.fi> wrote: > On Fri, Jun 12, 2015 at 11:02:30AM -0700, internet-drafts@ietf.org wrote: > > Filename : draft-ietf-tls-curve25519-00.txt > > "Servers MUST NOT select an ECDHE_ECDSA ciphersuite if there are no > common curves suitable for ECDSA." > > You mean MUST NOT select ECDSA certificate? Because TLS 1.2 rules > seemingly allow selecting ECDHE_RSA ciphersuite with ECDSA > certificate. > > "This section defines a new point format suitable to encode Curve25519 > public keys, as well as an identifier to negotiate this new format in > TLS, and includes guidance on their use." > > Is this format going to be the chosen one for TLS 1.3? Because TLS 1.3 > can't negotiate point formats for ECDHE. > > Also, I don't see the value of trying to negotiate the point format, > and I think that the negotiation will act as an implementation error > source. I would suggest claiming that this point format is "uncompressed" and the only point format for Curve25519. -Ekr > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --f46d041828082df9dd051857a14e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Fri, Jun 12, 2015 at 3:56 PM, Ilari Liusvaara <ilari.liusvaar= a@elisanet.fi> wrote:
On Fr= i, Jun 12, 2015 at 11:02:30AM -0700, internet-drafts@ietf.org wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-tls-curve25519-00.txt

"Servers MUST NOT select an ECDHE_ECDSA ciphersuite if there are no common curves suitable for ECDSA."

You mean MUST NOT select ECDSA certificate? Because TLS 1.2 rules
seemingly allow selecting ECDHE_RSA ciphersuite with ECDSA
certificate.

"This section defines a new point format suitable to encode Curve25519=
public keys, as well as an identifier to negotiate this new format in
TLS, and includes guidance on their use."

Is this format going to be the chosen one for TLS 1.3? Because TLS 1.3
can't negotiate point formats for ECDHE.

Also, I don't see the value of trying to negotiate the point format, and I think that the negotiation will act as an implementation error
source.

I would suggest claiming that this = point format is "uncompressed" and the
only point forma= t for Curve25519.

-Ekr



-Ilari

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

--f46d041828082df9dd051857a14e-- From nobody Fri Jun 12 13:43: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 61FDE1B2A7E for ; Fri, 12 Jun 2015 13:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLn8srZ0pHZQ for ; Fri, 12 Jun 2015 13:43:26 -0700 (PDT) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (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 89F401B2A7D for ; Fri, 12 Jun 2015 13:43:26 -0700 (PDT) Received: by ykfl8 with SMTP id l8so23028987ykf.1 for ; Fri, 12 Jun 2015 13:43:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=e7fuXfZ91ludXKU2OrhDaMjEw+kFboAeHXhgBFHXghg=; b=HwlLGP7TWnjI54QxN2LPXx7cedFwSiG4/+1VJy0lH3MG02t77AK6KtDXjsphuZcuha VMBtDGhXCOmAPinfwys8Qy3udHWnPnsLoG0WOGDyTV5wSWEh097hLwXM5piN7BCZvEh6 x8do4pr20fruhiiX4XhIkNPE9+VwyFP3a7ab2rXDn5HAzIFnTLbw4pw5OloQQi8Y3e7h PBsbPxq82I5wLDusEysYvDuPUZk8opKEtPij/3jLEsMdV1ob40wkpfNF3pGoql0qjCc7 YOCzRHleSN9rgHhkxadwOerUC6ewORQH6O0qjVzbfIJgI8AVIYcQ/SvIPWgvC/21i09t jbUQ== MIME-Version: 1.0 X-Received: by 10.129.39.21 with SMTP id n21mr5606163ywn.55.1434141805934; Fri, 12 Jun 2015 13:43:25 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Fri, 12 Jun 2015 13:43:25 -0700 (PDT) In-Reply-To: <20150612195654.GA9401@LK-Perkele-VII> References: <20150612180230.4804.45802.idtracker@ietfa.amsl.com> <20150612195654.GA9401@LK-Perkele-VII> Date: Fri, 12 Jun 2015 13:43:25 -0700 Message-ID: From: Martin Thomson To: Ilari Liusvaara Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] I-D Action: draft-ietf-tls-curve25519-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Jun 2015 20:43:28 -0000 On 12 June 2015 at 12:56, Ilari Liusvaara wrote: > "Servers MUST NOT select an ECDHE_ECDSA ciphersuite if there are no > common curves suitable for ECDSA." > > You mean MUST NOT select ECDSA certificate? Because TLS 1.2 rules > seemingly allow selecting ECDHE_RSA ciphersuite with ECDSA > certificate. This seems right to me. The point here is that when a named_curve (or named_group) identifies 25519, then it can't be used for ECDSA. 25519 is always OK with an _RSA_ suite. From nobody Fri Jun 12 18:45: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 9B7CA1A89F0 for ; Fri, 12 Jun 2015 18:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmd8moqxQh5N for ; Fri, 12 Jun 2015 18:45:18 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::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 D23F91A89C7 for ; Fri, 12 Jun 2015 18:45:17 -0700 (PDT) Received: by qkhg32 with SMTP id g32so25043212qkh.0 for ; Fri, 12 Jun 2015 18:45:17 -0700 (PDT) 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=bdWRL9hqf1keTWmvVtA0MHlP1ldDOiD7u/UtchJUt2I=; b=spxLKxRntKIP+YSkBf2Xq7LLeZOPk0JI3YpZP9GLzkt3lswnb8rfSo6digGx4gywwC QkWMNFRpxgbvX17FA6PEZnH9vEH8Ck8r/jofMFB4BtX/509zaNrjrt+ZyxQVDQzd2mid SRCsPrDO1obCaZUlQpeLmLM2Qm94jJxNh7ZK1hzBbIkF7MtO6mBCASmrsyXx/qvH+s1V VQBYHKBT2BzqCLXYmstzXLMQQIPC2z5kkLugoaekuIpo3vflkbvXdu5AyEIBu5x4QAJP O1QKCrer1lLDVgjlSLL5sgYoIqryx/dEOMlEUkYAcxziM6vWkCA0UGwSz23cl/X+q0wp CQDg== X-Received: by 10.55.40.7 with SMTP id o7mr36818957qkh.81.1434159917178; Fri, 12 Jun 2015 18:45:17 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id q105sm2502379qgq.11.2015.06.12.18.45.16 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 12 Jun 2015 18:45:16 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Fri, 12 Jun 2015 21:45:13 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-Id: <201506122145.13790.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2015 01:45:19 -0000 Based on the discussions today, I've significantly revised the text of this= proposal. This new draft goes into more detail for the PSK & anon cipher s= uites. Of note, I've added a table to state what's available to negotiate with wha= t. It's longer than it should be because both DHE_PSK and DH_anon should be= dropped from there, but for now I've included them because ECDHE_PSK and E= CDH_anon AEAD cipher suites have yet to be standardized. There's expired dr= afts for these and if PSK and anon are to be considered fully compatible wi= th TLS 1.3, then these really should be defined. Merging them together into= one I-D for AEAD ECDHE cipher suite assignments seems like the simplest ro= ute. I'd also rather plain (symmetric-only) PSK be relegated to its own specific= ations and not included here, but I've included it in the table for now. EC= DHE_PSK should ideally be the only supported PSK handshake. Plain PSK has n= o FS and it was generally agreed that TLS 1.3+ should be FS only. New draft text: https://github.com/davegarrett/tls13-spec/blob/alacarte/draft-ietf-tls-tls1= 3.md#cipher-suites Diff with master: https://github.com/tlswg/tls13-spec/compare/master...davegarrett:alacarte I think there might've been some discussion on this list in the past about = potentially adding PSK to the SignatureAlgorithm enum for the "signature_al= gorithms" extension. This could obsolete all ECDHE_PSK and DHE_PSK cipher s= uites and allow PSK negotiation via normal ECDHE_ECDSA cipher suites and th= e extension. I'm not sure if this would be desired or not. I'm not proposin= g this currently, but I'm not against also doing this, though. To reiterate from the anon discussion, the "signature_algorithms" extension= already defines `anonymous(0)` and has an explicit prohibition on it ever = being included. Obsoleting ECDH_anon and DH_anon and switching to this exte= nsion for negotiation would require either hacking in a second anonymous va= lue to replace it (bad idea, IMO) or changing the extension spec to allow t= he existing value, which might break things expecting otherwise. Personally= , I think anon should have its own cipher suite and not be negotiated via t= he signatures extension, as it is not a valid option for normal use-cases. = (paranoid exploit worry: a bad implementation could muck up extension handl= ing and negotiate anon when it shouldn't; safer to just keep it separate) A= rguably, PSK isn't a valid option most of the time either, but it can't be = negotiated without a pre-shared key actually being pre-shared, so using the= extension for it might be viable. If ECDH_anon suites are defined, anon wi= ll be able to negotiate DHE/ECDHE via the "supported_groups" extension, so = it would only be one anon suite per symmetric cipher. Also note that non-standards-track ciphers are still listed in there, but m= ay be dropped prior to merge. Promoting ECDHE AES-CCM from informational to= standards track would be a good idea if we only want to include standards = track ciphers here. AES-OCB will be added whenever its draft has a temporar= y codepoint to include. Dave From nobody Fri Jun 12 20:57: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 998E31B2DFA for ; Fri, 12 Jun 2015 20:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MfBDwUhcfJPD for ; Fri, 12 Jun 2015 20:57:08 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::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 1B6FB1B2DFF for ; Fri, 12 Jun 2015 20:55:49 -0700 (PDT) Received: by qkhg32 with SMTP id g32so26113974qkh.0 for ; Fri, 12 Jun 2015 20:55:48 -0700 (PDT) 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=t1QIGyN3S3DiKE00NXqvYw4fHrrQTKvlvl6seABF1qw=; b=grZctce/1gUoNBzRit44RHXaTYSV8vnzJfxldn0z+wcL4TCTjMJNqkJX35a+eat681 X1Not8SuNadrIV3rGhOhlNpwRY8Z50rJl/dD+8vIPOa3qPsPm4XAWRSLQkOq5A0W5VNP w2sVjQTYD5T5tTiOi9pgUsyGoWQ/V7fwG7fhT6IzsHB1fttDlfoSq4KYNaS0ZlTZhEsC WhYg7nxw23PSZr52HjHK30dvTDGYP+ISJHADa531jYByeeRPHOw47AFo8GjfEBMR8S5B /54J8TsUecdWhOeVc18yYAZjknvO12c5u3EzVyi2TTB2U/NHjAk5yfG0x3K+LEZKh+Ka dXTg== X-Received: by 10.55.25.134 with SMTP id 6mr37213257qkz.13.1434167748462; Fri, 12 Jun 2015 20:55:48 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id i197sm2611628qhc.36.2015.06.12.20.55.47 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 12 Jun 2015 20:55:47 -0700 (PDT) From: Dave Garrett To: Nikos Mavrogiannopoulos Date: Fri, 12 Jun 2015 23:55:45 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <20150611170317.13732.72719.idtracker@ietfa.amsl.com> In-Reply-To: <20150611170317.13732.72719.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201506122355.45772.davemgarrett@gmail.com> Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] I-D Action: draft-ietf-tls-chacha20-poly1305-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2015 03:57:09 -0000 After discussion earlier involving ECDHE_anon cipher suites, it occurred to me that it could be useful to define one for ChaChaPoly in this draft. Is it viable to add a cipher suite name and codepoint for this? It didn't get brought up in the previous discussion on this list about which suites were desired here. TLS_ECDHE_anon_WITH_CHACHA20_POLY1305 (preferably "ECDHE" instead of "ECDH" for consistency with newer suites, rather than the old anon suites) At the moment, there are no AEAD ECDHE anon cipher suites currently standardized. The only AEAD DHE anon cipher suites are the two AES-GCM suites defined in RFC5288. TLS 1.3 requires AEAD, so this means it has very few anon choices, and no ECDHE anon yet. Dave From nobody Sat Jun 13 03:24: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 31A181B2FC3 for ; Sat, 13 Jun 2015 03:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, 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 w_3CKt4FKO2w for ; Sat, 13 Jun 2015 03:24:39 -0700 (PDT) Received: from emh02.mail.saunalahti.fi (emh02.mail.saunalahti.fi [62.142.5.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 975DB1A8731 for ; Sat, 13 Jun 2015 03:24:37 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id 3E9FC81877; Sat, 13 Jun 2015 13:24:35 +0300 (EEST) Date: Sat, 13 Jun 2015 13:24:34 +0300 From: Ilari Liusvaara To: Dave Garrett Message-ID: <20150613102434.GA16258@LK-Perkele-VII> References: <201506111558.21577.davemgarrett@gmail.com> <201506121213.02446.davemgarrett@gmail.com> <20150612162236.GW2050@mournblade.imrryr.org> <201506121236.18304.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <201506121236.18304.davemgarrett@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2015 10:24:41 -0000 On Fri, Jun 12, 2015 at 12:36:17PM -0400, Dave Garrett wrote: > On Friday, June 12, 2015 12:22:37 pm Viktor Dukhovni wrote: > > On Fri, Jun 12, 2015 at 12:13:02PM -0400, Dave Garrett wrote: > > > It might even be warranted to use only DH_anon suites instead > > > of ECDH_anon due to its more widespread use. This would allow usage of > > > ECC without having to specify any new ECDH_anon suites for those lacking > > > them but already having DH_anon suites. > > > > I'm afraid I don't understand the above. Also AECDH (ECDH_anon) > > is not particularly rare: > > > > Jun 12 15:48:16 mournblade postfix/smtpd[25717]: Anonymous TLS connection established from xmpp.openssl.org[194.97.150.230]: TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits) > > Your quote is usage of: > TLS_ECDH_anon_WITH_AES_256_CBC_SHA > > AES CBC already cannot be used with TLS 1.3+, as it now requires AEAD ciphers only. > > TLS_DH_anon_WITH_AES_256_GCM_SHA384 is in: > https://tools.ietf.org/html/rfc5288 > > TLS_ECDH_anon_WITH_AES_256_GCM_SHA384 is in this expired draft: > https://tools.ietf.org/html/draft-williams-tls-anon-ecdh-modern-cipher-01 > > The current proposal requires all suites for TLS 1.3+ to be the ECC variants, which is not currently doable for anon AES-GCM. What I'm saying is that we could use "DH_anon" suites instead of "ECDH_anon" suites in this scheme. Just properly publishing a "ECDH_anon" RFC would be preferable, however. > Assembling the list of ciphersuites (with some renaming): C02B TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 C02C TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 C0AC TLS_ECDHE_ECDSA_WITH_AES_128_CCM_SHA256 C0AD TLS_ECDHE_ECDSA_WITH_AES_256_CCM_SHA256 C0AE TLS_ECDHE_ECDSA_WITH_AES_128_CCM8_SHA256 C0AF TLS_ECDHE_ECDSA_WITH_AES_256_CCM8_SHA256 C05C TLS_ECDHE_ECDSA_WITH_ARIA_128_GCM_SHA256 C05D TLS_ECDHE_ECDSA_WITH_ARIA_256_GCM_SHA384 C086 TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_GCM_SHA256 C087 TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_GCM_SHA384 CCA2? TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 ???? TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 ???? TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 ???? TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 ???? TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA256 ???? TLS_ECDHE_PSK_WITH_AES_128_CCM8_SHA256 ???? TLS_ECDHE_PSK_WITH_AES_256_CCM8_SHA256 ???? TLS_ECDHE_PSK_WITH_ARIA_128_GCM_SHA256 ???? TLS_ECDHE_PSK_WITH_ARIA_256_GCM_SHA384 ???? TLS_ECDHE_PSK_WITH_CAMELLIA_128_GCM_SHA256 ???? TLS_ECDHE_PSK_WITH_CAMELLIA_256_GCM_SHA384 CCA6? TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 ???? TLS_ECDHE_anon_WITH_AES_128_GCM_SHA256 ???? TLS_ECDHE_anon_WITH_AES_256_GCM_SHA384 ???? TLS_ECDHE_anon_WITH_AES_128_CCM_SHA256 ???? TLS_ECDHE_anon_WITH_AES_256_CCM_SHA256 ???? TLS_ECDHE_anon_WITH_AES_128_CCM8_SHA256 ???? TLS_ECDHE_anon_WITH_AES_256_CCM8_SHA256 ???? TLS_ECDHE_anon_WITH_ARIA_128_GCM_SHA256 ???? TLS_ECDHE_anon_WITH_ARIA_256_GCM_SHA384 ???? TLS_ECDHE_anon_WITH_CAMELLIA_128_GCM_SHA256 ???? TLS_ECDHE_anon_WITH_CAMELLIA_256_GCM_SHA384 ???? TLS_ECDHE_anon_WITH_CHACHA20_POLY1305_SHA256 00A8 TLS_PSK_WITH_AES_128_GCM_SHA256 00A9 TLS_PSK_WITH_AES_256_GCM_SHA384 C0A4 TLS_PSK_WITH_AES_128_CCM_SHA256 C0A5 TLS_PSK_WITH_AES_256_CCM_SHA256 C0A8 TLS_PSK_WITH_AES_128_CCM8_SHA256 C0A9 TLS_PSK_WITH_AES_256_CCM8_SHA256 C06A TLS_PSK_WITH_ARIA_128_GCM_SHA256 C06B TLS_PSK_WITH_ARIA_256_GCM_SHA384 C08E TLS_PSK_WITH_CAMELLIA_128_GCM_SHA256 C08F TLS_PSK_WITH_CAMELLIA_256_GCM_SHA384 CCA5? TLS_PSK_WITH_CHACHA20_POLY1305_SHA256 yyyy => Assigned ciphersuite ID (20) yyyy? => Proposed ciphersuite ID in I-D (3) ???? => No current I-D (21) Looking at how this would look with orthogoal negotiation: 17 codepoints: TLS13_KEX_GDHE_CERT TLS13_KEX_GDHE_PSK TLS13_KEX_GDHE_anon TLS13_KEX_PSK TLS13_PROT_AES_128_GCM TLS13_PROT_AES_256_GCM TLS13_PROT_AES_128_CCM TLS13_PROT_AES_256_CCM TLS13_PROT_AES_128_CCM8 TLS13_PROT_AES_256_CCM8 TLS13_PROT_ARIA_128_GCM TLS13_PROT_ARIA_256_GCM TLS13_PROT_CAMELLIA_128_GCM TLS13_PROT_CAMELLIA_256_GCM TLS13_PROT_CHACHA20_POLY1305 TLS13_PRF_SHA256 TLS13_PRF_SHA384 (select one KEX, one PROT and one PRF) - Would be much easier if SHA-2 ever gets broken[1]... - All TLS stacks should already separate key exchange, record protection and PRF[2]. - GDHE is the unfication of DHE and ECDHE (some other things might unify with it as well[3]). - I didn't separate GDHE from cert/psk/anon, because I can't get clean split there[4], and unclean splits are asking for trouble. - Certificate part (other than existence thereof) in TLS 1.2 is already ignored in ServerHello (and only sets overrideable defaults in ClientHello[5]). [1] Nominally, security rests on PRF-hash being CR (but exploiting collision doesn't look to be easy). So if SHA-256 ever gets broken CR, one needs to replace it (which would be 32 new ciphersuites, instead of just one PRF, and if whole SHA-2 goes, need 44 new ones, instead of just 2). [2] There are tables of ciphersuite properties (what key exchange, what record protection, what PRF (unless PRF is hardcoded to SHA256)). [3] Including one or two potential PQ key exchanges. [4] The problem is that PSK itself is quite different from GDHE_PSK, which is quite different from GDHE_CERT. [5] If signature_algorithms is sent, then similar ignore also applies to ClientHello cipher list. -Ilari From nobody Sat Jun 13 09:07: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 C0F4C1AC3C2 for ; Sat, 13 Jun 2015 09:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.992 X-Spam-Level: X-Spam-Status: No, score=-1.992 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, 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 yyL9dKPYrnjI for ; Sat, 13 Jun 2015 09:07:29 -0700 (PDT) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d: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 568711AC3B8 for ; Sat, 13 Jun 2015 09:07:29 -0700 (PDT) Received: by qcnj1 with SMTP id j1so17244212qcn.0 for ; Sat, 13 Jun 2015 09:07:28 -0700 (PDT) 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=YqfKNEoeElK9lhQKBCHnGlxD2chsxAoS7YfuI00CG00=; b=aAT88HqKc/8K5gcrm7zRm0Zi8Zbkw4miqTOo0GPPfL37KpblhG8X9Iqm7Uf48MvpSv I28F33C0dvDR2C45FDkhMhhgvEUnnx5TmH42X6hwkMytKyxE/dnd7CZ77uOVb86aTb2w 6vJpg1tnl6gpAZgnsJIiVMX6dWSPPHySVBg8fkzB2UZljjMPImSVHluduszzab7uqKT0 dMSAvhBTfUuTlPKLNnAC29UWuFCKSrOb2ld75UsQUzNEFXGj8yR2GT8T0QF80a2uWG+H 1maym3UY2hnYI6ehy13bnLOrotpJqGnlZpmXbPhFlIGwQmQxxIz7q3EqRPPqKASPQjAZ qqog== X-Received: by 10.55.56.213 with SMTP id f204mr42777184qka.78.1434211648617; Sat, 13 Jun 2015 09:07:28 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id 139sm3342451qhx.22.2015.06.13.09.07.27 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 13 Jun 2015 09:07:28 -0700 (PDT) From: Dave Garrett To: Ilari Liusvaara Date: Sat, 13 Jun 2015 12:07:26 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201506111558.21577.davemgarrett@gmail.com> <201506121236.18304.davemgarrett@gmail.com> <20150613102434.GA16258@LK-Perkele-VII> In-Reply-To: <20150613102434.GA16258@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201506131207.27048.davemgarrett@gmail.com> Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2015 16:07:30 -0000 On Saturday, June 13, 2015 06:24:34 am Ilari Liusvaara wrote: > ???? TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 > ???? TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 > ???? TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 > ???? TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA256 > ???? TLS_ECDHE_PSK_WITH_AES_128_CCM8_SHA256 > ???? TLS_ECDHE_PSK_WITH_AES_256_CCM8_SHA256 > ???? TLS_ECDHE_PSK_WITH_ARIA_128_GCM_SHA256 > ???? TLS_ECDHE_PSK_WITH_ARIA_256_GCM_SHA384 > ???? TLS_ECDHE_PSK_WITH_CAMELLIA_128_GCM_SHA256 > ???? TLS_ECDHE_PSK_WITH_CAMELLIA_256_GCM_SHA384 > ???? TLS_ECDHE_anon_WITH_AES_128_GCM_SHA256 > ???? TLS_ECDHE_anon_WITH_AES_256_GCM_SHA384 > ???? TLS_ECDHE_anon_WITH_AES_128_CCM_SHA256 > ???? TLS_ECDHE_anon_WITH_AES_256_CCM_SHA256 > ???? TLS_ECDHE_anon_WITH_AES_128_CCM8_SHA256 > ???? TLS_ECDHE_anon_WITH_AES_256_CCM8_SHA256 > ???? TLS_ECDHE_anon_WITH_ARIA_128_GCM_SHA256 > ???? TLS_ECDHE_anon_WITH_ARIA_256_GCM_SHA384 > ???? TLS_ECDHE_anon_WITH_CAMELLIA_128_GCM_SHA256 > ???? TLS_ECDHE_anon_WITH_CAMELLIA_256_GCM_SHA384 I think a single new "AEAD ECDHE PSK and anonymous cipher suites for TLS" I-D could cover the above. I found two expired drafts that this would be replacing, in addition to new definitions: https://tools.ietf.org/html/draft-williams-tls-anon-ecdh-modern-cipher-01 (AES-GCM&CCM anon) https://tools.ietf.org/html/draft-schmertmann-dice-ccm-psk-pfs-01 (AES-CCM PSK) Alternatively, if we just want to focus on standards track, a new I-D for just ECDHE AES AEAD cipher suites could cover: TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA256 TLS_ECDHE_PSK_WITH_AES_128_CCM8_SHA256 TLS_ECDHE_PSK_WITH_AES_256_CCM8_SHA256 TLS_ECDHE_anon_WITH_AES_128_GCM_SHA256 TLS_ECDHE_anon_WITH_AES_256_GCM_SHA384 TLS_ECDHE_anon_WITH_AES_128_CCM_SHA256 TLS_ECDHE_anon_WITH_AES_256_CCM_SHA256 TLS_ECDHE_anon_WITH_AES_128_CCM8_SHA256 TLS_ECDHE_anon_WITH_AES_256_CCM8_SHA256 Plus, it could promote the RFC 7251 suites to standards track: TLS_ECDHE_ECDSA_WITH_AES_128_CCM = {0xC0,0xAC} TLS_ECDHE_ECDSA_WITH_AES_256_CCM = {0xC0,0xAD} TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 = {0xC0,0xAE} TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 = {0xC0,0xAF} At the moment, CCM is in the odd situation where DHE CCM is standards track but ECDHE CCM is informational. > ???? TLS_ECDHE_anon_WITH_CHACHA20_POLY1305_SHA256 This could just get added to the current ChaChaPoly draft. Dave From nobody Sat Jun 13 09:12: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 E84431AC3FC for ; Sat, 13 Jun 2015 09:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWvGR7SRFhJa for ; Sat, 13 Jun 2015 09:12:34 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 4E5691AC3FE for ; Sat, 13 Jun 2015 09:12:34 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id A7254287FA; Sat, 13 Jun 2015 16:12:33 +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 92C10287F6; Sat, 13 Jun 2015 16:12:33 +0000 (GMT) Received: from email.msg.corp.akamai.com (ustx2ex-cas3.msg.corp.akamai.com [172.27.25.32]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 79EAE2038; Sat, 13 Jun 2015 16:12:33 +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.1076.9; Sat, 13 Jun 2015 11:12:32 -0500 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.1076.000; Sat, 13 Jun 2015 11:12:32 -0500 From: "Salz, Rich" To: Dave Garrett , Ilari Liusvaara Thread-Topic: [TLS] A la carte handshake negotiation Thread-Index: AQHQpSquSZGiiXjAJ0SzG41a/9YoRp2pYXmAgAAD0oCAASp5AIAAX8wA//+tL/A= Date: Sat, 13 Jun 2015 16:12:32 +0000 Message-ID: References: <201506111558.21577.davemgarrett@gmail.com> <201506121236.18304.davemgarrett@gmail.com> <20150613102434.GA16258@LK-Perkele-VII> <201506131207.27048.davemgarrett@gmail.com> In-Reply-To: <201506131207.27048.davemgarrett@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.56.150] 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] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2015 16:12:36 -0000 I think this is headed in the wrong direction. We want to minimize the number of ciphers and cipher-suites, not allow for = a mind-boggling combinatorial explosion that will cripple interop. From nobody Sat Jun 13 09:30: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 DDBF01A1B0D for ; Sat, 13 Jun 2015 09:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYDHEfFIFOMW for ; Sat, 13 Jun 2015 09:30:05 -0700 (PDT) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::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 873EC1A010F for ; Sat, 13 Jun 2015 09:30:05 -0700 (PDT) Received: by qcnj1 with SMTP id j1so17337107qcn.0 for ; Sat, 13 Jun 2015 09:30:04 -0700 (PDT) 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=95l0dmYVy079WJaJgScbMR95fglOgaNi4Z5NHgiH7iI=; b=mtHsAZgrq2WHu1633xD+ZL66arWiZXtsuZ2BnT7mzY2KdC3hhQBwXMmad+Q0K/Guuf SPToSp9GxKSVclwpvU790cQfnbJvaYDr1JxwUQKTXzNEjqxuN4GFZK2gBHTYWGrb3stW Cu5INGj8iE2T7sgqzXodW+6BmXvC5iH3q4N7i76RbK2ZuRuqlaIeuprEkBAkBH2l2WIY TH/nsNWDTCuOUnHibR7vyaYIYbEy7US0wbgehJX6ONenU4lEwaC1HbAkd1xRhb2VJcyU KLz85qjkMPgZN9SnsXRRyWhruj8+4PHX7NCecoCmxCBq9HRcOpTTumkiZjpS2EpPEH71 sz7A== X-Received: by 10.140.238.87 with SMTP id j84mr26269029qhc.29.1434213004849; Sat, 13 Jun 2015 09:30:04 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id b82sm3390951qkh.36.2015.06.13.09.30.04 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 13 Jun 2015 09:30:04 -0700 (PDT) From: Dave Garrett To: "Salz, Rich" Date: Sat, 13 Jun 2015 12:30:03 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201506111558.21577.davemgarrett@gmail.com> <201506131207.27048.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201506131230.03552.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2015 16:30:07 -0000 On Saturday, June 13, 2015 12:12:32 pm Salz, Rich wrote: > I think this is headed in the wrong direction. > > We want to minimize the number of ciphers and cipher-suites, not allow for a mind-boggling combinatorial explosion that will cripple interop. It's mostly just the ECDHE AEAD PSK & anon suites that never got defined for one reason or another. With this a la carte proposal, TLS 1.3 would only use ECDHE suites and be able to negotiate DHE or ECDHE using it. The number of suites would go down, overall; it'd just have these new ones for PSK & anon. The normal RSA/ECDSA suites that would be needed would drop in quantity far more drastically. The idea is to just move to all suites being to defined for just ECDHE_{ECDSA|PSK|anon} and drop all {DH|DHE|ECDH}_* and ECDHE_{RSA|DSS}. Technically, we could allow DHE_anon & DHE_PSK to negotiate ECDHE or DHE via the extension, but we'd like to deprecate all the old DHE suites to avoid even the possibility of negotiating weak groups. It would also make the valid TLS 1.3+ suites all start with ECDHE (with the exception of plain PSK, if that has to be kept around). Note that the list of AES AEAD suites could be pruned down notably if CCM8 was dropped in favor of CCM16 only (or vice versa). Dave From nobody Sat Jun 13 11:28: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 017241ACD8B for ; Sat, 13 Jun 2015 11:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.788 X-Spam-Level: X-Spam-Status: No, score=-0.788 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, J_CHICKENPOX_35=0.6, 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 zDutzsNuf4SP for ; Sat, 13 Jun 2015 11:28:19 -0700 (PDT) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::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 288881ACD57 for ; Sat, 13 Jun 2015 11:28:19 -0700 (PDT) Received: by igblz2 with SMTP id lz2so28339240igb.1 for ; Sat, 13 Jun 2015 11:28:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=6gAiIO/HCvDAjeeaepiEESlV2fR/O7aFgv2s+jYCPP4=; b=ohA4SpnezrZ7GUpWLPP+bfxg0LYk8FxGZZHvYdDovNH6lhkm6xvJF7bE8EJttVMCVc sctPd45Nv0coDBo3aEJT83UfgxR1ZKG9eLhRJx8G7XP3FMdy0iSXcbq1uZ9xFnMW8So3 +HlC5obAmMwpK/8Xd1RSoUHY7EXCI1IWL7vrE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; bh=6gAiIO/HCvDAjeeaepiEESlV2fR/O7aFgv2s+jYCPP4=; b=eTskIgzQDweAKokOf6Kvrcb2sZ3aEKhbScbVYw4YH2gMKritxexpHHWBjIZhf0vxEn zJvBR+bKDlY59zFVMJN1mM+a2B209iUSlXXEfLVyLXM0o+zQMna8AKRlf/OWWJopNk3k 8YtLKaaRW5rfK9hAartDwrjDWU0GXrLXcWib1PBn6PG/werbmoBluXIRu8bzz9/HIQq7 fw7hB2uqDd1ATKVaUp74dGjQKwd2Ob7DK0qti492vqtlI9mWRzlOL7t+6oaMxY4tYpMB A9TGe3hcbk9fmCUFO6TWY/ZXPdhyfhLT5cBxnUBwKmHikdelGoJ5R1sSzxRZAtc2vNoG HOKw== X-Gm-Message-State: ALoCoQmUf3p04ov4qoTwpDS4nrdXsAgAtZSyvNIGCRT9X4UUal9Oxr4RSVC/bGa1WpZ88MRKVlH4 X-Received: by 10.107.34.193 with SMTP id i184mr2561274ioi.56.1434220098356; Sat, 13 Jun 2015 11:28:18 -0700 (PDT) MIME-Version: 1.0 References: <201506111558.21577.davemgarrett@gmail.com> In-Reply-To: <201506111558.21577.davemgarrett@gmail.com> From: David Benjamin Date: Sat, 13 Jun 2015 18:28:06 +0000 Message-ID: To: Dave Garrett , "" Content-Type: multipart/alternative; boundary=001a1140e7867e36e905186a6311 Archived-At: Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2015 18:28:21 -0000 --001a1140e7867e36e905186a6311 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jun 11, 2015 at 3:58 PM Dave Garrett wrote= : > * TLS 1.3 implementations negotiate ECDHE/DHE & RSA/DSS/ECDSA solely via > the "supported_groups" & "signature_algorithms" extensions. > [...] > 4) All TLS 1.3 implementations are expected to be able to handle ECC, but > are not required to offer or negotiate it. (at least, here) > Are you sure this proposal completely achieves that? I believe, by using ECDHE_ECDSA as the representative key exchange, this effectively requires all clients to offer the ECDHE_ECDSA variant of every bulk cipher. ECDSA is negotiable pre-TLS-1.2, so you can't rely on an ECDSA-less signature_algorithms to disable things on TLS 1.1 servers (though hopefully ECDSA deployments all speak 1.2). Plus, if I'm reading this code right, OpenSSL didn't disable cipher suites based on signature_algorithms until 1.0.2. I haven't tested this, however. (It's hard to be sure of the behavior. RSA+ECDSA deployments probably aren't that common. Those that exist probably do custom things in callbacks, so who knows what they check. The built-in mechanism is slightly odd.) On the ECDHE side of things, OpenSSL 1.0.1 has two APIs for configuring ECDHE groups. The saner one (SSL_CTX_set_tmp_ecdh) has you just pick a group, and that seems to honor supported_curves fine. But there's also SSL_CTX_set_tmp_ecdh_callback. That callback is called very late, so I believe OpenSSL won't fall back to a different cipher suite. (OpenSSL will also treat missing supported_curves as "pick anything", not "don't do ECC".= ) At a glance, I wasn't able to find any popular server software that used SSL_CTX_set_tmp_ecdh_callback (it's kind of a weird API...). Though apparently Android's SSLServerSocket API does. Personally, mandatory ECDHE seems just fine. Still, something to be aware of. ECDSA might be more of a nuisance. At least as things stand currently, Chrome does not offer ECDSA suites on Windows XP because the system certificate verifier can't handle it. In general, I wouldn't expect filtering out cipher suites based on signature_algorithms/supported_curves to be a well-tested path in servers. You could easily mess it up and never notice. It's partially redundant with the cipher list and my unscientific impression is there's not much variance. (I expect most everyone supports and uses P-256.) Wouldn't it be simpler to just add a supported_aeads extension and make the cipher suite list meaningless for 1.3? With all the obsolete ciphers gone, most clients would probably only offer 2-3 of them. The interop risks of a bad compatibility cipher suite list seem simple enough. Ensure that: {legacy cipher list} =E2=88=A9 {all 1.3 combos} =E2=8A=86 {key ex.} =C3= =97 {sig alg.} =C3=97 {aeads} But I haven't thought about this very hard and haven't been following the topic, so that may be opening a huge can of worms. David --001a1140e7867e36e905186a6311 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jun 11= , 2015 at 3:58 PM Dave Garrett <davemgarrett@gmail.com> wrote:
* TLS 1.3 implementations negotiate ECDHE/DHE & RSA/DSS/ECDSA solely vi= a the "supported_groups" & "signature_algorithms" e= xtensions.
[...]
4) All TLS 1.3 implementations are expected to be able to handle ECC, but a= re not required to offer or negotiate it. (at least, here)
=

Are you sure this proposal completely achieves that? I = believe, by using ECDHE_ECDSA as the representative key exchange, this effe= ctively requires all clients to offer the ECDHE_ECDSA variant of every bulk= cipher.

ECDSA is negotiable pre-TLS-1.2, so y= ou can't rely on an ECDSA-less signature_algorithms to disable things o= n TLS 1.1 servers (though hopefully ECDSA deployments all speak 1.2). Plus,= if I'm reading this code right, OpenSSL didn't disable cipher suit= es based on signature_algorithms until 1.0.2. I haven't tested this, ho= wever. (It's hard to be sure of the behavior. RSA+ECDSA deployments pro= bably aren't that common. Those that exist probably do custom things in= callbacks, so who knows what they check. The built-in mechanism is slightl= y odd.)

On the ECDHE side of things, OpenSSL 1.0.1 has two APIs for = configuring ECDHE groups. The saner one (SSL_CTX_set_tmp_ecdh) has you just= pick a group, and that seems to honor supported_curves fine. But there'= ;s also=C2=A0SSL_CTX_set_tmp_ecdh_callback. That callback is called very la= te, so I believe OpenSSL won't fall back to a different cipher suite. (= OpenSSL will also treat missing supported_curves as "pick anything&quo= t;, not "don't do ECC".)

At a glance, I wasn't abl= e to find any popular server software that used SSL_CTX_set_tmp_ecdh_callba= ck (it's kind of a weird API...). Though apparently Android's SSLSe= rverSocket API does.

Personally, mandatory ECDHE seems just fine. St= ill, something to be aware of.=C2=A0ECDSA might be more of a nuisance. At l= east as things stand currently, Chrome does not offer ECDSA suites on Windo= ws XP because the system certificate verifier can't handle it.

I= n general, I wouldn't expect filtering out cipher suites based on signa= ture_algorithms/supported_curves to be a well-tested path in servers. You c= ould easily mess it up and never notice. It's partially redundant with = the cipher list and my unscientific impression is there's not much vari= ance. (I expect most everyone supports and uses P-256.)

Wouldn't= it be simpler to just add a supported_aeads extension and make the cipher = suite list meaningless for 1.3? With all the obsolete ciphers gone, most cl= ients would probably only offer 2-3 of them.=C2=A0The interop risks of a ba= d compatibility cipher suite list seem simple enough. Ensure that:

=C2=A0 {legacy cipher list}=C2=A0=E2=88=A9 {all 1.3 combos}=C2=A0=E2= =8A=86 {key ex.}=C2=A0=C3=97 {sig alg.}=C2=A0=C3=97 {aeads}

<= /div>
But I haven't thought about this very hard and haven't be= en following the topic, so that may be opening a huge can of worms.

=
David
--001a1140e7867e36e905186a6311-- From nobody Sat Jun 13 11:59: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 E57241A8940 for ; Sat, 13 Jun 2015 11:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-gyempZSrIG for ; Sat, 13 Jun 2015 11:59:34 -0700 (PDT) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) (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 474801A88ED for ; Sat, 13 Jun 2015 11:59:34 -0700 (PDT) Received: by qcnj1 with SMTP id j1so17827238qcn.0 for ; Sat, 13 Jun 2015 11:59:33 -0700 (PDT) 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=RRiAoS9C70SQ801PROhC4yuCfP9B16DQZ9v2jEM2VGQ=; b=ytPjvp+umKflGcipxaN8NmaWre4tDGdhPnbEX6Rznx42a3jSj5XP5muqddOafN38ek N4Chbt33wLmsUBvFMH9BDi+gEZPH0s/L3dyqY4XTTzvtWHuAAF9w3OnD2Ys72haiLkxI 16J4NLMf2JX8a9ybvxEPC+HWY0nDX0GT+lqpZoMgpPePQ2jA5/OrBd7eufXMixCIuxNa iiLZh9sOrBf/6kQt/tMMgsXhJyowPyeg60ekTyfcQfLfYur1EeOH0KGORccYn351/Rhk x3iZO4HqXqMXGEYT1UkduuxP1/K7hd5iGwVHWk1xTpfCEVRtIdfAKAlEDj072sXtMPIo rBNQ== X-Received: by 10.55.40.199 with SMTP id o68mr43924941qko.23.1434221973353; Sat, 13 Jun 2015 11:59:33 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id e71sm3578215qka.40.2015.06.13.11.59.32 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 13 Jun 2015 11:59:32 -0700 (PDT) From: Dave Garrett To: David Benjamin Date: Sat, 13 Jun 2015 14:59:31 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201506111558.21577.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201506131459.31745.davemgarrett@gmail.com> Archived-At: Cc: "" Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2015 18:59:36 -0000 On Saturday, June 13, 2015 02:28:06 pm David Benjamin wrote: > On Thu, Jun 11, 2015 at 3:58 PM Dave Garrett wro= te: > > * TLS 1.3 implementations negotiate ECDHE/DHE & RSA/DSS/ECDSA solely via > > the "supported_groups" & "signature_algorithms" extensions. > > [...] > > 4) All TLS 1.3 implementations are expected to be able to handle ECC, b= ut > > are not required to offer or negotiate it. (at least, here) >=20 > Are you sure this proposal completely achieves that? I believe, by using > ECDHE_ECDSA as the representative key exchange, this effectively requires > all clients to offer the ECDHE_ECDSA variant of every bulk cipher. Yes, for TLS 1.3 negotiation, offering the ECDHE_ECDSA would be required un= der this proposal. [snip] > Personally, mandatory ECDHE seems just fine. Still, something to be aware > of. ECDSA might be more of a nuisance. At least as things stand currently, > Chrome does not offer ECDSA suites on Windows XP because the system > certificate verifier can't handle it. At some point, clients that want to continue supporting EOL OSes forever ar= e going to have to roll their own implementations of modern crypto instead = of attempting to rely on the OS. Either that, or drop support. [snip] > Wouldn't it be simpler to just add a supported_aeads extension and make t= he > cipher suite list meaningless for 1.3? With all the obsolete ciphers gone, > most clients would probably only offer 2-3 of them. The interop risks of a > bad compatibility cipher suite list seem simple enough. Ensure that: >=20 > {legacy cipher list} =E2=88=A9 {all 1.3 combos} =E2=8A=86 {key ex.} =C3= =97 {sig alg.} =C3=97 {aeads} >=20 > But I haven't thought about this very hard and haven't been following the > topic, so that may be opening a huge can of worms. That's essentially the nuke it all from orbit, just to be sure, solution. ;) I'm not against it. It would trade one form of complexity (reduced suites += existing extensions) for a new form of complexity (existing extensions + a= new extension), but that could be worth it and simpler overall. If we want= to make absolutely sure TLS 1.2 backwards compatibility and TLS 1.3 suppor= t are separate, this is the way to do it. The largest benefit of this approach might actually just be dropping the ne= ed to define the missing ECDHE_* suites to fill in the gaps that got overlo= oked (e.g. expired drafts). The whole extension and its initial codepoint a= ssignments could be defined in the TLS 1.3 spec. It wouldn't be quite as simple as you propose, though, because we'd definit= ely have to add a new way to declare anon or PSK support via extensions, bu= t that's doable. That said, there was push back against full a la carte in previous discussi= on on this list. The reason for ending up at this proposal was the desire t= o use _existing_ systems (ciphers + existing extensions) in a consistent ma= nner to negotiate things with fewer suites, rather than overhaul everything= =2E=20 I'm perfectly willing to throw out my draft proposal and switch to this str= ategy if we agree it is worth implementing. Obsoleting the entire cipher su= ite system would be opening a can of worms, but it might be a smaller can o= f worms than we currently have to deal with. Dave From nobody Sat Jun 13 12:19: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 7440C1A8ADD for ; Sat, 13 Jun 2015 12:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 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, 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 Ax0IozwxTe61 for ; Sat, 13 Jun 2015 12:19:32 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (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 8267E1A8A80 for ; Sat, 13 Jun 2015 12:19:32 -0700 (PDT) Received: by iesa3 with SMTP id a3so41443921ies.2 for ; Sat, 13 Jun 2015 12:19:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=qWjY12uPmg8sj71WDfwv0MJhDqMnMX3m9VGl8Nxq1lQ=; b=gh9MZzTE2PjLmNQDhtzD1xC3LdHGQsqvwVDQBDyRK7yF9hckfjv/CIDRFbzgU0dAG7 wlk9xWyD8AFwCTCDPEkMsenSRrij9rGytufK2wRUpNET65I0TZuZs+NhJJqZaccWJsGZ 12jC2OiyxwJ3bB3kK643GbKeqfUSXSbnWWWxs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=qWjY12uPmg8sj71WDfwv0MJhDqMnMX3m9VGl8Nxq1lQ=; b=eIgczjMDlJrEWpIiEPS/dcdR26pTHzRAFUaSwpThw5eQtloHMKNmAnqQ9GDD7USLxF vFUnr2PXRZ6Glvsyhwm1+23hJGhhin9zCZN+9EgL5q2BYBL81nDztPAPh2Prqb6cAwUC WSZc5MqT77DwxNxPdN4ozkDjyrUd0oRSYC54bCME58fRdH3XxhnycCnpPmRXv6b7CqY3 Mi/GF2eCphocUSlya099cg5cePKrceD3MtRK4R4uU78+br4CwquVj8Z8EGPh1di/lQB5 Vo7Z9IKNUZRMxbS8A9POVxHdXgQQpXzr680aXa4qvs8+h+mNEr54/O5WVKxGkxODZjVc pUtw== X-Gm-Message-State: ALoCoQkaK2vUnecpYwazHGAMnu6yYlX0yQwORoe6a35VnkP+3tA0xCSi2TCvTVMWXG4BqpbSmTeX X-Received: by 10.50.79.169 with SMTP id k9mr11684317igx.44.1434223171780; Sat, 13 Jun 2015 12:19:31 -0700 (PDT) MIME-Version: 1.0 References: <201506111558.21577.davemgarrett@gmail.com> <201506131459.31745.davemgarrett@gmail.com> In-Reply-To: <201506131459.31745.davemgarrett@gmail.com> From: David Benjamin Date: Sat, 13 Jun 2015 19:19:20 +0000 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=089e013a01c8af2a1b05186b1aed Archived-At: Cc: "" Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2015 19:19:34 -0000 --089e013a01c8af2a1b05186b1aed Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Jun 13, 2015 at 2:59 PM Dave Garrett wrote= : > On Saturday, June 13, 2015 02:28:06 pm David Benjamin wrote: > > On Thu, Jun 11, 2015 at 3:58 PM Dave Garrett > wrote: > > > * TLS 1.3 implementations negotiate ECDHE/DHE & RSA/DSS/ECDSA solely > via > > > the "supported_groups" & "signature_algorithms" extensions. > > > [...] > > > 4) All TLS 1.3 implementations are expected to be able to handle ECC, > but > > > are not required to offer or negotiate it. (at least, here) > > > > Are you sure this proposal completely achieves that? I believe, by usin= g > > ECDHE_ECDSA as the representative key exchange, this effectively requir= es > > all clients to offer the ECDHE_ECDSA variant of every bulk cipher. > > Yes, for TLS 1.3 negotiation, offering the ECDHE_ECDSA would be required > under this proposal. > Perhaps I'm misunderstanding your goals here then. My read of (4) above was that this was intended to use the ECDHE_ECDSA representative of, say, AES_128_GCM as the spelling of AES_128_GCM (so effectively repurposing the cipher list as the list of AEADs[*]), and that this wouldn't actually translate to offering ECDHE_ECDSA due to that really being negotiated by the other two extensions. But this doesn't seem to be completely the case because the ClientHello is interpreted by both TLS 1.3 servers and existing servers. And so we need to consider the effects on both to avoid interop. issues. [*] As you say below, not quite because you still premultiply the really exotic things like PSK and anon. But setting those aside for the sake of discussion. David > [snip] > > Personally, mandatory ECDHE seems just fine. Still, something to be awa= re > > of. ECDSA might be more of a nuisance. At least as things stand > currently, > > Chrome does not offer ECDSA suites on Windows XP because the system > > certificate verifier can't handle it. > > At some point, clients that want to continue supporting EOL OSes forever > are going to have to roll their own implementations of modern crypto > instead of attempting to rely on the OS. Either that, or drop support. > > [snip] > > Wouldn't it be simpler to just add a supported_aeads extension and make > the > > cipher suite list meaningless for 1.3? With all the obsolete ciphers > gone, > > most clients would probably only offer 2-3 of them. The interop risks o= f > a > > bad compatibility cipher suite list seem simple enough. Ensure that: > > > > {legacy cipher list} =E2=88=A9 {all 1.3 combos} =E2=8A=86 {key ex.} = =C3=97 {sig alg.} =C3=97 > {aeads} > > > > But I haven't thought about this very hard and haven't been following t= he > > topic, so that may be opening a huge can of worms. > > That's essentially the nuke it all from orbit, just to be sure, solution. > ;) > > I'm not against it. It would trade one form of complexity (reduced suites > + existing extensions) for a new form of complexity (existing extensions = + > a new extension), but that could be worth it and simpler overall. If we > want to make absolutely sure TLS 1.2 backwards compatibility and TLS 1.3 > support are separate, this is the way to do it. > > The largest benefit of this approach might actually just be dropping the > need to define the missing ECDHE_* suites to fill in the gaps that got > overlooked (e.g. expired drafts). The whole extension and its initial > codepoint assignments could be defined in the TLS 1.3 spec. > > It wouldn't be quite as simple as you propose, though, because we'd > definitely have to add a new way to declare anon or PSK support via > extensions, but that's doable. > > That said, there was push back against full a la carte in previous > discussion on this list. The reason for ending up at this proposal was th= e > desire to use _existing_ systems (ciphers + existing extensions) in a > consistent manner to negotiate things with fewer suites, rather than > overhaul everything. > > I'm perfectly willing to throw out my draft proposal and switch to this > strategy if we agree it is worth implementing. Obsoleting the entire ciph= er > suite system would be opening a can of worms, but it might be a smaller c= an > of worms than we currently have to deal with. > > > Dave > --089e013a01c8af2a1b05186b1aed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Jun 13= , 2015 at 2:59 PM Dave Garrett <davemgarrett@gmail.com> wrote:
On Saturday, June 13, 2015 02:28:06 pm David Benjamin wrote:
> On Thu, Jun 11, 2015 at 3:58 PM Dave Garrett <davemgarrett@gmail.com> wrote= :
> > * TLS 1.3 implementations negotiate ECDHE/DHE & RSA/DSS/ECDSA= solely via
> > the "supported_groups" & "signature_algorithms= " extensions.
> > [...]
> > 4) All TLS 1.3 implementations are expected to be able to handle = ECC, but
> > are not required to offer or negotiate it. (at least, here)
>
> Are you sure this proposal completely achieves that? I believe, by usi= ng
> ECDHE_ECDSA as the representative key exchange, this effectively requi= res
> all clients to offer the ECDHE_ECDSA variant of every bulk cipher.

Yes, for TLS 1.3 negotiation, offering the ECDHE_ECDSA would be required un= der this proposal.

Perhaps I'm misunderstandin= g your goals here then. My read of (4) above was that this was intended to = use the ECDHE_ECDSA representative of, say, AES_128_GCM as the spelling of = AES_128_GCM (so effectively repurposing the cipher list as the list of AEAD= s[*]), and that this wouldn't actually translate to offering ECDHE_ECDS= A due to that really being negotiated by the other two extensions.

But this doesn't seem to be completely the case becaus= e the ClientHello is interpreted by both TLS 1.3 servers and existing serve= rs. And so we need to consider the effects on both to avoid interop. issues= .

[*] As you say below, not quite because you stil= l premultiply the really exotic things like PSK and anon. But setting those= aside for the sake of discussion.

David
=C2=A0
[snip]
> Personally, mandatory ECDHE seems just fine. Still, something to be aw= are
> of. ECDSA might be more of a nuisance. At least as things stand curren= tly,
> Chrome does not offer ECDSA suites on Windows XP because the system > certificate verifier can't handle it.

At some point, clients that want to continue supporting EOL OSes forever ar= e going to have to roll their own implementations of modern crypto instead = of attempting to rely on the OS. Either that, or drop support.

[snip]
> Wouldn't it be simpler to just add a supported_aeads extension and= make the
> cipher suite list meaningless for 1.3? With all the obsolete ciphers g= one,
> most clients would probably only offer 2-3 of them. The interop risks = of a
> bad compatibility cipher suite list seem simple enough. Ensure that: >
>=C2=A0 =C2=A0{legacy cipher list} =E2=88=A9 {all 1.3 combos} =E2=8A=86 = {key ex.} =C3=97 {sig alg.} =C3=97 {aeads}
>
> But I haven't thought about this very hard and haven't been fo= llowing the
> topic, so that may be opening a huge can of worms.

That's essentially the nuke it all from orbit, just to be sure, solutio= n. ;)

I'm not against it. It would trade one form of complexity (reduced suit= es + existing extensions) for a new form of complexity (existing extensions= + a new extension), but that could be worth it and simpler overall. If we = want to make absolutely sure TLS 1.2 backwards compatibility and TLS 1.3 su= pport are separate, this is the way to do it.

The largest benefit of this approach might actually just be dropping the ne= ed to define the missing ECDHE_* suites to fill in the gaps that got overlo= oked (e.g. expired drafts). The whole extension and its initial codepoint a= ssignments could be defined in the TLS 1.3 spec.

It wouldn't be quite as simple as you propose, though, because we'd= definitely have to add a new way to declare anon or PSK support via extens= ions, but that's doable.

That said, there was push back against full a la carte in previous discussi= on on this list. The reason for ending up at this proposal was the desire t= o use _existing_ systems (ciphers + existing extensions) in a consistent ma= nner to negotiate things with fewer suites, rather than overhaul everything= .

I'm perfectly willing to throw out my draft proposal and switch to this= strategy if we agree it is worth implementing. Obsoleting the entire ciphe= r suite system would be opening a can of worms, but it might be a smaller c= an of worms than we currently have to deal with.


Dave
--089e013a01c8af2a1b05186b1aed-- From nobody Sat Jun 13 12:34: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 4F5D91ACDF1 for ; Sat, 13 Jun 2015 12:34:41 -0700 (PDT) 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=[BAYES_50=0.8, 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 l7kxnuwDVpRc for ; Sat, 13 Jun 2015 12:34:40 -0700 (PDT) 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 EEDDF1ACE0A for ; Sat, 13 Jun 2015 12:34:39 -0700 (PDT) Received: by wibdq8 with SMTP id dq8so42567510wib.1 for ; Sat, 13 Jun 2015 12:34:38 -0700 (PDT) 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:mime-version :content-type:content-disposition:user-agent; bh=pvfEns+7pKl4WNj/WBbhL+/+KYpptom8gaVmJQAXJ58=; b=fjNd18lP550SOknmiGs7b0pzDd75GGTev69nLrXlOakFleFSFaKshFFUWnEwZYsyHd 3t2CpRpfUeqd0Faczwb+kkhwhq/S5CnbdcEiNINmhZngXyH0YqS6IldNfMZj8YlVTC/C eYp2fgixFoW+klOdgybypecwso31do7uXEk3Qr/EapfstQCyAYG7MEpwxVKMkbfJVk5S UczoP7BlOa7msVK8Qhh9cmmIvh245njbAjifKC5Q0Byt8dwP62ABmvldyPBTfrtuRN+z 6P2WxerDGt4ffhMtiM76y5HiVoCT2dGWqOCQZkqbNVEo9O/uX1ug/gZRWR9+LqC06SVA wTUA== X-Gm-Message-State: ALoCoQmRpPDWqD3hp8DI5SngiEvUAunnnhhHvsomSxPXc1dqhBLNyoVw6UKmVcBxIgwC+G6VKy6q X-Received: by 10.194.237.34 with SMTP id uz2mr38167464wjc.155.1434224078666; Sat, 13 Jun 2015 12:34:38 -0700 (PDT) Received: from typhoon.azet.org (chello080108032135.14.11.univie.teleweb.at. [80.108.32.135]) by mx.google.com with ESMTPSA id q4sm11543198wju.14.2015.06.13.12.34.37 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 13 Jun 2015 12:34:37 -0700 (PDT) Date: Sat, 13 Jun 2015 21:34:45 +0200 From: Aaron Zauner To: tls@ietf.org Message-ID: <20150613193444.GA31312@typhoon.azet.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="bp/iNruPH9dso1Pn" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: [TLS] What's up with TACK? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2015 19:34:41 -0000 --bp/iNruPH9dso1Pn Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Hey, I've been meaning to write this message for almost a year now. I've not seen any recent discussion on generic key pinning on this list. We now have HPKP support in major browsers but protocols like STARTTLS are still left our when it comes to pinning. Discussion on TACK seemed to have died during the HPKP proposal somehow, yet it's the more elegant, generic approach to key pinning in TLS. Although the spec is confusing I have no problem with HPKP as is and I'm happy that it's in roll-out phase. I'd like to see discussion on TACK again. Actually I don't understand why this proposal was never adopted by the WG. Thanks for your time, Aaron --bp/iNruPH9dso1Pn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVfIXUAAoJEOTbZJL9ubXVxwoP/0NoH48ioRThg1Jp2czemJEk Sbk2tDGzufYg+C5FHV+25aVQlOiC3K1islskAvQAqnpcyulteoFboQiggW+W7p2z QiCAh9SNp6fUyEKSBWN1dShvbEF17nGYI/8ATmxs7rmgh73hMPAwR7S9wyE1/Eer F3ZIlZSsZqmNw9t+WJLP2YzpJn1DKyxgktDwJewA1JuegPJk7wq3rWaGcqEPyiSq H+2pIQYkjYQE3vHM6NZ1C/fWBiGOpjPpavVLmFkKRBknLpxPm9zmFcW/OTYWSpxw eVNUBvSgsQcufxHCNXQ6SVejBdZusE+EcZaH4LcL9OOR5oezRbSSVfJgEtdu0a7N S2omL/K16/EFV2T6cW/Uo86vnqynbv3bvz8WU2SdUHHokpNE+PcVGeqlOjxC1mKS 9Z4tCiwI4YRYoK58LiFb9VOhFPCN/0qjlKsygf2+cg2cYCwCLS+vtiI9YCu7Ugl3 B+OSZzWi9tAjkM3Bam33RV2LsxhqClty2WymDpHY296YFYGMZ2iHC0XzAnKk0KrK jREihg7ge05Mndz4UY6745g8pvkvtdk6prEiLZnuD0lLW66SwT8DNwdVU2VeYfoY DpvMsISHoC/OOckyENyIzGDxndUk9ARVtlJi3Fay/EBOfT4QIK4z3OA+0tW4yzDA HHWNDHjspYugCty8Sf+s =LSL8 -----END PGP SIGNATURE----- --bp/iNruPH9dso1Pn-- From nobody Sat Jun 13 12:47: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 9209F1ACE5C for ; Sat, 13 Jun 2015 12:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yL1wU2nRc4hJ for ; Sat, 13 Jun 2015 12:47:33 -0700 (PDT) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::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 ED4A21ACE5B for ; Sat, 13 Jun 2015 12:47:32 -0700 (PDT) Received: by qcnj1 with SMTP id j1so17956032qcn.0 for ; Sat, 13 Jun 2015 12:47:32 -0700 (PDT) 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=TSDmlb4MOdfPTYLsfZcN6ltF/COKvgKwr+omcSVkc+A=; b=o72c40HynwsVm+wUGewP0u6bInExJxWnfx4ZQrVGVxu22zDCBQxQq6Ljm9yIBvMhbT 6ZfqwRmQeyLHMeJ+sUDGCOlV+4Bfog4OZeeRVw2wC5dcogzhFyni2gN18czGL+PRwLny GwbxpW5iweeN/s1RH2+fOcgPbui6BbHFNcHXAipRUzwiB5Wckn6Nr6kYHTvJzFO7qhOk Gk2q3dC4MOjE5u6n4caDeN5rM5Ys6SaYc/ZlVVkC+4nhfhI6Iy4ttXvrtuXDIgg9X8Mf zIKL0X3bc9RamK05P7h63Fw+4ADiTPAT+oeHE2QCE8S6YCnMK+BVjpkhSkZylI3bAFCq Lp7A== X-Received: by 10.55.53.207 with SMTP id c198mr20957852qka.48.1434224852294; Sat, 13 Jun 2015 12:47:32 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id 97sm1153648qgl.4.2015.06.13.12.47.31 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 13 Jun 2015 12:47:31 -0700 (PDT) From: Dave Garrett To: David Benjamin Date: Sat, 13 Jun 2015 15:47:29 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201506111558.21577.davemgarrett@gmail.com> <201506131459.31745.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201506131547.30428.davemgarrett@gmail.com> Archived-At: Cc: "" Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2015 19:47:34 -0000 On Saturday, June 13, 2015 03:19:20 pm David Benjamin wrote: > On Sat, Jun 13, 2015 at 2:59 PM Dave Garrett wrote: > > Yes, for TLS 1.3 negotiation, offering the ECDHE_ECDSA would be required > > under this proposal. > > Perhaps I'm misunderstanding your goals here then. My read of (4) above was > that this was intended to use the ECDHE_ECDSA representative of, say, > AES_128_GCM as the spelling of AES_128_GCM (so effectively repurposing the > cipher list as the list of AEADs[*]), and that this wouldn't actually > translate to offering ECDHE_ECDSA due to that really being negotiated by > the other two extensions. > > But this doesn't seem to be completely the case because the ClientHello is > interpreted by both TLS 1.3 servers and existing servers. And so we need to > consider the effects on both to avoid interop. issues. This proposal could be extended to allow any cipher to negotiate any handshake based on the extensions, but that leaves us with a din of cipher suites. TLS 1.3 implementations would have to allow: negotiate DHE/ECDHE + RSA/DSS/ECDSA from all suites with any of the following: DHE_RSA, DHE_DSS, DHE_ECDSA, ECDHE_RSA, ECDHE_DSS, ECDHE_ECDSA (some of these combos don't exist, though) negotiate DHE/ECDHE + PSK from all suites with any of the following: DHE_PSK, ECDHE_PSK negotiate DHE/ECDHE +anon from all suites with any of the following: DH_anon, ECDH_anon (or named as: DHE_anon, ECDHE_anon) We could do this, but it's more to keep track of. By restricting TLS 1.3 suites to just those prefixed with ECDHE_ECDSA/PSK/anon, this means all others can be completely ignored for TLS 1.3+ and DHE suites can be deprecated in general. DHE weak param negotiation is a problem, but negotiation via the extension uses strong groups. Requiring ECDHE prefixed suites also prevents negotiation of DHE with weak params with older implementations, as it's not even offered. > [*] As you say below, not quite because you still premultiply the really > exotic things like PSK and anon. But setting those aside for the sake of > discussion. I set them aside for the sake of discussion for the first draft of this proposal and most of the discussion ended up on being how to deal with them. They complicate things, but they need to be taken into account from the start regardless of which path we pick. Dave From nobody Sat Jun 13 13: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 C4EC71AD0D3 for ; Sat, 13 Jun 2015 13:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 ovvFzkTLH2Eq for ; Sat, 13 Jun 2015 13:43:21 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 370971AD0D1 for ; Sat, 13 Jun 2015 13:43:21 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 6C99B488CF; Sat, 13 Jun 2015 20:43:20 +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 60D16488CE; Sat, 13 Jun 2015 20:43:20 +0000 (GMT) Received: from email.msg.corp.akamai.com (ustx2ex-cas4.msg.corp.akamai.com [172.27.25.33]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 481038008D; Sat, 13 Jun 2015 20:43:20 +0000 (GMT) Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com (172.27.27.102) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.27.104) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Sat, 13 Jun 2015 15:43:19 -0500 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.1076.000; Sat, 13 Jun 2015 15:43:19 -0500 From: "Salz, Rich" To: Dave Garrett , David Benjamin Thread-Topic: [TLS] A la carte handshake negotiation Thread-Index: AQHQpga91U3B3BYMxU+sAz6Clza/8J2rHeyA///JChA= Date: Sat, 13 Jun 2015 20:43:18 +0000 Message-ID: <1ee9bd7cd68d4583aaa0415020825ada@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <201506111558.21577.davemgarrett@gmail.com> <201506131459.31745.davemgarrett@gmail.com> In-Reply-To: <201506131459.31745.davemgarrett@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.56.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "" Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2015 20:43:22 -0000 DQo+IEl0IHdvdWxkbid0IGJlIHF1aXRlIGFzIHNpbXBsZSBhcyB5b3UgcHJvcG9zZSwgdGhvdWdo LCBiZWNhdXNlIHdlJ2QNCj4gZGVmaW5pdGVseSBoYXZlIHRvIGFkZCBhIG5ldyB3YXkgdG8gZGVj bGFyZSBhbm9uIG9yIFBTSyBzdXBwb3J0IHZpYQ0KPiBleHRlbnNpb25zLCBidXQgdGhhdCdzIGRv YWJsZS4NCg0KT3Igd2UgZG9uJ3Qgc3VwcG9ydCB0aG9zZSBmZWF0dXJlcyBpbiAxLjMuICBTb21l dGhpbmcgd2Ugc2hvdWxkIHRoaW5rIGFib3V0Pw0K From nobody Sat Jun 13 14:44: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 A36F61B2A42 for ; Sat, 13 Jun 2015 14:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 4rD025wbDrIv for ; Sat, 13 Jun 2015 14:44:53 -0700 (PDT) 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 3A6EC1B2A3E for ; Sat, 13 Jun 2015 14:44:53 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3A7B8284B64; Sat, 13 Jun 2015 21:44:46 +0000 (UTC) Date: Sat, 13 Jun 2015 21:44:46 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150613214445.GL2050@mournblade.imrryr.org> References: <201506111558.21577.davemgarrett@gmail.com> <201506131459.31745.davemgarrett@gmail.com> <1ee9bd7cd68d4583aaa0415020825ada@ustx2ex-dag1mb2.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1ee9bd7cd68d4583aaa0415020825ada@ustx2ex-dag1mb2.msg.corp.akamai.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] A la carte handshake negotiation 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: Sat, 13 Jun 2015 21:44:54 -0000 On Sat, Jun 13, 2015 at 08:43:18PM +0000, Salz, Rich wrote: > > It wouldn't be quite as simple as you propose, though, because we'd > > definitely have to add a new way to declare anon or PSK support via > > extensions, but that's doable. > > Or we don't support those features in 1.3. Something we should think about? I don't see any reason to kill them they don't add to the combinatorial bloat of the client HELLO. Most clients won't offer either in the handshake, but those that need them, benefit from having a protocol definition for them. Especially if these are negotiated separately from the bulk cipher-suite, they are easy to support. -- Viktor. From nobody Sat Jun 13 15:20: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 72F431B3103 for ; Sat, 13 Jun 2015 15:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RFKJNTUaJTbA for ; Sat, 13 Jun 2015 15:20:12 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (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 540EE1B2AB9 for ; Sat, 13 Jun 2015 15:20:12 -0700 (PDT) Received: by qkhg32 with SMTP id g32so34663750qkh.0 for ; Sat, 13 Jun 2015 15:20:11 -0700 (PDT) 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=lIQS7J9NzC0hFB7jhsaT6bP5TyZahK61iiDw4Mu5oew=; b=e3IeFTBB9slmKIUFjUxZWBbszdT1GRL7U4QKrGPofq8a0SMrHVvRi8KZWM9YgR/exn WoVbcUvXP4Rtru9PumU27WXgl6FYJKxXkkKkYVaxbuWLoV/Ht2iLmr7pnqwfcZb3jP7l aoAZcvk3UADQphJ3fdKMEL+045kbDGMnrg94Vdbp+y2rcDzE/GpWhtQhJW1Al4hNtSBV UGplBNj/XvoytKwk2H7V7UIiIqup0jkCUitOqhQ/IKISdx+R5HS4PBT682cS8NNPXSGj rcVY0JhctOIOxsCMdo91uqisUuvPdRg3+X2fhyqzd+wy0TOgc4yHXCiyza6/pcsmhjhM +7+g== X-Received: by 10.55.25.42 with SMTP id k42mr44541030qkh.79.1434234011691; Sat, 13 Jun 2015 15:20:11 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id 139sm3792636qhx.22.2015.06.13.15.20.10 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 13 Jun 2015 15:20:10 -0700 (PDT) From: Dave Garrett To: "Salz, Rich" Date: Sat, 13 Jun 2015 18:20:08 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201506111558.21577.davemgarrett@gmail.com> <201506131459.31745.davemgarrett@gmail.com> <1ee9bd7cd68d4583aaa0415020825ada@ustx2ex-dag1mb2.msg.corp.akamai.com> In-Reply-To: <1ee9bd7cd68d4583aaa0415020825ada@ustx2ex-dag1mb2.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201506131820.09262.davemgarrett@gmail.com> Archived-At: Cc: "" Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2015 22:20:13 -0000 On Saturday, June 13, 2015 04:43:18 pm Salz, Rich wrote: > > It wouldn't be quite as simple as you propose, though, because we'd > > definitely have to add a new way to declare anon or PSK support via > > extensions, but that's doable. > > Or we don't support those features in 1.3. Something we should think about? Completely dropping support for PSK & anon is not likely to get consensus. Dave From nobody Sat Jun 13 17:44: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 17E671A8988 for ; Sat, 13 Jun 2015 17:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y76t-dNgIq9j for ; Sat, 13 Jun 2015 17:44:50 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 95E371A897D for ; Sat, 13 Jun 2015 17:44:50 -0700 (PDT) Received: by qkhq76 with SMTP id q76so35673706qkh.2 for ; Sat, 13 Jun 2015 17:44:50 -0700 (PDT) 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=yd3JSkSyH1t1grLhS0nVSRntM3VrjwSY/+JlICnxWJ8=; b=zHQ3LypjBlJqYl1DmH8BajrHoUVx60aXVOyvAwN3jt/Be3Ix+wvF60tssIbeAIcTVw UVBiDPcZ9j46RfMcIZWRmFOKeYSfOG5MhLgg2PDjM7PaHnoM9mSiHqzcMawj6v5X5JBz hNJdPk5kkJFglLxv1JHlf2B1UfUkN2SPPq3kFuVFpf1W8sC8dA4IotWNp9QQlo06Ec2H ODgT4voPJs1zcUv49+p+OdVK5QefpngmHzgk6EFtc4pd59qwHno6QHAECQEYS8apeN1Z D5W0eqMxmuBUfVYarK6PRxQRPOZuSvJJzy6PtEmX6QBXHLzSOsUTWm9/su28c1zryKWG b8Sw== X-Received: by 10.55.52.12 with SMTP id b12mr44317055qka.22.1434242689952; Sat, 13 Jun 2015 17:44:49 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id b191sm3983068qka.14.2015.06.13.17.44.49 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 13 Jun 2015 17:44:49 -0700 (PDT) From: Dave Garrett To: "" Date: Sat, 13 Jun 2015 20:44:47 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201506111558.21577.davemgarrett@gmail.com> <201506131820.09262.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201506132044.48381.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Jun 2015 00:44:52 -0000 On Saturday, June 13, 2015 06:29:31 pm Eric Rescorla wrote: > On Sat, Jun 13, 2015 at 6:20 PM, Dave Garrett wr= ote: > > On Saturday, June 13, 2015 04:43:18 pm Salz, Rich wrote: > > > > It wouldn't be quite as simple as you propose, though, because we'd > > > > definitely have to add a new way to declare anon or PSK support via > > > > extensions, but that's doable. > > > > > > Or we don't support those features in 1.3. Something we should think= about? > > > > Completely dropping support for PSK & anon is not likely to get consens= us. >=20 > Certainly not PSK. Anon could be replaced relatively easily, though: it's essentially just nul= l PSK. Define the null PSK identity to use a null key, and then all (EC)DHE_PSK su= ites can be used similarly to (EC)DH_anon. You just need to have the client= propose the PSK identity in the ClientHello via an extension, which is alr= eady on the table in ekr's current WIP branch. PSK suites could be replaced with a PSK SignatureAlgorithm codepoint in =E2= =80=9Csignature_algorithms=E2=80=9D extension. (this was suggested by someo= ne at some point on this list, but I don't remember where that discussion w= as, offhand) With the above, ECDHE_ECDSA becomes the one-true-prefix. TLS 1.3 would only= negotiate cipher suites of that prefix, and cipher suites would be solely = for negotiating the symmetric cipher. All (EC)DH(E)_PSK & (EC)DH_anon suite= s would be deprecated, in addition to the older suites currently proposed t= o be deprecated (DHE, DH, ECDH, RSA, DSS). This would simplify the current proposal without the need to create a new A= EAD cipher negotiation extension as suggested by David Benjamin. The only caveat is plain PSK, which has three options: 1) Define NamedGroup=3Dnull(0) for it to be negotiated via the =E2=80=9Cnam= ed_groups=E2=80=9D extension. 2) Drop it and only use (EC)DHE_PSK. 3) Keep TLS_PSK_WITH_* suites around just for this. =46rankly, anything so constrained that it can't use an ECDHE exchange with= PSK probably has no incentive to upgrade to TLS 1.3, or possibly even to a= n AEAD cipher. I would prefer simply mandating (EC)DHE usage with PSK and a= nything that can't even use the fastest ECDHE curve can stick with TLS 1.0-= 1.2 forever. Dave From nobody Sat Jun 13 17:54: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 1C7151A8F33 for ; Sat, 13 Jun 2015 17:54:54 -0700 (PDT) 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 BeoPLwvhBlJc for ; Sat, 13 Jun 2015 17:54:52 -0700 (PDT) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (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 1CB5D1A86E6 for ; Sat, 13 Jun 2015 17:54:52 -0700 (PDT) Received: by wiga1 with SMTP id a1so45436399wig.0 for ; Sat, 13 Jun 2015 17:54:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=VD6qNm0J0MRCHfXYbeG9Al55TU4xsyDo5MFnN+qIRJ4=; b=JxWuSYMiSwE+MdjiagX83JHFzeQKeEcg4v/tMi4A8yoBBHygxnGfuJ0Dn2ERwhM7EE 8OOnk3kqb5t49FWA5NYt5ECLFlTq09S0AlpivfEoRhK1LfaBZvPMmW7c9sBgeGHW13Ux RxPRTReFF0wLmOa8+kV+tAXIR2HGwpbANp+LAwGobfyG5adKMJDZAbAcMpJdLIpOgHuz 5Z5/WLCH+EifhAqVpoiR78rRxhTv/Rz604cA5k7SrhWAcyEEXaiV2G/uyMn7Sv6ep91D /U0hFNgEq6gMNFu0e+s7vOtlM2u368DslvH4F0NFh8NAeYa3Hem0aHgxlLwN62jRBkLo qaSw== X-Gm-Message-State: ALoCoQl4CuS0kKPvNfH0Wvs7ngMKfLOCbWFp26J7QnoneP/okydC9Ld0lKT69np0T39Ex9wVRvvP X-Received: by 10.194.79.225 with SMTP id m1mr39749831wjx.8.1434243290856; Sat, 13 Jun 2015 17:54:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.225.14 with HTTP; Sat, 13 Jun 2015 17:54:10 -0700 (PDT) In-Reply-To: <201506132044.48381.davemgarrett@gmail.com> References: <201506111558.21577.davemgarrett@gmail.com> <201506131820.09262.davemgarrett@gmail.com> <201506132044.48381.davemgarrett@gmail.com> From: Eric Rescorla Date: Sat, 13 Jun 2015 20:54:10 -0400 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=047d7b10c903df958405186fc984 Archived-At: Cc: "" Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Jun 2015 00:54:54 -0000 --047d7b10c903df958405186fc984 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Jun 13, 2015 at 8:44 PM, Dave Garrett wrote: > On Saturday, June 13, 2015 06:29:31 pm Eric Rescorla wrote: > > On Sat, Jun 13, 2015 at 6:20 PM, Dave Garrett > wrote: > > > On Saturday, June 13, 2015 04:43:18 pm Salz, Rich wrote: > > > > > It wouldn't be quite as simple as you propose, though, because we= 'd > > > > > definitely have to add a new way to declare anon or PSK support v= ia > > > > > extensions, but that's doable. > > > > > > > > Or we don't support those features in 1.3. Something we should > think about? > > > > > > Completely dropping support for PSK & anon is not likely to get > consensus. > > > > Certainly not PSK. > > Anon could be replaced relatively easily, though: it's essentially just > null PSK. > > Define the null PSK identity to use a null key, and then all (EC)DHE_PSK > suites can be used similarly to (EC)DH_anon. You just need to have the > client propose the PSK identity in the ClientHello via an extension, whic= h > is already on the table in ekr's current WIP branch. > > PSK suites could be replaced with a PSK SignatureAlgorithm codepoint in > =E2=80=9Csignature_algorithms=E2=80=9D extension. (this was suggested by = someone at some > point on this list, but I don't remember where that discussion was, offha= nd > I don't see how this is going to work. All of the PSK cipher suites use the PSK as a source of keying material > With the above, ECDHE_ECDSA becomes the one-true-prefix. Maybe I'm misunderstanding what you're saying here, but I don't understand this point. Certainly I don't see any significant support whatsoever for deprecating RSA signatures, and given that we just standardized FFDHE, I don't see much evidence of consensus for deprecating DHE either. > Frankly, anything so constrained that it can't use an ECDHE exchange with > PSK probably has no incentive to upgrade to TLS 1.3, or possibly even to = an > AEAD cipher. I would prefer simply mandating (EC)DHE usage with PSK and > anything that can't even use the fastest ECDHE curve can stick with TLS > 1.0-1.2 forever. I do not support this position. There are plenty of devices which want to use PSK only, and we want everyone to upgrade to TLS 1.3. -Ekr --047d7b10c903df958405186fc984 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Jun 13, 2015 at 8:44 PM, Dave Garrett <davemgarrett@gmail= .com> wrote:
On Satur= day, June 13, 2015 06:29:31 pm Eric Rescorla wrote:
> On Sat, Jun 13, 2015 at 6:20 PM, Dave Garrett <davemgarrett@gmail.com> wrot= e:
> > On Saturday, June 13, 2015 04:43:18 pm Salz, Rich wrote:
> > > > It wouldn't be quite as simple as you propose, thou= gh, because we'd
> > > > definitely have to add a new way to declare anon or PSK= support via
> > > > extensions, but that's doable.
> > >
> > > Or we don't support those features in 1.3.=C2=A0 Somethi= ng we should think about?
> >
> > Completely dropping support for PSK & anon is not likely to g= et consensus.
>
> Certainly not PSK.

Anon could be replaced relatively easily, though: it's essential= ly just null PSK.

Define the null PSK identity to use a null key, and then all (EC)DHE_PSK su= ites can be used similarly to (EC)DH_anon. You just need to have the client= propose the PSK identity in the ClientHello via an extension, which is alr= eady on the table in ekr's current WIP branch.

PSK suites could be replaced with a PSK SignatureAlgorithm codepoint in =E2= =80=9Csignature_algorithms=E2=80=9D extension. (this was suggested by someo= ne at some point on this list, but I don't remember where that discussi= on was, offhand

I don't see how thi= s is going to work. All of the PSK cipher suites use the PSK
as a= source of keying material

=C2=A0
With the above, ECDHE_ECDSA becomes the one-true-prefix.
<= br>
Maybe I'm misunderstanding what you're saying here, b= ut I don't understand
this point. Certainly I don't see a= ny significant support whatsoever for deprecating RSA
signatures,= and given that we just standardized FFDHE, I don't see much evidence
of consensus for deprecating DHE either.

= =C2=A0
Frankly, anything so constrained that it can't use an ECDHE exchange wi= th PSK probably has no incentive to upgrade to TLS 1.3, or possibly even to= an AEAD cipher. I would prefer simply mandating (EC)DHE usage with PSK and= anything that can't even use the fastest ECDHE curve can stick with TL= S 1.0-1.2 forever.

I do not support this po= sition. There are plenty of devices which want to use PSK
only, a= nd we want everyone to upgrade to TLS 1.3.

-Ekr
--047d7b10c903df958405186fc984-- From nobody Sat Jun 13 18:15: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 758C31A8850 for ; Sat, 13 Jun 2015 18:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qRN5rdQb4QF for ; Sat, 13 Jun 2015 18:15:39 -0700 (PDT) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::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 9908E1A87E9 for ; Sat, 13 Jun 2015 18:15:39 -0700 (PDT) Received: by qcxj20 with SMTP id j20so2962162qcx.2 for ; Sat, 13 Jun 2015 18:15:39 -0700 (PDT) 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=NusVBPvnXz3fBja8KQp5TvACMyhs764joSS4oZVWzvs=; b=cARIYkK+Ac8UxCIJfBcGHdCpH3eqS25zDyvlnTV3Nsw0AXnWXSJgZULWfON43JZl0a jT5QbZu7OkzTTwJsxpjbyiPpeKfgZSZ2PvDQ0iSIrdtctKbVMDOyyEmmXDK/6bbCxYBC cm0ILNZa7QPCfHva6kQlqhKqJ0fsPJ4vEos+CYV3p2EY/Org0uvrY3FqOewHuaWE99QM GnqXBCffFjbWDDUalxB6Wqv/w7wz/rPVbw3VKLXYbf1+YaqyFURjKqC/OfhUR7/bmyXc rkH7GXEfbN7fT+gYn7z45bBAYQTJ0eMjwi2pdBCubIsQW0nlqEpW23bOiKH98lAadbMA cxHg== X-Received: by 10.55.33.158 with SMTP id f30mr46079086qki.104.1434244538975; Sat, 13 Jun 2015 18:15:38 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id z3sm4045452qge.30.2015.06.13.18.15.38 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 13 Jun 2015 18:15:38 -0700 (PDT) From: Dave Garrett To: Eric Rescorla Date: Sat, 13 Jun 2015 21:15:35 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201506111558.21577.davemgarrett@gmail.com> <201506132044.48381.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201506132115.36615.davemgarrett@gmail.com> Archived-At: Cc: "" Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Jun 2015 01:15:41 -0000 On Saturday, June 13, 2015 08:54:10 pm Eric Rescorla wrote: > On Sat, Jun 13, 2015 at 8:44 PM, Dave Garrett > wrote: > > PSK suites could be replaced with a PSK SignatureAlgorithm codepoint in > > =E2=80=9Csignature_algorithms=E2=80=9D extension. (this was suggested b= y someone at some > > point on this list, but I don't remember where that discussion was, off= hand >=20 > I don't see how this is going to work. All of the PSK cipher suites use t= he > PSK as a source of keying material A client proposing the PSK SignatureAlgorithm codepoint and a PSK identity = would be offering to negotiate PSK using that key. Anon would be proposed the same way, just with a null PSK identity. All sec= urity comes from the FS from (EC)DHE. (just like (EC)DH_anon) The server could simply state acceptance of negotiation by echoing back the= same PSK extension. > > With the above, ECDHE_ECDSA becomes the one-true-prefix. >=20 > Maybe I'm misunderstanding what you're saying here, but I don't understand > this point. Certainly I don't see any significant support whatsoever for > deprecating RSA signatures, and given that we just standardized FFDHE, I = don't see much > evidence of consensus for deprecating DHE either. This is all in the context of the proposal discussed in this thread. RSA si= gnatures would be negotiated using the "signatures_algorithms" extension. D= HE would be negotiated via the "named_groups" extension. (pick an FFDH grou= p for FFDHE or an ECDH curve for ECDHE) The point is to negotiate any of th= e following via those two extensions and the ECDHE_ECDSA prefix: DHE, ECDHE, RSA, DSS/DSA, ECDSA (or EdDSA), PSK (or anon) This would give us fewer suites with no new extensions beyond those already= proposed. Just need to use the already proposed extension additions and ad= d a codepoint for PSK/anon. Dave From nobody Sat Jun 13 19:05: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 1F7591A017C for ; Sat, 13 Jun 2015 19:05:30 -0700 (PDT) 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 nKTaA0qYEFqo for ; Sat, 13 Jun 2015 19:05:28 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.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 422641A0155 for ; Sat, 13 Jun 2015 19:05:28 -0700 (PDT) Received: by wibut5 with SMTP id ut5so46506621wib.1 for ; Sat, 13 Jun 2015 19:05:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=SiROt1maVh6l5b+nD/lOiL62uNLLvCtidUwsTtXRol0=; b=X0Jy2vEoRY6hDK6q7eRWi1cic14KHKj4hRLvo1EImHjoCRepI3Pl7DhrfFKLTzi8Us WnGw1oqYyZnbQWrVADXnE9voPm8ArH83Vz30jd0RiqjrzW7Y7bsxH8wgnKO04c4uQueI QuGXcl/KrGvq2JHhuyo8cHSt0P9ac5pZYHaSg8CJOd7VK0R6HIt9CJhb6EBDufppR77x ra4EjKVQyOVcWxQMpigQZquVUwb4K45ulzbtOxx4Ye4I+SEG41xFmGZDurkU47vnDSXn GDvL0U1AjtsxsrE3Y9IAA7Lt8eJvN0QgRzFOOTf9Djvpoz+MCC/FEMf2/viKglIJKIjH 0lvQ== X-Gm-Message-State: ALoCoQmnpiDDkFNm51V5rof/gB+QHKsc0KJsfGuj+M3Fpdw9ZAx/vK+xMPl1u8ANzGu5ZGfZjvcV X-Received: by 10.180.75.8 with SMTP id y8mr19531875wiv.31.1434247526917; Sat, 13 Jun 2015 19:05:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.225.14 with HTTP; Sat, 13 Jun 2015 19:04:46 -0700 (PDT) In-Reply-To: <201506132115.36615.davemgarrett@gmail.com> References: <201506111558.21577.davemgarrett@gmail.com> <201506132044.48381.davemgarrett@gmail.com> <201506132115.36615.davemgarrett@gmail.com> From: Eric Rescorla Date: Sat, 13 Jun 2015 22:04:46 -0400 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=f46d043c7b9c5cbd26051870c627 Archived-At: Cc: "" Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Jun 2015 02:05:30 -0000 --f46d043c7b9c5cbd26051870c627 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Jun 13, 2015 at 9:15 PM, Dave Garrett wrote: > On Saturday, June 13, 2015 08:54:10 pm Eric Rescorla wrote: > > On Sat, Jun 13, 2015 at 8:44 PM, Dave Garrett > > wrote: > > > PSK suites could be replaced with a PSK SignatureAlgorithm codepoint = in > > > =E2=80=9Csignature_algorithms=E2=80=9D extension. (this was suggested= by someone at > some > > > point on this list, but I don't remember where that discussion was, > offhand > > > > I don't see how this is going to work. All of the PSK cipher suites use > the > > PSK as a source of keying material > > A client proposing the PSK SignatureAlgorithm codepoint and a PSK identit= y > would be offering to negotiate PSK using that key. > But again, PSKs in TLS use it as a source of keying material, not just authentication. So, using that as a SignatureAlgorithm seems... weird. -Ekr Anon would be proposed the same way, just with a null PSK identity. All > security comes from the FS from (EC)DHE. (just like (EC)DH_anon) > > The server could simply state acceptance of negotiation by echoing back > the same PSK extension. > > > > With the above, ECDHE_ECDSA becomes the one-true-prefix. > > > > Maybe I'm misunderstanding what you're saying here, but I don't > understand > > this point. Certainly I don't see any significant support whatsoever fo= r > > deprecating RSA signatures, and given that we just standardized FFDHE, = I > don't see much > > evidence of consensus for deprecating DHE either. > > This is all in the context of the proposal discussed in this thread. RSA > signatures would be negotiated using the "signatures_algorithms" extensio= n. > DHE would be negotiated via the "named_groups" extension. (pick an FFDH > group for FFDHE or an ECDH curve for ECDHE) The point is to negotiate any > of the following via those two extensions and the ECDHE_ECDSA prefix: > DHE, ECDHE, RSA, DSS/DSA, ECDSA (or EdDSA), PSK (or anon) > > This would give us fewer suites with no new extensions beyond those > already proposed. Just need to use the already proposed extension additio= ns > and add a codepoint for PSK/anon. > > > Dave > --f46d043c7b9c5cbd26051870c627 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Jun 13, 2015 at 9:15 PM, Dave Garrett <davemgarrett@gmail= .com> wrote:
On Saturday, June 13, 2015 08:54:10 pm Eric Rescorla wrote:
> On Sat, Jun 13, 2015 at 8:44 PM, Dave Garrett <davemgarrett@gmail.com>
> wrote:
> > PSK suites could be replaced with a PSK S= ignatureAlgorithm codepoint in
> > =E2=80=9Csignature_algorithms=E2=80=9D extension. (this was sugge= sted by someone at some
> > point on this list, but I don't remember where that discussio= n was, offhand
>
> I don't see how this is going to work. All of the PSK cipher suite= s use the
> PSK as a source of keying material

A client proposing the PSK SignatureAlgorithm codepoint and a PSK id= entity would be offering to negotiate PSK using that key.
<= div>
But again, PSKs in TLS use it as a source of keying mate= rial, not just
authentication. So, using that as a SignatureAlgor= ithm seems... weird.

-Ekr

Anon would be proposed the same way, just with a null PSK identity. All sec= urity comes from the FS from (EC)DHE. (just like (EC)DH_anon)

The server could simply state acceptance of negotiation by echoing back the= same PSK extension.

> > With the above, ECDHE_ECDSA becomes the one-true-prefix.
>
> Maybe I'm misunderstanding what you're saying here, but I don&= #39;t understand
> this point. Certainly I don't see any significant support whatsoev= er for
> deprecating RSA signatures, and given that we just standardized FFDHE,= I don't see much
> evidence of consensus for deprecating DHE either.

This is all in the context of the proposal discussed in this thread.= RSA signatures would be negotiated using the "signatures_algorithms&q= uot; extension. DHE would be negotiated via the "named_groups" ex= tension. (pick an FFDH group for FFDHE or an ECDH curve for ECDHE) The poin= t is to negotiate any of the following via those two extensions and the ECD= HE_ECDSA prefix:
DHE, ECDHE, RSA, DSS/DSA, ECDSA (or EdDSA), PSK (or anon)

This would give us fewer suites with no new extensions beyond those already= proposed. Just need to use the already proposed extension additions and ad= d a codepoint for PSK/anon.


Dave

--f46d043c7b9c5cbd26051870c627-- From nobody Sat Jun 13 20:36: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 887711A8944 for ; Sat, 13 Jun 2015 20:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_55=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1UO3hqFzz6v for ; Sat, 13 Jun 2015 20:36:11 -0700 (PDT) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::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 F24F71A8942 for ; Sat, 13 Jun 2015 20:36:10 -0700 (PDT) Received: by qgf75 with SMTP id 75so19434590qgf.1 for ; Sat, 13 Jun 2015 20:36:10 -0700 (PDT) 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=BbxGgLIJYY3lXvr+bFnYMpcvau5V4Dlbdlt1IEqPY4s=; b=lEC8uLzLxpZ64e4POBgsh7VfQn6YtuXwZe594y0l0sMnUZWcv46a+5czMIIYL9rSOK GD36ovNkXAHdhf93+oGefMikdE0DTDrCcPQxGToD6rQ717nKxFVFk6Ii+gf7Y43EQCwM Z6BqAR2zL1oQDpQIGFS8Ir3GmFRbRVmQYWY1tuUYFqJUGqkgE/nOcEPJ3c9d2ARjWz6t ZnZJR9pqF21laafRHAvmvh4+sEN8Lhl4uenBYod03GMOg1guO5+Uaq3ugXuj6oknFxXL aTfvvJVtJjj/GyKBletQfXs7Ryssl1fa5EaucB5xxvi1eaVdSCWsAkOnFU0p7FqWjJqD ch7A== X-Received: by 10.140.91.246 with SMTP id z109mr27882245qgd.39.1434252970297; Sat, 13 Jun 2015 20:36:10 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id 33sm4177815qkq.41.2015.06.13.20.36.09 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 13 Jun 2015 20:36:09 -0700 (PDT) From: Dave Garrett To: Eric Rescorla Date: Sat, 13 Jun 2015 23:36:08 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201506111558.21577.davemgarrett@gmail.com> <201506132115.36615.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201506132336.08677.davemgarrett@gmail.com> Archived-At: Cc: "" Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Jun 2015 03:36:12 -0000 On Saturday, June 13, 2015 10:04:46 pm Eric Rescorla wrote: > On Sat, Jun 13, 2015 at 9:15 PM, Dave Garrett wr= ote: > > On Saturday, June 13, 2015 08:54:10 pm Eric Rescorla wrote: > > > On Sat, Jun 13, 2015 at 8:44 PM, Dave Garrett wrote: > > > > PSK suites could be replaced with a PSK SignatureAlgorithm codepoin= t in > > > > =E2=80=9Csignature_algorithms=E2=80=9D extension. (this was suggest= ed by someone at some > > > > point on this list, but I don't remember where that discussion was,= offhand > > > > > > I don't see how this is going to work. All of the PSK cipher suites u= se the > > > PSK as a source of keying material > > > > A client proposing the PSK SignatureAlgorithm codepoint and a PSK ident= ity > > would be offering to negotiate PSK using that key. >=20 > But again, PSKs in TLS use it as a source of keying material, not just > authentication. So, using that as a SignatureAlgorithm seems... weird. It already has a non-cert value in there for anonymous (that can't be used,= which is also weird), but I agree with your point. We could instead have no PSK sig point and just have the PSK identity exten= sion be the only thing to negotiate PSK. We don't really need both. In fact= , PSK-only clients wouldn't need to bother with the signatures extension at= all. Plain PSK would be as simple as just not offering the groups extensio= n, either. So: NamedGroup select FF group or EC curve -> FFDHE / ECDHE SignatureAndHashAlgorithm list -> RSA / DSA / ECDSA / EdDSA PSK_identity -> select key by id / null for anon All cipher suites used would be ECDHE_ECDSA, but these extensions would be = able to negotiate from any of the above. Cipher suite negotiation would be = only for selecting the symmetric cipher (+hash to go with it). The extensio= ns would do the rest. To reiterate the rationale for considering this: * DHE suites need retiring because of weak param negotiation and old Java c= hoking on mitigations. * Endpoints won't be able to fail a handshake anymore just because the admi= n missed one of the possible combinations of cipher suite components, even = though they should be compatible. Also, more subtly, they won't accidentall= y negotiate a suite that's only in there for backwards compatibility as eas= ily. (e.g. I've seen instances where one client gets an old cipher because = its new cipher combo is low in the list, as the server admin probably only = tested with another client that picks a slightly different combo higher in = the list.) * Simpler config overall; now a list of yes/no that can be individually pri= oritized, instead of having to prioritize all arbitrary combos. * Less ClientHello size bloat from adding lots of suites. Large hellos can = cause interop failure due to bugs. * Easier to amend. There was discussion of hand-waving EdDSA~ECDSA. With th= is, it can have its own signature algorithm point and nothing else special = is really needed (beyond using the frozen suite prefix, like everything els= e does). A future completely different algorithm could be added without hav= ing to muck around with cipher suite combinations anymore. (e.g. post-quant= um algorithms will be needed, eventually; once defined with a sig point in = the extension, all symmetric ciphers could use them right away) * Anon or PSK can be used with any symmetric cipher without having to stand= ardize suite values anymore. Dave From nobody Sat Jun 13 23:33: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 2D4851B2AB3 for ; Sat, 13 Jun 2015 23:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 j6chzpGokoZL for ; Sat, 13 Jun 2015 23:33:47 -0700 (PDT) Received: from emh02.mail.saunalahti.fi (emh02.mail.saunalahti.fi [62.142.5.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D1631B2AB0 for ; Sat, 13 Jun 2015 23:33:45 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id E26B58181C; Sun, 14 Jun 2015 09:33:42 +0300 (EEST) Date: Sun, 14 Jun 2015 09:33:42 +0300 From: Ilari Liusvaara To: Dave Garrett Message-ID: <20150614063342.GA24954@LK-Perkele-VII> References: <201506111558.21577.davemgarrett@gmail.com> <201506132044.48381.davemgarrett@gmail.com> <201506132115.36615.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <201506132115.36615.davemgarrett@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: "" Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Jun 2015 06:33:49 -0000 On Sat, Jun 13, 2015 at 09:15:35PM -0400, Dave Garrett wrote: > On Saturday, June 13, 2015 08:54:10 pm Eric Rescorla wrote: > > On Sat, Jun 13, 2015 at 8:44 PM, Dave Garrett > > wrote: > > > PSK suites could be replaced with a PSK SignatureAlgorithm codepoint in > > > “signature_algorithms” extension. (this was suggested by someone at some > > > point on this list, but I don't remember where that discussion was, offhand > > > > I don't see how this is going to work. All of the PSK cipher suites use the > > PSK as a source of keying material > > A client proposing the PSK SignatureAlgorithm codepoint and a PSK identity > would be offering to negotiate PSK using that key. > > Anon would be proposed the same way, just with a null PSK identity. All > security comes from the FS from (EC)DHE. (just like (EC)DH_anon) > > The server could simply state acceptance of negotiation by echoing back > the same PSK extension. IMO, the problem here is that all the following have quite different key exchange: - GDHE_CERT - GDHE_PSK - GDHE_anon - PSK (PRF and symmetric cipher don't affect key exchange). PSK is not signature algorithm. It works by mixing its key material into secrets. Trick of using empty cert and HMAC(PSK, ...) as authentication to unify GDHE_CERT and GDHE_PSK won't work if one is to remain compatible with TLS 1.2 DHE_PSK (or at least, requires further tricks). The problem is that in TLS 1.2, there is thing called PSK hint, which is optionally sent from server to client. Then client will chose its final PSK identity. In TLS 1.3, that sort of thing would need 1RTT miss, followed by extra message from the client to select the final PSK identity (and possibly also sending a missing group key if in GDHE_PSK). And I think optional handshake messages are a bad idea, being souce of nasty bugs (situation-dependent is different thing). Trying to map GDHE_anon to GDHE_PSK doesn't at least run into bad problems with messages, but I wouldn't use null identity, as that can be very much used in real world. Then the pure-PSK is totally different from anything else. There the only source of keying is the psk, which has to act as direct input to hMS. -Ilari From nobody Sun Jun 14 05:17: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 D24FC1B2D09 for ; Sun, 14 Jun 2015 05:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 MPN76Qbxc1Yu for ; Sun, 14 Jun 2015 05:17:37 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 48E891B2D07 for ; Sun, 14 Jun 2015 05:17:37 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t5ECHVjD022980 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Sun, 14 Jun 2015 14:17:32 +0200 From: Simon Josefsson To: Dave Garrett References: <20150611170317.13732.72719.idtracker@ietfa.amsl.com> <201506122355.45772.davemgarrett@gmail.com> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:150614:tls@ietf.org::kWLz9OtcYdkRKPGV:0iG2 X-Hashcash: 1:22:150614:davemgarrett@gmail.com::dEP9JpR2BrQ3q27G:1PgE X-Hashcash: 1:22:150614:nmav@redhat.com::1nc1MN8gkTf2O11Z:EsjV Date: Sun, 14 Jun 2015 14:17:29 +0200 In-Reply-To: <201506122355.45772.davemgarrett@gmail.com> (Dave Garrett's message of "Fri, 12 Jun 2015 23:55:45 -0400") Message-ID: <87r3petrfq.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] I-D Action: draft-ietf-tls-chacha20-poly1305-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Jun 2015 12:17:39 -0000 --=-=-= Content-Type: text/plain Dave Garrett writes: > After discussion earlier involving ECDHE_anon cipher suites, it > occurred to me that it could be useful to define one for ChaChaPoly in > this draft. > > Is it viable to add a cipher suite name and codepoint for this? What is the use-case? /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJVfXDaAAoJEIYLf7sy+BGdo6kH/R7FWq7DG+vcC5NCyyy+Qutm OaCY+ifSGP01bW+80h9INT6KHSef8VXQ8joUGowL5WJZiHqD8BtnxqbgeOiw2MqY BV6RnAdOoyhK6fVoknSUCJ07FrsMTVns7L/JC9JMDoAzDyhpO2c4KG+a7JZ1HhyK MB2cvI5EHgwucR4AoZ8V3j86dtGzbtFJNz2MASqdjkOq5QXy/67pGl2I1EwoMLtv 5KfLBMT66qEBF3LXp0pqj7e/dfNF1dBAsHctxzJxcKdb0G3D8vcEjfGzO4QxNM+/ ccGjABaG/kLFolgwYwHzYnJCMVLOtFBlwe50XZVy1rZ+kuAQ1UfIEK4CvAhPtk4= =mleG -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jun 14 06:46: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 43E231B2EE9 for ; Sun, 14 Jun 2015 06:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 PyyZz765W19U for ; Sun, 14 Jun 2015 06:46:43 -0700 (PDT) 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 EBFD11B2EE4 for ; Sun, 14 Jun 2015 06:46:42 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 914A6284AD9; Sun, 14 Jun 2015 13:46:39 +0000 (UTC) Date: Sun, 14 Jun 2015 13:46:39 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150614134639.GN2050@mournblade.imrryr.org> References: <20150611170317.13732.72719.idtracker@ietfa.amsl.com> <201506122355.45772.davemgarrett@gmail.com> <87r3petrfq.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87r3petrfq.fsf@latte.josefsson.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-chacha20-poly1305-00.txt 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: Sun, 14 Jun 2015 13:46:44 -0000 On Sun, Jun 14, 2015 at 02:17:29PM +0200, Simon Josefsson wrote: > > After discussion earlier involving ECDHE_anon cipher suites, it > > occurred to me that it could be useful to define one for ChaChaPoly in > > this draft. > > > > Is it viable to add a cipher suite name and codepoint for this? > > What is the use-case? 0. Authentication other than via certificate-based PKI. Establish anon TLS, and channel-bind the TLS-unique via GSSAPI or some other authentication method. 1. Unauthenticated opportunistic TLS. * Server performs no unnecessary signature operations, since the client can't verify the signature anyway. (More precisely the client can't verify the authenticity of the server keys, so it can only determine that somebody signed the handshake, but no idea whether it is the intended server). * Servers can tell which clients are not verifying their identity, (definitely the ones the offer or negotiate "anon" ciphersuites). This is useful information. -- Viktor. From nobody Sun Jun 14 08:56: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 58AE71B2F64 for ; Sun, 14 Jun 2015 08:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qr4eaaipEkIc for ; Sun, 14 Jun 2015 08:55:59 -0700 (PDT) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) (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 01FFB1A905B for ; Sun, 14 Jun 2015 08:55:05 -0700 (PDT) Received: by qcbfz6 with SMTP id fz6so325291qcb.0 for ; Sun, 14 Jun 2015 08:55:04 -0700 (PDT) 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=7lRMNtqse3tWdrnqstHSLJcEU6xDKlVH7FmBEYWku2U=; b=ot9o1+vrQ8OkkXzQPV0Xz1vXup4AHs+HTwNWbiJQ1oF75vsv0Ntq9RstIdIinzIx2f 0cnim/ibfGDqSnF/gXCHrvaEGiaTP4ZHLGuDi/9udFWFGJwduGg+hDlMgTJp+HRiNx2E 4N9eM98xYEaZxtetEfRuHL3/xwYF9/YusMmg/YF52BdDPXCsC01expSt/9bf8BCc+NFZ ObHQB6BLwvznQ7UEzQA8vpHaIUrozan7k8Faj9JiZJa82fFvE3ulk/u2FjqqovYeC9yw tJ4zYTBM9r7jgCYbcQq7dCXsxgDHy6p6OMIsGDNYd2XOLtrqQd5I8T/XcifzMsvTgqLS 5fXA== X-Received: by 10.140.46.75 with SMTP id j69mr30155007qga.17.1434297304264; Sun, 14 Jun 2015 08:55:04 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id j62sm4856258qhc.33.2015.06.14.08.55.03 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 14 Jun 2015 08:55:03 -0700 (PDT) From: Dave Garrett To: Ilari Liusvaara Date: Sun, 14 Jun 2015 11:55:02 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201506111558.21577.davemgarrett@gmail.com> <201506132115.36615.davemgarrett@gmail.com> <20150614063342.GA24954@LK-Perkele-VII> In-Reply-To: <20150614063342.GA24954@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201506141155.02725.davemgarrett@gmail.com> Archived-At: Cc: "" Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Jun 2015 15:56:01 -0000 On Sunday, June 14, 2015 02:33:42 am Ilari Liusvaara wrote: > Trick of using empty cert and HMAC(PSK, ...) as authentication to unify > GDHE_CERT and GDHE_PSK won't work if one is to remain compatible with > TLS 1.2 DHE_PSK (or at least, requires further tricks). >=20 > The problem is that in TLS 1.2, there is thing called PSK hint, which > is optionally sent from server to client. Then client will chose its > final PSK identity. In TLS 1.3, that sort of thing would need 1RTT > miss, followed by extra message from the client to select the final > PSK identity (and possibly also sending a missing group key if in > GDHE_PSK). https://www.ietf.org/mail-archive/web/tls/current/msg16748.html ekr is currently considering adding a PSK identity extension for the Client= Hello. (it's in his current WIP branch, atm) It's just a simple extension t= o have the client send the id it wants. This is what I was saying would be = all that was needed for PSK. The entire signatures extension wouldn't be ne= eded; just send the PSK id (anon=3Dnull) and the supported groups extension= =2E Selected NamedGroup selects FF/EC DHE; for plain PSK, don't send this e= xtension either. > And I think optional handshake messages are a bad idea, being souce > of nasty bugs (situation-dependent is different thing). Yes, that sort of thing is a risk. This has PSK & CERT largely separate, so= within each use-case, not much is optional. =46rom an alternate perspective, this could be viewed as kicking PSK/anon o= ut of TLS 1.3 proper and moving it entirely to a dedicated extension (thoug= h, defined in the same document). Dave From nobody Mon Jun 15 03:10: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 003981B3548 for ; Mon, 15 Jun 2015 03:10:49 -0700 (PDT) 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 WMysV9FHe1jM for ; Mon, 15 Jun 2015 03:10:47 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85D3A1B3539 for ; Mon, 15 Jun 2015 03:10:47 -0700 (PDT) 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 (Postfix) with ESMTPS id 18A903582A0; Mon, 15 Jun 2015 10:10:47 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-196.brq.redhat.com [10.34.0.196]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t5FAAjnA013655 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 15 Jun 2015 06:10:46 -0400 From: Hubert Kario To: tls@ietf.org Date: Mon, 15 Jun 2015 12:10:39 +0200 Message-ID: <3129639.pNdByueU9m@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.7 (Linux/4.0.4-202.fc21.x86_64; KDE/4.14.7; x86_64; ; ) In-Reply-To: <201506122145.13790.davemgarrett@gmail.com> References: <201506122145.13790.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1889505.7lrVgTz8D7"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Jun 2015 10:10:49 -0000 --nextPart1889505.7lrVgTz8D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Friday 12 June 2015 21:45:13 Dave Garrett wrote: > Based on the discussions today, I've significantly revised the text o= f this > proposal. This new draft goes into more detail for the PSK & anon cip= her > suites. >=20 > Of note, I've added a table to state what's available to negotiate wi= th > what. It's longer than it should be because both DHE_PSK and DH_anon = should > be dropped from there, but for now I've included them because ECDHE_P= SK and > ECDH_anon AEAD cipher suites have yet to be standardized. There's exp= ired > drafts for these and if PSK and anon are to be considered fully compa= tible > with TLS 1.3, then these really should be defined. Merging them toget= her > into one I-D for AEAD ECDHE cipher suite assignments seems like the > simplest route. >=20 > I'd also rather plain (symmetric-only) PSK be relegated to its own > specifications and not included here, but I've included it in the tab= le for > now. ECDHE_PSK should ideally be the only supported PSK handshake. Pl= ain > PSK has no FS and it was generally agreed that TLS 1.3+ should be FS = only. >=20 > New draft text: > https://github.com/davegarrett/tls13-spec/blob/alacarte/draft-ietf-tl= s-tls13 > .md#cipher-suites Diff with master: > https://github.com/tlswg/tls13-spec/compare/master...davegarrett:alac= arte How will the client know which parser it should use to deserialize the = Server=20 Key Exchange? Especially when we're close to having DHE, ECDHE, DHE+PSK (and DHE+PSK+= RSA?),=20 ECDHE+PSK (and ECDHE+PSK+ECDSA, ECDHE+PSK+ECDSA?), ADH and AECDH in a s= ingle=20 ciphersuite... Especially with the case of overloading the ECDHE to handle the ECDH_an= on, it=20 makes it possible that many implementations will reintroduce state mach= ine=20 bugs... =2D-=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 --nextPart1889505.7lrVgTz8D7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJVfqSlAAoJEJKo0bgB0vX1SGYQAIUUZmG+WsM0f639EGO8OXrj xgOLdyLGss25CgGh/+/EZ4mGMJ7t5bbVqvMZDiQHZhfMHK8+Q25yY8GWFyYC4cA0 qZ+C4QWpheygYsVnrJ0VXWmoiHwJF9cUNccgLf0PjDdnJKSyeAqM5Oy7VoRhdIOS /SDb+EI2ZtFQ2pFQMRR3J8MQzJiit0PwEa12QBjyqvwVbqQ83noJ7VLYSh7x9Mcp BY0clnZ1fD1JVjZn+FACsBO0kB8NB3yqDNEW9rs3U8FkPerlmkNm2TYe1syZp+/S IDiTilck4VyDysC6CN32aq5p0J+gQB4SulYeVRgGc7Bxm8v9jxo3R9uuULNUosVS dOq6ifO1iLj6nUeXaPUvIQ609vPsHusLsSNM+cYB+zlG+JE1oQ0dpCICIGMbFG0U M7ZqtIRlWVZZMs+5oVEZ208GIZJdxxpGXIPnCxbvSvmlvPNo9FZJFUyakh5BdMM3 aaho+uSbhBwnRvRCLCmSBSm7eE+aXsJabHxYUmXXFWG7r5X6ADLBg1+CaVkxA/Jl z7zECeD//3c2okbIANsGUxUAplzUNNkiTDDlM3pRnXspJLk2MBfgh5m2u7+goMW2 l+LJ3hgQKb45lig82PYDyyu6VlBG7vbt3g4G8pW8gyNC/m8b/hV4dyrnAfPubXQm vLOdWggfRY1ouBy3e4Qj =M+e6 -----END PGP SIGNATURE----- --nextPart1889505.7lrVgTz8D7-- From nobody Mon Jun 15 06:03: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 2497E1B35FD for ; Mon, 15 Jun 2015 06:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 GcQlsJWjaIi8 for ; Mon, 15 Jun 2015 06:03:47 -0700 (PDT) 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 BCD1E1B35FC for ; Mon, 15 Jun 2015 06:03:47 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id EB887284B58; Mon, 15 Jun 2015 13:03:45 +0000 (UTC) Date: Mon, 15 Jun 2015 13:03:45 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150615130345.GJ14121@mournblade.imrryr.org> References: <20150612180230.4804.45802.idtracker@ietfa.amsl.com> <20150612195654.GA9401@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-curve25519-00.txt 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: Mon, 15 Jun 2015 13:03:49 -0000 On Fri, Jun 12, 2015 at 01:43:25PM -0700, Martin Thomson wrote: > > "Servers MUST NOT select an ECDHE_ECDSA ciphersuite if there are no > > common curves suitable for ECDSA." > > > > You mean MUST NOT select ECDSA certificate? Because TLS 1.2 rules > > seemingly allow selecting ECDHE_RSA ciphersuite with ECDSA > > certificate. > > This seems right to me. The point here is that when a named_curve (or > named_group) identifies 25519, then it can't be used for ECDSA. 25519 > is always OK with an _RSA_ suite. It seems that provided there's also a named_curve for ECDSA that matches the certificate, then one might use 25519 for a key exchange that is signed with ECDSA. If both are supported I don't see why this combination should be excluded. What problem does the exclusion solve? If 25519 ECDH is faster and safer than with ECDSA why not use it even with servers that sign the parameters with ECDSA? -- Viktor. From nobody Mon Jun 15 06:28: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 E35B61B3616 for ; Mon, 15 Jun 2015 06:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 qv0XAy4TXkMX for ; Mon, 15 Jun 2015 06:28:00 -0700 (PDT) Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A5961B2D38 for ; Mon, 15 Jun 2015 06:23:56 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id 453D81A26B7; Mon, 15 Jun 2015 16:23:53 +0300 (EEST) Date: Mon, 15 Jun 2015 16:23:53 +0300 From: Ilari Liusvaara To: Hubert Kario Message-ID: <20150615132353.GA27040@LK-Perkele-VII> References: <201506122145.13790.davemgarrett@gmail.com> <3129639.pNdByueU9m@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <3129639.pNdByueU9m@pintsize.usersys.redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Jun 2015 13:28:07 -0000 On Mon, Jun 15, 2015 at 12:10:39PM +0200, Hubert Kario wrote: > On Friday 12 June 2015 21:45:13 Dave Garrett wrote: > > > > New draft text: > > https://github.com/davegarrett/tls13-spec/blob/alacarte/draft-ietf-tls-tls13 > > .md#cipher-suites Diff with master: > > https://github.com/tlswg/tls13-spec/compare/master...davegarrett:alacarte > > How will the client know which parser it should use to deserialize the Server > Key Exchange? > > Especially when we're close to having DHE, ECDHE, DHE+PSK (and DHE+PSK+RSA?), > ECDHE+PSK (and ECDHE+PSK+ECDSA, ECDHE+PSK+ECDSA?), ADH and AECDH in a single > ciphersuite... > > Especially with the case of overloading the ECDHE to handle the ECDH_anon, it > makes it possible that many implementations will reintroduce state machine > bugs... Well, the server key exchange message is presumably the same for all GDHE key exchanges, so one parser could parse those all (and pure-PSK would be separate, which doesn't even have server key exchange). However, if we were serious about eliminating state machine bugs (and TLS 1.3 state machine is totally different from TLS 1.2), we would eliminate all optional messages (different from context-sensitive messages, like Server key exchange message), and then eliminate handshake message types (except for those which have to have type numbers for backward compatiblity). That way, any state machine bugs just cause handshake failures, not security failures. Regarding the PSK integration work EKR has been doing in the WIP branch: 1) Doesn't support identity hints. Now, these might be something nobody uses and can be deprecated. 2) GDHE_PSK ciphers can't seemingly be safely resumed: Because resumption is PSK, it eats the PSK slot, not leaving space for the primary identity. -Ilari From nobody Mon Jun 15 06:29: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 14EFF1B2D3F for ; Mon, 15 Jun 2015 06:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 hJ4CBz2ZCNUL for ; Mon, 15 Jun 2015 06:29:22 -0700 (PDT) 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 81AA01B3615 for ; Mon, 15 Jun 2015 06:29:21 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id 86269900FE for ; Mon, 15 Jun 2015 16:29:19 +0300 (EEST) Date: Mon, 15 Jun 2015 16:29:19 +0300 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20150615132919.GA28329@LK-Perkele-VII> References: <20150612180230.4804.45802.idtracker@ietfa.amsl.com> <20150612195654.GA9401@LK-Perkele-VII> <20150615130345.GJ14121@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150615130345.GJ14121@mournblade.imrryr.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-curve25519-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Jun 2015 13:29:24 -0000 On Mon, Jun 15, 2015 at 01:03:45PM +0000, Viktor Dukhovni wrote: > On Fri, Jun 12, 2015 at 01:43:25PM -0700, Martin Thomson wrote: > > > > "Servers MUST NOT select an ECDHE_ECDSA ciphersuite if there are no > > > common curves suitable for ECDSA." > > > > > > You mean MUST NOT select ECDSA certificate? Because TLS 1.2 rules > > > seemingly allow selecting ECDHE_RSA ciphersuite with ECDSA > > > certificate. > > > > This seems right to me. The point here is that when a named_curve (or > > named_group) identifies 25519, then it can't be used for ECDSA. 25519 > > is always OK with an _RSA_ suite. > > It seems that provided there's also a named_curve for ECDSA > that matches the certificate, then one might use 25519 for a key > exchange that is signed with ECDSA. > > If both are supported I don't see why this combination should be > excluded. What problem does the exclusion solve? > > If 25519 ECDH is faster and safer than with ECDSA why not use it > even with servers that sign the parameters with ECDSA? The problem is that clients that support 25519 ECDHE might not support any curve usable for ECDSA. And even if they did, they are very unlikely to support 25519 ECDSA. -Ilari From nobody Mon Jun 15 06:35: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 3D8331B363A for ; Mon, 15 Jun 2015 06:35:41 -0700 (PDT) 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 OoTG6dg899Gv for ; Mon, 15 Jun 2015 06:35:40 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (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 CAAD91B3639 for ; Mon, 15 Jun 2015 06:35:39 -0700 (PDT) Received: by wifx6 with SMTP id x6so78607608wif.0 for ; Mon, 15 Jun 2015 06:35:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=jv6MpyNLpyRoCxNgG7UWG27VR/XTTHyyjnFA/QuFoFU=; b=hDpdiMysUJXC2UaRIql8LIxZrz1wr0miIZdTOPNibYjUu/DUL66aKnHnc8pXugFSOQ GC57N41019yaNkvYi7UmYLs4d+LfJiKrCbuo7sc8M6BUp0X2yycg/N89kY+PoKy+Oj4W S45rzlaV2nHtrixo8jQHGYGpWrBk6V9/bsttWpzNXEML9bFaeLMbch3Vdh57vRvcHfcY jUtSQMtZtwSaVV9XAk5ihCWzIcRp6GheIPFasJ9r8powqy6/FCsXFiYLWlnmvWXqYTrr AGKanetXVrCw2yL6ibFwCkehyCeF5H/OQOeUTxux3J/4K+Z0N/oxiz9AcNUAnmi1RNJi wMeA== X-Gm-Message-State: ALoCoQkVADOrTR0i63zWmYHDqI7H3T7AWCRHeVlce2UrjghBcGfkuj+qdrtI5TJspZoWPLNqcF+1 X-Received: by 10.180.99.39 with SMTP id en7mr31682134wib.31.1434375338546; Mon, 15 Jun 2015 06:35:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.225.14 with HTTP; Mon, 15 Jun 2015 06:34:58 -0700 (PDT) In-Reply-To: <20150615132353.GA27040@LK-Perkele-VII> References: <201506122145.13790.davemgarrett@gmail.com> <3129639.pNdByueU9m@pintsize.usersys.redhat.com> <20150615132353.GA27040@LK-Perkele-VII> From: Eric Rescorla Date: Mon, 15 Jun 2015 06:34:58 -0700 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=f46d04182808876fad05188e8861 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Jun 2015 13:35:41 -0000 --f46d04182808876fad05188e8861 Content-Type: text/plain; charset=UTF-8 On Mon, Jun 15, 2015 at 6:23 AM, Ilari Liusvaara < ilari.liusvaara@elisanet.fi> wrote: > > Regarding the PSK integration work EKR has been doing in the WIP branch: > > 1) Doesn't support identity hints. Now, these might be something nobody > uses and can be deprecated. > My sense was that it was sufficiently rare that we could deprecate it. It's a bad match for the state machine. > 2) GDHE_PSK ciphers can't seemingly be safely resumed: Because resumption > is PSK, it eats the PSK slot, not leaving space for the primary identity. And your concern here is that you might want to resume GDHE_PSK as ordinary PSK for performance reasons? If this seems really important, we could presumably have multiple PSK slots. -Ekr --f46d04182808876fad05188e8861 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jun 15, 2015 at 6:23 AM, Ilari Liusvaara <ilari.liusvaara@e= lisanet.fi> wrote:
Regarding the PSK integration work EKR has been doing in the WIP branch:
1) Doesn't support identity hints. Now, these might be something nobody=
uses and can be deprecated.

My sense wa= s that it was sufficiently rare that we could deprecate it.
It= 9;s a bad match for the state machine.

=C2=A0
<= /div>
2) GDHE_PSK ciphers can't seemingly be safely resumed: Because resumpti= on
is PSK, it eats the PSK slot, not leaving space for the primary identity.

And your concern here is that you might want= to resume GDHE_PSK as ordinary
PSK for performance reasons? If t= his seems really important, we could presumably
have multiple PSK= slots.

-Ekr

=C2=A0
--f46d04182808876fad05188e8861-- From nobody Mon Jun 15 06:36: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 C6F291A1E0F for ; Mon, 15 Jun 2015 06:36:56 -0700 (PDT) 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 ZM8dydhgwgJC for ; Mon, 15 Jun 2015 06:36:55 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D68F1A1A12 for ; Mon, 15 Jun 2015 06:36:55 -0700 (PDT) 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 (Postfix) with ESMTPS id E49A2345A8A; Mon, 15 Jun 2015 13:36:54 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-196.brq.redhat.com [10.34.0.196]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t5FDaoHm023559 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 15 Jun 2015 09:36:52 -0400 From: Hubert Kario To: Ilari Liusvaara Date: Mon, 15 Jun 2015 15:36:44 +0200 Message-ID: <8295853.kIc6eIqDrM@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.7 (Linux/4.0.4-202.fc21.x86_64; KDE/4.14.7; x86_64; ; ) In-Reply-To: <20150615132353.GA27040@LK-Perkele-VII> References: <201506122145.13790.davemgarrett@gmail.com> <3129639.pNdByueU9m@pintsize.usersys.redhat.com> <20150615132353.GA27040@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1768965.Pnt4Yhm5g4"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Jun 2015 13:36:56 -0000 --nextPart1768965.Pnt4Yhm5g4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Monday 15 June 2015 16:23:53 Ilari Liusvaara wrote: > On Mon, Jun 15, 2015 at 12:10:39PM +0200, Hubert Kario wrote: > > On Friday 12 June 2015 21:45:13 Dave Garrett wrote: > > > New draft text: > > > https://github.com/davegarrett/tls13-spec/blob/alacarte/draft-iet= f-tls-t > > > ls13 .md#cipher-suites Diff with master: > > > https://github.com/tlswg/tls13-spec/compare/master...davegarrett:= alacart > > > e > >=20 > > How will the client know which parser it should use to deserialize = the > > Server Key Exchange? > >=20 > > Especially when we're close to having DHE, ECDHE, DHE+PSK (and > > DHE+PSK+RSA?), ECDHE+PSK (and ECDHE+PSK+ECDSA, ECDHE+PSK+ECDSA?), A= DH and > > AECDH in a single ciphersuite... > >=20 > > Especially with the case of overloading the ECDHE to handle the ECD= H_anon, > > it makes it possible that many implementations will reintroduce sta= te > > machine bugs... >=20 > Well, the server key exchange message is presumably the same for all = GDHE > key exchanges, so one parser could parse those all there's still the difference between signed vs not-signed > (and pure-PSK would be > separate, which doesn't even have server key exchange). pure PSK is outside TLSv1.3 as it doesn't provide PFS, ECDHE-PSK and DH= E-PSK=20 though doesn't use signature on server key share > However, if we were serious about eliminating state machine bugs (and= TLS > 1.3 state machine is totally different from TLS 1.2), we would elimin= ate > all optional messages (different from context-sensitive messages, lik= e > Server key exchange message), and then eliminate handshake message ty= pes > (except for those which have to have type numbers for backward > compatiblity). there's a difference between having messages which are optional from pr= otocol=20 standpoint but are mandatory for given ciphersuite and messages which a= re=20 optional always > Regarding the PSK integration work EKR has been doing in the WIP bran= ch: >=20 > 1) Doesn't support identity hints. Now, these might be something nobo= dy > uses and can be deprecated. >=20 > 2) GDHE_PSK ciphers can't seemingly be safely resumed: Because resump= tion > is PSK, it eats the PSK slot, not leaving space for the primary ident= ity. =2D-=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 --nextPart1768965.Pnt4Yhm5g4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJVftTxAAoJEJKo0bgB0vX1xEwQAKGPhGF/zceMZZiBEgaW/aUD y10DnWtWJSrm07ZLW9gyp+57meX4dcfM/BoJjfy0aAryNO4wVKi+8n9VGT0jLvko uhOFw7JRbXotFfoyAPUAIafpQGM5lHNp9bPAbfNAKnofN3uTsbiHEtFNEq6VuBqO pUOYhI0Qsq5/LhSV1HwtUECzwox44HVBmGSzs8PAXJ3w7s6O3TSIVPhpV/ougChF fLOAG59mn6lktscJ7xWJHZP1K4+LSUurEABoCyayUup5/SDNoPNSd80A2TJeh54l 3ZHMdICNIqIMy7Lbx0roxF2+RX1yTyVqj8pZIPNTiApNF8n1wsUZj13qWb19/PSs LS29tZXVwvA1SVz2zUTqpMHeh/86Q+Q9v3F/k0/XvaU24rWbhRcn5EvbYcIAg7Fb o3eRA5ob12GWMJ8wCqH7katm5mm87UAStvJro703ZVtfXkmjmVUaltT2BgURKwZt wcpdsuNHvL/+7RIXHchRVUmfQyuhJZIQBvqrhrMgiOgvrO7IfAU3FH6fvgRi6136 0SBYtWn4kay3lISWBb/nxA3Jvn1NZrmx41lHwIaxeFaIzAqcIcgNg9WjIcf4RMWS J7TGtkoodBFtmTphmh5WhDffPRClyvaAxhfR1rZyvPcmXoIuLZoUwmflumGedRz8 sfTnr7Ot6lrj48mM2yeT =hHmk -----END PGP SIGNATURE----- --nextPart1768965.Pnt4Yhm5g4-- From nobody Mon Jun 15 06:48: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 2CD3E1A8A4D for ; Mon, 15 Jun 2015 06:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 yYPTIT9Yed-P for ; Mon, 15 Jun 2015 06:48:35 -0700 (PDT) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (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 EC3D41A1A2F for ; Mon, 15 Jun 2015 06:48:34 -0700 (PDT) Received: by wgbhy7 with SMTP id hy7so36169700wgb.2 for ; Mon, 15 Jun 2015 06:48:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=fBBt4b/75Yp9Hb8jiZdukkLQzN2GyyXAdwXXU1rOrpo=; b=bGHWyogL0hsQ8til4scGrEzZ/iK5wWLrmg+xHNsAeN17yMDqqFI+pFZDIjA3H22s2i wwVz6YENsputNm75QRwAaUiGROtFrD/bsXC/YFR+HoeO9eqfk20C+UI3NJgvNlLKncsM ijgPi3aDPbB+6ijEr00znP/f5IkjttuWCJWoYaLOPWEk/u0oX+82QgbIQf9eUjwKA6tj FFIGMtWTx2anjrIkwWtYeR8ScKFhmpGePxcorsv/7PCMRRxc+Y51OLHelhrOAIFbuHPZ zc5dO88ok26rRhFLPYEHkj4YEWunAVUwAwvgXHmruDTRuYahXXIS9ZYdvrzRGtLf4jxM lhpQ== X-Gm-Message-State: ALoCoQlhqwWUr2TPlVqanZeuT1BXXbtjvHFyzHzzV6fbhUvKXmg6/FZIZU6Q/tHca+VcHN5TXwN4 X-Received: by 10.194.79.225 with SMTP id m1mr52852725wjx.8.1434376113707; Mon, 15 Jun 2015 06:48:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.225.14 with HTTP; Mon, 15 Jun 2015 06:47:53 -0700 (PDT) In-Reply-To: <20150615132919.GA28329@LK-Perkele-VII> References: <20150612180230.4804.45802.idtracker@ietfa.amsl.com> <20150612195654.GA9401@LK-Perkele-VII> <20150615130345.GJ14121@mournblade.imrryr.org> <20150615132919.GA28329@LK-Perkele-VII> From: Eric Rescorla Date: Mon, 15 Jun 2015 06:47:53 -0700 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=047d7b10c903bb6fc805188eb662 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] I-D Action: draft-ietf-tls-curve25519-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Jun 2015 13:48:37 -0000 --047d7b10c903bb6fc805188eb662 Content-Type: text/plain; charset=UTF-8 On Mon, Jun 15, 2015 at 6:29 AM, Ilari Liusvaara < ilari.liusvaara@elisanet.fi> wrote: > On Mon, Jun 15, 2015 at 01:03:45PM +0000, Viktor Dukhovni wrote: > > On Fri, Jun 12, 2015 at 01:43:25PM -0700, Martin Thomson wrote: > > > > > > "Servers MUST NOT select an ECDHE_ECDSA ciphersuite if there are no > > > > common curves suitable for ECDSA." > > > > > > > > You mean MUST NOT select ECDSA certificate? Because TLS 1.2 rules > > > > seemingly allow selecting ECDHE_RSA ciphersuite with ECDSA > > > > certificate. > > > > > > This seems right to me. The point here is that when a named_curve (or > > > named_group) identifies 25519, then it can't be used for ECDSA. 25519 > > > is always OK with an _RSA_ suite. > > > > It seems that provided there's also a named_curve for ECDSA > > that matches the certificate, then one might use 25519 for a key > > exchange that is signed with ECDSA. > > > > If both are supported I don't see why this combination should be > > excluded. What problem does the exclusion solve? > > > > If 25519 ECDH is faster and safer than with ECDSA why not use it > > even with servers that sign the parameters with ECDSA? > > The problem is that clients that support 25519 ECDHE might not > support any curve usable for ECDSA. > > And even if they did, they are very unlikely to support 25519 > ECDSA. Taking a step back, RFC 4492 doesn't contemplate the case that you could use curve X for (say) ECDHE and not for signature, though it *does* allow for you to use different curves: NOTE: A server participating in an ECDHE-ECDSA key exchange may use different curves for (i) the ECDSA key in its certificate, and (ii) the ephemeral ECDH key in the ServerKeyExchange message. The server must consider the extensions in both cases. So the problem is that the signal that RFC 4492 contemplates is not sufficiently rich to support this case. However, it's obviously desirable that you be able to do Curve25519 ECDHE while still doing P256 for signature. It seems that there are two potential solutions here (assuming that the CFRG actually comes up with a Curve25519-based signature scheme). 1. Decide that it's not ECDSA 2. Pretend that there are two curves: Curve25519_kex and Curve25519_sig. In the latter case, implementors of this draft would just advertise Curve25519_kex and future implementors of the signature draft would advertise Curve25519_sig. Note that we don't have to decide this questions now, since the issue does not yet arise. We can just state that advertising Curve25519 doesn't mean that you should do ECDSA with it. -Ekr --047d7b10c903bb6fc805188eb662 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jun 15, 2015 at 6:29 AM, Ilari Liusvaara <= ilari.lius= vaara@elisanet.fi> wrote:
On Mon, Jun 15, 2015 at 01:03:45PM +0000, Viktor Dukhovni wrote:
> On Fri, Jun 12, 2015 at 01:43:25PM -0700, Martin Thomson wrote:
>
> > > "Servers MUST NOT select an ECDHE_ECDSA ciphersuite if = there are no
> > > common curves suitable for ECDSA."
> > >
> > > You mean MUST NOT select ECDSA certificate? Because TLS 1.2 = rules
> > > seemingly allow selecting ECDHE_RSA ciphersuite with ECDSA > > > certificate.
> >
> > This seems right to me.=C2=A0 The point here is that when a named= _curve (or
> > named_group) identifies 25519, then it can't be used for ECDS= A.=C2=A0 25519
> > is always OK with an _RSA_ suite.
>
> It seems that provided there's also a named_curve for ECDSA
> that matches the certificate, then one might use 25519 for a key
> exchange that is signed with ECDSA.
>
> If both are supported I don't see why this combination should be > excluded.=C2=A0 What problem does the exclusion solve?
>
> If 25519 ECDH is faster and safer than with ECDSA why not use it
> even with servers that sign the parameters with ECDSA?

The problem is that clients that support 25519 ECDHE might not
support any curve usable for ECDSA.

And even if they did, they are very unlikely to support 25519
ECDSA.

Taking a step back, RFC 4492 doesn&#= 39;t contemplate the case that you could
use curve X for (say) EC= DHE and not for signature, though it *does*
allow for you to use = different curves:

=C2=A0 =C2=A0NOTE: A server= participating in an ECDHE-ECDSA key exchange may use
=C2=A0 =C2= =A0different curves for (i) the ECDSA key in its certificate, and (ii)
=C2=A0 =C2=A0the ephemeral ECDH key in the ServerKeyExchange message.= =C2=A0 The server
=C2=A0 =C2=A0must consider the extensions in bo= th cases.

So the problem is that the signal = that RFC 4492 contemplates is not sufficiently
rich to support th= is case. However, it's obviously desirable that you be able to
do Curve25519 ECDHE while still doing P256 for signature.

<= /div>
It seems that there are two potential solutions here (assuming th= at the CFRG
actually comes up with a Curve25519-based signature s= cheme).

1. Decide that it's not ECDSA
2. Pretend that there are two curves: Curve25519_kex and Curve25519_s= ig.

In the latter case, implementors of this draft= would just advertise Curve25519_kex
and future implementors of t= he signature draft would =C2=A0advertise Curve25519_sig.
Note tha= t we don't have to decide this questions now, since the issue does not = yet
arise. We can just state that advertising Curve25519 doesn= 9;t mean that you
should do ECDSA with it.

-Ekr



--047d7b10c903bb6fc805188eb662-- From nobody Mon Jun 15 06:50: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 0E4631ACD6A for ; Mon, 15 Jun 2015 06:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 qnRp-y6tDVvM for ; Mon, 15 Jun 2015 06:50:27 -0700 (PDT) Received: from emh07.mail.saunalahti.fi (emh07.mail.saunalahti.fi [62.142.5.117]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B75E41ACE3B for ; Mon, 15 Jun 2015 06:50:25 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id B5E1CA7589; Mon, 15 Jun 2015 16:50:23 +0300 (EEST) Date: Mon, 15 Jun 2015 16:50:23 +0300 From: Ilari Liusvaara To: Hubert Kario Message-ID: <20150615135023.GA28680@LK-Perkele-VII> References: <201506122145.13790.davemgarrett@gmail.com> <3129639.pNdByueU9m@pintsize.usersys.redhat.com> <20150615132353.GA27040@LK-Perkele-VII> <8295853.kIc6eIqDrM@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <8295853.kIc6eIqDrM@pintsize.usersys.redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Jun 2015 13:50:29 -0000 On Mon, Jun 15, 2015 at 03:36:44PM +0200, Hubert Kario wrote: > On Monday 15 June 2015 16:23:53 Ilari Liusvaara wrote: > > On Mon, Jun 15, 2015 at 12:10:39PM +0200, Hubert Kario wrote: > > > > > > Especially with the case of overloading the ECDHE to handle the ECDH_anon, > > > it makes it possible that many implementations will reintroduce state > > > machine bugs... > > > > Well, the server key exchange message is presumably the same for all GDHE > > key exchanges, so one parser could parse those all > > there's still the difference between signed vs not-signed The signature or not comes much later than key exchange message (TLS 1.2 had those in the same message, TLS 1.3 does not). > > (and pure-PSK would be > > separate, which doesn't even have server key exchange). > > pure PSK is outside TLSv1.3 as it doesn't provide PFS, ECDHE-PSK and DHE-PSK > though doesn't use signature on server key share Well, none of the key exchanges planned for TLS 1.3 have signature in server key share (signature is its own message if it appears). > > However, if we were serious about eliminating state machine bugs (and TLS > > 1.3 state machine is totally different from TLS 1.2), we would eliminate > > all optional messages (different from context-sensitive messages, like > > Server key exchange message), and then eliminate handshake message types > > (except for those which have to have type numbers for backward > > compatiblity). > > there's a difference between having messages which are optional from protocol > standpoint but are mandatory for given ciphersuite and messages which are > optional always Well, the former are what I called "context-sensitive". And presence or absence of those can be inferred from the past handshake. -Ilari From nobody Mon Jun 15 07:30: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 98EA01B2D9F for ; Mon, 15 Jun 2015 07:30:27 -0700 (PDT) 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 e_o0MeipD9U2 for ; Mon, 15 Jun 2015 07:30:25 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65AB31B2D9A for ; Mon, 15 Jun 2015 07:30:25 -0700 (PDT) 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 (Postfix) with ESMTPS id 2F0BE350112; Mon, 15 Jun 2015 14:30:25 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-196.brq.redhat.com [10.34.0.196]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t5FEUNn6003621 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 15 Jun 2015 10:30:24 -0400 From: Hubert Kario To: Ilari Liusvaara Date: Mon, 15 Jun 2015 16:30:16 +0200 Message-ID: <4377771.p3nGbdM9qk@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.7 (Linux/4.0.4-202.fc21.x86_64; KDE/4.14.7; x86_64; ; ) In-Reply-To: <20150615135023.GA28680@LK-Perkele-VII> References: <201506122145.13790.davemgarrett@gmail.com> <8295853.kIc6eIqDrM@pintsize.usersys.redhat.com> <20150615135023.GA28680@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart7398370.DcBUk5ymSD"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Jun 2015 14:30:27 -0000 --nextPart7398370.DcBUk5ymSD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Monday 15 June 2015 16:50:23 Ilari Liusvaara wrote: > On Mon, Jun 15, 2015 at 03:36:44PM +0200, Hubert Kario wrote: > > On Monday 15 June 2015 16:23:53 Ilari Liusvaara wrote: > > > On Mon, Jun 15, 2015 at 12:10:39PM +0200, Hubert Kario wrote: > > > > Especially with the case of overloading the ECDHE to handle the= > > > > ECDH_anon, > > > > it makes it possible that many implementations will reintroduce= state > > > > machine bugs... > > > However, if we were serious about eliminating state machine bugs = (and > > > TLS > > > 1.3 state machine is totally different from TLS 1.2), we would el= iminate > > > all optional messages (different from context-sensitive messages,= like > > > Server key exchange message), and then eliminate handshake messag= e types > > > (except for those which have to have type numbers for backward > > > compatiblity). > >=20 > > there's a difference between having messages which are optional fro= m > > protocol standpoint but are mandatory for given ciphersuite and mes= sages > > which are optional always >=20 > Well, the former are what I called "context-sensitive". And presence = or > absence of those can be inferred from the past handshake. yes, and I'm saying we should be careful not to introduce ones which ca= n not=20 be inferred from previous messages putting ECDH_anon or ECDHE_PSK behind ECDHE_ECDSA_* ciphersuites makes = this=20 likely =2D-=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 --nextPart7398370.DcBUk5ymSD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJVfuF+AAoJEJKo0bgB0vX14iAP/1FJ4sAs8GdOaas7B1P9jFgt EwOZ6VmQ/IIDMkD0BUDmdkrRuna/Fu7maFmTaX/hKS9ftLAaz6f0cHr2Au1KxqcA DHQkLXzYuka/IVmR6E2Gntg1yjoRv6VaU+6c1C3Eklv+NHqFUwfUJe+62Z58Xfln AwFXaeX4N20GBirak/xoAZo77/IT66nrfg8OfZP6nbaZz0L2qErT7FlKZwvbA0Zd VYaDoGHkeSDrA1G+8MEqZELU7YDXUcUBIAN20bBMnjNHc1fP/GCsicao+8nscFP0 zmsj2nUC/3SE7hc8L4St8zJIcmWSRfYM2IaHmyYHZsWELEhA2gGhK9SkI0z4X0TM d/TFYeR4IyGpRBTMlxnalvSkjKobixmKzoN9m7zCE/dyiFbj9sor9ahN/siNFjNm 5jxkJPtLr5YNVdblS+Uvic43MaKRgb/34NZfGQgT3p4Oj1qODygWR0a6+lV6Rg9d mIfPgAWr6SAGiXVktukK0SGBwbeomEXqyUkezbyWPVHB3ADeHG0UJaJ4cI2zW30B WagJyLXTf9IVvCdKf4aSzOzM4/MTZIhg+QJipU2y4Ufv7MvDcY1KkLbg53izn1Z1 d6ZzDSEdxUOB2IE8LUWfmL6jlXNV6f3wTFelJPLuhftgQU/tBsoD2kMCHN/IarUL g4P9WEkzAfaaxJH41P4U =IaUV -----END PGP SIGNATURE----- --nextPart7398370.DcBUk5ymSD-- From nobody Mon Jun 15 08:22: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 433EA1A883D for ; Mon, 15 Jun 2015 08:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 PBWXQUiZ114n for ; Mon, 15 Jun 2015 08:21:52 -0700 (PDT) Received: from emh03.mail.saunalahti.fi (emh03.mail.saunalahti.fi [62.142.5.109]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37A171B2E75 for ; Mon, 15 Jun 2015 08:21:48 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id B7D41188868; Mon, 15 Jun 2015 18:21:45 +0300 (EEST) Date: Mon, 15 Jun 2015 18:21:45 +0300 From: Ilari Liusvaara To: Hubert Kario Message-ID: <20150615152145.GA30212@LK-Perkele-VII> References: <201506122145.13790.davemgarrett@gmail.com> <8295853.kIc6eIqDrM@pintsize.usersys.redhat.com> <20150615135023.GA28680@LK-Perkele-VII> <4377771.p3nGbdM9qk@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4377771.p3nGbdM9qk@pintsize.usersys.redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Jun 2015 15:21:57 -0000 On Mon, Jun 15, 2015 at 04:30:16PM +0200, Hubert Kario wrote: > On Monday 15 June 2015 16:50:23 Ilari Liusvaara wrote: > > On Mon, Jun 15, 2015 at 03:36:44PM +0200, Hubert Kario wrote: > > > > > > there's a difference between having messages which are optional from > > > protocol standpoint but are mandatory for given ciphersuite and messages > > > which are optional always > > > > Well, the former are what I called "context-sensitive". And presence or > > absence of those can be inferred from the past handshake. > > yes, and I'm saying we should be careful not to introduce ones which can not > be inferred from previous messages > > putting ECDH_anon or ECDHE_PSK behind ECDHE_ECDSA_* ciphersuites makes this > likely Unfortunately, things get nasty when considering extensions that introduce new handshake messages. Especially if you have multiple such things trying to put messages in the same "slot": Scanning TLS registeries and relevant RFCs, I found 7: client_certificate_url(2) uses certificate_url(21) This extension is somewhat dangerous. status_request(5) uses certificate_status(22) Obsoleted by status_request_v2 user_mapping(6) uses supplemental_data(23) Dunno about this. client_authz(7) uses supplemental_data(23) Infamous. server_authz(8) -> supplemental_data(23) Infamous. status_request_v2(17) -> certificate_status(22) This one looks to be in actual use. SessionTicket TLS(35) -> NewSessionTicket(4) Related to resumption in TLS 1.0-1.2 The slots these messages go is (apparently): certificate_url: Replaces certificate certificate_status: Immediately after certificate supplemental_data: Immediately before certificate NewSessionTicket: Immediately before server CCS. -Ilari From nobody Mon Jun 15 08:40: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 2916E1B2EE4 for ; Mon, 15 Jun 2015 08:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gr0i72d0ZK5b for ; Mon, 15 Jun 2015 08:40:26 -0700 (PDT) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d: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 DB5FF1B2EF5 for ; Mon, 15 Jun 2015 08:40:25 -0700 (PDT) Received: by qcwx2 with SMTP id x2so3927005qcw.1 for ; Mon, 15 Jun 2015 08:40:25 -0700 (PDT) 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=nB1rGHB6TbzRZ0DgjtFKvUsq9uo3ZJl+2sQ5MpUWlHc=; b=WU7cExH78e95DpWWPgBjSP/Vwu5W0PPbvIyjgIjt54Nm+QvOwoEFK+rSnIzwkWuRYN WMB5NMS6VpO1RWEL8p6t07p2w3kDE+9WLnaFP4FbF+wqshuqzicwUL4JgicxPtL6jXYj IDnaLLZy+08UYGz1dtXAhqFwZsQhBvdUSjthLO/FGM7AYDc3MU4RxUk5xYDZ1T9KdpyR K3CgXmhC+GcjLO9FX3oEeDocjAzuWg5eNv3H36LhGWJ1oQ8q5brDb8bl9C+mjUBRyP8B ++vADvta+nusMAYB+r2F7pm9Yn3qytzC3OcSSj5PKr8H29ZOzhHG07LjRT6MGqJk92DL pumg== X-Received: by 10.140.133.9 with SMTP id 9mr37927614qhf.5.1434382825184; Mon, 15 Jun 2015 08:40:25 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id g92sm6474333qgf.20.2015.06.15.08.40.24 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 15 Jun 2015 08:40:24 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Mon, 15 Jun 2015 11:40:23 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201506122145.13790.davemgarrett@gmail.com> <20150615135023.GA28680@LK-Perkele-VII> <4377771.p3nGbdM9qk@pintsize.usersys.redhat.com> In-Reply-To: <4377771.p3nGbdM9qk@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201506151140.23411.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Jun 2015 15:40:28 -0000 On Monday, June 15, 2015 10:30:16 am Hubert Kario wrote: > On Monday 15 June 2015 16:50:23 Ilari Liusvaara wrote: > > On Mon, Jun 15, 2015 at 03:36:44PM +0200, Hubert Kario wrote: > > > On Monday 15 June 2015 16:23:53 Ilari Liusvaara wrote: > > > > On Mon, Jun 15, 2015 at 12:10:39PM +0200, Hubert Kario wrote: > > > > > Especially with the case of overloading the ECDHE to handle the > > > > > ECDH_anon, > > > > > it makes it possible that many implementations will reintroduce state > > > > > machine bugs... > > > > However, if we were serious about eliminating state machine bugs (and > > > > TLS > > > > 1.3 state machine is totally different from TLS 1.2), we would eliminate > > > > all optional messages (different from context-sensitive messages, like > > > > Server key exchange message), and then eliminate handshake message types > > > > (except for those which have to have type numbers for backward > > > > compatiblity). > > > > > > there's a difference between having messages which are optional from > > > protocol standpoint but are mandatory for given ciphersuite and messages > > > which are optional always > > > > Well, the former are what I called "context-sensitive". And presence or > > absence of those can be inferred from the past handshake. > > yes, and I'm saying we should be careful not to introduce ones which can not > be inferred from previous messages > > putting ECDH_anon or ECDHE_PSK behind ECDHE_ECDSA_* ciphersuites makes this > likely I do agree that there is a risk of implementations introducing bugs. It's a matter of which new system with the potential for bugs we think has a lesser risk in comparison to the combinatorial exploded mess we have now. The compromise between the current line of discussion (ECDHE_ECDSA for everything) vs. what is currently in my proposal on GitHub (ECDHE_ECDSA | ECDHE_PSK | ECDH_anon) could be to only merge all the certificate authentication under ECDHE_ECDSA and merge PSK and anon under ECDHE_PSK. This would have certificate based suites and non-certificate based suites as fundamentally separate, but still notably reduce the number of suites that have to be worried about in the specs. (anon just becomes a special case of PSK) Dave From nobody Mon Jun 15 09:58: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 E42721A90E9 for ; Mon, 15 Jun 2015 09:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQJ6Ba0-k6RA for ; Mon, 15 Jun 2015 09:58:40 -0700 (PDT) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) (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 9FE3C1A90FC for ; Mon, 15 Jun 2015 09:57:50 -0700 (PDT) Received: by ykar6 with SMTP id r6so34944859yka.2 for ; Mon, 15 Jun 2015 09:57:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=2NxbCMgNGvS98+Wex8+U8yjg9ZXh6PEr0YKZ+6rezBY=; b=n/2EIRI3fr2LyA/pOOmUtUCfDUIwi14pt9ZnoRkSweONAVN0cIuajoQ2lJ+R4/tYB7 pd6JZl25dA90txC2gbNlWpSKz/BLVeKikJd018Fq3X2OyR0YiEG8c1uRfYW1BzuU/vTt QsLF7gBu6Rhh0fNjR2/vvBVO/xSJZVgeXjOe8nxP5v2nde3etDzZTM5ttKxVQVH8fblw dn0RKztQbTbYroSKHjqoLy0ILRzXzaYiC0hxTld3uwcdn2LU0C/cTkcJuz8tDxej1+Cx rF4Qjn96whbRJul9UQNFR90C3VT9oQGTMPB+xbcOYcPub+TfBmpINNDLr/nee9JNcfMx r7Zg== MIME-Version: 1.0 X-Received: by 10.170.90.5 with SMTP id h5mr35245828yka.26.1434387470126; Mon, 15 Jun 2015 09:57:50 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Mon, 15 Jun 2015 09:57:50 -0700 (PDT) In-Reply-To: <20150615130345.GJ14121@mournblade.imrryr.org> References: <20150612180230.4804.45802.idtracker@ietfa.amsl.com> <20150612195654.GA9401@LK-Perkele-VII> <20150615130345.GJ14121@mournblade.imrryr.org> Date: Mon, 15 Jun 2015 09:57:50 -0700 Message-ID: From: Martin Thomson To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-curve25519-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Jun 2015 16:58:43 -0000 On 15 June 2015 at 06:03, Viktor Dukhovni wrote: > It seems that provided there's also a named_curve for ECDSA > that matches the certificate, then one might use 25519 for a key > exchange that is signed with ECDSA. Perhaps I wasn't clear about this. I'm saying that we need one named_curve for 25519 + ECDH and another for Ec25519 + "ECDSA". From nobody Mon Jun 15 09:59: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 3F5271A90E9 for ; Mon, 15 Jun 2015 09:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lOW2XXu-OZS for ; Mon, 15 Jun 2015 09:59:51 -0700 (PDT) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (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 104341A90F1 for ; Mon, 15 Jun 2015 09:59:35 -0700 (PDT) Received: by ykaz81 with SMTP id z81so61599831yka.3 for ; Mon, 15 Jun 2015 09:59:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iGC9wQKR1erB8Pmm6TPMl52khQVLP3JboZ6Rmz5g+sE=; b=fK2MdM9VvyeCcj5V8eVQ4CU4snSdXaPUGU7y3fZ9adx5BPRIWAisiTOtOMgvRM1nXK 2y/kgJsecroGaWpucWRTDTlbQ15K92frs3Yrcv8TA02a5KQL0IvXCfj7UIAfJj6zsgoV uocHXBBesyOsgoy2jmcmfleVE4TpND5JvoWoOEOOc7mh/deNcRaghcjE+hziAnBUpZQU TA7CtEQmUfSTnXX/JMuFah1fYmX0mMH1FjyYGaiF/jdw0TznY864reyDxbiXD9m/LRKk oCDxGRBAk/+yhQwwTKiJzFviH0TuR0URRXVQd6TFlNOZbOSG8hEhph01U7WnAyvOVRcY jHBQ== MIME-Version: 1.0 X-Received: by 10.13.226.75 with SMTP id l72mr36359593ywe.89.1434387575459; Mon, 15 Jun 2015 09:59:35 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Mon, 15 Jun 2015 09:59:35 -0700 (PDT) In-Reply-To: References: <20150612180230.4804.45802.idtracker@ietfa.amsl.com> <20150612195654.GA9401@LK-Perkele-VII> <20150615130345.GJ14121@mournblade.imrryr.org> <20150615132919.GA28329@LK-Perkele-VII> Date: Mon, 15 Jun 2015 09:59:35 -0700 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] I-D Action: draft-ietf-tls-curve25519-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Jun 2015 16:59:52 -0000 On 15 June 2015 at 06:47, Eric Rescorla wrote: > In the latter case, implementors of this draft would just advertise > Curve25519_kex > and future implementors of the signature draft would advertise > Curve25519_sig. > Note that we don't have to decide this questions now, since the issue does > not yet > arise. We can just state that advertising Curve25519 doesn't mean that you > should do ECDSA with it. And I'd be happy with this outcome too. That is, we might decide later to reuse the code point. Of course, I'd still argue not to do the overload, based on the potential for implementations to support one and not t'other. From nobody Mon Jun 15 13:33: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 8C06D1A8AAA for ; Mon, 15 Jun 2015 13:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nWbkr-9DMJya for ; Mon, 15 Jun 2015 13:33:30 -0700 (PDT) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) (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 8DFC21A8A8D for ; Mon, 15 Jun 2015 13:33:30 -0700 (PDT) Received: by qcej3 with SMTP id j3so9998799qce.3 for ; Mon, 15 Jun 2015 13:33:29 -0700 (PDT) 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=do6SjepwxeelQk9xTqOvvSdzmwNaOiU3YEzktFhB9RE=; b=XQZSffNa6qPDawLPbKIF6wi/nZVHD2UAiar1/pVlT9kxXal7mgvyLJMv6XGbgzESxD dekibrk1PxBLaqgN5RajSVDrtG1s1Krqbd5/ii+q2KaeuMFAP57ZKXWLCrQx0Mfpw6Zx Odisu3jmGwhytxBZnnVGLXjlx8KYPXClp/YBFKYFJvwHTczEp2EcROgZ4LAT0SsVTWhs QBHOoMuLOsHf8eMMWMSBmZN/fsT3RAQZBNyCToC9MqxUbTB9q5rvsIFDzOPz8AmbltLK Rtt4FRjCUhxcZQO/bzciPlbr6Da9vIvnEnRkBg/heJjMFAftRyfKJ/JB0rXeJj1cEqXJ OSuA== X-Received: by 10.55.52.12 with SMTP id b12mr62223296qka.22.1434400409740; Mon, 15 Jun 2015 13:33:29 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id c38sm6900385qgd.33.2015.06.15.13.33.29 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 15 Jun 2015 13:33:29 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Mon, 15 Jun 2015 16:33:27 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <20150612180230.4804.45802.idtracker@ietfa.amsl.com> <20150615130345.GJ14121@mournblade.imrryr.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201506151633.28010.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-curve25519-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Jun 2015 20:33:32 -0000 On Monday, June 15, 2015 12:57:50 pm Martin Thomson wrote: > I'm saying that we need one named_curve for 25519 + ECDH and another > for Ec25519 + "ECDSA". Related issue: "Add ability to negotiate curves for ECDHE independently of curves for ECDSA signatures #162" https://github.com/tlswg/tls13-spec/issues/162 https://tlswg.github.io/tls13-spec/#negotiated-groups The simple solution would just be to just fork all codepoints into separate ECDH & ECDSA versions. (except the 10 or so <100-bit security level ones that should just get dropped) If this already effectively needs to be done for Curve25519, then doing it for all at seems like the most straightforward route. There's enough bits available that the high bit could just be used to indicate ECDSA-only, all the new ones could just be old+0x8000, and they'd be easy to distinguish from each other as-needed. Dave From nobody Mon Jun 15 13:58: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 1F64B1ACED9 for ; Mon, 15 Jun 2015 13:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 O8ZLzBxZqxNt for ; Mon, 15 Jun 2015 13:57:57 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 050971ACED8 for ; Mon, 15 Jun 2015 13:57:56 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t5FKvno5003876 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 15 Jun 2015 22:57:50 +0200 From: Simon Josefsson To: Viktor Dukhovni References: <20150611170317.13732.72719.idtracker@ietfa.amsl.com> <201506122355.45772.davemgarrett@gmail.com> <87r3petrfq.fsf@latte.josefsson.org> <20150614134639.GN2050@mournblade.imrryr.org> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:150615:tls@ietf.org::hN1v+zz3oBOm8q/u:0utq X-Hashcash: 1:22:150615:ietf-dane@dukhovni.org::B5RLZ5ZMEyy9IczK:4yyc Date: Mon, 15 Jun 2015 22:57:48 +0200 In-Reply-To: <20150614134639.GN2050@mournblade.imrryr.org> (Viktor Dukhovni's message of "Sun, 14 Jun 2015 13:46:39 +0000") Message-ID: <87bnggk7ub.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] I-D Action: draft-ietf-tls-chacha20-poly1305-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Jun 2015 20:57:58 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Viktor Dukhovni writes: > On Sun, Jun 14, 2015 at 02:17:29PM +0200, Simon Josefsson wrote: > >> > After discussion earlier involving ECDHE_anon cipher suites, it >> > occurred to me that it could be useful to define one for ChaChaPoly in >> > this draft. >> > >> > Is it viable to add a cipher suite name and codepoint for this? >>=20 >> What is the use-case? > > 0. Authentication other than via certificate-based PKI. Establish > anon TLS, and channel-bind the TLS-unique via GSSAPI or some > other authentication method. > > 1. Unauthenticated opportunistic TLS. > > * Server performs no unnecessary signature operations, > since the client can't verify the signature anyway. > (More precisely the client can't verify the authenticity > of the server keys, so it can only determine that somebody > signed the handshake, but no idea whether it is the intended > server). Both those use-cases can be achieved by chosing, say, ECDHE_ECDSA and not verify the signature, right? > * Servers can tell which clients are not verifying their > identity, (definitely the ones the offer or negotiate "anon" > ciphersuites). This is useful information. I don't think you can necessarily infer that from what a client offers. It may behave differently depending on which ciphersuite is chosen. However, maybe we can do: TLS_ECDHE_anon_WITH_CHACHA20_POLY1305 =3D {0xTBD, 0xTBD} {0xCC, 0xA4} I'd appreciate if others could weigh in their opinion on whether more ECDHE_anon ciphersuites are important or not. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJVfzxMAAoJEIYLf7sy+BGdR+wIAIKHQRywYTwPUOv7QiYPPWuM ZDYYzKpmVS9K37qMT4Ckxusr+IvNh5rB4hjxgXXuUatTA+abVJT0LHpIaNTAdXIQ uYrY3y7ngvGUxB7CG1bHDw6Xv0VxMU4C4XElhj+Rt01yfsNUdmVk8Kn6gZcr29Dc qphgPMqSBJHNXKP4dsl2kXeVC7AFiGD8F70CtVMmI8YEQftaOfGbbviilipNJWtQ 909mGsx0SpADVwKpytXKVmsi2qmP0hljOKezka3B+bQPFiJYhTT1REuA4sXx9ps+ KT6vq5PnkiXCwx9EtBZScTQcP80la3FjbqvGhxf6ROKJ63N8j9UmMk7NEM19DKo= =rJGF -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 15 14:06: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 175211AD190 for ; Mon, 15 Jun 2015 14:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.951 X-Spam-Level: X-Spam-Status: No, score=-0.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vz8m5H-1xi0N for ; Mon, 15 Jun 2015 14:06:25 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 9C2FA1AD182 for ; Mon, 15 Jun 2015 14:06:24 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t5FL68c1004836 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 15 Jun 2015 23:06:10 +0200 From: Simon Josefsson To: Martin Thomson References: <20150612180230.4804.45802.idtracker@ietfa.amsl.com> <20150612195654.GA9401@LK-Perkele-VII> <20150615130345.GJ14121@mournblade.imrryr.org> <20150615132919.GA28329@LK-Perkele-VII> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:150615:ekr@rtfm.com::mCOZFEHjgEKJ/6Oc:3Xgc X-Hashcash: 1:22:150615:tls@ietf.org::kbXlAtvszzSRHSgZ:9wt1 X-Hashcash: 1:22:150615:martin.thomson@gmail.com::gaRi0AH3NLhiO6cq:NXg3 Date: Mon, 15 Jun 2015 23:06:07 +0200 In-Reply-To: (Martin Thomson's message of "Mon, 15 Jun 2015 09:59:35 -0700") Message-ID: <877fr4k7gg.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] I-D Action: draft-ietf-tls-curve25519-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Jun 2015 21:06:26 -0000 --=-=-= Content-Type: text/plain Martin Thomson writes: > On 15 June 2015 at 06:47, Eric Rescorla wrote: >> In the latter case, implementors of this draft would just advertise >> Curve25519_kex >> and future implementors of the signature draft would advertise >> Curve25519_sig. >> Note that we don't have to decide this questions now, since the issue does >> not yet >> arise. We can just state that advertising Curve25519 doesn't mean that you >> should do ECDSA with it. > > And I'd be happy with this outcome too. That is, we might decide > later to reuse the code point. > > Of course, I'd still argue not to do the overload, based on the > potential for implementations to support one and not t'other. I agree. I changed the document to say: Servers MUST NOT select an ECDSA certificate if there are no common curves suitable for ECDSA. https://gitlab.com/jas/ietf-tls-newcurves/commit/e9bf1cbfe136d5b53cc9e52681b0a98ccaabcb44#diff-1 > On 15 June 2015 at 06:03, Viktor Dukhovni wrote: >> It seems that provided there's also a named_curve for ECDSA >> that matches the certificate, then one might use 25519 for a key >> exchange that is signed with ECDSA. > > Perhaps I wasn't clear about this. > > I'm saying that we need one named_curve for 25519 + ECDH and another > for Ec25519 + "ECDSA". I am currently thinking the same. That's what draft-josefsson-tls-eddsa2 does. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJVfz5AAAoJEIYLf7sy+BGd+6AIAJBmcNlBFcU43a/KlCwU20CO twy9Acrzmd8oEF4/P7viRh+l5Oxzsr2GKMcWu/qoehHgOXH/imjtgerdqECvLzHC uRIigRAVfyEsVhpAJS2c4XO4z9vqAesKC9e5KxOa7vce4BHS9PnK+S6nagmnnBio JfGSAhGpuXxzX18la3O1NpNUpuBQ6oznTn/rWZU41b6gw6bU87ChDKRJiNFEyYXh TGQ5ovMCdtwwLOLnxVfXoMS2sbQ+LkEonEAbuq2vzH49k7KHxprfHsabVFFJAJe7 +suVvCmQdC2SoGL+xsbM0eeHnMx1DIBNOFd53qtwotu7GYuaFxs7mznXfwq0FWA= =VQ8Y -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 15 14:13: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 0E7DE1B2A30 for ; Mon, 15 Jun 2015 14:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 uNUYbIPLrrD0 for ; Mon, 15 Jun 2015 14:13:00 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 905371B2A39 for ; Mon, 15 Jun 2015 14:12:46 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t5FLCHkq005306 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 15 Jun 2015 23:12:19 +0200 From: Simon Josefsson To: Eric Rescorla References: <20150612180230.4804.45802.idtracker@ietfa.amsl.com> <20150612195654.GA9401@LK-Perkele-VII> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:150615:ekr@rtfm.com::8H/rgY0ypkM/tn/w:8I9c X-Hashcash: 1:22:150615:tls@ietf.org::DqxQpKgmXA5ZtC2Y:kA+O X-Hashcash: 1:22:150615:ilari.liusvaara@elisanet.fi::+LLSErqwxT9YXzc0:gZel Date: Mon, 15 Jun 2015 23:12:16 +0200 In-Reply-To: (Eric Rescorla's message of "Fri, 12 Jun 2015 16:04:48 -0400") Message-ID: <87381sk767.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] I-D Action: draft-ietf-tls-curve25519-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Jun 2015 21:13:01 -0000 --=-=-= Content-Type: text/plain Eric Rescorla writes: >> "This section defines a new point format suitable to encode Curve25519 >> public keys, as well as an identifier to negotiate this new format in >> TLS, and includes guidance on their use." >> >> Is this format going to be the chosen one for TLS 1.3? Because TLS 1.3 >> can't negotiate point formats for ECDHE. >> >> Also, I don't see the value of trying to negotiate the point format, >> and I think that the negotiation will act as an implementation error >> source. > > > I would suggest claiming that this point format is "uncompressed" and the > only point format for Curve25519. I'm happy to do that. Anyone against? If I understand correctly, I would drop most of the montgomery_x_le ECPointFormat registration and instead say: use ECPointFormat "uncompressed" and send the public-key formatted as follows [...]. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJVfz+wAAoJEIYLf7sy+BGdJWoIAILLoXTLvSp/wR09tDUvVLcq 1nbJgOQDbORH7oprmr9VM+ICfcwCuL3W+DgytSXbYGgt59IaijuOkGTpenr5rr6t 4ZpovMjtswNmC7Adp9q5TcXGnpsV9cgsh2+qngh+10jnfHz2mPOH4yljumi00Nss Q+g1n8Eu7UrvcfztSDvGSIOZD8la9a/BgDv196eF5DBR1gkfP1x5jI50RVK+N4Pb 9CwqiiNq1Xcxcvwbh2+O3q9eu/mswRK2k1gz0adntHPlPEyKvc/IdF35VovsUuio gtV+nitZBCINCb4EG5uSGwhYBxuk9oNA8hAXOzfbobWuW1bU4mFNLCadGsHR5lg= =fXfb -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 15 14:22: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 628D81B2A8C for ; Mon, 15 Jun 2015 14:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cr6GXMPCLdCx for ; Mon, 15 Jun 2015 14:22:36 -0700 (PDT) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001: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 40AB81B2A4F for ; Mon, 15 Jun 2015 14:22:36 -0700 (PDT) Received: by igboe5 with SMTP id oe5so40613929igb.1 for ; Mon, 15 Jun 2015 14:22:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GrmeEhBjeKMkohUrMzOSxTyYoxMBmIz/g6/bZwBHLhs=; b=RrGqREmfsGYt4/d1zV0vTI4+eh3AxGCFv2PvZbckUGMfd6vcKvl2pW62I9QizoatV6 X5iwS1AcfsN16oCDlqdGl++B7e1z61nX0wIYCPw7VdHjB9mF6MvP94ei/Hz85jvH53Ux eQ+lAf4RgdTsw3E8I1UzsLHK9YIe1pRXYsP6vdKT+2B9/UmeWCkWXD0HWdphqLtGCc8D tnR2e9ZUQWak4Uf/Z+pXgnnkeOt+cNArIq/HMNgJVRyGFi3za/oc/ukCad7lEc9hSc72 DydbkzLPKUjiMLGxaNKd1iE4u+rxbONgRF0acI7W4WY4njlPjqot5fOJT21h+uzBKaxx wBqA== MIME-Version: 1.0 X-Received: by 10.50.110.104 with SMTP id hz8mr23319349igb.38.1434403355699; Mon, 15 Jun 2015 14:22:35 -0700 (PDT) Received: by 10.64.5.37 with HTTP; Mon, 15 Jun 2015 14:22:35 -0700 (PDT) In-Reply-To: <87381sk767.fsf@latte.josefsson.org> References: <20150612180230.4804.45802.idtracker@ietfa.amsl.com> <20150612195654.GA9401@LK-Perkele-VII> <87381sk767.fsf@latte.josefsson.org> Date: Mon, 15 Jun 2015 14:22:35 -0700 Message-ID: From: Martin Thomson To: Simon Josefsson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] I-D Action: draft-ietf-tls-curve25519-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Jun 2015 21:22:37 -0000 On 15 June 2015 at 14:12, Simon Josefsson wrote: >> I would suggest claiming that this point format is "uncompressed" and the >> only point format for Curve25519. > > I'm happy to do that. Anyone against? If I understand correctly, I > would drop most of the montgomery_x_le ECPointFormat registration and > instead say: use ECPointFormat "uncompressed" and send the public-key > formatted as follows [...]. The CFRG draft defines 25519 to take a 32 byte string. Use that directly. Just *claim* that it's uncompressed. You don't have to add a 4 at the front, or mess around with forms. Just define (by reference to draft-irtf-cfrg-curves, preferably) the format. We have plenty of contextual information available in TLS, we just need the bytes. From nobody Mon Jun 15 14: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 447891A8754 for ; Mon, 15 Jun 2015 14:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 HkPk-xyIyHNx for ; Mon, 15 Jun 2015 14:40:28 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 1760F1A8748 for ; Mon, 15 Jun 2015 14:40:27 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t5FLeCcf007972 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 15 Jun 2015 23:40:13 +0200 From: Simon Josefsson To: Martin Thomson References: <20150612180230.4804.45802.idtracker@ietfa.amsl.com> <20150612195654.GA9401@LK-Perkele-VII> <87381sk767.fsf@latte.josefsson.org> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:150615:tls@ietf.org::d5Jy+xogI1+Y/FH9:f3A X-Hashcash: 1:22:150615:martin.thomson@gmail.com::NiN11DUIRncuU3S9:6U7x Date: Mon, 15 Jun 2015 23:40:11 +0200 In-Reply-To: (Martin Thomson's message of "Mon, 15 Jun 2015 14:22:35 -0700") Message-ID: <87twu8irb8.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] I-D Action: draft-ietf-tls-curve25519-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Jun 2015 21:40:29 -0000 --=-=-= Content-Type: text/plain Martin Thomson writes: > On 15 June 2015 at 14:12, Simon Josefsson wrote: >>> I would suggest claiming that this point format is "uncompressed" and the >>> only point format for Curve25519. >> >> I'm happy to do that. Anyone against? If I understand correctly, I >> would drop most of the montgomery_x_le ECPointFormat registration and >> instead say: use ECPointFormat "uncompressed" and send the public-key >> formatted as follows [...]. > > The CFRG draft defines 25519 to take a 32 byte string. Use that > directly. Just *claim* that it's uncompressed. > > You don't have to add a 4 at the front, or mess around with forms. > Just define (by reference to draft-irtf-cfrg-curves, preferably) the > format. We have plenty of contextual information available in TLS, we > just need the bytes. I agree! Committed as follows: https://gitlab.com/jas/ietf-tls-newcurves/commit/e7b449ee5af70c2a0851f617ce225f93cc86d993#diff-1 /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJVf0Y7AAoJEIYLf7sy+BGd7R8H/02l+f8HbIRzFIvTdgFZbh9c y1SYLQLLkDsFFi4yQWfuPosQ3vDQu3oks/eT2v7DTdrtFMBSxosT4ciu5f3u5Q3A 4I4sqzDNtOdzmfT8lcpr0NGhAP7Vk7ktVTYmnWx3enRSlKioQF9rBPDHz54agULo bm1/eZcycMh6UJA+vciM66kV6Mt/43i3Fnr5l0V/bHYvV/seA3WRiJPT9NVoMpcj sA0HzkBPt/MgrtmgJ2QE6wsmuulzZEHdk65q9gyohCVsC5zk8bRDtRIk2+R7j9ov YwVKbLx5qBP21yctEBEo/TxsLJEVU7L3fIXTycWJlUhE/jOY40fmxNt30UG1oE4= =ZBMX -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 15 16:46: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 41B1A1B30E8 for ; Mon, 15 Jun 2015 16:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rrEwJbuexTi1 for ; Mon, 15 Jun 2015 16:46:03 -0700 (PDT) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::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 AC4561B30EA for ; Mon, 15 Jun 2015 16:46:01 -0700 (PDT) Received: by igboe5 with SMTP id oe5so42768949igb.1 for ; Mon, 15 Jun 2015 16:46:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ATYGMWEPCuldAW7+JJROFf/6XmlxH7ehviF8bBiN5ZM=; b=mNgK2rpu5lqj/7rcq1vxubYc1nTzLHB/njArKz8ZGU4vpkiyGA9s+idARDCLqosjz6 TV5W8JrhmjZSrr7yO72yPOK0GODZEB/qTV34B50waS+BhvZKngtpNsbceNN0aOtO0PhE sjKphOlofCiuU6iisn14d4Mne++NAxGMXNDbNtLxww3c6SbD/Hc2AiaW5VRavtgJN28d cWkl6AApFc+Xv2I7s3K8BwCBh8br9wEQz44k9gJpqmXoVyzXRM11MU7CwrPWzCy04oMZ qipRFcrjs5K0zwYOO0XfQ+er4bX8VD8ufGGFl1tRN/UV/cG6PsFMmkSFIikTjiEbfnsy 8kaA== MIME-Version: 1.0 X-Received: by 10.107.40.144 with SMTP id o138mr38171562ioo.66.1434411961228; Mon, 15 Jun 2015 16:46:01 -0700 (PDT) Received: by 10.36.77.15 with HTTP; Mon, 15 Jun 2015 16:46:01 -0700 (PDT) In-Reply-To: <87bnggk7ub.fsf@latte.josefsson.org> References: <20150611170317.13732.72719.idtracker@ietfa.amsl.com> <201506122355.45772.davemgarrett@gmail.com> <87r3petrfq.fsf@latte.josefsson.org> <20150614134639.GN2050@mournblade.imrryr.org> <87bnggk7ub.fsf@latte.josefsson.org> Date: Mon, 15 Jun 2015 19:46:01 -0400 Message-ID: From: Jeffrey Walton To: Simon Josefsson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] I-D Action: draft-ietf-tls-chacha20-poly1305-00.txt 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: Mon, 15 Jun 2015 23:46:05 -0000 >>> What is the use-case? >> >> 0. Authentication other than via certificate-based PKI. Establish >> anon TLS, and channel-bind the TLS-unique via GSSAPI or some >> other authentication method. >> >> 1. Unauthenticated opportunistic TLS. >> >> * Server performs no unnecessary signature operations, >> since the client can't verify the signature anyway. >> (More precisely the client can't verify the authenticity >> of the server keys, so it can only determine that somebody >> signed the handshake, but no idea whether it is the intended >> server). > > Both those use-cases can be achieved by choosing, say, ECDHE_ECDSA and > not verify the signature, right? > That's a violation of the engineering requirements :) If you don't need server authenticity, then you don't ask for it. If you ask for it, then you have to validate it. I know I'm splitting hairs, but I would reject that kind of check-in. I fear a proliferation of https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html. It also creates a few extra rules, and we have to teach them to developers, QA and auditors. Jeff From nobody Tue Jun 16 01:08: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 05D7E1B3372 for ; Tue, 16 Jun 2015 01:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 BV5i_CZNdJ9q for ; Tue, 16 Jun 2015 01:08:38 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 26C6C1B336E for ; Tue, 16 Jun 2015 01:08:37 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t5G88W8I003018 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 16 Jun 2015 10:08:34 +0200 From: Simon Josefsson To: Jeffrey Walton References: <20150611170317.13732.72719.idtracker@ietfa.amsl.com> <201506122355.45772.davemgarrett@gmail.com> <87r3petrfq.fsf@latte.josefsson.org> <20150614134639.GN2050@mournblade.imrryr.org> <87bnggk7ub.fsf@latte.josefsson.org> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:150616:tls@ietf.org::FpRqYhFfWV2pAbTT:2Cz5 X-Hashcash: 1:22:150616:noloader@gmail.com::LqV0OrEfnSBf1yFh:At8n Date: Tue, 16 Jun 2015 10:08:30 +0200 In-Reply-To: (Jeffrey Walton's message of "Mon, 15 Jun 2015 19:46:01 -0400") Message-ID: <87pp4why81.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] I-D Action: draft-ietf-tls-chacha20-poly1305-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Jun 2015 08:08:40 -0000 --=-=-= Content-Type: text/plain Jeffrey Walton writes: >>>> What is the use-case? >>> >>> 0. Authentication other than via certificate-based PKI. Establish >>> anon TLS, and channel-bind the TLS-unique via GSSAPI or some >>> other authentication method. >>> >>> 1. Unauthenticated opportunistic TLS. >>> >>> * Server performs no unnecessary signature operations, >>> since the client can't verify the signature anyway. >>> (More precisely the client can't verify the authenticity >>> of the server keys, so it can only determine that somebody >>> signed the handshake, but no idea whether it is the intended >>> server). >> >> Both those use-cases can be achieved by choosing, say, ECDHE_ECDSA and >> not verify the signature, right? >> > That's a violation of the engineering requirements :) If you don't > need server authenticity, then you don't ask for it. If you ask for > it, then you have to validate it. It may appear that way -- but implementing support for ANON ciphers is more work than NOT implementing support for certificate validation. Supporting ANON in standards, implementation, testing/QA etc carry a cost. We should strive towards offsetting costs with use-cases that can motivate the costs. > I know I'm splitting hairs, but I would reject that kind of check-in. > I fear a proliferation of > https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html. > It also creates a few extra rules, and we have to teach them to > developers, QA and auditors. Negotiating these ciphers and not verifying the signature is already widely deployed (e.g., SMTP STARTTLS), so there is nothing new that needs to be done. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJVf9l/AAoJEIYLf7sy+BGdpE4H/j3xRbyxipGhhuOotmz71mnX IRKuH36t1WY2xw8U0ZRhTTHfKBgx4jqV6UMfziTb2SCuBrrdPLDYCIpxpqSw3fYu HHZeUPWfMoKNec/aF2N4jH2uQmGZZ7z/jZA71nUXmyEhsFX7afFVFwB1LqPAvdPn CwtaaEkCoOZ9J8PWrAyIiCSBaDITUFUdx1LJ4CeHS+CIb+rV9yKZ+BiOEtjT4YiV wPGZa8FxEcyqPLySmL/k4XJFJgUVoXQWvIXLf1Z2buN6VH6OHftDQ673pb3bwv9z ypzdwmBwFRWho7/T7SKPy5b0wtnnpVRmeoaCUM4xmpb9EWSdFQnWJ1aLg+LMwgg= =3+T/ -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jun 16 01:46: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 525921A8874 for ; Tue, 16 Jun 2015 01:46:28 -0700 (PDT) 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 8HFrzCbvIFwc for ; Tue, 16 Jun 2015 01:46:26 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB3681A884C for ; Tue, 16 Jun 2015 01:46:25 -0700 (PDT) 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 (Postfix) with ESMTPS id 4124D19F215; Tue, 16 Jun 2015 08:46:25 +0000 (UTC) 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 t5G8kMdF013546 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 16 Jun 2015 04:46:24 -0400 Message-ID: <1434444382.3824.11.camel@redhat.com> From: Nikos Mavrogiannopoulos To: noloader@gmail.com Date: Tue, 16 Jun 2015 10:46:22 +0200 In-Reply-To: References: <20150611170317.13732.72719.idtracker@ietfa.amsl.com> <201506122355.45772.davemgarrett@gmail.com> <87r3petrfq.fsf@latte.josefsson.org> <20150614134639.GN2050@mournblade.imrryr.org> <87bnggk7ub.fsf@latte.josefsson.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.22 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] I-D Action: draft-ietf-tls-chacha20-poly1305-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Jun 2015 08:46:28 -0000 On Mon, 2015-06-15 at 19:46 -0400, Jeffrey Walton wrote: > > > > > > What is the use-case? > > > > > > 0. Authentication other than via certificate-based PKI. > > > Establish > > > anon TLS, and channel-bind the TLS-unique via GSSAPI or some > > > other authentication method. > > > > > > 1. Unauthenticated opportunistic TLS. > > > > > > * Server performs no unnecessary signature operations, > > > since the client can't verify the signature anyway. > > > (More precisely the client can't verify the authenticity > > > of the server keys, so it can only determine that somebody > > > signed the handshake, but no idea whether it is the > > > intended > > > server). > > > > Both those use-cases can be achieved by choosing, say, ECDHE_ECDSA > > and > > not verify the signature, right? > > > That's a violation of the engineering requirements :) If you don't > need server authenticity, then you don't ask for it. If you ask for > it, then you have to validate it. Not really. Validation of certificates is outside the scope of TLS. You may validate using PKIX, trust on first use, or not at all and still do TLS. Said that, I cannot think of many cases where you don't need server authenticity. Even the opportunistic encryption mentioned can use server authenticity, to verify using trust on first use for example. However, if you rely on the anonymous ciphersuites for opportunistic encryption you ensure that trust on first use _cannot_ be done. For the use case (0) mentioned, for authentication with alternative PKI methods, rfc7250 is more appropriate, rather than an anonymous ciphersuite. For channel-binding using anonymous ciphersuites, is that defined somewhere? If that practice is already used and defined by IETF, adding an anonymous ciphersuite may make sense. regards, Nikos From nobody Tue Jun 16 02: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 389311AC42E for ; Tue, 16 Jun 2015 02:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 02xbEhsFtudx for ; Tue, 16 Jun 2015 02:43:38 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 384901A92F8 for ; Tue, 16 Jun 2015 02:43:38 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t5G9hXd9012129 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 16 Jun 2015 11:43:34 +0200 From: Simon Josefsson To: Nikos Mavrogiannopoulos References: <20150611170317.13732.72719.idtracker@ietfa.amsl.com> <201506122355.45772.davemgarrett@gmail.com> <87r3petrfq.fsf@latte.josefsson.org> <20150614134639.GN2050@mournblade.imrryr.org> <87bnggk7ub.fsf@latte.josefsson.org> <1434444382.3824.11.camel@redhat.com> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:150616:noloader@gmail.com::M9HmFcPwdULtKCDf:1xsh X-Hashcash: 1:22:150616:tls@ietf.org::dBrdQTf7aqUyusga:F3uV X-Hashcash: 1:22:150616:nmav@redhat.com::BC2OEXeQJfGCDmz9:012Zl Date: Tue, 16 Jun 2015 11:43:32 +0200 In-Reply-To: <1434444382.3824.11.camel@redhat.com> (Nikos Mavrogiannopoulos's message of "Tue, 16 Jun 2015 10:46:22 +0200") Message-ID: <878ubkhttn.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] I-D Action: draft-ietf-tls-chacha20-poly1305-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Jun 2015 09:43:39 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Nikos Mavrogiannopoulos writes: > For channel-binding using anonymous ciphersuites, is that defined=20 > somewhere? If that practice is already used and defined by IETF,=20 > adding an anonymous ciphersuite may make sense. It is discussed in RFC 5802: If the external security layer used to protect the SCRAM exchange uses an anonymous key exchange, then the SCRAM channel binding mechanism can be used to detect a man-in-the-middle attack on the security layer and cause the authentication to fail as a result. However, the man-in-the-middle attacker will have gained sufficient information to mount an offline dictionary or brute-force attack. In my view, using anonymous key exchanges with channel binding is a bad idea. It opens up for these attacks and there is no ways of detecting them. If ANON ciphersuites aren't used, there is at least a way to detect MITM, and even if verification didn't happen directly, you can log fingerprints for later auditing to prove what happened. I believe more solid use-cases are needed to motivate ANON ciphersuites. The use-cases presented so far does not strike me as fully fleshed out, and there appears to be better ways of adressing them. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJVf+/EAAoJEIYLf7sy+BGdv9cIAKFbZY940076dCT5kuf9MbXK qAmE+0+eE247HN0qixgKGI4gSi+9lAB/Aw3sr93ZSZkFSRzfmZt0pcneLXATvCbr lkk1s4fk8uCpiIPcmXiytyN0LqldOtxea0MqLYJ6D/9tdlKo1WibzNE2DBI/7fh2 QAIC/6paK17GlJ5iK+8V043l9e2YG5gwepO+8t3bBgfZFxsdSbb+Ddwc5GoAwOzy BHk5GHHCON9tf7eWK8Hp7vm9OZsAQXLf0YYi40sUib/ut2BOxeOmhVwDeGuslBbN imUmp9vw1WMhWpT6SC8RAUpbFwQ8oDeum30In37pvKy+px1i9IjFwFHLC47JdM0= =q2O/ -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jun 16 03:02: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 83E8A1AD0B3 for ; Tue, 16 Jun 2015 03:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 aXIw_AluLBVj for ; Tue, 16 Jun 2015 03:02:43 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 653761ACE65 for ; Tue, 16 Jun 2015 03:02:43 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t5GA2Vrs014055 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 16 Jun 2015 12:02:32 +0200 From: Simon Josefsson To: tls@ietf.org References: <87zj4ah6i0.fsf@latte.josefsson.org> <87oakpjn16.fsf@latte.josefsson.org> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:150616:tls@ietf.org::mD74U0jsj1Pru0Tn:2/hU Date: Tue, 16 Jun 2015 12:02:30 +0200 In-Reply-To: <87oakpjn16.fsf@latte.josefsson.org> (Simon Josefsson's message of "Tue, 09 Jun 2015 10:36:53 +0200") Message-ID: <874mm8hsy1.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Subject: Re: [TLS] Updated EdDSA in TLS 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, 16 Jun 2015 10:02:44 -0000 --=-=-= Content-Type: text/plain Hi. The discussion about Curve25519 and ECPointFormat made me realize that the same appears to apply to Ed25519. So I have removed the ECPointFormat registration and let the document say "use uncompressed". Here is an updated document: https://tools.ietf.org/html/draft-josefsson-tls-eddsa2-02 Anyone disagreeing with this, and would like to see an EdDSA ECPointFormat for some reason? Why? Come to think of it, maybe the SignatureAlgorithm registration for eddsa is unnecessary too, and we can overload the ecdsa value. The NamedCurve value "ed25519" should signal support for EdDSA anyway. More review whether the draft would actually work for different TLS versions (1.3 included) is appreciated. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJVf/Q2AAoJEIYLf7sy+BGde78H/2a/uVFiwQDuRog24n8He0yo A6UKTnoewUJbYreiWwLjpdOAVnO3UXS3Dga2z36JN0RcLXyN0alOxp2d6D/JjKFL xZWhVcVFrxa13P+MoHlmPHk1qVkMThGTFNKsmFCKvtt2WPzu3UCMVB7NHhRXM5b0 eJt5DxceI3FrBIUquMDeOyBy3Yi3IvxtUg9naE8DBIMbsJLlP/0aN2MVSMwozHjs E6sgLunJlFsGqJMwgxUuFS8cwZ+hBUAmyfmApalbTK5xoNjtY84w9oICKd0p1QsC Vg0reACjHb2fsknMfIc93CpC0GE5HkU955spPbgbrcIaMsnEoCamFWhRkwz4rXU= =11d8 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jun 16 03:07: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 E2EA31ACE59 for ; Tue, 16 Jun 2015 03:07:17 -0700 (PDT) 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 Yqx0ZIs-NMck for ; Tue, 16 Jun 2015 03:07:16 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F69C1ACE4E for ; Tue, 16 Jun 2015 03:07:16 -0700 (PDT) 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 (Postfix) with ESMTPS id D73DB19CF9D; Tue, 16 Jun 2015 10:07:15 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-112-26.ams2.redhat.com [10.36.112.26]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t5GA7BHp025116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jun 2015 06:07:15 -0400 From: Hubert Kario To: tls@ietf.org Date: Tue, 16 Jun 2015 12:07:03 +0200 Message-ID: <5376091.DEdtQA7Asb@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.7 (Linux/4.0.4-202.fc21.x86_64; KDE/4.14.7; x86_64; ; ) In-Reply-To: <87pp4why81.fsf@latte.josefsson.org> References: <20150611170317.13732.72719.idtracker@ietfa.amsl.com> <87pp4why81.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1928648.8zJh08JdMv"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: Cc: Simon Josefsson Subject: Re: [TLS] I-D Action: draft-ietf-tls-chacha20-poly1305-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Jun 2015 10:07:18 -0000 --nextPart1928648.8zJh08JdMv Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Tuesday 16 June 2015 10:08:30 Simon Josefsson wrote: > Jeffrey Walton writes: > >>>> What is the use-case? > >>>=20 > >>> 0. Authentication other than via certificate-based PKI. Establ= ish > >>>=20 > >>> anon TLS, and channel-bind the TLS-unique via GSSAPI or some= > >>> other authentication method. > >>>=20 > >>> 1. Unauthenticated opportunistic TLS. > >>>=20 > >>> * Server performs no unnecessary signature operations, > >>> =20 > >>> since the client can't verify the signature anyway. > >>> (More precisely the client can't verify the authenticity > >>> of the server keys, so it can only determine that somebody > >>> signed the handshake, but no idea whether it is the intende= d > >>> server). > >>=20 > >> Both those use-cases can be achieved by choosing, say, ECDHE_ECDSA= and > >> not verify the signature, right? > >=20 > > That's a violation of the engineering requirements :) If you don't > > need server authenticity, then you don't ask for it. If you ask for= > > it, then you have to validate it. >=20 > It may appear that way -- but implementing support for ANON ciphers i= s > more work than NOT implementing support for certificate validation. > Supporting ANON in standards, implementation, testing/QA etc carry a > cost. We should strive towards offsetting costs with use-cases that = can > motivate the costs. From=20QA perspective it's easier to test a specific ciphersuite than to = test=20 some obscure option that disables signature verification that every=20 application names differently. A(EC)DH ciphersutes are well known and used configuration option, "disa= ble=20 signature verification on ServerKeyExchange" is not. > > I know I'm splitting hairs, but I would reject that kind of check-i= n. > > I fear a proliferation of > > https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.ht= ml. > > It also creates a few extra rules, and we have to teach them to > > developers, QA and auditors. >=20 > Negotiating these ciphers and not verifying the signature is already > widely deployed (e.g., SMTP STARTTLS), so there is nothing new that > needs to be done. this is true only in SMTP because of its legacy, it's not something we = should=20 encourage =2D-=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 --nextPart1928648.8zJh08JdMv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJVf/VNAAoJEJKo0bgB0vX1GAIP/2HDpYsXoHHfSz4ggbMD2Y8m fVLeLahmpFlBeEcOLxxsINLxUZF452VU/zSrlSeqOOImaXPj34Vnyrq9OswLbwqU HztIp1USYAxOatwvkLwYGethcwGuP5uISvJGHIqj0QxNOLqNS9LoUNhcDh2B9cb8 gZRae/yEn+vOjfxTUpXks5yobCNZxjzn6Wc9pBImh87q65c0wJD68bFVHxsb42CI 58xE4jg8iuXEOe77iutjAohVPMRLGvNWNy9dqtScbPHq3S8vSuwHFl1RGqnGDzOj XOJBVitSVt0sJ3R6mn/EsM6Cfv6qzN7Yqhb7UmHnRZCzySWBTcqWMlTgpMawzMwL urmpW3teGVrU8eu3dvIGddCE9YVgO2UMC09B3NofDgHJhCE0gKtg5pegCi+I+nUS j+YFzTqFG3+Op9zkkrc4spHpmnb2ZnwCGQ151+cxyzSJ5Iyu4zcHLcqjJn8po+np e+cmDzpii7dFZD4bxiMOm4TtAmHjI+LDxlBfken9TiOJYszwwE3QXRzQGPNvGNEw XbZEI1bgAc3Q/zITYymrkieMM0E0UhqJ6u6vohNaGHerbonf/GPIItnhgKVogeQu ucjFjlh8/wvYl+GyVDu+B2gjyxmi7+SlevJQJQuC21v8IxE/AGZ48gZ1+bCH3upY 9/cd0qwE28+M9W7qQ6r2 =kB86 -----END PGP SIGNATURE----- --nextPart1928648.8zJh08JdMv-- From nobody Tue Jun 16 09:24: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 EE6CF1B2EF8 for ; Tue, 16 Jun 2015 09:24:18 -0700 (PDT) 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 U_8fohpTO6yL for ; Tue, 16 Jun 2015 09:24:17 -0700 (PDT) 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 E482A1B2EFC for ; Tue, 16 Jun 2015 09:24:16 -0700 (PDT) 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 C5AC6445BB; Tue, 16 Jun 2015 18:24:14 +0200 (CEST) X-purgate-ID: 152705::1434471854-00005316-69063CCC/0/0 X-purgate-size: 1541 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id B76E54082E; Tue, 16 Jun 2015 18:24:14 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id AA50A1A141; Tue, 16 Jun 2015 18:24:14 +0200 (CEST) In-Reply-To: <5376091.DEdtQA7Asb@pintsize.usersys.redhat.com> To: Hubert Kario Date: Tue, 16 Jun 2015 18:24:14 +0200 (CEST) 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: <20150616162414.AA50A1A141@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: Simon Josefsson , tls@ietf.org Subject: Re: [TLS] I-D Action: draft-ietf-tls-chacha20-poly1305-00.txt 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, 16 Jun 2015 16:24:19 -0000 Hubert Kario wrote: >>> >>> That's a violation of the engineering requirements :) If you don't >>> need server authenticity, then you don't ask for it. If you ask for >>> it, then you have to validate it. >> >> It may appear that way -- but implementing support for ANON ciphers is >> more work than NOT implementing support for certificate validation. >> Supporting ANON in standards, implementation, testing/QA etc carry a >> cost. We should strive towards offsetting costs with use-cases that can >> motivate the costs. > > From QA perspective it's easier to test a specific ciphersuite than to test > some obscure option that disables signature verification that every > application names differently. > > A(EC)DH ciphersutes are well known and used configuration option, "disable > signature verification on ServerKeyExchange" is not. There may be SSL/TLS implementations that do not implement any of the DH_anon/ECDH_anon cipher suites. Our implementation does not implement them. So for use with SMTP+TLS (which we do support) DH_anon may simply not be an option. But we also do not allow application programmers to skip certificate path validation (that is only possible at the low-level APIs and used by the SMTP+TLS/STARTTLS code. The problem that I have with DH_anon/ECDH_anon is that it is equal to TLS with Alzheimer. Not being able to authenticate the server is a problem, but also being unable to re-recognize a previous communication peer is significantly worse. -Martin From nobody Tue Jun 16 12:59: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 23F5A1B2B48 for ; Tue, 16 Jun 2015 12:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XYNISAifGWRa for ; Tue, 16 Jun 2015 12:59:49 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::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 5DE931B2BEF for ; Tue, 16 Jun 2015 12:59:47 -0700 (PDT) Received: by qkfe185 with SMTP id e185so14902017qkf.3 for ; Tue, 16 Jun 2015 12:59:46 -0700 (PDT) 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=k2Z15lrkI5LyRQhFJTDDpX6JewcDd4pzDLkMDdemMas=; b=BcHI8pOdiRTeMp03nFfZ04jVuWqOA87AYJO/GmzLw9ZAXDjTdPfVDo6MWC3wQ5JuTU voeM/v4FyqD2vUsuwxsPDigZ+mbSEstTLRUefX5EKTv3XTc1dp3Vz7bYVIU/FNnt0ter 4B9vj3J1+PpCsuGu2BnjvvmmPD7xEAaqhyzDOnlgsV2Qy8D076NpX+CP81Ju7DBe5kpf 69eAiZvhfTlMKXYGs6W1o6ezJ0w/w3NSgD5S0CjFWgmVK4dq8BUAE9vFFxBaLMyzjiGR lAaiwzgCNm4IgKplhekwcc01cg588lx5gIEYPhiJq6dk/QhNWVgg+RL6OpMO83lzkSZC 4zvg== X-Received: by 10.140.233.214 with SMTP id e205mr3310202qhc.68.1434484786642; Tue, 16 Jun 2015 12:59:46 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id 202sm970859qhy.1.2015.06.16.12.59.45 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 16 Jun 2015 12:59:45 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Tue, 16 Jun 2015 15:59:44 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201506161559.44658.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Jun 2015 19:59:51 -0000 There's enough arguments in this thread and the ChaChaPoly thread that anon suites are not the best way to do things. I've cut it from the draft proposal and relegated it to its own section. This would have (EC)DH_anon suites deprecated for TLS 1.3 in favor of raw keys (RFC7250; trust on first use) or (EC)DHE PSK with the identity "anonymous" universally reserved to have a NULL PSK key. (PSK spec wants printable characters for identities) Getting rid of the separate anon suites simplifies things significantly and should be better for its use-cases. New ECDH_anon suites aren't needed anymore, as ECDHE_PSK will suffice. (though, I think ChaChaPoly should probably specify an ECDH_anon suite for TLS 1.2 in the meantime) https://github.com/davegarrett/tls13-spec/blob/alacarte/draft-ietf-tls-tls13.md#cipher-suites-in-tls-13 https://github.com/davegarrett/tls13-spec/blob/alacarte/draft-ietf-tls-tls13.md#anonymous-key-exchange There's a little hand-waving in the new anon bit as the PSK side of TLS 1.3 is currently a WIP as-is. (the new method of offering a PSK id is not yet specified, but in WIP) This draft keeps certificate authenticated suites and PSK suites separate. Attempting to merge everything into one prefix does not appear to be worth the trouble. Dave From nobody Tue Jun 16 13:06: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 0E2081B2E7A for ; Tue, 16 Jun 2015 13:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.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, 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 oDlVQwTeUIMj for ; Tue, 16 Jun 2015 13:06:51 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id A9AF31A1B85 for ; Tue, 16 Jun 2015 13:06:51 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 2BB61180208; Tue, 16 Jun 2015 13:04:07 -0700 (PDT) To: ekr@rtfm.com, stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com, turners@ieca.com, joe@salowey.net X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20150616200407.2BB61180208@rfc-editor.org> Date: Tue, 16 Jun 2015 13:04:07 -0700 (PDT) Archived-At: Cc: rick@openfortress.nl, tls@ietf.org, rfc-editor@rfc-editor.org Subject: [TLS] [Technical Errata Reported] RFC5705 (4395) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Jun 2015 20:06:53 -0000 The following errata report has been submitted for RFC5705, "Keying Material Exporters for Transport Layer Security (TLS)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5705&eid=4395 -------------------------------------- Type: Technical Reported by: Rick van Rein Section: 4 Original Text ------------- If no context is provided, it then computes: PRF(SecurityParameters.master_secret, label, SecurityParameters.client_random + SecurityParameters.server_random )[length] If context is provided, it computes: PRF(SecurityParameters.master_secret, label, SecurityParameters.client_random + SecurityParameters.server_random + context_value_length + context_value )[length] Corrected Text -------------- If no context is provided, it then computes: PRF(SecurityParameters.master_secret, label, SecurityParameters.client_random + SecurityParameters.server_random )[0..length-1] If context is provided, it computes: PRF(SecurityParameters.master_secret, label, SecurityParameters.client_random + SecurityParameters.server_random + context_value_length + context_value )[0..length-1] Notes ----- The current notation is not in line with that of RFC 5246, where the [0..N-1] notation is used on a PRF outcome in Sections 7.4.9 and 8.1 and similar [A..B] notation is also used elsewhere. This makes me believe that the current text is technically wrong, and not in line with the intentions stated informally below it, The output is a pseudorandom bit string of length bytes generated from the master_secret. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5705 (draft-ietf-tls-extractor-07) -------------------------------------- Title : Keying Material Exporters for Transport Layer Security (TLS) Publication Date : March 2010 Author(s) : E. Rescorla Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Tue Jun 16 16:31: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 41C681B2A28 for ; Tue, 16 Jun 2015 16:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.034 X-Spam-Level: * X-Spam-Status: No, score=1.034 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, 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 eMk-dR4LNJtu for ; Tue, 16 Jun 2015 16:31:14 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5D63B1B2A16 for ; Tue, 16 Jun 2015 16:31:14 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id 9F9EE163B; Tue, 16 Jun 2015 16:31:13 -0700 (PDT) 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=JXSrLtu4Pe3nFv OZbpnNd+afTeM=; b=Gv3rvd4mcSbHLKl8MqHfxQkMgM4hyo9GlqkXOAIAfXMvIm 6QRaMZFfg0YYmUnkLc+wERdLXXqCAsR5rcPhC1xmfQIfSy0qzS8jCkdSWXzcYoCD j2/3t78ktzc2Pp3B3nnbr/NFS2ZyWMG0RT9txQ9r9w5QLhtQhu8Mx83yCbW+8= 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 4D4201636; Tue, 16 Jun 2015 16:31:13 -0700 (PDT) Date: Tue, 16 Jun 2015 18:31:12 -0500 From: Nico Williams To: Dave Garrett Message-ID: <20150616233111.GD6117@localhost> References: <201506111558.21577.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201506111558.21577.davemgarrett@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "" Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Jun 2015 23:31:15 -0000 On Thu, Jun 11, 2015 at 03:58:21PM -0400, Dave Garrett wrote: > Here is a branch with a rough draft of an a la carte handshake > algorithm negotiation scheme for TLS 1.3, based on discussions on this > list. Commenting on the latest update of that: > https://github.com/davegarrett/tls13-spec/compare/updateciphersuites...davegarrett:alacarte - Yes! This. - IMO the hash should be associated with the "handshake portion" of a cipher suite, not the bulk side. Ideally it'd be: Hash_Algs x KE_groups x Server_auth_algs x Bulk_cipher_and_mode That's four registries instead of one or two. I'll settle for your proposal though! - It'd be nice if instead of always thinking of authentication as "signatures" we just thought of it as authentication. Consider authentication by using a DH cert... If that's selected then the handshake won't be the usual one that we're all used to, but it would be workable. - Anon ciphersuites... I'd much rather that the WG did NOT deprecate these! For opportunistic security and channel binding applications anon ciphersuites are just fine, and the alternatives are wasteful (e.g., doing signatures that aren't needed). Recommending against the use of anon ciphersuites is and should be a job for UTA. Nico -- From nobody Tue Jun 16 17:31: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 779C91B307C for ; Tue, 16 Jun 2015 17:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gc60ivupwU85 for ; Tue, 16 Jun 2015 17:31:51 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (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 BED601B376B for ; Tue, 16 Jun 2015 17:29:21 -0700 (PDT) Received: by qkhu186 with SMTP id u186so18148758qkh.0 for ; Tue, 16 Jun 2015 17:29:20 -0700 (PDT) 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=76qL534WBE3NfctA+KGi3D5yW1qZMXUupIKT9m0Gqag=; b=o8ky0uzS6anznUb1zbeLgdB/bMRka/vRCHkV8dgszrWY+g7wMtj3DI40+38CiEx3aI Q1z0XE6E4J3oVGS77YgdBnXw9iuto3aFkxVytrMYiwuC0WqTH4RQfIqK7AFO4r7IKwoP /v3t0S+kTW3jPE7zQYT72rZLunCrKypodwEu3vfC412aHc+ljnBZ4EbVug2HD7FeOxn+ 9u2iq/sBYucs+EHtEPGeDngSS8gbCyUzWBjgM/PsLxqnv54kxDbiECJjSTi1HncmIGet 21xBaPyOV6PdO6fFr+rcMtgCxuxiYUp8bMRu6FI19iNcP3fiG3pKMr5pSM+ryl6hqxup xD+g== X-Received: by 10.55.51.129 with SMTP id z123mr7286048qkz.92.1434500960731; Tue, 16 Jun 2015 17:29:20 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id e49sm1338748qga.49.2015.06.16.17.29.19 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 16 Jun 2015 17:29:20 -0700 (PDT) From: Dave Garrett To: Nico Williams Date: Tue, 16 Jun 2015 20:29:17 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201506111558.21577.davemgarrett@gmail.com> <20150616233111.GD6117@localhost> In-Reply-To: <20150616233111.GD6117@localhost> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201506162029.18277.davemgarrett@gmail.com> Archived-At: Cc: "" Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Jun 2015 00:31:53 -0000 On Tuesday, June 16, 2015 07:31:12 pm Nico Williams wrote: > > https://github.com/davegarrett/tls13-spec/compare/updateciphersuites...davegarrett:alacarte > > - Yes! This. > > - IMO the hash should be associated with the "handshake portion" of a > cipher suite, not the bulk side. The bulk cipher and hash are often directly correlated. (e.g. SHA384 paired with AES-256) The signature algorithms extension lists hashes for each certificate type. > - Anon ciphersuites... > > I'd much rather that the WG did NOT deprecate these! > > For opportunistic security and channel binding applications anon > ciphersuites are just fine The alternatives in the current draft proposal are raw keys with trust after anon connect and fully anon via PSK. The reason for wanting to deprecate these suites is that this feature is under-maintained in the spec. There are currently no ECDHE AEAD anon suites. We'll want to publish an RFC to define new codepoints for ECDHE PSK suites to match existing DHE versions, but having to double that for anon is a bit of a mess (and some are against it). Folding anon into PSK as a special case simplifies things and makes cipher support not as much a side issue / afterthought. Logically, anon is a globally pre-shared null key, so it makes sense. > the alternatives are wasteful (e.g., doing signatures that aren't needed). The currently proposed anon PSK has no overhead. Anon PSK is just id="anonymous" and a NULL key. (EC)DHE is used as normal. The only difference in computation is that the pre-master secret with anon PSK is DHresult + 0x00010 (where `+` is concat). Tacking 5 bytes onto the end of the DH result, once a handshake, is essentially zero overhead. Dave From nobody Tue Jun 16 20:59: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 48B551B3AE6 for ; Tue, 16 Jun 2015 20:59:55 -0700 (PDT) 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 RnokBZcLsy7D for ; Tue, 16 Jun 2015 20:59:54 -0700 (PDT) Received: from homiemail-a85.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 257B01B3924 for ; Tue, 16 Jun 2015 20:59:54 -0700 (PDT) Received: from homiemail-a85.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTP id EBEFEBBA08A; Tue, 16 Jun 2015 20:59:53 -0700 (PDT) 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=p/2THwyGAdpirM +/E2EHhjc5ci8=; b=PpPX8wMXiSHydaibe/cwPUa6/1qnRt2lRKLcq3m4DHIZrB RmdKh/O/mbGM8z1xLeBIXS+2xU7S8KWQYKQNgYaPZzMcpm8YHp7O/bY3qsVRu4qi 3lBuTfLqLhR4CSQmc5r2G3RGJ98Hhi6h8aCWGt+8qdrSWqhyF22icX1LfWmnQ= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTPA id 86400BBA088; Tue, 16 Jun 2015 20:59:53 -0700 (PDT) Date: Tue, 16 Jun 2015 22:59:52 -0500 From: Nico Williams To: Dave Garrett Message-ID: <20150617035951.GF6117@localhost> References: <201506111558.21577.davemgarrett@gmail.com> <20150616233111.GD6117@localhost> <201506162029.18277.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201506162029.18277.davemgarrett@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "" Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Jun 2015 03:59:55 -0000 On Tue, Jun 16, 2015 at 08:29:17PM -0400, Dave Garrett wrote: > On Tuesday, June 16, 2015 07:31:12 pm Nico Williams wrote: > > - IMO the hash should be associated with the "handshake portion" of a > > cipher suite, not the bulk side. > > The bulk cipher and hash are often directly correlated. (e.g. SHA384 > paired with AES-256) The signature algorithms extension lists hashes > for each certificate type. Ah, OK. > > - Anon ciphersuites... > > > > I'd much rather that the WG did NOT deprecate these! > > > > For opportunistic security and channel binding applications anon > > ciphersuites are just fine > > The alternatives in the current draft proposal are raw keys with trust > after anon connect and fully anon via PSK. The reason for wanting to Raw (or certificated but unable to chain to any trust anchor of the relying party's) works, but it's a waste of resources. PSK with a fixed key is a pointless complexity. We already have an unauthenticated mode; there's no need to replace it with another more complicated one. > deprecate these suites is that this feature is under-maintained in the > spec. There are currently no ECDHE AEAD anon suites. [...] We've noted this and asked for them to be registered. The missing assignments does not mean that the feature is unmaintained as implemented (it's in use), as as to the spec: we're maintaining it now, and a la carte negotiation effectively fixes the missing cipher suite assignment issue. > Logically, anon is a globally pre-shared null key, so it makes sense. Logically anon (really, unauthenticated) is just... not authenticated. > The currently proposed anon PSK has no overhead. Anon PSK is just > id="anonymous" and a NULL key. (EC)DHE is used as normal. The only > difference in computation is that the pre-master secret with anon PSK > is DHresult + 0x00010 (where `+` is concat). Tacking 5 bytes onto the > end of the DH result, once a handshake, is essentially zero overhead. Why do even that? Nico -- From nobody Tue Jun 16 21:42: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 D66131B3BC6 for ; Tue, 16 Jun 2015 21:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-ob15wPoYyc for ; Tue, 16 Jun 2015 21:42:09 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 40B141B3BC8 for ; Tue, 16 Jun 2015 21:41:33 -0700 (PDT) Received: by qkeo142 with SMTP id o142so3259389qke.1 for ; Tue, 16 Jun 2015 21:41:32 -0700 (PDT) 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=CNwyfWYgqDYwtKZhhYimyFGMQLf7JWQvcvsBca8g4M4=; b=Jcx/VLVSYq3ZhWQLc1L9v9HFPmrT5AZiaooNoAzHsoLzZCL/O98o3Th5H12fr1LpNl H8Ti7I+wOegqI/sC96P0LYX+IjeMm617cEEEft2xjBpjC4AraJyT7oyh3nsArT0kJwMn hfQZmV4jwcCkuGGS8p+xP5wBrcKz/QHXKs2m6HLjxsYwpggR2k5djiOtZp7PMABuf614 +OHvmMm7xNOJgfYzysZucTSmqO6OJyEIPPyAureV6vA3L/pZyMC0iaj7sPf9njM1bbPO dc3KD+jtI8wmsbUhCVeKggf5/eLkQfETNW0zAAFVlm1ZyHWH+HTyjYsXOWB5BzIWdQ5t aMrA== X-Received: by 10.140.49.11 with SMTP id p11mr5390278qga.60.1434516092202; Tue, 16 Jun 2015 21:41:32 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id t77sm1614317qgt.42.2015.06.16.21.41.31 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 16 Jun 2015 21:41:31 -0700 (PDT) From: Dave Garrett To: Nico Williams Date: Wed, 17 Jun 2015 00:41:30 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201506111558.21577.davemgarrett@gmail.com> <201506162029.18277.davemgarrett@gmail.com> <20150617035951.GF6117@localhost> In-Reply-To: <20150617035951.GF6117@localhost> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201506170041.30538.davemgarrett@gmail.com> Archived-At: Cc: "" Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Jun 2015 04:42:11 -0000 On Tuesday, June 16, 2015 11:59:52 pm Nico Williams wrote: > PSK with a fixed key is a pointless complexity. We already have an > unauthenticated mode; there's no need to replace it with another more > complicated one. > > > deprecate these suites is that this feature is under-maintained in the > > spec. There are currently no ECDHE AEAD anon suites. [...] > > We've noted this and asked for them to be registered. The missing > assignments does not mean that the feature is unmaintained as > implemented (it's in use), as as to the spec: we're maintaining it now, > and a la carte negotiation effectively fixes the missing cipher suite > assignment issue. I'm trying to reduce the number of valid prefixes. The anon options are essentially: 1) Merge (EC)DH_anon into ECDHE_PSK & drop all (EC)DH_anon 2) Define all ECDHE_anon & drop all DH_anon I moved towards #1 in the last revision of the draft because some seemed interested in dropping the feature to reduce overall spec complexity. There's notable disagreement on this list over whether or not the anon suites are worthwhile, so I wrote up what would be needed for it. (e.g. wasn't sure if ChaChaPoly would get an anon assignment) > Why do even that? The idea was to get rid of an entire class of suites as a simplification. There seemed to be a desire on list for dropping them. (was brought up by a few) I think I'll set the anon deprecation part aside and go back to #2, if defining the new suites isn't an issue. I still think they should be actively discouraged in favor of trust on first use. I'll change the WIP in a bit. Dave From nobody Tue Jun 16 22: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 8BB2E1B3C62 for ; Tue, 16 Jun 2015 22:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdbbsFCWGnFB for ; Tue, 16 Jun 2015 22:31:19 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::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 938581B3C60 for ; Tue, 16 Jun 2015 22:31:19 -0700 (PDT) Received: by qkeo142 with SMTP id o142so3701603qke.1 for ; Tue, 16 Jun 2015 22:31:19 -0700 (PDT) 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=ja0SLE9bm1FTK88ptorbcgVrbR9WSnXV4TZZo/7381w=; b=vrLZaJ6M7Urwt8lht2/pia0CW0HMYJCDU95GX768YwV0UchfPAp+lLeYrb/3HYJhjn OGzyDnajLY+JFAWaysofb6s2oQRfy1lC3oHFFyW3DeGbJ+8h4tQWMqGbehb2a9l56YOM Qx5eXSblaOX89vE2vOJxfP9vuDkGq5/gF+jvxBDJVdiAzI3sq+Kbvj/L5vta9EWaSykY YWhZMsN82EJ7mYEZVX6GRH4l6O2pLM1eViMk1uLLBmyCgXRQQG+xk8fjLSfOrosI1/EU MCF+yHNzzmAbSSn8jkzjUlcYObJN5eSjgM3X51MOI+XvPuIbxUT5Vgfg/5GZnUVNaOrW G0Ng== X-Received: by 10.55.41.211 with SMTP id p80mr9207545qkp.32.1434519078936; Tue, 16 Jun 2015 22:31:18 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id 67sm1644151qhw.43.2015.06.16.22.31.18 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 16 Jun 2015 22:31:18 -0700 (PDT) From: Dave Garrett To: Nico Williams Date: Wed, 17 Jun 2015 01:31:16 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201506111558.21577.davemgarrett@gmail.com> <20150616233111.GD6117@localhost> In-Reply-To: <20150616233111.GD6117@localhost> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201506170131.17179.davemgarrett@gmail.com> Archived-At: Cc: "" Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Jun 2015 05:31:21 -0000 On Tuesday, June 16, 2015 07:31:12 pm Nico Williams wrote: > On Thu, Jun 11, 2015 at 03:58:21PM -0400, Dave Garrett wrote: > > Here is a branch with a rough draft of an a la carte handshake > > algorithm negotiation scheme for TLS 1.3, based on discussions on this > > list. > > Commenting on the latest update of that: > > > https://github.com/davegarrett/tls13-spec/compare/updateciphersuites...davegarrett:alacarte > > - Yes! This. [snip] > - Anon ciphersuites... > > I'd much rather that the WG did NOT deprecate these! Ok, I revised the drafts and forked the anon deprecation changeset. Main draft proposal: https://github.com/davegarrett/tls13-spec/blob/alacarte/draft-ietf-tls-tls13.md#cipher-suites-in-tls-13 Version with deprecated anon suites: https://github.com/davegarrett/tls13-spec/blob/alacarte-noanonsuites/draft-ietf-tls-tls13.md#anonymous-key-exchange Note that both totally deprecate all DH(E) suites, as that's one of the goals here. (due to weak DH params, old Java choking, & etc.) Thus, all suites must be ECDHE prefixed for TLS 1.3 support under these proposals (with the exception of plain PSK). All ECDHE suites would be capable of negotiating either ECDHE or DHE using string groups via the extension. PSK & anon will need a litany of new ECDHE suites to be defined. There is currently no ECDHE AEAD anon suite, thus none supporting TLS 1.3 (among the reasons I pursued the idea of merging it into PSK). I'm fine with relegating the anon deprecation idea to the bin if we agree to define all the new suites we need to maintain support. Getting ECDHE_anon into the ChaChaPoly draft would be a start. Dave From nobody Tue Jun 16 22:35: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 7A12F1B3C6B for ; Tue, 16 Jun 2015 22:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUDdOBz_OIgG for ; Tue, 16 Jun 2015 22:35:55 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::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 0AD491B3C6A for ; Tue, 16 Jun 2015 22:35:55 -0700 (PDT) Received: by qkhu186 with SMTP id u186so20933298qkh.0 for ; Tue, 16 Jun 2015 22:35:54 -0700 (PDT) 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=a+nS2H83Y41cy/ML0F5WBBbuu+kni3zk4IwSx18ypZE=; b=db5iMAVgij5BG9CraXBtcpCb8N8SVndHoALVVccWxDdwNUx72uUtCtszofg9q0iNkU ffl+1mtxNctLduolQKRO0xcC8S+v49oGd9N1xj7Emct+VPrdPnkIc7YqyLQ6KhEnCEMc z8LlhF65R49fGQKHgOUen6uB8oCFXdNTma82Z+I7W8AHRlOEvYiLf6olkwqSgx8dcrhg swZhHheXZFdej9A9eBDAad13TzhWLE6qeYKy7p4GLgk2IRz5CXKUxx/EcY9eDWolMOIQ jMTWuIMud8FCJK0fAGZAmoOki93YOaAuebyshlW07z/Lzl8DeG8/hx11gVInzbAjxrZD D11g== X-Received: by 10.140.86.239 with SMTP id p102mr5654573qgd.49.1434519354220; Tue, 16 Jun 2015 22:35:54 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id j44sm1665674qgd.28.2015.06.16.22.35.53 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 16 Jun 2015 22:35:53 -0700 (PDT) From: Dave Garrett To: Nico Williams Date: Wed, 17 Jun 2015 01:35:52 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201506111558.21577.davemgarrett@gmail.com> <20150616233111.GD6117@localhost> <201506170131.17179.davemgarrett@gmail.com> In-Reply-To: <201506170131.17179.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201506170135.52617.davemgarrett@gmail.com> Archived-At: Cc: "" Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Jun 2015 05:35:56 -0000 On Wednesday, June 17, 2015 01:31:16 am Dave Garrett wrote: > All ECDHE suites would be capable of negotiating either ECDHE or DHE using string groups via the extension. Ugh. Bad enough typo to warrant a quick correction: "string groups" -> "strong groups" https://tlswg.github.io/tls13-spec/#negotiated-groups Dave From nobody Wed Jun 17 00:34: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 0E51F1A1B7C for ; Wed, 17 Jun 2015 00:34:05 -0700 (PDT) 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 ixyaFoDAgSwv for ; Wed, 17 Jun 2015 00:34:02 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0691.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::691]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31CAF1A1B8A for ; Wed, 17 Jun 2015 00:33:49 -0700 (PDT) Received: from BN3PR0101MB1139.prod.exchangelabs.com (10.161.219.15) by BN3PR0101MB1138.prod.exchangelabs.com (10.161.219.149) with Microsoft SMTP Server (TLS) id 15.1.190.14; Wed, 17 Jun 2015 07:33:32 +0000 Received: from BN3PR0101MB1139.prod.exchangelabs.com ([10.161.219.15]) by BN3PR0101MB1139.prod.exchangelabs.com ([10.161.219.15]) with mapi id 15.01.0190.013; Wed, 17 Jun 2015 07:33:32 +0000 From: Douglas Stebila To: "tls@ietf.org" Thread-Topic: Computation of static secret in anonymous DH Thread-Index: AQHQqM/pv0TL4/Ya7k2Y027UTUErwg== Date: Wed, 17 Jun 2015 07:33:31 +0000 Message-ID: <2AA11887-2F82-48EF-BD45-4D85CFA83847@qut.edu.au> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2098) authentication-results: spf=none (sender IP is ) smtp.mailfrom=stebila@qut.edu.au; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [131.181.47.132] x-microsoft-exchange-diagnostics: 1; BN3PR0101MB1138; 3:i/yDqgeczK1l9gIB83+o96ORnRhBhNudIg7DGcnaVFErqFPd0GTLBCfnA4iWgjv3SFHGFl8E5OzFblmP//dIs7hTf+52gD9TZXQZpc+4zK6x8K90gYIL2BjZGUgvPMPdcr/ZmlYQo6CwBJEsZ25zkg==; 10:dixtRma4DW/fip+FUADxfXLZEkOd5iDSypFcbV9n/GVXRScnOmO4H62pcj/aoJ5tpAWatXfGw14dU+Hrbygs5xfP/NefCJeMtQVROdoEVEQ=; 6:4pkrzz4zl8tdM+9QXT0SlnM8QAWWkq/lwF+xhYyzM6NNHxo9QLE0UyMk4/CZ79Je x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0101MB1138; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(520003)(5005006)(3002001); SRVR:BN3PR0101MB1138; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0101MB1138; x-forefront-prvs: 0610D16BBE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(6009001)(86362001)(50226001)(57306001)(88552001)(15975445007)(102836002)(122556002)(77096005)(50986999)(2656002)(40100003)(87936001)(5002640100001)(66066001)(2351001)(229853001)(2501003)(33656002)(19580395003)(74482002)(558084003)(36756003)(106116001)(83716003)(110136002)(107886002)(5001960100002)(450100001)(62966003)(77156002)(189998001)(92566002)(2900100001)(46102003)(74826001)(82746002)(219293001)(104396002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0101MB1138; H:BN3PR0101MB1139.prod.exchangelabs.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; received-spf: None (protection.outlook.com: qut.edu.au 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: qut.edu.au X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2015 07:33:31.9484 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: dc0b52a3-68c5-44f7-881d-9383d8850b96 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0101MB1138 Archived-At: Subject: [TLS] Computation of static secret in anonymous 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, 17 Jun 2015 07:34:05 -0000 In the DH-based draft of TLS 1.3 (https://github.com/ekr/tls13-spec/blob/ie= tf92_materials/draft-ietf-tls-tls13-dh-based.txt), how is the ServerParamet= ers message containing the static secret SS constructed in the unauthentica= ted setting? Douglas= From nobody Wed Jun 17 01:25: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 B8D5A1A7005 for ; Wed, 17 Jun 2015 01:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 v7lqEq_pm1oX for ; Wed, 17 Jun 2015 01:25:33 -0700 (PDT) Received: from emh02.mail.saunalahti.fi (emh02.mail.saunalahti.fi [62.142.5.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F6E21A6FED for ; Wed, 17 Jun 2015 01:25:33 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id 1251781CA2; Wed, 17 Jun 2015 11:25:29 +0300 (EEST) Date: Wed, 17 Jun 2015 11:25:29 +0300 From: Ilari Liusvaara To: Douglas Stebila Message-ID: <20150617082529.GA17280@LK-Perkele-VII> References: <2AA11887-2F82-48EF-BD45-4D85CFA83847@qut.edu.au> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <2AA11887-2F82-48EF-BD45-4D85CFA83847@qut.edu.au> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Computation of static secret in anonymous 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, 17 Jun 2015 08:25:36 -0000 On Wed, Jun 17, 2015 at 07:33:31AM +0000, Douglas Stebila wrote: > In the DH-based draft of TLS 1.3 (https://github.com/ekr/tls13-spec/blob/ietf92_materials/draft-ietf-tls-tls13-dh-based.txt), > how is the ServerParameters message containing the static secret SS > constructed in the unauthenticated setting? There's much newer version in ekr/tls13-spec#WIP_draft_06 (seems to have fixed most of the mistakes in the original WIP) There for anonymous setting, seemingly SS is copy of ES, and configurations (essentially replacement of ServerParameters) can't appear at all (because one needs a certificate to send one). I can't figure out what to use as configurations hash part of session hash in case there isn't assumed or negotiated configuration (some session hashes are seemingly always that way, especially things like the one used for handshake key derivation). It also does not say what master key to use for handshake encryption key derivation. I presume tmp2. Also, I note that seemingly if configuration private key gets compromised, one can MITM all sessions using it at will (it has finite lifetime, but other than that, I see no good way to revoke). -Ilari From nobody Wed Jun 17 05:57: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 90F631A90EF for ; Wed, 17 Jun 2015 05:57:07 -0700 (PDT) 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 uh6EbDcIHNH5 for ; Wed, 17 Jun 2015 05:57:05 -0700 (PDT) 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 020521A90DA for ; Wed, 17 Jun 2015 05:57:05 -0700 (PDT) Received: by wicnd19 with SMTP id nd19so28135382wic.1 for ; Wed, 17 Jun 2015 05:57:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=kgPgUcE3OYW84fTDiyvbZ7ApraciHJhgyhV7PFVVE7w=; b=TNSzHwb24pG7rbPJyGxZQb0eck+rB27WjMqmkCDMndKEWvDlnNjs4KNGf+L2J39e9R oLf3qwzPWU8qm4rp1nHk5Ru+jXNyvwuydS/XsGQoGd4Bd/caqon7WbNfKVjERpX9kuW3 Xz6ZFUWvvN+hnCboHIMJM+vQ+PeKCkY/tIAofIQQAJJyC8sj2rQYpX5daxQtg9vtqo3W NOMF5NhT65gpsjjJgAMQlpG57cNYdAP9fd/uzvcqrmHkS6nm0QI+HuDRe/kExvC9lc1I yjBf0l3PeQNnUHDPELOL3e1nCV1xUmQbkUCKm6V5xSRivZhCRe3mtbthc9zU1Wuf3Xt5 5Z7A== X-Gm-Message-State: ALoCoQlkTYxhcRwFMgb9TusklLCxHXirIlgAy44PRCbgpMFr0Cu61Ck/JQ2zLEsl+WoZpMvk0iPY X-Received: by 10.194.59.79 with SMTP id x15mr5525838wjq.81.1434545823732; Wed, 17 Jun 2015 05:57:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.225.14 with HTTP; Wed, 17 Jun 2015 05:56:23 -0700 (PDT) In-Reply-To: <20150617082529.GA17280@LK-Perkele-VII> References: <2AA11887-2F82-48EF-BD45-4D85CFA83847@qut.edu.au> <20150617082529.GA17280@LK-Perkele-VII> From: Eric Rescorla Date: Wed, 17 Jun 2015 05:56:23 -0700 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=047d7b8737ae3ce19e0518b63a21 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Computation of static secret in anonymous 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, 17 Jun 2015 12:57:07 -0000 --047d7b8737ae3ce19e0518b63a21 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 17, 2015 at 1:25 AM, Ilari Liusvaara < ilari.liusvaara@elisanet.fi> wrote: > On Wed, Jun 17, 2015 at 07:33:31AM +0000, Douglas Stebila wrote: > > In the DH-based draft of TLS 1.3 ( > https://github.com/ekr/tls13-spec/blob/ietf92_materials/draft-ietf-tls-tls13-dh-based.txt > ), > > how is the ServerParameters message containing the static secret SS > > constructed in the unauthenticated setting? > > There's much newer version in ekr/tls13-spec#WIP_draft_06 > (seems to have fixed most of the mistakes in the original WIP) > Don't worry, I'm sure there are plenty of mistakes left! > There for anonymous setting, seemingly SS is copy of ES, and > configurations (essentially replacement of ServerParameters) can't > appear at all (because one needs a certificate to send one). > Affirmative. > I can't figure out what to use as configurations hash part of > session hash in case there isn't assumed or negotiated > configuration (some session hashes are seemingly always that > way, especially things like the one used for handshake key > derivation). > It's empty, but I'll be fixing this. > It also does not say what master key to use for handshake > encryption key derivation. I presume tmp2. > " For handshake records, this means the ephemeral secret (ES)" This whole section is still under active development, though. > Also, I note that seemingly if configuration private key > gets compromised, one can MITM all sessions using it at > will (it has finite lifetime, but other than that, I see > no good way to revoke). Yes, this seems like an inherent property of anything that authenticates with a semi-static or static DH key. -Ekr > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --047d7b8737ae3ce19e0518b63a21 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jun 17, 2015 at 1:25 AM, Ilari Liusvaara <= ilari.lius= vaara@elisanet.fi> wrote:
On Wed, Jun 17, 2015 at 07:33:31AM +0000, Douglas Stebila wrote:
> In the DH-based draft of TLS 1.3 (https://github.com/ekr/tls13-spec/blob/ietf92_m= aterials/draft-ietf-tls-tls13-dh-based.txt),
> how is the ServerParameters message containing the static secret SS > constructed in the unauthenticated setting?

There's much newer version in ekr/tls13-spec#WIP_draft_06
(seems to have fixed most of the mistakes in the original WIP)

Don't worry, I'm sure there are plenty of m= istakes left!

=C2=A0
There f= or anonymous setting, seemingly SS is copy of ES, and
configurations (essentially replacement of ServerParameters) can't
appear at all (because one needs a certificate to send one).

Affirmative.

=C2=A0
I can't figure out what to use as configurations hash part of
session hash in case there isn't assumed or negotiated
configuration (some session hashes are seemingly always that
way, especially things like the one used for handshake key
derivation).

It's empty, but I'= ll be fixing this.

=C2=A0
It also does not say what master key to use for handshake
encryption key derivation. I presume tmp2.

<= div>" For handshake records, this means the ephemeral secret (ES)"= ;

This whole section is still under active develop= ment, though.

=C2=A0
Also, I note that seemingly if configuration private key
gets compromised, one can MITM all sessions using it at
will (it has finite lifetime, but other than that, I see
no good way to revoke).

Yes, this seems lik= e an inherent property of anything that
authenticates with a semi= -static or static DH key.

-Ekr
=C2=A0


-Ilari

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

--047d7b8737ae3ce19e0518b63a21-- From nobody Wed Jun 17 08:05: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 3A76B1ACEA2 for ; Wed, 17 Jun 2015 08:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 A_gfkH9dZGwY for ; Wed, 17 Jun 2015 08:05:09 -0700 (PDT) Received: from emh02.mail.saunalahti.fi (emh02.mail.saunalahti.fi [62.142.5.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4F991ACEA8 for ; Wed, 17 Jun 2015 08:05:08 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id F229C81806; Wed, 17 Jun 2015 18:05:05 +0300 (EEST) Date: Wed, 17 Jun 2015 18:05:05 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20150617150505.GA19959@LK-Perkele-VII> References: <2AA11887-2F82-48EF-BD45-4D85CFA83847@qut.edu.au> <20150617082529.GA17280@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Computation of static secret in anonymous 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, 17 Jun 2015 15:05:16 -0000 On Wed, Jun 17, 2015 at 05:56:23AM -0700, Eric Rescorla wrote: > On Wed, Jun 17, 2015 at 1:25 AM, Ilari Liusvaara < > ilari.liusvaara@elisanet.fi> wrote: > > > On Wed, Jun 17, 2015 at 07:33:31AM +0000, Douglas Stebila wrote: > > > In the DH-based draft of TLS 1.3 ( > > https://github.com/ekr/tls13-spec/blob/ietf92_materials/draft-ietf-tls-tls13-dh-based.txt > > ), > > > how is the ServerParameters message containing the static secret SS > > > constructed in the unauthenticated setting? > > > > There's much newer version in ekr/tls13-spec#WIP_draft_06 > > (seems to have fixed most of the mistakes in the original WIP) > > > > Don't worry, I'm sure there are plenty of mistakes left! Such as how keys for TLS exporters are derived? Trying to search for 'export' or 'extractor' only gives changelog entry about fixing used key... Editor's copy says exporters use master secret (not quite ideal). > > It also does not say what master key to use for handshake > > encryption key derivation. I presume tmp2. > > > > " For handshake records, this means the ephemeral secret (ES)" > > This whole section is still under active development, though. I was thinking about avoiding using ES twice (since it is not secured against THS-style attacks, while tmp2 is). -Ilari From nobody Wed Jun 17 09:36: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 11B9F1B2A52 for ; Wed, 17 Jun 2015 09:36:01 -0700 (PDT) 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 6I43ukgEBR8J for ; Wed, 17 Jun 2015 09:35:56 -0700 (PDT) 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 9A65E1B2A4A for ; Wed, 17 Jun 2015 09:35:56 -0700 (PDT) Received: by wibdq8 with SMTP id dq8so59847667wib.1 for ; Wed, 17 Jun 2015 09:35:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=H22PMVcsUZKiYJSlwfM1DqqGjVdizrd/bNdOKyIGffs=; b=cjz3RrM3qLDhHXlOr3pVTCN4vpUMBvABJKycu+kBiynSv7j6oxd9+Gb3Oki4n92ZGe nfjXzyp9xw44z2dLbkzWkRZOFu1TrKBN4aKCXI6ykmQRdzItxfYT7aYaZ5vLag6Zwa1r yy1I92QM684V6xjYsUWKf/KU3HSAWZ7VsjPshwBpdAE7WvnbT6sBWnUITzKJpKksrMZb m5OW43q2VH9q5jlcmfcdzv2nkS0xTd6JXi+fB0oZWx2PXJlc8YxxrKxgbYqGJf3hSyVf hjGi5Fkg5ecUEhhllQ9rXYIsyMGrw8Fs4zS51DVylQsMNe4JOnSv5ObmnuhaV6QVLvKv 6OEw== X-Gm-Message-State: ALoCoQk5PFQwGh2ClVbWH8B1MrvRflNkNf9GpNW5dL61ocifnJhNKkXMCrz4pCIawQppOX817oKz X-Received: by 10.180.99.39 with SMTP id en7mr55963479wib.31.1434558955377; Wed, 17 Jun 2015 09:35:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.225.14 with HTTP; Wed, 17 Jun 2015 09:35:14 -0700 (PDT) In-Reply-To: <20150617150505.GA19959@LK-Perkele-VII> References: <2AA11887-2F82-48EF-BD45-4D85CFA83847@qut.edu.au> <20150617082529.GA17280@LK-Perkele-VII> <20150617150505.GA19959@LK-Perkele-VII> From: Eric Rescorla Date: Wed, 17 Jun 2015 09:35:14 -0700 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=f46d04182808f1e9fd0518b948c3 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Computation of static secret in anonymous 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, 17 Jun 2015 16:36:01 -0000 --f46d04182808f1e9fd0518b948c3 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 17, 2015 at 8:05 AM, Ilari Liusvaara < ilari.liusvaara@elisanet.fi> wrote: > On Wed, Jun 17, 2015 at 05:56:23AM -0700, Eric Rescorla wrote: > > On Wed, Jun 17, 2015 at 1:25 AM, Ilari Liusvaara < > > ilari.liusvaara@elisanet.fi> wrote: > > > > > On Wed, Jun 17, 2015 at 07:33:31AM +0000, Douglas Stebila wrote: > > > > In the DH-based draft of TLS 1.3 ( > > > > https://github.com/ekr/tls13-spec/blob/ietf92_materials/draft-ietf-tls-tls13-dh-based.txt > > > ), > > > > how is the ServerParameters message containing the static secret SS > > > > constructed in the unauthenticated setting? > > > > > > There's much newer version in ekr/tls13-spec#WIP_draft_06 > > > (seems to have fixed most of the mistakes in the original WIP) > > > > > > > Don't worry, I'm sure there are plenty of mistakes left! > > Such as how keys for TLS exporters are derived? Quite possibly. Hence the WIP designation. > Trying to > search for 'export' or 'extractor' only gives changelog > entry about fixing used key... > > Editor's copy says exporters use master secret (not quite > ideal). > > > > It also does not say what master key to use for handshake > > > encryption key derivation. I presume tmp2. > > > > > > > " For handshake records, this means the ephemeral secret (ES)" > > > > This whole section is still under active development, though. > > I was thinking about avoiding using ES twice (since it is not > secured against THS-style attacks, while tmp2 is). All key derivations include the transcript. -Ekr --f46d04182808f1e9fd0518b948c3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jun 17, 2015 at 8:05 AM, Ilari Liusvaara <= ilari.lius= vaara@elisanet.fi> wrote:
<= span class=3D"">On Wed, Jun 17, 2015 at 05:56:23AM -0700, Eric Rescorla wro= te:
> On Wed, Jun 17, 2015 at 1:25 AM, Ilari Liusvaara <
> ilari.liusvaara@elisane= t.fi> wrote:
>
> > On Wed, Jun 17, 2015 at 07:33:31AM +0000, Douglas Stebila wrote:<= br> > > > In the DH-based draft of TLS 1.3 (
> > h= ttps://github.com/ekr/tls13-spec/blob/ietf92_materials/draft-ietf-tls-tls13= -dh-based.txt
> > ),
> > > how is the ServerParameters message containing the static se= cret SS
> > > constructed in the unauthenticated setting?
> >
> > There's much newer version in ekr/tls13-spec#WIP_draft_06
> > (seems to have fixed most of the mistakes in the original WIP) > >
>
> Don't worry, I'm sure there are plenty of mistakes left!

Such as how keys for TLS exporters are derived?
Quite possibly. Hence the WIP designation.
=C2=A0
Trying to
search for 'export' or 'extractor' only gives changelog
entry about fixing used key...

Editor's copy says exporters use master secret (not quite
ideal).

> > It also does not say what master key to use for handshake
> > encryption key derivation. I presume tmp2.
> >
>
> " For handshake records, this means the ephemeral secret (ES)&quo= t;
>
> This whole section is still under active development, though.

I was thinking about avoiding using ES twice (since it is not
secured against THS-style attacks, while tmp2 is).

All key derivations include the transcript.

-Ekr
=C2=A0

--f46d04182808f1e9fd0518b948c3-- From nobody Wed Jun 17 12:03: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 EB2011B2D32 for ; Wed, 17 Jun 2015 12:03:17 -0700 (PDT) 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_40=-0.001, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.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 I9Z8zjuOVYOf for ; Wed, 17 Jun 2015 12:03:16 -0700 (PDT) Received: from gateway08.websitewelcome.com (gateway08.websitewelcome.com [69.41.242.28]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FE1D1B2D35 for ; Wed, 17 Jun 2015 12:03:16 -0700 (PDT) Received: by gateway08.websitewelcome.com (Postfix, from userid 5007) id AAA2074A5FDD3; Wed, 17 Jun 2015 14:03:15 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway08.websitewelcome.com (Postfix) with ESMTP id 94EFF74A5FD85 for ; Wed, 17 Jun 2015 14:03:15 -0500 (CDT) Received: from [96.231.223.98] (port=58702 helo=[172.16.0.112]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Z5IcF-0001U2-33 for tls@ietf.org; Wed, 17 Jun 2015 14:03:15 -0500 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: <4A5C6D8F-6A28-4374-AF1F-3B202738FB1D@ieca.com> Date: Wed, 17 Jun 2015 15:03:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5EB44559-367E-4173-833D-69E806D33587@ieca.com> References: <4A5C6D8F-6A28-4374-AF1F-3B202738FB1D@ieca.com> To: "" 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.223.98 X-Exim-ID: 1Z5IcF-0001U2-33 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([172.16.0.112]) [96.231.223.98]:58702 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Subject: Re: [TLS] =?windows-1252?q?confirming_the_room=92s_consensus=3A_adopt?= =?windows-1252?q?_HKDF_PRF_for_TLS_1=2E3?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Jun 2015 19:03:18 -0000 All, The consensus of the WG is to replace the current TLS PRF with an HKDF = PRF. Being more specific (and using Brian=92s wording), the TLS 1.3 = will use an HKDF-Extract, then HKDF-Expand, with suitable parameters, as = recommended in RFC5869, to build the keyblock that will be partitioned = into keys. The TLS extractor will also use HKDF in a similar way for = new versions of TLS. WRT the downref issue, this seems entirely procedural and can be dealt = with during the WG/IETF LCs; we=92ll call it out in our WGLC, get our = AD to do it during the IETF LC per the procedures in RFC 3967, and = assuming consensus is reached we can normatively refer to an = informational RFC. WRT msj=92s technical comments about including the length L of the = output key material to the info string, it seems like we are free to do = so if we choose to. I want to avoid having a consensus call on every = issue so if somebody is really against adding the length L of the output = key material to the info string - please start a thread and say why not. spt On Apr 01, 2015, at 14:00, Sean Turner wrote: > This message is to confirm the consensus reached @ the IETF 92 TLS = session in Dallas and at the TLS Interim in Seattle to make the TLS 1.3 = PRF be an HKDF-based PRF (see = http://datatracker.ietf.org/doc/rfc5869/?include_text=3D1). >=20 > Please indicate whether or not you agree with the consensus by = 2015-04-17. If not, please indicate why. Also, please note that we=92re = interested in uncovering new issues not rehashing issues already = discussed. >=20 > Thanks - J&S From nobody Wed Jun 17 12:07: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 C6D181A0024 for ; Wed, 17 Jun 2015 12:07:03 -0700 (PDT) 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 I_ieBv218sNL for ; Wed, 17 Jun 2015 12:07:02 -0700 (PDT) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (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 3D5191B2CEB for ; Wed, 17 Jun 2015 12:07:01 -0700 (PDT) Received: by wiwd19 with SMTP id d19so1187730wiw.0 for ; Wed, 17 Jun 2015 12:07:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=sGysoD5rmDd/J0f9Nn9IFM7PjChjnTFe/Hreii21yVw=; b=PdtG3edGe2ysyquIbVnyZ69FyZZAqU/K+fGcpqCfMdHd9wjxz5snPXPdzXbwW1CBDn cezuFAzszcA3EFmPvl96wQbnb3k19PMK0hLdj3at2pqRJOLs1sqKWF7smZ7ZguGipPHr hK+G4j6zeeru26kkyZp4N0+1xr/J/7io81lI7I4QdqmDS072KoMWRD7tEeGyTCYS/tBh xwrZj79mr3WP4yeefrmBqnMvNetQX1xcNAJMlisIkwnnpJEqUEJy129PNP2Kg+x7/L0m OEy1oknQ40kWWeZGX8msKTxpYKJG//UKxvBlS30+8yFCbSzL+HCa1Tca3OPHfU/4cchA ylzQ== X-Gm-Message-State: ALoCoQnYM/tPOBVRyOfuxOzMhpWOCLC+l5ey78gyGQXB8ztl82AkNvdk/hkAeTvSvGFEv/KRiAcL X-Received: by 10.194.133.73 with SMTP id pa9mr8560209wjb.148.1434568019949; Wed, 17 Jun 2015 12:06:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.225.14 with HTTP; Wed, 17 Jun 2015 12:06:19 -0700 (PDT) In-Reply-To: <5EB44559-367E-4173-833D-69E806D33587@ieca.com> References: <4A5C6D8F-6A28-4374-AF1F-3B202738FB1D@ieca.com> <5EB44559-367E-4173-833D-69E806D33587@ieca.com> From: Eric Rescorla Date: Wed, 17 Jun 2015 12:06:19 -0700 Message-ID: To: Sean Turner Content-Type: multipart/alternative; boundary=089e011771a93c4fed0518bb65ee Archived-At: Cc: "" Subject: Re: [TLS] =?utf-8?q?confirming_the_room=E2=80=99s_consensus=3A_adopt_?= =?utf-8?q?HKDF_PRF_for_TLS_1=2E3?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Jun 2015 19:07:04 -0000 --089e011771a93c4fed0518bb65ee Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Chairs, I will work with Hugo to develop an appropriate proposal based on this direction. Thanks, -Ekr On Wed, Jun 17, 2015 at 12:03 PM, Sean Turner wrote: > All, > > The consensus of the WG is to replace the current TLS PRF with an HKDF > PRF. Being more specific (and using Brian=E2=80=99s wording), the TLS 1.= 3 will use > an HKDF-Extract, then HKDF-Expand, with suitable parameters, as recommend= ed > in RFC5869, to build the keyblock that will be partitioned into keys. Th= e > TLS extractor will also use HKDF in a similar way for new versions of TLS= . > > WRT the downref issue, this seems entirely procedural and can be dealt > with during the WG/IETF LCs; we=E2=80=99ll call it out in our WGLC, get = our AD to > do it during the IETF LC per the procedures in RFC 3967, and assuming > consensus is reached we can normatively refer to an informational RFC. > > WRT msj=E2=80=99s technical comments about including the length L of the = output > key material to the info string, it seems like we are free to do so if we > choose to. I want to avoid having a consensus call on every issue so if > somebody is really against adding the length L of the output key material > to the info string - please start a thread and say why not. > > spt > > On Apr 01, 2015, at 14:00, Sean Turner wrote: > > > This message is to confirm the consensus reached @ the IETF 92 TLS > session in Dallas and at the TLS Interim in Seattle to make the TLS 1.3 P= RF > be an HKDF-based PRF (see > http://datatracker.ietf.org/doc/rfc5869/?include_text=3D1). > > > > Please indicate whether or not you agree with the consensus by > 2015-04-17. If not, please indicate why. Also, please note that we=E2= =80=99re > interested in uncovering new issues not rehashing issues already discusse= d. > > > > Thanks - J&S > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --089e011771a93c4fed0518bb65ee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Chairs,

I will work with Hug= o to develop an appropriate proposal based on this direction.
Thanks,
-Ekr



On Wed, Jun 17, = 2015 at 12:03 PM, Sean Turner <turners@ieca.com> wrote:
All,

The consensus of the WG is to replace the current TLS PRF with an HKDF PRF.= =C2=A0 Being more specific (and using Brian=E2=80=99s wording), the TLS 1.3= will use an HKDF-Extract, then HKDF-Expand, with suitable parameters, as r= ecommended in RFC5869, to build the keyblock that will be partitioned into = keys.=C2=A0 The TLS extractor will also use HKDF in a similar way for new v= ersions of TLS.

WRT the downref issue, this seems entirely procedural and can be dealt with= during the WG/IETF LCs; we=E2=80=99ll call it out in our WGLC,=C2=A0 get o= ur AD to do it during the IETF LC per the procedures in RFC 3967, and assum= ing consensus is reached we can normatively refer to an informational RFC.<= br>
WRT msj=E2=80=99s technical comments about including the length L of the ou= tput key material to the info string, it seems like we are free to do so if= we choose to.=C2=A0 I want to avoid having a consensus call on every issue= so if somebody is really against adding the length L of the output key mat= erial to the info string - please start a thread and say why not.

spt

On Apr 01, 2015, at 14:00, Sean Turner <turners@ieca.com> wrote:

> This message is to confirm the consensus reached @ the IETF 92 TLS ses= sion in Dallas and at the TLS Interim in Seattle to make the TLS 1.3 PRF be= an HKDF-based PRF (see http://datatracker.= ietf.org/doc/rfc5869/?include_text=3D1).
>
> Please indicate whether or not you agree with the consensus by 2015-04= -17.=C2=A0 If not, please indicate why.=C2=A0 Also, please note that we=E2= =80=99re interested in uncovering new issues not rehashing issues already d= iscussed.
>
> Thanks - J&S

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

--089e011771a93c4fed0518bb65ee-- From nobody Wed Jun 17 20:07: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 A0DE81ACE4F for ; Wed, 17 Jun 2015 20:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.3 X-Spam-Level: * X-Spam-Status: No, score=1.3 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_48=0.6, MIME_QP_LONG_LINE=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 Wl2HB0KM7maR for ; Wed, 17 Jun 2015 20:07:37 -0700 (PDT) Received: from out4133-34.mail.aliyun.com (out4133-34.mail.aliyun.com [42.120.133.34]) by ietfa.amsl.com (Postfix) with ESMTP id 192DB1ACE42 for ; Wed, 17 Jun 2015 20:07:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1434596855; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; bh=OeGAgohX7ZVYVHJLo8PoAfWdtXRINAziNTokoVkZiWA=; b=LdYch8stJpV7JH+c424aZnl43QO2ar4Njz6VF1U3BnC0qGjlPymxMf+gLhXnCU2ZKir9iR3TZv4CTMaqTn5y9rxDDxt82NNJKbuxPBOPPs2+/mXAkff0iVDH7d6omNi5SE+9q6V0NWRcH4rNUVo7WN8zF4wrPdWQSaAzKUmMriQ= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R191e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r41g03020; MF=bingzheng.wbz@alibaba-inc.com; PH=DW; RN=1; RT=1; SR=0; Received: from WS-web (bingzheng.wbz@alibaba-inc.com[42.120.74.183]) by r41g03021.xy2.aliyun.com at Thu, 18 Jun 2015 11:07:34 +0800 Date: Thu, 18 Jun 2015 11:07:34 +0800 From: "Bingzheng Wu" To: "tls" Message-ID: <----3-------MPf3-$e9162029-e7fe-4f8d-9805-569a4c7475b1@alibaba-inc.com> X-Mailer: Alimail-Mailagent revision 2696742 MIME-Version: 1.0 x-aliyun-mail-creator: W4_2697534_hLSTW96aWxsYS81LjAgKFdpbmRvd3MgTlQgNi4xOyBXT1c2NCkgQXBwbGVXZWJLaXQvNTM3LjM2IChLSFRNTCwgbGlrZSBHZWNrbykgQ2hyb21lLzQzLjAuMjM1Ny4xMjQgU2FmYXJpLzUzNy4zNg==2I Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [TLS] =?utf-8?q?is_it_good_using_password_for_authentication_only?= =?utf-8?q?=3F?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bingzheng Wu List-Id: "This is the mailing list 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, 18 Jun 2015 03:07:38 -0000 Hi all,=0A=0AI have a question about authentication and key-exchange.=0A=0ATLS= 1.3 removes RSA and DH static key-exchange, which mixs authentication=0Aand k= ey-exchange together.=0AHowever there are some PAKE models for TLS, e.g. RFC 5= 054 and 2 drafts.=0AI think that PAKE mixs them together too.=0A=0AWhich is be= tter, mixing them together, or keeping them independent to each other?=0AIs it= possible to use password for authentication only?=0A=0A=0AHere is a example h= andshake flow for password-based authentication:=0A=0A ClientHello=0A Client= Keyshare -->=0A ServerHello=0A = ServerKeyshare=0A PasswordVerify=0A = <-- Finished=0A PasswordVerify=0A Finished -->=0A=0Awhere:=0A=0A= ClientHello takes an extension to carry username.=0A=0A PasswordVerify take= s the verifier based on password, which could be:=0A HASH(username, passw= ard, handshake_message_hash, label)=0A where handshake_message_hash is de= fined in TLS 1.3,=0A and label is "TLS 1.3, server PasswordVerify" or "TL= S 1.3, client=0A PasswordVerify".=0A=0A and other messages keep the same= with TLS 1.3.=0A=0A=0AThis could work with Certificate authentication togethe= r, by server adding=0ACertificate and CertificateVerify messages following Pas= swordVerify, and=0Aclient verifying them both.=0A=0A=0AIs this ok?=0A=0AI thin= k this makes it easier to merge passward-based authentication into TLS 1.3.=0A= =0A=0AThanks in advance,=0ABingzheng Wu From nobody Thu Jun 18 04:19: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 494D01A1BA5 for ; Thu, 18 Jun 2015 04:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.699 X-Spam-Level: ** X-Spam-Status: No, score=2.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 DoqD0Xq8SBv8 for ; Thu, 18 Jun 2015 04:19:50 -0700 (PDT) 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 3E64C1A1BB1 for ; Thu, 18 Jun 2015 04:19:49 -0700 (PDT) Received: from pc1 (x4d03062b.dyn.telefonica.de [::ffff:77.3.6.43]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Thu, 18 Jun 2015 13:19:46 +0200 id 00000000000000F1.000000005582A952.00004D84 Date: Thu, 18 Jun 2015 13:20:41 +0200 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: tls@ietf.org Message-ID: <20150618132041.1ae55865@pc1> In-Reply-To: <20150613193444.GA31312@typhoon.azet.org> References: <20150613193444.GA31312@typhoon.azet.org> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-19844-1434626386-0001-2" Archived-At: Subject: Re: [TLS] What's up with TACK? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Jun 2015 11:19:52 -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-19844-1434626386-0001-2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm a bit surprised that nobody seems to care to answer here. CA failures still happen on a quite regular basis. We recently had CNNIC, ANSSI and India CCA. I think this is the elephant in the room of TLS problems. HPKP makes me have very mixed feelings. On the one hand I'm happy that we have something at last, but on the other hand I fear that people might move into the "we now have a solution for HTTPS" direction and neglect other uses of TLS. I'd be worried if we consider non-HTTPS-TLS a second-best security solution. Also from my understanding TACK also solves another problem: STARTTLS-stripping (draft, chapter 5.2), which is as far as I'm aware also otherwise an unsolved issue (see e.g. [1]). In other words: I support Aarons request to adopt TACK or something similar. [1] https://blog.filippo.io/the-sad-state-of-smtp-encryption/ --=20 Hanno B=C3=B6ck http://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: BBB51E42 --=_zucker.schokokeks.org-19844-1434626386-0001-2 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJVgqmJAAoJEKWIAHK7tR5CWxQQAJj74OL2YVGD9aiEVC2zJhC6 J1V5lavukcsGc0rBbClVI/zlKdd+dSaYCrg/rFtAwMFkVYxpFzgOljSaeGtHCfJ8 5TOtJxZ74fbJrclOm663VkccqmxKosOkDqJ7SYzHDuuWOWNOb+Ye2irVANHcKbpm VeGB373+4MZnRWV5T2+EZa46nBu5lx0t1nt7jfqdFJGib7M+6isPnbA/WV73ceT+ i2MgHP1WO9Cc1LEiNNA/3SJJ2WBq+6vead1tWhurD7zt8ghHp05wUdfkyb5NNof8 aY2su3MAUD87f3aFJmk998vgAtxjz63/fIQdJ69/pTuxyxjU8bALcHkyaRI/igW4 zfVc5rmqjnPvMBH03Pt+m6us/38eHQ6zpsM8mq7iEEK64L1yNK2yfetEbk/mAmEh 4xXZHS6QYF0oYBK7aIvg/RWWYXw9GJ0vZ50xXmc5DwkYRFkrRncFVqCp1RB4p1tf KRH42xGyB9oOxZeLAJx90J2gCqTpwymA/SdZBMZLr6Yx2I4TxV6ha/oSIrrqHQA3 kCrP3Ji4+bCXIQ6pBNGwO5tCzRgjpYZbygzfktShAhf8TrvtK+M+12Bp0Zb8fbwm 18Zm3NWDc27FhDTt9fFW6WWX6YLbG9Xgi2g4TW3nZb0sDKEIw8LJPsQDD4DSDeiA Jd9TBAA407yRByBulSLu =QiKs -----END PGP SIGNATURE----- --=_zucker.schokokeks.org-19844-1434626386-0001-2-- From nobody Fri Jun 19 01:19: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 CC56D1A8725 for ; Fri, 19 Jun 2015 01:19:54 -0700 (PDT) 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_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_48=0.6, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 LzIkik7w2tRm for ; Fri, 19 Jun 2015 01:19:53 -0700 (PDT) Received: from out4133-66.mail.aliyun.com (out4133-66.mail.aliyun.com [42.120.133.66]) by ietfa.amsl.com (Postfix) with ESMTP id 423751A871C for ; Fri, 19 Jun 2015 01:19:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1434701992; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; bh=u6Gp5i3JDfs2BjnP777CPvcC6TuSEpAPhC3NA2BJODg=; b=xnEeD9CgQIXBVCbd8lWWoHH2F/ApKsGuweyyDO5MrVHYY3tg1LiUIKmi+nvcl/8MWH8ViO/Fwg7MtxFM14mgqY2MdlemqVcLWNYK2fhM+dUTaJRIj9OW07brB/PcASxL2SY+I2E8JXRlG+BG994kPEIWEFve9FMPeQPNefRMkwE= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R181e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r41g03020; MF=bingzheng.wbz@alibaba-inc.com; PH=DS; RN=2; RT=2; SR=0; Received: from ali074145n(mailfrom:bingzheng.wbz@alibaba-inc.com ip:42.120.74.187) by smtp.aliyun-inc.com(127.0.0.1); Fri, 19 Jun 2015 16:19:39 +0800 From: "Bingzheng Wu" To: "Bingzheng Wu" , "'tls'" References: <----3-------MPf3-$e9162029-e7fe-4f8d-9805-569a4c7475b1@alibaba-inc.com> In-Reply-To: <----3-------MPf3-$e9162029-e7fe-4f8d-9805-569a4c7475b1@alibaba-inc.com> Date: Fri, 19 Jun 2015 16:19:38 +0800 Message-ID: <011401d0aa68$af6818e0$0e384aa0$@alibaba-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIpOz5ldmRkdleV+OrBFxoGmWrSs50CWOlw Content-Language: zh-cn Archived-At: Subject: Re: [TLS] is it good using password for authentication only? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bingzheng Wu List-Id: "This is the mailing list 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, 19 Jun 2015 08:19:55 -0000 Maybe I realize the problem. The PasswordVerify message is susceptible to offline dictionary attacks. Dose it become resistant to the attack if we add some secret generated from master-secret into the HASH? PasswordVerify = HASH(username, passward, handshake_message_hash, master-secret, label) This becomes involved with key-exchange, but it is not involved with any specific key-exchange method. It just need the key-exchange result. Bingzheng > -----Original Message----- > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Bingzheng Wu > Sent: Thursday, June 18, 2015 11:08 AM > To: tls > Subject: [TLS] is it good using password for authentication only? > > Hi all, > > I have a question about authentication and key-exchange. > > TLS 1.3 removes RSA and DH static key-exchange, which mixs authentication > and key-exchange together. > However there are some PAKE models for TLS, e.g. RFC 5054 and 2 drafts. > I think that PAKE mixs them together too. > > Which is better, mixing them together, or keeping them independent to each > other? > Is it possible to use password for authentication only? > > > Here is a example handshake flow for password-based authentication: > > ClientHello > ClientKeyshare --> > ServerHello > ServerKeyshare > PasswordVerify > <-- Finished > PasswordVerify > Finished --> > > where: > > ClientHello takes an extension to carry username. > > PasswordVerify takes the verifier based on password, which could be: > HASH(username, passward, handshake_message_hash, label) > where handshake_message_hash is defined in TLS 1.3, > and label is "TLS 1.3, server PasswordVerify" or "TLS 1.3, client > PasswordVerify". > > and other messages keep the same with TLS 1.3. > > > This could work with Certificate authentication together, by server adding > Certificate and CertificateVerify messages following PasswordVerify, and client > verifying them both. > > > Is this ok? > > I think this makes it easier to merge passward-based authentication into TLS > 1.3. > > > Thanks in advance, > Bingzheng Wu > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Fri Jun 19 04:03: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 BC0881A894E for ; Fri, 19 Jun 2015 04:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_48=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=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 lXD9KqdTMgi1 for ; Fri, 19 Jun 2015 04:03:07 -0700 (PDT) Received: from out4133-50.mail.aliyun.com (out4133-50.mail.aliyun.com [42.120.133.50]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9091A894A for ; Fri, 19 Jun 2015 04:03:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1434711785; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; bh=uCocMO6y1AnR75p5Rr3q67cltFDxPLNwdRsemcLMUMQ=; b=trSZx3uKBOnF3ErtRlKkMK63bPDQHzWvFSckQA2UB1dTRpqBcJvpZv/BL2ee9yKhRe2uS/Rn5IEYY3jd72SGUgCoulRS4BZVclGEdDwnKeOdTqHbaMet1jINKs6VrmFAShinlMZaZpjO4Y3OUmTXvgPDY3NLGjQeSfjt/AGkFCo= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R141e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r46d02008; MF=bingzheng.wbz@alibaba-inc.com; PH=DW; RN=2; RT=2; SR=0; Received: from WS-web (bingzheng.wbz@alibaba-inc.com[42.120.74.157]) by r41g03043.xy2.aliyun.com at Fri, 19 Jun 2015 19:03:02 +0800 Date: Fri, 19 Jun 2015 19:03:02 +0800 From: "Bingzheng Wu" To: "=?UTF-8?B?5q2m54Kz5q2jKOWFgeS4rSk=?=" , "tls" Message-ID: <----3-------MPf3-$9050573e-2304-452c-9b77-668deaf79dd6@alibaba-inc.com> X-Mailer: Alimail-Mailagent revision 2698616 MIME-Version: 1.0 References: <----3-------MPf3-$e9162029-e7fe-4f8d-9805-569a4c7475b1@alibaba-inc.com>, 011401d0aa68$af6818e0$0e384aa0$@alibaba-inc.com In-Reply-To: 011401d0aa68$af6818e0$0e384aa0$@alibaba-inc.com x-aliyun-mail-creator: W4_2697534_hLSTW96aWxsYS81LjAgKFdpbmRvd3MgTlQgNi4xOyBXT1c2NCkgQXBwbGVXZWJLaXQvNTM3LjM2IChLSFRNTCwgbGlrZSBHZWNrbykgQ2hyb21lLzQzLjAuMjM1Ny4xMjQgU2FmYXJpLzUzNy4zNg==2I Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] =?utf-8?q?is_it_good_using_password_for_authentication_only?= =?utf-8?q?=3F?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bingzheng Wu List-Id: "This is the mailing list 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, 19 Jun 2015 11:03:07 -0000 I am wrong again. Adding master-secret is useless.=0A=0ANow I think that asymm= etric crypto must be used to prevent offline directory attack, which is the wa= y PAKE works as.=0A=0ASorry for disturbing.=0A=0A=0A--------------------------= ----------------------------------------=0AFrom:=E6=AD=A6=E7=82=B3=E6=AD=A3(=E5= =85=81=E4=B8=AD) =0ATime:2015 Jun 19 (Fri) 16:1= 9=0ATo:=E6=AD=A6=E7=82=B3=E6=AD=A3(=E5=85=81=E4=B8=AD) , tls =0ASubject:RE: [TLS] is it good using password for= authentication only?=0A=0AMaybe I realize the problem. The PasswordVerify mes= sage is susceptible to=0Aoffline dictionary attacks.=0A=0ADose it become resis= tant to the attack if we add some secret generated from=0Amaster-secret into t= he HASH?=0A=0A PasswordVerify =3D HASH(username, passward, handshake_message_= hash,=0Amaster-secret, label)=0A=0AThis becomes involved with key-exchange, bu= t it is not involved with any=0Aspecific key-exchange method.=0AIt just need t= he key-exchange result.=0A=0A=0ABingzheng From nobody Tue Jun 23 04:42: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 E5B931B2B12 for ; Tue, 23 Jun 2015 04:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, 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 4KgPbKvdEG39 for ; Tue, 23 Jun 2015 04:42:07 -0700 (PDT) Received: from tus1smtoutpex03.symantec.com (tus1smtoutpex03.symantec.com [216.10.195.243]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 471641B2B56 for ; Tue, 23 Jun 2015 04:42:07 -0700 (PDT) X-AuditID: d80ac3f3-f798f6d000007a91-e8-558945ffc38d Received: from tus1opsmtapin01.ges.symantec.com (tus1opsmtapin01.ges.symantec.com [192.168.214.43]) by tus1smtoutpex03.symantec.com (Symantec Brightmail Gateway out) with SMTP id 01.0D.31377.FF549855; Tue, 23 Jun 2015 12:41:51 +0100 (BST) Received: from [155.64.220.138] (helo=TUS1XCHHUBPIN02.SYMC.SYMANTEC.COM) by tus1opsmtapin01.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1Z7MaN-0006DH-RT for tls@ietf.org; Tue, 23 Jun 2015 11:41:51 +0000 Received: from TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM ([155.64.220.146]) by TUS1XCHHUBPIN02.SYMC.SYMANTEC.COM ([155.64.220.138]) with mapi; Tue, 23 Jun 2015 04:42:01 -0700 From: Rick Andrews To: "tls@ietf.org" Date: Tue, 23 Jun 2015 04:41:48 -0700 Thread-Topic: Strawman on EdDSA/Ed25519 in TLS Thread-Index: AdCtqS/mNgMErVLqQfeSDIsgN1W6mQ== Message-ID: <544B0DD62A64C1448B2DA253C011414615B1DD55AC@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0292_01D0AD6E.E9FA30C0" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHIsWRmVeSWpSXmKPExsVyYMU1bd3/rp2hBhvvmFt8Ot/F6MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujMZD31kKTvhWfO6fxNjAON2zi5GTQ0LAROLf+g+MELaYxIV7 69m6GLk4hAQ+MEpcbu1mh3D+MkqcON3LCuGsYpS4saGfDaSFTUBPYsvjK+wgtoiAosSOq91g NouAqsTbd0/BaoQF9CX2LdvMClGjL7Hxxn1GCFtPYvLW6ywgNq9AlMTDs1/BehmBzvh+ag0T iM0sIC5x68l8JojzRCQeXjzNBmGLSrx8/I8Vol5U4k77ekaI+l5Gia3/XCFmCkqcnPmEZQKj 8Cwko2YhKZuFpGwWIwdQXE+ibSMjRIm8xPa3c5ghbGuJGb8OskHYihJTuh+yQ9imEq+PfmRc wMixilGmpLTYsDi3JL+0pCC1wsBYr7gyNxEYT8l6yfm5mxiBMXWD6/DnHYy/9zgeYhTgYFTi 4d1m1hkqxJpYBlR5iFEFaNyjDasvMEqx5OXnpSqJ8P52AErzpiRWVqUW5ccXleakFh9ilOZg URLn7VjUHCokkJ5YkpqdmlqQWgSTZeLglGpgjK+r6CmPf/XxQFSi5QuLl69U34s9O/t8kYKv 5NuGKjljfTsJg6Vbay6cubZ487tJ86eUWB7QPjDr1cUPZne1fjmtbn9l9vLgjkfir/k4i34V vRQMXhRUc0N81bdQ4eUbphr/n+/Dq+V4SfizTK6ze1Zhyi+eCTP/PKpIMWpXVzqw4qAu58mv T5VYijMSDbWYi4oTAXdjxcOxAgAA Archived-At: Subject: Re: [TLS] Strawman on EdDSA/Ed25519 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: Tue, 23 Jun 2015 11:42:09 -0000 ------=_NextPart_000_0292_01D0AD6E.E9FA30C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Symantec owns Thawte which owns 1.3.101. We're happy to donate a reasonable number of OIDs under this arc for your purposes. Please let me know if you'd like to take us up on the offer. Thanks to Rob Stradling for bringing this to my attention. -Rick -----Original Message----- Date: Thu, 21 May 2015 19:42:53 -0700 From: Peter Bowen To: Nico Williams Cc: Simon Josefsson , "tls@ietf.org" Subject: Re: [TLS] Strawman on EdDSA/Ed25519 in TLS Message-ID: Content-Type: text/plain; charset=UTF-8 On Wed, May 20, 2015 at 12:07 PM, Nico Williams wrote: > On Wed, May 20, 2015 at 07:14:47PM +0200, Simon Josefsson wrote: >> Support for EdDSA/Ed25519 in TLS has been suggested a couple of times. > > I'm in favor. > >> One aspect I'm aware of is that there is no OID allocated nor >> specification of PKIX certificates with EdDSA/Ed25519 public keys. >> I'm not sure the above document is the right place for doing that >> though, and more thinking around this topic is especially appreciated. > > It's an OID. You can get your own OID arc and then allocate an OID. > > Is it important to separate the addition of a PKIX algorithm OID from > the TLS bits? Well, it is neater that way. I'll donate a short OID to the cause if that will help move things forward. We have the 1.3.187 arc which is only three bytes DER. If someone has a smaller arc (third node would be 127 or lower) and would offer an OID from their arc we can shave off another couple of bytes. ------=_NextPart_000_0292_01D0AD6E.E9FA30C0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRhzCCBBkw ggMBAhBhcMtJjF+YRSnnsKbZUFt6MA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHMzAeFw05OTEwMDEwMDAwMDBaFw0zNjA3MTYyMzU5NTlaMIHKMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQg dXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK8K DcLVLNtnuS3llCfdpb7gsE2Ps2FWPNZ8w/TNPobLooji4dikacW14r/BpkdQXkY5i9WWurVvFL8Q zicTngVHmzF6E9gf2dMCN4utLEfwjoEGpw0wDOv3PA8gHdxyRu6lAshbw8lWaUzFGMGRewvVEwCb vO/DSD5GYCCFKtWQts2LoMwy3bf9QFWyUBxWrsyNd03HIE2nMXbvaJKKkB4IgVayrWmjUtDLHMQj PR+Z/kzoFmOOxgiO9jH20vrldt21HJKjSc3NAc1ozalpuqPrHQ2cpCCmwaDF0UZMF23SrGY/lozg hNQ2/yJZxfkRYKhfBH3yGvYlQmEPxEq4PokCAwEAATANBgkqhkiG9w0BAQUFAAOCAQEANCYVPMCN TUNJHb3pIZLXZpy33sW40ORdX3YiwCb5hDo6+Yy1++xg8ejOBLDI3acDjzDzmN+k5qQx39McC0bc ciA/ru4FPKQzPws5rHB4c0uZK98wwlSwqDtVof4WKM1CvXRugNsnRKfORF3UG5CYDR5ClLEALATQ dKMCBSJjY82DtfvBbWJraXX9XXBBufW/fN++wTJzIiGLWIF7FZF6uuNkSLB/+zYl2pXQ8SQUF90Y gGtGIzlU9Y5iCQQdlJCmm+Yl4kJFqriQrb4Ij6kLQhiUz3I54bFD4CjPt+dabBNrSbP/4xh8iYsz Xawz16f52jpVyVgQ+arvWrbPS0vfKjCCBkwwggU0oAMCAQICEBw3Lcu5cD5rtz7z+tELQgYwDQYJ KoZIhvcNAQELBQAwgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24s IEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3Mg MiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTE1MDEwNjAw MDAwMFoXDTI1MDEwNTIzNTk1OVowgbAxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBD b3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xh c3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExKjAoBgNVBAMTIVN5bWFu dGVjIENsYXNzIDIgRW1wbG95ZWUgQ0EgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALbX9Fd7nt9wUT7ISGRoQMGJbj8EkkrtHHQnINo4z1KTPLnRWscXLT5oTmFpC7JuaHn0AnYK +NJutht+e0vGtU/avfhJDgLP7K1qZ+vOBHm9hMzzmiME1s9CP0nOlifrJK5h2TS5Znq8g4kfGJTA asB5zmfjNVCJomx17jhf8fuZrvMXSBsWDxl6NGohZloUgxFAwrCe0NuDzt8E8jJCgw5lewsqjlll eBvJbCxOXhcuMvjK6/ilNC1WjkaIlTWXyaraGQAMPm2nsZED4+aBNRMX855Amtk5zAoKh1oeIiN7 2YaPVmiIIOeGKqY0B3RYTY7cmxgU4RA5xgKA3LeMIP0CAwEAAaOCAkQwggJAMBIGA1UdEwEB/wQI MAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXAjBSMCYGCCsGAQUFBwIBFhpodHRwOi8v d3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29t L3JwYTAOBgNVHQ8BAf8EBAMCAQYwNwYIKwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8v cGtpLW9jc3Auc3ltYXV0aC5jb20wNwYDVR0fBDAwLjAsoCqgKIYmaHR0cDovL2NybC53cy5zeW1h bnRlYy5jb20vcGNhMi1nMy5jcmwwKAYDVR0RBCEwH6QdMBsxGTAXBgNVBAMTEFN5bWFudGVjUEtJ LTItMjMwHQYDVR0OBBYEFKQzr7DDRoer5XhJsrTiRp/qCfwVMIHwBgNVHSMEgegwgeWhgdCkgc0w gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghBhcMtJjF+YRSnnsKbZUFt6MA0GCSqG SIb3DQEBCwUAA4IBAQChthp96rPOdkvEEfo4yk4Q8auHf5LqUJUlwDdoAvuCrYDLM9TMQzCwRWf7 IpiGPMAVnddFj2ohiX3bYd0tkaqyjfDJDtZQK9YgN5GD0RTO2gHS0PHOOyJBSDJ5G0um4NLofhkB h9RqEE3mBF68RGe4Te7Z5ST+pvgqGzC8v/2xDEZcClXhch8gNU7muFl18YdX9gWV54BcTj0lo9E9 9/2HVCPB5QAzFhHqgHjDnETpw5S3JlpKTEMXyqaWd/5+Vo+ID+jd51HS+BS1u2Dguv+FvgINTVrr IO1ymEh5L3XM4gQrCgD7yajPRf/BIjyF/xzL/ONUoxd8e1gR/E1N98oyMIIHFjCCBf6gAwIBAgIQ OVrt7EotOiYavftZTf7D7jANBgkqhkiG9w0BAQsFADCBsDELMAkGA1UEBhMCVVMxHTAbBgNVBAoT FFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMTUw MwYDVQQLEyxDbGFzcyAyIE1hbmFnZWQgUEtJIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEqMCgG A1UEAxMhU3ltYW50ZWMgQ2xhc3MgMiBFbXBsb3llZSBDQSAtIEczMB4XDTE1MDYwNTAwMDAwMFoX DTE2MDYwNDIzNTk1OVowWDEdMBsGA1UECgwUU3ltYW50ZWMgQ29ycG9yYXRpb24xIDAeBgNVBAsM F1N5bWFudGVjIEVtcGxveWVlIEVtYWlsMRUwEwYDVQQDDAxSaWNrIEFuZHJld3MwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMkzz3/cxC5IPK1PgEVnb2v6HNo5VaRHC5nKGTtKfmdl58 yBdBK4SJwGSIHiQsIgItAQc4mmd7MUIQOxt5RN7dCFMDFzxbSF0nIl1GR52WzN8mgVE9+6oMxDKN 5LOckMEKNH13NF7Ebjz/p0v0JaRHEuzG4w12ah3B8GkBKJn0XDRJjZNq1R/fJJxklUWsQcimw7S5 bb9bGQwCipDGDn1WLaXP1UWDqyP/ja6OYyKY3QFlk1olDk5iZ5XipSiX57euk9FigV4Ddu6gsVaE hQR/mZNcNag1rH/RjcVoox7iTgvKxyBh3VVT2dEX4vebLdt2/rwIgz626XDSTeUmJQ+ZAgMBAAGj ggOBMIIDfTAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIFoDAWBgNVHSUBAf8EDDAKBggrBgEF BQcDBDAdBgNVHQ4EFgQUVoVKaC1xEPB9EWKq3dWrwskIufkwJAYDVR0RBB0wG4EZUmlja19BbmRy ZXdzQHN5bWFudGVjLmNvbTAfBgNVHSMEGDAWgBSkM6+ww0aHq+V4SbK04kaf6gn8FTCCAWQGCCsG AQUFBwEBBIIBVjCCAVIwJwYIKwYBBQUHMAGGG2h0dHA6Ly9wa2ktb2NzcC5zeW1hdXRoLmNvbTCC ASUGCCsGAQUFBzAChoIBF2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24uY29tL0NOJTIwJTNEJTIw U3ltYW50ZWMlMjBDbGFzcyUyMDIlMjBFbXBsb3llZSUyMENBJTIwLSUyMEczJTJDJTIwT1UlMjAl M0QlMjBDbGFzcyUyMDIlMjBNYW5hZ2VkJTIwUEtJJTIwSW5kaXZpZHVhbCUyMFN1YnNjcmliZXIl MjBDQSUyQyUyME9VJTIwJTNEJTIwU3ltYW50ZWMlMjBUcnVzdCUyME5ldHdvcmslMkMlMjBPJTIw JTNEJTIwU3ltYW50ZWMlMjBDb3Jwb3JhdGlvbiUyQyUyMEMlMjAlM0QlMjBVUz9jQUNlcnRpZmlj YXRlO2JpbmFyeTBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vcGtpLWNybC5zeW1hdXRoLmNvbS9j YV8yYzc5ZDVmMGM0NTZlMGUzZTJmYjNlMjM2OTAzZGExNS9MYXRlc3RDUkwuY3JsMGwGA1UdIARl MGMwYQYLYIZIAYb4RQEHFwIwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9j cHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwQgYJKoZIhvcNAQkP BDUwMzAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBKjAr BgpghkgBhvhFARADBB0wGwYSYIZIAYb4RQEQAQICAQGdpPp0FgUxNjc0ODA5BgpghkgBhvhFARAF BCswKQIBABYkYUhSMGNITTZMeTl3YTJrdGNtRXVjM2x0WVhWMGFDNWpiMjA9MA0GCSqGSIb3DQEB CwUAA4IBAQAXM1lZbwfKyY8FFxOxBuM1zaVaoRHcKD6EjwhcTlIeFQSGl/n24G+1xpy6NIe7Mwzp EAwVUwzb3wKFyKnDMdDvPIedes3QyC1yIjA3ZViOLNpIhWmalth1ohXYFGjjLx7eAq6GJ7oorcJH ZCWOMNr4Nm82UlZ4WoOw1W9mU2ll9R4rfDxsWOImko7O0E9fvozhf4B224DA6cin71gk5rFzzzKC Knjv2lUSpjNuOmlcY2LFOIKPyFzpGKRikO/LwfWVsefhppBSRGKaxfbKS9QP8ex1IcZgGbdCTBzW t9u/tgGv8+qMCn347fdIwO3qFAFgGfJULuFLOvdwqtkJZ8CxMYIEsDCCBKwCAQEwgcUwgbAxCzAJ BgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50 ZWMgVHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0ExKjAoBgNVBAMTIVN5bWFudGVjIENsYXNzIDIgRW1wbG95ZWUgQ0EgLSBH MwIQOVrt7EotOiYavftZTf7D7jAJBgUrDgMCGgUAoIICvzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNTA2MjMxMTQxNDdaMCMGCSqGSIb3DQEJBDEWBBSxBqbi84It ob++kmFaa1Z3t/e7ljCBqwYJKoZIhvcNAQkPMYGdMIGaMAsGCWCGSAFlAwQBKjALBglghkgBZQME ARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggq hkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUD BAICMAsGCWCGSAFlAwQCATCB1gYJKwYBBAGCNxAEMYHIMIHFMIGwMQswCQYDVQQGEwJVUzEdMBsG A1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENB MSowKAYDVQQDEyFTeW1hbnRlYyBDbGFzcyAyIEVtcGxveWVlIENBIC0gRzMCEDla7exKLTomGr37 WU3+w+4wgdgGCyqGSIb3DQEJEAILMYHIoIHFMIGwMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3lt YW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxNTAzBgNV BAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMSowKAYDVQQD EyFTeW1hbnRlYyBDbGFzcyAyIEVtcGxveWVlIENBIC0gRzMCEDla7exKLTomGr37WU3+w+4wDQYJ KoZIhvcNAQEBBQAEggEAccVPUs3h+/PmzheHg7bpewbsLQ0G6rLhX+3MihcuoxGAls2ZJxnzvhLU m9yMKTPIraaGD0dAVBMy0jGF0hWaM/AS4mlFgd/btjSynVw5xfVR2vL4qo/9FKZuhZhDEdOI8tEp vPjJf0pw3DpEYUnh90CneBIqcLlbLWbdOdQO1mH6MON01XSo9nuGX4zbAayfk+KeN6e1xaJdpPks 6SdAnc5GjDBZ0XikH5589Xj6j5Kl6fqMNVeCbFHPOv297TajekMLSkuttuIw1ALzTb6my+dxY2QE 8XjSK3eFXoJWwATd00VM8TR+xpR6yoGxPrqpLFZog/fEQVvQo+oYXAY2TwAAAAAAAA== ------=_NextPart_000_0292_01D0AD6E.E9FA30C0-- From nobody Tue Jun 23 11:33: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 BE4BE1B2F39 for ; Tue, 23 Jun 2015 11:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 JK3y4oCz_MvX for ; Tue, 23 Jun 2015 11:32:57 -0700 (PDT) Received: from emh03.mail.saunalahti.fi (emh03.mail.saunalahti.fi [62.142.5.109]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D3C51B2F3C for ; Tue, 23 Jun 2015 11:32:56 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id C74BA188786; Tue, 23 Jun 2015 21:32:53 +0300 (EEST) Date: Tue, 23 Jun 2015 21:32:53 +0300 From: Ilari Liusvaara To: Simon Josefsson Message-ID: <20150623183253.GA20173@LK-Perkele-VII> References: <20150612180230.4804.45802.idtracker@ietfa.amsl.com> <20150612195654.GA9401@LK-Perkele-VII> <87381sk767.fsf@latte.josefsson.org> <87twu8irb8.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87twu8irb8.fsf@latte.josefsson.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] I-D Action: draft-ietf-tls-curve25519-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Jun 2015 18:32:59 -0000 On Mon, Jun 15, 2015 at 11:40:11PM +0200, Simon Josefsson wrote: > Martin Thomson writes: > > > On 15 June 2015 at 14:12, Simon Josefsson wrote: > > > > You don't have to add a 4 at the front, or mess around with forms. > > Just define (by reference to draft-irtf-cfrg-curves, preferably) the > > format. We have plenty of contextual information available in TLS, we > > just need the bytes. > > I agree! Committed as follows: > > https://gitlab.com/jas/ietf-tls-newcurves/commit/e7b449ee5af70c2a0851f617ce225f93cc86d993#diff-1 +1. But seemingly examples of encoding got stripped in process. Could be a good idea to take the DH test vectors from cfrg-curves and also show the resulting premaster secret (note: The hexadecimal versions are already little-endian, as can be seen by computing mod 16 on the decimal integer versions). Also, could be a good idea to add Curve448 while at it too (Note: The DH final result in testcase is wrong, the correct one seems to be: 07fff4181ac6cc95ec1c16a94a0f74d12da232ce40a77552281d282b b60c0b56fd2464c335543936521c24403085d59a449a5037514a879d As per https://www.ietf.org/mail-archive/web/cfrg/current/msg06770.html ) -Ilari From nobody Tue Jun 23 11:51: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 0D03D1A0338 for ; Tue, 23 Jun 2015 11:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 4gqnfC4LveIN for ; Tue, 23 Jun 2015 11:51:43 -0700 (PDT) Received: from emh03.mail.saunalahti.fi (emh03.mail.saunalahti.fi [62.142.5.109]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2BBF1A024E for ; Tue, 23 Jun 2015 11:51:42 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id 61CC7188776; Tue, 23 Jun 2015 21:51:41 +0300 (EEST) Date: Tue, 23 Jun 2015 21:51:41 +0300 From: Ilari Liusvaara To: Yoav Nir Message-ID: <20150623185141.GA20677@LK-Perkele-VII> References: <3FCBCBD5-9295-4A8D-BD27-71377B6B8E7C@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3FCBCBD5-9295-4A8D-BD27-71377B6B8E7C@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: IETF TLS Working Group Subject: Re: [TLS] WG adoption + early code point assignment: draft-mavrogiannopoulos-chacha-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: Tue, 23 Jun 2015 18:51:44 -0000 On Wed, May 20, 2015 at 12:51:40AM +0300, Yoav Nir wrote: > 2) I question the need for TLS_DHE_ ciphersuites, and I seriously doubt > anybody’s going to use those with ChaCha20 “in the wild”. Can you expand on that (I found that comment strange)? The possiblities that come to mind are: a) That was a typo for TLS_RSA_ (which isn't FS) b) Actually both TLS_DHE_ and TLS_RSA_, since whatever considers supporting Chacha20 supports ECDHE already (or it just does pure-PSK), and that's superrior to both. c) Something else. -Ilari From nobody Tue Jun 23 13:22: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 1A52C1B3086 for ; Tue, 23 Jun 2015 13:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JkMFTuTZYf7Q for ; Tue, 23 Jun 2015 13:22:07 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::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 73CCE1B3081 for ; Tue, 23 Jun 2015 13:22:07 -0700 (PDT) Received: by wicnd19 with SMTP id nd19so116397226wic.1 for ; Tue, 23 Jun 2015 13:22:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fSqAXw4rsGdfyotqixQHud5WVQhSxULzrLNX42Yx+JI=; b=sGEDV6sskbhZgYf0HUMKAYxvYp0XJ1dDM0B267n6KhJkzAY3zhDkBWUyxE9fa23teh htoySc3EfF9wnc7xCZn+Aket/IsEq7yVEwEu1u3pfnHdZA7m918Mpkb8lwWqTkoWAmT4 Jbm0algBeYYAVgKPjhQzas1EvlAl1OPDCq+qJ2Hayp/lbyAHBMDFuuTHjaNA7FaCoxIP dp9dXdyasK40LgiEy2Cex562cd2Oh8WwvyMYGKF0rAe3fyB8NpaF6jTVtXX70NOCqG6n R3XPXA4d9AsMaJeTEgIOc+PnTdelVAkpoLa47COrZF3ApL06dypA6YlMELgL6pMrFSz9 mzag== X-Received: by 10.194.179.167 with SMTP id dh7mr63248564wjc.15.1435090926199; Tue, 23 Jun 2015 13:22:06 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id ha4sm925791wib.0.2015.06.23.13.21.55 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Jun 2015 13:21:55 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Yoav Nir In-Reply-To: <20150623185141.GA20677@LK-Perkele-VII> Date: Tue, 23 Jun 2015 23:21:53 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <79998D45-BF29-4261-968A-185931187DE2@gmail.com> References: <3FCBCBD5-9295-4A8D-BD27-71377B6B8E7C@gmail.com> <20150623185141.GA20677@LK-Perkele-VII> To: Ilari Liusvaara X-Mailer: Apple Mail (2.2098) Archived-At: Cc: IETF TLS Working Group Subject: Re: [TLS] WG adoption + early code point assignment: draft-mavrogiannopoulos-chacha-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: Tue, 23 Jun 2015 20:22:09 -0000 > On Jun 23, 2015, at 9:51 PM, Ilari Liusvaara = wrote: >=20 > On Wed, May 20, 2015 at 12:51:40AM +0300, Yoav Nir wrote: >=20 >> 2) I question the need for TLS_DHE_ ciphersuites, and I seriously = doubt >> anybody=E2=80=99s going to use those with ChaCha20 =E2=80=9Cin the = wild=E2=80=9D. >=20 > Can you expand on that (I found that comment strange)? The = possiblities > that come to mind are: >=20 > a) That was a typo for TLS_RSA_ (which isn't FS) > b) Actually both TLS_DHE_ and TLS_RSA_, since whatever considers > supporting Chacha20 supports ECDHE already (or it just does = pure-PSK), > and that's superrior to both. > c) Something else. No, I actually meant DHE. DHE is hardly used. Any cryptographic library = new enough to support ChaCha20 will also support ECDHE, which is faster = than DHE and does not have the baggage of interoperability with legacy = implementations that only support 1024 bits. I thought that we should just deprecate DHE and not even do the = negotiated-ff-dhe draft. The group thought differently, but pairing this = legacy key exchange with a new cipher looks strange to me.=20 Yoav= From nobody Tue Jun 23 14:05: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 7BC111A09C9 for ; Tue, 23 Jun 2015 14:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHVWeqPb4O8B for ; Tue, 23 Jun 2015 14:05:21 -0700 (PDT) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (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 E3BD81A0451 for ; Tue, 23 Jun 2015 14:05:20 -0700 (PDT) Received: by obctg8 with SMTP id tg8so14505177obc.3 for ; Tue, 23 Jun 2015 14:05:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=3MQO6teGF4iPefY9CiKv2NwSLOLlR68pSTmPv6cidgE=; b=y8vI3g7QN6j1X1eO3nJyY84RSnVMO0gPlE5NXnhaWziDGeBxUTZSzz5MAU+2OlRm6m aSIwlNwDb4/iRUU3Y3S8XCCLKiDaLAS8In6272y68RF5+otEHziSsWYVTLsCwrE98uk7 hoDxx0ugeAzZyTJdmBgIVRodbSFJPP07EVJLzfQ1AtofGrQ/fWFlY+Zbh5TNQg2rOwp9 DmDsIrfILyN9S2JaIAflrQHkq6n+IlFOW/ir/CdApSZrHVRSr8veaMkto7VaVy1rKFLw qzZnjeyuVTgvZHyzSlueRdsddAO1vM63c5qzmmkPx4bA+ViREs1p+xg2klMoLrznbRgn 18ag== X-Received: by 10.202.210.148 with SMTP id j142mr29617576oig.68.1435093520281; Tue, 23 Jun 2015 14:05:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.113.142 with HTTP; Tue, 23 Jun 2015 14:05:00 -0700 (PDT) In-Reply-To: <79998D45-BF29-4261-968A-185931187DE2@gmail.com> References: <3FCBCBD5-9295-4A8D-BD27-71377B6B8E7C@gmail.com> <20150623185141.GA20677@LK-Perkele-VII> <79998D45-BF29-4261-968A-185931187DE2@gmail.com> From: Tony Arcieri Date: Tue, 23 Jun 2015 14:05:00 -0700 Message-ID: To: Yoav Nir Content-Type: multipart/alternative; boundary=001a113d2bf87ef702051935bfab Archived-At: Cc: IETF TLS Working Group Subject: Re: [TLS] WG adoption + early code point assignment: draft-mavrogiannopoulos-chacha-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: Tue, 23 Jun 2015 21:05:22 -0000 --001a113d2bf87ef702051935bfab Content-Type: text/plain; charset=UTF-8 On Tue, Jun 23, 2015 at 1:21 PM, Yoav Nir wrote: > No, I actually meant DHE. DHE is hardly used. Any cryptographic library > new enough to support ChaCha20 will also support ECDHE, which is faster > than DHE and does not have the baggage of interoperability with legacy > implementations that only support 1024 bits. > > I thought that we should just deprecate DHE and not even do the > negotiated-ff-dhe draft. I'll just reiterate I'm +1 with you. -- Tony Arcieri --001a113d2bf87ef702051935bfab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jun 23, 2015 at 1:21 PM, Yoav Nir <ynir.ietf@gmail.com> wrote:
No, I actually meant DHE. DHE is= hardly used. Any cryptographic library new enough to support ChaCha20 will= also support ECDHE, which is faster than DHE and does not have the baggage= of interoperability with legacy implementations that only support 1024 bit= s.

I thought that we should just deprecate DHE and not even do the negotiated-= ff-dhe draft.

I'll just reiterate I'= ;m +1 with you.=C2=A0

--
Tony Arcieri
--001a113d2bf87ef702051935bfab-- From nobody Wed Jun 24 04:54: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 4CB9D1A891C for ; Wed, 24 Jun 2015 04:53:59 -0700 (PDT) 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 iYO5TgJK6nzg for ; Wed, 24 Jun 2015 04:53:57 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB6401A891B for ; Wed, 24 Jun 2015 04:53:57 -0700 (PDT) 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 (Postfix) with ESMTPS id 0EDC52B9DE9; Wed, 24 Jun 2015 11:53:56 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-121.brq.redhat.com [10.34.0.121]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t5OBrsxl019744 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 24 Jun 2015 07:53:55 -0400 From: Hubert Kario To: tls@ietf.org Date: Wed, 24 Jun 2015 13:53:49 +0200 Message-ID: <3039391.7h1HagpxET@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.7 (Linux/4.0.4-202.fc21.x86_64; KDE/4.14.7; x86_64; ; ) In-Reply-To: <79998D45-BF29-4261-968A-185931187DE2@gmail.com> References: <20150623185141.GA20677@LK-Perkele-VII> <79998D45-BF29-4261-968A-185931187DE2@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2409185.SyiTynOQmb"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: Subject: Re: [TLS] WG adoption + early code point assignment: draft-mavrogiannopoulos-chacha-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, 24 Jun 2015 11:53:59 -0000 --nextPart2409185.SyiTynOQmb Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Tuesday 23 June 2015 23:21:53 Yoav Nir wrote: > > On Jun 23, 2015, at 9:51 PM, Ilari Liusvaara > > wrote:>=20 > > On Wed, May 20, 2015 at 12:51:40AM +0300, Yoav Nir wrote: > >> 2) I question the need for TLS_DHE_ ciphersuites, and I seriously = doubt > >> anybody=E2=80=99s going to use those with ChaCha20 =E2=80=9Cin the= wild=E2=80=9D. > >=20 > > Can you expand on that (I found that comment strange)? The possibli= ties > > that come to mind are: > >=20 > > a) That was a typo for TLS_RSA_ (which isn't FS) > > b) Actually both TLS_DHE_ and TLS_RSA_, since whatever considers > >=20 > > supporting Chacha20 supports ECDHE already (or it just does pure-= PSK), > > and that's superrior to both. > >=20 > > c) Something else. >=20 > No, I actually meant DHE. DHE is hardly used. Any cryptographic libra= ry new > enough to support ChaCha20 will also support ECDHE, which is faster t= han > DHE and does not have the baggage of interoperability with legacy > implementations that only support 1024 bits. >=20 > I thought that we should just deprecate DHE and not even do the > negotiated-ff-dhe draft. The group thought differently, but pairing t= his > legacy key exchange with a new cipher looks strange to me. If we go the route of negotiating the KEX separately from bulk cipher i= n=20 TLSv1.3, you'll have DHE with ChaCha20 in TLSv1.3. So you'll remove it only from TLSv1.2 and lower. =2D-=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 --nextPart2409185.SyiTynOQmb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJVippRAAoJEJKo0bgB0vX1CiEQAJAb2WQXpCTOWpvfbv8OfwcD bazR55JnQpfStn8my9VMORngxVuyunkYEPwdQZjQfN33fbdIsbLTAo9GYi6fcsR6 8BqY9VktdqkHcq/hxhgf6nUViGUwJlcTzrzPgZq5UdtLxz6w08WuaXjMLCGnAr8I YnC5pjTSaaBm+NdnB7NBsC03o96BMXIWKABwKzIBqiviXpW4MldZ49x6RqeMakZd GFGtVBp7j3dvs6cS0ZyzwDJf3HyY4eeFKmp5rQzMj5rCcym3G+ViIjdo+nM+5SwE 6NxaW1R8ULKonoHinqQU8zz52z1wlu422dfPvtTaKI73nEwWa1TKSBdZIjFlJNZ5 +UMpU3Os02iQN0rkeBhOBMpvC9moz/YDWIY4MjLa7H+PMQNJ8aV/9AUV6e3fsK++ ae5sXyHRwoKaUcaG+06S3737re+a8IfWnEk/bZrE0Vj2qBAQNE9QmoDXOOg3PgE+ XVi94Xg0M7zeEJOjoIOKJLiCedFArmD8ALFnGWgpnBYtHIy31B57TzojaFzWSny8 n4Cl9X8yCzkdaCluMS7VxPdw9F/t9RiZc5lHJFKLbnfMwbTGVCOrXRF8YnH5hDX5 Z48S1JA8ZcZcRI1EVVEA+Bn2MY8dXLBzczHL8cMU9Fg+aSLlhyV7J34lnl2rsVnv R8SAOBdRSyQ/nDOU+Ml9 =/H5N -----END PGP SIGNATURE----- --nextPart2409185.SyiTynOQmb-- From nobody Thu Jun 25 10: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 CC88D1A8AA5 for ; Thu, 25 Jun 2015 10:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.167 X-Spam-Level: X-Spam-Status: No, score=-0.167 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 sHBZVLXZpIwR for ; Thu, 25 Jun 2015 10:50:39 -0700 (PDT) Received: from gateway07.websitewelcome.com (gateway07.websitewelcome.com [69.56.236.22]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 662701A1B64 for ; Thu, 25 Jun 2015 10:50:04 -0700 (PDT) Received: by gateway07.websitewelcome.com (Postfix, from userid 5007) id 98465AB840BBA; Thu, 25 Jun 2015 12:50:03 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway07.websitewelcome.com (Postfix) with ESMTP id 87D64AB840B75 for ; Thu, 25 Jun 2015 12:50:03 -0500 (CDT) Received: from [204.42.252.17] (port=54840 helo=[5.5.33.215]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Z8BHm-000167-U3; Thu, 25 Jun 2015 12:50:03 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner Date: Thu, 25 Jun 2015 14:49:56 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <0D3AFCB8-C84E-4817-8E15-BDA5F5B8AB70@ieca.com> References: <20150619232740.1236.55980.idtracker@ietfa.amsl.com> To: "" 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: 204.42.252.17 X-Exim-ID: 1Z8BHm-000167-U3 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([5.5.33.215]) [204.42.252.17]:54840 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 4 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Subject: [TLS] Fwd: IETF 93 Preliminary Agenda X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 25 Jun 2015 17:50:40 -0000 FYI Begin forwarded message: > From: IETF Agenda > Subject: IETF 93 Preliminary Agenda > Date: June 19, 2015 at 20:27:40 GMT-3 > To: "Working Group Chairs" > Cc: irsg@irtf.org > Reply-To: IETF Agenda >=20 >=20 > The IETF 93 preliminary agenda has been posted. The final agenda will = be published on Friday, June 26th, 2015. =20 >=20 > If you would like to request a change to the preliminary agenda, = please send a message to agenda@ietf.org and copy all relevant Area = Directors. >=20 > Please note the cut-off date for requests to reschedule Working Group = sessions and BOFs is Wednesday, June 24th, 2015 at UTC 23:59. >=20 > https://datatracker.ietf.org/meeting/93/agenda.html > https://datatracker.ietf.org/meeting/93/agenda.txt >=20 > Thank you! >=20 > IETF Secretariat >=20 From nobody Thu Jun 25 13:48: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 68D8B1B29CE; Thu, 25 Jun 2015 13:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.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, 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 IQ13SRsJQHKC; Thu, 25 Jun 2015 13:48:56 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id F09CE1B29A5; Thu, 25 Jun 2015 13:48:55 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 15BEF180452; Thu, 25 Jun 2015 13:46:01 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20150625204601.15BEF180452@rfc-editor.org> Date: Thu, 25 Jun 2015 13:46:01 -0700 (PDT) Archived-At: Cc: tls@ietf.org, rfc-editor@rfc-editor.org Subject: [TLS] RFC 7568 on Deprecating Secure Sockets Layer Version 3.0 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 25 Jun 2015 20:48:57 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7568 Title: Deprecating Secure Sockets Layer Version 3.0 Author: R. Barnes, M. Thomson, A. Pironti, A. Langley Status: Standards Track Stream: IETF Date: June 2015 Mailbox: rlb@ipv.sx, martin.thomson@gmail.com, alfredo@pironti.eu, agl@google.com Pages: 7 Characters: 13489 Updates: RFC 5246 I-D Tag: draft-ietf-tls-sslv3-diediedie-03.txt URL: https://www.rfc-editor.org/info/rfc7568 DOI: http://dx.doi.org/10.17487/RFC7568 The Secure Sockets Layer version 3.0 (SSLv3), as specified in RFC 6101, is not sufficiently secure. This document requires that SSLv3 not be used. The replacement versions, in particular, Transport Layer Security (TLS) 1.2 (RFC 5246), are considerably more secure and capable protocols. This document updates the backward compatibility section of RFC 5246 and its predecessors to prohibit fallback to SSLv3. This document is a product of the Transport Layer Security Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu Jun 25 14:04: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 8A05D1B29F8 for ; Thu, 25 Jun 2015 14:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l4J9gxKYNhoK for ; Thu, 25 Jun 2015 14:04:32 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::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 40C901B29F7 for ; Thu, 25 Jun 2015 14:04:32 -0700 (PDT) Received: by ieqy10 with SMTP id y10so63272388ieq.0 for ; Thu, 25 Jun 2015 14:04:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=2oGPi9DbhXdx5Fbx5mdZMLz3DecIDACp+UZ594w7Aeg=; b=0gQQI0FhmxRzWemxeALCnUqBd6sYDUFCw/35swV33Ib+BRLdjBhyBl8WgEY+HlCBT6 aKKGbwLkBKYcoCF1BgH6LBFhMkGTDgUkimDXqOg3Fs5XGPbDTsI3m669oC2gWPvzIoYA LqqhgzcpFpo3xQQ9DTBefT3g74XhQJMpAj2t9yHr0nu9VYqR73yOuH+qyepjfpXo3zLb gk1bzYJDh8ssecDB2X2Ws0K0GWqp8JX7AB50Lo+cqOIy3RFIOwTOohfxwXUYfnm3OHM0 IgUku45KSup7g/zAWEwy0Z550dxa/Ut52I6O5cgUejPAyloD5KvQxnP21cRqjrjJsbEU 4FlA== MIME-Version: 1.0 X-Received: by 10.107.25.15 with SMTP id 15mr3341193ioz.11.1435266271560; Thu, 25 Jun 2015 14:04:31 -0700 (PDT) Received: by 10.36.77.15 with HTTP; Thu, 25 Jun 2015 14:04:31 -0700 (PDT) Date: Thu, 25 Jun 2015 17:04:31 -0400 Message-ID: From: Jeffrey Walton To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [TLS] Origin Bound Certificates extension? 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, 25 Jun 2015 21:04:33 -0000 Forgive my ignorance... What happened with the Origin Bound Certificates extension (https://tools.ietf.org/html/draft-balfanz-tls-obc-01)? From nobody Thu Jun 25 14:06: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 D826B1A7001 for ; Thu, 25 Jun 2015 14:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 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, 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 ytyjfz3J7boO for ; Thu, 25 Jun 2015 14:06:08 -0700 (PDT) Received: from mail-vn0-x236.google.com (mail-vn0-x236.google.com [IPv6:2607:f8b0:400c:c0f::236]) (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 C38471A8025 for ; Thu, 25 Jun 2015 14:06:08 -0700 (PDT) Received: by vnav203 with SMTP id v203so12904675vna.6 for ; Thu, 25 Jun 2015 14:06:08 -0700 (PDT) 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; bh=9xcYnFb3RLfg/SJJSlI0fDEK4jqDf54M96EbSdIGqxk=; b=OTf09JvOLDtAP5AyUsssSjmVE/xXZu64XUvu+fyiYQFZesnO2DeHZAl5ugN4PxnxEe fAd6RPeFwkda5pGBq51LQdfftuxa5vhE+G2D/MNhUAkf3/UjqjA/4RjjHRroLaU8rl1g aFJIaK93pNPQKr2v8crYwCqaSkFvIot2PeaMkoqR3ENbvjR5wiH26xZ4yZ0DzlRRu4WR 6k3zQkrqZUF83aJBNxEQwt8ilh5jMhl5ma8aEr7ng5utjfabY8wFi6kfG72FePWANtsi 3wlGfLfc5nh7lhnGkJf2QbtIKOSiIVd836ZnEi7E0qK+/FqZ1hn0IA4gY4XFxfRUbuBG OW9Q== 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=9xcYnFb3RLfg/SJJSlI0fDEK4jqDf54M96EbSdIGqxk=; b=VKfN7sKlKGtRaHLULgdhkKX9hFAodlNuE2YVDoWnLUi7BuVv6eNBjyS8gI9DdwBhYO UIcQDHtw1Yd6Hlku5SQvuSKnSsUgTE25WBN0xa9+ylYSYLw3PzdDmRhlb6/TqFYWRdhR N2Tgl96x2Hb+NsmUtj+2uKU2lLKr72ywil9L+nKIa95nGwQDbI7TtDtEPUJ3mNuJFcId u3wlzdhsNkJakA7AUE/YLeiSq9sSNthECysvrbZ9YIeRfb038V+smbe/r7+CXpUvenkl oGpFkZsXcfQ/kqBorYBjP3D+HKAAtTCcULGZ3JxvhjyuU0zcH+duMYsg7oy00fF6CknX xLiA== X-Gm-Message-State: ALoCoQmkJvfwKnHT2h8u4q/i3g8toQuQ/72g1irCRs7wR0a8zYPa/B26oCs587lNQd12GwTF7BCH X-Received: by 10.52.71.203 with SMTP id x11mr43720584vdu.48.1435266367944; Thu, 25 Jun 2015 14:06:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.67.150 with HTTP; Thu, 25 Jun 2015 14:05:45 -0700 (PDT) In-Reply-To: References: From: Adam Langley Date: Thu, 25 Jun 2015 14:05:45 -0700 Message-ID: To: noloader@gmail.com Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Origin Bound Certificates 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: Thu, 25 Jun 2015 21:06:10 -0000 On Thu, Jun 25, 2015 at 2:04 PM, Jeffrey Walton wrote: > Forgive my ignorance... What happened with the Origin Bound > Certificates extension > (https://tools.ietf.org/html/draft-balfanz-tls-obc-01)? It evolved into https://tools.ietf.org/html/draft-ietf-tokbind-protocol-01 Cheers AGL From nobody Thu Jun 25 16:46: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 A4CF41B2D12 for ; Thu, 25 Jun 2015 16:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id grFd1flTs0hS for ; Thu, 25 Jun 2015 16:46:31 -0700 (PDT) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001: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 5B0031A89B9 for ; Thu, 25 Jun 2015 16:46:31 -0700 (PDT) Received: by igin14 with SMTP id n14so3012621igi.1 for ; Thu, 25 Jun 2015 16:46:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=mb4D7M8+81hgM/HrnRa0moxKuSKCQIAJJOQ+OynRT2E=; b=kRoTVGGrSZb34xgZqTsF6KOWEZQtsuJt2Nayn8BIFqrEXgxzyUGF1t22BPKMNxvQIg yaiBpK5Ltqkxz2lDY7By6syoh1Y83JSc7TXz7a39yF4k5zx7s4fYpqWRBDucvGUKwVw8 4P2kfjBqj0Ei03NBm7gV1RcOOUuLQn+IBk7jXLT+0wJ0iORVTn/kIvH2nXywOZMgIVDU 5oNWgxQW9PFy0SAmxJwveulFf6He00MnYgCkZ/TSyrvrG0mxESJRVKbso3641RYXig8T b2YC8nm3y4gdTKBMS3ptW5yaKGVANYjGcoEfg7NlTOQs8IPct5bvaHr6tvdxd3yJ+oLy zQSA== MIME-Version: 1.0 X-Received: by 10.42.176.8 with SMTP id bc8mr196467icb.22.1435275990823; Thu, 25 Jun 2015 16:46:30 -0700 (PDT) Received: by 10.36.77.15 with HTTP; Thu, 25 Jun 2015 16:46:30 -0700 (PDT) In-Reply-To: References: Date: Thu, 25 Jun 2015 19:46:30 -0400 Message-ID: From: Jeffrey Walton To: Adam Langley Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Origin Bound Certificates extension? 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, 25 Jun 2015 23:46:32 -0000 On Thu, Jun 25, 2015 at 5:05 PM, Adam Langley wrote: > On Thu, Jun 25, 2015 at 2:04 PM, Jeffrey Walton wrote: >> Forgive my ignorance... What happened with the Origin Bound >> Certificates extension >> (https://tools.ietf.org/html/draft-balfanz-tls-obc-01)? > > It evolved into https://tools.ietf.org/html/draft-ietf-tokbind-protocol-01 > Perfect, thanks. Any plans to support Bernstein's gear: ... enum { rsa(1), ecdsap256(3), (255) } SignatureAlgorithm; ... enum { secp256r1 (23), (0xFFFF) } NamedCurve; Should there be a ed25519 or similar? To be clear, I'm interested in using it to stop MitM due to gaps in existing controls in some security models, and not stop the triple handshake threat. Jeff From nobody Thu Jun 25 16:49: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 B4FF21B2D1E for ; Thu, 25 Jun 2015 16:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 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, 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 lVKrizf_h4rN for ; Thu, 25 Jun 2015 16:49:19 -0700 (PDT) Received: from mail-vn0-x235.google.com (mail-vn0-x235.google.com [IPv6:2607:f8b0:400c:c0f::235]) (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 C59DC1B2D1D for ; Thu, 25 Jun 2015 16:49:18 -0700 (PDT) Received: by vnbf7 with SMTP id f7so13378161vnb.7 for ; Thu, 25 Jun 2015 16:49:18 -0700 (PDT) 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; bh=qdrexhJ/SkpJWhHSg9FfYWRGW6tZIiQW3GV7jIyJDnk=; b=cvsSbxQuefvOp5BX0YmbCVZexkgq2uXXtRW/Hy4ngSv9lmd8tvX9y82Cv2zNMmwqBp IP3CzTKYCiwwTHqPZHkFVaDpjZ8gJWIDmz3dX8ofgtS3GGtnj9DWWcZE8paL4A8FbAeA pJT0ljQC4httgJVghFMmjt2ICZth9vk+gZ4dDcJrUNKludBxZQB8fgsul1J9A/kCrnrs xC1hKjnmwNbv0Ac5HY7v7gFu8dPjUgTieOG7bqIsjDgw0iGY5DGlwW0FbHesk4Uf8GTB Mdw0UKY/enYq3Htu/z+HdNgFtbwOnAOv7ZG25Hrb56ublZpmjRmCL5LxkH5iopj4G6fR IUAg== 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=qdrexhJ/SkpJWhHSg9FfYWRGW6tZIiQW3GV7jIyJDnk=; b=OcpnoGZ+ECgKio9Gj1w1hlpMSwiygjyera/XpQFhDMaVT7m+ilMtJ0lvmlTxDgPVPo Gw1MlZhOgYuewTn6+IwXLT4TMmr1VZ0/zneTkfnizoy3o6OVIJRtC7aSp0uPvvaMSj1j IT2QgNZNtbavi4DlOSLM1mmqCTKgrt45/0Cj3+wjrwNioDa1Kd2BCH6byE3dNb7BL+b3 R7cMhUoTpeMydSL5mW/xnmCYKqCEOVtwVfNRza0ty8CSFJMJT2lcZFSwzRjB4DCTaLY8 0R597uUUNW4M1xoDweQK0nvl2VwBqO2vQbN/CRU06siVvComUBt2NWM1nymEsW0DB9DI Gtkw== X-Gm-Message-State: ALoCoQlbPizycJrLOktDUC4lwAm2QjcbeDpmC+qfR3DgrRy7+n2a/usfogXO6TJ7E7kXXEJo3epl X-Received: by 10.52.179.73 with SMTP id de9mr38309857vdc.28.1435276157998; Thu, 25 Jun 2015 16:49:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.67.150 with HTTP; Thu, 25 Jun 2015 16:48:55 -0700 (PDT) In-Reply-To: References: From: Adam Langley Date: Thu, 25 Jun 2015 16:48:55 -0700 Message-ID: To: noloader@gmail.com Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Origin Bound Certificates 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: Thu, 25 Jun 2015 23:49:19 -0000 On Thu, Jun 25, 2015 at 4:46 PM, Jeffrey Walton wrote: > Should there be a ed25519 or similar? When CFRG kick out a signature scheme I expect that would be a very good candidate for inclusion. (Although CFRG will not be standardising Ed25519 based on current discussions.) Cheers AGL From nobody Thu Jun 25 19:04: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 CD2771B3178 for ; Thu, 25 Jun 2015 19:04:08 -0700 (PDT) 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 MMTyTxXs1SQE for ; Thu, 25 Jun 2015 19:04:08 -0700 (PDT) Received: from homiemail-a112.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id EF8FE1B3175 for ; Thu, 25 Jun 2015 19:04:07 -0700 (PDT) Received: from homiemail-a112.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a112.g.dreamhost.com (Postfix) with ESMTP id A9CC52005E80D; Thu, 25 Jun 2015 19:04:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=c1p4Ko7YenLQCeXWUy8wArb0Jxo=; b=ji8P81czrRPmc1TDD K5ey3h9PjzUvg6aYVFezW5ruOaMliYjcB01JyF1xWY+yElUbAzr1LIp14JBZcH+s Yjzz5rWGI9izoMvgHsArhuY1Y6RC0zhElI0iNsNQPk3QXl8wwZlQbLfF2dZRigoz fPbwDjL6o2eSchXmdm///N/sGc= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a112.g.dreamhost.com (Postfix) with ESMTPA id 41C612005E809; Thu, 25 Jun 2015 19:04:07 -0700 (PDT) Received: from 46.140.104.238 (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Thu, 25 Jun 2015 19:04:06 -0700 Message-ID: In-Reply-To: References: Date: Thu, 25 Jun 2015 19:04:06 -0700 From: "Ryan Sleevi" To: noloader@gmail.com User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Origin Bound Certificates extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ryan-ietftls@sleevi.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, 26 Jun 2015 02:04:09 -0000 On Thu, June 25, 2015 4:46 pm, Jeffrey Walton wrote: > Should there be a ed25519 or similar? You should ask the WG that is working on the draft, which is the tokbind WG, not the tls WG. http://datatracker.ietf.org/wg/tokbind/charter/ From nobody Fri Jun 26 01:50: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 746551A0276 for ; Fri, 26 Jun 2015 01:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 8BvEeZQ3Vafa for ; Fri, 26 Jun 2015 01:50:16 -0700 (PDT) Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 339691A0469 for ; Fri, 26 Jun 2015 01:50:12 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id 91BA01A2655; Fri, 26 Jun 2015 11:50:09 +0300 (EEST) Date: Fri, 26 Jun 2015 11:50:09 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20150626085008.GA25187@LK-Perkele-VII> References: <2AA11887-2F82-48EF-BD45-4D85CFA83847@qut.edu.au> <20150617082529.GA17280@LK-Perkele-VII> <20150617150505.GA19959@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Computation of static secret in anonymous 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, 26 Jun 2015 08:50:21 -0000 On Wed, Jun 17, 2015 at 09:35:14AM -0700, Eric Rescorla wrote: > On Wed, Jun 17, 2015 at 8:05 AM, Ilari Liusvaara < > ilari.liusvaara@elisanet.fi> wrote: > > > On Wed, Jun 17, 2015 at 05:56:23AM -0700, Eric Rescorla wrote: > > > On Wed, Jun 17, 2015 at 1:25 AM, Ilari Liusvaara < > > > ilari.liusvaara@elisanet.fi> wrote: > > > > > > > There's much newer version in ekr/tls13-spec#WIP_draft_06 > > > > (seems to have fixed most of the mistakes in the original WIP) > > > > > > > > > > Don't worry, I'm sure there are plenty of mistakes left! > > > > Such as how keys for TLS exporters are derived? > > Quite possibly. Hence the WIP designation. > Reviewing it again after changes (e1219310a7f, Jun 25th): 1) xSS is used as direct input to HKDF-Expand, so one would presume it should be HKDF-Extract output (AFAIK, HKDF-Extract and HKDF-Expand are supposed to be paired). HKDF-Extract does not take label nor length. 2) Same as above for xES. 3) Same as above for master_secret. 4) Why does master_secret derivation take xSS and xES instead of SS and ES directly (especially if xSS and xES are supposed to be HKDF-Extract outputs)? 4) Why is finished independent of ES (IIRC, it did depend on it in earlier version)? 5) Application data uses xES as secret. AFAICT, leads to an attack. Should be master_secret (IIRC, was that way in earlier version)? 6) I think the key table should refer to inputs by their proper names, not e.g. referring to "xES" as "ES" when there is another thing named "ES" (that's confusing even with a note). 7) I think there should be helper function defined to do the label zero-padding, instead of it being just a note (just for clarity). -Ilari From nobody Fri Jun 26 05:56: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 C0BF51B2D61 for ; Fri, 26 Jun 2015 05:56:05 -0700 (PDT) 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 YQPu2BA8rn-J for ; Fri, 26 Jun 2015 05:56:04 -0700 (PDT) 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 2F61B1B2DAB for ; Fri, 26 Jun 2015 05:56:02 -0700 (PDT) Received: by wiwl6 with SMTP id l6so44749848wiw.0 for ; Fri, 26 Jun 2015 05:56:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Q2/mqb2ZtZLO8KrPd1K02Hu8Gzd8t3X9WDOodjjcfJo=; b=B0F4owAtxOexCT27OCxMGug1/4KDxI2722WC0gTmH8sH3dKeBx/pQALBsq33GR2Ipn FALa7iP/7NYTLAjoQt7wgmHlucQGU0KZ/xxEzh4TFpQ44knQWaxXVUQclEZRpJ5exyFV O7TRxzqrz85HnW0QICHtZDGurO0hxKvVyXmYO8jrcTD96M7WaH58Pz4RlMBqU5g7vylF 4JKnCx3Bm1qhyWnnMyBL6MalzFksutXVOZE4eXgvaRzlX2PW8H/vrgbIaa+02rKCGIgN CXI96v0pWwnQmFQGFdcpkteEpyb2dnanyvU92RtgBwtBz4pdcmfbEouE0kHfls7vl26X SeRw== X-Gm-Message-State: ALoCoQlYIJjA183/XWI4/PBaPZok6gSxDYlvMV3+E7ImYV/NWsJmmpgdLxMaT/prSiq8TznTLxqi X-Received: by 10.194.133.73 with SMTP id pa9mr2819500wjb.148.1435323360872; Fri, 26 Jun 2015 05:56:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.95.211 with HTTP; Fri, 26 Jun 2015 05:55:21 -0700 (PDT) In-Reply-To: <20150626085008.GA25187@LK-Perkele-VII> References: <2AA11887-2F82-48EF-BD45-4D85CFA83847@qut.edu.au> <20150617082529.GA17280@LK-Perkele-VII> <20150617150505.GA19959@LK-Perkele-VII> <20150626085008.GA25187@LK-Perkele-VII> From: Eric Rescorla Date: Fri, 26 Jun 2015 05:55:21 -0700 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=089e011771a91044fc05196b43b1 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Computation of static secret in anonymous 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, 26 Jun 2015 12:56:05 -0000 --089e011771a91044fc05196b43b1 Content-Type: text/plain; charset=UTF-8 On Fri, Jun 26, 2015 at 1:50 AM, Ilari Liusvaara < ilari.liusvaara@elisanet.fi> wrote: > On Wed, Jun 17, 2015 at 09:35:14AM -0700, Eric Rescorla wrote: > > On Wed, Jun 17, 2015 at 8:05 AM, Ilari Liusvaara < > > ilari.liusvaara@elisanet.fi> wrote: > > > > > On Wed, Jun 17, 2015 at 05:56:23AM -0700, Eric Rescorla wrote: > > > > On Wed, Jun 17, 2015 at 1:25 AM, Ilari Liusvaara < > > > > ilari.liusvaara@elisanet.fi> wrote: > > > > > > > > > There's much newer version in ekr/tls13-spec#WIP_draft_06 > > > > > (seems to have fixed most of the mistakes in the original WIP) > > > > > > > > > > > > > Don't worry, I'm sure there are plenty of mistakes left! > > > > > > Such as how keys for TLS exporters are derived? > > > > Quite possibly. Hence the WIP designation. > > > > Reviewing it again after changes (e1219310a7f, Jun 25th): > > 1) xSS is used as direct input to HKDF-Expand, so one would presume > it should be HKDF-Extract output (AFAIK, HKDF-Extract and HKDF-Expand > are supposed to be paired). HKDF-Extract does not take label nor > length. > > 2) Same as above for xES. > > 3) Same as above for master_secret. > > 4) Why does master_secret derivation take xSS and xES instead of > SS and ES directly (especially if xSS and xES are supposed to be > HKDF-Extract outputs)? > > 4) Why is finished independent of ES (IIRC, it did depend on it > in earlier version)? > i'm going to refer these to Hugo, as they were his suggestion. > 5) Application data uses xES as secret. AFAICT, leads to an attack. > Should be master_secret (IIRC, was that way in earlier version)? > This is a typo. Will fix. Remember, this is a WIP branch. :) With that said, I'd be interested in hearing what the attack is. 6) I think the key table should refer to inputs by their proper > names, not e.g. referring to "xES" as "ES" when there is another > thing named "ES" (that's confusing even with a note). > Typo. Willdo. 7) I think there should be helper function defined to do the > label zero-padding, instead of it being just a note (just for > clarity). Hmm... Can you suggest text? Do you think we should do this for the signature context as well? -Ekr > > -Ilari > --089e011771a91044fc05196b43b1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jun 26, 2015 at 1:50 AM, Ilari Liusvaara <= ilari.lius= vaara@elisanet.fi> wrote:
<= span>On Wed, Jun 17, 2015 at 09:35:14AM -0700, Eric Rescorla wrote:
> On Wed, Jun 17, 2015 at 8:05 AM, Ilari Liusvaara <
> ilari= .liusvaara@elisanet.fi> wrote:
>
> > On Wed, Jun 17, 2015 at 05:56:23AM -0700, Eric Rescorla wrote: > > > On Wed, Jun 17, 2015 at 1:25 AM, Ilari Liusvaara <
> > > ilari.liusvaara@elisanet.fi> wrote:
> > >
> > > > There's much newer version in ekr/tls1= 3-spec#WIP_draft_06
> > > > (seems to have fixed most of the mistakes in the origin= al WIP)
> > > >
> > >
> > > Don't worry, I'm sure there are plenty of mistakes l= eft!
> >
> > Such as how keys for TLS exporters are derived?
>
> Quite possibly. Hence the WIP designation.
>

Reviewing it again after changes (e1219310a7f, Jun 25th):

1) xSS is used as direct input to HKDF-Expand, so one would presume
it should be HKDF-Extract output (AFAIK, HKDF-Extract and HKDF-Expand
are supposed to be paired). HKDF-Extract does not take label nor
length.

2) Same as above for xES.

3) Same as above for master_secret.

4) Why does master_secret derivation take xSS and xES instead of
SS and ES directly (especially if xSS and xES are supposed to be
HKDF-Extract outputs)?

4) Why is finished independent of ES (IIRC, it did depend on it
in earlier version)?

i'm going to r= efer these to Hugo, as they were his suggestion.

= =C2=A0
5) Application data uses xES as secret. AFAICT, leads to an attack.
Should be master_secret (IIRC, was that way in earlier version)?

This is a typo. Will fix.=C2=A0 Remember, this is= a WIP branch. :)

With that said, I'd be inter= ested in hearing what the attack is.


6) I think the key table should refer to inputs by their proper
names, not e.g. referring to "xES" as "ES" when there i= s another
thing named "ES" (that's confusing even with a note).

Typo. Willdo.


7) I think there should be helper function defined to do the
label zero-padding, instead of it being just a note (just for
clarity).

Hmm... Can you suggest text? Do y= ou think we should do this
for the signature context as well?

-Ekr




-Ilari

--089e011771a91044fc05196b43b1-- From nobody Fri Jun 26 08:44: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 58BFC1A8845 for ; Fri, 26 Jun 2015 08:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4S6dW-TIV3B for ; Fri, 26 Jun 2015 08:44:16 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (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 F27A21A882D for ; Fri, 26 Jun 2015 08:44:15 -0700 (PDT) Received: by igbiq7 with SMTP id iq7so16038003igb.1 for ; Fri, 26 Jun 2015 08:44:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=rotEBG3ulhwX/fb3wmyiKvpZuvWd/GWqUCYtUBvjwu4=; b=b+kdyDqyR83J4c6WX47uHsuQIvNnMYYMlVc1bBtqbZ2azTbpS9D22s4MZEE98aKEjj 5a+635v8RQrnB/IL9NzDvBA7KV+izFr9gTwSSw3TiPbS8Xkh/QIw+KyGEWJR2nCADMcS GVMIcborPtfCa7ah7bMLTFJs9E5PU5xS1mvfve22uqmFtaLIYQdkbY06fQIdVEaEpWsd yBefaRnoAwIf2RK4kgpBJcuOMRjJOyQCGoTZnlz1cRGgYoJls5NBmNAzuoJzLtQOGHoG CHrhzXeRWB2ImsL1gD35kEXYKl9bniSzHjhHodGBk+ZHsSx3SUnz5xs1O6f2jMlK7Z9h qVaA== MIME-Version: 1.0 X-Received: by 10.50.2.3 with SMTP id 3mr4316029igq.34.1435333455544; Fri, 26 Jun 2015 08:44:15 -0700 (PDT) Received: by 10.36.77.15 with HTTP; Fri, 26 Jun 2015 08:44:15 -0700 (PDT) In-Reply-To: References: Date: Fri, 26 Jun 2015 11:44:15 -0400 Message-ID: From: Jeffrey Walton To: ryan-ietftls@sleevi.com Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Origin Bound Certificates extension? 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: Fri, 26 Jun 2015 15:44:17 -0000 On Thu, Jun 25, 2015 at 10:04 PM, Ryan Sleevi wrote: > On Thu, June 25, 2015 4:46 pm, Jeffrey Walton wrote: >> Should there be a ed25519 or similar? > > You should ask the WG that is working on the draft, which is the tokbind > WG, not the tls WG. > > http://datatracker.ietf.org/wg/tokbind/charter/ Ah, thanks again Ryan. Sorry about the extra noise. Jeff From nobody Fri Jun 26 09:54: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 A94191A893F for ; Fri, 26 Jun 2015 09:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 kSDjPjo7N2bA for ; Fri, 26 Jun 2015 09:54:19 -0700 (PDT) Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84B411A893E for ; Fri, 26 Jun 2015 09:54:18 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id 06BE41A2612; Fri, 26 Jun 2015 19:54:15 +0300 (EEST) Date: Fri, 26 Jun 2015 19:54:15 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20150626165415.GA28534@LK-Perkele-VII> References: <2AA11887-2F82-48EF-BD45-4D85CFA83847@qut.edu.au> <20150617082529.GA17280@LK-Perkele-VII> <20150617150505.GA19959@LK-Perkele-VII> <20150626085008.GA25187@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Computation of static secret in anonymous 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, 26 Jun 2015 16:54:23 -0000 On Fri, Jun 26, 2015 at 05:55:21AM -0700, Eric Rescorla wrote: > On Fri, Jun 26, 2015 at 1:50 AM, Ilari Liusvaara < > ilari.liusvaara@elisanet.fi> wrote: > > > 1) xSS is used as direct input to HKDF-Expand, so one would presume > > it should be HKDF-Extract output (AFAIK, HKDF-Extract and HKDF-Expand > > are supposed to be paired). HKDF-Extract does not take label nor > > length. > > > > 2) Same as above for xES. > > > > 3) Same as above for master_secret. > > > > 4) Why does master_secret derivation take xSS and xES instead of > > SS and ES directly (especially if xSS and xES are supposed to be > > HKDF-Extract outputs)? > > > > 4) Why is finished independent of ES (IIRC, it did depend on it > > in earlier version)? > > > > i'm going to refer these to Hugo, as they were his suggestion. Also, TLS 1.2 had tls-unique also be secret (but one would have to really misuse it for that to matter). With finished just depending on SS, secrecy might fail. Probably nobody uses tls-unique the wrong way, but then, nobody probably thought somebody uses tls-extractor outputs as nonces in TLS 1.2 (I know two (now deprecated) protocols that do that, both took a nasty hit from THS). > > 5) Application data uses xES as secret. AFAICT, leads to an attack. > > Should be master_secret (IIRC, was that way in earlier version)? > > > > This is a typo. Will fix. Remember, this is a WIP branch. :) > > With that said, I'd be interested in hearing what the attack is. Pretty weak one, but replaying 0-RTT and then decoding what the server sends back (which can be quite revealing about what the 0-RTT payload was). > > 7) I think there should be helper function defined to do the > > label zero-padding, instead of it being just a note (just for > > clarity). > > Hmm... Can you suggest text? Do you think we should do this > for the signature context as well? Maybe something like: HKDF-Extract-Label(secret, label, seed, length) = HKDF-Extract(secret, label + "\0" + seed, length) Where label is ASCII label with no NUL bytes and "\0" is the NUL byte. And then use that. Might be worthwhile doing for digital signatures as well, but it isn't clear how to best denote it, since digitally-signed works as a macro. Some more stuff: 8) Client and Server certificate verify sign hash of handshake (using prf-hash) but don't indicate what hash was used. Can have nasty effects if the prf-hash is ever really broken and replacement has the same bitlength (yes, we know that broken hashes should be de-implemented, except this doesn't seem to happen as fast as we would like. RC4, MD5 and EXPORT anybody?). 9) Might make sense to replace the early_data_allowed in ServerCofiguration with a bitfield listing acceptable uses (some other uses might be ClientAuthentication and ServerAuthentication). 10) "Finally, note that if the server key is compromised, and client authentication is used, then the attacker can impersonate the client to the server (as it knows the traffic key)." ... How does that work? I tried to figure that out, the problem I hit was that I couldn't figure out how to compute ES on server side of MITM (without also having compromised some signed client's key). 11) Section "Random Number Generation and Seeding". Maybe change SHA-1 to SHA-256 and delete remark about PCs (it is throughly obsolete). 12) "Implementation Pitfalls". Add rejecting incorrect sequence of handshake message types. There have been _multiple_ catastrophic security failures from getting this wrong. 13) 'the DSA "k" parameter'. Maybe change that to 'the ECDSA "k" parameter' (DSA is pretty much obsolete, or better, use deterministic ECDSA). 14) 'In order to allow servers to readily distinguish between messages sent in the first flight and in the second flight (in cases where the server rejects the EarlyDataIndication extension), the client MUST send the handshake messages as content type "early_handshake"' ... How does that work? Without explicit end of transmission incidation, the server doesn't know when to send ServerHello, and it needs to know that in order to properly lay out its session_hash (and not including those in session_hash needs _serious_ analysis). -Ilari From nobody Fri Jun 26 10:09: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 AD77C1A8992 for ; Fri, 26 Jun 2015 10:09:39 -0700 (PDT) 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 0WyySQvkS6sa for ; Fri, 26 Jun 2015 10:09:37 -0700 (PDT) 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 CE5A21A898D for ; Fri, 26 Jun 2015 10:09:36 -0700 (PDT) Received: by wicgi11 with SMTP id gi11so23343258wic.0 for ; Fri, 26 Jun 2015 10:09:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=/T6p/m7BXG32wW++xinlH5dfpBFUgxiKO7Kj7BxF+k0=; b=mUic7jliqPz/OLf2lNL4/Czrlp5PNdTY7pgDphwXJcYz50FmovkHHbKMZIUpqav5xQ s9LbvbtyqzWYl3mqwm0snxQaCDyvs87eRGmU4DMa1n+2fZHjXD9/ViXNcv8BgniZ+sJ5 Nx7lCZ48UT819hfgzqTnX2D2TOkux595r5EwfG9ruRHaLmwN2zhfulFnLn8qo7DOq+Gb Mcgwmq/0xh17GniVPDXdmfRF2v3h/xU1wLbu5wAnZiZGEFKd+Fkth9uO8gJDvIUrHNUF sReZrkzYV1itWduUBgo5uw5Q6AwSSExTRSvliE/NpN0JZ7QT+v8xt4WFdeew+n2S2LDv vZsw== X-Gm-Message-State: ALoCoQmhNaJbZbrmexb2CFkOowj2FmAagbedd+HaA6CEGqsT/qgUXJZaiht8PzNVeXySVNVvyOVW X-Received: by 10.180.189.201 with SMTP id gk9mr6776343wic.53.1435338575498; Fri, 26 Jun 2015 10:09:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.95.211 with HTTP; Fri, 26 Jun 2015 10:08:55 -0700 (PDT) In-Reply-To: <20150626165415.GA28534@LK-Perkele-VII> References: <2AA11887-2F82-48EF-BD45-4D85CFA83847@qut.edu.au> <20150617082529.GA17280@LK-Perkele-VII> <20150617150505.GA19959@LK-Perkele-VII> <20150626085008.GA25187@LK-Perkele-VII> <20150626165415.GA28534@LK-Perkele-VII> From: Eric Rescorla Date: Fri, 26 Jun 2015 10:08:55 -0700 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a11c352a0ece4c505196ecde7 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Computation of static secret in anonymous 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, 26 Jun 2015 17:09:39 -0000 --001a11c352a0ece4c505196ecde7 Content-Type: text/plain; charset=UTF-8 Thanks for your review. On Fri, Jun 26, 2015 at 9:54 AM, Ilari Liusvaara < ilari.liusvaara@elisanet.fi> wrote: > On Fri, Jun 26, 2015 at 05:55:21AM -0700, Eric Rescorla wrote: > > On Fri, Jun 26, 2015 at 1:50 AM, Ilari Liusvaara < > > ilari.liusvaara@elisanet.fi> wrote: > > > > > 1) xSS is used as direct input to HKDF-Expand, so one would presume > > > it should be HKDF-Extract output (AFAIK, HKDF-Extract and HKDF-Expand > > > are supposed to be paired). HKDF-Extract does not take label nor > > > length. > > > > > > 2) Same as above for xES. > > > > > > 3) Same as above for master_secret. > > > > > > 4) Why does master_secret derivation take xSS and xES instead of > > > SS and ES directly (especially if xSS and xES are supposed to be > > > HKDF-Extract outputs)? > > > > > > 4) Why is finished independent of ES (IIRC, it did depend on it > > > in earlier version)? > > > > > > > i'm going to refer these to Hugo, as they were his suggestion. > > Also, TLS 1.2 had tls-unique also be secret (but one would have to > really misuse it for that to matter). With finished just depending on > SS, secrecy might fail. > As I understand it, there are cryptographic logic reasons for this (again, I'll defer to Hugo here). Maybe we should just define a new value for TLS-Unique based on the exporter secrets? > > > 5) Application data uses xES as secret. AFAICT, leads to an attack. > > > Should be master_secret (IIRC, was that way in earlier version)? > > > > > > > This is a typo. Will fix. Remember, this is a WIP branch. :) > > > > With that said, I'd be interested in hearing what the attack is. > > Pretty weak one, but replaying 0-RTT and then decoding what the server > sends back (which can be quite revealing about what the 0-RTT payload > was). Sorry, I'm still not seeing how this works. If you replay 0-RTT, then don't you by definition not know the original client DHE share (otherwise, why replay), so how do you decrypt? Maybe I'm just being stupid here. > 7) I think there should be helper function defined to do the > > > label zero-padding, instead of it being just a note (just for > > > clarity). > > > > Hmm... Can you suggest text? Do you think we should do this > > for the signature context as well? > > Maybe something like: > > HKDF-Extract-Label(secret, label, seed, length) = > HKDF-Extract(secret, label + "\0" + seed, length) > > Where label is ASCII label with no NUL bytes and "\0" is the NUL > byte. > > And then use that. > > > Might be worthwhile doing for digital signatures as well, but > it isn't clear how to best denote it, since digitally-signed > works as a macro. > Thanks. I'll give it a shot. > > Some more stuff: > > 8) Client and Server certificate verify sign hash of handshake (using > prf-hash) but don't indicate what hash was used. Can have nasty effects > if the prf-hash is ever really broken and replacement has the same > bitlength (yes, we know that broken hashes should be de-implemented, > except this doesn't seem to happen as fast as we would like. RC4, MD5 > and EXPORT anybody?). > What did you have in mind for fixing this? > 9) Might make sense to replace the early_data_allowed in > ServerCofiguration with a bitfield listing acceptable uses (some other > uses might be ClientAuthentication and ServerAuthentication). > Yeah, worth a shot. 10) "Finally, note that if the server key is compromised, and client > authentication is used, then the attacker can impersonate the client > to the server (as it knows the traffic key)." ... How does that work? > I tried to figure that out, the problem I hit was that I couldn't > figure out how to compute ES on server side of MITM (without also > having compromised some signed client's key). > This was pointed out to me by Kartik so maybe I'm > 11) Section "Random Number Generation and Seeding". Maybe change > SHA-1 to SHA-256 and delete remark about PCs (it is throughly > obsolete). I am planning to rewrite much of this section. 12) "Implementation Pitfalls". Add rejecting incorrect sequence > of handshake message types. There have been _multiple_ catastrophic > security failures from getting this wrong. > > 13) 'the DSA "k" parameter'. Maybe change that to 'the ECDSA "k" > parameter' (DSA is pretty much obsolete, or better, use deterministic > ECDSA). > I would appreciate PRs for this. 14) 'In order to allow servers to readily distinguish between > messages sent in the first flight and in the second flight (in > cases where the server rejects the EarlyDataIndication extension), > the client MUST send the handshake messages as content type > "early_handshake"' ... How does that work? Without explicit > end of transmission incidation, the server doesn't know when > to send ServerHello, and it needs to know that in order to > properly lay out its session_hash (and not including those in > session_hash needs _serious_ analysis) > There are two cases: 1. You accept the 0-RTT, in which case you process them and then include them in the session hash. 2. You reject the 0-RTT, in which case you can't even decrypt them and then you don't include them in the session hash but instead send a ServerHello right away. With that said, I still haven't implemented this part (WIP!) and so am not totally sure it works. Doe that make sense? -Ekr --001a11c352a0ece4c505196ecde7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for your review.
On Fri, Jun 26, 2015 at 9:54 AM, Ilari Liusvaar= a <ilari.liusvaara@elisanet.fi> wrote:
On Fri, Jun 26, 2015 at 05:55:21AM = -0700, Eric Rescorla wrote:
> On Fri, Jun 26, 2015 at 1:50 AM, Ilari Liusvaara <
> ilari.liusvaara@elisane= t.fi> wrote:
>
> > 1) xSS is used as direct input to HKDF-Ex= pand, so one would presume
> > it should be HKDF-Extract output (AFAIK, HKDF-Extract and HKDF-Ex= pand
> > are supposed to be paired). HKDF-Extract does not take label nor<= br> > > length.
> >
> > 2) Same as above for xES.
> >
> > 3) Same as above for master_secret.
> >
> > 4) Why does master_secret derivation take xSS and xES instead of<= br> > > SS and ES directly (especially if xSS and xES are supposed to be<= br> > > HKDF-Extract outputs)?
> >
> > 4) Why is finished independent of ES (IIRC, it did depend on it > > in earlier version)?
> >
>
> i'm going to refer these to Hugo, as they were his suggestion.

Also, TLS 1.2 had tls-unique also be secret (but one would have to really misuse it for that to matter). With finished just depending on
SS, secrecy might fail.

As I understand= it, there are cryptographic logic reasons for this (again,
I'= ;ll defer to Hugo here). Maybe we should just define a new value
= for TLS-Unique based on the exporter secrets?


=

> > 5) Application data uses xES as secret. AFAICT, leads to an attac= k.
> > Should be master_secret (IIRC, was that way in earlier version)?<= br> > >
>
> This is a typo. Will fix.=C2=A0 Remember, this is a WIP branch. :)
>
> With that said, I'd be interested in hearing what the attack is.
Pretty weak one, but replaying 0-RTT and then decoding what the serv= er
sends back (which can be quite revealing about what the 0-RTT payload
was).

Sorry, I'm still not seeing how t= his works. If you replay 0-RTT, then don't
you by definition = not know the original client DHE share (otherwise, why
replay), s= o how do you decrypt? Maybe I'm just being stupid here.

<= /div>


> 7) I think there should be helper function defined to do the
> > label zero-padding, instead of it being just a note (just for
> > clarity).
>
> Hmm... Can you suggest text? Do you think we should do this
> for the signature context as well?

Maybe something like:

HKDF-Extract-Label(secret, label, seed, length) =3D
=C2=A0 =C2=A0 HKDF-Extract(secret, label + "\0" + seed, length)
Where label is ASCII label with no NUL bytes and "\0" is the NUL<= br> byte.

And then use that.


Might be worthwhile doing for digital signatures as well, but
it isn't clear how to best denote it, since digitally-signed
works as a macro.

Thanks. I'll give= it a shot.

=C2=A0

Some more stuff:

8) Client and Server certificate verify sign hash of handshake (using
prf-hash) but don't indicate what hash was used. Can have nasty effects=
if the prf-hash is ever really broken and replacement has the same
bitlength (yes, we know that broken hashes should be de-implemented,
except this doesn't seem to happen as fast as we would like. RC4, MD5 and EXPORT anybody?).

What did you have= in mind for fixing this?

=C2=A0
9) Might make sense to replace the early_data_allowed in
ServerCofiguration with a bitfield listing acceptable uses (some other
uses might be ClientAuthentication and ServerAuthentication).

Yeah, worth a shot.


10) "Finally, note that if the server key is compromised, and client authentication is used, then the attacker can impersonate the client
to the server (as it knows the traffic key)." ... How does that work?<= br> I tried to figure that out, the problem I hit was that I couldn't
figure out how to compute ES on server side of MITM (without also
having compromised some signed client's key).

=
This was pointed out to me by Kartik so maybe I'm
= =C2=A0
=C2=A0
11) Section "Random Number Generation and Seeding". Maybe change<= br> SHA-1 to SHA-256 and delete remark about PCs (it is throughly
obsolete).

I am planning to rewrite much of= this section.


=C2=A0
12) "Implementation Pitfalls". Add rejecting incorrect sequence of handshake message types. There have been _multiple_ catastrophic
security failures from getting this wrong.

13) 'the DSA "k" parameter'. Maybe change that to 'th= e ECDSA "k"
parameter' (DSA is pretty much obsolete, or better, use deterministic ECDSA).

I would appreciate PRs for this= .


14) 'In order to allow servers to readily distinguish between
messages sent in the first flight and in the second flight (in
cases where the server rejects the EarlyDataIndication extension),
the client MUST send the handshake messages as content type
"early_handshake"' ...=C2=A0 How does that work? Without expl= icit
end of transmission incidation, the server doesn't know when
to send ServerHello, and it needs to know that in order to
properly lay out its session_hash (and not including those in
session_hash needs _serious_ analysis)

= There are two cases:
1. You accept the 0-RTT, in which case you p= rocess them and then
include them in the session hash.
= 2. You reject the 0-RTT, in which case you can't even decrypt them
and then you don't include them in the session hash but instead
send a ServerHello right away.

With that = said, I still haven't implemented this part (WIP!) and so
am = not totally sure it works. Doe that make sense?

-E= kr



=
--001a11c352a0ece4c505196ecde7-- From nobody Fri Jun 26 11:41: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 170841A92DE for ; Fri, 26 Jun 2015 11:41:33 -0700 (PDT) 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 N7Bta-t1XX8n for ; Fri, 26 Jun 2015 11:41:32 -0700 (PDT) Received: from homiemail-a110.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 161421A90E2 for ; Fri, 26 Jun 2015 11:41:32 -0700 (PDT) Received: from homiemail-a110.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a110.g.dreamhost.com (Postfix) with ESMTP id 87FB020058D39; Fri, 26 Jun 2015 11:41:31 -0700 (PDT) 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=+vct5GPTwpv4Lw pV8QJLLuAUEA4=; b=d6FRxyyYcWJPW99kvG0lHiT9ofv2pGVx1G8DtROk54Y9KA +YNE5S1cmbp0W3MxOpo/EtikBykdCTh9A9k2WeDqGLVdFatBOLxH8+G0MkdXcJjX gDB6L++A79UgVZ083vGe9fI0saMPKPE55FedxZTOmnUl8Jwtd9LS8QaEpaLUQ= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a110.g.dreamhost.com (Postfix) with ESMTPA id F2CC420058D37; Fri, 26 Jun 2015 11:41:30 -0700 (PDT) Date: Fri, 26 Jun 2015 13:41:29 -0500 From: Nico Williams To: Eric Rescorla Message-ID: <20150626184128.GG6117@localhost> References: <2AA11887-2F82-48EF-BD45-4D85CFA83847@qut.edu.au> <20150617082529.GA17280@LK-Perkele-VII> <20150617150505.GA19959@LK-Perkele-VII> <20150626085008.GA25187@LK-Perkele-VII> <20150626165415.GA28534@LK-Perkele-VII> 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@ietf.org" Subject: Re: [TLS] Computation of static secret in anonymous 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, 26 Jun 2015 18:41:33 -0000 On Fri, Jun 26, 2015 at 10:08:55AM -0700, Eric Rescorla wrote: > On Fri, Jun 26, 2015 at 9:54 AM, Ilari Liusvaara < > ilari.liusvaara@elisanet.fi> wrote: > > On Fri, Jun 26, 2015 at 05:55:21AM -0700, Eric Rescorla wrote: > > > On Fri, Jun 26, 2015 at 1:50 AM, Ilari Liusvaara < > > > ilari.liusvaara@elisanet.fi> wrote: > > > > 4) Why is finished independent of ES (IIRC, it did depend on it > > > > in earlier version)? > > > > > > i'm going to refer these to Hugo, as they were his suggestion. > > > > Also, TLS 1.2 had tls-unique also be secret (but one would have to > > really misuse it for that to matter). With finished just depending on > > SS, secrecy might fail. > > As I understand it, there are cryptographic logic reasons for this (again, > I'll defer to Hugo here). Maybe we should just define a new value > for TLS-Unique based on the exporter secrets? tls-unique depends on the Finished message strongly binding the entire transcript up to that point. I find this elegant (despite the resumption problem, which anyways, should be fixed by the session hash) and easy to understand and analyze. If the Finished message no longer has this property in 1.3 then that's a problem for tls-unique, and we'd have to fix one or the other. Surely 1.3 will have some handshake message that binds the transcript, and why that wouldn't be the Finished message is beyond me (but I am missing a lot of the 1.3 context, so please forgive and inform me). It would be better though to move the responsibility for defining tls-unique to the TLS 1.3 spec even if tls-unique remains unchanged. That way 1.3 and/or future versions of TLS can specify different constructions of tls-unique. Nico -- From nobody Fri Jun 26 11:48: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 229C41ABD37 for ; Fri, 26 Jun 2015 11:48:24 -0700 (PDT) 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 r1oTXZMTPaPS for ; Fri, 26 Jun 2015 11:48:22 -0700 (PDT) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) (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 308901ABC75 for ; Fri, 26 Jun 2015 11:48:22 -0700 (PDT) Received: by wgck11 with SMTP id k11so95493185wgc.0 for ; Fri, 26 Jun 2015 11:48:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=nub/VePD5DI6334076qUDLtVWlr74/Q6xFXga11QdU4=; b=eQkORL9v5gkA3gRA8UrWdkuQKVJIHvT3vqJnhVyA9TZA6CD0V2812CQtEZtSItF/Wj fqsVT3/ERxWiDH26rcUKwk1bP1nSzG2pNfnbEnFs9PQSv6YmyHw1yZWQXOvvea3HDgWt EZekFjhEYsV6kx49VzXnIkQpli6ortzSdDW2usMwkKGotTwZWxueUHlZ2Tt83gOOT3z9 uUAZ/dexps9MASlvPQ0jfrvFxCG8RXiWbyXVdZ5lI/YJH4Wl5W91B8o09FRDSEva9P0O yldCK7eozxurwGPhdol/X+s1og+ggCuYIrEWM0dCUC8dTr832Px1JQW6RsnWOeZRD5g9 cyDg== X-Gm-Message-State: ALoCoQnRfDiaaRtEQGb8vilcfozFQieA6xBftRvW81IvTb88W8h0677INXtRtmgxMbYOXIa9bYt6 X-Received: by 10.180.75.78 with SMTP id a14mr7629349wiw.68.1435344500974; Fri, 26 Jun 2015 11:48:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.95.211 with HTTP; Fri, 26 Jun 2015 11:47:41 -0700 (PDT) In-Reply-To: <20150626184128.GG6117@localhost> References: <2AA11887-2F82-48EF-BD45-4D85CFA83847@qut.edu.au> <20150617082529.GA17280@LK-Perkele-VII> <20150617150505.GA19959@LK-Perkele-VII> <20150626085008.GA25187@LK-Perkele-VII> <20150626165415.GA28534@LK-Perkele-VII> <20150626184128.GG6117@localhost> From: Eric Rescorla Date: Fri, 26 Jun 2015 11:47:41 -0700 Message-ID: To: Nico Williams Content-Type: multipart/alternative; boundary=f46d0438eb9d1c7a7f0519702f8f Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Computation of static secret in anonymous 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, 26 Jun 2015 18:48:24 -0000 --f46d0438eb9d1c7a7f0519702f8f Content-Type: text/plain; charset=UTF-8 On Fri, Jun 26, 2015 at 11:41 AM, Nico Williams wrote: > On Fri, Jun 26, 2015 at 10:08:55AM -0700, Eric Rescorla wrote: > > On Fri, Jun 26, 2015 at 9:54 AM, Ilari Liusvaara < > > ilari.liusvaara@elisanet.fi> wrote: > > > On Fri, Jun 26, 2015 at 05:55:21AM -0700, Eric Rescorla wrote: > > > > On Fri, Jun 26, 2015 at 1:50 AM, Ilari Liusvaara < > > > > ilari.liusvaara@elisanet.fi> wrote: > > > > > 4) Why is finished independent of ES (IIRC, it did depend on it > > > > > in earlier version)? > > > > > > > > i'm going to refer these to Hugo, as they were his suggestion. > > > > > > Also, TLS 1.2 had tls-unique also be secret (but one would have to > > > really misuse it for that to matter). With finished just depending on > > > SS, secrecy might fail. > > > > As I understand it, there are cryptographic logic reasons for this > (again, > > I'll defer to Hugo here). Maybe we should just define a new value > > for TLS-Unique based on the exporter secrets? > > tls-unique depends on the Finished message strongly binding the entire > transcript up to that point. I find this elegant (despite the > resumption problem, which anyways, should be fixed by the session hash) > and easy to understand and analyze. > > If the Finished message no longer has this property in 1.3 then that's a > problem for tls-unique, and we'd have to fix one or the other. Surely > 1.3 will have some handshake message that binds the transcript, and why > that wouldn't be the Finished message is beyond me (but I am missing a > lot of the 1.3 context, so please forgive and inform me). > In general TLS 1.3 tries to derive keys from as much of the transcript as is available. The issue with Finished is that for the cryptographic logic reasons I indicated earlier [0], it is computes using only SS which means that for some handshake modes it isn't tied to the ephemeral keys. However, the exporter secret is. It would be better though to move the responsibility for defining > tls-unique to the TLS 1.3 spec even if tls-unique remains unchanged. > That way 1.3 and/or future versions of TLS can specify different > constructions of tls-unique. > This seems like a good idea. -Ekr [0] Hugo can explain this better than I, but as I understand it, the point is that SS is being used to authenticate ES via the Finished and if you compute the Finished based on ES, then it creates a circular logic. > o > -- > --f46d0438eb9d1c7a7f0519702f8f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jun 26, 2015 at 11:41 AM, Nico Williams <<= a href=3D"mailto:nico@cryptonector.com" target=3D"_blank">nico@cryptonector= .com> wrote:
On Fri, Jun= 26, 2015 at 10:08:55AM -0700, Eric Rescorla wrote:
> On Fri, Jun 26, 2015 at 9:54 AM, Ilari Liusvaara <
> ilari.liusvaara@elisane= t.fi> wrote:
> > On Fri, Jun 26, 2015 at 05:55:21AM -0700, Eric Rescorla wrote: > > > On Fri, Jun 26, 2015 at 1:50 AM, Ilari Liusvaara <
> > > ilari.liusvaa= ra@elisanet.fi> wrote:
> > > > 4) Why is finished independent = of ES (IIRC, it did depend on it
> > > > in earlier version)?
> > >
> > > i'm going to refer these to Hugo, as they were his sugge= stion.
> >
> > Also, TLS 1.2 had tls-unique also be secret (but one would have t= o
> > really misuse it for that to matter). With finished just dependin= g on
> > SS, secrecy might fail.
>
> As I understand it, there are cryptographic logic reasons for this (ag= ain,
> I'll defer to Hugo here). Maybe we should just define a new value<= br> > for TLS-Unique based on the exporter secrets?

tls-unique depends on the Finished message strongly binding the enti= re
transcript up to that point.=C2=A0 I find this elegant (despite the
resumption problem, which anyways, should be fixed by the session hash)
and easy to understand and analyze.

If the Finished message no longer has this property in 1.3 then that's = a
problem for tls-unique, and we'd have to fix one or the other.=C2=A0 Su= rely
1.3 will have some handshake message that binds the transcript, and why
that wouldn't be the Finished message is beyond me (but I am missing a<= br> lot of the 1.3 context, so please forgive and inform me).
<= div>
In general TLS 1.3 tries to derive keys from as much of = the transcript
as is available. The issue with Finished is that f= or the cryptographic
logic reasons I indicated earlier [0], it is= computes using only SS
which means that for some handshake modes= it isn't tied to the
ephemeral keys. However, the exporter s= ecret is.


It would be better though to move the responsibility for defining
tls-unique to the TLS 1.3 spec even if tls-unique remains unchanged.
That way 1.3 and/or future versions of TLS can specify different
constructions of tls-unique.

This seems= like a good idea.=C2=A0

-Ekr

=
[0] Hugo can explain this better than I, but as I understand it, the p= oint is
that SS is being used to authenticate ES via the Finished= and if you
compute the Finished based on ES, then it creates a c= ircular logic.

=C2=A0=C2=A0
= o
--

--f46d0438eb9d1c7a7f0519702f8f-- From nobody Fri Jun 26 12:27: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 826131A8B84 for ; Fri, 26 Jun 2015 12:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tl48b1-ZSJ0U for ; Fri, 26 Jun 2015 12:27:52 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (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 E9E501A8AB9 for ; Fri, 26 Jun 2015 12:27:51 -0700 (PDT) Received: by lacny3 with SMTP id ny3so69259023lac.3 for ; Fri, 26 Jun 2015 12:27:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=1B71AthVLQYsMpf6HDBcdvPlEXP0J/W8wQbhnh3WOfU=; b=CZ7BIFVgWTaYreka99eEscXRjO4ekQZq8AICZNPn8rmFUwfIKfArW0JMOCKh69+Ngi yZZFPegWAq0byqqbPmfGu1okOfOGGIGOLKehu6B5AR+i3jzo6rQUmEDZnm32ZDr28aAL Wzh+JVCIBojsNEXegEx4BVXOfI1HW1if0QAwqEJTZTiO3omdN4dOWQEMNsM1XI19Kako TmKFnkSXjGBydHOGjM9zJiomXSkh5gjPyNnsKl6lFMCp88anXUACnzr++OO8voj5mmg6 qmujClSAP7ph26+fuMXWWn/yyEWzMnOhvBhQb4LlszF2u/3SKY4TJBwZr5sj6iSvcAD3 uUDg== X-Received: by 10.112.170.167 with SMTP id an7mr2987686lbc.103.1435346870251; Fri, 26 Jun 2015 12:27:50 -0700 (PDT) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.209.145 with HTTP; Fri, 26 Jun 2015 12:27:20 -0700 (PDT) In-Reply-To: <20150626085008.GA25187@LK-Perkele-VII> References: <2AA11887-2F82-48EF-BD45-4D85CFA83847@qut.edu.au> <20150617082529.GA17280@LK-Perkele-VII> <20150617150505.GA19959@LK-Perkele-VII> <20150626085008.GA25187@LK-Perkele-VII> From: Hugo Krawczyk Date: Fri, 26 Jun 2015 12:27:20 -0700 X-Google-Sender-Auth: 47qM5VEDBes4Orn1HErAUlBHKT0 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a11c368cc54b525051970bc13 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Computation of static secret in anonymous 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, 26 Jun 2015 19:27:55 -0000 --001a11c368cc54b525051970bc13 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I would prefer to have a more stable version of the draft to comment on these design choices/logic but let me refer to some of your questions below (particularly as I may not be available for responding in the next few days). On Fri, Jun 26, 2015 at 1:50 AM, Ilari Liusvaara < ilari.liusvaara@elisanet.fi> wrote: > On Wed, Jun 17, 2015 at 09:35:14AM -0700, Eric Rescorla wrote: > > On Wed, Jun 17, 2015 at 8:05 AM, Ilari Liusvaara < > > ilari.liusvaara@elisanet.fi> wrote: > > > > > On Wed, Jun 17, 2015 at 05:56:23AM -0700, Eric Rescorla wrote: > > > > On Wed, Jun 17, 2015 at 1:25 AM, Ilari Liusvaara < > > > > ilari.liusvaara@elisanet.fi> wrote: > > > > > > > > > There's much newer version in ekr/tls13-spec#WIP_draft_06 > > > > > (seems to have fixed most of the mistakes in the original WIP) > > > > > > > > > > > > > Don't worry, I'm sure there are plenty of mistakes left! > > > > > > Such as how keys for TLS exporters are derived? > > > > Quite possibly. Hence the WIP designation. > > > > Reviewing it again after changes (e1219310a7f, Jun 25th): > > 1) xSS is used as direct input to HKDF-Expand, so one would presume > it should be HKDF-Extract output (AFAIK, HKDF-Extract and HKDF-Expand > are supposed to be paired). HKDF-Extract does not take label nor > length. > =E2=80=8BLogically, xSS is an extracted version of SS and could have been d= erived as xSS =3D HKDF-Extract(0,SS)=E2=80=8B. Same would apply to xES. The reason we apply a full HKDF in these derivations (i.e., adding the Expand part after Extract) is that in cases where SS=3DES (e.g. in PSK mode without PFS) doing just Extract would result in xES=3DxSS which is bad for the derivation of master_secret (it would set the seed and key material of HKDF in the derivation of master_secret to the same value hence requiring stronger assumptions on HKDF, e.g. being an idealized random oracle). By running through the additional expand with different labels we get xSS and xES to be computationally independent (i.e., the outputs of a prf with the same key but computed on different inputs). > 2) Same as above for xES. > =E2=80=8BSame logic/answer as above.=E2=80=8B > > 3) Same as above for master_secret. > =E2=80=8BWe could have defined master_secret =3D HKDF-Extract(xSS, xES) but we used full HKDF here for uniformity with the derivation of xES and xSS. A =E2=80=8Blso, in this way we do not have the use of HKDF-Extract in the dra= ft at all, just full HKDF or HKDF-Expand (the latter being essentially a PRF) which adds to simplicity. =E2=80=8B > > 4) Why does master_secret derivation take xSS and xES instead of > SS and ES directly (especially if xSS and xES are supposed to be > HKDF-Extract outputs)? > =E2=80=8BSince we already extracted the entropy of SS and ES into the keys = xSS and xES it is better to directly use the latter as keys rather than the non-uniform SS and ES. =E2=80=8B > > 4) Why is finished independent of ES (IIRC, it did depend on it > in earlier version)? > Two important reasons. 1. Only SS can authenticate the handshake as it is the only element to involve the server's (semi) static private key. 2. One of the main elements to be authenticated by the server (via the Finished message) is its key share - deriving the key for the Finished message calculation from ES would create a circularity issue in the logic of the derivation. Note that the derivation of application keys (and other key material remaining after the end of the handshake) do involve both SS and ES, but there it makes sense since this comes after authentication and has the goal of secrecy of the application keys (particularly to resist future attacks upon compromise of long-term secret keys, namely, when PFS is required). 5) Application data uses xES as secret. AFAICT, leads to an attack. > Should be master_secret (IIRC, was that way in earlier version)? > =E2=80=8BApplication data uses master_secret: See table before 7.2.1 where application keys are derived from MS (should be denoted as master_secret; the symbol MS is not used anymore)=E2=80=8B > > 6) I think the key table should refer to inputs by their proper > names, not e.g. referring to "xES" as "ES" when there is another > thing named "ES" (that's confusing even with a note). > =E2=80=8BThe table is correct by referring to xSS and xES. These are different values than SS and ES. As their name indicates they are extracted versions of the latter, hence stronger for use as keys and for extraction seeds. =E2=80=8B =E2=80=8BHugo =E2=80=8B > 7) I think there should be helper function defined to do the > label zero-padding, instead of it being just a note (just for > clarity). > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11c368cc54b525051970bc13 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I would prefer to have a more stable version of= the draft to comment on these design choices/logic but let me refer to som= e of your questions below (particularly as I =C2=A0may not be available for= responding in the next few days).

On Fri, Jun 26, 2015 at 1:50 AM, Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote:
On Wed, Jun 17, 2015 at 09:35:14AM -0700, Eric Resc= orla wrote:
> On Wed, Jun 17, 2015 at 8:05 AM, Ilari Liusvaara <
> ilari= .liusvaara@elisanet.fi> wrote:
>
> > On Wed, Jun 17, 2015 at 05:56:23AM -0700, Eric Rescorla wrote: > > > On Wed, Jun 17, 2015 at 1:25 AM, Ilari Liusvaara <
> > > ilari.liusvaara@elisanet.fi> wrote:
> > >
> > > > There's much newer version in ekr/tls1= 3-spec#WIP_draft_06
> > > > (seems to have fixed most of the mistakes in the origin= al WIP)
> > > >
> > >
> > > Don't worry, I'm sure there are plenty of mistakes l= eft!
> >
> > Such as how keys for TLS exporters are derived?
>
> Quite possibly. Hence the WIP designation.
>

Reviewing it again after changes (e1219310a7f, Jun 25th):

1) xSS is used as direct input to HKDF-Expand, so one would presume
it should be HKDF-Extract output (AFAIK, HKDF-Extract and HKDF-Expand
are supposed to be paired). HKDF-Extract does not take label nor
length.

=E2= =80=8BLogically, xSS is an extracted version of SS and could have been deri= ved as=C2=A0
xSS =3D HKDF-Extract= (0,SS)=E2=80=8B. Same would apply to xES.
The reason we apply a full HKDF in these derivations (i.e., adding= the Expand part after Extract) is that in cases where SS=3DES (e.g. in PSK= mode without PFS) doing just Extract would result in xES=3DxSS which is ba= d for the derivation of master_secret (it would set the seed and key materi= al of HKDF in the derivation of master_secret to the same value hence requi= ring stronger assumptions on HKDF, e.g. being an idealized random oracle).<= /div>
By running through the additional= expand with different labels we get xSS and xES to be computationally inde= pendent (i.e., the outputs of a prf with the same key but computed on diffe= rent inputs).


2) Same as above for xES.

=E2=80=8BSame logic/answer as above.=E2=80=8B
=C2=A0

3) Same as above for master_secret.

=E2=80=8BWe could have defined=C2=A0
master_secret =3D HKDF-Extract(xSS, xES)
but we used full HKDF here for uniformit= y with the derivation of xES and xSS.
A
=E2=80=8Blso, in this way we do no= t have the use of HKDF-Extract in the draft at all, just full HKDF or HKDF-= Expand (the latter being essentially a PRF) which adds to simplicity.
=

=E2=80=8B

4) Why does master_secret derivation take xSS and xES instead of
SS and ES directly (especially if xSS and xES are supposed to be
HKDF-Extract outputs)?

=E2=80=8BSince we already extracted the entropy of SS and ES into= the keys xSS and xES it is better to directly use the latter as keys rathe= r than the non-uniform SS and ES.
=E2=80=8B
=C2=A0

4) Why is finished independent of ES (IIRC, it did depend on it
in earlier version)?

Two important reasons.
1.= Only SS can authenticate the handshake as it is the only element to involv= e the server's (semi) static private key.
2. One of the main elements to be authenticated by the server = (via the Finished message) is its key share =C2=A0- deriving the key for th= e Finished message calculation from ES would create a circularity issue in = the logic of the derivation.

=
Note that the derivation of appl= ication keys (and other key material remaining after the end of the handsha= ke) do involve both SS and ES, but there it makes sense since this comes af= ter authentication and has the goal of secrecy of the application keys (par= ticularly to resist future attacks upon compromise of long-term secret keys= , namely, when PFS is required).
=

5) Application data uses xES as secret. AFAICT, leads to an attack.
Should be master_secret (IIRC, was that way in earlier version)?

=E2=80=8BApplication data uses master_= secret: See table before 7.2.1 where application keys are derived from MS (= should be denoted as master_secret; the symbol MS is not used anymore)=E2= =80=8B

=C2=A0

6) I think the key table should refer to inputs by their proper
names, not e.g. referring to "xES" as "ES" when there i= s another
thing named "ES" (that's confusing even with a note).

=E2=80=8BThe table i= s correct by referring to xSS and xES.
These are different values than SS and ES.
As their name indicates they are extracted versions of the = latter, hence stronger for use as keys and for extraction seeds.
=E2=80=8B
=C2=A0
=E2=80=8BHugo
=E2=80=8B


7) I think there should be helper function defined to do the
label zero-padding, instead of it being just a note (just for
clarity).


-Ilari

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

--001a11c368cc54b525051970bc13-- From nobody Fri Jun 26 12: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 343ED1B2E43 for ; Fri, 26 Jun 2015 12:31:44 -0700 (PDT) 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 FBXtVSRjc6PH for ; Fri, 26 Jun 2015 12:31:42 -0700 (PDT) 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 5AD3E1B2E38 for ; Fri, 26 Jun 2015 12:31:42 -0700 (PDT) Received: by wicgi11 with SMTP id gi11so26135580wic.0 for ; Fri, 26 Jun 2015 12:31:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=DdeqmXbCWuWk8V+IlEUvJqR1oNcJrQqRH2Vfp54oAoo=; b=lKpbx44RmY516HwXBtNAl55CZy2Vw9x7amvVLlJOkb0nXp+PnEzCf6GQPVSREOmtVK VZ09Vz/1pzna4nMUUbi3spbTqy+xDTLRRZDO/wu6ovllK6VJCxUbVOMHRgfmqMImVX58 2chLhGlr/yrbWyfm6kS5lxDIsaQaCqHRwkMuNMBQzRFE6c/2iY5+7HVwqEWGAmo6CUry FvGWokG5uJEkPx9yfSMWCdlx9TD7ZQFrbeoyRrHGaRhCG8ONwEfRB4m4OB5AyWqqVlC/ XaSDETyJT8Fah1p7h87xjbbBGzkLncvjXOtWctG7AujAfDfIn/6joLU5NvJwHkiLtVzQ FqCA== X-Gm-Message-State: ALoCoQla9/OZsaOKxMkXWU/FvgIMVgRHyLxA73Egrkji7BKRCm0UqKv1p6STGXrjqIdRe2eIn0v4 X-Received: by 10.194.158.42 with SMTP id wr10mr5453973wjb.81.1435347101013; Fri, 26 Jun 2015 12:31:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.95.211 with HTTP; Fri, 26 Jun 2015 12:31:01 -0700 (PDT) In-Reply-To: References: <2AA11887-2F82-48EF-BD45-4D85CFA83847@qut.edu.au> <20150617082529.GA17280@LK-Perkele-VII> <20150617150505.GA19959@LK-Perkele-VII> <20150626085008.GA25187@LK-Perkele-VII> From: Eric Rescorla Date: Fri, 26 Jun 2015 12:31:01 -0700 Message-ID: To: Hugo Krawczyk Content-Type: multipart/alternative; boundary=089e013c647815f167051970ca15 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Computation of static secret in anonymous 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, 26 Jun 2015 19:31:44 -0000 --089e013c647815f167051970ca15 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Note: I have updated the WIP (and that's what I sent to Hugo) so it now contains the changes the values Hugo describes. On Fri, Jun 26, 2015 at 12:27 PM, Hugo Krawczyk wrote: > > 5) Application data uses xES as secret. AFAICT, leads to an attack. >> Should be master_secret (IIRC, was that way in earlier version)? >> > > =E2=80=8BApplication data uses master_secret: See table before 7.2.1 wher= e > application keys are derived from MS (should be denoted as master_secret; > the symbol MS is not used anymore)=E2=80=8B > I intend to change this to "master_secret", but the table got too wide and I need to figure out how to fix that :) > > >> >> 6) I think the key table should refer to inputs by their proper >> names, not e.g. referring to "xES" as "ES" when there is another >> thing named "ES" (that's confusing even with a note). >> > > =E2=80=8BThe table is correct by referring to xSS and xES. > These are different values than SS and ES. > As their name indicates they are extracted versions of the latter, hence > stronger for use as keys and for extraction seeds. > =E2=80=8B > As Hugo indicates, these are now fixed in my working copy. -Ekr =E2=80=8BHugo > =E2=80=8B > > >> 7) I think there should be helper function defined to do the >> label zero-padding, instead of it being just a note (just for >> clarity). >> >> >> -Ilari >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > --089e013c647815f167051970ca15 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Note: I have updated the WIP (and that's what I sent t= o Hugo) so it now contains the
changes the values Hugo describes.
=

On Fri, Jun 26, 2= 015 at 12:27 PM, Hugo Krawczyk <hugo@ee.technion.ac.il>= wrote:
5) Application data uses xES as secret. AFAICT, leads to an attack.
Should be master_secret (IIRC, was that way in earlier version)?

=E2=80=8BApplication data uses master_secret: See table= before 7.2.1 where application keys are derived from MS (should be denoted= as master_secret; the symbol MS is not used anymore)=E2=80=8B
<= /div>

I intend to change this t= o "master_secret", but the table got too wide and
I nee= d to figure out how to fix that :)
=C2=A0
=C2=A0

6) I think the key table should refer to inputs by their proper
names, not e.g. referring to "xES" as "ES" when there i= s another
thing named "ES" (that's confusing even with a note).

=E2=80=8BThe table is correct by refe= rring to xSS and xES.
These are different values than SS = and ES.
As their name indicates they are extracted versio= ns of the latter, hence stronger for use as keys and for extraction seeds.<= /div>
=E2=80=8B
=
As Hugo indicates, these are now fixed in my working copy.

-Ekr

=E2=80= =8BHugo
= =E2=80=8B


7) I think there should be helper function defined to do the
label zero-padding, instead of it being just a note (just for
clarity).


-Ilari

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


--089e013c647815f167051970ca15-- From nobody Fri Jun 26 12:47: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 8EE641B304F for ; Fri, 26 Jun 2015 12:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 87UVoPm6ey7S for ; Fri, 26 Jun 2015 12:47:38 -0700 (PDT) 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 7F2F31B3009 for ; Fri, 26 Jun 2015 12:47:37 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id 3913F9035C; Fri, 26 Jun 2015 22:47:34 +0300 (EEST) Date: Fri, 26 Jun 2015 22:47:34 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20150626194734.GA31681@LK-Perkele-VII> References: <2AA11887-2F82-48EF-BD45-4D85CFA83847@qut.edu.au> <20150617082529.GA17280@LK-Perkele-VII> <20150617150505.GA19959@LK-Perkele-VII> <20150626085008.GA25187@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Computation of static secret in anonymous 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, 26 Jun 2015 19:47:40 -0000 On Fri, Jun 26, 2015 at 12:31:01PM -0700, Eric Rescorla wrote: > Note: I have updated the WIP (and that's what I sent to Hugo) so it now > contains the > changes the values Hugo describes. Small nit: master_secret= HKDF(xSS, xES, "master secret") Should that be: master_secret= HKDF(xSS, xES, "master secret", L) (the length parameter is seemingly missing)? Also, is that label NUL-terminated or not (I think it is)? Another reason why I think it is not a good idea to use notes to change meaning of explcit algorithms... -Ilari From nobody Fri Jun 26 12:51: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 D89961ACCFB for ; Fri, 26 Jun 2015 12:51:43 -0700 (PDT) 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 eUrVDm0zP1ti for ; Fri, 26 Jun 2015 12:51:42 -0700 (PDT) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (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 E81551AC44D for ; Fri, 26 Jun 2015 12:51:41 -0700 (PDT) Received: by wicnd19 with SMTP id nd19so53527774wic.1 for ; Fri, 26 Jun 2015 12:51:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=sDrPxPyX+jP0t3a/tFwzN6m8AVFud4crIM4O0NS1/hE=; b=DoY06WYtoACSuJDxCF/+7YLTmMzNosMJKWVqaydQ629GPfD0GkpiebPl2vGucfNqbG h3zaoIoLxTFWk7bW41NjBlg+0uh9b7AiKN8+6xB6gYP24l0MYdUogHQjIWWaw1eyuKA9 tU0mDuExa6YqhHHyVNIEbXJBwwhB5RfYfjI/9cN5RTHsnlNp+aQnXyq1xib4n8X3CPBV l0tWFKoxVPlTXmqY85vAPcWT4A5ccH32tKg1LiYQHHcxrJZWHymns7tDqJsFRE76dFeI dC4lXDHIWszMKtso6F18VMExtVhtUUdHft0j2EfQ7UGOvvfjBFNQ04krSac0fPSITwnD N9Fw== X-Gm-Message-State: ALoCoQktz84pw1SJC5GdoSOSIIQJZa7mwQHUOllBl6PoBRrCyenb6A7aSejCOBBKpJJPosAtwVTi X-Received: by 10.194.79.225 with SMTP id m1mr5935019wjx.8.1435348300721; Fri, 26 Jun 2015 12:51:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.95.211 with HTTP; Fri, 26 Jun 2015 12:51:01 -0700 (PDT) In-Reply-To: <20150626194734.GA31681@LK-Perkele-VII> References: <2AA11887-2F82-48EF-BD45-4D85CFA83847@qut.edu.au> <20150617082529.GA17280@LK-Perkele-VII> <20150617150505.GA19959@LK-Perkele-VII> <20150626085008.GA25187@LK-Perkele-VII> <20150626194734.GA31681@LK-Perkele-VII> From: Eric Rescorla Date: Fri, 26 Jun 2015 12:51:01 -0700 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=047d7b10c90397fa35051971115c Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Computation of static secret in anonymous 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, 26 Jun 2015 19:51:44 -0000 --047d7b10c90397fa35051971115c Content-Type: text/plain; charset=UTF-8 On Fri, Jun 26, 2015 at 12:47 PM, Ilari Liusvaara < ilari.liusvaara@elisanet.fi> wrote: > On Fri, Jun 26, 2015 at 12:31:01PM -0700, Eric Rescorla wrote: > > Note: I have updated the WIP (and that's what I sent to Hugo) so it now > > contains the > > changes the values Hugo describes. > > Small nit: > > master_secret= HKDF(xSS, xES, "master secret") > > Should that be: > > master_secret= HKDF(xSS, xES, "master secret", L) > > (the length parameter is seemingly missing)? > Yes, thanks for the correction. > > Also, is that label NUL-terminated or not (I think it is)? Another > reason why I think it is not a good idea to use notes to change > meaning of explcit algorithms... They are all NUL-terminated. I'm happy to add a wrapper as you suggest, just haven't gotten to it yet. -Ekr > > > -Ilari > --047d7b10c90397fa35051971115c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jun 26, 2015 at 12:47 PM, Ilari Liusvaara <= ;ilari.liu= svaara@elisanet.fi> wrote:
= On Fri, Jun 26, 2015 at 12:31:01PM -0700, Eric Rescorla wr= ote:
> Note: I have updated the WIP (and that's what I sent to Hugo) so i= t now
> contains the
> changes the values Hugo describes.

Small nit:

master_secret=3D HKDF(xSS, xES, "master secret")

Should that be:

master_secret=3D HKDF(xSS, xES, "master secret", L)

(the length parameter is seemingly missing)?

Yes, thanks for the correction.

=C2=A0
=

Also, is that label NUL-terminated or not (I think it is)? Another
reason why I think it is not a good idea to use notes to change
meaning of explcit algorithms...

They are a= ll NUL-terminated.

I'm happy to add a wrapper = as you suggest, just haven't gotten to it yet.

-Ekr




-Ilari

--047d7b10c90397fa35051971115c-- From nobody Fri Jun 26 13:47: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 9B4C61ACD66 for ; Fri, 26 Jun 2015 13:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.034 X-Spam-Level: * X-Spam-Status: No, score=1.034 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, 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 aIEKHO7kDi5J for ; Fri, 26 Jun 2015 13:47:35 -0700 (PDT) Received: from homiemail-a110.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id B61781ACD83 for ; Fri, 26 Jun 2015 13:47:35 -0700 (PDT) Received: from homiemail-a110.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a110.g.dreamhost.com (Postfix) with ESMTP id 7228920058D39; Fri, 26 Jun 2015 13:47:35 -0700 (PDT) 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:content-transfer-encoding; s= cryptonector.com; bh=q0iyingMsS60rZ5YGXONkKxtmZg=; b=pQU6skktQIN yoT8bWQWp6QHVadXgTlqntxIulFg4MpfX5W4QgMfh5WEs4wtpVaQqq+/ZxBfnUxy UPEv6WgVRRaplroKHmwy1G95/M4AbpxPTyE/sNpBLKenoyrHdOEmDWW2hsPUO4ZG L+Hk5icviOHtIvfikT1RvVq3bWo/wp7s= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a110.g.dreamhost.com (Postfix) with ESMTPA id 30FAA20058D36; Fri, 26 Jun 2015 13:47:33 -0700 (PDT) Date: Fri, 26 Jun 2015 15:47:32 -0500 From: Nico Williams To: David Benjamin Message-ID: <20150626204731.GJ6117@localhost> References: <201506111558.21577.davemgarrett@gmail.com> <20150616233111.GD6117@localhost> <201506170131.17179.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "" Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 26 Jun 2015 20:47:36 -0000 On Fri, Jun 26, 2015 at 07:02:32PM +0000, David Benjamin wrote: > On Wed, Jun 17, 2015 at 1:31 AM Dave Garrett w= rote: > > >=20 > I have the same concerns with this version as before. I don=E2=80=99t b= elieve it > lowers the risk of accidental interop failure---if anything, it makes i= t > worse. >=20 > This scheme is still a problem for Chrome on Windows XP. This proposal > effectively makes ECDSA (and ECDHE) MTI for any clients doing the stand= ard > PKI-based handshake. Whether or not this is desirable, it certainly sho= uld > be spelled out clearly in the spec. >=20 > Imagine how implementations look. Most allow configuring the cipher sui= te > list. This now interacts subtly with configuring 1.3 ciphers, and we ha= ve > the same interop risks of a parallel extension. What if the consumer, f= or > whatever reason, omitted the ECDHE_ECDSA variant of some AEAD but inclu= ded > ECDHE_RSA? Now 1.2 servers work, 1.3 ones don=E2=80=99t. Alright, so wh= at if we > internally checked for consistency? That=E2=80=99s fine, but we could j= ust as > easily have checked for consistency between 1.2 cipher suites and a new= 1.3 > mechanism. This can be fixed by having signalling cipher suite assignments for negotiating a cartesian product of them (in addition to any actual cipher suites offered). This allows for a) compression of negotiation, b) fallback support for 1.2, 1.1, and 1.0, and c) expression of preference for specific cipher suites ahead of (or after) the cartesian product cipher suites. We'd still end up with a cartesian product in the registry, but missing registrations implied by the negotiation signalling cipher suites could still work. > If the worry is state-machine bugs due to PKI and PSK key exchanges bei= ng > different, we won=E2=80=99t guard against them by separating > ECDHE_PSK_WITH_AES_128_GCM_SHA256 from ECDHE_ECDSA_WITH_AES_128_GCM_SHA= 256. > No one would make ECDHE_PSK_WITH_AES_128_GCM_SHA256 use a codepath from > ECDHE_PSK_WITH_CHACHA20_POLY1305, so sufficiently similar cipher suites > will be funneled together anyway. +1 From nobody Fri Jun 26 13:56: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 9C94B1ACDCD for ; Fri, 26 Jun 2015 13:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 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, 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 9VywOsqU5z7K for ; Fri, 26 Jun 2015 13:56:25 -0700 (PDT) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::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 B51E31ACDB6 for ; Fri, 26 Jun 2015 13:56:24 -0700 (PDT) Received: by igblr2 with SMTP id lr2so21070031igb.0 for ; Fri, 26 Jun 2015 13:56:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=AWr4JF6GmIxvvaLf9fJkMr3rHg/bZyJ05w6qrAehP6M=; b=hGqR1BYNWf81ePafKgChtMNR5mAeHR0x3Zvhe8zBvfN6eJJV4GqvqXmjlqOtpXp2rd C5mC8T1Pt3IP24klfPeoknN8GVYKclpn0NxDtUG1dJ8R4Ei5Euo33U3kGhNdqkBWTPY0 MwDJmua68lHpAeYrjkDOj8sLwMcZlwsIiMbW4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=AWr4JF6GmIxvvaLf9fJkMr3rHg/bZyJ05w6qrAehP6M=; b=UHx/sV7CXH54+2vXigD+hiazQXCtkiVGNzX4+BuSpp46NVR8H8691JoSN+WoQ+DQkk r82wvxbtYleQ96M+uRNoGZGvhO2b0efIxYE+QOFHLvk2UfYGhcC5H6qc2lzOLZ9IsuKb pPc/F64FuW9OI8dflSbpPMnt5XjPRdXjMJ+TkwOp1cTO4xJTuQGXIFnfJDuOjq7pYVv4 JCgXl39JzFelAOC2Rm1A0yGo0zFVNPXjvMfNPVAbRUS4q5HvkBWfmuJJTUsOcW5f13JY s3+Yr4Tl0GjXVO5GHrY5MwlsAh5hh6cVCjF52x+pnStCvmPNHkKJRwqXy/2WLX6BwnfM Z6oQ== X-Gm-Message-State: ALoCoQn1GBIt/8QdaO4vY0SXbY6w3U4qHCW4sPjU1LVrBmEjj5t/OK7w/nOMwhLnXDe5/xHmnhqs X-Received: by 10.42.131.202 with SMTP id a10mr5664069ict.49.1435352184210; Fri, 26 Jun 2015 13:56:24 -0700 (PDT) MIME-Version: 1.0 References: <201506111558.21577.davemgarrett@gmail.com> <20150616233111.GD6117@localhost> <201506170131.17179.davemgarrett@gmail.com> In-Reply-To: From: David Benjamin Date: Fri, 26 Jun 2015 20:56:14 +0000 Message-ID: To: Dave Garrett , Nico Williams Content-Type: multipart/alternative; boundary=bcaec55237801169d3051971f90a Archived-At: Cc: "" Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 26 Jun 2015 20:56:27 -0000 --bcaec55237801169d3051971f90a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable [Oops. I sent this from the wrong address the first time so it didn't get through to the broader list. Apologies for messing up the threading.] On Fri, Jun 26, 2015 at 3:02 PM David Benjamin wrote: > On Wed, Jun 17, 2015 at 1:31 AM Dave Garrett > wrote: > >> [snip] > > >> Ok, I revised the drafts and forked the anon deprecation changeset. >> >> Main draft proposal: >> >> https://github.com/davegarrett/tls13-spec/blob/alacarte/draft-ietf-tls-t= ls13.md#cipher-suites-in-tls-13 >> >> Version with deprecated anon suites: >> >> https://github.com/davegarrett/tls13-spec/blob/alacarte-noanonsuites/dra= ft-ietf-tls-tls13.md#anonymous-key-exchange >> >> Note that both totally deprecate all DH(E) suites, as that's one of the >> goals here. (due to weak DH params, old Java choking, & etc.) Thus, all >> suites must be ECDHE prefixed for TLS 1.3 support under these proposals >> (with the exception of plain PSK). All ECDHE suites would be capable of >> negotiating either ECDHE or DHE using string groups via the extension. >> >> PSK & anon will need a litany of new ECDHE suites to be defined. There i= s >> currently no ECDHE AEAD anon suite, thus none supporting TLS 1.3 (among = the >> reasons I pursued the idea of merging it into PSK). >> >> I'm fine with relegating the anon deprecation idea to the bin if we agre= e >> to define all the new suites we need to maintain support. Getting >> ECDHE_anon into the ChaChaPoly draft would be a start. >> > > I have the same concerns with this version as before. I don=E2=80=99t bel= ieve it > lowers the risk of accidental interop failure---if anything, it makes it > worse. > > This scheme is still a problem for Chrome on Windows XP. This proposal > effectively makes ECDSA (and ECDHE) MTI for any clients doing the standar= d > PKI-based handshake. Whether or not this is desirable, it certainly shoul= d > be spelled out clearly in the spec. > > Imagine how implementations look. Most allow configuring the cipher suite > list. This now interacts subtly with configuring 1.3 ciphers, and we have > the same interop risks of a parallel extension. What if the consumer, for > whatever reason, omitted the ECDHE_ECDSA variant of some AEAD but include= d > ECDHE_RSA? Now 1.2 servers work, 1.3 ones don=E2=80=99t. Alright, so what= if we > internally checked for consistency? That=E2=80=99s fine, but we could jus= t as > easily have checked for consistency between 1.2 cipher suites and a new 1= .3 > mechanism. > > A separate extension avoids any mixing of semantics and gives a clean > break from the old pre-multiplied scheme. > > As for what this extension contains, I don=E2=80=99t have strong opinions= over > whether we go a la carte---pruning down to the GCMs and CHACHA would also > address the explosion---but if we bother, it seems a list of AEAD or > AEAD+PRF is correct. The key exchange is already consistently separated > from the bulk cipher in TLS. It's a waste to ignore the one clear boundar= y > that we actually have. > > If the worry is state-machine bugs due to PKI and PSK key exchanges being > different, we won=E2=80=99t guard against them by separating > ECDHE_PSK_WITH_AES_128_GCM_SHA256 from ECDHE_ECDSA_WITH_AES_128_GCM_SHA25= 6. > No one would make ECDHE_PSK_WITH_AES_128_GCM_SHA256 use a codepath from > ECDHE_PSK_WITH_CHACHA20_POLY1305, so sufficiently similar cipher suites > will be funneled together anyway. > > David > --bcaec55237801169d3051971f90a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
[Oops. I sent this from the wrong address the first time s= o it didn't get through to the broader list. Apologies for messing up t= he threading.]

On Fri, J= un 26, 2015 at 3:02 PM David Benjamin <davidben@google.com> wrote:
On Wed, = Jun 17, 2015 at 1:31 AM Dave Garrett <davemgarrett@gmail.com> wrote:
[snip]

Ok, I revised the drafts and forked the anon deprecation changeset.

Main draft proposal:
https://github.com/davegarrett/tls13-spec/blob/alacarte/draft-ietf-tls-t= ls13.md#cipher-suites-in-tls-13

Version with deprecated anon suites:
https://github.com/davegarrett/tls13-spec/blob/alacarte-noan= onsuites/draft-ietf-tls-tls13.md#anonymous-key-exchange

Note that both totally deprecate all DH(E) suites, as that's one of the= goals here. (due to weak DH params, old Java choking, & etc.) Thus, al= l suites must be ECDHE prefixed for TLS 1.3 support under these proposals (= with the exception of plain PSK). All ECDHE suites would be capable of nego= tiating either ECDHE or DHE using string groups via the extension.

PSK & anon will need a litany of new ECDHE suites to be defined. There = is currently no ECDHE AEAD anon suite, thus none supporting TLS 1.3 (among = the reasons I pursued the idea of merging it into PSK).

I'm fine with relegating the anon deprecation idea to the bin if we agr= ee to define all the new suites we need to maintain support. Getting ECDHE_= anon into the ChaChaPoly draft would be a start.

David
--bcaec55237801169d3051971f90a-- From nobody Fri Jun 26 14:12: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 BFECA1A8794 for ; Fri, 26 Jun 2015 14:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 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, 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 pj0pcPLCuTxK for ; Fri, 26 Jun 2015 14:12:53 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001: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 220D41A876B for ; Fri, 26 Jun 2015 14:12:53 -0700 (PDT) Received: by iebmu5 with SMTP id mu5so83333793ieb.1 for ; Fri, 26 Jun 2015 14:12:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=gf26hGf+GPQsYVg+LT6lg1wKX1b/54xljFU3KsBn6+Q=; b=jyALsr1g3DNxGsDbA1pmUNb6lPfvYgTG2JEMrMqcTIlbMBD/aTK5GMkQ+smg1Kq/lU /2qjAma8ongzsmftdLuC/cQQvAO/L5GMPP6O03z4Nj6i93bosuzq+5zaaI4ks3PDF39E rO5D/ptCQkYkn/2waEsFP+zOnmLRimklKYx78= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=gf26hGf+GPQsYVg+LT6lg1wKX1b/54xljFU3KsBn6+Q=; b=UXYEPwrrjY3ZCK5P3Cvu/uxG/mNBz8FsjxmKZKvhzm//YA+psTj7coulS4dL4eKZ4i VeTB9VFlcjHYn5NWa6de2XXXlkKX2kppz7G9FEzZrI3qZMYv3kth68HM354kQtehIIaZ J+Kp42ijLofDED0eAqLaauAB+tXsIeFuH+WKSKl1uNgDpAQK1ckzoGizr2Alc1evX9e/ DxgAZfcaxX5z3P+QaOxdJSR5+5XqkO0Sm9moEEIDNiPOLCA5+dXw5mZ5GR8+tH2y5h1i SOK0U326Cv4ad+iAuDfvrRYTiWOeHsCB+ONXQO4e7/E263x1tgfDP8U9tr6YecCg2+Jl sUrA== X-Gm-Message-State: ALoCoQljupDG4jsXUYkd7cZ8rPSLYRc+yalPP5a1MYFUdu/Qe3AuHgXD35Zb0UDCof7LlGMJTKnE X-Received: by 10.107.136.214 with SMTP id s83mr5112497ioi.65.1435353172599; Fri, 26 Jun 2015 14:12:52 -0700 (PDT) MIME-Version: 1.0 References: <201506111558.21577.davemgarrett@gmail.com> <20150616233111.GD6117@localhost> <201506170131.17179.davemgarrett@gmail.com> <20150626204731.GJ6117@localhost> In-Reply-To: <20150626204731.GJ6117@localhost> From: David Benjamin Date: Fri, 26 Jun 2015 21:12:43 +0000 Message-ID: To: Nico Williams Content-Type: multipart/alternative; boundary=001a113eb2a6fb0a0305197233a6 Archived-At: Cc: "" Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 26 Jun 2015 21:12:54 -0000 --001a113eb2a6fb0a0305197233a6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jun 26, 2015 at 4:47 PM Nico Williams wrote= : > On Fri, Jun 26, 2015 at 07:02:32PM +0000, David Benjamin wrote: > > On Wed, Jun 17, 2015 at 1:31 AM Dave Garrett > wrote: > > > > > > > I have the same concerns with this version as before. I don=E2=80=99t b= elieve it > > lowers the risk of accidental interop failure---if anything, it makes i= t > > worse. > > > > This scheme is still a problem for Chrome on Windows XP. This proposal > > effectively makes ECDSA (and ECDHE) MTI for any clients doing the > standard > > PKI-based handshake. Whether or not this is desirable, it certainly > should > > be spelled out clearly in the spec. > > > > Imagine how implementations look. Most allow configuring the cipher sui= te > > list. This now interacts subtly with configuring 1.3 ciphers, and we ha= ve > > the same interop risks of a parallel extension. What if the consumer, f= or > > whatever reason, omitted the ECDHE_ECDSA variant of some AEAD but > included > > ECDHE_RSA? Now 1.2 servers work, 1.3 ones don=E2=80=99t. Alright, so wh= at if we > > internally checked for consistency? That=E2=80=99s fine, but we could j= ust as > > easily have checked for consistency between 1.2 cipher suites and a new > 1.3 > > mechanism. > > This can be fixed by having signalling cipher suite assignments for > negotiating a cartesian product of them (in addition to any actual > cipher suites offered). This allows for a) compression of negotiation, > b) fallback support for 1.2, 1.1, and 1.0, and c) expression of > preference for specific cipher suites ahead of (or after) the cartesian > product cipher suites. > > We'd still end up with a cartesian product in the registry, but missing > registrations implied by the negotiation signalling cipher suites could > still work. > Hrm. I might not understanding you right, isn't that roughly the same as defining new values: TLS_ECDHE_CERT_WITH_AES_128_GCM_SHA256 TLS_ECDHE_CERT_WITH_CHACHA20_POLY1305 etc. ("CERT" being an unopinionated placeholder for the result of the inevitable bikeshedding over the name. :-) ) and saying that TLS 1.3 uses those rather than either ECDHE_RSA or ECDHE_ECDSA, but they share a namespace with the pre-1.3 cipher suite list for convenience and avoiding a new extension? That seems reasonable to me actually. If we avoid weird pre-1.3 interactions, I don't have opinions on new extension vs camping out in the old namespace. Or is the goal that, by accepting both ECDHE_CERT and ECDHE_ECDSA, the common case can send a slightly shorter ClientHello? (For Chrome I think it'd be four bytes because we only do two AEADs.) David --001a113eb2a6fb0a0305197233a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 26= , 2015 at 4:47 PM Nico Williams <nico@cryptonector.com> wrote:
On Fri, Jun 26, 2015 at 07:02:32PM +0000, David Benja= min wrote:
> On Wed, Jun 17, 2015 at 1:31 AM Dave Garrett <davemgarrett@gmail.com> wrote= :
> >
>
> I have the same concerns with this version as before. I don=E2=80=99t = believe it
> lowers the risk of accidental interop failure---if anything, it makes = it
> worse.
>
> This scheme is still a problem for Chrome on Windows XP. This proposal=
> effectively makes ECDSA (and ECDHE) MTI for any clients doing the stan= dard
> PKI-based handshake. Whether or not this is desirable, it certainly sh= ould
> be spelled out clearly in the spec.
>
> Imagine how implementations look. Most allow configuring the cipher su= ite
> list. This now interacts subtly with configuring 1.3 ciphers, and we h= ave
> the same interop risks of a parallel extension. What if the consumer, = for
> whatever reason, omitted the ECDHE_ECDSA variant of some AEAD but incl= uded
> ECDHE_RSA? Now 1.2 servers work, 1.3 ones don=E2=80=99t. Alright, so w= hat if we
> internally checked for consistency? That=E2=80=99s fine, but we could = just as
> easily have checked for consistency between 1.2 cipher suites and a ne= w 1.3
> mechanism.

This can be fixed by having signalling cipher suite assignments for
negotiating a cartesian product of them (in addition to any actual
cipher suites offered).=C2=A0 This allows for a) compression of negotiation= ,
b) fallback support for 1.2, 1.1, and 1.0, and c) expression of
preference for specific cipher suites ahead of (or after) the cartesian
product cipher suites.

We'd still end up with a cartesian product in the registry, but missing=
registrations implied by the negotiation signalling cipher suites could
still work.

Hrm. I might not understanding you right, isn't that roughl= y the same as defining new values:

=C2=A0 TLS_ECDHE_CERT_WITH_AES_12= 8_GCM_SHA256
=C2=A0 TLS_ECDHE_CERT_WITH_CHACHA20_POLY1305
=C2=A0 etc.=
=C2=A0 ("CERT" being an unopinionated placeholder for = the result of the inevitable bikeshedding over the name. :-) )

and s= aying that TLS 1.3 uses those rather than either ECDHE_RSA or ECDHE_ECDSA, = but they share a namespace with the pre-1.3 cipher suite list for convenien= ce and avoiding a new extension? That seems reasonable to me actually. If w= e avoid weird pre-1.3 interactions, I don't have opinions on new extens= ion vs camping out in the old namespace.

Or is the goal that, by acc= epting both ECDHE_CERT and ECDHE_ECDSA, the common case can send a slightly= shorter ClientHello? (For Chrome I think it'd be four bytes because we= only do two AEADs.)


David
--001a113eb2a6fb0a0305197233a6-- From nobody Fri Jun 26 15:15: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 48FE21ACE12 for ; Fri, 26 Jun 2015 15:15:00 -0700 (PDT) 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 E5GDwjCvVd-E for ; Fri, 26 Jun 2015 15:14:59 -0700 (PDT) Received: from homiemail-a109.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 74CBC1ACE11 for ; Fri, 26 Jun 2015 15:14:59 -0700 (PDT) Received: from homiemail-a109.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a109.g.dreamhost.com (Postfix) with ESMTP id 1E3E52005DD02; Fri, 26 Jun 2015 15:14:59 -0700 (PDT) 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=PV/NxlztpWDz47 SYQjsi62MVYwE=; b=EENNml94GoG0pXixNSMHkAvk8cMpZb2peMPQ36/9nqLisn FceJgktonmNl6Ux81rX5FKrZ5629W2IHmnWyBGlOiKnmfhuio6PkvtDYD2JoK7gy uaxrddGOqmgNGc4eDack6L4RsfZzdIajkzRnl4K9jmVcSuMDQSMbgjVYQ2BxA= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a109.g.dreamhost.com (Postfix) with ESMTPA id 8AD022005DD00; Fri, 26 Jun 2015 15:14:58 -0700 (PDT) Date: Fri, 26 Jun 2015 17:14:57 -0500 From: Nico Williams To: David Benjamin Message-ID: <20150626221456.GK6117@localhost> References: <201506111558.21577.davemgarrett@gmail.com> <20150616233111.GD6117@localhost> <201506170131.17179.davemgarrett@gmail.com> <20150626204731.GJ6117@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: Cc: "" Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 26 Jun 2015 22:15:00 -0000 On Fri, Jun 26, 2015 at 09:12:43PM +0000, David Benjamin wrote: > On Fri, Jun 26, 2015 at 4:47 PM Nico Williams wrote: > > This can be fixed by having signalling cipher suite assignments for > > negotiating a cartesian product of them (in addition to any actual > > cipher suites offered). [...] > > Hrm. I might not understanding you right, isn't that roughly the same as > defining new values: > > [...] > > and saying that TLS 1.3 uses those rather than either ECDHE_RSA or > ECDHE_ECDSA, but they share a namespace with the pre-1.3 cipher suite list > for convenience and avoiding a new extension? That seems reasonable to me > actually. If we avoid weird pre-1.3 interactions, I don't have opinions on > new extension vs camping out in the old namespace. Yes, they'd share the same cipher suite number (and name) namespace. Pre-1.3 implementations would ignore these "new" cipher suites, which is why still sending some old ones is important for interop. Using an extension loses the ability to express old vs. new cipher suite relative priorities. That might not be a problem (with 1.3<->1.3 using only the new thing), and if no one cares, then I wouldn't either. > Or is the goal that, by accepting both ECDHE_CERT and ECDHE_ECDSA, the > common case can send a slightly shorter ClientHello? (For Chrome I think > it'd be four bytes because we only do two AEADs.) There's two different goals here: 1) "Compress" the ClientHello; 2) (maybe!) reduce the amount of bookkeeping to do in the cipher suite registry. (2) is easier if we go with an extension instead of camping on the cipher suite namespace. We've failed to register useful cipher suites before. We can probably fix this anyways by writing tools for IANA to do the cartesian product so that it's never again a manual process for RFC authors nor for IANA. Elegance would also be a goal, except that it's too late for that. Nico -- From nobody Fri Jun 26 15: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 882731AD0BF for ; Fri, 26 Jun 2015 15:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 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, 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 NOCtSGJvvfze for ; Fri, 26 Jun 2015 15:40:26 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (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 D9DDF1ACE80 for ; Fri, 26 Jun 2015 15:40:25 -0700 (PDT) Received: by igblr2 with SMTP id lr2so22599177igb.0 for ; Fri, 26 Jun 2015 15:40:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=x0lRc8slmCrf28+UgruRB96IF98J9vuofhfCGiZ9YnQ=; b=Xom4mBdEgloNBROIvvEBF5R87Y8elXNeXM6cYshMFg4cgI30BS/a3pMZ8xvkch+POU wtpHq7p2WVPeUUttwlnFI3w8DI47YJmBigFzEKjHAu4gQWDDH/JbLoj/o0n50LWG5q8e V6aBBT/2hvi8VAVnOCiEqw8NQYeBLSZdhu6cU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=x0lRc8slmCrf28+UgruRB96IF98J9vuofhfCGiZ9YnQ=; b=Vtj4DKus8beCKmUbsA1RKOwbRk+RAZDtAEXsmTv2tBYSbU93jdaV5QeOiMnd2bs0uL rod3IMwbO4Hir8pS+HiAAI/ouNKGBJvHQMYWYwvgcH/lt2AyK3gKBdu1HvQgDykX3tlp lGttW/6MDBTtAx6BBY6g0k5KSaak8ElTusfoH5RXU0BrOkvsB6TNloAM0BnrU+UjjvcV VzDFrXu/kVV6DVrOwoILhlnjZapGX23wr/ozPqTtZ5jxM9Rj1ArFvoSRxfRojpTRLyn7 ZiUcZiYjc7H95kdpR8GovnKM0SfKklzTsOdhoKN/2lj09n9Th8nmmSYTy8hhtYLaf7z4 PX/g== X-Gm-Message-State: ALoCoQnwoMk4Ppt3QmwdPpud1JI1nVb/Ei//12rBzQBH96e295cWeeiEzCqhD9kIwZEgS2WAtD2v X-Received: by 10.50.61.130 with SMTP id p2mr554278igr.9.1435358424948; Fri, 26 Jun 2015 15:40:24 -0700 (PDT) MIME-Version: 1.0 References: <201506111558.21577.davemgarrett@gmail.com> <20150616233111.GD6117@localhost> <201506170131.17179.davemgarrett@gmail.com> <20150626204731.GJ6117@localhost> <20150626221456.GK6117@localhost> In-Reply-To: <20150626221456.GK6117@localhost> From: David Benjamin Date: Fri, 26 Jun 2015 22:40:15 +0000 Message-ID: To: Nico Williams Content-Type: multipart/alternative; boundary=047d7bdcaa0e0b9a170519736d57 Archived-At: Cc: "" Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 26 Jun 2015 22:40:27 -0000 --047d7bdcaa0e0b9a170519736d57 Content-Type: text/plain; charset=UTF-8 On Fri, Jun 26, 2015 at 6:15 PM Nico Williams wrote: > On Fri, Jun 26, 2015 at 09:12:43PM +0000, David Benjamin wrote: > > On Fri, Jun 26, 2015 at 4:47 PM Nico Williams > wrote: > > > This can be fixed by having signalling cipher suite assignments for > > > negotiating a cartesian product of them (in addition to any actual > > > cipher suites offered). [...] > > > > Hrm. I might not understanding you right, isn't that roughly the same as > > defining new values: > > > > [...] > > > > and saying that TLS 1.3 uses those rather than either ECDHE_RSA or > > ECDHE_ECDSA, but they share a namespace with the pre-1.3 cipher suite > list > > for convenience and avoiding a new extension? That seems reasonable to me > > actually. If we avoid weird pre-1.3 interactions, I don't have opinions > on > > new extension vs camping out in the old namespace. > > Yes, they'd share the same cipher suite number (and name) namespace. > > Pre-1.3 implementations would ignore these "new" cipher suites, which is > why still sending some old ones is important for interop. > > Using an extension loses the ability to express old vs. new cipher suite > relative priorities. That might not be a problem (with 1.3<->1.3 using > only the new thing), and if no one cares, then I wouldn't either. > I was assuming there would never be a reason to order 1.3 and 1.2's mechanisms, yeah. If it's a new extension, only use that new extension and we just ignore the 1.2 cipher suite list once 1.3 is set. If it's camping out in the cipher suite list, anything not in 1.3 should be ignored once 1.3 is set. (Amusingly, if we use the same namespace but use completely non-overlapping values, it might be safer to put the 1.3 ciphers *after* the 1.2 ones. I've gotten a bug report about a server that only pays attention to the second byte of every cipher suite value. Or perhaps it thought cipher suites were one byte. Anyway, I don't actually think this is worth bothering about, just a funny/sad story. It's only been the one report and I declined to do anything for it.) David > > Or is the goal that, by accepting both ECDHE_CERT and ECDHE_ECDSA, the > > common case can send a slightly shorter ClientHello? (For Chrome I think > > it'd be four bytes because we only do two AEADs.) > > There's two different goals here: > > 1) "Compress" the ClientHello; > 2) (maybe!) reduce the amount of bookkeeping to do in the cipher suite > registry. > > (2) is easier if we go with an extension instead of camping on the > cipher suite namespace. > > We've failed to register useful cipher suites before. We can probably > fix this anyways by writing tools for IANA to do the cartesian product > so that it's never again a manual process for RFC authors nor for IANA. > > Elegance would also be a goal, except that it's too late for that. > > Nico > -- > --047d7bdcaa0e0b9a170519736d57 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 26= , 2015 at 6:15 PM Nico Williams <nico@cryptonector.com> wrote:
On Fri, Jun 26, 2015 at 09:12:43PM +0000, David Benjamin wrote:
> On Fri, Jun 26, 2015 at 4:47 PM Nico Williams <nico@cryptonector.com> wrote:=
> > This can be fixed by having signalling cipher suite assignments f= or
> > negotiating a cartesian product of them (in addition to any actua= l
> > cipher suites offered).=C2=A0 [...]
>
> Hrm. I might not understanding you right, isn't that roughly the s= ame as
> defining new values:
>
>=C2=A0 =C2=A0[...]
>
> and saying that TLS 1.3 uses those rather than either ECDHE_RSA or
> ECDHE_ECDSA, but they share a namespace with the pre-1.3 cipher suite = list
> for convenience and avoiding a new extension? That seems reasonable to= me
> actually. If we avoid weird pre-1.3 interactions, I don't have opi= nions on
> new extension vs camping out in the old namespace.

Yes, they'd share the same cipher suite number (and name) namespace.
Pre-1.3 implementations would ignore these "new" cipher suites, w= hich is
why still sending some old ones is important for interop.

Using an extension loses the ability to express old vs. new cipher suite relative priorities.=C2=A0 That might not be a problem (with 1.3<->1.= 3 using
only the new thing), and if no one cares, then I wouldn't either.

I was assuming there would never be a reason to order 1= .3 and 1.2's mechanisms, yeah. If it's a new extension, only use th= at new extension and we just ignore the 1.2 cipher suite list once 1.3 is s= et. If it's camping out in the cipher suite list, anything not in 1.3 s= hould be ignored once 1.3 is set.

(Amusingly, if we use the same nam= espace but use completely non-overlapping values, it might be safer to put = the 1.3 ciphers *after* the 1.2 ones. I've gotten a bug report about a = server that only pays attention to the second byte of every cipher suite va= lue. Or perhaps it thought cipher suites were one byte. Anyway, I don't= actually think this is worth bothering about, just a funny/sad story. It&#= 39;s only been the one report and I declined to do anything for it.)
David
=C2=A0
> Or is the goal that, by accepting both ECDHE_CERT and ECDHE_ECDSA, the=
> common case can send a slightly shorter ClientHello? (For Chrome I thi= nk
> it'd be four bytes because we only do two AEADs.)

There's two different goals here:

1) "Compress" the ClientHello;
2) (maybe!) reduce the amount of bookkeeping to do in the cipher suite
=C2=A0 =C2=A0registry.

(2) is easier if we go with an extension instead of camping on the
cipher suite namespace.

We've failed to register useful cipher suites before.=C2=A0 We can prob= ably
fix this anyways by writing tools for IANA to do the cartesian product
so that it's never again a manual process for RFC authors nor for IANA.=

Elegance would also be a goal, except that it's too late for that.

Nico
--
--047d7bdcaa0e0b9a170519736d57-- From nobody Fri Jun 26 16: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 4FB311B2B1F for ; Fri, 26 Jun 2015 16:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_34=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7uT-Z0hDpu5q for ; Fri, 26 Jun 2015 16:18:51 -0700 (PDT) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (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 137F71B2B1E for ; Fri, 26 Jun 2015 16:18:51 -0700 (PDT) Received: by ykdy1 with SMTP id y1so71825160ykd.2 for ; Fri, 26 Jun 2015 16:18:50 -0700 (PDT) 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=eXMeFFmPdF7Xu0ReSb+vS6497N3Aemnxk2PDkMHa3sk=; b=jihZ1T7mIYWRCvgW4Ovtv9AA9WYjx0w8sb1Mutm7hJazFGbWFwQ7flRxWf+gl72PFf kVw1TrpR4BYI3rSfCTKUAjyCVkgVtYZIlHy8Mssc9jsXAxCrLIxbS6C6kWS1T1RCnDvJ LEz7IPc8ee1Wir2xqqW1rQ2FCWpUIPuofmhjksiEpXhyDZwVzXhr6+UxGsJ1gcIu+q9i 70UrWRKCVuu1DjBV3ym955kGJNmnTi5BWqlGyXMR5OBEfVkCA7ZAt8SYHhP8pl732arh ZBnGVk0UOEP580UbCNSUchLOHtolVXyR79ByhMNqeMg/+zJXJek4RINjEt2Um6BME8Bm 3QBg== X-Received: by 10.129.7.214 with SMTP id 205mr4940430ywh.133.1435360730362; Fri, 26 Jun 2015 16:18:50 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id w6sm27518307ywf.31.2015.06.26.16.18.49 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 26 Jun 2015 16:18:49 -0700 (PDT) From: Dave Garrett To: David Benjamin Date: Fri, 26 Jun 2015 19:18:47 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201506111558.21577.davemgarrett@gmail.com> <201506170131.17179.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201506261918.48332.davemgarrett@gmail.com> Archived-At: Cc: "" Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 26 Jun 2015 23:18:52 -0000 On Friday, June 26, 2015 03:02:32 pm David Benjamin wrote: > This scheme is still a problem for Chrome on Windows XP. This proposal > effectively makes ECDSA (and ECDHE) MTI for any clients doing the standard > PKI-based handshake. Whether or not this is desirable, it certainly should > be spelled out clearly in the spec. In the current draft proposal, ECDSA cipher suites are mandatory for TLS 1.= 3, but endpoints are not required to support ECDSA (extension does negotiat= ion). Support expectation is clear: "SHOULD offer at least one ECDHE group = and SHOULD offer support for ECDSA". Clients on EOL OSes without ECC that don't have their own ECC implementatio= ns are broken. We shouldn't even consider trying to compensate for this in = the spec. To implement the new spec, you have to write a new implementation= , so no, relying on an old EOL OS implementation for a part of it into your= implementation is not guaranteed to be enough. Vendors still doing this wi= ll need to either decide to actually implement things themselves or only su= pport capable OSes. > A separate extension avoids any mixing of semantics and gives a clean bre= ak > from the old pre-multiplied scheme. Indeed. Again, I do not oppose this route. If we can agree on this, I have = no problem with dropping my current approach to switch to it. It is, however, a total break from cipher suites, which could make assessin= g configurations with mixed TLS version support a bit more complicated. Kee= ping bulk cipher negotiation in suites makes keeping track of server bulk c= ipher support a little easier. > As for what this extension contains, I don=E2=80=99t have strong opinions= over > whether we go a la carte---pruning down to the GCMs and CHACHA would also > address the explosion---but if we bother, it seems a list of AEAD or > AEAD+PRF is correct. I think the best way to do this would be one byte for selecting the AEAD ci= pher and a second byte for selecting a key+hash size combination. This coul= d be very helpful in the future when SHA3 and future new hashes get deploye= d, as anything would be capable of negotiating it if an appropriate size is= available. Separating these two would give us full a la carte, which could= be very helpful, but is also of course more complex. Dave From nobody Fri Jun 26 16:24: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 E65401B2B42 for ; Fri, 26 Jun 2015 16:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TvrE1m6XNcb for ; Fri, 26 Jun 2015 16:24:26 -0700 (PDT) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (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 515631B2B41 for ; Fri, 26 Jun 2015 16:24:26 -0700 (PDT) Received: by ykfy125 with SMTP id y125so71961903ykf.1 for ; Fri, 26 Jun 2015 16:24:25 -0700 (PDT) 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=44DEDhoHlw4NwbSkLQ1zz9zJbw08DC94aZW/jyzFayU=; b=sBowulYZK+SYZYskRIdN9wT+bWV7b50pDUm1Hlc0LswYSbDEJ8HDmFsgKp/Eae2dF/ V5Vu+5JCGzNiif5Dhdbi0h0Hjm1XYe91VBPKpQ1BoEVxfXdR3wW6cxuEYJy7lAgdP+Bc oAT4V8rMKJ74KS9R0D+n77l654oFr+0l6TszdUdi0DdtLnmYhznEcUPtj2XCwDAHYVoa 9et7ydAQmdTjBmanftQJLq1A2haRHBj5qPWrg6KhybxHfaYXK5nPiZY15wSLhhgDSmAW FoJBWE+z/OXfOCNRW+pXOsVeJaL2835tB6zILjpeDEI0+OJeXyzN3WgrfjN5LGrPDxf1 3TrQ== X-Received: by 10.170.121.210 with SMTP id n201mr4966885ykb.97.1435361065797; Fri, 26 Jun 2015 16:24:25 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id z194sm14546640ywz.56.2015.06.26.16.24.25 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 26 Jun 2015 16:24:25 -0700 (PDT) From: Dave Garrett To: David Benjamin Date: Fri, 26 Jun 2015 19:24:24 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201506111558.21577.davemgarrett@gmail.com> <20150626221456.GK6117@localhost> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201506261924.24454.davemgarrett@gmail.com> Archived-At: Cc: "" Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 26 Jun 2015 23:24:28 -0000 On Friday, June 26, 2015 06:40:15 pm David Benjamin wrote: > Amusingly, if we use the same namespace but use completely non-overlapping > values, it might be safer to put the 1.3 ciphers *after* the 1.2 ones. This is sort of a variation of one of the ideas much earlier in the discussion. The idea was to create new cipher suites for TLS 1.3+ and cut off support for old suites in new versions. This would let us name them in a less confusing manner, e.g.: TLS2_E_CERT_WITH_AES_128_GCM_SHA256 TLS2_E_ANON_WITH_AES_128_GCM_SHA256 TLS2_E_PSK_WITH_AES_128_GCM_SHA256 TLS2_S_PSK_WITH_AES_128_GCM_SHA256 (where 'E' indicates ephemeral and 'S' indicates static or symmetric-only) Not a bad route, but requires defining a pile of new suites. Dave From attilamolnar@hush.com Fri Jun 26 16:48: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 1F3D01B2B92 for ; Fri, 26 Jun 2015 16:48:03 -0700 (PDT) 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_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 p6GAjqv9yXrZ for ; Fri, 26 Jun 2015 16:48:02 -0700 (PDT) Received: from smtp1.hushmail.com (smtp1.hushmail.com [65.39.178.135]) (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 6019F1B2B91 for ; Fri, 26 Jun 2015 16:48:02 -0700 (PDT) Received: from smtp1.hushmail.com (localhost [127.0.0.1]) by smtp1.hushmail.com (Postfix) with SMTP id 0E3E64014F for ; Fri, 26 Jun 2015 23:48:02 +0000 (UTC) Received: from smtp.hushmail.com (w2.hushmail.com [65.39.178.46]) by smtp1.hushmail.com (Postfix) with ESMTP for ; Fri, 26 Jun 2015 23:48:01 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id ED7DDE04DA; Fri, 26 Jun 2015 23:48:01 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Jun 2015 01:48:01 +0200 To: tls@ietf.org From: "Attila Molnar" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20150626234801.ED7DDE04DA@smtp.hushmail.com> Archived-At: Subject: [TLS] New cipher suites for SRP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 26 Jun 2015 23:49:19 -0000 Hello, Currently SRP cannot be used with newer crypto primitives such as ciphers in AEAD mode or SHA-2 due to the lack of cipher suites enabling these. There's only 3DES and AES-CBC with SHA-1. Would there be support for expanding the SRP cipher suites? Regards, Attila From nobody Fri Jun 26 18: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 6AE291B2D85 for ; Fri, 26 Jun 2015 18:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJO8dR6apFZU for ; Fri, 26 Jun 2015 18:01:59 -0700 (PDT) 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 268721B2D83 for ; Fri, 26 Jun 2015 18:01:59 -0700 (PDT) Received: by ykdy1 with SMTP id y1so73093457ykd.2 for ; Fri, 26 Jun 2015 18:01:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:message-id; bh=rJOGOfmEg7fwkVVF7f9GEstq19eeDwNfJzOUyHYnj8A=; b=ESDeHc6MaiQvo05x2Mx8683SjEqvKhKPQG040Ual8VfRmfZyZV5Pvjry8Sk8kLdZPE 3TSiqsfo2pxvfswMOLzRz254jV49Z5t72dvZeWMhDoi+OVQlZrpSGppw/DLkYsH+Q8Q9 F7Y+Ad8+pz3gW3To9m86efss8rLksgSHrbs+5SWwhYr6+RscHKndrdPkiSMVlPqu++6w 9ouONKN6IvvddMF/POjxZlHQFncRmzEN+C+NloRBY4y0T4267qNOURwd3H9J/l/+h8xW Ggsk8k8SyM2mCSrKJ7S2PYo5GgVv6b4av9KxuXRjRpO5uo59sY9CqtnYvqJLxKeQe6Bz Swaw== X-Received: by 10.13.222.5 with SMTP id h5mr5462508ywe.124.1435366918571; Fri, 26 Jun 2015 18:01:58 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id m8sm27812528ywd.30.2015.06.26.18.01.58 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 26 Jun 2015 18:01:58 -0700 (PDT) From: Dave Garrett To: tls@ietf.org, "Attila Molnar" Date: Fri, 26 Jun 2015 21:01:56 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <20150626234801.ED7DDE04DA@smtp.hushmail.com> In-Reply-To: <20150626234801.ED7DDE04DA@smtp.hushmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201506262101.57121.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] New cipher suites for SRP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Jun 2015 01:02:00 -0000 On Friday, June 26, 2015 07:48:01 pm Attila Molnar wrote: > Currently SRP cannot be used with newer crypto primitives such as ciphers in > AEAD mode or SHA-2 due to the lack of cipher suites enabling these. > There's only 3DES and AES-CBC with SHA-1. > > Would there be support for expanding the SRP cipher suites? I don't think it's a good idea to add new SRP cipher suites. Instead, I think redefining SRP as an extension to PSK would make more sense. Use (EC)DHE_PSK cipher suites with an updated SRP extension to get similar capabilities. This would make updating SRP to use newer crypto much easier, as modern PSK cipher suites are easier to get standardized. The current SRP spec actually already appears to rely on PSK identity alert codes. Dave From nobody Fri Jun 26 18:40: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 D5D9B1B2AD1 for ; Fri, 26 Jun 2015 18:40:38 -0700 (PDT) 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_44=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 PekShHPbQLYR for ; Fri, 26 Jun 2015 18:40:37 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2721ACD78 for ; Fri, 26 Jun 2015 18:40:37 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id 1ED7321DE57; Fri, 26 Jun 2015 18:40:37 -0700 (PDT) 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=RRx86z0j6DYRQf SkUyDDJ68/E6A=; b=FLrHPZcddg8oWjHvEF94Xy94lBioMUVoQ51T1aLSUXZYdr Yo2GZDGI5o7QwS3EhBJtzc6l5A/jwZJwiuRPQQgNHGX5UGp0YjRItJvUqBXvixTC TyjFNiw0fcCuMefSkRL+kk/tNUE2Noqdxucg5qS76nhVXfWjDcSprWSnLGnyA= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPA id A553F21DE55; Fri, 26 Jun 2015 18:40:36 -0700 (PDT) Date: Fri, 26 Jun 2015 20:40:35 -0500 From: Nico Williams To: Dave Garrett Message-ID: <20150627014034.GL6117@localhost> References: <201506111558.21577.davemgarrett@gmail.com> <20150626221456.GK6117@localhost> <201506261924.24454.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201506261924.24454.davemgarrett@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "" Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Jun 2015 01:40:39 -0000 On Fri, Jun 26, 2015 at 07:24:24PM -0400, Dave Garrett wrote: > On Friday, June 26, 2015 06:40:15 pm David Benjamin wrote: > > Amusingly, if we use the same namespace but use completely non-overlapping > > values, it might be safer to put the 1.3 ciphers *after* the 1.2 ones. > > This is sort of a variation of one of the ideas much earlier in the > discussion. The idea was to create new cipher suites for TLS 1.3+ and > cut off support for old suites in new versions. This would let us name > them in a less confusing manner, e.g.: > TLS2_E_CERT_WITH_AES_128_GCM_SHA256 > TLS2_E_ANON_WITH_AES_128_GCM_SHA256 > TLS2_E_PSK_WITH_AES_128_GCM_SHA256 > TLS2_S_PSK_WITH_AES_128_GCM_SHA256 > (where 'E' indicates ephemeral and 'S' indicates static or symmetric-only) We could do even better: stop cartesian products altogether. TLS_SRV_AUTH_NONE (anon) TLS_SRV_AUTH_PKIX (certs) TLS_SRV_AUTH_PSK (also authenticates the client) TLS_KEX_DH TLS_KEX_ECDH TLS_KEX_KEY_TRANSPORT (encryption to the server's RSA pubkey) TLS_ENC_AES_128_GCM_SHA256 (the hash is for the handshake, but has to match the symmetric encryption suite's strength) TLS_ENC_AES_256_GCM_SHA512 ... Key exchange, authentication, bulk+hash. > Not a bad route, but requires defining a pile of new suites. We wouldn't change any of the details of the symmetric parts of the cipher suites. It'd be easier to keep track of things if we do this. Nico -- From nobody Fri Jun 26 18:51: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 2DF941A07BC for ; Fri, 26 Jun 2015 18:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_44=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZWaQSPQMHEE for ; Fri, 26 Jun 2015 18:51:50 -0700 (PDT) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (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 1F5061A009B for ; Fri, 26 Jun 2015 18:51:50 -0700 (PDT) Received: by ykdt186 with SMTP id t186so73632230ykd.0 for ; Fri, 26 Jun 2015 18:51:49 -0700 (PDT) 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=WMR+HXkrBRh+Vh1negjmEMg7GsDg+GZvJuH5BHdf7vE=; b=nDIZ0ShsEi4wQz7anonOSOYymRh7sbq6zXf+TdLFjD2693LvRzIQCfEIAfwrazXC+L sjTy91JHK6G9CRTQSVzU4bpKiv+A0YxzhaA2i95wGyYRyhjWvvh+NDyrwL4TXEDyHxIW oidlQSsBBHBoKuhga5o8RQlc2Rud1cI2p3vZvb4vzlwA8zWqj5kqlSEQOKbQnW1ABQsV kl06QHqAM2VeYmbZn1XDrpAWwo2H73Gfy0MpW7rTLNDAWMJdlJjVp/tCnzmG4swiAgf0 eyT3hNUz2AKWGjpithuWagTj+uVS7BhHmRUI5j010Ez2r9sZ3H9SZmk9ekIc9b0VRqdw OvOw== X-Received: by 10.129.52.9 with SMTP id b9mr4793334ywa.58.1435369909585; Fri, 26 Jun 2015 18:51:49 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id r205sm27951628ywr.25.2015.06.26.18.51.48 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 26 Jun 2015 18:51:49 -0700 (PDT) From: Dave Garrett To: Nico Williams Date: Fri, 26 Jun 2015 21:51:47 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201506111558.21577.davemgarrett@gmail.com> <201506261924.24454.davemgarrett@gmail.com> <20150627014034.GL6117@localhost> In-Reply-To: <20150627014034.GL6117@localhost> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201506262151.47456.davemgarrett@gmail.com> Archived-At: Cc: "" Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Jun 2015 01:51:51 -0000 On Friday, June 26, 2015 09:40:35 pm Nico Williams wrote: > We could do even better: stop cartesian products altogether. > > TLS_SRV_AUTH_NONE (anon) > TLS_SRV_AUTH_PKIX (certs) > TLS_SRV_AUTH_PSK (also authenticates the client) What's "SRV" in this context, short for "server"? > TLS_KEX_DH > TLS_KEX_ECDH > TLS_KEX_KEY_TRANSPORT (encryption to the server's RSA pubkey) > > TLS_ENC_AES_128_GCM_SHA256 (the hash is for the handshake, but has to > match the symmetric encryption suite's > strength) > TLS_ENC_AES_256_GCM_SHA512 > ... > > Key exchange, authentication, bulk+hash. > > > Not a bad route, but requires defining a pile of new suites. > > We wouldn't change any of the details of the symmetric parts of the > cipher suites. It'd be easier to keep track of things if we do this. I don't really like this variation. It adds a lot more stuff in the existing cipher suite codespace and makes it a lot more complicated. I'd rather either go for less change or maximal change, i.e. current draft proposal or deprecate suites in favor of a new extension. I don't think this sort of middle-ground is worth it. I suggested something somewhat similar to this in prior discussion, but we ended up moving towards the current proposal. Dave From nobody Fri Jun 26 20:39: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 286A71B2E01 for ; Fri, 26 Jun 2015 20:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.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 iEThcY5OdtDQ for ; Fri, 26 Jun 2015 20:39:25 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [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 322561B2DFE for ; Fri, 26 Jun 2015 20:39:25 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 1A1C233D1D0; Sat, 27 Jun 2015 03:39:24 +0000 (UTC) Sender: geoffk@localhost.localdomain To: Dave Garrett , tls@ietf.org, "Attila Molnar" References: <20150626234801.ED7DDE04DA@smtp.hushmail.com> <201506262101.57121.davemgarrett@gmail.com> From: Geoffrey Keating Date: 26 Jun 2015 20:39:24 -0700 In-Reply-To: <201506262101.57121.davemgarrett@gmail.com> Message-ID: Lines: 39 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: Subject: Re: [TLS] New cipher suites for SRP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Jun 2015 03:39:27 -0000 Dave Garrett writes: > On Friday, June 26, 2015 07:48:01 pm Attila Molnar wrote: > > Currently SRP cannot be used with newer crypto primitives such as ciphers in > > AEAD mode or SHA-2 due to the lack of cipher suites enabling these. > > There's only 3DES and AES-CBC with SHA-1. > > > > Would there be support for expanding the SRP cipher suites? > > I don't think it's a good idea to add new SRP cipher suites. > > Instead, I think redefining SRP as an extension to PSK would make more sense. Use (EC)DHE_PSK cipher suites with an updated SRP extension to get similar capabilities. This would make updating SRP to use newer crypto much easier, as modern PSK cipher suites are easier to get standardized. The current SRP spec actually already appears to rely on PSK identity alert codes. The problem with that is that there are surely many use cases where you're willing to do SRP, or if no SRP you can do a regular ECDHE and prompt for the username/password, but PSK is too insecure. I've been thinking an improved SRP would be useful. It should: - Specify Modern cipher and hash algorithms as mentioned above - Replace the existing SHA1+seed with a password whitening function like PBKDF2, so that in the event of a compromised server cracking the password is harder, and also making online password guessing attacks (sending lots of username+password pairs to the server) more expensive* - Deprecate the 1024-bit and the 1536-bit group, and the previous SRP ciphersuites; and say that these should only be chosen if the server has a legacy verifier for a particular username which requires them. *: You can even keep two verifiers for each account: a 'fast' one where PBKDF2 should execute in a fraction of a second, and a 'slow' one where PBKDF2 might take 15-30 seconds, and pick between them based on recent account history, IP address reputation, or whatever. It costs the server no more to use the 'slow' path but anyone guessing passwords will find it much less effective. From nobody Sat Jun 27 01:09: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 313E31B321F for ; Sat, 27 Jun 2015 01:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_44=0.6, 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 l_N_sb9hqZSa for ; Sat, 27 Jun 2015 01:09:31 -0700 (PDT) Received: from emh03.mail.saunalahti.fi (emh03.mail.saunalahti.fi [62.142.5.109]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0609F1B321E for ; Sat, 27 Jun 2015 01:09:31 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id BA250188E5D; Sat, 27 Jun 2015 11:09:28 +0300 (EEST) Date: Sat, 27 Jun 2015 11:09:28 +0300 From: Ilari Liusvaara To: Nico Williams Message-ID: <20150627080928.GA7886@LK-Perkele-VII> References: <201506111558.21577.davemgarrett@gmail.com> <20150626221456.GK6117@localhost> <201506261924.24454.davemgarrett@gmail.com> <20150627014034.GL6117@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150627014034.GL6117@localhost> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: "" Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Jun 2015 08:09:33 -0000 On Fri, Jun 26, 2015 at 08:40:35PM -0500, Nico Williams wrote: > On Fri, Jun 26, 2015 at 07:24:24PM -0400, Dave Garrett wrote: > > On Friday, June 26, 2015 06:40:15 pm David Benjamin wrote: > > > Amusingly, if we use the same namespace but use completely non-overlapping > > > values, it might be safer to put the 1.3 ciphers *after* the 1.2 ones. > > > > This is sort of a variation of one of the ideas much earlier in the > > discussion. The idea was to create new cipher suites for TLS 1.3+ and > > cut off support for old suites in new versions. This would let us name > > them in a less confusing manner, e.g.: > > TLS2_E_CERT_WITH_AES_128_GCM_SHA256 > > TLS2_E_ANON_WITH_AES_128_GCM_SHA256 > > TLS2_E_PSK_WITH_AES_128_GCM_SHA256 > > TLS2_S_PSK_WITH_AES_128_GCM_SHA256 > > (where 'E' indicates ephemeral and 'S' indicates static or symmetric-only) > > We could do even better: stop cartesian products altogether. > > TLS_SRV_AUTH_NONE (anon) > TLS_SRV_AUTH_PKIX (certs) > TLS_SRV_AUTH_PSK (also authenticates the client) > > TLS_KEX_DH > TLS_KEX_ECDH > TLS_KEX_KEY_TRANSPORT (encryption to the server's RSA pubkey) > > TLS_ENC_AES_128_GCM_SHA256 (the hash is for the handshake, but has to > match the symmetric encryption suite's > strength) > TLS_ENC_AES_256_GCM_SHA512 > ... > > Key exchange, authentication, bulk+hash. One can't really decouple authentication and key exchange cleanly, especially because of PSK (KEX+Auth sets key exchange shape). Also, DH and ECDH (and perhaps some other things) do unify to GDH. Also, one way to do PRF-hash replacement would be to define sets of PRF-hashes, and have the symmetric algorithm pick algorithm from that set. E.g. SHA-2: SHA-256/SHA-384/SHA-512 BLAKE2B: BLAKE2B-256/BLAKE2B-384/BLAKE2B-512 Then YYY_HASH256 + SHA2 -> SHA-256, YYY_HASH384 + SHA2 -> SHA-384, YYY_HASH256 + BLAKE2B -> BLAKE2B-256, YYY_HASH384 + BLAKE2B-384 And so on. -Ilari From nobody Sat Jun 27 11:05: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 5161F1A1BAC for ; Sat, 27 Jun 2015 11:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.151 X-Spam-Level: X-Spam-Status: No, score=-0.151 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_SE=0.35, 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 3CQXWfat7wZY for ; Sat, 27 Jun 2015 11:05:13 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 2130E1A1BA5 for ; Sat, 27 Jun 2015 11:05:12 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t5RI4p82006480 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Sat, 27 Jun 2015 20:04:53 +0200 From: Simon Josefsson To: Rick Andrews References: <544B0DD62A64C1448B2DA253C011414615B1DD55AC@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:150627:rick_andrews@symantec.com::p4YwQ49194bQvjzL:EmpB X-Hashcash: 1:22:150627:tls@ietf.org::2mzCHX7hRXn2vTlY:0Y7IN Date: Sat, 27 Jun 2015 20:04:50 +0200 In-Reply-To: <544B0DD62A64C1448B2DA253C011414615B1DD55AC@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> (Rick Andrews's message of "Tue, 23 Jun 2015 04:41:48 -0700") Message-ID: <87zj3lauyl.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Strawman on EdDSA/Ed25519 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: Sat, 27 Jun 2015 18:05:15 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi Rick -- thank you for the offer! Would you please allocate a range of OIDs for EdDSA-based signatures? I suggest: 1.3.101.1 EdDSA Ed25519 PKIX public keys 1.3.101.2 EdDSA Ed25519 PKIX signatures 1.3.101.3 EdDSA Ed448 PKIX public keys 1.3.101.4 EdDSA Ed448 PKIX signatures 1.3.101.5 EdDSA Curve41417 PKIX public keys 1.3.101.6 EdDSA Curve41417 PKIX signatures 1.3.101.7-16 <> I can update draft-josefsson-pkix-eddsa-01 once you confirm. If you don't want to start at .1 for historic or other reasons, we can start at a higher number. But please keep the number low so it won't increase the DER encoded size of the OID. Btw, there is still some possibility of reaching even shorter OID size by allocating from the 0.0-0.39 range, as suggested by Rob Stradling. I think we are approaching the point of diminishing returns now though. /Simon Rick Andrews writes: > Symantec owns Thawte which owns 1.3.101. We're happy to donate a reasonab= le > number of OIDs under this arc for your purposes. Please let me know if yo= u'd > like to take us up on the offer. Thanks to Rob Stradling for bringing this > to my attention. > > -Rick > > -----Original Message----- > Date: Thu, 21 May 2015 19:42:53 -0700 > From: Peter Bowen > To: Nico Williams > Cc: Simon Josefsson , "tls@ietf.org" > > Subject: Re: [TLS] Strawman on EdDSA/Ed25519 in TLS > Message-ID: > > Content-Type: text/plain; charset=3DUTF-8 > > On Wed, May 20, 2015 at 12:07 PM, Nico Williams > wrote: >> On Wed, May 20, 2015 at 07:14:47PM +0200, Simon Josefsson wrote: >>> Support for EdDSA/Ed25519 in TLS has been suggested a couple of times. >> >> I'm in favor. >> >>> One aspect I'm aware of is that there is no OID allocated nor=20 >>> specification of PKIX certificates with EdDSA/Ed25519 public keys.=20=20 >>> I'm not sure the above document is the right place for doing that=20 >>> though, and more thinking around this topic is especially appreciated. >> >> It's an OID. You can get your own OID arc and then allocate an OID. >> >> Is it important to separate the addition of a PKIX algorithm OID from=20 >> the TLS bits? Well, it is neater that way. > > I'll donate a short OID to the cause if that will help move things forwar= d. > We have the 1.3.187 arc which is only three bytes DER. If someone has a > smaller arc (third node would be 127 or lower) and would offer an OID from > their arc we can shave off another couple of bytes. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJVjuXCAAoJEIYLf7sy+BGdmNEH/ii6d5P1EKbQ1gGBB2DHCcfW lIG6WQMrL7uz4pq2OaJGHlP7jweExC0tGP5HpADuuhw9kIFb5JG1aTzCzp2D/RNa BMhbGw1c7+OZ2Ph74ILwqKWarckL7VXANHvIDFTuiIu2eiqYJJknMuXmneJVO5bY Aqx0MrxopzJs0rCehJAw2GWt7i9px1aXNhWapl1r4ipdD6GlbSUBOZAldqUqMQ4/ r/3l6gSD36MYuyclG5qokFflvpHCtRFgwH3qgyzffSu/PVAyfY4TLtK9VjGXOEI7 MQCEteepTjqmRY3esaaLAPK7F0kLRr2G9drON3Ofrs9cPv6H9BcDD7diUjCYMEs= =9GuD -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Jun 27 11:13: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 EA0611A1EFE for ; Sat, 27 Jun 2015 11:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 hHZPPRB9_3mZ for ; Sat, 27 Jun 2015 11:13:09 -0700 (PDT) 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 038881A1E0F for ; Sat, 27 Jun 2015 11:13:07 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id DE6D39001D; Sat, 27 Jun 2015 21:13:05 +0300 (EEST) Date: Sat, 27 Jun 2015 21:13:05 +0300 From: Ilari Liusvaara To: Simon Josefsson Message-ID: <20150627181305.GA27513@LK-Perkele-VII> References: <544B0DD62A64C1448B2DA253C011414615B1DD55AC@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <87zj3lauyl.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87zj3lauyl.fsf@latte.josefsson.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: "tls@ietf.org" , Rick Andrews Subject: Re: [TLS] Strawman on EdDSA/Ed25519 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: Sat, 27 Jun 2015 18:13:11 -0000 On Sat, Jun 27, 2015 at 08:04:50PM +0200, Simon Josefsson wrote: > > 1.3.101.1 EdDSA Ed25519 PKIX public keys > 1.3.101.2 EdDSA Ed25519 PKIX signatures > 1.3.101.3 EdDSA Ed448 PKIX public keys > 1.3.101.4 EdDSA Ed448 PKIX signatures > 1.3.101.5 EdDSA Curve41417 PKIX public keys > 1.3.101.6 EdDSA Curve41417 PKIX signatures > 1.3.101.7-16 <> AFAIK, Ed448 and Curve41417 do not meet defintion of curve by EdDSA. And what hash would those use (I presume Ed25519 would use SHA-512)? -Ilari From nobody Sat Jun 27 13:12: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 F32611A8935 for ; Sat, 27 Jun 2015 13:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-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 rq91rFV78az1 for ; Sat, 27 Jun 2015 13:12:52 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id A9F901A87BF for ; Sat, 27 Jun 2015 13:12:52 -0700 (PDT) Received: from fifthhorseman.net (h-67-101-29-115.nycm.ny.dynamic.megapath.net [67.101.29.115]) by che.mayfirst.org (Postfix) with ESMTPSA id A732EF984; Sat, 27 Jun 2015 16:12:49 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id F1B2720119; Sat, 27 Jun 2015 16:12:35 -0400 (EDT) From: Daniel Kahn Gillmor To: Dave Garrett , Nico Williams In-Reply-To: <201506262151.47456.davemgarrett@gmail.com> References: <201506111558.21577.davemgarrett@gmail.com> <201506261924.24454.davemgarrett@gmail.com> <20150627014034.GL6117@localhost> <201506262151.47456.davemgarrett@gmail.com> User-Agent: Notmuch/0.20.1 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Sat, 27 Jun 2015 16:12:35 -0400 Message-ID: <87vbe86hcc.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "" Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Jun 2015 20:12:54 -0000 On Fri 2015-06-26 21:51:47 -0400, Dave Garrett wrote: > On Friday, June 26, 2015 09:40:35 pm Nico Williams wrote: >> We could do even better: stop cartesian products altogether. >> >> TLS_SRV_AUTH_NONE (anon) >> TLS_SRV_AUTH_PKIX (certs) >> TLS_SRV_AUTH_PSK (also authenticates the client) > > What's "SRV" in this context, short for "server"? Yeah, the in-fixed term here is "SRV_AUTH", not just "SRV". They're "server authentication" mechanisms (with the caveat Nico mentions above that "PSK" also authenticates the client). --dkg From nobody Sat Jun 27 22:06: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 12AC21A92F5 for ; Sat, 27 Jun 2015 22:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.334 X-Spam-Level: X-Spam-Status: No, score=0.334 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_44=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 LT9JJ0du4EuL for ; Sat, 27 Jun 2015 22:06:11 -0700 (PDT) Received: from homiemail-a110.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 23C7E1A92F4 for ; Sat, 27 Jun 2015 22:06:11 -0700 (PDT) Received: from homiemail-a110.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a110.g.dreamhost.com (Postfix) with ESMTP id 7B85120058F02; Sat, 27 Jun 2015 22:06:10 -0700 (PDT) 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=HHO4ot/mgUJySq 3wkRZMtGbCi8w=; b=aTkbuQlGbA2gpwa1ilCRNjMmQD8/1+sCKl3KlVh23/4iBG NsOh68L2BKOQ3f3oZdmqZjrY71rBia0TMzW2lpK6A12RQ/nKXyNo5PKmjOapsYz2 Xz12/vfbIVeYdthjwBGJY4q/yUipvQHelUTNcukQqDv4O6aar9dKEgQI6IPLQ= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a110.g.dreamhost.com (Postfix) with ESMTPA id 18FC72005E809; Sat, 27 Jun 2015 22:06:10 -0700 (PDT) Date: Sun, 28 Jun 2015 00:06:09 -0500 From: Nico Williams To: Ilari Liusvaara Message-ID: <20150628050607.GN6117@localhost> References: <201506111558.21577.davemgarrett@gmail.com> <20150626221456.GK6117@localhost> <201506261924.24454.davemgarrett@gmail.com> <20150627014034.GL6117@localhost> <20150627080928.GA7886@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150627080928.GA7886@LK-Perkele-VII> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "" Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Jun 2015 05:06:12 -0000 On Sat, Jun 27, 2015 at 11:09:28AM +0300, Ilari Liusvaara wrote: > > We could do even better: stop cartesian products altogether. > > > > TLS_SRV_AUTH_NONE (anon) > > TLS_SRV_AUTH_PKIX (certs) > > TLS_SRV_AUTH_PSK (also authenticates the client) > > > > TLS_KEX_DH > > TLS_KEX_ECDH > > TLS_KEX_KEY_TRANSPORT (encryption to the server's RSA pubkey) > > > > TLS_ENC_AES_128_GCM_SHA256 (the hash is for the handshake, but has to > > match the symmetric encryption suite's > > strength) > > TLS_ENC_AES_256_GCM_SHA512 > > ... > > > > Key exchange, authentication, bulk+hash. > > One can't really decouple authentication and key exchange cleanly, > especially because of PSK (KEX+Auth sets key exchange shape). But I think it simplifies things if we separate them and note that some mechanisms of one kind have a "twin" of the other kind. Imagine that TLS 1.3 clients offer / servers select mechanisms for key exchange and authentication separately but either may contribute to the other. Thus to do PSK without PFS the client would offer PSK for key exchange, and PSK again for authentication. If the client offers ECDH for key exchange and PSK for both (and no others), then the server can pick either PSK only, or PSK + ECDH; if the client offers ECDH for key exchange and PSK for authentication (and no others) then the server must do that (or fail). Some combinations would be non-sensical, such as RSA key transport for key exchange but PSK for authentication. The server must not pick them, but with the client only offering sets of mechanisms from which the server picks, that's fine. If there's no sane combination that could be picked, then the client screwed up and the connection fails. > Also, DH and ECDH (and perhaps some other things) do unify to GDH. Yes. Preferably all DH-like key agreement protocols should be unified, especially when they can work with standard groups. > Also, one way to do PRF-hash replacement would be to define sets of > PRF-hashes, and have the symmetric algorithm pick algorithm from > that set. Sure. I tend to think of the PRF as part of the handshake, so it's a bit strange to associate it with the bulk cipher, but since we want to match their strengths, it makes some sense. We also have to match key exchange and authentication strengths, but we want to succeed with a mismatch provided we don't fall to realtime downgrade attacks -- the one thing we can always match is the hashed and the bulk ciphers. Nico -- From nobody Sat Jun 27 22:09: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 E08211ABC75 for ; Sat, 27 Jun 2015 22:09:48 -0700 (PDT) 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 rJ9Lfi3k_RXS for ; Sat, 27 Jun 2015 22:09:48 -0700 (PDT) Received: from homiemail-a108.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF381ABC74 for ; Sat, 27 Jun 2015 22:09:48 -0700 (PDT) Received: from homiemail-a108.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTP id BDC8B2005D82E; Sat, 27 Jun 2015 22:09:47 -0700 (PDT) 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=xryG/jURLhgrj3 pZVjy/aeCFFL4=; b=hdzHelQhzaQKPK5aj0WLCOxyuO1L+s/SgPwaxx+eOh+1fH 21Uhnq6MUd2a78pxCtfmQkmhYdZXAnpr/KbBEdgP9LCMwxBfCCYfclUglbe2MQbj NsVqZCv8Ayai6wUHINv4YWUVopYmz0MTSstYMavg7XPzR4r8d4kuPsuO1KWxk= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTPA id 4EBF22005D82D; Sat, 27 Jun 2015 22:09:47 -0700 (PDT) Date: Sun, 28 Jun 2015 00:09:46 -0500 From: Nico Williams To: Dave Garrett Message-ID: <20150628050945.GO6117@localhost> References: <201506111558.21577.davemgarrett@gmail.com> <201506261924.24454.davemgarrett@gmail.com> <20150627014034.GL6117@localhost> <201506262151.47456.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201506262151.47456.davemgarrett@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "" Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Jun 2015 05:09:49 -0000 On Fri, Jun 26, 2015 at 09:51:47PM -0400, Dave Garrett wrote: > On Friday, June 26, 2015 09:40:35 pm Nico Williams wrote: > > We could do even better: stop cartesian products altogether. > > > > TLS_SRV_AUTH_NONE (anon) > > TLS_SRV_AUTH_PKIX (certs) > > TLS_SRV_AUTH_PSK (also authenticates the client) > > What's "SRV" in this context, short for "server"? Yes. > > [...] > > I don't really like this variation. It adds a lot more stuff in the > existing cipher suite codespace and makes it a lot more complicated. It would reduce the number of new cipher suite allocations. > I'd rather either go for less change or maximal change, i.e. current > draft proposal or deprecate suites in favor of a new extension. I I didn't necessarily mean that these are all in one namespace. I was ambiguous on purpose. I'd be ecstatic with any solution that gets us past the cartesian product registry and pessimized negotiation. > don't think this sort of middle-ground is worth it. I suggested > something somewhat similar to this in prior discussion, but we ended > up moving towards the current proposal. Fully dropping the pre-1.3 pre-registered cartesian products and having N sets of negotiable things instead *is* the maximal change. Whether we use a new extension (sure, that seems cleanest) or not is a detail. Nico -- From nobody Sun Jun 28 00:44: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 B77021ACD69 for ; Sun, 28 Jun 2015 00:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_74=0.6, 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 nLGad6eclCo7 for ; Sun, 28 Jun 2015 00:44:07 -0700 (PDT) Received: from emh03.mail.saunalahti.fi (emh03.mail.saunalahti.fi [62.142.5.109]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B94F1ACD63 for ; Sun, 28 Jun 2015 00:44:06 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id 244381887AD; Sun, 28 Jun 2015 10:44:03 +0300 (EEST) Date: Sun, 28 Jun 2015 10:44:03 +0300 From: Ilari Liusvaara To: Nico Williams Message-ID: <20150628074403.GA13633@LK-Perkele-VII> References: <201506111558.21577.davemgarrett@gmail.com> <20150626221456.GK6117@localhost> <201506261924.24454.davemgarrett@gmail.com> <20150627014034.GL6117@localhost> <20150627080928.GA7886@LK-Perkele-VII> <20150628050607.GN6117@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150628050607.GN6117@localhost> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: "" Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Jun 2015 07:44:09 -0000 On Sun, Jun 28, 2015 at 12:06:09AM -0500, Nico Williams wrote: > On Sat, Jun 27, 2015 at 11:09:28AM +0300, Ilari Liusvaara wrote: > > > We could do even better: stop cartesian products altogether. > > > > > > TLS_SRV_AUTH_NONE (anon) > > > TLS_SRV_AUTH_PKIX (certs) > > > TLS_SRV_AUTH_PSK (also authenticates the client) > > > > > > TLS_KEX_DH > > > TLS_KEX_ECDH > > > TLS_KEX_KEY_TRANSPORT (encryption to the server's RSA pubkey) > > > > > > TLS_ENC_AES_128_GCM_SHA256 (the hash is for the handshake, but has to > > > match the symmetric encryption suite's > > > strength) > > > TLS_ENC_AES_256_GCM_SHA512 > > > ... > > > > > > Key exchange, authentication, bulk+hash. > > > > One can't really decouple authentication and key exchange cleanly, > > especially because of PSK (KEX+Auth sets key exchange shape). > > But I think it simplifies things if we separate them and note that some > mechanisms of one kind have a "twin" of the other kind. > > Imagine that TLS 1.3 clients offer / servers select mechanisms for key > exchange and authentication separately but either may contribute to the > other. Thus to do PSK without PFS the client would offer PSK for key > exchange, and PSK again for authentication. If the client offers ECDH > for key exchange and PSK for both (and no others), then the server can > pick either PSK only, or PSK + ECDH; if the client offers ECDH for key > exchange and PSK for authentication (and no others) then the server must > do that (or fail). > > Some combinations would be non-sensical, such as RSA key transport for > key exchange but PSK for authentication. The server must not pick them, > but with the client only offering sets of mechanisms from which the > server picks, that's fine. If there's no sane combination that could be > picked, then the client screwed up and the connection fails. "Chinese menus" with coupled choices are classical source of interop problems. Also, out of 6 points for kex/aux (after unifying DH, adding PSK and renaming PKIX to CERT), only 4 seem sane: GDH+CERT GDH+PSK GDH+ANON PSK+PSK KEY_TRANSPORT doesn't lead to anything sane without greatly different key exchange. If new PAKE KEX would be added, it would add 2 combinations fooPAKE+CERT and fooPAKE+ANON (6 for 7). > > Also, DH and ECDH (and perhaps some other things) do unify to GDH. > > Yes. Preferably all DH-like key agreement protocols should be unified, > especially when they can work with standard groups. Things that I think might be able to unify are SIDH and RLWE (but I'm not sure, especially of the latter). Which would be nice, given that both are allegedly PQ, and together with PQ signatures would make PQ protocol. The requirements for unification are: - Capability to work with fixed public parameters - Only one message per side. - The messages can be in either order (even if client always goes first). - Message size <64kB for both. > > Also, one way to do PRF-hash replacement would be to define sets of > > PRF-hashes, and have the symmetric algorithm pick algorithm from > > that set. > > Sure. I tend to think of the PRF as part of the handshake, so it's a > bit strange to associate it with the bulk cipher, but since we want to > match their strengths, it makes some sense. We also have to match key > exchange and authentication strengths, but we want to succeed with a > mismatch provided we don't fall to realtime downgrade attacks -- the one > thing we can always match is the hashed and the bulk ciphers. The reason to have a plan for PRF replacement is that formally TLS 1.3 requires CR prf-hash (even if reality may be a lot less harsh). So if SHA-2 ever breaks, there might be a lot of new ciphers.... (SHA-2 breaking would also cause problems with signatures, but that is a separate matter and only partially solvable at TLS level). -Ilari From nobody Sun Jun 28 11:30: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 B790C1A1BEA for ; Fri, 26 Jun 2015 12:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.511 X-Spam-Level: X-Spam-Status: No, score=0.511 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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, 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 OXuSmcFqc3Df for ; Fri, 26 Jun 2015 12:02:47 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (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 0FA731A6EDE for ; Fri, 26 Jun 2015 12:02:43 -0700 (PDT) Received: by igblr2 with SMTP id lr2so19334670igb.0 for ; Fri, 26 Jun 2015 12:02:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=A7qaJvXmGg9RZNk7nF2KAdkzzpo7fpevZCJdeLSlqt4=; b=pbSG5DbNHzurdfYXN41orLnUEN69q6vuBtqigKg5xYy5bJ79hdBx/mUfLEYtll1j1y oYs7tJZqkBN32kZUz+n2jRjFYD+zMhDqVcTCyT/POv+uqg0wB/pWU0L4yRuq++dg4TSu cG52VeP1IKD+nTs2e6ewbLuf9rLYJxY8M9H+ei9plBGQOatogDJlmbD9gSzHpwC3iYmh VJeUOqB2RVaJRCaQymbEkPKHNMm7uihlJTd1X5jcCdekWcKL/zFiWXxNtmyFbuQVWi6c ZB5nw3UZcAHX7zZokk/xQoB1sudsw0AGGK8UQFj8lHzojqk7HrsZ3JlDkcdyl7rGZCM6 8lIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=A7qaJvXmGg9RZNk7nF2KAdkzzpo7fpevZCJdeLSlqt4=; b=O5rqgfiUv095QUpxMllI0eAChEqLreQgyOVOlIR+q/D0q7whHvEdHi3xzaV4RrHd+J A7EZw1TpQ6Zu5AH4/zKEhhTJ0U/PtNHZIwRmHTjz5fJ1ATx8GdCMudKKMVAHqEHTqolg yiv+70xFo8eKAtF8uMOVPRjnowT2sku2RaNzwG7CzV/KK6m9qXJ5y7yGTtELJTh7Sr69 U6k3GfovHyQ0p38Pi7LR/EkbQXopZc4AK/2WyO6B4SqlRBuQBzMlsGgio6EaH5T/r0Lp oie622mgEw6tqKyKoSCRE3JxBm1c+ABy4e1GGLEXshQv45sMUAVVL077wQXiaelmxMWj GClg== X-Gm-Message-State: ALoCoQlLINQC+pRuyMYLOa8ukDFT9YKNBHWlSS9cCyPJzmbkTv4SlipVowSN5AHKYEqb/W0eNwwA X-Received: by 10.107.130.153 with SMTP id m25mr3884379ioi.92.1435345362125; Fri, 26 Jun 2015 12:02:42 -0700 (PDT) MIME-Version: 1.0 References: <201506111558.21577.davemgarrett@gmail.com> <20150616233111.GD6117@localhost> <201506170131.17179.davemgarrett@gmail.com> In-Reply-To: <201506170131.17179.davemgarrett@gmail.com> From: David Benjamin Date: Fri, 26 Jun 2015 19:02:32 +0000 Message-ID: To: Dave Garrett , Nico Williams Content-Type: multipart/alternative; boundary=001a113fc24c70d13c05197062a0 Archived-At: X-Mailman-Approved-At: Sun, 28 Jun 2015 11:30:38 -0700 Cc: "" Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 26 Jun 2015 19:02:48 -0000 --001a113fc24c70d13c05197062a0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jun 17, 2015 at 1:31 AM Dave Garrett wrote= : > [snip] > Ok, I revised the drafts and forked the anon deprecation changeset. > > Main draft proposal: > > https://github.com/davegarrett/tls13-spec/blob/alacarte/draft-ietf-tls-tl= s13.md#cipher-suites-in-tls-13 > > Version with deprecated anon suites: > > https://github.com/davegarrett/tls13-spec/blob/alacarte-noanonsuites/draf= t-ietf-tls-tls13.md#anonymous-key-exchange > > Note that both totally deprecate all DH(E) suites, as that's one of the > goals here. (due to weak DH params, old Java choking, & etc.) Thus, all > suites must be ECDHE prefixed for TLS 1.3 support under these proposals > (with the exception of plain PSK). All ECDHE suites would be capable of > negotiating either ECDHE or DHE using string groups via the extension. > > PSK & anon will need a litany of new ECDHE suites to be defined. There is > currently no ECDHE AEAD anon suite, thus none supporting TLS 1.3 (among t= he > reasons I pursued the idea of merging it into PSK). > > I'm fine with relegating the anon deprecation idea to the bin if we agree > to define all the new suites we need to maintain support. Getting > ECDHE_anon into the ChaChaPoly draft would be a start. > I have the same concerns with this version as before. I don=E2=80=99t belie= ve it lowers the risk of accidental interop failure---if anything, it makes it worse. This scheme is still a problem for Chrome on Windows XP. This proposal effectively makes ECDSA (and ECDHE) MTI for any clients doing the standard PKI-based handshake. Whether or not this is desirable, it certainly should be spelled out clearly in the spec. Imagine how implementations look. Most allow configuring the cipher suite list. This now interacts subtly with configuring 1.3 ciphers, and we have the same interop risks of a parallel extension. What if the consumer, for whatever reason, omitted the ECDHE_ECDSA variant of some AEAD but included ECDHE_RSA? Now 1.2 servers work, 1.3 ones don=E2=80=99t. Alright, so what i= f we internally checked for consistency? That=E2=80=99s fine, but we could just = as easily have checked for consistency between 1.2 cipher suites and a new 1.3 mechanism. A separate extension avoids any mixing of semantics and gives a clean break from the old pre-multiplied scheme. As for what this extension contains, I don=E2=80=99t have strong opinions o= ver whether we go a la carte---pruning down to the GCMs and CHACHA would also address the explosion---but if we bother, it seems a list of AEAD or AEAD+PRF is correct. The key exchange is already consistently separated from the bulk cipher in TLS. It's a waste to ignore the one clear boundary that we actually have. If the worry is state-machine bugs due to PKI and PSK key exchanges being different, we won=E2=80=99t guard against them by separating ECDHE_PSK_WITH_AES_128_GCM_SHA256 from ECDHE_ECDSA_WITH_AES_128_GCM_SHA256. No one would make ECDHE_PSK_WITH_AES_128_GCM_SHA256 use a codepath from ECDHE_PSK_WITH_CHACHA20_POLY1305, so sufficiently similar cipher suites will be funneled together anyway. David --001a113fc24c70d13c05197062a0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 17= , 2015 at 1:31 AM Dave Garrett <davemgarrett@gmail.com> wrote:
[snip]
Ok, I revised the drafts and forked the anon deprecation changeset.

Main draft proposal:
https://github.com/davegarrett/tls13-spec/blob/alacarte/draft-ietf-tls-t= ls13.md#cipher-suites-in-tls-13

Version with deprecated anon suites:
https://github.com/davegarrett/tls13-spec/blob/alacarte-noan= onsuites/draft-ietf-tls-tls13.md#anonymous-key-exchange

Note that both totally deprecate all DH(E) suites, as that's one of the= goals here. (due to weak DH params, old Java choking, & etc.) Thus, al= l suites must be ECDHE prefixed for TLS 1.3 support under these proposals (= with the exception of plain PSK). All ECDHE suites would be capable of nego= tiating either ECDHE or DHE using string groups via the extension.

PSK & anon will need a litany of new ECDHE suites to be defined. There = is currently no ECDHE AEAD anon suite, thus none supporting TLS 1.3 (among = the reasons I pursued the idea of merging it into PSK).

I'm fine with relegating the anon deprecation idea to the bin if we agr= ee to define all the new suites we need to maintain support. Getting ECDHE_= anon into the ChaChaPoly draft would be a start.

<= div>I have the same concerns with this version as before. I don=E2=80=99t b= elieve it lowers the risk of accidental interop failure---if anything, it m= akes it worse.

This scheme is still a problem for = Chrome on Windows XP. This proposal effectively makes ECDSA (and ECDHE) MTI= for any clients doing the standard PKI-based handshake. Whether or not thi= s is desirable, it certainly should be spelled out clearly in the spec.

Imagine how implementations look. Most allow configur= ing the cipher suite list. This now interacts subtly with configuring 1.3 c= iphers, and we have the same interop risks of a parallel extension. What if= the consumer, for whatever reason, omitted the ECDHE_ECDSA variant of some= AEAD but included ECDHE_RSA? Now 1.2 servers work, 1.3 ones don=E2=80=99t.= Alright, so what if we internally checked for consistency? That=E2=80=99s = fine, but we could just as easily have checked for consistency between 1.2 = cipher suites and a new 1.3 mechanism.

A separate = extension avoids any mixing of semantics and gives a clean break from the o= ld pre-multiplied scheme.

As for what this extensi= on contains, I don=E2=80=99t have strong opinions over whether we go a la c= arte---pruning down to the GCMs and CHACHA would also address the explosion= ---but if we bother, it seems a list of AEAD or AEAD+PRF is correct. The ke= y exchange is already consistently separated from the bulk cipher in TLS.= =C2=A0It's a waste to ignore the one clear boundary that we actually ha= ve.

If the worry is state-machine bugs due to PKI = and PSK key exchanges being different, we won=E2=80=99t guard against them = by separating ECDHE_PSK_WITH_AES_128_GCM_SHA256 from ECDHE_ECDSA_WITH_AES_1= 28_GCM_SHA256. No one would make ECDHE_PSK_WITH_AES_128_GCM_SHA256 use a co= depath from ECDHE_PSK_WITH_CHACHA20_POLY1305, so sufficiently similar ciphe= r suites will be funneled together anyway.

David
--001a113fc24c70d13c05197062a0-- From nobody Sun Jun 28 14:24: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 ED1151A8A41 for ; Sun, 28 Jun 2015 14:24:06 -0700 (PDT) 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_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 3KWoXWEiE0uy for ; Sun, 28 Jun 2015 14:24:05 -0700 (PDT) Received: from smtp10.hushmail.com (smtp10.hushmail.com [65.39.178.143]) (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 6B95C1A8A6A for ; Sun, 28 Jun 2015 14:24:05 -0700 (PDT) Received: from smtp10.hushmail.com (localhost [127.0.0.1]) by smtp10.hushmail.com (Postfix) with SMTP id DA74FC0549 for ; Sun, 28 Jun 2015 21:24:04 +0000 (UTC) Received: from smtp.hushmail.com (w2.hushmail.com [65.39.178.46]) by smtp10.hushmail.com (Postfix) with ESMTP; Sun, 28 Jun 2015 21:24:04 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 76501E04BE; Sun, 28 Jun 2015 21:24:04 +0000 (UTC) MIME-Version: 1.0 Date: Sun, 28 Jun 2015 23:24:04 +0200 To: "Geoffrey Keating" , "Dave Garrett" , tls@ietf.org From: "Attila Molnar" In-Reply-To: References: <20150626234801.ED7DDE04DA@smtp.hushmail.com> <201506262101.57121.davemgarrett@gmail.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20150628212404.76501E04BE@smtp.hushmail.com> Archived-At: Subject: Re: [TLS] New cipher suites for SRP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Jun 2015 21:24:07 -0000 On 2015. 06. 27. at 5:39 AM, "Geoffrey Keating" wrote: > >Dave Garrett writes: > >> On Friday, June 26, 2015 07:48:01 pm Attila Molnar wrote: >> > Currently SRP cannot be used with newer crypto primitives such >as ciphers in >> > AEAD mode or SHA-2 due to the lack of cipher suites enabling >these. >> > There's only 3DES and AES-CBC with SHA-1. >> > >> > Would there be support for expanding the SRP cipher suites? >> >> I don't think it's a good idea to add new SRP cipher suites. >> >> Instead, I think redefining SRP as an extension to PSK would >make more sense. Use (EC)DHE_PSK cipher suites with an updated SRP >extension to get similar capabilities. This would make updating >SRP to use newer crypto much easier, as modern PSK cipher suites >are easier to get standardized. The current SRP spec actually >already appears to rely on PSK identity alert codes. Interesting solution, but doesn't this create corner cases e.g. when both SRP and PSK are supported? They are probably solvable one way or the other, though. However if TLS 1.3 will allow pairing key exchanges with ciphers etc. on the fly all work on this becomes wasted time. >The problem with that is that there are surely many use cases where >you're willing to do SRP, or if no SRP you can do a regular ECDHE >and >prompt for the username/password, but PSK is too insecure. > >I've been thinking an improved SRP would be useful. It should: > >- Specify Modern cipher and hash algorithms as mentioned above > >- Replace the existing SHA1+seed with a password whitening function > like PBKDF2, so that in the event of a compromised server >cracking > the password is harder, and also making online password guessing > attacks (sending lots of username+password pairs to the server) >more > expensive* > >- Deprecate the 1024-bit and the 1536-bit group, and the previous >SRP > ciphersuites; and say that these should only be chosen if the >server > has a legacy verifier for a particular username which requires > them. > >*: You can even keep two verifiers for each account: a 'fast' one > where PBKDF2 should execute in a fraction of a second, and a >'slow' > one where PBKDF2 might take 15-30 seconds, and pick between them > based on recent account history, IP address reputation, or >whatever. > It costs the server no more to use the 'slow' path but anyone > guessing passwords will find it much less effective. Some thoughts that apply to both suggestions: - Specification-wise they are both significantly more complex than adding new cipher suites. - Same for implementations. Adding cipher suites is very simple if the crypto primitives are already there, and is more likely to happen compared to adding new logic. As a result of these two, it will take a considerably longer time for applications to be able to make use of the result of either of the mentioned ideas (if an enhanced SRP ever gets implemented). Because of its abandonment, as of now TLS-SRP cannot be recommended to be used in place of ad hoc, less secure application protocols. The reason I suggested adding new cipher suites is that it seems to be a good tradeoff: it's a drop-in remedy for a major problem with SRP. I understand that it is me who wants to see it updated so it is also me who has to do the lion's share of the work. I thought that expanding the cipher suite arsenal is a good enough treatment for the short term for SRP, but if the WG thinks otherwise and rather wants a bigger overhaul I'm willing to work on that too to improve the unfortunate situation of SRP in TLS. However, I'd like to see a consensus on a TODO first. What do you think about this? Are the original authors of TLS-SRP still interested in it? Please discuss. Regards, Attila From nobody Sun Jun 28 15:38: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 EA8DD1B2FCD for ; Sun, 28 Jun 2015 15:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.199 X-Spam-Level: * X-Spam-Status: No, score=1.199 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_74=0.6] 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 IQnOtOd7XX8b for ; Sun, 28 Jun 2015 15:38:42 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id E0E2D1B2FCC for ; Sun, 28 Jun 2015 15:38:41 -0700 (PDT) Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id CF6E4F984 for ; Sun, 28 Jun 2015 18:38:38 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 52F492030B; Sun, 28 Jun 2015 18:38:28 -0400 (EDT) From: Daniel Kahn Gillmor To: tls@ietf.org In-Reply-To: <20150628074403.GA13633@LK-Perkele-VII> References: <201506111558.21577.davemgarrett@gmail.com> <20150626221456.GK6117@localhost> <201506261924.24454.davemgarrett@gmail.com> <20150627014034.GL6117@localhost> <20150627080928.GA7886@LK-Perkele-VII> <20150628050607.GN6117@localhost> <20150628074403.GA13633@LK-Perkele-VII> User-Agent: Notmuch/0.20.1 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Sun, 28 Jun 2015 18:38:28 -0400 Message-ID: <87bnfz4fx7.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Jun 2015 22:38:43 -0000 On Sun 2015-06-28 03:44:03 -0400, Ilari Liusvaara wrote: > Also, out of 6 points for kex/aux I think you mean kex/auth here, right? i'm just asking for the sake of clarity; this conversation has lots of slightly divergent shorthand notation thrown around. > (after unifying DH, adding PSK and renaming PKIX to CERT), only 4 seem > sane: > > GDH+CERT > GDH+PSK > GDH+ANON > PSK+PSK > > KEY_TRANSPORT doesn't lead to anything sane without greatly different > key exchange. > > If new PAKE KEX would be added, it would add 2 combinations > fooPAKE+CERT and fooPAKE+ANON (6 for 7). Doesn't PAKE provide authentication mechanism as well? shouldn't at least one of these be fooPAKE+fooPAKE ? --dkg From nobody Sun Jun 28 20:16: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 DC9721B3148 for ; Sun, 28 Jun 2015 20:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.079 X-Spam-Level: X-Spam-Status: No, score=-0.079 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 rTpI8q26cnkl for ; Sun, 28 Jun 2015 20:16:47 -0700 (PDT) Received: from mail-qk0-f179.google.com (mail-qk0-f179.google.com [209.85.220.179]) (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 082311B3147 for ; Sun, 28 Jun 2015 20:16:47 -0700 (PDT) Received: by qkbp125 with SMTP id p125so88345303qkb.2 for ; Sun, 28 Jun 2015 20:16:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=e2kyjvIrSHUnOynTj0Sshk2c4OwvEbZ1qKbwjssXBr0=; b=Sww0SSmqzLTEkbEoOqDSBtbUfXeGBRdo0J7R775Bfk3JxTrE9h++ujvfioe39hwNvf t4POv/gEAcPkYt+BI3MK3XbDDoUA3nFgLgGKw9Bnphrp7N+YlsykS+UOWCviGX1HfFsQ M9Do/sOFXnlET2Y7OpPmDHSX6V7Gt3ZgNULRldY0qEgt0OYutufUXBgAiqg4281T4p9A CrYoRh6qM5efxa2g0tLsYsBfwWNzGWOM4FSzxdJPd/zdYoib7q7rORgGh5MeZ4hjgdUz IZ7lKtrEpDvo5dM1a9D2OAuJjqe5jd2F/hzHtPOLU6MQa1utCPa6uaZQM2EGnxbinkgj GYsg== X-Gm-Message-State: ALoCoQkvCSa9BOxcRXlQWtJC95rtv8YWPJ6A1J3bugbGPaf5Sh67pUCaDDCSlfQULFYmvDpy3j3D MIME-Version: 1.0 X-Received: by 10.140.82.72 with SMTP id g66mr16354885qgd.41.1435547805391; Sun, 28 Jun 2015 20:16:45 -0700 (PDT) Received: by 10.96.161.169 with HTTP; Sun, 28 Jun 2015 20:16:45 -0700 (PDT) Date: Sun, 28 Jun 2015 20:16:45 -0700 Message-ID: From: Joseph Salowey To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11c13ee6ffa27105199f84b6 Archived-At: Subject: [TLS] Adding Curve448-Goldilocks to draft-ietf-tls-curve25519 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 29 Jun 2015 03:16:52 -0000 --001a11c13ee6ffa27105199f84b6 Content-Type: text/plain; charset=UTF-8 Does anyone have an objection to adding Curve448-Goldilocks to draft-ietf-tls-curve25519? Please respond by July 5, 2015. Thanks, Joe --001a11c13ee6ffa27105199f84b6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Does anyone have an objecti= on to adding Curve448-Goldilocks to=C2=A0draft-ietf-tls-curve25519?=C2=A0 P= lease respond by July 5, 2015. =C2=A0
<= br>
Thanks,

Joe
--001a11c13ee6ffa27105199f84b6-- From nobody Sun Jun 28 22:50: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 3F94A1A0263 for ; Sun, 28 Jun 2015 22:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.234 X-Spam-Level: ** X-Spam-Status: No, score=2.234 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_34=0.6, J_CHICKENPOX_74=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 7mLFq9uwUGtL for ; Sun, 28 Jun 2015 22:50:26 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA551A0222 for ; Sun, 28 Jun 2015 22:50:26 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id BA7E710060; Sun, 28 Jun 2015 22:50:25 -0700 (PDT) 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=isYDew2l4Jj1Ci jlxITBM0zoig4=; b=ORXq93u+CtdRbavLGJWEDUzeIWUvkGffsdwvL0ncFZlDLa ifojlDM0KnGng9wqDmNt4FRP13hqCCNaowU0NRB6rXNApP9cNjxeTpel/ZNrRzZA onwPZ8ynxLW6cKrDM6JSqgqtdk5XsNxdK+Czm3sbzHdBo2mnpyVfT+TdOq+V4= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPA id 5700C1005D; Sun, 28 Jun 2015 22:50:25 -0700 (PDT) Date: Mon, 29 Jun 2015 00:50:24 -0500 From: Nico Williams To: Ilari Liusvaara Message-ID: <20150629055023.GP6117@localhost> References: <201506111558.21577.davemgarrett@gmail.com> <20150626221456.GK6117@localhost> <201506261924.24454.davemgarrett@gmail.com> <20150627014034.GL6117@localhost> <20150627080928.GA7886@LK-Perkele-VII> <20150628050607.GN6117@localhost> <20150628074403.GA13633@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150628074403.GA13633@LK-Perkele-VII> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "" Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 29 Jun 2015 05:50:27 -0000 On Sun, Jun 28, 2015 at 10:44:03AM +0300, Ilari Liusvaara wrote: > "Chinese menus" with coupled choices are classical source of interop > problems. It's worked for SSHv2. > Also, out of 6 points for kex/aux (after unifying DH, adding PSK and > renaming PKIX to CERT), only 4 seem sane: > > GDH+CERT > GDH+PSK > GDH+ANON > PSK+PSK > > KEY_TRANSPORT doesn't lead to anything sane without greatly different > key exchange. Key transport is its own authentication (like PSK). It can be combined with key agreement, but it's much easier to combine key agreement with signatures instead. If we unify all the key agreement protocols, then I agree that we have few enough key exchange + server authentication mechanisms for now, but see below. > If new PAKE KEX would be added, it would add 2 combinations > fooPAKE+CERT and fooPAKE+ANON (6 for 7). We added GSS support to SSHv2, and I suppose we could add all sorts of server authentication options to TLS eventually. And if we don't unify some key agreement protocols, then we've still got a largish cartesian product. Still, much smaller (and manageable) than with the bulk cipher suites thrown in. > The reason to have a plan for PRF replacement is that formally TLS 1.3 > requires CR prf-hash (even if reality may be a lot less harsh). So if > SHA-2 ever breaks, there might be a lot of new ciphers.... Why not use HMAC? > (SHA-2 breaking would also cause problems with signatures, but that > is a separate matter and only partially solvable at TLS level). I agree that we should deal with each case separately and try to minimize future pain. Nico -- From nobody Sun Jun 28 23:27: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 635FB1A1ADF for ; Sun, 28 Jun 2015 23:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, J_CHICKENPOX_74=0.6, 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 SEB9E46x9Glb for ; Sun, 28 Jun 2015 23:27:02 -0700 (PDT) Received: from emh07.mail.saunalahti.fi (emh07.mail.saunalahti.fi [62.142.5.117]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0B041A1AB8 for ; Sun, 28 Jun 2015 23:27:01 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id 4C4AA4050; Mon, 29 Jun 2015 09:26:59 +0300 (EEST) Date: Mon, 29 Jun 2015 09:26:59 +0300 From: Ilari Liusvaara To: Daniel Kahn Gillmor Message-ID: <20150629062659.GA12123@LK-Perkele-VII> References: <201506111558.21577.davemgarrett@gmail.com> <20150626221456.GK6117@localhost> <201506261924.24454.davemgarrett@gmail.com> <20150627014034.GL6117@localhost> <20150627080928.GA7886@LK-Perkele-VII> <20150628050607.GN6117@localhost> <20150628074403.GA13633@LK-Perkele-VII> <87bnfz4fx7.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87bnfz4fx7.fsf@alice.fifthhorseman.net> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 29 Jun 2015 06:27:04 -0000 On Sun, Jun 28, 2015 at 06:38:28PM -0400, Daniel Kahn Gillmor wrote: > On Sun 2015-06-28 03:44:03 -0400, Ilari Liusvaara wrote: > > Also, out of 6 points for kex/aux > > I think you mean kex/auth here, right? i'm just asking for the sake of > clarity; this conversation has lots of slightly divergent shorthand > notation thrown around. Yeah, a typo. > > (after unifying DH, adding PSK and renaming PKIX to CERT), only 4 seem > > sane: > > > > GDH+CERT > > GDH+PSK > > GDH+ANON > > PSK+PSK > > > > KEY_TRANSPORT doesn't lead to anything sane without greatly different > > key exchange. > > > > If new PAKE KEX would be added, it would add 2 combinations > > fooPAKE+CERT and fooPAKE+ANON (6 for 7). > > Doesn't PAKE provide authentication mechanism as well? shouldn't at > least one of these be fooPAKE+fooPAKE ? Well, at least for SRP there are both cert (server authentication) and no cert (verify possession of verifier) variants. -Ilari From nobody Sun Jun 28 23: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 27F4E1A1B66 for ; Sun, 28 Jun 2015 23:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.198 X-Spam-Level: * X-Spam-Status: No, score=1.198 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_74=0.6, 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 i6-5WvNlhr1u for ; Sun, 28 Jun 2015 23:47:29 -0700 (PDT) Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A2911A1B5B for ; Sun, 28 Jun 2015 23:47:28 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id 9BE511A260A; Mon, 29 Jun 2015 09:47:26 +0300 (EEST) Date: Mon, 29 Jun 2015 09:47:26 +0300 From: Ilari Liusvaara To: Nico Williams Message-ID: <20150629064726.GB12123@LK-Perkele-VII> References: <201506111558.21577.davemgarrett@gmail.com> <20150626221456.GK6117@localhost> <201506261924.24454.davemgarrett@gmail.com> <20150627014034.GL6117@localhost> <20150627080928.GA7886@LK-Perkele-VII> <20150628050607.GN6117@localhost> <20150628074403.GA13633@LK-Perkele-VII> <20150629055023.GP6117@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150629055023.GP6117@localhost> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: "" Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 29 Jun 2015 06:47:30 -0000 On Mon, Jun 29, 2015 at 12:50:24AM -0500, Nico Williams wrote: > On Sun, Jun 28, 2015 at 10:44:03AM +0300, Ilari Liusvaara wrote: > > "Chinese menus" with coupled choices are classical source of interop > > problems. > > It's worked for SSHv2. Also, the way SSHv2 key exchange and authentication is constructed, the coupling in SSHv2 is much smaller than it seems. Also, errorneus pairs can be easily recovered from. > > Also, out of 6 points for kex/aux (after unifying DH, adding PSK and > > renaming PKIX to CERT), only 4 seem sane: > > > > GDH+CERT > > GDH+PSK > > GDH+ANON > > PSK+PSK > > > > KEY_TRANSPORT doesn't lead to anything sane without greatly different > > key exchange. > > Key transport is its own authentication (like PSK). It can be combined > with key agreement, but it's much easier to combine key agreement with > signatures instead. > > If we unify all the key agreement protocols, then I agree that we have > few enough key exchange + server authentication mechanisms for now, but > see below. > > > If new PAKE KEX would be added, it would add 2 combinations > > fooPAKE+CERT and fooPAKE+ANON (6 for 7). > > We added GSS support to SSHv2, and I suppose we could add all sorts of > server authentication options to TLS eventually. > > And if we don't unify some key agreement protocols, then we've still got > a largish cartesian product. Still, much smaller (and manageable) than > with the bulk cipher suites thrown in. I don't think it is that large... And also, different kex/auth pairs change the handshake in pretty fundamential ways. GDH+GSS would presumably be very different from both GDH+CERT and GSS+GSS or whatever. Also, I think it is quite major undertaking to add a new kex/auth pair (especially if it does something "odd" with respect to what's current). > > The reason to have a plan for PRF replacement is that formally TLS 1.3 > > requires CR prf-hash (even if reality may be a lot less harsh). So if > > SHA-2 ever breaks, there might be a lot of new ciphers.... > > Why not use HMAC? Transcripts use hashes. And if raw hash can be collided, HMAC can be collided as well. As said, one might need more powerful attacks against hash than collision to actually break things, but security analysis breaks with just CR failure. > > (SHA-2 breaking would also cause problems with signatures, but that > > is a separate matter and only partially solvable at TLS level). > > I agree that we should deal with each case separately and try to > minimize future pain. The "partially solvable" meant adding indicator of prf-hash into CertficateVerify TBS. The signatures themselves can't be helped. -Ilari From nobody Mon Jun 29 00:26: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 DD28D1A6F0A for ; Mon, 29 Jun 2015 00:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.034 X-Spam-Level: * X-Spam-Status: No, score=1.034 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, 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 fhoZU8K4dz1P for ; Mon, 29 Jun 2015 00:26:33 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 551A31A6F04 for ; Mon, 29 Jun 2015 00:26:33 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id D7C60678063; Mon, 29 Jun 2015 00:26:32 -0700 (PDT) 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=F3p+XJxdp7rVUQ lYqXvgsWFdJmw=; b=dEPJnFRZEartheIzrW72j9aSB+R1CEykswBZSZ4fzf8rWF 3hubRC38NQuINQkeFYi0AyhcXKOlKjMidnS8hH73ChdUHrHPENiRpfgdUK4uyb9H VdIIEuhgNtFWx2NeBzzKcYulE6K1ZhPtM+JWuOhKXM15+iDgXcmyW6329fCJo= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPA id 65F07678062; Mon, 29 Jun 2015 00:26:32 -0700 (PDT) Date: Mon, 29 Jun 2015 02:26:31 -0500 From: Nico Williams To: Ilari Liusvaara Message-ID: <20150629072630.GQ6117@localhost> References: <201506111558.21577.davemgarrett@gmail.com> <20150626221456.GK6117@localhost> <201506261924.24454.davemgarrett@gmail.com> <20150627014034.GL6117@localhost> <20150627080928.GA7886@LK-Perkele-VII> <20150628050607.GN6117@localhost> <20150628074403.GA13633@LK-Perkele-VII> <20150629055023.GP6117@localhost> <20150629064726.GB12123@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150629064726.GB12123@LK-Perkele-VII> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "" Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 29 Jun 2015 07:26:34 -0000 On Mon, Jun 29, 2015 at 09:47:26AM +0300, Ilari Liusvaara wrote: > On Mon, Jun 29, 2015 at 12:50:24AM -0500, Nico Williams wrote: > > Why not use HMAC? > > Transcripts use hashes. And if raw hash can be collided, HMAC can be > collided as well. Ay, pardon the braino. Nico -- From nobody Mon Jun 29 01: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 A96E31A8761 for ; Mon, 29 Jun 2015 01:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 vh_gPTBhZv-B for ; Mon, 29 Jun 2015 01:07:02 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 34F691A874B for ; Mon, 29 Jun 2015 01:07:01 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t5T86oSt027643 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 29 Jun 2015 10:06:51 +0200 From: Simon Josefsson To: Ilari Liusvaara References: <544B0DD62A64C1448B2DA253C011414615B1DD55AC@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <87zj3lauyl.fsf@latte.josefsson.org> <20150627181305.GA27513@LK-Perkele-VII> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:150629:tls@ietf.org::a1H5WW3EDlGsvqlN:9NGL X-Hashcash: 1:22:150629:ilari.liusvaara@elisanet.fi::Go6+wvi4b4CChEms:CBBE X-Hashcash: 1:22:150629:rick_andrews@symantec.com::iZwVDssujEy1Ql3G:Fz+7 Date: Mon, 29 Jun 2015 10:06:48 +0200 In-Reply-To: <20150627181305.GA27513@LK-Perkele-VII> (Ilari Liusvaara's message of "Sat, 27 Jun 2015 21:13:05 +0300") Message-ID: <87oajzaqg7.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: "tls@ietf.org" , Rick Andrews Subject: Re: [TLS] Strawman on EdDSA/Ed25519 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: Mon, 29 Jun 2015 08:07:03 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Ilari Liusvaara writes: > On Sat, Jun 27, 2015 at 08:04:50PM +0200, Simon Josefsson wrote: >>=20 >> 1.3.101.1 EdDSA Ed25519 PKIX public keys >> 1.3.101.2 EdDSA Ed25519 PKIX signatures >> 1.3.101.3 EdDSA Ed448 PKIX public keys >> 1.3.101.4 EdDSA Ed448 PKIX signatures >> 1.3.101.5 EdDSA Curve41417 PKIX public keys >> 1.3.101.6 EdDSA Curve41417 PKIX signatures >> 1.3.101.7-16 <> > > AFAIK, Ed448 and Curve41417 do not meet defintion of curve by EdDSA. > > And what hash would those use (I presume Ed25519 would use SHA-512)? I believe details for EdDSA with other curves will be available shortly, and allocating an OID now will save us some time. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJVkPyYAAoJEIYLf7sy+BGds8kH+wTHUSR0QGgDHElU56bKjd5v 2cNh4WHsai8U4+ZDXjbkxKvu1tb3ZOUZ6n+602RzeQxFLsnxL8Su2V5N2Z3S2UI0 JrTNNxNNfcXXlvJ4BXIdPUZDS84ycGsfnR+k89SosiR65xSFo8d5MbYoVAUiLA2B gydLUWZU6RrNC8bwRO8FZ5+ubX6+3l8z6YR1PcW2OK79GZ2XjPXeJwgQtY1uavRL 4lyaYq1QNRTDcUscS8gCsseXh1tmXVVCODzmyWSIWdTXeMfq2CLfOB5l6v9yrbOE FyKfGG0riiTE1l2g4TvEIZwg/Juvu4GugfUrV5MjaqyTSr7wbLTQnvMEg9Zq3gg= =sC8H -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 29 01:42: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 E89841A1ABC for ; Mon, 29 Jun 2015 01:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 2xgrpWatVze4 for ; Mon, 29 Jun 2015 01:42:15 -0700 (PDT) Received: from emh02.mail.saunalahti.fi (emh02.mail.saunalahti.fi [62.142.5.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 742681A1AA9 for ; Mon, 29 Jun 2015 01:42:15 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id 9DB4D8183C; Mon, 29 Jun 2015 11:42:12 +0300 (EEST) Date: Mon, 29 Jun 2015 11:42:12 +0300 From: Ilari Liusvaara To: Simon Josefsson Message-ID: <20150629084212.GA13762@LK-Perkele-VII> References: <544B0DD62A64C1448B2DA253C011414615B1DD55AC@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <87zj3lauyl.fsf@latte.josefsson.org> <20150627181305.GA27513@LK-Perkele-VII> <87oajzaqg7.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87oajzaqg7.fsf@latte.josefsson.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: "tls@ietf.org" , Rick Andrews Subject: Re: [TLS] Strawman on EdDSA/Ed25519 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: Mon, 29 Jun 2015 08:42:18 -0000 On Mon, Jun 29, 2015 at 10:06:48AM +0200, Simon Josefsson wrote: > Ilari Liusvaara writes: > > > On Sat, Jun 27, 2015 at 08:04:50PM +0200, Simon Josefsson wrote: > >> > >> 1.3.101.1 EdDSA Ed25519 PKIX public keys > >> 1.3.101.2 EdDSA Ed25519 PKIX signatures > >> 1.3.101.3 EdDSA Ed448 PKIX public keys > >> 1.3.101.4 EdDSA Ed448 PKIX signatures > >> 1.3.101.5 EdDSA Curve41417 PKIX public keys > >> 1.3.101.6 EdDSA Curve41417 PKIX signatures > >> 1.3.101.7-16 <> > > > > AFAIK, Ed448 and Curve41417 do not meet defintion of curve by EdDSA. > > > > And what hash would those use (I presume Ed25519 would use SHA-512)? > > I believe details for EdDSA with other curves will be available shortly, > and allocating an OID now will save us some time. Well, I think that defining serialization of points + basepoints[1] for Curve41417 and Ed448 together with with hash used[2] would be enough for interop[3]. However, that will not be the CFRG signature scheme, whatever it is. [1] The basepoint is clear for Curve41417. However, for Ed448, there are two different basepoints: 1) The original basepoint from Ed448-Goldilocks: x=0x297ea0ea2692ff1b4faff46098453a6a26adf733245f065c3c59d0709cecfa96147eaaf3932d94c63d96c170033f4ba0c7f0de840aed939f y=0x13 2) Inverted (not dual) isogeny point to Curve448 basepoint: x=0xB0E68F399412F212DDE2EA59DD40C92561EB9A8FB8F0E89815921CDA5C2C5B9BED51E508D5499AEEBCC47F1E74FF6C71D9D957D438F33FA1 y=0x693F46716EB6BC248876203756C9C7624BEA73736CA3984087789C1E05A0C2D73AD3FF1CE67C39C4FDBD132C4ED7C8AD9808795BF230FA14 This point B' has the property that (y/x)^2 of nth scalar multiple is the nth scalar multiple of Curve448 basepoint (u=5). Which would be handy if also working on Curve448, as fixed-base multiplier with that point as base could be used to accelerate Curve448 key generation. (One can see that (y/x)^2 of point given is 5). [2] AFAICT: - Near-PoT order -> At least 64 bits more than order. - Otherwise -> maximum of 5/4 of order bits or 64 more. All three curves have near-pot orders, so limits by that rule would be: Curve25519: >=317 bits (>=40 bytes) Curve41417: >=475 bits (>=60 bytes) Curve448: >=510 bits (>=64 bytes) All three limits are less than 512, so 512-bit hash like SHA-512 would work. [3] Where interop means defining what verifier accepts, but not specifics of signing. -Ilari From nobody Mon Jun 29 01:58: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 5AEF11A8745 for ; Mon, 29 Jun 2015 01:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 jpVEOZp8VjXg for ; Mon, 29 Jun 2015 01:58:21 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BDE21A8703 for ; Mon, 29 Jun 2015 01:58:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1435568301; x=1467104301; h=from:to:cc:date:message-id:in-reply-to:references: subject:mime-version:content-transfer-encoding; bh=IYOqRJvT10mWTLexB0YVSqcDTLyFDKT5vOZP4WPxD2w=; b=LD8VN5W9O5Qc9Q/cxfthWF5OMiQ3P8mfLsu8a2RwJg013t/mgvnZ29SM JWj+0FeAtwiiVpf7NNGRWPZdjMFlXsASrPwsuUvOdio7BoMvv/CiDSxDC 4aOAHjUTRDpN/7PVkE39QuctGnEgfoeBHux1Plp17ZEAvIzMSuJmgho8T tlkh3eblkGRbK9BMb2SdD+VWeaD6IO2g9si/EIDj4IHduGxzP0605Ah5e JO0e9h27SjPMaUCqDjWb7OW+GNBMIQXlMxKrbtI421wMqQo2CVNPxsZgl 2vqgfuntsNhjBlYJ7TKzH6fMRvPTzkcuU/XquwuZrtAdNOkFu3WKx7YYJ g==; X-IronPort-AV: E=Sophos;i="5.13,698,1427713200"; d="scan'208";a="25564949" X-Ironport-HAT: None - $RELAY-AUTH X-Ironport-Source: 194.105.229.28 - Outgoing - Outgoing-SSL Received: from mobile-out-229-28.siminn.is (HELO [10.128.46.173]) ([194.105.229.28]) by mx4-int.auckland.ac.nz with ESMTP; 29 Jun 2015 20:58:13 +1200 From: Peter Gutmann To: Nico Williams , Ilari Liusvaara Date: Mon, 29 Jun 2015 08:58:11 +0000 Message-ID: <14e3e898220.276b.b9f769d0c6fd5b2dd1c91644b008d34c@cs.auckland.ac.nz> In-Reply-To: <20150629055023.GP6117@localhost> References: <201506111558.21577.davemgarrett@gmail.com> <20150626221456.GK6117@localhost> <201506261924.24454.davemgarrett@gmail.com> <20150627014034.GL6117@localhost> <20150627080928.GA7886@LK-Perkele-VII> <20150628050607.GN6117@localhost> <20150628074403.GA13633@LK-Perkele-VII> <20150629055023.GP6117@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "" Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 29 Jun 2015 08:58:25 -0000 Nico Williams writes: >On Sun, Jun 28, 2015 at 10:44:03AM +0300, Ilari Liusvaara wrote: > >>"Chinese menus" with coupled choices are classical source of interop >>problems. > >It's worked for SSHv2. It worked for SSH because implementations use algorithm groups in highly stereotyped ways, so you have a de facto interop profile. Try negotiating e.g. RC4+SHA in one direction and AES+SHA2 in the other and see how quickly the wheels fall off. Peter.   From nobody Mon Jun 29 02:06: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 F335C1A8833 for ; Mon, 29 Jun 2015 02:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, 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 SBJzu4Yq3N8u for ; Mon, 29 Jun 2015 02:06:08 -0700 (PDT) Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC66B1A8772 for ; Mon, 29 Jun 2015 02:06:07 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id 9160C1A267B for ; Mon, 29 Jun 2015 12:06:04 +0300 (EEST) Date: Mon, 29 Jun 2015 12:06:04 +0300 From: Ilari Liusvaara To: "" Message-ID: <20150629090604.GA14692@LK-Perkele-VII> References: <201506111558.21577.davemgarrett@gmail.com> <20150626221456.GK6117@localhost> <201506261924.24454.davemgarrett@gmail.com> <20150627014034.GL6117@localhost> <20150627080928.GA7886@LK-Perkele-VII> <20150628050607.GN6117@localhost> <20150628074403.GA13633@LK-Perkele-VII> <20150629055023.GP6117@localhost> <14e3e898220.276b.b9f769d0c6fd5b2dd1c91644b008d34c@cs.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <14e3e898220.276b.b9f769d0c6fd5b2dd1c91644b008d34c@cs.auckland.ac.nz> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 29 Jun 2015 09:06:09 -0000 On Mon, Jun 29, 2015 at 08:58:11AM +0000, Peter Gutmann wrote: > Nico Williams writes: > >On Sun, Jun 28, 2015 at 10:44:03AM +0300, Ilari Liusvaara wrote: > > > >>"Chinese menus" with coupled choices are classical source of interop > >>problems. > > > >It's worked for SSHv2. > > It worked for SSH because implementations use algorithm groups in highly > stereotyped ways, so you have a de facto interop profile. Try negotiating > e.g. RC4+SHA in one direction and AES+SHA2 in the other and see how quickly > the wheels fall off. Also, regarding kex+auth in SSH2, the authentication is interactive, so choosing something bad most likely just gives an error and client trying something else. Definitely not the case in TLS. And record protections in different directions aren't even coupled choice (all pairs should technically work). -Ilari From nobody Mon Jun 29 03:55: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 D13681A8AD6 for ; Mon, 29 Jun 2015 03:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nb_03tdNIcTO for ; Mon, 29 Jun 2015 03:55:05 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (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 3D3391A8AD3 for ; Mon, 29 Jun 2015 03:55:05 -0700 (PDT) Received: by wicgi11 with SMTP id gi11so68572810wic.0 for ; Mon, 29 Jun 2015 03:55:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=Pb/GJKZ+PMDJF2qgGrP0FzWLdQU+E2AjHdxFuR0ULVw=; b=nHrzDzHK/eqh420RzWW4Abu0mhYLpvWQy5BrAnCASgRbL2FwOmsIEn9qVurJRoU5kC isEaVrPwdX45kDBfTTIWRCBxQ+PlgLJUPewgs8qZHMaWZD969XdWuG5oG1FrH2z6yo/O SviSuNuejgX1Owf3mELVGHWk+mOw4ZKdsmLtXCOqo3+hDBnUI36RwcPB3JI2dY9lHKNA ULgnlWpWCsFBIxr3a0BkFPEPWN9IxZWbxAVPNRqGXa5Wtu3qwRKIJ99mKV5EqGRphJAC AzWtC4WKZXojKVr8cV/qBVAgxZrF4GEYVF/YWeuzMZBtaIF5vsp77jd+njeV6cDcgrUn NHSw== X-Received: by 10.180.86.168 with SMTP id q8mr20158579wiz.80.1435575303821; Mon, 29 Jun 2015 03:55:03 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id fm8sm11540338wib.9.2015.06.29.03.55.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Jun 2015 03:55:03 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_CD248F94-3D8E-4F91-8FE9-88C730EDF8AA" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Yoav Nir In-Reply-To: Date: Mon, 29 Jun 2015 13:55:00 +0300 Message-Id: <0A6F3668-BA06-437C-97F1-15EBEE2F46F7@gmail.com> References: To: Joseph Salowey X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Adding Curve448-Goldilocks to draft-ietf-tls-curve25519 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 29 Jun 2015 10:55:07 -0000 --Apple-Mail=_CD248F94-3D8E-4F91-8FE9-88C730EDF8AA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yes! CFRG has not chosen a higher-security curve yet, but that one seems to = have the most support, and nobody=E2=80=99s claimed that it is = problematic in any way (other than =E2=80=9Cnot as many bits as some = other curve=E2=80=9D). So I think we can move forward with this. Yoav > On Jun 29, 2015, at 6:16 AM, Joseph Salowey wrote: >=20 > Does anyone have an objection to adding Curve448-Goldilocks to = draft-ietf-tls-curve25519? Please respond by July 5, 2015. =20 >=20 > Thanks, >=20 > Joe > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_CD248F94-3D8E-4F91-8FE9-88C730EDF8AA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Yes!

CFRG = has not chosen a higher-security curve yet, but that one seems to have = the most support, and nobody=E2=80=99s claimed that it is problematic in = any way (other than =E2=80=9Cnot as many bits as some other curve=E2=80=9D= ). So I think we can move forward with this.

Yoav

On = Jun 29, 2015, at 6:16 AM, Joseph Salowey <joe@salowey.net> = wrote:

Does = anyone have an objection to adding Curve448-Goldilocks = to draft-ietf-tls-curve25519?  Please respond by July 5, 2015. =  

Thanks,

Joe
_______________________________________________
TLS = mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

= --Apple-Mail=_CD248F94-3D8E-4F91-8FE9-88C730EDF8AA-- From nobody Mon Jun 29 04:02: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 10A7F1A8AF0 for ; Mon, 29 Jun 2015 04:02:46 -0700 (PDT) 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 IaI7jYy1rxJ7 for ; Mon, 29 Jun 2015 04:02:38 -0700 (PDT) Received: from mmextmx2.mcr.colo.comodoca.net (mmextmx2.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd6]) (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 9A7D41A8AEC for ; Mon, 29 Jun 2015 04:02:36 -0700 (PDT) Received: (qmail 22729 invoked by uid 1004); 29 Jun 2015 11:02:34 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx2.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Mon, 29 Jun 2015 12:02:34 +0100 Received: (qmail 12038 invoked by uid 1000); 29 Jun 2015 11:02:34 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Mon, 29 Jun 2015 12:02:34 +0100 Message-ID: <559125CA.9050704@comodo.com> Date: Mon, 29 Jun 2015 12:02:34 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Yoav Nir , Joseph Salowey References: <0A6F3668-BA06-437C-97F1-15EBEE2F46F7@gmail.com> In-Reply-To: <0A6F3668-BA06-437C-97F1-15EBEE2F46F7@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Adding Curve448-Goldilocks to draft-ietf-tls-curve25519 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 29 Jun 2015 11:02:46 -0000 On 29/06/15 11:55, Yoav Nir wrote: > Yes! > > CFRG has not chosen a higher-security curve yet, Haven't they? On 25th Feb, Alexey Melnikov (CFRG co-chair) wrote: "So CFRG prefers curve 448." [1] [1] http://www.ietf.org/mail-archive/web/cfrg/current/msg06398.html > but that one seems to > have the most support, and nobodys claimed that it is problematic in > any way (other than not as many bits as some other curve). So I think > we can move forward with this. > > Yoav > >> On Jun 29, 2015, at 6:16 AM, Joseph Salowey > > wrote: >> >> Does anyone have an objection to adding Curve448-Goldilocks >> to draft-ietf-tls-curve25519? Please respond by July 5, 2015. >> >> Thanks, >> >> Joe >> _______________________________________________ >> 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 > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. From nobody Mon Jun 29 04:10: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 257881A8BC2 for ; Mon, 29 Jun 2015 04:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 RB82C5xR69SJ for ; Mon, 29 Jun 2015 04:10:06 -0700 (PDT) Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA0521A8BC0 for ; Mon, 29 Jun 2015 04:10:05 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id 78A011A2613; Mon, 29 Jun 2015 14:10:03 +0300 (EEST) Date: Mon, 29 Jun 2015 14:10:03 +0300 From: Ilari Liusvaara To: Yoav Nir Message-ID: <20150629111003.GA16505@LK-Perkele-VII> References: <0A6F3668-BA06-437C-97F1-15EBEE2F46F7@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0A6F3668-BA06-437C-97F1-15EBEE2F46F7@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Adding Curve448-Goldilocks to draft-ietf-tls-curve25519 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 29 Jun 2015 11:10:08 -0000 On Mon, Jun 29, 2015 at 01:55:00PM +0300, Yoav Nir wrote: > Yes! > > CFRG has not chosen a higher-security curve yet, but that one seems > to have the most support, and nobody’s claimed that it is problematic > in any way (other than “not as many bits as some other curve”). So I > think we can move forward with this. Huh, I was under impression that they had picked the higher-secrity curve for Diffie-Hellman months ago (March). In months since, nothing has come up with that (apart from one KAT being wrong[1]). Regarding their progress, they now have CfP on signatures (will run for ~1 more week). Only 3 proposals in ~1 week, I would have expected more. [1] The final DH result for Curve448 test vectors is wrong in cfrg-curves-02. For the correct one, see: https://www.ietf.org/mail-archive/web/cfrg/current/msg06770.html -Ilari From nobody Mon Jun 29 04:20: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 9B9F01A21BE for ; Mon, 29 Jun 2015 04:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6pAhHVepp8s for ; Mon, 29 Jun 2015 04:20:47 -0700 (PDT) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) (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 109371A21B8 for ; Mon, 29 Jun 2015 04:20:47 -0700 (PDT) Received: by wgck11 with SMTP id k11so138660701wgc.0 for ; Mon, 29 Jun 2015 04:20:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hB1J2Sxgjq0YNPaYoiakbzxwt1X0L62D+8r4hDU7/8Y=; b=RnMiiqPuUBtgdUDUFaIYx0O4LA++7EO5+ikO+syyJ7bmnBFgxu9xx51fkMEKnvUBo2 zn1cHeovQp8XI26EaAZfQWEc5Oj96bW8NQx/Xy5o+B5eEek1agbcUlvPwVWEJbiDEzvb Tu5iNoR7tWs2cNfHclnPfffMY9i6wimleG3nproGvCDVnYW/KJYNlQ6CBPy/emu1Ykpn CXZbwDO/nH1TdIDFKdRdA3u/w9Mw7X2fhItfN7l3AMRxetd/rwT2sbf80GKv+/0mycCh KwJo4sHoCdldz63sa8kLZJfkkDVKm3n2p0i1fnlz57OrT9URzNuV2cA6RJZANPHA8lW1 kO+w== X-Received: by 10.180.92.162 with SMTP id cn2mr21046601wib.26.1435576845842; Mon, 29 Jun 2015 04:20:45 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id ho10sm7856693wjb.39.2015.06.29.04.20.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Jun 2015 04:20:44 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Yoav Nir In-Reply-To: <559125CA.9050704@comodo.com> Date: Mon, 29 Jun 2015 14:20:42 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0A6F3668-BA06-437C-97F1-15EBEE2F46F7@gmail.com> <559125CA.9050704@comodo.com> To: Rob Stradling X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Adding Curve448-Goldilocks to draft-ietf-tls-curve25519 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 29 Jun 2015 11:20:48 -0000 > On Jun 29, 2015, at 2:02 PM, Rob Stradling = wrote: >=20 > On 29/06/15 11:55, Yoav Nir wrote: >> Yes! >>=20 >> CFRG has not chosen a higher-security curve yet, >=20 > Haven't they? >=20 > On 25th Feb, Alexey Melnikov (CFRG co-chair) wrote: > "So CFRG prefers curve 448." [1] >=20 >=20 > [1] http://www.ietf.org/mail-archive/web/cfrg/current/msg06398.html Thanks. I=92ve missed that. And now that I=92m checking, it even got = into the curves draft.=20 So definitely yes. Yoav From nobody Mon Jun 29 04: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 174721A8FD6 for ; Mon, 29 Jun 2015 04:31:28 -0700 (PDT) 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 ZUVl9quZn3HK for ; Mon, 29 Jun 2015 04:31:26 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D21681A8901 for ; Mon, 29 Jun 2015 04:31:26 -0700 (PDT) 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 (Postfix) with ESMTPS id 46F70A2C21; Mon, 29 Jun 2015 11:31:26 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-104.brq.redhat.com [10.34.0.104]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t5TBVO1Q003022 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 29 Jun 2015 07:31:25 -0400 From: Hubert Kario To: tls@ietf.org Date: Mon, 29 Jun 2015 13:31:18 +0200 Message-ID: <36814552.ToKCXeCVxV@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.7 (Linux/4.0.4-202.fc21.x86_64; KDE/4.14.7; x86_64; ; ) In-Reply-To: References: <20150626234801.ED7DDE04DA@smtp.hushmail.com> <201506262101.57121.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1876552.l4Vj1hVOFF"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: Cc: Geoffrey Keating Subject: Re: [TLS] New cipher suites for SRP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 29 Jun 2015 11:31:28 -0000 --nextPart1876552.l4Vj1hVOFF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Friday 26 June 2015 20:39:24 Geoffrey Keating wrote: > Dave Garrett writes: > > On Friday, June 26, 2015 07:48:01 pm Attila Molnar wrote: > > > Currently SRP cannot be used with newer crypto primitives such as= > > > ciphers in AEAD mode or SHA-2 due to the lack of cipher suites en= abling > > > these. There's only 3DES and AES-CBC with SHA-1. > > >=20 > > > Would there be support for expanding the SRP cipher suites? > >=20 > > I don't think it's a good idea to add new SRP cipher suites. > >=20 > > Instead, I think redefining SRP as an extension to PSK would make m= ore > > sense. Use (EC)DHE_PSK cipher suites with an updated SRP extension = to get > > similar capabilities. This would make updating SRP to use newer cry= pto > > much easier, as modern PSK cipher suites are easier to get standard= ized. > > The current SRP spec actually already appears to rely on PSK identi= ty > > alert codes. > The problem with that is that there are surely many use cases where > you're willing to do SRP, or if no SRP you can do a regular ECDHE and= > prompt for the username/password, but PSK is too insecure. >=20 > I've been thinking an improved SRP would be useful. It should: >=20 > - Specify Modern cipher and hash algorithms as mentioned above >=20 > - Replace the existing SHA1+seed with a password whitening function > like PBKDF2, so that in the event of a compromised server cracking > the password is harder, and also making online password guessing > attacks (sending lots of username+password pairs to the server) mor= e > expensive* >=20 > - Deprecate the 1024-bit and the 1536-bit group, and the previous SRP= > ciphersuites; and say that these should only be chosen if the serve= r > has a legacy verifier for a particular username which requires > them. +1, provided we do two more things: - Change the negotiation so that user name is not exchanged in the cle= ar - Change key exchange to do PFS =2D-=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 --nextPart1876552.l4Vj1hVOFF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJVkSyMAAoJEJKo0bgB0vX1E9sP/3jS9OEHlGaWPsCljUdW4+0o /GGjIebQ4nrXj0JRWTDiSxRngc1NfX3ocnvUty5guwg9nlfLWfNyLS2z9KZbDmVM Y1c06VUcifOBsGUSBuIX6FTseDmdmF8j4WHSJ1sfgjvTsmxjOtiZXjBTlV6ti8u3 2UEYt/VS3gKHPUDuNO7rQLdHis/ussqM34VYBKBh/2B3fnxcTJ79+WcSa6xGwxM4 FVrtmo9RkTXMEailFhxA07IMDmHpsd/nTfRVsmFdEljx+65MP8Kouh/rdrRuKMux /wT3t70i5mOYxvzhd+0H1B/ZjpTH0wueefLPDdvjIsfa3G1vE/dPB3womPbtwrko fH3LtstQo3mGTRuMp6+m1RJpVEo2tfwisPw7Vh/IacQstlWvP7t+T+l7yizGomz3 Mh6EVxBC1PuOGSRxU/JAQz5OqPSRANS25yWq2AxfU/vsRYpwd87H9dmkJR8Pe31d eVIyek10v8x9xZg7nlHW2n7oYtDWQHlXNNBG75+eGhuFS0O69rIdX8dTEh4i2LYN cK0BUAPXnqilRQuauchFZNt3F5cX7nk2nWPAfgj+tHNgSIRKzRQ4sFbEGH+QyYI8 pTHnEOqFpVZVv4lQ6QpNs0x7FK8p+iyUDh0oytzY4D65fXv1HAs5cJchFFbtdxLV Nhswic5h/1hid5NI2LOy =b77h -----END PGP SIGNATURE----- --nextPart1876552.l4Vj1hVOFF-- From nobody Mon Jun 29 04:46: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 C1C011A903B for ; Mon, 29 Jun 2015 04:46:27 -0700 (PDT) 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 pn2GIy63Jkpt for ; Mon, 29 Jun 2015 04:46:26 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C5F41A9037 for ; Mon, 29 Jun 2015 04:46:26 -0700 (PDT) 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 (Postfix) with ESMTPS id 584B236B1D5; Mon, 29 Jun 2015 11:46:26 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-104.brq.redhat.com [10.34.0.104]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t5TBkOV2012143 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 29 Jun 2015 07:46:25 -0400 From: Hubert Kario To: tls@ietf.org Date: Mon, 29 Jun 2015 13:46:18 +0200 Message-ID: <2076415.VIIdDxSi72@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.7 (Linux/4.0.4-202.fc21.x86_64; KDE/4.14.7; x86_64; ; ) In-Reply-To: References: <2AA11887-2F82-48EF-BD45-4D85CFA83847@qut.edu.au> <20150626194734.GA31681@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3216458.qXkVxhrZEJ"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: Subject: Re: [TLS] Computation of static secret in anonymous 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: Mon, 29 Jun 2015 11:46:27 -0000 --nextPart3216458.qXkVxhrZEJ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Friday 26 June 2015 12:51:01 Eric Rescorla wrote: > On Fri, Jun 26, 2015 at 12:47 PM, Ilari Liusvaara < >=20 > ilari.liusvaara@elisanet.fi> wrote: > > On Fri, Jun 26, 2015 at 12:31:01PM -0700, Eric Rescorla wrote: > > > Note: I have updated the WIP (and that's what I sent to Hugo) so = it now > > > contains the > > > changes the values Hugo describes. > >=20 > > Small nit: > >=20 > > master_secret=3D HKDF(xSS, xES, "master secret") > >=20 > > Should that be: > >=20 > > master_secret=3D HKDF(xSS, xES, "master secret", L) > >=20 > > (the length parameter is seemingly missing)? >=20 > Yes, thanks for the correction. >=20 > > Also, is that label NUL-terminated or not (I think it is)? Another > > reason why I think it is not a good idea to use notes to change > > meaning of explcit algorithms... >=20 > They are all NUL-terminated. Isn't this a departure from TLS1.0 up to TLS1.2? I don't think this is a good idea... =20 =2D-=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 --nextPart3216458.qXkVxhrZEJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJVkTAPAAoJEJKo0bgB0vX1tPEP/RyY5k5vdNzziyFfcVnXwr3z 6qAvU29H5hTTe2SuFo6IPW+EVMEMghWWWMvcyabPWTYfhSVa3GveEtiyH29gDBcb KlmyDjlX4etzy9g/xTEYxdH3QF2P4+cQOs1egqjGVSEiJvAUDlNBWtE03pGK7X6x RzypWo1OxEQATI160IMsOTxgA1C5PfssEzvMPOj1wDe0cTKIYSZ5qFNWPFDTMfzy bl5QAvQoKi/R3otsET0DdXc1c54JWbUlbRTkWjyskjixBFZxV7nuXcwfthL377tK bYXy90avhuG5WNh6dv64m6M8fMJ4ZRCRB2KCnV6e33uvLKUKiNQOlYkx1ZNYYlEO ZSisrAnZmIdEfE1oSCko7x2UHlEIh+8UbgItHyweJfkE4oNjFErRoYeA87tF8uO5 7IwCuIyDXQo5cEt9iiRabwsSyTrNrY8oHqIig/owGf4kDqhQ19obJ6ykPue0mQDU F2OhhXxZTX4xuH7r71hBJFMYT3bmy1280mFTOQ678eUKC1YHQpq3MZeYuNYJE2ir 9ZoXPXJcoycj65yVZePUbNoBUNraX4tLVWLs8ySbV8ncMRSon3Kax1u8xWvmp2UU quGcd3dO1hq+nSIJq/2uOJg/3T5flSrcaZNDvRPY6GITGsE1S5A5z1P5WK/U5H45 PSNCylVPGzgKSfDR+I/S =OxDQ -----END PGP SIGNATURE----- --nextPart3216458.qXkVxhrZEJ-- From nobody Mon Jun 29 04:50: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 CA47D1A9079 for ; Mon, 29 Jun 2015 04:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_MED=-2.3, 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 fNl64ZP75xVe for ; Mon, 29 Jun 2015 04:50:18 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52ED61A906B for ; Mon, 29 Jun 2015 04:49:47 -0700 (PDT) X-AuditID: c1b4fb3a-f79356d000006281-5a-559130d8f8e6 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 8B.54.25217.8D031955; Mon, 29 Jun 2015 13:49:45 +0200 (CEST) Received: from ESESSMB307.ericsson.se ([169.254.7.44]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0210.002; Mon, 29 Jun 2015 13:49:44 +0200 From: John Mattsson To: "TLS@ietf.org" Thread-Topic: New Version Notification for draft-mattsson-tls-ecdhe-psk-aead-00.txt Thread-Index: AQHQsl1RaIdIeD7NqkOXxvBF5+RB053DXqWA Date: Mon, 29 Jun 2015 11:49:43 +0000 Message-ID: References: <20150629111811.16517.15754.idtracker@ietfa.amsl.com> In-Reply-To: <20150629111811.16517.15754.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.1.150515 x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-ID: <9418D45C25741C4D9AE11DF0B568717C@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyM+Jvje5Ng4mhBo/aBCw+ne9idGD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxu0lV1kL5ilUnFn1jLGBcYt8FyMnh4SAicSGbzNYIGwxiQv3 1rN1MXJxCAkcZZSYfHsNE4SzmFFi0qQZ7CBVbAIGEnP3NABVcXCICChKfPqcDRIWFgiRuDx3 MjOILSIQKnF76gRGCNtIYtKpU2BxFgFViWX3V7KB2LwC5hJtR9vARgoJOEo0T7wMFucUcJLY OfE7WD0j0EHfT4HcwMnBLCAucevJfCaIQwUkluw5zwxhi0q8fPyPFcQWFdCTmH5xG1RcSWLR 7c9MIGcyC2hKrN+lDzHGWmL/ws+MELaixJTuh+wQ5whKnJz5hGUCo/gsJNtmIXTPQtI9C0n3 LCTdCxhZVzGKFqcWF+emGxnppRZlJhcX5+fp5aWWbGIExtXBLb+tdjAefO54iFGAg1GJhzch b0KoEGtiWXFl7iFGaQ4WJXHeGZvzQoUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwLkzde/V/ 8rQcafcLlRZrSk2KTA4vjK45GLQls/3SH6ZSK3kVfX6+RX+Xik69mZE9Y07F4f7w2KzyA6l8 v4wuKTEE8IhGfrV9OEHix6zOYt5ttmvvu/zQWFwZyRg8b/a1aT9cevv334h4dN81PtJEmfX7 adGuGEY5o3lT3kf63Z68+OZaPcUXSizFGYmGWsxFxYkAsP2fMIwCAAA= Archived-At: Subject: Re: [TLS] New Version Notification for draft-mattsson-tls-ecdhe-psk-aead-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 29 Jun 2015 11:50:20 -0000 SGksDQoNCldlIGhhdmUgc3VibWl0dGVkIGEgbmV3IGRyYWZ0IGRlZmluaW5nIHNldmVyYWwgbmV3 IFBTS19FQ0RIRSBjaXBoZXINCnN1aXRlcy4gVGhlIGNpcGhlciBzdWl0ZXMgYXJlIGFsbCBiYXNl ZCBvbiB0aGUgRXBoZW1lcmFsIEVsbGlwdGljIEN1cnZlDQpEaWZmaWUtSGVsbG1hbiB3aXRoIFBy ZS1TaGFyZWQgS2V5IChFQ0RIRV9QU0spIGtleSBleGNoYW5nZSB0b2dldGhlciB3aXRoDQp0aGUg QXV0aGVudGljYXRlZCBFbmNyeXB0aW9uIHdpdGggQXNzb2NpYXRlZCBEYXRhIChBRUFEKSBhbGdv cml0aG1zDQpBRVMtR0NNIGFuZCBBRVMtQ0NNLiBQcmUtU2hhcmVkLUtleSBhdXRoZW50aWNhdGlv biBpcyB1c2VkIGluIHNldmVyYWwNCmRlcGxveW1lbnRzLCBlLmcuIDNHUFAgYW5kIElvVC4NCg0K RXJpY3Nzb24gaGFzIHJlY2VudGx5IHByb3Bvc2VkIHRoYXQgM0dQUCBtYWtlcyBzaWduaWZpY2Fu dCB1cGRhdGVzIHRvIHRoZQ0KM0dQUCBwcm9maWxlcyBmb3IgVExTIGFuZCBEVExTLiBBbW9uZyBv dGhlciB0aGluZ3M6IFJlZmVyZW5jZSBSRkM3NTI1IGFuZA0KbWFuZGF0ZSBpbXBsZW1lbnRhdGlv biBvZiBUTFMgMS4yLCBEVExTIDEuMiwgYW5kDQpUTFNfRUNESEVfRUNEU0FfV0lUSF9BRVNfMTI4 X0dDTV9TSEEyNTYgKHdpdGggUC0yNTYpLg0KDQoNCkR1cmluZyB0aGlzIHdvcmsgd2UgaWRlbnRp ZmllZCB0aGF0IHRoZSBQU0sgY2lwaGVyIHN1aXRlcyB0aGF0IHdlIHdvdWxkDQpsaWtlIHRvIGlt cGxlbWVudCB3ZXJlIG5vdCBkZWZpbmVkLiBXZSB0aGluayB0aGF0IHRoZSBuYXR1cmFsIGNob2lj ZSBmb3INCmFueW9uZSB3YW50aW5nIFBTSyBhdXRoZW50aWNhdGlvbiBzaG91bGQgYmUgdG8gdXNl IEVDREhFIHRvZ2V0aGVyIHdpdGggdGhlDQpBRUFEIGFsZ29yaXRobXMgQUVTLUdDTSBhbmQgQUVT LUNDTS4NCg0KQ29tbWVudHMgYXBwcmVjaWF0ZWQuDQoNCkNoZWVycywNCkpvaG4NCg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpKb2huIE1hdHRzc29uDQpNU2MgRW5naW5lZXJpbmcgUGh5c2ljcywgTVNjIEJ1c2luZXNz IEFkbWluaXN0cmF0aW9uIGFuZCBFY29ub21pY3MNCkVyaWNzc29uIElFVEYgU2VjdXJpdHkgQ29v cmRpbmF0b3INClNlbmlvciBSZXNlYXJjaGVyLCBTZWN1cml0eQ0KDQpFcmljc3NvbiBBQiAgICAg ICAgICAgICAgICAgICAgICAgICAgUGhvbmUgKzQ2IDEwIDcxIDQzIDUwMQ0KRXJpY3Nzb24gUmVz ZWFyY2ggICAgICAgICAgICAgICAgICAgIFNNUy9NTVMgKzQ2IDc2IDExIDUzIDUwMQ0KRsOkcsO2 Z2F0YW4gNiAgICAgICAgICAgICAgICAgICAgICAgICAgam9obi5tYXR0c3NvbiBhdCBlcmljc3Nv bi5jb20NClNFLTE2NCA4MCBTdG9ja2hvbG0sIFN3ZWRlbiAgICAgICAgICB3d3cuZXJpY3Nzb24u Y29tDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCg0KDQoNCk9uIDI5LzA2LzE1IDEzOjE4LCAiaW50ZXJuZXQtZHJhZnRz QGlldGYub3JnIiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0Kd3JvdGU6DQoNCj4NCj5BIG5l dyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbWF0dHNzb24tdGxzLWVjZGhlLXBzay1hZWFkLTAwLnR4 dA0KPmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgSm9obiBNYXR0c3NvbiBhbmQg cG9zdGVkIHRvIHRoZQ0KPklFVEYgcmVwb3NpdG9yeS4NCj4NCj5OYW1lOgkJZHJhZnQtbWF0dHNz b24tdGxzLWVjZGhlLXBzay1hZWFkDQo+UmV2aXNpb246CTAwDQo+VGl0bGU6CQlFQ0RIRV9QU0sg d2l0aCBBRVMtR0NNIGFuZCBBRVMtQ0NNIENpcGhlciBTdWl0ZXMgZm9yIFRyYW5zcG9ydA0KPkxh eWVyIFNlY3VyaXR5IChUTFMpDQo+RG9jdW1lbnQgZGF0ZToJMjAxNS0wNi0yOQ0KPkdyb3VwOgkJ SW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+UGFnZXM6CQk1DQo+VVJMOiAgICAgICAgICAgIA0KPmh0 dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1tYXR0c3Nvbi10bHMtZWNk aGUtcHNrLWFlYWQtMDAuDQo+dHh0DQo+U3RhdHVzOiAgICAgICAgIA0KPmh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1hdHRzc29uLXRscy1lY2RoZS1wc2stYWVhZC8NCj5I dG1saXplZDogICAgICAgDQo+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1hdHRz c29uLXRscy1lY2RoZS1wc2stYWVhZC0wMA0KPg0KPg0KPkFic3RyYWN0Og0KPiAgIFRoaXMgbWVt byBkZWZpbmVzIHNldmVyYWwgbmV3IGNpcGhlciBzdWl0ZXMgZm9yIHRoZSBUcmFuc3BvcnQgTGF5 ZXINCj4gICBTZWN1cml0eSAoVExTKSBwcm90b2NvbC4gIFRoZSBjaXBoZXIgc3VpdGVzIGFyZSBh bGwgYmFzZWQgb24gdGhlDQo+ICAgRXBoZW1lcmFsIEVsbGlwdGljIEN1cnZlIERpZmZpZS1IZWxs bWFuIHdpdGggUHJlLVNoYXJlZCBLZXkNCj4gICAoRUNESEVfUFNLKSBrZXkgZXhjaGFuZ2UgdG9n ZXRoZXIgd2l0aCB0aGUgQXV0aGVudGljYXRlZCBFbmNyeXB0aW9uDQo+ICAgd2l0aCBBc3NvY2lh dGVkIERhdGEgKEFFQUQpIGFsZ29yaXRobXMgQUVTLUdDTSBhbmQgQUVTLUNDTS4gIFBTSw0KPiAg IHByb3ZpZGVzIGxpZ2h0IGFuZCBlZmZpY2llbnQgYXV0aGVudGljYXRpb24sIEVDREhFIHByb3Zp ZGVzIHBlcmZlY3QNCj4gICBmb3J3YXJkIHNlY3JlY3ksIGFuZCBBRVMtR0NNIGFuZCBBRVMtQ0NN IHByb3ZpZGVzIGVuY3J5cHRpb24gYW5kDQo+ICAgaW50ZWdyaXR5IHByb3RlY3Rpb24uDQo+DQo+ ICAgICAgICAgICAgICAgICAgDQo+ICAgICAgICANCj4NCj4NCj5QbGVhc2Ugbm90ZSB0aGF0IGl0 IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0KPnN1Ym1pc3Np b24NCj51bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0 IHRvb2xzLmlldGYub3JnLg0KPg0KPlRoZSBJRVRGIFNlY3JldGFyaWF0DQo+DQoNCg== From nobody Mon Jun 29 04:57: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 2834E1A9074 for ; Mon, 29 Jun 2015 04:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 dYLEgHfmHg8t for ; Mon, 29 Jun 2015 04:57:10 -0700 (PDT) Received: from emh07.mail.saunalahti.fi (emh07.mail.saunalahti.fi [62.142.5.117]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8618F1A9071 for ; Mon, 29 Jun 2015 04:57:10 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id 97C41400D; Mon, 29 Jun 2015 14:57:08 +0300 (EEST) Date: Mon, 29 Jun 2015 14:57:08 +0300 From: Ilari Liusvaara To: John Mattsson Message-ID: <20150629115708.GA22118@LK-Perkele-VII> References: <20150629111811.16517.15754.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: "TLS@ietf.org" Subject: Re: [TLS] New Version Notification for draft-mattsson-tls-ecdhe-psk-aead-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 29 Jun 2015 11:57:12 -0000 On Mon, Jun 29, 2015 at 11:49:43AM +0000, John Mattsson wrote: > On 29/06/15 13:18, "internet-drafts@ietf.org" > >Name: draft-mattsson-tls-ecdhe-psk-aead > >Revision: 00 > > Comments appreciated. 1) Searching existing ciphersuites, I think the names should be TLS_ECDHE_PSK_WITH_*. 2) Also, might consider changing 256 bit minimum ECC size to 255, since lower-security CFRG curve is 255 bits. -Ilari From nobody Mon Jun 29 05:55: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 CD5361A902D for ; Mon, 29 Jun 2015 05:55:43 -0700 (PDT) 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 KmtjyZD9Ssy6 for ; Mon, 29 Jun 2015 05:55:41 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id BDF251A902A for ; Mon, 29 Jun 2015 05:55:41 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id 2E5F13600B8; Mon, 29 Jun 2015 05:55:41 -0700 (PDT) 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=oGe9riq8Kh1aEl L4HZQWRiqiiLU=; b=BcxKaQS+TB5wVMZhX0J/EnMAxwmwXdJtCCilOp4BujYIaX Qm6aHjLo4rqMR9DfRnF7VG39lLC8/x3vRYvn7GQrSrLcnu1zOMhgSOAtSvjC6MOd SSzFBDFKlGvSrfrNIYPvPfpjIe37tjjyLiNalJIREk78ce+zQPnK47oXwipsg= 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 AE297360087; Mon, 29 Jun 2015 05:55:40 -0700 (PDT) Date: Mon, 29 Jun 2015 07:55:40 -0500 From: Nico Williams To: Peter Gutmann Message-ID: <20150629125538.GR6117@localhost> References: <201506111558.21577.davemgarrett@gmail.com> <20150626221456.GK6117@localhost> <201506261924.24454.davemgarrett@gmail.com> <20150627014034.GL6117@localhost> <20150627080928.GA7886@LK-Perkele-VII> <20150628050607.GN6117@localhost> <20150628074403.GA13633@LK-Perkele-VII> <20150629055023.GP6117@localhost> <14e3e898220.276b.b9f769d0c6fd5b2dd1c91644b008d34c@cs.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <14e3e898220.276b.b9f769d0c6fd5b2dd1c91644b008d34c@cs.auckland.ac.nz> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "" Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 29 Jun 2015 12:55:44 -0000 On Mon, Jun 29, 2015 at 08:58:11AM +0000, Peter Gutmann wrote: > Nico Williams writes: > >On Sun, Jun 28, 2015 at 10:44:03AM +0300, Ilari Liusvaara wrote: > > > >>"Chinese menus" with coupled choices are classical source of interop > >>problems. > > > >It's worked for SSHv2. > > It worked for SSH because implementations use algorithm groups in > highly stereotyped ways, so you have a de facto interop profile. Try > negotiating e.g. RC4+SHA in one direction and AES+SHA2 in the other > and see how quickly the wheels fall off. That was an idiotic mistake that nobody takes advantage of. From nobody Mon Jun 29 05:58: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 279A71A9101 for ; Mon, 29 Jun 2015 05:57:56 -0700 (PDT) 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_34=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 JUhScCFNCCKh for ; Mon, 29 Jun 2015 05:57:55 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 742511A90F8 for ; Mon, 29 Jun 2015 05:57:55 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTP id 1965E1E076; Mon, 29 Jun 2015 05:57:55 -0700 (PDT) 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=QI0TrhQFXyDN8v DruxsS1qJqE2g=; b=jKppchZ+cZc7znb97fbk2cnkt7RfEyo4wU3NdHkilyFpDJ mQr+9PvUfSv1HnRSdiz6+j6EqYDo+RzftMqkawzyyi2b/RSrvwbe6U1W5msKr0oM W76aoOiKGJwYizahD2k6sM+jYnYnzrfrbpf8IF2E+buN0Mb1DVc90PimZgAag= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTPA id 756D61E059; Mon, 29 Jun 2015 05:57:54 -0700 (PDT) Date: Mon, 29 Jun 2015 07:57:53 -0500 From: Nico Williams To: Ilari Liusvaara Message-ID: <20150629125751.GS6117@localhost> References: <20150626221456.GK6117@localhost> <201506261924.24454.davemgarrett@gmail.com> <20150627014034.GL6117@localhost> <20150627080928.GA7886@LK-Perkele-VII> <20150628050607.GN6117@localhost> <20150628074403.GA13633@LK-Perkele-VII> <20150629055023.GP6117@localhost> <14e3e898220.276b.b9f769d0c6fd5b2dd1c91644b008d34c@cs.auckland.ac.nz> <20150629090604.GA14692@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150629090604.GA14692@LK-Perkele-VII> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "" Subject: Re: [TLS] A la carte handshake negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 29 Jun 2015 12:57:56 -0000 On Mon, Jun 29, 2015 at 12:06:04PM +0300, Ilari Liusvaara wrote: > On Mon, Jun 29, 2015 at 08:58:11AM +0000, Peter Gutmann wrote: > > Nico Williams writes: > > >On Sun, Jun 28, 2015 at 10:44:03AM +0300, Ilari Liusvaara wrote: > > > > > >>"Chinese menus" with coupled choices are classical source of interop > > >>problems. > > > > > >It's worked for SSHv2. > > > > It worked for SSH because implementations use algorithm groups in highly > > stereotyped ways, so you have a de facto interop profile. Try negotiating > > e.g. RC4+SHA in one direction and AES+SHA2 in the other and see how quickly > > the wheels fall off. > > Also, regarding kex+auth in SSH2, the authentication is interactive, so > choosing something bad most likely just gives an error and client trying > something else. Definitely not the case in TLS. Not so. _User_ authentication in SSHv2 is retriable, but the key exchange part of the protocol (which includes server authentication) is not. > And record protections in different directions aren't even coupled choice > (all pairs should technically work). Again, that was a mistake that nobody takes advantage of. I don't understand how it came to be. From nobody Mon Jun 29 06:20: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 4C6261A9141 for ; Mon, 29 Jun 2015 06:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPERfSsjUBNa for ; Mon, 29 Jun 2015 06:20:24 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001: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 2D5531A9140 for ; Mon, 29 Jun 2015 06:20:24 -0700 (PDT) Received: by igrv9 with SMTP id v9so40081609igr.1 for ; Mon, 29 Jun 2015 06:20:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ZGF5isRr8wjM8z7m/bZGnaRFGrO6p3chEvk7AMRombg=; b=F82dpniEEF8vgwZB7D+rfqV5DVC7rccmyGsHNBoc9vR1FZdTG80rseTp7l5fwLCl29 tp/cEwyOx5pPZnVz1/oondZxfjoctxDgtwUAF1hOMsq+bLmnsDCfTI3gmz2Q2cGhwZf7 hPPBsMaS6GYusml+CvabHf/tHlI0ZvsSHCzmlpRh5L26FjasMvJcel2OGj6A5/asEfLc cXR2g7p7xJVUKMDyOK7qETXbnN4lZJwidmUW1o5LSchj5W1Ub+xeS5sEv7Q9Ke9cmZ90 uUXdQlMX/XnsLyH4kou9Ht3nh5SqWEPiYoRIEMQpU9DgQSDo8dJdv+7uTcnTfB0k0hl5 0bVA== MIME-Version: 1.0 X-Received: by 10.50.61.241 with SMTP id t17mr15546516igr.34.1435584023681; Mon, 29 Jun 2015 06:20:23 -0700 (PDT) Received: by 10.36.77.15 with HTTP; Mon, 29 Jun 2015 06:20:23 -0700 (PDT) In-Reply-To: <36814552.ToKCXeCVxV@pintsize.usersys.redhat.com> References: <20150626234801.ED7DDE04DA@smtp.hushmail.com> <201506262101.57121.davemgarrett@gmail.com> <36814552.ToKCXeCVxV@pintsize.usersys.redhat.com> Date: Mon, 29 Jun 2015 09:20:23 -0400 Message-ID: From: Jeffrey Walton To: Hubert Kario Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] New cipher suites for SRP 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: Mon, 29 Jun 2015 13:20:25 -0000 >> I've been thinking an improved SRP would be useful. It should: >> >> - Specify Modern cipher and hash algorithms as mentioned above >> >> - Replace the existing SHA1+seed with a password whitening function >> like PBKDF2, so that in the event of a compromised server cracking >> the password is harder, and also making online password guessing >> attacks (sending lots of username+password pairs to the server) more >> expensive* >> >> - Deprecate the 1024-bit and the 1536-bit group, and the previous SRP >> ciphersuites; and say that these should only be chosen if the server >> has a legacy verifier for a particular username which requires >> them. > > +1, provided we do two more things: > > - Change the negotiation so that user name is not exchanged in the clear > - Change key exchange to do PFS > The clear text username/email will generate a security related finding. I suffered on a couple of years ago when using email addresses. The wording should allow flexibility. Something like 'identity' or 'identity representation' so either the email or a hash of the email (or another way to identify the user) can be sent. It seems like a chicken-and-the-egg problem. The client won't know what to send until the server responds with what it consumes based on the organization's security posture. Jeff From nobody Mon Jun 29 06:24: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 CBECF1A9154 for ; Mon, 29 Jun 2015 06:24:32 -0700 (PDT) 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 EdnUwgnFM0_b for ; Mon, 29 Jun 2015 06:24:30 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0A0A1A9163 for ; Mon, 29 Jun 2015 06:24:30 -0700 (PDT) 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 (Postfix) with ESMTPS id 86FA791768; Mon, 29 Jun 2015 13:24:30 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-104.brq.redhat.com [10.34.0.104]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t5TDOR7U020176 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 29 Jun 2015 09:24:28 -0400 From: Hubert Kario To: noloader@gmail.com Date: Mon, 29 Jun 2015 15:24:21 +0200 Message-ID: <2206690.iAX3u749cm@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.7 (Linux/4.0.4-202.fc21.x86_64; KDE/4.14.7; x86_64; ; ) In-Reply-To: References: <20150626234801.ED7DDE04DA@smtp.hushmail.com> <36814552.ToKCXeCVxV@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4214798.oPhyfzb5bv"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] New cipher suites for SRP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 29 Jun 2015 13:24:33 -0000 --nextPart4214798.oPhyfzb5bv Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Monday 29 June 2015 09:20:23 Jeffrey Walton wrote: > >> I've been thinking an improved SRP would be useful. It should: > >>=20 > >> - Specify Modern cipher and hash algorithms as mentioned above > >>=20 > >> - Replace the existing SHA1+seed with a password whitening functio= n > >>=20 > >> like PBKDF2, so that in the event of a compromised server cracki= ng > >> the password is harder, and also making online password guessing= > >> attacks (sending lots of username+password pairs to the server) = more > >> expensive* > >>=20 > >> - Deprecate the 1024-bit and the 1536-bit group, and the previous = SRP > >>=20 > >> ciphersuites; and say that these should only be chosen if the se= rver > >> has a legacy verifier for a particular username which requires > >> them. > >=20 > > +1, provided we do two more things: > > - Change the negotiation so that user name is not exchanged in the= clear > > - Change key exchange to do PFS >=20 > The clear text username/email will generate a security related > finding. I suffered on a couple of years ago when using email > addresses. >=20 > The wording should allow flexibility. Something like 'identity' or > 'identity representation' so either the email or a hash of the email > (or another way to identify the user) can be sent. >=20 > It seems like a chicken-and-the-egg problem. The client won't know > what to send until the server responds with what it consumes based on= > the organization's security posture. what I meant, is that we may need to wait for TLS1.3 standardisation be= fore we=20 can update the SRP ciphersuites to a standard at which browsers like Fi= refox=20 will agree to ship it =2D-=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 --nextPart4214798.oPhyfzb5bv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJVkUcLAAoJEJKo0bgB0vX1eI4QAI426Tw/nKHzfZKy4EQtDpae xktgzgfBd6y/tODalUSPIiEzdgKE1h6zYj0Ko4ZkHtv6r6XeJidFJWIfI9YfS6JN TiQm2bo20hayXMQ7fLmaNMqWaXQxmPfH3wpkN5NEsgkSK2iOu6iLiaPymCKPrMb2 tpWolRd4HIGH7RPbhi+h0rHfETr6syyHULFLkhaZD74QFnUgruNzm+5D0LQ1TyKz YeiSIJNzdKsoo/4x75YV31NiKjM3ZIZq4hI1+M/7EsNdqcIfehPrQZe/rQe3gAtf Nk2pvZQxWTGrIWesornn1ZdX9YxVxdLKZPYqJr1beIFoZZHQljhxMACR8Myrf1aC F+0X2HcPAwAsqTRtyFCPlVssxdMLgIMkSCW9bBYQvhUh3R+pBKlWGZZCFRfbq8i1 tdSXbUQujmFm5cyvnAl5LoFJ5tBTpJ7g7JYH5mMV+bqeZlpsmt5vpnutO/RtVo2w Dreml4Nc+ceYwFwRNFQV96ynG2am8S9ylSZEJM+AhOqYQYj0L5UM+zm5EsONheEZ wifbdiJCgZ/I6Znp46+B5mOhCXcDK/WsFaL0+/7JYpa0ER85zSj9KUtLnAivRitw oICk2LyN4elv/nA8dyTJCVMuuRjif+L/SYWT6R73gqWmX3pQozuNLi4uxCqIR53t M1+3S2nv56sl43h21EOy =rtEC -----END PGP SIGNATURE----- --nextPart4214798.oPhyfzb5bv-- From nobody Mon Jun 29 06:56: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 2C1BC1ABB1A for ; Mon, 29 Jun 2015 06:56:01 -0700 (PDT) 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 Hjw-4K5sAnrb for ; Mon, 29 Jun 2015 06:56:00 -0700 (PDT) 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 386351A92F0 for ; Mon, 29 Jun 2015 06:56:00 -0700 (PDT) Received: from HQMAILSVR02.voltage.com (unknown [172.16.0.6]) by mail.voltage.com with smtp (TLS: TLSv1/SSLv3,128bits,AES128-SHA) id 5ae8_19ef_c44bd891_db38_4b26_9fcc_5090884e386a; Mon, 29 Jun 2015 06:57:37 -0700 Received: from HQMAILSVR02.voltage.com ([::1]) by HQMAILSVR02.voltage.com ([::1]) with mapi; Mon, 29 Jun 2015 06:55:51 -0700 From: Tom Wu To: Hubert Kario , "tls@ietf.org" Date: Mon, 29 Jun 2015 06:55:59 -0700 Thread-Topic: [TLS] New cipher suites for SRP Thread-Index: AdCyXymiJcu/sOemSce9+ZhAqjVBkgAE7ofw Message-ID: <0607259810418348811F3A862D51E885A5A0EC4965@HQMAILSVR02.voltage.com> References: <20150626234801.ED7DDE04DA@smtp.hushmail.com> <201506262101.57121.davemgarrett@gmail.com> <36814552.ToKCXeCVxV@pintsize.usersys.redhat.com> In-Reply-To: <36814552.ToKCXeCVxV@pintsize.usersys.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Geoffrey Keating Subject: Re: [TLS] New cipher suites for SRP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 29 Jun 2015 13:56:01 -0000 DQo+ICsxLCBwcm92aWRlZCB3ZSBkbyB0d28gbW9yZSB0aGluZ3M6DQo+IA0KPiAgLSBDaGFuZ2Ug dGhlIG5lZ290aWF0aW9uIHNvIHRoYXQgdXNlciBuYW1lIGlzIG5vdCBleGNoYW5nZWQgaW4gdGhl IGNsZWFyDQo+ICAtIENoYW5nZSBrZXkgZXhjaGFuZ2UgdG8gZG8gUEZTDQoNClNSUCBhbHJlYWR5 IHByb3ZpZGVzIFBGUyBhdXRvbWF0aWNhbGx5Lg0KDQpUb20NCg0K From nobody Mon Jun 29 06:57: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 234941ABD35 for ; Mon, 29 Jun 2015 06:57:34 -0700 (PDT) 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 lJUMHblpreCV for ; Mon, 29 Jun 2015 06:57:33 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 896EE1A92F2 for ; Mon, 29 Jun 2015 06:57:32 -0700 (PDT) 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 (Postfix) with ESMTPS id 483FD32C418; Mon, 29 Jun 2015 13:57:32 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-104.brq.redhat.com [10.34.0.104]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t5TDvUu8014300 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 29 Jun 2015 09:57:32 -0400 From: Hubert Kario To: Tom Wu Date: Mon, 29 Jun 2015 15:57:24 +0200 Message-ID: <1460843.VCt2HDe3YD@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.7 (Linux/4.0.4-202.fc21.x86_64; KDE/4.14.7; x86_64; ; ) In-Reply-To: <0607259810418348811F3A862D51E885A5A0EC4965@HQMAILSVR02.voltage.com> References: <20150626234801.ED7DDE04DA@smtp.hushmail.com> <36814552.ToKCXeCVxV@pintsize.usersys.redhat.com> <0607259810418348811F3A862D51E885A5A0EC4965@HQMAILSVR02.voltage.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1632522.fb7Omd0TdL"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: Cc: "tls@ietf.org" , Geoffrey Keating Subject: Re: [TLS] New cipher suites for SRP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 29 Jun 2015 13:57:34 -0000 --nextPart1632522.fb7Omd0TdL Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Monday 29 June 2015 06:55:59 Tom Wu wrote: > > +1, provided we do two more things: > >=20 > >=20 > > - Change the negotiation so that user name is not exchanged in the= clear > > - Change key exchange to do PFS >=20 >=20 > SRP already provides PFS automatically. I'm rather fuzzy about the details (I've read the RFC quite a bit ago),= but=20 isn't the server key share static in SRP? =2D-=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 --nextPart1632522.fb7Omd0TdL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJVkU7KAAoJEJKo0bgB0vX1O4MP/0690sIWnEX2Da3eoJIiaPxf GJQdc30fDEW375rc0IG8if/bRSMmfk0UPjfE4zAR46QqXSqkXdS/DWqjD3ynykkK 737JYK1o9NPl3Hh7ZsYuJ2pwQHmYLgkl9Of6ZVytETJ25TbfYe0AgOifbJ//u+IA C7F6YqU4oxHC0QfMgEHOSwi1Owcn5/9N1Gs6/yezXMjcpO7DMgn8V7jmzXpGzcsd xhJx7uVXVwcFu/gSh/iQL8u6Ee62q25uKI+IAks3llEQLx5nQfcr8vokGb2ijatr 2IAjbr5Gsl2i3OpQy2AsBvwlWQlmghPvI9oSKl36uqMcxrjN6ajILsC6mcWecs7M ToozAql1h41RG5oZz8ZnpEsj6d/Jl3NieeXVeOKEIIkdkQOE/7MGim0jKT2sKcjG uENWFzk//Df+pwViGVNrriNUqlKcxxG5c283Ul406hMjj6MtzaTX3moIyXA/Jz3C jibXpwdDwDLSuvxt8F+BvXf+gFJdjx9/gGZyaynHSbXgfIFQJNsZXeEYXifnlqNP UEN1lg713ahzkm2tFtXmQqfB0QQQIwXTpyssqL3IQr9flQ/vb5z+swB0uovEtmu/ vDJDB3fvUxPwQBOuqqrGKo1FqjlUwsV3MNAbpCMFqk1qMge2HgEP2qSKiL8Y1GQg oL38FFiNhamyYzWtsIAA =9zzi -----END PGP SIGNATURE----- --nextPart1632522.fb7Omd0TdL-- From nobody Mon Jun 29 07:05: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 A3F131ABC74 for ; Mon, 29 Jun 2015 07:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qeUSKiILMeaj for ; Mon, 29 Jun 2015 07:05:54 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::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 6DEB61ABC0F for ; Mon, 29 Jun 2015 07:05:54 -0700 (PDT) Received: by iebmu5 with SMTP id mu5so115384654ieb.1 for ; Mon, 29 Jun 2015 07:05:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=c1VeIvGPDZPF0NHgUQFUg9M5VIYaY81Gun2BtZrcIaQ=; b=q0B0v0rJaAEwM//qRz43wEHxWz5ZD1OcrdapSgQS1KFHAmvBIbS/gTbDHdeDvyCNnn UxPeEP2J2W6u5cK4nUih+b7ylHaJzAF7EEtK/j8W3TJshWu81e71ngtQNjMeJNne6Yo9 Qx734wrG3HmvYb89OHubH3rYOGrz1kviNj/RIVHSQVBjjAHlchM34r1n5Lu3GhAFhR6p 2tsukHL585XlJIkAXJubvGL+LACV+j97umk3Ejd82TWDVGCd5BRVVkWTUZWQm6f5r41X yNCPJeHHVmXj8lZoyICnwc+etFAmq8b+tNgmnG1iNkbPfeixjgP4JAFHo+RT9QrRq44l 70CQ== MIME-Version: 1.0 X-Received: by 10.107.168.150 with SMTP id e22mr21081480ioj.9.1435586753803; Mon, 29 Jun 2015 07:05:53 -0700 (PDT) Received: by 10.36.77.15 with HTTP; Mon, 29 Jun 2015 07:05:53 -0700 (PDT) In-Reply-To: <1460843.VCt2HDe3YD@pintsize.usersys.redhat.com> References: <20150626234801.ED7DDE04DA@smtp.hushmail.com> <36814552.ToKCXeCVxV@pintsize.usersys.redhat.com> <0607259810418348811F3A862D51E885A5A0EC4965@HQMAILSVR02.voltage.com> <1460843.VCt2HDe3YD@pintsize.usersys.redhat.com> Date: Mon, 29 Jun 2015 10:05:53 -0400 Message-ID: From: Jeffrey Walton To: Hubert Kario Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] New cipher suites for SRP 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: Mon, 29 Jun 2015 14:05:55 -0000 On Mon, Jun 29, 2015 at 9:57 AM, Hubert Kario wrote: > On Monday 29 June 2015 06:55:59 Tom Wu wrote: >> > +1, provided we do two more things: >> > >> > >> > - Change the negotiation so that user name is not exchanged in the clear >> > - Change key exchange to do PFS >> >> >> SRP already provides PFS automatically. > > I'm rather fuzzy about the details (I've read the RFC quite a bit ago), but > isn't the server key share static in SRP? > No. Here's the step that calls out its a random key (from RFC 5054): 2.5.3. Server Key Exchange The server key exchange message contains the prime (N), the generator (g), and the salt value (s) read from the SRP password file based on the user name (I) received in the client hello extension. The server key exchange message also contains the server's public value (B). The server calculates this value as B = k*v + g^b % N, where b is a random number that SHOULD be at least 256 bits in length and k = SHA1(N | PAD(g)). Things like resumption can affect the forward secrecy, though. But all cipher suites suffer it equally. Jeff From nobody Mon Jun 29 07: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 ED83B1AC3F7 for ; Mon, 29 Jun 2015 07:07:04 -0700 (PDT) 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 TWGK5QrgTYed for ; Mon, 29 Jun 2015 07:07:03 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C9F01AC3F5 for ; Mon, 29 Jun 2015 07:07:03 -0700 (PDT) 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 (Postfix) with ESMTPS id DAF2DBBF74; Mon, 29 Jun 2015 14:07:02 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-104.brq.redhat.com [10.34.0.104]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t5TE712c012877 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 29 Jun 2015 10:07:02 -0400 From: Hubert Kario To: noloader@gmail.com Date: Mon, 29 Jun 2015 16:07 +0200 Message-ID: <26106452.Ph2yVObLzg@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.7 (Linux/4.0.4-202.fc21.x86_64; KDE/4.14.7; x86_64; ; ) In-Reply-To: References: <20150626234801.ED7DDE04DA@smtp.hushmail.com> <1460843.VCt2HDe3YD@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart14505750.BbTrV4IYF7"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] New cipher suites for SRP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 29 Jun 2015 14:07:05 -0000 --nextPart14505750.BbTrV4IYF7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Monday 29 June 2015 10:05:53 Jeffrey Walton wrote: > On Mon, Jun 29, 2015 at 9:57 AM, Hubert Kario wro= te: > > On Monday 29 June 2015 06:55:59 Tom Wu wrote: > >> > +1, provided we do two more things: > >> > - Change the negotiation so that user name is not exchanged in = the > >> > clear > >> > - Change key exchange to do PFS > >>=20 > >> SRP already provides PFS automatically. > >=20 > > I'm rather fuzzy about the details (I've read the RFC quite a bit a= go), > > but > > isn't the server key share static in SRP? >=20 > No. >=20 > Here's the step that calls out its a random key (from RFC 5054): >=20 > 2.5.3. Server Key Exchange >=20 > The server key exchange message contains the prime (N), the genera= tor > (g), and the salt value (s) read from the SRP password file based = on > the user name (I) received in the client hello extension. >=20 > The server key exchange message also contains the server's public > value (B). The server calculates this value as B =3D k*v + g^b % = N, > where b is a random number that SHOULD be at least 256 bits in len= gth > and k =3D SHA1(N | PAD(g)). >=20 > Things like resumption can affect the forward secrecy, though. But al= l > cipher suites suffer it equally. ahh, I stand corrected, thanks =2D-=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 --nextPart14505750.BbTrV4IYF7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIbBAABCgAGBQJVkVEEAAoJEJKo0bgB0vX1P+8P9A/347hTsrq5pX653swWWHFQ xD4u2PrTIZ20JwHxBIhPInPI4gDy+2HLszeIziNQvaunOtJy1ACwUI3AbJwDcAuM iUBkplemi/7CFS6DCKyMrsW22rOeWODe0pYmbzhIYTUPd9x5j556k2a6xXt8q0HF BUq2UliAR12lamXK+N2J1RR/cYnZuiBRdz1GvxC6HmAlBbyNgwjaRAMLrNDxfk75 Htg63rRmYz6qXfQ4wEtSE+9pla36GNb5LxJRmhmz5Tce9H4oLkvP/8DWaUan/xqq G8ewfoMne4V6l8KyWaYxGJsbgUItnSkwG3r6nhlF9G7JX1Z85qvo5+nl0B8insHQ /baBOlXP8XhDz87qaGcwEeDaHrQ/6eKUZJhY8kZFX6xhcj56sJ7EZkdELfrrR2R8 qii+Knoj0qmsRws0qNfyjIi+k95oCGYD9XjxY6iJsmbepapA08FMvLXVdrONG92r f5UIJ3klUk/YLmLsm2M5dlg5WS+gFdfENtAPbr/dXQUJIp1DbYXlP0HHXx6j184N pRYIi1bQ0OlYGyFZSmMG0KJ1+pKktz1pDHxRu4HTXQLC5zzIJ9dIeuhqkJiIhkWk YenIFstQj6hwswUmt0tmQ7WsmeHmMVRK5zgqwNyFJEAotjVy0Xlh0gLn0GvAYXT7 tYxUEzSEtJo6Xkq3u7A= =IUPo -----END PGP SIGNATURE----- --nextPart14505750.BbTrV4IYF7-- From nobody Mon Jun 29 15:02: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 E8DB91B3574; Mon, 29 Jun 2015 15:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 Ymuup4o2jVLY; Mon, 29 Jun 2015 15:02:55 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 ADF411B3573; Mon, 29 Jun 2015 15:02:54 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t5TM2eK6009206 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 30 Jun 2015 00:02:42 +0200 X-Hashcash: 1:22:150629:pkix@ietf.org::q/llBA4qZTh4Wzv7:0aD1 X-Hashcash: 1:22:150629:tls@ietf.org::1B3u8k9trqI8xmhG:8iQH From: Simon Josefsson To: pkix@ietf.org, tls@ietf.org OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt Date: Tue, 30 Jun 2015 00:02:39 +0200 Message-ID: <87lhf29nr4.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Subject: [TLS] PKIX drafts on EdDSA/Ed25519 and Curve25519/Curve448 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 29 Jun 2015 22:02:56 -0000 --=-=-= Content-Type: text/plain Hi all, (I'm cross-posting pkix@ and tls@ because there is cross-WG coordination involved here -- please redirect followups appropriately.) Symantec kindly donated two OIDs for Ed25519 keys/signatures. I have updated the EdDSA/Ed25519 draft to use them, together with some other minor tweaks. Please find the updated document here: https://tools.ietf.org/html/draft-josefsson-pkix-eddsa-02 Symantec also offered 1.3.101.102...1.3.101.127 for other curves or signature schemes, as they are defined, which will shave off a couple of bytes for us. Coordination of allocation is handled by Rick Andrews. A couple of people suggested to define encodings for Curve25519/Curve448 (the CFRG curves) public keys. I didn't see that this necessarily had to be in the above document, so I put it in a separate document. I'm not entirely sure how useful this is, or if I may have completely misunderstood what people had in mind. Please find a new document here: https://tools.ietf.org/html/draft-josefsson-pkix-newcurves-00 The document is short and a bit rough at the moment; all feedback is welcome. Cheers, /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJVkcCAAAoJEIYLf7sy+BGd+NcH/A5KhgeEH5dATxOENUuiPYUB jZvHFwC9CfAjTDJ4Dr13yCQHT5ghspeh8LHHjsiMYqHhujSf5XEiALhCrxNePUSm kEThL9jo1n+Mrcya7OqYMuDeikj5+YlYIFYzuJlXliKv5GtxUcb//F5JA589QzSk n2SevxABqFvud9FmhpDGMzee+aqaAQoJK9i18zyEoRhya2OasAQGq1qT4oVBuP0N SYnsuWm5jRFF+zwByhMTCe4XUp/tNA46PmCzwIcWQQQmpqCbAV6fa1IzQVfAuEzf zC3txEwfZJlba71NNKKYddmKtJNM1ET8qVs5g1O5aFivmCTJJN4PSewLaQ9cwpE= =AJas -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 29 16:07: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 688A91B2C7C; Mon, 29 Jun 2015 16:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DgFMcfXQ2RDq; Mon, 29 Jun 2015 16:07:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 433B71B2EDB; Mon, 29 Jun 2015 16:07:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150629230722.2246.92241.idtracker@ietfa.amsl.com> Date: Mon, 29 Jun 2015 16:07:22 -0700 Archived-At: Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-tls13-06.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, 29 Jun 2015 23:07:24 -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 Author : Eric Rescorla Filename : draft-ietf-tls-tls13-06.txt Pages : 89 Date : 2015-06-29 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: https://tools.ietf.org/html/draft-ietf-tls-tls13-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-tls13-06 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 Mon Jun 29 22:13: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 EE9DC1B30F5 for ; Mon, 29 Jun 2015 22:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.266 X-Spam-Level: X-Spam-Status: No, score=-0.266 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 sofMeK0Kzh7X for ; Mon, 29 Jun 2015 22:13:23 -0700 (PDT) Received: from homiemail-a109.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id BDC1C1B30F4 for ; Mon, 29 Jun 2015 22:13:23 -0700 (PDT) Received: from homiemail-a109.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a109.g.dreamhost.com (Postfix) with ESMTP id 45B002005DD01 for ; Mon, 29 Jun 2015 22:13:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=nomountain.net; h= message-id:date:from:mime-version:to:subject:content-type :content-transfer-encoding; s=nomountain.net; bh=jqes3Uje6bkmp3V aOZ0LLLN9TGE=; b=Px5+JtkqVD5UFTUfGEi9MuVFqD+yet/CjRo8tOi9+CMq9I4 driD8nIbsNxBrtZxceF5eJcv0jloXghLQmmVY2N513+Dzcvp9vrCBnoCXiPNV3Em 7Ei9QnB2jddO+hRaK6i2ISrCtJD72cUpq7bb8p0/QhMZJqqdNn51H2nRy7nQ= Received: from spandex.local (216-67-117-38-rb3.fai.dsl.dynamic.acsalaska.net [216.67.117.38]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: melinda.shore@nomountain.net) by homiemail-a109.g.dreamhost.com (Postfix) with ESMTPSA id 0A3332005DD00 for ; Mon, 29 Jun 2015 22:13:22 -0700 (PDT) Message-ID: <55922571.8080605@nomountain.net> Date: Mon, 29 Jun 2015 21:13:21 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [TLS] draft-shore-tls-dnssec-chain-extension-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, 30 Jun 2015 05:13:25 -0000 Hi, all: We've submitted a initial draft describing a TLS extension for the transport of a DNS record serialized with the DNSSEC signatures needed to authenticate that record. This would allow DANE clients to perform DANE authentication of a TLS server certificate without performing additional DNS lookups and incurring the performance costs associated with them. There are some additional benefits around things like middlebox traversal, and allowing a TLS client to validate DANE records without needing secured access to a validating DNS resolver. Please have a look at it and get comments or suggestions to us. We're planning on getting one more revision out prior to the Prague meeting, and on having a test implementation available in Prague. The draft is available at: https://tools.ietf.org/html/draft-shore-tls-dnssec-chain-extension-00 Thanks, Melinda -- Melinda Shore No Mountain Software melinda.shore@nomountain.net "Software longa, hardware brevis." From nobody Mon Jun 29 23:25: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 CD9AF1AC3DF; Mon, 29 Jun 2015 23:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 7j9PVihA7FCL; Mon, 29 Jun 2015 23:25:21 -0700 (PDT) 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 DF7D61ABB19; Mon, 29 Jun 2015 23:25:20 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id A2861282FB9; Tue, 30 Jun 2015 06:25:18 +0000 (UTC) Date: Tue, 30 Jun 2015 06:25:18 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150630062518.GC14121@mournblade.imrryr.org> References: <55922571.8080605@nomountain.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55922571.8080605@nomountain.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: dane@ietf.org Subject: Re: [TLS] draft-shore-tls-dnssec-chain-extension-00 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: Tue, 30 Jun 2015 06:25:24 -0000 On Mon, Jun 29, 2015 at 09:13:21PM -0800, Melinda Shore wrote: > Please have a look at it and get comments or suggestions > to us. We're planning on getting one more revision out > prior to the Prague meeting, and on having a test > implementation available in Prague. > The draft is available at: > https://tools.ietf.org/html/draft-shore-tls-dnssec-chain-extension-00 1. There's a more compelling reason than stated why the extension is not well suited to MTA to MTA SMTP. With MTA to MTA SMTP DANE is opportunistic, (START)TLS is optional unless a requirement for authenticated signalled via TLSA records. Such signalled cannot be postponed to the TLS handshake, because that handshake may not even take place unless the SMTP client MTA knows that TLS is required. Even if TLS were to be used, authentication is generally not required in MTA to MTA traffic, so the extension would be vulnerable to MITM attacks. Similar considerations apply to server-to-server XMPP traffic. Thus the extension in question is only relevant with protocols where TLS (with authenticaiton) is mandatory, and DANE is a potentially attractive alternative PKI. With opportunistic DANE TLS, the extension is inevitably too late. 2. That said, the extension is a potentially good fit for MUA to MSA submission, and XMPP user-agent (client) to first-hop XMPP server, where the user agent statically enforces TLS, and generally connects to a single fixed server it can reasonably authenticate. 3. I'm not sure what purpose the last paragraph of section 3 is intended to serve: Obviously, an authentication chain will be most compact and easiest to verify if each RRset has a single record, i.e., if there is a single DNSKEY RR and a single DS RR at each step. In addition, as suggested above, keeping zone cuts to a minimum also reduces the length of the authentication chain. The TLS server has no choice but to return the complete RRset for each owner name class and RRtype, since RRSIGs cover RRsets, not individual RRs. So "compacting" is possible. The server returns the RRsets exactly as published by the relevant DNS(SEC) servers. Speaking of RRsets, are the RRs in each RRset returned by the server required to be sorted in canonical order? 4. I think the Section 4 SNI interaction would be a lot cleaner, if SNI is mandatory for clients that use the proposed extension. In which case the server can only respond with a leaf TLSA RRset (and chain of RRSIG/DNSKEY/DS/... records) whose "base domain" ( see section 3 of RFC6698 and soon definition of TLSA base domain in draft-ietf-dane-ops-13 (later this week)). Using some random name for the server's IP address is not a good idea IMHO. PTR records are too often poorly correlated with the client's notion of the target server name. 5. In Section 5, the server MUST not violate DNS TTLs. The last senetence: Alternatively, it could be configured to rebuild the chain at some predefined periodic intervals. is I fear too much rope. Sure the server can periodically flush its cache (using shorter than possible TTLs), but this does not free it of the obligation to not extend TTLs by relying exclusively on a cache lifetime of its own choosing. 6. Note that the soon up for IESG review draft-ietf-dane-ops considerably revises the DANE verification logic for TLSA certificate usage DANE-EE(3). Section 6 should refer to draft-ietf-dane-ops-12 (soon -13 which responds to AD and GEN-ART comments) as well as RFC6698. 7. The draft often says "TLSA record" when it needs to say "TLSA RRset". It will be quite common for multiple TLSA RRs to be present in the RRset, as this is required to correctly effect key rotation. Therefore, in Section 6 (and elsewhere), text such as the below: If the record is correctly authenticated, the client then performs DANE authentication according to the DANE TLS protocol [RFC6698]. is sub-optimal, it should refer to a TLSA RRset, which MUST contain at least one TLSA record that matches the server's certificate chain, but will often contain additional records that do not. 8. Great care must be taken (with Certificate usages other than DANE-EE(3)) to ensure that the TLSA record matches a certificate that is actually part of the server's chain and not just some random unrelated certificate that happens to be present in the server certificate message. Many implementors fail to check this. 9. This draft should reiterate the requirement that with certificate usage DANE-TA(2), the server MUST include the trust-anchor certificate in its certificate message even if that trust-anchor is self-signed (root CAs are NOT optional with DANE-TA(2)). 10. Validation of RRSIGs is a subtle art, the client will definitely need to check not only the signatures but also the validity intervals of all RRSIGs (the client must trust its own clock or have access to a trusted time source). Since the server forwards wire-format RRsets, these include TTLs, and clients might plausibly cache these, provided the TTLs are consistent with the RRSIG validity intervals. The draft might provide guidance on any client-side caching (clients might e.g. not even send the extension when they have unexpired cached TLSA data from a previous interaction with the server). 11. Finally, Shumon Huque (mostly) and I (helping out) are writing a draft to specify DANE TLSA for client authentication. If and when that progresses (WG adoption, ...), there may need to be a similar extension, allowing a client to forward its DNSSEC-validated TLSA RRset. This is not an immediate priority and can be re-evaluated later. -- Viktor. From nobody Tue Jun 30 01:20: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 689821A1ADF for ; Tue, 30 Jun 2015 01:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, 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 54_cUljvSpop for ; Tue, 30 Jun 2015 01:20:25 -0700 (PDT) Received: from emh03.mail.saunalahti.fi (emh03.mail.saunalahti.fi [62.142.5.109]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B1BB1A1A9E for ; Tue, 30 Jun 2015 01:20:24 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id 391EA1887A9; Tue, 30 Jun 2015 11:20:22 +0300 (EEST) Date: Tue, 30 Jun 2015 11:20:22 +0300 From: Ilari Liusvaara To: Simon Josefsson Message-ID: <20150630082022.GB6141@LK-Perkele-VII> References: <87lhf29nr4.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87lhf29nr4.fsf@latte.josefsson.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] PKIX drafts on EdDSA/Ed25519 and Curve25519/Curve448 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 30 Jun 2015 08:20:26 -0000 On Tue, Jun 30, 2015 at 12:02:39AM +0200, Simon Josefsson wrote: > > A couple of people suggested to define encodings for Curve25519/Curve448 > (the CFRG curves) public keys. I didn't see that this necessarily had > to be in the above document, so I put it in a separate document. I'm > not entirely sure how useful this is, or if I may have completely > misunderstood what people had in mind. Well, EdDSA-like scheme (obtained by dropping constraints on curve and hash[1] and generation of a and seed[2]) would be: (a and seed generated from secret) r = h(seed || M) R = rB A = aB s = (r + h(encode_p(R) || encode_p(A) || M) * a) mod l signature = encode_p(R) || encode_s(s) public key = encode_p(A) (Multiply equation for s to get verification equation: sB = R + h(encode_p(R) || encode_p(A) || M) * A ) (One can obtain Ed25519 from this by substituting suitable a / seed generation, B and functions h, encode_p and encode_a.) And since encode_p(X) is inside hash, one must pin it down for the scheme to work (interoperate between signers and verifiers), along with the hash function h to use. Edwards curves are always constant or quadric in x for in every term of curve equation. Which means that x can be compressed to a single LSB bit (Ed25519 paper is somewhat unclearly worded IMO, but this is what it does for prime curves[3][4]). There's also encode_s(x), but it is straightforward (can just use little-endian base-256 integer encoding. [1] Enabling it to work on curves other than very few ones, especially with standard-issue hashes. [2] Since hash function length is insufficient for the method used in Ed25519 without using exotic hashes. [3] There are other possibilities, but LSB bit (even/odd) seems to be the easiest to extract and to compare. [4] For Ed448 there is also encoding from Ed448-Goldilocks, which is 56 bytes (448 bits) instead of 57 bytes (449 bits). But it is fair bit more complicated (slow) than straightforward point compression. -Ilari From nobody Tue Jun 30 12:01: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 92F731B2C7B for ; Tue, 30 Jun 2015 12:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.155 X-Spam-Level: ** X-Spam-Status: No, score=2.155 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_14=0.6, RDNS_DYNAMIC=0.982, 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 jkycUNvz8vch for ; Tue, 30 Jun 2015 12:00:58 -0700 (PDT) Received: from aspartame.shiftleft.org (199-116-74-168-v301.PUBLIC.monkeybrains.net [199.116.74.168]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E4221B37D8 for ; Tue, 30 Jun 2015 12:00:45 -0700 (PDT) Received: from [10.184.148.249] (unknown [209.36.6.242]) by aspartame.shiftleft.org (Postfix) with ESMTPSA id B07C93A9C5; Tue, 30 Jun 2015 11:57:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shiftleft.org; s=sldo; t=1435690630; bh=t6bCMya5Kg2MRMylozvoNDqGi8rwBoFALcHvjhnh+k8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=RJ9hrs52TYoKV1I26ngO3hArfuHy8CCpGnu/wFq5Fl2WBclHchdQ4uYws6DPJWPi4 NRlSWW+i3t0x6fImKUrtiNwRB8OnalznFGYgdjTtNQfn1T3CnfsyNbWPvodFRUkU74 Ebv0UDV0tDLnNxaWbMAQx0vduoU4EJQ3GQnpuT6s= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Michael Hamburg In-Reply-To: <20150630082022.GB6141@LK-Perkele-VII> Date: Tue, 30 Jun 2015 12:00:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0F04C44E-8DFF-47EB-9717-90179BF4ABE1@shiftleft.org> References: <87lhf29nr4.fsf@latte.josefsson.org> <20150630082022.GB6141@LK-Perkele-VII> To: Ilari Liusvaara X-Mailer: Apple Mail (2.2102) Archived-At: Cc: Simon Josefsson , tls@ietf.org Subject: Re: [TLS] PKIX drafts on EdDSA/Ed25519 and Curve25519/Curve448 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 30 Jun 2015 19:00:59 -0000 > On Jun 30, 2015, at 1:20 AM, Ilari Liusvaara = wrote: >=20 > On Tue, Jun 30, 2015 at 12:02:39AM +0200, Simon Josefsson wrote: >>=20 >> A couple of people suggested to define encodings for = Curve25519/Curve448 >> (the CFRG curves) public keys. I didn't see that this necessarily = had >> to be in the above document, so I put it in a separate document. I'm >> not entirely sure how useful this is, or if I may have completely >> misunderstood what people had in mind.=20 >=20 > Well, EdDSA-like scheme (obtained by dropping constraints on curve > and hash[1] and generation of a and seed[2]) would be: >=20 > (a and seed generated from secret) > r =3D h(seed || M) > R =3D rB > A =3D aB > s =3D (r + h(encode_p(R) || encode_p(A) || M) * a) mod l > signature =3D encode_p(R) || encode_s(s) > public key =3D encode_p(A) >=20 > (Multiply equation for s to get verification equation: > sB =3D R + h(encode_p(R) || encode_p(A) || M) * A ) >=20 > (One can obtain Ed25519 from this by substituting suitable a / seed > generation, B and functions h, encode_p and encode_a.) >=20 >=20 > And since encode_p(X) is inside hash, one must pin it down for the > scheme to work (interoperate between signers and verifiers), along > with the hash function h to use. >=20 > Edwards curves are always constant or quadric in x for in every > term of curve equation. Which means that x can be compressed to > a single LSB bit (Ed25519 paper is somewhat unclearly worded IMO, > but this is what it does for prime curves[3][4]). >=20 > There's also encode_s(x), but it is straightforward (can just use > little-endian base-256 integer encoding. >=20 >=20 > [1] Enabling it to work on curves other than very few ones, especially > with standard-issue hashes. >=20 > [2] Since hash function length is insufficient for the method used in > Ed25519 without using exotic hashes. >=20 > [3] There are other possibilities, but LSB bit (even/odd) seems to be > the easiest to extract and to compare. >=20 > [4] For Ed448 there is also encoding from Ed448-Goldilocks, which is > 56 bytes (448 bits) instead of 57 bytes (449 bits). But it is fair > bit more complicated (slow) than straightforward point compression. >=20 >=20 > -Ilari To clarify, the encoding in Ed448-Goldilocks, and its successor = =E2=80=9Cdecaf=E2=80=9D, are more complicated than straightforward point compression but not significantly slower. There is also the alternative of (low bit of x is 0) ? y : -y, with the = identity (0,1) mapped arbitrarily to 1. As for hash functions, the hash function used to produce the challenge doesn=E2=80=99t have to be uniform. It doesn=E2=80=99t even have to = output a number as big as the curve =E2=80=94 half as big is good enough =E2=80=94 but most = schemes use the full length for extra conservatism. Also, if the curve order is = close to a power of 2 (i.e. 2^bleh +- O(2^(bleh/2))), then a hash the same length as the order is good enough for choosing the seed. You only need a longer seed if the curve is not close enough to a power of 2, eg P256 or Brainpool. But it is nice to be able to choose the same hash function = for every curve of the same size. Cheers, =E2=80=94 Mike From nobody Tue Jun 30 13:07: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 56A451B2CB3 for ; Tue, 30 Jun 2015 13:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, 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 kbXfCAn2-VEz for ; Tue, 30 Jun 2015 13:07:24 -0700 (PDT) Received: from emh07.mail.saunalahti.fi (emh07.mail.saunalahti.fi [62.142.5.117]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 437631B2CB7 for ; Tue, 30 Jun 2015 13:07:24 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id 5B6873FCC; Tue, 30 Jun 2015 23:07:21 +0300 (EEST) Date: Tue, 30 Jun 2015 23:07:21 +0300 From: Ilari Liusvaara To: Michael Hamburg Message-ID: <20150630200720.GA19085@LK-Perkele-VII> References: <87lhf29nr4.fsf@latte.josefsson.org> <20150630082022.GB6141@LK-Perkele-VII> <0F04C44E-8DFF-47EB-9717-90179BF4ABE1@shiftleft.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0F04C44E-8DFF-47EB-9717-90179BF4ABE1@shiftleft.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: Simon Josefsson , tls@ietf.org Subject: Re: [TLS] PKIX drafts on EdDSA/Ed25519 and Curve25519/Curve448 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 30 Jun 2015 20:07:27 -0000 On Tue, Jun 30, 2015 at 12:00:44PM -0700, Michael Hamburg wrote: > > > On Jun 30, 2015, at 1:20 AM, Ilari Liusvaara wrote: > > > > On Tue, Jun 30, 2015 at 12:02:39AM +0200, Simon Josefsson wrote: > >> > >> A couple of people suggested to define encodings for Curve25519/Curve448 > >> (the CFRG curves) public keys. I didn't see that this necessarily had > >> to be in the above document, so I put it in a separate document. I'm > >> not entirely sure how useful this is, or if I may have completely > >> misunderstood what people had in mind. > > > > Well, EdDSA-like scheme (obtained by dropping constraints on curve > > and hash[1] and generation of a and seed[2]) would be: > > > > (a and seed generated from secret) > > r = h(seed || M) > > R = rB > > A = aB > > s = (r + h(encode_p(R) || encode_p(A) || M) * a) mod l > > signature = encode_p(R) || encode_s(s) > > public key = encode_p(A) > > > > (Multiply equation for s to get verification equation: > > sB = R + h(encode_p(R) || encode_p(A) || M) * A ) > > > > (One can obtain Ed25519 from this by substituting suitable a / seed > > generation, B and functions h, encode_p and encode_a.) > > > > > > And since encode_p(X) is inside hash, one must pin it down for the > > scheme to work (interoperate between signers and verifiers), along > > with the hash function h to use. > > > > Edwards curves are always constant or quadric in x for in every > > term of curve equation. Which means that x can be compressed to > > a single LSB bit (Ed25519 paper is somewhat unclearly worded IMO, > > but this is what it does for prime curves[3][4]). > > > > There's also encode_s(x), but it is straightforward (can just use > > little-endian base-256 integer encoding. > > > > > > [1] Enabling it to work on curves other than very few ones, especially > > with standard-issue hashes. > > > > [2] Since hash function length is insufficient for the method used in > > Ed25519 without using exotic hashes. > > > > [3] There are other possibilities, but LSB bit (even/odd) seems to be > > the easiest to extract and to compare. > > > > [4] For Ed448 there is also encoding from Ed448-Goldilocks, which is > > 56 bytes (448 bits) instead of 57 bytes (449 bits). But it is fair > > bit more complicated (slow) than straightforward point compression. > > > > > > -Ilari > > To clarify, the encoding in Ed448-Goldilocks, and its successor “decaf”, > are more complicated than straightforward point compression but not > significantly slower. > > There is also the alternative of (low bit of x is 0) ? y : -y, with the identity > (0,1) mapped arbitrarily to 1. As for some explanation how to decode that... Use the y as y coordinate of the point and then force LSB(x) to 0. The resulting point is either (x,y) or (-x,-y)=(x,y)+(0,-1) (it has to be -x because curve is symmetric w.r.t. axes and the LSB(x) flipped). The (0,-1) term can be canceled out by multiplying both sides of the check equation by some even number coprime to basepoint order (8 works, and Ed25519 already recommends multiplication by that). That would certainly enable encoding Ed448 points to 56 bytes instead of 57. Also, it looks simple, fast to encode and reasonably fast to decode. > As for hash functions, the hash function used to produce the challenge > doesn’t have to be uniform. It doesn’t even have to output a number as > big as the curve — half as big is good enough — but most schemes use > the full length for extra conservatism. Also, if the curve order is close to > a power of 2 (i.e. 2^bleh +- O(2^(bleh/2))), then a hash the same length > as the order is good enough for choosing the seed. You only need a > longer seed if the curve is not close enough to a power of 2, eg P256 or > Brainpool. But it is nice to be able to choose the same hash function for > every curve of the same size. Yeah, I have noticed that when calculating what would be enough for various curves. If you are wondering where that 5/4 rule in signature proposal comes from, it is from those calculations. The formulas I use yield acceptable values already for 256-bit hash with Curve25519 (Delta=0.015 bits) and 448-bit hash with Curve448 (Delta=0.171 bits). The formulas are pretty conservative (e.g. assuming that 100% of entropy loss is converted to information about private key, and assume ridiculous amount of signatures), but maybe not conservative enough. -Ilari From nobody Tue Jun 30 13:26: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 F27C81B2D1E for ; Tue, 30 Jun 2015 13:26:29 -0700 (PDT) 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 RzIsgJ4kVQ0F for ; Tue, 30 Jun 2015 13:26:27 -0700 (PDT) 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 04EFA1B2D7B for ; Tue, 30 Jun 2015 13:26:16 -0700 (PDT) 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 E8D6F44724 for ; Tue, 30 Jun 2015 22:26:13 +0200 (CEST) X-purgate-ID: 152705::1435695973-00005316-A2004B17/0/0 X-purgate-size: 3323 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id D9B6D42F9A for ; Tue, 30 Jun 2015 22:26:13 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id D07251A1AD; Tue, 30 Jun 2015 22:26:13 +0200 (CEST) To: tls@ietf.org Date: Tue, 30 Jun 2015 22:26:13 +0200 (CEST) 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: <20150630202613.D07251A1AD@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Subject: [TLS] RFC7301 ALPN conflicting objectives about app-specific server certificates 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, 30 Jun 2015 20:26:30 -0000 I'm currently implementing support for ALPN in our middlware, and I'm wondering how to account for ALPN in the client side session caching management, because rfc7301 describes two mutually exclusive objectives and the ALPN protocol does not provide a means for the server to disambiguate the desired semantics in the ServerHello response. rfc7301, https://tools.ietf.org/html/rfc7301#section-1 Section 1. last sentence of paragraph 2 (end of page 2): Further, it would be advantageous to allow certificate selection based on the negotiated application protocol. Section 1, last sentence of paragraph 4 (last paragraph): The application protocol negotiation can thus be accomplished within the TLS handshake, without adding network round-trips, and allows the server to associate a different certificate with each application protocol, if desired. is in conflict with Section 3.1, last paragraph https://tools.ietf.org/html/rfc7301#page-5 Unlike many other TLS extensions, this extension does not establish properties of the session, only of the connection. When session resumption or session tickets [RFC5077] are used, the previous contents of this extension are irrelevant, and only the values in the new handshake messages are considered. Currently, my client-side session cache management, and the decision whether to propose a TLS session to the server for resumption, is based on a match of the application supplied "target name" which is usually an fqdn hostname, but could also be an abbreviated hostname or an IP address. When the server does not resume the proposed session, and performs a full handshake instead, my client purges the previous cached session and adds the newly established session to the client-side session cache instead. If the server uses distict server certificates per application protocol and properly(!!) performs a full handshake if the server certificate does not fit the requested application protocol, then alternating requests with two different protocols to the same server will result in constant full TLS handshakes. But what can also easily happen, is that the server is inappropriately sharing the server-side session cache an incorrectly resuming sessions associated with the wrong server certificate (a different certificate than what the server would select if it would perform a full TLS handshake), and if the different server certificate attributes are relevant to the application protocol, then this would result in random client-side errors (failed server certificate validation) when there is already a session for the _other_ app in the client-side session cache. I've seen incorrect server-side session cache pooling before, e.g. a few years ago between docs.google.com and www.google.com. Essentially, I believe that tagging of the session with the ALPN negotiated protocol to result in more "predictable" behaviour, because it will not interfere with client-side session cache management and not result in occasional confusion should other server implementors ever make their servers use different server certificates for different ALPN-negotiated protocols. -Martin From nobody Tue Jun 30 13:30: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 69D121B2DB6 for ; Tue, 30 Jun 2015 13:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.156 X-Spam-Level: ** X-Spam-Status: No, score=2.156 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RDNS_DYNAMIC=0.982, 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 jhqLgcaQ3gI0 for ; Tue, 30 Jun 2015 13:30:37 -0700 (PDT) Received: from aspartame.shiftleft.org (199-116-74-168-v301.PUBLIC.monkeybrains.net [199.116.74.168]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64D831B2DB9 for ; Tue, 30 Jun 2015 13:30:37 -0700 (PDT) Received: from [10.184.148.249] (unknown [209.36.6.242]) by aspartame.shiftleft.org (Postfix) with ESMTPSA id 8DA9A3A9C5; Tue, 30 Jun 2015 13:27:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shiftleft.org; s=sldo; t=1435696022; bh=bhcfRQIewcepbSw32ea1b2zPIBRaN71LCfLyJoBhi2A=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=MtGQS5WFH4NPUi8oMNMGRmBe3/jBqS8AI4sKvFyKiWd2yg2yALJQ/BivGJ+U/K0jf EU4GhN1xZ0VrvngdguEiNSNRVtBoMrp1YTB6vhoI4suLlKDqUEYPNl0iohSJApTV1v SNZQMfFMkwNr5vGIqeGOB5LEZeKc/nGS2AdsXUsk= Content-Type: multipart/alternative; boundary="Apple-Mail=_66BB520E-EC4F-445D-B10F-6DBF62D4916B" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Michael Hamburg In-Reply-To: <20150630200720.GA19085@LK-Perkele-VII> Date: Tue, 30 Jun 2015 13:30:37 -0700 Message-Id: <81CB3AC3-E3B6-4AE6-B19B-8E9789E07EC9@shiftleft.org> References: <87lhf29nr4.fsf@latte.josefsson.org> <20150630082022.GB6141@LK-Perkele-VII> <0F04C44E-8DFF-47EB-9717-90179BF4ABE1@shiftleft.org> <20150630200720.GA19085@LK-Perkele-VII> To: Ilari Liusvaara X-Mailer: Apple Mail (2.2102) Archived-At: Cc: Simon Josefsson , tls@ietf.org Subject: Re: [TLS] PKIX drafts on EdDSA/Ed25519 and Curve25519/Curve448 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 30 Jun 2015 20:30:39 -0000 --Apple-Mail=_66BB520E-EC4F-445D-B10F-6DBF62D4916B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 30, 2015, at 1:07 PM, Ilari Liusvaara = wrote: >=20 > On Tue, Jun 30, 2015 at 12:00:44PM -0700, Michael Hamburg wrote: >>=20 >>> On Jun 30, 2015, at 1:20 AM, Ilari Liusvaara = wrote: >>>=20 >>> On Tue, Jun 30, 2015 at 12:02:39AM +0200, Simon Josefsson wrote: >>>>=20 >>>> A couple of people suggested to define encodings for = Curve25519/Curve448 >>>> (the CFRG curves) public keys. I didn't see that this necessarily = had >>>> to be in the above document, so I put it in a separate document. = I'm >>>> not entirely sure how useful this is, or if I may have completely >>>> misunderstood what people had in mind.=20 >>>=20 >>> Well, EdDSA-like scheme (obtained by dropping constraints on curve >>> and hash[1] and generation of a and seed[2]) would be: >>>=20 >>> (a and seed generated from secret) >>> r =3D h(seed || M) >>> R =3D rB >>> A =3D aB >>> s =3D (r + h(encode_p(R) || encode_p(A) || M) * a) mod l >>> signature =3D encode_p(R) || encode_s(s) >>> public key =3D encode_p(A) >>>=20 >>> (Multiply equation for s to get verification equation: >>> sB =3D R + h(encode_p(R) || encode_p(A) || M) * A ) >>>=20 >>> (One can obtain Ed25519 from this by substituting suitable a / seed >>> generation, B and functions h, encode_p and encode_a.) >>>=20 >>>=20 >>> And since encode_p(X) is inside hash, one must pin it down for the >>> scheme to work (interoperate between signers and verifiers), along >>> with the hash function h to use. >>>=20 >>> Edwards curves are always constant or quadric in x for in every >>> term of curve equation. Which means that x can be compressed to >>> a single LSB bit (Ed25519 paper is somewhat unclearly worded IMO, >>> but this is what it does for prime curves[3][4]). >>>=20 >>> There's also encode_s(x), but it is straightforward (can just use >>> little-endian base-256 integer encoding. >>>=20 >>>=20 >>> [1] Enabling it to work on curves other than very few ones, = especially >>> with standard-issue hashes. >>>=20 >>> [2] Since hash function length is insufficient for the method used = in >>> Ed25519 without using exotic hashes. >>>=20 >>> [3] There are other possibilities, but LSB bit (even/odd) seems to = be >>> the easiest to extract and to compare. >>>=20 >>> [4] For Ed448 there is also encoding from Ed448-Goldilocks, which is >>> 56 bytes (448 bits) instead of 57 bytes (449 bits). But it is fair >>> bit more complicated (slow) than straightforward point compression. >>>=20 >>>=20 >>> -Ilari >>=20 >> To clarify, the encoding in Ed448-Goldilocks, and its successor = =E2=80=9Cdecaf=E2=80=9D, >> are more complicated than straightforward point compression but not >> significantly slower. >>=20 >> There is also the alternative of (low bit of x is 0) ? y : -y, with = the identity >> (0,1) mapped arbitrarily to 1. >=20 > As for some explanation how to decode that... Use the y as y = coordinate of > the point and then force LSB(x) to 0. The resulting point is either = (x,y) > or (-x,-y)=3D(x,y)+(0,-1) (it has to be -x because curve is symmetric = w.r.t. > axes and the LSB(x) flipped). >=20 > The (0,-1) term can be canceled out by multiplying both sides of the > check equation by some even number coprime to basepoint order (8 = works, > and Ed25519 already recommends multiplication by that).=20 >=20 > That would certainly enable encoding Ed448 points to 56 bytes instead = of > 57. Also, it looks simple, fast to encode and reasonably fast to = decode. Thanks for adding that missing explanation. I=E2=80=99m not pushing = this as necessarily a good idea; I just wanted it to be out there. >> As for hash functions, the hash function used to produce the = challenge >> doesn=E2=80=99t have to be uniform. It doesn=E2=80=99t even have to = output a number as >> big as the curve =E2=80=94 half as big is good enough =E2=80=94 but = most schemes use >> the full length for extra conservatism. Also, if the curve order is = close to >> a power of 2 (i.e. 2^bleh +- O(2^(bleh/2))), then a hash the same = length >> as the order is good enough for choosing the seed. You only need a >> longer seed if the curve is not close enough to a power of 2, eg P256 = or >> Brainpool. But it is nice to be able to choose the same hash = function for >> every curve of the same size. >=20 > Yeah, I have noticed that when calculating what would be enough for > various curves. If you are wondering where that 5/4 rule in signature > proposal comes from, it is from those calculations. >=20 > The formulas I use yield acceptable values already for 256-bit hash = with > Curve25519 (Delta=3D0.015 bits) and 448-bit hash with Curve448 = (Delta=3D0.171 > bits). The formulas are pretty conservative (e.g. assuming that 100% = of > entropy loss is converted to information about private key, and assume > ridiculous amount of signatures), but maybe not conservative enough. >=20 >=20 > -Ilari Ah, nice. What=E2=80=99s delta? Is that (work to break signatures with = uniform hash) - (work to break with biased hash)? In that case it=E2=80=99s = conservative enough. =E2=80=94 Mike= --Apple-Mail=_66BB520E-EC4F-445D-B10F-6DBF62D4916B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jun 30, 2015, at 1:07 PM, Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote:

On Tue, Jun 30, 2015 at 12:00:44PM -0700, = Michael Hamburg wrote:

On Jun 30, 2015, at 1:20 AM, Ilari Liusvaara = <ilari.liusvaara@elisanet.fi> wrote:

On Tue, Jun 30, 2015 at 12:02:39AM +0200, Simon Josefsson = wrote:

A= couple of people suggested to define encodings for = Curve25519/Curve448
(the CFRG curves) public keys.  I = didn't see that this necessarily had
to be in the above = document, so I put it in a separate document.  I'm
not = entirely sure how useful this is, or if I may have completely
misunderstood what people had in mind. 

Well, EdDSA-like scheme (obtained = by dropping constraints on curve
and hash[1] and = generation of a and seed[2])  would be:

(a and seed generated from secret)
r =3D h(seed = || M)
R =3D rB
A =3D aB
s =3D = (r + h(encode_p(R) || encode_p(A) || M) * a) mod l
signature= =3D encode_p(R) || encode_s(s)
public key =3D = encode_p(A)

(Multiply equation for s to get = verification equation:
sB =3D R + h(encode_p(R) || = encode_p(A) || M) * A )

(One can obtain = Ed25519 from this by substituting suitable a / seed
generation, B and functions h, encode_p and encode_a.)


And since encode_p(X) is inside = hash, one must pin it down for the
scheme to work = (interoperate between signers and verifiers), along
with = the hash function h to use.

Edwards curves = are always constant or quadric in x for in every
term of = curve equation. Which means that x can be compressed to
a = single LSB bit (Ed25519 paper is somewhat unclearly worded IMO,
but this is what it does for prime curves[3][4]).

There's also encode_s(x), but it is = straightforward (can just use
little-endian base-256 = integer encoding.


[1] = Enabling it to work on curves other than very few ones, especially
with standard-issue hashes.

[2] = Since hash function length is insufficient for the method used in
Ed25519 without using exotic hashes.

[3] There are other possibilities, but LSB bit (even/odd) = seems to be
the easiest to extract and to compare.

[4] For Ed448 there is also encoding from = Ed448-Goldilocks, which is
56 bytes (448 bits) instead of = 57 bytes (449 bits). But it is fair
bit more complicated = (slow) than straightforward point compression.


-Ilari

To clarify, the encoding in Ed448-Goldilocks, and its = successor =E2=80=9Cdecaf=E2=80=9D,
are more complicated = than straightforward point compression but not
significantly= slower.

There is also the alternative of = (low bit of x is 0) ? y : -y, with the identity
(0,1) = mapped arbitrarily to 1.

As for some explanation how to decode that... = Use the y as y coordinate of
the point and then force = LSB(x) to 0. The resulting point is either (x,y)
or (-x,-y)=3D(x,y)+(0,-1)  (it has to be -x = because curve is symmetric w.r.t.
axes and the LSB(x) flipped).

The (0,-1) term can be canceled out by = multiplying both sides of the
check equation by some = even number coprime to basepoint order (8 works,
and Ed25519 already recommends multiplication by = that). 

That would certainly enable encoding Ed448 = points to 56 bytes instead of
57. Also, it looks simple, = fast to encode and reasonably fast to decode.

Thanks for = adding that missing explanation.  I=E2=80=99m not pushing this as = necessarily a good idea; I just wanted it to be out there.

As for hash functions, the hash function used to = produce the challenge
doesn=E2=80=99t have to be uniform. =  It doesn=E2=80=99t even have to output a number as
big= as the curve =E2=80=94 half as big is good enough =E2=80=94 but most = schemes use
the full length for extra conservatism. =  Also, if the curve order is close to
a power of 2 = (i.e. 2^bleh +- O(2^(bleh/2))), then a hash the same length
as the order is good enough for choosing the seed.  You = only need a
longer seed if the curve is not close enough = to a power of 2, eg P256 or
Brainpool.  But it is = nice to be able to choose the same hash function for
every = curve of the same size.

Yeah, I have noticed that when calculating what = would be enough for
various curves. If you are = wondering where that 5/4 rule in signature
proposal comes from, it is from those = calculations.

The formulas I use yield = acceptable values already for 256-bit hash with
Curve25519 (Delta=3D0.015 bits) and 448-bit hash = with Curve448 (Delta=3D0.171
bits). The formulas are = pretty conservative (e.g. assuming that 100% of
entropy loss is converted to information about = private key, and assume
ridiculous amount of = signatures), but maybe not conservative enough.


-Ilari

Ah, nice.  What=E2=80=99s delta?  Is = that (work to break signatures with uniform hash)
- (work to = break with biased hash)?  In that case it=E2=80=99s conservative = enough.

=E2=80=94 = Mike
= --Apple-Mail=_66BB520E-EC4F-445D-B10F-6DBF62D4916B-- From nobody Tue Jun 30 13:38: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 48E691B2ECF for ; Tue, 30 Jun 2015 13:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Y46IvyXFBHqJ for ; Tue, 30 Jun 2015 13:38:07 -0700 (PDT) Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8482F1B2ECE for ; Tue, 30 Jun 2015 13:37:57 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id 786841A25DA; Tue, 30 Jun 2015 23:37:55 +0300 (EEST) Date: Tue, 30 Jun 2015 23:37:55 +0300 From: Ilari Liusvaara To: Michael Hamburg Message-ID: <20150630203755.GA19416@LK-Perkele-VII> References: <87lhf29nr4.fsf@latte.josefsson.org> <20150630082022.GB6141@LK-Perkele-VII> <0F04C44E-8DFF-47EB-9717-90179BF4ABE1@shiftleft.org> <20150630200720.GA19085@LK-Perkele-VII> <81CB3AC3-E3B6-4AE6-B19B-8E9789E07EC9@shiftleft.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <81CB3AC3-E3B6-4AE6-B19B-8E9789E07EC9@shiftleft.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: Simon Josefsson , tls@ietf.org Subject: Re: [TLS] PKIX drafts on EdDSA/Ed25519 and Curve25519/Curve448 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 30 Jun 2015 20:38:09 -0000 On Tue, Jun 30, 2015 at 01:30:37PM -0700, Michael Hamburg wrote: > > > On Jun 30, 2015, at 1:07 PM, Ilari Liusvaara wrote: > > > > The formulas I use yield acceptable values already for 256-bit hash with > > Curve25519 (Delta=0.015 bits) and 448-bit hash with Curve448 (Delta=0.171 > > bits). The formulas are pretty conservative (e.g. assuming that 100% of > > entropy loss is converted to information about private key, and assume > > ridiculous amount of signatures), but maybe not conservative enough. > > > > > > -Ilari > > Ah, nice. What’s delta? Is that (work to break signatures with uniform hash) > - (work to break with biased hash)? In that case it’s conservative enough. sqrt(l) times difference of entropies between uniform distribution and modulo distribution. -Ilari From nobody Tue Jun 30 14:10: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 6FEC51B29BB; Tue, 30 Jun 2015 14:10:27 -0700 (PDT) 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 pzy5k1cSjE2M; Tue, 30 Jun 2015 14:10:25 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 123C71B29A8; Tue, 30 Jun 2015 14:10:25 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTP id AB6622005E627; Tue, 30 Jun 2015 14:10:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=nomountain.net; h= message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; s= nomountain.net; bh=xWV3aOnylSofTe3X1pgWWO+gw9c=; b=ZePoNx2pi+qud qQToVVzv/gfwhE6SzCV/vBXLAAO1u58c3Vg5GoT95zCevBTGLGnHkwgRcAyea+UT Nu3/vZurhaLg/+C5Joz7nHvYr3TQuvVN8GewcPfiu6maJD0TZSTgxVxsLI50gwib aXJwo4cV4MFJpfFMj4zEN/9HQkXXNU= Received: from spandex.local (216-67-117-38-rb3.fai.dsl.dynamic.acsalaska.net [216.67.117.38]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: melinda.shore@nomountain.net) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTPSA id 0EAE22005E628; Tue, 30 Jun 2015 14:10:23 -0700 (PDT) Message-ID: <559305BD.9050502@nomountain.net> Date: Tue, 30 Jun 2015 13:10:21 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: tls@ietf.org References: <55922571.8080605@nomountain.net> <20150630062518.GC14121@mournblade.imrryr.org> In-Reply-To: <20150630062518.GC14121@mournblade.imrryr.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: dane@ietf.org Subject: Re: [TLS] draft-shore-tls-dnssec-chain-extension-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, 30 Jun 2015 21:10:27 -0000 Thanks for the detailed review, Viktor. Some of the issues you've raised are still things we're hashing through, and we're grateful for your clarifications. We'll be getting a new draft out before document submission closes and it will incorporate some of your suggestions. On 6/29/15 10:25 PM, Viktor Dukhovni wrote: > Similar considerations apply to server-to-server XMPP traffic. > Thus the extension in question is only relevant with protocols > where TLS (with authenticaiton) is mandatory, and DANE is a > potentially attractive alternative PKI. With opportunistic DANE > TLS, the extension is inevitably too late. Right now our main use case is https, as browser vendors are extremely sensitive to increased latency in connection establishment, and anything we can do to help that can make it easier to argue for implementation. We have, though, been talking about other application protocols, including XMPP, but haven't worked through the details. In particular we haven't looked at opportunistic DANE usage. We'll add some text clarifying that this extension would be inapplicable in those cases. > Speaking of RRsets, are the RRs in each RRset returned by the server > required to be sorted in canonical order? That's one of the things we've been discussing. One of the things that's been driving our decisions so far has been implementation considerations, and in particular how to deliver the data needed for validation to a validator that's part of a DNS API. > 4. I think the Section 4 SNI interaction would be a lot cleaner, > if SNI is mandatory for clients that use the proposed extension. > In which case the server can only respond with a leaf TLSA RRset > (and chain of RRSIG/DNSKEY/DS/... records) whose "base domain" ( > see section 3 of RFC6698 and soon definition of TLSA base domain > in draft-ietf-dane-ops-13 (later this week)). Using some random > name for the server's IP address is not a good idea IMHO. PTR > records are too often poorly correlated with the client's notion > of the target server name. Right, and we actually changed that back and forth a few times. It's not clear to us that SNI is being used across all applications using TLS. I think that generally we're going to need guidelines for application developers. > 6. Note that the soon up for IESG review draft-ietf-dane-ops > considerably revises the DANE verification logic for TLSA certificate > usage DANE-EE(3). Section 6 should refer to draft-ietf-dane-ops-12 > (soon -13 which responds to AD and GEN-ART comments) as well as > RFC6698. Okay, thanks. > is sub-optimal, it should refer to a TLSA RRset, which MUST contain > at least one TLSA record that matches the server's certificate > chain, but will often contain additional records that do not. That's another issue we're currently working through. We'll have some more thoughtful text in the next revision. > 8. Great care must be taken (with Certificate usages other than > DANE-EE(3)) to ensure that the TLSA record matches a certificate > that is actually part of the server's chain and not just some random > unrelated certificate that happens to be present in the server > certificate message. Many implementors fail to check this. Good point, thanks. > 9. This draft should reiterate the requirement that with certificate > usage DANE-TA(2), the server MUST include the trust-anchor certificate > in its certificate message even if that trust-anchor is self-signed > (root CAs are NOT optional with DANE-TA(2)). Ditto. > 10. Validation of RRSIGs is a subtle art, the client will definitely > need to check not only the signatures but also the validity intervals > of all RRSIGs (the client must trust its own clock or have access > to a trusted time source). Since the server forwards wire-format > RRsets, these include TTLs, and clients might plausibly cache these, > provided the TTLs are consistent with the RRSIG validity intervals. > The draft might provide guidance on any client-side caching (clients > might e.g. not even send the extension when they have unexpired > cached TLSA data from a previous interaction with the server). Will do, but I'm not sure this will make it into the next revision in much detail, given time constraints. But yes, I agree it should go into the document in greater detail in the future. Thanks again, Melind -- Melinda Shore No Mountain Software melinda.shore@nomountain.net "Software longa, hardware brevis." From nobody Tue Jun 30 14: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 175501A9096 for ; Tue, 30 Jun 2015 14:31:30 -0700 (PDT) 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, 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 Y7SLnx2Z4SGc for ; Tue, 30 Jun 2015 14:31:26 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0108.outbound.protection.outlook.com [207.46.100.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C07481A9093 for ; Tue, 30 Jun 2015 14:31:26 -0700 (PDT) Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) with Microsoft SMTP Server (TLS) id 15.1.195.15; Tue, 30 Jun 2015 21:31:24 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0195.005; Tue, 30 Jun 2015 21:31:24 +0000 From: Andrei Popov To: "mrex@sap.com" , "tls@ietf.org" Thread-Topic: [TLS] RFC7301 ALPN conflicting objectives about app-specific server certificates Thread-Index: AQHQs3MRkef6bIVx+0iShvNHWvsYnZ3FjFPw Date: Tue, 30 Jun 2015 21:31:24 +0000 Message-ID: References: <20150630202613.D07251A1AD@ld9781.wdf.sap.corp> In-Reply-To: <20150630202613.D07251A1AD@ld9781.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: sap.com; dkim=none (message not signed) header.d=none; x-originating-ip: [2001:4898:80e8:ee31::5] x-microsoft-exchange-diagnostics: 1; BLUPR03MB1396; 5:o8KXZHuPSALnSd7CPaU/LyWlIWfYdn5wN1IZmF9YlCxAASxIj4V+4FTiUCcMdJrNJ0vvaHyOnKdauP0YdaXHFvoIvuNWoZMHymklPXiOKoQZNKqukQiqFofg9FCtUq4gWVWmywAEqLpIE2r2Es1udQ==; 24:qbxxOVd1sPJdhw+R/iHgV7MeJ/ErITA43Z0zWjqdUJCJ+1LTAPZbt9A0fT0B8H96qJfKnlxden0MtFtQZOFdcJOoXILUmaoM2R1bpHc5vok=; 20:gEpPxC/UEQelaXyEd11P32KhcoUKnp0vKv9RoPwzHAEI3xVtY2omdDl9HihkskZcElZ3jOYInw3XEHOCwopD+w== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1396; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BLUPR03MB1396; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1396; x-forefront-prvs: 06237E4555 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(52314003)(13464003)(77156002)(62966003)(50986999)(76176999)(92566002)(74316001)(2950100001)(102836002)(2900100001)(5002640100001)(54356999)(33656002)(107886002)(5001770100001)(5001960100002)(189998001)(106116001)(122556002)(99286002)(2501003)(19580395003)(19580405001)(86362001)(2656002)(87936001)(77096005)(5003600100002)(15975445007)(76576001)(15974865002)(46102003)(7059030)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1396; H:BLUPR03MB1396.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-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jun 2015 21:31:24.7775 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1396 Archived-At: Subject: Re: [TLS] RFC7301 ALPN conflicting objectives about app-specific server certificates X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 30 Jun 2015 21:31:30 -0000 Hi Martin, > If the server uses distict server certificates per application protocol a= nd properly(!!) performs a full handshake if the server certificate does no= t fit the requested application protocol, then alternating requests with tw= o different protocols to the same server will result in constant full TLS h= andshakes. Yes, if a client negotiates a different application protocol on a subsequen= t connection, the server may reject resumption (which the server can always= do anyway, regardless of ALPN). =20 > But what can also easily happen, is that the server is inappropriately sh= aring the server-side session cache an incorrectly resuming sessions associ= ated with the wrong server certificate (a different certificate than what t= he server would select if it would perform a full TLS handshake), ... This would be a server bug indeed. > Essentially, I believe that tagging of the session with the ALPN negotiat= ed protocol to result in more "predictable" behaviour, because it will not = interfere with client-side session cache management and not result in occas= ional confusion should other server implementors ever make their servers us= e different server certificates for different ALPN-negotiated protocols. Can you describe how such tagging would work in more detail? Cheers, Andrei -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Rex Sent: Tuesday, June 30, 2015 1:26 PM To: tls@ietf.org Subject: [TLS] RFC7301 ALPN conflicting objectives about app-specific serve= r certificates I'm currently implementing support for ALPN in our middlware, and I'm wonde= ring how to account for ALPN in the client side session caching management,= because rfc7301 describes two mutually exclusive objectives and the ALPN p= rotocol does not provide a means for the server to disambiguate the desired= semantics in the ServerHello response. rfc7301, https://tools.ietf.org/html/rfc7301#section-1 Section 1. last sentence of paragraph 2 (end of page 2): Further, it would be advantageous to allow certificate selection based on the negotiated application protocol. =20 Section 1, last sentence of paragraph 4 (last paragraph): The application protocol negotiation can thus be accomplished within the TLS handshake, without adding network round-trips, and allows the server to associate a different certificate with each application protocol, if desired. is in conflict with Section 3.1, last paragraph https://tools.ietf.org/html/rfc7301#page-5 Unlike many other TLS extensions, this extension does not establish properties of the session, only of the connection. When session resumption or session tickets [RFC5077] are used, the previous contents of this extension are irrelevant, and only the values in the new handshake messages are considered. Currently, my client-side session cache management, and the decision whethe= r to propose a TLS session to the server for resumption, is based on a matc= h of the application supplied "target name" which is usually an fqdn hostna= me, but could also be an abbreviated hostname or an IP address. When the server does not resume the proposed session, and performs a full h= andshake instead, my client purges the previous cached session and adds the= newly established session to the client-side session cache instead. If the server uses distict server certificates per application protocol and= properly(!!) performs a full handshake if the server certificate does not = fit the requested application protocol, then alternating requests with two = different protocols to the same server will result in constant full TLS han= dshakes. But what can also easily happen, is that the server is inappropriately shar= ing the server-side session cache an incorrectly resuming sessions associat= ed with the wrong server certificate (a different certificate than what the= server would select if it would perform a full TLS handshake), and if the = different server certificate attributes are relevant to the application pro= tocol, then this would result in random client-side errors (failed server c= ertificate validation) when there is already a session for the _other_ app = in the client-side session cache. I've seen incorrect server-side session cache pooling before, e.g. a few years ago between docs.google.com and www.google.com. Essentially, I believe that tagging of the session with the ALPN negotiated= protocol to result in more "predictable" behaviour, because it will not in= terfere with client-side session cache management and not result in occasio= nal confusion should other server implementors ever make their servers use = different server certificates for different ALPN-negotiated protocols. -Martin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Tue Jun 30 15:24: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 4641A1B333A for ; Tue, 30 Jun 2015 15:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.723 X-Spam-Level: X-Spam-Status: No, score=0.723 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 6bKE3eQKiaFW for ; Tue, 30 Jun 2015 15:23:59 -0700 (PDT) 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 45E4F1B3339 for ; Tue, 30 Jun 2015 15:23:59 -0700 (PDT) Received: by wiar9 with SMTP id r9so50873692wia.1 for ; Tue, 30 Jun 2015 15:23:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=hyl6NysfFNqNnIepGJHEpj87it9eOwYOTPfD+7ugZU0=; b=K6kXaikKRo627dMmotVoaPU5TWArO4m7ClsAAYqWZ6qprcdjQHQaZoeLoJWSWI72Ob yfWUjOCAbztKhzLOOfvBC88AjG+7nnFQoccAJlezBno/pZm5FobCtKvpZJbs8MODzvmZ NVm7BieosB9DZOMxMWHffn5nxBwHoSCjTI55Ox99ANl0CQys1UxiMuLEtg+G3Gqh+v5m OunkQACo69PpmSYuKm0WBW+dSNfXVm0VX/w+7K4YVX/oZ3XFgUVtf+ktyYrTqElDvxUX XOUtM1cn9spSGCBGtR7XBhLDEsN23lMl9druGCZh7+misBxaY26V8h7C7LPwQ/yUaFra +7Mw== X-Gm-Message-State: ALoCoQmmqiuXPJXD2/3cR/rXIdgsDNEq4uxg+9Qez78RRncNLD1/8jEnZNVYHYneM110s2LXfR7z X-Received: by 10.180.72.179 with SMTP id e19mr38604716wiv.53.1435703037649; Tue, 30 Jun 2015 15:23:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.95.211 with HTTP; Tue, 30 Jun 2015 15:23:18 -0700 (PDT) From: Eric Rescorla Date: Tue, 30 Jun 2015 15:23:18 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=f46d043c7ba28ff9360519c3a995 Archived-At: Subject: [TLS] TLS 1.3 draft-07 sneak peek X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 30 Jun 2015 22:24:02 -0000 --f46d043c7ba28ff9360519c3a995 Content-Type: text/plain; charset=UTF-8 Folks, Yesterday, I posted the -06 draft which snapshots the consensus changes made since -05, specifically: - Prohibit RC4 negotiation for backwards compatibility. - Freeze & deprecate record layer version field. - Update format of signatures with context. - Remove explicit IV. In the background, I've also been working with Hugo, Hoeteck, Karthik, and others to develop a new draft using semi-ephemeral DH based on Hugo's ideas as discussed in Dallas. I'm planning to merge this into master soon and submit it as draft-07 next week, but I wanted to e-mail the list and give people a chance to comment before I do that. I've provided a summary of the major changes and open issues below. Remember, this is a WIP so if you see something wrong, don't panic, but do let me know. CHANGES 1. Move ClientKeyShare into an extension so that the ClientHello is the only message in the client's first flight. This removes a bunch of ugliness around the "early_data" extension which could encapsulate handshake and application data. 2. Added a mechanism for the server to indicate a known (EC)DHE key/configuration which the client can then use in subsequent handshakes (via the known_configuration extension). The net effect here is that the client and server can skip over the signature in subsequent handshakes, which provides benefit when signatures are much slower than key exchange, as with RSA; it also enables 0-RTT. 3. Added support for 0-RTT data, both with and without client authentication. 4. Removed most of the support for resumption in favor of a mechanism proposed by Karthik where you just establish a PSK in connection N which you then use to key a PSK cipher suite in connection N+1. All of these keying mechanisms use a unified key schedule based on two keys the "Ephemeral Secret" (ES) and the "Static Secret" (SS). Depending on the exact handshake type, these may be equal, but the logic is the same regardless. In the process, I also converted the key schedule to use HKDF (per WG consensus). OPEN ISSUES There are still a number of known open issues to discuss: 1. The present known_configuration mechanism allows the client to resurrect the handshake parameters (though not the keys) which were negotiated in a previous handshake, but this is done implicitly, i.e., the server provides a label and the client returns it on the next connection. This has the advantage of keeping things short but the disadvantage the it means that you can't have a static configuration ID for everyone (instead, the server has to somehow embed the properties in the configuration ID). There are (at least) three potential alternative designs: (a) Have the client indicate in his first flight "these are the parameters I expect you to negotiate", along with the configuration identifier, based on what the server negotiated the previous time. [Optionally, the server can run the same negotiation locally and abort on mismatch.] (b) As in (a) but with no indication of the expected parameters, just the configuration ID, and the client just preemptively uses the parameters from the last time and if the negotiation ends up differently, all the data is undecryptable (ugh) and you somehow fall back. (c) Have the server provide a preference list in his ServerConfiguration (this can be the same as in the ClientHello) and have the client do the negotiation based on that rather than the server (as in QUIC). This is a little odd in that it means that sometimes the server selects the parameters and sometimes the client does, but it's not that hard to make this code symmetrical. As I think this through, I am leaning towards (a) but other people's opinions on this topic would be welcome. 2. Should we require that PSK cipher suites where the PSK is used for resumption use compatible ciphers? This is the way it was in TLS 1.2 and below for resumption and tickets, but once you have a PSK, that's not really necessary [0]. So, for instance, if you had the following cipher list order: ECDHE + AES-GCM ECDHE + ChaCha/Poly PSK + ChaCha/Poly PSK + AES-GCM You could potentially negotiate one connection with GCM, use it to establish a shared key, and then reconnect with ChaCha/Poly. This seems like it probably should be something we avoid, though I'm not sure we have a concrete reason why, and it means a weird special case for PSK. Note that this issue might be ameliorated some (though not completely) with a la carte negotiation. 3. I don't currently have PSK/Resumption + 0-RTT working, because you need a way to indicate the expected parameters (see point #1 above). 4. I plan to rewrite the Handshake Protocol Overview (S 6.2) to be clearer. I hope to do this before submitting -07. 5. Security Considerations is badly out of date, so I plan to rewrite that soon, but probably not before Prague. I also intend to do a pretty substantial editorial cleanup pass and potentially some restructuring after Prague. As indicated above, this is still a WIP, so no doubt contains a number of errors, potentially serious ones. Comments and PRs welcome. Thanks, -Ekr [0] With the exception of cryptographic concerns about the use of the same IKM with different hash functions for HKDF, but this is a problem that applies to any use of PSK, not just this one. --f46d043c7ba28ff9360519c3a995 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Folks,

Yesterday, I posted t= he -06 draft which snapshots the consensus changes
made since -05= , specifically:

- Prohibit RC4 negotiation for bac= kwards compatibility.
- Freeze & deprecate record layer versi= on field.
- Update format of signatures with context.
-= Remove explicit IV.


In the backgro= und, I've also been working with Hugo, Hoeteck, Karthik,
and = others to develop a new draft using semi-ephemeral DH based on
Hu= go's ideas as discussed in Dallas. I'm planning to merge this into<= /div>
master soon and submit it as draft-07 next week, but I wanted to<= /div>
e-mail the list and give people a chance to comment before I do
that. I've provided a summary of the major changes and open is= sues
below. Remember, this is a WIP so if you see something wrong= , don't
panic, but do let me know.

<= br>
CHANGES
1. Move ClientKeyShare into an extension so= that the ClientHello
=C2=A0 =C2=A0is the only message in the cli= ent's first flight. This removes
=C2=A0 =C2=A0a bunch of ugli= ness around the "early_data" extension which
=C2=A0 =C2= =A0could encapsulate handshake and application data.

2. Added a mechanism for the server to indicate a known (EC)DHE
=C2=A0 =C2=A0key/configuration which the client can then use in subsequen= t
=C2=A0 =C2=A0handshakes (via the known_configuration extension)= . The net
=C2=A0 =C2=A0effect here is that the client and server = can skip over the
=C2=A0 =C2=A0signature in subsequent handshakes= , which provides benefit
=C2=A0 =C2=A0when signatures are much sl= ower than key exchange, as with
=C2=A0 =C2=A0RSA; it also enables= 0-RTT.

3. Added support for 0-RTT data, both with= and without
=C2=A0 =C2=A0client authentication.

4. Removed most of the support for resumption in favor of
=C2=A0 =C2=A0a mechanism proposed by Karthik where you just establish
=C2=A0 =C2=A0a PSK in connection N which you then use to key a PSK
=C2=A0 =C2=A0cipher suite in connection N+1.

<= div>All of these keying mechanisms use a unified key schedule based on two<= /div>
keys the "Ephemeral Secret" (ES) and the "Static S= ecret"
(SS). Depending on the exact handshake type, these ma= y be equal, but
the logic is the same regardless. In the process,= I also converted
the key schedule to use HKDF (per WG consensus)= .


OPEN ISSUES
There are s= till a number of known open issues to discuss:

1. = The present known_configuration mechanism allows the client to
re= surrect the handshake parameters (though not the keys) which were
negotiated in a previous handshake, but this is done implicitly,
i.e., the server provides a label and the client returns it on
t= he next connection. This has the advantage of keeping things short
but the disadvantage the it means that you can't have a static
<= div>configuration ID for everyone (instead, the server has to somehow
=
embed the properties in the configuration ID). There are (at least)
three potential alternative designs:

=C2= =A0 =C2=A0(a) Have the client indicate in his first flight "these are = the
=C2=A0 =C2=A0 =C2=A0 =C2=A0parameters I expect you to negotia= te", along with the
=C2=A0 =C2=A0 =C2=A0 =C2=A0configuration= identifier, based on what the server
=C2=A0 =C2=A0 =C2=A0 =C2=A0= negotiated the previous time. [Optionally, the server
=C2=A0 =C2= =A0 =C2=A0 =C2=A0can run the same negotiation locally and abort on mismatch= .]

=C2=A0 =C2=A0(b) As in (a) but with no indicati= on of the expected parameters,
=C2=A0 =C2=A0 =C2=A0 =C2=A0just th= e configuration ID, and the client just preemptively
=C2=A0 =C2= =A0 =C2=A0 =C2=A0uses the parameters from the last time and if the negotiat= ion
=C2=A0 =C2=A0 =C2=A0 =C2=A0ends up differently, all the data = is undecryptable
=C2=A0 =C2=A0 =C2=A0 =C2=A0(ugh) and you somehow= fall back.

=C2=A0 =C2=A0(c) Have the server provi= de a preference list in his
=C2=A0 =C2=A0 =C2=A0 =C2=A0ServerConf= iguration (this can be the same as in the
=C2=A0 =C2=A0 =C2=A0 = =C2=A0ClientHello) and have the client do the negotiation based on
=C2=A0 =C2=A0 =C2=A0 =C2=A0that rather than the server (as in QUIC). This= is a little odd
=C2=A0 =C2=A0 =C2=A0 =C2=A0in that it means that= sometimes the server selects the
=C2=A0 =C2=A0 =C2=A0 =C2=A0para= meters and sometimes the client does, but it's not that
=C2= =A0 =C2=A0 =C2=A0 =C2=A0hard to make this code symmetrical.

<= /div>
As I think this through, I am leaning towards (a) but other peopl= e's
opinions on this topic would be welcome.


2. Should we require that PSK cipher suites where t= he PSK is used for
resumption use compatible ciphers? This is the= way it was in TLS 1.2
and below for resumption and tickets, but = once you have a PSK, that's
not really necessary [0]. So, for= instance, if you had the following
cipher list order:
=
=C2=A0 =C2=A0 ECDHE + AES-GCM
=C2=A0 =C2=A0 ECDHE = + ChaCha/Poly
=C2=A0 =C2=A0 PSK + ChaCha/Poly
=C2=A0 = =C2=A0 PSK + AES-GCM

You could potentially negotia= te one connection with GCM, use it
to establish a shared key, and= then reconnect with ChaCha/Poly.
This seems like it probably sho= uld be something we avoid, though
I'm not sure we have a conc= rete reason why, and it means a
weird special case for PSK. Note = that this issue might be
ameliorated some (though not completely)= with a la carte negotiation.


3. I = don't currently have PSK/Resumption + 0-RTT working, because you
<= div>need a way to indicate the expected parameters (see point #1 above).


4. I plan to rewrite the Handshake Pr= otocol Overview (S 6.2)
to be clearer. I hope to do this before s= ubmitting -07.

5. Security Considerations is badly= out of date, so I plan to
rewrite that soon, but probably not be= fore Prague. I also intend
to do a pretty substantial editorial c= leanup pass and potentially
some restructuring after Prague.


As indicated above, this is still a WIP= , so no doubt contains
a number of errors, potentially serious on= es. Comments and PRs
welcome.

Thanks,
-Ekr


[0] With the exception= of cryptographic concerns about the use
of the same IKM with dif= ferent hash functions for HKDF, but this
is a problem that applie= s to any use of PSK, not just this one.

--f46d043c7ba28ff9360519c3a995-- From nobody Tue Jun 30 15:25: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 6EFC71B332E for ; Tue, 30 Jun 2015 15:25:48 -0700 (PDT) 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 zGiXJnZk0DIY for ; Tue, 30 Jun 2015 15:25:45 -0700 (PDT) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (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 435E31B3346 for ; Tue, 30 Jun 2015 15:25:37 -0700 (PDT) Received: by wiar9 with SMTP id r9so50902791wia.1 for ; Tue, 30 Jun 2015 15:25:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=CLxK4NzcZtxISWkefxUFQTmDXdFvhFkRSxdNq1NMJ1Q=; b=PY5plBz48PxZAJSQICeLdO37Fdw6pNftziZWDWBRpykB6Z9OihcZmTcJN9V25VCjEm Z3GxzPpm9ztHgMdvYUyUebWIWwPnqu1skRmp51mwZKk4i9Tb7+soyfG8LiwnEaM1mw8D w4QVBnm3BkEmKIXDehm4aZfwo4Vn5vqxf93/65ecgEpiNcR5hHZdGpoMwIF9vHiC7s3J UdDsPrcSPGWaRE/VOkud8ELNq+KA79bhKmUk/PiTo9TIxxbSnX7Gceap6xPN+9jlOKmD mckmzaVfjZxQSvi9Z12e/mCBnclcPJuVvtyV/03JX2w7EZvJAnGZSBUG0ft6Qi/sUjSZ 1ogw== X-Gm-Message-State: ALoCoQnbq6yFplbyNZG3WGQCd+xQn1wmo3VLwMp/zdNWWBLFj5J8L1ugAHDM1uqgnJXUeno6bUSE X-Received: by 10.180.83.137 with SMTP id q9mr39439472wiy.68.1435703135633; Tue, 30 Jun 2015 15:25:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.95.211 with HTTP; Tue, 30 Jun 2015 15:24:56 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Tue, 30 Jun 2015 15:24:56 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=f46d044401966715780519c3affe Archived-At: Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 30 Jun 2015 22:25:48 -0000 --f46d044401966715780519c3affe Content-Type: text/plain; charset=UTF-8 I see I forgot to provide a link. Here: https://github.com/ekr/tls13-spec/tree/WIP_draft_07 On Tue, Jun 30, 2015 at 3:23 PM, Eric Rescorla wrote: > Folks, > > Yesterday, I posted the -06 draft which snapshots the consensus changes > made since -05, specifically: > > - Prohibit RC4 negotiation for backwards compatibility. > - Freeze & deprecate record layer version field. > - Update format of signatures with context. > - Remove explicit IV. > > > In the background, I've also been working with Hugo, Hoeteck, Karthik, > and others to develop a new draft using semi-ephemeral DH based on > Hugo's ideas as discussed in Dallas. I'm planning to merge this into > master soon and submit it as draft-07 next week, but I wanted to > e-mail the list and give people a chance to comment before I do > that. I've provided a summary of the major changes and open issues > below. Remember, this is a WIP so if you see something wrong, don't > panic, but do let me know. > > > CHANGES > 1. Move ClientKeyShare into an extension so that the ClientHello > is the only message in the client's first flight. This removes > a bunch of ugliness around the "early_data" extension which > could encapsulate handshake and application data. > > 2. Added a mechanism for the server to indicate a known (EC)DHE > key/configuration which the client can then use in subsequent > handshakes (via the known_configuration extension). The net > effect here is that the client and server can skip over the > signature in subsequent handshakes, which provides benefit > when signatures are much slower than key exchange, as with > RSA; it also enables 0-RTT. > > 3. Added support for 0-RTT data, both with and without > client authentication. > > 4. Removed most of the support for resumption in favor of > a mechanism proposed by Karthik where you just establish > a PSK in connection N which you then use to key a PSK > cipher suite in connection N+1. > > All of these keying mechanisms use a unified key schedule based on two > keys the "Ephemeral Secret" (ES) and the "Static Secret" > (SS). Depending on the exact handshake type, these may be equal, but > the logic is the same regardless. In the process, I also converted > the key schedule to use HKDF (per WG consensus). > > > OPEN ISSUES > There are still a number of known open issues to discuss: > > 1. The present known_configuration mechanism allows the client to > resurrect the handshake parameters (though not the keys) which were > negotiated in a previous handshake, but this is done implicitly, > i.e., the server provides a label and the client returns it on > the next connection. This has the advantage of keeping things short > but the disadvantage the it means that you can't have a static > configuration ID for everyone (instead, the server has to somehow > embed the properties in the configuration ID). There are (at least) > three potential alternative designs: > > (a) Have the client indicate in his first flight "these are the > parameters I expect you to negotiate", along with the > configuration identifier, based on what the server > negotiated the previous time. [Optionally, the server > can run the same negotiation locally and abort on mismatch.] > > (b) As in (a) but with no indication of the expected parameters, > just the configuration ID, and the client just preemptively > uses the parameters from the last time and if the negotiation > ends up differently, all the data is undecryptable > (ugh) and you somehow fall back. > > (c) Have the server provide a preference list in his > ServerConfiguration (this can be the same as in the > ClientHello) and have the client do the negotiation based on > that rather than the server (as in QUIC). This is a little odd > in that it means that sometimes the server selects the > parameters and sometimes the client does, but it's not that > hard to make this code symmetrical. > > As I think this through, I am leaning towards (a) but other people's > opinions on this topic would be welcome. > > > 2. Should we require that PSK cipher suites where the PSK is used for > resumption use compatible ciphers? This is the way it was in TLS 1.2 > and below for resumption and tickets, but once you have a PSK, that's > not really necessary [0]. So, for instance, if you had the following > cipher list order: > > ECDHE + AES-GCM > ECDHE + ChaCha/Poly > PSK + ChaCha/Poly > PSK + AES-GCM > > You could potentially negotiate one connection with GCM, use it > to establish a shared key, and then reconnect with ChaCha/Poly. > This seems like it probably should be something we avoid, though > I'm not sure we have a concrete reason why, and it means a > weird special case for PSK. Note that this issue might be > ameliorated some (though not completely) with a la carte negotiation. > > > 3. I don't currently have PSK/Resumption + 0-RTT working, because you > need a way to indicate the expected parameters (see point #1 above). > > > 4. I plan to rewrite the Handshake Protocol Overview (S 6.2) > to be clearer. I hope to do this before submitting -07. > > 5. Security Considerations is badly out of date, so I plan to > rewrite that soon, but probably not before Prague. I also intend > to do a pretty substantial editorial cleanup pass and potentially > some restructuring after Prague. > > > As indicated above, this is still a WIP, so no doubt contains > a number of errors, potentially serious ones. Comments and PRs > welcome. > > Thanks, > -Ekr > > > [0] With the exception of cryptographic concerns about the use > of the same IKM with different hash functions for HKDF, but this > is a problem that applies to any use of PSK, not just this one. > > --f46d044401966715780519c3affe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I see I forgot to provide a link. Here:

https://gi= thub.com/ekr/tls13-spec/tree/WIP_draft_07

On Tue, Jun 30, 2015 at 3:23 PM= , Eric Rescorla <ekr@rtfm.com> wrote:
Folks,

Yesterday, I p= osted the -06 draft which snapshots the consensus changes
made si= nce -05, specifically:

- Prohibit RC4 negotiation = for backwards compatibility.
- Freeze & deprecate record laye= r version field.
- Update format of signatures with context.
- Remove explicit IV.


In the = background, I've also been working with Hugo, Hoeteck, Karthik,
and others to develop a new draft using semi-ephemeral DH based on
=
Hugo's ideas as discussed in Dallas. I'm planning to merge thi= s into
master soon and submit it as draft-07 next week, but I wan= ted to
e-mail the list and give people a chance to comment before= I do
that. I've provided a summary of the major changes and = open issues
below. Remember, this is a WIP so if you see somethin= g wrong, don't
panic, but do let me know.


CHANGES
1. Move ClientKeyShare into an exten= sion so that the ClientHello
=C2=A0 =C2=A0is the only message in = the client's first flight. This removes
=C2=A0 =C2=A0a bunch = of ugliness around the "early_data" extension which
=C2= =A0 =C2=A0could encapsulate handshake and application data.

<= /div>
2. Added a mechanism for the server to indicate a known (EC)DHE
=C2=A0 =C2=A0key/configuration which the client can then use in su= bsequent
=C2=A0 =C2=A0handshakes (via the known_configuration ext= ension). The net
=C2=A0 =C2=A0effect here is that the client and = server can skip over the
=C2=A0 =C2=A0signature in subsequent han= dshakes, which provides benefit
=C2=A0 =C2=A0when signatures are = much slower than key exchange, as with
=C2=A0 =C2=A0RSA; it also = enables 0-RTT.

3. Added support for 0-RTT data, bo= th with and without
=C2=A0 =C2=A0client authentication.

4. Removed most of the support for resumption in favor of
=C2=A0 =C2=A0a mechanism proposed by Karthik where you just establ= ish
=C2=A0 =C2=A0a PSK in connection N which you then use to key = a PSK
=C2=A0 =C2=A0cipher suite in connection N+1.

=
All of these keying mechanisms use a unified key schedule based = on two
keys the "Ephemeral Secret" (ES) and the "S= tatic Secret"
(SS). Depending on the exact handshake type, t= hese may be equal, but
the logic is the same regardless. In the p= rocess, I also converted
the key schedule to use HKDF (per WG con= sensus).


OPEN ISSUES
Ther= e are still a number of known open issues to discuss:

<= div>1. The present known_configuration mechanism allows the client to
=
resurrect the handshake parameters (though not the keys) which were
negotiated in a previous handshake, but this is done implicitly,
i.e., the server provides a label and the client returns it on
the next connection. This has the advantage of keeping things short
but the disadvantage the it means that you can't have a static=
configuration ID for everyone (instead, the server has to someho= w
embed the properties in the configuration ID). There are (at le= ast)
three potential alternative designs:

=C2=A0 =C2=A0(a) Have the client indicate in his first flight "these= are the
=C2=A0 =C2=A0 =C2=A0 =C2=A0parameters I expect you to ne= gotiate", along with the
=C2=A0 =C2=A0 =C2=A0 =C2=A0configur= ation identifier, based on what the server
=C2=A0 =C2=A0 =C2=A0 = =C2=A0negotiated the previous time. [Optionally, the server
=C2= =A0 =C2=A0 =C2=A0 =C2=A0can run the same negotiation locally and abort on m= ismatch.]

=C2=A0 =C2=A0(b) As in (a) but with no i= ndication of the expected parameters,
=C2=A0 =C2=A0 =C2=A0 =C2=A0= just the configuration ID, and the client just preemptively
=C2= =A0 =C2=A0 =C2=A0 =C2=A0uses the parameters from the last time and if the n= egotiation
=C2=A0 =C2=A0 =C2=A0 =C2=A0ends up differently, all th= e data is undecryptable
=C2=A0 =C2=A0 =C2=A0 =C2=A0(ugh) and you = somehow fall back.

=C2=A0 =C2=A0(c) Have the serve= r provide a preference list in his
=C2=A0 =C2=A0 =C2=A0 =C2=A0Ser= verConfiguration (this can be the same as in the
=C2=A0 =C2=A0 = =C2=A0 =C2=A0ClientHello) and have the client do the negotiation based on
=C2=A0 =C2=A0 =C2=A0 =C2=A0that rather than the server (as in QUIC= ). This is a little odd
=C2=A0 =C2=A0 =C2=A0 =C2=A0in that it mea= ns that sometimes the server selects the
=C2=A0 =C2=A0 =C2=A0 =C2= =A0parameters and sometimes the client does, but it's not that
=C2=A0 =C2=A0 =C2=A0 =C2=A0hard to make this code symmetrical.
=
As I think this through, I am leaning towards (a) but other = people's
opinions on this topic would be welcome.
<= br>

2. Should we require that PSK cipher suites wh= ere the PSK is used for
resumption use compatible ciphers? This i= s the way it was in TLS 1.2
and below for resumption and tickets,= but once you have a PSK, that's
not really necessary [0]. So= , for instance, if you had the following
cipher list order:
=

=C2=A0 =C2=A0 ECDHE + AES-GCM
=C2=A0 =C2=A0 E= CDHE + ChaCha/Poly
=C2=A0 =C2=A0 PSK + ChaCha/Poly
=C2= =A0 =C2=A0 PSK + AES-GCM

You could potentially neg= otiate one connection with GCM, use it
to establish a shared key,= and then reconnect with ChaCha/Poly.
This seems like it probably= should be something we avoid, though
I'm not sure we have a = concrete reason why, and it means a
weird special case for PSK. N= ote that this issue might be
ameliorated some (though not complet= ely) with a la carte negotiation.


3= . I don't currently have PSK/Resumption + 0-RTT working, because you
need a way to indicate the expected parameters (see point #1 above)= .


4. I plan to rewrite the Handshak= e Protocol Overview (S 6.2)
to be clearer. I hope to do this befo= re submitting -07.

5. Security Considerations is b= adly out of date, so I plan to
rewrite that soon, but probably no= t before Prague. I also intend
to do a pretty substantial editori= al cleanup pass and potentially
some restructuring after Prague.<= /div>


As indicated above, this is still a= WIP, so no doubt contains
a number of errors, potentially seriou= s ones. Comments and PRs
welcome.

Thanks= ,
-Ekr


[0] With the excep= tion of cryptographic concerns about the use
of the same IKM with= different hash functions for HKDF, but this
is a problem that ap= plies to any use of PSK, not just this one.


--f46d044401966715780519c3affe-- From nobody Tue Jun 30 16:00: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 D32F91AD0B4 for ; Tue, 30 Jun 2015 16:00:50 -0700 (PDT) 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 EgRGYu31cyne for ; Tue, 30 Jun 2015 16:00:46 -0700 (PDT) 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 E338C1ACDE1 for ; Tue, 30 Jun 2015 16:00:45 -0700 (PDT) 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 EDD3D2A7CA; Wed, 1 Jul 2015 01:00:42 +0200 (CEST) X-purgate-ID: 152705::1435705242-00000B48-24FCA13E/0/0 X-purgate-size: 3185 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id C1DA742FEB; Wed, 1 Jul 2015 01:00:42 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id B82C71A1AD; Wed, 1 Jul 2015 01:00:42 +0200 (CEST) In-Reply-To: To: Andrei Popov Date: Wed, 1 Jul 2015 01:00:42 +0200 (CEST) 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: <20150630230042.B82C71A1AD@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] RFC7301 ALPN conflicting objectives about app-specific server certificates 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, 30 Jun 2015 23:00:51 -0000 Andrei Popov wrote: >> >> If the server uses distict server certificates per application protocol >> and properly(!!) performs a full handshake if the server certificate >> does not fit the requested application protocol, then alternating >> requests with two different protocols to the same server will result >> in constant full TLS handshakes. > > Yes, if a client negotiates a different application protocol on a > subsequent connection, the server may reject resumption (which the > server can always do anyway, regardless of ALPN). Correct, the server may decide for a full handshake for a number of reasons. But in general, I want TLS session caching to work and expect to see a session resumption vs. full handshake rate of >> 10:1 on healthy servers. > >> But what can also easily happen, is that the server is inappropriately >> sharing the server-side session cache an incorrectly resuming sessions >> associated with the wrong server certificate (a different certificate >> than what the server would select if it would perform a full TLS >> handshake), ... > > This would be a server bug indeed. No, not right now. It would be a server implementing a defective specification as written, due to the last paragraph in section 3.1 of rfc7301. > >> Essentially, I believe that tagging of the session with the ALPN >> negotiated protocol to result in more "predictable" behaviour, >> because it will not interfere with client-side session cache >> management and not result in occasional confusion should other >> server implementors ever make their servers use different server >> certificates for different ALPN-negotiated protocols. > > Can you describe how such tagging would work in more detail? For the client, I will memorize the app-requested ALPN list in the client-side session cache and attempt resumption only when the application supplies the same ALPN list. For the server, two possible approaches are conceivable. (1) an extension specific approach, where the server includes the chosen app protocol in the server-side session cache and checks for a match on attempted resumption. (2) a generally robust approach that solves this and all related issues once and for all (but may not integrate easily with certain protocol stack implementations...) The server processes ClientHello always in the same fashion as it would do for a full TLS handshake, and only if it done with deciding all negotiation, it checks for a proposal to resume an old session. If there is a resumption proposal, the server compares the attributes of the newly negotiated parameters with that of the resumed session, and if the properties differ (in particular, if the new handshake would use a different server certificate than the cached session had used), the server will perform a full handshake instead of a session resume and the resulting server behaviour will bear the lowest risk of surprises (i.e. the session caching only results in speedup, but not in sessions with different properties or different identites). -Martin From nobody Tue Jun 30 16:53: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 15EC31B2A82 for ; Tue, 30 Jun 2015 16:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 4GmYQReZ1RZB for ; Tue, 30 Jun 2015 16:53:42 -0700 (PDT) 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 C8CC31B2BA7 for ; Tue, 30 Jun 2015 16:53:41 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 9AAED284D2C; Tue, 30 Jun 2015 23:53:40 +0000 (UTC) Date: Tue, 30 Jun 2015 23:53:40 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150630235340.GI14121@mournblade.imrryr.org> References: <20150630202613.D07251A1AD@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150630202613.D07251A1AD@ld9781.wdf.sap.corp> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] RFC7301 ALPN conflicting objectives about app-specific server certificates 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: Tue, 30 Jun 2015 23:53:44 -0000 On Tue, Jun 30, 2015 at 10:26:13PM +0200, Martin Rex wrote: > I'm currently implementing support for ALPN in our middlware, > and I'm wondering how to account for ALPN in the client side session caching > management, because rfc7301 describes two mutually exclusive objectives > and the ALPN protocol does not provide a means for the server to > disambiguate the desired semantics in the ServerHello response. > > rfc7301, > https://tools.ietf.org/html/rfc7301#section-1 > > Section 1. last sentence of paragraph 2 (end of page 2): > > Further, it would be > advantageous to allow certificate selection based on the negotiated > application protocol. > > Section 1, last sentence of paragraph 4 (last paragraph): > > The application protocol negotiation can thus > be accomplished within the TLS handshake, without adding network > round-trips, and allows the server to associate a different > certificate with each application protocol, if desired. > > is in conflict with > > Section 3.1, last paragraph > https://tools.ietf.org/html/rfc7301#page-5 > > Unlike many other TLS extensions, this extension does not establish > properties of the session, only of the connection. When session > resumption or session tickets [RFC5077] are used, the previous > contents of this extension are irrelevant, and only the values in the > new handshake messages are considered. I don't think there's a conflict here. All that's said is that ALPN is not a session property, and its value for a previous connection is not directly relevant for a new connection. Each connection signals its own ALPN value. Now to the extent that a new connection elects a different protocol and thus a different server certificate chain, or the server's configuration has changed and the same ALPN protocol is now associated with a new certificate chain, the server needs to perform a full handshake, so that the client sees the correct certificate chain. > Currently, my client-side session cache management, and the decision whether > to propose a TLS session to the server for resumption, is based on a match > of the application supplied "target name" which is usually an fqdn hostname, > but could also be an abbreviated hostname or an IP address. Postfix has had solved a similar issue some time ago, because multiple SMTP destination domains can use the same MX host, but the sending MTA administrator TLS policy may differ between domains and these domains might use distinct "transports" (instances of SMTP delivery channels, roughly analogous to a Sendmail "mailer"), where each transport has different trust-anchors or other relevant TLS settings. Therefore, the client cache is indexed by multiple properties that extract the enough detail from the security policy to make sure we are reaching the right server at the right security level. The relevant attributes are: * Postfix "transport name". Different transports have potentially very different base TLS settings, and it is simplest to not mix session caches accross "transports" * Nexthop domain (with port), MX hostname and target IP address. Some MX hosts that appear to be a single multi-homed host are in fact multiple hosts with separate caches, so each IP address gets a different parallel cache. * The EHLO name of the remote SMTP server, this detects split caches (multiple SMTP servers) behind a load balancer. C: EHLO client-name S: 250- ... 250 STARTTLS Google's pool of MX hosts at any given IP address, has a shared session cache, and a common EHLO name, so session caching works well across the load balancer. Some providers have shared caches, but fail to return a common HELO name, and the client cache is then not nearly as effective. * ... > Essentially, I believe that tagging of the session with the ALPN > negotiated protocol to result in more "predictable" behaviour, because > it will not interfere with client-side session cache management > and not result in occasional confusion should other server implementors > ever make their servers use different server certificates for > different ALPN-negotiated protocols. So, yes include all TLS security-relevant attributes in some manner in the client cache lookup key to avoid mixing cached sessions with incompatible security requirements. -- Viktor. From nobody Tue Jun 30 18:31: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 53CBD1A026E for ; Tue, 30 Jun 2015 18:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4YiFEewNyur0 for ; Tue, 30 Jun 2015 18:31:22 -0700 (PDT) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::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 AF8841A0171 for ; Tue, 30 Jun 2015 18:31:22 -0700 (PDT) Received: by ykdv136 with SMTP id v136so26046839ykd.0 for ; Tue, 30 Jun 2015 18:31:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:message-id; bh=qQVY29K3PuS4FhxC+uX/9aS2PXZXpmIyt54NdK5ZPF0=; b=dbQsVn8xz1/1EzFYXH4bUXtDg3mb3ONFH7P9gLgOg2NxNeMi5a2ODjs1t5jhPcRbFp waY5ihUqHyiEmJpgDo8yXW+z2/Wsin4G0vRjtO8WvZq7hdmCOZTnDG7k1F+9HLw2mFmJ LrbwxJUV2zmPi0m9F5VmmuctSDAfwqusX3wq1oLOsQgrqo3J8ZVICWYS5YUOUALHEpGH 19mKV3s3p34CaBxN3x9kJimTnHoW/fCOxo+oHa2LU6n4Zq850aeGrTyzZ3BB1JOaPAtE 991FqD87aUr2UFacRYX4WRrmmBrsyREnwx7QuC2eemM+M1fRW6wbzUCKtZWQyoIFvddy yuWQ== X-Received: by 10.170.110.82 with SMTP id c79mr28990014ykb.113.1435714282413; Tue, 30 Jun 2015 18:31:22 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id q190sm365247ywf.52.2015.06.30.18.31.21 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 30 Jun 2015 18:31:21 -0700 (PDT) From: Dave Garrett To: tls@ietf.org, Eric Rescorla Date: Tue, 30 Jun 2015 21:31:19 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201506302131.20214.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Jul 2015 01:31:24 -0000 On Tuesday, June 30, 2015 06:23:18 pm Eric Rescorla wrote: > 2. Should we require that PSK cipher suites where the PSK is used for > resumption use compatible ciphers? https://github.com/tlswg/tls13-spec/compare/master...ekr:WIP_draft_07#diff-9d84740dcc569a0a5a359d0fba461a05R3037 +After the server has received the client Finished message, it MAY send +a NewSessionTicket message. This message creates a pre-shared key +(PSK) binding between the resumption master secret and the ticket +label. The client MAY use this PSK for future handshakes by including +it in the pre_shared_key extension in its ClientHello +({{pre-shared-key-extension}}) and supplying a suitable PSK cipher +suite. + +%%% Ticket Establishment + struct { + uint32 ticket_lifetime_hint; + opaque ticket<0..2^16-1>; + } NewSessionTicket; The "suitable PSK cipher suite" & "resumption use compatible ciphers" issues would be simpler if the NewSessionTicket was just bound to a specified cipher suite (or vector of suites, but that's probably not needed). We could just add a cipher suite field here so the server tells the client exactly what it expects. Dave From nobody Tue Jun 30 19:43: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 9ED761A88C3 for ; Tue, 30 Jun 2015 19:43:46 -0700 (PDT) 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 P4d8gmTVYdHu for ; Tue, 30 Jun 2015 19:43:45 -0700 (PDT) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.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 E7D501A88AF for ; Tue, 30 Jun 2015 19:43:44 -0700 (PDT) Received: by wgck11 with SMTP id k11so24701299wgc.0 for ; Tue, 30 Jun 2015 19:43:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=CPIFA+ZcALZMCZJyds0OOMweTOD9l/bHUAM/ftETtKc=; b=SW3qIkBU5nASbgWqiptnqZ7w4qTqaIdYdCUbQn0+ubEKswcgrT5jR3nD0bNhriF/MF +8iTvkdPqW56G1yRFChbEZyBKmx/F8fFNMbsxH9/uYB6IkxCIVdD82reeW+maakZRpZJ nN97MfMqPmB6JvAYfpiXHGrje6h7NOgMEFdXFYTUQYGOAl7j/j2lOnPo+V2Fub6rj2Hg hbEYkloqtVc0PgNfmkfGR9KQbgQGTS6lVGKxB2caMaUXYv0OJ4YBrBigro5KWlWrGP6U fEjeBBsTvtt8/xPSWrZJMH7E7Dle92a1FjktkHKV9jDShzXqsLwHxUmTaDyxA/BXv/2t 5opA== X-Gm-Message-State: ALoCoQlFpeICWm5lYDmJuopwX3N20RPvXahx2X2RS0N/oTTOD71JzgzdGWIlrfuH4qrN9yi1HxE8 X-Received: by 10.180.189.201 with SMTP id gk9mr1579954wic.53.1435718624042; Tue, 30 Jun 2015 19:43:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.95.211 with HTTP; Tue, 30 Jun 2015 19:43:04 -0700 (PDT) In-Reply-To: <201506302131.20214.davemgarrett@gmail.com> References: <201506302131.20214.davemgarrett@gmail.com> From: Eric Rescorla Date: Tue, 30 Jun 2015 19:43:04 -0700 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=001a11c352a09577f40519c74a92 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Jul 2015 02:43:46 -0000 --001a11c352a09577f40519c74a92 Content-Type: text/plain; charset=UTF-8 On Tue, Jun 30, 2015 at 6:31 PM, Dave Garrett wrote: > On Tuesday, June 30, 2015 06:23:18 pm Eric Rescorla wrote: > > 2. Should we require that PSK cipher suites where the PSK is used for > > resumption use compatible ciphers? > > > https://github.com/tlswg/tls13-spec/compare/master...ekr:WIP_draft_07#diff-9d84740dcc569a0a5a359d0fba461a05R3037 > +After the server has received the client Finished message, it MAY send > +a NewSessionTicket message. This message creates a pre-shared key > +(PSK) binding between the resumption master secret and the ticket > +label. The client MAY use this PSK for future handshakes by including > +it in the pre_shared_key extension in its ClientHello > +({{pre-shared-key-extension}}) and supplying a suitable PSK cipher > +suite. > + > +%%% Ticket Establishment > + struct { > + uint32 ticket_lifetime_hint; > + opaque ticket<0..2^16-1>; > + } NewSessionTicket; > > The "suitable PSK cipher suite" & "resumption use compatible ciphers" > issues would be simpler if the NewSessionTicket was just bound to a > specified cipher suite (or vector of suites, but that's probably not > needed). We could just add a cipher suite field here so the server tells > the client exactly what it expects. Yes, that's one possibility. -Ekr > > Dave > --001a11c352a09577f40519c74a92 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jun 30, 2015 at 6:31 PM, Dave Garrett <davemgarrett@gmail= .com> wrote:
On Tuesday, June 30, 2015 06:23:18 pm Eric Rescorla wrote:
> 2. Should we require that PSK cipher suites where the PSK is used for<= br> > resumption use compatible ciphers?

https://github.com/tlswg/tls13-spec/compare/master...ekr= :WIP_draft_07#diff-9d84740dcc569a0a5a359d0fba461a05R3037
+After the server has received the client Finished message, it MAY send
+a NewSessionTicket message. This message creates a pre-shared key
+(PSK) binding between the resumption master secret and the ticket
+label. The client MAY use this PSK for future handshakes by including
+it in the pre_shared_key extension in its ClientHello
+({{pre-shared-key-extension}}) and supplying a suitable PSK cipher
+suite.
+
+%%% Ticket Establishment
+=C2=A0 =C2=A0 =C2=A0 struct {
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 uint32 ticket_lifetime_hint;
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 opaque ticket<0..2^16-1>;
+=C2=A0 =C2=A0 =C2=A0 } NewSessionTicket;

The "suitable PSK cipher suite" & "resumption use compat= ible ciphers" issues would be simpler if the NewSessionTicket was just= bound to a specified cipher suite (or vector of suites, but that's pro= bably not needed). We could just add a cipher suite field here so the serve= r tells the client exactly what it expects.

Yes, that's one possibility.

-Ekr
<= br>


Dave

--001a11c352a09577f40519c74a92-- From nobody Tue Jun 30 20:27: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 554681A1A70; Tue, 30 Jun 2015 20:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebWgKlwoW6OL; Tue, 30 Jun 2015 20:27:15 -0700 (PDT) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::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 9C9A01A1A66; Tue, 30 Jun 2015 20:27:15 -0700 (PDT) Received: by qgem68 with SMTP id m68so13350955qge.0; Tue, 30 Jun 2015 20:27:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=uLwayf64nkEoAjlF+A58u/8TULlEAwQr3Lmq5+nDzGs=; b=oyjod6zZwnwu3Dz9GD5/5qeUKTxRqML+cDzX8vJRPV5mKqwq3n4UbK8pQegrRPemTx OW/oQoqDrzgmzX8UqwgQlXDangFW/qtz2xf+lihCe6O4F+22EWssfUl6v9mYxm2CWj7P DU0mC9qM2xRm3ZGWO35VuzY2oTgxOj4WkC3uxVqBI72W9pdvrdgcYozRFJStLm8uclRW N0O1yOHpGjTY2jUb9/0xGHyQMQhiWq4iE3duopkvFbbv/jbXKEaDKsu63+FHnAEfSYJf o1tB9/GtvSzHJ+hVUxrEQ2f2S7msEEicOAx2BW6IKualEAl1b+XcZ9hlRVemRRf0SC29 tZHA== MIME-Version: 1.0 X-Received: by 10.55.23.17 with SMTP id i17mr50071868qkh.39.1435721235260; Tue, 30 Jun 2015 20:27:15 -0700 (PDT) Received: by 10.140.80.208 with HTTP; Tue, 30 Jun 2015 20:27:15 -0700 (PDT) In-Reply-To: <20150630062518.GC14121@mournblade.imrryr.org> References: <55922571.8080605@nomountain.net> <20150630062518.GC14121@mournblade.imrryr.org> Date: Tue, 30 Jun 2015 23:27:15 -0400 Message-ID: From: Shumon Huque To: tls@ietf.org Content-Type: multipart/alternative; boundary=001a1146fabe3986e30519c7e6ac Archived-At: Cc: "" Subject: Re: [TLS] [dane] draft-shore-tls-dnssec-chain-extension-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: shuque@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: Wed, 01 Jul 2015 03:27:18 -0000 --001a1146fabe3986e30519c7e6ac Content-Type: text/plain; charset=UTF-8 On Tue, Jun 30, 2015 at 2:25 AM, Viktor Dukhovni wrote: Thanks Victor. I'll add a few to Melinda's earlier comments .. On Mon, Jun 29, 2015 at 09:13:21PM -0800, Melinda Shore wrote: > > > Please have a look at it and get comments or suggestions > > to us. We're planning on getting one more revision out > > prior to the Prague meeting, and on having a test > > implementation available in Prague. > > The draft is available at: > > https://tools.ietf.org/html/draft-shore-tls-dnssec-chain-extension-00 > > > 3. I'm not sure what purpose the last paragraph of section 3 is > intended to serve: > > Obviously, an authentication chain will be most compact and easiest > to verify if each RRset has a single record, i.e., if there is a > single DNSKEY RR and a single DS RR at each step. In addition, as > suggested above, keeping zone cuts to a minimum also reduces the > length of the authentication chain. > > The TLS server has no choice but to return the complete RRset for > each owner name class and RRtype, since RRSIGs cover RRsets, not > individual RRs. So "compacting" is possible. The server returns > the RRsets exactly as published by the relevant DNS(SEC) servers. > Yeah, section 3 needs a bit of work. Also, the order of record (sets) in the given example doesn't match the dnssec_chain structure definition - that should be fixed in the next rev. The structure will likely undergo some additional changes too, e.g. names that involve CNAME/DNAMEs might need an authentication tree rather than a single authentication chain, or a sequence of authentication chains. > Speaking of RRsets, are the RRs in each RRset returned by the server > required to be sorted in canonical order? > It would be nice to do so, but not essential - as long as the validator sorts them canonically before signature verification. > 4. I think the Section 4 SNI interaction would be a lot cleaner, > if SNI is mandatory for clients that use the proposed extension. > In which case the server can only respond with a leaf TLSA RRset > (and chain of RRSIG/DNSKEY/DS/... records) whose "base domain" ( > see section 3 of RFC6698 and soon definition of TLSA base domain > in draft-ietf-dane-ops-13 (later this week)). Using some random > name for the server's IP address is not a good idea IMHO. PTR > records are too often poorly correlated with the client's notion > of the target server name. > I agree with this. > 5. In Section 5, the server MUST not violate DNS TTLs. The last > senetence: > > Alternatively, it could be configured to rebuild the chain at some > predefined periodic intervals. > > is I fear too much rope. Sure the server can periodically flush > its cache (using shorter than possible TTLs), but this does not > free it of the obligation to not extend TTLs by relying exclusively > on a cache lifetime of its own choosing. > I agree that is a bit of rope. The first part of the section does tell the validator to do the right thing. The alternative (which would be simpler to implement) was provided for cases where the server operator might know the TTLs and signature validity periods of the chain above it (assuming they are stable), and be able to select a suitable regeneration interval below them. But yes, it provides more opportunity for doing the wrong thing by selecting the wrong interval. Note that the original draft suggested something similar (regenerating the stapled chain into an X.509 cert at some predefined interval). > 11. Finally, Shumon Huque (mostly) and I (helping out) are writing > a draft to specify DANE TLSA for client authentication. If and > when that progresses (WG adoption, ...), there may need to be a > similar extension, allowing a client to forward its DNSSEC-validated > TLSA RRset. This is not an immediate priority and can be re-evaluated > later. > I posted a link to the draft separately on the dane list. But for TLS folks: https://tools.ietf.org/html/draft-huque-dane-client-cert-00 -- Shumon Huque --001a1146fabe3986e30519c7e6ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jun 30, 2015 at 2:25 AM, Viktor Dukhovni <ietf-dane@dukhovni.org= > wrote:

Thanks Victor. I'll add a few to Melinda's earlier= comments ..

On Mon, Jun 29, 2015 at 09:13:21PM -0800, Melinda Shore wrote:

> Please have a look at it and get comments or suggestions
> to us.=C2=A0 We're planning on getting one more revision out
> prior to the Prague meeting, and on having a test
> implementation available in Prague.
> The draft is available at:
> https://tools.ietf.org/htm= l/draft-shore-tls-dnssec-chain-extension-00

=C2=A0
3.=C2=A0 I'm not sure what purpose the last paragraph of section 3 is intended to serve:

=C2=A0 =C2=A0Obviously, an authentication chain will be most compact and ea= siest
=C2=A0 =C2=A0to verify if each RRset has a single record, i.e., if there is= a
=C2=A0 =C2=A0single DNSKEY RR and a single DS RR at each step.=C2=A0 In add= ition, as
=C2=A0 =C2=A0suggested above, keeping zone cuts to a minimum also reduces t= he
=C2=A0 =C2=A0length of the authentication chain.

The TLS server has no choice but to return the complete RRset for
each owner name class and RRtype, since RRSIGs cover RRsets, not
individual RRs.=C2=A0 So "compacting" is possible.=C2=A0 The serv= er returns
the RRsets exactly as published by the relevant DNS(SEC) servers.

Yeah, section 3 needs a bit of work. Also, the o= rder of record (sets) in the given example doesn't match the dnssec_cha= in structure definition - that should be fixed in the next rev. The structu= re will likely undergo some additional changes too, e.g. names that involve= CNAME/DNAMEs might need an authentication tree rather than a single authen= tication chain, or a sequence of authentication chains.


Speaking of RRsets, are the RRs in each RRset returned by the server
required to be sorted in canonical order?

It would be nice to do so, but not essential - as long as the validator = sorts them canonically before signature verification.
=C2=A0
4.=C2=A0 I think the Section 4 SNI interaction would be a lot cleaner,
if SNI is mandatory for clients that use the proposed extension.
In which case the server can only respond with a leaf TLSA RRset
(and chain of RRSIG/DNSKEY/DS/... records) whose "base domain" (<= br> see section 3 of RFC6698 and soon definition of TLSA base domain
in draft-ietf-dane-ops-13 (later this week)).=C2=A0 Using some random
name for the server's IP address is not a good idea IMHO.=C2=A0 PTR
records are too often poorly correlated with the client's notion
of the target server name.

I agree with= this.
=C2=A0
5.=C2=A0 In Section 5, the server MUST not violate DNS TTLs.=C2=A0 The last=
senetence:

=C2=A0 =C2=A0 Alternatively, it could be configured to rebuild the chain at= some
=C2=A0 =C2=A0 predefined periodic intervals.

is I fear too much rope.=C2=A0 Sure the server can periodically flush
its cache (using shorter than possible TTLs), but this does not
free it of the obligation to not extend TTLs by relying exclusively
on a cache lifetime of its own choosing.

I agree that is a bit of rope. The first part of the section does tell th= e validator to do the right thing. The alternative (which would be simpler = to implement) was provided for cases where the server operator might know t= he TTLs and signature validity periods of the chain above it (assuming they= are stable), and be able to select a suitable regeneration interval below = them. But yes, it provides more opportunity for doing the wrong thing by se= lecting the wrong interval. Note that the original draft suggested somethin= g similar (regenerating the stapled chain into an X.509 cert at some predef= ined interval).
=C2=A0
11.=C2=A0 Finally, Shumon Huque (mostly) and I (helping out) are writing a draft to specify DANE TLSA for client authentication.=C2=A0 If and
when that progresses (WG adoption, ...), there may need to be a
similar extension, allowing a client to forward its DNSSEC-validated
TLSA RRset.=C2=A0 This is not an immediate priority and can be re-evaluated=
later.

I posted a link to the draft sep= arately on the dane list. But for TLS folks:


--=C2=A0
Shumon Huque

--001a1146fabe3986e30519c7e6ac-- From nobody Tue Jun 30 20:27: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 1579C1A1A80 for ; Tue, 30 Jun 2015 20:27:47 -0700 (PDT) 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, 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 oLNyitg6xi2J for ; Tue, 30 Jun 2015 20:27:46 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3F4F1A1A78 for ; Tue, 30 Jun 2015 20:27:45 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mLp0H0HKpz9G; Wed, 1 Jul 2015 05:27:43 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=I1RU9fa5 X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id dUVm3EJa4uON; Wed, 1 Jul 2015 05:27:42 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 1 Jul 2015 05:27:41 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 31AE4800B3; Tue, 30 Jun 2015 23:27:41 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1435721261; bh=gRjAKeNLdDeeqpZX09x5XtERIGolgfvJ8g+c2CtO1cA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=I1RU9fa5er4AYm7K55hbHhw4XDne9cKxbDki1LXrz51JRvF7nlqQ9AJy6DRc/Z5QF xJy8q9CNARZE5shgR3H+uRrhhTMrKv0d/xFGsnyfUL+wqqOTU7Gk1QmtVFkYhfwv95 2Zu6z93sfDKooX8taQarO1Nfi+ohSALD4exgKw/0= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t613ReoC029661; Tue, 30 Jun 2015 23:27:40 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 30 Jun 2015 23:27:40 -0400 (EDT) From: Paul Wouters To: Melinda Shore In-Reply-To: <55922571.8080605@nomountain.net> Message-ID: References: <55922571.8080605@nomountain.net> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] draft-shore-tls-dnssec-chain-extension-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, 01 Jul 2015 03:27:47 -0000 On Mon, 29 Jun 2015, Melinda Shore wrote: > Subject: [TLS] draft-shore-tls-dnssec-chain-extension-00 > We've submitted a initial draft describing a TLS extension for > the transport of a DNS record serialized with the DNSSEC > signatures needed to authenticate that record. So this looks similar to the earlier "put it in an X509 attribute" experiment that chrome did for a while. If it makes browser people happier to use DNSSEC, I'm all for it. Although I would be happier if we just shipped a binary DNS packet blob (minus transport header) that could be given to a dnssec validation library as if it came from a remote DNS nameserver. I don't really see the use of a new DNS transport format, as the DNS packet format can already be used to add a large number of records. Additionally, code on nameservers for draft-ietf-dnsop-edns-chain-query could directly be used to generate the TLS extension data blob as well for the TLS server. Having browsers have some kind of "validate this chain of DNS records that is asumed to be in some validation order" seems awfully specific code that is "just not DNS enough" to cause problems. I'd rather see the data fed into existing real dns validation libraries. Paul From nobody Tue Jun 30 20:33: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 23B3D1A1C00 for ; Tue, 30 Jun 2015 20:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6QpxDtpA_OS for ; Tue, 30 Jun 2015 20:33:23 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (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 799D81A1C06 for ; Tue, 30 Jun 2015 20:33:23 -0700 (PDT) Received: by qkeo142 with SMTP id o142so21150389qke.1 for ; Tue, 30 Jun 2015 20:33:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=yNLMk5QOVf8g8UPxAaQqV+S8GVYkdnc5KQqH8m47HOU=; b=Epn3hDUaQjt7MUGKRawbpqI4Du7dqFRnhsO2Io9iFNIhfU+n1WMjPf853T3M2PmWhb 372orB8/qCSeZjsw6bbVL7uQIdgPz9gr2ngiFGkbfLN3XyUbdJSaVizUZ4uDN5xKU43e eGpgJXr6oDuxB1LuvM00Nhaua4tGbYdFXh3kpn1k7pM23M/wvXSWbzpjHXn0cA8/wBP6 LZ5EQCE2nTL2KJUHzxZeh0memrU5JKAbYtnkgZ+EmwduALf59b9RyPQ4plmPFUK7vwFy RWO84VgRec+Isgy3KLCeNFSA97Q8DtLpEUhZxq5luqu+1ftNH3icRLQuN21THvmeGsyp vkGg== MIME-Version: 1.0 X-Received: by 10.140.109.119 with SMTP id k110mr30338102qgf.53.1435721603121; Tue, 30 Jun 2015 20:33:23 -0700 (PDT) Received: by 10.140.80.208 with HTTP; Tue, 30 Jun 2015 20:33:23 -0700 (PDT) In-Reply-To: References: <55922571.8080605@nomountain.net> Date: Tue, 30 Jun 2015 23:33:23 -0400 Message-ID: From: Shumon Huque To: Paul Wouters Content-Type: multipart/alternative; boundary=001a1139bc5026893b0519c7fc0d Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] draft-shore-tls-dnssec-chain-extension-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: shuque@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: Wed, 01 Jul 2015 03:33:25 -0000 --001a1139bc5026893b0519c7fc0d Content-Type: text/plain; charset=UTF-8 On Tue, Jun 30, 2015 at 11:27 PM, Paul Wouters wrote: > On Mon, 29 Jun 2015, Melinda Shore wrote: > > Subject: [TLS] draft-shore-tls-dnssec-chain-extension-00 >> > > We've submitted a initial draft describing a TLS extension for >> the transport of a DNS record serialized with the DNSSEC >> signatures needed to authenticate that record. >> > > So this looks similar to the earlier "put it in an X509 attribute" > experiment that chrome did for a while. If it makes browser people > happier to use DNSSEC, I'm all for it. > Right. > > Although I would be happier if we just shipped a binary DNS packet > blob (minus transport header) that could be given to a dnssec > validation library as if it came from a remote DNS nameserver. I > don't really see the use of a new DNS transport format, as the DNS > packet format can already be used to add a large number of records. > > Additionally, code on nameservers for draft-ietf-dnsop-edns-chain-query > could directly be used to generate the TLS extension data blob as well > for the TLS server. > Yes, I suggested the possibility of using edns-chain-query also if/when nameservers support it. Are there any out there yet? > Having browsers have some kind of "validate this chain of DNS records > that is asumed to be in some validation order" seems awfully specific > code that is "just not DNS enough" to cause problems. I'd rather see > the data fed into existing real dns validation libraries. Me too. But I think there are some folks who want to implement the validation themselves in the application, so the draft is trying to cater to both camps. Shumon. --001a1139bc5026893b0519c7fc0d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jun 30, 2015 at 11:27 PM, Paul Wouters <paul@nohats.ca> wro= te:
On Mon, 29 Jun 2015, Melinda Shore wr= ote:

Subject: [TLS] draft-shore-tls-dnssec-chain-extension-00

We've submitted a initial draft describing a TLS extension for
the transport of a DNS record serialized with the DNSSEC
signatures needed to authenticate that record.

 So this looks similar to the earlier "put it in an X509 attribute"= ;
experiment that chrome did for a while. If it makes browser people
happier to use DNSSEC, I'm all for it.

<= div>Right.
=C2=A0

Although I would be happier if we just shipped a binary DNS packet
blob (minus transport header) that could be given to a dnssec
validation library as if it came from a remote DNS nameserver. I
don't really see the use of a new DNS transport format, as the DNS
packet format can already be used to add a large number of records.

Additionally, code on nameservers for draft-ietf-dnsop-edns-chain-query
could directly be used to generate the TLS extension data blob as well
for the TLS server.

Yes, I suggested th= e possibility of =C2=A0using edns-chain-query also if/when nameservers supp= ort it. Are there any out there yet?
=C2=A0
Having browsers have some kind of "validate this chain of DNS records<= br> that is asumed to be in some validation order" seems awfully specific<= br> code that is "just not DNS enough" to cause problems. I'd rat= her see
the data fed into existing real dns validation libraries.
=
Me too. But I think there are some folks who want to impleme= nt the validation themselves in the application, so the draft is trying to = cater to both camps.

Shumon.

<= /div>
--001a1139bc5026893b0519c7fc0d-- From nobody Tue Jun 30 20:58: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 DCF171A8A6C for ; Tue, 30 Jun 2015 20:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 SeBvWWZlMJ3s for ; Tue, 30 Jun 2015 20:58:22 -0700 (PDT) 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 323A41A8A56 for ; Tue, 30 Jun 2015 20:58:22 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 97912284D2B; Wed, 1 Jul 2015 03:58:20 +0000 (UTC) Date: Wed, 1 Jul 2015 03:58:20 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150701035820.GJ14121@mournblade.imrryr.org> References: <55922571.8080605@nomountain.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] draft-shore-tls-dnssec-chain-extension-00 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, 01 Jul 2015 03:58:24 -0000 On Tue, Jun 30, 2015 at 11:33:23PM -0400, Shumon Huque wrote: > > Having browsers have some kind of "validate this chain of DNS records > > that is asumed to be in some validation order" seems awfully specific > > code that is "just not DNS enough" to cause problems. I'd rather see > > the data fed into existing real dns validation libraries. > > > Me too. But I think there are some folks who want to implement the > validation themselves in the application, so the draft is trying to cater > to both camps. Notice that Paul said "libraries" not "servers". So the validation would still be "in application", but ideally with well tested DNS code, maintained by experts. This is a difficult enough bunch of logic to get right, so making the input as DNS-library friendly as possible is a worthwhile goal. The code could also be in a TLS toolkit used by the application, with the TLS toolkit using a suitably robust DNS library, or rolling its own validator logic. Separately, Shumon's mention of CNAME/DNAME raises a critical complication. A single chain from a TLSA RRset to the root will often be insufficient. Instead, there would need to be in various cases: * A validated chain of CNAMEs (possibly synthesized via validated DNAME RRs) leading from the client's requested SNI name to a final TLSA base domain. (0 or more CNAME/DNAME indirection records and all the DNSKEY/DS/RRSIG records to validate these). * A validated chain of CNAMES from _port._proto. to an actual validated TLSA RRset (and ...). * The final TLSA RRset with all the requisite validation records. * Also a potential change in the client's notion of the reference identifier to match in certificates, to the final TLSA base domain. While still feasible, this makes locating and processing all requisite records significantly more complex. Servers and clients will need very carefully designed and implemented libraries to collect and process this data. Caching at the server end is likely unavoidable, while the client likely also needs a cache to keep the handshake overhead more modest on average. -- Viktor. From nobody Tue Jun 30 22: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 A6C9F1ACDE0 for ; Tue, 30 Jun 2015 22:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 mMAtNX69RbnO for ; Tue, 30 Jun 2015 22:17:15 -0700 (PDT) Received: from emh07.mail.saunalahti.fi (emh07.mail.saunalahti.fi [62.142.5.117]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 202D21ACDE3 for ; Tue, 30 Jun 2015 22:17:09 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id 002B540C3; Wed, 1 Jul 2015 08:17:07 +0300 (EEST) Date: Wed, 1 Jul 2015 08:17:07 +0300 From: Ilari Liusvaara To: Dave Garrett Message-ID: <20150701051707.GA24615@LK-Perkele-VII> References: <201506302131.20214.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <201506302131.20214.davemgarrett@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Jul 2015 05:17:17 -0000 On Tue, Jun 30, 2015 at 09:31:19PM -0400, Dave Garrett wrote: > On Tuesday, June 30, 2015 06:23:18 pm Eric Rescorla wrote: > > 2. Should we require that PSK cipher suites where the PSK is used for > > resumption use compatible ciphers? > > The "suitable PSK cipher suite" & "resumption use compatible ciphers" > issues would be simpler if the NewSessionTicket was just bound to a > specified cipher suite (or vector of suites, but that's probably not > needed). We could just add a cipher suite field here so the server > tells the client exactly what it expects. Except since actual PSKs presumably don't have such restrictions (any supported ciphersuite ok), any games with ciphersuites the server plays would be specific to resumption. I don't see anything wrong with session being resumed with different ciphersuite in 1.3 (in 1.2 things worked differently, there there actually might have been problems if ciphersuite changed). -Ilari From nobody Tue Jun 30 22:23: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 69EB21ACDF9 for ; Tue, 30 Jun 2015 22:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 L973xEBHCA1D for ; Tue, 30 Jun 2015 22:22:58 -0700 (PDT) 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 3F19B1ACE01 for ; Tue, 30 Jun 2015 22:22:58 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh06.mail.saunalahti.fi (Postfix) with ESMTP id C858169A72; Wed, 1 Jul 2015 08:22:55 +0300 (EEST) Date: Wed, 1 Jul 2015 08:22:55 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20150701052255.GB24615@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Jul 2015 05:23:00 -0000 On Tue, Jun 30, 2015 at 03:23:18PM -0700, Eric Rescorla wrote: > > OPEN ISSUES > There are still a number of known open issues to discuss: > > 1. The present known_configuration mechanism allows the client to > resurrect the handshake parameters (though not the keys) which were > negotiated in a previous handshake, but this is done implicitly, > i.e., the server provides a label and the client returns it on > the next connection. This has the advantage of keeping things short > but the disadvantage the it means that you can't have a static > configuration ID for everyone (instead, the server has to somehow > embed the properties in the configuration ID). There are (at least) > three potential alternative designs: > > (a) Have the client indicate in his first flight "these are the > parameters I expect you to negotiate", along with the > configuration identifier, based on what the server > negotiated the previous time. [Optionally, the server > can run the same negotiation locally and abort on mismatch.] > > (b) As in (a) but with no indication of the expected parameters, > just the configuration ID, and the client just preemptively > uses the parameters from the last time and if the negotiation > ends up differently, all the data is undecryptable > (ugh) and you somehow fall back. > > (c) Have the server provide a preference list in his > ServerConfiguration (this can be the same as in the > ClientHello) and have the client do the negotiation based on > that rather than the server (as in QUIC). This is a little odd > in that it means that sometimes the server selects the > parameters and sometimes the client does, but it's not that > hard to make this code symmetrical. > > As I think this through, I am leaning towards (a) but other people's > opinions on this topic would be welcome. I think that there should be capability for server to fail decrypting the 0RTT data but still proceed with handshake (informing client of this fact). Are parameters here things like symmetric ciphersuite used for 0RTT encryption? Or something else? I think that even if one uses supported symmetric ciphers, one could still get decrypt failures. Or is this the "PSK + 0RTT" vs "DHE + 0RTT" problem (the one remaked in #3)? Undecryptable 0RTT becomes practicularly fun when considering how that would interact with handshake transcripts. > 2. Should we require that PSK cipher suites where the PSK is used for > resumption use compatible ciphers? This is the way it was in TLS 1.2 > and below for resumption and tickets, but once you have a PSK, that's > not really necessary [0]. So, for instance, if you had the following > cipher list order: > > ECDHE + AES-GCM > ECDHE + ChaCha/Poly > PSK + ChaCha/Poly > PSK + AES-GCM > > You could potentially negotiate one connection with GCM, use it > to establish a shared key, and then reconnect with ChaCha/Poly. > This seems like it probably should be something we avoid, though > I'm not sure we have a concrete reason why, and it means a > weird special case for PSK. Note that this issue might be > ameliorated some (though not completely) with a la carte negotiation. I would place stuff like this into "client sending odd stuff and getting odd behaviour in response". And with the negotiation the way it is, I don't see security problem here. Also, I noted that there isn't EncryptedExtensions for resumption. Is that message optional (it isn't marked so), or is it just omitted in pure-PSK case (tho I note that pure-PSK might want to use extensions that use EncryptedExtensions). > 3. I don't currently have PSK/Resumption + 0-RTT working, because you > need a way to indicate the expected parameters (see point #1 above). -Ilari From nobody Tue Jun 30 22:34: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 ABD311ACE1E for ; Tue, 30 Jun 2015 22:34:07 -0700 (PDT) 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 xMx_qARw9L4J for ; Tue, 30 Jun 2015 22:34:04 -0700 (PDT) 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 4F0431ACE1D for ; Tue, 30 Jun 2015 22:34:04 -0700 (PDT) Received: by wiga1 with SMTP id a1so115242561wig.0 for ; Tue, 30 Jun 2015 22:34:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=du50E/uV8FeOGnrRb4ySMHm3J2IXUv6DsugVCTyYYj4=; b=cXCC9sHHQuJd/frhKFUuYrB48QtUdHWb78iofa0Wy+Y1xTrPuGAMurA/bOBuCwYvrd KbczF87K5rNFRlV5Qk52JnUq5cc/r+eb3Lp/Gu5nHRBOUdyh1djoYQCeOY50gp2x9wO+ kpbGseZ4fGANpzRYnhdScbq1+JvjKyb4LEt2Nq0TTmxg7G4ClsWEA0rjQwQsDJGfn45c 9KSm9+zSjObFA+4Y9GZ0jZCKOdou4gEq8yiGT4/7fhImBiHg3Yj/lthhwZGns1X/WyxY dJUSaP0p/FUZ+o3sw47hGyPA7f5Ew8DIA3ab5HF21Kqj0YtcyF29HJeqAzBQecybVTVk dITQ== X-Gm-Message-State: ALoCoQl2naSHX7sOM94UKqQhD+LpRtJjCdQ/oDw+1Kr3qCnusknFaKsth4nCwFqh+wKKWDxklv1a X-Received: by 10.180.99.39 with SMTP id en7mr40770410wib.31.1435728843262; Tue, 30 Jun 2015 22:34:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.95.211 with HTTP; Tue, 30 Jun 2015 22:33:23 -0700 (PDT) In-Reply-To: <20150701052255.GB24615@LK-Perkele-VII> References: <20150701052255.GB24615@LK-Perkele-VII> From: Eric Rescorla Date: Tue, 30 Jun 2015 22:33:23 -0700 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=f46d04182808b260050519c9ab95 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Jul 2015 05:34:07 -0000 --f46d04182808b260050519c9ab95 Content-Type: text/plain; charset=UTF-8 On Tue, Jun 30, 2015 at 10:22 PM, Ilari Liusvaara < ilari.liusvaara@elisanet.fi> wrote: > On Tue, Jun 30, 2015 at 03:23:18PM -0700, Eric Rescorla wrote: > > > > OPEN ISSUES > > There are still a number of known open issues to discuss: > > > > 1. The present known_configuration mechanism allows the client to > > resurrect the handshake parameters (though not the keys) which were > > negotiated in a previous handshake, but this is done implicitly, > > i.e., the server provides a label and the client returns it on > > the next connection. This has the advantage of keeping things short > > but the disadvantage the it means that you can't have a static > > configuration ID for everyone (instead, the server has to somehow > > embed the properties in the configuration ID). There are (at least) > > three potential alternative designs: > > > > (a) Have the client indicate in his first flight "these are the > > parameters I expect you to negotiate", along with the > > configuration identifier, based on what the server > > negotiated the previous time. [Optionally, the server > > can run the same negotiation locally and abort on mismatch.] > > > > (b) As in (a) but with no indication of the expected parameters, > > just the configuration ID, and the client just preemptively > > uses the parameters from the last time and if the negotiation > > ends up differently, all the data is undecryptable > > (ugh) and you somehow fall back. > > > > (c) Have the server provide a preference list in his > > ServerConfiguration (this can be the same as in the > > ClientHello) and have the client do the negotiation based on > > that rather than the server (as in QUIC). This is a little odd > > in that it means that sometimes the server selects the > > parameters and sometimes the client does, but it's not that > > hard to make this code symmetrical. > > > > As I think this through, I am leaning towards (a) but other people's > > opinions on this topic would be welcome. > > I think that there should be capability for server to fail decrypting > the 0RTT data but still proceed with handshake (informing client of > this fact). > What I had in mind here was that you would be able to fail to decrypt the 0-RTT data and you fell back to an ordinary 1-RTT handshake (i.e., if there was client auth, it went in the second flight). Are parameters here things like symmetric ciphersuite used for 0RTT > encryption? Or something else? I think that even if one uses supported > symmetric ciphers, one could still get decrypt failures. > > Or is this the "PSK + 0RTT" vs "DHE + 0RTT" problem (the one remaked > in #3)? > Sorry, I'm not quite following this. Can you rephrase? > Undecryptable 0RTT becomes practicularly fun when considering how > that would interact with handshake transcripts. That's why I'm thinking that the above is the simpler approach. > > 2. Should we require that PSK cipher suites where the PSK is used for > > resumption use compatible ciphers? This is the way it was in TLS 1.2 > > and below for resumption and tickets, but once you have a PSK, that's > > not really necessary [0]. So, for instance, if you had the following > > cipher list order: > > > > ECDHE + AES-GCM > > ECDHE + ChaCha/Poly > > PSK + ChaCha/Poly > > PSK + AES-GCM > > > > You could potentially negotiate one connection with GCM, use it > > to establish a shared key, and then reconnect with ChaCha/Poly. > > This seems like it probably should be something we avoid, though > > I'm not sure we have a concrete reason why, and it means a > > weird special case for PSK. Note that this issue might be > > ameliorated some (though not completely) with a la carte negotiation. > > I would place stuff like this into "client sending odd stuff and > getting odd behaviour in response". And with the negotiation the > way it is, I don't see security problem here. > Thanks. Also, I noted that there isn't EncryptedExtensions for resumption. > Is that message optional (it isn't marked so), or is it just omitted > in pure-PSK case (tho I note that pure-PSK might want to use > extensions that use EncryptedExtensions). That's just error on my part. My intent was to make resumption-as-PSK as much like ordinary handshakes as possible. -Ekr --f46d04182808b260050519c9ab95 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jun 30, 2015 at 10:22 PM, Ilari Liusvaara <= ;ilari.liu= svaara@elisanet.fi> wrote:
=
On Tue, Jun 30, 2015 at 03:23:18PM = -0700, Eric Rescorla wrote:
>
> OPEN ISSUES
> There are still a number of known open issues to discuss:
>
> 1. The present known_configuration mechanism allows the client to
> resurrect the handshake parameters (though not the keys) which were > negotiated in a previous handshake, but this is done implicitly,
> i.e., the server provides a label and the client returns it on
> the next connection. This has the advantage of keeping things short > but the disadvantage the it means that you can't have a static
> configuration ID for everyone (instead, the server has to somehow
> embed the properties in the configuration ID). There are (at least) > three potential alternative designs:
>
>=C2=A0 =C2=A0 (a) Have the client indicate in his first flight "th= ese are the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 parameters I expect you to negotiate",= along with the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 configuration identifier, based on what the= server
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 negotiated the previous time. [Optionally, = the server
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 can run the same negotiation locally and ab= ort on mismatch.]
>
>=C2=A0 =C2=A0 (b) As in (a) but with no indication of the expected para= meters,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 just the configuration ID, and the client j= ust preemptively
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 uses the parameters from the last time and = if the negotiation
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 ends up differently, all the data is undecr= yptable
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 (ugh) and you somehow fall back.
>
>=C2=A0 =C2=A0 (c) Have the server provide a preference list in his
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 ServerConfiguration (this can be the same a= s in the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 ClientHello) and have the client do the neg= otiation based on
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 that rather than the server (as in QUIC). T= his is a little odd
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 in that it means that sometimes the server = selects the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 parameters and sometimes the client does, b= ut it's not that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 hard to make this code symmetrical.
>
> As I think this through, I am leaning towards (a) but other people'= ;s
> opinions on this topic would be welcome.

I think that there should be capability for server to fail decr= ypting
the 0RTT data but still proceed with handshake (informing client of
this fact).

What I had in mind here was= that you would be able to fail to decrypt
the 0-RTT data and you= fell back to an ordinary 1-RTT handshake
(i.e., if there was cli= ent auth, it went in the second flight).


Are parameters here things like symmetric ciphersuite used for 0RTT
encryption? Or something else? I think that even if one uses supported
symmetric ciphers, one could still get decrypt failures.

Or is this the "PSK + 0RTT" vs "DHE + 0RTT" problem (th= e one remaked
in #3)?

Sorry, I'm not quite follow= ing this. Can you rephrase?

=C2=A0
Undecryptable 0RTT becomes practicularly fun when considering how
that would interact with handshake transcripts.

=
That's why I'm thinking that the above is the simpler approach= .

=C2=A0
> 2. Should we require that PSK cipher suites where the PSK is used for<= br> > resumption use compatible ciphers? This is the way it was in TLS 1.2 > and below for resumption and tickets, but once you have a PSK, that= 9;s
> not really necessary [0]. So, for instance, if you had the following > cipher list order:
>
>=C2=A0 =C2=A0 =C2=A0ECDHE + AES-GCM
>=C2=A0 =C2=A0 =C2=A0ECDHE + ChaCha/Poly
>=C2=A0 =C2=A0 =C2=A0PSK + ChaCha/Poly
>=C2=A0 =C2=A0 =C2=A0PSK + AES-GCM
>
> You could potentially negotiate one connection with GCM, use it
> to establish a shared key, and then reconnect with ChaCha/Poly.
> This seems like it probably should be something we avoid, though
> I'm not sure we have a concrete reason why, and it means a
> weird special case for PSK. Note that this issue might be
> ameliorated some (though not completely) with a la carte negotiation.<= br>
I would place stuff like this into "client sending odd stuff an= d
getting odd behaviour in response". And with the negotiation the
way it is, I don't see security problem here.

=
Thanks.


Also, I noted that there isn't EncryptedExtensions for resumption.
Is that message optional (it isn't marked so), or is it just omitted in pure-PSK case (tho I note that pure-PSK might want to use
extensions that use EncryptedExtensions).

T= hat's just error on my part. My intent was to make resumption-as-PSK as=
much like ordinary handshakes as possible.

<= div>
-Ekr

--f46d04182808b260050519c9ab95--