From ekr@rtfm.com Fri Jan 3 11:42:22 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8A251AE018 for ; Fri, 3 Jan 2014 11:42:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iOPdqvZqdwgf for ; Fri, 3 Jan 2014 11:42:21 -0800 (PST) Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) by ietfa.amsl.com (Postfix) with ESMTP id 3F53D1AE009 for ; Fri, 3 Jan 2014 11:42:21 -0800 (PST) Received: by mail-we0-f178.google.com with SMTP id u57so13996360wes.9 for ; Fri, 03 Jan 2014 11:42:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=AbNUAFZpq/EUbErqOy5hE4djpOwmtG8CY9wdveoCF9k=; b=dFvvKkYRZcsgoOXS9Z5fvWhMXOj1pemrQd6INN4JfaBi8fA2zwX3afd15nCBrdWUjW gEAW8AYkthuZKipctfys7hLYRHGQ/AaYXc0mMOHrlxWkxkXmqpof5VsmwKJokBy+dMaP v1D9ISRBX2q1YOE6lbHQ/BcD4+IeYw3EPG0PxRUn2YH6jCvhxhmdrrs24rVH2s3bQCt7 ICrA+ZNLLo50j/eFwml71D26jBQBaewgft7WWr5wp/1AsazNhnJknloLrTaX4GK6sGLC /pWpX1vNTHpMeo/iHxN7G+rJu74iv6VrlSmzOnQTcT3G2de4MDg23yaxNisezaN2nT0z SsLA== X-Gm-Message-State: ALoCoQmp4U5hXjtE64LmUaOnJh++iHN0wIdUO2bC6OpQSr6tdzy6TMSWb2MGUilq41jTEzu7Fasg X-Received: by 10.180.103.35 with SMTP id ft3mr3204792wib.18.1388778133347; Fri, 03 Jan 2014 11:42:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.54.194 with HTTP; Fri, 3 Jan 2014 11:41:33 -0800 (PST) X-Originating-IP: [2620:101:8003:300:ad24:91b1:ed16:61e8] From: Eric Rescorla Date: Fri, 3 Jan 2014 11:41:33 -0800 Message-ID: To: "tls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [TLS] Next steps for draft-agl-tls-padding X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 19:42:22 -0000 WG Members, We have received a request from the authors of http://tools.ietf.org/html/draft-agl-tls-padding-02 For early code point assignment. While there have not been a lot of comments this is a simple draft and and seems like an important tool for dealing with noncompliant servers which do not react well to specific-sized ClientHellos and so far we have heard no objections to this document. If there are any strong objections to this document or to making this provisional code point assignment, please raise them by Jan 10. The chairs are also interested in if people feel this should be a TLS WG item or an individual submission (or, if, as above, they object to it.) -Ekr [For the chairs] From housley@vigilsec.com Fri Jan 3 11:52:31 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81B621ADFCB for ; Fri, 3 Jan 2014 11:52:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-iiWnixydsN for ; Fri, 3 Jan 2014 11:52:29 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id 4A2F21AE012 for ; Fri, 3 Jan 2014 11:52:29 -0800 (PST) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 3FC9E9A4241; Fri, 3 Jan 2014 14:52:12 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id CdDtc4PGzUqm; Fri, 3 Jan 2014 14:51:50 -0500 (EST) Received: from [192.168.2.110] (pool-96-255-140-248.washdc.fios.verizon.net [96.255.140.248]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 25F029A4243; Fri, 3 Jan 2014 14:51:51 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: Date: Fri, 3 Jan 2014 14:51:39 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2CA5F6C5-7BBE-498A-A124-59DEA6F5BD93@vigilsec.com> References: To: Eric Rescorla X-Mailer: Apple Mail (2.1085) Cc: "tls@ietf.org" Subject: Re: [TLS] Next steps for draft-agl-tls-padding X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 19:52:31 -0000 I think the document is fine, but I do not think that the TLS WG should = ask for a early allocation unless the WG is going to proceed with the = document. Russ On Jan 3, 2014, at 2:41 PM, Eric Rescorla wrote: > WG Members, >=20 > We have received a request from the authors of >=20 > http://tools.ietf.org/html/draft-agl-tls-padding-02 >=20 > For early code point assignment. While there have not been > a lot of comments this is a simple draft and and seems like > an important tool for dealing with noncompliant servers > which do not react well to specific-sized ClientHellos > and so far we have heard no objections to this document. >=20 > If there are any strong objections to this document or to > making this provisional code point assignment, please > raise them by Jan 10. >=20 > The chairs are also interested in if people feel this should > be a TLS WG item or an individual submission (or, if, as > above, they object to it.) >=20 > -Ekr > [For the chairs] > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From watsonbladd@gmail.com Fri Jan 3 11:54:04 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA30B1AE012 for ; Fri, 3 Jan 2014 11:54:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f0NnGHKFxZYp for ; Fri, 3 Jan 2014 11:54:03 -0800 (PST) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 210F31ADFD7 for ; Fri, 3 Jan 2014 11:54:02 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id n12so13628794wgh.21 for ; Fri, 03 Jan 2014 11:53:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0Ymi2AIOFLpe6ukdHWa0OBFIyVKoJxLnfPPG9T6M95g=; b=Ql3ZcIzZaxLrhlJNhaFSYy9VPXtTRx8E+6GfeZI2s13COK9xSYXoZQi958yCqOUkaE CuP2cdk0nc2tD9lKXBAkHSqFLMbZnAbSkQsmXRYskzDYIGpbdN+efZeIAvFwdmO5c2TD GuupaEOVdAXh5CCBwPK109tAGgeP8o/5dB8uFVVmS/M3Mf+VdM5RhRP69Wyw8jp+BWph TEAqgsCq4fcxeswQvi1W/NRNTggBFU2diAJiYJaGs/urbqeygKpyfOeRv1adHeAqXa+t Nh4Es4Pgf3BpueyxDv8dhltekE3JBsQZct/kaDLx89i/JFithFzSbuUD4ApkiYgiwIzC 4fiA== MIME-Version: 1.0 X-Received: by 10.180.13.242 with SMTP id k18mr3227335wic.44.1388778835316; Fri, 03 Jan 2014 11:53:55 -0800 (PST) Received: by 10.194.242.131 with HTTP; Fri, 3 Jan 2014 11:53:55 -0800 (PST) In-Reply-To: References: Date: Fri, 3 Jan 2014 14:53:55 -0500 Message-ID: From: Watson Ladd To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] Next steps for draft-agl-tls-padding X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 19:54:05 -0000 On Fri, Jan 3, 2014 at 2:41 PM, Eric Rescorla wrote: > WG Members, > > We have received a request from the authors of > > http://tools.ietf.org/html/draft-agl-tls-padding-02 > > For early code point assignment. While there have not been > a lot of comments this is a simple draft and and seems like > an important tool for dealing with noncompliant servers > which do not react well to specific-sized ClientHellos > and so far we have heard no objections to this document. > > If there are any strong objections to this document or to > making this provisional code point assignment, please > raise them by Jan 10. > > The chairs are also interested in if people feel this should > be a TLS WG item or an individual submission (or, if, as > above, they object to it.) What does this mean from a practical perspective? From my limited knowledge it only changes the length of the IETF last call, and doesn't substantively affect the process. Also, the draft shouldn't be published on April 1st. No one will believe this is a real extension if we do so. > > -Ekr > [For the chairs] > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From dkg@fifthhorseman.net Fri Jan 3 14:44:22 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 714171ADFC1 for ; Fri, 3 Jan 2014 14:44:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yYQejz2GELVz for ; Fri, 3 Jan 2014 14:44:20 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 793351ADFD7 for ; Fri, 3 Jan 2014 14:44:17 -0800 (PST) Received: from [192.168.13.121] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 97A4BF984; Fri, 3 Jan 2014 17:44:07 -0500 (EST) Message-ID: <52C73D37.4030403@fifthhorseman.net> Date: Fri, 03 Jan 2014 17:44:07 -0500 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.1.1 MIME-Version: 1.0 To: Eric Rescorla , "tls@ietf.org" References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="gQen7w5SjqtjWXOb4a6W39CUkrfWPuHUF" Subject: Re: [TLS] Next steps for draft-agl-tls-padding X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 22:44:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gQen7w5SjqtjWXOb4a6W39CUkrfWPuHUF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 01/03/2014 02:41 PM, Eric Rescorla wrote: > We have received a request from the authors of >=20 > http://tools.ietf.org/html/draft-agl-tls-padding-02 >=20 > For early code point assignment. While there have not been > a lot of comments this is a simple draft and and seems like > an important tool for dealing with noncompliant servers > which do not react well to specific-sized ClientHellos > and so far we have heard no objections to this document. >=20 > If there are any strong objections to this document or to > making this provisional code point assignment, please > raise them by Jan 10. I would be happy to see a provisional code point assignment on this TLS extension. > The chairs are also interested in if people feel this should > be a TLS WG item or an individual submission (or, if, as > above, they object to it.) It seems to me like it should be a WG item. It doesn't seem controversial at all, and it's clear that all TLS clients today have a concrete use for it. --dkg --gQen7w5SjqtjWXOb4a6W39CUkrfWPuHUF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJSxz03XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpc8QgP/2zZ4OaSHfF5TZFoe9XzxU8S 0wRT2faYChs04qmvJnmZnhw0/SJHliDW9vGfq022CO+4ZUzfTkI7sKOwQfXY2xso u8YKjp9xluI64QHdcJn3H7CdyC8fY1NZ6ODjadYxCTLMQGbr0B3ZeIbHbO3+MOS/ /C17HupVao9Gkj/JyudRHX3N1ZJVR/EazPPw8JeCUlN9ZgDthz8WIQSZlU3eJoWI gctTWxj5EgLAieIKM2UmHSYUCCbzU5S2FBdSJ0r1YkANUiVt0ZvMxstQqxFZQetx 2GcEP/WWlKtN846eb1AWjPRsDpCYMkeUKEeeFLoyGRU9gGJJbiBv5dxaWuAg1uiw yjeb6e88dqpJwONm+sHT6OP+qZ/giwBra7uS7b0gxzs+25fg4xENI5HQKNFkEC9M PTp0FFBmqQQbiiya6brUDS7Z6q/F/vaLkjvvX4cWHpeh0c/7d2bH8kfoqOYpQq9N TX+6q/dyH+5pRvpXVgWH7cNvYmdPfm3lcOfj2h3Ka0+HFDTzGi2o9C8DDrQY0ml+ hzQejyhSBwI4T2tlruERXpRBf1EXhNLtK09EZ+Eyz4lfmej5ikfnou+Ig/NebWbX RazdNmrmYy+ygroUNp5jZeFGiaVzsEmHRx0HDSfBw/spUoVjYTKW1Vzn+IacRlW8 SyRsEsxSKlSK+FI2EZS3 =/uZd -----END PGP SIGNATURE----- --gQen7w5SjqtjWXOb4a6W39CUkrfWPuHUF-- From frantz@pwpconsult.com Sun Jan 5 22:37:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 343151ADFA8 for ; Sun, 5 Jan 2014 22:37:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 PcUk8AQ01VDu for ; Sun, 5 Jan 2014 22:37:35 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id 6BBD91ADF69 for ; Sun, 5 Jan 2014 22:37:34 -0800 (PST) Received: from [173.75.83.221] (helo=Williams-MacBook-Pro.local) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1W03oU-0000k6-4G for tls@ietf.org; Mon, 06 Jan 2014 01:37:26 -0500 Date: Sun, 5 Jan 2014 22:37:25 -0800 From: Bill Frantz To: tls@ietf.org X-Priority: 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.3.1 (422) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec796a265d936621421ccbe2760c0e02c281350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 173.75.83.221 Subject: Re: [TLS] Fixing CBC Mode I: GenericBlockCipher construction X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Jan 2014 06:37:37 -0000 [Getting caught up on mail after vacation.] On 12/29/13 at 3:15 PM, ekr@rtfm.com (Eric Rescorla) wrote: > We have seen two major proposals for fixing the GenericBlockCipher > construction: >=20 > - Encrypt-then-MAC > - Pad-MAC-Encrypt Given the better robustness shown by Encrypt-then-MAC, I prefer it. Its wea= kness seem to be: * If the MAC leaks MAC key bits and the MAC key generation from the initial master secret can be reversed, an attacker can recover the session encryption key. I don't think this attack is likely. * If the MAC is weak enough that an attacker can create valid MACs for messages, a message injection attack or a replay attack may be possible. I think the proven properties of HMAC make this attack unlikely. =20 Cheers - Bill ------------------------------------------------------------------------- Bill Frantz | The first thing you need when | Periwinkle (408)356-8506 | using a perimeter defense is a | 16345 Englewood Ave www.pwpconsult.com | perimeter. | Los Gatos, CA 95032 From fabrice.gautier@gmail.com Tue Jan 7 08:55:04 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7EB01AE04E for ; Tue, 7 Jan 2014 08:55:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1r-hESpmD11 for ; Tue, 7 Jan 2014 08:55:03 -0800 (PST) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 3F37A1AE04D for ; Tue, 7 Jan 2014 08:55:03 -0800 (PST) Received: by mail-we0-f176.google.com with SMTP id p61so385769wes.21 for ; Tue, 07 Jan 2014 08:54:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=0j1w74iUkZonzlHk+tBHTP5Im71l7w1Hbz4I/9Tz2AE=; b=i9JVatibrPx7wS3MyKQp/AY1OWFwoe4zzBVgPGiwwxmUZ0O5SFuCc+wflwbB/j1p3y yIkvZ3fPofwJkmzp2u/O91LWzQA7jMSpbuulP24WuE4iSr6zZ+11V+n/SPfD2a26BX+C MbH1Ftj0EaqyhcOpXwx14Vmzx5mA36Xrl/s+chBWizYoF5OA3/hw6OR6DzGxAR5Q2mEn PTFAoLRn0UaZakmMeSDMv37HMXyvveleYxSyjDdZ9l1gcuGcihrlOzH3ayYpC3FjhWOG DMSWXe1f16reca+I0OgldAY/99z1mQtywipF4rDYsCxbC+h9cF4lBmxMlA7JGdfp/MJp Jq2w== X-Received: by 10.194.63.134 with SMTP id g6mr8670300wjs.46.1389113693932; Tue, 07 Jan 2014 08:54:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.84.202 with HTTP; Tue, 7 Jan 2014 08:54:33 -0800 (PST) From: Fabrice Gautier Date: Tue, 7 Jan 2014 08:54:33 -0800 Message-ID: To: "" Content-Type: text/plain; charset=ISO-8859-1 Subject: [TLS] DTLS and bad handshake messages. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Jan 2014 16:55:04 -0000 Hi all, I thought I already asked that question to the list, but can't find the answer, so here I go: During in DTLS handshake (over UDP), how should an implementation handle bad/invalid messages ? >From RFC 6347, section 1.4.2.7 explain how to handle invalid records (in general, just ignore and discard them). From the context I assume that this only mean something at the record layer is wrong: the header is invalid, the record is too small, didn't decrypt/mac properly, etc... However, what if the record layer is perfectly valid, but something is wrong at the message layer ? Section 4.2.2 mentions what to do in case the message sequence number are wrong (discard repeated sequence number, buffer future sequence number) But what to do if, for example, a message has the right message sequence number, but is not an expected message type ? A TLS implementation would send an alert and close the connection. Should a DTLS implementation do the same ? Thanks -- Fabrice From watsonbladd@gmail.com Tue Jan 7 10:11:47 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0BFA1AE06D for ; Tue, 7 Jan 2014 10:11:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzhQYK2kf50c for ; Tue, 7 Jan 2014 10:11:45 -0800 (PST) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 5E9C41AE0C9 for ; Tue, 7 Jan 2014 10:11:45 -0800 (PST) Received: by mail-we0-f179.google.com with SMTP id q59so498876wes.10 for ; Tue, 07 Jan 2014 10:11:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=J5aqQchnQaxXD6699+K530KvAV945hRw7hH9GIwqyMg=; b=h5DO05JYVjB7Q05xkT/90XL+YrGiDb+v+vJeIelzDnE9yjt9twQk2p9u9v3rgXs12z RZNTMn3CBdhdKlSDYyhaCam7x0x7dm9XX1MoDHPCgjbOXrYfTh4bsVFjjZBKF6ohMg45 v0AIHsYt4xwBv8KEWaS2eKLb/97sJo3kFyM2MqFrMpU69IxSMyz6hpTvddOAoffqVsfZ 8ujDCXrAfpX90ERc0r5aLcwwwFvoH+0u34i7kWREQk1n5Tda+nLZGvjlsYXFX46JRNdL KBj3ZKb1moms87hIL6mJuQPIW5tW6TS13Wx4JKGr8ODAXh4KP+U/s21GxqhPLcs2gKyI VTCw== MIME-Version: 1.0 X-Received: by 10.180.90.230 with SMTP id bz6mr18106168wib.17.1389118296103; Tue, 07 Jan 2014 10:11:36 -0800 (PST) Received: by 10.194.242.131 with HTTP; Tue, 7 Jan 2014 10:11:36 -0800 (PST) Date: Tue, 7 Jan 2014 10:11:36 -0800 Message-ID: From: Watson Ladd To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Subject: [TLS] Remarks on draft-shin-tls-augpake-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Jan 2014 18:11:48 -0000 Given that Dragonfly refuses to die, I think it is worth considering AugPAKE. I've changed my mind about the necessity: the IoT people want it badly, and if we don't do this, it will be Dragonfly. The only issue I see is the draft needs to be made group agnostic and work on some sufficiently big ECC group. That's a straightforward, if tedious, change of notation. Sincerely, Watson Ladd From Andrei.Popov@microsoft.com Tue Jan 7 11:13:54 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 187601AE107 for ; Tue, 7 Jan 2014 11:13:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 F4jX_vzMrYhj for ; Tue, 7 Jan 2014 11:13:51 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0183.outbound.protection.outlook.com [207.46.163.183]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC351AE0F4 for ; Tue, 7 Jan 2014 11:13:51 -0800 (PST) Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BL2PR03MB417.namprd03.prod.outlook.com (10.141.92.12) with Microsoft SMTP Server (TLS) id 15.0.847.13; Tue, 7 Jan 2014 19:13:40 +0000 Received: from BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) by BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) with mapi id 15.00.0847.008; Tue, 7 Jan 2014 19:13:40 +0000 From: Andrei Popov To: Daniel Kahn Gillmor , Eric Rescorla , "tls@ietf.org" Thread-Topic: [TLS] Next steps for draft-agl-tls-padding Thread-Index: AQHPCLvtby8WvpFe1k25HLMV2DNQuJpzmSaAgAYOCwA= Date: Tue, 7 Jan 2014 19:13:40 +0000 Message-ID: References: <52C73D37.4030403@fifthhorseman.net> In-Reply-To: <52C73D37.4030403@fifthhorseman.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::2] x-forefront-prvs: 008421A8FF x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(479174003)(377454003)(24454002)(13464003)(189002)(199002)(51704005)(74706001)(74876001)(77982001)(63696002)(79102001)(59766001)(81816001)(81686001)(65816001)(15975445006)(80022001)(76796001)(76786001)(76576001)(56776001)(85306002)(87266001)(56816005)(90146001)(83072002)(85852003)(87936001)(2656002)(80976001)(19580395003)(83322001)(19580405001)(74316001)(74366001)(53806001)(15202345003)(76482001)(54356001)(4396001)(46102001)(51856001)(49866001)(47736001)(50986001)(47976001)(74502001)(47446002)(31966008)(54316002)(74662001)(81542001)(69226001)(81342001)(33646001)(3826001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR03MB417; H:BL2PR03MB419.namprd03.prod.outlook.com; CLIP:2001:4898:80e8:ed31::2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [TLS] Next steps for draft-agl-tls-padding X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 19:13:54 -0000 QSBwcm92aXNpb25hbCBjb2RlIHBvaW50IGFzc2lnbm1lbnQgZm9yIHRoaXMgVExTIGV4dGVuc2lv biB3b3VsZCBiZSBncmVhdC4NCg0KQ2hlZXJzLA0KDQpBbmRyZWkNCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IFRMUyBbbWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgRGFuaWVsIEthaG4gR2lsbG1vcg0KU2VudDogRnJpZGF5LCBKYW51YXJ5IDMsIDIw MTQgMjo0NCBQTQ0KVG86IEVyaWMgUmVzY29ybGE7IHRsc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6 IFtUTFNdIE5leHQgc3RlcHMgZm9yIGRyYWZ0LWFnbC10bHMtcGFkZGluZw0KDQpPbiAwMS8wMy8y MDE0IDAyOjQxIFBNLCBFcmljIFJlc2NvcmxhIHdyb3RlOg0KPiBXZSBoYXZlIHJlY2VpdmVkIGEg cmVxdWVzdCBmcm9tIHRoZSBhdXRob3JzIG9mDQo+IA0KPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1hZ2wtdGxzLXBhZGRpbmctMDINCj4gDQo+IEZvciBlYXJseSBjb2RlIHBvaW50 IGFzc2lnbm1lbnQuIFdoaWxlIHRoZXJlIGhhdmUgbm90IGJlZW4gYSBsb3Qgb2YgDQo+IGNvbW1l bnRzIHRoaXMgaXMgYSBzaW1wbGUgZHJhZnQgYW5kIGFuZCBzZWVtcyBsaWtlIGFuIGltcG9ydGFu dCB0b29sIA0KPiBmb3IgZGVhbGluZyB3aXRoIG5vbmNvbXBsaWFudCBzZXJ2ZXJzIHdoaWNoIGRv IG5vdCByZWFjdCB3ZWxsIHRvIA0KPiBzcGVjaWZpYy1zaXplZCBDbGllbnRIZWxsb3MgYW5kIHNv IGZhciB3ZSBoYXZlIGhlYXJkIG5vIG9iamVjdGlvbnMgdG8gDQo+IHRoaXMgZG9jdW1lbnQuDQo+ IA0KPiBJZiB0aGVyZSBhcmUgYW55IHN0cm9uZyBvYmplY3Rpb25zIHRvIHRoaXMgZG9jdW1lbnQg b3IgdG8gbWFraW5nIHRoaXMgDQo+IHByb3Zpc2lvbmFsIGNvZGUgcG9pbnQgYXNzaWdubWVudCwg cGxlYXNlIHJhaXNlIHRoZW0gYnkgSmFuIDEwLg0KDQpJIHdvdWxkIGJlIGhhcHB5IHRvIHNlZSBh IHByb3Zpc2lvbmFsIGNvZGUgcG9pbnQgYXNzaWdubWVudCBvbiB0aGlzIFRMUyBleHRlbnNpb24u DQoNCj4gVGhlIGNoYWlycyBhcmUgYWxzbyBpbnRlcmVzdGVkIGluIGlmIHBlb3BsZSBmZWVsIHRo aXMgc2hvdWxkIGJlIGEgVExTIA0KPiBXRyBpdGVtIG9yIGFuIGluZGl2aWR1YWwgc3VibWlzc2lv biAob3IsIGlmLCBhcyBhYm92ZSwgdGhleSBvYmplY3QgdG8gDQo+IGl0LikNCg0KSXQgc2VlbXMg dG8gbWUgbGlrZSBpdCBzaG91bGQgYmUgYSBXRyBpdGVtLiAgSXQgZG9lc24ndCBzZWVtIGNvbnRy b3ZlcnNpYWwgYXQgYWxsLCBhbmQgaXQncyBjbGVhciB0aGF0IGFsbCBUTFMgY2xpZW50cyB0b2Rh eSBoYXZlIGEgY29uY3JldGUgdXNlIGZvciBpdC4NCg0KCS0tZGtnDQoNCg== From mrex@sap.com Tue Jan 7 12:17:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA341AE192 for ; Tue, 7 Jan 2014 12:17:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, WEIRD_QUOTING=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 ZVJEEGYy_Em7 for ; Tue, 7 Jan 2014 12:17:34 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 851F41AE15B for ; Tue, 7 Jan 2014 12:17:34 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s07KHN0p004489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 7 Jan 2014 21:17:23 +0100 (MET) In-Reply-To: To: Andrei Popov Date: Tue, 7 Jan 2014 21:17:22 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140107201722.ECDA01AB93@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "tls@ietf.org" Subject: Re: [TLS] Next steps for draft-agl-tls-padding 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, 07 Jan 2014 20:17:37 -0000 Andrei Popov wrote: > > A provisional code point assignment for this TLS extension would be great. A provisional code point would be nice, but I had to read the description of the extension contents several times and cross-check with other TLS extension documents to figure out (and assure myself) what draft-agl-tls-padding-02 really means implementation-wise. http://tools.ietf.org/html/draft-agl-tls-padding-02#section-3 3. Padding Extension A new extension type (""padding(TBD)"") is defined and MAY be included by the client in its ClientHello message. enum { padding(TBD), (65535) } ExtensionType The client MUST fill the padding extension completely with zero bytes, although the padding extension may be empty. The server MUST NOT echo the extension. Based on the general definition of TLS extensions: http://tools.ietf.org/html/rfc3546#section-2.3 http://tools.ietf.org/html/rfc4366#section-2.3 http://tools.ietf.org/html/rfc5246#section-7.4.1.4 2.3. Hello Extensions The extension format for extended client hellos and extended server hellos is: struct { ExtensionType extension_type; opaque extension_data<0..2^16-1>; } Extension; Here: - "extension_type" identifies the particular extension type. - "extension_data" contains information specific to the particular extension type. I assume that what draft-agl-tls-padding-02 intends to say is that "extension_data" for the Padding TLS extension has no internal structure (and therefore no additional extension-internal length field). Anyhow, extension_data is supposed to have variable length, and constain only zero bytes when present. compare to Renegotiation Info TLS extension: http://tools.ietf.org/html/rfc5746#section-3.2 It might help to describe the resulting on-the-wire encoding of two samples: the padding ExtensionType will be a 16-bit integer that can be represented as 0xhhll (where hh stands for the most significant octet and ll stands for the least significant octet). The shortest padding "Extension" struct with padding length 0 will encode to hh ll 00 00 With a padding of 5 octets, the padding "Extension" struct will encode to hh ll 00 05 00 00 00 00 00 \ / \ / \ / \ / \ / \ / | | ---------- | | | | | +---- Extension.extension_data contents | | | +-------------- <0..2^16-1> 16-bit length of | Extension.extension_data variable length vector | +-------------------- IANA-assigned Extension.extension_type for padding extension The Renegotiation Info extension will also be "empty" on initial handshakes on a connection, but its extension_data has internal structure struct { opaque renegotiated_connection<0..255>; } RenegotiationInfo; and the variable length internal structure adds an additional length field (a one-octet length field for vector size <0..255>), even when renegotiated_connection itself is "empty", resulting in the on-the-wire representation ff 01 00 01 00 . -Martin From ilari.liusvaara@elisanet.fi Tue Jan 7 12:55:21 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97C9E1AE1E3 for ; Tue, 7 Jan 2014 12:55:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NpuM3aIqBiwr for ; Tue, 7 Jan 2014 12:55:19 -0800 (PST) Received: from emh07.mail.saunalahti.fi (emh07.mail.saunalahti.fi [62.142.5.117]) by ietfa.amsl.com (Postfix) with ESMTP id 923BE1AE1DC for ; Tue, 7 Jan 2014 12:55:19 -0800 (PST) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id 2A02D3FEC; Tue, 7 Jan 2014 22:55:08 +0200 (EET) Date: Tue, 7 Jan 2014 22:55:08 +0200 From: Ilari Liusvaara To: Watson Ladd Message-ID: <20140107205508.GA9675@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.21 (2010-09-15) Sender: Ilari Liusvaara Cc: "tls@ietf.org" Subject: Re: [TLS] Remarks on draft-shin-tls-augpake-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Jan 2014 20:55:21 -0000 On Tue, Jan 07, 2014 at 10:11:36AM -0800, Watson Ladd wrote: > > The only issue I see is the draft needs to be made group agnostic and > work on some sufficiently big ECC group. That's a straightforward, if > tedious, change of notation. Also, there are interesting elliptic groups it would need to work over that don't have h=1, but still have small h (e.g. M-series groups have h=8, E-series has IIRC h=4). Would checking for elements with small orders be enough (I think no seriously considered group would have more than 8 of those)? The check in current spec that certain values are not -1, 0 or 1 can be seen as that sort of check, since those are the only values of small order (and 0 is just plain invalid)... Oh, and don't forget checks that point decompression succeeds[1] or that claimed point is on the curve (for uncompressed representation). [1] Certain square-root/curve implementations lead to twist attacks by sending invalid compressed points. Some others lead into a mess I don't know how what to make of[2]). [2] But probably it isn't good. -Ilari From watsonbladd@gmail.com Tue Jan 7 13:10:55 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D05E21AE0E2 for ; Tue, 7 Jan 2014 13:10:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lz9_HH5dOgkg for ; Tue, 7 Jan 2014 13:10:54 -0800 (PST) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) by ietfa.amsl.com (Postfix) with ESMTP id A1C731AE0CA for ; Tue, 7 Jan 2014 13:10:53 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id x18so697914lbi.17 for ; Tue, 07 Jan 2014 13:10:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=N8YUqFXqzpBVNqCZ90MEGXNTujDIBVH0lePPLK/L6KQ=; b=qkB/4JWsKV86MKdMYec6S/EafRpiooUCxm5iPOpMkV+/D/QUgptFpKIB166fSsmLJn aR+VH2/mHoQpxVTr8LCdv032nZTGIzEI4QhgJ53gLrBmIoFoklxhk/H4VhUkJyDdygSz h/plMOK1eHEvPsmdE7b75I7ZRrG8KYsUNo4E89kqqavlaeHerFDtkNMeP1GWQrJNqhc4 dXaAcmfLQKfy/Qxsefe+z/RHUGXSjpSWYcdRs0DuglqThOU3gVaEftEZnWb8KjJieWAB bS9/yOm08e0DZ3h4ckzLySfj3HidTxT4Ys+Qs/UJlPzYFy/VG3wW1fMB3IvfRx88jKJk pStQ== MIME-Version: 1.0 X-Received: by 10.112.219.99 with SMTP id pn3mr45131681lbc.24.1389129044076; Tue, 07 Jan 2014 13:10:44 -0800 (PST) Received: by 10.152.19.197 with HTTP; Tue, 7 Jan 2014 13:10:44 -0800 (PST) In-Reply-To: <20140107205508.GA9675@LK-Perkele-VII> References: <20140107205508.GA9675@LK-Perkele-VII> Date: Tue, 7 Jan 2014 13:10:44 -0800 Message-ID: From: Watson Ladd To: Ilari Liusvaara Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] Remarks on draft-shin-tls-augpake-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Jan 2014 21:10:56 -0000 On Tue, Jan 7, 2014 at 12:55 PM, Ilari Liusvaara wrote: > On Tue, Jan 07, 2014 at 10:11:36AM -0800, Watson Ladd wrote: >> >> The only issue I see is the draft needs to be made group agnostic and >> work on some sufficiently big ECC group. That's a straightforward, if >> tedious, change of notation. > > Also, there are interesting elliptic groups it would need to work over > that don't have h=1, but still have small h (e.g. M-series groups have > h=8, E-series has IIRC h=4). > > Would checking for elements with small orders be enough (I think no > seriously considered group would have more than 8 of those)? Checking membership in [l]E(F_p) is expensive (1 exponentiation), but would definitely do the job. > > The check in current spec that certain values are not -1, 0 or 1 can be > seen as that sort of check, since those are the only values of small > order (and 0 is just plain invalid)... These are contributory tests. > > Oh, and don't forget checks that point decompression succeeds[1] or that > claimed point is on the curve (for uncompressed representation). Isn't this part of implementing any cryptography? I can't speak for the authors, not being one of them, but I doubt this sort of statement would meet with strong opposition. > > > [1] Certain square-root/curve implementations lead to twist attacks by > sending invalid compressed points. Some others lead into a mess I don't > know how what to make of[2]). > > [2] But probably it isn't good. > > > -Ilari -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From agl@google.com Wed Jan 8 11:29:55 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 748701ADFF7 for ; Wed, 8 Jan 2014 11:29:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 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, RP_MATCHES_RCVD=-0.538, 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 ZzOGMteHxnE4 for ; Wed, 8 Jan 2014 11:29:53 -0800 (PST) Received: from mail-vb0-x22b.google.com (mail-vb0-x22b.google.com [IPv6:2607:f8b0:400c:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB901ADFCB for ; Wed, 8 Jan 2014 11:29:53 -0800 (PST) Received: by mail-vb0-f43.google.com with SMTP id p6so1473733vbe.2 for ; Wed, 08 Jan 2014 11:29:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=921NSC4/daidsBs9Bh2d1Jffb4zbpbORIBqvx6uJmYU=; b=Xa22DHJHx8l5bJXGqyms8kklQeXWTtfKoUAdDMQvQvg6FPtYy8EjSgaGk5JNqGXds7 gQfPKiJspP2j6Zq57RGAMGAb63Cg4RCPSadJiJwGrlOKmf/1snk4Y9/lMtOUtzkI6gxg sNqUvxtjCWfm674adY2gr0mlt2zjoLFlgz6ojxYurVhUFTcyuKf1qvUpk+VQvU1Y7Xze YVdzsS6Zr21Cz08VyNLNbfwwZOfIi0JrurcsqM+c2/lMxN+c8G/1VTKZJEesGs9v4P9S Eh1VE3tI1KZZnbRF1cmGFnzzlOnTnbNrQz+/Xsfb3nXAmmNtidUYvvYhsHo5/rmMlYIK BV4g== 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=921NSC4/daidsBs9Bh2d1Jffb4zbpbORIBqvx6uJmYU=; b=K+WhzKMh2GAEu+sSyEMTxia9cgkjtHszU+J1RTf6xBytU27jeTrrfJsxrkd5DNfSn1 XOeaR3e4Vz0di5u0lSNXTpnVbIOnXKbDFTz8IsAPy6pEvHJGPTtHClCclKS4gYJTNcOY yLWqgeScpIc3cy5QIplgxEWE3yi66BzZd9LpgkMX+DijG6W8MJAYbdY8p5s/0vAE9bYg fomj7FP/KVNqMGPr4lNLmIENsQda+eoyIgIl+NMhHO3CAYPLpegzhOVgmzRJR4FsWxmW 2GQVcN/iEFTVbPEeAD+PJXDoPIlLkZhu0v2vfgRcBn0e22rBWkH1d0YNxIpfy22OcJrQ O3tg== X-Gm-Message-State: ALoCoQlUU8mrmy2kly5E1dpqe3Pcr+I9rCHKFWDnUeLdfb89NQ1aKnpb7eDq6FF+JalGXjd2vaSwr20+vVCUHblk4jGpgP88hNnC5S+qw63Toug5uTU9qE2jH8ymcRmcR6+VVVix38GnOxZwNJB3X0hX3eETbsQm1ZeTZhnz0Xokq07fcrDlZ4W/6xnPlbOkKZGOlzWouThw X-Received: by 10.58.152.130 with SMTP id uy2mr4581757veb.71.1389209383823; Wed, 08 Jan 2014 11:29:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.96.134 with HTTP; Wed, 8 Jan 2014 11:29:23 -0800 (PST) In-Reply-To: <20140107201722.ECDA01AB93@ld9781.wdf.sap.corp> References: <20140107201722.ECDA01AB93@ld9781.wdf.sap.corp> From: Adam Langley Date: Wed, 8 Jan 2014 14:29:23 -0500 Message-ID: To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] Next steps for draft-agl-tls-padding X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 19:29:55 -0000 On Tue, Jan 7, 2014 at 3:17 PM, Martin Rex wrote: > A provisional code point would be nice, but I had to read the > description of the extension contents several times and cross-check > with other TLS extension documents to figure out (and assure myself) > what draft-agl-tls-padding-02 really means implementation-wise. Thanks for the comments. I think you make a good point and I've updated the draft (https://tools.ietf.org/html/draft-agl-tls-padding-03) to include your suggestions. (It'll need to be updated with the precise extension type, if assigned.) Cheers AGL From fabrice.gautier@gmail.com Wed Jan 8 13:59:45 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 874191ACC91 for ; Wed, 8 Jan 2014 13:59:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQIDRDsKWu44 for ; Wed, 8 Jan 2014 13:59:44 -0800 (PST) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id BA3561AC3FA for ; Wed, 8 Jan 2014 13:59:43 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id m15so2008479wgh.13 for ; Wed, 08 Jan 2014 13:59:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=s8tFyzaf+C+7VapqAPWSHTJ4Ck2GjHdLMfvDmpaU6xs=; b=S60qpzi72EdAzLRM7pceBfDjwKRzwkE3fhxU4NidIyN2oG2eeqZb8gaxe2sjGLgXE2 yIkrOcBQx0WxU7Y5e1ZKS6t265mrNXIygR9Mh0/QUuAFILwBIteGCkCRU2ee3nSw909H +XCy/aff4fHOx+3QwM2X+8MZiOyHv2cFdXu7WZ2BALelT8YZC2ocZvKoHEjDygyvLsUu aIfCyvJpOmZP0K5EZAcrlsRWd4Zz7WB663P7jYibWiv74VFJ5vFJS8g8q1T6hg4Hoqic ac6jbUTRihHI1vubR5BWa7oL5z7EHskNxbt+9jpeHsZwpWqRtG9LPTTCTAuaENQEIr8B WYOg== X-Received: by 10.180.205.162 with SMTP id lh2mr95114wic.57.1389218373874; Wed, 08 Jan 2014 13:59:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.84.202 with HTTP; Wed, 8 Jan 2014 13:59:12 -0800 (PST) From: Fabrice Gautier Date: Wed, 8 Jan 2014 13:59:12 -0800 Message-ID: To: "" Content-Type: text/plain; charset=ISO-8859-1 Subject: [TLS] Some questions about TLS False Start and symmetric ciphers. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Jan 2014 21:59:45 -0000 Hi all, A couple questions: 1) http://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00 is a few years old. Was there any intent to make this an actual RFC at some point ? 2) What was the rational for leaving some symmetric ciphers out of the white list. In particular, why was 3DES not part of the whitelist, and should RC4 still be on the whitelist ? My understanding is that the purpose of the whitelist was that an attacker would not be able downgrade to a trivially brute forceable cipher (e.g.: NULL, single DES...). My understanding is that even the best attacks on 3DES and RC4 still require an attacker to capture many messages, so that capturing a single encrypted message due to false start does not give you much advantage. Or putting it another way: If a cipher is considered not good enough for False Start, why would it be good enough for TLS without False Start ? Thanks -- Fabrice From agl@google.com Wed Jan 8 14:12:57 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C84431ACCFE for ; Wed, 8 Jan 2014 14:12:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 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, RP_MATCHES_RCVD=-0.538, 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 VhwI-Kq2I_7w for ; Wed, 8 Jan 2014 14:12:56 -0800 (PST) Received: from mail-vb0-x230.google.com (mail-vb0-x230.google.com [IPv6:2607:f8b0:400c:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 2B3A41ACCFF for ; Wed, 8 Jan 2014 14:12:56 -0800 (PST) Received: by mail-vb0-f48.google.com with SMTP id q12so1607736vbe.21 for ; Wed, 08 Jan 2014 14:12:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ZBAklJ1klI3qgw2icPCmvLOapJGpYs/3LQsio/c1rKA=; b=BgQjqnxlNWWqC/0fgglbi4YB3V7mrIl6b+6HzIGy2Bf4B/yZpImqbJyBZQW5FGDVnQ DlQlmUhnW4nkniJlzagJpt7hfQJCIpPxyGq5AolyljMIW8WgQWdz/3ANKujwHI+EB2p6 Z/rr+v5NTYHsjnPFUvRUeh93BASvEFyY0aS1VZVOHzreei4UYX5+1/Lrx+pl/tFfiG8G GJtZG9GLB0RZtsxTUBLv1FOMHJ1amO3Bo2TJU60/y5LsA95FBvd36ZyvLYOfZnsjCzQx Jxzm9fItaP+dNevUnD6lhaCUqvtDdrl98TLJl0uL1j5xENerVAYDKoRi6pWUwfGR0IqJ +Eaw== 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=ZBAklJ1klI3qgw2icPCmvLOapJGpYs/3LQsio/c1rKA=; b=NK+Ofn6nMhEhhhA5eCjNexvw3FrxP7A7iYxsOwaTh+uvsubDkBqjkshynflAovV/Ew 9yeHtj7o4zcVzerxEfzuYY4T+O93H6yTNWncuznLIG7iT8miYoyJksHXcwHuWiu95/TX FMRUg8MK9XGpwwNYzS/9w6y9R8wrXB2XJ1AbjeJPP7ryB4VWY2K1BqdXVGsmm4ECKheH WEPkfcMK+zik90gSUD16RsaY66HRpJxYGbgXy7YHiwfIBNHYA4H0gvDHtRhmXi1F2LTd qP3Fkk4Nvr2IpYVIV/UA7fia+qTjnPLpemxPi8EnCDkMBqWnA9p7RF1spfsMSvb7zpvc dI1w== X-Gm-Message-State: ALoCoQlihK/6s3o09xF6HQiMOd3NuBTh9guzLDJC5Cwsyn7tO8IcAuRjOVPbTtgMa9KXonmYEdxuub7MZ507vD3RCse+JlX4jJsqifCgoGYN745jgqBqqJFYQpa4QuKw/w4ZLZXkXkDCzrnL7ss12MPRnVQUMMZTllv+PD+gDOrXdvTHkUBzDT+l1yD7A54kldNOwbbOz+Uk X-Received: by 10.52.167.163 with SMTP id zp3mr4647669vdb.82.1389219166525; Wed, 08 Jan 2014 14:12:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.96.134 with HTTP; Wed, 8 Jan 2014 14:12:26 -0800 (PST) In-Reply-To: References: From: Adam Langley Date: Wed, 8 Jan 2014 17:12:26 -0500 Message-ID: To: Fabrice Gautier Content-Type: text/plain; charset=UTF-8 Cc: "" Subject: Re: [TLS] Some questions about TLS False Start and symmetric ciphers. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Jan 2014 22:12:58 -0000 On Wed, Jan 8, 2014 at 4:59 PM, Fabrice Gautier wrote: > 2) What was the rational for leaving some symmetric ciphers out of the > white list. > In particular, why was 3DES not part of the whitelist, and should RC4 > still be on the whitelist ? Nothing deep. 3DES just isn't in my mental model of ciphers most of the time. RC4 is likely to get removed from the list of False Start acceptable ciphers soon (in Chrome at least). > My understanding is that the purpose of the whitelist was that an > attacker would not be able downgrade to a trivially brute forceable > cipher (e.g.: NULL, single DES...). > My understanding is that even the best attacks on 3DES and RC4 still > require an attacker to capture many messages, so that capturing a > single encrypted message due to false start does not give you much > advantage. > > Or putting it another way: If a cipher is considered not good enough > for False Start, why would it be good enough for TLS without False > Start ? It probably wouldn't be. However, clients may wish to support poor ciphers because they would rather inter-operate with a server that would choose them, than simply not work. But we still wouldn't want enabling a poor cipher to potentially cause problems with every server. Cheers AGL From nmav@redhat.com Thu Jan 9 00:41:49 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 791461AD739 for ; Thu, 9 Jan 2014 00:41:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.44 X-Spam-Level: X-Spam-Status: No, score=-7.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, 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 ZVHDsy5dXYfx for ; Thu, 9 Jan 2014 00:41:47 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5801AC7F1 for ; Thu, 9 Jan 2014 00:41:47 -0800 (PST) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s098fadd020294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 9 Jan 2014 03:41:36 -0500 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s098fYit009752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Jan 2014 03:41:35 -0500 Message-ID: <1389256893.1498.13.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Fabrice Gautier Date: Thu, 09 Jan 2014 09:41:33 +0100 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Cc: "" Subject: Re: [TLS] Some questions about TLS False Start and symmetric ciphers. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Jan 2014 08:41:49 -0000 On Wed, 2014-01-08 at 13:59 -0800, Fabrice Gautier wrote: > My understanding is that the purpose of the whitelist was that an > attacker would not be able downgrade to a trivially brute forceable > cipher (e.g.: NULL, single DES...). > My understanding is that even the best attacks on 3DES and RC4 still > require an attacker to capture many messages, so that capturing a > single encrypted message due to false start does not give you much > advantage. It doesn't give you much advantage with the currently known attacks. Unfortunately attacks only get better with time and being conservative in design pays off. regards, Nikos From SRS0=d0zJ=WP=acm.org=bmoeller@srs.kundenserver.de Thu Jan 9 01:39:46 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BED91ADF5A for ; Thu, 9 Jan 2014 01:39:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.467 X-Spam-Level: X-Spam-Status: No, score=-1.467 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538, 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 zweqMOWcNwN5 for ; Thu, 9 Jan 2014 01:39:44 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by ietfa.amsl.com (Postfix) with ESMTP id 0A79A1AE146 for ; Thu, 9 Jan 2014 01:39:44 -0800 (PST) Received: from mail-ob0-f179.google.com (mail-ob0-f179.google.com [209.85.214.179]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0LpPm9-1VVisa1R0n-00ey0I; Thu, 09 Jan 2014 10:39:34 +0100 Received: by mail-ob0-f179.google.com with SMTP id wm4so2983206obc.24 for ; Thu, 09 Jan 2014 01:39:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4mmEgj+96FrEbSjpWhpPf6CV37mSQ3WdP4bFhSuM6PQ=; b=bSZ9JU4dTvRyAIqZV76RMFAQkaBqKDDrfcpCarVOduAkz9/Y5pmzUesLRPGT+5zl0f qAH3Ffk0RIFGn7dpYDQESEXkFWKlATOW5tIIHJW7xle7i87TWpncbIbZt/0yOU/B4/pn iJp0PC54+tdfujyNb6vykjpSvc5+smYr6AVAHWVp2FLl2t4qNYDn2wSDPQD1AjJU8gDv EIk+asAq1s1a68OGBJa4Tqu3h8FbuTPWhi17B9EJ8f3wOBbEU23k8dkToPm6w0OB6sd0 ZaVsQxLQ/tNIb5SWRp8Af8MZyj/CjQY+4LcNNCyq0GCYzhrzyrtT17a+xSwDVsVPszsa zN+Q== MIME-Version: 1.0 X-Received: by 10.60.233.9 with SMTP id ts9mr563697oec.65.1389260372028; Thu, 09 Jan 2014 01:39:32 -0800 (PST) Received: by 10.60.142.129 with HTTP; Thu, 9 Jan 2014 01:39:31 -0800 (PST) In-Reply-To: References: Date: Thu, 9 Jan 2014 10:39:31 +0100 Message-ID: From: Bodo Moeller To: Fabrice Gautier Content-Type: multipart/alternative; boundary=001a11369dc2f9bbf704ef86623b X-Provags-ID: V02:K0:j+91m6LQkD69qf0u/caqXRIltDLFVUmt6tvAd8SdtPY Z6KeDsgyElU5qspmOE0AIsnZeikIzwwdKvnWuf4Wd+/79hsFKg kbamRFRGsDcnTEz+blQR8vRJvwDEyGfFfTj7kUn1zjxud5CK59 NvHIkhEJuDblpJFVTqZjc6TY+VXOWZWlN/Ac8KZq8VAhoh5eGH iyxbC71jmSjRD2uUdnErRZ0lGZhdfeQZy+yDFe0IJS3H2Qq+xC RUe2ttd4l+I1QlD7pfckpB7tdyplLOpZObtjghFECuoSKqzED9 9Ae080tCNYDk4a2QU98adwwJfP6Q2G4hAeQYgjRLee94kACMOe DL80gQurNhnJp2Phkq0bnNblYVLxvvzwyIn8Ogd4ilvFGLkijb W9ZiErpk0ieXKSXKioQYSDqwBVYmSuiGrdfaOGtcsVC5FzrXuS h9TB/ Cc: "" Subject: Re: [TLS] Some questions about TLS False Start and symmetric ciphers. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Jan 2014 09:39:46 -0000 --001a11369dc2f9bbf704ef86623b Content-Type: text/plain; charset=ISO-8859-1 > > > 1) http://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00 is a > few years old. Was there any intent to make this an actual RFC at some > point ? > Yes. There just hasn't been anything essentially new to say for the spec, and the philosophical problem that we ran into remains -- while False Start works without problems with the huge majority servers (even though they haven't been specifically written for it) and is also used a lot in practice, it appears that some server implementors insist that they wouldn't like to be bound by *having* to interoperate with that. While otherwise we could bootstrap False Start compatibility by, say, making it a formal requirement with certain new ciphersuites or new TLS extensions, this unfortunately makes it hard to proceed with meaningful standardization (other than by waiting for TLS 1.3). With a bit of express working group enthusiasm, I could be enticed to create a new I-D version to at least formally un-expire it for now, though. > > > 2) What was the rational for leaving some symmetric ciphers out of the > white list. > In particular, why was 3DES not part of the whitelist, and should RC4 > still be on the whitelist ? > > My understanding is that even the best attacks on 3DES and RC4 still > require an attacker to capture many messages, so that capturing a > single encrypted message due to false start does not give you much > advantage. > As Adam has pointed out, we really should be removing RC4 from the suggested whitelist now. (3DES has less than 128 bits of security, which was the reasonable even if somewhat arbitrary threshold we picked.) Note that thinking that it's only about a *single* message is, these days at least, at trap -- clients could easily try to send the same secret over many independent connections that they try to establish with the same server. If that cipher is merely a "fallback" cipher that the real server wouldn't have picked voluntarily (given the other options offered by the client), this could weaken security. > Or putting it another way: If a cipher is considered not good enough > for False Start, why would it be good enough for TLS without False > Start ? Because without False Start, you have authenticated confirmation from the server that the cipher is good enough for that server. Bodo --001a11369dc2f9bbf704ef86623b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

1) http://tools.ietf.org/html/draft-bmoeller-tls-falsestart-= 00 is a
few years old. Was there any intent to make this an actual RFC at some
point ?

Yes. =A0There just hasn't b= een anything essentially new to say for the spec, and the philosophical pro= blem that we ran into remains -- while False Start works without problems w= ith the huge majority servers (even though they haven't been specifical= ly written for it) and is also used a lot in practice, it appears that some= server implementors insist that they wouldn't like to be bound by *hav= ing* to interoperate with that. =A0While otherwise we could bootstrap False= Start compatibility by, say, making it a formal requirement with certain n= ew ciphersuites or new TLS extensions, this unfortunately makes it hard to = proceed with meaningful standardization (other than by waiting for TLS 1.3)= . =A0With a bit of express working group enthusiasm, I could be enticed to = create a new I-D version to at least formally un-expire it for now, though.=

=A0


2) What was the rational for leaving some symmetric ciphers out of the
white list.
In particular, why was 3DES not part of the whitelist, and should RC4
still be on the whitelist ?
=A0
My understanding is that even the best attacks on 3DES and RC4 still
require an attacker to capture many messages, so that capturing a
single encrypted message due to false start does not give you much
advantage.

As Adam has pointed out, we = really should be removing RC4 from the suggested whitelist now. =A0(3DES ha= s less than 128 bits of security, which was the reasonable even if somewhat= arbitrary threshold we picked.) =A0Note that thinking that it's only a= bout a *single* message is, these days at least, at trap -- clients could e= asily try to send the same secret over many independent connections that th= ey try to establish with the same server. =A0If that cipher is merely a &qu= ot;fallback" cipher that the real server wouldn't have picked volu= ntarily (given the other options offered by the client), this could weaken = security.


Or putting it another way: If a cipher is considered not good enough
for False Start, why would it be good enough for TLS without False
Start ?

Because without False Start, you ha= ve authenticated confirmation from the server that the cipher is good enoug= h for that server.

Bodo

--001a11369dc2f9bbf704ef86623b-- From mnot@mnot.net Thu Jan 9 21:11:54 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89AE11ADBCD for ; Thu, 9 Jan 2014 21:11:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ya3KX_Ttjm1G for ; Thu, 9 Jan 2014 21:11:52 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8631ADEC8 for ; Thu, 9 Jan 2014 21:11:52 -0800 (PST) Received: from [192.168.1.57] (unknown [118.209.2.198]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 871C922E1FA; Fri, 10 Jan 2014 00:11:34 -0500 (EST) From: Mark Nottingham Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Fri, 10 Jan 2014 15:37:52 +1100 Message-Id: To: HTTP Working Group Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) Cc: "tls@ietf.org list" Subject: [TLS] FYI: ALPN implementation status tracking X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Jan 2014 05:11:54 -0000 I=92ve started a wiki page to track ALPN implementation status, since = it=92s on the critical path for implementing HTTP/2. Feel free to add / = correct / etc. https://github.com/http2/http2-spec/wiki/ALPN-Status -- Mark Nottingham http://www.mnot.net/ From mrex@sap.com Thu Jan 9 21:53:30 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12F8C1AE0CA for ; Thu, 9 Jan 2014 21:53:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 5c3n5vajKNUU for ; Thu, 9 Jan 2014 21:53:27 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 29A481AE0BC for ; Thu, 9 Jan 2014 21:53:23 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s0A5rCr7025112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 10 Jan 2014 06:53:12 +0100 (MET) In-Reply-To: To: Eric Rescorla Date: Fri, 10 Jan 2014 06:53:12 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140110055312.72CF31AB9A@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "tls@ietf.org" Subject: Re: [TLS] Fixing CBC Mode I: GenericBlockCipher construction X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 05:53:30 -0000 Eric Rescorla wrote: > > We have seen two major proposals for fixing the GenericBlockCipher > construction: > > - Encrypt-then-MAC > - Pad-MAC-Encrypt > > The sense of the chairs is that the Encrypt-then-MAC construction > has greater support (see, for instance, the thread started by > http://www.ietf.org/mail-archive/web/tls/current/msg10584.html) > but we would like to confirm that impression. > > If you have a comment to make about this, please do so by > January 10, 2014. It seems to me that both of these approaches, when applied to the SSLv3/TLSv1.0 GenericBlockCipher PDU with "running IV", will pull the rug from underneath the 1/(n-1) record splitting workaround that has been widely adopted as countermeasure to the Rizzo/Duong BEAST attack, because the first block is going to be filled with only deterministic block cipher padding following the one byte of application data rather than an unpredictable (H)MAC output. I therefore firmly believe that the fix should use one common GenericBlockCipher PDU with an explicit IV for SSLv3 and TLSv1.0 as well. A month ago I indicated that I would write and submit an I-D for Pad-MAC-Encrypt. I'm sorry I have not yet succeeded (I am still actively working on it). Aside of family/vacation and duties of my regular job, I've been busy trying to figure out the historic events and coming up with a rationale for the Pad-MAC-Encrypt approach that I prefer. (and I since realized that history was somewhat different to what I had thought...). Before X-Mas I did a proof-of-concept implementation for myself (based on openssl-1.0.1e) in order to get an idea about implementation complexity, LoC ballpark and potential pitfalls. In the last paragraph of Section 7, the LuckyThirteen paper writes about the OpenSSL patch to make the original Decrypt-unpad-MACverify processing execute in (near) constant time: The OpenSSL patch addressing the attacks in this paper provides an exemplar of how to do this. The complexity of the OpenSSL patch is notable, with around 500 lines of new 'C' code being required. For further discussion and explanation, see http://www.imperialviolet.org/2013/02/04/luckythirteen.html My private OpenSSL PoC included an SCSV for client->server signaling, a ServerHelloExtension for server->client signaling and covered TLSv1.0,v1.1&v1.2 and used an explicit IV for TLSv1.0 and amounted to ~200 LoC, but I continued to call tls1_cbc_remove_padding() to remove the padding. (Covering DTLS and SSLv3 should be less than 100 additional LoC). Implementing this took me 2 hours. Determining that the tunneling of the padding length back through rr->type was causing me interop problems took me 10 minutes once I stepped through the code in the debugger. (but I spend 4 hours trying to understand the interop problem only by source code review before I decided to recompile in debug mode and step through the code in the debugger...). -Martin From agl@google.com Fri Jan 10 07:55:01 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24E921AE089 for ; Fri, 10 Jan 2014 07:55:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 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, RP_MATCHES_RCVD=-0.538, 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 YdKsqMcspzuj for ; Fri, 10 Jan 2014 07:54:59 -0800 (PST) Received: from mail-vb0-x231.google.com (mail-vb0-x231.google.com [IPv6:2607:f8b0:400c:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 4542A1AE0D6 for ; Fri, 10 Jan 2014 07:54:59 -0800 (PST) Received: by mail-vb0-f49.google.com with SMTP id x11so3290884vbb.36 for ; Fri, 10 Jan 2014 07:54:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ZH0mYZkgwdXd2E2VRr6Gnix14q72YqPIgGcY5sBXUI4=; b=l6qqXtVJQh87J7jvhvK/rrHRhxDLyAxn3eY2Jwbb/eETAenZTU8hDOXDOMo3o0uYJ6 wIihAWMSkCJadcyaWMCIf/Ov34+UCj0rX9wQhNyBkNm7ly1ElsXp8QaV7PoYrK4sRu+0 xKo1MHSGbjkWgxw2gP7c8TMIhB+3EuWu/Hgy6DbmJtqAoiFU+HsKDc8hL84SK8qyjH1m TE5dI5nlujzgaDc/12dRQKjKDf+Wr9zPvxosc7cwM2HZXj+pZ/Nzu6D1fuJ4pjEVObNi /TVpzMoNPhDdrt69Gp0U+liBFqeb/XFCL1ctnwdLuJIBE/7g7wgD40eQAJnS21hN0zVX Sudw== 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=ZH0mYZkgwdXd2E2VRr6Gnix14q72YqPIgGcY5sBXUI4=; b=m0Gn21MOmkrQ36m4dUpec5RrK7PkRzjUzuINRTnnPATTRe1Tg47b0fES5FZST6xd5J 9Rb9xsmZ0qurJZdXge5/MsZ8FH7jDaHLiot7hNiqw25SCPandZ5wdrpUY7Tuec8dOb5M hW3L2qGdy8imoJeDaqsS4+WhneDiT6gD+3/stR/1YL039fLhcMCHvefDWDJGrll7vj6v vewUnupahUO+X7Q+qDUMkJoIj39lRoYghC/u5UZRGLz3/knmVLcZ7s4AkrASxeR3QK0z YMNde1mxaPbgM6o2zJ1VX6vQkJomkqY8Q/8Cxkk4TlbatAGs86RmH7fF/sM0/8jVVxr8 O5Bg== X-Gm-Message-State: ALoCoQmX/fTDgQAPzl/lhOPk6VKkxSinECEBPhqFrNW1cPGknuJ3jSvFM4mUyBjxiM/TwbrhBZu4JMNGfhGvB4pl+JznmA6LG6q7l5LP8NUPZmiJKqZdwLgTTMdK5fyyH3XTq5UvQkNebBnqo8BzyZJ2v2CfAq1qf3Z4cMacMMhnmzYk3+3MexMg28QhU0qPVHxCNApoFevO X-Received: by 10.52.166.6 with SMTP id zc6mr7257786vdb.10.1389369289158; Fri, 10 Jan 2014 07:54:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.96.134 with HTTP; Fri, 10 Jan 2014 07:54:29 -0800 (PST) In-Reply-To: <20140110055312.72CF31AB9A@ld9781.wdf.sap.corp> References: <20140110055312.72CF31AB9A@ld9781.wdf.sap.corp> From: Adam Langley Date: Fri, 10 Jan 2014 10:54:29 -0500 Message-ID: To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] Fixing CBC Mode I: GenericBlockCipher construction X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Jan 2014 15:55:01 -0000 On Fri, Jan 10, 2014 at 12:53 AM, Martin Rex wrote: > It seems to me that both of these approaches, when applied to the > SSLv3/TLSv1.0 GenericBlockCipher PDU with "running IV", will pull > the rug from underneath the 1/(n-1) record splitting workaround Yes, if the MAC isn't going to end up as the IV for the next block then 1/n-1 record splitting doesn't work. So unless this extension also enables an explicit IV then it's limited to >= TLS 1.1. That wouldn't be too much of a concern, except for version fallback. /Hopefully/ version fallback will be solved[1] soon. [1] https://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-01 > In the last paragraph of Section 7, the LuckyThirteen paper writes > about the OpenSSL patch to make the original Decrypt-unpad-MACverify > processing execute in (near) constant time: I believe the patch achieves actual constant time processing. (And I measured that with cycle counters.) Although note that upstream OpenSSL reenabled the stitched AES-SHA code and that's not constant-time. > My private OpenSSL PoC included an SCSV for client->server signaling, > a ServerHelloExtension for server->client signaling and covered > TLSv1.0,v1.1&v1.2 and used an explicit IV for TLSv1.0 and amounted > to ~200 LoC, but I continued to call tls1_cbc_remove_padding() > to remove the padding. (Covering DTLS and SSLv3 should be > less than 100 additional LoC). Certainly, almost anything is better than trying to implement the current CBC modes in constant-time. Cheers AGL From watsonbladd@gmail.com Fri Jan 10 08:15:58 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD8A71AE0CB for ; Fri, 10 Jan 2014 08:15:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHfWSa5y9-nS for ; Fri, 10 Jan 2014 08:15:57 -0800 (PST) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id E64131AE0C3 for ; Fri, 10 Jan 2014 08:15:56 -0800 (PST) Received: by mail-we0-f170.google.com with SMTP id u57so4111055wes.15 for ; Fri, 10 Jan 2014 08:15:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fnyxXBaVlozDBkOoqDwemzA69Po9OmUA2nhmRIpruBc=; b=Rby8zqdceJd8ySP64cdjI2qRHfXWFjX/U+CmKF4x8fs1X9LNa/mmgOtLbDNyovBeRo BW6MmacpqoE1Khi58MzHUo3/4Rh265m3NLseCorkdOuqxGoS0+g+rSJV5WXKiH1Z1asu jyd/jOK1c80uKjvYmcf6dG1yjoSAPvTxYOWRbc+ADGGaLshc1sD4F7sFTsNtIaPh6thv 8nsQ11KP1auuBCSpz+w3/iANpztmON9WTyw01p47KNxLmOBPYALq99W5RSJE/PTX3MDB Q4KCFoKrExwB+D71HMzxDOr6W0r/nvL7RCAgRqf16TvGUhXDZc+F9GBuQiv2r3TlRcbX RGxA== MIME-Version: 1.0 X-Received: by 10.194.187.101 with SMTP id fr5mr9497818wjc.76.1389370546382; Fri, 10 Jan 2014 08:15:46 -0800 (PST) Received: by 10.194.242.131 with HTTP; Fri, 10 Jan 2014 08:15:46 -0800 (PST) In-Reply-To: References: <20140110055312.72CF31AB9A@ld9781.wdf.sap.corp> Date: Fri, 10 Jan 2014 08:15:46 -0800 Message-ID: From: Watson Ladd To: Adam Langley Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] Fixing CBC Mode I: GenericBlockCipher construction X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Jan 2014 16:15:59 -0000 On Fri, Jan 10, 2014 at 7:54 AM, Adam Langley wrote: > On Fri, Jan 10, 2014 at 12:53 AM, Martin Rex wrote: >> It seems to me that both of these approaches, when applied to the >> SSLv3/TLSv1.0 GenericBlockCipher PDU with "running IV", will pull >> the rug from underneath the 1/(n-1) record splitting workaround > > Yes, if the MAC isn't going to end up as the IV for the next block > then 1/n-1 record splitting doesn't work. > > So unless this extension also enables an explicit IV then it's limited > to >= TLS 1.1. I'm very surprised at the both of you. Because we will have ciphertext integrity, CBC decryption oracles aren't a consideration. The remaining attack on deterministic IVs is guessing low entropy blocks by injecting cleverly chosen blocks. But 1/(n-1) record splitting will prevent this attack by restricting the control over the next IV to be negligible. Sincerely, Watson Ladd > > > > > Cheers > > AGL > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From kaie@kuix.de Fri Jan 10 08:39:21 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7876F1ACCE2 for ; Fri, 10 Jan 2014 08:39:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XdjpPBjybUpq for ; Fri, 10 Jan 2014 08:39:19 -0800 (PST) Received: from s15531995.onlinehome-server.info (s15531995.onlinehome-server.info [82.165.38.173]) by ietfa.amsl.com (Postfix) with ESMTP id C37561AE0D6 for ; Fri, 10 Jan 2014 08:39:18 -0800 (PST) Received: from [192.168.2.253] (p4FF357EF.dip0.t-ipconnect.de [79.243.87.239]) by s15531995.onlinehome-server.info (Postfix) with ESMTPSA id A2B13428906C for ; Fri, 10 Jan 2014 17:39:07 +0100 (CET) Message-ID: <1389371947.30279.56.camel@lapkaie> From: Kai Engert To: tls@ietf.org Date: Fri, 10 Jan 2014 17:39:07 +0100 Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.5 (3.8.5-2.fc19) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: [TLS] Ideas for TLS 1.3: Server key continuity and certificate reporting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Jan 2014 16:39:21 -0000 I would like to suggest a potential improvement for the TLS protocol. The intention is to make it more difficult for an adversary to act as a MITM, by using the abilities of a CA to obtain a valid certificate, that isn't controlled by the real owner of a TLS server. This message presents the ideas that I had today as a draft. The proposed enhancement consists of two parts. (1) TLS Clients should cache the most recently seen and sucessfully validated (accepted) server certificate for each hostname. When a client connects to the server again at a later time, and notices that the server sends a certificate that is different from the one that has been cached, and in addition the new certificate has been signed by a different CA certificate, then the client should report the previously cached certificate back to the server, using a new TLS protocol message. This way, the owner of a TLS server could learn if any users have visited a MITM server that impersonated the server using certificates that aren't controlled by the real owner of the domain. This could be automated on the server side. A list of previously used and valid certificates could be installed on the server, and any reports with known good certificates could be automatically ignored. Also, in order to ignore any certificates that belong to closed environment CAs, the server could ignore reports of certificates that cannot be validated using a chain to known public CAs. Should a server operator learn that a CA has falsely issued a certificate, the certificate can be publicly reported and a public investigation could be started. This proposal is based on the idea that temporary and targeted attacks to users are possible, and attempt a way to detect them. If it's correct to assume that a non-zero percentage of all targeted attacks are temporary, then attacks could automatically become known once the temporary attack is over and the client connects to the real destination server again. While this reporting cannot immediately protect TLS clients from being tricked into accepting a falsely issued certificate, it could at least help to detect the CAs that are involved in enabling such targeted attacks. Such public knowledge could be helpful to prevent such attacks in the future, by removing such CAs from the embedded trust lists used by TLS client software. (2) TLS clients should require key continuity. TLS Clients should cache the most recently seen and sucessfully validated (accepted) server certificate for each hostname. When a client connects to the server again at a later time, and notices that the server sends a certificate that is different from the one that has been cached, and in addition the new certificate has been signed by a different CA certificate, but the previous certificate hasn't expired yet, then the client should perform a key continuity check by requiring a proof of ownership of the previous key. The idea is, if a TLS server administrator has chosen to switch the server configuration to a new certificate, the server administrator can be assumed to still be in possession of the private key that was associated to the previous certificate. How could the proof-of-ownership of the previous key look like? Maybe it's better to talk about proof-of-legitimate-transition. A data format could be defined, which consists of a simple data structure that contains the new certificate, plus a digital signature that was created by using the private key that belongs to the previous certificate. Since a server could have used multiple certificates in the past that haven't yet expired, the server should be able to store multiple proofs-of-legitimate-transition. The server would send the correct one to the client, based on the certificate the TLS client reports as most recently seen. Using this strategy, it would no longer be sufficient to attack any other CA (a CA that is different from the one used officially by the server operator), as the attacker would require to obtain the server's current private key, too. I can think of a scenario where creating the proof wouldn't be possible, for example, if domain ownership has changed. In that case, the CA that had issued the previous certificate should revoke the certificate. The new owner of the domain should be able to convince the CA to revoke the previous certificate, by presenting current domain ownership documents. Once this has been done, an OCSP response (or a CRL) could be obtained from the previous CA that proofs revocation. If a TLS client reported the mismatching certificate to the server, the TLS server could staple the OCSP message with the revoked status into the TLS handshake, using a new TLS message. This could be allowed as a sufficient proof-of-legitimate-transition. Clients should accept an old OCSP message of status revoked (regardless of its age), therefore allowing the TLS server to cache this proof of transition forever. I hope these ideas make some sense. I'm sure there are edge case which I haven't covered yet. I'm looking forward to your feedback and hope that we might be able to find incremental tweaks to these ideas to make them work in general in a future version of TLS, such as TLS 1.3. Best Regards Kai From agl@google.com Fri Jan 10 08:57:51 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC1831AE117 for ; Fri, 10 Jan 2014 08:57:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 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, RP_MATCHES_RCVD=-0.538, 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 WyzPmC9fabHI for ; Fri, 10 Jan 2014 08:57:50 -0800 (PST) Received: from mail-vb0-x231.google.com (mail-vb0-x231.google.com [IPv6:2607:f8b0:400c:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 672421AE112 for ; Fri, 10 Jan 2014 08:57:50 -0800 (PST) Received: by mail-vb0-f49.google.com with SMTP id x11so3345397vbb.36 for ; Fri, 10 Jan 2014 08:57:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=J3gUi8Tw9NIYwC8GpxtuafuGDlqbj01BzwleQF0lFLU=; b=Gsskfs6K5ecz+PN1OMsSheOyY0dgzY6N0vCDkzxQPOv32XHSDGMmnM9U+C0Rm0qOVy d+HFWWZT/EzT6m6TnU3iYYG5t65BthcTwCEiKa2S5hoJ3Vwz2SbG3/Ki7xsYXjfBqrbU O+5SndlFeAL5Nti3tlrCCH8GCj2rBFcjcrcNdpUO0fvF8aW/LC0Y9xxChECZXhbe6+Bg KffzC5vVyXTycPH6QlG4XEFS/8e+R079cnGOdWnGlJ2xTKAmvwJ9prQf7eaWgOy0l3Fh v2i1mas2HgHdr34t/0v7CS334EDAm6WA/aiCLkuQVuqApRGGQj2g5HfHWldJMI018F8G Y7wQ== 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=J3gUi8Tw9NIYwC8GpxtuafuGDlqbj01BzwleQF0lFLU=; b=dbq3+csrlkuLOST3hnlMvWULjmmCOQ/zR8URfIyC4WdXnyeOqKqwPAbMbm+Y6wvz+M 61m0UqQI26u91KYHNGFxf89MnXqnm/XWsMW03G0Txt+NK78lMyjoEL3UItCIoSt+sP21 ejmKv+UoroMVfVOdmjlBAbeTxJPBwdhD4GOAaGtSPS9ZTDMzLH1yS14ZnVZwlDsdyOCo MivKGtwmqmqfTEAqsXDw+sItu7w0Yu5yJYx93hyUjz1YMNT2KgBwEdKItdxqEbSlkf0A o89u3sW4EBSsWu1iEGvdHP+JRYfL5KFVtBCPAkdq78T4KWgYeqxAdMn1E3T79XBmLZZJ 11gQ== X-Gm-Message-State: ALoCoQnTMoZX+u80146NvkA3k+KSoLMUJuBynfctNt+pxt1/bHR5eEtcla3OI7kYBCMH3CXLiT9PBnXs0UNXWhPJZCHe9yb81az/2I6m4cY817632UcEVqXvNDKgHZIdYv8SnsT7ZaYtXI9FcPGtwGTL/vzyWv+WnenWGpWVkOvPZITH1mXyBD0VYJc616wGeBd8mkpv2LVI X-Received: by 10.58.196.211 with SMTP id io19mr8699081vec.9.1389373060226; Fri, 10 Jan 2014 08:57:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.96.134 with HTTP; Fri, 10 Jan 2014 08:57:20 -0800 (PST) In-Reply-To: References: <20140110055312.72CF31AB9A@ld9781.wdf.sap.corp> From: Adam Langley Date: Fri, 10 Jan 2014 11:57:20 -0500 Message-ID: To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] Fixing CBC Mode I: GenericBlockCipher construction X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Jan 2014 16:57:52 -0000 On Fri, Jan 10, 2014 at 11:15 AM, Watson Ladd wrote: > I'm very surprised at the both of you. Because we will have ciphertext > integrity, > CBC decryption oracles aren't a consideration. Sure, but 1/n-1 was never about decryption oracles. > The remaining attack on > deterministic IVs is guessing > low entropy blocks by injecting cleverly chosen blocks. But 1/(n-1) > record splitting will prevent this attack > by restricting the control over the next IV to be negligible. This is using 1/n-1 record splitting in a different way and you appear to be confident that it's safe. It's certainly not as obviously safe as using a random IV for CBC mode. I agree that it's not obvious that anything bad can be done because the attacker doesn't have enough control over the contents of the first block. But we know that CBC mode *should* have random IVs and, if we're changing code anyway, I think you're being much too accepting of throwing together a new construction rather than doing it right. It would make me sad if we're not going to say that the extension negotiates explicit IVs *and* not say that it needs TLS 1.1. TLS 1.1 just isn't that hard to implement and we might be able to securely negotiate it soon. Cheers AGL From ekr@rtfm.com Fri Jan 10 09:07:52 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A34231AE0EC for ; Fri, 10 Jan 2014 09:07:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTuawWPLcxcM for ; Fri, 10 Jan 2014 09:07:51 -0800 (PST) Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4D01AE0D3 for ; Fri, 10 Jan 2014 09:07:51 -0800 (PST) Received: by mail-we0-f170.google.com with SMTP id u57so4170024wes.1 for ; Fri, 10 Jan 2014 09:07:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=H6hV5o8+Ec2/Fab0XEvdrZY7PgqZnPbxvhfBUxQhCnU=; b=Uq62UXCXGLfAhW0IvgUn5icIl/+C4Tl8X/Cgkd57nGqLcBBffwOva+T7xHCLsug31g wBoESA0+nJ+emYDvH4RTjZvjKp3JOenq03qAGh73LIsZbyXkMIomr0r0Ft8e7eexVF9Y j0Ccuadj4BsPU4EzqrxLczJX51PvjTUZn/Hh5d9ZgDfsyBqvsBMfZvp95OyAtRTVYG3d 9AIVbo4ez4EwxIisI5OFc6QkvK7DTVccVvFBYPfV/zwkgL5UarPwchoexNetwiyNB+0F tQFATDE1crFzdDHuQP8i12mungX+QECIaE32HbIVc2ku1vKyT2/2t60qNo4YH6JTZywQ ZhsQ== X-Gm-Message-State: ALoCoQkPJbLvpbzDx6DMjXWMYQgqUZugS/3OZGaYrTQiqbX6uFJlokDtdvOrUf03gkW9NbOqZFhI X-Received: by 10.180.12.115 with SMTP id x19mr3659285wib.49.1389373660524; Fri, 10 Jan 2014 09:07:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.54.194 with HTTP; Fri, 10 Jan 2014 09:07:00 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: References: <20140110055312.72CF31AB9A@ld9781.wdf.sap.corp> From: Eric Rescorla Date: Fri, 10 Jan 2014 09:07:00 -0800 Message-ID: To: Adam Langley Content-Type: text/plain; charset=ISO-8859-1 Cc: "tls@ietf.org" Subject: Re: [TLS] Fixing CBC Mode I: GenericBlockCipher construction X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Jan 2014 17:07:52 -0000 On Fri, Jan 10, 2014 at 8:57 AM, Adam Langley wrote: > It > would make me sad if we're not going to say that the extension > negotiates explicit IVs *and* not say that it needs TLS 1.1. TLS 1.1 > just isn't that hard to implement and we might be able to securely > negotiate it soon. Yes, that seems likely. Indeed, unless I'm missing something, the same draft that we need to negotiate TLS 1.1 securely is also what we need to negotiate this draft securely. -Ekr From fabrice.gautier@gmail.com Fri Jan 10 11:17:23 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD0E71AE140 for ; Fri, 10 Jan 2014 11:17:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KsjP1JvB5Spu for ; Fri, 10 Jan 2014 11:17:22 -0800 (PST) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id AAD4D1AE0CC for ; Fri, 10 Jan 2014 11:17:21 -0800 (PST) Received: by mail-we0-f170.google.com with SMTP id u57so4272503wes.29 for ; Fri, 10 Jan 2014 11:17:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=q9UXJxOoXR44TO1eVbuG7TfBmooF86oF9y0s8ycee5I=; b=sHwpfAQFsm2DL/dNGcHbjeUV7q7BvOf1751smyhPYubw/WUK2JB6Ks7t8p4yXGLUnv v9H4dwI6DKHxXsk2jCZnTH94L0WaSErNiEu2DThWAh4/QHISDDb2DI1ftZvTg9st+t9d GOodYgYwb7pJZ+aP3qozEOoJmCH18exXzs8LdDOdOOdcH+X3njjvpuIdXK0oI6BTQXzV 1/IeEVf4Jx0R0fo351MtahYldeKXYLryyzmtUSMkur5btKETqhEsOApIrQWvbjzcy8f2 QR0WySqVLEG1ArK8s4wEfSpT41CVDr30CocspKownWbjgwyspTD1fdus1rRtDDG/5AxE GJCg== X-Received: by 10.194.63.134 with SMTP id g6mr10023094wjs.46.1389381431162; Fri, 10 Jan 2014 11:17:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.44.131 with HTTP; Fri, 10 Jan 2014 11:16:51 -0800 (PST) From: Fabrice Gautier Date: Fri, 10 Jan 2014 11:16:51 -0800 Message-ID: To: "" Content-Type: text/plain; charset=ISO-8859-1 Subject: [TLS] NPN, ALPN and the case of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Jan 2014 19:17:24 -0000 Hi, When reading both NPN and ALPN drafts, I notice they both have this paragraph: 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. However, only NPN has that one, immediately following: For the same reasons, after a handshake has been performed for a given connection, renegotiations on the same connection MUST NOT include the "next_protocol_negotiation" extension. On the other hand, ALPN has this one a little further down: The protocol identified in the "application_layer_protocol_negotiation" extension type in the ServerHello SHALL be definitive for the connection. The server SHALL NOT respond with a selected protocol and subsequently use a different protocol for application data exchange. The question is: Should/can NPN/APLN extensions be sent/processed during a renegotiation handshake ? So far I'm only confidently interpreting the above as: 0) If NPN protocol was successfully selected during a handshake, the client should not send a NPN extension in its next client hello. I'm unsure of those other details though: 1) If client sent an NPN extension in a ClientHello and did not get back an NPN extension in the ServerHello, should/may the NPN client try the NPN extension again in a re-handshake? I'm assuming it should not. But somebody might come up with a reason for not wanting to provide the supported protocols in the clear. Although one would argue that if Application Data is sent between the two handshake, then a protocol is selected and you should not be able to change it with NPN extensions, so the client must not send the NPN extension in the renegotiation if they already received or sent some application data. 2) If a client sent an ALPN extension in the first ClientHello, can it send it again in a further negotiation ? I'm assuming it may, unless protocol was selected explicitly with a ALPN ServerHello extension, or implicitly by sending/receiving some application data. 3) If a client didn't send an NPN extension in the first ClientHello, may it send it in the next handshake ? I'm assuming it should not. and I don't really see a privacy angle in that case. 4) If a client didn't send an ALPN extension in the first ClientHello, may it send it in the next handshake ? I'm assuming yes. This is useful in case you want to hide the protocols supported and selected in a renegotiation (as indicated in Section 4 of ALPN draft) Although again, if a protocol was implicitly selected by sending/receiving data, it probably should not. Are my assumptions mostly correct ? Thanks -- Fabrice From akr@akr.io Fri Jan 10 11:19:29 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 450F81AE0E2 for ; Fri, 10 Jan 2014 11:19:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGYwKjTLmmgW for ; Fri, 10 Jan 2014 11:19:26 -0800 (PST) Received: from entima.net (entima.net [78.129.143.175]) by ietfa.amsl.com (Postfix) with ESMTP id 2786A1AE0CC for ; Fri, 10 Jan 2014 11:19:26 -0800 (PST) Received: from [10.10.42.10] (cpc5-derb12-2-0-cust796.8-3.cable.virginm.net [82.31.91.29]) by entima.net (Postfix) with ESMTPSA id 5DD7660453 for ; Fri, 10 Jan 2014 19:19:15 +0000 (GMT) Message-ID: <52D047C3.20208@akr.io> Date: Fri, 10 Jan 2014 19:19:31 +0000 From: Alyssa Rowan MIME-Version: 1.0 To: tls@ietf.org References: <1389371947.30279.56.camel@lapkaie> In-Reply-To: <1389371947.30279.56.camel@lapkaie> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [TLS] Ideas for TLS 1.3: Server key continuity and certificate reporting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Jan 2014 19:19:29 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 10/01/2014 16:39, Kai Engert wrote: > (1) […IF (new_certificate) THEN send_warning(new_certificate)…] I applaud the motive, but I'm not sure about the delivery. Three potential problems I can see with an in-band new-certificate canary. Firstly, it relies on TLS clients caching certificates, like SSH clients; they have not traditionally done this. I'll let those who write clients chime in on why they may or may not want to. Secondly, if the server does change certificate legitimately, it's going to get a lot of these warnings from everyone. That could get annoying. But thirdly - and most importantly - if an adversary is in a position to be a man-in-the-middle and actually use their fake CA certificate, they're also in a position to read your draft, know exactly what the new-certificate canary looks like - and make sure the server never gets it by filtering it out or injecting a RST to the server. And that is probably exactly what they'll do, because they do it already (“QUANTUMRESET”) and it's a very, very easy attack; much easier than getting a forged certificate. Sorry, I just don't think it would work. An out-of-band approach would be harder to disrupt and more successful, like the SSL Observatory type things we already have, and Certificate Transparency public audit log rules for CAs (which I personally think should be strictly enforced as a minimum bar for any CA remaining in browsers, although some CAs are apparently reluctant to do this, so that may not be too easily forthcoming in the immediate future). I think some browsers might already do this: Chrome, perhaps? > (2) TLS clients should require key continuity. As above - requires caching - but I'll let those who write clients chime in on this one. Would need a "I'm Z, old key X, new key Y" statement signed by old key X, yes. Obvious edge cases that leap out at me:— • Old key X expired first. Oh-so-common. - Do we still trust its assertion? • We don't have old key X. As you say, needs stapling of revocation. - But how many historical keys are we going to have to staple? - What if this domain changes hands a lot? • New key Y has a problem, e.g. isn't on the OCSP lists yet. • Old key X is revoked, but OCSP is unreachable and not stapled. • Z is large, does DNS round-robin or anycast and has huge load balancers all over the world with different keys [Xâ‚, Xâ‚‚, Xâ‚, X₄…]. - Forcing them to have the same key seems even _worse_. Now someone can swipe the key from any load balancer and look like every one. Needs some thinking through. It may or may not be a good idea, but there are certainly a few potential complications. - -- /akr -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJS0EfCAAoJEOyEjtkWi2t6hF4P/i0SWwfH8zz/h9XvhX/so289 bVTQNxJ3h6Qi1BnTprbw1+ReF8dGkq4gtegkTKZgFZxILNlJ32TfTq3TpuMxZSeZ rnKHe8qpvSV0Z00q+35e5EDJS9O0tIiA2MdX2O78czDYmXIEpeM+7PjrxeKbYGEF roRpiQ4EsApJKySL8tKl6mrNK92aSmlD4aE9tZ/x/JpKwueOvZEi5XPug3IKYVY1 KiuHZGv5YDTw172OxqagWKKp9gVSgPfEYMmC2K9NssDRYZvvysmcJo+vXMflw6GR AAubPpgVguB10Z0VugXgA90rlY6U57heQR06HQQWX0LFDwcSU8P3z2gME3kVq1dZ Ox7p/8S5LgcRzCeTeSlkwV38Ho9murxsSNrFXUyfxCsmBpRSyw5e6fmspBxYdO+b 6mMs6Yw+6FoPhfh/ygUoCYDtOQoHLgGP6Qrj0Zv61nNBfZyJqEfQcJ0tTGp6q0dK 7LXKx1IZEBNdBvWK5WiIV55FAozQeHvekMi2SsshUihvLoTW/kOSCTripfvgbIJ/ teR7s0Zugar0lWCNlL+JbXWhmdwxmb/5FzITY2mFu7GfHQBlNvdSdIsHMBg0mHf6 tFUfJXBD9YnOvz2aFIgGMvfUktcc2dc+nQkAMl7eG0V0IXK1LP5CvHBcuTY6ElRd o/PoL943EBU7orhZ5t6/ =ePZK -----END PGP SIGNATURE----- From kaie@kuix.de Fri Jan 10 11:51:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABD8F1AE1A5 for ; Fri, 10 Jan 2014 11:51:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFvpAIvEpYLK for ; Fri, 10 Jan 2014 11:51:35 -0800 (PST) Received: from s15531995.onlinehome-server.info (s15531995.onlinehome-server.info [82.165.38.173]) by ietfa.amsl.com (Postfix) with ESMTP id 5CDF01AE1C9 for ; Fri, 10 Jan 2014 11:51:33 -0800 (PST) Received: from [192.168.2.253] (p4FF357EF.dip0.t-ipconnect.de [79.243.87.239]) by s15531995.onlinehome-server.info (Postfix) with ESMTPSA id E7FA4428906E; Fri, 10 Jan 2014 20:51:22 +0100 (CET) Message-ID: <1389383482.30279.78.camel@lapkaie> From: Kai Engert To: Alyssa Rowan Date: Fri, 10 Jan 2014 20:51:22 +0100 In-Reply-To: <52D047C3.20208@akr.io> References: <1389371947.30279.56.camel@lapkaie> <52D047C3.20208@akr.io> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.5 (3.8.5-2.fc19) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Cc: tls@ietf.org Subject: Re: [TLS] Ideas for TLS 1.3: Server key continuity and certificate reporting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Jan 2014 19:51:37 -0000 On Fr, 2014-01-10 at 19:19 +0000, Alyssa Rowan wrote: > Firstly, it relies on TLS clients caching certificates, like SSH > clients; they have not traditionally done this. I'll let those who > write clients chime in on why they may or may not want to. Thanks for considering the client side, I'll add some thoughts as well. I agree there might be clients that wouldn't want to implement a cache, because they don't save a state. Or they might not want to update a cache when operating in a mode that intends to avoid local caching ("private browsing mode"). I think that's fine. Even if the most popular TLS clients, like browsers, e-mail agents and vpn clients were the only TLS clients that implemented the canary reporting, I believe it would still be beneficial. (Browsers in a "private browsing mode" could recommend to the user that they are operating with reduced web security checking. OTOH, if a user runs in private browsing mode, but a previous server certificate has already been cached from regular browsing, it could be considered safe to update the local cache, as it wouldn't creating additional leaks). > Secondly, if the server does change certificate legitimately, it's > going to get a lot of these warnings from everyone. That could get > annoying. That's why I'm suggesting that server software should have a configuration option, which allows to configure a list of allowed certificates. That list would contain the previously used certificates for the given hostname. The server could ignore any reports with those certificates. > But thirdly - and most importantly - if an adversary is in a position > to be a man-in-the-middle and actually use their fake CA certificate, > they're also in a position to read your draft, know exactly what the > new-certificate canary looks like - and make sure the server never > gets it by filtering it out or injecting a RST to the server. Yes, the canary reporting cannot prevent an attack. But I assume that most attacks are temporary. I assume that eventually most clients will be able to use a direct route to the real destination, without being attacked. For example, after they are back from travelling or from using a WiFi hotspot, or if they are able to use a VPN occassionally. Or it they connect to the neighour's wifi, instead of using their own fixed DSL line which has been hacked. Or if they switch between a DSL line with an active MITM and a 3G connection that is free of MITM. > And that > is probably exactly what they'll do, because they do it already > (“QUANTUMRESET”) and it's a very, very easy attack; much easier than > getting a forged certificate. > > Sorry, I just don't think it would work. > > An out-of-band approach would be harder to disrupt and more > successful, like the SSL Observatory type things we already have, and > Certificate Transparency public audit log rules for CAs (which I > personally think should be strictly enforced as a minimum bar for any > CA remaining in browsers, although some CAs are apparently reluctant > to do this, so that may not be too easily forthcoming in the immediate > future). > > I think some browsers might already do this: Chrome, perhaps? > > > (2) TLS clients should require key continuity. > > As above - requires caching - but I'll let those who write clients > chime in on this one. > > Would need a "I'm Z, old key X, new key Y" statement signed by old key > X, yes. > > Obvious edge cases that leap out at me:— > • Old key X expired first. Oh-so-common. > - Do we still trust its assertion? > • We don't have old key X. As you say, needs stapling of revocation. > - But how many historical keys are we going to have to staple? > - What if this domain changes hands a lot? > • New key Y has a problem, e.g. isn't on the OCSP lists yet. > • Old key X is revoked, but OCSP is unreachable and not stapled. > • Z is large, does DNS round-robin or anycast and has huge load > balancers all over the world with different keys [Xâ‚, Xâ‚‚, Xâ‚, X₄…]. > - Forcing them to have the same key seems even _worse_. > Now someone can swipe the key from any load balancer and look like > every one. > > Needs some thinking through. It may or may not be a good idea, but > there are certainly a few potential complications. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From kaie@kuix.de Fri Jan 10 11:54:59 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD3AA1AE1C1 for ; Fri, 10 Jan 2014 11:54:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOsTVC406PP7 for ; Fri, 10 Jan 2014 11:54:59 -0800 (PST) Received: from s15531995.onlinehome-server.info (s15531995.onlinehome-server.info [IPv6:2001:8d8:910:de00::2f:a36d]) by ietfa.amsl.com (Postfix) with ESMTP id 191761AE1BC for ; Fri, 10 Jan 2014 11:54:59 -0800 (PST) Received: from [192.168.2.253] (p4FF357EF.dip0.t-ipconnect.de [79.243.87.239]) by s15531995.onlinehome-server.info (Postfix) with ESMTPSA id 7E655428906E; Fri, 10 Jan 2014 20:54:48 +0100 (CET) Message-ID: <1389383687.13026.1.camel@lapkaie> From: Kai Engert To: Alyssa Rowan Date: Fri, 10 Jan 2014 20:54:47 +0100 In-Reply-To: <1389383482.30279.78.camel@lapkaie> References: <1389371947.30279.56.camel@lapkaie> <52D047C3.20208@akr.io> <1389383482.30279.78.camel@lapkaie> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.5 (3.8.5-2.fc19) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Ideas for TLS 1.3: Server key continuity and certificate reporting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Jan 2014 19:55:00 -0000 Sorry, I accidentally hit a key combination that sent the message, prior to me finishing the message. I need to continue the message and address the remaining parts of your message. Regards Kai From paul.hoffman@vpnc.org Fri Jan 10 12:12:58 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47CCB1AE10C for ; Fri, 10 Jan 2014 12:12:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id efVfcbZ30NM0 for ; Fri, 10 Jan 2014 12:12:57 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7C9631AE0BF for ; Fri, 10 Jan 2014 12:12:57 -0800 (PST) Received: from [10.20.30.90] (50-1-51-230.dsl.dynamic.fusionbroadband.com [50.1.51.230]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id s0AJqmqw011007 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 10 Jan 2014 12:52:49 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-230.dsl.dynamic.fusionbroadband.com [50.1.51.230] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Paul Hoffman In-Reply-To: <1389371947.30279.56.camel@lapkaie> Date: Fri, 10 Jan 2014 12:12:38 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <1DEAF365-97D4-493B-83C1-270AA9CD5670@vpnc.org> References: <1389371947.30279.56.camel@lapkaie> To: Kai Engert X-Mailer: Apple Mail (2.1827) Cc: "" Subject: Re: [TLS] Ideas for TLS 1.3: Server key continuity and certificate reporting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Jan 2014 20:12:58 -0000 These ideas (and the followups from Alyssa) are interesting, but I = suspect that they belong in the websec WG instead of here, unless you = truly mean them to apply to every application that uses TLS. I don't see = how they would work, for instance, with SMTP servers that do TLS. --Paul Hoffman= From kaie@kuix.de Fri Jan 10 12:28:53 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D40851AE0FB for ; Fri, 10 Jan 2014 12:28:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N9kBy6oZ_rwL for ; Fri, 10 Jan 2014 12:28:52 -0800 (PST) Received: from s15531995.onlinehome-server.info (s15531995.onlinehome-server.info [IPv6:2001:8d8:910:de00::2f:a36d]) by ietfa.amsl.com (Postfix) with ESMTP id 857E41AE02E for ; Fri, 10 Jan 2014 12:28:51 -0800 (PST) Received: from [192.168.2.253] (p4FF357EF.dip0.t-ipconnect.de [79.243.87.239]) by s15531995.onlinehome-server.info (Postfix) with ESMTPSA id 997F6428908E; Fri, 10 Jan 2014 21:28:40 +0100 (CET) Message-ID: <1389385719.13026.20.camel@lapkaie> From: Kai Engert To: tls@ietf.org, tls@ietf.org Date: Fri, 10 Jan 2014 21:28:39 +0100 In-Reply-To: <1DEAF365-97D4-493B-83C1-270AA9CD5670@vpnc.org> References: <1389371947.30279.56.camel@lapkaie> <1DEAF365-97D4-493B-83C1-270AA9CD5670@vpnc.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.5 (3.8.5-2.fc19) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Ideas for TLS 1.3: Server key continuity and certificate reporting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Jan 2014 20:28:54 -0000 On Fr, 2014-01-10 at 12:12 -0800, Paul Hoffman wrote: > These ideas (and the followups from Alyssa) are interesting, but I > suspect that they belong in the websec WG instead of here, unless you > truly mean them to apply to every application that uses TLS. I don't > see how they would work, for instance, with SMTP servers that do TLS. I'm motiviated to find ways to makes these ideas work with any TLS connection, completely independent of the encapsulated application protocol. I think a SMTP/TLS client could equally cache the previous cert and potentially report it to the TLS server on a subsequent connection. Where do you see differences that would cause it not to work with protocols other than http? Regards Kai From Andrei.Popov@microsoft.com Fri Jan 10 13:09:04 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E61F1AE154 for ; Fri, 10 Jan 2014 13:09:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 O5Bgov_BeLUz for ; Fri, 10 Jan 2014 13:09:01 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0239.outbound.protection.outlook.com [207.46.163.239]) by ietfa.amsl.com (Postfix) with ESMTP id 01D151AE131 for ; Fri, 10 Jan 2014 13:09:00 -0800 (PST) Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BL2PR03MB417.namprd03.prod.outlook.com (10.141.92.12) with Microsoft SMTP Server (TLS) id 15.0.847.13; Fri, 10 Jan 2014 21:08:49 +0000 Received: from BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) by BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) with mapi id 15.00.0847.008; Fri, 10 Jan 2014 21:08:49 +0000 From: Andrei Popov To: Fabrice Gautier , "" Thread-Topic: [TLS] NPN, ALPN and the case of renegotiation Thread-Index: AQHPDjiX2x1mV/7ikkKi9AvO9cv7ppp+caRQ Date: Fri, 10 Jan 2014 21:08:48 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::3] x-forefront-prvs: 00872B689F x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(189002)(199002)(13464003)(377454003)(15975445006)(19580405001)(53806001)(83322001)(74876001)(46102001)(51856001)(19580395003)(80976001)(81686001)(81342001)(47736001)(47976001)(50986001)(49866001)(85306002)(81542001)(77982001)(59766001)(79102001)(81816001)(69226001)(56776001)(4396001)(76786001)(76576001)(92566001)(87936001)(76796001)(93136001)(87266001)(33646001)(2656002)(83072002)(85852003)(56816005)(74706001)(90146001)(54356001)(63696002)(76482001)(74316001)(74366001)(31966008)(54316002)(80022001)(74502001)(47446002)(74662001)(65816001)(24736002)(3826001)(491001); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR03MB417; H:BL2PR03MB419.namprd03.prod.outlook.com; CLIP:2001:4898:80e8:ed31::3; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [TLS] NPN, ALPN and the case of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Jan 2014 21:09:04 -0000 Hi Fabrice, I cannot speak to the design of NPN, but will answer the ALPN questions: 2) If a client sent an ALPN extension in the first ClientHello, can it send= it again in a further negotiation ? Yes, the client\server can renegotiate the application protocol at any time= . 4) If a client didn't send an ALPN extension in the first ClientHello, may= it send it in the next handshake ? Yes, this can be used e.g. to make the application protocol negotiation con= fidential. Cheers, Andrei -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Fabrice Gautier Sent: Friday, January 10, 2014 11:17 AM To: Subject: [TLS] NPN, ALPN and the case of renegotiation Hi, When reading both NPN and ALPN drafts, I notice they both have this paragr= aph: 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. However, only NPN has that one, immediately following: For the same reasons, after a handshake has been performed for a given connection, renegotiations on the same connection MUST NOT include the "next_protocol_negotiation" extension. On the other hand, ALPN has this one a little further down: The protocol identified in the "application_layer_protocol_negotiation" extension type in the ServerHello SHALL be definitive for the connection. The server SHALL NOT respond with a selected protocol and subsequently use a different protocol for application data exchange. The question is: Should/can NPN/APLN extensions be sent/processed during a = renegotiation handshake ? So far I'm only confidently interpreting the above as: 0) If NPN protocol was successfully selected during a handshake, the client= should not send a NPN extension in its next client hello. I'm unsure of those other details though: 1) If client sent an NPN extension in a ClientHello and did not get back an= NPN extension in the ServerHello, should/may the NPN client try the NPN e= xtension again in a re-handshake? I'm assuming it should not. But somebody might come up with a reason for not wanting to provide the sup= ported protocols in the clear. Although one would argue that if Application= Data is sent between the two handshake, then a protocol is selected and yo= u should not be able to change it with NPN extensions, so the client must n= ot send the NPN extension in the renegotiation if they already received or = sent some application data. 2) If a client sent an ALPN extension in the first ClientHello, can it send= it again in a further negotiation ? I'm assuming it may, unless protocol was selected explicitly with a ALPN Se= rverHello extension, or implicitly by sending/receiving some application da= ta. 3) If a client didn't send an NPN extension in the first ClientHello, may i= t send it in the next handshake ? I'm assuming it should not. and I don't really see a privacy angle in that = case. 4) If a client didn't send an ALPN extension in the first ClientHello, may= it send it in the next handshake ? I'm assuming yes. This is useful in case you want to hide the protocols sup= ported and selected in a renegotiation (as indicated in Section 4 of ALPN d= raft) Although again, if a protocol was implicitly selected by sending/rece= iving data, it probably should not. Are my assumptions mostly correct ? Thanks -- Fabrice _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From trevp@trevp.net Fri Jan 10 13:18:22 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 730C51AE175 for ; Fri, 10 Jan 2014 13:18:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-tmS6VDN_gW for ; Fri, 10 Jan 2014 13:18:20 -0800 (PST) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) by ietfa.amsl.com (Postfix) with ESMTP id EDD791AE12A for ; Fri, 10 Jan 2014 13:18:19 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id a1so2368021wgh.16 for ; Fri, 10 Jan 2014 13:18:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=hoeXzWy192/HeFGnuF3qoKRH0V1mxdL5//lGsWUrYc4=; b=FL0e5zGrhEkooCFNilujU6rh6laKD/ZuJXKLB2khlWKSLQhA4mNNwI1QJZG/yEGEPc P/zH3W97OwwwVyQj33L7YtyUD1iJe/8cRVHHTatGVjaXaswpuShyldmGEEah4al6JXUw o2J7e5SiWyiiCWaaRKsheQexIVV5GkGm2RUEKTioCHJthig9bH2uBjTQ1Hm5YInBex0N AjtsGtNzKXYFI6rIMdUbReT3tARVOesrLq4L/UlSgtEtrXcSao5VI7nkfb9I6ei1Hd1y W1lK1SH+IdhunFHaCy4RXIsa+FI62yvnAXSXtnnuiH/jjpWrHrmCydvpJYKhlw4yL4Zr mPvA== X-Gm-Message-State: ALoCoQlCZ1BwyTkYic00RTKAcPHf40cR13ghB9VQXKzDW4DZIhtnwIXrOR4FAJPOtiF5Qzs0KmjT MIME-Version: 1.0 X-Received: by 10.194.78.210 with SMTP id d18mr10698645wjx.27.1389388689433; Fri, 10 Jan 2014 13:18:09 -0800 (PST) Received: by 10.216.214.134 with HTTP; Fri, 10 Jan 2014 13:18:09 -0800 (PST) X-Originating-IP: [199.83.223.81] In-Reply-To: <1389385719.13026.20.camel@lapkaie> References: <1389371947.30279.56.camel@lapkaie> <1DEAF365-97D4-493B-83C1-270AA9CD5670@vpnc.org> <1389385719.13026.20.camel@lapkaie> Date: Fri, 10 Jan 2014 13:18:09 -0800 Message-ID: From: Trevor Perrin To: Kai Engert Content-Type: text/plain; charset=ISO-8859-1 Cc: "tls@ietf.org" Subject: Re: [TLS] Ideas for TLS 1.3: Server key continuity and certificate reporting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Jan 2014 21:18:22 -0000 Hi Kai, Have you seen TACK? It does something similar but with self-managed signing keys, and has good procedures (IMO) for handling key and cert changes and pin lifetimes. http://tools.ietf.org/html/draft-perrin-tls-tack-02 http://tack.io/ Paul is correct there's more discussion about pinning on websec. But I agree with you this approach should be applied to SMTP, IMAP, etc. I'll also note that the bottleneck for ideas like this isn't IETF acceptance, but rather browser willingness to spend effort on experimental proposals (there are sites interested). Most browser experimentation in this area is going into CT at the moment, it seems to me. Trevor On Fri, Jan 10, 2014 at 12:28 PM, Kai Engert wrote: > On Fr, 2014-01-10 at 12:12 -0800, Paul Hoffman wrote: >> These ideas (and the followups from Alyssa) are interesting, but I >> suspect that they belong in the websec WG instead of here, unless you >> truly mean them to apply to every application that uses TLS. I don't >> see how they would work, for instance, with SMTP servers that do TLS. > > I'm motiviated to find ways to makes these ideas work with any TLS > connection, completely independent of the encapsulated application > protocol. > > I think a SMTP/TLS client could equally cache the previous cert and > potentially report it to the TLS server on a subsequent connection. > > Where do you see differences that would cause it not to work with > protocols other than http? > > Regards > Kai > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From fabrice.gautier@gmail.com Fri Jan 10 13:26:15 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDEB51AE18C for ; Fri, 10 Jan 2014 13:26:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXM6I0042OnU for ; Fri, 10 Jan 2014 13:26:11 -0800 (PST) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 926B81AE14B for ; Fri, 10 Jan 2014 13:26:11 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id hq4so144822wib.15 for ; Fri, 10 Jan 2014 13:26:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=pjwaWw6iGsfPx2y9zGLqxn7fYlj/HE0sNYulsMf6/p0=; b=PRMcx+xeXtzyKwstUejpZ7KDVNv/xIhfsoUhiRSGFWnxNrNvUiWvY4tbbtH47Yo8qw kb23oFO+dHpopmGtQBlZGbIR6sG/HpnAURArngdXwE2PWkIglzvvHM0hlYmEOwFkojth A7uRDO8et7mIoUQwDylTxHW6IpUumixPkTzgwQu7h8QJUM2gm7hyEjCLYxVQvlPyXmXe n6Vaw3JWMs4nfJWeVYPQBbHlJ5/rZIHtcY8ovs8ICOV4M6qjeZC5AqzcjwZ5FDOzR6MS VSNfMv7zKJ/rMQw1ITjnw7tyAUVWSu2KkHwcEIKo0DgD2nEQnE+FZM31t9cTnv2BjvoE 1tIw== X-Received: by 10.180.104.71 with SMTP id gc7mr4689691wib.2.1389389161185; Fri, 10 Jan 2014 13:26:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.44.131 with HTTP; Fri, 10 Jan 2014 13:25:41 -0800 (PST) In-Reply-To: References: From: Fabrice Gautier Date: Fri, 10 Jan 2014 13:25:41 -0800 Message-ID: To: Andrei Popov Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "" Subject: Re: [TLS] NPN, ALPN and the case of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Jan 2014 21:26:15 -0000 On Fri, Jan 10, 2014 at 1:08 PM, Andrei Popov wrote: > Hi Fabrice, > > I cannot speak to the design of NPN, but will answer the ALPN questions: > > 2) If a client sent an ALPN extension in the first ClientHello, can it se= nd it again in a further negotiation ? > Yes, the client\server can renegotiate the application protocol at any ti= me. > > 4) If a client didn't send an ALPN extension in the first ClientHello, m= ay it send it in the next handshake ? > Yes, this can be used e.g. to make the application protocol negotiation c= onfidential. Then I suggest that the following sentence in the ALPN draft be reworded to clarify this: The protocol identified in the "application_layer_protocol_negotiation" extension type in the ServerHello SHALL be definitive for the connection. At least something like: "SHALL be definitive for the connection, until renegotiated=94 This raise another question: if the Application Protocol is renegotiated when does the new application protocol starts? I=92m assuming that it would be for new Application Data received after the ChangeCipherSpec and Finished messages, and that any Application that may be interleaved with the earlier handshake message should still use the previous application protocol. =97 Fabrice > Cheers, > > Andrei > > -----Original Message----- > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Fabrice Gautier > Sent: Friday, January 10, 2014 11:17 AM > To: > Subject: [TLS] NPN, ALPN and the case of renegotiation > > Hi, > > When reading both NPN and ALPN drafts, I notice they both have this para= graph: > > 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. > > However, only NPN has that one, immediately following: > > For the same reasons, after a handshake has been performed for a > given connection, renegotiations on the same connection MUST NOT > include the "next_protocol_negotiation" extension. > > > On the other hand, ALPN has this one a little further down: > > The protocol identified in the > "application_layer_protocol_negotiation" extension type in the > ServerHello SHALL be definitive for the connection. The server SHALL > NOT respond with a selected protocol and subsequently use a different > protocol for application data exchange. > > > The question is: Should/can NPN/APLN extensions be sent/processed during = a renegotiation handshake ? > > So far I'm only confidently interpreting the above as: > 0) If NPN protocol was successfully selected during a handshake, the clie= nt should not send a NPN extension in its next client hello. > > I'm unsure of those other details though: > 1) If client sent an NPN extension in a ClientHello and did not get back = an NPN extension in the ServerHello, should/may the NPN client try the NPN= extension again in a re-handshake? > > I'm assuming it should not. > But somebody might come up with a reason for not wanting to provide the s= upported protocols in the clear. Although one would argue that if Applicati= on Data is sent between the two handshake, then a protocol is selected and = you should not be able to change it with NPN extensions, so the client must= not send the NPN extension in the renegotiation if they already received o= r sent some application data. > > 2) If a client sent an ALPN extension in the first ClientHello, can it se= nd it again in a further negotiation ? > > I'm assuming it may, unless protocol was selected explicitly with a ALPN = ServerHello extension, or implicitly by sending/receiving some application = data. > > 3) If a client didn't send an NPN extension in the first ClientHello, may= it send it in the next handshake ? > > I'm assuming it should not. and I don't really see a privacy angle in tha= t case. > > 4) If a client didn't send an ALPN extension in the first ClientHello, m= ay it send it in the next handshake ? > > I'm assuming yes. This is useful in case you want to hide the protocols s= upported and selected in a renegotiation (as indicated in Section 4 of ALPN= draft) Although again, if a protocol was implicitly selected by sending/re= ceiving data, it probably should not. > > > Are my assumptions mostly correct ? > > > Thanks > > > -- Fabrice > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From dkg@fifthhorseman.net Fri Jan 10 13:32:20 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAAE71AE1C6 for ; Fri, 10 Jan 2014 13:32:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L_ptN0XE_IYB for ; Fri, 10 Jan 2014 13:32:19 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id D4A551AE1C4 for ; Fri, 10 Jan 2014 13:32:18 -0800 (PST) Received: from [192.168.42.103] (h-67-101-156-12.nycm.ny.dynamic.megapath.net [67.101.156.12]) by che.mayfirst.org (Postfix) with ESMTPSA id EF3FFF984; Fri, 10 Jan 2014 16:32:06 -0500 (EST) Message-ID: <52D066D6.7070307@fifthhorseman.net> Date: Fri, 10 Jan 2014 16:32:06 -0500 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.1.1 MIME-Version: 1.0 To: Kai Engert , tls@ietf.org References: <1389371947.30279.56.camel@lapkaie> In-Reply-To: <1389371947.30279.56.camel@lapkaie> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="xuutwiOmccIQQBbdwRnCRkHXuVkMteg6K" Subject: Re: [TLS] Ideas for TLS 1.3: Server key continuity and certificate reporting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Jan 2014 21:32:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xuutwiOmccIQQBbdwRnCRkHXuVkMteg6K Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 01/10/2014 11:39 AM, Kai Engert wrote: > I would like to suggest a potential improvement for the TLS protocol. >=20 > The intention is to make it more difficult for an adversary to act as a= > MITM, by using the abilities of a CA to obtain a valid certificate, tha= t > isn't controlled by the real owner of a TLS server. >=20 > This message presents the ideas that I had today as a draft. this sounds like it covers similar ground to the TACK proposal: http://tack.io/ https://tools.ietf.org/html/draft-perrin-tls-tack-02 TACK permits sites to opt into this sort of key continuity infrastructure, though, rather than assuming a global key continuity policy that all servers may or may not be able to meet. As a thought experiment, do you think including TACK as a part of TLS 1.3 would meet the goals you're trying to achieve here? --dkg --xuutwiOmccIQQBbdwRnCRkHXuVkMteg6K Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJS0GbWXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcEhMP/0qGFC0CtxYHvoYt0VW/9mmr lKBVGV+rWtoc8cLwHDaigAJTIIzhZwZUjqJy2RNecjkviu8cfMUP15qeDrlMc7c8 EuslZ0153uNTm+TwSzIRgd2w9xfdS1fqVqlfhIRguwJMZwL753sq7QbedOv6TH0U RsBkRBYQAFK1ni5R27YPxeWwdqd4NnZTuDf8Z/uTCSD1DRSXu3TtFa0FNwg9elpb slTLVLYoQuLWjkc9eCm1eoboYx7L6CatsEr0WP2Es02SISEnSSpqWXcHNvgQDRMF qfzcRieOJB3PLJ6tssniNUDfEXFUZISoY2aCjzODiY9bc4nsh87gEFpANTa3fmZ0 5lXeTitZfU8ThpA/+Y2kHrTou7txZMRtTQS1TPd7i/J8epHt9vVVwGkb+qurKnMR 4ovdnAP0IxqyVsGfYBV8lvgb5ieVRZbDM0Q0vF4Ml8ELK+wLo4KKk/42Ty/qHspT rIeR1CyG7MR9oc2SM1hiFLTR/IuNd/lRBVugpPAa3jEPzWT6iGwFilW1pID8wefa OeNgxk84PQojBrXNwtYZDBEcoQKHLzhsDOru8EC/fJqUNTuJNtmV83Qy/fI1H6xE 5DuEgt5H4/Kn9d8i0kvT0O5MXyQN7BP+V5qvjuBH6nWyqg974riCaEmrp68uMLPU NmewIUcaYiJLeFwruKZK =ofts -----END PGP SIGNATURE----- --xuutwiOmccIQQBbdwRnCRkHXuVkMteg6K-- From agl@google.com Fri Jan 10 13:43:43 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F31F81AE1D0 for ; Fri, 10 Jan 2014 13:43:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 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, RP_MATCHES_RCVD=-0.538, 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 74GUt-TBhYTj for ; Fri, 10 Jan 2014 13:43:41 -0800 (PST) Received: from mail-ve0-x234.google.com (mail-ve0-x234.google.com [IPv6:2607:f8b0:400c:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 155DE1AE1C4 for ; Fri, 10 Jan 2014 13:43:40 -0800 (PST) Received: by mail-ve0-f180.google.com with SMTP id jz11so3889419veb.39 for ; Fri, 10 Jan 2014 13:43:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=/maZC2w3EDOH6qCkgKcF6r3TfYcx/RJIRPGFyflvtWc=; b=nfsxDTV3rrCeW7CHfF95JMMpWvEFA0nA1MSEsqgOQ2rA2w+CVzJdadc2MjGVgaxKb4 5JdvkT0pUrMHksl2HSwqKXb6io1S1lgKJuqSPunB2keWdcYOn90kRlyVZfZEmepvVjhQ s2oYGM7q/CgQ0EcSf3aWN086rY6LH4Nl8YWNGG5zV2L2T5KTIG4976yCShqXp0E7t6TS xkuteyXkgsTICTdoSJ2T3Y7AeLhmS4/NlcndyhAZAq7jx3yrMlaxIUivQQPq8Lmdj2r+ U8rEbvmtlSDNtRlwE39OnNaF7FP3XnplQa/DLYOxHaDROw8mxluE07JEBDW6IdLhtxi3 oZSg== 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=/maZC2w3EDOH6qCkgKcF6r3TfYcx/RJIRPGFyflvtWc=; b=Y3f2dxA06tlAvfH1awbWPLEOzfAng94N+PUw6jrhTVjC6MPVQaflxkHoxxSu4YzEde Ji5QAstx4dsLJNLkv8GQgawq7vcwjCRDE9te6QUGvMvxJsCBsHNvZnV967q3r1FFL3if arsmFFSaOooNSUbI3vRC8cflQak1CfibClpFp/Xn90WzgcFGZRjYoUVLNrq//vg0M3zU CdEBTb/XvMXjago1ts+u3cZtNOTIAogWf+SrBZ2f8b4mT+ZpnnPeRoFIHubp0GeJo0V5 BHQ6g95lAjClkOpEdTwA1YzG4m2Ntc4VT7rqht0JjitWJDx5BpZzSs/Z+mmORTBwQs0y pX9Q== X-Gm-Message-State: ALoCoQkGdtWu/0lxNd1vex49+BeczSqhjReuIQot61CbtkuNrYDs+HGYAdm/F7oWt9zGrI27p47ViDsewZnzBEfu3sgqLgQbhNqz+afxck8ClfKe8LLGnWsr13UamcIsKzjKE6NLlRYusDPrLz7Jhifm9RXZajqmx+8JDdECzSZQm2CWdpt7OgdYQjuRjYkC87lebXoilD1r X-Received: by 10.52.167.163 with SMTP id zp3mr14160vdb.82.1389390210742; Fri, 10 Jan 2014 13:43:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.96.134 with HTTP; Fri, 10 Jan 2014 13:43:10 -0800 (PST) In-Reply-To: References: From: Adam Langley Date: Fri, 10 Jan 2014 16:43:10 -0500 Message-ID: To: Fabrice Gautier Content-Type: text/plain; charset=UTF-8 Cc: "" Subject: Re: [TLS] NPN, ALPN and the case of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Jan 2014 21:43:43 -0000 On Fri, Jan 10, 2014 at 2:16 PM, Fabrice Gautier wrote: > So far I'm only confidently interpreting the above as: > 0) If NPN protocol was successfully selected during a handshake, the > client should not send a NPN extension in its next client hello. Correct. > I'm unsure of those other details though: > 1) If client sent an NPN extension in a ClientHello and did not get > back an NPN extension in the ServerHello, should/may the NPN client > try the NPN extension again in a re-handshake? It probably could. Although for sanity's sake I hope that there was no application data sent in the first handshake. I think you'll find that actual implementations of NPN just reject it on renegotiation and I don't ever recommend that anyone uses renegotiation, but one could make an argument for doing it under encryption. In any case, NPN is not a going concern at this point. > 2) If a client sent an ALPN extension in the first ClientHello, can it > send it again in a further negotiation ? Assuming that the server answers: Andrei thinks yes, but I think the answer is no :) If the first application protocol could synchronise the switch then it could possibly work but, at that point, just negotiate the new protocol at the application layer. For simplicity's sake I would ignore ALPN in a renegotiation. > 3) If a client didn't send an NPN extension in the first ClientHello, > may it send it in the next handshake ? See answer to (1) > 4) If a client didn't send an ALPN extension in the first > ClientHello, may it send it in the next handshake ? Yes, although again, for sanity's sake I hope that there was no application data sent in the first handshake. You can ignore all these problems and several more by simply not supporting renegotiation :) Cheers AGL From Andrei.Popov@microsoft.com Fri Jan 10 13:58:47 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0621AE118 for ; Fri, 10 Jan 2014 13:58:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 oGK5Mopx4DMZ for ; Fri, 10 Jan 2014 13:58:45 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0235.outbound.protection.outlook.com [207.46.163.235]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACDE1AE0C4 for ; Fri, 10 Jan 2014 13:58:45 -0800 (PST) Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BL2PR03MB418.namprd03.prod.outlook.com (10.141.92.13) with Microsoft SMTP Server (TLS) id 15.0.847.13; Fri, 10 Jan 2014 21:58:33 +0000 Received: from BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) by BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) with mapi id 15.00.0847.008; Fri, 10 Jan 2014 21:58:33 +0000 From: Andrei Popov To: Fabrice Gautier Thread-Topic: [TLS] NPN, ALPN and the case of renegotiation Thread-Index: AQHPDjiX2x1mV/7ikkKi9AvO9cv7ppp+caRQgAAG8YCAAAc3EA== Date: Fri, 10 Jan 2014 21:58:32 +0000 Message-ID: <796edc1745504aa5863925cf03bc9df0@BL2PR03MB419.namprd03.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::3] x-forefront-prvs: 00872B689F x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(51704005)(189002)(199002)(13464003)(24454002)(377454003)(164054003)(87266001)(76576001)(76786001)(76796001)(74706001)(83072002)(85852003)(74366001)(33646001)(2656002)(87936001)(74502001)(69226001)(19580395003)(19580405001)(83322001)(81342001)(47446002)(31966008)(74662001)(47736001)(50986001)(49866001)(47976001)(4396001)(81542001)(80976001)(56816005)(51856001)(46102001)(79102001)(54316002)(15975445006)(77982001)(59766001)(54356001)(92566001)(81686001)(90146001)(74316001)(74876001)(85306002)(76482001)(80022001)(81816001)(53806001)(56776001)(63696002)(65816001)(93136001)(24736002)(3826001); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR03MB418; H:BL2PR03MB419.namprd03.prod.outlook.com; CLIP:2001:4898:80e8:ed31::3; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "" Subject: Re: [TLS] NPN, ALPN and the case of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Jan 2014 21:58:47 -0000 Yes, both of these clarifications make sense to me. I think we should consi= der clarifying this in the draft. Thanks, Andrei -----Original Message----- From: Fabrice Gautier [mailto:fabrice.gautier@gmail.com]=20 Sent: Friday, January 10, 2014 1:26 PM To: Andrei Popov Cc: Subject: Re: [TLS] NPN, ALPN and the case of renegotiation On Fri, Jan 10, 2014 at 1:08 PM, Andrei Popov = wrote: > Hi Fabrice, > > I cannot speak to the design of NPN, but will answer the ALPN questions: > > 2) If a client sent an ALPN extension in the first ClientHello, can it se= nd it again in a further negotiation ? > Yes, the client\server can renegotiate the application protocol at any ti= me. > > 4) If a client didn't send an ALPN extension in the first ClientHello, m= ay it send it in the next handshake ? > Yes, this can be used e.g. to make the application protocol negotiation c= onfidential. Then I suggest that the following sentence in the ALPN draft be reworded to= clarify this: The protocol identified in the "application_layer_protocol_negotiation" extension type in the ServerHello SHALL be definitive for the connection. At least something like: "SHALL be definitive for the connection, until ren= egotiated" This raise another question: if the Application Protocol is renegotiated wh= en does the new application protocol starts? I'm assuming that it would be for new Application Data received after the C= hangeCipherSpec and Finished messages, and that any Application that may be= interleaved with the earlier handshake message should still use the previo= us application protocol. - Fabrice > Cheers, > > Andrei > > -----Original Message----- > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Fabrice Gautier > Sent: Friday, January 10, 2014 11:17 AM > To: > Subject: [TLS] NPN, ALPN and the case of renegotiation > > Hi, > > When reading both NPN and ALPN drafts, I notice they both have this para= graph: > > 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. > > However, only NPN has that one, immediately following: > > For the same reasons, after a handshake has been performed for a > given connection, renegotiations on the same connection MUST NOT > include the "next_protocol_negotiation" extension. > > > On the other hand, ALPN has this one a little further down: > > The protocol identified in the > "application_layer_protocol_negotiation" extension type in the > ServerHello SHALL be definitive for the connection. The server SHALL > NOT respond with a selected protocol and subsequently use a different > protocol for application data exchange. > > > The question is: Should/can NPN/APLN extensions be sent/processed during = a renegotiation handshake ? > > So far I'm only confidently interpreting the above as: > 0) If NPN protocol was successfully selected during a handshake, the clie= nt should not send a NPN extension in its next client hello. > > I'm unsure of those other details though: > 1) If client sent an NPN extension in a ClientHello and did not get back = an NPN extension in the ServerHello, should/may the NPN client try the NPN= extension again in a re-handshake? > > I'm assuming it should not. > But somebody might come up with a reason for not wanting to provide the s= upported protocols in the clear. Although one would argue that if Applicati= on Data is sent between the two handshake, then a protocol is selected and = you should not be able to change it with NPN extensions, so the client must= not send the NPN extension in the renegotiation if they already received o= r sent some application data. > > 2) If a client sent an ALPN extension in the first ClientHello, can it se= nd it again in a further negotiation ? > > I'm assuming it may, unless protocol was selected explicitly with a ALPN = ServerHello extension, or implicitly by sending/receiving some application = data. > > 3) If a client didn't send an NPN extension in the first ClientHello, may= it send it in the next handshake ? > > I'm assuming it should not. and I don't really see a privacy angle in tha= t case. > > 4) If a client didn't send an ALPN extension in the first ClientHello, m= ay it send it in the next handshake ? > > I'm assuming yes. This is useful in case you want to hide the protocols s= upported and selected in a renegotiation (as indicated in Section 4 of ALPN= draft) Although again, if a protocol was implicitly selected by sending/re= ceiving data, it probably should not. > > > Are my assumptions mostly correct ? > > > Thanks > > > -- Fabrice > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From mrex@sap.com Fri Jan 10 14:02:55 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C83381A1F54 for ; Fri, 10 Jan 2014 14:02:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 50TV8cKeqFsD for ; Fri, 10 Jan 2014 14:02:51 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 61B951A1F4C for ; Fri, 10 Jan 2014 14:02:51 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s0AM2dSW011677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 10 Jan 2014 23:02:39 +0100 (MET) In-Reply-To: To: Watson Ladd Date: Fri, 10 Jan 2014 23:02:39 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140110220239.3F10C1AB99@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "tls@ietf.org" Subject: Re: [TLS] Fixing CBC Mode I: GenericBlockCipher construction X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 22:02:55 -0000 Watson Ladd wrote: > Adam Langley wrote: >> >> Martin Rex wrote: >>> >>> It seems to me that both of these approaches, when applied to the >>> SSLv3/TLSv1.0 GenericBlockCipher PDU with "running IV", will pull >>> the rug from underneath the 1/(n-1) record splitting workaround >> >> Yes, if the MAC isn't going to end up as the IV for the next block >> then 1/n-1 record splitting doesn't work. >> >> So unless this extension also enables an explicit IV then it's limited >> to >= TLS 1.1. > > I'm very surprised at the both of you. Because we will have ciphertext > integrity, > CBC decryption oracles aren't a consideration. The remaining attack on > deterministic IVs is guessing > low entropy blocks by injecting cleverly chosen blocks. But 1/(n-1) > record splitting will prevent this attack > by restricting the control over the next IV to be negligible. Ooops, I'm sorry. You're correct in that 1/(n-1) record splitting will continue to prevent the original attack. I was confused. In its original characterization [1] the weakness has two prerequisites to work (1) the IV must be known prior to the submission of the plaintext and (2) it must be possible to specify most (or all) of the plaintext block that gets encrypted with that IV. The CBC residue that is IV for the next record in SSLv3/TLSv1.0 becomes known to the attacker prior to submission of the next plaintext, but it still has the "strong random" property. The attacker can not force a specific IV. With 1/(n-1) splitting, the attacker has control over just a single octet of the next plaintext block. Whether the remaining plaintext is strong random (e.g. encrypted HMAC) or whether it is known fixed padding is actually not relevant here. What happens is that the (len=1) record gets XOR-ed with a strong random (but pre-known) IV and is then AES-encrypted. The resulting ciphertext is again strong random / non-predictable (in the sense that you don't know it before you see it), so that the (n-1) block, where the attacker has full control over all plaintext bytes, the IV will be unknown at the time when the plaintext is submitted. I'm sorry for the confusion. -Martin From fabrice.gautier@gmail.com Fri Jan 10 14:11:33 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBB061ACCD8 for ; Fri, 10 Jan 2014 14:11:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2PtX8vfo8cm for ; Fri, 10 Jan 2014 14:11:31 -0800 (PST) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 6C1361A1F54 for ; Fri, 10 Jan 2014 14:11:31 -0800 (PST) Received: by mail-we0-f179.google.com with SMTP id q59so4607744wes.38 for ; Fri, 10 Jan 2014 14:11:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=WRHhthLfDlbRvaT5BET5Ck4tGgLUav2OH1jrQpb1SH8=; b=z8MBZDCoIiu/HEhqJEW3TqVH/F/2KU/KBCH2Rd+v0l4PSFiDSctzj732rAikJO76Pf zm+rdCwhRUF8miUmUTMqkAB4LG18J4QXAHay9Z68FnZ+0ASBBrULkz6ennQ/0CZxqq0E j8pLTcD4ZzVqZs4fM+TtYmjP6nIqNmdSxerUh8jtCLDLZKWGL3wtpKm5JBnGFYDK0idu OSSSTPrATpC7vDtYbfQt/DJvD1KkrH1FF60GtDxNaWWBpVvVXnomiOAtFKN13PQIGn5X LKechqZtxcVj2bx0nQ7125ZDs0Zt5HzZjCVu+H+w/R/LIhdPlOKpHgsaGHxMX0LI6Bvd GUFw== X-Received: by 10.194.57.19 with SMTP id e19mr112049wjq.93.1389391881020; Fri, 10 Jan 2014 14:11:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.44.131 with HTTP; Fri, 10 Jan 2014 14:11:00 -0800 (PST) In-Reply-To: References: From: Fabrice Gautier Date: Fri, 10 Jan 2014 14:11:00 -0800 Message-ID: To: Adam Langley Content-Type: text/plain; charset=ISO-8859-1 Cc: "" Subject: Re: [TLS] NPN, ALPN and the case of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Jan 2014 22:11:34 -0000 On Fri, Jan 10, 2014 at 1:43 PM, Adam Langley wrote: > On Fri, Jan 10, 2014 at 2:16 PM, Fabrice Gautier > wrote: >> So far I'm only confidently interpreting the above as: >> 0) If NPN protocol was successfully selected during a handshake, the >> client should not send a NPN extension in its next client hello. > > Correct. > >> I'm unsure of those other details though: >> 1) If client sent an NPN extension in a ClientHello and did not get >> back an NPN extension in the ServerHello, should/may the NPN client >> try the NPN extension again in a re-handshake? > > It probably could. Although for sanity's sake I hope that there was no > application data sent in the first handshake. > > I think you'll find that actual implementations of NPN just reject it > on renegotiation and I don't ever recommend that anyone uses > renegotiation, but one could make an argument for doing it under > encryption. > > In any case, NPN is not a going concern at this point. > >> 2) If a client sent an ALPN extension in the first ClientHello, can it >> send it again in a further negotiation ? > > Assuming that the server answers: Andrei thinks yes, but I think the > answer is no :) > > If the first application protocol could synchronise the switch then it > could possibly work but, at that point, just negotiate the new > protocol at the application layer. For simplicity's sake I would > ignore ALPN in a renegotiation. > >> 3) If a client didn't send an NPN extension in the first ClientHello, >> may it send it in the next handshake ? > > See answer to (1) > >> 4) If a client didn't send an ALPN extension in the first >> ClientHello, may it send it in the next handshake ? > > Yes, although again, for sanity's sake I hope that there was no > application data sent in the first handshake. > > You can ignore all these problems and several more by simply not > supporting renegotiation :) You mean not supporting TLS renegotiation in general? I'm afraid I can't do that until there is an RFC obsoleting it. But yeah, that would simplify a lots of things. If you mean renegotiating the application protocol, the draft opens the door to it, so I think it is important for TLS implementer to know how to handle those cases. > > Cheers > > AGL From fabrice.gautier@gmail.com Fri Jan 10 14:18:24 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13EC81ADF7E for ; Fri, 10 Jan 2014 14:18:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HaSbLpVUOAFG for ; Fri, 10 Jan 2014 14:18:21 -0800 (PST) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 497ED1A1F1A for ; Fri, 10 Jan 2014 14:18:21 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id n12so930814wgh.2 for ; Fri, 10 Jan 2014 14:18:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=JbBj/iVFYe54dLixacLl8XrWf5GT/a5S2vB8TzL/dYk=; b=sGw3eGGHtkc6iNTbsvwTj/mt0t/7v0NLdK5k2+U5bNWYLJC3CZzNeCyQGlehqVLq62 NYuDznFJTXcOOhfJG0ysBWypA/JCgKGZxs1UZur+uoZW2YZC//xZelDKACa2RNn7UeNJ g1A6yoLflpSOq9ub2bm6/mgYoHfe+Q4yC9crt5YHgZ442Lrfgm0KtnpcaUbUk6fSvQVp 1xpr6xQtJSdDsKVoQBB3ls7i3hhJYEuBFCn08ONxiOO0RBmV3W4Cg8G0XionNxyvKetm IdzuEucSQWU0UzrNIffmaEpqHpGWJ8eGYgyFcnmLVIGf4z3k1qv6LtrKXeoOfwfCHlx8 /JHQ== X-Received: by 10.180.205.162 with SMTP id lh2mr4692149wic.57.1389392290841; Fri, 10 Jan 2014 14:18:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.44.131 with HTTP; Fri, 10 Jan 2014 14:17:50 -0800 (PST) In-Reply-To: <796edc1745504aa5863925cf03bc9df0@BL2PR03MB419.namprd03.prod.outlook.com> References: <796edc1745504aa5863925cf03bc9df0@BL2PR03MB419.namprd03.prod.outlook.com> From: Fabrice Gautier Date: Fri, 10 Jan 2014 14:17:50 -0800 Message-ID: To: Andrei Popov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "" Subject: Re: [TLS] NPN, ALPN and the case of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Jan 2014 22:18:24 -0000 On Fri, Jan 10, 2014 at 1:58 PM, Andrei Popov wrote: > Yes, both of these clarifications make sense to me. I think we should con= sider clarifying this in the draft. > Also consider clarifying that, in the case of a renegotiation without ALPN extensions, after an initial handshake with ALPN extensions, the application protocol should remain the same, and not fall back to the "sane default". Thats probably obvious, but you would not want a browser to fall back to http 1.1 instead of http 2.0 or spdy because of a TLS renegotiation. -- Fabrice > Thanks, > > Andrei > > -----Original Message----- > From: Fabrice Gautier [mailto:fabrice.gautier@gmail.com] > Sent: Friday, January 10, 2014 1:26 PM > To: Andrei Popov > Cc: > Subject: Re: [TLS] NPN, ALPN and the case of renegotiation > > On Fri, Jan 10, 2014 at 1:08 PM, Andrei Popov wrote: >> Hi Fabrice, >> >> I cannot speak to the design of NPN, but will answer the ALPN questions: >> >> 2) If a client sent an ALPN extension in the first ClientHello, can it s= end it again in a further negotiation ? >> Yes, the client\server can renegotiate the application protocol at any t= ime. >> >> 4) If a client didn't send an ALPN extension in the first ClientHello, = may it send it in the next handshake ? >> Yes, this can be used e.g. to make the application protocol negotiation = confidential. > > > Then I suggest that the following sentence in the ALPN draft be reworded = to clarify this: > > The protocol identified in the > > "application_layer_protocol_negotiation" extension type in the > ServerHello SHALL be definitive for the connection. > > At least something like: "SHALL be definitive for the connection, until r= enegotiated" > > This raise another question: if the Application Protocol is renegotiated = when does the new application protocol starts? > I'm assuming that it would be for new Application Data received after the= ChangeCipherSpec and Finished messages, and that any Application that may = be interleaved with the earlier handshake message should still use the prev= ious application protocol. > > - Fabrice > > >> Cheers, >> >> Andrei >> >> -----Original Message----- >> From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Fabrice Gautier >> Sent: Friday, January 10, 2014 11:17 AM >> To: >> Subject: [TLS] NPN, ALPN and the case of renegotiation >> >> Hi, >> >> When reading both NPN and ALPN drafts, I notice they both have this par= agraph: >> >> 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. >> >> However, only NPN has that one, immediately following: >> >> For the same reasons, after a handshake has been performed for a >> given connection, renegotiations on the same connection MUST NOT >> include the "next_protocol_negotiation" extension. >> >> >> On the other hand, ALPN has this one a little further down: >> >> The protocol identified in the >> "application_layer_protocol_negotiation" extension type in the >> ServerHello SHALL be definitive for the connection. The server SHALL >> NOT respond with a selected protocol and subsequently use a different >> protocol for application data exchange. >> >> >> The question is: Should/can NPN/APLN extensions be sent/processed during= a renegotiation handshake ? >> >> So far I'm only confidently interpreting the above as: >> 0) If NPN protocol was successfully selected during a handshake, the cli= ent should not send a NPN extension in its next client hello. >> >> I'm unsure of those other details though: >> 1) If client sent an NPN extension in a ClientHello and did not get back= an NPN extension in the ServerHello, should/may the NPN client try the NP= N extension again in a re-handshake? >> >> I'm assuming it should not. >> But somebody might come up with a reason for not wanting to provide the = supported protocols in the clear. Although one would argue that if Applicat= ion Data is sent between the two handshake, then a protocol is selected and= you should not be able to change it with NPN extensions, so the client mus= t not send the NPN extension in the renegotiation if they already received = or sent some application data. >> >> 2) If a client sent an ALPN extension in the first ClientHello, can it s= end it again in a further negotiation ? >> >> I'm assuming it may, unless protocol was selected explicitly with a ALPN= ServerHello extension, or implicitly by sending/receiving some application= data. >> >> 3) If a client didn't send an NPN extension in the first ClientHello, ma= y it send it in the next handshake ? >> >> I'm assuming it should not. and I don't really see a privacy angle in th= at case. >> >> 4) If a client didn't send an ALPN extension in the first ClientHello, = may it send it in the next handshake ? >> >> I'm assuming yes. This is useful in case you want to hide the protocols = supported and selected in a renegotiation (as indicated in Section 4 of ALP= N draft) Although again, if a protocol was implicitly selected by sending/r= eceiving data, it probably should not. >> >> >> Are my assumptions mostly correct ? >> >> >> Thanks >> >> >> -- Fabrice >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls From mrex@sap.com Fri Jan 10 14:18:27 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10CF11AE15C for ; Fri, 10 Jan 2014 14:18:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 V7BpP93LNgVw for ; Fri, 10 Jan 2014 14:18:25 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 3462C1A1F1A for ; Fri, 10 Jan 2014 14:18:25 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s0AMIDmp012702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 10 Jan 2014 23:18:13 +0100 (MET) In-Reply-To: To: Adam Langley Date: Fri, 10 Jan 2014 23:18:13 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140110221813.B50341AB99@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "tls@ietf.org" Subject: Re: [TLS] Fixing CBC Mode I: GenericBlockCipher construction X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 22:18:27 -0000 Adam Langley wrote: > Watson Ladd wrote: >> >> I'm very surprised at the both of you. Because we will have ciphertext >> integrity, >> CBC decryption oracles aren't a consideration. > > Sure, but 1/n-1 was never about decryption oracles. > >> The remaining attack on >> deterministic IVs is guessing >> low entropy blocks by injecting cleverly chosen blocks. But 1/(n-1) >> record splitting will prevent this attack >> by restricting the control over the next IV to be negligible. > > This is using 1/n-1 record splitting in a different way and you appear > to be confident that it's safe. It's certainly not as obviously safe > as using a random IV for CBC mode. > > I agree that it's not obvious that anything bad can be done because > the attacker doesn't have enough control over the contents of the > first block. But we know that CBC mode *should* have random IVs and, > if we're changing code anyway, I think you're being much too accepting > of throwing together a new construction rather than doing it right. It > would make me sad if we're not going to say that the extension > negotiates explicit IVs *and* not say that it needs TLS 1.1. TLS 1.1 > just isn't that hard to implement and we might be able to securely > negotiate it soon. I'm perfectly fine with implementations supporting and using protocol features and semantics of TLSv1.1 and TLSv1.2. I am just violently opposed to requiring implementations having to send "ClientHello.client_version" = { 0x03,0x02 } or { 0x03, 0x03 } prior to using TLSv1.1 or TLSv1.2 protocol features or semantics. because we know that this causes interop problems with parts of the installed base and requires the complex, inefficient and dangerous reconnect fallbacks. >From a protocol perspective, it is completely irrelevant how both communication peers negotiate the use of specific protocol features, and it is more important that we devise a scheme that interops nicely with the installed base, than maintaining the illusion of a "clean specification", where in reality implementations will need complex, inefficient and dangerous reconnect fallback hacks for interop. -Martin From kaie@kuix.de Fri Jan 10 14:22:57 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 556391A1F66 for ; Fri, 10 Jan 2014 14:22:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9eq-ZvCRc_E for ; Fri, 10 Jan 2014 14:22:54 -0800 (PST) Received: from s15531995.onlinehome-server.info (s15531995.onlinehome-server.info [82.165.38.173]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD801A1F1A for ; Fri, 10 Jan 2014 14:22:53 -0800 (PST) Received: from [192.168.2.253] (p4FF357EF.dip0.t-ipconnect.de [79.243.87.239]) by s15531995.onlinehome-server.info (Postfix) with ESMTPSA id A3EAA428906E for ; Fri, 10 Jan 2014 23:22:42 +0100 (CET) Message-ID: <1389392562.13026.111.camel@lapkaie> From: Kai Engert To: tls Date: Fri, 10 Jan 2014 23:22:42 +0100 In-Reply-To: <52D047C3.20208@akr.io> References: <1389371947.30279.56.camel@lapkaie> <52D047C3.20208@akr.io> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.5 (3.8.5-2.fc19) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: Re: [TLS] Ideas for TLS 1.3: Server key continuity and certificate reporting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Jan 2014 22:22:57 -0000 This message replaces my earlier incomplete message. On Fr, 2014-01-10 at 19:19 +0000, Alyssa Rowan wrote: > Firstly, it relies on TLS clients caching certificates, like SSH > clients; they have not traditionally done this. I'll let those who > write clients chime in on why they may or may not want to. Thanks for considering the client side, I'll add some thoughts as well. I agree there might be clients that wouldn't want to implement a cache, because they don't save a state. Or they might not want to update a cache when operating in a mode that intends to avoid local caching ("private browsing mode"). I think that's fine. Even if the most popular TLS clients, like browsers, e-mail agents and vpn clients were the only TLS clients that implemented the canary reporting, I believe it would still be beneficial. (Browsers in a "private browsing mode" could recommend to the user that they are operating with reduced web security checking. OTOH, if a user runs in private browsing mode, but a previous server certificate has already been cached from regular browsing, it could be considered safe to update the local cache, as it wouldn't creating additional leaks). > Secondly, if the server does change certificate legitimately, it's > going to get a lot of these warnings from everyone. That could get > annoying. That's why I'm suggesting that server software should have a configuration option, which allows to configure a list of allowed certificates. That list would contain the previously used certificates for the given hostname. The server could ignore any reports with those certificates. > But thirdly - and most importantly - if an adversary is in a position > to be a man-in-the-middle and actually use their fake CA certificate, > they're also in a position to read your draft, know exactly what the > new-certificate canary looks like - and make sure the server never > gets it by filtering it out or injecting a RST to the server. Yes, the reporting cannot prevent an attack, that isn't the purpose of the reporting (but might potentially be achieved when combined with the second part of the proposal). I assume that most attacks are temporary and that eventually most clients will be able to use a direct route to the real destination, without being attacked. For example, after they are back from travelling or from using a WiFi hotspot, or if they are able to use a VPN occassionally. Or if they connect to the neighbour's wifi, instead of using their own fixed DSL line which has been hacked. Or if they switch between a DSL line with an active MITM and a 3G connection that is free of MITM. Unless an individual is specifically targetted by an adversary who has the resources to MITM absolutely all connectivity options at all times, the TLS client should eventually be able to succeed in submitting the report. For this part of the proposal, the intention is to make it likely that most abuse of CA capabilities will eventually get noticed. > And that > is probably exactly what they'll do, because they do it already > (“QUANTUMRESET”) and it's a very, very easy attack; much easier than > getting a forged certificate. Sorry, I don't understand this part of the argument. Where can I read more about "QUANTUMRESET"? > Sorry, I just don't think it would work. > > An out-of-band approach would be harder to disrupt and more > successful, like the SSL Observatory type things we already have, and > Certificate Transparency public audit log rules for CAs (which I > personally think should be strictly enforced as a minimum bar for any > CA remaining in browsers, although some CAs are apparently reluctant > to do this, so that may not be too easily forthcoming in the immediate > future). > > I think some browsers might already do this: Chrome, perhaps? An out-of-band channel can be more easily blocked without consequences. Browsers don't want to block primary connections with an error message, just because an out-of-band check failed. That's why as of today, browsers continue to accept TLS server certificates despite connectivity failures, when attempting to check status using OCSP. Querying the SSL observatory is expensive (latency), adds a single point of failure (if a successful result becomes mandatory), and it's still difficult to make an automatic decision whether a certificate is the right one (for example, if a server uses multiple different certificates based on client's cryptographic capabilities). The reporting I have suggested doesn't depend on a centralized infrastructure, nor out-of-band connections, and might still help to gain more trust in CAs (or find out which ones aren't behaving as expected). > > (2) TLS clients should require key continuity. > > As above - requires caching - but I'll let those who write clients > chime in on this one. > > Would need a "I'm Z, old key X, new key Y" statement signed by old key > X, yes. > > Obvious edge cases that leap out at me:— > • Old key X expired first. Oh-so-common. > - Do we still trust its assertion? It could become a best practice that updated certificates get rolled out to servers a few weeks prior to certificate expiration, that way most regularly connecting clients would roll over to the new key in time. If the old cert has really expired, I wouldn't require an assertion. Note the key continuity check is proposed as an additional check on top of regular certificate validation. In order to abuse this gap, a MITM would still have to have access to falsely issued certificate and would have to carefully wait until the current certificate expires, without intercepting any connections while the old one is still valid, but intercepting all connections immediately afterwards. That's probably quite tricky, and it's not sure how many MITMs would be sufficiently patient to wait until this gap attack works. I agree there might still be some MITMs who were willing to wait for the gap, but the server administrator can minimize this risk by rolling out the replacement certificate early. > • We don't have old key X. As you say, needs stapling of revocation. > - But how many historical keys are we going to have to staple? > - What if this domain changes hands a lot? We only need to staple one revocation, the one for the certificate that the client reports as having cached. The server must keep a list of all old certificates and a revocation statement for stapling for each of them. I proposed to do without key continuity check if the CA remains the same. The new domain owner would have to get a certificate from the same CA, and would have to stay with that CA, as long as the previous certificate hasn't expired yet. This helps to confirm that the certificate is double checked, as the CA has contact records for the previous owner of the domain. On top of that, as a last resort, TLS Clients would probably offer a mechanism to allow the user to "connect anyway", despite the failed key continuity check, just as with certificate errors, so there's a way out of this situation for this special case where one domain changes a lot. (The TLS client should use a new kind of feedback message, that informs the client that ownership of the domain has very likely changed, and to only proceed with the connection if the change of domain ownership is known/expected.) > • New key Y has a problem, e.g. isn't on the OCSP lists yet. I don't see a problem with that as part of this proposal. Requiring strict and general availability of fresh OCSP information is a separate decision. In order to pass the key continuity check, I don't suggest to require OCSP. When I previously talked about having a OCSP status message available to proof the revocation of a previously seen certificate, that was meant as a special situation where this information is mandatory, but I don't require stapled OCSP data in general. Since the proof I have asked for (satisfied with a OCSP message) would be related to a previous certificate (not the one used for the current handshake), this exchange would have to be separate from the general OCSP stapling protocol anyway. > • Old key X is revoked, but OCSP is unreachable and not stapled. If OCSP is unreachable and OCSP isn't stapled, then the TLS client doesn't know that X has been revoked. If the client expects X, but sees Y, the certificates have been issued by different CAs, and no key continuity proof is presented by the server, then fail the certificate validation. The TLS client should warn the user, show appropriate warnings and explanations (just as with other certificate validations today). TLS client could give the user a mechanism to proceed anyway. > • Z is large, does DNS round-robin or anycast and has huge load > balancers all over the world with different keys [Xâ‚, Xâ‚‚, Xâ‚, X₄…]. > - Forcing them to have the same key seems even _worse_. > Now someone can swipe the key from any load balancer and look like > every one. Use certificates from the same CA on all systems. If you need to transition to updated certificates, no problem as long as you keep using the same CA. If you switch to a different CA (or if you decide to transition to a different CA, prepare the proof using the previous key, and install on servers. The primary purpose of the proposal is to detect falsely issued certificates from an unrelated CA. (If the CA you have chosen cooperates with the adversary, we would need a different idea to detect that. I'll keep brainstorming on that.) > Needs some thinking through. It may or may not be a good idea, but > there are certainly a few potential complications. Thanks for your helpful feedback. I'm looking forward to additional thoughts. Regards Kai From mrex@sap.com Fri Jan 10 14:26:47 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEE591AE1A1 for ; Fri, 10 Jan 2014 14:26:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 PzqZG2kZUXzb for ; Fri, 10 Jan 2014 14:26:43 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1381AE17A for ; Fri, 10 Jan 2014 14:26:43 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s0AMQVVn013172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 10 Jan 2014 23:26:31 +0100 (MET) In-Reply-To: <20140110220239.3F10C1AB99@ld9781.wdf.sap.corp> To: mrex@sap.com Date: Fri, 10 Jan 2014 23:26:31 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140110222631.BBD0B1AB99@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "tls@ietf.org" Subject: Re: [TLS] Fixing CBC Mode I: GenericBlockCipher construction X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 22:26:47 -0000 Sorry, I forgot the reference to the "original characterization[1]" of the weakness. -Martin [1] Bodo Moeller quoting his 2002 Email response to Wei Dai in http://www.openssl.org/~bodo/tls-cbc.txt >> Phil Rogaway observed that CBC mode is not secure against chosen- >> plaintext attack if the IV is known or can be predicted by the attacker >> before he choses his plaintext. in which Wei Dai refers to an I-D formatted comment of Phil Rogaway on IPSEC from 1995 http://www.cs.ucdavis.edu/~rogaway/papers/draft-rogaway-ipsec-comments-00.txt Martin Rex wrote: > Watson Ladd wrote: > > Adam Langley wrote: > >> > >> Martin Rex wrote: > >>> > >>> It seems to me that both of these approaches, when applied to the > >>> SSLv3/TLSv1.0 GenericBlockCipher PDU with "running IV", will pull > >>> the rug from underneath the 1/(n-1) record splitting workaround > >> > >> Yes, if the MAC isn't going to end up as the IV for the next block > >> then 1/n-1 record splitting doesn't work. > >> > >> So unless this extension also enables an explicit IV then it's limited > >> to >= TLS 1.1. > > > > I'm very surprised at the both of you. Because we will have ciphertext > > integrity, > > CBC decryption oracles aren't a consideration. The remaining attack on > > deterministic IVs is guessing > > low entropy blocks by injecting cleverly chosen blocks. But 1/(n-1) > > record splitting will prevent this attack > > by restricting the control over the next IV to be negligible. > > > Ooops, I'm sorry. You're correct in that 1/(n-1) record splitting > will continue to prevent the original attack. I was confused. > > In its original characterization [1] the weakness has two prerequisites > to work (1) the IV must be known prior to the submission of the plaintext > and (2) it must be possible to specify most (or all) of the plaintext > block that gets encrypted with that IV. > > The CBC residue that is IV for the next record in SSLv3/TLSv1.0 becomes known > to the attacker prior to submission of the next plaintext, but it > still has the "strong random" property. The attacker can not force a > specific IV. With 1/(n-1) splitting, the attacker has control over just > a single octet of the next plaintext block. Whether the remaining > plaintext is strong random (e.g. encrypted HMAC) or whether it is > known fixed padding is actually not relevant here. > > What happens is that the (len=1) record gets XOR-ed with a strong random > (but pre-known) IV and is then AES-encrypted. The resulting ciphertext > is again strong random / non-predictable (in the sense that you don't > know it before you see it), so that the (n-1) block, where the attacker > has full control over all plaintext bytes, the IV will be unknown at > the time when the plaintext is submitted. > > > I'm sorry for the confusion. > > -Martin > From Andrei.Popov@microsoft.com Fri Jan 10 15:12:50 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23DFF1ACCD8 for ; Fri, 10 Jan 2014 15:12:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 JE8xCfeY38hO for ; Fri, 10 Jan 2014 15:12:47 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0155.outbound.protection.outlook.com [207.46.163.155]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE9E1AC4A7 for ; Fri, 10 Jan 2014 15:12:46 -0800 (PST) Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BL2PR03MB417.namprd03.prod.outlook.com (10.141.92.12) with Microsoft SMTP Server (TLS) id 15.0.847.13; Fri, 10 Jan 2014 23:12:35 +0000 Received: from BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) by BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) with mapi id 15.00.0847.008; Fri, 10 Jan 2014 23:12:35 +0000 From: Andrei Popov To: Fabrice Gautier Thread-Topic: [TLS] NPN, ALPN and the case of renegotiation Thread-Index: AQHPDjiX2x1mV/7ikkKi9AvO9cv7ppp+caRQgAAG8YCAAAc3EIAAB1sAgAAMI4A= Date: Fri, 10 Jan 2014 23:12:35 +0000 Message-ID: References: <796edc1745504aa5863925cf03bc9df0@BL2PR03MB419.namprd03.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::3] x-forefront-prvs: 00872B689F x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(189002)(199002)(24454002)(51704005)(164054003)(13464003)(377454003)(15975445006)(19580405001)(53806001)(83322001)(74876001)(46102001)(51856001)(19580395003)(80976001)(81686001)(81342001)(47736001)(47976001)(50986001)(49866001)(85306002)(81542001)(77982001)(59766001)(79102001)(81816001)(69226001)(56776001)(4396001)(76786001)(76576001)(92566001)(87936001)(76796001)(93136001)(87266001)(33646001)(2656002)(83072002)(85852003)(56816005)(74706001)(90146001)(54356001)(63696002)(76482001)(74316001)(74366001)(31966008)(54316002)(80022001)(74502001)(47446002)(74662001)(65816001)(24736002)(3826001); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR03MB417; H:BL2PR03MB419.namprd03.prod.outlook.com; CLIP:2001:4898:80e8:ed31::3; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "" Subject: Re: [TLS] NPN, ALPN and the case of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Jan 2014 23:12:50 -0000 Regarding the "sane default", I could see this both ways, and I don't think= this belongs in a document produced by the TLS WG.=20 ALPN allows applications negotiate (and renegotiate) an application protoco= l. What application protocol should be used in the absence of ALPN, whether= it's a "sane default", whether it's the same application protocol previous= ly negotiated with this server, etc. - all this is highly application-speci= fic, and belongs in the corresponding application RFC. In your example of H= TTP/1.1 vs. HTTP/2, I would expect the HTTP/2 spec to define this. -----Original Message----- From: Fabrice Gautier [mailto:fabrice.gautier@gmail.com]=20 Sent: Friday, January 10, 2014 2:18 PM To: Andrei Popov Cc: Subject: Re: [TLS] NPN, ALPN and the case of renegotiation On Fri, Jan 10, 2014 at 1:58 PM, Andrei Popov = wrote: > Yes, both of these clarifications make sense to me. I think we should con= sider clarifying this in the draft. > Also consider clarifying that, in the case of a renegotiation without ALPN = extensions, after an initial handshake with ALPN extensions, the applicatio= n protocol should remain the same, and not fall back to the "sane default". Thats probably obvious, but you would not want a browser to fall back to ht= tp 1.1 instead of http 2.0 or spdy because of a TLS renegotiation. -- Fabrice > Thanks, > > Andrei > > -----Original Message----- > From: Fabrice Gautier [mailto:fabrice.gautier@gmail.com] > Sent: Friday, January 10, 2014 1:26 PM > To: Andrei Popov > Cc: > Subject: Re: [TLS] NPN, ALPN and the case of renegotiation > > On Fri, Jan 10, 2014 at 1:08 PM, Andrei Popov wrote: >> Hi Fabrice, >> >> I cannot speak to the design of NPN, but will answer the ALPN questions: >> >> 2) If a client sent an ALPN extension in the first ClientHello, can it s= end it again in a further negotiation ? >> Yes, the client\server can renegotiate the application protocol at any t= ime. >> >> 4) If a client didn't send an ALPN extension in the first ClientHello, = may it send it in the next handshake ? >> Yes, this can be used e.g. to make the application protocol negotiation = confidential. > > > Then I suggest that the following sentence in the ALPN draft be reworded = to clarify this: > > The protocol identified in the > > "application_layer_protocol_negotiation" extension type in the > ServerHello SHALL be definitive for the connection. > > At least something like: "SHALL be definitive for the connection, until r= enegotiated" > > This raise another question: if the Application Protocol is renegotiated = when does the new application protocol starts? > I'm assuming that it would be for new Application Data received after the= ChangeCipherSpec and Finished messages, and that any Application that may = be interleaved with the earlier handshake message should still use the prev= ious application protocol. > > - Fabrice > > >> Cheers, >> >> Andrei >> >> -----Original Message----- >> From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Fabrice Gautier >> Sent: Friday, January 10, 2014 11:17 AM >> To: >> Subject: [TLS] NPN, ALPN and the case of renegotiation >> >> Hi, >> >> When reading both NPN and ALPN drafts, I notice they both have this par= agraph: >> >> 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. >> >> However, only NPN has that one, immediately following: >> >> For the same reasons, after a handshake has been performed for a >> given connection, renegotiations on the same connection MUST NOT >> include the "next_protocol_negotiation" extension. >> >> >> On the other hand, ALPN has this one a little further down: >> >> The protocol identified in the >> "application_layer_protocol_negotiation" extension type in the >> ServerHello SHALL be definitive for the connection. The server SHALL >> NOT respond with a selected protocol and subsequently use a different >> protocol for application data exchange. >> >> >> The question is: Should/can NPN/APLN extensions be sent/processed during= a renegotiation handshake ? >> >> So far I'm only confidently interpreting the above as: >> 0) If NPN protocol was successfully selected during a handshake, the cli= ent should not send a NPN extension in its next client hello. >> >> I'm unsure of those other details though: >> 1) If client sent an NPN extension in a ClientHello and did not get back= an NPN extension in the ServerHello, should/may the NPN client try the NP= N extension again in a re-handshake? >> >> I'm assuming it should not. >> But somebody might come up with a reason for not wanting to provide the = supported protocols in the clear. Although one would argue that if Applicat= ion Data is sent between the two handshake, then a protocol is selected and= you should not be able to change it with NPN extensions, so the client mus= t not send the NPN extension in the renegotiation if they already received = or sent some application data. >> >> 2) If a client sent an ALPN extension in the first ClientHello, can it s= end it again in a further negotiation ? >> >> I'm assuming it may, unless protocol was selected explicitly with a ALPN= ServerHello extension, or implicitly by sending/receiving some application= data. >> >> 3) If a client didn't send an NPN extension in the first ClientHello, ma= y it send it in the next handshake ? >> >> I'm assuming it should not. and I don't really see a privacy angle in th= at case. >> >> 4) If a client didn't send an ALPN extension in the first ClientHello, = may it send it in the next handshake ? >> >> I'm assuming yes. This is useful in case you want to hide the protocols = supported and selected in a renegotiation (as indicated in Section 4 of ALP= N draft) Although again, if a protocol was implicitly selected by sending/r= eceiving data, it probably should not. >> >> >> Are my assumptions mostly correct ? >> >> >> Thanks >> >> >> -- Fabrice >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls From holz@net.in.tum.de Fri Jan 10 15:14:39 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E161C1AE145 for ; Fri, 10 Jan 2014 15:14:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] 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 kmlDIUlFT2DO for ; Fri, 10 Jan 2014 15:14:37 -0800 (PST) Received: from smtp.serverkommune.de (serverkommune.de [176.9.61.43]) by ietfa.amsl.com (Postfix) with ESMTP id A597C1AE129 for ; Fri, 10 Jan 2014 15:14:37 -0800 (PST) Received: by smtp.serverkommune.de (Postfix, from userid 5001) id DBE008060A; Sat, 11 Jan 2014 00:14:26 +0100 (CET) Received: from [192.168.178.34] (ex6.serverkommune.de [176.9.61.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.serverkommune.de (Postfix) with ESMTPSA id E8655805AE for ; Sat, 11 Jan 2014 00:14:25 +0100 (CET) Message-ID: <52D07ED1.1020002@net.in.tum.de> Date: Sat, 11 Jan 2014 00:14:25 +0100 From: Ralph Holz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: tls@ietf.org References: <1389371947.30279.56.camel@lapkaie> In-Reply-To: <1389371947.30279.56.camel@lapkaie> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97.8 at ex6 X-Virus-Status: Clean Subject: Re: [TLS] Ideas for TLS 1.3: Server key continuity and certificate reporting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Jan 2014 23:14:40 -0000 Hi Kai, I am not sure what "real" attacker you are adressing, and if this static kind of pinning is really helpful. On (1): First, I have a suspicion that certificates may change relatively fast, and CAs change too fast for pinning against the CA, too -- or at least that is how I understood two colleagues of mine who investigated this. Second, on (1), reporting a cert: you assume a temporary attack, but how is the client to find out if the attack is over? Is it supposed to report the suspicious cert on every connection attempt until it re-encounters the old cert? But what if the change was legitimate? Finally, what is the server operator expected to do with this information, and how is it signalled to him? A further thought comes to mind -- couldn't I spam the system by reporting rogue certs to servers all the time? (This is a problem that we also faced with Crossbear) > (2) TLS clients should require key continuity. What you propose here is a kind of life-cycle management for pins. Are you familiar with TACK by Trevor and Moxie? Their scheme does essentially this and provides for key roll-over, both legitimate and due to compromise. The core idea is not to pin against the TLS key, which is subject to change, but to a domain key, much in the style of Sovereign Keys. It also provides for roll-over of the domain key. I think your ideas are pretty much covered by TACK. For the record, should the IETF make a move towards adopting TACK as part of TLS, I'd be happy to see that. I think one of TACK's greatest strengths is that it is immune even against a globally acting attacker as long as that first contact was secure. Ralph -- Ralph Holz I8 - Network Architectures and Services Technische Universität München http://www.net.in.tum.de/de/mitarbeiter/holz/ Phone +49.89.289.18043 PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF From fabrice.gautier@gmail.com Fri Jan 10 15:28:35 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE2F1AE0E3 for ; Fri, 10 Jan 2014 15:28:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UyCMlOHUjzHM for ; Fri, 10 Jan 2014 15:28:32 -0800 (PST) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 318FC1AE0E2 for ; Fri, 10 Jan 2014 15:28:32 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id a1so2384102wgh.28 for ; Fri, 10 Jan 2014 15:28:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=UByXPNHF5etffklg4Nt+fVb+LpjcozQpFdiXWVXKDpc=; b=OG2FR5HFjGfXvl6Gjp4marrcHziD0w0ZV/z/nik0YHAiZ9QpdkWgML503t2RGJBDN0 PhF4kxyPMtZ7f8Sr5kB8pqWrXf5S/akwEbzQPx2FfKPxTS7ObtdgIO8nld2wrfa+JD+C aYEsBszXLOzcbfl1jUra1x4Gu2ymOWuK4vc5j458LOBj8rVDJSmZFzCJnmG8dL6NUKPB r3VYw+sT4+aw3BTSc+cDTV5RMZ/BCNYobxGSRX3VA05OliLrbAQmwYTOAO0WGxK59xpU rfWmABhGDzXzt9BFoF43OxrlA1Ex51+QBZQpm0lSxdxFn+mWcAQnr29Kp8rlicfrMRsT hGbA== X-Received: by 10.180.108.240 with SMTP id hn16mr4908373wib.5.1389396501637; Fri, 10 Jan 2014 15:28:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.44.131 with HTTP; Fri, 10 Jan 2014 15:28:01 -0800 (PST) In-Reply-To: References: <796edc1745504aa5863925cf03bc9df0@BL2PR03MB419.namprd03.prod.outlook.com> From: Fabrice Gautier Date: Fri, 10 Jan 2014 15:28:01 -0800 Message-ID: To: Andrei Popov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "" Subject: Re: [TLS] NPN, ALPN and the case of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Jan 2014 23:28:35 -0000 On Fri, Jan 10, 2014 at 3:12 PM, Andrei Popov wrote: > Regarding the "sane default", I could see this both ways, and I don't thi= nk this belongs in a document produced by the TLS WG. > > ALPN allows applications negotiate (and renegotiate) an application proto= col. What application protocol should be used in the absence of ALPN, wheth= er it's a "sane default", whether it's the same application protocol previo= usly negotiated with this server, etc. - all this is highly application-spe= cific, and belongs in the corresponding application RFC. In your example of= HTTP/1.1 vs. HTTP/2, I would expect the HTTP/2 spec to define this. True, since the TLS renegotiations are normally triggered by something at the application level anyway. -- Fabrice > > -----Original Message----- > From: Fabrice Gautier [mailto:fabrice.gautier@gmail.com] > Sent: Friday, January 10, 2014 2:18 PM > To: Andrei Popov > Cc: > Subject: Re: [TLS] NPN, ALPN and the case of renegotiation > > On Fri, Jan 10, 2014 at 1:58 PM, Andrei Popov wrote: >> Yes, both of these clarifications make sense to me. I think we should co= nsider clarifying this in the draft. >> > > Also consider clarifying that, in the case of a renegotiation without ALP= N extensions, after an initial handshake with ALPN extensions, the applicat= ion protocol should remain the same, and not fall back to the "sane default= ". > > Thats probably obvious, but you would not want a browser to fall back to = http 1.1 instead of http 2.0 or spdy because of a TLS renegotiation. > > -- Fabrice > > >> Thanks, >> >> Andrei >> >> -----Original Message----- >> From: Fabrice Gautier [mailto:fabrice.gautier@gmail.com] >> Sent: Friday, January 10, 2014 1:26 PM >> To: Andrei Popov >> Cc: >> Subject: Re: [TLS] NPN, ALPN and the case of renegotiation >> >> On Fri, Jan 10, 2014 at 1:08 PM, Andrei Popov wrote: >>> Hi Fabrice, >>> >>> I cannot speak to the design of NPN, but will answer the ALPN questions= : >>> >>> 2) If a client sent an ALPN extension in the first ClientHello, can it = send it again in a further negotiation ? >>> Yes, the client\server can renegotiate the application protocol at any = time. >>> >>> 4) If a client didn't send an ALPN extension in the first ClientHello,= may it send it in the next handshake ? >>> Yes, this can be used e.g. to make the application protocol negotiation= confidential. >> >> >> Then I suggest that the following sentence in the ALPN draft be reworded= to clarify this: >> >> The protocol identified in the >> >> "application_layer_protocol_negotiation" extension type in the >> ServerHello SHALL be definitive for the connection. >> >> At least something like: "SHALL be definitive for the connection, until = renegotiated" >> >> This raise another question: if the Application Protocol is renegotiated= when does the new application protocol starts? >> I'm assuming that it would be for new Application Data received after th= e ChangeCipherSpec and Finished messages, and that any Application that may= be interleaved with the earlier handshake message should still use the pre= vious application protocol. >> >> - Fabrice >> >> >>> Cheers, >>> >>> Andrei >>> >>> -----Original Message----- >>> From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Fabrice Gautier >>> Sent: Friday, January 10, 2014 11:17 AM >>> To: >>> Subject: [TLS] NPN, ALPN and the case of renegotiation >>> >>> Hi, >>> >>> When reading both NPN and ALPN drafts, I notice they both have this pa= ragraph: >>> >>> 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. >>> >>> However, only NPN has that one, immediately following: >>> >>> For the same reasons, after a handshake has been performed for a >>> given connection, renegotiations on the same connection MUST NOT >>> include the "next_protocol_negotiation" extension. >>> >>> >>> On the other hand, ALPN has this one a little further down: >>> >>> The protocol identified in the >>> "application_layer_protocol_negotiation" extension type in the >>> ServerHello SHALL be definitive for the connection. The server SHAL= L >>> NOT respond with a selected protocol and subsequently use a differen= t >>> protocol for application data exchange. >>> >>> >>> The question is: Should/can NPN/APLN extensions be sent/processed durin= g a renegotiation handshake ? >>> >>> So far I'm only confidently interpreting the above as: >>> 0) If NPN protocol was successfully selected during a handshake, the cl= ient should not send a NPN extension in its next client hello. >>> >>> I'm unsure of those other details though: >>> 1) If client sent an NPN extension in a ClientHello and did not get bac= k an NPN extension in the ServerHello, should/may the NPN client try the N= PN extension again in a re-handshake? >>> >>> I'm assuming it should not. >>> But somebody might come up with a reason for not wanting to provide the= supported protocols in the clear. Although one would argue that if Applica= tion Data is sent between the two handshake, then a protocol is selected an= d you should not be able to change it with NPN extensions, so the client mu= st not send the NPN extension in the renegotiation if they already received= or sent some application data. >>> >>> 2) If a client sent an ALPN extension in the first ClientHello, can it = send it again in a further negotiation ? >>> >>> I'm assuming it may, unless protocol was selected explicitly with a ALP= N ServerHello extension, or implicitly by sending/receiving some applicatio= n data. >>> >>> 3) If a client didn't send an NPN extension in the first ClientHello, m= ay it send it in the next handshake ? >>> >>> I'm assuming it should not. and I don't really see a privacy angle in t= hat case. >>> >>> 4) If a client didn't send an ALPN extension in the first ClientHello,= may it send it in the next handshake ? >>> >>> I'm assuming yes. This is useful in case you want to hide the protocols= supported and selected in a renegotiation (as indicated in Section 4 of AL= PN draft) Although again, if a protocol was implicitly selected by sending/= receiving data, it probably should not. >>> >>> >>> Are my assumptions mostly correct ? >>> >>> >>> Thanks >>> >>> >>> -- Fabrice >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls From paul.hoffman@vpnc.org Fri Jan 10 16:33:59 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70B761A8034 for ; Fri, 10 Jan 2014 16:33:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dI98dKvHWmj8 for ; Fri, 10 Jan 2014 16:33:56 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id A7B371A1F4C for ; Fri, 10 Jan 2014 16:33:56 -0800 (PST) Received: from [10.20.30.90] (50-1-51-230.dsl.dynamic.fusionbroadband.com [50.1.51.230]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id s0B0DkYT018078 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 10 Jan 2014 17:13:48 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-230.dsl.dynamic.fusionbroadband.com [50.1.51.230] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Paul Hoffman In-Reply-To: <1389385719.13026.20.camel@lapkaie> Date: Fri, 10 Jan 2014 16:33:29 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1389371947.30279.56.camel@lapkaie> <1DEAF365-97D4-493B-83C1-270AA9CD5670@vpnc.org> <1389385719.13026.20.camel@lapkaie> To: Kai Engert X-Mailer: Apple Mail (2.1827) Cc: "" Subject: Re: [TLS] Ideas for TLS 1.3: Server key continuity and certificate reporting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Jan 2014 00:33:59 -0000 On Jan 10, 2014, at 12:28 PM, Kai Engert wrote: > I'm motiviated to find ways to makes these ideas work with any TLS > connection, completely independent of the encapsulated application > protocol. OK, that would be likely to make it part of the TLS WG then. As others = have noted, the folks in the websec WG have discussed these issues = already and are considering some of them for HTTP-over-TLS. > I think a SMTP/TLS client could equally cache the previous cert and > potentially report it to the TLS server on a subsequent connection. I'm still wondering about what you are proposing for failures in key = continuity. > Where do you see differences that would cause it not to work with > protocols other than http? You don't say so explicitly, but I'm imagining that you will later add = "and if the key continuity fails, don't set up a connection". This = completely bolloxes using TLS for opportunistic encryption, which is the = common way to use it in SMTP/TLS. It could work in a = user-sitting-in-front-of-an-application scenario like HTTP and IMAP, but = not SMTP and others that basically use opportunistic TLS. --Paul Hoffman= From watsonbladd@gmail.com Fri Jan 10 16:36:49 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34DCF1AD190 for ; Fri, 10 Jan 2014 16:36:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWjtP1U8A-0m for ; Fri, 10 Jan 2014 16:36:47 -0800 (PST) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id 2621D1ACCFD for ; Fri, 10 Jan 2014 16:36:46 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id hn9so277454wib.7 for ; Fri, 10 Jan 2014 16:36:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=NxY9bIOkAgbtB10UYL1iFHMmmqDlH0Qr4e1Pfe+IUsM=; b=0Ei3OWgwHqiZaiXblsXzAtqxvjrcZ5phdESRYiDmwb0Aomoz/BBKClRuou7fem11WI 7G+pq/oS1Es6HNQYbHVnIhknorQ/gIwuuZvfClWNWdOGRqR8Xm5ad3LBG/jxJYUQcfxQ 2x2govCXZlL91n6JngFU+ZfdlSHTRF8KlR65O6zrVf4s1kmNfcchH3SPlLnx/IeF+37N 5DTUFAl0Wlz5S1TdAJdR+qYO4lqY31R/yE7aEn4qiGcyoS9nfsN88ClYGInyywpW3IDx 0XZDBrgXTwlzbe6HEXz0TKWHQ/2UTKY8FUEkPDx9ghzvFfJxEqFPm1FNS0X573a4sfh2 IUZA== MIME-Version: 1.0 X-Received: by 10.180.13.242 with SMTP id k18mr5173581wic.44.1389400596687; Fri, 10 Jan 2014 16:36:36 -0800 (PST) Received: by 10.194.242.131 with HTTP; Fri, 10 Jan 2014 16:36:36 -0800 (PST) In-Reply-To: References: <1389371947.30279.56.camel@lapkaie> <1DEAF365-97D4-493B-83C1-270AA9CD5670@vpnc.org> <1389385719.13026.20.camel@lapkaie> Date: Fri, 10 Jan 2014 16:36:36 -0800 Message-ID: From: Watson Ladd To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "" Subject: Re: [TLS] Ideas for TLS 1.3: Server key continuity and certificate reporting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Jan 2014 00:36:49 -0000 On Fri, Jan 10, 2014 at 4:33 PM, Paul Hoffman wrote= : > On Jan 10, 2014, at 12:28 PM, Kai Engert wrote: > >> I'm motiviated to find ways to makes these ideas work with any TLS >> connection, completely independent of the encapsulated application >> protocol. > > OK, that would be likely to make it part of the TLS WG then. As others ha= ve noted, the folks in the websec WG have discussed these issues already an= d are considering some of them for HTTP-over-TLS. > >> I think a SMTP/TLS client could equally cache the previous cert and >> potentially report it to the TLS server on a subsequent connection. > > I'm still wondering about what you are proposing for failures in key cont= inuity. > >> Where do you see differences that would cause it not to work with >> protocols other than http? > > You don't say so explicitly, but I'm imagining that you will later add "a= nd if the key continuity fails, don't set up a connection". This completely= bolloxes using TLS for opportunistic encryption, which is the common way t= o use it in SMTP/TLS. It could work in a user-sitting-in-front-of-an-applic= ation scenario like HTTP and IMAP, but not SMTP and others that basically u= se opportunistic TLS. We need to move to a world with no more plaintext. If someone is doing tricks in DANE, TACK will catch them. Opportunistic encryption is no encryption, even without MITM: a forged RST gets the plaintext. Putting TACK into TLS is a big step towards that goal. Sincerely, Watson > > --Paul Hoffman > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --=20 "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From paul.hoffman@vpnc.org Fri Jan 10 17:34:44 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B51061AD8F0 for ; Fri, 10 Jan 2014 17:34:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgYQyJWO-feR for ; Fri, 10 Jan 2014 17:34:43 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id C5A061A1F76 for ; Fri, 10 Jan 2014 17:34:43 -0800 (PST) Received: from [10.20.30.90] (50-1-51-230.dsl.dynamic.fusionbroadband.com [50.1.51.230]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id s0B1EUse019368 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 10 Jan 2014 18:14:32 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-230.dsl.dynamic.fusionbroadband.com [50.1.51.230] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Paul Hoffman In-Reply-To: Date: Fri, 10 Jan 2014 17:34:10 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1389371947.30279.56.camel@lapkaie> <1DEAF365-97D4-493B-83C1-270AA9CD5670@vpnc.org> <1389385719.13026.20.camel@lapkaie> To: Watson Ladd X-Mailer: Apple Mail (2.1827) Cc: "" Subject: Re: [TLS] Ideas for TLS 1.3: Server key continuity and certificate reporting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Jan 2014 01:34:44 -0000 On Jan 10, 2014, at 4:36 PM, Watson Ladd wrote: > On Fri, Jan 10, 2014 at 4:33 PM, Paul Hoffman = wrote: >> You don't say so explicitly, but I'm imagining that you will later = add "and if the key continuity fails, don't set up a connection". This = completely bolloxes using TLS for opportunistic encryption, which is the = common way to use it in SMTP/TLS. It could work in a = user-sitting-in-front-of-an-application scenario like HTTP and IMAP, but = not SMTP and others that basically use opportunistic TLS. >=20 > We need to move to a world with no more plaintext. Exactly right. That's why many SMTP servers use TLS in opportunistic = mode.=20 > If someone is doing > tricks in DANE, TACK will catch them. If someone is "doing tricks in DANE", then DANE was not designed = correctly. You should definitely bring those design errors to the DANE = WG. > Opportunistic encryption is > no encryption, even without MITM: a forged RST gets the plaintext. It does? I thought it gets the connection restarted, and TLS will get = set up again. > Putting TACK into TLS is a big step towards that goal. If your goal is to kill off opportunistic encryption, yes. I didn't get = the feeling that was Kai's goal with his proposal. --Paul Hoffman= From trevp@trevp.net Fri Jan 10 19:15:13 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FAE51ADF44 for ; Fri, 10 Jan 2014 19:15:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmBMS1AhhYlF for ; Fri, 10 Jan 2014 19:15:09 -0800 (PST) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id 9DBB51ADF0F for ; Fri, 10 Jan 2014 19:15:09 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id x12so2479241wgg.25 for ; Fri, 10 Jan 2014 19:14:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=g35H6zRXHEiDU0n1qw4ML3kwjVtM2hjDws/Wi3MVrU8=; b=JO2I6Vq1ywYTFnb+DatXVMO65GkIPZiEqpweY0UP1uwXNomjoVnndpS1AE0xoQa6iL V3Xh+DuK9cChgvxG7vhg4y9TBGHWfEN/Iu1VMLYcJ6HEhYzILLqSWZS6huzcnn/VqBO3 R37ByYG6Ohkua88CepW2PZCFv9SOQVtVejkDem21+BH7TnVTMZtJ8tvKVYdZwy+dRd8S e/iwytjuTC5d0+WQ49PEwYRuS/Hw6Zyqs72MyY0Pf1BaicJzatrow0DFzUjQvFmfz+Bs Gg/vSwhTq6tC9Ydrzae4KQsIJ52ufyxYaChxz0pRrhiVu6HyWfKmrw0YtukvhmWHGRRP NFfQ== X-Gm-Message-State: ALoCoQnbRbR+GpsuGIbvGIRPFYGned/YDOnCOfSu5T60yQAdqfkjTxUSpyYrcYC/S7sdnomdEiL5 MIME-Version: 1.0 X-Received: by 10.194.82.68 with SMTP id g4mr133640wjy.85.1389410099138; Fri, 10 Jan 2014 19:14:59 -0800 (PST) Received: by 10.216.214.134 with HTTP; Fri, 10 Jan 2014 19:14:59 -0800 (PST) X-Originating-IP: [199.83.223.81] In-Reply-To: References: <1389371947.30279.56.camel@lapkaie> <1DEAF365-97D4-493B-83C1-270AA9CD5670@vpnc.org> <1389385719.13026.20.camel@lapkaie> Date: Fri, 10 Jan 2014 19:14:59 -0800 Message-ID: From: Trevor Perrin To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "" Subject: Re: [TLS] Ideas for TLS 1.3: Server key continuity and certificate reporting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Jan 2014 03:15:13 -0000 On Fri, Jan 10, 2014 at 5:34 PM, Paul Hoffman wrote= : > On Jan 10, 2014, at 4:36 PM, Watson Ladd wrote: > >> On Fri, Jan 10, 2014 at 4:33 PM, Paul Hoffman wr= ote: >>> You don't say so explicitly, but I'm imagining that you will later add = "and if the key continuity fails, don't set up a connection". This complete= ly bolloxes using TLS for opportunistic encryption, which is the common way= to use it in SMTP/TLS. It could work in a user-sitting-in-front-of-an-appl= ication scenario like HTTP and IMAP, but not SMTP and others that basically= use opportunistic TLS. >> >> We need to move to a world with no more plaintext. > > Exactly right. That's why many SMTP servers use TLS in opportunistic mode= . > >> If someone is doing >> tricks in DANE, TACK will catch them. > > If someone is "doing tricks in DANE", then DANE was not designed correctl= y. You should definitely bring those design errors to the DANE WG. I'd guess he's talking about trust failures, such as your TLD signing a bad key for your domain. But having a second security check like pinning could also backstop design flaws we're unaware of, or software flaws in validating DNSSEC or certificate chains. >> Opportunistic encryption is >> no encryption, even without MITM: a forged RST gets the plaintext. > > It does? I thought it gets the connection restarted, and TLS will get set= up again. Let's all agree that opportunistic encryption is valuable, and adding authentication is even more valuable, and move on. >> Putting TACK into TLS is a big step towards that goal. > > If your goal is to kill off opportunistic encryption, yes. Ouch! Man, that's not true. TACK gives you a pinning check that could co-exist with another system (Web PKI, DNSSEC) or could be added to opportunistic encryption. I think your concern is for MTA-to-MTA SMTP where there's no user to "click through" pinning errors due to operator screwup. Instead, you're assuming the connection would hard-fail, and mail flow would be interrupted. "Report-only" handling of failures would probably be better. I.e., the sending MTA would notify its administrator if mails were delivered to a recipient MTA which had a pin validation failure. Anyways, interesting topic and more could be said. Perhaps the UTA list is a better place for application-specific discussion of TLS-layer pinning? Trevor From paul.hoffman@vpnc.org Fri Jan 10 19:49:03 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B7631ADF7E for ; Fri, 10 Jan 2014 19:49:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vGJdMIO70DYk for ; Fri, 10 Jan 2014 19:49:01 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id D94661ACCD8 for ; Fri, 10 Jan 2014 19:49:01 -0800 (PST) Received: from [10.20.30.90] (50-1-51-230.dsl.dynamic.fusionbroadband.com [50.1.51.230]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id s0B3Sqpq022234 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 10 Jan 2014 20:28:53 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-230.dsl.dynamic.fusionbroadband.com [50.1.51.230] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Paul Hoffman In-Reply-To: Date: Fri, 10 Jan 2014 19:48:29 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1389371947.30279.56.camel@lapkaie> <1DEAF365-97D4-493B-83C1-270AA9CD5670@vpnc.org> <1389385719.13026.20.camel@lapkaie> To: Trevor Perrin X-Mailer: Apple Mail (2.1827) Cc: "" Subject: Re: [TLS] Ideas for TLS 1.3: Server key continuity and certificate reporting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Jan 2014 03:49:03 -0000 On Jan 10, 2014, at 7:14 PM, Trevor Perrin wrote: > On Fri, Jan 10, 2014 at 5:34 PM, Paul Hoffman = wrote: >> On Jan 10, 2014, at 4:36 PM, Watson Ladd = wrote: >>> If someone is doing >>> tricks in DANE, TACK will catch them. >>=20 >> If someone is "doing tricks in DANE", then DANE was not designed = correctly. You should definitely bring those design errors to the DANE = WG. >=20 > I'd guess he's talking about trust failures, such as your TLD signing > a bad key for your domain. >=20 > But having a second security check like pinning could also backstop > design flaws we're unaware of, or software flaws in validating DNSSEC > or certificate chains. Again, my question is whether such checks have value in scenarios where = there is no user sitting there looking for warnings. >>> Opportunistic encryption is >>> no encryption, even without MITM: a forged RST gets the plaintext. >>=20 >> It does? I thought it gets the connection restarted, and TLS will get = set up again. >=20 > Let's all agree that opportunistic encryption is valuable, and adding > authentication is even more valuable, and move on. I would love to, but you can take that up with Watson. >>> Putting TACK into TLS is a big step towards that goal. >>=20 >> If your goal is to kill off opportunistic encryption, yes. >=20 > Ouch! Man, that's not true. Sorry, I was unclear. Putting TACK into TLS in a way that would force = user interaction when there were warnings would help kill off = opportunistic encryption, which is what Watson says he wants. Putting = TACK into TLS-for-HTTP will make key-substitution attacks more obvious = to the browser user, if the browser vendors put it in and figure out the = GUI for it. > TACK gives you a pinning check that could co-exist with another system > (Web PKI, DNSSEC) or could be added to opportunistic encryption. >=20 > I think your concern is for MTA-to-MTA SMTP where there's no user to > "click through" pinning errors due to operator screwup. Instead, > you're assuming the connection would hard-fail, and mail flow would be > interrupted. >=20 > "Report-only" handling of failures would probably be better. I.e., > the sending MTA would notify its administrator if mails were delivered > to a recipient MTA which had a pin validation failure. Yes, definitely. Having TACK, or whatever Kai was initially suggesting, = appear in SMTP security logs is probably a good thing. > Anyways, interesting topic and more could be said. Perhaps the UTA > list is a better place for application-specific discussion of > TLS-layer pinning? Kai's suggestion was for a feature that is built into TLS; that would be = the purview of this WG. If it is application-by-application (and not = just web browsers), it would be uta; if it is web browsers only it would = be websec. Whee... --Paul Hoffman= From simon@josefsson.org Sat Jan 11 08:33:09 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4E71AE046 for ; Sat, 11 Jan 2014 08:33:09 -0800 (PST) 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 AvCLJdzgXhmo for ; Sat, 11 Jan 2014 08:33:07 -0800 (PST) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) by ietfa.amsl.com (Postfix) with ESMTP id 49D111AE044 for ; Sat, 11 Jan 2014 08:33:06 -0800 (PST) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id s0BGWrE3012138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Sat, 11 Jan 2014 17:32:55 +0100 X-Hashcash: 1:22:140111:tls@ietf.org::VGEWgrE9aktwknTi:Atof From: Simon Josefsson To: tls@ietf.org OpenPGP: id=B565716F; url=http://josefsson.org/key.txt Date: Sat, 11 Jan 2014 17:32:53 +0100 Message-ID: <87eh4e7a2y.fsf@latte.josefsson.org> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.8 at duva.sjd.se X-Virus-Status: Clean Subject: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Jan 2014 16:33:09 -0000 Dear WG, I may have missed to announce this document before, since some people appear to have missed it. This email is an attempt to introduce the draft to the TLS WG properly. This draft started out as specifying Curve25519 ECDHE key agreement for TLS, back on September. Manuel Pegourie-Gonnard jumped in as co-author and has added details on public/private key representation, shared secret computation, and test vectors, for the -02 draft. In the latest -03 version of the draft, I have changed the document to specify EC Named Curve code points for all "additional elliptic curves" (i.e., Curve25519, E382, M383, Curve3617, M511, E521). Some of the Curve25519-related text may no longer be applicable to all curves, but hopefully that can be fixed later on. The latest draft is here: http://tools.ietf.org/html/draft-josefsson-tls-curve25519-03 The additional curves come from the following CFRG draft, and my current thinking is that our draft (for TLS) would stay in sync with the list of curves in the CFRG document. http://tools.ietf.org/html/draft-ladd-safecurves-02 We'd appreciate general feedback on the draft, especially if there is any interest in adopting this document, and particular feedback on the following points: 1) Do we need all these curves defined for TLS? What is the selection critera for including/exluding some of the curves? Is that a TLS process, or an CFRG process? 2) Does description of private/public key representation and computation of shared secret belong in draft-josefsson-tls-curve25519? It has to be somewhere, I believ, but possibly this could go into draft-ladd-safecurves, or some other generic document, unless there are TLS-specific aspects. Insight into this would be appreciated. Cheers, /Simon From lists@drh-consultancy.co.uk Sat Jan 11 09:28:38 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 307391AE085 for ; Sat, 11 Jan 2014 09:28:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.111 X-Spam-Level: X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, T_HK_NAME_DR=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 ZUX023PCIedJ for ; Sat, 11 Jan 2014 09:28:36 -0800 (PST) Received: from claranet-outbound-smtp02.uk.clara.net (claranet-outbound-smtp02.uk.clara.net [195.8.89.35]) by ietfa.amsl.com (Postfix) with ESMTP id EEEA01ADF46 for ; Sat, 11 Jan 2014 09:28:35 -0800 (PST) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:34145 helo=[192.168.7.9]) by relay12.mail.eu.clara.net (relay.clara.net [81.171.239.32]:10465) with esmtpa (authdaemon_plain:drh) id 1W22M8-0002rL-6u (return-path ); Sat, 11 Jan 2014 17:28:20 +0000 Message-ID: <52D17F30.1090008@drh-consultancy.co.uk> Date: Sat, 11 Jan 2014 17:28:16 +0000 From: Dr Stephen Henson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Simon Josefsson , tls@ietf.org References: <87eh4e7a2y.fsf@latte.josefsson.org> In-Reply-To: <87eh4e7a2y.fsf@latte.josefsson.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Jan 2014 17:28:38 -0000 On 11/01/2014 16:32, Simon Josefsson wrote: > > 2) Does description of private/public key representation and computation > of shared secret belong in draft-josefsson-tls-curve25519? It has to > be somewhere, I believ, but possibly this could go into > draft-ladd-safecurves, or some other generic document, unless there > are TLS-specific aspects. Insight into this would be appreciated. > A comment on the following paragraph: This document only describes usage of additional curves for ephemeral key exchange (ECDHE), not for use with long-term keys embedded in PKIX certificates (ECDH_ECDSA and ECDH_ECDSA). This is because Curve25519 is not directly suitable for authentication with ECDSA, and thus not applicable for signing of e.g. PKIX certificates. See draft-josefsson-eddsa-ed25519 for a parallel effort. Although the curves are not directly suitable for authentication this doesn't actually matter because the certificate doesn't have to be signed using the same curve or indeed the same algorithm. So it would (for example) permit a certificate containing a curve25519 key signed by a CA using a Brainpool curve (or even RSA with the relaxed CA signing rules of TLS 1.2). However to do that would require a standard for the use of curve25519 in certificates which currently doesn't exist. Having said that the static ECDH ciphersuites are rarely used and don't offer forward secrecy. IMHO a discussion of private/public key format should be in a separate document which would include an appropriate ASN1.1 format (e.g. PKCS#8 for private keys and SubjectPublicKeyInfo for public keys). That would enable the use of curve25519 (and other curves) in a wider range of applications, not just TLS. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From watsonbladd@gmail.com Sat Jan 11 09:31:18 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FEB61AE097 for ; Sat, 11 Jan 2014 09:31:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKYLwedoq9PH for ; Sat, 11 Jan 2014 09:31:16 -0800 (PST) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 9F54A1AE094 for ; Sat, 11 Jan 2014 09:31:16 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id l18so4317284wgh.29 for ; Sat, 11 Jan 2014 09:31:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AXrhxpAWEko4WyLkNft19hcB1KJyVgLPQ9Eq0eJYtLo=; b=RFHKm66zigAXotx4zXZGiqj7oU5N36kWvzTZu4WRX/Z/gYrHasXCxlUp9EpfGk6C5S 9dRpK+4VH6nosOnuG/yxo2r1LeHzV05ON7yDdm+TZF6BEPlF/YvDl3MB8vSLDBXb6Rmc 2tcnChtFNlJV8BV5y3keoVKrI4iUoIP0Qb3Kde5dS7cxHC1kHuq/O0bFnyHTYw07I2HO v1N1517/3voZf+QE8D2TOhHF/h+aAKzgd8W0FxI/Wsnzg4R0T9z6qT2w7Bb1NHy3nT/G Lb/o+b1O2jy1Phb+IJ/hYb38EaWUnw1zwQe3erlifiM8xO9jv9bzLJ80nQb1Chq32+gl Qneg== MIME-Version: 1.0 X-Received: by 10.194.133.34 with SMTP id oz2mr14260887wjb.14.1389461465896; Sat, 11 Jan 2014 09:31:05 -0800 (PST) Received: by 10.194.242.131 with HTTP; Sat, 11 Jan 2014 09:31:05 -0800 (PST) In-Reply-To: <52D17F30.1090008@drh-consultancy.co.uk> References: <87eh4e7a2y.fsf@latte.josefsson.org> <52D17F30.1090008@drh-consultancy.co.uk> Date: Sat, 11 Jan 2014 09:31:05 -0800 Message-ID: From: Watson Ladd To: Dr Stephen Henson Content-Type: text/plain; charset=UTF-8 Cc: Simon Josefsson , "tls@ietf.org" Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Jan 2014 17:31:18 -0000 On Sat, Jan 11, 2014 at 9:28 AM, Dr Stephen Henson wrote: > On 11/01/2014 16:32, Simon Josefsson wrote: > > Although the curves are not directly suitable for authentication this doesn't > actually matter because the certificate doesn't have to be signed using the same > curve or indeed the same algorithm. So it would (for example) permit a > certificate containing a curve25519 key signed by a CA using a Brainpool curve > (or even RSA with the relaxed CA signing rules of TLS 1.2). However to do that > would require a standard for the use of curve25519 in certificates which > currently doesn't exist. > > Having said that the static ECDH ciphersuites are rarely used and don't offer > forward secrecy. > > IMHO a discussion of private/public key format should be in a separate document > which would include an appropriate ASN1.1 format (e.g. PKCS#8 for private keys > and SubjectPublicKeyInfo for public keys). That would enable the use of > curve25519 (and other curves) in a wider range of applications, not just TLS. But for that we need an OID. Does anyone know where to get one/have one they want to assign? Sincerely, Watson Ladd > > Steve. > -- > Dr Stephen N. Henson. > Core developer of the OpenSSL project: http://www.openssl.org/ > Freelance consultant see: http://www.drh-consultancy.co.uk/ > Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From lists@drh-consultancy.co.uk Sat Jan 11 09:38:21 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29B071AE0D0 for ; Sat, 11 Jan 2014 09:38:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.111 X-Spam-Level: X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, T_HK_NAME_DR=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 OaAV4SC2NGTy for ; Sat, 11 Jan 2014 09:38:19 -0800 (PST) Received: from claranet-outbound-smtp02.uk.clara.net (claranet-outbound-smtp02.uk.clara.net [195.8.89.35]) by ietfa.amsl.com (Postfix) with ESMTP id 736AA1AE017 for ; Sat, 11 Jan 2014 09:38:19 -0800 (PST) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:10249 helo=[192.168.7.9]) by relay12.mail.eu.clara.net (relay.clara.net [81.171.239.32]:10465) with esmtpa (authdaemon_plain:drh) id 1W22Va-0005rb-9U (return-path ); Sat, 11 Jan 2014 17:38:07 +0000 Message-ID: <52D1817B.9090303@drh-consultancy.co.uk> Date: Sat, 11 Jan 2014 17:38:03 +0000 From: Dr Stephen Henson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Watson Ladd References: <87eh4e7a2y.fsf@latte.josefsson.org> <52D17F30.1090008@drh-consultancy.co.uk> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Simon Josefsson , "tls@ietf.org" Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Jan 2014 17:38:21 -0000 On 11/01/2014 17:31, Watson Ladd wrote: > On Sat, Jan 11, 2014 at 9:28 AM, Dr Stephen Henson > wrote: >> On 11/01/2014 16:32, Simon Josefsson wrote: >> >> Although the curves are not directly suitable for authentication this doesn't >> actually matter because the certificate doesn't have to be signed using the same >> curve or indeed the same algorithm. So it would (for example) permit a >> certificate containing a curve25519 key signed by a CA using a Brainpool curve >> (or even RSA with the relaxed CA signing rules of TLS 1.2). However to do that >> would require a standard for the use of curve25519 in certificates which >> currently doesn't exist. >> >> Having said that the static ECDH ciphersuites are rarely used and don't offer >> forward secrecy. >> >> IMHO a discussion of private/public key format should be in a separate document >> which would include an appropriate ASN1.1 format (e.g. PKCS#8 for private keys >> and SubjectPublicKeyInfo for public keys). That would enable the use of >> curve25519 (and other curves) in a wider range of applications, not just TLS. > > But for that we need an OID. Does anyone know where to get one/have > one they want to assign? > Private OID arcs are easy to obtain. The following has been suggested for curve25519: 1.3.6.1.4.1.3029.1.5.1 iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1) gutmann(3029) ???(1) ???(5) ???(1) If we want to use all the curves mentioned they will of course all need OIDs. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From rransom.8774@gmail.com Sat Jan 11 09:40:32 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FFBA1AE0D7 for ; Sat, 11 Jan 2014 09:40:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 syv6spcG2su9 for ; Sat, 11 Jan 2014 09:40:31 -0800 (PST) Received: from mail-qe0-x229.google.com (mail-qe0-x229.google.com [IPv6:2607:f8b0:400d:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC3A1AE0B7 for ; Sat, 11 Jan 2014 09:40:31 -0800 (PST) Received: by mail-qe0-f41.google.com with SMTP id gh4so5828378qeb.14 for ; Sat, 11 Jan 2014 09:40:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=k+QXYP60xlkin14cuKVZjQnj7LQ+fKJta4bF64oSo4c=; b=ER5hpDHKGf+FHkJ3t7I/qQ4NFOjLZvrF2cuUIekmeXdEjTr59ps+YT5XBZxkLGIG/e qQkIWF48lnDkv0J8/Mvp49TCYyV3Wls+rOt5Wu+GLKw+hjb6Lx8uBLh8UvUfgV3TM59s Y6sCkRRxxfZEwbNjAoQTzs+jOrFGXIm+9ZIQHc0v8WoZLg7Ql/90/aOt+eeATYWIGZZ6 pfPrRAW+BItSTpxK/lieAMv6+ghK33FnmciJkxmYagrGKBIegEJP9uZ8QovdIFRkt62p CsVErwmbdMeIenGqhOPan1jMQw79WxdAqBNVZlSdDL8PX83GGA/4NSA0ZnHXdLAU3fPS FTRA== MIME-Version: 1.0 X-Received: by 10.229.195.195 with SMTP id ed3mr20840815qcb.3.1389462020677; Sat, 11 Jan 2014 09:40:20 -0800 (PST) Received: by 10.229.181.132 with HTTP; Sat, 11 Jan 2014 09:40:20 -0800 (PST) In-Reply-To: <52D17F30.1090008@drh-consultancy.co.uk> References: <87eh4e7a2y.fsf@latte.josefsson.org> <52D17F30.1090008@drh-consultancy.co.uk> Date: Sat, 11 Jan 2014 09:40:20 -0800 Message-ID: From: Robert Ransom To: Dr Stephen Henson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Simon Josefsson , tls@ietf.org Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Jan 2014 17:40:32 -0000 On 1/11/14, Dr Stephen Henson wrote: > On 11/01/2014 16:32, Simon Josefsson wrote: >> >> 2) Does description of private/public key representation and computation >> of shared secret belong in draft-josefsson-tls-curve25519? It has to >> be somewhere, I believ, but possibly this could go into >> draft-ladd-safecurves, or some other generic document, unless there >> are TLS-specific aspects. Insight into this would be appreciated. >> > > A comment on the following paragraph: > > This document only describes usage of additional curves for ephemeral > key exchange (ECDHE), not for use with long-term keys embedded in > PKIX certificates (ECDH_ECDSA and ECDH_ECDSA). This is because > Curve25519 is not directly suitable for authentication with ECDSA, > and thus not applicable for signing of e.g. PKIX certificates. See > draft-josefsson-eddsa-ed25519 for a parallel effort. > > Although the curves are not directly suitable for authentication this > doesn't > actually matter because the certificate doesn't have to be signed using t= he > same > curve or indeed the same algorithm. Montgomery and Edwards curves can easily be used for signature schemes (remember that =E2=80=9Cauthentication=E2=80=9D can refer to protocols othe= r than signatures). The problem with using them in ECDSA is that ECDSA is specified in terms of curves in short-Weierstrass form, and having to map these curves to short-Weierstrass form would be ugly. Dr. Bernstein's EdDSA is even worse: it prohibits every curve that Dr. Bernstein himself has specified since Curve25519. It would be easy for a competent author to specify a signature scheme which doesn't constrain the point formats that it uses. Feng Hao's I-D specifying Schnorr proofs of knowledge could be used as a starting point for this. Robert Ransom From akr@akr.io Sat Jan 11 09:50:41 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6CEC1AE09E for ; Sat, 11 Jan 2014 09:50:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2AQMtabxBHTW for ; Sat, 11 Jan 2014 09:50:38 -0800 (PST) Received: from entima.net (entima.net [78.129.143.175]) by ietfa.amsl.com (Postfix) with ESMTP id AADD81AE085 for ; Sat, 11 Jan 2014 09:50:38 -0800 (PST) Received: from [10.10.42.10] (cpc5-derb12-2-0-cust796.8-3.cable.virginm.net [82.31.91.29]) by entima.net (Postfix) with ESMTPSA id 083966010F for ; Sat, 11 Jan 2014 17:50:28 +0000 (GMT) Message-ID: <52D18475.10709@akr.io> Date: Sat, 11 Jan 2014 17:50:45 +0000 From: Alyssa Rowan MIME-Version: 1.0 To: tls@ietf.org References: <87eh4e7a2y.fsf@latte.josefsson.org> In-Reply-To: <87eh4e7a2y.fsf@latte.josefsson.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Jan 2014 17:50:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11/01/2014 16:32, Simon Josefsson wrote: > [draft-josefsson-tls-curve25519-03] Strong interest here. Curve25519 in particular has extremely fast, public-domain constant-time implementations compared to, say, secp256r1, with better security, and a less clouded origin. Better forward security at a very fast speed? Yes please! 1. Representation - Endian I had thought that I might point out that all the existing routines in the wild use little-endian representations and so that might be a good reason to prefer that, so the routines can be used directly to accelerate rollout. But on reflection, pretty much everything else in internet standards goes big-endian, so there's consistency there, and an endian swap isn't exactly a big deal. No objection. 2. Monty & Eddie You list both Montgomery and Edwards curves in that list. I suggest just listing the Montgomery curves (Curve25519, M383 and M511) for this use, as these are the forms that are the very natural choices for ECDHE, with the handy x-coordinate-only feature. Edwards forms (Curve1174, E382, Curve3617, E521 in their natural states) are more eminently suitable for other uses like authentication (although definitely should not be used with ECDSA, and note EdDSA as specified is actually closely tied to Ed25519 - really we should specify a new derivative, which we should really get on with). You can also convert between the representations (e.g. Ed25519 is the twisted Edwards isomorphism of Curve25519). The ones which are naturally specified in Montgomery form have handy basepoints in that form. I'd suggest putting Curve25519 as a MUST to implement, and M383 and M511 as a MAY. 3. Security Considerations: Implementation Thoughtful. Do we need to directly specify that implementations MUST avoid side-channel attacks, because otherwise they might be tempted to implement them in a way that isn't constant-time? (There's a typo in that section, by the way; "22519".) 4. Other uses I think other uses of these curves, which should definitely be specified, should be specified in another draft (i.e. something like EdDSA one, though it may not end up being exactly EdDSA). We'll want OIDs for that. Can we get some for these "Chicago curves"? I gather there's one suggested for Curve25519: could Mr Gutmann perhaps please provide us with some for all of the others? (We could put them in the eventual CFRG informational RFC for posterity, then.) - -- /akr -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJS0YR1AAoJEOyEjtkWi2t6z3AP/jwvsUwcPawNSsT8hIxJkLg+ tj8kUMeyRpxv2gqzGudycxAwi9WVV9LD9ml7Up9dfRQfxbkIr1lj6Y3Xbf/UbMXe ENw9rvTz15p9p7fZJN8vb0Ab19xGptzwBtMl3sMeOy4eCeATLq0smpPqfgLNwl6m FHcP8Vx4zrvvs1OKPlgUEEwv6l6F6A5P4OytW48WmIVGMr4ud34JPJAv4OdscvXD 8jtythP1b2Pvr+j+03LP9b0beV74YgwlqCpyQtTmLF/W7WtmW1xdBs0mKP94bB/K 9AGH86pUuBi/fBfn9lUDBkaETx6EnN8r9Mzat96o9gL2DB+s8ML0+1ckZkORzISb VDVGxv5bZLBuW9zVlelsfAJO0az7DCaS5WKk3pKvhO9uT1R66EWpWwHJiJd4+TFB H85Ko+tU65xBwh5Er/uiLwCAq205D9GFxd+MZUfNOWIDQ8/8rx+OrAImDJbkOxwr +yOs7c1jbXlDaI9aA3j894d3ZDAFG5wal8m+gYRJumLfN8ufwr0bYYLpJy+DeFwN i1Ic+Jj8b513/YxKNdJNZcK6RtL7taDAv8jl7Yiym2ze8PMZWJtsqyL06KCeDt0C 9ZzGQGV/AoDiJ1xktFwZ1YGPcTavqq9167l/r9JP0v4riA1O1Xnr9LaVBs8Z2++D o2g0CcBzXK0AhWfLqfbC =nhGq -----END PGP SIGNATURE----- From lists@drh-consultancy.co.uk Sat Jan 11 09:56:59 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F4FD1AE0BB for ; Sat, 11 Jan 2014 09:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.111 X-Spam-Level: X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, T_HK_NAME_DR=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 pUpDf7eAHZ1Y for ; Sat, 11 Jan 2014 09:56:58 -0800 (PST) Received: from claranet-outbound-smtp01.uk.clara.net (claranet-outbound-smtp01.uk.clara.net [195.8.89.34]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBC61AE0A3 for ; Sat, 11 Jan 2014 09:56:58 -0800 (PST) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:55838 helo=[192.168.7.9]) by relay11.mail.eu.clara.net (relay.clara.net [81.171.239.31]:10465) with esmtpa (authdaemon_plain:drh) id 1W22nd-0005lz-5V (return-path ); Sat, 11 Jan 2014 17:56:45 +0000 Message-ID: <52D185DA.1030407@drh-consultancy.co.uk> Date: Sat, 11 Jan 2014 17:56:42 +0000 From: Dr Stephen Henson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Alyssa Rowan , tls@ietf.org References: <87eh4e7a2y.fsf@latte.josefsson.org> <52D18475.10709@akr.io> In-Reply-To: <52D18475.10709@akr.io> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Jan 2014 17:56:59 -0000 On 11/01/2014 17:50, Alyssa Rowan wrote: > > 3. Security Considerations: Implementation > > Thoughtful. Do we need to directly specify that implementations MUST > avoid side-channel attacks, because otherwise they might be tempted to > implement them in a way that isn't constant-time? > While that is a concern for long time use how significant is it for epehemeral ciphersuites? In that case the key is typically, generated one ECDH operation performed and then discarded. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From rransom.8774@gmail.com Sat Jan 11 09:58:33 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD751AE0E4 for ; Sat, 11 Jan 2014 09:58:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 YmUm3fgCTKkD for ; Sat, 11 Jan 2014 09:58:32 -0800 (PST) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 032931ADFA4 for ; Sat, 11 Jan 2014 09:58:31 -0800 (PST) Received: by mail-qc0-f170.google.com with SMTP id e9so4942904qcy.29 for ; Sat, 11 Jan 2014 09:58:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UkLn/0Xt8rOsZGqWUSZ+ktaPV9PSPWnhcvuPzjmNh9c=; b=0fsNsSMTIpBmwJJN4pu53bKh8r1BrRDv0f0iDCPRT3eZ94ek0pxgBSujtQtNSI+5mb BiknW90r0RWyH21JYMjtauueeQjJ6+obuKyi6oSWOg+2mXOTgQurKWYyxMVzIi0qgGCT BRZf1FiMZFiS4JhdRzApFq7WE81FsOXYqLJe73MuirjRJUlc8+q6ujbpXQYdSvbtTB7j tbop5fddZj07/nvYGreDnNWUut1oJtlgMlo44so7zmTAuP1Oju93F+NQTkmiukC43nGh PN8NxzJUEAk2/raVnmwLWveEApk5yDvSchhPAviIw7KVdvRxRe4AwtQdzWP+cTrbmdQ6 sgZA== MIME-Version: 1.0 X-Received: by 10.49.53.66 with SMTP id z2mr21177751qeo.45.1389463101488; Sat, 11 Jan 2014 09:58:21 -0800 (PST) Received: by 10.229.181.132 with HTTP; Sat, 11 Jan 2014 09:58:21 -0800 (PST) In-Reply-To: <52D18475.10709@akr.io> References: <87eh4e7a2y.fsf@latte.josefsson.org> <52D18475.10709@akr.io> Date: Sat, 11 Jan 2014 09:58:21 -0800 Message-ID: From: Robert Ransom To: Alyssa Rowan Content-Type: text/plain; charset=UTF-8 Cc: tls@ietf.org Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Jan 2014 17:58:33 -0000 On 1/11/14, Alyssa Rowan wrote: > 2. Monty & Eddie > > You list both Montgomery and Edwards curves in that list. I suggest > just listing the Montgomery curves (Curve25519, M383 and M511) for > this use, as these are the forms that are the very natural choices for > ECDHE, with the handy x-coordinate-only feature. Every Edwards curve listed on the SafeCurves web site can be used just as efficiently in Montgomery form. (The converse is not true -- curves with small-integer Montgomery parameter are needlessly unpleasant to use in Edwards form. No one should be generating new curves with small-integer Montgomery parameter.) > Edwards forms (Curve1174, E382, Curve3617, E521 in their natural > states) are more eminently suitable for other uses like authentication > (although definitely should not be used with ECDSA, and note EdDSA as > specified is actually closely tied to Ed25519 - really we should > specify a new derivative, which we should really get on with). > > You can also convert between the representations (e.g. Ed25519 is the > twisted Edwards isomorphism of Curve25519). The ones which are > naturally specified in Montgomery form have handy basepoints in that form. > > I'd suggest putting Curve25519 as a MUST to implement, and M383 and > M511 as a MAY. Don't use M383 and M511 -- their coordinate fields are awful. Curve3617 is much better; E-521 and Ed448-Goldilocks are okay. > 3. Security Considerations: Implementation > > Thoughtful. Do we need to directly specify that implementations MUST > avoid side-channel attacks, because otherwise they might be tempted to > implement them in a way that isn't constant-time? YES. Robert Ransom From akr@akr.io Sat Jan 11 10:17:13 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 813941AE074 for ; Sat, 11 Jan 2014 10:17:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wX6qocKIhSvM for ; Sat, 11 Jan 2014 10:17:12 -0800 (PST) Received: from entima.net (entima.net [78.129.143.175]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3061ACCE2 for ; Sat, 11 Jan 2014 10:17:11 -0800 (PST) Received: from [10.10.42.10] (cpc5-derb12-2-0-cust796.8-3.cable.virginm.net [82.31.91.29]) by entima.net (Postfix) with ESMTPSA id E9B6B6010F for ; Sat, 11 Jan 2014 18:17:00 +0000 (GMT) Message-ID: <52D18AAE.7050501@akr.io> Date: Sat, 11 Jan 2014 18:17:18 +0000 From: Alyssa Rowan MIME-Version: 1.0 To: tls@ietf.org References: <87eh4e7a2y.fsf@latte.josefsson.org> <52D18475.10709@akr.io> <52D185DA.1030407@drh-consultancy.co.uk> In-Reply-To: <52D185DA.1030407@drh-consultancy.co.uk> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Jan 2014 18:17:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11/01/2014 17:56, Dr Stephen Henson wrote: >> [the potential risks of non-constant-time ECDHE] > While that is a concern for long time use how significant is it for > epehemeral ciphersuites? In that case the key is typically, > generated one ECDH operation performed and then discarded. Hmm. I take your point: repeated attacks wouldn't be useful because the keys are different each time anyway, so side-channel attacks relying on iteration won't work - they'd have to be one-shot affairs, and side-channel attacks which work in one shot are extraordinarily rare and extremely contrived. Nevertheless, they are not quite so contrived as to be impossible in all cases, especially given a really determined adversary with proximity - and all the good implementations of these curves are already constant-time/memory-access patterns/etc. I don't think we really want to encourage the proliferation of ones that aren't (mostly due to the much higher risk that someone'll go ahead and unwittingly later use them in something that did need them to be constant-time!). I'd soften it to a SHOULD implement in a way which minimises the impact of any possible side-channel attack, but I'd make growly noises at anyone who didn't in practice. We've had enough timing troubles in TLS already: the opportunity to avoid another, even if it seems useless now, I think should be taken. - -- /akr -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJS0YquAAoJEOyEjtkWi2t6XwUP/0EZZFbp4VPcw/ozSvAHytRK 1QzMCT4zHAV+hvsUFp3Ao0XRXTBmeuApeKA5EnnCGQHyitI39/IAuiiHDw+uKWtc uMhBoSTI575raz/KqxE+DXhlhfnR3XtaFu/jtZhC52G7IHG2qhnTzNROd9gk7ocU YvszISzINIuiW2zSrg+Iq65oci3AJkT1YgtH2ko3hBD4qkCwYw7GEnCOONBvqxDb tw5rIQQSm4NKPqmacAkkRJpfGr+nJzGfifyYtqu+8K3TEtgjLkhUNvPDu3bNcRCZ LIXMP3uyEg/CnruM4+twHx3vdsqjJ71PbrYLDirkJlrS0Bmt65SaOepLYcVR8PSk gvlIwWE8yyBwCV5O3LqAi1Ila1R+RmDdKi865fv5TZDLunq8QZmNwhwWn70emNXE KTX1/TB7gw/GWyZt0AqhPo3/KzDZ1uHfb/acOyzjw8mDPxzPN3IyjOVnf6VyeIFA RQ0aJriSAtnVAzSV5c9CLcQEytzImtvm0PZDqMQLJeQJ+no6yKfp01iec9h0tWyX D602X3FtSbuMy1DNMw1TWBs4k1QTIk7FbV8JFdon8rmrAqXGz9FlEns7vCq0ht1R QcFT9cogVPSbiMWmzZHAQDOWDgxZ6Yfrr/Sp9osY0k/nkNslgME3gOxIPoYImcL/ VCkuhqv0alZWfetGmeg3 =/sJj -----END PGP SIGNATURE----- From alangley@gmail.com Sat Jan 11 11:03:52 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32A3B1AE103 for ; Sat, 11 Jan 2014 11:03:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KEIqbrGDuw8q for ; Sat, 11 Jan 2014 11:03:51 -0800 (PST) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) by ietfa.amsl.com (Postfix) with ESMTP id A708C1AE037 for ; Sat, 11 Jan 2014 11:03:50 -0800 (PST) Received: by mail-lb0-f181.google.com with SMTP id z5so1922445lbh.26 for ; Sat, 11 Jan 2014 11:03:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=xnAXDfg2R4TU3lvbU8iv82/7TH2IxTOW6dkFfyQkVQE=; b=qHI3pxxXGEf9xdDlB6YOOrk9L/9i4D3yGQ+4lLezU/KiGp3DuvadiT+PyFU6IpIbj8 AroXkYB+gr2urofaiPZBggd2N/O7xyEsiF2gerdY0S/ZXWld/ikG5Di+Gk5viPC9JUGy YEJiCV1xQN7OO6aRETeXRQkcIJDDyAIRqpVkG7aCI/3Sz+WBjKF645MUxcTa+apwn8+K g+JLvDPcy+LvaHVLnvtMUsL3vgvLbiJk7lzUBKpGRoF7R+FSQpGRwLbSyVLSvvMrMN3v madEvLAwjMNQ9fNjbifuGGCGOsgsHfJp4Uq3cLCU8WhCL//OzrH4syuq+4iEI/0hWoFb ML+A== MIME-Version: 1.0 X-Received: by 10.112.209.101 with SMTP id ml5mr117089lbc.70.1389467019572; Sat, 11 Jan 2014 11:03:39 -0800 (PST) Sender: alangley@gmail.com Received: by 10.112.162.200 with HTTP; Sat, 11 Jan 2014 11:03:39 -0800 (PST) In-Reply-To: <52D18475.10709@akr.io> References: <87eh4e7a2y.fsf@latte.josefsson.org> <52D18475.10709@akr.io> Date: Sat, 11 Jan 2014 14:03:39 -0500 X-Google-Sender-Auth: BylcDEuNinpkyZsNtAersIraINk Message-ID: From: Adam Langley To: Alyssa Rowan Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Jan 2014 19:03:52 -0000 On Sat, Jan 11, 2014 at 12:50 PM, Alyssa Rowan wrote: > But on reflection, pretty much everything else in internet standards > goes big-endian, so there's consistency there, and an endian swap > isn't exactly a big deal. No objection. Happy to see curve25519 specified, but I do object to this. Every curve25519 implementation follows djb's API, which is byte orientated. I think it's sensible to leave the exact field representation to the DH function rather than have that concept spill into TLS. Maybe future DH functions will want to save an inversion and send extended coordinates or something. Flipping the endianness just means that every single implementation has to undo it before feeding it into the curve25519 function. Cheers AGL From kurt@roeckx.be Sat Jan 11 11:09:33 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 384801AE148 for ; Sat, 11 Jan 2014 11:09:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15rY49vwxHIj for ; Sat, 11 Jan 2014 11:09:31 -0800 (PST) Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) by ietfa.amsl.com (Postfix) with ESMTP id CEF8C1AE0E9 for ; Sat, 11 Jan 2014 11:09:30 -0800 (PST) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 575901C20A7; Sat, 11 Jan 2014 20:09:19 +0100 (CET) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 349D21FE01CB; Sat, 11 Jan 2014 20:09:19 +0100 (CET) Date: Sat, 11 Jan 2014 20:09:19 +0100 From: Kurt Roeckx To: Alyssa Rowan Message-ID: <20140111190918.GA1820@roeckx.be> References: <87eh4e7a2y.fsf@latte.josefsson.org> <52D18475.10709@akr.io> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52D18475.10709@akr.io> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: tls@ietf.org Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Jan 2014 19:09:33 -0000 On Sat, Jan 11, 2014 at 05:50:45PM +0000, Alyssa Rowan wrote: > 3. Security Considerations: Implementation > > Thoughtful. Do we need to directly specify that implementations MUST > avoid side-channel attacks, because otherwise they might be tempted to > implement them in a way that isn't constant-time? So looking at currently available implementations of this, they are not all constant-time. See https://code.google.com/p/curve25519-donna/ for intance that the portable C version is marked as being none costant-time. The only other known portable implementation that I know of is by Matthew Dempsky that's part of nacl, for which I can't find any information about it being costant-time or not and assume it's not. Kurt From alangley@gmail.com Sat Jan 11 11:13:23 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E65D1AE155 for ; Sat, 11 Jan 2014 11:13:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zAO1U8IfpRJF for ; Sat, 11 Jan 2014 11:13:22 -0800 (PST) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 1748D1AE153 for ; Sat, 11 Jan 2014 11:13:21 -0800 (PST) Received: by mail-lb0-f175.google.com with SMTP id w6so4302619lbh.34 for ; Sat, 11 Jan 2014 11:13:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=KrjZpK6lt3SPUfrotiJmpjqcLzywvD8gSdpPjyX07ws=; b=v+QLvGKWlEHF5R/f8yKuxXme/CXpiCLQSaLaTwx2lH8dFDXf38treu9eugivb0Dwp2 +R7clAq2miBYjisb6gHroGQTnzaKteIJt+gSRUIFWVsf/eFSBJkUvo7mVPLl5wzFIhTa 2dYlvd0aJnK4V+XEZUGs9XP00j8IVm+eLIyB2u+BSyh9jkm553YQCO3j18QZa+1ETxOi tKm4NqfJgoKgDpSJET3JSJezcMNYckfkkKRZIERcsi7tCpcEjk6jXxp10T+4MQZ03Awp fow+QH4EW1ZZNafkedwrxiAu//I9tQuyBsAS4L6oJ1XKLbLCkljZeauBfmeOjQs7gneL VFWw== MIME-Version: 1.0 X-Received: by 10.152.6.232 with SMTP id e8mr98759laa.82.1389467591013; Sat, 11 Jan 2014 11:13:11 -0800 (PST) Sender: alangley@gmail.com Received: by 10.112.162.200 with HTTP; Sat, 11 Jan 2014 11:13:10 -0800 (PST) In-Reply-To: <20140111190918.GA1820@roeckx.be> References: <87eh4e7a2y.fsf@latte.josefsson.org> <52D18475.10709@akr.io> <20140111190918.GA1820@roeckx.be> Date: Sat, 11 Jan 2014 14:13:10 -0500 X-Google-Sender-Auth: xNikwGxnqg776-Ytm2Le4qPq1B8 Message-ID: From: Adam Langley To: Kurt Roeckx Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Jan 2014 19:13:23 -0000 On Sat, Jan 11, 2014 at 2:09 PM, Kurt Roeckx wrote: > So looking at currently available implementations of this, they > are not all constant-time. See > https://code.google.com/p/curve25519-donna/ for intance that the > portable C version is marked as being none costant-time. Actually, the Tor folks and others have fixed that. I just haven't updated the page. Cheers AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From frodo@baggins.org Sat Jan 11 11:43:00 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A5641ADA5D for ; Sat, 11 Jan 2014 11:43:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622] 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 HIYRtsWT6qaY for ; Sat, 11 Jan 2014 11:42:59 -0800 (PST) Received: from ns3.dns-engine.com (ns3.dns-engine.com [87.106.189.53]) by ietfa.amsl.com (Postfix) with ESMTP id EF4951AC829 for ; Sat, 11 Jan 2014 11:42:58 -0800 (PST) Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com [209.85.213.175]) by ns3.dns-engine.com (Postfix) with ESMTPSA id 53EE41824494 for ; Sat, 11 Jan 2014 19:42:45 +0000 (GMT) Received: by mail-ig0-f175.google.com with SMTP id uy17so1216975igb.2 for ; Sat, 11 Jan 2014 11:42:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0V9RmFZA8OFxFRGra3D06zZEmKOEPiJva6bNjnSnwQI=; b=egtQEcyia4/mjZLxf4svb9dwBYSeurNB2aNqSf0pnxQuDbOi29pEKs5uvntnuiLox9 oadRO/qY8bp08pvOTlA+Hyps0IU7npsufsBmwALVC+ZTcDck2vMIKm2+foY2i8t3ZkTO o2uCATHzIdPKEIgR2VfZdcowNUgH+8gpsZVrh5hcWTDO8KuiHpPEdwgCTe+/i+L5zf7u tfCC7stBUx5GIysyt+niyyXmCvS2bFYEenzwuK+asiIl5tTcsCRMyTsrzssMntCXK/eq n8D2DjAnEgdgT165lMpkBPedGgB5hXeqo4vFrkmtgrtwtY0FvuTXghlhSH0j35La6g+a ztcw== MIME-Version: 1.0 X-Received: by 10.42.18.68 with SMTP id w4mr13927778ica.22.1389469364171; Sat, 11 Jan 2014 11:42:44 -0800 (PST) Received: by 10.50.101.138 with HTTP; Sat, 11 Jan 2014 11:42:44 -0800 (PST) In-Reply-To: <52D1817B.9090303@drh-consultancy.co.uk> References: <87eh4e7a2y.fsf@latte.josefsson.org> <52D17F30.1090008@drh-consultancy.co.uk> <52D1817B.9090303@drh-consultancy.co.uk> Date: Sat, 11 Jan 2014 19:42:44 +0000 Message-ID: From: Matt Caswell To: Dr Stephen Henson Content-Type: text/plain; charset=ISO-8859-1 Cc: "tls@ietf.org" , Simon Josefsson Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Jan 2014 19:43:00 -0000 On 11 January 2014 17:38, Dr Stephen Henson wrote: > On 11/01/2014 17:31, Watson Ladd wrote: >> But for that we need an OID. Does anyone know where to get one/have >> one they want to assign? >> > > Private OID arcs are easy to obtain. The following has been suggested for > curve25519: > > 1.3.6.1.4.1.3029.1.5.1 > > iso(1) > identified-organization(3) > dod(6) > internet(1) > private(4) > enterprise(1) > gutmann(3029) > ???(1) > ???(5) > ???(1) > > If we want to use all the curves mentioned they will of course all need OIDs. Given that private OID arcs are easy to obtain would it not be better to get an IETF arc for this use, rather than using someone's personal arc? (Is there not an IETF arc already - that seems surprising!?) Matt From stephen.farrell@cs.tcd.ie Sat Jan 11 11:45:08 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1CD11ADF43 for ; Sat, 11 Jan 2014 11:45:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FaI_51e_xQVN for ; Sat, 11 Jan 2014 11:45:06 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 382391ADC03 for ; Sat, 11 Jan 2014 11:45:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BA5EBBE3E; Sat, 11 Jan 2014 19:44:54 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lr1MyFIdhaKC; Sat, 11 Jan 2014 19:44:53 +0000 (GMT) Received: from [10.87.48.14] (unknown [86.46.19.46]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C436CBE39; Sat, 11 Jan 2014 19:44:53 +0000 (GMT) Message-ID: <52D19F35.6050009@cs.tcd.ie> Date: Sat, 11 Jan 2014 19:44:53 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Matt Caswell , Dr Stephen Henson References: <87eh4e7a2y.fsf@latte.josefsson.org> <52D17F30.1090008@drh-consultancy.co.uk> <52D1817B.9090303@drh-consultancy.co.uk> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Simon Josefsson , "tls@ietf.org" Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Jan 2014 19:45:09 -0000 On 01/11/2014 07:42 PM, Matt Caswell wrote: > Given that private OID arcs are easy to obtain would it not be better > to get an IETF arc for this use, rather than using someone's personal > arc? (Is there not an IETF arc already - that seems surprising!?) Russ has managed a PKIX OID arc for years and is in the process of turning that into a set of IANA registries. I mailed him and the authors of these drafts so expect they'll figure it out. S. From ekr@rtfm.com Sat Jan 11 11:52:20 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFCA91ADA5D for ; Sat, 11 Jan 2014 11:52:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCfkYHkrNHh5 for ; Sat, 11 Jan 2014 11:52:19 -0800 (PST) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by ietfa.amsl.com (Postfix) with ESMTP id 4E19C1AD34C for ; Sat, 11 Jan 2014 11:52:19 -0800 (PST) Received: by mail-wi0-f177.google.com with SMTP id hm2so828455wib.16 for ; Sat, 11 Jan 2014 11:52:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=9xzVsVkaK+5ujsV+a8U/xgItRIL8uytq4xfaRx06dA8=; b=WhAuFK7HobIDoLyqV3kifuQKJGdFaL9Kyzr6qxm1BhFTIQlVAQvXHXzvDC+cbiUhBw oCO0UTub8EHIfVVcimaPvcgBls0gPVPYUV0lEuRARVPkV9a1s5Yn9vUtgkir+vUzQ20j aSA1pRTZFiNRGuLAedKafm5NuXQcAwzGIj4CI1B2d++CcbPgxxo/OpaOYzDcj/17162U MKXfCFTVQzbGvkvxLfUITVAq0Qid2CN5bghmfBflSYmNjppiDNyqpN7JQuSL4yp2vJ9w Mk5AZLhBm/uDUt1z2J9vNf2HX73jm44RtjouEyRhON0OT2ffq6D3vMxUULlUB8k95Ay0 iwWA== X-Gm-Message-State: ALoCoQn4L6YF7zioenm7/VziAoGAANOhP5c8J9/aaxikgDBstf1e3uuzqcIS4Lv0yHzIercvqz/5 X-Received: by 10.194.175.133 with SMTP id ca5mr14652383wjc.19.1389469928513; Sat, 11 Jan 2014 11:52:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.54.194 with HTTP; Sat, 11 Jan 2014 11:51:28 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: <87eh4e7a2y.fsf@latte.josefsson.org> References: <87eh4e7a2y.fsf@latte.josefsson.org> From: Eric Rescorla Date: Sat, 11 Jan 2014 11:51:28 -0800 Message-ID: To: Simon Josefsson Content-Type: text/plain; charset=ISO-8859-1 Cc: "tls@ietf.org" Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Jan 2014 19:52:21 -0000 On Sat, Jan 11, 2014 at 8:32 AM, Simon Josefsson wrote: > 1) Do we need all these curves defined for TLS? What is the selection > critera for including/exluding some of the curves? Is that a TLS > process, or an CFRG process? Speaking as chair: The TLS WG is not chartered (or qualified) to assess curves. What I believe is needed is for the IETF (whether directly or through the CFRG) to come to consensus on what curves we believe our protocols should support and then we can adopt them across the relevant security WGs, doing whatever protocol-specific work is required then. I've spoken with our AD about this a little bit, but as far as I know such an effort hasn't actually been started. Perhaps this is a topic for SAAG? -Ekr From frodo@baggins.org Sat Jan 11 12:01:07 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 886CE1AE0B6 for ; Sat, 11 Jan 2014 12:01:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622] 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 p9oS4zFtc-dn for ; Sat, 11 Jan 2014 12:01:06 -0800 (PST) Received: from ns3.dns-engine.com (ns3.dns-engine.com [87.106.189.53]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA621AE072 for ; Sat, 11 Jan 2014 12:01:06 -0800 (PST) Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com [209.85.223.176]) by ns3.dns-engine.com (Postfix) with ESMTPSA id 9D85918002C8 for ; Sat, 11 Jan 2014 20:00:52 +0000 (GMT) Received: by mail-ie0-f176.google.com with SMTP id at1so6400289iec.7 for ; Sat, 11 Jan 2014 12:00:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sx5qKeTdubZobazTOAN9udKNO6cCrZl0n9a8ALgs2Y4=; b=awWhcTRGCff3Ktbc6SkltJuLjVcwt2LYUVK+KAn0UPUdwgwaZpRiWWc6l1BQHvgLFT kuI5DRmhc6O4BuaZ1cYUkMFXCPKf92LownFXtpK/3CQNL5D97GRWE/RBQw1NwtzrvGDX f7exyvuV5ojvAlsrGVJ4d5ERcZAvJeCi1qma7TjCACm1BbK242N/EtXqph5IAONTBm82 hf8AsLrmZ3QQq6oi/HDXXVZRSX7ORZm2ozFGOd56Fx3nsodDdeW+sbitZSYj+VeYYbVY 2R2dQQF9sWU3Fy6HvUWi6yJC2oAuQl9ACywv/7bDW03h5PZuOlN8wOBK1VsJcGwdUwW/ s1Vw== MIME-Version: 1.0 X-Received: by 10.50.87.201 with SMTP id ba9mr10680161igb.21.1389470450887; Sat, 11 Jan 2014 12:00:50 -0800 (PST) Received: by 10.50.101.138 with HTTP; Sat, 11 Jan 2014 12:00:50 -0800 (PST) In-Reply-To: References: <87eh4e7a2y.fsf@latte.josefsson.org> Date: Sat, 11 Jan 2014 20:00:50 +0000 Message-ID: From: Matt Caswell To: Eric Rescorla Content-Type: text/plain; charset=ISO-8859-1 Cc: Simon Josefsson , "tls@ietf.org" Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Jan 2014 20:01:07 -0000 On 11 January 2014 19:51, Eric Rescorla wrote: > On Sat, Jan 11, 2014 at 8:32 AM, Simon Josefsson wrote: >> 1) Do we need all these curves defined for TLS? What is the selection >> critera for including/exluding some of the curves? Is that a TLS >> process, or an CFRG process? > > Speaking as chair: > > The TLS WG is not chartered (or qualified) to assess curves. What I > believe is needed is for the IETF (whether directly or through the > CFRG) to come to consensus on what curves we believe our > protocols should support and then we can adopt them across > the relevant security WGs, doing whatever protocol-specific > work is required then. > > I've spoken with our AD about this a little bit, but as far as I know > such an effort hasn't actually been started. Perhaps this is a topic > for SAAG? Isn't that exactly what Watson Ladd's draft is? That was initiated out of discussions within CFRG, and is currently being debated by CFRG. Matt From ekr@rtfm.com Sat Jan 11 12:41:15 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73CE81AE16E for ; Sat, 11 Jan 2014 12:41:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUM7T3gI6jFn for ; Sat, 11 Jan 2014 12:41:13 -0800 (PST) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC4E1AE155 for ; Sat, 11 Jan 2014 12:41:13 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id l18so1563663wgh.3 for ; Sat, 11 Jan 2014 12:41:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=b6IMFw6Bh1dLcartvO43nDiFOQYv7/QmiG1Hry8a+R4=; b=QDsE312bsBEgdlpmnNQV0MSZtivVDRs/4LS9MtESi8WGRprz1yDoSXNmcWgnGyPxb9 4YTx5wmyHhKGzcJpnUYqkkHY8MqARFmlShsS6q1k4nfMnJhfGZMrErxvjnnK+VJL+3UV lj1O3M8TU4f40nfVqpkpZ1UJozGAyBDpxBQ8ItsyJa0CLJptK/72pw8voG/0tmqjpIXF 39csOY8cStjHj/8JRCFlwi4nrGo/Qk1E4M/gu9Swr/ZqNH3Eafpdo9Ffsxz/xjpj9hSR GxLE1VEZ+SdoixRPZ15FTAIX3ztZu3fo42TQ50Nu3DvbP4aTFUApIHCiLUhnddSP+Q0I gVtw== X-Gm-Message-State: ALoCoQkdHLvsVh7h/55Lxxo0DCM9nI6EtIhI6KNIDnu+P0r3N8cYo3lNir1v3jFPYgmoTXEjpYsH X-Received: by 10.194.175.133 with SMTP id ca5mr14759739wjc.19.1389472862625; Sat, 11 Jan 2014 12:41:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.54.194 with HTTP; Sat, 11 Jan 2014 12:40:22 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: References: <87eh4e7a2y.fsf@latte.josefsson.org> From: Eric Rescorla Date: Sat, 11 Jan 2014 12:40:22 -0800 Message-ID: To: Matt Caswell Content-Type: text/plain; charset=ISO-8859-1 Cc: Simon Josefsson , "tls@ietf.org" Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Jan 2014 20:41:15 -0000 On Sat, Jan 11, 2014 at 12:00 PM, Matt Caswell wrote: > On 11 January 2014 19:51, Eric Rescorla wrote: >> On Sat, Jan 11, 2014 at 8:32 AM, Simon Josefsson wrote: >>> 1) Do we need all these curves defined for TLS? What is the selection >>> critera for including/exluding some of the curves? Is that a TLS >>> process, or an CFRG process? >> >> Speaking as chair: >> >> The TLS WG is not chartered (or qualified) to assess curves. What I >> believe is needed is for the IETF (whether directly or through the >> CFRG) to come to consensus on what curves we believe our >> protocols should support and then we can adopt them across >> the relevant security WGs, doing whatever protocol-specific >> work is required then. >> >> I've spoken with our AD about this a little bit, but as far as I know >> such an effort hasn't actually been started. Perhaps this is a topic >> for SAAG? > > Isn't that exactly what Watson Ladd's draft is? Perhaps. That's not quite clear to me from the draft, and for instance the title is "Additional Elliptic Curves for IETF protocols" and the contents seem to be, as promised, additional curves. The mailing list discussion seems consistent with that. What I believe is actually needed is not just definitions of new curves but a harmonized set of recommendations about which curves IETF should or should not use, which we can then use as a guide to protocol adoption and recommendation (see for instance http://tools.ietf.org/html/draft-sheffer-tls-bcp-01#section-4.1). Perhaps that's the endpoint of the CFRG discussion of draft-ladd, but just based on what I've seen so far it seems like a bigger discussion. I suspect the CFRG has a role to play here, but probably this is an IETF security area question as well. That's why I suggested this would be a good question for SAAG. -Ekr From martin.thomson@gmail.com Sat Jan 11 13:45:12 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFFDC1A1F58 for ; Sat, 11 Jan 2014 13:45:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u23tCX6ysAFL for ; Sat, 11 Jan 2014 13:45:11 -0800 (PST) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 634D31A1F55 for ; Sat, 11 Jan 2014 13:45:11 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id hq4so888189wib.3 for ; Sat, 11 Jan 2014 13:45:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ObmBrnFCpGnYWVc7IzDb6z4ZOHFHEmXKgWoRdbTkx8Y=; b=yOOjSmxTvire0m0Z4XCtQt2PLSfGjzc9IovphRwaqyNAtmNr5JU9kcwlv0uS50JqMu bjKPoWrPyO+5zaesEhAaHhSTEfUNocTDuLR5deQqv4I5Iq8iImW2Rvo1CI6r7pFij30m U4vX1FRNhYCDGdtzZX4hFlbP/d/S+SiBPWfuofTFwYwXqh8ecjlvjNvJHc2aA2W7vra/ fgEBOhurznPHgXQycXG4eOszYvNzBWL2YJPPcNYE4OSCkoEgXyypfEx8gCWmcdZ5NsOF mlagOzQeAktWy6KxBcMm+7hgREPFnuxyIHNFXtL3oE44mW/fWEw0MPmIDPZwflsnusbG WjQA== MIME-Version: 1.0 X-Received: by 10.194.192.233 with SMTP id hj9mr533727wjc.78.1389476700593; Sat, 11 Jan 2014 13:45:00 -0800 (PST) Received: by 10.227.134.195 with HTTP; Sat, 11 Jan 2014 13:45:00 -0800 (PST) In-Reply-To: References: <796edc1745504aa5863925cf03bc9df0@BL2PR03MB419.namprd03.prod.outlook.com> Date: Sat, 11 Jan 2014 13:45:00 -0800 Message-ID: From: Martin Thomson To: Andrei Popov Content-Type: text/plain; charset=UTF-8 Cc: "" Subject: Re: [TLS] NPN, ALPN and the case of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Jan 2014 21:45:13 -0000 On 10 January 2014 15:12, Andrei Popov wrote: > Regarding the "sane default", I could see this both ways, and I don't think this belongs in a document produced by the TLS WG. That's right. For HTTP, it's fairly obvious that absent ALPN, we get HTTP/1.1 (or predecessors). It might be different for new protocols, but new protocols also get to consider the option of making ALPN "MUST use". From rsalz@akamai.com Sat Jan 11 13:57:40 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EAA91A1F62 for ; Sat, 11 Jan 2014 13:57:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RgbIphtImwU for ; Sat, 11 Jan 2014 13:57:39 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 65C541A1F61 for ; Sat, 11 Jan 2014 13:57:39 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id AC7D0473AF; Sat, 11 Jan 2014 21:57:28 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 9F1EB473AE; Sat, 11 Jan 2014 21:57:28 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 9B91F2029; Sat, 11 Jan 2014 21:57:28 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.77]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Sat, 11 Jan 2014 16:57:28 -0500 From: "Salz, Rich" To: Matt Caswell , Dr Stephen Henson Date: Sat, 11 Jan 2014 16:57:27 -0500 Thread-Topic: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement Thread-Index: Ac8PBVLv96navzoATdS6GGiF85KxOAAEqU8w Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711E8766BEF@USMBX1.msg.corp.akamai.com> References: <87eh4e7a2y.fsf@latte.josefsson.org> <52D17F30.1090008@drh-consultancy.co.uk> <52D1817B.9090303@drh-consultancy.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Simon Josefsson , "tls@ietf.org" Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Jan 2014 21:57:40 -0000 > Given that private OID arcs are easy to obtain would it not be better to = get an IETF arc for this use, rather than using someone's personal arc? It absolutely shouldn't matter; OID's are opaque identifiers and a "vanity = IETF" number is silly. It's much more sensible to use something that is al= ready in use. /r$ -- =20 Principal Security Engineer Akamai Technology Cambridge, MA From frodo@baggins.org Sat Jan 11 14:35:30 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB8991ACCF0 for ; Sat, 11 Jan 2014 14:35:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622] 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 y715Y4p6Ll_k for ; Sat, 11 Jan 2014 14:35:30 -0800 (PST) Received: from ns3.dns-engine.com (ns3.dns-engine.com [87.106.189.53]) by ietfa.amsl.com (Postfix) with ESMTP id C5EEB1ACCED for ; Sat, 11 Jan 2014 14:35:29 -0800 (PST) Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) by ns3.dns-engine.com (Postfix) with ESMTPSA id 05E5E1824650 for ; Sat, 11 Jan 2014 22:35:14 +0000 (GMT) Received: by mail-ie0-f181.google.com with SMTP id e14so6315755iej.26 for ; Sat, 11 Jan 2014 14:35:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Qf7nvOy0QoPhSFTeEbLt4W++n6VZhvCZ4YSAaEHNlnc=; b=WAesBfUE/vKze1Qs4c7KJyq/JraV+nIJA2jjIPGM4cyklMXhGUKmjk6IER6soy/Irj U66Xr77Au2lQIXQ35LnhFZSuyIpqWEJqW+tcm2wLIkaAkHE7OG6xomw+6NwDSeCQAyYR /8buGtgCc0BqlxWS0bfOyGBYegNfgy3VSI6fKfWGwrDF9TLqF/I4/Hx9F1UwABVCDtcq MUzXKjHeXIXDA6LOFlwv/vl42vz7boJDatq8oI9pmyTzFuClftCzCbr2p6S2jvmppB2u WZ1quMJS73SxuqQCBlOGvmrcplzneGKS9R2YMeOiM5n3jsEvMOCqxrqx1t04bZWgDaM7 OT0A== MIME-Version: 1.0 X-Received: by 10.50.154.102 with SMTP id vn6mr11112896igb.15.1389479713488; Sat, 11 Jan 2014 14:35:13 -0800 (PST) Received: by 10.50.101.138 with HTTP; Sat, 11 Jan 2014 14:35:13 -0800 (PST) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711E8766BEF@USMBX1.msg.corp.akamai.com> References: <87eh4e7a2y.fsf@latte.josefsson.org> <52D17F30.1090008@drh-consultancy.co.uk> <52D1817B.9090303@drh-consultancy.co.uk> <2A0EFB9C05D0164E98F19BB0AF3708C711E8766BEF@USMBX1.msg.corp.akamai.com> Date: Sat, 11 Jan 2014 22:35:13 +0000 Message-ID: From: Matt Caswell To: "Salz, Rich" Content-Type: text/plain; charset=ISO-8859-1 Cc: Simon Josefsson , "tls@ietf.org" Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Jan 2014 22:35:30 -0000 On 11 January 2014 21:57, Salz, Rich wrote: >> Given that private OID arcs are easy to obtain would it not be better to get an IETF arc for this use, rather than using someone's personal arc? > > It absolutely shouldn't matter; OID's are opaque identifiers and a "vanity IETF" number is silly. It's much more sensible to use something that is already in use. For Curve25519 possibly (although I hadn't got the impression that the proposed OID had seen any significant deployment) - but there are a number of other curves in need of OIDs. I also wouldn't see an IETF arc as a "vanity" arc. It's a clear marker of those OIDs that have some backing of a standards authority. No big deal - but if setting one up is easy to do, why would we not want to do that? Its probably a moot point, because from Stephen Farrell's response it seems like there is something we can use anyway. Matt From pgut001@cs.auckland.ac.nz Sat Jan 11 22:01:50 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E58211ADF24 for ; Sat, 11 Jan 2014 22:01:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhr43raSdbv1 for ; Sat, 11 Jan 2014 22:01:48 -0800 (PST) Received: from mx1.auckland.ac.nz (mx1.auckland.ac.nz [130.216.125.243]) by ietfa.amsl.com (Postfix) with ESMTP id BA9441ADBCE for ; Sat, 11 Jan 2014 22:01:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1389506498; x=1421042498; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=Qmm/9yaMGvUJYD3MiI39WNwFtQAKf3kZUPSh3sgLnxM=; b=TMzavwCEBgNk3f+nwTWCn/1ixJP5LguNDO94wGlWs598Q2z/WwtpWw3f gYWxHuIx62x30JMsgEGe6p4aEg1WTdWabU6w1ucPsTDSuG0qdg4LhTcyV dlHF+i9a2t2GAloDZNWdz4ohH2n+/2rmjaZI1jSph7ZttrlKYyVN+hS0C s=; X-IronPort-AV: E=Sophos;i="4.95,646,1384254000"; d="scan'208";a="306868589" 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 mx1-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 12 Jan 2014 19:01:34 +1300 Received: from UXCN10-TDC06.UoA.auckland.ac.nz ([169.254.11.205]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0158.001; Sun, 12 Jan 2014 19:01:33 +1300 From: Peter Gutmann To: Watson Ladd , Simon Josefsson , "tls@ietf.org" Thread-Topic: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement Thread-Index: Ac8PW744OJeLdwUWS46HyuHEXefTGw== Date: Sun, 12 Jan 2014 06:01:32 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73723576AE@uxcn10-tdc06.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 Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Jan 2014 06:01:51 -0000 Dr Stephen Henson writes:=0A= =0A= >If we want to use all the curves mentioned they will of course all need OI= Ds.=0A= =0A= The arc for 25519 is:=0A= =0A= iso(1) identified-organization(3) dod(6) internet(1) private(4)=0A= enterprise(1) dds(3029) algorithm(1) ecc(5) curve25519(1)=0A= =0A= This discussion is unfortunately spread across a few too many lists, I=0A= mentioned on the CFRG list:=0A= =0A= I can assign them under the same arc as the -25519 curve. Or I can deleg= ate=0A= it to someone else if they want to act as a registrar. I'm happy to do i= t,=0A= but I don't want to make myself the bottleneck.=0A= =0A= Peter.= From ilari.liusvaara@elisanet.fi Sat Jan 11 22:29:58 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 433A41ADF4D for ; Sat, 11 Jan 2014 22:29:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVTsinH2kVe3 for ; Sat, 11 Jan 2014 22:29:55 -0800 (PST) Received: from emh01.mail.saunalahti.fi (emh01.mail.saunalahti.fi [62.142.5.107]) by ietfa.amsl.com (Postfix) with ESMTP id 254BA1ADF0F for ; Sat, 11 Jan 2014 22:29:54 -0800 (PST) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id EA69E900AF; Sun, 12 Jan 2014 08:29:42 +0200 (EET) Date: Sun, 12 Jan 2014 08:29:42 +0200 From: Ilari Liusvaara To: Alyssa Rowan Message-ID: <20140112062942.GA32437@LK-Perkele-VII> References: <87eh4e7a2y.fsf@latte.josefsson.org> <52D18475.10709@akr.io> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <52D18475.10709@akr.io> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Ilari Liusvaara Cc: tls@ietf.org Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Jan 2014 06:29:58 -0000 On Sat, Jan 11, 2014 at 05:50:45PM +0000, Alyssa Rowan wrote: > > Edwards forms (Curve1174, E382, Curve3617, E521 in their natural > states) are more eminently suitable for other uses like authentication > (although definitely should not be used with ECDSA, and note EdDSA as > specified is actually closely tied to Ed25519 - really we should > specify a new derivative, which we should really get on with). As far as I know (from reading the Ed25519 paper), no, EdDSA is not tied to Ed25519. Quoting the paper: "Choice of curve. Our recommended curve for EdDSA is a twisted Edwards curve birationally equivalent to the curve Curve25519 from [12]." Note the word "recommended". One problem with defining EdDSA for larger curves is that the needed hashes are large. Even if one uses ~3/2 expansion (largest possible for certain pretty simple modulo algorithm), even E382 is going to blow 512 bits. And there are very few hashes with serious analysis that can do >512 bits. -Ilari From pgut001@cs.auckland.ac.nz Sat Jan 11 22:40:20 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A11071ADF51 for ; Sat, 11 Jan 2014 22:40:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VlXauY2uGMhN for ; Sat, 11 Jan 2014 22:40:17 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 244961ADF0F for ; Sat, 11 Jan 2014 22:40:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1389508807; x=1421044807; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=Z4lDMhYaH1jAFRBu27tlxRaeXZMg5EC+9PxZOzeoffA=; b=i4/stb0ud9e7VPUI1eOiMUnwtXMcTtYZEOMsvUNvT2UjJ4uLduIIHJl8 FJEkupQePl5r0npuQdeU75mc1fJE1Th4SWJJrx/wkWrL9fGiGkFnAlLoF WR8OfC1V0wjj3GmeuHpL8kEFIYRFSeZaYEaNr/7pPV8H0jcQF9Bjx/FuI 0=; X-IronPort-AV: E=Sophos;i="4.95,646,1384254000"; d="scan'208";a="229237080" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 12 Jan 2014 19:40:05 +1300 Received: from UXCN10-TDC06.UoA.auckland.ac.nz ([169.254.11.205]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0158.001; Sun, 12 Jan 2014 19:40:05 +1300 From: Peter Gutmann To: "tls@ietf.org" Thread-Topic: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement Thread-Index: Ac8PYSC7AfNVRo+nT86peDkQ7rW+5w== Date: Sun, 12 Jan 2014 06:40:05 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C7372357712@uxcn10-tdc06.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 Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Jan 2014 06:40:20 -0000 Ilari Liusvaara writes:=0A= =0A= >One problem with defining EdDSA for larger curves is that the needed hashe= s=0A= >are large.=0A= =0A= Are they? You can use SHA-256 for everything if you want to keep things=0A= manageable.=0A= =0A= (Unless there's some odd requirement in TLS 1.2 that says that the hash has= to=0A= match the curve size).=0A= =0A= Peter.= From ilari.liusvaara@elisanet.fi Sat Jan 11 23:06:32 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 576931ADF4E for ; Sat, 11 Jan 2014 23:06:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BgD82rv-vfMR for ; Sat, 11 Jan 2014 23:06:31 -0800 (PST) Received: from emh07.mail.saunalahti.fi (emh07.mail.saunalahti.fi [62.142.5.117]) by ietfa.amsl.com (Postfix) with ESMTP id BC82E1ADF4B for ; Sat, 11 Jan 2014 23:06:29 -0800 (PST) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id 92A8240CD; Sun, 12 Jan 2014 09:06:15 +0200 (EET) Date: Sun, 12 Jan 2014 09:06:15 +0200 From: Ilari Liusvaara To: Peter Gutmann Message-ID: <20140112070614.GA1897@LK-Perkele-VII> References: <9A043F3CF02CD34C8E74AC1594475C7372357712@uxcn10-tdc06.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C7372357712@uxcn10-tdc06.UoA.auckland.ac.nz> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Ilari Liusvaara Cc: "tls@ietf.org" Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Jan 2014 07:06:32 -0000 On Sun, Jan 12, 2014 at 06:40:05AM +0000, Peter Gutmann wrote: > Ilari Liusvaara writes: > > >One problem with defining EdDSA for larger curves is that the needed hashes > >are large. > > Are they? You can use SHA-256 for everything if you want to keep things > manageable. > > (Unless there's some odd requirement in TLS 1.2 that says that the hash has to > match the curve size). EdDSA internally uses a hash in some places, and Ed25519 (which is ~255 bit curve) defines that hash to be SHA-512. Actually, reading the spec more carefully, the equations given for EdDSA seem to assume cofactor 8 (all the E-curves are cofactor 4 by design) and double- width hash. Cofactor 4 would at least need replacing some constants... -Ilari From rransom.8774@gmail.com Sat Jan 11 23:12:10 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 032B11ADF59 for ; Sat, 11 Jan 2014 23:12:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 w1keHVsxx9iY for ; Sat, 11 Jan 2014 23:12:08 -0800 (PST) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 9BAAD1ACC7E for ; Sat, 11 Jan 2014 23:12:08 -0800 (PST) Received: by mail-qa0-f43.google.com with SMTP id k15so5395957qaq.2 for ; Sat, 11 Jan 2014 23:11:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BcVkA5sJmBQwhqE9sj9VbYoWDQhfXYbzB6PQW8GDfIw=; b=C2/xif129ztezYU8KAZb+/5Bs1KCMbNGmMdjF7zv8ZzTTUOKuDlEQJYzrTs9OrJhbc 0+7BRmUGfctT7sF52QFl7WozdlgU2gBAr01xzg8Re3yBJaELE3RbQgxH8T7hSeth/eG5 +y7K3K7E5A0Fw/myFzxyt6QDL5esYN4mCyhwyK29UQgr7GvSx01cTgJZ2fLotRKmbzBl zmMiGh/LuBFCL40HGEC44/ZP2syi5KdaIlixdiOm8uOnaJwxVunFOZ57UrIA1GZ5YhUp OMonYIqee3ErkuNvzPJfMDBObB1sF16pvqHqasKPiU7Ufxb+0uFaWU5PxgY/h6qb32xC Cs0g== MIME-Version: 1.0 X-Received: by 10.224.53.71 with SMTP id l7mr26042187qag.33.1389510717940; Sat, 11 Jan 2014 23:11:57 -0800 (PST) Received: by 10.229.181.132 with HTTP; Sat, 11 Jan 2014 23:11:57 -0800 (PST) In-Reply-To: <20140112070614.GA1897@LK-Perkele-VII> References: <9A043F3CF02CD34C8E74AC1594475C7372357712@uxcn10-tdc06.UoA.auckland.ac.nz> <20140112070614.GA1897@LK-Perkele-VII> Date: Sat, 11 Jan 2014 23:11:57 -0800 Message-ID: From: Robert Ransom To: Ilari Liusvaara Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Jan 2014 07:12:10 -0000 On 1/11/14, Ilari Liusvaara wrote: > On Sun, Jan 12, 2014 at 06:40:05AM +0000, Peter Gutmann wrote: >> Ilari Liusvaara writes: >> >> >One problem with defining EdDSA for larger curves is that the needed >> > hashes >> >are large. >> >> Are they? You can use SHA-256 for everything if you want to keep things >> manageable. >> >> (Unless there's some odd requirement in TLS 1.2 that says that the hash >> has to >> match the curve size). > > EdDSA internally uses a hash in some places, and Ed25519 (which is ~255 bit > curve) defines that hash to be SHA-512. > > Actually, reading the spec more carefully, the equations given for EdDSA > seem > to assume cofactor 8 (all the E-curves are cofactor 4 by design) and > double- > width hash. has more. The root cause is that EdDSA requires twisted Edwards form with a=-1. A good signature scheme for use within IETF should not fix the group-element format. Robert Ransom From rransom.8774@gmail.com Sat Jan 11 23:13:38 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 090561ADF5D for ; Sat, 11 Jan 2014 23:13:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 uCZ5d-4i3zX7 for ; Sat, 11 Jan 2014 23:13:37 -0800 (PST) Received: from mail-qe0-x22a.google.com (mail-qe0-x22a.google.com [IPv6:2607:f8b0:400d:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 1800F1ACC7E for ; Sat, 11 Jan 2014 23:13:36 -0800 (PST) Received: by mail-qe0-f42.google.com with SMTP id b4so6020565qen.15 for ; Sat, 11 Jan 2014 23:13:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ca6sN8DM+370D38N9/KWWNDfwxKzZjoiqE9UpgqjA+o=; b=FteiNQ7nO/S/N2Ndc0UB8sH/iBy7wbN9Qr2EXkaHGDrfDbcrofc7Mn4ntBvwn+SbK6 gUz537x6sY7UMFR9vUOrjZ9nyBo7jMqou57w5wF/kqfDmc2Rjsel832b+OjhSieJj3Zh jvb2UxtnFVcvKKYTWtetPMj2v0P5mhMdT5Gz+CXJ9/7VcGQyv0f6s0kBtT3qRuHFDjy4 8ChxdDnUdXtOtzpo5HQNXgkvHYH304ohvoSt8lDdLqO1WJ5XVS7f4aGXP76yUnityYmv gkAEJCKV75mo8Zpps76mslWVBSWWqPN3qmG5D8FcaHK1zVgTG+yFLs3/tcsgcfRnS2YX Sphg== MIME-Version: 1.0 X-Received: by 10.229.14.1 with SMTP id e1mr13602064qca.15.1389510806455; Sat, 11 Jan 2014 23:13:26 -0800 (PST) Received: by 10.229.181.132 with HTTP; Sat, 11 Jan 2014 23:13:26 -0800 (PST) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C7372357712@uxcn10-tdc06.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C7372357712@uxcn10-tdc06.UoA.auckland.ac.nz> Date: Sat, 11 Jan 2014 23:13:26 -0800 Message-ID: From: Robert Ransom To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Jan 2014 07:13:38 -0000 On 1/11/14, Peter Gutmann wrote: > Ilari Liusvaara writes: > >>One problem with defining EdDSA for larger curves is that the needed >> hashes >>are large. > > Are they? You can use SHA-256 for everything if you want to keep things > manageable. EdDSA uses its hash function in two other places: * to expand the EdDSA secret key into two secrets: the secret exponent of the public key, and a secret hash input Z; and * to generate the per-message secret random exponents as a secretly deterministic function of Z. The latter use is the big issue. Robert Ransom From ilari.liusvaara@elisanet.fi Sat Jan 11 23:54:20 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA211ADF4F for ; Sat, 11 Jan 2014 23:54:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ybm55sUoREWS for ; Sat, 11 Jan 2014 23:54:18 -0800 (PST) Received: from emh03.mail.saunalahti.fi (emh03.mail.saunalahti.fi [62.142.5.109]) by ietfa.amsl.com (Postfix) with ESMTP id 726261ADF4D for ; Sat, 11 Jan 2014 23:54:18 -0800 (PST) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id D1411188774; Sun, 12 Jan 2014 09:54:05 +0200 (EET) Date: Sun, 12 Jan 2014 09:54:05 +0200 From: Ilari Liusvaara To: Robert Ransom Message-ID: <20140112075405.GB1897@LK-Perkele-VII> References: <9A043F3CF02CD34C8E74AC1594475C7372357712@uxcn10-tdc06.UoA.auckland.ac.nz> <20140112070614.GA1897@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.21 (2010-09-15) Sender: Ilari Liusvaara Cc: "tls@ietf.org" Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Jan 2014 07:54:20 -0000 On Sat, Jan 11, 2014 at 11:11:57PM -0800, Robert Ransom wrote: > > The root cause is that EdDSA requires twisted Edwards form with a=-1. > A good signature scheme for use within IETF should not fix the > group-element format. Well, even if one drops all constraints that don't have obvious reasons[1] and generalizes the formulas so math works there still are some group elements in fixed format, specifically, due to the H(R,A,m) factor. [1] e.g. a=-1, h=8, p=4k+1, H is 2b bits. -Ilari From mpg@polarssl.org Sun Jan 12 06:47:56 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6A11ADED7 for ; Sun, 12 Jan 2014 06:47:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.394 X-Spam-Level: X-Spam-Status: No, score=0.394 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hyU_uoFwKkb1 for ; Sun, 12 Jan 2014 06:47:55 -0800 (PST) Received: from vps2.brainspark.nl (vps2.brainspark.nl [141.138.204.106]) by ietfa.amsl.com (Postfix) with ESMTP id CA3F41AD8E1 for ; Sun, 12 Jan 2014 06:47:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=S2RP6NmTFtSowtUc2STL+khWqP/JlsCePqtKUy2Iaj8=; b=UE+kw9zKcqsdTOS2vfKQSD96SEMsp34nb33a6m7Q0bZTt+9cEKPd7zE0L9z21QkxAdCUlBrpyOdbpgGB9MOQ/0EPsdGkTACv2lcKfx9qbcv/AVjd+AXsLDxhVG6rWIuj8kn97QUwiMOMAuXekne2GqCWeM+2S/46X5G/l8mQKnA=; Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.brainspark.nl with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1W2MDC-0002xJ-RI; Sun, 12 Jan 2014 15:40:27 +0100 Message-ID: <52D2AB07.7010806@polarssl.org> Date: Sun, 12 Jan 2014 15:47:35 +0100 From: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.1.1 MIME-Version: 1.0 To: Dr Stephen Henson , Simon Josefsson , tls@ietf.org References: <87eh4e7a2y.fsf@latte.josefsson.org> <52D17F30.1090008@drh-consultancy.co.uk> In-Reply-To: <52D17F30.1090008@drh-consultancy.co.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 88.165.216.11 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.brainspark.nl) Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Jan 2014 14:47:56 -0000 On 11/01/2014 18:28, Dr Stephen Henson wrote: > On 11/01/2014 16:32, Simon Josefsson wrote: >> >> 2) Does description of private/public key representation and computation >> of shared secret belong in draft-josefsson-tls-curve25519? It has to >> be somewhere, I believ, but possibly this could go into >> draft-ladd-safecurves, or some other generic document, unless there >> are TLS-specific aspects. Insight into this would be appreciated. >> > > A comment on the following paragraph: > > This document only describes usage of additional curves for ephemeral > key exchange (ECDHE), not for use with long-term keys embedded in > PKIX certificates (ECDH_ECDSA and ECDH_ECDSA). This is because > Curve25519 is not directly suitable for authentication with ECDSA, > and thus not applicable for signing of e.g. PKIX certificates. See > draft-josefsson-eddsa-ed25519 for a parallel effort. > > Although the curves are not directly suitable for authentication this doesn't > actually matter because the certificate doesn't have to be signed using the same > curve or indeed the same algorithm. So it would (for example) permit a > certificate containing a curve25519 key signed by a CA using a Brainpool curve > (or even RSA with the relaxed CA signing rules of TLS 1.2). However to do that > would require a standard for the use of curve25519 in certificates which > currently doesn't exist. > Agreed. Actually, a previous (unpublished) version of the draft had a more precise wording about that, but I unfortunately deleted it in the editing process. Thanks for noticing. > Having said that the static ECDH ciphersuites are rarely used and don't offer > forward secrecy. > Right. > IMHO a discussion of private/public key format should be in a separate document > which would include an appropriate ASN1.1 format (e.g. PKCS#8 for private keys > and SubjectPublicKeyInfo for public keys). That would enable the use of > curve25519 (and other curves) in a wider range of applications, not just TLS. > I don't disagree that such a document would be a useful addition, but since ECDHE in TLS isn't using ASN.1 to represent the keys, and only needs to represent public keys, I felt like the easiest way forward was to specify only what's needed to do ECDHE in TLS, that is how to represent public keys, without ASN.1. Manuel. From mpg@polarssl.org Sun Jan 12 06:54:45 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA261ADE72 for ; Sun, 12 Jan 2014 06:54:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.394 X-Spam-Level: X-Spam-Status: No, score=0.394 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JiF9VsavBhE6 for ; Sun, 12 Jan 2014 06:54:44 -0800 (PST) Received: from vps2.brainspark.nl (vps2.brainspark.nl [141.138.204.106]) by ietfa.amsl.com (Postfix) with ESMTP id C4B741AD8E1 for ; Sun, 12 Jan 2014 06:54:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=zI5KXwxtw8VYicX8i4VEVifjaLz39IqUG8Tca8xb0bg=; b=HFUJwx6Sxw52e5CDPu/r9WP1Z430eWTqyjE/gpGwYW7Rr8IrRH8ChagRUWGqoCXv0I3bMG/trGbsTB2flTbE37tFYK4tY2hvxNSulvHHa1CAjUf2T58N4H+218qby9eJmxla1FCMCEBK1wyTLJ9nRNQwcWLfCD8DrIEag/7Omo8=; Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.brainspark.nl with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1W2MJu-0002yr-PV; Sun, 12 Jan 2014 15:47:23 +0100 Message-ID: <52D2ACA7.3080407@polarssl.org> Date: Sun, 12 Jan 2014 15:54:31 +0100 From: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.1.1 MIME-Version: 1.0 To: Alyssa Rowan , tls@ietf.org References: <87eh4e7a2y.fsf@latte.josefsson.org> <52D18475.10709@akr.io> In-Reply-To: <52D18475.10709@akr.io> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 88.165.216.11 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.brainspark.nl) Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Jan 2014 14:54:45 -0000 On 11/01/2014 18:50, Alyssa Rowan wrote: > 2. Monty & Eddie > > You list both Montgomery and Edwards curves in that list. I suggest > just listing the Montgomery curves (Curve25519, M383 and M511) for > this use, as these are the forms that are the very natural choices for > ECDHE, with the handy x-coordinate-only feature. > I tend to agree. But as was noted by others (including Robert Ransom on the CFRG list), every Edwards curve can also be used to do Montgomery. So I'm curious to hear more about whether people are also interested by the Edwards curve for ECDHE or if the Montgomery curves are enough. One argument for using only the Mongtgomery curves is that we probably don't need more than one curve (of the same origin) at each security level. But then, this argument could be used to conclude we don't need the Montgomery curves at all. > (There's a typo in that section, by the way; "22519".) > Thanks. Manuel. From rransom.8774@gmail.com Sun Jan 12 07:01:26 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48F061ADF65 for ; Sun, 12 Jan 2014 07:01:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.45 X-Spam-Level: X-Spam-Status: No, score=-1.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3Ulqw5GtP37 for ; Sun, 12 Jan 2014 07:01:25 -0800 (PST) Received: from mail-qe0-x22d.google.com (mail-qe0-x22d.google.com [IPv6:2607:f8b0:400d:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 219B11AD68A for ; Sun, 12 Jan 2014 07:01:25 -0800 (PST) Received: by mail-qe0-f45.google.com with SMTP id nd7so859800qeb.32 for ; Sun, 12 Jan 2014 07:01:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=kjQz0GcZTAnIlQ+/mAl9eQYr7mJ43BKiGIN5OrSX68Y=; b=yV8Arbbwp3VOTrlQ6V8Kay1ZPsyZGJDxoQKl+qd5msroV6auqfb38Bol5hRcW6sAWo oSEdBCNrKJJx6klq8Lo19ubVi39iM37o76nIA0xXMdY46gQ3y+a55HfvPf6qxdqKBef+ AQMGYH2b/XC7g6+0fXl2j6f6dAFX+HTV29EXE0gRjPMSGTmODAW7f2XmlFvQ0eGP/3TT Et1guw5PJK2f0XyZUF/WAO7y7wr2Eq5d67mKRpq+EKKyiYQW8LOpphfF17bHU0aPadZ7 4MmF/n5BUYRX9009K4izE8vp62FT6MNgnngZpSADA2DanVheRj2zM6evMmYey0RHlLWr CK/g== MIME-Version: 1.0 X-Received: by 10.49.86.169 with SMTP id q9mr29868637qez.19.1389538874347; Sun, 12 Jan 2014 07:01:14 -0800 (PST) Received: by 10.229.181.132 with HTTP; Sun, 12 Jan 2014 07:01:14 -0800 (PST) In-Reply-To: <52D2ACA7.3080407@polarssl.org> References: <87eh4e7a2y.fsf@latte.josefsson.org> <52D18475.10709@akr.io> <52D2ACA7.3080407@polarssl.org> Date: Sun, 12 Jan 2014 07:01:14 -0800 Message-ID: From: Robert Ransom To: =?UTF-8?Q?Manuel_P=C3=A9gouri=C3=A9=2DGonnard?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Jan 2014 15:01:26 -0000 On 1/12/14, Manuel P=C3=A9gouri=C3=A9-Gonnard wrote: > On 11/01/2014 18:50, Alyssa Rowan wrote: >> 2. Monty & Eddie >> >> You list both Montgomery and Edwards curves in that list. I suggest >> just listing the Montgomery curves (Curve25519, M383 and M511) for >> this use, as these are the forms that are the very natural choices for >> ECDHE, with the handy x-coordinate-only feature. >> > I tend to agree. But as was noted by others (including Robert Ransom on t= he > CFRG > list), every Edwards curve can also be used to do Montgomery. So I'm curi= ous > to > hear more about whether people are also interested by the Edwards curve f= or > ECDHE or if the Montgomery curves are enough. * ECDH should use only Montgomery form, *never* Edwards form. (There are key-agreement protocols which require Edwards form. ECDH is not one of them.) * Every curve with minimal Edwards-form parameter can be efficiently used in Montgomery form with the simplest possible implementation. The converse is not true. * Most of the =E2=80=98SafeCurves=E2=80=99 curves (including all of the one= s specified in Montgomery form, except Curve25519) would be needlessly unpleasant to implement. The only curves that I could support using for ECDH at this time are Curve25519, Curve3617, and (possibly) E-521. Robert Ransom From ietf-ietf-tls@m.gmane.org Sun Jan 12 07:02:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E02CD1ADF83 for ; Sun, 12 Jan 2014 07:02:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.538 X-Spam-Level: X-Spam-Status: No, score=-1.538 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538, 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 5lhcP0YYLjaA for ; Sun, 12 Jan 2014 07:02:36 -0800 (PST) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by ietfa.amsl.com (Postfix) with ESMTP id 79B461ADF7F for ; Sun, 12 Jan 2014 07:02:35 -0800 (PST) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1W2MYQ-0001g1-Nm for tls@ietf.org; Sun, 12 Jan 2014 16:02:22 +0100 Received: from c-50-132-41-203.hsd1.wa.comcast.net ([50.132.41.203]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 12 Jan 2014 16:02:22 +0100 Received: from eternaleye by c-50-132-41-203.hsd1.wa.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 12 Jan 2014 16:02:22 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: tls@ietf.org From: Alex Elsayed Date: Sun, 12 Jan 2014 07:02:12 -0800 Lines: 31 Message-ID: References: <87eh4e7a2y.fsf@latte.josefsson.org> <52D18475.10709@akr.io> <20140111190918.GA1820@roeckx.be> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-50-132-41-203.hsd1.wa.comcast.net User-Agent: KNode/4.12 Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Jan 2014 15:02:38 -0000 Kurt Roeckx wrote: > On Sat, Jan 11, 2014 at 05:50:45PM +0000, Alyssa Rowan wrote: >> 3. Security Considerations: Implementation >> >> Thoughtful. Do we need to directly specify that implementations MUST >> avoid side-channel attacks, because otherwise they might be tempted to >> implement them in a way that isn't constant-time? > > So looking at currently available implementations of this, they > are not all constant-time. See > https://code.google.com/p/curve25519-donna/ for intance that the > portable C version is marked as being none costant-time. > > The only other known portable implementation that I know of is by > Matthew Dempsky that's part of nacl, for which I can't find any > information about it being costant-time or not and assume it's > not. I'd suspect that the reason there's no information about that _part_ of NaCl being constant-time is due to the constant-time guarantees being stated as applying to _all_ of NaCl (http://nacl.cace-project.eu/features.html) > No data-dependent branches > ... > No data-dependent array indices > ... > No dynamic memory allocation > ... Thus, if it didn't meet those constraints it wouldn't be in NaCl at all. From mpg@polarssl.org Sun Jan 12 07:17:44 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5561ADF65 for ; Sun, 12 Jan 2014 07:17:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.394 X-Spam-Level: X-Spam-Status: No, score=0.394 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNoS50MDdVql for ; Sun, 12 Jan 2014 07:17:43 -0800 (PST) Received: from vps2.brainspark.nl (vps2.brainspark.nl [141.138.204.106]) by ietfa.amsl.com (Postfix) with ESMTP id D81341AD68A for ; Sun, 12 Jan 2014 07:17:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:CC:To:MIME-Version:From:Date:Message-ID; bh=ToDMuFWrxwAJGdWL26uMX/bFZG5lFeq+GDu6BEBZfFM=; b=Dcoo0bRvK+jDZ819YWwL+QKdc9NNGdD7ZvtqzGoe77Ml8i2nZm7uFJ8aRdRh5yO+lAb0Mf/JONhDMrmUjK5RPHdEUIfoW6o0BG2oiyy1jECnJoR/6xqc1FX3fOmw2KHGFQ5bbIbEgNvg5bw0gU28Ul+sHIrX2lcU6PRdq7oQESM=; Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.brainspark.nl with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1W2Mg6-000337-Rz; Sun, 12 Jan 2014 16:10:19 +0100 Message-ID: <52D2B208.90407@polarssl.org> Date: Sun, 12 Jan 2014 16:17:28 +0100 From: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.1.1 MIME-Version: 1.0 To: Eric Rescorla , Simon Josefsson References: <87eh4e7a2y.fsf@latte.josefsson.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 88.165.216.11 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.brainspark.nl) Cc: "tls@ietf.org" Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Jan 2014 15:17:44 -0000 On 11/01/2014 20:51, Eric Rescorla wrote: > The TLS WG is not chartered (or qualified) to assess curves. What I > believe is needed is for the IETF (whether directly or through the > CFRG) to come to consensus on what curves we believe our > protocols should support and then we can adopt them across > the relevant security WGs, doing whatever protocol-specific > work is required then. > Thanks for making that clear. Just to be sure I'm not misunderstanding, is the problem adding a whole family of curves, or would that be just the same if the draft was only about Curve25519? I'm asking because there seem to be interest by many people, including implementers, to have support for Curve25519 in TLS sooner rather than later, and if I remember correctly there was some consensus in the thread [1] about the fact that it would be a nice option to add (even if there was disagreements on some points, eg comparing the "rigidity" of Curve25519 vs Brainpool). [1]: https://www.ietf.org/mail-archive/web/tls/current/msg09813.html So, do you think it would OK to pursue efforts on a Curve25519-only draft, or if any draft adding new curves should way for a document from CFRG and/or SAAG establishing more general guidance on which curves (and associated protocol variants) to use for IETF protocols given that such a document will probably be much longer to produce than just a Curve25519-in-TLS document? Manuel. From watsonbladd@gmail.com Sun Jan 12 07:18:27 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 114FD1ADF8B for ; Sun, 12 Jan 2014 07:18:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oqB6R1ZMHYC9 for ; Sun, 12 Jan 2014 07:18:25 -0800 (PST) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 26BE01ADF65 for ; Sun, 12 Jan 2014 07:18:25 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id hn9so1295991wib.6 for ; Sun, 12 Jan 2014 07:18:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=sKTLWoGsBmzvF4D+YGUg6HmeUVZS4swcP9Qt+iUTPH0=; b=cZ0/8HpIdiaedJpXA+RMK1b/dIrUc3w2bkT4ZpCscbgEH4xlJJewIvr9BRroOLGiUQ Z8hb8CCMHOEdp64EFwX+sRFAIqEih9y0vtGIgAOySpPxayp8po7c7z9MkFQJlkIapgqX A9kpIoYnhfsbIfAQldD4EOOyWx2GrcQoU9JO/krzRstm+JIt8RL2lp2dhtRv0SVkgMdu EbxqGocc6uYIFoXu73wEj8zoPXPZfklpqGXaBV1JLyUohb6cxT1Q/d7shS12U6m0jre8 AJN4toSUkLJsoj75ZnHmf3LY7NTaCpdP2VPkR9c76tk+hsatt8gYD2VhGX2rNU9zdHvW L7pQ== MIME-Version: 1.0 X-Received: by 10.180.95.162 with SMTP id dl2mr11576717wib.17.1389539893947; Sun, 12 Jan 2014 07:18:13 -0800 (PST) Received: by 10.194.242.131 with HTTP; Sun, 12 Jan 2014 07:18:13 -0800 (PST) In-Reply-To: References: <87eh4e7a2y.fsf@latte.josefsson.org> <52D18475.10709@akr.io> <52D2ACA7.3080407@polarssl.org> Date: Sun, 12 Jan 2014 07:18:13 -0800 Message-ID: From: Watson Ladd To: Robert Ransom Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "tls@ietf.org" Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Jan 2014 15:18:27 -0000 On Sun, Jan 12, 2014 at 7:01 AM, Robert Ransom wro= te: > On 1/12/14, Manuel P=C3=A9gouri=C3=A9-Gonnard wrote: >> On 11/01/2014 18:50, Alyssa Rowan wrote: >>> 2. Monty & Eddie >>> >>> You list both Montgomery and Edwards curves in that list. I suggest >>> just listing the Montgomery curves (Curve25519, M383 and M511) for >>> this use, as these are the forms that are the very natural choices for >>> ECDHE, with the handy x-coordinate-only feature. >>> >> I tend to agree. But as was noted by others (including Robert Ransom on = the >> CFRG >> list), every Edwards curve can also be used to do Montgomery. So I'm cur= ious >> to >> hear more about whether people are also interested by the Edwards curve = for >> ECDHE or if the Montgomery curves are enough. > > * ECDH should use only Montgomery form, *never* Edwards form. (There > are key-agreement protocols which require Edwards form. ECDH is not > one of them.) > > * Every curve with minimal Edwards-form parameter can be efficiently > used in Montgomery form with the simplest possible implementation. > The converse is not true. Why is using twisted Edwards form, or the Montgomery ladder, so bad from an implementation perspective? Twisted Edwards form makes the converse true. I now mention it in the draft, as well as the AFRICACRYPT paper which introduces it. Not every implementation needs to be the fastest, just fast enough. > > * Most of the =E2=80=98SafeCurves=E2=80=99 curves (including all of the o= nes specified > in Montgomery form, except Curve25519) would be needlessly unpleasant > to implement. The only curves that I could support using for ECDH at > this time are Curve25519, Curve3617, and (possibly) E-521. You will have to expand on this. All of these curves have primes of similar shapes, and while some might require more annoying limb placements than others, without having actual implementations to compare, we don't know how big the impact actually will be. M-383 is actually better than Curve3617 from your perspective: it reduces the size of the actual coefficient in Montgomery form and in twisted Edwards form will be the same size. The prime is also the same. > > > Robert Ransom > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --=20 "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From mpg@polarssl.org Sun Jan 12 07:30:00 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85C5A1ADF24 for ; Sun, 12 Jan 2014 07:30:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.394 X-Spam-Level: X-Spam-Status: No, score=0.394 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0lPBj8O5fWzg for ; Sun, 12 Jan 2014 07:29:59 -0800 (PST) Received: from vps2.brainspark.nl (vps2.brainspark.nl [141.138.204.106]) by ietfa.amsl.com (Postfix) with ESMTP id 845521ADE72 for ; Sun, 12 Jan 2014 07:29:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=UvkIgyBLSo3+7S4i0sxQT/qCuAuCxkIcsHc4PFk5FXM=; b=HtWk0QWBTdKyfTNTVxbQWGaNy4w27ZZS5I3qTadu6S/tBUPJen18+WU1uF5D8/Sk68GgaBIFj1OxohgxzvxAQiuBVKXHUJsrDJyrSN980FyARimcJ4mYZ0dVsTHttAn2DKQsqcYAS5liaWRbZzGAuFMmtYW59ZpoyQYrFWSzs8g=; Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.brainspark.nl with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1W2Ms1-00035Y-HB for tls@ietf.org; Sun, 12 Jan 2014 16:22:37 +0100 Message-ID: <52D2B4EB.807@polarssl.org> Date: Sun, 12 Jan 2014 16:29:47 +0100 From: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.1.1 MIME-Version: 1.0 To: tls@ietf.org References: <87eh4e7a2y.fsf@latte.josefsson.org> <52D18475.10709@akr.io> <52D185DA.1030407@drh-consultancy.co.uk> In-Reply-To: <52D185DA.1030407@drh-consultancy.co.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 88.165.216.11 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.brainspark.nl) Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Jan 2014 15:30:00 -0000 On 11/01/2014 18:56, Dr Stephen Henson wrote: > On 11/01/2014 17:50, Alyssa Rowan wrote: >> >> 3. Security Considerations: Implementation >> >> Thoughtful. Do we need to directly specify that implementations MUST >> avoid side-channel attacks, because otherwise they might be tempted to >> implement them in a way that isn't constant-time? >> > > While that is a concern for long time use how significant is it for epehemeral > ciphersuites? In that case the key is typically, generated one ECDH operation > performed and then discarded. > I was under the impression that, for performance reasons, some implementations (I thought this included OpenSSL but your message seems to imply I was mistaken) didn't discard the private exponent after each key exchange but instead reused it for a given period of time and/or number of key exchanges. If that is the case, then these implementations probably need to be constant-time. Also, though it's a less compelling argument, there's always the risk that a non-constant time implementation used initially only for truly ephemeral keys will be re-used later with long-term keys. Manuel. From kurt@roeckx.be Sun Jan 12 07:35:20 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07D971ADF83 for ; Sun, 12 Jan 2014 07:35:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kMu5tUNCFP3y for ; Sun, 12 Jan 2014 07:35:17 -0800 (PST) Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) by ietfa.amsl.com (Postfix) with ESMTP id DA9F51ADF78 for ; Sun, 12 Jan 2014 07:35:16 -0800 (PST) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 74B471C20F3; Sun, 12 Jan 2014 16:35:04 +0100 (CET) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 4A69D1FE01DA; Sun, 12 Jan 2014 16:35:04 +0100 (CET) Date: Sun, 12 Jan 2014 16:35:04 +0100 From: Kurt Roeckx To: Alex Elsayed Message-ID: <20140112153504.GA18966@roeckx.be> References: <87eh4e7a2y.fsf@latte.josefsson.org> <52D18475.10709@akr.io> <20140111190918.GA1820@roeckx.be> 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) Cc: tls@ietf.org Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Jan 2014 15:35:20 -0000 On Sun, Jan 12, 2014 at 07:02:12AM -0800, Alex Elsayed wrote: > Kurt Roeckx wrote: > > > On Sat, Jan 11, 2014 at 05:50:45PM +0000, Alyssa Rowan wrote: > >> 3. Security Considerations: Implementation > >> > >> Thoughtful. Do we need to directly specify that implementations MUST > >> avoid side-channel attacks, because otherwise they might be tempted to > >> implement them in a way that isn't constant-time? > > > > So looking at currently available implementations of this, they > > are not all constant-time. See > > https://code.google.com/p/curve25519-donna/ for intance that the > > portable C version is marked as being none costant-time. > > > > The only other known portable implementation that I know of is by > > Matthew Dempsky that's part of nacl, for which I can't find any > > information about it being costant-time or not and assume it's > > not. > > I'd suspect that the reason there's no information about that _part_ of NaCl > being constant-time is due to the constant-time guarantees being stated as > applying to _all_ of NaCl (http://nacl.cace-project.eu/features.html) I also looked at the source in the mean time and couldn't see an obvious problems with it. So I think all known implementations are currently constant-time. Kurt From lists@drh-consultancy.co.uk Sun Jan 12 07:36:45 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27D6C1ADFAC for ; Sun, 12 Jan 2014 07:36:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.811 X-Spam-Level: X-Spam-Status: No, score=-0.811 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, T_HK_NAME_DR=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 w-9iDXsymw6q for ; Sun, 12 Jan 2014 07:36:43 -0800 (PST) Received: from claranet-outbound-smtp01.uk.clara.net (claranet-outbound-smtp01.uk.clara.net [195.8.89.34]) by ietfa.amsl.com (Postfix) with ESMTP id 160A41ADFAA for ; Sun, 12 Jan 2014 07:36:43 -0800 (PST) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:34533 helo=[192.168.7.9]) by relay11.mail.eu.clara.net (relay.clara.net [81.171.239.31]:10465) with esmtpa (authdaemon_plain:drh) id 1W2N5M-0001Ms-54 (return-path ); Sun, 12 Jan 2014 15:36:24 +0000 Message-ID: <52D2B678.7010302@drh-consultancy.co.uk> Date: Sun, 12 Jan 2014 15:36:24 +0000 From: Dr Stephen Henson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= , Simon Josefsson , tls@ietf.org References: <87eh4e7a2y.fsf@latte.josefsson.org> <52D17F30.1090008@drh-consultancy.co.uk> <52D2AB07.7010806@polarssl.org> In-Reply-To: <52D2AB07.7010806@polarssl.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Jan 2014 15:36:45 -0000 On 12/01/2014 14:47, Manuel Pégourié-Gonnard wrote: > On 11/01/2014 18:28, Dr Stephen Henson wrote: > >> IMHO a discussion of private/public key format should be in a separate document >> which would include an appropriate ASN1.1 format (e.g. PKCS#8 for private keys >> and SubjectPublicKeyInfo for public keys). That would enable the use of >> curve25519 (and other curves) in a wider range of applications, not just TLS. >> > I don't disagree that such a document would be a useful addition, but since > ECDHE in TLS isn't using ASN.1 to represent the keys, and only needs to > represent public keys, I felt like the easiest way forward was to specify only > what's needed to do ECDHE in TLS, that is how to represent public keys, without > ASN.1. > Although TLS and ASN.1 represent the keys in different ways they are wrappers round the same low level point format specified in X9.62/SEC1. Specifically in RFC4492 for TLS in 5.4, the description of ECPoint. There is an equivalent reference for certificates in in RFC5480 2.2, again ECPoint. I think we should keep this consistency and have the point format for the new curves defined in one standard, whatever that might be. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From rransom.8774@gmail.com Sun Jan 12 07:46:48 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E52C1ADF48 for ; Sun, 12 Jan 2014 07:46:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 GUbUt9ZK6Eyr for ; Sun, 12 Jan 2014 07:46:47 -0800 (PST) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id DFC2B1ADF24 for ; Sun, 12 Jan 2014 07:46:46 -0800 (PST) Received: by mail-qc0-f179.google.com with SMTP id e16so3384280qcx.10 for ; Sun, 12 Jan 2014 07:46:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=V1knKzPfjgjOdgjm6eQDjfRlzZf2n0B+dr7tfNHpvaY=; b=HBIpCNAEizDF82LeMDrc9haX9KaCmPmCG4M9aAhVZO5f51EzBlREAUJQlrzO88xjku eqx1Yv6MQCpHg5wKo3SyBScv6iXGSr8h8fugKpm7XyIMdbdNmToYwJZAJzTEc2Wlv+GW 6+pL3XC3fIsnaw8uzoc4d8uC/9GUXziTElpfWErhKsCLKnxfTKtsQtGu4MWepD3T/BhZ bPLuPDQ2uSdoc5/OsuCXNe1QbenF06bJtfah9ljr4ltwV9FTZMcAIe16K/lcWdTyXp1A 5MACmsLAIdzSYojJETEpQ/ODvhsJFw31QNmbBhDgafTEvSTu/WKVLVB6mkMzV2miYEoA B7eA== MIME-Version: 1.0 X-Received: by 10.224.53.71 with SMTP id l7mr30277693qag.33.1389541596154; Sun, 12 Jan 2014 07:46:36 -0800 (PST) Received: by 10.229.181.132 with HTTP; Sun, 12 Jan 2014 07:46:36 -0800 (PST) In-Reply-To: References: <87eh4e7a2y.fsf@latte.josefsson.org> <52D18475.10709@akr.io> <52D2ACA7.3080407@polarssl.org> Date: Sun, 12 Jan 2014 07:46:36 -0800 Message-ID: From: Robert Ransom To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "tls@ietf.org" Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Jan 2014 15:46:48 -0000 On 1/12/14, Watson Ladd wrote: > On Sun, Jan 12, 2014 at 7:01 AM, Robert Ransom > wrote: >> On 1/12/14, Manuel P=C3=A9gouri=C3=A9-Gonnard wrote: >>> On 11/01/2014 18:50, Alyssa Rowan wrote: >>>> 2. Monty & Eddie >>>> >>>> You list both Montgomery and Edwards curves in that list. I suggest >>>> just listing the Montgomery curves (Curve25519, M383 and M511) for >>>> this use, as these are the forms that are the very natural choices for >>>> ECDHE, with the handy x-coordinate-only feature. >>>> >>> I tend to agree. But as was noted by others (including Robert Ransom on >>> the >>> CFRG >>> list), every Edwards curve can also be used to do Montgomery. So I'm >>> curious >>> to >>> hear more about whether people are also interested by the Edwards curve >>> for >>> ECDHE or if the Montgomery curves are enough. >> >> * ECDH should use only Montgomery form, *never* Edwards form. (There >> are key-agreement protocols which require Edwards form. ECDH is not >> one of them.) >> >> * Every curve with minimal Edwards-form parameter can be efficiently >> used in Montgomery form with the simplest possible implementation. >> The converse is not true. > > Why is using twisted Edwards form, or the Montgomery ladder, so bad from > an implementation perspective? Twisted Edwards form makes the converse > true. I now mention it in the draft, as well as the AFRICACRYPT paper whi= ch > introduces it. Dr. Bernstein's Ed25519 paper specifies the a=3D-1 twist because that twist has strictly faster formulas than any other value of a, even if that twist requires a large value of d. > Not every implementation needs to be the fastest, just fast enough. That does not justify choosing curves in a way that unnecessarily harms the performance of simple implementations and raises the complexity of fully optimized implementations. >> * Most of the =E2=80=98SafeCurves=E2=80=99 curves (including all of the = ones specified >> in Montgomery form, except Curve25519) would be needlessly unpleasant >> to implement. The only curves that I could support using for ECDH at >> this time are Curve25519, Curve3617, and (possibly) E-521. > > You will have to expand on this. All of these curves have primes of > similar shapes, > and while some might require more annoying limb placements than > others, without having > actual implementations to compare, we don't know how big the impact > actually will be. > > M-383 is actually better than Curve3617 from your perspective: it > reduces the size of > the actual coefficient in Montgomery form and in twisted Edwards form > will be the same size. Curve3617's Montgomery-form parameter is 1/3617 (or something close to it). (In the Montgomery formulas, a reciprocal-of-small-integer parameter is as efficient as a small-integer parameter.) M-383's Montgomery-form parameter will be a small integer with about 6 decimal digits. > The prime is also the same. Curve3617's coordinate field is 414-bit; M-383's coordinate field is 383-bit. I don't think they're the same. Robert Ransom From mpg@polarssl.org Sun Jan 12 08:04:45 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07D551ADFD7 for ; Sun, 12 Jan 2014 08:04:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.394 X-Spam-Level: X-Spam-Status: No, score=0.394 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-lqVNGuipzA for ; Sun, 12 Jan 2014 08:04:42 -0800 (PST) Received: from vps2.brainspark.nl (vps2.brainspark.nl [141.138.204.106]) by ietfa.amsl.com (Postfix) with ESMTP id 02A901ADF24 for ; Sun, 12 Jan 2014 08:04:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=fRovOsHjqrCrNTbuW72/stuFaJcns21jXgcWYCcCd40=; b=GR+xhbvT+oS80mnASjvpyFWYLVa2r7MtW+YarkBHgVkZeCItLuQpmUBppxlCGK5j11NnPsiM6E62225ugk2iV5smZzkhi6aN+Rr6dcM7hRWcePM6GC+rywZeb7x9t8yi+aUvtKoDl4QgFwPLJtNjSU+BNpIgGGUTLprNBP6kX+0=; Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.brainspark.nl with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1W2NPZ-0003Ab-Md; Sun, 12 Jan 2014 16:57:18 +0100 Message-ID: <52D2BD0B.1020007@polarssl.org> Date: Sun, 12 Jan 2014 17:04:27 +0100 From: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.1.1 MIME-Version: 1.0 To: Dr Stephen Henson , Simon Josefsson , tls@ietf.org References: <87eh4e7a2y.fsf@latte.josefsson.org> <52D17F30.1090008@drh-consultancy.co.uk> <52D2AB07.7010806@polarssl.org> <52D2B678.7010302@drh-consultancy.co.uk> In-Reply-To: <52D2B678.7010302@drh-consultancy.co.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 88.165.216.11 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.brainspark.nl) Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Jan 2014 16:04:45 -0000 On 12/01/2014 16:36, Dr Stephen Henson wrote: > Although TLS and ASN.1 represent the keys in different ways they are wrappers > round the same low level point format specified in X9.62/SEC1. > > Specifically in RFC4492 for TLS in 5.4, the description of ECPoint. > > There is an equivalent reference for certificates in in RFC5480 2.2, again ECPoint. > > I think we should keep this consistency and have the point format for the new > curves defined in one standard, whatever that might be. > Good point. Since this format may be used by more than just TLS, and was originally defined outside the IETF, what would be the most appropriate place to discuss extending it? Manuel. From mpg@polarssl.org Sun Jan 12 08:17:57 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEF4A1AE005 for ; Sun, 12 Jan 2014 08:17:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.394 X-Spam-Level: X-Spam-Status: No, score=0.394 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZ16CE_cvDqA for ; Sun, 12 Jan 2014 08:17:57 -0800 (PST) Received: from vps2.brainspark.nl (vps2.brainspark.nl [141.138.204.106]) by ietfa.amsl.com (Postfix) with ESMTP id D01FE1ADFF2 for ; Sun, 12 Jan 2014 08:17:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=WUsXgCtkzbLGRuWQHPVBugbrQs+oEEJloxLlw7ulwpU=; b=PPb8NSHMO/K4Hlj0xcupg7F+6hoZLfLoy0OO39Qs1LZckIX9QHNvMuPuSI5PtMcdrbXsfwU4fdhP7rPeFAG5EDiJRI6gweJWLTj/6a9OhESUlY2kGOUojsXKP4UKY4Ft188kNToyNSIx87XHaZBxfAmmvNcOIH7sxH0g3eW8Cr8=; Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.brainspark.nl with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1W2NcQ-0003CX-PA for tls@ietf.org; Sun, 12 Jan 2014 17:10:35 +0100 Message-ID: <52D2C028.4090001@polarssl.org> Date: Sun, 12 Jan 2014 17:17:44 +0100 From: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.1.1 MIME-Version: 1.0 To: tls@ietf.org References: <87eh4e7a2y.fsf@latte.josefsson.org> <52D18475.10709@akr.io> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 88.165.216.11 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.brainspark.nl) Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Jan 2014 16:17:58 -0000 On 11/01/2014 20:03, Adam Langley wrote: > On Sat, Jan 11, 2014 at 12:50 PM, Alyssa Rowan wrote: >> But on reflection, pretty much everything else in internet standards >> goes big-endian, so there's consistency there, and an endian swap >> isn't exactly a big deal. No objection. > > Happy to see curve25519 specified, but I do object to this. Every > curve25519 implementation follows djb's API, which is byte orientated. > I think it's sensible to leave the exact field representation to the > DH function rather than have that concept spill into TLS. Maybe future > DH functions will want to save an inversion and send extended > coordinates or something. > > Flipping the endianness just means that every single implementation > has to undo it before feeding it into the curve25519 function. > I understand your point. Concerning implementations, unless I'm mistaken all the implementations of Curve25519 you mention use custom routines for field arithmetic. I was thinking about other implementations might want to use a more generic bignum library, whose output function will probably be big-endian since that's the ordering generally used in protocols. So for these implementations, big-endian would probably be more natural. (As a matter of fact, that's precisely the case of the implementation in PolarSSL, but of course it wouldn't be fair to count it as pre-existing the draft, since I've been involved in both the draft and this implementation.) Manuel. From rsalz@akamai.com Sun Jan 12 11:21:32 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 442421AE013 for ; Sun, 12 Jan 2014 11:21:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNLupHf9-oZ8 for ; Sun, 12 Jan 2014 11:21:31 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id F2F231AE01B for ; Sun, 12 Jan 2014 11:21:28 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 0140F47398; Sun, 12 Jan 2014 19:21:18 +0000 (GMT) Received: from prod-mail-relay02.akamai.com (prod-mail-relay02.akamai.com [172.17.50.21]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id E937947394; Sun, 12 Jan 2014 19:21:17 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub6.kendall.corp.akamai.com [172.27.105.22]) by prod-mail-relay02.akamai.com (Postfix) with ESMTP id DE8AEFE054; Sun, 12 Jan 2014 19:21:17 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.77]) by USMA1EX-CASHUB6.kendall.corp.akamai.com ([172.27.105.22]) with mapi; Sun, 12 Jan 2014 14:21:17 -0500 From: "Salz, Rich" To: "tls@ietf.org" , "Stephen Farrell (stephen.farrell@cs.tcd.ie)" , "Sean Turner (turners@ieca.com)" Date: Sun, 12 Jan 2014 14:21:16 -0500 Thread-Topic: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement Thread-Index: Ac8Pr/8VO9F1c/nhTsmmkBsl/ZuFHwAGrM6w Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711E8766BFF@USMBX1.msg.corp.akamai.com> References: <87eh4e7a2y.fsf@latte.josefsson.org> <52D17F30.1090008@drh-consultancy.co.uk> <52D2AB07.7010806@polarssl.org> <52D2B678.7010302@drh-consultancy.co.uk> <52D2BD0B.1020007@polarssl.org> In-Reply-To: <52D2BD0B.1020007@polarssl.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Simon Josefsson Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Jan 2014 19:21:32 -0000 I don't want this question to get lost in the general discussion so I am ex= plicitly addressing this to the AD's >> I think we should keep this consistency and have the point format for=20 >> the new curves defined in one standard, whatever that might be. > Since this format may be used by more than just TLS, and was originally d= efined outside the IETF, what would > be the most appropriate place to discuss extending it? Some folks have been working on a concrete proposal, which is that we "take= " 0x41 as a new marker byte in ECPoint, and use that to mean "key format de= fined by the curve" Ask IANA to maintain a curve point-format registry. F= or example, Curve25519 would have 0x41 followed by the 32 bytes of x-value = for the key. So, where should such a document be started? Many of us are feeling pressure to implement ECDHA to get PFS for our custo= mers, and see the efficiency of Curve25519 as very important. That is, the= clock is ticking... /r$ -- =20 Principal Security Engineer Akamai Technology Cambridge, MA From lists@drh-consultancy.co.uk Sun Jan 12 11:29:52 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA5D91AE02A for ; Sun, 12 Jan 2014 11:29:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.111 X-Spam-Level: X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, T_HK_NAME_DR=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 bsGKkz7poPrN for ; Sun, 12 Jan 2014 11:29:50 -0800 (PST) Received: from claranet-outbound-smtp05.uk.clara.net (claranet-outbound-smtp05.uk.clara.net [195.8.89.38]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5451AE013 for ; Sun, 12 Jan 2014 11:29:50 -0800 (PST) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:19726 helo=[192.168.7.9]) by relay15.mail.eu.clara.net (relay.clara.net [81.171.239.35]:10465) with esmtpa (authdaemon_plain:drh) id 1W2Qit-0007AN-GZ (return-path ); Sun, 12 Jan 2014 19:29:27 +0000 Message-ID: <52D2ED16.6040209@drh-consultancy.co.uk> Date: Sun, 12 Jan 2014 19:29:26 +0000 From: Dr Stephen Henson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Salz, Rich" , "tls@ietf.org" , "Stephen Farrell (stephen.farrell@cs.tcd.ie)" , "Sean Turner (turners@ieca.com)" References: <87eh4e7a2y.fsf@latte.josefsson.org> <52D17F30.1090008@drh-consultancy.co.uk> <52D2AB07.7010806@polarssl.org> <52D2B678.7010302@drh-consultancy.co.uk> <52D2BD0B.1020007@polarssl.org> <2A0EFB9C05D0164E98F19BB0AF3708C711E8766BFF@USMBX1.msg.corp.akamai.com> In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711E8766BFF@USMBX1.msg.corp.akamai.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Simon Josefsson Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Jan 2014 19:29:53 -0000 On 12/01/2014 19:21, Salz, Rich wrote: > I don't want this question to get lost in the general discussion so I am explicitly addressing this to the AD's > >>> I think we should keep this consistency and have the point format for >>> the new curves defined in one standard, whatever that might be. > >> Since this format may be used by more than just TLS, and was originally defined outside the IETF, what would >> be the most appropriate place to discuss extending it? > > Some folks have been working on a concrete proposal, which is that we "take" 0x41 as a new marker byte in ECPoint, and use that to mean "key format defined by the curve" Ask IANA to maintain a curve point-format registry. For example, Curve25519 would have 0x41 followed by the 32 bytes of x-value for the key. > > So, where should such a document be started? > > Many of us are feeling pressure to implement ECDHA to get PFS for our customers, and see the efficiency of Curve25519 as very important. That is, the clock is ticking... > Based on the current text, perhaps draft-ladd-safecurves (which might get renamed) being discussed in CFRG? It already has some brief notes on key formats though not the same as above. I'm thinking we'd have a section indicating a (recommended, suggested or just possible) key format and then the TLS, a certificate format document and any other interested protocols could reference it. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From watsonbladd@gmail.com Sun Jan 12 11:33:35 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02AB41AE02F for ; Sun, 12 Jan 2014 11:33:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJjd70tP575M for ; Sun, 12 Jan 2014 11:33:31 -0800 (PST) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id A8E731AE027 for ; Sun, 12 Jan 2014 11:33:30 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id hq4so1421097wib.2 for ; Sun, 12 Jan 2014 11:33:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=68Zh42sa4d5amjNeDyz1cbu/37rQXPwugOGNcdA2VRc=; b=wW3ZzY18iaqzjcmVHIUgXnnTSFJyXCe3HWbp+LDk9qjuTlLN9XKEnd8Bil7WuhGy8S cSlSAhkEbAPv5y5rPUn30K05wcW30eApvnPhpm/uuEOj889Z3kNhxcuOoFy+tJIkVu42 YtbqmPZKLFGg+fbdvGxsWjmvZqVsd/nK5E0zLCuAI0+gUe/lZ3nFM1MgnoiSu577q8Rj XTploqEbUz9Z0Zh0j1FEMqvSbrChII4LEVYUgMNM0K+cSk6tOMNwTD9i3Khod5f6DiBv VvjwSy0FUUYgOTtmi5Y8E5UD3xhoH+eQ6wFr496GiZ4W253XF+1L+0Cj7WZEqgqRdsll ag0w== MIME-Version: 1.0 X-Received: by 10.180.221.129 with SMTP id qe1mr2754162wic.17.1389555199546; Sun, 12 Jan 2014 11:33:19 -0800 (PST) Received: by 10.194.242.131 with HTTP; Sun, 12 Jan 2014 11:33:19 -0800 (PST) In-Reply-To: <52D2ED16.6040209@drh-consultancy.co.uk> References: <87eh4e7a2y.fsf@latte.josefsson.org> <52D17F30.1090008@drh-consultancy.co.uk> <52D2AB07.7010806@polarssl.org> <52D2B678.7010302@drh-consultancy.co.uk> <52D2BD0B.1020007@polarssl.org> <2A0EFB9C05D0164E98F19BB0AF3708C711E8766BFF@USMBX1.msg.corp.akamai.com> <52D2ED16.6040209@drh-consultancy.co.uk> Date: Sun, 12 Jan 2014 11:33:19 -0800 Message-ID: From: Watson Ladd To: Dr Stephen Henson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "tls@ietf.org" , Simon Josefsson Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Jan 2014 19:33:35 -0000 On Sun, Jan 12, 2014 at 11:29 AM, Dr Stephen Henson wrote: > On 12/01/2014 19:21, Salz, Rich wrote: >> I don't want this question to get lost in the general discussion so I am= explicitly addressing this to the AD's >> >>>> I think we should keep this consistency and have the point format for >>>> the new curves defined in one standard, whatever that might be. >> >>> Since this format may be used by more than just TLS, and was originally= defined outside the IETF, what would >>> be the most appropriate place to discuss extending it? >> >> Some folks have been working on a concrete proposal, which is that we "t= ake" 0x41 as a new marker byte in ECPoint, and use that to mean "key format= defined by the curve" Ask IANA to maintain a curve point-format registry.= For example, Curve25519 would have 0x41 followed by the 32 bytes of x-val= ue for the key. >> >> So, where should such a document be started? >> >> Many of us are feeling pressure to implement ECDHA to get PFS for our cu= stomers, and see the efficiency of Curve25519 as very important. That is, = the clock is ticking... >> > > Based on the current text, perhaps draft-ladd-safecurves (which might get > renamed) being discussed in CFRG? It already has some brief notes on key = formats > though not the same as above. I've expanded the section on key formats. So far I'm using big-endian. The last thing I want to do is reignite the crusade. Yes, there is a software compatibility issue, but it is a minor one. > > I'm thinking we'd have a section indicating a (recommended, suggested or = just > possible) key format and then the TLS, a certificate format document and = any > other interested protocols could reference it. Good idea: in fact the latest versions have a compressed point format. The compressed point patent is expiring this summer, and I don't think it applies to anything that isn't short Weierstrass anyway. > > Steve. > -- > Dr Stephen N. Henson. > Core developer of the OpenSSL project: http://www.openssl.org/ > Freelance consultant see: http://www.drh-consultancy.co.uk/ > Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --=20 "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From TurnerS@ieca.com Sun Jan 12 11:39:32 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C65871AE01A for ; Sun, 12 Jan 2014 11:39:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 TMkCwtopGmuz for ; Sun, 12 Jan 2014 11:39:31 -0800 (PST) Received: from gateway16.websitewelcome.com (gateway16.websitewelcome.com [69.56.206.4]) by ietfa.amsl.com (Postfix) with ESMTP id 720401AE013 for ; Sun, 12 Jan 2014 11:39:31 -0800 (PST) Received: by gateway16.websitewelcome.com (Postfix, from userid 5007) id CAD6F248EAA90; Sun, 12 Jan 2014 13:39:20 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway16.websitewelcome.com (Postfix) with ESMTP id B2DF8248EAA6C for ; Sun, 12 Jan 2014 13:39:20 -0600 (CST) Received: from [173.73.130.192] (port=62914 helo=[192.168.1.4]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1W2QsR-0006DT-RQ; Sun, 12 Jan 2014 13:39:20 -0600 Content-Type: multipart/signed; boundary="Apple-Mail=_BE0C71AA-382D-4B22-9C59-1F09903B89E7"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Sean Turner In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711E8766BEF@USMBX1.msg.corp.akamai.com> Date: Sun, 12 Jan 2014 14:39:18 -0500 Message-Id: <1306251D-5592-444A-9449-7B8F5744B0B6@ieca.com> References: <87eh4e7a2y.fsf@latte.josefsson.org> <52D17F30.1090008@drh-consultancy.co.uk> <52D1817B.9090303@drh-consultancy.co.uk> <2A0EFB9C05D0164E98F19BB0AF3708C711E8766BEF@USMBX1.msg.corp.akamai.com> To: "Salz, Rich" X-Mailer: Apple Mail (2.1827) 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: 173.73.130.192 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.4]) [173.73.130.192]:62914 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Cc: Simon Josefsson , "tls@ietf.org" Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Jan 2014 19:39:32 -0000 --Apple-Mail=_BE0C71AA-382D-4B22-9C59-1F09903B89E7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jan 11, 2014, at 16:57, Salz, Rich wrote: >> Given that private OID arcs are easy to obtain would it not be better = to get an IETF arc for this use, rather than using someone's personal = arc? >=20 > It absolutely shouldn't matter; OID's are opaque identifiers and a = "vanity IETF" number is silly. It's much more sensible to use something = that is already in use. >=20 > /r$ >=20 > -- =20 > Principal Security Engineer > Akamai Technology > Cambridge, MA > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls Agree with Rich here. OIDs are OIDs whether it=92s a private arc, a = google arc, or an IETF arc - it just doesn=92t matter as long as we pick = one and standardize it. If one has been used in the wild we ought to = just adopt it. spt= --Apple-Mail=_BE0C71AA-382D-4B22-9C59-1F09903B89E7 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEgDCCBHww ggJkoAMCAQICCQCdWMxKNutUeTANBgkqhkiG9w0BAQsFADAiMQswCQYDVQQGEwJVUzETMBEGA1UE ChMKSUVDQSwgSW5jLjAeFw0xMzA0MDMxNDUxMThaFw0xNDA0MDMxNDUxMThaMDgxCzAJBgNVBAYT AlVTMRMwEQYDVQQKEwpJRUNBLCBJbmMuMRQwEgYDVQQDEwtTZWFuIFR1cm5lcjCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAOpCGCRptT1m+bIpLTmbahZLZ0Qe4X99f8SgTQ7QISvUfpmn tfOD1oA1AttXlOULEERYubzvDnUTXvstFomQx0XTA67IaV+mw9ODRtG1hPN/erdKX6sU6rH4tsEb ba3Drr/I0HT3YVvD3SjWtGXjF12XLvTP6+LfMIIDTCAPiEd9KPG23D7skVu/4BvvmdLFI96OARhg wQ86M+lTIn83KRJlbbfAeIevbRx/rUB7D+uvMdWxOzR0KZJhd6dEeTXVwBXZG4rnQ4uFM+mRSiD4 rxDCyOuIuOzR07tnOyCRio6sRipOZvwQUWttdsgMEs6IxLdWsaTXcs1HjCsxrdedovMCAwEAAaOB njCBmzAOBgNVHQ8BAf8EBAMCBeAwHwYDVR0jBBgwFoAUAHRsSeXJUmFxTVY4q2HJ8uHl+w0wGwYD VR0RBBQwEoEQVHVybmVyU0BpZWNhLmNvbTAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vd3d3Lmll Y2EuY29tL2NybHMvaWVjYS5jcmwwFwYDVR0gBBAwDjAMBgorBgEEAYHXAAAAMA0GCSqGSIb3DQEB CwUAA4ICAQAimDYm77ppTi4vK6qJSUhyvCDMGb8mngiEXEYKxsfdHPWoDO7+06j7dAZ8sDD9/FtE kiUMyoNGSUmKHR+tGperVnNiM/Zk6WwCJv8dYZwhGXNQeEGzeys/UkFv7CFX7uDSn8GQeB8sOAZ1 N1hxV/TvT8qXvcRxP5+aWTAGAq3TKtCQxZjuU74L3st2hZiOhJlhjhqz0K5FIwWzXUK9uwhZe1th GUpDbRustVgmKN2Xa0pzwqI1VUO0jnWt24A4u59xo6DJQXzQVMhCx0xhpemuT9BrsBDTX8eJdI1i Wv9wp3ivSrfHjKXp8y8OGD+usiG40HCjj0W9C+dH0VfbgrB6QOI4vA9+kTg4mANth1cxyxwPYOSJ v0zi1qR0eDIGI//2v2/s6TmGuNqbnRa26Ldv5gGqS7xj32Fiaby6UOXs4+aAIWGZEOH+BXjozcvE eGBwjU/VRQYu6itR28PaNhNVji4D5ITaGxWWiycqK1EUaFraWHtk7W100ROX69xTeFVZP86D2ymi /aohl5Vb1vlYHdqlbgqjDRl9dPbTxVCXEHf+jkexcuwlLTvr7F+5DIN6c/EbCpRqQx3edy193L48 OGyRDh1/Wmzpew0VWWAWOSXGl/P9VzXf3Z6GPt7flN/V9iEJAa3Mo+w+eIdzJkHBWR+yJcqQcCRM MSyishMwLDGCAjgwggI0AgEBMC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklFQ0EsIEluYy4C CQCdWMxKNutUeTAJBgUrDgMCGgUAoIHfMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTE0MDExMjE5MzkxOVowIwYJKoZIhvcNAQkEMRYEFC+nlsAbOYUs69dYEKa+9TYH O9eFMD4GCSsGAQQBgjcQBDExMC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklFQ0EsIEluYy4C CQCdWMxKNutUeTBABgsqhkiG9w0BCRACCzExoC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklF Q0EsIEluYy4CCQCdWMxKNutUeTANBgkqhkiG9w0BAQEFAASCAQBftG6Ob1xZnAQs5ehTH284Ql3E nwDRfvw9W8wO5xSKzGriMEpZ37cOmnN6/5Ga/XJOlliax7Pn6b51Ovmjd6RDx0R6oVEcf8izeM3z E564T1NpekiX7d/U+MmsN2d+sExqa7bfBSmdb9OIAXXgT0FXtfHygKIx/XdR5AwlONExvVjWtgQt G3aQ91P27A3R4Kxpj6nXT05ZxQkDRKOlT7BCjJzxKAKa5/vdFeeP+6y+FTTGPJGS+sZJZCrMCbSl SUk0NzLFhfQIPZN7qbclg38wPnYWIwo+Z2P9gvcV1sbMu8go3uBdNACQpJ9i0Bht4/o8NUPPGBaf fT4eh2FR9dRGAAAAAAAA --Apple-Mail=_BE0C71AA-382D-4B22-9C59-1F09903B89E7-- From TurnerS@ieca.com Sun Jan 12 11:47:08 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ECC91AE019 for ; Sun, 12 Jan 2014 11:47:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 lA30er5Ppbk1 for ; Sun, 12 Jan 2014 11:47:07 -0800 (PST) Received: from gateway09.websitewelcome.com (gateway09.websitewelcome.com [69.93.164.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5D27A1AE013 for ; Sun, 12 Jan 2014 11:47:07 -0800 (PST) Received: by gateway09.websitewelcome.com (Postfix, from userid 507) id 9D82644D57697; Sun, 12 Jan 2014 13:46:56 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway09.websitewelcome.com (Postfix) with ESMTP id 7963744D57671 for ; Sun, 12 Jan 2014 13:46:56 -0600 (CST) Received: from [173.73.130.192] (port=62921 helo=[192.168.1.4]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1W2Qzn-0000xO-Cu; Sun, 12 Jan 2014 13:46:55 -0600 Content-Type: multipart/signed; boundary="Apple-Mail=_E0BD4B59-E113-4133-9765-6DDBCF1077A1"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Sean Turner In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711E8766BFF@USMBX1.msg.corp.akamai.com> Date: Sun, 12 Jan 2014 14:46:53 -0500 Message-Id: References: <87eh4e7a2y.fsf@latte.josefsson.org> <52D17F30.1090008@drh-consultancy.co.uk> <52D2AB07.7010806@polarssl.org> <52D2B678.7010302@drh-consultancy.co.uk> <52D2BD0B.1020007@polarssl.org> <2A0EFB9C05D0164E98F19BB0AF3708C711E8766BFF@USMBX1.msg.corp.akamai.com> To: "Salz, Rich" X-Mailer: Apple Mail (2.1827) 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: 173.73.130.192 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.4]) [173.73.130.192]:62921 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 12 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Cc: Simon Josefsson , "tls@ietf.org" Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Jan 2014 19:47:08 -0000 --Apple-Mail=_E0BD4B59-E113-4133-9765-6DDBCF1077A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Rich, Stephen and I will come up with a plan. I hope to get back to you = fairly soon being that Stephen and I chat at least once a week and we=92ve= known this was coming down the pipe. spt On Jan 12, 2014, at 14:21, Salz, Rich wrote: > I don't want this question to get lost in the general discussion so I = am explicitly addressing this to the AD's >=20 >>> I think we should keep this consistency and have the point format = for=20 >>> the new curves defined in one standard, whatever that might be. >=20 >> Since this format may be used by more than just TLS, and was = originally defined outside the IETF, what would >> be the most appropriate place to discuss extending it? >=20 > Some folks have been working on a concrete proposal, which is that we = "take" 0x41 as a new marker byte in ECPoint, and use that to mean "key = format defined by the curve" Ask IANA to maintain a curve point-format = registry. For example, Curve25519 would have 0x41 followed by the 32 = bytes of x-value for the key. >=20 > So, where should such a document be started? >=20 > Many of us are feeling pressure to implement ECDHA to get PFS for our = customers, and see the efficiency of Curve25519 as very important. That = is, the clock is ticking... >=20 > /r$ >=20 > -- =20 > Principal Security Engineer > Akamai Technology > Cambridge, MA >=20 --Apple-Mail=_E0BD4B59-E113-4133-9765-6DDBCF1077A1 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEgDCCBHww ggJkoAMCAQICCQCdWMxKNutUeTANBgkqhkiG9w0BAQsFADAiMQswCQYDVQQGEwJVUzETMBEGA1UE ChMKSUVDQSwgSW5jLjAeFw0xMzA0MDMxNDUxMThaFw0xNDA0MDMxNDUxMThaMDgxCzAJBgNVBAYT AlVTMRMwEQYDVQQKEwpJRUNBLCBJbmMuMRQwEgYDVQQDEwtTZWFuIFR1cm5lcjCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAOpCGCRptT1m+bIpLTmbahZLZ0Qe4X99f8SgTQ7QISvUfpmn tfOD1oA1AttXlOULEERYubzvDnUTXvstFomQx0XTA67IaV+mw9ODRtG1hPN/erdKX6sU6rH4tsEb ba3Drr/I0HT3YVvD3SjWtGXjF12XLvTP6+LfMIIDTCAPiEd9KPG23D7skVu/4BvvmdLFI96OARhg wQ86M+lTIn83KRJlbbfAeIevbRx/rUB7D+uvMdWxOzR0KZJhd6dEeTXVwBXZG4rnQ4uFM+mRSiD4 rxDCyOuIuOzR07tnOyCRio6sRipOZvwQUWttdsgMEs6IxLdWsaTXcs1HjCsxrdedovMCAwEAAaOB njCBmzAOBgNVHQ8BAf8EBAMCBeAwHwYDVR0jBBgwFoAUAHRsSeXJUmFxTVY4q2HJ8uHl+w0wGwYD VR0RBBQwEoEQVHVybmVyU0BpZWNhLmNvbTAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vd3d3Lmll Y2EuY29tL2NybHMvaWVjYS5jcmwwFwYDVR0gBBAwDjAMBgorBgEEAYHXAAAAMA0GCSqGSIb3DQEB CwUAA4ICAQAimDYm77ppTi4vK6qJSUhyvCDMGb8mngiEXEYKxsfdHPWoDO7+06j7dAZ8sDD9/FtE kiUMyoNGSUmKHR+tGperVnNiM/Zk6WwCJv8dYZwhGXNQeEGzeys/UkFv7CFX7uDSn8GQeB8sOAZ1 N1hxV/TvT8qXvcRxP5+aWTAGAq3TKtCQxZjuU74L3st2hZiOhJlhjhqz0K5FIwWzXUK9uwhZe1th GUpDbRustVgmKN2Xa0pzwqI1VUO0jnWt24A4u59xo6DJQXzQVMhCx0xhpemuT9BrsBDTX8eJdI1i Wv9wp3ivSrfHjKXp8y8OGD+usiG40HCjj0W9C+dH0VfbgrB6QOI4vA9+kTg4mANth1cxyxwPYOSJ v0zi1qR0eDIGI//2v2/s6TmGuNqbnRa26Ldv5gGqS7xj32Fiaby6UOXs4+aAIWGZEOH+BXjozcvE eGBwjU/VRQYu6itR28PaNhNVji4D5ITaGxWWiycqK1EUaFraWHtk7W100ROX69xTeFVZP86D2ymi /aohl5Vb1vlYHdqlbgqjDRl9dPbTxVCXEHf+jkexcuwlLTvr7F+5DIN6c/EbCpRqQx3edy193L48 OGyRDh1/Wmzpew0VWWAWOSXGl/P9VzXf3Z6GPt7flN/V9iEJAa3Mo+w+eIdzJkHBWR+yJcqQcCRM MSyishMwLDGCAjgwggI0AgEBMC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklFQ0EsIEluYy4C CQCdWMxKNutUeTAJBgUrDgMCGgUAoIHfMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTE0MDExMjE5NDY1NVowIwYJKoZIhvcNAQkEMRYEFAIF17jtBfVmGjQUWwsB1UZ0 ViKIMD4GCSsGAQQBgjcQBDExMC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklFQ0EsIEluYy4C CQCdWMxKNutUeTBABgsqhkiG9w0BCRACCzExoC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklF Q0EsIEluYy4CCQCdWMxKNutUeTANBgkqhkiG9w0BAQEFAASCAQCduTIuy9eU6BgmmVjzhTymwgkn ihxe7mJ9ONXcEQNi8/x0xzFDcXole3C0L83brlbfHD8P3flLTa3xMcI3RBNn+QfZ8kO6reAbYIB7 +hgI2SxHKo9j+HCreyWZYsK9NeqtN5G9cWvUupbFEA96TtA+xTdGPZv34PXdEaiB5RB27eCtY6uc P0cWcNBLFoyLLwAM4aY4WAFDUvXrOHnDXIWn4jst8q4v+GCPHlShbeUsJouZ4XnqpVWmmZr9Lyg6 vHlYa4YS/OamSTH8lNfAqFoE9QR6QHLYBk+t2FD3oo2NKlDsQaiAXe2fLAUUkgVYKuV+G2Al+ncd tVB74Pe+BR2TAAAAAAAA --Apple-Mail=_E0BD4B59-E113-4133-9765-6DDBCF1077A1-- From agl@google.com Sun Jan 12 11:54:20 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4BE1ACC85 for ; Sun, 12 Jan 2014 11:54:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.617 X-Spam-Level: X-Spam-Status: No, score=-1.617 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, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.538, 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 4f_0KHNih_CQ for ; Sun, 12 Jan 2014 11:54:19 -0800 (PST) Received: from mail-oa0-x22f.google.com (mail-oa0-x22f.google.com [IPv6:2607:f8b0:4003:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2621ACAD7 for ; Sun, 12 Jan 2014 11:54:19 -0800 (PST) Received: by mail-oa0-f47.google.com with SMTP id i7so7163775oag.34 for ; Sun, 12 Jan 2014 11:54:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=hGIk5dSgtrOoCDL080+CVRXhSfonyWX/pkrbynawKgo=; b=W3TrUOHvB+SrWCZh02TArOIfbGAaD3SxuQzXSvzcLU1nl8x37TFbyKLzw5ZOelQZqf ueh5cy0aSxOV6IShgPHUAewxzJrcNUPTxynI7Vl+FRRTh4PN2nIyhxqFuKhYPS8MFyaJ ugHv6xWxtZ8vzdQyscLnBcb7oI0+3kzCj+RDnBEtS1fUTd6j1ZjvE+mS8oX9BDxU+zA/ w0Dh8S3pXf8dp7Hl3Lgr9fquI6f6hWA5W0tO9kw7IR0I5sgdnVzpYxXp7dfdrQJEeoL5 /WuZJj2Cpud6ObDP7nKjksftXht1l5KWWeVOYBfKfLGDPkMiaRNgu/3XznZWr7JLEjFQ PWbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=hGIk5dSgtrOoCDL080+CVRXhSfonyWX/pkrbynawKgo=; b=MGAyJQ3mDfSlWM4pDBEFDJTH4isH6ihyAGqEDnTMNMOjKksdemwaWV52zrQ8jY+z5g LAC2c8GFRe31SDxXkD9tPuS5qgaMOhLubxKNANLHSCAKascUHdtWEtfFOPn+qm5c3FP2 a/wVBYM9U1DFGBDbxi2NQEeyBQHen6oiNU0vZ73tBlebLjDt9yXMwq+thpG6gvWueE+F aXH+mWS6x8syVpDlWdTx3Pc9tv1ie+mCxOA2GJzP+JSzjUWhYy025UeR1EiTRwKG5xKb 40xowD1LVbx3qZAzwTp9WK9zvYVVldTACip8CJZp4JyaKTM4IlzlFlb38z1YRdIkVxeI QfUQ== X-Gm-Message-State: ALoCoQn1uR7SYo36BpXIZpGD3oZTo+lu8FqTjZV+Z01NOBjUNwxBoHnZh447N4m9ia53z7mmz0Oqu5rWxrcglHV15mtJB0XUVzL0AxwsMNf7bDdVRtQGs8S34yyNJj5NCf4PJCWoFwuMJnYVkqWBH4OK3a1mITF3aE8bOmU/iuaGbpYmcTmIKJ0rurUTvZLZr80irZUXHR6Z X-Received: by 10.182.148.106 with SMTP id tr10mr26367obb.65.1389556448152; Sun, 12 Jan 2014 11:54:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.79.105 with HTTP; Sun, 12 Jan 2014 11:53:48 -0800 (PST) In-Reply-To: <52D2C028.4090001@polarssl.org> References: <87eh4e7a2y.fsf@latte.josefsson.org> <52D18475.10709@akr.io> <52D2C028.4090001@polarssl.org> From: Adam Langley Date: Sun, 12 Jan 2014 14:53:48 -0500 Message-ID: To: =?UTF-8?Q?Manuel_P=C3=A9gouri=C3=A9=2DGonnard?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "tls@ietf.org" Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Jan 2014 19:54:20 -0000 On Sun, Jan 12, 2014 at 11:17 AM, Manuel P=C3=A9gouri=C3=A9-Gonnard wrote: > Concerning implementations, unless I'm mistaken all the implementations o= f > Curve25519 you mention use custom routines for field arithmetic. I was th= inking > about other implementations might want to use a more generic bignum libra= ry, > whose output function will probably be big-endian since that's the orderi= ng > generally used in protocols. So for these implementations, big-endian wou= ld > probably be more natural. Using a generic bigint library is tough if you want to be constant time. (For example, integer division on Intel is variable time.) Also, internally, the library likely stores values as a series of words in little-endian order and is likely to be operating on little-endian systems, so little-endian is the more native representation. I guess my overall point is that I don't see the concept of an "integer" as being a good one to put into TLS here. I think keeping a DH function as something that operates on bytestrings makes sense. Maybe they'll want to operate on binary fields, or compress the 'y' coordinate into one of the unused bits, or export a different coordinate form. Cheers AGL From ietf@augustcellars.com Sun Jan 12 13:25:55 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B02D41AE013 for ; Sun, 12 Jan 2014 13:25:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWmGqsLgk7Be for ; Sun, 12 Jan 2014 13:25:54 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 159C71ACC85 for ; Sun, 12 Jan 2014 13:25:54 -0800 (PST) Received: from Philemon (static-50-47-50-163.sttl.wa.frontiernet.net [50.47.50.163]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 5A87238EFF for ; Sun, 12 Jan 2014 13:25:43 -0800 (PST) From: "Jim Schaad" To: References: <87eh4e7a2y.fsf@latte.josefsson.org> <52D17F30.1090008@drh-consultancy.co.uk> <52D1817B.9090303@drh-consultancy.co.uk> In-Reply-To: Date: Sun, 12 Jan 2014 13:24:09 -0800 Message-ID: <022901cf0fdc$a24a8c10$e6dfa430$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFWnXuEkJkYvLDeRYQr00gvv942UQHhhzHKAkQ/FSgB1bl8qgICcR8ymzKNuGA= Content-Language: en-us Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Jan 2014 21:25:55 -0000 You can get OIDs assigned out of the PKIX arc by IANA when the document progresses. Russ is currently moving control of the arc from him to IANA> Jim > -----Original Message----- > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Matt Caswell > Sent: Saturday, January 11, 2014 11:43 AM > To: Dr Stephen Henson > Cc: tls@ietf.org; Simon Josefsson > Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH > key agreement > > On 11 January 2014 17:38, Dr Stephen Henson > wrote: > > On 11/01/2014 17:31, Watson Ladd wrote: > >> But for that we need an OID. Does anyone know where to get one/have > >> one they want to assign? > >> > > > > Private OID arcs are easy to obtain. The following has been suggested > > for > > curve25519: > > > > 1.3.6.1.4.1.3029.1.5.1 > > > > iso(1) > > identified-organization(3) > > dod(6) > > internet(1) > > private(4) > > enterprise(1) > > gutmann(3029) > > ???(1) > > ???(5) > > ???(1) > > > > If we want to use all the curves mentioned they will of course all need > OIDs. > > Given that private OID arcs are easy to obtain would it not be better to get > an IETF arc for this use, rather than using someone's personal arc? (Is there > not an IETF arc already - that seems surprising!?) > > Matt > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From rsalz@akamai.com Sun Jan 12 14:44:08 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44A051ACC80 for ; Sun, 12 Jan 2014 14:44:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0L19ub06MM0g for ; Sun, 12 Jan 2014 14:44:06 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 672401AC7F1 for ; Sun, 12 Jan 2014 14:44:06 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 581824739D; Sun, 12 Jan 2014 22:43:55 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 4AFC54739C; Sun, 12 Jan 2014 22:43:55 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub5.kendall.corp.akamai.com [172.27.105.21]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 472402029; Sun, 12 Jan 2014 22:43:55 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.77]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Sun, 12 Jan 2014 17:43:54 -0500 From: "Salz, Rich" To: Sean Turner Date: Sun, 12 Jan 2014 17:43:52 -0500 Thread-Topic: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement Thread-Index: Ac8Pzw/TqpQ1rzHcRVillkZoHKkRwQAGJlgg Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711E8766C05@USMBX1.msg.corp.akamai.com> References: <87eh4e7a2y.fsf@latte.josefsson.org> <52D17F30.1090008@drh-consultancy.co.uk> <52D2AB07.7010806@polarssl.org> <52D2B678.7010302@drh-consultancy.co.uk> <52D2BD0B.1020007@polarssl.org> <2A0EFB9C05D0164E98F19BB0AF3708C711E8766BFF@USMBX1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Simon Josefsson , "tls@ietf.org" Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Jan 2014 22:44:08 -0000 > Stephen and I will come up with a plan. I hope to get back to you fairly= soon being Great, thanks. If there's anything I can do to help please let me know. /r$ -- =20 Principal Security Engineer Akamai Technology Cambridge, MA From mpg@polarssl.org Sun Jan 12 15:38:28 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E305E1ACC8B for ; Sun, 12 Jan 2014 15:38:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.394 X-Spam-Level: X-Spam-Status: No, score=0.394 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVZ42flZRj3w for ; Sun, 12 Jan 2014 15:38:27 -0800 (PST) Received: from vps2.brainspark.nl (vps2.brainspark.nl [141.138.204.106]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC831AC7F3 for ; Sun, 12 Jan 2014 15:38:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:CC:To:MIME-Version:From:Date:Message-ID; bh=50vi3oesV5YHiSd14cQDQ/XBTAqbeotzNXiW6FdpJuo=; b=iYir4Uyyc+wd3Lo3v7L9yWs0vXFsqyCyvSQS7pgKOAfDMhGGTzqTuRJBboSoDQZit9JraSpcQIN7BcnR6XoIn+MKw6T4RaFq0oOG+Kn6K8oowCzAYQVVudN23tUUj9OfGD474E3FLvzhhcw1XDuAzL0Bc4e8mpxl0aKERa0S3cg=; Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.brainspark.nl with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1W2UUi-0004Kv-Bo; Mon, 13 Jan 2014 00:31:04 +0100 Message-ID: <52D32766.3000202@polarssl.org> Date: Mon, 13 Jan 2014 00:38:14 +0100 From: =?UTF-8?B?TWFudWVsIFDDqWdvdXJpw6ktR29ubmFyZA==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.1.1 MIME-Version: 1.0 To: Adam Langley References: <87eh4e7a2y.fsf@latte.josefsson.org> <52D18475.10709@akr.io> <52D2C028.4090001@polarssl.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 88.165.216.11 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.brainspark.nl) Cc: "tls@ietf.org" Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Jan 2014 23:38:29 -0000 On 12/01/2014 20:53, Adam Langley wrote: > On Sun, Jan 12, 2014 at 11:17 AM, Manuel PĂ©gouriĂ©-Gonnard > wrote: >> Concerning implementations, unless I'm mistaken all the implementations of >> Curve25519 you mention use custom routines for field arithmetic. I was thinking >> about other implementations might want to use a more generic bignum library, >> whose output function will probably be big-endian since that's the ordering >> generally used in protocols. So for these implementations, big-endian would >> probably be more natural. > > Using a generic bigint library is tough if you want to be constant > time. (For example, integer division on Intel is variable time.) > Right, but it seems to me some randomisation can help here. > Also, internally, the library likely stores values as a series of > words in little-endian order and is likely to be operating on > little-endian systems, so little-endian is the more native > representation. > Agreed. > I guess my overall point is that I don't see the concept of an > "integer" as being a good one to put into TLS here. I think keeping a > DH function as something that operates on bytestrings makes sense. > Maybe they'll want to operate on binary fields, or compress the 'y' > coordinate into one of the unused bits, or export a different > coordinate form. > If there was currently no concept of "integer" in TLS, I'd totally agree with you here. But since there is, and they usually are represented as big-endian, there is a tension between being consistent with existing usage and going the arguably better way. Manuel. From alangley@gmail.com Sun Jan 12 17:13:02 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFCC91ACCEA for ; Sun, 12 Jan 2014 17:13:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 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, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TaAkZmApckyN for ; Sun, 12 Jan 2014 17:13:01 -0800 (PST) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 301A81ACC91 for ; Sun, 12 Jan 2014 17:13:00 -0800 (PST) Received: by mail-lb0-f171.google.com with SMTP id w7so4925487lbi.30 for ; Sun, 12 Jan 2014 17:12:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=n/gjIEP0YGKtoiYjIcM39XV0teFcvX0LG8uRmDCZxwI=; b=IiFNc/kS5+SKv2bT/JOWQdcUIZ91w349An3J/i2HLUbizbnqS6qzIf+8InCvQfDAko fNSO+i033nS90g7yzAZqoxPU98unPCzVaIt4eQhKngcGTa5FJAC4iX45QP2oArK+7Oud GcJ69/HVKD7M7upoLXvh3BsOMLRkfjm/bNMRenGLOcy5O0726vlCmB1TAYPBRo+nhtMD bBxXGpVy1gO3awrzJDM/TocLahGrUJb4NJSCqgg6Umpi7+ckgyqwImQbwYEdmhcIKi9b /Zry26R5W8LyNOmwzS1f5KJ6iJlXDcheld8YI12z0ambph1CaEQ6SLYWzM6BIv/31e+O UB4w== MIME-Version: 1.0 X-Received: by 10.152.170.199 with SMTP id ao7mr9387906lac.40.1389575569724; Sun, 12 Jan 2014 17:12:49 -0800 (PST) Sender: alangley@gmail.com Received: by 10.112.162.200 with HTTP; Sun, 12 Jan 2014 17:12:49 -0800 (PST) In-Reply-To: <52D32766.3000202@polarssl.org> References: <87eh4e7a2y.fsf@latte.josefsson.org> <52D18475.10709@akr.io> <52D2C028.4090001@polarssl.org> <52D32766.3000202@polarssl.org> Date: Sun, 12 Jan 2014 20:12:49 -0500 X-Google-Sender-Auth: 6ws8wql48RYwXOLWHm4LwruyYpc Message-ID: From: Adam Langley To: =?UTF-8?Q?Manuel_P=C3=A9gouri=C3=A9=2DGonnard?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "tls@ietf.org" Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Jan 2014 01:13:03 -0000 On Sun, Jan 12, 2014 at 6:38 PM, Manuel P=C3=A9gouri=C3=A9-Gonnard wrote: > If there was currently no concept of "integer" in TLS, I'd totally agree = with > you here. But since there is, and they usually are represented as big-end= ian, > there is a tension between being consistent with existing usage and going= the > arguably better way. When it comes down to it - reversing 32 bytes isn't going to make or break it in either way. I guess I just see a byte string orientated interface to DH functions as being the right way to go. We have a legacy of over-general elliptic curve support that tries to support arbitrary curves and that led to 'integers' being a concept in TLS regarding EC. However, nobody(?) implements explicit_prime/explicit_char2 so what we actually have are three DH functions: p256, p384 and p521 and they serialise as 0x04 in practice. Although it's an opaque <1..2^8-1> in RFC 4492, the big-endian is coming from X9.62. So, given an opaque<1..2^8-1> in TLS and a desire to plug curve25519 in there, using curve25519's format just seems less surprising and simpler. Cheers AGL --=20 Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From rsalz@akamai.com Sun Jan 12 18:17:59 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B51731AD34C for ; Sun, 12 Jan 2014 18:17:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.138 X-Spam-Level: X-Spam-Status: No, score=-2.138 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3d_3KF6E3cW for ; Sun, 12 Jan 2014 18:17:58 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 21C071ACCF9 for ; Sun, 12 Jan 2014 18:17:57 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 041E2481BB; Mon, 13 Jan 2014 02:17:47 +0000 (GMT) Received: from prod-mail-relay03.akamai.com (prod-mail-relay03.akamai.com [172.27.8.26]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id EBD6B481A5; Mon, 13 Jan 2014 02:17:46 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay03.akamai.com (Postfix) with ESMTP id D1B672FD7C; Mon, 13 Jan 2014 02:17:46 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.77]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Sun, 12 Jan 2014 21:17:46 -0500 From: "Salz, Rich" To: Adam Langley , =?utf-8?B?TWFudWVsIFDDqWdvdXJpw6ktR29ubmFyZA==?= Date: Sun, 12 Jan 2014 21:17:45 -0500 Thread-Topic: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement Thread-Index: Ac8P/Jjhxoj3Kv5WTbSGORB/h+8xpgACQRrA Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711E8766C11@USMBX1.msg.corp.akamai.com> References: <87eh4e7a2y.fsf@latte.josefsson.org> <52D18475.10709@akr.io> <52D2C028.4090001@polarssl.org> <52D32766.3000202@polarssl.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Jan 2014 02:17:59 -0000 PiBTbywgZ2l2ZW4gYW4gb3BhcXVlPDEuLjJeOC0xPiBpbiBUTFMgYW5kIGEgZGVzaXJlIHRvIHBs dWcgY3VydmUyNTUxOSBpbiB0aGVyZSwgdXNpbmcgY3VydmUyNTUxOSdzIGZvcm1hdCBqdXN0IHNl ZW1zIGxlc3Mgc3VycHJpc2luZyBhbmQgc2ltcGxlci4NCg0KKzENCg0KDQotLSAgDQpQcmluY2lw YWwgU2VjdXJpdHkgRW5naW5lZXINCkFrYW1haSBUZWNobm9sb2d5DQpDYW1icmlkZ2UsIE1BDQoN Cg== From mpg@polarssl.org Sun Jan 12 18:41:46 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D44921AD627 for ; Sun, 12 Jan 2014 18:41:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.394 X-Spam-Level: X-Spam-Status: No, score=0.394 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VND0WShji88r for ; Sun, 12 Jan 2014 18:41:46 -0800 (PST) Received: from vps2.brainspark.nl (vps2.brainspark.nl [141.138.204.106]) by ietfa.amsl.com (Postfix) with ESMTP id C79251ACCF9 for ; Sun, 12 Jan 2014 18:41:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:CC:To:MIME-Version:From:Date:Message-ID; bh=GRjG1w2vEUTzXPZQoMCCVJO2BQsTUsfaryNvK5A4NwQ=; b=NrIngtsNkjeecwafbTi3JWYQrytkMZ53xHcdpDGTyGtmh4pZcNAUuYZ50ZOjiN23PwQa1VBwQJDzkwlBxMX6hlBi3MOD12rbcmHGe/3XxxV1+47cH4E/7b0t7Z93p1kbzwi78tAE4jnmzCbSbyh4FnIhhfX0iB9MZGp203iXYXU=; Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.brainspark.nl with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1W2XLs-0004mb-De; Mon, 13 Jan 2014 03:34:21 +0100 Message-ID: <52D3524E.8040805@polarssl.org> Date: Mon, 13 Jan 2014 03:41:18 +0100 From: =?UTF-8?B?TWFudWVsIFDDqWdvdXJpw6ktR29ubmFyZA==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.1.1 MIME-Version: 1.0 To: "Salz, Rich" , Adam Langley References: <87eh4e7a2y.fsf@latte.josefsson.org> <52D18475.10709@akr.io> <52D2C028.4090001@polarssl.org> <52D32766.3000202@polarssl.org> <2A0EFB9C05D0164E98F19BB0AF3708C711E8766C11@USMBX1.msg.corp.akamai.com> In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711E8766C11@USMBX1.msg.corp.akamai.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 88.165.216.11 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.brainspark.nl) Cc: "tls@ietf.org" Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Jan 2014 02:41:46 -0000 On 13/01/2014 03:17, Salz, Rich wrote: >> So, given an opaque<1..2^8-1> in TLS and a desire to plug curve25519 in >> there, using curve25519's format just seems less surprising and simpler. > > +1 > Just to be clear: curve25519's format, plus a leading byte, (eg. 0x41) to indicate "curve specific encoding"? Manuel. From watsonbladd@gmail.com Sun Jan 12 18:55:17 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 851311AD93D for ; Sun, 12 Jan 2014 18:55:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hme4606aceCD for ; Sun, 12 Jan 2014 18:55:16 -0800 (PST) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 082C31AD8C4 for ; Sun, 12 Jan 2014 18:55:15 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id e4so602705wiv.0 for ; Sun, 12 Jan 2014 18:55:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=tOidq/YO03zk2qEi1xmCSp+JT39XxQEAIjd4v95ODx4=; b=0+3gGVUzGT6EiwuC10c0ybxmTbAjcknFpVW3OV2nmMRQlysIBTHb5/nRZ/+O7l+VTd Vg8avF26TVL2nGHJ7gOiSz4DHzaJhLH1UxZ7cu829mo0UET6NlJGDoyROxYbCS9tIUVM V/a4/ez4cDqT/7Z8UveTXf4S/emuqxqK/Phj5N/CYVxpVVNZowXRYQGatglPV3F2z2aN qihqgY2Yho3CuCAShd8Li84YFgbDpUg8iIEHWxbGf8mB87uwXofkxUtJAHnEH7rxijdV r2cVo5tIxhMilfwK6NIqc4lus8tCiUfSfkRovFubiBM1I58PGvyEjaN9kY9dhvhx3u5R BuGQ== MIME-Version: 1.0 X-Received: by 10.194.187.101 with SMTP id fr5mr368797wjc.76.1389581704768; Sun, 12 Jan 2014 18:55:04 -0800 (PST) Received: by 10.194.242.131 with HTTP; Sun, 12 Jan 2014 18:55:04 -0800 (PST) In-Reply-To: <52D3524E.8040805@polarssl.org> References: <87eh4e7a2y.fsf@latte.josefsson.org> <52D18475.10709@akr.io> <52D2C028.4090001@polarssl.org> <52D32766.3000202@polarssl.org> <2A0EFB9C05D0164E98F19BB0AF3708C711E8766C11@USMBX1.msg.corp.akamai.com> <52D3524E.8040805@polarssl.org> Date: Sun, 12 Jan 2014 18:55:04 -0800 Message-ID: From: Watson Ladd To: =?UTF-8?Q?Manuel_P=C3=A9gouri=C3=A9=2DGonnard?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Adam Langley , "tls@ietf.org" Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Jan 2014 02:55:17 -0000 On Sun, Jan 12, 2014 at 6:41 PM, Manuel P=C3=A9gouri=C3=A9-Gonnard wrote: > On 13/01/2014 03:17, Salz, Rich wrote: >>> So, given an opaque<1..2^8-1> in TLS and a desire to plug curve25519 in >>> there, using curve25519's format just seems less surprising and simpler= . >> >> +1 >> > Just to be clear: curve25519's format, plus a leading byte, (eg. 0x41) to > indicate "curve specific encoding"? I have no objection to this idea. If a snap/false/jump/start in TLS 1.3 needs to indicate the curve in a compact way, we can handle that later. > > Manuel. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --=20 "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From watsonbladd@gmail.com Sun Jan 12 19:23:09 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 917E71ADBCF for ; Sun, 12 Jan 2014 19:23:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Z1dpzAmMfZP for ; Sun, 12 Jan 2014 19:23:07 -0800 (PST) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 79BAB1ADBCC for ; Sun, 12 Jan 2014 19:23:07 -0800 (PST) Received: by mail-we0-f176.google.com with SMTP id q58so1768113wes.35 for ; Sun, 12 Jan 2014 19:22:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QuYATVakO3Gvc0rHAA0bNJLFRqi38rnANa+g6swLPAg=; b=PLuA5WGRZRkYnrGQdlO56d7NQpT7P7tyJ2TXkOXS/gk7DCbAtpRHKY75Cj5JHUV7+W iL6FaJpuRUbwI3yj/+Fd31/2C70mYyP7twqq+rHiVfn79NpQXVPznip1Drc2OBZTznEG dmhIgFEbPZZoFPHXBai05a7tKRNSB89mIHnMVQbxFEJSE2+uJuQ9X+E46grQvhQqfzDH 5sFq3Z6ZG/Kxoy+VccA3KPuIi0vuYmRBo+CUw/pbgXXhEXwizSIEWqDjosnnQv4cZUi+ LAy+gbhlUGPtVWKgYTLtXdl8vQJzQIAwsatfQx3PY0KltpaVHolKmXT6c8jY7DO0vD/Q vy2A== MIME-Version: 1.0 X-Received: by 10.180.19.35 with SMTP id b3mr4917326wie.20.1389583376086; Sun, 12 Jan 2014 19:22:56 -0800 (PST) Received: by 10.194.242.131 with HTTP; Sun, 12 Jan 2014 19:22:55 -0800 (PST) In-Reply-To: <87eh4e7a2y.fsf@latte.josefsson.org> References: <87eh4e7a2y.fsf@latte.josefsson.org> Date: Sun, 12 Jan 2014 19:22:55 -0800 Message-ID: From: Watson Ladd To: Simon Josefsson Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Jan 2014 03:23:09 -0000 On Sat, Jan 11, 2014 at 8:32 AM, Simon Josefsson wrote: > Dear WG, > > I may have missed to announce this document before, since some people > appear to have missed it. This email is an attempt to introduce the > draft to the TLS WG properly. > > This draft started out as specifying Curve25519 ECDHE key agreement for > TLS, back on September. Manuel Pegourie-Gonnard jumped in as co-author > and has added details on public/private key representation, shared > secret computation, and test vectors, for the -02 draft. > > In the latest -03 version of the draft, I have changed the document to > specify EC Named Curve code points for all "additional elliptic curves" > (i.e., Curve25519, E382, M383, Curve3617, M511, E521). Some of the > Curve25519-related text may no longer be applicable to all curves, but > hopefully that can be fixed later on. > > The latest draft is here: > http://tools.ietf.org/html/draft-josefsson-tls-curve25519-03 > > The additional curves come from the following CFRG draft, and my current > thinking is that our draft (for TLS) would stay in sync with the list of > curves in the CFRG document. > > http://tools.ietf.org/html/draft-ladd-safecurves-02 > > We'd appreciate general feedback on the draft, especially if there is > any interest in adopting this document, and particular feedback on the > following points: > > 1) Do we need all these curves defined for TLS? What is the selection > critera for including/exluding some of the curves? Is that a TLS > process, or an CFRG process? It's unclear. Eric Resola (in a cousin n-removed from this email) seems to think that CFRG should do it, but unless he asks the CFRG chairs there doesn't seem to be a process for this conversation to happen. Part of the reason is that Curve25519 is secure, so in some sense there is nothing to discuss on the CFRG end. It comes down to "what should be supported" and efficiency argues Curve25519 should be in the mix. The easiest solution is someone to ask if anyone disagrees, and if no one does, consider the security conversation over. > > 2) Does description of private/public key representation and computation > of shared secret belong in draft-josefsson-tls-curve25519? It has to > be somewhere, I believ, but possibly this could go into > draft-ladd-safecurves, or some other generic document, unless there > are TLS-specific aspects. Insight into this would be appreciated. It looks good, but the specification should ideally be in the draft or cited in an informative RFC. draft-ladd aims to completely specify what is exchanged, and so is a better (IMHO) source for the normative part then the curve25519 paper. Worst case you can write something close to the specification section of "Cryptography in NaCl" or "Curve25519: New Diffie-Hellman Speed Records" in the case draft-ladd fails to progress. Sincerely, Watson Ladd > > Cheers, > /Simon > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From rsalz@akamai.com Sun Jan 12 20:44:56 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 870931ADEC4 for ; Sun, 12 Jan 2014 20:44:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.438 X-Spam-Level: X-Spam-Status: No, score=-4.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uYoQOhQ7oYoa for ; Sun, 12 Jan 2014 20:44:55 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 540481A1EF9 for ; Sun, 12 Jan 2014 20:44:55 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id E9319284E8; Mon, 13 Jan 2014 04:44:43 +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 D6CDE284DB; Mon, 13 Jan 2014 04:44:43 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub5.kendall.corp.akamai.com [172.27.105.21]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id D35C12029; Mon, 13 Jan 2014 04:44:43 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.77]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Sun, 12 Jan 2014 23:44:43 -0500 From: "Salz, Rich" To: =?utf-8?B?TWFudWVsIFDDqWdvdXJpw6ktR29ubmFyZA==?= , Adam Langley Date: Sun, 12 Jan 2014 23:44:37 -0500 Thread-Topic: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement Thread-Index: Ac8QCPnUYQwXEM7XT8C+d9hn1A8j8wAESGfg Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711E8766C1A@USMBX1.msg.corp.akamai.com> References: <87eh4e7a2y.fsf@latte.josefsson.org> <52D18475.10709@akr.io> <52D2C028.4090001@polarssl.org> <52D32766.3000202@polarssl.org> <2A0EFB9C05D0164E98F19BB0AF3708C711E8766C11@USMBX1.msg.corp.akamai.com> <52D3524E.8040805@polarssl.org> In-Reply-To: <52D3524E.8040805@polarssl.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Jan 2014 04:44:56 -0000 PiBKdXN0IHRvIGJlIGNsZWFyOiBjdXJ2ZTI1NTE5J3MgZm9ybWF0LCBwbHVzIGEgbGVhZGluZyBi eXRlLCAoZWcuIDB4NDEpIHRvIGluZGljYXRlICJjdXJ2ZSBzcGVjaWZpYyBlbmNvZGluZyI/DQoN Clllcy4NCg0KLS0gIA0KUHJpbmNpcGFsIFNlY3VyaXR5IEVuZ2luZWVyDQpBa2FtYWkgVGVjaG5v bG9neQ0KQ2FtYnJpZGdlLCBNQQ0K From ynir@checkpoint.com Sun Jan 12 23:27:36 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D26A1AE058 for ; Sun, 12 Jan 2014 23:27:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.439 X-Spam-Level: X-Spam-Status: No, score=-7.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, 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 kG-rGFFyN6tL for ; Sun, 12 Jan 2014 23:27:34 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 075191AE030 for ; Sun, 12 Jan 2014 23:27:33 -0800 (PST) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id s0D7RGQT004829; Mon, 13 Jan 2014 09:27:16 +0200 X-CheckPoint: {52D38FD4-0-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.110]) by IL-EX10.ad.checkpoint.com ([169.254.2.228]) with mapi id 14.03.0123.003; Mon, 13 Jan 2014 09:27:16 +0200 From: Yoav Nir To: Watson Ladd Thread-Topic: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement Thread-Index: AQHPEA7LhmYT3caF+UGapYIBPsTFZJqCIB0A Date: Mon, 13 Jan 2014 07:27:14 +0000 Message-ID: <448F91C2-1658-4BB1-8E69-76B1D1ACF002@checkpoint.com> References: <87eh4e7a2y.fsf@latte.josefsson.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.69] x-kse-antivirus-interceptor-info: protection disabled Content-Type: text/plain; charset="us-ascii" Content-ID: <8F6C05F18360D540BFC67D0391534DF5@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Simon Josefsson , "tls@ietf.org" Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Jan 2014 07:27:36 -0000 On Jan 13, 2014, at 5:22 AM, Watson Ladd wrote: > On Sat, Jan 11, 2014 at 8:32 AM, Simon Josefsson wr= ote: >> Dear WG, >>=20 >> I may have missed to announce this document before, since some people >> appear to have missed it. This email is an attempt to introduce the >> draft to the TLS WG properly. >>=20 >> This draft started out as specifying Curve25519 ECDHE key agreement for >> TLS, back on September. Manuel Pegourie-Gonnard jumped in as co-author >> and has added details on public/private key representation, shared >> secret computation, and test vectors, for the -02 draft. >>=20 >> In the latest -03 version of the draft, I have changed the document to >> specify EC Named Curve code points for all "additional elliptic curves" >> (i.e., Curve25519, E382, M383, Curve3617, M511, E521). Some of the >> Curve25519-related text may no longer be applicable to all curves, but >> hopefully that can be fixed later on. >>=20 >> The latest draft is here: >> http://tools.ietf.org/html/draft-josefsson-tls-curve25519-03 >>=20 >> The additional curves come from the following CFRG draft, and my current >> thinking is that our draft (for TLS) would stay in sync with the list of >> curves in the CFRG document. >>=20 >> http://tools.ietf.org/html/draft-ladd-safecurves-02 >>=20 >> We'd appreciate general feedback on the draft, especially if there is >> any interest in adopting this document, and particular feedback on the >> following points: >>=20 >> 1) Do we need all these curves defined for TLS? What is the selection >> critera for including/exluding some of the curves? Is that a TLS >> process, or an CFRG process? >=20 > It's unclear. Eric Resola (in a cousin n-removed from this email) > seems to think that > CFRG should do it, but unless he asks the CFRG chairs there doesn't seem = to be > a process for this conversation to happen. Part of the reason is that > Curve25519 is > secure, so in some sense there is nothing to discuss on the CFRG end. > It comes down to > "what should be supported" and efficiency argues Curve25519 should be > in the mix. Or you can do the equivalent of the signature authentication in IKEv2 draft= : http://tools.ietf.org/html/draft-kivinen-ipsecme-signature-auth-04 Just create a draft for a TLS extension that allows you to specify a curve = and point format as OIDs. Not sure whether that's a good idea, though. > The easiest solution is someone to ask if anyone disagrees, and if no > one does, consider > the security conversation over. That didn't work so well for Dragonfly, did it? Yoav From watsonbladd@gmail.com Mon Jan 13 07:21:54 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 638C51AE1B7 for ; Mon, 13 Jan 2014 07:21:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sebtr8L-PEbA for ; Mon, 13 Jan 2014 07:21:52 -0800 (PST) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 0680A1AE1F9 for ; Mon, 13 Jan 2014 07:21:46 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id l18so2882481wgh.3 for ; Mon, 13 Jan 2014 07:21:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2LH5OVHwQgd/wwpLpCE82h6UNUPWjSZpP+Bm2b3P9S4=; b=FrE9siPN0THBOCiiBNEKU3w9DR3yGfCZJp+Ch+1omsj3NQDnYeD8W5O8thyK9mY9LW 7S1ZOBDLyh3bidTBjf5KMKWJ/JnMapF8XjbAazo97LFTQw0K7jBPWu2gXL3tMtVbDui1 tG2sv4dMINVBgUSryyeBT6dDvF8W9fiSnXrcz/5Yw2hfstZDCoZPh17Pk//H4N3Erd2T eczFKF2oTr+4IG6m+6+MVjXC3oSFlvVWHgS6QkmvbrrQbMf+KhNgsqeSJFUYrtAA/W8t U7eTVlBH1JwDdJG8iJQlEs1lYnUxMTI5aN7HEmCXT3zoq5UkeCXb00AaLjNwlrV72UPJ oivg== MIME-Version: 1.0 X-Received: by 10.194.133.34 with SMTP id oz2mr22508981wjb.14.1389626495584; Mon, 13 Jan 2014 07:21:35 -0800 (PST) Received: by 10.194.242.131 with HTTP; Mon, 13 Jan 2014 07:21:35 -0800 (PST) In-Reply-To: <448F91C2-1658-4BB1-8E69-76B1D1ACF002@checkpoint.com> References: <87eh4e7a2y.fsf@latte.josefsson.org> <448F91C2-1658-4BB1-8E69-76B1D1ACF002@checkpoint.com> Date: Mon, 13 Jan 2014 07:21:35 -0800 Message-ID: From: Watson Ladd To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Cc: Simon Josefsson , "tls@ietf.org" Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Jan 2014 15:21:54 -0000 On Sun, Jan 12, 2014 at 11:27 PM, Yoav Nir wrote: > > On Jan 13, 2014, at 5:22 AM, Watson Ladd wrote: > >> On Sat, Jan 11, 2014 at 8:32 AM, Simon Josefsson wrote: >>> Dear WG, >>> >>> I may have missed to announce this document before, since some people >>> appear to have missed it. This email is an attempt to introduce the >>> draft to the TLS WG properly. >>> >>> This draft started out as specifying Curve25519 ECDHE key agreement for >>> TLS, back on September. Manuel Pegourie-Gonnard jumped in as co-author >>> and has added details on public/private key representation, shared >>> secret computation, and test vectors, for the -02 draft. >>> >>> In the latest -03 version of the draft, I have changed the document to >>> specify EC Named Curve code points for all "additional elliptic curves" >>> (i.e., Curve25519, E382, M383, Curve3617, M511, E521). Some of the >>> Curve25519-related text may no longer be applicable to all curves, but >>> hopefully that can be fixed later on. >>> >>> The latest draft is here: >>> http://tools.ietf.org/html/draft-josefsson-tls-curve25519-03 >>> >>> The additional curves come from the following CFRG draft, and my current >>> thinking is that our draft (for TLS) would stay in sync with the list of >>> curves in the CFRG document. >>> >>> http://tools.ietf.org/html/draft-ladd-safecurves-02 >>> >>> We'd appreciate general feedback on the draft, especially if there is >>> any interest in adopting this document, and particular feedback on the >>> following points: >>> >>> 1) Do we need all these curves defined for TLS? What is the selection >>> critera for including/exluding some of the curves? Is that a TLS >>> process, or an CFRG process? >> >> It's unclear. Eric Resola (in a cousin n-removed from this email) >> seems to think that >> CFRG should do it, but unless he asks the CFRG chairs there doesn't seem to be >> a process for this conversation to happen. Part of the reason is that >> Curve25519 is >> secure, so in some sense there is nothing to discuss on the CFRG end. >> It comes down to >> "what should be supported" and efficiency argues Curve25519 should be >> in the mix. > > Or you can do the equivalent of the signature authentication in IKEv2 draft: > http://tools.ietf.org/html/draft-kivinen-ipsecme-signature-auth-04 > > Just create a draft for a TLS extension that allows you to specify a curve and point format as OIDs. Not sure whether that's a good idea, though. > >> The easiest solution is someone to ask if anyone disagrees, and if no >> one does, consider >> the security conversation over. > > That didn't work so well for Dragonfly, did it? The huge difference between these curves and Dragonfly is that these curves satisfy every known property required to make ECDH secure, and also some designed to make implementation easier. Dragonfly had obvious security flaws. If you want more of a process, go ahead and start it. But I think what you will get is a bunch of "Yes, these numbers are prime" and "I clicked all the links on safecurves.cr.yp.to and used PARI to verify everything". If they are missing attacks, that's one thing, but they aren't. Security conversations are never over: it's entirely possible that tomorrow a paper hits IACR which identifies a new set of weaknesses in elliptic curves, and then we have to go through and see which ones fall. Sincerely, Watson Ladd > > Yoav > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From kaie@kuix.de Mon Jan 13 07:45:09 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36DF71ADF86 for ; Mon, 13 Jan 2014 07:45:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_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 GBi1wbZmvzQ8 for ; Mon, 13 Jan 2014 07:45:07 -0800 (PST) Received: from s15531995.onlinehome-server.info (s15531995.onlinehome-server.info [IPv6:2001:8d8:910:de00::2f:a36d]) by ietfa.amsl.com (Postfix) with ESMTP id 06F241ADF53 for ; Mon, 13 Jan 2014 07:45:06 -0800 (PST) Received: from [192.168.2.253] (p4FF35775.dip0.t-ipconnect.de [79.243.87.117]) by s15531995.onlinehome-server.info (Postfix) with ESMTPSA id AF31142980E2 for ; Mon, 13 Jan 2014 16:44:54 +0100 (CET) Message-ID: <1389627894.16063.26.camel@lapkaie> From: Kai Engert To: tls Date: Mon, 13 Jan 2014 16:44:54 +0100 In-Reply-To: <1389392562.13026.111.camel@lapkaie> References: <1389371947.30279.56.camel@lapkaie> <52D047C3.20208@akr.io> <1389392562.13026.111.camel@lapkaie> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.5 (3.8.5-2.fc19) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: Re: [TLS] Ideas for TLS 1.3: Server key continuity and certificate reporting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Jan 2014 15:45:09 -0000 On Fr, 2014-01-10 at 23:22 +0100, Kai Engert wrote: > > And that > > is probably exactly what they'll do, because they do it already > > (“QUANTUMRESET”) and it's a very, very easy attack; much easier than > > getting a forged certificate. > > Sorry, I don't understand this part of the argument. > Where can I read more about "QUANTUMRESET"? In the meantime I've learned what this is about. It's a mechanism to implement MITM on a connection. I believe your point is, it doesn't matter which pysical connectivity option a client uses to connect to the Internet - because the adversary doesn't need to manipulate connections close to the victim, but rather could enforce that MITM remains always active for a particular client. I agree, for state level attackers who can manipulate the Internet backbone, this could block the ability of a victim to report a falsely issued certificate to the real server. Question is, is the quantum server really sufficiently reliable enough to be active at all times, no expections? For each victim, a onetime glitch or downtime would be sufficient to get the false certificate reported. Kai From kaie@kuix.de Mon Jan 13 07:56:39 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56DA41AE098 for ; Mon, 13 Jan 2014 07:56:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RI94WDFFJ07S for ; Mon, 13 Jan 2014 07:56:37 -0800 (PST) Received: from s15531995.onlinehome-server.info (s15531995.onlinehome-server.info [IPv6:2001:8d8:910:de00::2f:a36d]) by ietfa.amsl.com (Postfix) with ESMTP id 64D361ADF53 for ; Mon, 13 Jan 2014 07:56:36 -0800 (PST) Received: from [192.168.2.253] (p4FF35775.dip0.t-ipconnect.de [79.243.87.117]) by s15531995.onlinehome-server.info (Postfix) with ESMTPSA id 8CC4642980EB for ; Mon, 13 Jan 2014 16:56:25 +0100 (CET) Message-ID: <1389628585.16063.34.camel@lapkaie> From: Kai Engert To: tls Date: Mon, 13 Jan 2014 16:56:25 +0100 In-Reply-To: <1389627894.16063.26.camel@lapkaie> References: <1389371947.30279.56.camel@lapkaie> <52D047C3.20208@akr.io> <1389392562.13026.111.camel@lapkaie> <1389627894.16063.26.camel@lapkaie> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.5 (3.8.5-2.fc19) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Ideas for TLS 1.3: Server key continuity and certificate reporting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Jan 2014 15:56:39 -0000 On Mo, 2014-01-13 at 16:44 +0100, Kai Engert wrote: > I believe your point is, it doesn't matter which pysical connectivity > option a client uses to connect to the Internet - because the adversary > doesn't need to manipulate connections close to the victim, but rather > could enforce that MITM remains always active for a particular client. > > I agree, for state level attackers who can manipulate the Internet > backbone, this could block the ability of a victim to report a falsely > issued certificate to the real server. > > Question is, is the quantum server really sufficiently reliable enough > to be active at all times, no expections? For each victim, a onetime > glitch or downtime would be sufficient to get the false certificate > reported. Replying to myself, a few additional comments on that: If a powerful adversary used QUANTUM* to implement MITM widely, for many clients, using a falsely issued certificate, the adversary risks detection. For example, I have proposed the http://detector.io project, where I encourage all operators of TLS servers to monitor their own server for an unexpected certificate, by connecting from elsewhere, for example, by making use of the capabilities of the existing Tor network. The ideas presented in this particular mailing list thread focus on the idea that most MITM attacks wouldn't be executed broadly, because of the high risk of detecting the falsely issued certificate. Rather, I focus on targetted attacks, which involve only clients of a very small subset of the network. When targetting only a small subset of a network with MTIM, I think it's likely that eventually the client will be able to connect around that network, either caused by a roaming client, or by a temporary downtime of the MITM attack, which would be sufficient for reporting the false certificate as I'm proposing here. Kai From ekr@rtfm.com Mon Jan 13 08:09:58 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AFFC1ADFBC for ; Mon, 13 Jan 2014 08:09:58 -0800 (PST) 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, 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 hq0kEoOSpOD2 for ; Mon, 13 Jan 2014 08:09:57 -0800 (PST) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id 97EC71AC4A7 for ; Mon, 13 Jan 2014 08:09:56 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id hi5so1319309wib.12 for ; Mon, 13 Jan 2014 08:09:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=81Lyu32EPALd3BrrJasau32v1T3WRn7fvkMeu9O+ZhY=; b=nGmrppvNGTOL/67pdiATh/cfZqZegW0yX9hHjxKQTE6M2GBzSE+HSE1YZZMMzaHnQk PQfSOua8jUh2s58EDJLNC/N69b5BgNwhQl+cOIe8BBotfxcKXD3VgJaHaWd5npzy8/43 3lOl1bR0BJaSVqM8okc8nXqCI23FFB7LxGlnvUfQK/ki95WxZPXD5ycxHmPA9WAnfyxN Mbl3CPpoXoZryq3xaVoPCIzChjqs6Cv1Z5tm6Gz2PoNrrIZNEV7fxkEECxUsHez3RKm2 96m8cX3pxv1wxOaoGqVkC1+0kHfItiaNhUDrFmMa0YRu1Qn4jGekZ2VtAV2xnl7MxoOe Xdng== X-Gm-Message-State: ALoCoQn0/7Uvt+ORy3rQFXsnGZcdrrzxclSvrdRJb7D4LBgnb9X1pmmPB1jkpgQOINRZzlnxE02b X-Received: by 10.194.142.174 with SMTP id rx14mr22308886wjb.45.1389629385176; Mon, 13 Jan 2014 08:09:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.9.67 with HTTP; Mon, 13 Jan 2014 08:09:05 -0800 (PST) X-Originating-IP: [74.95.2.173] From: Eric Rescorla Date: Mon, 13 Jan 2014 08:09:05 -0800 Message-ID: To: "tls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [TLS] Conclusion of Fixing CBC Discussion X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Jan 2014 16:09:58 -0000 The comment period about drafts for fixing CBC has now expired. Based on the messages sent to the list, the chairs believe that the overall WG sentiment is to proceed with a document that: - Codifies encrypt-then-MAC - Uses an extension for negotiation Accordingly, we propose to have the WG adopt draft-gutmann with Peter Gutmann as editor, should he be willing to serve. The revised draft should also contain a section addressing the security question of fallback issues (with an informative reference to draft-moeller, likely to become a normative reference if that draft is adopted). If there are any objections to this plan, please raise them by Friday January 17. -Ekr [For the Chairs] P.S. The chairs note that there have been a number of other comments on draft-gutmann. Once the draft is adopted, we'll need to resolve those as well. From kaie@kuix.de Mon Jan 13 09:02:13 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 956A41ADF84 for ; Mon, 13 Jan 2014 09:02:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbFbt-1s1pWl for ; Mon, 13 Jan 2014 09:02:09 -0800 (PST) Received: from s15531995.onlinehome-server.info (s15531995.onlinehome-server.info [82.165.38.173]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1B91ADFD6 for ; Mon, 13 Jan 2014 09:02:07 -0800 (PST) Received: from [192.168.2.253] (p4FF35775.dip0.t-ipconnect.de [79.243.87.117]) by s15531995.onlinehome-server.info (Postfix) with ESMTPSA id EF94B42980E9 for ; Mon, 13 Jan 2014 18:01:55 +0100 (CET) Message-ID: <1389632514.16063.91.camel@lapkaie> From: Kai Engert To: tls@ietf.org Date: Mon, 13 Jan 2014 18:01:54 +0100 In-Reply-To: <52D07ED1.1020002@net.in.tum.de> References: <1389371947.30279.56.camel@lapkaie> <52D07ED1.1020002@net.in.tum.de> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.5 (3.8.5-2.fc19) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Ideas for TLS 1.3: Server key continuity and certificate reporting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Jan 2014 17:02:13 -0000 On Sa, 2014-01-11 at 00:14 +0100, Ralph Holz wrote: > I am not sure what "real" attacker you are adressing, During many informal chats, people have repeatedly told me, they have no trust in certificate authorities (CAs). I accept the fact that (as of today) we need trusted third parties to make Internet security for the masses of users simple. Nevertheless, I'm worried, too. The speculation that some CAs might be willing to issue false certificates for MITM purposes might be true. I would like us to implement technology that allows to confirm or to negate the speculation. There are three possibilities: Speculation (a) All CAs issueing certificates for the public Internet are trustworthy. None of them would ever sign a false certificate. If it happens, it was an accident, and such certificates get immediately revoked, and all private keys are immediately destroyed, to ensure that nobody could abuse the certificates with clients that don't do strict revocation checking. Speculation (b) All CAs issueing certificates for the public Internet might secretly issue false certificates for MITM purposes for one motivation or the other, for example if they are being compelled by the government or other powers related to their place of operation, or because of blackmail or corruption or undercover agents within their organization. Speculation (c) Neither (a) nor (b) is true. Rather most are trustworthy, but some might secretly issue false certificates. The certificate validation that is usually combined with TLS relies on the assumption that (a) is true. If everyone of you agreed that (b) were true, we could drop my reporting proposal, but we would also have to stop using TLS immediately, and design a system that enforces multiple assertions from different parties and technologies prior to trusting any TLS connection. My proposal is based on my opinion that (c) is the most realistic speculation. If we were able to identify all CAs that might issue false certificates, we would be able to remove them from all software that ships with a list of trusted CAs. My proposal to introduce a reporting mechanism for server certificates is intended to identify all CAs that aren't trustworthy. (My second proposal to introduce key continuity checks was a quick follow up idea, which could be dropped independently, if it turned out as not working as described.) > and if this static kind of pinning is really helpful. > > On (1): > > First, I have a suspicion that certificates may change relatively fast, > and CAs change too fast for pinning against the CA, too -- or at least > that is how I understood two colleagues of mine who investigated this. > > Second, on (1), reporting a cert: you assume a temporary attack, but how > is the client to find out if the attack is over? For the reporting part, the client wouldn't attempt to make a decision whether it's an attack or not. It simply reports the previously seen certificate to the server. > Is it supposed to > report the suspicious cert on every connection attempt until it > re-encounters the old cert? > But what if the change was legitimate? If current cert is different from previously seen valid cert, then report the previous cert to the server. Only if the current cert can be validated, forget the previously seen cert and update the local cache using the new valid cert. This means, with most servers, a report will usually be sent only in a few scenarios. However, if a cluster of servers uses multiple certificates at the same time, and the client randomly sees one of multiple certificates with each connection, change reports will be sent frequently. > Finally, what is the server operator expected to do with this > information, and how is it signalled to him? The server must have a list of all currently used certificates (local configuration, public part only). This is the list of known and expected certificates. All reports of certificates contained in the known list are automatically and silently ignored on the server side. If the server receives a report with a certificate that isn't contained in the know list, then the server attempts to perform a standard certificate validation (like client software would do). If the certificate appears valid, it's worthy to report it to the server operator. Only falsely issued certificates should pass the filtering. Signalling should be implemented by TLS server software in any way appropriate. Logfiles, local email, whatever the software wishes to support for reporting server software failures might work for this kind of alert, too. > A further thought comes to mind -- couldn't I spam the system by > reporting rogue certs to servers all the time? (This is a problem that > we also faced with Crossbear) A public facing TLS servers will require protection against DDoS attacks anyway. The need for having to validate a reported certificate as part of a client connection would increase the load for each attacking client connection slightly, but that's about it. If the reported certificate cannot be validated (because it was really just a DoS attempt, not a falsely issued certificate), the server can simply proceed with the regular countermeasure to block attacking client connections (e.g. standard rate limiting of connection attempts by IP address, etc.). > > (2) TLS clients should require key continuity. > > What you propose here is a kind of life-cycle management for pins. Are > you familiar with TACK by Trevor and Moxie? Their scheme does > essentially this and provides for key roll-over, both legitimate and due > to compromise. The core idea is not to pin against the TLS key, which is > subject to change, but to a domain key, much in the style of Sovereign > Keys. It also provides for roll-over of the domain key. I think your > ideas are pretty much covered by TACK. > > For the record, should the IETF make a move towards adopting TACK as > part of TLS, I'd be happy to see that. I think one of TACK's greatest > strengths is that it is immune even against a globally acting attacker > as long as that first contact was secure. I'll comment on this and TACK separately. Regards Kai From mrex@sap.com Mon Jan 13 10:37:34 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD461ADF99 for ; Mon, 13 Jan 2014 10:37:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.252 X-Spam-Level: X-Spam-Status: No, score=-6.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_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 fYSLtFeIvC-j for ; Mon, 13 Jan 2014 10:37:31 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4DFB91ADF93 for ; Mon, 13 Jan 2014 10:37:31 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s0DIbIox000158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 13 Jan 2014 19:37:19 +0100 (MET) In-Reply-To: <52C213F2.5040809@polarssl.org> To: =?UTF-8?Q?Manuel_P=C3=A9gouri=C3=A9-Gonnard?= Date: Mon, 13 Jan 2014 19:37:18 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" Message-Id: <20140113183718.D80471ABA0@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] SHA-2 in TLS 1.0 and 1.1 -- Was: Remarks on draft-popov-prohibiting-rc4-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 18:37:34 -0000 Manuel P=E9gouri=E9-Gonnard wrote: > > Watson Ladd wrote: >> >> Even if SHA-1 is utterly broken, this won't necessarily break HMAC >> based on it. More importantly, with the current TLS protocol, the MAC is encrypted, so even if SHA-1 was "broken" and HMAC-SHA1 was broken too, the MAC would still be encrypted and therefore still be more secure than AES-GCM ciphersuites. (The GHASH function that is used by AES-GCM does not have cryptographic properties to begin with). >>=20 >> I also don't like the idea of backporting: if we are going to be >> patching systems and forcing >> upgrades, why not to TLS 1.2 which doesn't have these issues? >=20 > Well, that was more or less my question: is using SHA-2 for HMAC with > TLS < 1.2 really backporting? I just checked RFC 2246 and 4346 and they > both state: >=20 > Additional hash algorithms can be defined by cipher suites and > used to protect record data, but MD5 and SHA-1 are hard coded into > the description of the handshaking for this version of the protocol. In spite of this wording in the document, changing the PRF in TLSv1.0 and TLSv1.1 to use a different hash is no more difficult that doing so in TLSv1.2, this has been in active use for several years, e.g. http://tools.ietf.org/html/draft-chudov-cryptopro-cptls-04 and it is so simple and straightforward, that it can even be done in Microsoft Windows XP's SChannel through third-party plugins, a TLS implementation that is TLSv1.0-only, doesn't support TLS extensions and not even AES-CBC cipher suites (rfc3268, jun 2002). >=20 > So, I'm really under the impression that there is nothing that prevents > anyone from defining a SHA-2 ciphersuite and using it with TLS < 1.2, > with the understanding that the PRF (hence the handshake authentication) > remains based on MD5 + SHA1. It would amount ot a complete waste of resources to use HMAC-SHA256 in current TLS cipher suites, HMAC-SHA1 is perfectly sufficient, at least when it is encrypted like it currently is. >=20 > However, a number of facts (akr's recent message, the restriction in RFC > 5932, the fact that neither OpenSSL nor GnuTLS accepts to negotiate any > SHA-2 suite with TLS < 1.2) seems to indicate otherwise, so I wanted to > check if I missed some good reason not to use SHA-2 suites with TLS < > 1.2. I was also surprised to see implementations fail interop for the _SHA256 ciphersuites from rfc5246 for TLSv1.1 and TLSv1.0 with no apparent reason. -Martin From mrex@sap.com Mon Jan 13 11:05:17 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5A81ADFD8 for ; Mon, 13 Jan 2014 11:05:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 Fbjs7hndjKUg for ; Mon, 13 Jan 2014 11:05:15 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9E33F1ADFB1 for ; Mon, 13 Jan 2014 11:05:15 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s0DJ53ck003457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 13 Jan 2014 20:05:03 +0100 (MET) In-Reply-To: To: Eric Rescorla Date: Mon, 13 Jan 2014 20:05:03 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" Message-Id: <20140113190503.CBD781ABA0@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "tls@ietf.org" Subject: Re: [TLS] SHA-2 in TLS 1.0 and 1.1 -- Was: Remarks on draft-popov-prohibiting-rc4-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 19:05:17 -0000 > wrote: >> >> On 30/12/2013 19:44, Alyssa Rowan wrote: >>> - TLS 1.1/1.0: ChaCha20_SHA { draft-mavrogiannopoulos-chacha20-tls } >>> =B7 Not loving having to use HMAC_SHA1 but TLS 1.0/1 is stuck with = it >> >> Are we really stuck with SHA1 (as opposed to SHA-256 or SHA-384) >> for HMAC on TLS 1.0 and 1.1? Encrypted HMAC-SHA1 is stronger than the integrity protection provided by AES-GCM. And certainly much stronger than SHA1 used in digital signatures. Eric Rescorla wrote: >=20 > With that said, my impression is that the use of SHA-1 in HMAC is > comparatively strong ... >=20 > With that in mind, how much extra security benefit do we get from replaci= ng > HMAC-SHA1 with HMAC-, as long as we still have SHA-1 for > certificates and signatures? And if we're considering only replacing > the MAC, it seems like it might make sense to go with a MAC that is not > hash based at all. NIST SP800-57 part1 says: equivalent symmetric strength for use of SHA1 in digital signatures is 80-bit, to-be-retired by the end of 2010 (we know how that went). equivalent symmetric strength for use of HMAC-SHA1 as MAC is 128-bit, good for use beyond 2030. And this applies to HMAC-SHA1 travelling in the clear, not the much stronger encrypted HMAC-SHA1 that TLS is currently using for GenericBlockCipher and GenericStreamCipher. The MAC that is used with AES-GCM (AES-encrypted GHASH) is substantially weaker than AES-encrypted HMAC-SHA1. For the specific case of TLS, this should not normally be a problem, however. For TLS-protected traffic, we desire the confidentiality to last for several years to come, even if someone captures and archives TLS-protected communication today in order to attack it at some point in the future. For the MAC that protects TLS traffic, we do not need as much of a security margin as for the encryption, because a successful attack only creates a problem when it happens in near real time, i.e. while the communication channel that uses the respective traffic protection keys is still established. After the TLS connection terminates, there are no more benefits from obtaining the MAC keys that were used on that connection. The average TLS connection is fairly short-lived (seconds, minutes, sometimes a few hours). But there may be consumers of TLS that keep a connection open for a much longer time, or use it to transfer huge amounts of data (xx gigabytes or more), and for those, the actualy safety margin of the MAC may become relevant, and whether that safety margin of the MAC goes down with the amount of data that is transfered -- IIRC the latter applies to AES-GCM. -Martin From ryan-ietftls@sleevi.com Mon Jan 13 11:06:52 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF821ADF48 for ; Mon, 13 Jan 2014 11:06:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_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 PA78KfKxlEfi for ; Mon, 13 Jan 2014 11:06:50 -0800 (PST) Received: from homiemail-a107.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 2DCD81ADF30 for ; Mon, 13 Jan 2014 11:06:50 -0800 (PST) Received: from homiemail-a107.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTP id 0DA782007F125; Mon, 13 Jan 2014 11:06:39 -0800 (PST) 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=AtUIaZnMLWHJMfnbIfUH7gsJikQ=; b=jhA9yPffo5UPcI8OU gN1f7x+jaavXcQhuqooRtcBA1iwKNaXUh/JjbypRiECMFi49+3jztn8ajoZbqy3t LEFEWKOHl2vQeZFqMS9KXADTpV7kx6ou/acE+dSxpVUtSxaIy0W9bd4O2JN9CbEo Uw/G54Upq6bDXuDr5ZwUpyBB7A= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTPA id 3E0862007F11C; Mon, 13 Jan 2014 11:06:37 -0800 (PST) Received: from 173.8.157.162 (proxying for 173.8.157.162) (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Mon, 13 Jan 2014 11:06:38 -0800 Message-ID: <38b58a333ac7c9fcce0669261c1f121c.squirrel@webmail.dreamhost.com> In-Reply-To: <1389632514.16063.91.camel@lapkaie> References: <1389371947.30279.56.camel@lapkaie> <52D07ED1.1020002@net.in.tum.de> <1389632514.16063.91.camel@lapkaie> Date: Mon, 13 Jan 2014 11:06:38 -0800 From: "Ryan Sleevi" To: "Kai Engert" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] Ideas for TLS 1.3: Server key continuity and certificate reporting 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: Mon, 13 Jan 2014 19:06:52 -0000 On Mon, January 13, 2014 9:01 am, Kai Engert wrote: > On Sa, 2014-01-11 at 00:14 +0100, Ralph Holz wrote: > > I am not sure what "real" attacker you are adressing, > > During many informal chats, people have repeatedly told me, they have = no > trust in certificate authorities (CAs). > > I accept the fact that (as of today) we need trusted third parties to > make Internet security for the masses of users simple. Nevertheless, I= 'm > worried, too. > > The speculation that some CAs might be willing to issue false > certificates for MITM purposes might be true. I would like us to > implement technology that allows to confirm or to negate the > speculation. > > There are three possibilities: > > Speculation (a) All CAs issueing certificates for the public Internet > are trustworthy. None of them would ever sign a false certificate. If = it > happens, it was an accident, and such certificates get immediately > revoked, and all private keys are immediately destroyed, to ensure tha= t > nobody could abuse the certificates with clients that don't do strict > revocation checking. > > Speculation (b) All CAs issueing certificates for the public Internet > might secretly issue false certificates for MITM purposes for one > motivation or the other, for example if they are being compelled by th= e > government or other powers related to their place of operation, or > because of blackmail or corruption or undercover agents within their > organization. > > Speculation (c) Neither (a) nor (b) is true. Rather most are > trustworthy, but some might secretly issue false certificates. > > > The certificate validation that is usually combined with TLS relies on > the assumption that (a) is true. > > If everyone of you agreed that (b) were true, we could drop my reporti= ng > proposal, but we would also have to stop using TLS immediately, and > design a system that enforces multiple assertions from different parti= es > and technologies prior to trusting any TLS connection. > > > My proposal is based on my opinion that (c) is the most realistic > speculation. > > If we were able to identify all CAs that might issue false certificate= s, > we would be able to remove them from all software that ships with a li= st > of trusted CAs. > > My proposal to introduce a reporting mechanism for server certificates > is intended to identify all CAs that aren't trustworthy. > > (My second proposal to introduce key continuity checks was a quick > follow up idea, which could be dropped independently, if it turned out > as not working as described.) If (c) is your goal, what, if any, advantages are there over RFC 6962? Al= l I can see are disadvantages. Incorporating into TLS 1.3: - Only provides herd immunity for clients that adopt TLS 1.3 CT protects all clients, past and present. - Effectively requires online checking capabilities for TLS servers (abou= t legitimacy of reports), otherwise simply logging reports can become a DoS vector. CT allows offline processing, by either the server operator acting as a log monitor, or - better yet, by outsourcing the work itself to a log monitor. - Requires adoption by server operators (in the hundreds of millions) CT only requires the adoption of user agents (in the tens to hundreds) an= d CAs - which, depending on your preferred counting metric (hi Phil!), ranges from ~1000 or fewer. The problem 9c) is one that CT is uniquely designed to address, so I don'= t see the need for protocol changes to support an alternative reporting mechanism, unless there can be demonstrated significant advantage. And I don't think "saves CA's $X dollars" to be a significant advantage, when i= t would require server operators spend "$(X*Y) dollars" to implement TLS 1.= 3 to kinda gain protection but only with clients and only if it's not a state actor. From pgut001@cs.auckland.ac.nz Thu Jan 16 04:19:40 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0DE61AE31A for ; Thu, 16 Jan 2014 04:19:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.539 X-Spam-Level: X-Spam-Status: No, score=-0.539 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cD5DLsuxSc9r for ; Thu, 16 Jan 2014 04:19:36 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 347E01AE1ED for ; Thu, 16 Jan 2014 04:19:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1389874765; x=1421410765; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=/cXbGR+yQbI7jHxcj6L7LwKUNh/U//R9WYPUQZ/nis0=; b=Gfy8ktPRJoUvwurL9iwtskRHxWnECHQq8E08X797NKXxauV5eAvAm/yu 03mvBUc8QWVr3+ivgVKiHOynBRFLplhVQhomHaaadMI3qWhn+FRmJBjy9 yMBbCMoMbv5nxh4pVYJiGOw+SYRDV2+Scfe5SuS2ZwIkPP5weaB9G92G0 A=; X-IronPort-AV: E=Sophos;i="4.95,667,1384254000"; d="scan'208";a="229756537" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 17 Jan 2014 01:19:23 +1300 Received: from UXCN10-TDC06.UoA.auckland.ac.nz ([169.254.11.205]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0158.001; Fri, 17 Jan 2014 01:19:23 +1300 From: Peter Gutmann To: "tls@ietf.org" Thread-Topic: [TLS] Conclusion of Fixing CBC Discussion Thread-Index: Ac8StTAtJRYd7xLMSZyMAekR6j6bIg== Date: Thu, 16 Jan 2014 12:19:22 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C7372359B6A@uxcn10-tdc06.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 Subject: Re: [TLS] Conclusion of Fixing CBC Discussion X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Jan 2014 12:19:40 -0000 Eric Rescorla writes:=0A= =0A= >Accordingly, we propose to have the WG adopt draft-gutmann with Peter Gutm= ann=0A= >as editor, should he be willing to serve.=0A= =0A= Sure, no problem.=0A= =0A= Peter.=0A= From internet-drafts@ietf.org Mon Jan 20 13:34:16 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE55E1A0233; Mon, 20 Jan 2014 13:34:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jk-8E_ppJrC5; Mon, 20 Jan 2014 13:34:15 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DA7C91A0254; Mon, 20 Jan 2014 13:34:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140120213412.15811.42221.idtracker@ietfa.amsl.com> Date: Mon, 20 Jan 2014 13:34:12 -0800 Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-oob-pubkey-11.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, 20 Jan 2014 21:34:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Layer Security Working Group of= the IETF. Title : Using Raw Public Keys in Transport Layer Security= (TLS) and Datagram Transport Layer Security (DTLS) Authors : Paul Wouters Hannes Tschofenig John Gilmore Samuel Weiler Tero Kivinen Filename : draft-ietf-tls-oob-pubkey-11.txt Pages : 17 Date : 2014-01-20 Abstract: This document specifies a new certificate type and two TLS extensions for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). The new certificate type allows raw public keys to be used for authentication. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-oob-pubkey/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-oob-pubkey-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-oob-pubkey-11 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 simon@josefsson.org Wed Jan 22 08:19:00 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 493B71A0483 for ; Wed, 22 Jan 2014 08:19:00 -0800 (PST) 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 tTGx7l1kvu9r for ; Wed, 22 Jan 2014 08:18:58 -0800 (PST) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) by ietfa.amsl.com (Postfix) with ESMTP id 45EAF1A0429 for ; Wed, 22 Jan 2014 08:18:58 -0800 (PST) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id s0MGIsc9017100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 22 Jan 2014 17:18:56 +0100 X-Hashcash: 1:22:140122:tls@ietf.org::cxSBv7HYrkPIEC65:GcxW From: Simon Josefsson To: tls@ietf.org OpenPGP: id=B565716F; url=http://josefsson.org/key.txt Date: Wed, 22 Jan 2014 17:18:54 +0100 Message-ID: <87ob3456s1.fsf@latte.josefsson.org> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.8 at duva.sjd.se X-Virus-Status: Clean Subject: [TLS] Curve25519 in TLS and Additional Curves 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, 22 Jan 2014 16:19:00 -0000 All, I have updated the Curve25519 draft. I believe people are implementing Curve25519 for TLS. My idea of adding the "additional" curves to the same draft seems like a mistake, or at least the timing of doing it was a mistake. Merging all curves into one draft makes it harder to evaluate consensus and maturity around the Curve25519 part, which I hope/believe we are approching. Thus, I have split the draft into two drafts: 1) Curve25519 for TLS. This was the original scope of the draft. The URL is: . As far as I know, there are no outstanding issues, and it is possible to implement and deploy Curve25519 in TLS following the draft. Please prove me wrong with comments or preferrably patches to the draft. 2) Additional curves for TLS. This reflect the idea I had recently after reading draft-ladd-safecurves. However it seems there is still many things to discuss and that it is not near the maturity of the curve25519 part. The following draft is also pending on the CFRG discussions and maturity of draft-ladd-safecurves. . Several people suggested to remove some curves from the list, and I'm inclined to agree, but haven't made the change yet. I'm not sure we have a solid understanding of which curves makes sense and which doesn't yet. Eventually the drafts may be merged, if/when closure is reached on the open issues for the second draft. But I don't have high hopes that will happen in the near term, and I believe there is growing interest in moving forward with the first draft. The drafts are on gitorious, if anyone prefers to send patches that way, see: https://www.gitorious.org/ietf-simon/tls-curve25519/ Cheers, /Simon From rob.stradling@comodo.com Wed Jan 22 10:07:32 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC661A02F1 for ; Wed, 22 Jan 2014 10:07:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.11 X-Spam-Level: X-Spam-Status: No, score=0.11 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_MISMATCH_NET=0.611, 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_9Kch4on-qb for ; Wed, 22 Jan 2014 10:07:29 -0800 (PST) Received: from ian.brad.office.comodo.net (eth5.brad-fw.brad.office.ccanet.co.uk [178.255.87.226]) by ietfa.amsl.com (Postfix) with ESMTP id 149431A035A for ; Wed, 22 Jan 2014 10:07:28 -0800 (PST) Received: (qmail 12966 invoked by uid 1000); 22 Jan 2014 18:07:26 -0000 Received: from nigel.brad.office.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 (CAMELLIA256-SHA encrypted) ESMTPSA; Wed, 22 Jan 2014 18:07:26 +0000 Message-ID: <52E008DD.9050002@comodo.com> Date: Wed, 22 Jan 2014 18:07:25 +0000 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Simon Josefsson , tls@ietf.org References: <87ob3456s1.fsf@latte.josefsson.org> In-Reply-To: <87ob3456s1.fsf@latte.josefsson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Curve25519 in TLS and Additional Curves 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, 22 Jan 2014 18:07:32 -0000 On 22/01/14 16:18, Simon Josefsson wrote: > 1) Curve25519 for TLS. This was the original scope of the draft. The > URL is: . As > far as I know, there are no outstanding issues, and it is possible to > implement and deploy Curve25519 in TLS following the draft. Please > prove me wrong with comments or preferrably patches to the draft. Simon, Section 2.1 says: "Since Curve25519 are not designed to be used in signatures, clients who offer ECDHE_ECDSA ciphersuites and advertise support for Curve25519 in the elliptic_curves ClientHello extension SHOULD also advertise support for at least one other curve, suitable for ECDSA. Servers MUST NOT select an ECDHE_ECDSA ciphersuite if the only common curve is Curve25519." Why is that "SHOULD" not a MUST? -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From rransom.8774@gmail.com Wed Jan 22 13:16:23 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64D0B1A048F for ; Wed, 22 Jan 2014 13:16:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 IaxAHy98qZby for ; Wed, 22 Jan 2014 13:16:21 -0800 (PST) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3421A0480 for ; Wed, 22 Jan 2014 13:16:21 -0800 (PST) Received: by mail-qa0-f45.google.com with SMTP id ii20so1143766qab.4 for ; Wed, 22 Jan 2014 13:16:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=bI5QAK64rBHwR6qm+RI4RW0LaXQhCcOUPT1aJmzf14s=; b=ZGV7aurnDVmL5YkcDiQuGZjQROmHW13oGAhdMtCg1JKt9rsxVh7NePHkkMUaZuQ+3x 7xgqpx+XbPFVOnqfsfJILabSXdIS3tTYxTbBlMXg2kXsmz0q65Tb9inDpGCpiuW9rBOA Juqn1l71SGHu+kPJBNdwwLepXNtPpj5vm9dLUwrgPoIPsX2hXyA6Yapq+sfTi6ymKB8m 4iOR7ksG5eqhtOnDN+8mJ9E8thKXTvlCO8NX3DObdiB2T/PwZ4Lo4hEH8VGB8sZ2if2L vQArLCPobcNZObH5Bsw07kiEFiDnwQUQP44OWDg/dBeDyrwDyXTNfOPPUdXtkwdX4+jv oN1Q== MIME-Version: 1.0 X-Received: by 10.140.51.170 with SMTP id u39mr5781391qga.69.1390425380737; Wed, 22 Jan 2014 13:16:20 -0800 (PST) Received: by 10.229.181.132 with HTTP; Wed, 22 Jan 2014 13:16:20 -0800 (PST) In-Reply-To: <87ob3456s1.fsf@latte.josefsson.org> References: <87ob3456s1.fsf@latte.josefsson.org> Date: Wed, 22 Jan 2014 13:16:20 -0800 Message-ID: From: Robert Ransom To: Simon Josefsson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] Curve25519 in TLS and Additional Curves 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, 22 Jan 2014 21:16:23 -0000 On 1/22/14, Simon Josefsson wrote: > All, > > I have updated the Curve25519 draft. I believe people are implementing > Curve25519 for TLS. My idea of adding the "additional" curves to the > same draft seems like a mistake, or at least the timing of doing it was > a mistake. Merging all curves into one draft makes it harder to > evaluate consensus and maturity around the Curve25519 part, which I > hope/believe we are approching. Thus, I have split the draft into two > drafts: > > 1) Curve25519 for TLS. This was the original scope of the draft. The > URL is: . As > far as I know, there are no outstanding issues, and it is possible to > implement and deploy Curve25519 in TLS following the draft. Please > prove me wrong with comments or preferrably patches to the draft. * The draft still specifies a big-endian point format. What is the technical benefit of requiring every TLS implementation which uses one of the existing efficient, secure implementations of Curve25519 Montgomery-form scalar multiplication to reverse the byte order of its input and output? (Note that people want to use Curve25519 in TLS because of those existing implementations, so deliberately breaking compatibility with them seems especially unwise.) * The draft should specify that implementations MUST discard (i.e. set to zero) the most significant bit of a received public key, for two reasons: (a) Existing Curve25519 scalarmult implementations differ in their handling of inputs with that bit set, and could be distinguished by an active attacker using that difference. (b) Future specifications may wish to include the sign bit of an Edwards-form x coordinate in a Curve25519 point format for use with other protocols (e.g. Schnorr signature, Ace) without breaking backwards compatibility with use in ECDH. * The draft does not specify the curve equation of Curve25519 or the basepoint for use in ECDH. * The =E2=80=98Security Considerations=E2=80=99 section suggests that Curve= 25519 can be implemented securely using bignum libraries which leak information about the numbers they operate on to a side-channel attacker, as long as the internal projective representation of each point is randomized. Has this proposed side-channel countermeasure been evaluated? If so, which types of information leakage does the countermeasure render harmless? * The draft claims that every curve listed in RFC 4492 whose name ends in =E2=80=9Ck1=E2=80=9D is defined over a binary (characteristic 2) field. = This is false: RFC4492 defines several GLV curves over prime fields (e.g. =E2=80=98secp256k1=E2=80=99), and their names also end in =E2=80=9Ck1=E2=80= =9D. Robert Ransom From rsalz@akamai.com Wed Jan 22 13:55:05 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9171A012E for ; Wed, 22 Jan 2014 13:55:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vx8dwxSVU5xG for ; Wed, 22 Jan 2014 13:55:04 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 43CBB1A04B1 for ; Wed, 22 Jan 2014 13:55:00 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 9A3F71655DE; Wed, 22 Jan 2014 21:54:59 +0000 (GMT) Received: from prod-mail-relay03.akamai.com (prod-mail-relay03.akamai.com [172.27.8.26]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 8EB6A1655DB; Wed, 22 Jan 2014 21:54:59 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub5.kendall.corp.akamai.com [172.27.105.21]) by prod-mail-relay03.akamai.com (Postfix) with ESMTP id 710622FD73; Wed, 22 Jan 2014 21:54:59 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.77]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Wed, 22 Jan 2014 16:54:59 -0500 From: "Salz, Rich" To: Robert Ransom , Simon Josefsson Date: Wed, 22 Jan 2014 16:54:57 -0500 Thread-Topic: [TLS] Curve25519 in TLS and Additional Curves in TLS Thread-Index: Ac8XtzfIE685kAjATAW6cMTYhu5AfAABTp6w Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711E95FFF6D@USMBX1.msg.corp.akamai.com> References: <87ob3456s1.fsf@latte.josefsson.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] Curve25519 in TLS and Additional Curves 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, 22 Jan 2014 21:55:05 -0000 PiAqIFRoZSBkcmFmdCBzdGlsbCBzcGVjaWZpZXMgYSBiaWctZW5kaWFuIHBvaW50IGZvcm1hdA0K DQpZZXMsIHRoaXMgaXMgYSBzZXJpb3VzIGZsYXcsIGFyZ3VhYmx5IHJlYXNvbiBlbm91Z2ggdG8g InZvdGUgbm8iDQoNCi0tICANClByaW5jaXBhbCBTZWN1cml0eSBFbmdpbmVlcg0KQWthbWFpIFRl Y2hub2xvZ3kNCkNhbWJyaWRnZSwgTUENCg== From mpg@polarssl.org Wed Jan 22 15:45:02 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 209B81A03C4 for ; Wed, 22 Jan 2014 15:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.893 X-Spam-Level: ** X-Spam-Status: No, score=2.893 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.793] 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 2PdoESjPWQd3 for ; Wed, 22 Jan 2014 15:45:00 -0800 (PST) Received: from mordell.elzevir.fr (unknown [IPv6:2001:4b98:dc0:41:216:3eff:feeb:c406]) by ietfa.amsl.com (Postfix) with ESMTP id 94B1C1A00C8 for ; Wed, 22 Jan 2014 15:45:00 -0800 (PST) Received: from thue.elzevir.fr (thue.elzevir.fr [88.165.216.11]) by mordell.elzevir.fr (Postfix) with ESMTPS id 65DA316431 for ; Thu, 23 Jan 2014 00:44:59 +0100 (CET) Received: from [192.168.0.124] (unknown [192.168.0.254]) by thue.elzevir.fr (Postfix) with ESMTPSA id 724282986C for ; Thu, 23 Jan 2014 00:44:58 +0100 (CET) Message-ID: <52E057F8.8040906@polarssl.org> Date: Thu, 23 Jan 2014 00:44:56 +0100 From: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.1.1 MIME-Version: 1.0 To: tls@ietf.org References: <87ob3456s1.fsf@latte.josefsson.org> <52E008DD.9050002@comodo.com> In-Reply-To: <52E008DD.9050002@comodo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Curve25519 in TLS and Additional Curves 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, 22 Jan 2014 23:45:02 -0000 On 22/01/2014 19:07, Rob Stradling wrote: > Simon, Section 2.1 says: > "Since Curve25519 are not designed to be used in signatures, clients > who offer ECDHE_ECDSA ciphersuites and advertise support for > Curve25519 in the elliptic_curves ClientHello extension SHOULD also > advertise support for at least one other curve, suitable for ECDSA. > Servers MUST NOT select an ECDHE_ECDSA ciphersuite if the only common > curve is Curve25519." > > Why is that "SHOULD" not a MUST? > The idea is that, if a client offers ECDHE_ECDSA ciphersuites but no ECDSA-capable curve, the handshake can still be completed if non-ECDSA ciphersuites are offered too: the server will select one of these suites. In this case, offering ECDHE_ECDSA suite is just a waste of bytes, but does not harm interoperability. Making it a SHOULD may simplify client-side implementations in which the user can select the list of supported curves and ciphersuites, by allowing the implementation not to filter the list of ciphersuites based on the selected curves. Manuel. From mpg@polarssl.org Wed Jan 22 16:22:46 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E41181A01D6 for ; Wed, 22 Jan 2014 16:22:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.994 X-Spam-Level: X-Spam-Status: No, score=0.994 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.793] 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 kgmqfEICDmFj for ; Wed, 22 Jan 2014 16:22:46 -0800 (PST) Received: from mordell.elzevir.fr (unknown [IPv6:2001:4b98:dc0:41:216:3eff:feeb:c406]) by ietfa.amsl.com (Postfix) with ESMTP id DE3861A01A5 for ; Wed, 22 Jan 2014 16:22:45 -0800 (PST) Received: from thue.elzevir.fr (thue.elzevir.fr [88.165.216.11]) by mordell.elzevir.fr (Postfix) with ESMTPS id 93E6A16431 for ; Thu, 23 Jan 2014 01:22:44 +0100 (CET) Received: from [192.168.0.124] (unknown [192.168.0.254]) by thue.elzevir.fr (Postfix) with ESMTPSA id 8F2CE2986C for ; Thu, 23 Jan 2014 01:22:42 +0100 (CET) Message-ID: <52E060D0.9030801@polarssl.org> Date: Thu, 23 Jan 2014 01:22:40 +0100 From: =?UTF-8?B?TWFudWVsIFDDqWdvdXJpw6ktR29ubmFyZA==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.1.1 MIME-Version: 1.0 To: tls@ietf.org References: <87ob3456s1.fsf@latte.josefsson.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [TLS] Curve25519 in TLS and Additional Curves 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, 23 Jan 2014 00:22:47 -0000 On 22/01/2014 22:16, Robert Ransom wrote: > * The draft still specifies a big-endian point format. What is the > technical benefit of requiring every TLS implementation which uses one > of the existing efficient, secure implementations of Curve25519 > Montgomery-form scalar multiplication to reverse the byte order of its > input and output? (Note that people want to use Curve25519 in TLS > because of those existing implementations, so deliberately breaking > compatibility with them seems especially unwise.) > I have no objection to changing the byte ordering if nobody speaks up for big-endian in the next few days. > * The draft should specify that implementations MUST discard (i.e. set > to zero) the most significant bit of a received public key, for two > reasons: (a) Existing Curve25519 scalarmult implementations differ in > their handling of inputs with that bit set, and could be distinguished > by an active attacker using that difference. I wasn't aware that some implementations ignored the most significant bit. Out of curiosity, could you cite examples? One of the "selling points" of Curve25519 is that no public key validation is needed, so I find it quite unfortunate that after all there is something to do when receiving public keys. > (b) Future specifications > may wish to include the sign bit of an Edwards-form x coordinate in a > Curve25519 point format for use with other protocols (e.g. Schnorr > signature, Ace) without breaking backwards compatibility with use in > ECDH. > This is a serious concern indeed. By the way, there was another issue under discussion that is related: should the point format be just the 32 bytes, or should we use a leading byte to follow the existing practice from X9.62, as Salz Rich suggested? If we use a leading byte, maybe it's better to have two formats, one for "x coordinate only", one for "y + bit sign of x"? > * The draft does not specify the curve equation of Curve25519 or the > basepoint for use in ECDH. > Of course it's no problem to add it. Do you think we should explain the arithmetic too (Montgomery ladder + differential addition formulas)? > * The â€Security Considerations’ section suggests that Curve25519 can > be implemented securely using bignum libraries which leak information > about the numbers they operate on to a side-channel attacker, as long > as the internal projective representation of each point is randomized. > Has this proposed side-channel countermeasure been evaluated? If so, > which types of information leakage does the countermeasure render > harmless? > I'm not aware of any specific analysis of this countermeasure for this type of curves. > * The draft claims that every curve listed in RFC 4492 whose name ends > in “k1” is defined over a binary (characteristic 2) field. This is > false: RFC4492 defines several GLV curves over prime fields (e.g. > â€secp256k1’), and their names also end in “k1”. > Right, this should have been corrected already. Manuel. From rransom.8774@gmail.com Wed Jan 22 17:17:40 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8DE1A01D5 for ; Wed, 22 Jan 2014 17:17:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.45 X-Spam-Level: X-Spam-Status: No, score=-1.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHmRKP8pmbpK for ; Wed, 22 Jan 2014 17:17:39 -0800 (PST) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id BFAA71A01B1 for ; Wed, 22 Jan 2014 17:17:38 -0800 (PST) Received: by mail-qa0-f48.google.com with SMTP id f11so1445079qae.21 for ; Wed, 22 Jan 2014 17:17:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=c7rnSYsS4yVkvUmK6AUfzS4tFBG0/4RSDdo8GLZX+xY=; b=tRP616G2VF+8pJTtZnaoNsMfykAmOdT9aKttYGQndssohVNhhYb/ORbbeXyWCzv06c ppYyojIV8wtKNwaisba4wRhorMQpxe5hVvd32G3i0dG1jrtCD74TpIPr+5KTOuwH3BBN yQvmGXXcgq4fGRjVb0xEnUCv5QgATs8mqKP8wCbMEI20FTOgkUPsOyNyzd82dNJxdBDU 5MUX0Cwl/vWTAfPLdjfmbY4UhzVJemH2ey5jLMu2FrYbSY0SJaHm8yZCvUfMOQ2nlsG9 QSvy/yc802WiaYnwRYtA/mMWRj+DW/6LRV2cqs+Z8PzcvhR4MO1xKB7Mi3ycQRnxsaRw XzUQ== MIME-Version: 1.0 X-Received: by 10.224.111.195 with SMTP id t3mr7597448qap.2.1390439857981; Wed, 22 Jan 2014 17:17:37 -0800 (PST) Received: by 10.229.181.132 with HTTP; Wed, 22 Jan 2014 17:17:37 -0800 (PST) In-Reply-To: <52E060D0.9030801@polarssl.org> References: <87ob3456s1.fsf@latte.josefsson.org> <52E060D0.9030801@polarssl.org> Date: Wed, 22 Jan 2014 17:17:37 -0800 Message-ID: From: Robert Ransom To: =?UTF-8?Q?Manuel_P=C3=A9gouri=C3=A9=2DGonnard?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] Curve25519 in TLS and Additional Curves 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, 23 Jan 2014 01:17:40 -0000 On 1/22/14, Manuel P=C3=A9gouri=C3=A9-Gonnard wrote: > On 22/01/2014 22:16, Robert Ransom wrote: >> * The draft should specify that implementations MUST discard (i.e. set >> to zero) the most significant bit of a received public key, for two >> reasons: (a) Existing Curve25519 scalarmult implementations differ in >> their handling of inputs with that bit set, and could be distinguished >> by an active attacker using that difference. > > I wasn't aware that some implementations ignored the most significant bit= . > Out > of curiosity, could you cite examples? curve25519-donna and -donna-c64 ignore the MSB. Nick Mathewson (Tor lead developer) tested whether Dr. Bernstein's floating-point implementation for IA-32 in NaCl ignores the MSB; he reported that it does. The =E2=80=98ref=E2=80=99 implementation in NaCl does not ignore the MSB. I have no idea what Dr. Bernstein's original floating-point Curve25519 implementation for IA-32 does with the MSB, but the web page documenting it hints that it treats the MSB as part of the x coordinate. > One of the "selling points" of Curve25519 is that no public key validatio= n > is > needed, so I find it quite unfortunate that after all there is something = to > do > when receiving public keys. Fingerprinting of implementations wasn't one of the security concerns that Dr. Bernstein had in mind at the time, and it still isn't widely considered to be a security risk. It's certainly minor compared to the numerous ways that NSA-curve ECDH implementations can leak their keys. But the bigger reason to mask off the high bit is extensibility. >> (b) Future specifications >> may wish to include the sign bit of an Edwards-form x coordinate in a >> Curve25519 point format for use with other protocols (e.g. Schnorr >> signature, Ace) without breaking backwards compatibility with use in >> ECDH. >> > This is a serious concern indeed. By the way, there was another issue und= er > discussion that is related: should the point format be just the 32 bytes,= or > should we use a leading byte to follow the existing practice from X9.62, = as > Salz > Rich suggested? If we use a leading byte, maybe it's better to have two > formats, > one for "x coordinate only", one for "y + bit sign of x"? * You appear to be confusing Montgomery form with Edwards form. The Curve25519 paper specifies =E2=80=98Montgomery-form x coordinate only=E2=80= =99; the other format you are suggesting seems to be =E2=80=98Edwards-form y coordin= ate with sign bit of Edwards-form x coordinate=E2=80=99. (Remember that the Edwards-form y coordinate is analogous to the Montgomery-form x coordinate.) * There is no reason to ever transmit an Edwards-form y coordinate for use in ECDH. The formats that would be useful here are =E2=80=98Montgomery-form x coordinate only=E2=80=99 and =E2=80=98Montgomery= -form x coordinate with sign bit of Edwards-form x coordinate=E2=80=99. * If you do not add a leading point-format byte, there is no reason to specify the meaning of the high bit in this document. If you do add a leading byte, you will have to choose in this document whether the sign bit is for the Edwards-form x coordinate or the Montgomery-form y coordinate. * Some future applications may wish to transmit an uncompressed Edwards-form x coordinate or Montgomery-form y coordinate, not just the sign bit. If you add a leading byte, you'll have to choose which coordinate to use now. Alternatively, you could specify that implementations of this document accept 64-byte points and ignore the second half of the point structure. (Note that this means implementations of this protocol MUST ignore the second half, even if they know how to use it in some other protocol, or they will be distinguishable from other ECDH implementations. I don't think that restriction will ever be a problem for ECDH implementations.) * Some future (non-ECDH) applications may wish to transmit an Edwards-form y coordinate instead of a Montgomery-form x coordinate (e.g. so that they can distinguish the point of order 2 from the identity). If you do not add a leading point-format byte now, those applications will have to use a different NamedCurve in order to indicate that they are incompatible with the point formats used for ECDH. (I'm not sure that this is a problem, or that any such applications will ever exist.) I'm currently leaning towards =E2=80=98just reserve the high bit and tell implementations to accept and ignore the second half of a 64-byte point structure=E2=80=99, but there may be good enough arguments for using = a magic byte to justify the minor downsides. >> * The draft does not specify the curve equation of Curve25519 or the >> basepoint for use in ECDH. >> > Of course it's no problem to add it. Do you think we should explain the > arithmetic too (Montgomery ladder + differential addition formulas)? Only if you will do it well. >> * The =E2=80=98Security Considerations=E2=80=99 section suggests that Cu= rve25519 can >> be implemented securely using bignum libraries which leak information >> about the numbers they operate on to a side-channel attacker, as long >> as the internal projective representation of each point is randomized. >> Has this proposed side-channel countermeasure been evaluated? If so, >> which types of information leakage does the countermeasure render >> harmless? >> > I'm not aware of any specific analysis of this countermeasure for this ty= pe > of > curves. Then either (a) don't recommend that countermeasure as an alternative to using constant-time field operations, or (b) explicitly warn that there is no evidence that that countermeasure will be sufficient to protect against side-channel attacks. Robert Ransom From watsonbladd@gmail.com Wed Jan 22 22:42:39 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04A711A025F for ; Wed, 22 Jan 2014 22:42:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqT1PLQYY9St for ; Wed, 22 Jan 2014 22:42:37 -0800 (PST) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 0F33E1A022C for ; Wed, 22 Jan 2014 22:42:36 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id e4so276641wiv.4 for ; Wed, 22 Jan 2014 22:42:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZqEvph/i+IhLYhM01h/yEi05NCaKVpIHAAQYv2hmO9k=; b=xCRrTgEZksspY//NFvLcglua0HSRHamAVWgWnRsb6O0rDorFKlDtVY70e9kNFoVsVx gbeejwfsqlCiImrbr6iT/+eNgR50fo7H+fdqf7bSCRuTdbr6yYJQJtL3U81IWTjGxSwB GtDQ09miFCTc0uqZRoqZCyMzkIAvBret0PU9bf0Zi85148wI5XRUxf0vWnpqC5jkRpoT X2I8jqSBx4bHXiuUMhq5oACkp1I736ltetQrmR84Gpn20jIvqdK5kMXZNAjVCkemI2KZ pRpIfjDMxH+Y60SUC4q8lYBQAPlAuIWJ6uszXjPOLPF7jvo7LoG4TUaD++yZOHd6u/Ii l60A== MIME-Version: 1.0 X-Received: by 10.180.149.175 with SMTP id ub15mr23242264wib.44.1390459355756; Wed, 22 Jan 2014 22:42:35 -0800 (PST) Received: by 10.194.250.101 with HTTP; Wed, 22 Jan 2014 22:42:35 -0800 (PST) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711E95FFF6D@USMBX1.msg.corp.akamai.com> References: <87ob3456s1.fsf@latte.josefsson.org> <2A0EFB9C05D0164E98F19BB0AF3708C711E95FFF6D@USMBX1.msg.corp.akamai.com> Date: Wed, 22 Jan 2014 22:42:35 -0800 Message-ID: From: Watson Ladd To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" , Simon Josefsson Subject: Re: [TLS] Curve25519 in TLS and Additional Curves 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, 23 Jan 2014 06:42:39 -0000 On Wed, Jan 22, 2014 at 1:54 PM, Salz, Rich wrote: >> * The draft still specifies a big-endian point format > > Yes, this is a serious flaw, arguably reason enough to "vote no" Endinanness is never a good reason to vote no. Please read http://www.ietf.org/rfc/ien/ien137.txt if you do not believe this. What you are complaining about takes three lines of C to fix. Let's not reignite a holy war that the IETF settled long ago. Sincerely, Watson Ladd > > -- > Principal Security Engineer > Akamai Technology > Cambridge, MA > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nmav@redhat.com Thu Jan 23 00:39:39 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 962791A02A4 for ; Thu, 23 Jan 2014 00:39:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.437 X-Spam-Level: X-Spam-Status: No, score=-7.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, 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 RlKcYqjJMwnU for ; Thu, 23 Jan 2014 00:39:38 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 476E81A0282 for ; Thu, 23 Jan 2014 00:39:38 -0800 (PST) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s0N8daVZ010205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 23 Jan 2014 03:39:36 -0500 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s0N8dYKR020461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Jan 2014 03:39:35 -0500 Message-ID: <1390466373.20176.8.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Robert Ransom Date: Thu, 23 Jan 2014 09:39:33 +0100 In-Reply-To: References: <87ob3456s1.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.24 Cc: Simon Josefsson , tls@ietf.org Subject: Re: [TLS] Curve25519 in TLS and Additional Curves 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, 23 Jan 2014 08:39:39 -0000 On Wed, 2014-01-22 at 13:16 -0800, Robert Ransom wrote: > * The draft still specifies a big-endian point format. What is the > technical benefit of requiring every TLS implementation which uses one > of the existing efficient, secure implementations of Curve25519 > Montgomery-form scalar multiplication to reverse the byte order of its > input and output? (Note that people want to use Curve25519 in TLS > because of those existing implementations, so deliberately breaking > compatibility with them seems especially unwise.) An Internet protocol is not typically designed based on the existing implementations limitations and they it is often expected to outlive them. Almost all IETF protocols use the big-endian format for transferring integers, and implementations of these protocols in have already ways to convert these numbers to the native endianess. regards, Nikos From mpg@polarssl.org Thu Jan 23 01:35:05 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ECAF1A037A for ; Thu, 23 Jan 2014 01:35:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.394 X-Spam-Level: X-Spam-Status: No, score=0.394 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRJvhzISSiOk for ; Thu, 23 Jan 2014 01:35:03 -0800 (PST) Received: from vps2.brainspark.nl (vps2.brainspark.nl [141.138.204.106]) by ietfa.amsl.com (Postfix) with ESMTP id 4C68A1A0376 for ; Thu, 23 Jan 2014 01:35:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=lwmqmvy+Hw8urGSv5RDeLLtNejoBTPw0nXALkez9ijA=; b=ERH5z/m3eey+Y2X14SQ9M0KmJGKhVCFiGkXqhvl76S6xxvYlOJeXmcU3wNkyV8zcf0F5Sys//0ztJuEjG/cEIVUsq2uR5NtGPVLgMsiqVZ8xkLhlKIFOSn2YVQ4DAewEY6fW/C7Z5qvGWnqSo7dKdg3IsiEOLNDMiGQXALKNyIY=; Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.brainspark.nl with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1W6GZk-0001Bb-DD for tls@ietf.org; Thu, 23 Jan 2014 10:27:53 +0100 Message-ID: <52E0E241.40406@polarssl.org> Date: Thu, 23 Jan 2014 10:34:57 +0100 From: =?UTF-8?B?TWFudWVsIFDDqWdvdXJpw6ktR29ubmFyZA==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.1.1 MIME-Version: 1.0 To: tls@ietf.org References: <87ob3456s1.fsf@latte.josefsson.org> <52E060D0.9030801@polarssl.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 88.165.216.11 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.brainspark.nl) Subject: Re: [TLS] Curve25519 in TLS and Additional Curves 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, 23 Jan 2014 09:35:06 -0000 On 23/01/2014 02:17, Robert Ransom wrote: > On 1/22/14, Manuel PĂ©gouriĂ©-Gonnard wrote: >> On 22/01/2014 22:16, Robert Ransom wrote: > >>> * The draft should specify that implementations MUST discard (i.e. set >>> to zero) the most significant bit of a received public key, for two >>> reasons: (a) Existing Curve25519 scalarmult implementations differ in >>> their handling of inputs with that bit set, and could be distinguished >>> by an active attacker using that difference. >> >> I wasn't aware that some implementations ignored the most significant bit. >> Out >> of curiosity, could you cite examples? > > curve25519-donna and -donna-c64 ignore the MSB. > [...] > The â€ref’ implementation in NaCl does not ignore the MSB. > [...] Ok, thanks for the information. > Fingerprinting of implementations wasn't one of the security concerns > that Dr. Bernstein had in mind at the time, and it still isn't widely > considered to be a security risk. It's certainly minor compared to > the numerous ways that NSA-curve ECDH implementations can leak their > keys. > > But the bigger reason to mask off the high bit is extensibility. > I fully agree it's the bigger reason. As discussed below, there is probably some other ways to achieve extensibility, so if extensibility wasn't a concern, would you think that avoiding implementation fingerprinting is more valuable than being able to accept any string as a public key without no validation or masking? >>> (b) Future specifications >>> may wish to include the sign bit of an Edwards-form x coordinate in a >>> Curve25519 point format for use with other protocols (e.g. Schnorr >>> signature, Ace) without breaking backwards compatibility with use in >>> ECDH. >>> >> This is a serious concern indeed. By the way, there was another issue under >> discussion that is related: should the point format be just the 32 bytes, or >> should we use a leading byte to follow the existing practice from X9.62, as >> Salz >> Rich suggested? If we use a leading byte, maybe it's better to have two >> formats, >> one for "x coordinate only", one for "y + bit sign of x"? > > * You appear to be confusing Montgomery form with Edwards form. The > Curve25519 paper specifies â€Montgomery-form x coordinate only’; the > other format you are suggesting seems to be â€Edwards-form y coordinate > with sign bit of Edwards-form x coordinate’. (Remember that the > Edwards-form y coordinate is analogous to the Montgomery-form x > coordinate.) > I misinterpreted your suggestion indeed. I read "Edwards" and immediately thought that you were talking everything in Edwards form (hence the y coordinate), which would have made little sense in this context. > * If you do not add a leading point-format byte, there is no reason to > specify the meaning of the high bit in this document. If you do add a > leading byte, you will have to choose in this document whether the > sign bit is for the Edwards-form x coordinate or the Montgomery-form y > coordinate. > Or we could add a leading byte now and say that the meaning of the msb is not defined yet an reserved for future use (which is what you suggest anyway, IIUC). Then a future document could update the meaning of this leading byte. > * Some future applications may wish to transmit an uncompressed > Edwards-form x coordinate or Montgomery-form y coordinate, not just > the sign bit. If you add a leading byte, you'll have to choose which > coordinate to use now. Alternatively, you could specify that > implementations of this document accept 64-byte points and ignore the > second half of the point structure. (Note that this means > implementations of this protocol MUST ignore the second half, even if > they know how to use it in some other protocol, or they will be > distinguishable from other ECDH implementations. I don't think that > restriction will ever be a problem for ECDH implementations.) > I'm afraid I didn't get your point. Why would we have to choose which coordinate to use now? If we add a leading byte meaning "the 32 bytes of the x coordinate (Montgomery form) follow"[1], and if people later want to be able to transmit two full coordinates, then they will pick a new leading byte and they will have to choose which coordinates to use with it, not us. [1] With some clarification about the msb as discussed above. > * Some future (non-ECDH) applications may wish to transmit an > Edwards-form y coordinate instead of a Montgomery-form x coordinate > (e.g. so that they can distinguish the point of order 2 from the > identity). If you do not add a leading point-format byte now, those > applications will have to use a different NamedCurve in order to > indicate that they are incompatible with the point formats used for > ECDH. (I'm not sure that this is a problem, or that any such > applications will ever exist.) > My humble opinion is that those applications should use a different NamedCurve indeed. > I'm currently leaning towards â€just reserve the high bit and tell > implementations to accept and ignore the second half of a 64-byte > point structure’, but there may be good enough arguments for using a > magic byte to justify the minor downsides. > Transmitting 64 bytes when 33 (32 + leading byte allowing future extensions) are enough will probably be seen as a waste by many people. > Then either (a) don't recommend that countermeasure as an alternative > to using constant-time field operations, or (b) explicitly warn that > there is no evidence that that countermeasure will be sufficient to > protect against side-channel attacks. > Right. Manuel. From ekr@rtfm.com Thu Jan 23 02:06:46 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD6221A03DB for ; Thu, 23 Jan 2014 02:06:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjEtA285ACSL for ; Thu, 23 Jan 2014 02:06:45 -0800 (PST) Received: from mail-ve0-f178.google.com (mail-ve0-f178.google.com [209.85.128.178]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA221A03CD for ; Thu, 23 Jan 2014 02:06:45 -0800 (PST) Received: by mail-ve0-f178.google.com with SMTP id oy12so955379veb.23 for ; Thu, 23 Jan 2014 02:06:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=BgCpgxsvJ8ikx3wTbVrjzu4vd5uiTayqA+tkC/fDgv0=; b=cs1yipKo45IzHViRcnfSEh3SeGsksA3RqYo1UzmUBtWXiTwz8nvtKjGu+DtNEYw4yb KRActbbOdK5GpzfmS3g3PpnDNX4Z7fvvcLwETYYU1fK+zV4T925+RmArcmlCPFqXK36J fyAHhI79UKqrRektgKHBj/E7N98vx1XHT0j37zTrmtdQpIVgKsiGZjEryjCZ0/gWJLPd qSgSbyUQ9Ett1aO8wB8gq+omGUPHWu0n0Jr747ZYNdMb5UtIcRXo+lKpfAlXuUbSODJc w6/gWnLBBQKlVIATyEjewtC6/p6yRj9n21Ab+CS1I5vT9wJEaqW/CNBe0NDWjoZ9iYsd CK2A== X-Gm-Message-State: ALoCoQnzFznw8xdJ+Tq0Z14TZjns8o0Mv99FcQB53xW69EBGgCpAcp9gFjOmzFZ69ZaAlLH70v+h X-Received: by 10.220.99.7 with SMTP id s7mr4006143vcn.19.1390471604346; Thu, 23 Jan 2014 02:06:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.106.162 with HTTP; Thu, 23 Jan 2014 02:06:04 -0800 (PST) X-Originating-IP: [173.38.208.169] From: Eric Rescorla Date: Thu, 23 Jan 2014 11:06:04 +0100 Message-ID: To: "tls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Jan 2014 10:06:47 -0000 WG Members, This message is a call for acceptance of http://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-01 As a TLS WG item. Please provide any comments on this action by Feb 7. Because there has been only modest discussion of this document, the chairs ask people who have already spoken in favor or against this document to re-register their opinion (feel free to just say +1 or -1 and point back to the archives.) -Ekr [For the chairs] From benl@google.com Thu Jan 23 02:53:50 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 353DB1A0447 for ; Thu, 23 Jan 2014 02:53:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.914 X-Spam-Level: X-Spam-Status: No, score=-1.914 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, RP_MATCHES_RCVD=-0.535, 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 TWZt61d4VZMQ for ; Thu, 23 Jan 2014 02:53:48 -0800 (PST) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 72F0A1A03E8 for ; Thu, 23 Jan 2014 02:53:48 -0800 (PST) Received: by mail-ig0-f171.google.com with SMTP id uy17so16627106igb.4 for ; Thu, 23 Jan 2014 02:53:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1gtBD1FDYMy4Qnd3UfIEV6T0RAK2fH73YpvPWr0rEtA=; b=JXf/woESKru6u4IaJSO0z7aaxefuK/GXmjOE5pvVygXYhlh1w4bMniALmtWgSasAvR UcgXi/bNoYFiVg3H8x/k7fi+2Ui/mrBBRtS6tKzWjpC+sYuNkvsBcItY/OQ6j1b+7Nj2 quSsK0NIZlZ1bTqxOPR8e32vAQlPVHNS1UdrKFP7r0UENyx+Uatm+ciSVXnZ/EDWtRWx ld2xMImjYJYReRMzklBhQjD45bzRlYIKotnpoeDpttGjiHjDWp0xOp0PR42gQk/sfe8e nHCx2PQbu7YHbTenHG/dxNsomOH85EHqOF2B2y/z2CWd08MmRJ4agPjDuKMmDbJjMVLf MsAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1gtBD1FDYMy4Qnd3UfIEV6T0RAK2fH73YpvPWr0rEtA=; b=VuBXlcw7NukiugkDNqU1B8DwVtAqqDWgclxJJBOUmCnmYAqIAfuabkZLNSyWM9IKfl QzlOqps+8/A9ep6aSZFRlhwvkccqLEX2XlP+x09sAEojDQVWK7LpeVCoB1o8g9z7PN0/ /qkZPId8tHoZJLYrdez9u0CppMQGGjHZP7UD8/OZ8DQYsN6EgNqmBqSKAWEqbNQ+46wz 7Q35D26Me7+vt2pkYswp2RCm/SKbg94M16v8GX5nvSfqa9BA5bfJKgbNpMGMk6pMeHWX 1lcSg3YvTNp/rI8RnrJTCYrCZa32SyuylGqppKuH3yYPmQsPM8yAHP9aFrOXuSTEHSkG yiZw== X-Gm-Message-State: ALoCoQmw9C27PzGtBBf690iEbtW053zhX5Z5GxtMX3jyIviUMDhhwWgIEiDUW3jhSSpff5fqef9Ye1No9hDtMw8sfqx+JYgz39uckcipjy2pqTyLZzX+SrP47d4EF7ifwZ0OtwJhIvVA4N5eWrKjSSjzduOWF5/imrEoYAjhGNlpQ41C/v+Yb/Opk+HseU5Yv8mhi7+HqorG MIME-Version: 1.0 X-Received: by 10.50.161.132 with SMTP id xs4mr28246871igb.38.1390474427397; Thu, 23 Jan 2014 02:53:47 -0800 (PST) Received: by 10.64.230.140 with HTTP; Thu, 23 Jan 2014 02:53:47 -0800 (PST) In-Reply-To: References: Date: Thu, 23 Jan 2014 10:53:47 +0000 Message-ID: From: Ben Laurie To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Jan 2014 10:53:50 -0000 On 23 January 2014 10:06, Eric Rescorla wrote: > WG Members, > > This message is a call for acceptance of > http://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-01 > > As a TLS WG item. > > Please provide any comments on this action by Feb 7. Because > there has been only modest discussion of this document, the > chairs ask people who have already spoken in favor or against > this document to re-register their opinion (feel free to just say > +1 or -1 and point back to the archives.) I think I haven't said anything before, but nevertheless, +1. > > -Ekr > [For the chairs] > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From rob.stradling@comodo.com Thu Jan 23 03:03:29 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7A61A0441 for ; Thu, 23 Jan 2014 03:03:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.41 X-Spam-Level: X-Spam-Status: No, score=0.41 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Ec2AB4xPpqZ for ; Thu, 23 Jan 2014 03:03:27 -0800 (PST) Received: from ian.brad.office.comodo.net (eth5.brad-fw.brad.office.ccanet.co.uk [178.255.87.226]) by ietfa.amsl.com (Postfix) with ESMTP id C89801A0385 for ; Thu, 23 Jan 2014 03:03:26 -0800 (PST) Received: (qmail 18608 invoked by uid 1000); 23 Jan 2014 11:03:24 -0000 Received: from nigel.brad.office.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 (CAMELLIA256-SHA encrypted) ESMTPSA; Thu, 23 Jan 2014 11:03:24 +0000 Message-ID: <52E0F6FC.9040000@comodo.com> Date: Thu, 23 Jan 2014 11:03:24 +0000 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= , tls@ietf.org References: <87ob3456s1.fsf@latte.josefsson.org> <52E008DD.9050002@comodo.com> <52E057F8.8040906@polarssl.org> In-Reply-To: <52E057F8.8040906@polarssl.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [TLS] Curve25519 in TLS and Additional Curves 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, 23 Jan 2014 11:03:29 -0000 On 22/01/14 23:44, Manuel Pégourié-Gonnard wrote: > On 22/01/2014 19:07, Rob Stradling wrote: >> Simon, Section 2.1 says: >> "Since Curve25519 are not designed to be used in signatures, clients >> who offer ECDHE_ECDSA ciphersuites and advertise support for >> Curve25519 in the elliptic_curves ClientHello extension SHOULD also >> advertise support for at least one other curve, suitable for ECDSA. >> Servers MUST NOT select an ECDHE_ECDSA ciphersuite if the only common >> curve is Curve25519." >> >> Why is that "SHOULD" not a MUST? >> > The idea is that, if a client offers ECDHE_ECDSA ciphersuites but no > ECDSA-capable curve, the handshake can still be completed if non-ECDSA > ciphersuites are offered too: the server will select one of these suites. In > this case, offering ECDHE_ECDSA suite is just a waste of bytes, but does not > harm interoperability. > > Making it a SHOULD may simplify client-side implementations in which the user > can select the list of supported curves and ciphersuites, by allowing the > implementation not to filter the list of ciphersuites based on the selected curves. > > Manuel. OK, that makes sense. BTW, since other NamedCurves may be defined in the future that "are not designed to be used in signatures", how about changing... "Servers MUST NOT select an ECDHE_ECDSA ciphersuite if the only common curve is Curve25519." ...to... "Servers MUST NOT select an ECDHE_ECDSA ciphersuite if there are no common curves suitable for ECDSA." ? -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From mpg@polarssl.org Thu Jan 23 03:06:35 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D4751A0441 for ; Thu, 23 Jan 2014 03:06:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.293 X-Spam-Level: ** X-Spam-Status: No, score=2.293 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6dybGkxqIyp for ; Thu, 23 Jan 2014 03:06:34 -0800 (PST) Received: from vps2.brainspark.nl (vps2.brainspark.nl [141.138.204.106]) by ietfa.amsl.com (Postfix) with ESMTP id 618B51A0430 for ; Thu, 23 Jan 2014 03:06:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=30TNBvD8WNJZ3fsBbtWC5zmCRDTaSMyN492UENlO840=; b=MorayaDSDebrf3lWumbL1RmLaoJ7U8C67WSAGfgs8up3Rbkqx77/J1DRP6wqcAIKn5Cp+E6efPjzeVfXGi29kTxibO9GursgQhfibatND6DJUKINOpQwo+DAc3XEPUpmK286XlLX+QMMJyxuHlSQt/u6WdkVVTK/rQgZP3sjRWE=; Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.brainspark.nl with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1W6I0M-0001O7-Td for tls@ietf.org; Thu, 23 Jan 2014 11:59:27 +0100 Message-ID: <52E0F7B8.60307@polarssl.org> Date: Thu, 23 Jan 2014 12:06:32 +0100 From: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.1.1 MIME-Version: 1.0 To: tls@ietf.org References: <87ob3456s1.fsf@latte.josefsson.org> <52E008DD.9050002@comodo.com> <52E057F8.8040906@polarssl.org> <52E0F6FC.9040000@comodo.com> In-Reply-To: <52E0F6FC.9040000@comodo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 88.165.216.11 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.brainspark.nl) Subject: Re: [TLS] Curve25519 in TLS and Additional Curves 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, 23 Jan 2014 11:06:35 -0000 On 23/01/2014 12:03, Rob Stradling wrote: > OK, that makes sense. > I'm glad you agree. > BTW, since other NamedCurves may be defined in the future that "are not > designed to be used in signatures", how about changing... > > "Servers MUST NOT select an ECDHE_ECDSA ciphersuite if the only common > curve is Curve25519." > > ...to... > > "Servers MUST NOT select an ECDHE_ECDSA ciphersuite if there are no > common curves suitable for ECDSA." > > ? > Yes, absolutely. Manuel. From rsalz@akamai.com Thu Jan 23 07:14:01 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 624481A0016 for ; Thu, 23 Jan 2014 07:14:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNMtSBm48QBD for ; Thu, 23 Jan 2014 07:13:58 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB741A000E for ; Thu, 23 Jan 2014 07:13:58 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 5749948210; Thu, 23 Jan 2014 15:13:56 +0000 (GMT) Received: from prod-mail-relay04.akamai.com (prod-mail-relay04.akamai.com [172.27.8.27]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 49CB64820F; Thu, 23 Jan 2014 15:13:56 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub4.kendall.corp.akamai.com [172.27.105.20]) by prod-mail-relay04.akamai.com (Postfix) with ESMTP id 2ACB547BF8; Thu, 23 Jan 2014 15:13:56 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.2.116]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Thu, 23 Jan 2014 10:13:55 -0500 From: "Salz, Rich" To: Watson Ladd Date: Thu, 23 Jan 2014 10:13:55 -0500 Thread-Topic: [TLS] Curve25519 in TLS and Additional Curves in TLS Thread-Index: Ac8YBk6LbUGpdR6pTkSEi67OKl9nHwAR0sUg Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711EA93FB50@USMBX1.msg.corp.akamai.com> References: <87ob3456s1.fsf@latte.josefsson.org> <2A0EFB9C05D0164E98F19BB0AF3708C711E95FFF6D@USMBX1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "tls@ietf.org" , Simon Josefsson Subject: Re: [TLS] Curve25519 in TLS and Additional Curves 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, 23 Jan 2014 15:14:01 -0000 V291bGQgeW91IHByZWZlciBpdCBwaHJhc2VkIHRoaXMgd2F5OiAgInBvaW50bGVzc2x5IGJyZWFr aW5nIGNvbXBhdGliaWxpdHkgd2l0aCBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgaXMgcmVhc29u IGVub3VnaCB0byB2b3RlIG5vIg0KDQoJL3IkDQoNCi0tICANClByaW5jaXBhbCBTZWN1cml0eSBF bmdpbmVlcg0KQWthbWFpIFRlY2hub2xvZ3kNCkNhbWJyaWRnZSwgTUENCg== From agl@google.com Thu Jan 23 09:57:53 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4087B1A00C2 for ; Thu, 23 Jan 2014 09:57:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.914 X-Spam-Level: X-Spam-Status: No, score=-1.914 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, RP_MATCHES_RCVD=-0.535, 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 ro1SYnndnwYt for ; Thu, 23 Jan 2014 09:57:48 -0800 (PST) Received: from mail-oa0-x22b.google.com (mail-oa0-x22b.google.com [IPv6:2607:f8b0:4003:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 71D2F1A000C for ; Thu, 23 Jan 2014 09:57:48 -0800 (PST) Received: by mail-oa0-f43.google.com with SMTP id h16so2530330oag.2 for ; Thu, 23 Jan 2014 09:57:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=3NdcVdg80uEWnKSf9D38Glh3s6T731Gy1BEX3I3xEG8=; b=Mk4z58+js64+zIk+rHVEe/brRiBqFmvyuMpCq5XaIAZc8jv4AOHG4jVret1otmNoDD 6sYmwT3k1fhaEgZVgoFL6nv1/EcJTp1z/7Jp5jwd6NPe4XjNKvvevlMLvxx1AedpzRhn kIAsTVEcPXf0r4utp4gXv+ftL0j1okNt2z3gArWy3wlw4u0YcYNalA9uNp6tUU6EoA6I D0848gLA1gmsxrt0H1v3OsRm3XZj5T/3vkPceUetI7PwkQlZ60X1jy7vH7OkSD0Gj2XK HF1fKT83+Cz41V7+Av1Dx4qKjjNmp070f/+2diUSU6EUnUWRQNW1EKgbGlYIBhYhdd5a bOng== 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=3NdcVdg80uEWnKSf9D38Glh3s6T731Gy1BEX3I3xEG8=; b=LJoU+6DnuNHR10gDbL9n16pNSKCEiWmfnv5BiTTjM/8OB7veC5y9YIKx0f+FZUwHaR hK0fwAlf5S/1sj3TjgixuFH6OHxYu+wUYFKYzv3MpFk1SiG82Ua42v8g4Vw2XzQW4eRp CHwqgblSCc23Sc8HFXerZKss0cg3GRhhRPIMgreMG6cJOxm/nE0Pq9Dao74Ov/fnMhoj Yab0YSgsQ64erjm7cLf9SKKAJkKChgOaSK6DXd9jK9P4PbYtP6MjBItl5UNEznTMyW06 L/9/PPIE18C3XDHwlPz6MoAPf6awl+9oOF7EJ8Lkh+tsXX04DqvmQG7CeqwshH6fymnG pW0Q== X-Gm-Message-State: ALoCoQl69ULkzQU4UaJRLLO4n3odSJuYfr4DENYGy5zuAdcTalF9ecHHvY1XS6XlXHftEBhKSSloGEdFhyCo/vsyo3+hbgD6q7/irYN878M0DQ4jr7Kjng94QOZESFaC6wbazxT9GhcSDjl0QP8eZexscYQT6m8qD+OwjNKGm3LFVA4qDUro5ZgbIMWiibgf2pdD51z2TT4h X-Received: by 10.182.135.165 with SMTP id pt5mr1751526obb.66.1390499867318; Thu, 23 Jan 2014 09:57:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.79.105 with HTTP; Thu, 23 Jan 2014 09:57:27 -0800 (PST) In-Reply-To: References: From: Adam Langley Date: Thu, 23 Jan 2014 12:57:27 -0500 Message-ID: To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Jan 2014 17:57:53 -0000 On Thu, Jan 23, 2014 at 5:06 AM, Eric Rescorla wrote: > Please provide any comments on this action by Feb 7. Because > there has been only modest discussion of this document, the > chairs ask people who have already spoken in favor or against > this document to re-register their opinion (feel free to just say > +1 or -1 and point back to the archives.) 0 currently because I don't know whether it'll work in the real world. Ask me again in 10 weeks. Cheers AGL From kurt@roeckx.be Thu Jan 23 10:07:21 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96D1D1A0177 for ; Thu, 23 Jan 2014 10:07:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 388YObyHxClV for ; Thu, 23 Jan 2014 10:07:15 -0800 (PST) Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) by ietfa.amsl.com (Postfix) with ESMTP id 093C91A0015 for ; Thu, 23 Jan 2014 10:07:15 -0800 (PST) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 7AB041C20F7; Thu, 23 Jan 2014 19:07:13 +0100 (CET) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 57D861FE0170; Thu, 23 Jan 2014 19:07:13 +0100 (CET) Date: Thu, 23 Jan 2014 19:07:13 +0100 From: Kurt Roeckx To: Eric Rescorla Message-ID: <20140123180713.GA31076@roeckx.be> References: 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) Cc: "tls@ietf.org" Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Jan 2014 18:07:21 -0000 On Thu, Jan 23, 2014 at 11:06:04AM +0100, Eric Rescorla wrote: > WG Members, > > This message is a call for acceptance of > http://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-01 > > As a TLS WG item. > > Please provide any comments on this action by Feb 7. I think preventing downgrade attacks is important, and as such I think it's a good idea. But I have to wonder if it actually solves anything or not. I think the document starts from the assumption that there is someone in the middle that can alter the data, and then let the client do a downgrade. What is stopping this attacker from removing this scsv from the client hello? Kurt From agl@google.com Thu Jan 23 10:14:44 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC101A00F7 for ; Thu, 23 Jan 2014 10:14:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.914 X-Spam-Level: X-Spam-Status: No, score=-1.914 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, RP_MATCHES_RCVD=-0.535, 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 kBJ6I5n1BL9p for ; Thu, 23 Jan 2014 10:14:39 -0800 (PST) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 7DEE31A0028 for ; Thu, 23 Jan 2014 10:14:39 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id vb8so2464862obc.31 for ; Thu, 23 Jan 2014 10:14:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Yk79wnv1R10dPIKR9iigOd96XjKenERaeq0B7B1PHgE=; b=M7lfFjaYIYnR+pPMRlk1/SVg0ryJb6onnHIoiVsSHzqV7n4Oc4lZMe2aI9HbGP/6R7 51hwptGQq5DvxcNMFblMf95S62kBbiVMWDpfa4HyzG0g7oI8H9zjDlxZZf+xZmiiuaev 1Ywsh5j9NI2xsEGf1eRs2fQqgvbaZOR5O9jjvSH/WqcyRQHX4G51zwc3jE/3QGPArMaW u+9z1r7UtD+iCXeqcqx+3mEexn89jHVhynmyasnldki/+YSL720mnE/+5jo2DK+QazJW yfjOeoiWsZgds8AhvmGB0RhqEbRV2gsQ4abEJ6/u9ksYDIJFYrqZcgXfGBBZzR7t/+C2 xv8g== 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=Yk79wnv1R10dPIKR9iigOd96XjKenERaeq0B7B1PHgE=; b=KdwxMbn0x6m4xiKQFZ600xZpC5GkPZlNUmiNZVvG9GZQ6WqZSpAAXLWshirkpNGHxU Ap7e0qW+Usv0X7A11yzt6aa5CIawpVULm6nZcs5/UXZs/6KpMpyjic3c0UO6RlePudon E4yqdsYClyiUNA/BEEL4lvQAXSfQYNC2WM8E0605UrvNFUrSldBFjLu1hc69jldbb4aY wKexT7cgXiuVoHOEAAEM/SHn78byE9iAfdAHORslPh3zK6UGEvL17mvZWNaqZWSUuOIm A7meI6Pn6bEgWSB9i0I4nMFnA7CqO0GIenMq+UpbYzAscT/+rofbgyGwndPmBdKQ1nOz C9jg== X-Gm-Message-State: ALoCoQm8qKfoK3kI6fk9JlW8kedUI3hFZeXBrLO/Jlz0CGW9nrj9FIZxcN3mwLT/emB5GOBqWgugqj6mzXjZfWsv+eUszMBsw2wu37m1TgDAjR46PT3bjg6MtwtKxlNXz6xJ1jXwE9bIWcN+qVAgUOzSBxMeeeJbVt/j2vcx8gcPlgiO9Yhuevn2Z7/bjqNZ8hM9+E1FBC0B X-Received: by 10.182.129.201 with SMTP id ny9mr7907465obb.0.1390500878426; Thu, 23 Jan 2014 10:14:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.79.105 with HTTP; Thu, 23 Jan 2014 10:14:18 -0800 (PST) In-Reply-To: <20140123180713.GA31076@roeckx.be> References: <20140123180713.GA31076@roeckx.be> From: Adam Langley Date: Thu, 23 Jan 2014 13:14:18 -0500 Message-ID: To: Kurt Roeckx Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Jan 2014 18:14:44 -0000 On Thu, Jan 23, 2014 at 1:07 PM, Kurt Roeckx wrote: > I think the document starts from the assumption that there is > someone in the middle that can alter the data, and then let the > client do a downgrade. What is stopping this attacker from > removing this scsv from the client hello? The Finished messages will detect any manipulation of the handshake. The key to the draft is that we believe that no servers will be intolerant to the SCSV, and thus clients can always send it when doing a fallback. Cheers AGL From rransom.8774@gmail.com Thu Jan 23 10:33:32 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF5A1A01AB for ; Thu, 23 Jan 2014 10:33:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 Tc_kyUw12iaf for ; Thu, 23 Jan 2014 10:33:31 -0800 (PST) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id A82601A000A for ; Thu, 23 Jan 2014 10:33:31 -0800 (PST) Received: by mail-qc0-f178.google.com with SMTP id m20so2959300qcx.23 for ; Thu, 23 Jan 2014 10:33:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gt+nuBxPujwJX8Dp7EXT1yFbe01pJYFMKy/nELT7y/s=; b=DCu7HTn8Wm4FvoG/qffcGhuLH1+4FogJZwM8sCRGRqAfT/PquGiyZEI4pdP1mLzM6c dRjApMqCHD80cmIrmhWbFrIg2mg41gGXM8cu+BxixSBWt5qILXcdQssPCiiVj+znrCJE wN/pzHiUk+6VNs1YfznGeGlezzFIDPNJfF0Fs7ORmE1+6D8GDltS6fBb8nSdx3Qyz5eO uOo8yiUvDY3C0qFiAM2sUEWpTKKjCKX0esEBFZXMycAE0096u/JI9VRzvIfvhEmjtMaX Em9V1vwN1qU75kPNyeF0ysh0vtMPyu/M47anNKBBw7q4w9i86OJ8M65pqqNSSxBfnC/N cCnQ== MIME-Version: 1.0 X-Received: by 10.140.92.213 with SMTP id b79mr13191626qge.108.1390502010639; Thu, 23 Jan 2014 10:33:30 -0800 (PST) Received: by 10.229.181.132 with HTTP; Thu, 23 Jan 2014 10:33:30 -0800 (PST) In-Reply-To: <1390466373.20176.8.camel@dhcp-2-127.brq.redhat.com> References: <87ob3456s1.fsf@latte.josefsson.org> <1390466373.20176.8.camel@dhcp-2-127.brq.redhat.com> Date: Thu, 23 Jan 2014 10:33:30 -0800 Message-ID: From: Robert Ransom To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 Cc: Simon Josefsson , tls@ietf.org Subject: Re: [TLS] Curve25519 in TLS and Additional Curves 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, 23 Jan 2014 18:33:32 -0000 On 1/23/14, Nikos Mavrogiannopoulos wrote: > On Wed, 2014-01-22 at 13:16 -0800, Robert Ransom wrote: > >> * The draft still specifies a big-endian point format. What is the >> technical benefit of requiring every TLS implementation which uses one >> of the existing efficient, secure implementations of Curve25519 >> Montgomery-form scalar multiplication to reverse the byte order of its >> input and output? (Note that people want to use Curve25519 in TLS >> because of those existing implementations, so deliberately breaking >> compatibility with them seems especially unwise.) > > An Internet protocol is not typically designed based on the existing > implementations limitations and they it is often expected to outlive > them. Almost all IETF protocols use the big-endian format for > transferring integers, and implementations of these protocols in have > already ways to convert these numbers to the native endianess. *This* Internet protocol is motivated by the existing implementations for Curve25519. What is the *technical benefit* of deliberately breaking compatibility with the implementations which justify this protocol's existence? Robert Ransom From luto@amacapital.net Thu Jan 23 10:40:39 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D18F91A001B for ; Thu, 23 Jan 2014 10:40:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 jSwtX_EMA5Id for ; Thu, 23 Jan 2014 10:40:35 -0800 (PST) Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com [209.85.192.175]) by ietfa.amsl.com (Postfix) with ESMTP id A5E771A01E6 for ; Thu, 23 Jan 2014 10:40:19 -0800 (PST) Received: by mail-pd0-f175.google.com with SMTP id w10so2096173pde.6 for ; Thu, 23 Jan 2014 10:40:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=rgeRnBqsNOLkBv5N69pv39/7MZpJlfdIFwEtSA+RYJ0=; b=YZa4cmXtzmeEeQFDvSiKpNO0Csio0w9Atmzdoqu1gXD185vJB/Vc95UyeYGpYN1NYr eXGzpF5Q09Mx3SOBWdi4ehH3ES2G/vuVeKLZAM8VoM/1MN10CA0Nhs+s9v+vN0F/iltT OPIBuRXCWxtWOh2WYe6Qc/0I/UhohWSa16Q0I+rDHvllupcb8Zak/eOjrR6CHFrUhmAE HccjPbPlpUNUvHS9zt/nS+rSw6qbO+nNKSUFDYiPlBf7UCuLkhpZTAwtVnKMsJPYJL4n tQjsIBtMFaIwI8ojV3yx0TjcS5AyDgW4N/0jfBXev/aOJgwESDrYqQ19ZbGj7/Op3vzl UfPg== X-Gm-Message-State: ALoCoQl4Y13eFWlU0AKccBxK2uU4uunjWzqg3nz8jveFxRm8BrLq80xYCQlBSBxaUBSuHWDcRF2a X-Received: by 10.66.232.7 with SMTP id tk7mr9607362pac.94.1390502418752; Thu, 23 Jan 2014 10:40:18 -0800 (PST) Received: from amaluto.corp.amacapital.net (50-76-60-73-ip-static.hfc.comcastbusiness.net. [50.76.60.73]) by mx.google.com with ESMTPSA id lh13sm64707907pab.4.2014.01.23.10.40.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 Jan 2014 10:40:18 -0800 (PST) Message-ID: <52E16210.1000405@mit.edu> Date: Thu, 23 Jan 2014 10:40:16 -0800 From: Andy Lutomirski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Robert Ransom , =?UTF-8?B?TWFudWVsIFDDqWdvdXJp?= =?UTF-8?B?w6ktR29ubmFyZA==?= References: <87ob3456s1.fsf@latte.josefsson.org> <52E060D0.9030801@polarssl.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: tls@ietf.org Subject: Re: [TLS] Curve25519 in TLS and Additional Curves 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, 23 Jan 2014 18:40:40 -0000 On 01/22/2014 05:17 PM, Robert Ransom wrote: > On 1/22/14, Manuel PĂ©gouriĂ©-Gonnard wrote: >> On 22/01/2014 22:16, Robert Ransom wrote: > >>> * The draft should specify that implementations MUST discard (i.e. set >>> to zero) the most significant bit of a received public key, for two >>> reasons: (a) Existing Curve25519 scalarmult implementations differ in >>> their handling of inputs with that bit set, and could be distinguished >>> by an active attacker using that difference. >> >> I wasn't aware that some implementations ignored the most significant bit. >> Out >> of curiosity, could you cite examples? > > curve25519-donna and -donna-c64 ignore the MSB. > > Nick Mathewson (Tor lead developer) tested whether Dr. Bernstein's > floating-point implementation for IA-32 in NaCl ignores the MSB; he > reported that it does. > > The â€ref’ implementation in NaCl does not ignore the MSB. > > I have no idea what Dr. Bernstein's original floating-point Curve25519 > implementation for IA-32 does with the MSB, but the web page > documenting it hints that it treats the MSB as part of the x > coordinate. > >> One of the "selling points" of Curve25519 is that no public key validation >> is >> needed, so I find it quite unfortunate that after all there is something to >> do >> when receiving public keys. > > Fingerprinting of implementations wasn't one of the security concerns > that Dr. Bernstein had in mind at the time, and it still isn't widely > considered to be a security risk. It's certainly minor compared to > the numerous ways that NSA-curve ECDH implementations can leak their > keys. > > But the bigger reason to mask off the high bit is extensibility. > >>> (b) Future specifications >>> may wish to include the sign bit of an Edwards-form x coordinate in a >>> Curve25519 point format for use with other protocols (e.g. Schnorr >>> signature, Ace) without breaking backwards compatibility with use in >>> ECDH. >>> >> This is a serious concern indeed. By the way, there was another issue under >> discussion that is related: should the point format be just the 32 bytes, or >> should we use a leading byte to follow the existing practice from X9.62, as >> Salz >> Rich suggested? If we use a leading byte, maybe it's better to have two >> formats, >> one for "x coordinate only", one for "y + bit sign of x"? > > * You appear to be confusing Montgomery form with Edwards form. The > Curve25519 paper specifies â€Montgomery-form x coordinate only’; the > other format you are suggesting seems to be â€Edwards-form y coordinate > with sign bit of Edwards-form x coordinate’. (Remember that the > Edwards-form y coordinate is analogous to the Montgomery-form x > coordinate.) > > * There is no reason to ever transmit an Edwards-form y coordinate for > use in ECDH. The formats that would be useful here are > â€Montgomery-form x coordinate only’ and â€Montgomery-form x coordinate > with sign bit of Edwards-form x coordinate’. > > * If you do not add a leading point-format byte, there is no reason to > specify the meaning of the high bit in this document. If you do add a > leading byte, you will have to choose in this document whether the > sign bit is for the Edwards-form x coordinate or the Montgomery-form y > coordinate. > > * Some future applications may wish to transmit an uncompressed > Edwards-form x coordinate or Montgomery-form y coordinate, not just > the sign bit. If you add a leading byte, you'll have to choose which > coordinate to use now. Alternatively, you could specify that > implementations of this document accept 64-byte points and ignore the > second half of the point structure. (Note that this means > implementations of this protocol MUST ignore the second half, even if > they know how to use it in some other protocol, or they will be > distinguishable from other ECDH implementations. I don't think that > restriction will ever be a problem for ECDH implementations.) > > * Some future (non-ECDH) applications may wish to transmit an > Edwards-form y coordinate instead of a Montgomery-form x coordinate > (e.g. so that they can distinguish the point of order 2 from the > identity). If you do not add a leading point-format byte now, those > applications will have to use a different NamedCurve in order to > indicate that they are incompatible with the point formats used for > ECDH. (I'm not sure that this is a problem, or that any such > applications will ever exist.) Can someone remind me why any of the above is better than using ECPointFormat to specify the point format? --Andy From rsalz@akamai.com Thu Jan 23 10:46:51 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D62A51A001B for ; Thu, 23 Jan 2014 10:46:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.435 X-Spam-Level: X-Spam-Status: No, score=-4.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MI5aRuKgdync for ; Thu, 23 Jan 2014 10:46:45 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 839A31A000A for ; Thu, 23 Jan 2014 10:46:45 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 896D228441; Thu, 23 Jan 2014 18:46:44 +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 7607328132; Thu, 23 Jan 2014 18:46:44 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 5D3FE1FF9; Thu, 23 Jan 2014 18:46:44 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.2.116]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Thu, 23 Jan 2014 13:46:43 -0500 From: "Salz, Rich" To: Andy Lutomirski , Robert Ransom , =?utf-8?B?TWFudWVsIFDDqWdvdXJpw6ktR29ubmFyZA==?= Date: Thu, 23 Jan 2014 13:46:43 -0500 Thread-Topic: [TLS] Curve25519 in TLS and Additional Curves in TLS Thread-Index: Ac8YaqPUoIknXzsIQ6GgahMlABAklQAAGyOA Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711EA93FCA9@USMBX1.msg.corp.akamai.com> References: <87ob3456s1.fsf@latte.josefsson.org> <52E060D0.9030801@polarssl.org> <52E16210.1000405@mit.edu> In-Reply-To: <52E16210.1000405@mit.edu> 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 Cc: "tls@ietf.org" Subject: Re: [TLS] Curve25519 in TLS and Additional Curves 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, 23 Jan 2014 18:46:52 -0000 PiBDYW4gc29tZW9uZSByZW1pbmQgbWUgd2h5IGFueSBvZiB0aGUgYWJvdmUgaXMgYmV0dGVyIHRo YW4gdXNpbmcgRUNQb2ludEZvcm1hdCB0byBzcGVjaWZ5IHRoZSBwb2ludCBmb3JtYXQ/DQoNCkJl Y2F1c2UgRUNQb2lucnRGb3JtYXQgcmVxdWlyZXMgWCBhbmQgWSBjb3JkcyBhbmQgQ3VydmUyNTUx OSBoYXMgbm8gWS4NCg0KVGhlcmUgaXMgZGlzY3Vzc2lvbiBhYm91dCBoYXZpbmcgYSAiZGVmaW5l ZCBieSB0aGUgY3VydmUiIEVDUG9pbnRGb3JtYXQ7IGhvdyB0byBtb3ZlIHN1Y2ggYSBwcm9wb3Nh bCBmb3J3YXJkIGlzIGJlaW5nIGRpc2N1c3NlZCBieSB0aGUgU2VjdXJpdHkgQXJlYSBEaXJlY3Rv cnMsIHdobyBvd2UgYXMgYSByZXNwb25zZSAic29vbiIgKHNlZSBodHRwOi8vd3d3LmlldGYub3Jn L21haWwtYXJjaGl2ZS93ZWIvdGxzL2N1cnJlbnQvbXNnMTExMzkuaHRtbCApDQoNCgkvciQNCg0K LS0gIA0KUHJpbmNpcGFsIFNlY3VyaXR5IEVuZ2luZWVyDQpBa2FtYWkgVGVjaG5vbG9neQ0KQ2Ft YnJpZGdlLCBNQQ0K From luto@amacapital.net Thu Jan 23 10:53:25 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8B91A0115 for ; Thu, 23 Jan 2014 10:53:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UbZaXV7iBERQ for ; Thu, 23 Jan 2014 10:53:21 -0800 (PST) Received: from mail-ve0-f173.google.com (mail-ve0-f173.google.com [209.85.128.173]) by ietfa.amsl.com (Postfix) with ESMTP id C270B1A00FF for ; Thu, 23 Jan 2014 10:53:20 -0800 (PST) Received: by mail-ve0-f173.google.com with SMTP id oz11so1355188veb.18 for ; Thu, 23 Jan 2014 10:53:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=x9D+Fp1L9nYUzjWEREyT6rdxBli9ZTppYgev8EEg7vw=; b=VPNgpl64Cz7cWYmus/dbVuGD0BihyV4nTZgO8UjKtk1OEv6FFP+nqGqVkTj0GuB0SN DIDy0vQ4W/YjwUvu2JyjpzLEevAZJgKZyDvjoYrN9/v94oETwScCLD+VNyjLDxKRq8RV Dvat3mz1hAgprj2zNXlgipBkDO72LJnIvnH/W0UK8FfoSL9+qnO6w1X7T7Tuuk3PuN3Y Xt9nwV+VNKKspoccqa5xEWFcnVePagFOLP7UJLnC3o0CqHIkVlzgG4sEDKLBu4VzEi1c AFRhry4TSTeStkPtW7hzRvF2DI+30yj9nt8+c4ftiKrlJAoYTisZNQCCZMmYL4YiaS0A aS0A== X-Gm-Message-State: ALoCoQkG4PEq+78fnFDZH61dWxCaX37MQClt68zRxvbvI0gTzE/7xUBipyDkN/8dX7XFY0k+6l8X X-Received: by 10.58.180.227 with SMTP id dr3mr2336083vec.36.1390503199691; Thu, 23 Jan 2014 10:53:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.57.130 with HTTP; Thu, 23 Jan 2014 10:52:59 -0800 (PST) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711EA93FCA9@USMBX1.msg.corp.akamai.com> References: <87ob3456s1.fsf@latte.josefsson.org> <52E060D0.9030801@polarssl.org> <52E16210.1000405@mit.edu> <2A0EFB9C05D0164E98F19BB0AF3708C711EA93FCA9@USMBX1.msg.corp.akamai.com> From: Andy Lutomirski Date: Thu, 23 Jan 2014 10:52:59 -0800 Message-ID: To: "Salz, Rich" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9=2DGonnard?= , "tls@ietf.org" Subject: Re: [TLS] Curve25519 in TLS and Additional Curves 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, 23 Jan 2014 18:53:25 -0000 On Thu, Jan 23, 2014 at 10:46 AM, Salz, Rich wrote: >> Can someone remind me why any of the above is better than using ECPointF= ormat to specify the point format? > > Because ECPoinrtFormat requires X and Y cords and Curve25519 has no Y. > Why is "defined by the curve" (where said definition may not actually allow x and y to be computed) less of a departure from the current ECPointFormat than, say, "Montgomery form x and sign bit of Edwards form x"? It's already the case that not all point formats are applicable to all curves. > There is discussion about having a "defined by the curve" ECPointFormat; = how to move such a proposal forward is being discussed by the Security Area= Directors, who owe as a response "soon" (see http://www.ietf.org/mail-arch= ive/web/tls/current/msg11139.html ) > > /r$ > > -- > Principal Security Engineer > Akamai Technology > Cambridge, MA --=20 Andy Lutomirski AMA Capital Management, LLC From rransom.8774@gmail.com Thu Jan 23 11:08:22 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF3B1A0197 for ; Thu, 23 Jan 2014 11:08:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 pO7CtA51MM4S for ; Thu, 23 Jan 2014 11:08:17 -0800 (PST) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id A2A1F1A0210 for ; Thu, 23 Jan 2014 11:08:17 -0800 (PST) Received: by mail-qa0-f44.google.com with SMTP id w5so2754825qac.31 for ; Thu, 23 Jan 2014 11:08:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Xng1/E8WHGf5P/tK6hmd31cxdt4JnyL36VHWp/qcwUc=; b=FAeBQ8GwPDlcmZF4fp3ove+5MrCGVYJXfm5+0EhodHV4WbdnpYgcGHOWmNm6p1xvVR 8/JJBHUW+sDLrE2nGpXCgWjamVA6Bm6MwpgMe806ahNnUFCF66MjuTPYwFoxDjjYnV08 M59uXrh9nWEk4HU23fOdRxSjgK/UlzSxkz4GIbrL1yD3hA1WDfN9Iv+jHIaPSRNW7gKb StWl9pPGOXF6KMQaN9fShzRXWCz4pFxHLSM3LjiYPHLCBWKm6U3SfPmxx3m8llmr8bJw hIGIWskKMhHxqKpvUa1mOT6vYlLImsC4o8DAvGXaAwnpeoRzG1U95W9J5bgi1wZuYN0M +fng== MIME-Version: 1.0 X-Received: by 10.229.251.7 with SMTP id mq7mr14322985qcb.18.1390504096620; Thu, 23 Jan 2014 11:08:16 -0800 (PST) Received: by 10.229.181.132 with HTTP; Thu, 23 Jan 2014 11:08:16 -0800 (PST) In-Reply-To: <52E16210.1000405@mit.edu> References: <87ob3456s1.fsf@latte.josefsson.org> <52E060D0.9030801@polarssl.org> <52E16210.1000405@mit.edu> Date: Thu, 23 Jan 2014 11:08:16 -0800 Message-ID: From: Robert Ransom To: Andy Lutomirski Content-Type: text/plain; charset=UTF-8 Cc: =?UTF-8?Q?Manuel_P=C3=A9gouri=C3=A9=2DGonnard?= , tls@ietf.org Subject: Re: [TLS] Curve25519 in TLS and Additional Curves 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, 23 Jan 2014 19:08:22 -0000 On 1/23/14, Andy Lutomirski wrote: > Can someone remind me why any of the above is better than using > ECPointFormat to specify the point format? As far as I can tell from the spec, ECPointFormat is used only to tell parties what point formats their communication partner can process, not to describe the format of an actual point. (That's why the point formats referenced by RFC 4492 include a leading magic byte.) ECPoint must be self-describing within the scope of a given curve. Robert Ransom From rransom.8774@gmail.com Thu Jan 23 11:45:40 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 397231A001D for ; Thu, 23 Jan 2014 11:45:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.45 X-Spam-Level: X-Spam-Status: No, score=-1.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNUc5JiRDhNp for ; Thu, 23 Jan 2014 11:45:38 -0800 (PST) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 610141A007C for ; Thu, 23 Jan 2014 11:45:38 -0800 (PST) Received: by mail-qc0-f173.google.com with SMTP id i8so3114300qcq.18 for ; Thu, 23 Jan 2014 11:45:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=e/oK62t0XEms/KS+wBBk8HY8PX4sLn8S11jCl3rsiNI=; b=UuCAJoxqqXwTXB8lDopkeykCZhuUduVBo5Hc9Ll/BsZVEiR918HKcBhmMNJThcYg1R Sbxc0cmcfXtA/c7MgIeiCr1FMwMQogEy1yXUSz8o+jOhwOOkJQ4S9Wu4iBlnr1XfafdG +Dx6U+hDZiUKsaD0B/buEa89/zE5Jo3HcaRQV+aLo7LcSsYTUogs79jHHJpQR4HDiiww soEJ/rUxPg5S6jTxL0/EjT7XhpyQidCJeof/cAuwDiq+RzDK30v5kK6hwVsHezsCArAC LQwUvk3PR57f7dqr7I4/4+l2xEyGVQhzg8KM4m5C9kc/ShT2Q9OfMqUtgv0PODGopSl2 qspw== MIME-Version: 1.0 X-Received: by 10.229.102.4 with SMTP id e4mr14620264qco.2.1390506337275; Thu, 23 Jan 2014 11:45:37 -0800 (PST) Received: by 10.229.181.132 with HTTP; Thu, 23 Jan 2014 11:45:37 -0800 (PST) In-Reply-To: <52E0E241.40406@polarssl.org> References: <87ob3456s1.fsf@latte.josefsson.org> <52E060D0.9030801@polarssl.org> <52E0E241.40406@polarssl.org> Date: Thu, 23 Jan 2014 11:45:37 -0800 Message-ID: From: Robert Ransom To: =?UTF-8?Q?Manuel_P=C3=A9gouri=C3=A9=2DGonnard?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] Curve25519 in TLS and Additional Curves 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, 23 Jan 2014 19:45:40 -0000 On 1/23/14, Manuel P=C3=A9gouri=C3=A9-Gonnard wrote: > On 23/01/2014 02:17, Robert Ransom wrote: >> On 1/22/14, Manuel P=C3=A9gouri=C3=A9-Gonnard wrote: >>> On 22/01/2014 22:16, Robert Ransom wrote: >> >>>> * The draft should specify that implementations MUST discard (i.e. set >>>> to zero) the most significant bit of a received public key, for two >>>> reasons: (a) Existing Curve25519 scalarmult implementations differ in >>>> their handling of inputs with that bit set, and could be distinguished >>>> by an active attacker using that difference. >>> >>> I wasn't aware that some implementations ignored the most significant >>> bit. >>> Out >>> of curiosity, could you cite examples? >> >> curve25519-donna and -donna-c64 ignore the MSB. >> [...] >> The =E2=80=98ref=E2=80=99 implementation in NaCl does not ignore the MSB= . >> [...] > > Ok, thanks for the information. Samuel Neves reports that Dr. Bernstein's original Curve25519 implementation for IA-32 does ignore the high bit. So, the only implementation I know of that does not ignore the MSB is a horribly slow one that should never be used in production -- I would not be surprised if it's slower than a typical implementation of the BND curves. >> Fingerprinting of implementations wasn't one of the security concerns >> that Dr. Bernstein had in mind at the time, and it still isn't widely >> considered to be a security risk. It's certainly minor compared to >> the numerous ways that NSA-curve ECDH implementations can leak their >> keys. >> >> But the bigger reason to mask off the high bit is extensibility. >> > I fully agree it's the bigger reason. As discussed below, there is probab= ly > some > other ways to achieve extensibility, so if extensibility wasn't a concern= , > would > you think that avoiding implementation fingerprinting is more valuable th= an > being able to accept any string as a public key without no validation or > masking? I still think that avoiding implementation fingerprinting would justify =E2=80=9Cimplementations SHOULD mask off the high bit=E2=80=9D. Remember that what Dr. Bernstein refers to as =E2=80=98public key validatio= n=E2=80=99 in the Curve25519 paper is considerably more expensive than one bitwise AND: * With typical (non-twist-secure) curves in x-coordinate-only form, the recipient must compute the Legendre/Jacobi symbol of x^3 + c*x^2 + a*x + b in order to avoid operating on the twist. With Curve25519, the twist is as secure as the curve which contains the basepoint, so operating on the twist does not expose the secret key to any useful attacks. * The standard advice for handling curves with cofactor >1 is to check that it is a member of the prime-order subgroup before using it; this effectively performs the scalar multiplication operation twice. Curve25519 avoids this by (a) masking secret keys to be divisible by the cofactor, so the output will be in a subgroup of large-prime order regardless of the input; and (b) ignoring the widespread recommendation to reject ECDH keys which have small order. >> * If you do not add a leading point-format byte, there is no reason to >> specify the meaning of the high bit in this document. If you do add a >> leading byte, you will have to choose in this document whether the >> sign bit is for the Edwards-form x coordinate or the Montgomery-form y >> coordinate. >> > Or we could add a leading byte now and say that the meaning of the msb is > not > defined yet an reserved for future use (which is what you suggest anyway, > IIUC). > Then a future document could update the meaning of this leading byte. I think that's easiest (provided that current implementations also accept 64-byte points and discard the second half; see below). >> * Some future applications may wish to transmit an uncompressed >> Edwards-form x coordinate or Montgomery-form y coordinate, not just >> the sign bit. If you add a leading byte, you'll have to choose which >> coordinate to use now. Alternatively, you could specify that >> implementations of this document accept 64-byte points and ignore the >> second half of the point structure. (Note that this means >> implementations of this protocol MUST ignore the second half, even if >> they know how to use it in some other protocol, or they will be >> distinguishable from other ECDH implementations. I don't think that >> restriction will ever be a problem for ECDH implementations.) >> > I'm afraid I didn't get your point. Why would we have to choose which > coordinate > to use now? If we add a leading byte meaning "the 32 bytes of the x > coordinate > (Montgomery form) follow"[1], and if people later want to be able to > transmit > two full coordinates, then they will pick a new leading byte and they wil= l > have > to choose which coordinates to use with it, not us. > > [1] With some clarification about the msb as discussed above. If a future protocol wants to be compatible with implementations of this protocol, this protocol must specify some form of extension hook. If you choose a leading byte as the only extension hook, you must reserve a few alternate leading bytes now, along with enough information about the formats they will eventually describe that current implementations will be able to dig a Montgomery-form x coordinate out of the ECPoint blob. If you add a leading byte as an extension hook *and* specify an ECPointFormat value for the current =E2=80=98Montgomery-form x=E2=80=99 poi= nt format, current implementations can refuse to receive point formats which they won't understand. (This has the slight theoretical disadvantage that if a future protocol specifies time-based authentication of servers' ECDH public keys (to avoid the overhead of one signing for each client connection), implementations of that future protocol may have to sign more than one type of Curve25519 key per time period. I don't think this will be a real problem.) If you don't add a leading byte, I think the ECPoint length byte can still be used as an adequate extension mechanism for future non-ECDH protocols. >> * Some future (non-ECDH) applications may wish to transmit an >> Edwards-form y coordinate instead of a Montgomery-form x coordinate >> (e.g. so that they can distinguish the point of order 2 from the >> identity). If you do not add a leading point-format byte now, those >> applications will have to use a different NamedCurve in order to >> indicate that they are incompatible with the point formats used for >> ECDH. (I'm not sure that this is a problem, or that any such >> applications will ever exist.) >> > My humble opinion is that those applications should use a different > NamedCurve > indeed. OK. (Like I said, I'm not sure that anyone will ever want to do that.) >> I'm currently leaning towards =E2=80=98just reserve the high bit and tel= l >> implementations to accept and ignore the second half of a 64-byte >> point structure=E2=80=99, but there may be good enough arguments for usi= ng a >> magic byte to justify the minor downsides. >> > Transmitting 64 bytes when 33 (32 + leading byte allowing future extensio= ns) > are > enough will probably be seen as a waste by many people. I agree, but future implementations should be allowed to send an uncompressed second coordinate without breaking compatibility with implementations of this protocol. What I'm suggesting is that (a) current implementations send 32-byte points; (b) current implementations accept both 32-byte and 64-byte point objects, and ignore the second half of a 64-byte point. Robert Ransom From rob.stradling@comodo.com Thu Jan 23 12:35:05 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 963011A0164 for ; Thu, 23 Jan 2014 12:35:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.29 X-Spam-Level: X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, 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 WSSI2DFgakyn for ; Thu, 23 Jan 2014 12:35:02 -0800 (PST) Received: from ian.brad.office.comodo.net (eth5.brad-fw.brad.office.ccanet.co.uk [178.255.87.226]) by ietfa.amsl.com (Postfix) with ESMTP id 586171A013C for ; Thu, 23 Jan 2014 12:35:01 -0800 (PST) Received: (qmail 8083 invoked by uid 1000); 23 Jan 2014 20:35:00 -0000 Received: from nigel.brad.office.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 (CAMELLIA256-SHA encrypted) ESMTPSA; Thu, 23 Jan 2014 20:35:00 +0000 Message-ID: <52E17CF3.7030308@comodo.com> Date: Thu, 23 Jan 2014 20:34:59 +0000 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Adam Langley , Kurt Roeckx References: <20140123180713.GA31076@roeckx.be> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "tls@ietf.org" Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Jan 2014 20:35:05 -0000 On 23/01/14 18:14, Adam Langley wrote: > On Thu, Jan 23, 2014 at 1:07 PM, Kurt Roeckx wrote: >> I think the document starts from the assumption that there is >> someone in the middle that can alter the data, and then let the >> client do a downgrade. What is stopping this attacker from >> removing this scsv from the client hello? > > The Finished messages will detect any manipulation of the handshake. > > The key to the draft is that we believe that no servers will be > intolerant to the SCSV, and thus clients can always send it when doing > a fallback. Adam, I wonder if [1] is relevant here. Apparently some servers ignore the most significant byte of each cipher suite value sent by the client. Those servers would presumably interpret... TLS_FALLBACK_SCSV {0x56, 0x00} ...as... TLS_NULL_WITH_NULL_NULL {0x00, 0x00} I guess the chances of a server actually having TLS_NULL_WITH_NULL_NULL enabled and choosing to select it above all other mutually supported ciphers is pretty remote. But nonetheless, is there any reason why TLS_FALLBACK_SCSV couldn't have a value of, say, {0x00, 0xFE} ? [1] https://bugzilla.mozilla.org/show_bug.cgi?id=946147 -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From agl@google.com Thu Jan 23 12:43:52 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADCDB1A0225 for ; Thu, 23 Jan 2014 12:43:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.914 X-Spam-Level: X-Spam-Status: No, score=-1.914 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, RP_MATCHES_RCVD=-0.535, 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 RTcp12rc7Hge for ; Thu, 23 Jan 2014 12:43:50 -0800 (PST) Received: from mail-oa0-x233.google.com (mail-oa0-x233.google.com [IPv6:2607:f8b0:4003:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 012BF1A021C for ; Thu, 23 Jan 2014 12:43:49 -0800 (PST) Received: by mail-oa0-f51.google.com with SMTP id h16so2798822oag.10 for ; Thu, 23 Jan 2014 12:43:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=xR5XH7B7nFtFkpN9UPB5NDk2B1jK8GE8lNu75bMS1fQ=; b=Y4Dxo5/TrbOuL2XO7bLyKPbk0Nmn5XvXOR5d5DZ2rykxrqUWR2+QMnpk4LiY7966CS rrLGlGgDsTIKMHOhAXnT2Xsrc7NlDtwhNL6BBdoqWsEClhHDeColwe+S+SzL+OMvl676 W0LizVwyNpnsrBlL5mDuNkNUNy7N4E6mtWwfKDG+XbtlzE0fgaFi7cbMCZXqw7b4Hv8C J2o2d6rIxuh3P8CHTqbBL98C/pwQ/lC77b8K+h6dL1YWQKqQot/Mcbl1oS8HkKj0jjaK 67yNRrvCaXYthWQYSqsYVYqKWePfjY8J9RCU11xHI/YiQRk6FERy9/7DH4HPCMfRWGCT 06hQ== 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=xR5XH7B7nFtFkpN9UPB5NDk2B1jK8GE8lNu75bMS1fQ=; b=fcjRIdskXLlaqbMp5JUMWzXU4EOgQCRuZEPuEEnyokLyUnVUB/WJMsiQVTr0+DCkpO /EdKz1QMU0t3Rp97CPjTnA62Gqo0/7jeWfJHqbeGlNm46ZbhOfo7MAU8mdysDiR86zq7 l4uh+h3bYyFyHHoEx4F80X1dmxx/+eccMFfhCnm8Mz7U1btaKep5z0KH/NDTCrWD6uIX CxuaASfJHX5gKNy8KrjB/6xr2aWHRffF1rBGDw8h9P+zmUzw2NQKHeR5G/afVGBN3vMA PWLsxcYxsCMObPelg58GtKMzNUJGFC29+JXuFN6qa5kbzDf8dNXryte6ggSkQo8ypQx3 P8Pg== X-Gm-Message-State: ALoCoQl81Jzv1PrhjLT+J67/lEhjKr12y6y0cu7t9PkBNaYMxOkPi+h6nNow/dKwaJBzYa0JInA+e9F3OzR4SI46TR7JwkvizPTQgWS2nkLMMoBvyucD6cbmKlfvaFBS0kb5C1aBx4KxMf8uuAryio5M0F/boV/gw/Eo0UJTxbIhaXuIxm/zw0wGDby/WdA747+eizgX51x5 X-Received: by 10.182.158.71 with SMTP id ws7mr8742250obb.6.1390509828903; Thu, 23 Jan 2014 12:43:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.79.105 with HTTP; Thu, 23 Jan 2014 12:43:28 -0800 (PST) In-Reply-To: <52E17CF3.7030308@comodo.com> References: <20140123180713.GA31076@roeckx.be> <52E17CF3.7030308@comodo.com> From: Adam Langley Date: Thu, 23 Jan 2014 15:43:28 -0500 Message-ID: To: Rob Stradling Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Jan 2014 20:43:52 -0000 > I guess the chances of a server actually having TLS_NULL_WITH_NULL_NULL > enabled and choosing to select it above all other mutually supported ciphers > is pretty remote. But nonetheless, is there any reason why > TLS_FALLBACK_SCSV couldn't have a value of, say, {0x00, 0xFE} ? Has anything ever implemented TLS_NULL_WITH_NULL_NULL? Either way, it's not a big problem to change the SCSV value if need be, although I don't believe that servers mistaking it for TLS_NULL_WITH_NULL_NULL will be an issue. Additionally, the value is added at the end of the list in practice. Cheers AGL From cloos@jhcloos.com Thu Jan 23 12:44:48 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8284E1A021B for ; Thu, 23 Jan 2014 12:44:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, 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 E6ziC_QEHUYY for ; Thu, 23 Jan 2014 12:44:47 -0800 (PST) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9AE1A012B for ; Thu, 23 Jan 2014 12:44:47 -0800 (PST) Received: by ore.jhcloos.com (Postfix, from userid 10) id 249D91DFCD; Thu, 23 Jan 2014 20:44:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore13; t=1390509886; bh=qBVAyxp8DRtjDrbVfxGb6S5MVlaZA+NwzmbQB5Z511A=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=kjQ6OA8vQ0/7hlc4Kf+RFX+JCd4bepYGCiJ9z4p9HsOIXszhFTqmueBq0v4N9pztm KV2kJ5SrgdMTjrbMUXE2auRFzScTDzi5aJCctE8gL7SMeSkNYRncCKT5dsv9EBzHel znkpDsNWaRw89a81TfLLdBI8Wb4ww3Z9yHKv9sWWsxg== Received: by carbon.jhcloos.org (Postfix, from userid 500) id B4A1360027; Thu, 23 Jan 2014 20:38:17 +0000 (UTC) From: James Cloos To: tls@ietf.org In-Reply-To: <52E060D0.9030801@polarssl.org> ("Manuel =?iso-8859-1?Q?P=E9g?= =?iso-8859-1?Q?ouri=E9-Gonnard=22's?= message of "Thu, 23 Jan 2014 01:22:40 +0100") References: <87ob3456s1.fsf@latte.josefsson.org> <52E060D0.9030801@polarssl.org> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2013 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Thu, 23 Jan 2014 15:38:17 -0500 Message-ID: Lines: 14 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Hashcash: 1:30:140123:tls@ietf.org::ExFFZBxWeTA96Eho:00009V6wo X-Hashcash: 1:30:140123:mpg@polarssl.org::q4J7q1/LTzTnqpxj:fC4AI Cc: Manuel =?iso-8859-1?Q?P=E9gouri=E9-Gonnard?= Subject: Re: [TLS] Curve25519 in TLS and Additional Curves 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, 23 Jan 2014 20:44:48 -0000 >>>>> "MP" == Manuel Pégourié-Gonnard writes: MP> I have no objection to changing the byte ordering if nobody speaks MP> up for big-endian in the next few days. Internet-endian is the better choice. Coding is thusly is not a problem, and as the tls libs -- or their number-crunching libs -- gain support they can code to expect 'net- endian keys. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From rob.stradling@comodo.com Thu Jan 23 13:03:12 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 314221A012B for ; Thu, 23 Jan 2014 13:03:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.29 X-Spam-Level: X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, 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 BIRY_xD3-K_5 for ; Thu, 23 Jan 2014 13:03:10 -0800 (PST) Received: from ian.brad.office.comodo.net (eth5.brad-fw.brad.office.ccanet.co.uk [178.255.87.226]) by ietfa.amsl.com (Postfix) with ESMTP id 19F751A00CC for ; Thu, 23 Jan 2014 13:03:09 -0800 (PST) Received: (qmail 14116 invoked by uid 1000); 23 Jan 2014 21:03:08 -0000 Received: from nigel.brad.office.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 (CAMELLIA256-SHA encrypted) ESMTPSA; Thu, 23 Jan 2014 21:03:08 +0000 Message-ID: <52E1838C.2000808@comodo.com> Date: Thu, 23 Jan 2014 21:03:08 +0000 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Adam Langley References: <20140123180713.GA31076@roeckx.be> <52E17CF3.7030308@comodo.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "tls@ietf.org" Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Jan 2014 21:03:12 -0000 On 23/01/14 20:43, Adam Langley wrote: >> I guess the chances of a server actually having TLS_NULL_WITH_NULL_NULL >> enabled and choosing to select it above all other mutually supported ciphers >> is pretty remote. But nonetheless, is there any reason why >> TLS_FALLBACK_SCSV couldn't have a value of, say, {0x00, 0xFE} ? > > Has anything ever implemented TLS_NULL_WITH_NULL_NULL? A quick Google search suggests Yes. > Either way, it's not a big problem to change the SCSV value if need > be, although I don't believe that servers mistaking it for > TLS_NULL_WITH_NULL_NULL will be an issue. OK. > Additionally, the value is added at the end of the list in practice. How about stating this "in practice" behaviour as a MUST or SHOULD requirement in the draft? -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From rransom.8774@gmail.com Thu Jan 23 13:37:20 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 910A41A0140 for ; Thu, 23 Jan 2014 13:37:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.45 X-Spam-Level: X-Spam-Status: No, score=-1.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NhArbNXxVrQ6 for ; Thu, 23 Jan 2014 13:37:19 -0800 (PST) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8C01A00C9 for ; Thu, 23 Jan 2014 13:37:19 -0800 (PST) Received: by mail-qa0-f54.google.com with SMTP id i13so2957038qae.27 for ; Thu, 23 Jan 2014 13:37:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=rPuZ9wnckyRwANwEOatw4K67GZpSq6ydtctbcqBaqhE=; b=06a9worltmaHzLbxpa39MNhUejuo3RDkmTmY3yU1KmWNSbnkncxa5iTURiqP5AY9k0 uiuOUQf4zkI6KK6ly7mFWpkFF8jbG3X8mCj946ggA00q+C8D8PH/U5+63AO5cmAGHlDd pyqurMlJKJK2nKiuyCQOOU/MqJ8/MIwSdq5zlvuDcvt19OdZillx/gBsmN8N/yzuFVJm RUYN2i0M/7wrGECG1cEm/tKjoqW+G1kvF/a4z/5EWSL3i4GwltZwovdIeobhkQXrAfIY d640AZoEZF3CvBQhNeHNmW7NMq29bTNA9qfgK0A1zDow7lKHn7sFvg8zMXN3c1zRIvXV vKlg== MIME-Version: 1.0 X-Received: by 10.224.46.8 with SMTP id h8mr15397796qaf.49.1390513038172; Thu, 23 Jan 2014 13:37:18 -0800 (PST) Received: by 10.229.181.132 with HTTP; Thu, 23 Jan 2014 13:37:18 -0800 (PST) In-Reply-To: References: <87ob3456s1.fsf@latte.josefsson.org> <52E060D0.9030801@polarssl.org> <52E0E241.40406@polarssl.org> Date: Thu, 23 Jan 2014 13:37:18 -0800 Message-ID: From: Robert Ransom To: =?UTF-8?Q?Manuel_P=C3=A9gouri=C3=A9=2DGonnard?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] Curve25519 in TLS and Additional Curves 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, 23 Jan 2014 21:37:20 -0000 On 1/23/14, Robert Ransom wrote: > On 1/23/14, Manuel P=C3=A9gouri=C3=A9-Gonnard wrote: >> On 23/01/2014 02:17, Robert Ransom wrote: >>> * If you do not add a leading point-format byte, there is no reason to >>> specify the meaning of the high bit in this document. If you do add a >>> leading byte, you will have to choose in this document whether the >>> sign bit is for the Edwards-form x coordinate or the Montgomery-form y >>> coordinate. >>> >> Or we could add a leading byte now and say that the meaning of the msb i= s >> not >> defined yet an reserved for future use (which is what you suggest anyway= , >> IIUC). >> Then a future document could update the meaning of this leading byte. > > I think that's easiest (provided that current implementations also > accept 64-byte points and discard the second half; see below). On further thought, there is a major technical benefit to sending (either all of or a sign bit for) the Edwards-form x coordinate rather than the Montgomery-form y coordinate. Denoting the Montgomery-form point as (u, v) and the Edwards-form point as (x, y), the isomorphism from Montgomery form to Edwards form computes x =3D 2 u/v, which is undefined for the point of order 2 (Montgomery (0, 0)). I think that issue, combined with the fact that implementations which use the sign bit will almost certainly use Edwards form internally, should rule out any use of a Montgomery-form y coordinate in any current or future protocol. Since Curve25519's coordinate field order is congruent to 5 mod 8, there is no notion of =E2=80=98principal square root=E2=80=99, and thus no = plausible alternative to using the least significant bit of a coordinate as its sign bit. So there is only one likely choice of sign bit for Curve25519 group elements, and that is the LSB of the Edwards-form x coordinate. Now that I'm not worried about what will eventually be chosen as the sign bit, the only reason I can see to use a leading magic byte in the point format is to distinguish =E2=80=98the sender did not compute the sign bit of this point=E2=80=99 from =E2=80=98the sender computed the sign bit o= f this point, and it is 0=E2=80=99. I have previously suggested that distinguishi= ng those cases could be useful, but now I think mitigation of implementation fingerprinting is more important -- I see no reason to advertise whether an implementation computes the sign bit of its group elements or not, even if an attacker could infer that piece of information after a series of connections. Robert Ransom From agl@google.com Thu Jan 23 15:48:41 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 815FC1A0467 for ; Thu, 23 Jan 2014 15:48:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.914 X-Spam-Level: X-Spam-Status: No, score=-1.914 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, RP_MATCHES_RCVD=-0.535, 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 JP_9tZsnmeB9 for ; Thu, 23 Jan 2014 15:48:40 -0800 (PST) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 34A5D1A0449 for ; Thu, 23 Jan 2014 15:48:40 -0800 (PST) Received: by mail-ob0-f175.google.com with SMTP id wn1so2836822obc.6 for ; Thu, 23 Jan 2014 15:48:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=vKXmXmAIKjRHRopfr7xKMvsl1xZH2L/+U62Hf+2DU08=; b=HNP5YtjkoWIudxDAoBMZgymkLlxQ71ktJpeZ8PIL5YGc3F8eCLvXIIE4tWSdkA3285 4cfLB8ZaWSJeRztzW2KwkWlGEz8px18cE86Y3q6oNJEA6aM/3p4Vgr9IdrIjALeJjtie mrTos/aWDGI0ldufUmV+Phq62p9kGppboukS1BPVag8sPBD+iwEGmeigQgkw6QeQtamK +aAutykcr3kIoTaBPJx28CicchmVfV5zbiSUcHl6TGXcdeNR1Q6jEyyISS3ouO9p8Ldf GHDH/I8flxW/eF6c4in9mRjy0F7cWzpXttqkBdIAX+npx1NHkTpxWWh2dGNia5HoKFbD XOSg== 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=vKXmXmAIKjRHRopfr7xKMvsl1xZH2L/+U62Hf+2DU08=; b=TWWwJ9ll+wU2bJe9wPmYXC1IEzUmWjTmLxyIuFUGiIe+WYSOpWQ1J+lSSNs5tVSqDD us2jmkHihFJ3VBBhdT/MVwsWeNLUZV8thNkEB+AEEKorO4noQ8K9z+dwHeC31Y/zbIIP +zyQsqD0fQspyC5qKmps2v22LUvi+QXGCxevpy7VCxJ/xVr74yVn0tNbzlwM5NlzWdZv 575xdkER8FlaoH7qx17qspfld/72JsxgwAiB0ZD5fTUvQv6vq3JQTd5G8NxUjrB/us1z 6+k1hxwqvE21e/pXM2mt5SD8/NI/MMTyqgP/vqCLgvshOZbaJ7BHz54ckqKm+nTW8GMr MOZw== X-Gm-Message-State: ALoCoQmAGbJhEgMu1/OvUN1KFHoPVnee3nYJ4kaYqHmn1f3T46X4Wa5jM93Qjtor0uIj5rku6UZUa+UCWGsBYtoC5E+eBINwxIuurt1y9Ebwp3Ix3DBelBy3Onn/yXiMYwdcAgyTAiWVLR1yn4bnOkeA0/9Zd1SvtIiXS48rZKkqeC0nq7r7NKrfhPky+hbSoXC2xcVL4EmA X-Received: by 10.182.102.7 with SMTP id fk7mr9536458obb.28.1390520919120; Thu, 23 Jan 2014 15:48:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.79.105 with HTTP; Thu, 23 Jan 2014 15:48:19 -0800 (PST) In-Reply-To: <52E1838C.2000808@comodo.com> References: <20140123180713.GA31076@roeckx.be> <52E17CF3.7030308@comodo.com> <52E1838C.2000808@comodo.com> From: Adam Langley Date: Thu, 23 Jan 2014 18:48:19 -0500 Message-ID: To: Rob Stradling , Bodo Moeller Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Jan 2014 23:48:41 -0000 On Thu, Jan 23, 2014 at 4:03 PM, Rob Stradling wrote: > How about stating this "in practice" behaviour as a MUST or SHOULD > requirement in the draft? I don't have the XML for this one, but, if Bodo is around, I think that makes sense. Cheers AGL From mike-list@pobox.com Thu Jan 23 16:59:42 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 342DA1A01C3 for ; Thu, 23 Jan 2014 16:59:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 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_NONE=-0.0001, RP_MATCHES_RCVD=-0.535, 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 QBH9qIoj8wld for ; Thu, 23 Jan 2014 16:59:40 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4691A012B for ; Thu, 23 Jan 2014 16:59:40 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id C8907F657; Thu, 23 Jan 2014 19:59:49 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=BMvW71lnk/0X 0eudb01IJNmmo0w=; b=bD01GdueRGcwrAN4vVBVyp6cTGYmYS62fRiicdk5T8DY fTocvqHpq6R0FMgXY7GkaZT/R1A968zAH8Oa5yPOp79BujPMX0NMi9s0hmp4aIt+ AE2NeOMdsRdg237nyUzdRWWeidxjdHTKsy5LGr82P4js23SDj46QCWNOoP+TjNw= 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=JqOgB1 l7reXcqkr+8OtA+pmMqqZt+0W1RD8tGNgbrW8L2/C7M7yYWmz1XLugESPIWdP1Tq OTDxgpngqQtCViFMaDVueS6bCOrR02a9KCzJfpQUd7GvM4PAjC+H2l5M/pqoaC+a 8AO4vBx0KS47diRUnbG8tmq/g5yroJje6tFD0= Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id BD5C5F656; Thu, 23 Jan 2014 19:59:49 -0500 (EST) Received: from iMac.local (unknown [24.234.153.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 854B1F655; Thu, 23 Jan 2014 19:59:47 -0500 (EST) Message-ID: <52E1BAF5.7090407@pobox.com> Date: Thu, 23 Jan 2014 16:59:33 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Adam Langley References: <20140123180713.GA31076@roeckx.be> <52E17CF3.7030308@comodo.com> <52E1838C.2000808@comodo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: D273A946-8492-11E3-AA02-873F0E5B5709-38729857!a-pb-sasl-quonix.pobox.com Cc: Bodo Moeller , "tls@ietf.org" Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Jan 2014 00:59:42 -0000 Adam Langley wrote: > On Thu, Jan 23, 2014 at 4:03 PM, Rob Stradling wrote: >> How about stating this "in practice" behaviour as a MUST or SHOULD >> requirement in the draft? > > I don't have the XML for this one, but, if Bodo is around, I think > that makes sense. TLS_FALLBACK_SCSV would be our second SCSV so far, maybe we'll need more of these at some point. Only one of them can be last in the cipher suite list though, so perhaps they SHOULD be placed after all of the 'real' cipher suites, but not at a fixed location. Mike From martin.thomson@gmail.com Thu Jan 23 20:46:14 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2001A0094 for ; Thu, 23 Jan 2014 20:46:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79kLLEQ40V_h for ; Thu, 23 Jan 2014 20:46:13 -0800 (PST) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id AF7171A0051 for ; Thu, 23 Jan 2014 20:46:12 -0800 (PST) Received: by mail-wg0-f53.google.com with SMTP id y10so2519871wgg.32 for ; Thu, 23 Jan 2014 20:46:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zQC538e28mfRdPkpA7SjAsp+CoMjr32nIqMxjOIIH6k=; b=fQzYTyrzIhj3l4x5dRcCt6tECMpKqKgAhdz9kgm7nUTQjA5Aw7Ew2AZ+fCW8JY7SLP 6NXcMcpTO47X+zIHVbUIeWlPKIacr23sIeB+pjjJDbcm4/hy33ArjMXMkuk9h6ABlLIG 24Yz1Il2o2nJmsAcGvGfS9z3Ss/0EY5dr08h/sMiXtHFgiFR6keGyoiPXxMVMe2A/Bqf bq+xoG9FzYh7qVN3OsubHWJ+P/WUljunuysCcx4qzlO56rhb/i63Rr1CUbEy+ogiJOF/ lWlW7GYfviW8VJv429JWGoTRXBSCx22YgbY7T5mKpQLxQ/nXCzZm60vVmGYwQcG8lIBD A+AA== MIME-Version: 1.0 X-Received: by 10.194.119.168 with SMTP id kv8mr9066004wjb.41.1390538771305; Thu, 23 Jan 2014 20:46:11 -0800 (PST) Received: by 10.227.105.132 with HTTP; Thu, 23 Jan 2014 20:46:11 -0800 (PST) In-Reply-To: References: Date: Fri, 24 Jan 2014 05:46:11 +0100 Message-ID: From: Martin Thomson To: Adam Langley Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Jan 2014 04:46:14 -0000 On 23 January 2014 18:57, Adam Langley wrote: > 0 currently because I don't know whether it'll work in the real world. > Ask me again in 10 weeks. That's probably a good reason to block publication, but not WG adoption. The good thing is that we rarely publish anything in less than 10 weeks, so you'll have plenty of time to work out if this is viable in practice. I'm +1 on adoption. From SRS0=sQdR=W6=acm.org=bmoeller@srs.kundenserver.de Fri Jan 24 02:05:59 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9C01A0222 for ; Fri, 24 Jan 2014 02:05:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.464 X-Spam-Level: X-Spam-Status: No, score=-1.464 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535, 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 YXYl5ahWF-vO for ; Fri, 24 Jan 2014 02:05:57 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by ietfa.amsl.com (Postfix) with ESMTP id 6BABD1A0253 for ; Fri, 24 Jan 2014 02:05:52 -0800 (PST) Received: from mail-ob0-f173.google.com (mail-ob0-f173.google.com [209.85.214.173]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0La2aD-1VSJbU1pSX-00mAOe; Fri, 24 Jan 2014 11:05:50 +0100 Received: by mail-ob0-f173.google.com with SMTP id vb8so3405911obc.32 for ; Fri, 24 Jan 2014 02:05:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=YqLwmv2LIwBzWTYTpbyk0niAkANqMKN7uyD3ldvJ8Yk=; b=aP/FpFlstPMPRwMMeo4puTX86EInKfSp4P+BwR/AJEJ0awOGnonbTebF89/8uwefxa 9VK4DAhAiqcB2S1joAmTz+/hVBGIgkfaTLUizS1eh/5c63MNUG5YU1uS0mxFPGn50qNZ EDJeJD/9w/376+boJhUPw4Jc/Neq3DmXgj4Vf6Z0rdxycIljcYvuCfWd0/4KO7d1EqHd lOirEdy304qISXUQuf776iNWiExOgs0HE/BTN542XNndY8LJO1PNJ5jzNJULMUWuajV+ /86za6VFz8waAB7lO5RFuO80QuHZk590r7vCD7C/vhCmSh4HvSi8IuhO/NPBig2TonaI iMwA== MIME-Version: 1.0 X-Received: by 10.60.99.8 with SMTP id em8mr9234181oeb.8.1390557946621; Fri, 24 Jan 2014 02:05:46 -0800 (PST) Received: by 10.60.170.239 with HTTP; Fri, 24 Jan 2014 02:05:46 -0800 (PST) In-Reply-To: References: Date: Fri, 24 Jan 2014 11:05:46 +0100 Message-ID: From: Bodo Moeller To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=047d7b33cad272b68f04f0b48043 X-Provags-ID: V02:K0:o3qL8Qj9uw8fxEMv82ePC4+Tl2+8qkjqvCB2RICXwu4 dUcsT5t0Md2tXWLqTF7yrt2TgrYls6q3NViehtWkWs6Nk5Rkje GR0agJxpdYCrzk7pDDQXtExAgNcjTqtH176ZQji+5M9toFVCEr XwATH/Mnb9ZDTGFOzY4rcH/XUf5qg/jPXdztN6Ay1RTKEr13+D 4R1bmrJ2pysza9yVqPa6dyQIDrR+WbtmF2jhzD0Ng67+Yj4P89 CNuSTz0oEcJB+kyza3CXazYICga9tuPsFw9l1SIKR1pzqcUN2G 3CCqMxtFoIgo7aOYPuX2+bkam6G8oQw6YNRSjU9DsqugLHlCrQ eXUlp8iULQnvNgJyepSb0CLp1avuMuqceOZH0pvSCo23PBLzca Agafg9JkaAL1Dll6+IIHOZYKg9deY02GjKszUtM6BiocdSbcVw LPtOC Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Jan 2014 10:29:39 -0000 --047d7b33cad272b68f04f0b48043 Content-Type: text/plain; charset=ISO-8859-1 Adam Langley: > 0 currently because I don't know whether it'll work in the real world. > Ask me again in 10 weeks. This isn't a working group Last Call: this is solely about adoption by the working group, still as a working document. I agree that we shouldn't aim to do a Last Call before we have sufficient practical experience with the specification, but I also want to avoid unnecessary delays (and maybe we can even get additional practical experience earlier if this is a working group document). Kurt Roeckx: I think the document starts from the assumption that there is > someone in the middle that can alter the data, and then let the > client do a downgrade. What is stopping this attacker from > removing this scsv from the client hello? Note that the downgrade attack countered by this specification isn't one in which the attacker modifies the protocol version sent by any of the legitimate protocol participants: that kind of attack would be stopped by existing integrity checks, just like removing the SCSV from the Client Hello would. Instead, it's about attacks in which the attacker intentionally lets a first handshake fail in order to get the client to fall back to an earlier protocol version. Rob Stradling: > [...] the value is added at the end of the list in practice. > > How about stating this "in practice" behaviour as a MUST or SHOULD > requirement in the draft? > Right, it's a good idea to include a note about this in the specification, so that client implementations will avoid that potential problem. However, I think saying that this particular SCSV should go last would be wrong, because it unnecessarily and unreasonably restricts other specifications -- this isn't the only SCSV ever, and when sending multiple SCSVs in ClientHello.cipher_suites, there's no reason why this particular one would have to go last. I also don't agree with a "MUST": who knows what other creative uses ClientHello.cipher_suites may find in the future? Also note the pitfall here: We don't want any server-side implementations start to make assumptions about where in the cipher suite list this SCSV could appear (e.g., only honoring it if it indeed comes last, or only honoring if it comes after all the "real" cipher suites); so we'll also have to include a note about this aspect, telling servers to look at every single item in ClientHello.cipher_suites. I think that sending SCSVs last is really a corollary of the existing definition of ClientHello.cipher_suites: These appear in order of decreasing preference; and an SCSV, by definition, is a cipher suite that you *don't* want to negotiate (thus, it has lower preference than any real cipher suite). So we'll include reminders about this, rather than imposing new requirements or recommendations. Adam Langley: I don't have the XML for this one, Well, search your email for draft-bmoeller-tls-downgrade-scsv-01.xml :-) (Also, the XML source is publicly available for download from the usual location: http://tools.ietf.org/id/draft-bmoeller-tls-downgrade-scsv-01.xml) I'm fine with making the edits, though. Bodo --047d7b33cad272b68f04f0b48043 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Adam Langley:
=A0
0 currently becaus= e I don't know whether it'll work in the real world.
Ask me a= gain in 10 weeks.

This isn't a w= orking group Last Call: this is solely about adoption by the working group,= still as a working document. =A0I agree that we shouldn't aim to do a = Last Call before we have sufficient practical experience with the specifica= tion, but I also want to avoid unnecessary delays (and maybe we can even ge= t additional practical experience earlier if this is a working group docume= nt).


Kurt Roeckx:

I think the doc= ument starts from the assumption that there is
someone in the middle that can al= ter the data, and then let the
client d= o a downgrade. =A0What is stopping this attacker from
removing this scsv from th= e client hello?

Not= e that the downgrade attack countered by this specification isn't one i= n which the attacker modifies the protocol version sent by any of the legit= imate protocol participants: that kind of attack would be stopped by existi= ng integrity checks, just like removing the SCSV from the Client Hello woul= d. =A0Instead, it's about attacks in which the attacker intentionally l= ets a first handshake fail in order to get the client to fall back to an ea= rlier protocol version.


Rob Stradling:


[...] the value is added at the end of the list in pra= ctice.
How about stati= ng this "in practice" behaviour as a MUST or SHOULD requirement i= n the draft?
=A0

Right, it's = a good idea to include a note about this in the specification, so that clie= nt implementations will avoid that potential problem. =A0However, I think s= aying that this particular SCSV should go last would be wrong, because it u= nnecessarily and unreasonably restricts other specifications -- this isn= 9;t the only SCSV ever, and when sending multiple SCSVs in ClientHello.ciph= er_suites, there's no reason why this particular one would have to go l= ast. =A0I also don't agree with a "MUST": who knows what othe= r creative uses ClientHello.cipher_suites may find in the future?

Also note the pitfall here: We don't want any serve= r-side implementations start to make assumptions about where in the cipher = suite list this SCSV could appear (e.g., only honoring it if it indeed come= s last, or only honoring if it comes after all the "real" cipher = suites); so we'll also have to include a note about this aspect, tellin= g servers to look at every single item in ClientHello.cipher_suites.

I think that sending SCSVs last is really a corollary o= f the existing definition of ClientHello.cipher_suites: These appear in ord= er of decreasing preference; and an SCSV, by definition, is a cipher suite = that you *don't* want to negotiate (thus, it has lower preference than = any real cipher suite). =A0So we'll include reminders about this, rathe= r than imposing new requirements or recommendations.


Adam Langley:

I don't hav= e the XML for this one,

Well, search= your email for=A0draft-bmoeller-tls-downgrade-scsv-01.xml :-) =A0(Also, th= e XML source is publicly available for download from the usual location: http://tools.ietf.org/id/draft-bmoeller-tls-downgrade-scsv-01.xml) =A0= I'm fine with making the edits, though.

Bodo
--047d7b33cad272b68f04f0b48043-- From mpg@polarssl.org Fri Jan 24 10:49:49 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8A61A0028 for ; Fri, 24 Jan 2014 10:49:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.394 X-Spam-Level: X-Spam-Status: No, score=0.394 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0nP2HVTtGCR for ; Fri, 24 Jan 2014 10:49:48 -0800 (PST) Received: from vps2.brainspark.nl (vps2.brainspark.nl [141.138.204.106]) by ietfa.amsl.com (Postfix) with ESMTP id B533A1A0015 for ; Fri, 24 Jan 2014 10:49:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:CC:To:MIME-Version:From:Date:Message-ID; bh=S7vtABMMf7tII60+6KKobRbqZc+5/3q+TKjQbWhQ6ws=; b=N9MERGZduaZXK4lzYdcGivQsSEESosvNGrqlIQdVaJVsmNNgLGtYy181x1rWzXODo/nA6ZFkEpfGSU1We1bOebgxIBy04H/Qmps55209sg1NeKg+GCSkhC+CL+17PehOupU2yCt7XcN2Kq0mhfi9olUjPRhD1xPD4Ep/GsCRtBA=; Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.brainspark.nl with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1W6liB-0005mF-4H; Fri, 24 Jan 2014 19:42:39 +0100 Message-ID: <52E2B5C7.5040600@polarssl.org> Date: Fri, 24 Jan 2014 19:49:43 +0100 From: =?UTF-8?B?TWFudWVsIFDDqWdvdXJpw6ktR29ubmFyZA==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.1.1 MIME-Version: 1.0 To: Robert Ransom References: <87ob3456s1.fsf@latte.josefsson.org> <52E060D0.9030801@polarssl.org> <52E0E241.40406@polarssl.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 88.165.216.11 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.brainspark.nl) Cc: tls@ietf.org Subject: Re: [TLS] Curve25519 in TLS and Additional Curves in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 18:49:49 -0000 On 23/01/2014 20:45, Robert Ransom wrote: > So, the only implementation I know of that does not ignore the MSB is > a horribly slow one that should never be used in production -- I would > not be surprised if it's slower than a typical implementation of the > BND curves. > Good to know. It really pleads for recommending to ignore the MSB even if we don't need it later. > I still think that avoiding implementation fingerprinting would > justify “implementations SHOULD mask off the high bit”. > I agree. > Remember that what Dr. Bernstein refers to as â€public key validation’ > in the Curve25519 paper is considerably more expensive than one > bitwise AND: > [...] Sure.. Another point I thought about in the meantime is that the security consequences of not doing that check are minimal for Curve25519 (implementation fingerprinting) as opposed to short Weierstrass curves with (x, y) coordinate (small subgroup attack). > If you add a leading byte as an extension hook *and* specify an > ECPointFormat value for the current â€Montgomery-form x’ point format, > current implementations can refuse to receive point formats which they > won't understand. Haha, I think I finally understood. You're referring to this paragraph of the draft, right? Since only one point format can be used with Curve25519, which is distinct from the formats used by short Weierstrass curves, the contents of the "Supported Point Formats" extension is irrelevant for this curve. Yes, if we add a leading byte, and we want to be able to use other formats (hence other leading bytes) with Curve25519 in TLS in the future, then this phrase should be removed and a new ECPointFormat value requested from IANA. > If you don't add a leading byte, I think the ECPoint length byte can > still be used as an adequate extension mechanism for future non-ECDH > protocols. > As long as there is no more than one future format mapping to the same length. Eg, is for some reason some people want to send > I agree, but future implementations should be allowed to send an > uncompressed second coordinate without breaking compatibility with > implementations of this protocol. What I'm suggesting is that (a) > current implementations send 32-byte points; (b) current > implementations accept both 32-byte and 64-byte point objects, and > ignore the second half of a 64-byte point. > That's an option too, but compared to a leading byte, it doesn't allow to define two different 64-byte point formats in the future, right? So maybe the leading byte (with ECPointFormat negociation) is the most future-proof way. Manuel. From mrex@sap.com Fri Jan 24 10:52:27 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5D31A00F4 for ; Fri, 24 Jan 2014 10:52:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 K6q6Omiuvx7g for ; Fri, 24 Jan 2014 10:52:25 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id C62C81A00C0 for ; Fri, 24 Jan 2014 10:52:24 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s0OIqMAl011179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 24 Jan 2014 19:52:22 +0100 (MET) In-Reply-To: To: Eric Rescorla Date: Fri, 24 Jan 2014 19:52:22 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140124185222.1FD4B1ABCA@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "tls@ietf.org" Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 18:52:27 -0000 Eric Rescorla wrote: > WG Members, > > This message is a call for acceptance of > http://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-01 > > As a TLS WG item. > > Please provide any comments on this action by Feb 7. -1 I'm strongly opposed to a scheme whose only purpose in life is to make TLS handshakes _fail_ based on bogus heuristics by the wrong communication peer. -Martin From benl@google.com Fri Jan 24 10:54:15 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21B461A0108 for ; Fri, 24 Jan 2014 10:54:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.914 X-Spam-Level: X-Spam-Status: No, score=-1.914 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, RP_MATCHES_RCVD=-0.535, 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 uXswG5rTLZmx for ; Fri, 24 Jan 2014 10:54:13 -0800 (PST) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id BC49D1A00A9 for ; Fri, 24 Jan 2014 10:54:13 -0800 (PST) Received: by mail-ie0-f171.google.com with SMTP id as1so3315833iec.2 for ; Fri, 24 Jan 2014 10:54:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MF+fvr/doeCnUPNcND4DNQOA1YvIdB49Qdx1Qw5sBJA=; b=iriQhlte41Pm2YGEmrh/clkpCQyvecsAsTF7ABfxKILw7HS9/yJYfoSNvqmxSYjRp6 BoTFgPpWxyoXs5NMuES0bNaTSLfo23BGD4XhZHg/7BaZe0peRdVJVPSIaS9Bqp4MRoE6 fUS3Bmpa66yePyzPp93jqAu25yn1qDdlTmvx8zWxWkPeagT5l5X+zD8I2CwYlQb76E+a C1AVvtCMgbfbcX7IzMAXWMJEMNqW5OAnpnWEXIosbaHKrt96laShCkm/JrFugsDRJ8oG F9ijKUzsOTY2fsmpBYj5EMTbqMvGTAeDJ8Tc5LAF2QMljmUW2MDRAt9VIo++sq3ERa/0 Z2fA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=MF+fvr/doeCnUPNcND4DNQOA1YvIdB49Qdx1Qw5sBJA=; b=PqpffnnJqe/8kfUAWLM4m7Y7cC8kNx3EpyTDBWTjCCPw5xao0CGxqgIWoq7ihY+L6O B4hzqLEMVDbjJzvpPZnZ3GFcj/0/amOB6iRw9z70iaG3dPDtdOPFtrSnm+Xln0aYtpW7 NS0Gg1prnnpXIsawC8l1GDlxDHJPLqwJdqP8YQlxuxag1pQcipLvzea/1wNKkRdpThBl JXxHygFjdDY5RfafDbymq5aDtsE8Wydmk07jUVfquFKc+rY4F7awx6TaNbfRiBubaUz2 xUllVUaGkQ5Z0ykStD82h640M+y8ug7IYZCJjMb5bDvmdt/vM5tN6BuAatyUNDN9DaBc FBlA== X-Gm-Message-State: ALoCoQnPf5LDrN3TxWQ1htzSHua4Md1wsE6iQ6XUptgDWVDWpsaFM+9RSKJzVeq4v/OMgFdo0bi2QmYcGqyXjAQQPKdoLwphNPA0Wnrp/T0nQ5bwpYF6coxM6cCX1/irbuaQqTanZWgZdHE3dvVC2SXO9FoXdEqjHE2+qzTR4L9b7tZO4fgudfSClwjyUdOs5UR5Ilwvb5ED MIME-Version: 1.0 X-Received: by 10.42.156.72 with SMTP id y8mr11955407icw.25.1390589652426; Fri, 24 Jan 2014 10:54:12 -0800 (PST) Received: by 10.64.230.140 with HTTP; Fri, 24 Jan 2014 10:54:12 -0800 (PST) In-Reply-To: <20140124185222.1FD4B1ABCA@ld9781.wdf.sap.corp> References: <20140124185222.1FD4B1ABCA@ld9781.wdf.sap.corp> Date: Fri, 24 Jan 2014 18:54:12 +0000 Message-ID: From: Ben Laurie To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Jan 2014 18:54:15 -0000 On 24 January 2014 18:52, Martin Rex wrote: > Eric Rescorla wrote: >> WG Members, >> >> This message is a call for acceptance of >> http://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-01 >> >> As a TLS WG item. >> >> Please provide any comments on this action by Feb 7. > > -1 > > I'm strongly opposed to a scheme whose only purpose in life is > to make TLS handshakes _fail_ based on bogus heuristics by the > wrong communication peer. Which one is the wrong one? From kurt@roeckx.be Fri Jan 24 10:58:33 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 307C41A00C4 for ; Fri, 24 Jan 2014 10:58:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YcUW4j-M6gTq for ; Fri, 24 Jan 2014 10:58:31 -0800 (PST) Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) by ietfa.amsl.com (Postfix) with ESMTP id 49C111A00A9 for ; Fri, 24 Jan 2014 10:58:31 -0800 (PST) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 3D9181C215C; Fri, 24 Jan 2014 19:58:29 +0100 (CET) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 020161FE019C; Fri, 24 Jan 2014 19:58:28 +0100 (CET) Date: Fri, 24 Jan 2014 19:58:28 +0100 From: Kurt Roeckx To: Martin Rex Message-ID: <20140124185828.GA617@roeckx.be> References: <20140124185222.1FD4B1ABCA@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140124185222.1FD4B1ABCA@ld9781.wdf.sap.corp> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "tls@ietf.org" Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Jan 2014 18:58:33 -0000 On Fri, Jan 24, 2014 at 07:52:22PM +0100, Martin Rex wrote: > Eric Rescorla wrote: > > WG Members, > > > > This message is a call for acceptance of > > http://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-01 > > > > As a TLS WG item. > > > > Please provide any comments on this action by Feb 7. > > -1 > > I'm strongly opposed to a scheme whose only purpose in life is > to make TLS handshakes _fail_ based on bogus heuristics by the > wrong communication peer. I'm not sure I understand you. Which heuristics do you mean? The client is telling the server to drop the connection (under some conditions). The client is in control of sending this or not. Kurt From mpg@polarssl.org Fri Jan 24 11:04:30 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFCFE1A009A for ; Fri, 24 Jan 2014 11:04:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.394 X-Spam-Level: X-Spam-Status: No, score=0.394 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d_vEHblNObrz for ; Fri, 24 Jan 2014 11:04:30 -0800 (PST) Received: from vps2.brainspark.nl (vps2.brainspark.nl [141.138.204.106]) by ietfa.amsl.com (Postfix) with ESMTP id DFF091A0047 for ; Fri, 24 Jan 2014 11:04:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:CC:To:MIME-Version:From:Date:Message-ID; bh=w5X54VA192Zs17VzkL0lmqKDWT/ri8k6UBDYH7yuaig=; b=Rd2DNlhuORw4a0Rv6U0V2eK/CXjpLA19aISImO10r0Z0RrEZkZexgtc34O6zdayzRKDnOIcBE+hfN9av4UpOpiACDMbkFxlNSx9JKz+vyXMZLvq8UyTaQOwXROtb2TOgxyOWtAXbxtBS4wGkTvjFyxj+tOfW+mhiQOuAKiTh0+U=; Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.brainspark.nl with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1W6lwM-0005on-Uj; Fri, 24 Jan 2014 19:57:19 +0100 Message-ID: <52E2B937.5080502@polarssl.org> Date: Fri, 24 Jan 2014 20:04:23 +0100 From: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.1.1 MIME-Version: 1.0 To: Robert Ransom , Nikos Mavrogiannopoulos References: <87ob3456s1.fsf@latte.josefsson.org> <1390466373.20176.8.camel@dhcp-2-127.brq.redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 88.165.216.11 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.brainspark.nl) Cc: Simon Josefsson , tls@ietf.org Subject: Re: [TLS] Curve25519 in TLS and Additional Curves in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 19:04:31 -0000 On 23/01/2014 19:33, Robert Ransom wrote: > On 1/23/14, Nikos Mavrogiannopoulos wrote: >> An Internet protocol is not typically designed based on the existing >> implementations limitations and they it is often expected to outlive >> them. Almost all IETF protocols use the big-endian format for >> transferring integers, and implementations of these protocols in have >> already ways to convert these numbers to the native endianess. > > *This* Internet protocol is motivated by the existing implementations > for Curve25519. What is the *technical benefit* of deliberately > breaking compatibility with the implementations which justify this > protocol's existence? > While I can see your point, I feel "breaking compatibility" is a bit of an overstatement. Swapping bytes when points are written/read is no difficult task and could be done in the TLS-specific portion of the code before passing the point from/to one of the existing implementations of Curve25519 arithmetic. Of course it does not invalidate your point that existing implementations are an important motivation for this draft, and that there is no technical benefit to big endian (if you don't count uniformity with other formats as technical), but I think it's worth noting that we're not discussing whether using the existing implementations will be *possible* but only *how easy* it will be. Manuel. From internet-drafts@ietf.org Fri Jan 24 11:19:25 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4E461A019D; Fri, 24 Jan 2014 11:19:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0m-L2mJn1c7; Fri, 24 Jan 2014 11:19:24 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4496E1A013F; Fri, 24 Jan 2014 11:19:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140124191924.18230.61462.idtracker@ietfa.amsl.com> Date: Fri, 24 Jan 2014 11:19:24 -0800 Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-applayerprotoneg-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 19:19:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Layer Security Working Group of= the IETF. Title : Transport Layer Security (TLS) Application Layer = Protocol Negotiation Extension Authors : Stephan Friedl Andrei Popov Adam Langley Emile Stephan Filename : draft-ietf-tls-applayerprotoneg-04.txt Pages : 8 Date : 2014-01-24 Abstract: This document describes a Transport Layer Security (TLS) extension for application layer protocol negotiation within the TLS handshake. For instances in which the TLS connection is established over a well known TCP/IP port not associated with the desired application layer protocol, this extension allows the application layer to negotiate which protocol will be used within the TLS connection. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-applayerprotoneg/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-applayerprotoneg-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From sfriedl@cisco.com Fri Jan 24 11:30:06 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 619721A00F4 for ; Fri, 24 Jan 2014 11:30:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.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 fbKp-NuYzTsj for ; Fri, 24 Jan 2014 11:30:04 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 7CDF81A00C0 for ; Fri, 24 Jan 2014 11:30:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=538; q=dns/txt; s=iport; t=1390591804; x=1391801404; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=wDsoTMKMhaPaN301ZwzggyZGgEEPaVW2S1hjTAViLhU=; b=e6xhlO1/92u0Y57cRYNnKEVGtDqjsRyGDultcDGXytfHfBoefTtGJWgZ pHLTqjjaKtdZyPjlynWfApCCB1oUtKDROCkiiCtHcsjlS3KNY91v8hdm2 DAdzXxW1eak3cCFO0x98k3imIPD90dPnb5yKPkFQurwQLmr0a+dDJYr12 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFABa+4lKtJV2Y/2dsb2JhbABagwyBDrw1gQ0WdIInAQQ6UQEqFEImAQQbh32cYKtvF45bg1yBFASqRYMtgio X-IronPort-AV: E=Sophos;i="4.95,714,1384300800"; d="scan'208";a="299574238" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 24 Jan 2014 19:30:03 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0OJU22s026692 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 24 Jan 2014 19:30:03 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.76]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Fri, 24 Jan 2014 13:30:02 -0600 From: "Stephan Friedl (sfriedl)" To: "tls@ietf.org" Thread-Topic: New Revision of draft-ietf-tls-applayerprotoneg posted Thread-Index: Ac8ZOaDLT9QGLaJzQguGBMZcvRiK5g== Date: Fri, 24 Jan 2014 19:30:02 +0000 Message-ID: <2AA4F2B7B0341A4CA4DAB10D4EDA0D7C2328AB80@xmb-aln-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.81.151] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [TLS] New Revision of draft-ietf-tls-applayerprotoneg posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Jan 2014 19:30:06 -0000 We have just posted a new revision of draft-ietf-tls-applayerprotoneg. This revision addresses comments received during the IETF LC, notably comme= nts from Alyssa Rowan and Yoav Nir and others concerning enriching the Secu= rity Considerations section to call out that the protocol selected is trans= mitted in the clear and to encourage protocol designers and implementers to= take this into consideration for scenarios where protocol leakage could le= ad to leaking personally identifiable information. Thanks, Stephan From rsalz@akamai.com Fri Jan 24 12:19:08 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33FCA1A016B for ; Fri, 24 Jan 2014 12:19:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.435 X-Spam-Level: X-Spam-Status: No, score=-4.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJ10Ie3mXuhP for ; Fri, 24 Jan 2014 12:19:04 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id B37DE1A012D for ; Fri, 24 Jan 2014 12:19:04 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 43397284E8; Fri, 24 Jan 2014 20:19:03 +0000 (GMT) Received: from prod-mail-relay02.akamai.com (prod-mail-relay02.akamai.com [172.17.50.21]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 1CFB7284E2; Fri, 24 Jan 2014 20:19:03 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub5.kendall.corp.akamai.com [172.27.105.21]) by prod-mail-relay02.akamai.com (Postfix) with ESMTP id 0936FFE055; Fri, 24 Jan 2014 20:19:03 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.92]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Fri, 24 Jan 2014 15:19:02 -0500 From: "Salz, Rich" To: =?iso-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= , Robert Ransom Date: Fri, 24 Jan 2014 15:19:01 -0500 Thread-Topic: [TLS] Curve25519 in TLS and Additional Curves in TLS Thread-Index: Ac8ZNx8XYOgwxHCuRpaN6ThOHCRoLQACavNg Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711EB9F2DB6@USMBX1.msg.corp.akamai.com> References: <87ob3456s1.fsf@latte.josefsson.org> <1390466373.20176.8.camel@dhcp-2-127.brq.redhat.com> <52E2B937.5080502@polarssl.org> In-Reply-To: <52E2B937.5080502@polarssl.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] Curve25519 in TLS and Additional Curves in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 20:19:08 -0000 > While I can see your point, I feel "breaking compatibility" is a bit of a= n overstatement. Swapping bytes when points are written/read is no difficul= t task and could be done in the TLS-specific portion of the code before pas= sing the point from/to one of the existing implementations of Curve25519 ar= ithmetic. Sure, and we could also use the existing ECC point structure and transmit 3= 2 bytes of zero as a fake y value. It's a slippery slope. =20 The main interest in using this curve is to use the existing implementation= s for their security and performance benefits and that there is a real bene= fit to being able to feed directly from the wire into implementations. On = the "other side" the only argument seems to be that this format is what all= other protocols do. So explain to me which "side" is following religious dogma? :) /r$ -- =20 Principal Security Engineer Akamai Technology Cambridge, MA From mpg@polarssl.org Fri Jan 24 12:32:57 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B951C1A0060 for ; Fri, 24 Jan 2014 12:32:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.394 X-Spam-Level: X-Spam-Status: No, score=0.394 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1eBc2lTZYrVZ for ; Fri, 24 Jan 2014 12:32:57 -0800 (PST) Received: from vps2.brainspark.nl (vps2.brainspark.nl [141.138.204.106]) by ietfa.amsl.com (Postfix) with ESMTP id A75891A004E for ; Fri, 24 Jan 2014 12:32:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=f1+MlSMBNFbU0ESspMvW30SNP3uX2wdx/sMQ+FHfEe4=; b=GyeVPIRWZy6p49HX2Fw7gCXA4Qofxtbfr2qOgYwrYnt3PJXwB34Nubw2RAl9ShdptAU+ZWt/Wws+USsLvf0I2rxDYTZSZ/l9p6tudAyDUuvJzpvQW3w2L8NtFA9NmVqnyn3wnoEG9VHwhhUPoo5/fT+VoTfEAL9EDVg0hwtRaN8=; Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.brainspark.nl with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1W6nK1-00060L-34 for tls@ietf.org; Fri, 24 Jan 2014 21:25:49 +0100 Message-ID: <52E2CDF5.1010904@polarssl.org> Date: Fri, 24 Jan 2014 21:32:53 +0100 From: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.1.1 MIME-Version: 1.0 To: tls@ietf.org References: <87ob3456s1.fsf@latte.josefsson.org> <1390466373.20176.8.camel@dhcp-2-127.brq.redhat.com> <52E2B937.5080502@polarssl.org> <2A0EFB9C05D0164E98F19BB0AF3708C711EB9F2DB6@USMBX1.msg.corp.akamai.com> In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711EB9F2DB6@USMBX1.msg.corp.akamai.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 88.165.216.11 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.brainspark.nl) Subject: Re: [TLS] Curve25519 in TLS and Additional Curves in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 20:32:57 -0000 On 24/01/2014 21:19, Salz, Rich wrote: > So explain to me which "side" is following religious dogma? :) > I don't think I ever accused you, or anyone else, of following a religious dogma in this discussion. But I remember writing: > I have no objection to changing the byte ordering if nobody speaks up for > big-endian in the next few days. As it happens, a few people spoke for big-endian, but it should be noted the above phrase has only an "if" clause, not an "if and only if" :) Manuel. From rsalz@akamai.com Fri Jan 24 12:34:48 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D221F1A00AB for ; Fri, 24 Jan 2014 12:34:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.435 X-Spam-Level: X-Spam-Status: No, score=-4.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ETYouMY_JNaW for ; Fri, 24 Jan 2014 12:34:47 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB571A004E for ; Fri, 24 Jan 2014 12:34:47 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 4F175284DD; Fri, 24 Jan 2014 20:34:46 +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 3BA52284D9; Fri, 24 Jan 2014 20:34:46 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub5.kendall.corp.akamai.com [172.27.105.21]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 285482027; Fri, 24 Jan 2014 20:34:46 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.92]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Fri, 24 Jan 2014 15:34:45 -0500 From: "Salz, Rich" To: =?iso-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= , "tls@ietf.org" Date: Fri, 24 Jan 2014 15:34:44 -0500 Thread-Topic: [TLS] Curve25519 in TLS and Additional Curves in TLS Thread-Index: Ac8ZQ3mxG9lGjFapR3iX9+K9Kg7TdgAACGsQ Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711EB9F2DD3@USMBX1.msg.corp.akamai.com> References: <87ob3456s1.fsf@latte.josefsson.org> <1390466373.20176.8.camel@dhcp-2-127.brq.redhat.com> <52E2B937.5080502@polarssl.org> <2A0EFB9C05D0164E98F19BB0AF3708C711EB9F2DB6@USMBX1.msg.corp.akamai.com> <52E2CDF5.1010904@polarssl.org> In-Reply-To: <52E2CDF5.1010904@polarssl.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] Curve25519 in TLS and Additional Curves in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 20:34:48 -0000 > I don't think I ever accused you, or anyone else, of following a religiou= s dogma in this discussion No, you never did and I'm sorry if I gave that impression. I should have r= emoved all names from the headers and sent it just to tls. /r$ -- =20 Principal Security Engineer Akamai Technology Cambridge, MA From mrex@sap.com Fri Jan 24 13:05:39 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9849F1A01F2 for ; Fri, 24 Jan 2014 13:05:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 gJy7JWv6CyfY for ; Fri, 24 Jan 2014 13:05:38 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id F01EA1A01EB for ; Fri, 24 Jan 2014 13:05:37 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s0OL5Y9R004247 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 24 Jan 2014 22:05:34 +0100 (MET) In-Reply-To: To: Ben Laurie Date: Fri, 24 Jan 2014 22:05:34 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140124210534.C77871ABCA@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "tls@ietf.org" Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 21:05:39 -0000 Ben Laurie wrote: [ Charset UTF-8 unsupported, converting... ] > On 24 January 2014 18:52, Martin Rex wrote: > > Eric Rescorla wrote: > >> WG Members, > >> > >> This message is a call for acceptance of > >> http://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-01 > >> > >> As a TLS WG item. > >> > >> Please provide any comments on this action by Feb 7. > > > > -1 > > > > I'm strongly opposed to a scheme whose only purpose in life is > > to make TLS handshakes _fail_ based on bogus heuristics by the > > wrong communication peer. > > Which one is the wrong one? The server is definitely the wrong peer to guess whether the client wants to continue or abort TLS handshake. -Martin From rransom.8774@gmail.com Fri Jan 24 13:18:02 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53EF91A01E6 for ; Fri, 24 Jan 2014 13:18:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.45 X-Spam-Level: X-Spam-Status: No, score=-1.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXZavIZAKiiK for ; Fri, 24 Jan 2014 13:18:01 -0800 (PST) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id DF5491A01CA for ; Fri, 24 Jan 2014 13:18:00 -0800 (PST) Received: by mail-qc0-f175.google.com with SMTP id x13so5057313qcv.6 for ; Fri, 24 Jan 2014 13:17:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=wdKGQm5eKebIAE/EUJKWBSzHWLHvD6qIPx1usI0YIqM=; b=SHyAgeLlHIAzRz6NzNL+x/6XGFCYVhoyjn5RT+Xnq7+CA49/nnlfPER4SO9LznrwoO 9zZqLxX+U3gUDEDm4C+Os+PoMC5AzPivbCL7M2uTEemsDE7HH0aLcXsHXr3SgsatzrED eJ1cxddgyPbpXT1Ynoj67m7CKoIoGKlK+8Pa4et7UKMbG5BPjP1veoau1SqmxjwCKVxy Q6lOuDzy7iMMQYnNhs9SCrtJtc8TV6D6t9DtKyJGt/mvyuvQTEvg27PuIXO4YUHFj/kj kEQOwd3s6fNhnHSdDyv8MebF/wdxr9nz3gY/BmCIlzz3xrcAOEffvFhhr7Ueok7GtVpH UwNw== MIME-Version: 1.0 X-Received: by 10.224.111.195 with SMTP id t3mr24162988qap.2.1390598279460; Fri, 24 Jan 2014 13:17:59 -0800 (PST) Received: by 10.229.181.132 with HTTP; Fri, 24 Jan 2014 13:17:59 -0800 (PST) In-Reply-To: <52E2B5C7.5040600@polarssl.org> References: <87ob3456s1.fsf@latte.josefsson.org> <52E060D0.9030801@polarssl.org> <52E0E241.40406@polarssl.org> <52E2B5C7.5040600@polarssl.org> Date: Fri, 24 Jan 2014 13:17:59 -0800 Message-ID: From: Robert Ransom To: =?UTF-8?Q?Manuel_P=C3=A9gouri=C3=A9=2DGonnard?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] Curve25519 in TLS and Additional Curves in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 21:18:02 -0000 On 1/24/14, Manuel P=C3=A9gouri=C3=A9-Gonnard wrote: > On 23/01/2014 20:45, Robert Ransom wrote: >> Remember that what Dr. Bernstein refers to as =E2=80=98public key valida= tion=E2=80=99 >> in the Curve25519 paper is considerably more expensive than one >> bitwise AND: >> [...] > > Sure.. Another point I thought about in the meantime is that the security > consequences of not doing that check are minimal for Curve25519 > (implementation > fingerprinting) as opposed to short Weierstrass curves with (x, y) > coordinate > (small subgroup attack). Yes. >> If you add a leading byte as an extension hook *and* specify an >> ECPointFormat value for the current =E2=80=98Montgomery-form x=E2=80=99 = point format, >> current implementations can refuse to receive point formats which they >> won't understand. > > Haha, I think I finally understood. You're referring to this paragraph of > the > draft, right? Yes, I am. > Since only one point format can be used with Curve25519, which is > distinct from the formats used by short Weierstrass curves, the > contents of the "Supported Point Formats" extension is irrelevant for > this curve. > > Yes, if we add a leading byte, and we want to be able to use other format= s > (hence other leading bytes) with Curve25519 in TLS in the future, then th= is > phrase should be removed and a new ECPointFormat value requested from IAN= A. Yes. >> If you don't add a leading byte, I think the ECPoint length byte can >> still be used as an adequate extension mechanism for future non-ECDH >> protocols. >> > As long as there is no more than one future format mapping to the same > length. > Eg, is for some reason some people want to send > >> I agree, but future implementations should be allowed to send an >> uncompressed second coordinate without breaking compatibility with >> implementations of this protocol. What I'm suggesting is that (a) >> current implementations send 32-byte points; (b) current >> implementations accept both 32-byte and 64-byte point objects, and >> ignore the second half of a 64-byte point. >> > That's an option too, but compared to a leading byte, it doesn't allow to > define > two different 64-byte point formats in the future, right? So maybe the > leading > byte (with ECPointFormat negociation) is the most future-proof way. Yes. (Even though I am now convinced that there is only one reasonable choice for the other coordinate for Curve25519.) Robert Ransom From dkg@fifthhorseman.net Fri Jan 24 13:26:39 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 078C81A013C for ; Fri, 24 Jan 2014 13:26:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKWE0bu40f-2 for ; Fri, 24 Jan 2014 13:26:36 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id BCB3F1A011F for ; Fri, 24 Jan 2014 13:26:36 -0800 (PST) Received: from [192.168.23.229] (dsl254-070-154.nyc1.dsl.speakeasy.net [216.254.70.154]) by che.mayfirst.org (Postfix) with ESMTPSA id 3CB82F984 for ; Fri, 24 Jan 2014 16:26:32 -0500 (EST) Message-ID: <52E2DA85.4010705@fifthhorseman.net> Date: Fri, 24 Jan 2014 16:26:29 -0500 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.2.0 MIME-Version: 1.0 To: "tls@ietf.org" References: <20140124210534.C77871ABCA@ld9781.wdf.sap.corp> In-Reply-To: <20140124210534.C77871ABCA@ld9781.wdf.sap.corp> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="h6ucqrOobvhhvwTs1GjCaAfkhHJcQhuPI" Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Jan 2014 21:26:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --h6ucqrOobvhhvwTs1GjCaAfkhHJcQhuPI Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 01/24/2014 04:05 PM, Martin Rex wrote: > The server is definitely the wrong peer to guess whether > the client wants to continue or abort TLS handshake. In the fallback scenario this SCSV is designed to address, the server normally has no knowledge that the client's prior attempts to connect with a reasonable protocol version had failed. By transmitting this SCSV, the client is saying to the server "just so you know, i tried a better protocol, but it didn't work -- if you meant to accept better protocols, then someone is messing with us, please abort= =2E" The server knows whether it believes it can accept better protocols, so it is in the right position to make this call. I support adoption of this draft by the WG. However, there is a risk that clients will offer the SCSV when other non-version handshake parameters have changed (e.g. different ciphersuites were offered, or extensions present in normal connections that are removed in a fallback "compatibility" mode). I'm assuming that clients generally don't want to do multiple layers of fallback, each time testing removing a particular extension or protocol or version or ciphersuite; instead, i suspect clients will prefer a "normal mode" and then a lowest-common-denominator "fallback mode". In this scenario, it does seem plausible that the SCSV could trigger a connection abort that otherwise wouldn't happen. Is there guidance we can give to server or client implementors to mitigate this risk? --dkg --h6ucqrOobvhhvwTs1GjCaAfkhHJcQhuPI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJS4tqFXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcNwoP/RcnR8X7N1yYxNs/nLY3VeGi xOsnFYzAWU73HZbCMI9YEYf8DLQs7Yi/x6YLz7h7cXGhkvbfxfGCGCbKVSp5VMET DU8Np/EZ3lA5A6+kEe9er+OOmucL+RP9rANJrZOWxKwKley9zwO2hCG5/GmoKCUy NW9RjtAU8OR8hvLxSo3MZCo2+ldysw0tfa89Fsbe8M/P6wofTCAA7qt4V9TNne4F Hn9mbtmPOR7D4yaqfAnRQUcMdFT8aeJzoGEAvN83ueFhzwpcruGLJCXXvmfidQUE uATnN/1s+Or46Xz8di2qf6fe/ZlhQtgyit77sazZPXg4OPdTZDoWTliQWFihJ36z UtoF/GzadGlnNKCvMmXM3R7YZKA2R2hQrLZpST1kVroI56caJ3xzCXTuzS+N7nUu +XieP2fD/0vq5jQSF6IVNjSwXkeQ7iDYPQR4CMvEtncK+R36PcfPPtRvMt9EfA48 fIzyQ/lT3CfthFntSrCsDNI+p16tk6CHCM9XXpxlXRkXakfCtraOE/ctbn7BvhIS Tb7gZcjSAMGG7q/sFyiLm6l1j6CeJWM3n34Ub7GS23BKleMjxLjHD5XP/yjlIONK TG879XdY/HAPkNnjxsyJjHWHWF99T1TUHUNZmltvvYpHn785UOHsfgZ5CEfdC5UX 6zuFesJTgHefY7loRFk6 =cJ2k -----END PGP SIGNATURE----- --h6ucqrOobvhhvwTs1GjCaAfkhHJcQhuPI-- From rsalz@akamai.com Fri Jan 24 13:43:42 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC9A1A00CC for ; Fri, 24 Jan 2014 13:43:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjkVqzJbxFSs for ; Fri, 24 Jan 2014 13:43:40 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id CBEE61A00C2 for ; Fri, 24 Jan 2014 13:43:40 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 6DB08473C6; Fri, 24 Jan 2014 21:43:39 +0000 (GMT) Received: from prod-mail-relay02.akamai.com (prod-mail-relay02.akamai.com [172.17.50.21]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 604E4473C5; Fri, 24 Jan 2014 21:43:39 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub6.kendall.corp.akamai.com [172.27.105.22]) by prod-mail-relay02.akamai.com (Postfix) with ESMTP id 57052FE054; Fri, 24 Jan 2014 21:43:39 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.92]) by USMA1EX-CASHUB6.kendall.corp.akamai.com ([172.27.105.22]) with mapi; Fri, 24 Jan 2014 16:43:38 -0500 From: "Salz, Rich" To: Daniel Kahn Gillmor , "tls@ietf.org" Date: Fri, 24 Jan 2014 16:43:38 -0500 Thread-Topic: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv Thread-Index: Ac8ZSvt3Ay4mNUFPQD+fJM627sDqpgAAjxYg Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711EB9F2E33@USMBX1.msg.corp.akamai.com> References: <20140124210534.C77871ABCA@ld9781.wdf.sap.corp> <52E2DA85.4010705@fifthhorseman.net> In-Reply-To: <52E2DA85.4010705@fifthhorseman.net> 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 Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Jan 2014 21:43:42 -0000 PiBCeSB0cmFuc21pdHRpbmcgdGhpcyBTQ1NWLCB0aGUgY2xpZW50IGlzIHNheWluZyB0byB0aGUg c2VydmVyICJqdXN0IHNvIHlvdSBrbm93LCBpIHRyaWVkIGEgYmV0dGVyIHByb3RvY29sLCBidXQg aXQgZGlkbid0IHdvcmsgLS0gaWYgeW91IG1lYW50IHRvIGFjY2VwdCBiZXR0ZXIgcHJvdG9jb2xz LCB0aGVuIHNvbWVvbmUgaXMgbWVzc2luZyB3aXRoIHVzLCBwbGVhc2UgYWJvcnQuIg0KDQpUaGF0 J3MgYSByZWFsbHkgbmljZSBleHBsYW5hdGlvbi4NCg0KKzENCg0KDQotLSAgDQpQcmluY2lwYWwg U2VjdXJpdHkgRW5naW5lZXINCkFrYW1haSBUZWNobm9sb2d5DQpDYW1icmlkZ2UsIE1BDQoNCg== From geoffk@geoffk.org Fri Jan 24 15:15:08 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5E971A0207 for ; Fri, 24 Jan 2014 15:15:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALp7hdHL4u2X for ; Fri, 24 Jan 2014 15:15:00 -0800 (PST) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.105.14]) by ietfa.amsl.com (Postfix) with ESMTP id D44571A01F0 for ; Fri, 24 Jan 2014 15:15:00 -0800 (PST) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 8865733CF89; Fri, 24 Jan 2014 23:14:59 +0000 (UTC) Sender: geoffk@localhost.localdomain To: Daniel Kahn Gillmor References: <20140124210534.C77871ABCA@ld9781.wdf.sap.corp> <52E2DA85.4010705@fifthhorseman.net> From: Geoffrey Keating Date: 24 Jan 2014 15:14:59 -0800 In-Reply-To: <52E2DA85.4010705@fifthhorseman.net> Message-ID: Lines: 12 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "tls@ietf.org" Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Jan 2014 23:15:09 -0000 Daniel Kahn Gillmor writes: > By transmitting this SCSV, the client is saying to the server "just so > you know, i tried a better protocol, but it didn't work -- if you meant > to accept better protocols, then someone is messing with us, please abort." Another way to phrase this is that the client is saying "I think you are an old buggy server. If you think you are not an old buggy server, please abort." The implicit assumption is that there will not be new buggy servers. I think that's the greatest weakness of this concept. From mrex@sap.com Fri Jan 24 16:34:04 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59BB01A023B for ; Fri, 24 Jan 2014 16:34:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 14VG4GrwAFVN for ; Fri, 24 Jan 2014 16:34:02 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 267511A022B for ; Fri, 24 Jan 2014 16:34:01 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s0P0Xt0x017478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 25 Jan 2014 01:33:55 +0100 (MET) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711EB9F2E33@USMBX1.msg.corp.akamai.com> To: "Salz, Rich" Date: Sat, 25 Jan 2014 01:33:55 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140125003355.061101ABCA@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "tls@ietf.org" Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 00:34:04 -0000 Salz, Rich wrote: > >> By transmitting this SCSV, the client is saying to the server >> "just so you know, i tried a better protocol, but it didn't work >> -- if you meant to accept better protocols, then someone is >> messing with us, please abort." > > That's a really nice explanation. Nope, that is a bad idea. We know pretty damn well that there are a number of non-malicious middle-boxes all over the place on the internet. They're the reason that the fallbacks to overcome handshake failures were invented in the first place. If you either believe that giving those middle-boxes a hard time and giving the end users a hard time and forcing the user to use cleartext HTTP is desirable, then simply disable the fallback on the client and be done with it -- this will reliably work with every existing server out there. But if instead, after having pestered enough of your users/customers, you figure that you need to enable succeding with TLSv1.0 instead of forcing the user to switch to cleartext-HTTP, then you will need yet another level of fallback, to a ClientHello without that SCSV -- at which point this whole effort turns into a complete waste. Now on top of that, we do know that TLSv1.2 is cryptographically weaker than TLSv1.0 and TLSv1.1 because of the weak default SHA1-only digitally-signed with RSA server certificates. I would really appreciate if this Working Group would spend more time on making more TLS handshakes succeed and make strong algorithms and cipher suites more easily achievable for the huge installed base of TLS that is under software maintenance. -Martin From mrex@sap.com Fri Jan 24 20:24:31 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20ED51A00B2 for ; Fri, 24 Jan 2014 20:24:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 z26i24yzvWO9 for ; Fri, 24 Jan 2014 20:24:29 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 68B7F1A0043 for ; Fri, 24 Jan 2014 20:24:29 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s0P4OPHD018984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 25 Jan 2014 05:24:25 +0100 (MET) In-Reply-To: <52E2DA85.4010705@fifthhorseman.net> To: Daniel Kahn Gillmor Date: Sat, 25 Jan 2014 05:24:25 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140125042425.230961ABCA@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "tls@ietf.org" Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 04:24:31 -0000 Daniel Kahn Gillmor wrote: > > By transmitting this SCSV, the client is saying to the server "just so > you know, i tried a better protocol, but it didn't work -- if you meant > to accept better protocols, then someone is messing with us, please abort." > > The server knows whether it believes it can accept better protocols, so > it is in the right position to make this call. The _only_ reasonable server response of a TLS server that supports TLSv1.2 to a ClientHello that contains an SCSV which indicates that the client (a) supports TLSv1.2 and (b) would prefer to use TLSv1.2 is a ServerHello with server_version=TLSv1.2. -Martin From watsonbladd@gmail.com Fri Jan 24 21:57:20 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 492601A00D1 for ; Fri, 24 Jan 2014 21:57:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTVoMkOTw2Ed for ; Fri, 24 Jan 2014 21:57:18 -0800 (PST) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 51D0C1A00C7 for ; Fri, 24 Jan 2014 21:57:18 -0800 (PST) Received: by mail-we0-f171.google.com with SMTP id w61so3520634wes.30 for ; Fri, 24 Jan 2014 21:57:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WLCdVeujCQJeDpsPCBrMAV28K1wm96e/gZAq8Wa3EPg=; b=i8SPpP4I+r7bPQ/tiaxQ/sCbfMU5+QHt/1Oo+AU8bcTUprOQsXxbp+jT2eGiwpmVbp MZESgoB83GC/tU2Z5CfKid78mxXqeQF9ifyXkysCJtJRWQIKHxNsBwv3+bAf5PWVKGUm 2C4ccoRWLs8Y44BqDpM7wf7QSEAsTzxTjeLB+R0OOVZ9grf7BHWxalVAAMl6b8PNS14R tfnPsGvclOB0uO1jmw8OzmSZleho4hxPwtSpK4lkoRqumZmFnJMhQP2ez3gKEkkdWAnU EOf6vQH1U5t6oQMEPpim4TzDV1/ycfruI8ZuUh+fXSS+tDez04vV9d8OTvaVrUWistGQ gbbA== MIME-Version: 1.0 X-Received: by 10.194.24.65 with SMTP id s1mr223307wjf.38.1390629436531; Fri, 24 Jan 2014 21:57:16 -0800 (PST) Received: by 10.194.250.101 with HTTP; Fri, 24 Jan 2014 21:57:16 -0800 (PST) In-Reply-To: <20140125042425.230961ABCA@ld9781.wdf.sap.corp> References: <52E2DA85.4010705@fifthhorseman.net> <20140125042425.230961ABCA@ld9781.wdf.sap.corp> Date: Fri, 24 Jan 2014 21:57:16 -0800 Message-ID: From: Watson Ladd To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 25 Jan 2014 05:57:20 -0000 On Fri, Jan 24, 2014 at 8:24 PM, Martin Rex wrote: > Daniel Kahn Gillmor wrote: >> >> By transmitting this SCSV, the client is saying to the server "just so >> you know, i tried a better protocol, but it didn't work -- if you meant >> to accept better protocols, then someone is messing with us, please abort." >> >> The server knows whether it believes it can accept better protocols, so >> it is in the right position to make this call. > > The _only_ reasonable server response of a TLS server that supports TLSv1.2 > to a ClientHello that contains an SCSV which indicates that the client > (a) supports TLSv1.2 and (b) would prefer to use TLSv1.2 > is a ServerHello with server_version=TLSv1.2. Let me try to explain, in words as simple as possible, why everything you have contributed to this thread is just wrong. Some servers are version intolerant to TLS 1.0. For this reason, and not because of middleboxes, version fallback cannot be stopped. Some clients only offer SSL 3.0. Until these clients are gone, some servers will want to serve them. Right now these servers have a dilemma: they cannot serve the SSL 3.0 population without permitting clients offering TLS 1.0 or higher to get forced back down to SSL 3.0 by an attacker. There are real, unfixable problems with SSL 3.0, including the lack of an extension mechanism. Unfortunately, TLS 1.0, 1.1, and 1.2 rely on extensions to indicate which curves are supported. It isn't possible to send at ServerHello back after seeing a ClientHello with "I tried TLS 1.2, and it didn't work" because sending back a ServerHello requires information you don't have, like what curves are supported. This proposal solves that problem by letting clients indicate if they are dropping down because of fallback or because they cannot offer anything better. Your complaint about signature strength is utterly bogus. Cleartext HTTP doesn't have a little lock in the address bar with a green color. Stop pretending that weak crypto is better than no crypto: as I've pointed out to you, I can train my mother to not put in her credit card number without seeing that green lock. I can't train her to evaluate connection strength. Why should the existence of middleboxes permit an active attacker to interfere when I visit my bank website from my home computer? Why should the fact that some corporate networks want to use TLS interception prevent websites from choosing not to permit that sort of attack, while still serving the IE6/XP clients? Why should we let the lowest common denominator drive the security of all our connections, even when better options are supported by both sides? Sincerely, Watson > > > -Martin > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From mrex@sap.com Fri Jan 24 22:48:41 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFEAA1A018B for ; Fri, 24 Jan 2014 22:48:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 Wb2fv1t0vmxc for ; Fri, 24 Jan 2014 22:48:39 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id EE3421A0168 for ; Fri, 24 Jan 2014 22:48:38 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s0P6mYld025030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 25 Jan 2014 07:48:34 +0100 (MET) In-Reply-To: To: Watson Ladd Date: Sat, 25 Jan 2014 07:48:34 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140125064834.B9E191ABC8@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "tls@ietf.org" Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 06:48:42 -0000 Watson Ladd wrote: > Martin Rex wrote: >> >> The _only_ reasonable server response of a TLS server that supports TLSv1.2 >> to a ClientHello that contains an SCSV which indicates that the client >> (a) supports TLSv1.2 and (b) would prefer to use TLSv1.2 >> is a ServerHello with server_version=TLSv1.2. > > Some servers are version intolerant to TLS 1.0. For this reason, and > not because of middleboxes, version fallback cannot be stopped. Servers intolerant to TLSv1.0 have become close to non-existant. Servers intolerant to TLSv1.1 and TLSv1.2, on the other hand, are too many to ignore. The fiscal authority of portugal newly commissioned in July 2013 a mandatory (for Portugal businesses) web service that requires TLS client certs (issued by the authority) and which will drop the connection when receiving a TLS ClientHello with TLSv1.1 or TLSv1.2 in it. Handshake succeeds with TLSv1.0 or SSLv3. > > Some clients only offer SSL 3.0. Until these clients are gone, some > servers will want to serve them. No problem. > > Right now these servers have a dilemma: they cannot serve the SSL 3.0 > population without permitting clients offering TLS 1.0 or higher to > get forced back down to SSL 3.0 by an attacker. There are real, > unfixable problems with SSL 3.0, including the lack of an extension > mechanism. You can not force down the server, only the client. SSLv3 has the EXACT SAME extension mechanism as TLS. http://tools.ietf.org/html/rfc6101#page-27 It's true that this was retrofitted into the SSLv3 protocol late 1996, after the initial SSLv3 spec and initial implementations of SSLv3 had been shipped. And it's also true that Netscape and the TLS WG failed badly in making the 18-Nov-1996 SSLv3 spec easily accessible, which is listed in the references of TLSv1.0 [RFC2246]. http://tools.ietf.org/html/rfc2246#page-77 Curiously, there are not just old, extensions-intolerant SSLv3 servers, there are also extensions-intolerant TLSv1.0 servers. > > Unfortunately, TLS 1.0, 1.1, and 1.2 rely > on extensions to indicate which curves are supported. It isn't > possible to send at ServerHello back after > seeing a ClientHello with "I tried TLS 1.2, and it didn't work" > because sending back a ServerHello requires > information you don't have, like what curves are supported. You're misled. It is perfectly possible to send back a TLSv1.2 ServerHello. If the client doesn't support ECDHE, it will not include any ECC cipher suites anyway. The semantics of the presence of TLS cipher suites, but no accompanying ECC TLS extension is also well-defined in the TLS ECC spec (rfc4492). > > This proposal solves that problem by letting clients indicate if they > are dropping down because of fallback or because they cannot offer > anything better. This proposal does not solve anything at all. When Server sends back a ServerHello with server_version=TLSv1.2, then the client could still decide to abort the handshake if the client so desires. When the server sends a fatal TLS alert, then interop has completely failed. Calling a complete interop failure a "solution" is incompatible with the mission of the IETF. > > Your complaint about signature strength is utterly bogus. No, it isn't. That TLSv1.2 breakage would have been easily avoidable. And we can still fix it, rather than pretending that a sha1-with-rsa digital signature would be a reasonable and secure default choice for a protocol. > > Cleartext HTTP doesn't have a little lock in the address bar with a > green color. Stop pretending that weak crypto is better than no > crypto: > as I've pointed out to you, I can train my mother to not put in her > credit card number without seeing that green lock. I can't train her > to evaluate connection strength. When she starts surfing with a HTTP URL, then the little green lock that onlyappears when she is prompted for her credit card provides pretty close to zero security. > > Why should the existence of middleboxes permit an active attacker to > interfere when I visit my bank website from my home computer? > Why should the fact that some corporate networks want to use TLS > interception prevent websites from choosing not to permit that sort > of attack, while still serving the IE6/XP clients? Why should we let > the lowest common denominator drive the security of all our > connections, even when better options are supported by both sides? When better options are supported by both sides, then it is our task to (a) make these peers interoperate and (b) negotiate&use at least some of those better protocol features in a fashion that will not blow up badly in case of spurious internet connectivity failures or when new TLS software is tested in a few servers of a NATed server farm. Fatally aborting the handshake is the far opposite of a successful negotiation. -Martin From rransom.8774@gmail.com Sat Jan 25 01:18:35 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9FE1A01F4 for ; Sat, 25 Jan 2014 01:18:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 ohUeXYWR4auc for ; Sat, 25 Jan 2014 01:18:34 -0800 (PST) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 1E6831A0158 for ; Sat, 25 Jan 2014 01:18:34 -0800 (PST) Received: by mail-qc0-f169.google.com with SMTP id w7so5728143qcr.14 for ; Sat, 25 Jan 2014 01:18:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nicz1tc1J4zPLzEMd5t37dMXZHTrsU1g5Vng0lV/Xhw=; b=e6qAAWlbo+MW0UxW28vhDlUyOp/bfYDo/sLFci8rF74X9GtsGqWogs8IKEKiK+Kia0 6ufguTJQGLtUZW/yr4OhyxGzLIhKz9GOVxgKKBtFnjrIjdcJJwUqzQx3P6KSojr+z8dL MfxKRFP7usBWgbPZjj/yOU0TTyeRER9rTdKbhm2uA89RZmdEudsIT6IMVKYjpbheu/++ DF72W9/Iwj7/0yx4OyBXstvQhDk2HmQntW6+ttedS1yOiybiNgUNz+wIa3Ws/wqObtZE A9rn1nckn8NDGJdAi64hS84CRS+2P7cNhpT1HZ2KDziLoOPrk5UJgQysXmO4FxDSOrvq zTdQ== MIME-Version: 1.0 X-Received: by 10.140.92.213 with SMTP id b79mr25504829qge.108.1390641512447; Sat, 25 Jan 2014 01:18:32 -0800 (PST) Received: by 10.229.181.132 with HTTP; Sat, 25 Jan 2014 01:18:32 -0800 (PST) In-Reply-To: <282749297.5013598.1390639819914.JavaMail.root@redhat.com> References: <87ob3456s1.fsf@latte.josefsson.org> <1390466373.20176.8.camel@dhcp-2-127.brq.redhat.com> <52E2B937.5080502@polarssl.org> <2A0EFB9C05D0164E98F19BB0AF3708C711EB9F2DB6@USMBX1.msg.corp.akamai.com> <282749297.5013598.1390639819914.JavaMail.root@redhat.com> Date: Sat, 25 Jan 2014 01:18:32 -0800 Message-ID: From: Robert Ransom To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 Cc: =?UTF-8?Q?Manuel_P=C3=A9gouri=C3=A9=2DGonnard?= , tls@ietf.org Subject: Re: [TLS] Curve25519 in TLS and Additional Curves 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, 25 Jan 2014 09:18:35 -0000 On 1/25/14, Nikos Mavrogiannopoulos wrote: >> Sure, and we could also use the existing ECC point structure and transmit >> 32 >> bytes of zero as a fake y value. It's a slippery slope. >> >> The main interest in using this curve is to use the existing >> implementations >> for their security and performance benefits and that there is a real >> benefit >> to being able to feed directly from the wire into implementations. On >> the >> "other side" the only argument seems to be that this format is what all >> other protocols do. >> So explain to me which "side" is following religious dogma? :) > > You seem to imply that following conventions established during the years is > unecessary. That could be true, but your only point of backing that up is > that a library that implements this curve uses the little endian format. Several libraries implement Curve25519 scalar multiplication in constant time, with varying degrees of portability and efficiency. All of them operate on public and secret keys in little-endian format. > Is > there really merit in that argument? Yes. > Do you really believe that all > implementations of this draft will use this library? I sure hope all implementations of this draft will use a constant-time implementation of Curve25519. Since the most likely way that a TLS implementation will obtain a constant-time implementation of Curve25519 is to use an existing one, I hope all TLS implementations will initially use one of the existing little-endian implementations of Curve25519. > Why force any other > library that will implement this curve handle its points in a special way? Does this mean that you intend to implement Curve25519 using a generic bignum library? How will your implementation (attempt to) avoid leaking information about key material to a side-channel attacker? > This is not about standardizing code, it is about standardizing a curve. It is about standardizing a curve which has a well-established convention of storing and transmitting keys in little-endian format. Robert Ransom From synp71@live.com Sun Jan 26 06:12:27 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACE061A012B for ; Sun, 26 Jan 2014 06:12:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptPd0G6hIwSY for ; Sun, 26 Jan 2014 06:12:26 -0800 (PST) Received: from blu0-omc3-s15.blu0.hotmail.com (blu0-omc3-s15.blu0.hotmail.com [65.55.116.90]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC2A1A011A for ; Sun, 26 Jan 2014 06:12:26 -0800 (PST) Received: from BLU0-SMTP173 ([65.55.116.73]) by blu0-omc3-s15.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 26 Jan 2014 06:12:24 -0800 X-TMN: [3We93v/C59r9FX+acXhM6HtYs77hmji1] X-Originating-Email: [synp71@live.com] Message-ID: Received: from ynir-MBA.local ([194.29.32.131]) by BLU0-SMTP173.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 26 Jan 2014 06:12:22 -0800 Date: Sun, 26 Jan 2014 16:12:10 +0200 From: Yoav Nir User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Eric Rescorla , "tls@ietf.org" References: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050300070506050004010809" X-OriginalArrivalTime: 26 Jan 2014 14:12:22.0246 (UTC) FILETIME=[A16DF060:01CF1AA0] Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 26 Jan 2014 14:12:27 -0000 --------------ms050300070506050004010809 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 23/1/14 12:06 PM, Eric Rescorla wrote: > WG Members, > > This message is a call for acceptance of > http://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-01 > > As a TLS WG item. > > Please provide any comments on this action by Feb 7. Because > there has been only modest discussion of this document, the > chairs ask people who have already spoken in favor or against > this document to re-register their opinion (feel free to just say > +1 or -1 and point back to the archives.) +0.5 I'm not opposed to this document, but we should be realistic as to what=20 this solution can accomplish. This extension (I use this term in the sense of protocol extension, not=20 TLS ClientHello Extension) will not protect the client or the server=20 from a TLS proxy. TLS proxies that do not support high versions of TLS=20 will negotiate both the client and the server down to TLS 1.0, and will=20 not forward the SCSV. Also, older servers will not recognize the SCSV and ignore it. So to=20 have this extension add any value, all of the following much be true: - an updated server - an updated client - Something that causes the negotiation to fail. This something could=20 be the client, the server, or something in between. The goal of this=20 extension is to catch the something in the middle. So presumably, the server blocks the connection, or returns a=20 poorly-protected error page whenever it gets the SCSV. But this could be = caused by a MitM that drops negotiations that have a too-high TLS=20 version, or by client bugs or by server bugs. Broadly speaking, I think=20 there are four failure scenarios: 1. either the (updated) client or the (updated) server have bugs that=20 caused the TLS 1.2 handshake to fail. 2. The (updated) client has a bug causing it to send the SCSV even=20 though no downgrade happened 3. An attacker is on-path and is dropping TLS 1.2 because it can break = TLS 1.2. 4. An older firewall is dropping the TLS 1.2 connections, because they = fail some sanity check. (that all TLS records have 3.0 or 3.1 in the=20 record header) So the extension makes sense if #3 is the likely scenario for failure.=20 Any failure for the other reasons is kind of "collateral damage" that I=20 don't think is justified in a world where TLS 1.0 is not considered so=20 terrible as to disable it entirely. So I guess we need to hear some=20 real-world experience about where most such failures would come from. =20 Of course, we don't have any data *now* about buggy updated servers, so=20 we'd have to guess how many and what kind of bugs are going to be=20 present in not-yet-written code. Yoav --------------ms050300070506050004010809 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO4zCC BJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2Ny bC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEB BCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG9w0B AQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QWuZGH kfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLRzIlf sXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7LmrmdlMa5 lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg7sJx ggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCCBRow ggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRo ZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1h aWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFAGpDM J1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq1Gdv IBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg7SQf Oq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWSD//g sWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUswggFH MB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvGeGNk J8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNVHSAE CjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3QuY29t L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYIKwYB BQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVROQWRk VHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3Qu Y29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/avQUn1 G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo2rHA 8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjrP0OD 8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIaXXxH maWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7qpeeU 0rD+83X5f27nMIIFIDCCBAigAwIBAgIRAJLy3rLPGBD9qh6TW+ZG9DowDQYJKoZIhvcNAQEF BQAwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01P RE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTMxMTE3 MDAwMDAwWhcNMTQxMTE3MjM1OTU5WjAgMR4wHAYJKoZIhvcNAQkBFg9zeW5wNzFAbGl2ZS5j b20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCow0TXP0M95fIMY0Fsd3xpZj55 m1mkkKhUWLjVtQcd57MyVmBZNQkAmxp9PrzqdHw5eIIBn1EI9foIoynEnUSZzv6pIEXAqdYu xBH0AdvjoPCzWb9uYrqBtbmxnLh9k9ox1pVJG4hit6WEpK+LZ7uvLj5GUWMdmzghC/+fVEZS W8U62xlhd8Hq8ded9bfqjM4psDgqUubjcCkMIUnkD9yuXhzfzwF0wwtD66vXrUe8T4/m6XHO iIqvvVMjzYyKrdLE7zuPyDcDjkxLCCdi2j4c44anq8Pj/yEh5JGU0XSKSfwm2m0UDHj7P/6u B74JwiAyMtqWzdQBHVOphHKDI0ZTAgMBAAGjggHfMIIB2zAfBgNVHSMEGDAWgBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAdBgNVHQ4EFgQUq+f5Y55gheJJpWtJDEPf6j2uzhQwDgYDVR0PAQH/ BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUC MBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsG AQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBI hkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6 Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJl RW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAaBgNV HREEEzARgQ9zeW5wNzFAbGl2ZS5jb20wDQYJKoZIhvcNAQEFBQADggEBACRvTZSZMhI7HrJr jTpnm5FZXyYwJYVhhc643/94hv8pxAQzIY6vH+BlVwmG4Z0Dt6vWYwaUUYdGmvlH0bti8aql JPe4fUgTxbDlTldhOYfISl3ky9+4CEPg4QvX6tOGIusOrvaIszGUIdvKHzvYM4ZapdTxyFCt oe1RXq/17ifvIklgmuh+QcB1xNBmE3lBNj+Vy8xLvsAQlqf9ZAIcBNL2yQGCaBcr6XoR24/D oCNCTAOCR/J2nN/okuGsEF+kvxP/BCPBnDph9coFLNOEwR4ZataT6H4vq0fwGxm5SROTDYis SUTKc+YYKY2RllEwOxX1NZUSmISuGKrGhr2aCaUxggQcMIIEGAIBATCBqTCBkzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEa MBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJLy3rLPGBD9qh6TW+ZG9DowCQYF Kw4DAhoFAKCCAkcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTQwMTI2MTQxMjEwWjAjBgkqhkiG9w0BCQQxFgQUTHOxfUYTh/6TBVp6fHUNO8/4mogwbAYJ KoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB ugYJKwYBBAGCNxAEMYGsMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBAhEAkvLess8YEP2qHpNb5kb0OjCBvAYLKoZIhvcNAQkQAgsxgayggakwgZMxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCS8t6yzxgQ/aoek1vmRvQ6 MA0GCSqGSIb3DQEBAQUABIIBAGWkiHmY/3ozcf521knvu+PBjNZFFtwaC8EDkNGRopTte5xh QAX/Fhx97P3ob7QGr0YO2KifLfR/bD/1zpx28+HG9wx+RoLwLJ7k+HFYX7oWHpCUr0mugtoU hNzGm95tR+P3EBLWrWB8/Dgk+vqNnpCyrobfYp1wC/kXhzpDrJ3XHsKetNZLVkmTnjiZIUvh 7Qfq/85Zl1jHQF8xw/4uhzplHbywP329K6Tq+Al/abTfZnMAA3rySmhnqgTlBkwAdkjs4HlE ixqmNCEEbdJ6g5HrcOoB0cr6l/gXLqh4jm6hgg9jRlHxOPIE2DgC0L/hFxTOXfhj3BPtSgnz MjYipBwAAAAAAAA= --------------ms050300070506050004010809-- From dkg@fifthhorseman.net Sun Jan 26 09:08:15 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B48C1A0009 for ; Sun, 26 Jan 2014 09:08:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbr_ivZ-FD7p for ; Sun, 26 Jan 2014 09:08:11 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 92A821A0005 for ; Sun, 26 Jan 2014 09:08:11 -0800 (PST) Received: from [192.168.13.184] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 40A37F984; Sun, 26 Jan 2014 12:08:07 -0500 (EST) Message-ID: <52E540F4.6090007@fifthhorseman.net> Date: Sun, 26 Jan 2014 12:08:04 -0500 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.2.0 MIME-Version: 1.0 To: Yoav Nir , Eric Rescorla , "tls@ietf.org" References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="mtKHJOdrPrMTw85DSG0Bs3ohDRuDdoRR9" Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 26 Jan 2014 17:08:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mtKHJOdrPrMTw85DSG0Bs3ohDRuDdoRR9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 01/26/2014 09:12 AM, Yoav Nir wrote: > This extension (I use this term in the sense of protocol extension, not= > TLS ClientHello Extension) will not protect the client or the server > from a TLS proxy. TLS proxies that do not support high versions of TLS > will negotiate both the client and the server down to TLS 1.0, and will= > not forward the SCSV. By "TLS proxy", i think you mean a MITM that controls a CA certificate that the client already has loaded in their root store (and is therefore willing to "trust" to terminate the other end of a TLS connection). Otherwise, if it strips the SCSV, the peers would notice that their Finished handshakes don't match. This sounds like yet another reason why TLS proxies of this type are actively bad for client communications security. The client has delegated these decisions to such a proxy, and cannot make them on its ow= n. > Also, older servers will not recognize the SCSV and ignore it. So to > have this extension add any value, all of the following much be true: > - an updated server > - an updated client > - Something that causes the negotiation to fail. This something could > be the client, the server, or something in between. The goal of this > extension is to catch the something in the middle. Yes, precisely. This is a proposed extension that should make TLS safer between two compatible peers. > So presumably, the server blocks the connection, or returns a > poorly-protected error page whenever it gets the SCSV. But this could b= e > caused by a MitM that drops negotiations that have a too-high TLS > version, or by client bugs or by server bugs. Broadly speaking, I think= > there are four failure scenarios: > 1. either the (updated) client or the (updated) server have bugs that > caused the TLS 1.2 handshake to fail. ... *and* this happens in a scenario that causes the client to initiate its fallback/downgrade mode to a level that offers the SCSV. > 2. The (updated) client has a bug causing it to send the SCSV even > though no downgrade happened > 3. An attacker is on-path and is dropping TLS 1.2 because it can break= > TLS 1.2. > 4. An older firewall is dropping the TLS 1.2 connections, because they= > fail some sanity check. (that all TLS records have 3.0 or 3.1 in the > record header) Is this a "sanity check" or an "insanity check" ? :) Your breakdown of the scenarios where this extension seems relevant is a good one. > So the extension makes sense if #3 is the likely scenario for failure. > Any failure for the other reasons is kind of "collateral damage" that I= > don't think is justified in a world where TLS 1.0 is not considered so > terrible as to disable it entirely.=20 Remember also that clients can choose to offer the downgrade SCSV only for particular protocols that they really want to see go away (e.g. today they might implement it when falling back to SSLv3 only, but not when falling back to TLSv1). This is covered by the Security Considerations section of the draft. Another way to look at the situation is: do we want to accept that the existence of some client or server bugs (1 and 2) and some overly-restrictive firewalls (4) mean we should leave all of our machines vulnerable to the attacker in (3), even though we have a mechanism to protect against that attacker when communicating with updated peers? Regards, --dkg --mtKHJOdrPrMTw85DSG0Bs3ohDRuDdoRR9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJS5UD0XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcjIAP/jF4NAEUkXDv6h84cWZtdVcu sZPWoGpQG/AWTNGlKznEcJjhav5lgGJ00sBhWodTMOSJMg1j8hfHq+nEVG3iuHoy 3ggDcKudN8cUxnAxFGUUZxDqlsj3ghavo0LWBp4pBdJRlxQvuy5pppDefJcK0GO4 +EXu5m+q0rSigcYyYGYhWlUuCwhwJ/jHmqGAfMGJeLixr2CQ/DUGuHcYiA8RVaH/ ZCy30HO97p+ijSWl/0vsdgZeb28uAFJOgmSsVzbvUVt8EveHQkUakQuY/PLtdwNy UIt5I/LT7sGs2Ml7ph8QfhTggtZGTX0tVlnTwJp36G76DX/luRQvcd8tsPRP1XK6 SJe3dNKiAEvHjOa4eDdt8fzQUybUbhICevgNxeeHwwt/FV5lirrSzeNUQHQoMqZJ xcGRajLLSvIG5EOTvjpio9wscZFg560EDW5geUoQOFr2DMTDb5wVee5vJb+Vh5AL Q870GX6kp7n4IEJsuDe+66rsmIWx47o2bmOSY3MN4nLJZi+J6jN0tLYPjVPX2r6p 6kkvXdttuWyWXhg+SnHtEa7U+y2aqP59NHfNomf5If3nuMhiHI7/5wLsjAvwo+4r 2ClbZW5nSRiQHe11s9Sggl4EgBem4lHvKrAN92QdasW2Hn1CMW/ntS56IphgXbeJ NTzDo1WezjohgpFF85H5 =Vo95 -----END PGP SIGNATURE----- --mtKHJOdrPrMTw85DSG0Bs3ohDRuDdoRR9-- From watsonbladd@gmail.com Sun Jan 26 10:15:13 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D80B71A00AE for ; Sun, 26 Jan 2014 10:15:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBj-O2tnWN0T for ; Sun, 26 Jan 2014 10:15:08 -0800 (PST) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 701FE1A0023 for ; Sun, 26 Jan 2014 10:15:08 -0800 (PST) Received: by mail-we0-f174.google.com with SMTP id x55so4500159wes.33 for ; Sun, 26 Jan 2014 10:15:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TJY2OYlUY9Wq3Pl45kHXZIQwsI+LyjgPsqnky5GmpQU=; b=zPVcaxzfBBivkjARENwQZdB5H8v2PxUrsevBbbNN5YG2uJ22XRZnt172pDyjUGbbk8 c6cKjVrgKAqSLUW9ZY3f5h3xQ+05GRIi5a/enP3+nBYcomwOiU5/obn0z1gOT/VVZc8C rWzmglCBecvRV3JANwIvAJZC0uBhlBxZnDBUXTiXArN/k2EB3YmhD3/nOpNWFQx91VzK VRZ8fTT2yDDkGnVhxLauBgwbofamBJ7yPxKQIpzshR5yurq9ldCIgSmyEkeWymE2XVQ+ 1FPOtU4ZsR1tQh5HFveHVQp7odOYCHNUpW2sPus7EXVPApkXWgn7oy1BzQkqbk4zlGCz pPgg== MIME-Version: 1.0 X-Received: by 10.194.60.103 with SMTP id g7mr1736184wjr.37.1390760105882; Sun, 26 Jan 2014 10:15:05 -0800 (PST) Received: by 10.194.250.101 with HTTP; Sun, 26 Jan 2014 10:15:05 -0800 (PST) In-Reply-To: <52E540F4.6090007@fifthhorseman.net> References: <52E540F4.6090007@fifthhorseman.net> Date: Sun, 26 Jan 2014 10:15:05 -0800 Message-ID: From: Watson Ladd To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 26 Jan 2014 18:15:14 -0000 On Sun, Jan 26, 2014 at 9:08 AM, Daniel Kahn Gillmor wrote: > On 01/26/2014 09:12 AM, Yoav Nir wrote: >> This extension (I use this term in the sense of protocol extension, not >> TLS ClientHello Extension) will not protect the client or the server >> from a TLS proxy. TLS proxies that do not support high versions of TLS >> will negotiate both the client and the server down to TLS 1.0, and will >> not forward the SCSV. > > By "TLS proxy", i think you mean a MITM that controls a CA certificate > that the client already has loaded in their root store (and is therefore > willing to "trust" to terminate the other end of a TLS connection). > Otherwise, if it strips the SCSV, the peers would notice that their > Finished handshakes don't match. > > This sounds like yet another reason why TLS proxies of this type are > actively bad for client communications security. The client has > delegated these decisions to such a proxy, and cannot make them on its own. > >> Also, older servers will not recognize the SCSV and ignore it. So to >> have this extension add any value, all of the following much be true: >> - an updated server >> - an updated client >> - Something that causes the negotiation to fail. This something could >> be the client, the server, or something in between. The goal of this >> extension is to catch the something in the middle. > > Yes, precisely. This is a proposed extension that should make TLS safer > between two compatible peers. > >> So presumably, the server blocks the connection, or returns a >> poorly-protected error page whenever it gets the SCSV. But this could be >> caused by a MitM that drops negotiations that have a too-high TLS >> version, or by client bugs or by server bugs. Broadly speaking, I think >> there are four failure scenarios: >> 1. either the (updated) client or the (updated) server have bugs that >> caused the TLS 1.2 handshake to fail. > > ... *and* this happens in a scenario that causes the client to initiate > its fallback/downgrade mode to a level that offers the SCSV. > >> 2. The (updated) client has a bug causing it to send the SCSV even >> though no downgrade happened >> 3. An attacker is on-path and is dropping TLS 1.2 because it can break >> TLS 1.2. >> 4. An older firewall is dropping the TLS 1.2 connections, because they >> fail some sanity check. (that all TLS records have 3.0 or 3.1 in the >> record header) > > Is this a "sanity check" or an "insanity check" ? :) > > Your breakdown of the scenarios where this extension seems relevant is a > good one. > >> So the extension makes sense if #3 is the likely scenario for failure. >> Any failure for the other reasons is kind of "collateral damage" that I >> don't think is justified in a world where TLS 1.0 is not considered so >> terrible as to disable it entirely. > > Remember also that clients can choose to offer the downgrade SCSV only > for particular protocols that they really want to see go away (e.g. > today they might implement it when falling back to SSLv3 only, but not > when falling back to TLSv1). This is covered by the Security > Considerations section of the draft. > > Another way to look at the situation is: do we want to accept that the > existence of some client or server bugs (1 and 2) and some > overly-restrictive firewalls (4) mean we should leave all of our > machines vulnerable to the attacker in (3), even though we have a > mechanism to protect against that attacker when communicating with > updated peers? If a server is buggy it shouldn't pretend to offer TLS 1.2 support. If you don't notice this bug, what are you doing when testing? As a workaround one can turn off the downgrade protection if fallback is required to interop. Furthermore, I think we should have a name-and-shame lab if we are going to be considering not addressing security issues because of interop. Everyone brings in their implementation, and we go through the whole combination of setups, and see what fails in unacceptable ways, then publish the results. If you don't want to do this, then you shouldn't offer your product as supporting TLS. We'll also have negative test cases as well, plus some fuzzing. Why exactly wouldn't a serious implementor be doing this already? Let's see if we can get this done by IETF 90. Furthermore, since gambling is legal in the UK, you can put your money where your mouth is. Sincerely, Watson > > Regards, > > --dkg > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From frantz@pwpconsult.com Sun Jan 26 10:18:15 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7649E1A000A for ; Sun, 26 Jan 2014 10:18:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_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 mveOkrzDAlG9 for ; Sun, 26 Jan 2014 10:18:13 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 568971A0019 for ; Sun, 26 Jan 2014 10:18:13 -0800 (PST) Received: from [173.75.83.192] (helo=Williams-MacBook-Pro.local) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1W7UHa-0006d8-VM for tls@ietf.org; Sun, 26 Jan 2014 13:18:11 -0500 Date: Sun, 26 Jan 2014 10:18:10 -0800 From: Bill Frantz To: tls@ietf.org X-Priority: 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.3.1 (422) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79ba493d7e40dd046919cbddef5a35d0a3350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 173.75.83.192 Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 26 Jan 2014 18:18:15 -0000 On 1/26/14 at 6:12 AM, synp71@live.com (Yoav Nir) wrote: >1. either the (updated) client or the (updated) server have=20 >bugs that caused the TLS 1.2 handshake to fail. >2. The (updated) client has a bug causing it to send the SCSV even though = no downgrade happened Perhaps a decent public test suite could make these causes=20 disappear. The idea that we're designing for buggy new software=20 offends me. We should have procedures that eliminate these=20 situations no later than very early in deployment. Cheers - Bill ----------------------------------------------------------------------- Bill Frantz | I don't have high-speed | Periwinkle (408)356-8506 | internet. I have DSL. | 16345=20 Englewood Ave www.pwpconsult.com | | Los Gatos,=20 CA 95032 From synp71@live.com Sun Jan 26 15:33:04 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16A511A00A7 for ; Sun, 26 Jan 2014 15:33:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8m8sBGmdls7t for ; Sun, 26 Jan 2014 15:33:02 -0800 (PST) Received: from blu0-omc3-s7.blu0.hotmail.com (blu0-omc3-s7.blu0.hotmail.com [65.55.116.82]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2C91A0092 for ; Sun, 26 Jan 2014 15:33:02 -0800 (PST) Received: from BLU0-SMTP134 ([65.55.116.72]) by blu0-omc3-s7.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 26 Jan 2014 15:33:00 -0800 X-TMN: [9+H4TgpISX+LGUkeojXG9TRT9Ugwv6qZ] X-Originating-Email: [synp71@live.com] Message-ID: Received: from ynir-MBA.local ([84.109.50.18]) by BLU0-SMTP134.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 26 Jan 2014 15:32:57 -0800 Date: Mon, 27 Jan 2014 01:32:51 +0200 From: Yoav Nir User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Daniel Kahn Gillmor , Eric Rescorla , "tls@ietf.org" References: <52E540F4.6090007@fifthhorseman.net> In-Reply-To: <52E540F4.6090007@fifthhorseman.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000200090804030504090007" X-OriginalArrivalTime: 26 Jan 2014 23:32:58.0055 (UTC) FILETIME=[F1EF1570:01CF1AEE] Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 26 Jan 2014 23:33:04 -0000 --------------ms000200090804030504090007 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable On 26/1/14 7:08 PM, Daniel Kahn Gillmor wrote: > 4. An older firewall is dropping the TLS 1.2 connections, because the= y > fail some sanity check. (that all TLS records have 3.0 or 3.1 in the > record header) > Is this a "sanity check" or an "insanity check" ? :) When attacks are known, it's easy to program firewalls or IPS systems to = detect them. the problem is unknown attacks. One countermeasure that is=20 as old as firewalls is to make a sanity check of what a protocol should=20 look like. This is somewhat beneficial. Most buffer overflow exploits=20 and even SQL injections would not pass a sanity check. So firewall=20 validations are written to common practice, not necessarily to RFC. Sometimes this has unintended consequences. 12 years ago, many firewalls = (including ours) would make a sanity check on TCP: we enforced the=20 sequence SYN--SYNACK--ACK--data. Apple introduced some version of Mac OS = (I think it was 9.2) that had a unique feaure: The first data from the=20 client was sent in the third packet instead of following it. For the=20 firewall this was a violation of TCP sanity. But as it turns out, this=20 is not prohibited by the TCP specs. We fixed our firewall, but I guess=20 this broke some things. I haven't seen this behavior again anywhere, and = all versions of Mac OS following that did not do this*. So I wouldn't be surprised if there are some version-intolerant=20 firewalls out there just as there are version intolerant servers. Yoav (*) Yes, I realize that this has probably more to do with moving to a=20 BSD kernel than with traversing firewalls, but it is instructive that=20 nobody repeated this experiment. --------------ms000200090804030504090007 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO4zCC BJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2Ny bC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEB BCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG9w0B AQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QWuZGH kfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLRzIlf sXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7LmrmdlMa5 lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg7sJx ggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCCBRow ggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRo ZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1h aWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFAGpDM J1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq1Gdv IBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg7SQf Oq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWSD//g sWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUswggFH MB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvGeGNk J8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNVHSAE CjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3QuY29t L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYIKwYB BQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVROQWRk VHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3Qu Y29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/avQUn1 G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo2rHA 8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjrP0OD 8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIaXXxH maWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7qpeeU 0rD+83X5f27nMIIFIDCCBAigAwIBAgIRAJLy3rLPGBD9qh6TW+ZG9DowDQYJKoZIhvcNAQEF BQAwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01P RE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTMxMTE3 MDAwMDAwWhcNMTQxMTE3MjM1OTU5WjAgMR4wHAYJKoZIhvcNAQkBFg9zeW5wNzFAbGl2ZS5j b20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCow0TXP0M95fIMY0Fsd3xpZj55 m1mkkKhUWLjVtQcd57MyVmBZNQkAmxp9PrzqdHw5eIIBn1EI9foIoynEnUSZzv6pIEXAqdYu xBH0AdvjoPCzWb9uYrqBtbmxnLh9k9ox1pVJG4hit6WEpK+LZ7uvLj5GUWMdmzghC/+fVEZS W8U62xlhd8Hq8ded9bfqjM4psDgqUubjcCkMIUnkD9yuXhzfzwF0wwtD66vXrUe8T4/m6XHO iIqvvVMjzYyKrdLE7zuPyDcDjkxLCCdi2j4c44anq8Pj/yEh5JGU0XSKSfwm2m0UDHj7P/6u B74JwiAyMtqWzdQBHVOphHKDI0ZTAgMBAAGjggHfMIIB2zAfBgNVHSMEGDAWgBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAdBgNVHQ4EFgQUq+f5Y55gheJJpWtJDEPf6j2uzhQwDgYDVR0PAQH/ BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUC MBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsG AQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBI hkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6 Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJl RW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAaBgNV HREEEzARgQ9zeW5wNzFAbGl2ZS5jb20wDQYJKoZIhvcNAQEFBQADggEBACRvTZSZMhI7HrJr jTpnm5FZXyYwJYVhhc643/94hv8pxAQzIY6vH+BlVwmG4Z0Dt6vWYwaUUYdGmvlH0bti8aql JPe4fUgTxbDlTldhOYfISl3ky9+4CEPg4QvX6tOGIusOrvaIszGUIdvKHzvYM4ZapdTxyFCt oe1RXq/17ifvIklgmuh+QcB1xNBmE3lBNj+Vy8xLvsAQlqf9ZAIcBNL2yQGCaBcr6XoR24/D oCNCTAOCR/J2nN/okuGsEF+kvxP/BCPBnDph9coFLNOEwR4ZataT6H4vq0fwGxm5SROTDYis SUTKc+YYKY2RllEwOxX1NZUSmISuGKrGhr2aCaUxggQcMIIEGAIBATCBqTCBkzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEa MBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJLy3rLPGBD9qh6TW+ZG9DowCQYF Kw4DAhoFAKCCAkcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTQwMTI2MjMzMjUxWjAjBgkqhkiG9w0BCQQxFgQU9apz/Ubr1zsFYz0T8A0CNreGI/owbAYJ KoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB ugYJKwYBBAGCNxAEMYGsMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBAhEAkvLess8YEP2qHpNb5kb0OjCBvAYLKoZIhvcNAQkQAgsxgayggakwgZMxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCS8t6yzxgQ/aoek1vmRvQ6 MA0GCSqGSIb3DQEBAQUABIIBABxI6jQ8CY2Z7hKLFGw9wR8KtUqDpXJ2aPNwl5cMgeAiL+GL ib3Qa16TwGvIeTzOuhZTE1mTn1joH3jJZGmckf5E3iTe0JyOieBd32BJWcCBQvO0CgdjiT8F Hv7ouiyec9HmtT/wVtJUSWLniUpbRV3S/96fN5pZldCooJkOdACGUYrberoxPoTlXXIcL3Te 8p285rw4eA9auP9XNb6KvxVN+K8ngjHXlARwLplzCKYImUAlKOI52jhEW13rXdWF9tcdKHQS 3TifNnvV0/UL/sF0BQ2NaUrkw+nvJDXyCaqNHh07oADhdFlvbgexyDAfNQkqoYjAH9iaWH0c B/YsgFwAAAAAAAA= --------------ms000200090804030504090007-- From ekr@rtfm.com Sun Jan 26 15:38:32 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70D001A0161 for ; Sun, 26 Jan 2014 15:38:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T06f-qLOz02G for ; Sun, 26 Jan 2014 15:38:30 -0800 (PST) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by ietfa.amsl.com (Postfix) with ESMTP id BBF631A00F3 for ; Sun, 26 Jan 2014 15:38:30 -0800 (PST) Received: by mail-vb0-f54.google.com with SMTP id w20so3037640vbb.27 for ; Sun, 26 Jan 2014 15:38:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=E5nnZroCF7aLrXBUBHsQDs5jO2+KA7jntfaGxQPlEcQ=; b=UlNuWkVVxPtXkAsOX7Vo+3FPfG9sH8g+Ah3CHvjFm0QqYCAZ604s95asN4i7yUmr+b /9KVnybuDFwnuEwuvimBgOBfekIsU4/6VbPFGhqLU9QCJxzyk+GO1tHp8ennk8ZJXgtm ip/wdOOvOAw3VoASdSr86tAfNpODuUE4pdLEdTE2JqjsxZ8xmBs1MZrGQIT8IGMrdQN8 LhbLo/pqy5+DEIy5IJJFxq4WLBmVn0PByNGSSr4tWCaI0wCTfAJTq90xQQskkJDcs5qR +OT6pWIPJy9TWL1ePCWor7iE0Zv6ORbJ1Vvja57Wzvs9N9SAOY40q4wd+C3kDE8uWXha N6Tw== X-Gm-Message-State: ALoCoQkJjbH34jW2UPsfKOvNLAMAZgmZurDHEgiHH3mLaHtlpQ0CnXpjdaS+vtcIDMOvDDEZnGmf X-Received: by 10.220.193.70 with SMTP id dt6mr13941479vcb.17.1390779508640; Sun, 26 Jan 2014 15:38:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.106.162 with HTTP; Sun, 26 Jan 2014 15:37:48 -0800 (PST) X-Originating-IP: [74.95.2.168] In-Reply-To: References: <20140107201722.ECDA01AB93@ld9781.wdf.sap.corp> From: Eric Rescorla Date: Sun, 26 Jan 2014 15:37:48 -0800 Message-ID: To: Adam Langley Content-Type: text/plain; charset=ISO-8859-1 Cc: "tls@ietf.org" Subject: Re: [TLS] Next steps for draft-agl-tls-padding X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2014 23:38:32 -0000 WG Members, Based on this discussion the chairs believe we have sufficient support to ask for an early code point assignment. This message serves as a request to the chair to do so. Additionally, unless someone objects we intend to adopt it as a WG draft. If there are any objections, please post them by Mon Feb 3. -Ekr On Wed, Jan 8, 2014 at 11:29 AM, Adam Langley wrote: > On Tue, Jan 7, 2014 at 3:17 PM, Martin Rex wrote: >> A provisional code point would be nice, but I had to read the >> description of the extension contents several times and cross-check >> with other TLS extension documents to figure out (and assure myself) >> what draft-agl-tls-padding-02 really means implementation-wise. > > Thanks for the comments. I think you make a good point and I've > updated the draft > (https://tools.ietf.org/html/draft-agl-tls-padding-03) to include your > suggestions. (It'll need to be updated with the precise extension > type, if assigned.) > > > Cheers > > AGL > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From watsonbladd@gmail.com Sun Jan 26 16:24:06 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA801A016C for ; Sun, 26 Jan 2014 16:24:06 -0800 (PST) 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_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 tjWjzpK8r7Dz for ; Sun, 26 Jan 2014 16:24:04 -0800 (PST) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 4148A1A0169 for ; Sun, 26 Jan 2014 16:24:03 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id x13so4949997wgg.27 for ; Sun, 26 Jan 2014 16:24:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gTBFC45TNRevlbu9o4nb/FSEFlq93uLyVH6CcgMKUiE=; b=SQw9p6Lo6hX7KKO6JK4RRpzqAppE8SVTXmbNHyBJHykKvgxyD99KD9RT8TPB54kvWR p9kX3G50+OIiOly17dV9gF7AmM4YPHK29EwRCVb2ne30pQMyFvTmzjtdjOnymh6GNGwA y1XhEe/tYMXNwczFr1AIfB+1nKEYuzxc6m0S5aNGy100ldOCTz2lUQtHOfvE7ZlDuez/ lIb6xaBhZzSF1JwLMMoLktX/E6pKkwqWgMf0ub0zDzK40j5FltfM79dKhULj5RwK2yrP THj2CIR1xBSkQbiADa5sOck5PaIAc24E02Mh+igP1i8fptRscmXdVdrZMGMKX/GtESyG fzqw== MIME-Version: 1.0 X-Received: by 10.195.13.113 with SMTP id ex17mr18348790wjd.0.1390782241538; Sun, 26 Jan 2014 16:24:01 -0800 (PST) Received: by 10.194.250.101 with HTTP; Sun, 26 Jan 2014 16:24:01 -0800 (PST) In-Reply-To: References: <52E540F4.6090007@fifthhorseman.net> Date: Sun, 26 Jan 2014 16:24:01 -0800 Message-ID: From: Watson Ladd To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Jan 2014 00:24:06 -0000 On Sun, Jan 26, 2014 at 3:32 PM, Yoav Nir wrote: > On 26/1/14 7:08 PM, Daniel Kahn Gillmor wrote: >> >> 4. An older firewall is dropping the TLS 1.2 connections, because they >> fail some sanity check. (that all TLS records have 3.0 or 3.1 in the >> record header) >> Is this a "sanity check" or an "insanity check" ? :) > > > When attacks are known, it's easy to program firewalls or IPS systems to > detect them. the problem is unknown attacks. One countermeasure that is as > old as firewalls is to make a sanity check of what a protocol should look > like. This is somewhat beneficial. Most buffer overflow exploits and even > SQL injections would not pass a sanity check. So firewall validations are > written to common practice, not necessarily to RFC. How exactly does that hurt this proposal? If the server is behind the firewall and the SCVC is recognized, someone screwed up big time: not our fault, they can always disable the SCVC check, and it lets them know something is broken. If it's the client, then this is the calculation server operators get to make: kick them off, vs. enable downgrade attacks. The second part is that this behavior is highly suboptimal for permitting protocol evolution. Part of this is our fault: validating and parsing incoming data should be done with as little complexity as possible, reducing future bugs. However, it raises a big problem for TLS 1.3: something like reducing round trips might get blocked spuriously, or maybe we run into problems with big extensions etc. More clarity on what is being done here is required, or you need to tell your customers "this product can break the internet in ways unanticipated, and it is our fault". F5 was kind enough to explain why they broke the internet, and it was for a somewhat good cause. I'ld like to see future issues like this get resolved before five years of worry go by. The third part is that exploits don't necessarily fail sanity checks: Even if limited to ASCII bytes, I can most likely find a gadget that does what I need to get inside within any large codebase. Oddly enough, I've never seen a CVE where "firewall XYZ prevents exploitation" is mentioned. You would think firewall vendors would trumpet these successes if they ever happened. Or think of all the sendmail bugs exploitable by sending email to the wrong people: no firewall could ever stop them. > > Sometimes this has unintended consequences. 12 years ago, many firewalls > (including ours) would make a sanity check on TCP: we enforced the sequence > SYN--SYNACK--ACK--data. Apple introduced some version of Mac OS (I think it > was 9.2) that had a unique feaure: The first data from the client was sent > in the third packet instead of following it. For the firewall this was a > violation of TCP sanity. But as it turns out, this is not prohibited by the > TCP specs. We fixed our firewall, but I guess this broke some things. I > haven't seen this behavior again anywhere, and all versions of Mac OS > following that did not do this*. > > So I wouldn't be surprised if there are some version-intolerant firewalls > out there just as there are version intolerant servers. > > Yoav > (*) Yes, I realize that this has probably more to do with moving to a BSD > kernel than with traversing firewalls, but it is instructive that nobody > repeated this experiment. > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From yngve@spec-work.net Sun Jan 26 16:35:41 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B60EA1A00B1 for ; Sun, 26 Jan 2014 16:35:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 s2K6tROSZBKi for ; Sun, 26 Jan 2014 16:35:39 -0800 (PST) Received: from smtp.domeneshop.no (smtp.domeneshop.no [194.63.252.54]) by ietfa.amsl.com (Postfix) with ESMTP id DA9901A00A7 for ; Sun, 26 Jan 2014 16:35:38 -0800 (PST) Received: from [31.209.139.223] (port=63910 helo=lessa.lan) by smtp.domeneshop.no with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1W7aAq-0002VH-9M for tls@ietf.org; Mon, 27 Jan 2014 01:35:36 +0100 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes References: To: tls@ietf.org Date: Mon, 27 Jan 2014 01:35:34 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettesen" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.16 (Win32) Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Jan 2014 00:35:41 -0000 On Thu, 23 Jan 2014 11:06:04 +0100, Eric Rescorla wrote: > WG Members, > > This message is a call for acceptance of > http://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-01 > > As a TLS WG item. > > Please provide any comments on this action by Feb 7. Because > there has been only modest discussion of this document, the > chairs ask people who have already spoken in favor or against > this document to re-register their opinion (feel free to just say > +1 or -1 and point back to the archives.) -1 I dislike this approach for several reasons: 1) I dislike the recent tendency to use (throw) an SCSV for (at) any protocol problem showing up. At present these decisions seem to be too ad-hoc IMO. If this use of SCSVs is to continue (which I do not recommend) perhaps the WG should first define a policy for when to use them, and possibly also set aside a range of ciphersuite values for SCSVs and interpretation of unknown SCSVs? E.g. should some SCSVs be considered critical, and should a server that knows about SCSVs but which does not understand a critical SCSV abort the connection? 2) The use of this SCSV require both client and server to be updated to understand the SCSV. The deployment of such a fix is going to take a minimum of 5-10 years (The renego patch, fixing a major security vulnerability, have only recently passed 80%, more than 3 years after it was released). I would prefer a solution that only require one party, the client, to be updated. 3) Involving two parties in determining what to do about the fallback issue will complicate implementations, and also risk interoperability problems. There is one party that specifically knows that it has been falling back, and who can (and IMO should) be making the decisions: the client. The reason for the fallback (assuming no client bugs) may be normal network issues, server non-compliance, non-compliant intermediates, or an MITM attack. The only cases in which an SCSV might help, is in the case of non-compliant intermediates and MITM attacks, but that requires (as mentioned above) that the server supports the SCSV indication. If the server does not support the SCSV the client will have to assume that the server is just non-compliant and continue the connection using an older protocol, or use other means to try to discover if the connection is being interfered with before trusting it. In my opinion the WG should not, at this stage, take on a specific solution as as work item, but should instead explore, as an I-D (by a neutral editor), the problem space and alternative proposals for solving the issues, including SCSVs, proxy indications (such as my renego-based proposal), or recommending "no fallback". That would collect information about the problems and proposals in a single document, and make the matter more readily accessible to new readers than trying to review several years of discussion threads in the WG mailing list. As for the time aspect, using 6-12 months to produce such a document might create a better understanding of the problem and solution, and would not delay the 5-10 year deployment by much (for that matter, there are still many SSL v3-only servers 15 years after TLS 1.0 was published, so deployment might be 10-20 years instead; unless the WG decides to set hard deadlines and to risk "breaking the internet"). A couple of questions that might be investigated in such a document includes: Should the solution support SSL v3-only servers? TLS 1.0 servers without TLS Extension support? Should SCSV capable servers be required to implement TLS 1.2? Can the indication be implemented as an extension instead? and so on. Sincerely, Yngve N. Pettersen -- Using Opera's mail client: http://www.opera.com/mail/ From SRS0=Ipyw=XB=acm.org=bmoeller@srs.kundenserver.de Mon Jan 27 01:44:03 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E250D1A0188 for ; Mon, 27 Jan 2014 01:44:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.464 X-Spam-Level: X-Spam-Status: No, score=-1.464 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535, 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 uFX1c4S1G29d for ; Mon, 27 Jan 2014 01:44:02 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF0C1A0184 for ; Mon, 27 Jan 2014 01:44:01 -0800 (PST) Received: from mail-oa0-f46.google.com (mail-oa0-f46.google.com [209.85.219.46]) by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis) id 0MLOoU-1W7AVD2MqY-000ZwF; Mon, 27 Jan 2014 10:43:58 +0100 Received: by mail-oa0-f46.google.com with SMTP id n16so6464064oag.33 for ; Mon, 27 Jan 2014 01:43:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xhEQFeT1ppqUEz875AeYdhH9aWAcOjY0ys3H6hcoZH0=; b=gWl3F0sQr4NQWqXFCwrApge31pqXLSX8sX3gFYRqA5SkSDaHuJbZZvVmTsj3/anRiw wPAu/lUPotDuewVq4RySbzO2Y3aXC3DvreRUyC1q7e4Q8NvDxgU6Yr6ZJrTbRaZil/Y5 A7iNfEdpsn3BuZWgeEpu3tKZZY7sKTBa2+aw6eOw6ddspOYZGcSIqlpRTUb9blgDuaF2 Q4wLHGi7oJ4JZ+Wm5gJGYuylelGhOlg2xgVEUrTjPBKr/D+/tW1t8igPc+2Eqfrbh22K IbUhjk3A+1JHvCARgCX3XqaOaEpOaOkthW1iD8zbeq8uDpuebw3SAlB7s/g7DkX70hKh +48w== MIME-Version: 1.0 X-Received: by 10.182.161.1 with SMTP id xo1mr2015303obb.19.1390815830263; Mon, 27 Jan 2014 01:43:50 -0800 (PST) Received: by 10.60.170.239 with HTTP; Mon, 27 Jan 2014 01:43:50 -0800 (PST) In-Reply-To: References: <20140124210534.C77871ABCA@ld9781.wdf.sap.corp> <52E2DA85.4010705@fifthhorseman.net> Date: Mon, 27 Jan 2014 10:43:50 +0100 Message-ID: From: Bodo Moeller To: Geoffrey Keating Content-Type: multipart/alternative; boundary=f46d04462e3682cd2204f0f08bb7 X-Provags-ID: V02:K0:5jhPs8ZsCViCD61i6u3vK1/af1euLHdDHrV6ZlABYmt 6vCrQsKKNiI1va/IyW0Wx2B2vunFwUhj8eu1x0ksZbkJ6yrsUq bMiRsbswj8rhcudtiaA7oEUwasfBK9i+owDHYkfT1VhP2h8yqJ Y5+st8xfYlQ74a2HbZiS5to9EhZeuMrL5qgYLT95eWf930l8ni jpvkiLkhuoIWhpbsn53CIFGmMufGzTBfcdvsA0GvEOjWZqrIxB 140qTMcQ4TFcypANVoB28AFvZ3xJNW7T5TPagoF+BudFpaQNfz tVx4mdRV8WeuHbwlxusMngE8WavXBpZG/jTn5K2YuvR8UVYqjl 4IMxAk8uhXMhwm25sg6t0TH5kEUhPyFNPz1lU/UdhrCsEorhuA uYjeiiajgTD9Q3iMieMGXX45qY9PC3zxQADyU54KdxI+VpyJ/1 nRNrX Cc: "tls@ietf.org" Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Jan 2014 09:44:49 -0000 --f46d04462e3682cd2204f0f08bb7 Content-Type: text/plain; charset=ISO-8859-1 Geoffrey Keating : > > Another way to phrase this is that the client is saying "I think you > are an old buggy server. If you think you are not an old buggy > server, please abort." > > The implicit assumption is that there will not be new buggy servers. > I think that's the greatest weakness of this concept. New buggy servers that work exactly like the old buggy servers, and thus require the same workarounds to achieve interoperability, are sort of out of scope for this measure. The spec changes essentially nothing about how you work with these: you send an additional cipher-suite value, but expect such servers to ignore it. They really are old servers. If "new" means servers with an updated implementation including support for this SCSV, the hope is that once the spec has sufficient client-side deployment, this can prevent the deployment of (certain) buggy servers, because they'll fail standard interoperability testing. If the new buggy server honors the SCSV, the protocol downgrade workaround that exist to deal with old buggy servers won't hide the problem as it otherwise might. Bodo --f46d04462e3682cd2204f0f08bb7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Geof= frey Keating <geoffk@geoffk.org>:

Another way to phrase this is that the client is saying "I think= you
are an old buggy server. =A0If you think you are not an old buggy
server, please abort."

The implicit assumption is that there will not be new buggy servers.
I think that's the greatest weakness of this concept.
=
New buggy servers that work exactly like the old buggy serve= rs, and thus require the same workarounds to achieve interoperability, are = sort of out of scope for this measure. =A0 The spec changes essentially not= hing about how you work with these: you send an additional cipher-suite val= ue, but expect such servers to ignore it. =A0They really are old servers.

If "new" means servers with an updated implem= entation including support for this SCSV, the hope is that once the spec ha= s sufficient client-side deployment, this can prevent the deployment of (ce= rtain) buggy servers, because they'll fail standard interoperability te= sting. =A0If the new buggy server honors the SCSV, the protocol downgrade w= orkaround that exist to deal with old buggy servers won't hide the prob= lem as it otherwise might.

Bodo

--f46d04462e3682cd2204f0f08bb7-- From nmav@redhat.com Mon Jan 27 02:00:55 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA8D1A0186 for ; Mon, 27 Jan 2014 02:00:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.437 X-Spam-Level: X-Spam-Status: No, score=-7.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, 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 J194xsWceTD6 for ; Mon, 27 Jan 2014 02:00:53 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id E14391A011C for ; Mon, 27 Jan 2014 02:00:53 -0800 (PST) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s0RA0nkx000918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 27 Jan 2014 05:00:49 -0500 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s0R9U1NG032451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 27 Jan 2014 04:30:02 -0500 Message-ID: <1390815001.3812.10.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Robert Ransom Date: Mon, 27 Jan 2014 10:30:01 +0100 In-Reply-To: References: <87ob3456s1.fsf@latte.josefsson.org> <1390466373.20176.8.camel@dhcp-2-127.brq.redhat.com> <52E2B937.5080502@polarssl.org> <2A0EFB9C05D0164E98F19BB0AF3708C711EB9F2DB6@USMBX1.msg.corp.akamai.com> <282749297.5013598.1390639819914.JavaMail.root@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Cc: Manuel =?ISO-8859-1?Q?P=E9gouri=E9-Gonnard?= , tls@ietf.org Subject: Re: [TLS] Curve25519 in TLS and Additional Curves 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, 27 Jan 2014 10:00:55 -0000 On Sat, 2014-01-25 at 01:18 -0800, Robert Ransom wrote: > > You seem to imply that following conventions established during the years is > > unecessary. That could be true, but your only point of backing that up is > > that a library that implements this curve uses the little endian format. > Several libraries implement Curve25519 scalar multiplication in > constant time, with varying degrees of portability and efficiency. > All of them operate on public and secret keys in little-endian format. I still cannot see your argument here. Is there a requirement for this curve to be implemented or do these libraries use little-endian format because it suits them better (e.g., they target little endian systems)? This is an honest question as I don't know the answer. > > Why force any other > > library that will implement this curve handle its points in a special way? > Does this mean that you intend to implement Curve25519 using a generic > bignum library? How will your implementation (attempt to) avoid > leaking information about key material to a side-channel attacker? Do you mean about power analysis (e.g., constant power consumption or time)? Why would that matter for the protocol in question? As I understand the document specifies additional curves for ephemeral key exchange (ECDHE), so side channels are not a threat. > It is about standardizing a curve which has a well-established > convention of storing and transmitting keys in little-endian format. I believe that software does the transmitting rather than the curve itself, so that I think that my point of not standardizing software but a curve is still valid. regards, Nikos From SRS0=Ipyw=XB=acm.org=bmoeller@srs.kundenserver.de Mon Jan 27 03:03:38 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC991A01CC for ; Mon, 27 Jan 2014 03:03:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.464 X-Spam-Level: X-Spam-Status: No, score=-1.464 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535, 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 35XRgEk_Db0K for ; Mon, 27 Jan 2014 03:03:36 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by ietfa.amsl.com (Postfix) with ESMTP id A42C91A017A for ; Mon, 27 Jan 2014 03:03:35 -0800 (PST) Received: from mail-oa0-f53.google.com (mail-oa0-f53.google.com [209.85.219.53]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0Lm6Wf-1VYxFq3rW5-00ZJFk; Mon, 27 Jan 2014 12:03:32 +0100 Received: by mail-oa0-f53.google.com with SMTP id m1so6467771oag.40 for ; Mon, 27 Jan 2014 03:03:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nDzmRg2xYXr3oh74hPTSVYcua+eDOIXmxBLEELRykRQ=; b=aB6Kqj1GNN2GUpqYy5CWH7ZBoWE5HfRqGJAXcm0BgeQRVUXquQMHsTnNcfi6uxPXaM BkZwpWFOODesq2stsbnpgMj07kPmtVwLgU8SiPivLxY63ptUNuCUXiYhm8tmDSfr/p/s cUjchuug895X+MUSW5C/APICBR68/TNSha0L47r48pFrOWcn05IcScURU7ZreXJwHBrf bbZFDBWHUVsjBGxrHEBzRBiZSeREEBVUxFY6rXdgoviJD2j/bEIx/RwGaNBVrGeDtYQw QuPIIEVMqS/jhXVLOVpGvpWHfL3NIN3x7K3yMCoJ7CEV43rD8XauvVaW7GX9djsgTKL4 JN7g== MIME-Version: 1.0 X-Received: by 10.182.113.195 with SMTP id ja3mr1113189obb.46.1390820609469; Mon, 27 Jan 2014 03:03:29 -0800 (PST) Received: by 10.60.170.239 with HTTP; Mon, 27 Jan 2014 03:03:29 -0800 (PST) In-Reply-To: References: Date: Mon, 27 Jan 2014 12:03:29 +0100 Message-ID: From: Bodo Moeller To: "Yngve N. Pettesen" Content-Type: multipart/alternative; boundary=089e013d0db05fb59004f0f1a84f X-Provags-ID: V02:K0:BE9K+cZOETrrI/jIqc5RX2FKNNw8eT44RV+KHd9y7iz 8qnSKXsIQD6OIgv1C/8TUT8A/ujHH1G1KQqr67W33jFL4Pq2CM BbIA21B6ngyyHYMQeQB60MiTZhwtfgfdcyVQ/AdqdmfEnXp3IS 0lJrb1rIStZgOuFKfK+Eo3dpClDjAH+nNA/LRZI7TSIMOF56i6 KnMdQR1vQqzfN+j0dZc7oUdK48OUiUO9GcJ1Ls3AyKg11rBIL+ DMWYvgO8eRP4AkSa3vKZ603dtX+dXdvhPA/wOj6oht+LH3JuX5 0zT+ypTns2SCxYj5omjGxDGY1sF/iH5gj3oDUGG/urWArMPXGe ZKtCsJQxJoDkGedXu8bfqzqhZ5kzv1RozuxV9FcvQe6yNdU9cO K9RrMj7S2I+0HQI5jU93S8K+JLFToAxJsMCfZ9/LSQNQ2HcdJa tYEvf Cc: "tls@ietf.org" Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Jan 2014 11:03:38 -0000 --089e013d0db05fb59004f0f1a84f Content-Type: text/plain; charset=ISO-8859-1 Yngve N. Pettesen : 1) I dislike the recent tendency to use (throw) an SCSV for (at) any > protocol problem showing up. At present these decisions seem to be too > ad-hoc IMO. If this use of SCSVs is to continue (which I do not recommend) > perhaps the WG should first define a policy for when to use them, and > possibly also set aside a range of ciphersuite values for SCSVs and > interpretation of unknown SCSVs? E.g. should some SCSVs be considered > critical, and should a server that knows about SCSVs but which does not > understand a critical SCSV abort the connection? > I don't really like SCSVs either -- they are a last-resort measure: using TLS extensions instead certainly would be cleaner, but we resort to an SCSV so that we can send the signal even if we suspect that the server might not tolerate any Client Hello extensions. (Accordingly, I don't see a use case for critical SCSVs. Only updated implementations would know which SCSVs are to be considered critical; but with updated implementations, we shouldn't need SCSVs in the first place. Possibly there'd be a cause for critical TLS extensions instead, but we'd have a similar problem about retroactively declaring something "critical": existing implementations just won't know about this. If you want the client to be able to insist on a particular extension, have the server send it back when it sees it: that's something you can check in the client, without depending on changes to the server implementation. Of course you could, say, specify a new TLS extension that allows negotiating a range of critical TLS extensions, or specify such a range for all TLS 1.3 connections, but my first instinct is that anything like that is overly complicated given what it can achieve.) > 2) The use of this SCSV require both client and server to be updated to > understand the SCSV. The deployment of such a fix is going to take a > minimum of 5-10 years (The renego patch, fixing a major security > vulnerability, have only recently passed 80%, more than 3 years after it > was released). I would prefer a solution that only require one party, the > client, to be updated. > Your 5-10 year estimate is for wide deployment. Narrower deployment can happen much quicker: once you update your client, you get the expected protection for all connections to those servers that have been updated. Even if that's just 1% of *all* servers, that 1% might include those servers you care about most. A percentage of servers isn't a very useful metric (and even a percentage of appropriately specified "sessions" couldn't do justice to the fact that security will be much more important for some of these than for others). I would prefer a solution that only require one party, the client, to be > updated. > I think everyone would prefer that; note that the TLS_FALLBACK_SCSV spec doesn't preclude it. Any client-only solution is still available, and if the client doesn't need TLS_FALLBACK_SCSV (such as because it doesn't attempt any fallback reconnections in the first place), it doesn't have to send it. Server-side support for TLS_FALLBACK_SCSV gives clients a particular option: I think this option is currently useful, and expect that it may be useful again when TLS 1.3 deployment starts, but certainly any (intermediate) state in which clients don't have to make use of it would be nicer. > > In my opinion the WG should not, at this stage, take on a specific > solution as as work item, but should instead explore, as an I-D (by a > neutral editor), the problem space and alternative proposals for solving > the issues, including SCSVs, proxy indications (such as my renego-based > proposal), or recommending "no fallback". That would collect information > about the problems and proposals in a single document, and make the matter > more readily accessible to new readers than trying to review several years > of discussion threads in the WG mailing list. As for the time aspect, using > 6-12 months to produce such a document might create a better understanding > of the problem and solution, and would not delay the 5-10 year deployment > by much (for that matter, there are still many SSL v3-only servers 15 years > after TLS 1.0 was published, so deployment might be 10-20 years instead; > unless the WG decides to set hard deadlines and to risk "breaking the > internet"). > I don't agree with your assessment of the impact of a deployment delay, as discussed further above. The TLS_FALLBACK_SCSV spec exists specifically *because* we want to be able to fix security for those connections going to updated servers long before we can fix security with *all* servers. If we could just get all servers fixed (or give up interoperability with the unfixed servers), we wouldn't need it. (For example, if an updated server supports the extension from draft-gutmann-tls-encrypt-then-mac-05, TLS_FALLBACK_SCSV can prevent falling back to a handshake with no extensions, and thus without that protocol fix. With old servers, we might still have to use unfixed CBC ciphersuites.) > A couple of questions that might be investigated in such a document > includes: Should the solution support SSL v3-only servers? TLS 1.0 servers > without TLS Extension support? Should SCSV capable servers be required to > implement TLS 1.2? Can the indication be implemented as an extension > instead? and so on. > In case it's not clear, draft-bmoeller-tls-downgrade-scsv-01 is based on the assumption that we do need to allow interoperability with SSL-3.0-only servers and with extension-intolerant servers (because that's what various clients currently do), and thus couldn't rely on an extension only. (I'd expect any server actually implementing TLS_FALLBACK_SCSV to also include extension support, but it's about interoperability with servers that aren't there yet.) In the interest of simplicity -- reducing the burden on server implementations --, the feature is specified as an SCSV only, without an equivalent TLS Extensions. As it happens, this also reduces the on-the-wire overhead (2 bytes for the SCSV vs. at least 4 bytes for an empty extension). Bodo --089e013d0db05fb59004f0f1a84f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yngv= e N. Pettesen <yngve@spec-work.net>:

1) I dislike the recent tendency to use (throw) an SCSV for (at) any protoc= ol problem showing up. At present these decisions seem to be too ad-hoc IMO= . If this use of SCSVs is to continue (which I do not recommend) perhaps th= e WG should first define a policy for when to use them, and possibly also s= et aside a range of ciphersuite values for SCSVs and interpretation of unkn= own SCSVs? E.g. should some SCSVs be considered critical, and should a serv= er that knows about SCSVs but which does not understand a critical SCSV abo= rt the connection?

I don't really like SCSVs either -- th= ey are a last-resort measure: using TLS extensions instead certainly would = be cleaner, but we resort to an SCSV so that we can send the signal even if= we suspect that the server might not tolerate any Client Hello extensions.=

(Accordingly, I don't see a use case for critical S= CSVs. =A0Only updated implementations would know which SCSVs are to be cons= idered critical; but with updated implementations, we shouldn't need SC= SVs in the first place. =A0Possibly there'd be a cause for critical TLS= extensions instead, but we'd have a similar problem about retroactivel= y declaring something "critical": existing implementations just w= on't know about this. =A0If you want the client to be able to insist on= a particular extension, have the server send it back when it sees it: that= 's something you can check in the client, without depending on changes = to the server implementation. =A0Of course you could, say, specify a new TL= S extension that allows negotiating a range of critical TLS extensions, or = specify such a range for all TLS 1.3 connections, but my first instinct is = that anything like that is overly complicated given what it can achieve.)



2) The use of this SCSV require both client and server to be updated to und= erstand the SCSV. The deployment of such a fix is going to take a minimum o= f 5-10 years (The renego patch, fixing a major security vulnerability, have= only recently passed 80%, more than 3 years after it was released). I woul= d prefer a solution that only require one party, the client, to be updated.=

Your 5-10 year estimate is for wide deploy= ment. =A0Narrower deployment can happen much quicker: once you update your = client, you get the expected protection for all connections to those server= s that have been updated. =A0Even if that's just 1% of *all* servers, t= hat 1% might include those servers you care about most. =A0A percentage of = servers isn't a very useful metric (and even a percentage of appropriat= ely specified "sessions" couldn't do justice to the fact that= security will be much more important for some of these than for others).


=A0I would prefer a so= lution that only require one party, the client, to be updated.

I think everyone would prefer that; = note that the TLS_FALLBACK_SCSV spec doesn't preclude it. =A0Any client= -only solution is still available, and if the client doesn't need TLS_F= ALLBACK_SCSV (such as because it doesn't attempt any fallback reconnect= ions in the first place), it doesn't have to send it. =A0Server-side su= pport for TLS_FALLBACK_SCSV gives clients a particular option: I think this= option is currently useful, and expect that it may be useful again when TL= S 1.3 deployment starts, but certainly any (intermediate) state in which cl= ients don't have to make use of it would be nicer.

=A0

In my opinion the WG should not, at this stage, take on a specific solution= as as work item, but should instead explore, as an I-D (by a neutral edito= r), the problem space and alternative proposals for solving the issues, inc= luding SCSVs, proxy indications (such as my renego-based proposal), or reco= mmending "no fallback". That would collect information about the = problems and proposals in a single document, and make the matter more readi= ly accessible to new readers than trying to review several years of discuss= ion threads in the WG mailing list. As for the time aspect, using 6-12 mont= hs to produce such a document might create a better understanding of the pr= oblem and solution, and would not delay the 5-10 year deployment by much (f= or that matter, there are still many SSL v3-only servers 15 years after TLS= 1.0 was published, so deployment might be 10-20 years instead; unless the = WG decides to set hard deadlines and to risk "breaking the internet&qu= ot;).

I don't agree with your assessment of = the impact of a deployment delay, as discussed further above. =A0The TLS_FA= LLBACK_SCSV spec exists specifically *because* we want to be able to fix se= curity for those connections going to updated servers long before we can fi= x security with *all* servers. =A0If we could just get all servers fixed (o= r give up interoperability with the unfixed servers), we wouldn't need = it.

(For example, if an updated server supports the extensi= on from draft-gutmann-tls-encrypt-then-mac-05, TLS_FALLBACK_SCSV can preven= t falling back to a handshake with no extensions, and thus without that pro= tocol fix. =A0With old servers, we might still have to use unfixed CBC ciph= ersuites.)



A couple of questions that might be investigated in such a document include= s: Should the solution support SSL v3-only servers? TLS 1.0 servers without= TLS Extension support? Should SCSV capable servers be required to implemen= t TLS 1.2? Can the indication be implemented as an extension instead? and s= o on.

In case it's not clear, draft-bmoeller= -tls-downgrade-scsv-01 is based on the assumption that we do need to allow = interoperability with SSL-3.0-only servers and with extension-intolerant se= rvers (because that's what various clients currently do), and thus coul= dn't rely on an extension only. =A0 (I'd expect any server actually= implementing TLS_FALLBACK_SCSV to also include extension support, but it&#= 39;s about interoperability with servers that aren't there yet.) =A0In = the interest of simplicity -- reducing the burden on server implementations= --, the feature is specified as an SCSV only, without an equivalent TLS Ex= tensions. =A0As it happens, this also reduces the on-the-wire overhead (2 b= ytes for the SCSV vs. at least 4 bytes for an empty extension).

Bodo



=
--089e013d0db05fb59004f0f1a84f-- From SRS0=Ipyw=XB=acm.org=bmoeller@srs.kundenserver.de Mon Jan 27 03:41:05 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEEE71A01E8 for ; Mon, 27 Jan 2014 03:41:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.464 X-Spam-Level: X-Spam-Status: No, score=-1.464 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535, 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 nbMyKMLcd88r for ; Mon, 27 Jan 2014 03:41:04 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id 40D161A01E4 for ; Mon, 27 Jan 2014 03:41:04 -0800 (PST) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0MbsGc-1VoQiz1Qn8-00JhFz; Mon, 27 Jan 2014 12:41:00 +0100 Received: by mail-ob0-f181.google.com with SMTP id va2so6266206obc.40 for ; Mon, 27 Jan 2014 03:40:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uLshMShztkqcl6w5WydKqU17DB/GLMLuMJXlAtPr3z4=; b=JR2lLdbB0i0B5QQnfbbMwkC4mwdRRH3I9712qIqZjezHffWF8/IT/z7X43v+MQbPG5 siIuLsQtlycZTacSVay6C7Xi78VJvp7SB//h8CJCOoIVrLxGjMyZ82kSKsO9Lc+WQq8h coFMHn7p2NhLN2TNOzWdgVZMF9Yn1OXVMc/wQQlkqgU/pNFaUKWjGgZywf8bu1CRrp9q ZxcuZjuqfkEvXeRszc9R90X2+XMOBYowUPK6t9SwVKjdWXe7f7SPPM8/CcsdhSJ45N8t SiBc9khVHanJJsOmLyEBt+HPG0KVPk1+rv5d5k/wJ7K0CVHuTXlH8Vgha41C39ecG+RL PhkA== MIME-Version: 1.0 X-Received: by 10.60.119.70 with SMTP id ks6mr803203oeb.45.1390822855868; Mon, 27 Jan 2014 03:40:55 -0800 (PST) Received: by 10.60.170.239 with HTTP; Mon, 27 Jan 2014 03:40:55 -0800 (PST) In-Reply-To: <20140125042425.230961ABCA@ld9781.wdf.sap.corp> References: <52E2DA85.4010705@fifthhorseman.net> <20140125042425.230961ABCA@ld9781.wdf.sap.corp> Date: Mon, 27 Jan 2014 12:40:55 +0100 Message-ID: From: Bodo Moeller To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=047d7b33c91445def704f0f22e16 X-Provags-ID: V02:K0:M/wxpVb9stnA3RURq2N4JwkI/+v8Q4o4YlhjC13hzCF pi7k+G5S8+/SYJtqN0DQsAKpfyUEn75ELWDCu1vbZ/F/soCDOZ kay6lF3pRnsc5ar5YBtwhzNcmzRHuhyQGP0666FOCHE9NGLL73 ucnlwHsdEQHi/5uKSMBjlwsJ1ahJzQ8SxIHsqrE0Lg0ElAzdwm 7sOQzIydQTnOR0KPOq9a25x7wx+DyLJNx3HzWhKAGVAqyReDI9 ePz5cUP0rx1fmyGxNCX0r2h/432Xfn54cF2ejJlBzqgQjoX9YH b1DU2Vnk/xc1zK5y1rd5PF8r152QygtfmnkVSJw2M6i57P6rvj 5/7622X892d8uWduhyszM7ugJ50t194sS74Xlp3MMdGr2KZJR1 3v9Ra3b8FvQ0RUZKIaJHbQNH5D1+WISzPLVExazCs7oZVGHckL CuLR/ Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Jan 2014 11:41:06 -0000 --047d7b33c91445def704f0f22e16 Content-Type: text/plain; charset=ISO-8859-1 Martin Rex : > Daniel Kahn Gillmor wrote: > > > By transmitting this SCSV, the client is saying to the server "just so > > you know, i tried a better protocol, but it didn't work -- if you meant > > to accept better protocols, then someone is messing with us, please > abort." > > > > The server knows whether it believes it can accept better protocols, so > > it is in the right position to make this call. > > The _only_ reasonable server response of a TLS server that supports TLSv1.2 > to a ClientHello that contains an SCSV which indicates that the client > (a) supports TLSv1.2 and (b) would prefer to use TLSv1.2 > is a ServerHello with server_version=TLSv1.2. Well, I guess that this sort of would work: I'd still expect many connection failures (if a middle box doesn't like TLS 1.2 in the Client Hello, why would it like it in the Server Hello and in actual use?), but then with the TLS_FALLBACK_SCSV spec, failures are expected in the similar scenario too. Of course, a TLS_FALLBACK_SCSV-induced early abort is computationally much cheaper than proceeding with a handshake and running into a failure later. Also note that TLS_FALLBACK_SCSV as specified in draft-bmoeller-tls-downgrade-scsv-01 is *not* about having the client indicate to the server that it supports TLS 1.2 and would like to use that particular protocol version. To keep the protocol as simple as possible and entirely *avoid* servers-side heuristics, the SCSV simply indicates that the client has fallen back below the protocol version it would normally try to use: maybe it would really want to use TLS 1.3, maybe it would really want to use TLS 1.1 (but has fallen back to 1.0). Trying to do a secondary protocol version negotiating using SCSVs as sketched by you would be much more complex than handling TLS_FALLBACK_SCSV, with unclear practical advantages (see above). Of course, TLS_FALLBACK_SCSV won't prevent you from experimenting with that kind of fix. The caveat is that where the current spec has the server look at ClientHello.client_version, server implementations would have to look at the overridden client_version value instead. Bodo --047d7b33c91445def704f0f22e16 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Mart= in Rex <mrex@sap.com>:
Daniel Kahn Gillmor wrote:
=A0=
> By transmitting this SCSV, the client is saying to the server "ju= st so
> you know, i tried a better protocol, but it didn't work -- if you = meant
> to accept better protocols, then someone is messing with us, please ab= ort."
>
> The server knows whether it believes it can accept better protocols, s= o
> it is in the right position to make this call.
<= div>=A0
The _only_ reasonable server response of a TLS server that supports T= LSv1.2
to a ClientHello that contains an SCSV which indicates that the client
(a) supports TLSv1.2 and (b) would prefer to use TLSv1.2
is a ServerHello with server_version=3DTLSv1.2.

=
Well, I guess that this sort of would work: I'd still expect many = connection failures (if a middle box doesn't like TLS 1.2 in the Client= Hello, why would it like it in the Server Hello and in actual use?), but t= hen with the=A0= TLS_FALLBACK_SCSV spec, failures are expected in the similar scenario too. = =A0Of course, a=A0TLS_FALLBACK_SCSV-induced early abort is computationally much che= aper than proceeding with a handshake and running into a failure later.

Also n= ote=A0th= at=A0TLS= _FALLBACK_SCSV as specified in=A0draft-bmoeller-tls-downgrade-scsv-01 is *not* about having the cl= ient indicate to the server that it supports TLS 1.2 and would like to use = that particular protocol version. =A0To keep the protocol as simple as poss= ible and entirely *avoid* servers-side heuristics, the SCSV simply indicate= s that the client has fallen back below the protocol version it would norma= lly try to use: maybe it would really want to use TLS 1.3, maybe it would r= eally want to use TLS 1.1 (but has fallen back to 1.0). =A0Trying to do a s= econdary protocol version negotiating using SCSVs as sketched by you would = be much more complex than handling=A0TLS_FALLBACK_SCSV, with unclear practical advantages (see above).

Of course,=A0TLS_FALLBACK_SCSV won'= t prevent you from experimenting with that kind of fix. =A0The caveat is th= at where the current spec has the server look at=A0ClientHello.client_version, server implementati= ons would have to look at the overridden client_version value instead.

Bodo
<= div>
=
--047d7b33c91445def704f0f22e16-- From mrex@sap.com Mon Jan 27 07:07:47 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2781A0230 for ; Mon, 27 Jan 2014 07:07:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 1YhK34c1SwGO for ; Mon, 27 Jan 2014 07:07:44 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 809021A0143 for ; Mon, 27 Jan 2014 07:07:44 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s0RF7dsE010399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 27 Jan 2014 16:07:39 +0100 (MET) In-Reply-To: To: Watson Ladd Date: Mon, 27 Jan 2014 16:07:39 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140127150739.45B671ABC9@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "tls@ietf.org" Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 15:07:47 -0000 Watson Ladd wrote: > > If a server is buggy it shouldn't pretend to offer TLS 1.2 support. > If you don't notice this bug, what are you doing when testing? > [...] > > Furthermore, I think we should have a name-and-shame lab if we are > going to be considering not addressing security issues because of > interop. > [...] > > If you don't want to do this, then you shouldn't offer your product > as supporting TLS. > [...] > > Why exactly wouldn't a serious implementor be doing this already? I don't know why vendors are not testing in any reasonable fashion before shipping, but I know that it is happening regularly. Microsoft goofed the RSA premaster secret version check for the renegotiation handshake in Windows 7 (the first version of SChannel that supports TLSv1.2): http://www.ietf.org/mail-archive/web/tls/current/msg08139.html The TLS WG knew very well that there were serious interop problems in the installed base about the RSA Premaster secret version check and that these interop problems lead to handshake failures. The TLS WG also knew that the security of TLS does not depend on RSA premaster secret client_version number, because it this additional version number appears only in static RSA key exchanges, it does not appear in DH and DHE key exchanges. Now in spite of knowing this, the TLS WG added s not-well-baked text to the TLSv1.2 specification recommending that servers be anal about the RSA premaster secret and abort the TLS handshake in a knee-jerk reaction: https://tools.ietf.org/html/rfc5246#page-59 and Microsoft's SChannel is (a) anal about the check and (b) got the check wrong for the renegotiation handshake in Windows 7 and is actively causing painful and unnecessary interop problems at zero benefit: http://www.ietf.org/mail-archive/web/tls/current/msg09417.html -Martin From mrex@sap.com Mon Jan 27 07:30:23 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA131A02D9 for ; Mon, 27 Jan 2014 07:30:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 k9tr2KC5Yg2j for ; Mon, 27 Jan 2014 07:30:18 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 0EDB91A029B for ; Mon, 27 Jan 2014 07:29:58 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s0RFTu27020432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 27 Jan 2014 16:29:56 +0100 (MET) In-Reply-To: To: Yoav Nir Date: Mon, 27 Jan 2014 16:29:56 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140127152956.460001ABC9@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "tls@ietf.org" Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 15:30:23 -0000 Yoav Nir wrote: > > I'm not opposed to this document, but we should be realistic as to what > this solution can accomplish. > > Also, older servers will not recognize the SCSV and ignore it. So to > have this extension add any value, all of the following much be true: > - an updated server > - an updated client > - Something that causes the negotiation to fail. This something could > be the client, the server, or something in between. The goal of this > extension is to catch the something in the middle. You're missing an even more important pre-requisite. This SCSV will only provide any value for application clients that are actually implementing a reconnect fallback logic at the application level. A fallback reconnect can not be transparently implemented by a TLS implementation, because it requires a seperate and new connection to be established, and any application-level protocol handshakes (such as a HTTP CONNECT proxy traversal or the application protocol exhanges that happen before and include "STARTTLS". The vast majority of programmatic TLS clients does still does not have any reconnect fallback logic, and would have zero benefits from this proposal. A modified extension that allows the server to continue the handshake with a TLSv1.2 ServerHello, could be processed transparently within the TLS client implementation and provide immediate benefits to TLS clients that do not have any application-level reconnect fallback. What you also have to keep in mind is that the reconnect fallback that has been implemented&shipped was quite brittle/flaky, and reconnect fallbacks often happen unnecessarily because of bugs in the clients connection handling (keep in mind that this is app-level reconnect fallback logic, since this can not be transparently hidden within TLS): https://bugzilla.mozilla.org/show_bug.cgi?id=450280#c3 I know that Microsoft Internet Explorer has similar problems in its client-side app-level connection state handling, which can already cause connection failures (and white pages/frames). -Martin From mike-list@pobox.com Mon Jan 27 09:11:07 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE8E1A037B for ; Mon, 27 Jan 2014 09:11:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 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_NONE=-0.0001, RP_MATCHES_RCVD=-0.535, 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 cemoqXf6SLV9 for ; Mon, 27 Jan 2014 09:10:59 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by ietfa.amsl.com (Postfix) with ESMTP id 757601A02E4 for ; Mon, 27 Jan 2014 09:10:59 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 717BFFFC0; Mon, 27 Jan 2014 12:10:55 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=r29ExdvJorCK CgyRkiBAaHOK1gk=; b=pioy9kRt6y/2vPbuOYlQGN2TarhWfabEVz9LO86EKpKo nzjddyiX39N09ntVUeyrobA05J5SQxhuwmsR1vUb8qQM8iBFJHY5mKrKg3spfI47 uXngj4E+Ap1Beu0tX5F/QKn4Hu/q8lmBmAv5WPJ8LDPI8k4jNb+DKxAljB8Kjsc= 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=fUhtoM 1A5IdK493fRqJRifw1JcmxpStN7EkGoF7zgTTZUTcl5r7gqJC8VTzi9KOTjya+Vm ya3NXAKMCy+UKo0+eNMXtrP/lfURvy+kn1P1KzLiGQkr58cbvKxa7HQVONSBMrlP L//UGynUD0PAavrGT8esQVDRBqXYF/dW6puzw= Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 6724EFFBE; Mon, 27 Jan 2014 12:10:55 -0500 (EST) Received: from iMac.local (unknown [24.234.153.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 100D3FFBC; Mon, 27 Jan 2014 12:10:53 -0500 (EST) Message-ID: <52E6931C.6030604@pobox.com> Date: Mon, 27 Jan 2014 09:10:52 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Bodo Moeller References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: FB0ED2F0-8775-11E3-A4C7-873F0E5B5709-38729857!a-pb-sasl-quonix.pobox.com Cc: "tls@ietf.org" Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Jan 2014 17:11:07 -0000 Bodo Moeller wrote: > > I don't really like SCSVs either -- they are a last-resort measure: > using TLS extensions instead certainly would be cleaner, but we resort > to an SCSV so that we can send the signal even if we suspect that the > server might not tolerate any Client Hello extensions. Then we really don't want to define TLS_FALLBACK_SCSV at all since it's too specific. The SCSV we really need is one that indicates a belief by the client that the server is intolerant to extensions. The downgrade protection can be a normal extension, and a client would only resort to sending the TLS_NO_EXTENSIONS_SCSV if it gets pushed all the way back to TLS v1.0 w/o extensions or SSLv3. Mike From mike-list@pobox.com Mon Jan 27 09:22:33 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9A951A0141 for ; Mon, 27 Jan 2014 09:22:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 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_NONE=-0.0001, RP_MATCHES_RCVD=-0.535, 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 Ns_wD4b0jGsX for ; Mon, 27 Jan 2014 09:22:31 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by ietfa.amsl.com (Postfix) with ESMTP id 474901A0230 for ; Mon, 27 Jan 2014 09:22:31 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 86B3AF080; Mon, 27 Jan 2014 12:22:28 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=eKGGLKQj6Ilk 56/FUH6o769cQvY=; b=xeT19FgFlYnJfvSCaV3bWnZmK9ZDrIZGerO7XGCkwbYK S3yRFV4GHSuo11GoAC/xhhvtnNhZHqazvrbrIINWJOfTsQ/PTLMC+4ABYYw7OqCs 44IwFDteGbFEo5o6Zq9gHMOu35lJRqt/enndsLVCJ4Yg1zAF10s9QI3PXwh5ntM= 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=uVI+fI zhLfcxkWLtJBNTay7c4VTKTGo3Ven4FvkGhKXQPZwgDrAYPyxzwl8FvHeHsWMlyj /jwLINA4a3WkdMVMR6qZ+6xEVu7TEd7rz1j7+Chz9MlLow+rpRvjAptHmqeNZcf+ 3rfNqMUl3xRwKiNT3taz285n7G15XnyTbA5SE= Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 7CD76F07F; Mon, 27 Jan 2014 12:22:28 -0500 (EST) Received: from iMac.local (unknown [24.234.153.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id C77EFF07E; Mon, 27 Jan 2014 12:22:26 -0500 (EST) Message-ID: <52E695D1.5050504@pobox.com> Date: Mon, 27 Jan 2014 09:22:25 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Eric Rescorla References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 97DED7DC-8777-11E3-A0B4-873F0E5B5709-38729857!a-pb-sasl-quonix.pobox.com Cc: "tls@ietf.org" Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Jan 2014 17:22:33 -0000 -1 We should consider whether we can define a single SCSV that a client issues when it thinks a server is extension intolerant. Such an SCSV could be used in conjunction with a normal extension used for downgrade protection, if the client gets pushed all the way back to TLSv1.0 without extensions, or to SSLv3. This approach could solve the problem of desiring more SCSVs in the future. Mike Eric Rescorla wrote: > WG Members, > > This message is a call for acceptance of > http://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-01 > > As a TLS WG item. > > Please provide any comments on this action by Feb 7. Because > there has been only modest discussion of this document, the > chairs ask people who have already spoken in favor or against > this document to re-register their opinion (feel free to just say > +1 or -1 and point back to the archives.) > > -Ekr > [For the chairs] From agl@google.com Mon Jan 27 09:27:55 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 537F91A0230 for ; Mon, 27 Jan 2014 09:27:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.914 X-Spam-Level: X-Spam-Status: No, score=-1.914 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, RP_MATCHES_RCVD=-0.535, 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 4sOK5JGiFYeO for ; Mon, 27 Jan 2014 09:27:53 -0800 (PST) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8681A015A for ; Mon, 27 Jan 2014 09:27:53 -0800 (PST) Received: by mail-ie0-f171.google.com with SMTP id as1so6232127iec.30 for ; Mon, 27 Jan 2014 09:27:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=fpejdyWwlfcAQsivACcWqAETYYd2Nkxgq3cGLL0WVzs=; b=opa5ATJ+ktrgiF0wwPed+bAR2f2GhsS9CFMipmXsCybTYHpU0/xeM0AWXdMcBzfwQV l9wUesSdLmaETeiq3j3NbbkShKlbYxJ0DxLno3QnUX/Sk0dYpkUopNGjpNOTRU8YBEl7 RhVRr7xTCmG3pd4QWCg6MWhwnr/plMC7gX37bfX3K1tR6SUHnGSM6LBPn6ntR1aJ33hL pLK4YxRUEVrZ5PCYp7R0rB5kV7MULIbkRBF9M1R3Fc4t9jwSQ+nRYyVTSs3DYRrFc7yW JpJjI9l+XrmEzJCcwFxAigRH0xdKR8eDs7mwomJfGHnzFs55d52K+aPshvUqpCOpnTNH Iupg== 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=fpejdyWwlfcAQsivACcWqAETYYd2Nkxgq3cGLL0WVzs=; b=g9AEnc5s89KPn954CAE5Q5hMQu6bwTi5ZxpMMQN70uDmeE5v5uCcScA7d+kjAa4XX7 GQKNcZ45+t/sjxnIxctdpLpGKabBg3/u3lHbygjAsgiWH4EhYKTxQIqd2WpW5w+AZVLb zQug8/x3YpJCY+abHg+teENzm4w9s8GJyLOw3wkbPUeMlRKEq5tgYoLaTggVAQ9FNyqe AfTtxI3crsIIBVenY/hNhyp/i2k1X2K8fNiW+NmRvzDiDjOR/kKOYxPYhJKvgR0O6gqW SIPju/2dvNxDu3EFXHMn8FQt/CiQ3b15PGhKNh20eMQd9h6wNOXfNUWb7uSNVEObtZ/a pZUA== X-Gm-Message-State: ALoCoQneCVrkAPZL6b+Eghv0NryDphAwEeRstt7G2lVDO7R9doPWT1oxr4BS7xva8zOWsOhvgLBQpv5k2GijkeSv25yCK5y0TxNOEz3Tc6BswKib2LOIMeBxNJvNTO6mdvuvOyuNUUO7Lf/kclnteRxsTLOWFNEcnVYpXhv5zJus0PavhpG+K12ucsriOk46KPV44NDiMx88 X-Received: by 10.50.147.72 with SMTP id ti8mr18683859igb.20.1390843671000; Mon, 27 Jan 2014 09:27:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.224.198 with HTTP; Mon, 27 Jan 2014 09:27:30 -0800 (PST) In-Reply-To: <20140127152956.460001ABC9@ld9781.wdf.sap.corp> References: <20140127152956.460001ABC9@ld9781.wdf.sap.corp> From: Adam Langley Date: Mon, 27 Jan 2014 12:27:30 -0500 Message-ID: To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Jan 2014 17:27:55 -0000 On Mon, Jan 27, 2014 at 10:29 AM, Martin Rex wrote: > A modified extension that allows the server to continue the handshake > with a TLSv1.2 ServerHello, could be processed transparently within > the TLS client implementation and provide immediate benefits to TLS clients > that do not have any application-level reconnect fallback. The ServerHello could not contain options that the ClientHello didn't offer. For example, AES-GCM or even ECDHE (if the client fell back to SSLv3). Thus an attacker could still choose important features of the connection. Cheers AGL From SRS0=Ipyw=XB=acm.org=bmoeller@srs.kundenserver.de Mon Jan 27 11:34:43 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D9121A007C for ; Mon, 27 Jan 2014 11:34:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.464 X-Spam-Level: X-Spam-Status: No, score=-1.464 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535, 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 UKkJB_Vuz9AW for ; Mon, 27 Jan 2014 11:34:41 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by ietfa.amsl.com (Postfix) with ESMTP id 670641A028B for ; Mon, 27 Jan 2014 11:34:41 -0800 (PST) Received: from mail-ob0-f176.google.com (mail-ob0-f176.google.com [209.85.214.176]) by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis) id 0Lc873-1VOs6D3wWL-00jZev; Mon, 27 Jan 2014 20:34:37 +0100 Received: by mail-ob0-f176.google.com with SMTP id gq1so6902050obb.21 for ; Mon, 27 Jan 2014 11:34:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ao5HcL3jl3WozATAGNYoRkJFJCvQ0TkbkZMVFYt8HnU=; b=mtt0uWOWqC6Oz/w+eWuc250el0bC9pBCqRWpTlBNC8aeU7NYSrOUoCWM+xfD8Ucirr n8o14a8rAna3rCFSO35UZj+muElPXcHtPfo9RIux/3tvQGeM0rilRbbiuLHm0L1QctbS KDaYujvFvam+CqtVXA+OZiaKk7OPaIn/aSeXtMDS38fn7+cJpBcF/gvT5YMxFthbSjjh i+uFBy6PnrZks+fMvk7pm97FE0RFrKtcSPSuflKarXr0o6MXya2ATmg5SEC3EN+eKC6C vSX30svlj9S7whHp/py/Dq4TmL9PNhaVK/4WEyx7s1OUcr4O2uGhpWC30B7eRxsCmogN uiFw== MIME-Version: 1.0 X-Received: by 10.182.22.18 with SMTP id z18mr6426629obe.42.1390851275736; Mon, 27 Jan 2014 11:34:35 -0800 (PST) Received: by 10.60.170.239 with HTTP; Mon, 27 Jan 2014 11:34:35 -0800 (PST) In-Reply-To: <52E695D1.5050504@pobox.com> References: <52E695D1.5050504@pobox.com> Date: Mon, 27 Jan 2014 20:34:35 +0100 Message-ID: From: Bodo Moeller To: "Michael D'Errico" Content-Type: multipart/alternative; boundary=001a11332d1639d84004f0f8cca8 X-Provags-ID: V02:K0:yPb+kSGNppdKgYinZ3Q56G8krZzbrBRyKfnW+bSPcEU H76952R86E6Xm35j2uHdwiAa63ccvMZ2e7iUsyc+FCNL/dZg5Q w4KpRWdyNNUsZSEl3Ku1xj/aL+jERfZR9fZ/imS8jYNIu663hd agdpuf7dB/635cWlFgCR0ApFZELoVO3CJz0ugQsduehsW33QFf s8D4SQfIQJLmlBzHPhvVj5CR+/mQJwOTX+SqIDUXGTAlVBlSEl 3YIaeIDEMnmBMDSQvb8M94eSK75ZhAflTUfJ045WY6mOylXqQj dHVnX8N/rwfcHd/sli76AscZXGmR5dplwQwfrQ6RxJvjIvxpVU l0136dUDWjKZWpxXQTTgcC8IDSGMDOzgqv2uFhv26JbW9aPJ3s ZoxbZX36GRyGjLKx5GTAJpoPjv0VU/DBCJzYROPCNx3rz56XVl QDz1o Cc: "tls@ietf.org" Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Jan 2014 19:34:43 -0000 --001a11332d1639d84004f0f8cca8 Content-Type: text/plain; charset=ISO-8859-1 Michael D'Errico : > We should consider whether we can define a single SCSV that a > client issues when it thinks a server is extension intolerant. > > Such an SCSV could be used in conjunction with a normal extension > used for downgrade protection, if the client gets pushed all the > way back to TLSv1.0 without extensions, or to SSLv3. > > This approach could solve the problem of desiring more SCSVs in > the future. Hm, that would mean having the SCSV for special-case downgrade protection (extension intolerance) and an extension for general-case downgrade protection (when extension intolerance is not an issue). That means requiring more code to be added to servers (to *all* servers, since these mechanisms only work as intended if all servers support them). In practice, what would be gained from that over just having the SCSV and using it for both? (If someone really wanted to add a new negotiation mechanism for anything and allow it to be backported to SSL 3.0 implementations with no extension support, they'd *still* want a new SCSV for that ... however, I hope that with the protocol downgrade issue getting addressed, the need to support any other new protocol tweak to these obsolete protocol versions will go away. For example, draft-gutmann-tls-encrypt-then-mac-05 doesn't need an SCSV when you can use TLS_FALLBACK_SCSV to avoid falling back to old protocol versions.) Bodo --001a11332d1639d84004f0f8cca8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Mich= ael D'Errico <mike-list@pobox.com>:
=A0
We should consider whether we can define a single SCSV that a
client issues when it thinks a server is extension intolerant.

Such an SCSV could be used in conjunction with a normal extension
used for downgrade protection, if the client gets pushed all the
way back to TLSv1.0 without extensions, or to SSLv3.

This approach could solve the problem of desiring more SCSVs in
the future.

Hm, that would mean having the = SCSV for special-case downgrade protection (extension intolerance) and an e= xtension for general-case downgrade protection (when extension intolerance = is not an issue). =A0That means requiring more code to be added to servers = (to *all* servers, since these mechanisms only work as intended if all serv= ers support them). =A0In practice, what would be gained from that over just= having the SCSV and using it for both?

(If someone really wanted to add a new negotiation mech= anism for anything and allow it to be backported to SSL 3.0 implementations= with no extension support, they'd *still* want a new SCSV for that ...= =A0however, I hope that with the protocol downgrade issue getting addresse= d, the need to support any other new protocol tweak to these obsolete proto= col versions will go away. =A0For example,=A0draft-gutmann-tls-encrypt-then= -mac-05 doesn't need an SCSV when you can use TLS_FALLBACK_SCSV to avoi= d falling back to old protocol versions.)

Bodo


--001a11332d1639d84004f0f8cca8-- From wtc@google.com Mon Jan 27 12:09:14 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5A741A0386 for ; Mon, 27 Jan 2014 12:09:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.914 X-Spam-Level: X-Spam-Status: No, score=-1.914 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, RP_MATCHES_RCVD=-0.535, 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 zSvN8SD-S7zz for ; Mon, 27 Jan 2014 12:09:13 -0800 (PST) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 1A13C1A0371 for ; Mon, 27 Jan 2014 12:09:12 -0800 (PST) Received: by mail-qc0-f180.google.com with SMTP id i17so8943320qcy.11 for ; Mon, 27 Jan 2014 12:09:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ONJQ6VK7hpbXn+2vo9BD/jis77XbQwGTi/n+0PPzqTA=; b=aL4tD+ViYqNhGP5RJxAmr+4Oegf9KgLYq1jYwkProhr2UTUiqMwr2dDqC8kNPQOElX eYvJmx8FTbENjT2rVX84I4lgkmOXDK6KHDFm/VSX/bC4+HS2Bapjd/fSMK8NylfFlAZF /QRhEr/FZFjgqCme8IAawzsmr0FRZfOeD9bOvJW7JTKvZVHo0XeX5QlfZY7Ym+EdqwxF v2NUS4/6CvkS3FrgF8OqPgnFhUFfA7qlRDuAI5L/BydvQm0GsWfyzTRpeWAQSJgxuZnX v61HomJYhheosr7TITZc2QcOR98IEMxENpeDxEeC060qOAMtZyhiQ3SwfV59Cvx190fI u0Gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ONJQ6VK7hpbXn+2vo9BD/jis77XbQwGTi/n+0PPzqTA=; b=ghYK1M/TfqCUsWDylLmrYaPlK+lo/SeVBCy+GyTOuA25GA340W9Os7EIz7doMONTlL LvGM8kJPZr6Vc+olQ9M7MtGWznIRK8IL/t5NGY041Y2wD3T4tLvis9sAuC6LbX2OTbFt XbP3eQf36hBFSKmgiU1xCPJEjarEMCTCXlTidPiwgUkVKsue04IhpuRmWN49XFCytXga 2hSd6PJIfh+Tm5E3Nxt1CAOLKfl8ep5rgTWrvEytWq8xkvypChpwWvfn6EgHrscoBLIS SkcLaygYYTI/JZVCHJKXVw38uhhKsvv2jwHUHRcSEX4MSNvQZ1SUFVzhRolP1odp59Dj xmlA== X-Gm-Message-State: ALoCoQkap4gge3tr2gwgEFTglGR4aY0ftrXTRRUPZoARk3nSkDwmvQ7pIO3SwSpyAzPCCDkWOZ1k6MIKSRuL66dENma1sZ9pVmPRUTJ7+oXK6p3SaLxP/UbfkvHMRcVJIWmNPgHNS7zfvgfIyAz0x7kBiZNIvTLOshFAwdiLEefIeZwN/6yUmXIayadEEnwW6f06qHoL/UoL MIME-Version: 1.0 X-Received: by 10.224.169.11 with SMTP id w11mr45750716qay.71.1390853350511; Mon, 27 Jan 2014 12:09:10 -0800 (PST) Received: by 10.229.51.67 with HTTP; Mon, 27 Jan 2014 12:09:10 -0800 (PST) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C7372359B6A@uxcn10-tdc06.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C7372359B6A@uxcn10-tdc06.UoA.auckland.ac.nz> Date: Mon, 27 Jan 2014 12:09:10 -0800 Message-ID: From: Wan-Teh Chang To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] Conclusion of Fixing CBC Discussion X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Jan 2014 20:09:14 -0000 On Thu, Jan 16, 2014 at 4:19 AM, Peter Gutmann wrote: > Eric Rescorla writes: > >>Accordingly, we propose to have the WG adopt draft-gutmann with Peter Gutmann >>as editor, should he be willing to serve. > > Sure, no problem. Hi Peter, I am planning to implement your draft in NSS later this week. Do you have or know of a server on the Internet that I can test against? I'll need both the URL of the server and the "extension_type" value for the encrypt_then_MAC extension the server uses. Thanks, Wan-Teh Chang From mrex@sap.com Mon Jan 27 16:17:55 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7540C1A0251 for ; Mon, 27 Jan 2014 16:17:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 vncHqyQJ-XL5 for ; Mon, 27 Jan 2014 16:17:53 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 10DE51A008F for ; Mon, 27 Jan 2014 16:17:52 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s0S0Hb1g021602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 28 Jan 2014 01:17:38 +0100 (MET) In-Reply-To: To: Bodo Moeller Date: Tue, 28 Jan 2014 01:17:37 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140128001737.D9D581ABC9@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "tls@ietf.org" Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv 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, 28 Jan 2014 00:17:55 -0000 Bodo Moeller wrote: > Michael D'Errico : >> >> We should consider whether we can define a single SCSV that a >> client issues when it thinks a server is extension intolerant. >> >> Such an SCSV could be used in conjunction with a normal extension >> used for downgrade protection, if the client gets pushed all the >> way back to TLSv1.0 without extensions, or to SSLv3. >> >> This approach could solve the problem of desiring more SCSVs in >> the future. > > Hm, that would mean having the SCSV for special-case downgrade protection > (extension intolerance) and an extension for general-case downgrade > protection (when extension intolerance is not an issue). That means > requiring more code to be added to servers (to *all* servers, since these > mechanisms only work as intended if all servers support them). But you _are_ aware that your proposal is vitally dependent that the TLS server puts a fatal SSL alert on the wire before closing the connection? Historically, (close to) all applications running on top of Microsoft SChannel (including MSIE client and IIS server) do not send any fatal alerts before closing connections, because they use a transport-free API (Microsoft SSPI, similar to GSS-API) to their TLS implementation, and the application code does not support (a) processing a fatal error messages and (b) sending tokens over the network at the same time. It's basically the same reason why the forwarding of error tokens and outputs of "gss_delete_sec_context()" was deprecated in GSS-API v2 -- because most apps will simple refuse to do it. It would not be possible to hide such a change in behaviour (writing a fatal alert to the network before closing the connection) within SChannel, it would also require a change to at least Microsoft IIS. How likely is that going to happen? (It's been the way it is not for the last ~14 years...). Which server implementers are eager to send such a fatal alert as is contained in this proposal anyway? I will certainly ensure that our server implementation will NEVER grow such silly behaviour. -Martin From agl@google.com Mon Jan 27 16:35:11 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 674CC1A02B7 for ; Mon, 27 Jan 2014 16:35:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.914 X-Spam-Level: X-Spam-Status: No, score=-1.914 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, RP_MATCHES_RCVD=-0.535, 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 pG_vyzRm-Zw6 for ; Mon, 27 Jan 2014 16:35:09 -0800 (PST) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 6C19F1A0247 for ; Mon, 27 Jan 2014 16:35:09 -0800 (PST) Received: by mail-ob0-f169.google.com with SMTP id wo20so7427986obc.0 for ; Mon, 27 Jan 2014 16:35:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=7LJfWtXN4YBzV59oRYNBc93DjcKcrRWyw0WhFQJXYkk=; b=B1uEdX9qiJWd3qIHMeGZXMO8BcAF50EmaFRhYPKT+axMzihtW2LNceZpHgx2A6SuT0 sBSCIVTZmMM3lY+sMNkO5lGBG9JrOxrR4rnqQnL8j4kNUyiZWSfg5XdlD79g9EgLxKlo NQ4cyTOhwCOMxd7gjyipT4TY8sQ6/k/SywdlMsPqfE0y0An5Vo9tPvESA5DRNIRUbu9i c8dFO9birMY5jZhfMifR0KpSNKfOd6tjene8asIysY/Kh4T5gMYBiJUh3qVLP9z4s6A6 zOrsaLZDEUA4jbMB+aZjh85eG3fkqJDEPTCyco4EMEyPM4qqxYCoICz7uodGpdalTM0X eTWA== 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=7LJfWtXN4YBzV59oRYNBc93DjcKcrRWyw0WhFQJXYkk=; b=f3B7+d21x8aM6MpW5nkPFjcbR7FMKqEua96+ecNpVNBfyP7HVQiMJHNsqalkg43/Au thPmDXObr8eWKf9GiZAcvZnkPVJz1nWwmlTeRtyA7Nad7ZyO/UC9prajudsgbkLHHLgC haD4F0Tk6YEeRk5fTVZJ0be6/0d2bEe3OQoeJpOuqEPwKPfUb3YW3i6ou9ogwXSBzbre /myefPrRBe2dtbY1xiWrVA74bOWaGFs2d/ixB43J/0S7Ft5orO1kP//fiAx3g8+6ywhd wbaKV+RRHTpN718fXdL771TDuaYo6dwwtYnPiTQSpOuuMb9nOo80qE0ACYCEI+n8zrOU vCCA== X-Gm-Message-State: ALoCoQmTcW2p1iu0Xs5m3kufM1oe2CwsYnvfnQ9j304Ekdprga5MflVhencRe4Z1XQb7KduWgC8BF62UwY0CcfZZmmyCSZfhcp0f0B6e5kGieMXeR/vHhiv7NnwkX1WyqGMQ3eMKqY54wM1S51+ciNCPCOCw8ouv/d0Xp4IkxfK6AtddMk6Mm1bxz27Bxpw2cGulPHJZxlio X-Received: by 10.60.51.230 with SMTP id n6mr16334598oeo.35.1390869306795; Mon, 27 Jan 2014 16:35:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.79.105 with HTTP; Mon, 27 Jan 2014 16:34:46 -0800 (PST) In-Reply-To: <20140128001737.D9D581ABC9@ld9781.wdf.sap.corp> References: <20140128001737.D9D581ABC9@ld9781.wdf.sap.corp> From: Adam Langley Date: Mon, 27 Jan 2014 19:34:46 -0500 Message-ID: To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Jan 2014 00:35:11 -0000 On Mon, Jan 27, 2014 at 7:17 PM, Martin Rex wrote: > It would not be possible to hide such a change in behaviour (writing > a fatal alert to the network before closing the connection) within > SChannel. I don't believe that sending an alert is beyond the ken of Andrei and Microsoft free to speak up if they have a problem with it. Cheers AGL From Andrei.Popov@microsoft.com Mon Jan 27 17:04:47 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B95B41A039E for ; Mon, 27 Jan 2014 17:04:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 vWYZy9NJwjtE for ; Mon, 27 Jan 2014 17:04:46 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0181.outbound.protection.outlook.com [207.46.163.181]) by ietfa.amsl.com (Postfix) with ESMTP id A931F1A02DA for ; Mon, 27 Jan 2014 17:04:45 -0800 (PST) Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BL2PR03MB418.namprd03.prod.outlook.com (10.141.92.13) with Microsoft SMTP Server (TLS) id 15.0.859.15; Tue, 28 Jan 2014 01:04:41 +0000 Received: from BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) by BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) with mapi id 15.00.0859.020; Tue, 28 Jan 2014 01:04:41 +0000 From: Andrei Popov To: "mrex@sap.com" , Bodo Moeller Thread-Topic: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv Thread-Index: AQHPGCLYtuT5cbQOIEmjzG1QZtPhb5qY2GuAgAAk7YCAAE8UgIAAB82Q Date: Tue, 28 Jan 2014 01:04:40 +0000 Message-ID: <828b043cac0f4b62875d00f31d2f92e3@BL2PR03MB419.namprd03.prod.outlook.com> References: <20140128001737.D9D581ABC9@ld9781.wdf.sap.corp> In-Reply-To: <20140128001737.D9D581ABC9@ld9781.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::3] x-forefront-prvs: 0105DAA385 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(164054003)(13464003)(24454002)(189002)(199002)(377454003)(51704005)(54356001)(76482001)(46102001)(53806001)(15975445006)(33646001)(74662001)(47446002)(74502001)(87266001)(31966008)(51856001)(2656002)(50986001)(93516002)(47976001)(85306002)(76576001)(76796001)(76786001)(69226001)(87936001)(81686001)(81816001)(4396001)(49866001)(47736001)(56776001)(81342001)(19580395003)(93136001)(80022001)(92566001)(74316001)(81542001)(80976001)(90146001)(54316002)(86362001)(65816001)(74706001)(83322001)(19580405001)(56816005)(85852003)(83072002)(59766001)(77982001)(74876001)(63696002)(79102001)(561944002)(74366001)(94316002)(3826001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR03MB418; H:BL2PR03MB419.namprd03.prod.outlook.com; CLIP:2001:4898:80e8:ed31::3; FPR:; InfoNoRecordsMX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "tls@ietf.org" Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Jan 2014 01:04:47 -0000 For my understanding: why is this proposal vitally dependent on the server = sending inappropriate_fallback alert? If the server receives the SCSV, has = a higher protocol version enabled than that in the ClientHello, and quietly= aborts the handshake, isn't the downgrade attack thwarted? Thanks, Andrei -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Rex Sent: Monday, January 27, 2014 4:18 PM To: Bodo Moeller Cc: tls@ietf.org Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv Bodo Moeller wrote: > Michael D'Errico : >> >> We should consider whether we can define a single SCSV that a client=20 >> issues when it thinks a server is extension intolerant. >> >> Such an SCSV could be used in conjunction with a normal extension=20 >> used for downgrade protection, if the client gets pushed all the way=20 >> back to TLSv1.0 without extensions, or to SSLv3. >> >> This approach could solve the problem of desiring more SCSVs in the=20 >> future. >=20 > Hm, that would mean having the SCSV for special-case downgrade=20 > protection (extension intolerance) and an extension for general-case=20 > downgrade protection (when extension intolerance is not an issue). =20 > That means requiring more code to be added to servers (to *all*=20 > servers, since these mechanisms only work as intended if all servers supp= ort them). But you _are_ aware that your proposal is vitally dependent that the TLS se= rver puts a fatal SSL alert on the wire before closing the connection? His= torically, (close to) all applications running on top of Microsoft SChannel= (including MSIE client and IIS server) do not send any fatal alerts before= closing connections, because they use a transport-free API (Microsoft SSPI= , similar to GSS-API) to their TLS implementation, and the application code= does not support (a) processing a fatal error messages and (b) sending tokens over the netwo= rk at the same time. It's basically the same reason why the forwarding of = error tokens and outputs of "gss_delete_sec_context()" was deprecated in GSS-API v2 -- because most apps will simple refuse to do = it. It would not be possible to hide such a change in behaviour (writing a fata= l alert to the network before closing the connection) within SChannel, it w= ould also require a change to at least Microsoft IIS. How likely is that going to happen? (It's been the way it is not for the l= ast ~14 years...). Which server implementers are eager to send such a fatal alert as is contai= ned in this proposal anyway? I will certainly ensure that our server imple= mentation will NEVER grow such silly behaviour. -Martin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From Andrei.Popov@microsoft.com Mon Jan 27 17:46:43 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 023BF1A0345 for ; Mon, 27 Jan 2014 17:46:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 It95nKq7HDNu for ; Mon, 27 Jan 2014 17:46:41 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) by ietfa.amsl.com (Postfix) with ESMTP id 15A491A016C for ; Mon, 27 Jan 2014 17:46:40 -0800 (PST) Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BL2PR03MB420.namprd03.prod.outlook.com (10.141.92.25) with Microsoft SMTP Server (TLS) id 15.0.859.15; Tue, 28 Jan 2014 01:46:36 +0000 Received: from BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) by BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) with mapi id 15.00.0859.020; Tue, 28 Jan 2014 01:46:36 +0000 From: Andrei Popov To: Adam Langley , "mrex@sap.com" Thread-Topic: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv Thread-Index: AQHPGCLYtuT5cbQOIEmjzG1QZtPhb5qY2GuAgAAk7YCAAE8UgIAABMsAgAAQaqA= Date: Tue, 28 Jan 2014 01:46:36 +0000 Message-ID: <4e68bd097d9a455482671ae14fd26552@BL2PR03MB419.namprd03.prod.outlook.com> References: <20140128001737.D9D581ABC9@ld9781.wdf.sap.corp> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::3] x-forefront-prvs: 0105DAA385 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(13464003)(199002)(24454002)(189002)(377454003)(81816001)(51856001)(53806001)(46102001)(76786001)(76576001)(76796001)(85306002)(87936001)(85852003)(83072002)(2656002)(87266001)(93136001)(81686001)(56816005)(90146001)(76482001)(54356001)(92566001)(86362001)(56776001)(74366001)(74502001)(80976001)(74876001)(83322001)(19580405001)(19580395003)(74706001)(77982001)(59766001)(74662001)(47446002)(31966008)(80022001)(65816001)(33646001)(63696002)(69226001)(79102001)(81542001)(54316002)(4396001)(15975445006)(49866001)(93516002)(47736001)(47976001)(94316002)(74316001)(50986001)(81342001)(3826001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR03MB420; H:BL2PR03MB419.namprd03.prod.outlook.com; CLIP:2001:4898:80e8:ed31::3; FPR:; InfoNoRecordsA:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "tls@ietf.org" Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Jan 2014 01:46:43 -0000 Just to clarify: schannel does generate alerts as specified for SSL/TLS, an= d these alerts are exposed via SSPI. For a variety of reasons, SSPI callers= may choose to not send alerts when a handshake is aborted, but technically= they could. Cheers, Andrei -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Adam Langley Sent: Monday, January 27, 2014 4:35 PM To: mrex@sap.com Cc: tls@ietf.org Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv On Mon, Jan 27, 2014 at 7:17 PM, Martin Rex wrote: > It would not be possible to hide such a change in behaviour (writing a=20 > fatal alert to the network before closing the connection) within=20 > SChannel. I don't believe that sending an alert is beyond the ken of Andrei and Micro= soft free to speak up if they have a problem with it. Cheers AGL _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From agl@google.com Mon Jan 27 17:52:47 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2383A1A03F9 for ; Mon, 27 Jan 2014 17:52:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.914 X-Spam-Level: X-Spam-Status: No, score=-1.914 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, RP_MATCHES_RCVD=-0.535, 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 UgTmL72dTxQh for ; Mon, 27 Jan 2014 17:52:45 -0800 (PST) Received: from mail-oa0-x22f.google.com (mail-oa0-x22f.google.com [IPv6:2607:f8b0:4003:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id C21D01A03F5 for ; Mon, 27 Jan 2014 17:52:45 -0800 (PST) Received: by mail-oa0-f47.google.com with SMTP id m1so7693226oag.34 for ; Mon, 27 Jan 2014 17:52:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=+bnfYVZ1/VFtanq0t7271euPCXI7ZCPB4lK5a8sGddA=; b=GdhOcHUUEhJTPbt8vxscBKidG4NaNrSjQfPvwUctgBab3t1F/CleLbmSUY5EIa7/9K HnOvn+z14AAc1idJ8tlZ0+wjMAW09YFqtYm+vIT4odwEAACNdG77aP9qDxa2gt+rhkNh Q5jozfyDhrWCnf56X56yhhJOStSeJU8iAzuMCcJPap5QnSJ90Dm0ynhPet6nz+FUv0fQ X6WsQwpFZI15prxRqeXv4PKnsyxQ4Eqxc8RwsfQkbKjiHktZZAjkpFLiIfxt7JcUNC2m uufAcxBmK6sLCaNsS/KVP9PclxpKDh2t2+YI7mEzRCj44fJUQD9YOiFkGYr5484AsHFj ZnFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=+bnfYVZ1/VFtanq0t7271euPCXI7ZCPB4lK5a8sGddA=; b=D1UFxFQbx9TCRQSpMAB6gqWloghy6dyX+HSaDvX3imIETEU0r+U/d71hem9nnmwZZ2 FppKkA6jn4PXhvYKzaZlL3gItAz9nAE0VdocZ9x6P4tsyGsmcxxWRFsFCm2/TMXPuOQe f8qyMYrQuJWkgZQBA+3zfUgXNbpbYSCS18T/L5UGut4wOamNEx0krq6Pute7fxlcgvdg qQ5MP7MVk6ssU20G7mh4YLEII3wMNAHAuAmVLJM4beDyK4M0kUDW7gWY6CcQFvO7a0rw YXUOGuclV2R+BcjUTaP1zSN9UGi1vlED5SN8+0l49eRAxnhF/zeDx8hGTtXMo3Bd2VDX o+dg== X-Gm-Message-State: ALoCoQlQK7Hi5ZFwNofmvnf94QmV4OKk09mLe5ubkGM3qSMHtZcGFZKWVxwCQw9RWWhY7bSHOHRRhVchAF/e7tMKo+TO2aTN+E/hCIM+OQDzQ5XUD7h71tCNeqQDvdvCM6VWefB/+LpVi487GxxQDUII0ZvpzT63jfACrycNIHGlSCIEt08pWXJF//0oUTZmLi+9NYEpt5Oa X-Received: by 10.182.196.3 with SMTP id ii3mr25761049obc.11.1390873963146; Mon, 27 Jan 2014 17:52:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.79.105 with HTTP; Mon, 27 Jan 2014 17:52:22 -0800 (PST) In-Reply-To: <828b043cac0f4b62875d00f31d2f92e3@BL2PR03MB419.namprd03.prod.outlook.com> References: <20140128001737.D9D581ABC9@ld9781.wdf.sap.corp> <828b043cac0f4b62875d00f31d2f92e3@BL2PR03MB419.namprd03.prod.outlook.com> From: Adam Langley Date: Mon, 27 Jan 2014 20:52:22 -0500 Message-ID: To: Andrei Popov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "tls@ietf.org" Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Jan 2014 01:52:47 -0000 On Mon, Jan 27, 2014 at 8:04 PM, Andrei Popov wrote: > For my understanding: why is this proposal vitally dependent on the serve= r sending inappropriate_fallback alert? If the server receives the SCSV, ha= s a higher protocol version enabled than that in the ClientHello, and quiet= ly aborts the handshake, isn't the downgrade attack thwarted? Yes, just closing the connection is good enough for security. The advantage of returning the fatal alert is that a) it stops the fallback process faster and b) the client can report the error that caused the original connection to fail, rather than that the final fallback hit connection closed. Cheers AGL From mrex@sap.com Mon Jan 27 19:31:49 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC151A039B for ; Mon, 27 Jan 2014 19:31:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 yDGmR-JWb0-h for ; Mon, 27 Jan 2014 19:31:46 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 956801A017F for ; Mon, 27 Jan 2014 19:31:46 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s0S3VgJZ019971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 28 Jan 2014 04:31:42 +0100 (MET) In-Reply-To: To: Adam Langley Date: Tue, 28 Jan 2014 04:31:41 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140128033141.EEEDE1ABC9@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "tls@ietf.org" Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv 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, 28 Jan 2014 03:31:49 -0000 Adam Langley wrote: > Martin Rex wrote: >> A modified extension that allows the server to continue the handshake >> with a TLSv1.2 ServerHello, could be processed transparently within >> the TLS client implementation and provide immediate benefits to TLS clients >> that do not have any application-level reconnect fallback. > > The ServerHello could not contain options that the ClientHello didn't > offer. For example, AES-GCM or even ECDHE (if the client fell back to > SSLv3). Thus an attacker could still choose important features of the > connection. You really do not need to curtail your imagination and creativity so badly. If you have an urge to resend a ClientHello with TLS extensions, how about extending this proposal to allow the client to do this within the handshake rather then dropping the connection like a hot potato and expecting the application to clean up the resulting mess with an app-supplied reconnect fallback facility? The negotiation could work like this: Client is performing a fallback and stripping information from ClientHello (such as TLS extensions or certain cipher suites) that the client would prefer to use if availabe and marks that omission with an SCSV. Server checks the ClientHello, recognizes the SCSV and if the server supports features beyond those currently present in ClientHello _and_ features which would be preferable _to_the_server_ (such as ECC cipher, AES-GCM cipher suites, TLS signature extension), then the server could return ServerHello with ServerHello.cipher_suite=SCSV and ServerHello.server_version set to the highest TLS version supported by the server directly followed by ServerHelloDone, and upon receiving this, the client would simply restart the Handshake with a new ClientHello handshake message that contains all the previously omitted stuff. In a number of situations, the server may simply want to continue the handshake, when the server does not support any features beyond what is offered in that fallback ClientHello, or when the choices present in the fallback ClientHello meet the preferences configured by the server administrator. i.e. when the server admin has configured to prefer TLS_RSA_WITH_AES_128_CBC_SHA, this cipher suite is present in the fallback ClientHello and the server has only a single cipher suite, then it wouldn't matter when ClientHello.client_version is only TLSv1.1 or when there are no TLS extensions in ClientHello, and no need to suggest resending his ClientHello to the client. i.e. the regular full TLS handshake: http://tools.ietf.org/html/rfc5246#page-36 Client Server ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data Figure 1. Message flow for a full handshake the fall-forward full TLS handshake: Client Server minimal ClientHello w/SCSV --------> ServerHello w/SCSV <-------- ServerHelloDone ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data Figure 1. Message flow for a full handshake -Martin From watsonbladd@gmail.com Mon Jan 27 22:14:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A93801A019D for ; Mon, 27 Jan 2014 22:14:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUtHoxDFlgTT for ; Mon, 27 Jan 2014 22:14:36 -0800 (PST) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id BA79D1A0197 for ; Mon, 27 Jan 2014 22:14:35 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id x13so6853957wgg.15 for ; Mon, 27 Jan 2014 22:14:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=ZXQTilRlOezhEy9RnkSR5WXxOBg/yiIhNMoPW+LKGOY=; b=hAqDlgQJ69utrWJjyI54c6h1f9c8bAzXBZ86+j/jkGTCd6mczh57LEfGa0nSeloOMo 2Hba+W62uvtMx/YJ5cRUJLUhoIjA69FjnKkMfdtysPguqfsYt4XLZBiZ0bEar3vrDzCT fzafUAZYImxzFONjJAEhAQffSk0xO1J3dZwbQUzrbLPeRJcr1Fie1di+PVJSgjg5y1A0 qHg5nTDCQw4/Cihz/asU9s/e5FxtiQDHfvarW9ey0EcLryg/yPZIp7y/UFYO5ZWFwIpO UyN7BeTbM6csLBT7qtnfJ0KWZ8Y1VneQcwanj9xAoQpvmRwhGbN4wViy4EeYcOUWYQnh nyfw== MIME-Version: 1.0 X-Received: by 10.180.79.7 with SMTP id f7mr827092wix.20.1390889672816; Mon, 27 Jan 2014 22:14:32 -0800 (PST) Received: by 10.194.250.101 with HTTP; Mon, 27 Jan 2014 22:14:32 -0800 (PST) In-Reply-To: <20140128024632.F2A8A1ABC9@ld9781.wdf.sap.corp> References: <20140128024632.F2A8A1ABC9@ld9781.wdf.sap.corp> Date: Mon, 27 Jan 2014 22:14:32 -0800 Message-ID: From: Watson Ladd To: mrex@sap.com, "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Jan 2014 06:14:37 -0000 On Mon, Jan 27, 2014 at 6:46 PM, Martin Rex wrote: > Watson Ladd wrote: >> "Martin Rex" wrote: >> > >> > Which server implementers are eager to send such a fatal alert as >> > is contained in this proposal anyway? I will certainly ensure that >> > our server implementation will NEVER grow such silly behaviour. >> >> Let me get this straight: all SAP applications will be vulnerable to >> downgrades even when clients are fixed because that behavior is "silly". > > Nope. We do not implement reconnect fallbacks, so none of our stuff > is downgradable. > > There might be defective browsers who will needlessly downgrade > to insecure behaviour or suggest end users to not use HTTPS at all, > but that is a defect of those browsers, not of our server. So let me get this straight: Because none of your clients ever need to implement reconnects and none of your servers are ever connected to by clients that do, this proposal is a problem for you because...? You can always not implement it. I'm much more inclined to take seriously the complaints from folks who actually have to live with the proposal. So far the Firefox and Chrome folks have supported this proposal. The servers probably will support it: I think I can do PolarSSL without too much trouble, and someone far more skilled then me in arcana can do OpenSSL. > > >> >> I'm sure your clients will be happy to hear how seriously SAP takes >> security. > > We do take security very seriously. But we also take robustness, > support and performance very seriously, but the reconnect fallback > approach is neither robust, nor supportable and a royal PITA for > performance. Yes it is. But the browser folks disagree: being able to connect to a small minority of broken servers is worth the pain for them. > > How many TLS clients beyond a negligible small amount of browsers > is doing the reconnect fallbacks anyway? How many POP/IMAP/SMTP/LDAP > clients and programmatic HTTPS clients is doing reconnect fallbacks? If they aren't doing fallbacks, then this doesn't affect them. This is a much easier change (bail out if you think you can support TLS 1.2) then your proposal. > > > I refuse to blame the apps folks that they will have to jump hoops > to workaround the botched TLS feature negotiation, rather than fixing > the TLS feature negotiation within the TLS protocol itself. Dead hands. Our ability to redo the negotiation at this point is about nil. I've got no idea why it was done this way Hopefully with TLS 1.3 we won't screw it up even further: perhaps TLS 1.2.1 is a better name. The apps folks can always refuse to support servers that can't negotiate properly. Or we can make TLS APIs and libraries that handle the uglyness of reconnection for the apps. > > -Martin -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From SRS0=vgwm=XC=acm.org=bmoeller@srs.kundenserver.de Tue Jan 28 00:29:54 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B455E1A003E for ; Tue, 28 Jan 2014 00:29:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.464 X-Spam-Level: X-Spam-Status: No, score=-1.464 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535, 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 jtyFnoM0ufjv for ; Tue, 28 Jan 2014 00:29:53 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id 4979A1A0018 for ; Tue, 28 Jan 2014 00:29:53 -0800 (PST) Received: from mail-oa0-f50.google.com (mail-oa0-f50.google.com [209.85.219.50]) by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis) id 0Lmc9z-1VYB8X0123-00ZnBN; Tue, 28 Jan 2014 09:29:50 +0100 Received: by mail-oa0-f50.google.com with SMTP id n16so67938oag.37 for ; Tue, 28 Jan 2014 00:29:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TOINKUXyI5yvvU91t2uLvVwk+eDDgyzpaluOAPp+itU=; b=V3458da5088giZCsrXdhfDRlxDfTMMA1eQzVJFRqcgO6z4kZwgUW8//ygjZy0WtGd5 UQQ6R8Z0VdlXGVsEp6d1ew7ZCDQhoIjq4fshPLcj0HO1p/2NI1UBB/NPXV5bQtKen0Kl C1ETybugUvdhD94rs3rCWJyl9XpMYLXxcLhIODQm2TkgB8So9Xw6XsIm3YWbAyRA//Ex HlC7LCmQds853c6ockGGL5wnB7MzmvvD77mBSlqkJyQ+W7jzSZaMFI7lhERiZuJvstk4 Po9zrjAV5l1qp56wnR3w0K1tWA13lNJWJNp1GiEyWlj4lotyIlcW921Hl7e/WpgSBYEG 6gig== MIME-Version: 1.0 X-Received: by 10.182.48.233 with SMTP id p9mr132546obn.44.1390897787602; Tue, 28 Jan 2014 00:29:47 -0800 (PST) Received: by 10.60.170.239 with HTTP; Tue, 28 Jan 2014 00:29:47 -0800 (PST) In-Reply-To: References: <20140128024632.F2A8A1ABC9@ld9781.wdf.sap.corp> Date: Tue, 28 Jan 2014 09:29:47 +0100 Message-ID: From: Bodo Moeller To: Watson Ladd Content-Type: multipart/alternative; boundary=047d7b66f0bd8c8f0304f103a03b X-Provags-ID: V02:K0:vTA7SqY6TCA0MaaIhHALxZk70xivFlxm6TeVvId4waP ULzQ4ZgF2YKuMekqE4cpzsUwSFcm8FxKEmMC5+RutggWcSONW3 YwFb6ipoQIS8Q21I0zmAXSL/sgOFva3hVEcCOSOUJbDohDGGeP 2bMtJ2x5N/9pkwFnWF/+mHIAT3sLwlE7bGVmR/72kHPkgZVsW9 7UPC+IXWmsqhKBAeztZPf4EEi/8GQPPNPD0mmQOYzHoxlqgoQf T4sVNxRSF94qWHvUvj2sKUTV3iRYyAzNu04OrA50LLqQHktFXk oNeMQXfmt+bGodZrPTSVehp5i+RJtGuIbCKphjEBJ9ZXC4agiQ JQsq37k6QZ5xuIDw5PNtzItnjTxT3eVRA3NlbAiC1ZAe1NmM7B FzAvZ0fMy+Ynr9LqvvgTJX7vMwcqtStbFcXsh9yhFk8HlGK4qn DabqT Cc: "tls@ietf.org" Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Jan 2014 08:52:47 -0000 --047d7b66f0bd8c8f0304f103a03b Content-Type: text/plain; charset=ISO-8859-1 Watson Ladd : I'm much more inclined to take seriously the complaints from folks who > actually have to live with the > proposal. So far the Firefox and Chrome folks have supported this > proposal. The servers probably will > support it: I think I can do PolarSSL without too much trouble, and > someone far more skilled then me in > arcana can do OpenSSL. No problem there; Adam has a patch for OpenSSL server-side behavior. Bodo --047d7b66f0bd8c8f0304f103a03b Content-Type: text/html; charset=ISO-8859-1
Watson Ladd <watsonbladd@gmail.com>:

I'm much more inclined to take seriously the complaints from folks who
actually have to live with the
proposal. So far the Firefox and Chrome folks have supported this
proposal. The servers probably will
support it: I think I can do PolarSSL without too much trouble, and
someone far more skilled then me in
arcana can do OpenSSL.

No problem there; Adam has a patch for OpenSSL server-side behavior.

Bodo

--047d7b66f0bd8c8f0304f103a03b-- From SRS0=vgwm=XC=acm.org=bmoeller@srs.kundenserver.de Tue Jan 28 00:52:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF79D1A008A for ; Tue, 28 Jan 2014 00:52:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.464 X-Spam-Level: X-Spam-Status: No, score=-1.464 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535, 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 X4wQFDjT6uMs for ; Tue, 28 Jan 2014 00:52:36 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by ietfa.amsl.com (Postfix) with ESMTP id 400B91A003E for ; Tue, 28 Jan 2014 00:52:36 -0800 (PST) Received: from mail-ob0-f175.google.com (mail-ob0-f175.google.com [209.85.214.175]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0MZysF-1Vqf3H3e7L-00KyuC; Tue, 28 Jan 2014 09:52:33 +0100 Received: by mail-ob0-f175.google.com with SMTP id wn1so87367obc.34 for ; Tue, 28 Jan 2014 00:52:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Gl16s9dR0egtnMw1Nd6eKeLGRy5g7FSifN6H+pUVNc8=; b=mc1yeTQie6Fz6Cy91ZvWT5xzHNC06sSIlbyYb5t2HfqR2JfQmL70u+ibmhS+W0m/0a 78ZfNNWnaPin7BdWjAwcavjcf05lK70XKkdmIpIOqEpZnmK6Bkz/oTF5/LUq9FNpBihg LQ9Sqr/3qMVOvVxMYCmCDxu8Z2R8ETawzaLfuxokKP1trrsRgyLh9xmNaKQlD3uRXBsh iiweNE63lTkmaHDThuxP3/bIOzGysiC6aJKtmmyYsVQNQmHpkckRP+DM1ASfWdjiRWRg JCRtxubGrlladixIUvCHFJN+QUYy6Y1ihgmukiRsXMuz/f64urquB3O2L7+WH5LvOfM0 VqSQ== MIME-Version: 1.0 X-Received: by 10.182.22.18 with SMTP id z18mr180636obe.42.1390899151658; Tue, 28 Jan 2014 00:52:31 -0800 (PST) Received: by 10.60.170.239 with HTTP; Tue, 28 Jan 2014 00:52:31 -0800 (PST) In-Reply-To: <20140128033141.EEEDE1ABC9@ld9781.wdf.sap.corp> References: <20140128033141.EEEDE1ABC9@ld9781.wdf.sap.corp> Date: Tue, 28 Jan 2014 09:52:31 +0100 Message-ID: From: Bodo Moeller To: Martin Rex Content-Type: multipart/alternative; boundary=001a11332d16da649404f103f1e7 X-Provags-ID: V02:K0:Ui+gX5d30Kl6CwQBQq780KGlIqiWZM+Dna2WPWMKMnL Boj8zdCQdwzVMbdOw8Ww/kAKdYW137Ppz1EToFdP8M+FL9Sqwl bCXXqnGwg6SXl8yeEJRU9llWH0Vy0jVaLfMX/phokmhITTvCXO 2AGSlgAh+RPRlCV5Oo3o1GDY4op+UbmGPdz79JEahTkflWYefT MbSq4lJ48nqiPyd0Q7jj0l9+OOQawmHBPm33TWXw4xf4O0KjQK uKxIuJx1D7ZaFsWaoXnaC1C6M7ieUWEjWH9+qoEbn8WdgcLrfK dWtB5sWv8S5cFt2Dzeo63EzmTu6e4br0H56I3B0B6HDPTgLug2 WxrE7oBRHgqHj+NpOUWyUamRpvsiHuqJfqn7D3vg/Yzj/IMFKU upn/hzT+KaUVZeGejIRXW3MCDC9kpzFVlC2NFnEmOk9/ql07oK tDUPy Cc: "tls@ietf.org" Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Jan 2014 08:53:23 -0000 --001a11332d16da649404f103f1e7 Content-Type: text/plain; charset=ISO-8859-1 Martin Rex : The negotiation could work like this: > > Client Server > > minimal ClientHello w/SCSV --------> > ServerHello w/SCSV > <-------- ServerHelloDone > ClientHello --------> > ServerHello > Certificate* > ServerKeyExchange* > CertificateRequest* > <-------- ServerHelloDone > Certificate* > ClientKeyExchange > CertificateVerify* > [ChangeCipherSpec] > Finished --------> > [ChangeCipherSpec] > <-------- Finished > Application Data <-------> Application Data > Well, it could, but I certainly think it's fair to say that getting this deployed will take much more design and implementation work than deploying TLS_FALLBACK_SCSV. There's actually no conflict here. TLS_FALLBACK_SCSV provides an immediately available simple fix for clients that use protocol fallback strategies. Later, if and when a more elaborate solution is available (or if broken servers simply are no longer an issue, whichever happens first), either clients won't have to send TLS_FALLBACK_SCSV (if there's no fallback reconnect), or servers won't have to abort the connection (if they are able to negotiate a non-downgraded protocol version as in your protocol sketch). (I'm highly skeptical that extending the protocol by another round as shown in your diagram would be desirable overall and that this would solve a real-world problem in the real world, but the utility of TLS_FALLBACK_SCSV does not depend on that question.) Bodo --001a11332d16da649404f103f1e7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Mart= in Rex <mrex@sap.com>:

The negotiation could work like this:
=A0
=A0 =A0 =A0Client =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Server

=A0 =A0 =A0 minimal ClientHello w/SCSV =A0 =A0-------->
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ServerHello w/SCSV
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<= -------- =A0 =A0 =A0ServerHelloDone
=A0 =A0 =A0 ClientHello =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 --------> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ServerHello
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Certificate*
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0ServerKeyExchange*
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 CertificateRequest*
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<= -------- =A0 =A0 =A0ServerHelloDone
=A0 =A0 =A0 Certificate*
=A0 =A0 =A0 ClientKeyExchange
=A0 =A0 =A0 CertificateVerify*
=A0 =A0 =A0 [ChangeCipherSpec]
=A0 =A0 =A0 Finished =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 --------> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0[ChangeCipherSpec]
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<= -------- =A0 =A0 =A0 =A0 =A0 =A0 Finished
=A0 =A0 =A0 Application Data =A0 =A0 =A0 =A0 =A0 =A0 <-------> =A0 = =A0 Application Data

Well, it could, bu= t I certainly think it's fair to say that getting this deployed will ta= ke much more design and implementation work than deploying=A0TLS_FALLBACK_S= CSV.

There's actually no conflict here. =A0TLS_FALLBACK_= SCSV provides an immediately available simple fix for clients that use prot= ocol fallback strategies. =A0Later, if and when a more elaborate solution i= s available (or if broken servers simply are no longer an issue, whichever = happens first), either clients won't have to send=A0TLS_FALLBACK_SCSV (= if there's no fallback reconnect), or servers won't have to abort t= he connection (if they are able to negotiate a non-downgraded protocol vers= ion as in your protocol sketch).

(I'm highly skeptical that extending the protocol b= y another round as shown in your diagram would be desirable overall and tha= t this would solve a real-world problem in the real world, but the utility = of TLS_FALLBACK_SCSV does not depend on that question.)

Bodo

--001a11332d16da649404f103f1e7-- From rransom.8774@gmail.com Tue Jan 28 06:34:14 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2439D1A0424 for ; Tue, 28 Jan 2014 06:34:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 89eBqbKru54U for ; Tue, 28 Jan 2014 06:34:12 -0800 (PST) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 784321A041B for ; Tue, 28 Jan 2014 06:34:12 -0800 (PST) Received: by mail-qc0-f179.google.com with SMTP id e16so618428qcx.24 for ; Tue, 28 Jan 2014 06:34:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PtfQmWGr9Sap41T79VUCourp9B7Q7TBcCSpbTuD87Eo=; b=TKG/svxFn/x029/Tbndo9+HlwdVYyuFQFKGryJIznV0R/A/3VLMD+lCYg1/6dpZl4h zyBullln6JQLqnppIRxFmyi9yIzX5RfO4PrDUd+1Fann7Hr692Xwc+s3PZbxVHiSOKyV waK+jKd126jj0PdyRSleO9dmpTwCxOlysIiViNscJzJJdop/vVf6z9OIuZ0PBjkzoFEg kBVuo1yaOaVXqFZInX/sI7id6Pl3siADoXKHfjSxPsP97Z4vaqBjsh0/gZPNIsgCvxRa HW4oitAhiUtJtW3ZzLRkzS5bn0+FOXBua7x6R0iwNbydnSfevFoADg9BZjILp/32ZJmn UtdQ== MIME-Version: 1.0 X-Received: by 10.140.89.52 with SMTP id u49mr2574911qgd.93.1390919649738; Tue, 28 Jan 2014 06:34:09 -0800 (PST) Received: by 10.140.86.42 with HTTP; Tue, 28 Jan 2014 06:34:09 -0800 (PST) In-Reply-To: <1390815001.3812.10.camel@dhcp-2-127.brq.redhat.com> References: <87ob3456s1.fsf@latte.josefsson.org> <1390466373.20176.8.camel@dhcp-2-127.brq.redhat.com> <52E2B937.5080502@polarssl.org> <2A0EFB9C05D0164E98F19BB0AF3708C711EB9F2DB6@USMBX1.msg.corp.akamai.com> <282749297.5013598.1390639819914.JavaMail.root@redhat.com> <1390815001.3812.10.camel@dhcp-2-127.brq.redhat.com> Date: Tue, 28 Jan 2014 06:34:09 -0800 Message-ID: From: Robert Ransom To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 Cc: =?UTF-8?Q?Manuel_P=C3=A9gouri=C3=A9=2DGonnard?= , tls@ietf.org Subject: Re: [TLS] Curve25519 in TLS and Additional Curves 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, 28 Jan 2014 14:34:14 -0000 On 1/27/14, Nikos Mavrogiannopoulos wrote: > On Sat, 2014-01-25 at 01:18 -0800, Robert Ransom wrote: > >> > You seem to imply that following conventions established during the >> > years is >> > unecessary. That could be true, but your only point of backing that up >> > is >> > that a library that implements this curve uses the little endian >> > format. >> Several libraries implement Curve25519 scalar multiplication in >> constant time, with varying degrees of portability and efficiency. >> All of them operate on public and secret keys in little-endian format. > > I still cannot see your argument here. Is there a requirement for this > curve to be implemented or do these libraries use little-endian format > because it suits them better (e.g., they target little endian systems)? > This is an honest question as I don't know the answer. Curve25519 has a standard format for public and secret keys: little-endian. Several independent implementations, each of which has its own advantages and disadvantages, conform to that standard. Because each of them implements the existing standard key formats for Curve25519, they interoperate with each other. Complying with the existing, little-endian, standard for Curve25519 key formats would have the major technical advantage that TLS implementations can use existing, off-the-shelf Curve25519 implementations without the unnecessary additional complexity of reversing the bytes of Curve25519 inputs and outputs. I have not seen a compelling *technical* reason for TLS to disobey the currently existing, currently implemented Curve25519 standard by reversing the bytes. >> > Why force any other >> > library that will implement this curve handle its points in a special >> > way? >> Does this mean that you intend to implement Curve25519 using a generic >> bignum library? How will your implementation (attempt to) avoid >> leaking information about key material to a side-channel attacker? > > Do you mean about power analysis (e.g., constant power consumption or > time)? Why would that matter for the protocol in question? Timing attacks can be (and have been) performed successfully on the public-key portions of TLS implementations across a network. They do not require measurements of a server's power supply, as you seem to be implying. Data cache attacks are also relevant for all TLS implementations run on hardware shared among parties who do not trust each other (e.g. virtual private servers). > As I > understand the document specifies additional curves for ephemeral > key exchange (ECDHE), so side channels are not a threat. Side channels are a threat to every protocol implemented in software, unless the implementation guarantees that secret information is not made available to any hardware component which may leak it. >> It is about standardizing a curve which has a well-established >> convention of storing and transmitting keys in little-endian format. > > I believe that software does the transmitting rather than the curve > itself, so that I think that my point of not standardizing software but > a curve is still valid. The existing Curve25519 software represents the rough consensus and running code of several parties. There are at least two independent implementations (Dr. Bernstein's original and Adam Langley's curve25519-donna). As far as IETF is concerned, the existing little-endian key formats for Curve25519 *are* a standard. If you have a *technical* argument that justifies disregarding the existing standard for Curve25519 key formats, please state it. Robert Ransom From ietfc@btconnect.com Tue Jan 28 06:47:52 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD371A0227 for ; Tue, 28 Jan 2014 06:47:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.008 X-Spam-Level: X-Spam-Status: No, score=-1.008 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, 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 GTdhcId6sTpQ for ; Tue, 28 Jan 2014 06:47:50 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id 711651A0216 for ; Tue, 28 Jan 2014 06:47:50 -0800 (PST) Received: from mail40-ch1-R.bigfish.com (10.43.68.246) by CH1EHSOBE014.bigfish.com (10.43.70.64) with Microsoft SMTP Server id 14.1.225.22; Tue, 28 Jan 2014 14:47:47 +0000 Received: from mail40-ch1 (localhost [127.0.0.1]) by mail40-ch1-R.bigfish.com (Postfix) with ESMTP id 553B03C02DB; Tue, 28 Jan 2014 14:47:47 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.249.213; KIP:(null); UIP:(null); IPV:NLI; H:AM2PRD0710HT005.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -15 X-BigFish: PS-15(zz9371I1454I542I1432Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h20f7h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL17326ah8275bh8275dh1de097h186068hz2dh2a8h5a9h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah2222h224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h2218h2216h226dh22d0h24afh2327h2336h2438h2461h2487h24d7h304l1d11m1155h) X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(13464003)(51704005)(377454003)(52044002)(199002)(189002)(76786001)(56776001)(54316002)(76796001)(77096001)(77156001)(46102001)(87976001)(85306002)(87286001)(87266001)(76482001)(51856001)(61296002)(81542001)(81342001)(53806001)(74502001)(74662001)(93136001)(92726001)(84392001)(23756003)(86362001)(80976001)(15202345003)(44736004)(62966002)(33646001)(93916002)(69226001)(50466002)(74706001)(14496001)(15975445006)(74876001)(19580405001)(19580395003)(80022001)(47736001)(83322001)(77982001)(59766001)(49866001)(66066001)(79102001)(50986001)(47976001)(47446002)(94316002)(31966008)(93516002)(42186004)(44716002)(50226001)(62236002)(63696002)(47776003)(90146001)(89996001)(74366001)(92566001)(56816005)(65816001)(85852003)(83072002)(4396001)(88136002)(74416001)(7726001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR07MB060; H:DB3PRD0411HT002.eurprd04.prod.outlook.com; CLIP:157.56.253.53; FPR:; InfoNoRecordsA:0; MX:1; LANG:en; Received: from mail40-ch1 (localhost.localdomain [127.0.0.1]) by mail40-ch1 (MessageSwitch) id 1390920463938671_7741; Tue, 28 Jan 2014 14:47:43 +0000 (UTC) Received: from CH1EHSMHS031.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.226]) by mail40-ch1.bigfish.com (Postfix) with ESMTP id D70E526004A; Tue, 28 Jan 2014 14:47:43 +0000 (UTC) Received: from AM2PRD0710HT005.eurprd07.prod.outlook.com (157.56.249.213) by CH1EHSMHS031.bigfish.com (10.43.70.31) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 28 Jan 2014 14:47:42 +0000 Received: from DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) by AM2PRD0710HT005.eurprd07.prod.outlook.com (10.255.165.40) with Microsoft SMTP Server (TLS) id 14.16.395.1; Tue, 28 Jan 2014 14:47:28 +0000 Received: from DB3PRD0411HT002.eurprd04.prod.outlook.com (157.56.253.53) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.0.859.15; Tue, 28 Jan 2014 14:47:27 +0000 Message-ID: <002201cf1c37$4128b6c0$4001a8c0@gateway.2wire.net> From: t.petch To: Eric Rescorla , References: Date: Tue, 28 Jan 2014 11:09:53 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.253.53] X-ClientProxiedBy: AMSPR07CA002.eurprd07.prod.outlook.com (10.242.77.170) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) X-Forefront-PRVS: 0105DAA385 X-OriginatorOrg: btconnect.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Jan 2014 14:47:52 -0000 Accept. I never wanted SCSV in the first place but now the cat is out of the bag, we might as well make the most of it. Tom Petch ----- Original Message ----- From: "Eric Rescorla" To: Sent: Thursday, January 23, 2014 10:06 AM > WG Members, > > This message is a call for acceptance of > http://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-01 > > As a TLS WG item. > > Please provide any comments on this action by Feb 7. Because > there has been only modest discussion of this document, the > chairs ask people who have already spoken in favor or against > this document to re-register their opinion (feel free to just say > +1 or -1 and point back to the archives.) > > -Ekr > [For the chairs] > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From rsalz@akamai.com Tue Jan 28 06:57:03 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 867D01A0227 for ; Tue, 28 Jan 2014 06:57:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id paHusNPUOy5J for ; Tue, 28 Jan 2014 06:57:02 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 78F251A008E for ; Tue, 28 Jan 2014 06:57:02 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id B588C284F0; Tue, 28 Jan 2014 14:56:59 +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 A2321284EE; Tue, 28 Jan 2014 14:56:59 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub4.kendall.corp.akamai.com [172.27.105.20]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 9F2932027; Tue, 28 Jan 2014 14:56:59 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.92]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Tue, 28 Jan 2014 09:56:59 -0500 From: "Salz, Rich" To: Robert Ransom , Nikos Mavrogiannopoulos Date: Tue, 28 Jan 2014 09:56:58 -0500 Thread-Topic: [TLS] Curve25519 in TLS and Additional Curves in TLS Thread-Index: Ac8cNgM23H4S2pLuRxmOCxf7/19l4QAAyIxQ Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711EB9F3513@USMBX1.msg.corp.akamai.com> References: <87ob3456s1.fsf@latte.josefsson.org> <1390466373.20176.8.camel@dhcp-2-127.brq.redhat.com> <52E2B937.5080502@polarssl.org> <2A0EFB9C05D0164E98F19BB0AF3708C711EB9F2DB6@USMBX1.msg.corp.akamai.com> <282749297.5013598.1390639819914.JavaMail.root@redhat.com> <1390815001.3812.10.camel@dhcp-2-127.brq.redhat.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: =?utf-8?B?TWFudWVsIFDDqWdvdXJpw6ktR29ubmFyZA==?= , "tls@ietf.org" Subject: Re: [TLS] Curve25519 in TLS and Additional Curves 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, 28 Jan 2014 14:57:03 -0000 PiBJIGhhdmUgbm90IHNlZW4gYSBjb21wZWxsaW5nICp0ZWNobmljYWwqIHJlYXNvbiBmb3IgVExT IHRvIGRpc29iZXkgdGhlIGN1cnJlbnRseSBleGlzdGluZywgY3VycmVudGx5IGltcGxlbWVudGVk IEN1cnZlMjU1MTkgc3RhbmRhcmQgYnkgcmV2ZXJzaW5nIHRoZSBieXRlcy4NCg0KUmlnaHQuDQoN Cg0KDQotLSAgDQpQcmluY2lwYWwgU2VjdXJpdHkgRW5naW5lZXINCkFrYW1haSBUZWNobm9sb2d5 DQpDYW1icmlkZ2UsIE1BDQoNCg== From Andrei.Popov@microsoft.com Tue Jan 28 07:41:51 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 161311A0424 for ; Tue, 28 Jan 2014 07:41:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Bb4jrZpRIkOZ for ; Tue, 28 Jan 2014 07:41:49 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0204.outbound.protection.outlook.com [207.46.163.204]) by ietfa.amsl.com (Postfix) with ESMTP id 8482F1A03B6 for ; Tue, 28 Jan 2014 07:41:49 -0800 (PST) Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BL2PR03MB417.namprd03.prod.outlook.com (10.141.92.12) with Microsoft SMTP Server (TLS) id 15.0.868.8; Tue, 28 Jan 2014 15:41:45 +0000 Received: from BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) by BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) with mapi id 15.00.0859.020; Tue, 28 Jan 2014 15:41:45 +0000 From: Andrei Popov To: Adam Langley Thread-Topic: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv Thread-Index: AQHPGCLYtuT5cbQOIEmjzG1QZtPhb5qY2GuAgAAk7YCAAE8UgIAAB82QgAASrACAAOV7yw== Date: Tue, 28 Jan 2014 15:41:44 +0000 Message-ID: References: <20140128001737.D9D581ABC9@ld9781.wdf.sap.corp> <828b043cac0f4b62875d00f31d2f92e3@BL2PR03MB419.namprd03.prod.outlook.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.46.247.0] x-forefront-prvs: 0105DAA385 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(164054003)(189002)(199002)(377454003)(24454002)(69226001)(46102001)(76576001)(51856001)(93136001)(87936001)(76796001)(76786001)(561944002)(59766001)(77982001)(79102001)(53806001)(54356001)(76482001)(74502001)(31966008)(74662001)(47446002)(83072002)(85306002)(87266001)(74366001)(90146001)(56816005)(19580395003)(92566001)(74316001)(2656002)(85852003)(83322001)(19580405001)(54316002)(81686001)(81816001)(81342001)(80976001)(93516002)(74876001)(66066001)(74706001)(47736001)(49866001)(4396001)(80022001)(56776001)(33646001)(81542001)(94316002)(47976001)(65816001)(86362001)(50986001)(63696002)(7756004)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR03MB417; H:BL2PR03MB419.namprd03.prod.outlook.com; CLIP:50.46.247.0; FPR:2ED85514.20D247CA.BDE163BB.8AE0E1ED.20221; InfoNoRecordsMX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "tls@ietf.org" Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Jan 2014 15:41:51 -0000 Yes, this makes sense, and the other fatal TLS alerts are defined for simil= ar reasons. Because of Martin's comment, I thought I might be overlooking a= security issue with not sending inappropriate_fallback.=0A= =0A= Thanks,=0A= =0A= Andrei=0A= =0A= ________________________________________=0A= From: Adam Langley =0A= Sent: Monday, January 27, 2014 5:52 PM=0A= To: Andrei Popov=0A= Cc: mrex@sap.com; Bodo Moeller; tls@ietf.org=0A= Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv= =0A= =0A= On Mon, Jan 27, 2014 at 8:04 PM, Andrei Popov=0A= wrote:=0A= > For my understanding: why is this proposal vitally dependent on the serve= r sending inappropriate_fallback alert? If the server receives the SCSV, ha= s a higher protocol version enabled than that in the ClientHello, and quiet= ly aborts the handshake, isn't the downgrade attack thwarted?=0A= =0A= Yes, just closing the connection is good enough for security. The=0A= advantage of returning the fatal alert is that a) it stops the=0A= fallback process faster and b) the client can report the error that=0A= caused the original connection to fail, rather than that the final=0A= fallback hit connection closed.=0A= =0A= =0A= Cheers=0A= =0A= AGL=0A= From ynir@checkpoint.com Tue Jan 28 07:57:47 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF1BB1A03B6 for ; Tue, 28 Jan 2014 07:57:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.436 X-Spam-Level: X-Spam-Status: No, score=-7.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, 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 sDp9eaFpnuIu for ; Tue, 28 Jan 2014 07:57:43 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 0AEDF1A0227 for ; Tue, 28 Jan 2014 07:57:41 -0800 (PST) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id s0SFvaGD005079; Tue, 28 Jan 2014 17:57:37 +0200 X-CheckPoint: {52E7CD05-10-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.110]) by IL-EX10.ad.checkpoint.com ([169.254.2.228]) with mapi id 14.03.0123.003; Tue, 28 Jan 2014 17:57:37 +0200 From: Yoav Nir To: Andrei Popov Thread-Topic: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv Thread-Index: AQHPGCLa7p3uMjOdpEO8c0/oGRcyYJqYtuSAgAAk7YCAAE8UgIAADSUAgAANVACAAOe5AIAABF4A Date: Tue, 28 Jan 2014 15:57:36 +0000 Message-ID: References: <20140128001737.D9D581ABC9@ld9781.wdf.sap.corp> <828b043cac0f4b62875d00f31d2f92e3@BL2PR03MB419.namprd03.prod.outlook.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.176] x-kse-antivirus-interceptor-info: protection disabled Content-Type: text/plain; charset="us-ascii" Content-ID: <62D80102C10DE14EAF9066675E2B0977@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Jan 2014 15:57:48 -0000 Well, suppose a client implements a three-stage fallback: TLS1.2-with-exten= sions--->TLS1.0-with-extensions--->SSLv3. Suppose TLS1.2-with-extensions got a RST. The client is now trying TLS1.0-w= ith-extensions. If it gets an alert, it will know that it needs to stop. If= it gets another RST, it will proceed to try SSLv3, and that's a bad thing,= because it should have stopped at TLS 1.0. I don't think it matters much, because if an attacker can cause a TLS 1.2 s= ession to fail, it can do the same to a TLS 1.0 session. So an attacker can= always force the sides to the lowest common denominator. The best this ext= ension can do is to make sure that when they finally do talk to each other = at the lowest common denominator, that they recognize that the interference= had happened. As long as they don't go below SSLv3, they will know that wi= th the SCSV, regardless of whether the server resets or sends an appropriat= e alert. Yoav On Jan 28, 2014, at 5:41 PM, Andrei Popov wrote: > Yes, this makes sense, and the other fatal TLS alerts are defined for sim= ilar reasons. Because of Martin's comment, I thought I might be overlooking= a security issue with not sending inappropriate_fallback. >=20 > Thanks, >=20 > Andrei >=20 > ________________________________________ > From: Adam Langley > Sent: Monday, January 27, 2014 5:52 PM > To: Andrei Popov > Cc: mrex@sap.com; Bodo Moeller; tls@ietf.org > Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scs= v >=20 > On Mon, Jan 27, 2014 at 8:04 PM, Andrei Popov > wrote: >> For my understanding: why is this proposal vitally dependent on the serv= er sending inappropriate_fallback alert? If the server receives the SCSV, h= as a higher protocol version enabled than that in the ClientHello, and quie= tly aborts the handshake, isn't the downgrade attack thwarted? >=20 > Yes, just closing the connection is good enough for security. The > advantage of returning the fatal alert is that a) it stops the > fallback process faster and b) the client can report the error that > caused the original connection to fail, rather than that the final > fallback hit connection closed. >=20 >=20 > Cheers >=20 > AGL > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 > Email secured by Check Point From Andrei.Popov@microsoft.com Tue Jan 28 12:12:09 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 522351A045F for ; Tue, 28 Jan 2014 12:12:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 u3u5hIjxckLY for ; Tue, 28 Jan 2014 12:12:06 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0156.outbound.protection.outlook.com [207.46.163.156]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB281A03AA for ; Tue, 28 Jan 2014 12:12:06 -0800 (PST) Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BL2PR03MB418.namprd03.prod.outlook.com (10.141.92.13) with Microsoft SMTP Server (TLS) id 15.0.868.8; Tue, 28 Jan 2014 20:12:02 +0000 Received: from BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) by BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) with mapi id 15.00.0859.020; Tue, 28 Jan 2014 20:12:02 +0000 From: Andrei Popov To: Yoav Nir Thread-Topic: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv Thread-Index: AQHPGCLYtuT5cbQOIEmjzG1QZtPhb5qY2GuAgAAk7YCAAE8UgIAAB82QgAASrACAAOV7y4AABq0AgABAF0A= Date: Tue, 28 Jan 2014 20:12:01 +0000 Message-ID: <062f690386314652b30aa8247ec18c0c@BL2PR03MB419.namprd03.prod.outlook.com> References: <20140128001737.D9D581ABC9@ld9781.wdf.sap.corp> <828b043cac0f4b62875d00f31d2f92e3@BL2PR03MB419.namprd03.prod.outlook.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ee43::3] x-forefront-prvs: 0105DAA385 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(979002)(6009001)(164054003)(24454002)(51704005)(189002)(199002)(377454003)(13464003)(76482001)(81816001)(56776001)(54316002)(85306002)(51856001)(46102001)(53806001)(54356001)(79102001)(83072002)(31966008)(85852003)(81542001)(74662001)(47446002)(74502001)(92566001)(81686001)(76796001)(76786001)(69226001)(65816001)(33646001)(80976001)(76576001)(80022001)(93136001)(93516002)(74706001)(74876001)(74366001)(87266001)(83322001)(19580405001)(81342001)(63696002)(74316001)(561944002)(87936001)(86362001)(19580395003)(4396001)(47736001)(47976001)(50986001)(49866001)(2656002)(77982001)(90146001)(56816005)(94316002)(59766001)(15975445006)(24736002)(3826001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR03MB418; H:BL2PR03MB419.namprd03.prod.outlook.com; CLIP:2001:4898:80e0:ee43::3; FPR:2EFCF137.A8F217CA.BCF25177.8AF49943.20412; InfoNoRecordsMX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "tls@ietf.org" Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Jan 2014 20:12:09 -0000 Correct, but I'm more concerned about this scenario: suppose a client imple= ments a three-stage fallback: TLS1.2-with-extensions ---> TLS1.0-with-exten= sions ---> SSLv3. Suppose TLS1.2-with-extensions got a RST from a TLS1.2-supporting server be= cause there is an interoperability problem, or a middle box problem, or a c= onfiguration problem, etc. The client is now trying TLS1.0-with-extensions + SCSV. Without the SCSV, t= he handshake may have succeeded, but with SCSV the TLS connection will fail= . >From the standpoint of the browser vendors, this largely defeats the purpos= e of re-connects. Perhaps a browser could only send the SCSV on the last re= -connect, when downgraded to the least secure protocol version (e.g. SSL3).= But even this compromise seems unlikely to get deployed. Cheers, Andrei -----Original Message----- From: Yoav Nir [mailto:ynir@checkpoint.com]=20 Sent: Tuesday, January 28, 2014 7:58 AM To: Andrei Popov Cc: Adam Langley; tls@ietf.org Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv Well, suppose a client implements a three-stage fallback: TLS1.2-with-exten= sions--->TLS1.0-with-extensions--->SSLv3. Suppose TLS1.2-with-extensions got a RST. The client is now trying TLS1.0-w= ith-extensions. If it gets an alert, it will know that it needs to stop. If= it gets another RST, it will proceed to try SSLv3, and that's a bad thing,= because it should have stopped at TLS 1.0. I don't think it matters much, because if an attacker can cause a TLS 1.2 s= ession to fail, it can do the same to a TLS 1.0 session. So an attacker can= always force the sides to the lowest common denominator. The best this ext= ension can do is to make sure that when they finally do talk to each other = at the lowest common denominator, that they recognize that the interference= had happened. As long as they don't go below SSLv3, they will know that wi= th the SCSV, regardless of whether the server resets or sends an appropriat= e alert. Yoav On Jan 28, 2014, at 5:41 PM, Andrei Popov wrote: > Yes, this makes sense, and the other fatal TLS alerts are defined for sim= ilar reasons. Because of Martin's comment, I thought I might be overlooking= a security issue with not sending inappropriate_fallback. >=20 > Thanks, >=20 > Andrei >=20 > ________________________________________ > From: Adam Langley > Sent: Monday, January 27, 2014 5:52 PM > To: Andrei Popov > Cc: mrex@sap.com; Bodo Moeller; tls@ietf.org > Subject: Re: [TLS] Call for acceptance of=20 > draft-moeller-tls-downgrade-scsv >=20 > On Mon, Jan 27, 2014 at 8:04 PM, Andrei Popov=20 > wrote: >> For my understanding: why is this proposal vitally dependent on the serv= er sending inappropriate_fallback alert? If the server receives the SCSV, h= as a higher protocol version enabled than that in the ClientHello, and quie= tly aborts the handshake, isn't the downgrade attack thwarted? >=20 > Yes, just closing the connection is good enough for security. The=20 > advantage of returning the fatal alert is that a) it stops the=20 > fallback process faster and b) the client can report the error that=20 > caused the original connection to fail, rather than that the final=20 > fallback hit connection closed. >=20 >=20 > Cheers >=20 > AGL > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 > Email secured by Check Point From agl@google.com Tue Jan 28 12:19:57 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC871A0245 for ; Tue, 28 Jan 2014 12:19:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.914 X-Spam-Level: X-Spam-Status: No, score=-1.914 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, RP_MATCHES_RCVD=-0.535, 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 CqRVwNo2LLGU for ; Tue, 28 Jan 2014 12:19:54 -0800 (PST) Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id ACA991A028B for ; Tue, 28 Jan 2014 12:19:54 -0800 (PST) Received: by mail-oa0-f42.google.com with SMTP id i7so1008412oag.15 for ; Tue, 28 Jan 2014 12:19:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=+gW1XaDXBDKCIcfB0M7OVGJo/5OAtU/YxCWH4WQWfA0=; b=dCqQAVGfNjKNepw/T5kwN1UVJPdpXXvu/AiQh6vwlghBYgz8ya/8BXYwzHYY8eLzh0 ur8MpXd/TmmZORFXcmwxoVo8J2fEfX74V01RTlS24X6sBZ91GCHttmTUQs/jHZA9QHFV pjf43n7nL3ie9f5ahr9KwlVOVJT4gAM2HyZQsqWtSVvhpAOwq60td/2CdeAVOLxFIISV fDGdLT4XMVyiLfBRtacV3aqwTXNNYcgE5yCUQpv6Jq5PDSZWb7Oqxc+tPasBWk8ja3tf JpccRWjHnbg7ZOaS11yf+TWNlgDNNllHuZOiH3HuJCwKjR4VLt9GdJI1oOfjNcfhps2P Yz5A== 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=+gW1XaDXBDKCIcfB0M7OVGJo/5OAtU/YxCWH4WQWfA0=; b=CEgatYXzKebMocVoiCiVe/q+cCTDzWo0+o04WQ9u+jIqslnDYx5Eq4xcnOk1x135Qq EJ22LYSXGIyayyeniKq0JXH3CcgB62cUmvsvHxX2t27I292Bh7rodJA6Gx0jneTmrXCl cyOgkNYmfs8m6047410Um4go1Cw65c+W8MODM7jhK39McdTB00zsUBnXzf1IuOXCOp6C KsPQf/ERggTSynG+sFXjyeDgf2efJmfN80eBtSAdWb55HvmtqHX3oN2vpkWtTtjrizyr /M4Dk4GUX++7XklAN919mTNSeKszjp/KzJRSkHYnDMNuWBRWHYyCj4HD7yKk2RQeBFpN 3ZKQ== X-Gm-Message-State: ALoCoQlYVH5TciP6QnI58QTdRp2+eQiXthJz7sR8AgszyBpBFdciUt0H8VWi4PPeK/lA8n763YGTpnO3up3bIt30TdQu8kzqJx2VKPuj9qYmazv9mMnVPWutYHgEBYRr8BhWUctfFMRiea/rHLSran9tHfCxaWJ0nJ7sdE2niO0GSGay7dDgmQUbZ+F6TqwpoGJHMrkcjruP X-Received: by 10.60.119.70 with SMTP id ks6mr2576146oeb.45.1390940391847; Tue, 28 Jan 2014 12:19:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.79.105 with HTTP; Tue, 28 Jan 2014 12:19:31 -0800 (PST) In-Reply-To: <062f690386314652b30aa8247ec18c0c@BL2PR03MB419.namprd03.prod.outlook.com> References: <20140128001737.D9D581ABC9@ld9781.wdf.sap.corp> <828b043cac0f4b62875d00f31d2f92e3@BL2PR03MB419.namprd03.prod.outlook.com> <062f690386314652b30aa8247ec18c0c@BL2PR03MB419.namprd03.prod.outlook.com> From: Adam Langley Date: Tue, 28 Jan 2014 15:19:31 -0500 Message-ID: To: Andrei Popov Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Jan 2014 20:19:57 -0000 On Tue, Jan 28, 2014 at 3:12 PM, Andrei Popov wrote: > Correct, but I'm more concerned about this scenario: suppose a client implements a three-stage fallback: TLS1.2-with-extensions ---> TLS1.0-with-extensions ---> SSLv3. > Suppose TLS1.2-with-extensions got a RST from a TLS1.2-supporting server because there is an interoperability problem, or a middle box problem, or a configuration problem, etc. > The client is now trying TLS1.0-with-extensions + SCSV. Without the SCSV, the handshake may have succeeded, but with SCSV the TLS connection will fail. We have pretty good evidence that SCSVs are ok from putting them in SSLv3 for renego, no? I suppose it's possible that there exist some TLSv1 servers that handle the renego extension, but couldn't handle the SCSV, but we have deployed new ciphersuites in the past without issue, no? (Except for the servers that only look at the lower 8-bits, but we believe that we can order the ciphersuites to avoid those problems.) Cheers AGL From watsonbladd@gmail.com Tue Jan 28 12:38:33 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DCE41A0465 for ; Tue, 28 Jan 2014 12:38:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tmlMU9aKVdoW for ; Tue, 28 Jan 2014 12:38:31 -0800 (PST) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 473FB1A026C for ; Tue, 28 Jan 2014 12:38:31 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id x13so1784500wgg.21 for ; Tue, 28 Jan 2014 12:38:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OD+zVsxuHrIjO/oqRdnsJQ6ELplhFaPQrtchHfafWZQ=; b=r5KlxMiJ6C4itMAPH7SfjTAQ9oPF4yJCbiYpG8m4d0l2t2t/yPguRCEiPdrL4zbJhL vy79ok6Am5hPNbRuCS//fb5a540EGH8Y2D2lsa3LkrmZYPBlXwAqMYK6cgNRESSjNMA1 uvDmUMo1406Pkoh/K95YyuZhj5D97POaIgbXjypQcIJ/ecAZB4AIT1mFcGQxgfmtsFqe yrUWRt9N3dlQcrNlefOML828rWSyAWsq3QLGU2ReeSJ85JwctsEyj3KlXHuwtmd4qubE EIyTgEvDixs9vo9rK04Kp7be91QmTKdafdNJPB/IMV3Wl+OOevmHkNn6ORe9tjx+iU2V n7Qg== MIME-Version: 1.0 X-Received: by 10.180.189.169 with SMTP id gj9mr3742821wic.17.1390941508183; Tue, 28 Jan 2014 12:38:28 -0800 (PST) Received: by 10.194.250.101 with HTTP; Tue, 28 Jan 2014 12:38:28 -0800 (PST) In-Reply-To: References: <20140128001737.D9D581ABC9@ld9781.wdf.sap.corp> <828b043cac0f4b62875d00f31d2f92e3@BL2PR03MB419.namprd03.prod.outlook.com> <062f690386314652b30aa8247ec18c0c@BL2PR03MB419.namprd03.prod.outlook.com> Date: Tue, 28 Jan 2014 12:38:28 -0800 Message-ID: From: Watson Ladd To: Adam Langley Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Jan 2014 20:38:33 -0000 On Tue, Jan 28, 2014 at 12:19 PM, Adam Langley wrote: > On Tue, Jan 28, 2014 at 3:12 PM, Andrei Popov > wrote: >> Correct, but I'm more concerned about this scenario: suppose a client implements a three-stage fallback: TLS1.2-with-extensions ---> TLS1.0-with-extensions ---> SSLv3. >> Suppose TLS1.2-with-extensions got a RST from a TLS1.2-supporting server because there is an interoperability problem, or a middle box problem, or a configuration problem, etc. >> The client is now trying TLS1.0-with-extensions + SCSV. Without the SCSV, the handshake may have succeeded, but with SCSV the TLS connection will fail. > > We have pretty good evidence that SCSVs are ok from putting them in > SSLv3 for renego, no? No, that isn't the concern Mr. Popov expresses. The concern is that the TLS 1.2 supporting server thinks it supports TLS 1.2 but actually doesn't. Then the fallback to TLS 1.0 fails, instead of succeeds, because it's a fallback that is unnecessary according to the server. He's exactly correct that putting in this SCSV will cause a connection failure. However, this can't be distinguished from a downgrade attack, and I doubt that servers will have mistaken beliefs about their TLS 1.2 support. > > I suppose it's possible that there exist some TLSv1 servers that > handle the renego extension, but couldn't handle the SCSV, but we have > deployed new ciphersuites in the past without issue, no? (Except for > the servers that only look at the lower 8-bits, but we believe that we > can order the ciphersuites to avoid those problems.) > > > Cheers > > AGL > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From agl@google.com Tue Jan 28 12:43:54 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E67C1A0469 for ; Tue, 28 Jan 2014 12:43:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.914 X-Spam-Level: X-Spam-Status: No, score=-1.914 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, RP_MATCHES_RCVD=-0.535, 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 9HHZmQSrK4Ar for ; Tue, 28 Jan 2014 12:43:53 -0800 (PST) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 3BBFA1A0475 for ; Tue, 28 Jan 2014 12:43:53 -0800 (PST) Received: by mail-ob0-f170.google.com with SMTP id va2so1003145obc.15 for ; Tue, 28 Jan 2014 12:43:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=xOszUX58xNxUSgOLWpT9WxUkPED+9FrArvHZ5VscvUc=; b=c2yaoMQJ4BCYASuN7m8qiCZftqtMwqy0ZgRVTtfuU7rbZIy2rpQPpmDcBwTXLAR9vf tS8WGGa8VUzFu8LXLRR4ZIT/iQUBPlmQVsZOwR4wEg/ZzcXalO2meVzTYp4EaCnoRymn HPuhSLO30VNZiThJ92MD5fqVJraIUczN7dlk7CdInhk97iVreAlHCpj/69yxRXGE/dkD GJLilyplB2pPuffE2GqSA4lJsgACY0jMhoX2icxxByB21RU8tNlVobKACjmhEsvfLosf Va7zpI8AOcKIt52YnslCo5ocJqDHRKOEC7EMQl9NnVgACGi6r5HDFbtd+sQB+TyzAq+V bM+A== 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=xOszUX58xNxUSgOLWpT9WxUkPED+9FrArvHZ5VscvUc=; b=BFmhKqwpoyeV/SJsWSog8P0nTo4kz1M/++wUcI0fG9HUiOMD81VfIAw1VBb0Bfl/tO exmI3uZI/ooFgdfe2HAdQJlHru1wPIjr0M4VXhLEAKRb90tym5DSBakJL7H3N0NzbdSo II393xv1yrpfJGU39ItOejzWMox5cdXoeYHbXe1aJuynn19fa+1bApuzOBtLZO4bCzGM Zo8E31hm4Y41sUHGtX7ZFR4uapKUhlx6BAS6b6xZ6kS50NkFyhb1Vsn9zbJDLXbbF36a kZseWfwOX6FqMSYju8eGabdYtNL3Y6AztkpcRNWjhVoygfKaD2VMZ3u7rn62bFIdx7eD DhKw== X-Gm-Message-State: ALoCoQnZKkKm6B+xbTqsJXP98/hiLkWlMVqIPSpC3uXhEJIAmLLTXA5idfi9KXuRnlznrfD6JmX83rcMPYfV2o8I8P56USmc7gOZtq16Uz6aICKq0B8iIukJc8ZIDSMB6rZTlmilk4Pfdeg+tv407RFTPSGs5cv/KU4dRydi4Ixa9SGVXhnRNzMqAGZmbPLLA8Ec8smhxYJY X-Received: by 10.60.132.107 with SMTP id ot11mr2741545oeb.8.1390941830516; Tue, 28 Jan 2014 12:43:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.79.105 with HTTP; Tue, 28 Jan 2014 12:43:30 -0800 (PST) In-Reply-To: References: <20140128001737.D9D581ABC9@ld9781.wdf.sap.corp> <828b043cac0f4b62875d00f31d2f92e3@BL2PR03MB419.namprd03.prod.outlook.com> <062f690386314652b30aa8247ec18c0c@BL2PR03MB419.namprd03.prod.outlook.com> From: Adam Langley Date: Tue, 28 Jan 2014 15:43:30 -0500 Message-ID: To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Jan 2014 20:43:54 -0000 On Tue, Jan 28, 2014 at 3:38 PM, Watson Ladd wrote: > No, that isn't the concern Mr. Popov expresses. The concern is that > the TLS 1.2 supporting server thinks it supports TLS 1.2 but actually > doesn't. Then the fallback to TLS 1.0 fails, instead of succeeds, > because it's a fallback that is unnecessary according to the server. Ah, I see. It's certainly possible that clients that are currently doing a fallback because of a middle box will stop working because of this SCSV, yes. It won't be clear how big a problem this is until Chrome 33 rolls out. If we get a good population of clients with this SCSV however, servers that add support for it and need fallbacks should find any problems in testing. There might be areas of TLS 1.2 that the population of SCSV-enabled clients don't test and bad servers could grow in that space. That's also the case today. Cheers AGL From frantz@pwpconsult.com Tue Jan 28 16:11:41 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7C311A02F1 for ; Tue, 28 Jan 2014 16:11:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_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 8nPkMhwTEvq1 for ; Tue, 28 Jan 2014 16:11:39 -0800 (PST) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id D4AD51A018F for ; Tue, 28 Jan 2014 16:11:39 -0800 (PST) Received: from [173.75.83.192] (helo=Williams-MacBook-Pro.local) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1W8Iki-0004T8-M3 for tls@ietf.org; Tue, 28 Jan 2014 19:11:36 -0500 Date: Tue, 28 Jan 2014 16:11:34 -0800 From: Bill Frantz To: tls@ietf.org X-Priority: 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.3.1 (422) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec7936fa02abe799ff64fe4efe27272c9457350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 173.75.83.192 Subject: Re: [TLS] Curve25519 in TLS and Additional Curves 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, 29 Jan 2014 00:11:41 -0000 There is two thing that all long-term endian warriors have in=20 common. (1) They have a strong opinion about what the right=20 answer is; and (2) They wish the other side had won a complete victory. In this spirit, please look at RFC1762 which says: Exactly one length field and one DNA Phase IV Routing=20 packet are encapsulated in the information field of a PPP Data Link Layer frame where the Protocol field indicates type hex 0027=20 (DNA Phase IV Routing). The length field contains a count of the=20 number of octets in the DNA Phase IV Routing packet. It is two=20 octets in length itself, and is stored in VAX byte ordering, to be more consistent with DNA Phase IV Routing over Ethernet (i.e. least significant byte first). It is needed to disambiguate optional padding octets from real information. So it would not be unprecedented to have little endian data in=20 an Internet Protocol. Cheers - Bill ----------------------------------------------------------------------- Bill Frantz | Privacy is dead, get over | Periwinkle (408)356-8506 | it. | 16345=20 Englewood Ave www.pwpconsult.com | - Scott McNealy | Los Gatos,=20 CA 95032 From mrex@sap.com Tue Jan 28 19:18:44 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D04701A033C for ; Tue, 28 Jan 2014 19:18:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 QDgYad9Fs51b for ; Tue, 28 Jan 2014 19:18:42 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id DF32A1A015E for ; Tue, 28 Jan 2014 19:18:41 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s0T3IZKi029934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 29 Jan 2014 04:18:35 +0100 (MET) In-Reply-To: To: Bodo Moeller Date: Wed, 29 Jan 2014 04:18:35 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140129031835.A80091ABCF@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "tls@ietf.org" Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 03:18:45 -0000 Bodo Moeller wrote: > Martin Rex : > > The negotiation could work like this: > > > > Client Server > > > > minimal ClientHello w/SCSV --------> > > ServerHello w/SCSV > > <-------- ServerHelloDone > > ClientHello --------> > > ServerHello > > Certificate* > > ServerKeyExchange* > > CertificateRequest* > > <-------- ServerHelloDone > > Certificate* > > ClientKeyExchange > > CertificateVerify* > > [ChangeCipherSpec] > > Finished --------> > > [ChangeCipherSpec] > > <-------- Finished > > Application Data <-------> Application Data > > > > Well, it could, but I certainly think it's fair to say that getting this > deployed will take much more design and implementation work than > deploying TLS_FALLBACK_SCSV. > > There's actually no conflict here. TLS_FALLBACK_SCSV provides an > immediately available simple fix for clients that use protocol fallback > strategies. Later, if and when a more elaborate solution is available (or > if broken servers simply are no longer an issue, whichever happens first), > either clients won't have to send TLS_FALLBACK_SCSV (if there's no fallback > reconnect), or servers won't have to abort the connection (if they are able > to negotiate a non-downgraded protocol version as in your protocol sketch). > > (I'm highly skeptical that extending the protocol by another round as shown > in your diagram would be desirable overall and that this would solve a > real-world problem in the real world, but the utility of TLS_FALLBACK_SCSV > does not depend on that question.) In contrast to your proposal, such an approach would result in additional interoperability that can be transparently provided by two TLS implementations. Compare it to what your current proposal *REALLY* amounts to: Client Server minimal ClientHello w/SCSV --------> <-------- FatalAlert close() TCP FIN --------> <-------- TCP FIN ACK TCP ACK --------> connect() TCP SYN --------> <-------- TCP SYN ACK TCP ACK --------> "HTTP CONNECT a.b.c:1234" ---> <--- "HTTP/x.y 200 Connection established" ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data and you need to redesign each and every TLS application caller to implement this reconnect fallback in order to be able to use this. The example protocol flow that I gave is just one possible outcome, the server could simply continue a regular handshake if it doesn't expect any benefits from the client doing a reconnect fallback. Right now, the vast majority of programmatic TLS clients do not implement reconnect fallbacks and will therefore use a conservative TLSv1.0-only ClientHello, maybe even an extension-less TLSv1.0 ClientHello to get the best interoperability results. With the fall-forward approach, the TLS implementation could transparently provide an in-band upgrade to TLSv1.2 features without loosing any connectivity to TLS version-intolerant and TLS extensions-intolerant servers, and without any single caller having to retrofit a reconnect fallback at the application layer. In many communication scenarios, full handshakes are rare to compared to TLS session resumes, and none of the complexity appears on TLS session resumes and neither on full handshakes with a session resumption proposal (that may turn into a full TLS handshake when the server has already expired the session on his side). If you're wondering about the amount of changes that are required and the likelyhood of a change getting deployed--the real benefit and the amount of situations/connections & components that will benefit from a change may actually be more important than the size of the code change itself. The sooner we can obviate reconnect fallback hacks, the better. I've had a few apps folks come and ask for support for TLSv1.1 & TLSv1.2 in our TLS client. Every time when I explain to them that they will either be facing a sustained level of customer support calls to analyze and fix connection failures, or they will have to retrofit a complex, heuristics-based multi-level reconnect fallback logic into their application I see jaws dropping all the way to the floor and they bin their plans. -Martin From jsalowey@cisco.com Wed Jan 29 11:30:41 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 490AB1A03E9 for ; Wed, 29 Jan 2014 11:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.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 GLvyr8XLht_t for ; Wed, 29 Jan 2014 11:30:39 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 14E701A0361 for ; Wed, 29 Jan 2014 11:30:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4107; q=dns/txt; s=iport; t=1391023836; x=1392233436; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=CxAlTx2VnVFLBrLhsL4seRascvkWSnWMuqVW7UW+mME=; b=HeqcRsk1p/jUoETGYPohjv5zapPHeJixYVZSqYjw+Mc25FEaEW/vTzjN SGPw4KtgjMQqDz4Ae2d1W75/24WGwp6wKrbc1Sml8gtAD/XNdFVHz/VzY DB2rnsJTxza/87JpEEuuPEH8S4OVDxizYBZkvw27q+Ql++zHvl1NrMyFL M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAEhW6VKtJV2b/2dsb2JhbABDFoMMOFa9CYEHFnSCJQEBAQMBAQEBGhQJNAUGBQsCAQgYEwsQIQYLJQIEDgWHcQMJCA2sdJR2DYgKEwSMaoErNzMHgySBFASWPIFsjF6FQYMtgWgHHR4 X-IronPort-AV: E=Sophos;i="4.95,743,1384300800"; d="scan'208";a="300571980" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 29 Jan 2014 19:30:36 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0TJUZnR016307 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Jan 2014 19:30:35 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.227]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Wed, 29 Jan 2014 13:30:35 -0600 From: "Joseph Salowey (jsalowey)" To: Watson Ladd Thread-Topic: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv Thread-Index: AQHPHSiU5SA2NYIuD02DzGrb0hd6LQ== Date: Wed, 29 Jan 2014 19:30:35 +0000 Message-ID: References: <52E2DA85.4010705@fifthhorseman.net> <20140125042425.230961ABCA@ld9781.wdf.sap.corp> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.158] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 29 Jan 2014 19:30:41 -0000 Hi Folks, I'm glad that we have people that are motivated and passionate about this t= opic participating in this discussion. This is a good thing for the standa= rds process, however we need to temper our comments on the list so the tone= does not come across as personal and negative. This behavior turns both o= bservers and other participants away from the discussion. This is bad for = the standards process. If you have issues with some aspect of the discuss= ion please raise that with the chairs or ADs. =20 Some comments inline below.=20 =20 Thanks, Joe On Jan 24, 2014, at 9:57 PM, Watson Ladd wrote: > On Fri, Jan 24, 2014 at 8:24 PM, Martin Rex wrote: >> Daniel Kahn Gillmor wrote: >>>=20 >>> By transmitting this SCSV, the client is saying to the server "just so >>> you know, i tried a better protocol, but it didn't work -- if you meant >>> to accept better protocols, then someone is messing with us, please abo= rt." >>>=20 >>> The server knows whether it believes it can accept better protocols, so >>> it is in the right position to make this call. >>=20 >> The _only_ reasonable server response of a TLS server that supports TLSv= 1.2 >> to a ClientHello that contains an SCSV which indicates that the client >> (a) supports TLSv1.2 and (b) would prefer to use TLSv1.2 >> is a ServerHello with server_version=3DTLSv1.2. >=20 > Let me try to explain, in words as simple as possible, why everything > you have contributed > to this thread is just wrong. >=20 [Joe] The above is unnecessary. > Some servers are version intolerant to TLS 1.0. For this reason, and > not because of middleboxes, > version fallback cannot be stopped. >=20 > Some clients only offer SSL 3.0. Until these clients are gone, some > servers will want to serve them. >=20 > Right now these servers have a dilemma: they cannot serve the SSL 3.0 > population without permitting > clients offering TLS 1.0 or higher to get forced back down to SSL 3.0 > by an attacker. There are real, unfixable > problems with SSL 3.0, including the lack of an extension mechanism. > Unfortunately, TLS 1.0, 1.1, and 1.2 rely > on extensions to indicate which curves are supported. It isn't > possible to send at ServerHello back after > seeing a ClientHello with "I tried TLS 1.2, and it didn't work" > because sending back a ServerHello requires > information you don't have, like what curves are supported. >=20 > This proposal solves that problem by letting clients indicate if they > are dropping down because of fallback or > because they cannot offer anything better. >=20 > Your complaint about signature strength is utterly bogus. > Cleartext HTTP doesn't have a little lock in the address bar with a > green color. Stop pretending that weak crypto is better than no > crypto: > as I've pointed out to you, I can train my mother to not put in her > credit card number without seeing that green lock. I can't train her > to evaluate connection strength. >=20 [Joe] The tone of the above is also unnecessary. > Why should the existence of middleboxes permit an active attacker to > interfere when I visit my bank website from my home computer? > Why should the fact that some corporate networks want to use TLS > interception prevent websites from choosing not to permit that sort > of attack, while still serving the IE6/XP clients? Why should we let > the lowest common denominator drive the security of all our > connections, > even when better options are supported by both sides? > Sincerely, > Watson >=20 >>=20 >>=20 >> -Martin >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >=20 >=20 >=20 > --=20 > "Those who would give up Essential Liberty to purchase a little > Temporary Safety deserve neither Liberty nor Safety." > -- Benjamin Franklin > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From jsalowey@cisco.com Thu Jan 30 15:00:45 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 477681A04D9 for ; Thu, 30 Jan 2014 15:00:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.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 Wf_ASXlKOp_n for ; Thu, 30 Jan 2014 15:00:43 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id D0CF51A039C for ; Thu, 30 Jan 2014 15:00:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2697; q=dns/txt; s=iport; t=1391122839; x=1392332439; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=zWiPpXX45WslC3nFNOWKm9yQnH0ZraI19youVVoear8=; b=I5v64Zj7QvYbLI6CyrrWO4Pi/1XeORUfOtOvhum6sTvAO0wfYncYnssm SRNoPEw291Kkh2JhZxGrojF/zLMSOl7njnb8NV78plCXj+F6RQm2dtAKI RXdSYjJxr9BXGjDiWhwwz8yEAyeDhUc5nuik0nSNcP9lUM+k671ZcxUE5 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAArZ6lKtJXG8/2dsb2JhbABZgww4V6pbkk6BChZ0giYBAQQ6TwIBCDYQMiUCBIgYzHMXjk86gySBFASUQINokh+DLYIq X-IronPort-AV: E=Sophos;i="4.95,752,1384300800"; d="scan'208";a="300949345" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 30 Jan 2014 23:00:39 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0UN0duU032091 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 30 Jan 2014 23:00:39 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.227]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Thu, 30 Jan 2014 17:00:38 -0600 From: "Joseph Salowey (jsalowey)" To: "" Thread-Topic: [TLS] TLS Charter Revision Thread-Index: AQHO75QH12xj16hlv0SmAgrMfgWOIZpCOZwAgAGJjoCADV40AIAAAvsAgAAHaYCAALekAIAAC32AgAZIHoCARmyZgA== Date: Thu, 30 Jan 2014 23:00:38 +0000 Message-ID: References: <2F2286E3-7717-4E8F-B1EA-B2E4155F7C17@cisco.com> <53edda7bf2804289817f54a8c2ecce33@BY2PR03MB074.namprd03.prod.outlook.com> <2A0EFB9C05D0164E98F19BB0AF3708C711E42D63D8@USMBX1.msg.corp.akamai.com> <3A9A4169-6B5E-453E-930A-F00291B541F4@apple.com> <2A0EFB9C05D0164E98F19BB0AF3708C711E4675283@USMBX1.msg.corp.akamai.com> <568e68cbc61344fc8ad91dcd238a5f4b@BY2PR03MB074.namprd03.prod.outlook.com> In-Reply-To: <568e68cbc61344fc8ad91dcd238a5f4b@BY2PR03MB074.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.158] Content-Type: text/plain; charset="us-ascii" Content-ID: <10A22C22C8F7DF47B5EC01AAD8820C9C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] TLS Charter Revision X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 30 Jan 2014 23:00:45 -0000 I updated the charter based on the list discussion and included it below. = Sean is going to forward this version to the IESG. Main changes: 2nd bullet: added "The aim is also to maintain current security=20 features." 4th bullet: added "Are additional mechanisms needed to prevent version rollback needed?" 6th Bullet: added Stephen's privacy text. Cheers, Joe The TLS (Transport Layer Security) working group was established in 1996 to standardize a 'transport layer' security protocol. The basis for the work was SSL (Secure Socket Layer) v3.0. The TLS working group has completed a series of specifications that describe the TLS protocol v1.0, v1.1, and v1.2 and DTLS (Datagram TLS) v1.2 as well as extensions to the protocols and ciphersuites. The primary purpose of the working group is to develop (D)TLS v1.3. Some of the main design goals are as follows, in no particular order: o Develop a mode that encrypts as much of the handshake as is possible to reduce the amount of observable data to both passive and active attackers. o Develop modes to reduce handshake latency, which primarily support HTTP-based applications, aiming for one roundtrip for a full handshake and one or zero roundtrip for repeated handshakes. The aim is also to maintain current security=20 features. o Update record payload protection cryptographic mechanisms and algorithms to address known weaknesses in the CBC block cipher modes and to replace RC4. o Reevaluate handshake contents, e.g.,: Is time needed in client hello? Should signature in server key exchange cover entire handshake? Are bigger randoms required? Should there be distinct cipher list for each version? Are additional mechanisms needed to prevent version rollback needed? o The WG will consider the privacy implications of TLS1.3 and where possible (balancing with other requirements) will aim to make TLS1.3 more privacy-friendly, e.g. via more consistent application traffic padding, more considered use of long term identifying values, etc. A secondary purpose is to maintain previous version of the (D)TLS protocols as well as to specify the use of (D)TLS, recommendations for use of (D)TLS, extensions to (D)TLS, and cipher suites. However, changes or additions to older versions of (D)TLS whether via extensions or ciphersuites are discouraged and require significant justification to be taken on as work items. =20 With these objectives in mind, the TLS WG will also place a priority in minimizing gratuitous changes to TLS. Milestone/Dates: 201404 - CBC Fixes to IESG 201405 - RC4 replacement to IESG=20 201411 - (D)TLS 1.3 to IESG= From rstruik.ext@gmail.com Thu Jan 30 15:50:15 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 692651A04EE for ; Thu, 30 Jan 2014 15:50:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UrO3BCuj9lfK for ; Thu, 30 Jan 2014 15:50:05 -0800 (PST) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 93A211A04ED for ; Thu, 30 Jan 2014 15:49:32 -0800 (PST) Received: by mail-ie0-f182.google.com with SMTP id lx4so3939443iec.41 for ; Thu, 30 Jan 2014 15:49:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=TdCDO6OEYMmAXJ7by97kN/s0aKVVvnbDZ2G6QriX8co=; b=utBAVxjH2rZbHEEhd6kM6UxRTsluw4MeL6MsKX6ApfbKbAMkTJQb4/CazfUB1ZukVd DMEOLP2+M2X9HsedniPpt2Ll1eqpQYKs+yn1rW00a4drPSlIBmiKjYBMx9qie0AKOHnJ 2Pu1+vNLrMi50BnZ3PSjo6k6OusBYiEmmdHwzYO+cKwexKI50UuVCKEEJTFgqKHZoqp1 B8siJlae4eBnY7HmLzn57ugvMQhgAaLOKbcENUZrVj7VOv5uEWCrLa9HIWqlZhVtWxq8 n+oUfnVb/8Eu+aCECKXk/2B1N32EUNJjaSkVJfhY2bcDkiHoimALvS9bAy5mFjY+cdAu CDgA== X-Received: by 10.51.17.101 with SMTP id gd5mr16938137igd.25.1391125769125; Thu, 30 Jan 2014 15:49:29 -0800 (PST) Received: from [192.168.1.101] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [99.231.3.110]) by mx.google.com with ESMTPSA id x13sm58251240igp.2.2014.01.30.15.49.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 Jan 2014 15:49:28 -0800 (PST) Message-ID: <52EAE4FE.2060503@gmail.com> Date: Thu, 30 Jan 2014 18:49:18 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" , "" References: <2F2286E3-7717-4E8F-B1EA-B2E4155F7C17@cisco.com> <53edda7bf2804289817f54a8c2ecce33@BY2PR03MB074.namprd03.prod.outlook.com> <2A0EFB9C05D0164E98F19BB0AF3708C711E42D63D8@USMBX1.msg.corp.akamai.com> <3A9A4169-6B5E-453E-930A-F00291B541F4@apple.com> <2A0EFB9C05D0164E98F19BB0AF3708C711E4675283@USMBX1.msg.corp.akamai.com> <568e68cbc61344fc8ad91dcd238a5f4b@BY2PR03MB074.namprd03.prod.outlook.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040905070506090407000204" Subject: Re: [TLS] TLS Charter Revision X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 30 Jan 2014 23:50:16 -0000 This is a multi-part message in MIME format. --------------040905070506090407000204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi Joe: Thanks for forwarding this to the group. I would recommend adding one more objective to the list: improving the efficiency of the handshake protocol, even in scenarios where one does not try and cut down the number of protocol flows, e.g., by exploiting parallel vs. serial key computation and combined key computation and certificate verification techniques. Some of this was presented at the CFRG meeting in Paris, France, March 28, 2012, see Slide 6 of http://www.ietf.org/proceedings/83/slides/slides-83-cfrg-5.pdf and at SAC 2010:René Struik : Batch Computations Revisited: Combining Key Computations and Batch Verifications. 130-142 This would be especially useful in highly constrained settings, where any computational efficiency gains are highly desirable. Suggested additional Charter text: o Consider other mechanisms to reduce handshake time latency, based on reconsideration of packet processing rules that could facilitate more efficient cryptographic processing, while maintaining or improving current security features. On 1/30/2014 6:00 PM, Joseph Salowey (jsalowey) wrote: > I updated the charter based on the list discussion and included it below. Sean is going to forward this version to the IESG. > > Main changes: > > 2nd bullet: added "The aim is also to maintain current security > features." > > 4th bullet: added "Are > additional mechanisms needed to prevent version rollback > needed?" > > 6th Bullet: added Stephen's privacy text. > > Cheers, > > Joe > > The TLS (Transport Layer Security) working group was > established in 1996 to standardize a 'transport layer' > security protocol. The basis for the work was SSL > (Secure Socket Layer) v3.0. The TLS working group has > completed a series of specifications that describe the > TLS protocol v1.0, v1.1, and v1.2 and DTLS > (Datagram TLS) v1.2 as well as extensions to the > protocols and ciphersuites. > > The primary purpose of the working group is to develop > (D)TLS v1.3. Some of the main design goals are as follows, > in no particular order: > > o Develop a mode that encrypts as much of the handshake as > is possible to reduce the amount of observable data to > both passive and active attackers. > > o Develop modes to reduce handshake latency, which primarily > support HTTP-based applications, aiming for one roundtrip > for a full handshake and one or zero roundtrip for repeated > handshakes. The aim is also to maintain current security > features. > > o Update record payload protection cryptographic > mechanisms and algorithms to address known weaknesses > in the CBC block cipher modes and to replace RC4. > > o Reevaluate handshake contents, e.g.,: Is time needed in > client hello? Should signature in server key exchange > cover entire handshake? Are bigger randoms required? > Should there be distinct cipher list for each version? Are > additional mechanisms needed to prevent version rollback > needed? > > o The WG will consider the privacy implications of > TLS1.3 and where possible (balancing with other requirements) > will aim to make TLS1.3 more privacy-friendly, e.g. via more > consistent application traffic padding, more considered use > of long term identifying values, etc. > > A secondary purpose is to maintain previous version of > the (D)TLS protocols as well as to specify the use of > (D)TLS, recommendations for use of (D)TLS, extensions to > (D)TLS, and cipher suites. However, changes or additions > to older versions of (D)TLS whether via extensions or > ciphersuites are discouraged and require significant > justification to be taken on as work items. > > With these objectives in mind, the TLS WG will also place a priority > in minimizing gratuitous changes to TLS. > > Milestone/Dates: > > 201404 - CBC Fixes to IESG > 201405 - RC4 replacement to IESG > 201411 - (D)TLS 1.3 to IESG > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --------------040905070506090407000204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 
Hi Joe:

Thanks for forwarding this to the group.

I would recommend adding one more objective to the list: improving the efficiency of the handshake protocol, even in scenarios where one does not try and cut down the number of protocol flows, e.g., by exploiting parallel vs. serial key computation and combined key computation and certificate verification techniques.

Some of this was presented at the CFRG meeting in Paris, France, March 28, 2012, see Slide 6 of
http://www.ietf.org/proceedings/83/slides/slides-83-cfrg-5.pdf
and at SAC 2010:René Struik: Batch Computations Revisited: Combining Key Computations and Batch Verifications. 130-142

This would be especially useful in highly constrained settings, where any computational efficiency gains are highly desirable. 

Suggested additional Charter text:

o Consider other mechanisms to reduce handshake time latency, based on reconsideration of packet processing rules that could facilitate more efficient cryptographic processing, while maintaining or improving current security features.
On 1/30/2014 6:00 PM, Joseph Salowey (jsalowey) wrote:
I updated the charter based on the list discussion and included it below.  Sean is going to forward this version to the IESG.

Main changes:

2nd bullet: added "The aim is also to maintain current security 
features."

4th bullet: added "Are
additional mechanisms needed to prevent version rollback
needed?"

6th Bullet: added Stephen's privacy text.

Cheers,

Joe

The TLS (Transport Layer Security) working group was
established in 1996 to standardize a 'transport layer'
security protocol.  The basis for the work was SSL
(Secure Socket Layer) v3.0.  The TLS working group has
completed a series of specifications that describe the
TLS protocol v1.0, v1.1, and v1.2 and DTLS
(Datagram TLS) v1.2 as well as extensions to the
protocols and ciphersuites.

The primary purpose of the working group is to develop
(D)TLS v1.3.  Some of the main design goals are as follows,
in no particular order:

o Develop a mode that encrypts as much of the handshake as
is possible to reduce the amount of observable data to
both passive and active attackers.

o Develop modes to reduce handshake latency, which primarily
support HTTP-based applications, aiming for one roundtrip
for a full handshake and one or zero roundtrip for repeated
handshakes.   The aim is also to maintain current security 
features.

o Update record payload protection cryptographic
mechanisms and algorithms to address known weaknesses
in the CBC block cipher modes and to replace RC4.

o Reevaluate handshake contents, e.g.,: Is time needed in
client hello?  Should signature in server key exchange
cover entire handshake?  Are bigger randoms required?
Should there be distinct cipher list for each version?  Are
additional mechanisms needed to prevent version rollback
needed?

o The WG will consider the privacy implications of
TLS1.3 and where possible (balancing with other requirements)
will aim to make TLS1.3 more privacy-friendly, e.g. via more
consistent application traffic padding, more considered use
of long term identifying values, etc.

A secondary purpose is to maintain previous version of
the (D)TLS protocols as well as to specify the use of
(D)TLS, recommendations for use of (D)TLS, extensions to
(D)TLS, and cipher suites.  However, changes or additions
to older versions of (D)TLS whether via extensions or
ciphersuites are discouraged and require significant
justification to be taken on as work items.  

With these objectives in mind, the TLS WG will also place a priority
in minimizing gratuitous changes to TLS.

Milestone/Dates:

201404 - CBC Fixes to IESG
201405 - RC4 replacement to IESG 
201411 - (D)TLS 1.3 to IESG
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls



-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--------------040905070506090407000204-- From TurnerS@ieca.com Fri Jan 31 07:25:15 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 164BB1A058D for ; Fri, 31 Jan 2014 07:25:15 -0800 (PST) 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 3f8LZHoWhDdG for ; Fri, 31 Jan 2014 07:25:13 -0800 (PST) Received: from gateway07.websitewelcome.com (gateway07.websitewelcome.com [69.56.170.18]) by ietfa.amsl.com (Postfix) with ESMTP id A87641A057F for ; Fri, 31 Jan 2014 07:25:13 -0800 (PST) Received: by gateway07.websitewelcome.com (Postfix, from userid 5007) id 18E938A654337; Fri, 31 Jan 2014 09:25:10 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway07.websitewelcome.com (Postfix) with ESMTP id EB9D98A65428F for ; Fri, 31 Jan 2014 09:25:09 -0600 (CST) Received: from [209.23.210.2] (port=60069 helo=[192.168.100.229]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1W9Fxt-0006Ms-FW for tls@ietf.org; Fri, 31 Jan 2014 09:25:09 -0600 From: Sean Turner Content-Type: multipart/signed; boundary="Apple-Mail=_7CA45647-DA89-4554-B18D-E9891C0EF914"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: <8C1E329B-B6BF-4457-9A4F-5FE70E4A691E@ieca.com> Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Date: Fri, 31 Jan 2014 10:25:06 -0500 References: <2AA4F2B7B0341A4CA4DAB10D4EDA0D7C2328AB80@xmb-aln-x02.cisco.com> To: tls@ietf.org In-Reply-To: <2AA4F2B7B0341A4CA4DAB10D4EDA0D7C2328AB80@xmb-aln-x02.cisco.com> X-Mailer: Apple Mail (2.1827) 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: 209.23.210.2 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.100.229]) [209.23.210.2]:60069 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Subject: Re: [TLS] New Revision of draft-ietf-tls-applayerprotoneg posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 31 Jan 2014 15:25:15 -0000 --Apple-Mail=_7CA45647-DA89-4554-B18D-E9891C0EF914 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Just so no one will be surprised I plan to place this document on the = IESG telechat for next week. I do plan to add a comment based on Paul=92s = comment on the shepherd write-up. spt On Jan 24, 2014, at 14:30, Stephan Friedl (sfriedl) = wrote: > We have just posted a new revision of draft-ietf-tls-applayerprotoneg. >=20 > This revision addresses comments received during the IETF LC, notably = comments from Alyssa Rowan and Yoav Nir and others concerning enriching = the Security Considerations section to call out that the protocol = selected is transmitted in the clear and to encourage protocol designers = and implementers to take this into consideration for scenarios where = protocol leakage could lead to leaking personally identifiable = information. >=20 > Thanks, >=20 > Stephan > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_7CA45647-DA89-4554-B18D-E9891C0EF914 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEgDCCBHww ggJkoAMCAQICCQCdWMxKNutUeTANBgkqhkiG9w0BAQsFADAiMQswCQYDVQQGEwJVUzETMBEGA1UE ChMKSUVDQSwgSW5jLjAeFw0xMzA0MDMxNDUxMThaFw0xNDA0MDMxNDUxMThaMDgxCzAJBgNVBAYT AlVTMRMwEQYDVQQKEwpJRUNBLCBJbmMuMRQwEgYDVQQDEwtTZWFuIFR1cm5lcjCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAOpCGCRptT1m+bIpLTmbahZLZ0Qe4X99f8SgTQ7QISvUfpmn tfOD1oA1AttXlOULEERYubzvDnUTXvstFomQx0XTA67IaV+mw9ODRtG1hPN/erdKX6sU6rH4tsEb ba3Drr/I0HT3YVvD3SjWtGXjF12XLvTP6+LfMIIDTCAPiEd9KPG23D7skVu/4BvvmdLFI96OARhg wQ86M+lTIn83KRJlbbfAeIevbRx/rUB7D+uvMdWxOzR0KZJhd6dEeTXVwBXZG4rnQ4uFM+mRSiD4 rxDCyOuIuOzR07tnOyCRio6sRipOZvwQUWttdsgMEs6IxLdWsaTXcs1HjCsxrdedovMCAwEAAaOB njCBmzAOBgNVHQ8BAf8EBAMCBeAwHwYDVR0jBBgwFoAUAHRsSeXJUmFxTVY4q2HJ8uHl+w0wGwYD VR0RBBQwEoEQVHVybmVyU0BpZWNhLmNvbTAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vd3d3Lmll Y2EuY29tL2NybHMvaWVjYS5jcmwwFwYDVR0gBBAwDjAMBgorBgEEAYHXAAAAMA0GCSqGSIb3DQEB CwUAA4ICAQAimDYm77ppTi4vK6qJSUhyvCDMGb8mngiEXEYKxsfdHPWoDO7+06j7dAZ8sDD9/FtE kiUMyoNGSUmKHR+tGperVnNiM/Zk6WwCJv8dYZwhGXNQeEGzeys/UkFv7CFX7uDSn8GQeB8sOAZ1 N1hxV/TvT8qXvcRxP5+aWTAGAq3TKtCQxZjuU74L3st2hZiOhJlhjhqz0K5FIwWzXUK9uwhZe1th GUpDbRustVgmKN2Xa0pzwqI1VUO0jnWt24A4u59xo6DJQXzQVMhCx0xhpemuT9BrsBDTX8eJdI1i Wv9wp3ivSrfHjKXp8y8OGD+usiG40HCjj0W9C+dH0VfbgrB6QOI4vA9+kTg4mANth1cxyxwPYOSJ v0zi1qR0eDIGI//2v2/s6TmGuNqbnRa26Ldv5gGqS7xj32Fiaby6UOXs4+aAIWGZEOH+BXjozcvE eGBwjU/VRQYu6itR28PaNhNVji4D5ITaGxWWiycqK1EUaFraWHtk7W100ROX69xTeFVZP86D2ymi /aohl5Vb1vlYHdqlbgqjDRl9dPbTxVCXEHf+jkexcuwlLTvr7F+5DIN6c/EbCpRqQx3edy193L48 OGyRDh1/Wmzpew0VWWAWOSXGl/P9VzXf3Z6GPt7flN/V9iEJAa3Mo+w+eIdzJkHBWR+yJcqQcCRM MSyishMwLDGCAjgwggI0AgEBMC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklFQ0EsIEluYy4C CQCdWMxKNutUeTAJBgUrDgMCGgUAoIHfMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTE0MDEzMTE1MjUwN1owIwYJKoZIhvcNAQkEMRYEFBBq0K+K4CkS8efRuKtpuL6L c/hqMD4GCSsGAQQBgjcQBDExMC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklFQ0EsIEluYy4C CQCdWMxKNutUeTBABgsqhkiG9w0BCRACCzExoC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklF Q0EsIEluYy4CCQCdWMxKNutUeTANBgkqhkiG9w0BAQEFAASCAQCyjPTp51eJv2vUof7mw6rZtHZb VCLyy04VmNiajLnnkPGEs8TbuOoCMjxBJQQKyABW8QIdTvUgDr1bdYZI4ZhBFWjoqguE4Uya7RRK K+WZvLceyPy8Bomd+XgYzp6Kaeeo+jx7n+tTKpANT4H9SUnCVonhG2JU9u7om+/Rq2Pt4l4revI2 v1jkMdMgfs8XNlMv69RtcgDa3nF3qbd/EgILRJ1/MHVVCe5fz5iBtdYeYqHM8md9LIy6YSHwkIXI GsYgdxh0AtzTWy2ffaZhHyLlkT+ofK6kQ/74FaP6Uk2GH6xuSRyh6gLsBAgk+dotUIkumNfPwvnD 0m/83xVUP0eTAAAAAAAA --Apple-Mail=_7CA45647-DA89-4554-B18D-E9891C0EF914-- From TurnerS@ieca.com Fri Jan 31 07:36:06 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B36771A0376 for ; Fri, 31 Jan 2014 07:36:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 fe9kGUHg-mem for ; Fri, 31 Jan 2014 07:36:05 -0800 (PST) Received: from gateway07.websitewelcome.com (gateway07.websitewelcome.com [69.56.170.18]) by ietfa.amsl.com (Postfix) with ESMTP id E5A2A1A020C for ; Fri, 31 Jan 2014 07:36:04 -0800 (PST) Received: by gateway07.websitewelcome.com (Postfix, from userid 5007) id 784338A6B5B76; Fri, 31 Jan 2014 09:36:01 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway07.websitewelcome.com (Postfix) with ESMTP id 49F508A6B5AD6 for ; Fri, 31 Jan 2014 09:36:01 -0600 (CST) Received: from [209.23.210.2] (port=60073 helo=[192.168.100.229]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1W9G8O-0006eN-Fv; Fri, 31 Jan 2014 09:36:00 -0600 Content-Type: multipart/signed; boundary="Apple-Mail=_86BB4931-7C00-4E27-9252-FFBEF89E2E5F"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Sean Turner In-Reply-To: <52EAE4FE.2060503@gmail.com> Date: Fri, 31 Jan 2014 10:35:58 -0500 Message-Id: References: <2F2286E3-7717-4E8F-B1EA-B2E4155F7C17@cisco.com> <53edda7bf2804289817f54a8c2ecce33@BY2PR03MB074.namprd03.prod.outlook.com> <2A0EFB9C05D0164E98F19BB0AF3708C711E42D63D8@USMBX1.msg.corp.akamai.com> <3A9A4169-6B5E-453E-930A-F00291B541F4@apple.com> <2A0EFB9C05D0164E98F19BB0AF3708C711E4675283@USMBX1.msg.corp.akamai.com> <568e68cbc61344fc8ad91dcd238a5f4b@BY2PR03MB074.namprd03.prod.outlook.com> <52EAE4FE.2060503@gmail.com> To: Rene Struik X-Mailer: Apple Mail (2.1827) 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: 209.23.210.2 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.100.229]) [209.23.210.2]:60073 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 4 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Cc: "" Subject: Re: [TLS] TLS Charter Revision X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 31 Jan 2014 15:36:06 -0000 --Apple-Mail=_86BB4931-7C00-4E27-9252-FFBEF89E2E5F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Rene, A couple of people have mentioned the fact that list of objectives is = incomplete or they=92re worried their issue not being listed means it=92s = out of scope. Right now the charter includes the following to address = this (at least in my mind) "Some of the main design goals are as = follows, in no particular order:=94 That list is honestly there to make = sure the IESG will be comfortable agreeing to the rechartering. What I = hope will happen is that folks can bring their proposals, they get = evaluated, and the WG will use its better judgement about what makes = sense to get adopted. spt On Jan 30, 2014, at 18:49, Rene Struik wrote: > Hi Joe: >=20 > Thanks for forwarding this to the group. >=20 > I would recommend adding one more objective to the list: improving the = efficiency of the handshake protocol, even in scenarios where one does = not try and cut down the number of protocol flows, e.g., by exploiting = parallel vs. serial key computation and combined key computation and = certificate verification techniques. >=20 > Some of this was presented at the CFRG meeting in Paris, France, March = 28, 2012, see Slide 6 of >=20 > http://www.ietf.org/proceedings/83/slides/slides-83-cfrg-5.pdf >=20 > and at SAC 2010: > Ren=E9 Struik: Batch Computations Revisited: Combining Key = Computations and Batch Verifications. 130-142 >=20 >=20 > This would be especially useful in highly constrained settings, where = any computational efficiency gains are highly desirable.=20 >=20 > Suggested additional Charter text: >=20 > o Consider other mechanisms to reduce handshake time latency, based on = reconsideration of packet processing rules that could facilitate more = efficient cryptographic processing, while maintaining or improving = current security features. >=20 >=20 >=20 > On 1/30/2014 6:00 PM, Joseph Salowey (jsalowey) wrote: >> I updated the charter based on the list discussion and included it = below. Sean is going to forward this version to the IESG. >>=20 >> Main changes: >>=20 >> 2nd bullet: added "The aim is also to maintain current security=20 >> features." >>=20 >> 4th bullet: added "Are >> additional mechanisms needed to prevent version rollback >> needed?" >>=20 >> 6th Bullet: added Stephen's privacy text. >>=20 >> Cheers, >>=20 >> Joe >>=20 >> The TLS (Transport Layer Security) working group was >> established in 1996 to standardize a 'transport layer' >> security protocol. The basis for the work was SSL >> (Secure Socket Layer) v3.0. The TLS working group has >> completed a series of specifications that describe the >> TLS protocol v1.0, v1.1, and v1.2 and DTLS >> (Datagram TLS) v1.2 as well as extensions to the >> protocols and ciphersuites. >>=20 >> The primary purpose of the working group is to develop >> (D)TLS v1.3. Some of the main design goals are as follows, >> in no particular order: >>=20 >> o Develop a mode that encrypts as much of the handshake as >> is possible to reduce the amount of observable data to >> both passive and active attackers. >>=20 >> o Develop modes to reduce handshake latency, which primarily >> support HTTP-based applications, aiming for one roundtrip >> for a full handshake and one or zero roundtrip for repeated >> handshakes. The aim is also to maintain current security=20 >> features. >>=20 >> o Update record payload protection cryptographic >> mechanisms and algorithms to address known weaknesses >> in the CBC block cipher modes and to replace RC4. >>=20 >> o Reevaluate handshake contents, e.g.,: Is time needed in >> client hello? Should signature in server key exchange >> cover entire handshake? Are bigger randoms required? >> Should there be distinct cipher list for each version? Are >> additional mechanisms needed to prevent version rollback >> needed? >>=20 >> o The WG will consider the privacy implications of >> TLS1.3 and where possible (balancing with other requirements) >> will aim to make TLS1.3 more privacy-friendly, e.g. via more >> consistent application traffic padding, more considered use >> of long term identifying values, etc. >>=20 >> A secondary purpose is to maintain previous version of >> the (D)TLS protocols as well as to specify the use of >> (D)TLS, recommendations for use of (D)TLS, extensions to >> (D)TLS, and cipher suites. However, changes or additions >> to older versions of (D)TLS whether via extensions or >> ciphersuites are discouraged and require significant >> justification to be taken on as work items. =20 >>=20 >> With these objectives in mind, the TLS WG will also place a priority >> in minimizing gratuitous changes to TLS. >>=20 >> Milestone/Dates: >>=20 >> 201404 - CBC Fixes to IESG >> 201405 - RC4 replacement to IESG=20 >> 201411 - (D)TLS 1.3 to IESG >> _______________________________________________ >> TLS mailing list >>=20 >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >=20 >=20 > --=20 > email:=20 > rstruik.ext@gmail.com > | Skype: rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_86BB4931-7C00-4E27-9252-FFBEF89E2E5F Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEgDCCBHww ggJkoAMCAQICCQCdWMxKNutUeTANBgkqhkiG9w0BAQsFADAiMQswCQYDVQQGEwJVUzETMBEGA1UE ChMKSUVDQSwgSW5jLjAeFw0xMzA0MDMxNDUxMThaFw0xNDA0MDMxNDUxMThaMDgxCzAJBgNVBAYT AlVTMRMwEQYDVQQKEwpJRUNBLCBJbmMuMRQwEgYDVQQDEwtTZWFuIFR1cm5lcjCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAOpCGCRptT1m+bIpLTmbahZLZ0Qe4X99f8SgTQ7QISvUfpmn tfOD1oA1AttXlOULEERYubzvDnUTXvstFomQx0XTA67IaV+mw9ODRtG1hPN/erdKX6sU6rH4tsEb ba3Drr/I0HT3YVvD3SjWtGXjF12XLvTP6+LfMIIDTCAPiEd9KPG23D7skVu/4BvvmdLFI96OARhg wQ86M+lTIn83KRJlbbfAeIevbRx/rUB7D+uvMdWxOzR0KZJhd6dEeTXVwBXZG4rnQ4uFM+mRSiD4 rxDCyOuIuOzR07tnOyCRio6sRipOZvwQUWttdsgMEs6IxLdWsaTXcs1HjCsxrdedovMCAwEAAaOB njCBmzAOBgNVHQ8BAf8EBAMCBeAwHwYDVR0jBBgwFoAUAHRsSeXJUmFxTVY4q2HJ8uHl+w0wGwYD VR0RBBQwEoEQVHVybmVyU0BpZWNhLmNvbTAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vd3d3Lmll Y2EuY29tL2NybHMvaWVjYS5jcmwwFwYDVR0gBBAwDjAMBgorBgEEAYHXAAAAMA0GCSqGSIb3DQEB CwUAA4ICAQAimDYm77ppTi4vK6qJSUhyvCDMGb8mngiEXEYKxsfdHPWoDO7+06j7dAZ8sDD9/FtE kiUMyoNGSUmKHR+tGperVnNiM/Zk6WwCJv8dYZwhGXNQeEGzeys/UkFv7CFX7uDSn8GQeB8sOAZ1 N1hxV/TvT8qXvcRxP5+aWTAGAq3TKtCQxZjuU74L3st2hZiOhJlhjhqz0K5FIwWzXUK9uwhZe1th GUpDbRustVgmKN2Xa0pzwqI1VUO0jnWt24A4u59xo6DJQXzQVMhCx0xhpemuT9BrsBDTX8eJdI1i Wv9wp3ivSrfHjKXp8y8OGD+usiG40HCjj0W9C+dH0VfbgrB6QOI4vA9+kTg4mANth1cxyxwPYOSJ v0zi1qR0eDIGI//2v2/s6TmGuNqbnRa26Ldv5gGqS7xj32Fiaby6UOXs4+aAIWGZEOH+BXjozcvE eGBwjU/VRQYu6itR28PaNhNVji4D5ITaGxWWiycqK1EUaFraWHtk7W100ROX69xTeFVZP86D2ymi /aohl5Vb1vlYHdqlbgqjDRl9dPbTxVCXEHf+jkexcuwlLTvr7F+5DIN6c/EbCpRqQx3edy193L48 OGyRDh1/Wmzpew0VWWAWOSXGl/P9VzXf3Z6GPt7flN/V9iEJAa3Mo+w+eIdzJkHBWR+yJcqQcCRM MSyishMwLDGCAjgwggI0AgEBMC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklFQ0EsIEluYy4C CQCdWMxKNutUeTAJBgUrDgMCGgUAoIHfMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTE0MDEzMTE1MzU1OVowIwYJKoZIhvcNAQkEMRYEFKBiWKAZjb0uYIdJsuXap0L2 npvkMD4GCSsGAQQBgjcQBDExMC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklFQ0EsIEluYy4C CQCdWMxKNutUeTBABgsqhkiG9w0BCRACCzExoC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklF Q0EsIEluYy4CCQCdWMxKNutUeTANBgkqhkiG9w0BAQEFAASCAQAr+UbjH3keML8fDaZe72Pn8vby 8zXO8MsBmM3Cwv2SwcESNa3q0Rq4fxbK5B+SukAqkZQ4StDoBiHoaG2a61H7nisppjBduLS574gM NiND1BtOSLkSwFRb2/HlieRDQK2iMFKhGlwbvAcR1JXnEWaqd8AcQIE0aV0Teufo7U2KHPmLeHzz PHo9+Sfif7+WyV+v5b7Ie6NlnhkxSn6Inf/gtLTAceNxUp5HxB+RnctE5hf/Qx0OsdDQnnIqWCQ+ IcC0AJo1Z/PLyaYrQ8Pd6MGHwaI57/ZrG/yFaiig/wSIWZkDG8W6Dfbf2TMGfwZ15RqJ7rdPFZ5r pgJmU6vvDBImAAAAAAAA --Apple-Mail=_86BB4931-7C00-4E27-9252-FFBEF89E2E5F-- From housley@vigilsec.com Fri Jan 31 08:46:04 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 729841A0367 for ; Fri, 31 Jan 2014 08:46:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSPHMCcAuupj for ; Fri, 31 Jan 2014 08:46:03 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id 14A561A035D for ; Fri, 31 Jan 2014 08:46:03 -0800 (PST) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id BD7839A42D7; Fri, 31 Jan 2014 11:45:49 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id Tw0h32Cri2mk; Fri, 31 Jan 2014 11:45:28 -0500 (EST) Received: from [192.168.100.238] (209-23-210-2-ip-static.hfc.comcastbusiness.net [209.23.210.2]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id CB59A9A42AD; Fri, 31 Jan 2014 11:45:28 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: Date: Fri, 31 Jan 2014 11:45:17 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Eric Rescorla X-Mailer: Apple Mail (2.1085) Cc: "tls@ietf.org" Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 31 Jan 2014 16:46:04 -0000 I did not previously voice an opinion, but I think the TLS WG should = adopt the document and push to WG Last Call very quickly. Russ On Jan 23, 2014, at 5:06 AM, Eric Rescorla wrote: > WG Members, >=20 > This message is a call for acceptance of > http://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-01 >=20 > As a TLS WG item. >=20 > Please provide any comments on this action by Feb 7. Because > there has been only modest discussion of this document, the > chairs ask people who have already spoken in favor or against > this document to re-register their opinion (feel free to just say > +1 or -1 and point back to the archives.) >=20 > -Ekr > [For the chairs]