From nobody Wed May 1 10:02:03 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 931AE120130; Wed, 1 May 2019 10:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jyemFS0rtnpb; Wed, 1 May 2019 10:01:51 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12A8612008A; Wed, 1 May 2019 10:01:51 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 09724B81BFF; Wed, 1 May 2019 10:01:39 -0700 (PDT) To: Frank.Theinen@web.de, ynir.ietf@gmail.com, simon@josefsson.org, mpg@elzevir.fr X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: kaduk@mit.edu, iesg@ietf.org, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20190501170139.09724B81BFF@rfc-editor.org> Date: Wed, 1 May 2019 10:01:39 -0700 (PDT) Archived-At: Subject: [TLS] [Errata Verified] RFC8422 (5703) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2019 17:01:53 -0000 The following errata report has been verified for RFC8422, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5703 -------------------------------------- Status: Verified Type: Technical Reported by: Frank Theinen Date Reported: 2019-04-23 Verified by: Benjamin Kaduk (IESG) Section: 5.10. Original Text ------------- All RSA signatures must be generated and verified according to Section 7.2 of [RFC8017]. Corrected Text -------------- All RSA signatures must be generated and verified according to Section 8.2 of [RFC8017]. Notes ----- Section 7.2 of RFC 8017 describes the RSAES-PKCS1-v1_5 encryption scheme. Section 8.2 of RFC 8017 describes the RSASSA-PKCS1-v1_5 signature scheme. The original text contradicts the natural expectation and is probably wrong. If it was intended, there should have been a thorough explanation (like in the well-known case of IKEv1 using the encryption scheme for signing). -------------------------------------- RFC8422 (draft-ietf-tls-rfc4492bis-17) -------------------------------------- Title : Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier Publication Date : August 2018 Author(s) : Y. Nir, S. Josefsson, M. Pegourie-Gonnard Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Wed May 1 10:14:30 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA351200A2; Wed, 1 May 2019 10:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9WHRH_mfM_t; Wed, 1 May 2019 10:14:21 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35A7912008F; Wed, 1 May 2019 10:14:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1556730860; x=1588266860; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ukpviiUmiu8hjbPd5KnFx+4cp3JHc+mMwyNps04L6l8=; b=ArXz3HtghYRZnzHyKCswyteAgtvlw8nfTY7EEUEExDh+XV9nlawWd5Zp bpRE4j9bkaM4Jf4kIrMTeXGli0rOnuxaDlf3KDsWsNkDKGuew7cVuJOGB GFtlj0Bw0ZNsBEA+GokXKh7iDteBdXryAGjwbU0LtwhZIblQvtYrwW4V7 OH8HEF1jLfWeipC24f2HhDXxFCpEJA2CLp9tCQWcuyRW6jJubH3ioRZRQ DtMr44A01szUIiHTNkujEMUWtoCV+jdhKXdGAAigk3s5RLGU6KLq+4/3G 6eqN4MPQu9Tn7ixUHNKZtvqzNQiC9CHXM4H3lQ+6lR7aomrqqu3EmnDHQ w==; X-IronPort-AV: E=Sophos;i="5.60,418,1549882800"; d="scan'208";a="59758603" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.3 - Outgoing - Outgoing Received: from smtp.uoa.auckland.ac.nz (HELO uxcn13-ogg-b.UoA.auckland.ac.nz) ([10.6.2.3]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 02 May 2019 05:14:17 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-b.UoA.auckland.ac.nz (10.6.2.3) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 2 May 2019 05:14:17 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Thu, 2 May 2019 05:14:16 +1200 From: Peter Gutmann To: RFC Errata System , "Frank.Theinen@web.de" , "ynir.ietf@gmail.com" , "simon@josefsson.org" , "mpg@elzevir.fr" CC: "tls@ietf.org" , "kaduk@mit.edu" , "iesg@ietf.org" Thread-Topic: [TLS] [Errata Verified] RFC8422 (5703) Thread-Index: AQHVAD+xvmTycsWpgEucdeij7zQ/yaZWgcek Date: Wed, 1 May 2019 17:14:16 +0000 Message-ID: <1556730851631.37840@cs.auckland.ac.nz> References: <20190501170139.09724B81BFF@rfc-editor.org> In-Reply-To: <20190501170139.09724B81BFF@rfc-editor.org> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] [Errata Verified] RFC8422 (5703) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2019 17:14:23 -0000 RFC Errata System writes:=0A= =0A= >Section 7.2 of RFC 8017 describes the RSAES-PKCS1-v1_5 encryption scheme.= =0A= >Section 8.2 of RFC 8017 describes the RSASSA-PKCS1-v1_5 signature scheme. = The=0A= >original text contradicts the natural expectation and is probably wrong.= =0A= =0A= The original text is correct, TLS 1.2 (and earlier) use PKCS #1 v1.5. Stat= ing=0A= that RSA-PSS should be used is wrong.=0A= =0A= Peter.= From nobody Wed May 1 10:18:01 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C121F12008F; Wed, 1 May 2019 10:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jyRnosy2n0cz; Wed, 1 May 2019 10:17:58 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F1A21200A2; Wed, 1 May 2019 10:17:57 -0700 (PDT) Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x41HHl7n027888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 1 May 2019 13:17:49 -0400 Date: Wed, 1 May 2019 12:17:47 -0500 From: Benjamin Kaduk To: Peter Gutmann Cc: RFC Errata System , "Frank.Theinen@web.de" , "ynir.ietf@gmail.com" , "simon@josefsson.org" , "mpg@elzevir.fr" , "tls@ietf.org" , "iesg@ietf.org" Message-ID: <20190501171746.GL59871@kduck.mit.edu> References: <20190501170139.09724B81BFF@rfc-editor.org> <1556730851631.37840@cs.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1556730851631.37840@cs.auckland.ac.nz> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [TLS] [Errata Verified] RFC8422 (5703) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2019 17:18:00 -0000 On Wed, May 01, 2019 at 05:14:16PM +0000, Peter Gutmann wrote: > RFC Errata System writes: > > >Section 7.2 of RFC 8017 describes the RSAES-PKCS1-v1_5 encryption scheme. > >Section 8.2 of RFC 8017 describes the RSASSA-PKCS1-v1_5 signature scheme. The > >original text contradicts the natural expectation and is probably wrong. > > The original text is correct, TLS 1.2 (and earlier) use PKCS #1 v1.5. Stating > that RSA-PSS should be used is wrong. Section 7.2 is an encryption scheme, not a signature scheme; this is just a typo. (And RSASSA-PKCS1-v1_5 is, well, PKCS #1 v1.5, not RSASSA-PSS.) -Ben From nobody Wed May 1 10:19:56 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1FE51200A2; Wed, 1 May 2019 10:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnkUn7k_PygB; Wed, 1 May 2019 10:19:45 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F03B812006E; Wed, 1 May 2019 10:19:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1556731185; x=1588267185; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ZxUzZ0I6/Z4QLFDO3JAV7H5XtowYcuF3A1TvyLd97sc=; b=PcjvYB16WPws+FzqtlTHiCoKxkmjgA+nFDx8E32dD0kQPDFLPukULuZA Qc7P0CgB9R6ThtkYxUOdTAbs0+4eagi6bQar8hjB5IpYpCrCdCAeGXa8j ubFIpgFXlk4IXgvWn9gxy3UE0b/sHEKLjvtneoPJwGTxCaHsmwYJ044Jo +Q4SPAmzVResmxDwrGwizZVA/worUVZPXgVbyHsjg+pS0ACTE6/DctLWE qhRebxb+GHcrRHVC2b7qhyOqsTJVrNBR/75ApXEBASQAfjvpEAJkdIaA2 y5fsQlMXUHfLEtQUhM+9TAQP9UVpd6LWkF5d+rv4VlN+eUo8O0KR97KC+ A==; X-IronPort-AV: E=Sophos;i="5.60,418,1549882800"; d="scan'208";a="59758856" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.3 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-b.UoA.auckland.ac.nz) ([10.6.3.3]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 02 May 2019 05:19:43 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-b.UoA.auckland.ac.nz (10.6.3.3) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 2 May 2019 05:19:42 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Thu, 2 May 2019 05:19:42 +1200 From: Peter Gutmann To: Benjamin Kaduk CC: RFC Errata System , "Frank.Theinen@web.de" , "ynir.ietf@gmail.com" , "simon@josefsson.org" , "mpg@elzevir.fr" , "tls@ietf.org" , "iesg@ietf.org" Thread-Topic: [TLS] [Errata Verified] RFC8422 (5703) Thread-Index: AQHVAD+xvmTycsWpgEucdeij7zQ/yaZWgcek//84JoCAAMmNvA== Date: Wed, 1 May 2019 17:19:41 +0000 Message-ID: <1556731177027.96650@cs.auckland.ac.nz> References: <20190501170139.09724B81BFF@rfc-editor.org> <1556730851631.37840@cs.auckland.ac.nz>, <20190501171746.GL59871@kduck.mit.edu> In-Reply-To: <20190501171746.GL59871@kduck.mit.edu> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] [Errata Verified] RFC8422 (5703) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2019 17:19:47 -0000 Benjamin Kaduk writes:=0A= =0A= >(And RSASSA-PKCS1-v1_5 is, well, PKCS #1 v1.5, not RSASSA-PSS.)=0A= =0A= Ah, sorry, I saw all the SS's and read it as PSS :-).=0A= =0A= Peter.=0A= From nobody Thu May 2 08:12:48 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94C491203E2 for ; Thu, 2 May 2019 08:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mgAjFzQ_sHWR for ; Thu, 2 May 2019 08:12:43 -0700 (PDT) Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ED5E1203C2 for ; Thu, 2 May 2019 08:12:30 -0700 (PDT) Received: by mail-oi1-x22b.google.com with SMTP id l203so1982612oia.3 for ; Thu, 02 May 2019 08:12:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ThkRZwZCtrlqD/BvAIc7SUxgFLDnOygLI0t9IBXf0W8=; b=toyMCLhJjm6EhSXMcr2V6EdbckKGSS6SsbeynkV9R+oeK7ETWh17JfDDIgfMLO8EPd /1XhTyrZwvX1Fudddimn1WX/TN9WCNdo4NEv3rX0iCHRXYFPce5WHOg2UbDD1nX6U3Zq PCSRBs4C/Xjzm2WdvOmLYZlLmV6gojRwKfJ5l+Ml20aoKoVRxJu10qnn5blj/6k5M4wi Jdgh7XAufxZVSo68ZS9QTfD5mbNtDSltrVO1OKo3IqF1EkOT0LaaAUUkoQ16avehYs5/ vwJNsb2DTvauMJ9le3IWw0b2D8ZJoJqlQMnlTYjisOv7B9akpvM9ROArNGeLMJZDiNtL Wzdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ThkRZwZCtrlqD/BvAIc7SUxgFLDnOygLI0t9IBXf0W8=; b=h3TavZbHjA/O6V3D2dEhrOrBSq5ocl9ae9owof3gmLrIb+pspjUU7adykI2bi4+38v OkBW8g/NwtNC/Zp8klI2s331FBrcHSg7w5T5ye1W4LqY1y2w/4fF2k89AYgp82Jjcemo kRbT9gvpjW1TFv5E+1in84T0dMK17fcAhaoMUedbQVNOBo/ol7E9Z+TZl72BOAkAlAdW uJBAJ8wCFTnccPcJzHXxC0Lh/5k6n1fgxxcbkL+rTUgRyIC2D9F465kB5juysYgW2WtU 7aRLYLfdV0jB4naHNgmpruRHNQ3j8cvN2lWfOh9kOFVcVHBreEsouD+0ItaNR+JszmCd O7/g== X-Gm-Message-State: APjAAAXsb8hQ4L+XU7+yAtH+0TZsTY/tRiv3x/Sy4Rv8ElIukMYNBdmf 5A48LXaz824tvzGtiEcUNd2Pn9O4aIlNI0x0XnU= X-Google-Smtp-Source: APXvYqz1Fn37VT5sxRHUX4KnN2boF3H3sPpSoiMOTxYXJbRRI/LCUTynEiDsQ8nDzEqFUJn77p2OhErKMvCS9rw/5gc= X-Received: by 2002:aca:b156:: with SMTP id a83mr2549505oif.119.1556809949942; Thu, 02 May 2019 08:12:29 -0700 (PDT) MIME-Version: 1.0 References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <4d34a22a-3d77-4fe8-9c8e-e2128a7a80f8@www.fastmail.com> In-Reply-To: <4d34a22a-3d77-4fe8-9c8e-e2128a7a80f8@www.fastmail.com> From: Kathleen Moriarty Date: Thu, 2 May 2019 11:11:53 -0400 Message-ID: To: Martin Thomson Cc: "" Content-Type: multipart/alternative; boundary="0000000000000c992d0587e91005" Archived-At: Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 02 May 2019 15:12:46 -0000 --0000000000000c992d0587e91005 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you for your feedback in this review. Responses inline as to how I propose it is addressed: On Sat, Apr 13, 2019 at 12:16 AM Martin Thomson wrote: > Section 1.1 doesn't say *how* those listed documents are updated. Might > pay to include a few works on how. > Thank you, that was helpful feedback. I changed the introduction text as follows: OLD: This document updates these RFCs that normatively reference TLSv1.0 or TLSv1.1 or DTLS1.0 and have not been obsoleted. NEW: This document updates the following RFCs that normatively reference TLSv1.0 or TLSv1.1 or DTLS1.0. The update is to obsolete usage of these older versions. Fallback to these versions are prohibited through this update. Section 2 can be cut down a lot. The quote from another document is longer > than the rest of the text. In many ways, saying that the IETF is moving > last is not a great thing to memorialize in RFC, as much as it is useful = in > an Internet-Draft or in argumentation in support of publication of the do= c. > A bunch has been cut out already, but I propose also cutting out the following text to address your specific point (well taken): 1st paragraph and last 2. REMOVE: Industry has actively followed guidance provided by NIST and the PCI Council to deprecate TLSv1.0 and TLSv1.1 by June 30, 2018. TLSv1.2 should remain a minimum baseline for TLS support at this time. The Canadian government treasury board have also mandated that these old versions of TLS not be used. Various companies and web sites have announced plans to deprecate these old versions of TLS. The title of Section 3 could be a bit clearer. > Proposed: SHA-1 Usage Problematic in TLSv1.0 and TLSv1.1 If you have a more terse suggestion, please post. I agree this should be more clear. > > It might pay to explain what RFC 7525 is in Section 6. Why does that > document warrant special attention over the 70-odd other ones. > Good point, how about the following text: PROPOSED: RFC7525 is BCP195, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", is the mpost recent best practice document for implementing TLS and was based off of TLSv1.2. At the time of publication, TLSv1.0 and TLSv1.1 had not yet been deprecated. As such, this document is called out specifically to update text implementing the deprecation recommendations of this document. > Otherwise, publish this. > Thank you! I'll continue through the rest of the messages, but may have a delay when tending to other responsibilities. I am putting the proposals into a new version to upload to the git repository. Best regards, Kathleen > > > On Sat, Apr 13, 2019, at 09:28, Christopher Wood wrote: > > This is the working group last call for the "Deprecating TLSv1.0 and > > TLSv1.1=E2=80=9D draft available at: > > > > > https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/ > > > > Please review the document and send your comments to the list by April > 26, 2019. > > > > Thanks, > > Chris, Joe, and Sean > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --=20 Best regards, Kathleen --0000000000000c992d0587e91005 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you for your feedback in = this review.=C2=A0 Responses inline as to how I propose it is addressed:
On = Sat, Apr 13, 2019 at 12:16 AM Martin Thomson <mt@lowentropy.net> wrote:
Section 1.1 doesn't say *how* those listed = documents are updated.=C2=A0 Might pay to include a few works on how.

Thank you, that was helpful feedback.=C2=A0 = I changed the introduction text as follows:
OLD:
This document upd= ates these RFCs that normatively reference TLSv1.0 or TLSv1.1 or DTLS1.0 an= d have not been obsoleted.
NEW:
=C2=A0This document updates t= he following RFCs that normatively reference TLSv1.0 or TLSv1.1 or DTLS1.0.= The update is to obsolete usage of these older versions. Fallback to these= versions are prohibited through this update.

Section 2 can be cut down a lot.=C2=A0 The quote from another document is l= onger than the rest of the text.=C2=A0 In many ways, saying that the IETF i= s moving last is not a great thing to memorialize in RFC, as much as it is = useful in an Internet-Draft or in argumentation in support of publication o= f the doc.

A bunch has been cut out alr= eady, but I propose also cutting out the following text to address your spe= cific point (well taken):
1st paragraph and last 2.
REMOVE:
=C2=A0 =C2=A0 =C2=A0 Industry has actively fo= llowed guidance provided by NIST and the PCI
=C2=A0 =C2=A0 = =C2=A0 Council to deprecate TLSv1.0 and TLSv1.1 by June 30, 2018. TLSv1.2
=C2=A0 =C2=A0 =C2=A0 should remain a minimum baseline for TLS supp= ort at this time.

=C2=A0 =C2=A0 =C2=A0 The Ca= nadian government treasury board have also mandated that these
=C2=A0 =C2=A0 =C2=A0 old versions of TLS not be used.=C2=A0
=C2=A0 =C2=A0 =C2=A0 Various companies and web sites have annou= nced plans to deprecate
=C2=A0 =C2=A0 =C2=A0 these old versions o= f TLS.


The title of Section 3 could be a bit clearer.
Propose= d:=C2=A0
SHA-1 Usage Problematic in TLSv1.0 and TLSv1.1

If you have a more terse suggestion, please post.=C2=A0 I a= gree this should be more clear.
=C2=A0

It might pay to explain what RFC 7525 is in Section 6.=C2=A0 Why does that = document warrant special attention over the 70-odd other ones.

Good point, how about the following text:

PROPOSED:
RFC7525 is BCP195, "Recommendation= s for Secure Use of Transport Layer Security (TLS) and Datagram Transport L= ayer Security (DTLS)", is the mpost recent best practice document for = implementing TLS and was based off of TLSv1.2. At the time of publication, = TLSv1.0 and TLSv1.1 had not yet been deprecated. As such, this document is = called out specifically to update text implementing the deprecation recomme= ndations of this document.=C2=A0


Otherwise, publish this.

Thank you!

I'll continue through the rest of the messages, b= ut may have a delay when tending to other responsibilities.=C2=A0 =C2=A0
I am putting the proposals into a new version to upload to the git = repository.

Best regards,
Kathleen
=




On Sat, Apr 13, 2019, at 09:28, Christopher Wood wrote:
> This is the working group last call for the "Deprecating TLSv1.0 = and
> TLSv1.1=E2=80=9D draft available at:
>
>=C2=A0 =C2=A0 =C2=A0https:= //datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/
>
> Please review the document and send your comments to the list by April= 26, 2019.
>
> Thanks,
> Chris, Joe, and Sean
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

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


--

Best regards,
Kathleen
--0000000000000c992d0587e91005-- From nobody Thu May 2 09:38:21 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62E3E12046D for ; Thu, 2 May 2019 09:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fI-Jo9gmtwgc for ; Thu, 2 May 2019 09:38:17 -0700 (PDT) Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7566712047B for ; Thu, 2 May 2019 09:38:12 -0700 (PDT) Received: by mail-oi1-x22b.google.com with SMTP id 143so2220650oii.4 for ; Thu, 02 May 2019 09:38:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jifbOMtCkipxGzfTfc87YsF2xHu3aku+CqV8vTBKd5k=; b=MXMkkdozVQO+35hVEIxaJths7XDBga5mb+iKHLeUiRv73mlpcmycQZsZPjv8r38Tve MDS/Gkvj2U4cMCDH980CB2pzHcjXeuV3H07Ry+FtxE4fMF23Tfebr6FHeZwgcPbbWAwR rzqAnKLs/8qZ5KgSB9E3UhGr8hg4UGA8C09KxDLkWG7HvBZ1Wt65PfKQTw3R6yzmgc5T lhTJSPZNLtkt3AGAsTzhJK1L+e4q9F48E2v2TDTPSy19xKoQR5eAjKRv/NyWM8mq+mwd O7k/5dhVpDrJQtrLpgNywwIoc0DKCAEBCMROhaHUgIhqXUZnx4BQmnu2UEQdYNC7toCT 6Kbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jifbOMtCkipxGzfTfc87YsF2xHu3aku+CqV8vTBKd5k=; b=LQr6MtllqyPXrxjIysvhId1+ZVGVEPAvttJe4SI3RoSkZruqBxcwGJke2AktQiZAqS HqBPwQ8oQXr1WH3+tEr9PZBu8iPzZAPvCVopW5qTrKOjJf9znkgMmmHvoW+sot/EWTxK NQK++hq9ahZjoqcD4T6dUJXWuBpEHesTU+F+21DSOovXMb1SkEgUh/cNinnhU/IQxHxF EfIpyGu9vZwfBYwgj1Exrb/DH2XozxtsKfewlw8nd8VlUtQvoYu7jTsPY0zd+1qKe9GG OMeUF80XaUQo0zr5CxJTlL8ZTKXWEZsqkclZ9hG4dQUQagTNBudRthtsgdhVEiktLOPu 15kg== X-Gm-Message-State: APjAAAWxTJh5mudXrz0C/+dd7Z9ebo977XJt3p3wSv6LTsQ2NZ0Df+Nk dqAlgEUUdtS5v2a7VUsZQCMqUrunxl9ZL6x4IQKcmbNv X-Google-Smtp-Source: APXvYqyoC3hdULZO9pznye3xIcOBvK4yJNg8QtTFGybpnd7H/59GbKb+treWBudHxpKfVNNh9lpXWZQJGBN0BZFfXs0= X-Received: by 2002:aca:72c9:: with SMTP id p192mr3120564oic.164.1556815091849; Thu, 02 May 2019 09:38:11 -0700 (PDT) MIME-Version: 1.0 References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <5c4ff718-e063-4799-507c-04e38a47f83f@ncsc.nl> In-Reply-To: <5c4ff718-e063-4799-507c-04e38a47f83f@ncsc.nl> From: Kathleen Moriarty Date: Thu, 2 May 2019 12:37:34 -0400 Message-ID: To: "Maarten Aertsen (NCSC-NL)" Cc: "" Content-Type: multipart/alternative; boundary="00000000000087df0b0587ea42b3" Archived-At: Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 02 May 2019 16:38:20 -0000 --00000000000087df0b0587ea42b3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Maarten, On Wed, Apr 24, 2019 at 3:43 AM Maarten Aertsen (NCSC-NL) wrote: > Hi, > > On 13-4-2019 01:28, Christopher Wood wrote: > > This is the working group last call for the "Deprecating TLSv1.0 and > TLSv1.1=E2=80=9D draft available at: > > > > > https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/ > > > > Please review the document and send your comments to the list by April > 26, 2019. > > I'd like to see this published. > > @Kathleen, Stephen: in case there's any value in an additional ref for > section 2, we published updated TLS-guidelines yesterday, with clear > advice to phase out TLSv1, TLSv1.1. > > > https://www.ncsc.nl/english/current-topics/news/future-proof-tls-configur= ation-using-the-updated-tls-guidelines-from-ncsc.html Thank you for your review and this additional information, it's great to see more traction on this. Since we've greatly reduced section 2, cutting out this type of data, we'll leave it out. It's in the mail archive now though. If there are disagreements on this text having been cut, please speak up! Best regards, Kathleen > > > kind regards, Maarten > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --=20 Best regards, Kathleen --00000000000087df0b0587ea42b3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Maarten,

On Wed, Apr 24, 2019 at 3:43 AM M= aarten Aertsen (NCSC-NL) <maarten.aertsen=3D40ncsc.nl@dmarc.ietf.org> wrote:
Hi,

On 13-4-2019 01:28, Christopher Wood wrote:
> This is the working group last call for the "Deprecating TLSv1.0 = and TLSv1.1=E2=80=9D draft available at:
>
>=C2=A0 =C2=A0 =C2=A0 https= ://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/
>
> Please review the document and send your comments to the list by April= 26, 2019.

I'd like to see this published.

@Kathleen, Stephen: in case there's any value in an additional ref for =
section 2, we published updated TLS-guidelines yesterday, with clear
advice to phase out TLSv1, TLSv1.1.

https://www.ncsc.nl/english/current-topics/news/f= uture-proof-tls-configuration-using-the-updated-tls-guidelines-from-ncsc.ht= ml

Thank you for your review and this a= dditional information, it's great to see more traction on this.=C2=A0 S= ince we've greatly reduced section 2, cutting out this type of data, we= 'll leave it out.=C2=A0 It's in the mail archive now though.=C2=A0 = If there are disagreements on this text having been cut, please speak up!

Best regards,
Kathleen


kind regards, Maarten

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


--

Best regards,
Kathleen
--00000000000087df0b0587ea42b3-- From nobody Thu May 2 09:58:55 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E81F4120470 for ; Thu, 2 May 2019 09:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYC0ESh3QROn for ; Thu, 2 May 2019 09:58:51 -0700 (PDT) Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AB6B120486 for ; Thu, 2 May 2019 09:58:51 -0700 (PDT) Received: by mail-ot1-x336.google.com with SMTP id d24so2707081otl.11 for ; Thu, 02 May 2019 09:58:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OcHoVEb0OH1tbuaiDPoIdXmoeMmFPEQNI9uMXzbslwM=; b=LrruMnLmv2JMTxTq03QCe+DDBbKcdRdKg+40Uy3pXFDUpG7XJgtEFwLicCdJn2F7Nw fF0pcH6A+JJw3KSamSWXrFx+kRKWB1puYL0kcrF8N5QgL8lw39Y+fOLTQ/ZYH0/Y20VI xgSyAYTrG2hys6rg0TTlJrDrEaar3i1IzOF1gFbFT5mxaBCwctG25TtVWX7pEAC/jEae 1JHdgYLRtBNG2R65AJZ2P+jrcs2ghZKC4NjGOE4DA7HkFEvqxg4LiV0sUZ41hqmw+E9z k6UTBqp81fxFtp6GJsOKAKFEwbjJAX1OErUDEegfL3KgkIEF5PkoKHjaadRRBz9yzzb2 wKxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OcHoVEb0OH1tbuaiDPoIdXmoeMmFPEQNI9uMXzbslwM=; b=rt2AuxrLLHfu7r6JTM8fxiPAv7l5WC5c8Y3O21E4FhyOrsqbxv4gczXljJ/O0yD71n OyJq/DVnIvEaO7rAJiJ9UF+ErcLxOD/zH9mNygAnSP0rSHT9qN4xusTKAKJ1Fmk5jJSK sSRWnrUVOHECIuAOccjjE45V6TJ80yaRX3lOyb2nGgQ/B1wOGFAzWm9Dr025QiPWbWJO 5jHDOoA3g782uRv8isfJrZFrYDQJuG4NtwPK367o0vaJlVYy9/zk94e/Tl79JjlOPbL2 HiEjKJvO2w2cfoVySPsGvVe2rPa60X1EpTOZ2nmi74J8qNourtM1VFZgKhgrGdOAQNn7 HG7Q== X-Gm-Message-State: APjAAAVbfgXDNbBlih/TUg5kl3sld2WjFq62NcXmxSY2DtZCJgJo5W+M c8xK5ef0fHyMezipobGRNmtQLqM7FE7DUKU56Aao06+iKeg= X-Google-Smtp-Source: APXvYqyd5hzhq7/yx0AH9pltLdbPni2s9Fs+Xj9qp5Y3fHSY9kBEJh9ekO9CT7PlTtVYTBLBADEy2B1qxmx34pOpPL8= X-Received: by 2002:a9d:72c8:: with SMTP id d8mr3268376otk.149.1556816330939; Thu, 02 May 2019 09:58:50 -0700 (PDT) MIME-Version: 1.0 References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <7f76d36c-962b-78fe-87ab-e17c31430cb3@garygapinski.com> In-Reply-To: <7f76d36c-962b-78fe-87ab-e17c31430cb3@garygapinski.com> From: Kathleen Moriarty Date: Thu, 2 May 2019 12:58:13 -0400 Message-ID: To: Gary Gapinski Cc: "" Content-Type: multipart/alternative; boundary="00000000000062e30d0587ea8cbf" Archived-At: Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 02 May 2019 16:58:54 -0000 --00000000000062e30d0587ea8cbf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Gary, Thanks for your review and support. I'll respond inline and if Stephen disagrees, he will chime in :-) On Wed, Apr 24, 2019 at 9:51 AM Gary Gapinski wrote: > On 4/12/19 7:28 PM, Christopher Wood wrote: > > This is the working group last call for the "Deprecating TLSv1.0 and TLSv= 1.1=E2=80=9D draft available at: > > https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate= / > > Please review the document and send your comments to the list by April 26= , 2019. > > I think the document should be published. > > I agree with Martin Thomson's observation that the SP 800-52r2 quotes in > Section 2 are a bit prolix considering the relatively small content that > would remain if excised, and that NIST document has been in draft for a > prolonged time (reducing its authority). The quotes imply but do not dema= nd > disuse of TLS 1.0 and TLS 1.1, and could inadvertently be interpreted to > mean that use of TLS 1.2 rather than TLS 1.3 is sinful. > I had interpreted Martin's comment's a little differently and cut out other text. Hmm, for the NIST quotes, I see this as providing the supporting reasons and their recommendations not being the same as the recommendations in this draft. I think by the updated text Marten suggested on "updates", this point is addressed, but please let us know if you feel otherwise. > An additional (congenial) informative reference could be BSI TR-02102-2 > found at > > > https://www.bsi.bund.de/EN/Publications/TechnicalGuidelines/tr02102/index= _htm.html > > which in =C2=A73.2 states "TLS 1.0 and TLS 1.1 are *not recommended*". > Thank you for the reference, it's probably bets to have a couple of sources here. I included the following text with the pdf reference included in the working copy: The German Federal Office for Information Security, recommends against use of TLS versions less than 1.2 in the publication Cryptographic Mechanisms: Recommendations and Key Lengths Best regards, Kathleen > Regards, > > Gary > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --=20 Best regards, Kathleen --00000000000062e30d0587ea8cbf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Gary,

<= div>Thanks for your review and support.=C2=A0 I'll respond inline and i= f Stephen disagrees, he will chime in :-)

On Wed, Apr 24, 2019 at 9:51= AM Gary Gapinski <gary=3D40garygapinski.com@dmarc.ietf.org> wrote:
=20 =20 =20
On 4/12/19 7= :28 PM, Christopher Wood wrote:
This is the =
working group last call for the "Deprecating TLSv1.0 and TLSv1.1=E2=80=
=9D draft available at:

    https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-=
deprecate/

Please review the document and send your comments to the list by April 26, =
2019.

I think the document should be published.

I agree with Martin Thomson's observation that the SP 800-52r2 quotes in Section 2 are a bit prolix considering the relatively small content that would remain if excised, and that NIST document has been in draft for a prolonged time (reducing its authority). The quotes imply but do not demand disuse of TLS 1.0 and TLS 1.1, and could inadvertently be interpreted to mean that use of TLS 1.2 rather than TLS 1.3 is sinful.


I had interpreted Martin's comment's a little differently a= nd cut out other text.=C2=A0 Hmm, for the NIST quotes, I see this as provid= ing the supporting reasons and their recommendations not being the same as = the recommendations in this draft.=C2=A0 I think by the updated text Marten= suggested on "updates", this point is addressed, but please let = us know if you feel otherwise.

An additional (congenial) informative reference could be BSI TR-02102-2 found at

https://www.bsi.bund.de/EN/Pub= lications/TechnicalGuidelines/tr02102/index_htm.html

which in =C2=A73.2 states "TLS 1.0 and TLS 1.1 are not recom= mended".


Thank you for t= he reference, it's probably bets to have a couple of sources here.=C2= =A0 I included the following text with the pdf reference included in the wo= rking copy:

The German Federal Office for Informat= ion Security, recommends against use of TLS versions less than 1.2 in the p= ublication <xref
target=3D"TR-02102-2"
>Cryptographic Mechanisms: Recommendations and Key Lengths</xref>=

Best regards,
Kathleen
=C2=A0=

Regards,

Gary

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


--

Best regards,
Kathleen
--00000000000062e30d0587ea8cbf-- From nobody Thu May 2 10:03:21 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 818FD1204B4 for ; Thu, 2 May 2019 10:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYEbUOTHjKmq for ; Thu, 2 May 2019 10:03:16 -0700 (PDT) Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB5001204A8 for ; Thu, 2 May 2019 10:03:16 -0700 (PDT) Received: by mail-ot1-x329.google.com with SMTP id r20so2756657otg.4 for ; Thu, 02 May 2019 10:03:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=wklJdNKlg5bvpzksiSRKOudYihh+YoOYhBp+LdxlM5Q=; b=mAq9vnO65oq32HWVBluk77B0BSaM7VFa0tiCzzypzdidFOJFUUT4X6VHDLPkZfa07o h1NNcwfgjA18p4zUdMjngE30nw2h2HO4ArVRtB/uyhGWfvHeYlnVJZLWNuN3X6BPbY7P b5FtduaIHQDAB+Av/i+8oHhyFpBHmXr8j5G09NhjCcvCFc+GcLjaN6v+f9ba0qcFjJ1b ewKmPsyaRGqOfIUwo1cfQ9dHbTARRSpeFG0HGkLkDFRWGi9z/MK8kLImu5ymsh/u+DSL DaUZhq7bwXMYw/8VCy7PERBKLThwzRcIN5H149ijlIP0hxK7XkgIQZVCmogYN8Gn+972 pslQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=wklJdNKlg5bvpzksiSRKOudYihh+YoOYhBp+LdxlM5Q=; b=iuFKujkgNt+tGsYPO02nmucir9l1cxQ80basjUYdPWEtfdziu9Dxw/m8wswgR869Jn DkBgYmMfPNG2UdRUEJrQjjTpb59B/t4/1P2/Zi5WxLWd7ugN3smWvWrvr0TOIjATKBha ajlvmaaICrbURzs9B5Vi5qeXshTUbPdGRVNtBHTWQJrVc9egwPZ3cCF7EwiI+mr6bFdL qkvz+qMyjYe+friQ1IYa1l3RNHSR0FLLu5i3nV4JvpLblKdTPOZggugLlfE1UA+hq0x3 uims9VKIBBXxxko4clb6TNlLtzVyJSyM8kG5cojoDseo6hUny+TAwZ/ez6tVJMSPv4H4 Bh3w== X-Gm-Message-State: APjAAAV0ZaE6kHkYbuiKkylvjR9wC7F545FjFXJuikvnYeWSO/mUFpZf 4ILd/R15MAEewo0sEHp3ltxeOnWRoMZ10hGu1ljqo7Xv X-Google-Smtp-Source: APXvYqz4YRBO3uOn42LcOvw1803leDd11cTwDyVkrdwZnyfDT8EueMSjUvpTql2EWrp9+oSd65lGBjQXaRPzjJlmUzM= X-Received: by 2002:a05:6830:119:: with SMTP id i25mr1832692otp.158.1556816595926; Thu, 02 May 2019 10:03:15 -0700 (PDT) MIME-Version: 1.0 References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <2EF7433E-DB94-497F-80D7-2A060097261B@dukhovni.org> In-Reply-To: <2EF7433E-DB94-497F-80D7-2A060097261B@dukhovni.org> From: Kathleen Moriarty Date: Thu, 2 May 2019 13:02:38 -0400 Message-ID: To: IETF TLS WG Content-Type: multipart/alternative; boundary="0000000000002e44040587ea9c0f" Archived-At: Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 02 May 2019 17:03:20 -0000 --0000000000002e44040587ea9c0f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Victor, Thank you very much for your work and pushing the points on uses of TLS outside of web as this is an important point. On Thu, Apr 25, 2019 at 9:30 PM Viktor Dukhovni wrote: > > On Apr 12, 2019, at 7:28 PM, Christopher Wood > wrote: > > > > This is the working group last call for the "Deprecating TLSv1.0 and > TLSv1.1=E2=80=9D draft available at: > > > > > https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/ > > > > Please review the document and send your comments to the list by April > 26, 2019. > > My concern is whether the time is yet nigh for TLS 1.0 to be disabled > in opportunistic TLS in SMTP, or whether TLS 1.0 remains sufficiently > common to cause deprecation to do more harm than good via unnecessary > downgrades to cleartext. > > I don't have survey numbers for SMTP TLS protocol versions across MTAs > generally to shed light on this, perhaps someone does. What I do have > is numbers for those MTAs (not a representative sample) that have DANE > TLSA records (so presumably a greater focus on security). > > The observed version frequencies are approximately: > > TLS 1.0: 1% > TLS 1.1: 0% > TLS 1.2: 87% > TLS 1.3: 12% > > essentially regardless of whether I deduplicate by name, IP or name and I= P. > The respective sample sizes are 5435, 6938 and 7959. > > So if a DANE-enabled sender were to disable TLS 1.0 today, approximately > 1% of the destination MX hosts would be broken and need remediation. The= se > handle just of 189 mostly small SOHO domains out of the ~1.1 million tota= l > DANE SMTP domains, but four handle enough email to show up on the Gmail > SMTP transparency report: > > tu-darmstadt.de > t-2.net > t-2.com > t-2.si > > So on the whole, the draft should proceed, but some caution may be > appropriate > outside the browser space, before operators start switching off TLS 1.0 > support. > > I don't see an operational considerations section. Nor much discussion o= f > "less mainstream" (than Web browser) TLS application protocols. Would a > few > words of caution be appropriate, or is it expected that by the time the R= FC > starts to change operator behaviour the "market share" of TLS 1.0 will be > substantially lower than I see today even with SMTP, XMPP, NTTP and the > like. > > [ I would speculate that TLS 1.0's share is noticeably higher among MTAs > generally than among the bleeding-edge MTAs that have published DANE TL= SA > RRs. ] > My take on deprecation drafts is that once published, they take time (years) before there is compliance. Even with that, we may never achieve full compliance and older version use continues. We do know that OpenSSL will continue to support the version that came out last fall for 5 years from that point in time. Publication of the draft does not mean support goes away at that point in time, but provides another push. If there's a strong feeling that text should be added, we could, but my preference would be to leave it to the normal process for deprecation. Thank you, Kathleen > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --=20 Best regards, Kathleen --0000000000002e44040587ea9c0f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Victor,

<= div>Thank you very much for your work and pushing the points on uses of TLS= outside of web as this is an important point.

On Thu, Apr 25, 2019 at 9:30 = PM Viktor Dukhovni <ietf-dane@= dukhovni.org> wrote:
> On Apr 12, 2019, at 7:28 PM, Christopher Wood <caw@heapingbits.net&g= t; wrote:
>
> This is the working group last call for the "Deprecating TLSv1.0 = and TLSv1.1=E2=80=9D draft available at:
>
>=C2=A0 =C2=A0 https://data= tracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/
>
> Please review the document and send your comments to the list by April= 26, 2019.

My concern is whether the time is yet nigh for TLS 1.0 to be disabled
in opportunistic TLS in SMTP, or whether TLS 1.0 remains sufficiently
common to cause deprecation to do more harm than good via unnecessary
downgrades to cleartext.

I don't have survey numbers for SMTP TLS protocol versions across MTAs<= br> generally to shed light on this, perhaps someone does.=C2=A0 What I do have=
is numbers for those MTAs (not a representative sample) that have DANE
TLSA records (so presumably a greater focus on security).

The observed version frequencies are approximately:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 TLS 1.0:=C2=A0 1%
=C2=A0 =C2=A0 =C2=A0 =C2=A0 TLS 1.1:=C2=A0 0%
=C2=A0 =C2=A0 =C2=A0 =C2=A0 TLS 1.2: 87%
=C2=A0 =C2=A0 =C2=A0 =C2=A0 TLS 1.3: 12%

essentially regardless of whether I deduplicate by name, IP or name and IP.=
The respective sample sizes are 5435, 6938 and 7959.

So if a DANE-enabled sender were to disable TLS 1.0 today, approximately 1% of the destination MX hosts would be broken and need remediation.=C2=A0 = These
handle just of 189 mostly small SOHO domains out of the ~1.1 million total<= br> DANE SMTP domains, but four handle enough email to show up on the Gmail
SMTP transparency report:

=C2=A0 tu-darmstadt.de
=C2=A0 t-2.= net
=C2=A0 t-2.= com
=C2=A0 t-2.s= i

So on the whole, the draft should proceed, but some caution may be appropri= ate
outside the browser space, before operators start switching off TLS 1.0 sup= port.

I don't see an operational considerations section.=C2=A0 Nor much discu= ssion of
"less mainstream" (than Web browser) TLS application protocols.= =C2=A0 Would a few
words of caution be appropriate, or is it expected that by the time the RFC=
starts to change operator behaviour the "market share" of TLS 1.0= will be
substantially lower than I see today even with SMTP, XMPP, NTTP and the lik= e.

[ I would speculate that TLS 1.0's share is noticeably higher among MTA= s
=C2=A0 generally than among the bleeding-edge MTAs that have published DANE= TLSA
=C2=A0 RRs. ]

My take on deprecation dr= afts is that once published, they take time (years) before there is complia= nce.=C2=A0 Even with that, we may never achieve full compliance and older v= ersion use continues. We do know that OpenSSL will continue to support the = version that came out last fall for 5 years from that point in time.=C2=A0 = Publication of the draft does not mean support goes away at that point in t= ime, but provides another push.=C2=A0 If there's a strong feeling that = text should be added, we could, but my preference would be to leave it to t= he normal process for deprecation.

Thank you,
Kathleen


--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.

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


--

Best regards,
Kathleen
--0000000000002e44040587ea9c0f-- From nobody Thu May 2 10:05:10 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1E61204DA for ; Thu, 2 May 2019 10:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1IMwobd1Oh7P for ; Thu, 2 May 2019 10:05:07 -0700 (PDT) Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28CD21204D6 for ; Thu, 2 May 2019 10:05:07 -0700 (PDT) Received: by mail-oi1-x22d.google.com with SMTP id d62so2201436oib.13 for ; Thu, 02 May 2019 10:05:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=utyhgNUFSF5RTkg/isG3nZLo0RIUA4tX8SybytjcVMs=; b=dImlWoWTxmZWQ88t7ORrkVKYmcgb311PRGuxTIyu5Hy8lCT4AE5GvqFrwR3uxs0sP5 uvNFsdPkYSpaUQE8WWK59/fj7FaWOSnMAuLHGjCSgaSNaoHFZmSxkyGGJ1pCgwYRYCUs v7XrZ7ONBo/PSQUo1z+vAu7GVdyohlYeoDc4Bi+n5RsfjyxZFvFWbBv0+pYhMmM+2B8f 6q0sBp5lU4nuKbhS5R+4ZZrlaVcZSxln3WujGok3Tj6QNzEu8jSq1lRjCewh+OKz559o 8nISoHltidgy5D+bBEcVVn1YjIRaE9gniX25dGD78T1GK2/unfnL3M0feKQ5v5mnoCAk tApg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=utyhgNUFSF5RTkg/isG3nZLo0RIUA4tX8SybytjcVMs=; b=SB776g49zhen4qA25ii03sDSkCB4mUYPjeqeQqK8MR+87YVNiaOvcmsIHok5pO53GV 40KmxKfWO2GvI296JNvgLZwBMO4Xei98DZpK6im9NJiuiBH7gNwQGlzephVVq5Al4anC HNuXSARvJVcbjdamePwd+kR4pJKsSOhmMkpdC8evX5QAnYi04YjxZRcsjU+rpPcSM0ge aEFqAO3vjNuvIb5H4i2hQN+2vR8Smpzf2Jl4/cvoj914kNwrXfx7ZS7FX3baA1DUW3OE nKNH6zqNmh1eNLyADWfyY2P382sLqVPaovEof1V9O9WxxTH4Rr9hZIHL92RsaXi5LcQG IO2Q== X-Gm-Message-State: APjAAAXxMFKySZQQfndw7i8FTO2Edzf2yhV5rPB9oki4MaRNhbbIoAuj kZMWEkgDjTgJsNdhga5J0Km/UgEt0t+ZOox1TdGDbBc4 X-Google-Smtp-Source: APXvYqzE/EBZ0ZsKJMQ+GokI3pkqE/e23WZRM1fqTCrl7fmvh9olra93qS3CSr+CLbQ8tCxl0ulox67VS9rHyJ8WYpw= X-Received: by 2002:aca:3e56:: with SMTP id l83mr3000131oia.111.1556816706282; Thu, 02 May 2019 10:05:06 -0700 (PDT) MIME-Version: 1.0 References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <2EF7433E-DB94-497F-80D7-2A060097261B@dukhovni.org> <5C3C015B-88B9-4502-861B-C59120B2F151@akamai.com> In-Reply-To: From: Kathleen Moriarty Date: Thu, 2 May 2019 13:04:29 -0400 Message-ID: To: IETF TLS WG Content-Type: multipart/alternative; boundary="000000000000c22ac40587eaa2c2" Archived-At: Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 02 May 2019 17:05:09 -0000 --000000000000c22ac40587eaa2c2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Apr 26, 2019 at 5:29 PM Viktor Dukhovni wrote: > > On Apr 26, 2019, at 11:24 AM, Salz, Rich wrote: > > > > If they haven=E2=80=99t already moved off TLS 1 then maybe this documen= t will > give the right people a push to do so. > > > > Nobody is going to arrest an MTA for non compliance. > > Of course. > > And as I said, I'd like to see the document move forward, I just > wanted to see whether there was any appetite for adding some > operator guidance. It's not an issue of internet policing, > rather it is a question of whether there should advice for > operators who are considering disabling the legacy protocols. > > The sound-bite version is: first raise the ceiling, *then* the floor. > > The advice would therefore be for everyone to first make sure that > their systems support at least TLS 1.2, and not just the now deprecated > versions. And then check whether the same holds true for their applicati= on > ecosystem and if so disable the protocols at that time. > > In unauthenticated opportunistic TLS where cleartext is used when TLS > handshakes fail, removing support for TLS 1.0 can reduce security in the > short term (some messages needlessly going in cleartext). Yes, this may > be what it takes to finally get the long tail procrastinators to upgrade. > > The operational question then boils down to timing: when is your > application > ecosystem ready to drop the training wheels. > > Anyway, it does not look like there's much interest in adding operational > considerations, which users will then perhaps learn about elsewhere if > need be. That's fine... > Thanks for your follow up assessment on this from the WG. It seems we are in agreement. I appreciate your review, consideration, and attention to deployment statistics for this move. Best regards, Kathleen > > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --=20 Best regards, Kathleen --000000000000c22ac40587eaa2c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Apr 26, 2019 at 5:29 PM Vikto= r Dukhovni <ietf-dane@dukhovni= .org> wrote:
> On Apr 26, 2019, at 11:24 AM, Salz, Rich <rsalz@akamai.com> wrote:
>
> If they haven=E2=80=99t already moved off TLS 1 then maybe this docume= nt will give the right people a push to do so.
>=C2=A0
> Nobody is going to arrest an MTA for non compliance.

Of course.

And as I said, I'd like to see the document move forward, I just
wanted to see whether there was any appetite for adding some
operator guidance.=C2=A0 It's not an issue of internet policing,
rather it is a question of whether there should advice for
operators who are considering disabling the legacy protocols.

The sound-bite version is: first raise the ceiling, *then* the floor.

The advice would therefore be for everyone to first make sure that
their systems support at least TLS 1.2, and not just the now deprecated
versions.=C2=A0 And then check whether the same holds true for their applic= ation
ecosystem and if so disable the protocols at that time.

In unauthenticated opportunistic TLS where cleartext is used when TLS
handshakes fail, removing support for TLS 1.0 can reduce security in the short term (some messages needlessly going in cleartext).=C2=A0 Yes, this m= ay
be what it takes to finally get the long tail procrastinators to upgrade.
The operational question then boils down to timing: when is your applicatio= n
ecosystem ready to drop the training wheels.

Anyway, it does not look like there's much interest in adding operation= al
considerations, which users will then perhaps learn about elsewhere if
need be.=C2=A0 That's fine...

Thank= s for your follow up assessment on this from the WG.=C2=A0 It seems we are = in agreement.

I appreciate your review, considerat= ion, and attention to deployment statistics for this move.

Best regards,
Kathleen=C2=A0

--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.

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


--

Best regards,
Kathleen
--000000000000c22ac40587eaa2c2-- From nobody Thu May 2 10:06:50 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58A581205DA for ; Thu, 2 May 2019 10:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7XlyIe-6Gje for ; Thu, 2 May 2019 10:06:47 -0700 (PDT) Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9C9F1205D6 for ; Thu, 2 May 2019 10:06:46 -0700 (PDT) Received: by mail-oi1-x22a.google.com with SMTP id l203so2309834oia.3 for ; Thu, 02 May 2019 10:06:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=anZOpU88FLp7hoBCg4v5UY6b5ZNgo+yFlJMeEhioJM0=; b=FtfXWTFobLOhP50oDPTgdqbXVfZr9SCvqBuATQJy6pToVJMJFPJucC4a1fCOUgTSBt xBAKTa7KA5ijYxux9g563kHWRlviZq4Mtq6atT0iFWX6oY51uFitfK3JiyPWuBFr5Bk0 mC23AqQ9b0s6KoaxAmIviKMghX89PxoHFemJJUNOe0v4ogvME7bO6eD8H9mo8rqBsoPL bX2DuAiCSuzG22k1HWiEnWctJX+fWBIBjK+/1eTIah4Lmxqhcn77TfyFzAJBlaNLqJG8 Zfq9FGVl6pRq4b8v5XhUMmPRtNsAFlqIIoqTKWj8McbS5N7zTOoEtmkqBPMtAhUAnUNr n8Lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=anZOpU88FLp7hoBCg4v5UY6b5ZNgo+yFlJMeEhioJM0=; b=QssIvRPV0EUAutmqRztqBkKVfJgB+VXL93WDxnl7BZu5MA3yXRFyf7QlShm0z0u2wP QoA+qIBTTvPCaVx5Rs9pa0LTxze1aoljNyM8Cu7OKTrI3k6AhUDchrSZYw0rJWX5eCzq 4wy8FjjuztpSdtWMMGlZO0Mam3vdAUZPTmaakSmu9tdFR/eZ/4tqlM1k5rjUVYpuVa/i YRKMz/aMymmAaWhqmz4wfu4CZCVS0857rnYS+nwgOM6mH43+jdIUWzLkrt/ykOBntHcM IrIdkN7qVUz4S06XZ2yWU4LEE/JCDY3MNIJLmStQCYuwfWqmkgYWQLeoViC7qqBwpe10 rt0w== X-Gm-Message-State: APjAAAVbIoR8eQlOpNJ8r/Z2pX+7MN5BvR5MJKsObxcHO2Bv+Z4GlRMI DhR7kgwW9cfeiqXCoIgeLcjWkUiZOQMTYuIc1Pw= X-Google-Smtp-Source: APXvYqzs4kqZ4i0yOc3au9KKaAuThnntjsOkKWRSnor9AXHTqbjQDGFEi56qis4sPpiAETm80Lcza6g1P5zNk2XQYSc= X-Received: by 2002:aca:72c9:: with SMTP id p192mr3207825oic.164.1556816806197; Thu, 02 May 2019 10:06:46 -0700 (PDT) MIME-Version: 1.0 References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <2EF7433E-DB94-497F-80D7-2A060097261B@dukhovni.org> <5C3C015B-88B9-4502-861B-C59120B2F151@akamai.com> <7d37f7ca-e253-4c95-9cf7-2d16b0b6a0aa@www.fastmail.com> <20190430234952.21F5C404C@ld9781.wdf.sap.corp> In-Reply-To: <20190430234952.21F5C404C@ld9781.wdf.sap.corp> From: Kathleen Moriarty Date: Thu, 2 May 2019 13:06:09 -0400 Message-ID: To: mrex@sap.com Cc: Martin Thomson , "" Content-Type: multipart/alternative; boundary="000000000000b6bf5f0587eaa878" Archived-At: Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 02 May 2019 17:06:48 -0000 --000000000000b6bf5f0587eaa878 Content-Type: text/plain; charset="UTF-8" Hello Martin, On Tue, Apr 30, 2019 at 7:50 PM Martin Rex wrote: > Martin Thomson wrote: > > On Sat, Apr 27, 2019, at 07:29, Viktor Dukhovni wrote: > >> The sound-bite version is: first raise the ceiling, *then* the floor. > > > > Yep. We've done the ceiling bit twice now. > > Once in 2008 when we published TLS 1.2 and then in 2018 > > with the publication of TLS 1.3. I'd say we're overdue for the floor > bit. > > Just that this rationale is a blatant lie. > > It is formally provable that from the three protocol versions: > > TLSv1.0, TLSv1.1, TLSv1.2 > > the weakest one is TLSv1.2, because of the royally stupid downgrade > in the strength of digitally signed. > > > Disabling TLSv1.0 will only result in lots of interop failures > and pain, but no improvement in security. > > I believe this is the last outstanding comment, pending a reference. Thank you for your review and contribution. Best regards, Kathleen > > -Martin > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Best regards, Kathleen --000000000000b6bf5f0587eaa878 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Martin,

On Tue, Apr 30, 2019 at 7:50= PM Martin Rex <mrex@sap.com> wro= te:
Martin Thoms= on <mt@lowentropy= .net> wrote:
> On Sat, Apr 27, 2019, at 07:29, Viktor Dukhovni wrote:
>> The sound-bite version is: first raise the ceiling, *then* the flo= or.
>
> Yep.=C2=A0 We've done the ceiling bit twice now.
> Once in 2008 when we published TLS 1.2 and then in 2018
> with the publication of TLS 1.3.=C2=A0 I'd say we're overdue f= or the floor bit.

Just that this rationale is a blatant lie.

It is formally provable that from the three protocol versions:

=C2=A0TLSv1.0, TLSv1.1, TLSv1.2

the weakest one is TLSv1.2, because of the royally stupid downgrade
in the strength of digitally signed.


Disabling TLSv1.0 will only result in lots of interop failures
and pain, but no improvement in security.


I believe this is the last outstanding= comment, pending a reference. Thank you for your review and contribution.<= /div>

Best regards,
Kathleen

-Martin

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


--

Best regards,
Kathleen
--000000000000b6bf5f0587eaa878-- From nobody Thu May 2 14:18:00 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1765F1200F4 for ; Thu, 2 May 2019 14:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5oO6ozJ_tebA for ; Thu, 2 May 2019 14:17:57 -0700 (PDT) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA0B21200C7 for ; Thu, 2 May 2019 14:17:57 -0700 (PDT) Received: by mail-qt1-x82a.google.com with SMTP id k24so652622qtq.7 for ; Thu, 02 May 2019 14:17:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=jO2r5R9qOm857DuvSf25DcQ4aD0NwT/M8F1ixLQIYUc=; b=eiqgG/6rckbkVADgQy5HpPORp9ByJT2vFJNgOlXfuYJ4t3Ho+mECqmSRWF8k2Fy1f+ Rda3MkojErc4ZjBv4fWv7lqGLuWCk72+QAQd0CN5DDxuDfDYhedi6nLoaN6QmHqsTXIJ kYJioWIj8JsqeGwDiU/+l6kxffbBKEEFjrwIvOR4ZijDaXI+AdiNAzw46NQez3TcRbII VdB528pq/bQNoVnt39NUC5G+b+e21YH09MFH8sbsIkQbrcwcR3u1oEnuvbm37UFl28wl TQb/34KRf6VJqoWrw6KFo48R2xp+e3ZlY83pM6ohOnjWg/Gjqa44yycNLaqvEiavj667 m54Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=jO2r5R9qOm857DuvSf25DcQ4aD0NwT/M8F1ixLQIYUc=; b=n1PXEVHgfBTOUlTs781wUYWAfH1YvlYt2mwA891sAQhhsnBmlm/L6Uyk9c+OB0bjYt QqEYxhDyXaqpCFQBGrR1XDYKdMvllOhY7PgWmgdeOYaY5dcTVlnFEcL1C8jShK+yeJ4V 1plgEhe6NifXRYdO4pGEooirE7X4I/JOOyESVJKSX2aVgh1RcfC9jW7yLs4O1qaQ8YDV 8CgeT2BOX7xU1ScI0BuB8yKVLvb8VLO+jW5ErECY8M1KE8yL41of7zQWTJ9f/lVACHM/ urMBY3U+xVDSWvMcnC6Pyh/MMapN6apXGLaROV167+lig2K3lFWc6LMyqdnadV9RXYfK My6g== X-Gm-Message-State: APjAAAVFpEZLlNZIzlwRk4HUmFKDFRbXqxHA/dUINTmxrUmEQqGDMCiZ ok8F9ABEEKo/nf5Z/g90HWeZEVKwh4dvHTlewKEVxX6Jssw= X-Google-Smtp-Source: APXvYqyfGcsyhBi0niM+sLEWAiQVTekt5vRLksA1QEMGkEYgGub6M1zDlFTjwyaiPGSGkkp8Bv9KW1ZzIc0B6wmi5A4= X-Received: by 2002:ac8:3553:: with SMTP id z19mr5444419qtb.146.1556831876291; Thu, 02 May 2019 14:17:56 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Joseph Salowey Date: Thu, 2 May 2019 14:17:45 -0700 Message-ID: To: TLS List Content-Type: multipart/alternative; boundary="000000000000f663f30587ee2ac0" Archived-At: Subject: Re: [TLS] WG adoption call: draft-wood-tls-external-psk-importer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 02 May 2019 21:18:00 -0000 --000000000000f663f30587ee2ac0 Content-Type: text/plain; charset="UTF-8" This call for adoption has completed with positive response for adoption. Please submit the draft as a working group draft - draft-ietf-tls-external-psk-importer-00.txt. On Mon, Apr 8, 2019 at 5:57 PM Sean Turner wrote: > At TLS@IETF104, there was consensus in the room to adopt > draft-wood-tls-external-psk-importer. This message is to confirm that > consensus. If you do not support adoption of > draft-wood-tls-external-psk-importer as WG item please say so by 2359UTC on > 22 April 2019 (and say why). > > Thanks, > Joe and Sean > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000f663f30587ee2ac0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This call for adoption has completed with positive respons= e for adoption.=C2=A0 Please submit the draft as a working group draft -=C2= =A0draft-ietf-tls-external-psk-importer-00.txt.

On Mon, Apr 8, 2019 at 5:57 = PM Sean Turner <sean= @sn3rd.com> wrote:
At TLS@IETF104, there was consensus in the room to adopt draft-w= ood-tls-external-psk-importer.=C2=A0 This message is to confirm that consen= sus.=C2=A0 If you do not support adoption of draft-wood-tls-external-psk-im= porter as WG item please say so by 2359UTC on 22 April 2019 (and say why).<= br>
Thanks,
Joe and Sean
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000f663f30587ee2ac0-- From nobody Thu May 2 16:52:01 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6918C120086 for ; Thu, 2 May 2019 16:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=yPjVqbyj; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QeqxKgmk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjltjq0foiC6 for ; Thu, 2 May 2019 16:51:57 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BB8212003F for ; Thu, 2 May 2019 16:51:57 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 341C123666; Thu, 2 May 2019 19:51:56 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Thu, 02 May 2019 19:51:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type:content-transfer-encoding; s=fm2; bh=MJ Fh5caIrACsrT3uJvDBtKJmdLD10fjKJ3s/z0TVGRY=; b=yPjVqbyj5LbvHW7ArE U00zfOcXoaYSEpgqd6GFCskg3FPdwuWS1AgDrHeGG/un1oNFC+1ypxhkZrUA1iCP 5lNhN0xv1xotp0n+cybccGI0ql9UASgiOysRX3HQbRQY8vHBBEiSJr7UmYRdlf2n ctCN02rg6su54344XTj81MeBzTFBhycHHh07lOnTumG/oWtVJp2thD+zJxSthUze glJy2WBnLyiEa9VtzCh3qJM4Khtgee1ohzk3F8auqUApTibO9FG5/RsiGzWbYMSk dcY0m0e0iEK4GKYQCuVhG18t/0ntvGbdQHrvDJixzOKMeA4139mSaIO2KfzrkPdv JL4w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=MJFh5caIrACsrT3uJvDBtKJmdLD10fjKJ3s/z0TVG RY=; b=QeqxKgmk+vPruObeEc/vWOcAQ4klED64DiXUredFeUXRf7oauheIQ9lux O9l9/xewLc7gtcO9lEXiZhjIk9Z7PeiQxkHfspFqx8VS5Ku6DH9fVZ8MRBk9163v u3642shw4/gD+fKowEUWDO9BlG8bZxKH3erFUNVwQzZWDptWN5DZ0hGJjfPGWfO/ TI48b7SjSaiVSj7vBXoSsMbklKuR/tU1t1U+mnYHYV357eHxjzRjek7Sdc+wItaM WmBXNbFGEH0GQbzJNX+eq5dJR/pKsromCeE94O0GCZ2hrpU3zkXTliSWnfLJjG0X xEBrfGwUdMQvVL3w4nJ6MqAGORlFQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrjedtgddvjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucffohhmrghinhepihgvthhfrdhorhhgnecurfgrrh grmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvghtnecuvehluhhs thgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id BF0367C6D9; Thu, 2 May 2019 19:51:55 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-449-gfb3fc5a-fmstable-20190430v1 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <4d34a22a-3d77-4fe8-9c8e-e2128a7a80f8@www.fastmail.com> Date: Thu, 02 May 2019 19:51:57 -0400 From: "Martin Thomson" To: "Kathleen Moriarty" Cc: "" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 02 May 2019 23:52:00 -0000 Thanks Kathleen, these look like good changes. =20 Nits in the proposed BCP195 section: Lose the "p" in mpost and s/off of/= on/ On Fri, May 3, 2019, at 01:12, Kathleen Moriarty wrote: > Thank you for your feedback in this review. Responses inline as to how= =20 > I propose it is addressed: >=20 > On Sat, Apr 13, 2019 at 12:16 AM Martin Thomson wr= ote: > > Section 1.1 doesn't say *how* those listed documents are updated. Mi= ght pay to include a few works on how. >=20 > Thank you, that was helpful feedback. I changed the introduction text=20= > as follows: > OLD: > This document updates these RFCs that normatively reference TLSv1.0 or= =20 > TLSv1.1 or DTLS1.0 and have not been obsoleted.=20 > NEW: > This document updates the following RFCs that normatively reference=20= > TLSv1.0 or TLSv1.1 or DTLS1.0. The update is to obsolete usage of thes= e=20 > older versions. Fallback to these versions are prohibited through this= =20 > update. >=20 > > Section 2 can be cut down a lot. The quote from another document is= longer than the rest of the text. In many ways, saying that the IETF is= moving last is not a great thing to memorialize in RFC, as much as it i= s useful in an Internet-Draft or in argumentation in support of publicat= ion of the doc. >=20 > A bunch has been cut out already, but I propose also cutting out the=20= > following text to address your specific point (well taken): > 1st paragraph and last 2. >=20 > REMOVE: > Industry has actively followed guidance provided by NIST and the PCI > Council to deprecate TLSv1.0 and TLSv1.1 by June 30, 2018. TLSv1.2 > should remain a minimum baseline for TLS support at this time. >=20 > The Canadian government treasury board have also mandated that these > old versions of TLS not be used.=20 >=20 > Various companies and web sites have announced plans to deprecate > these old versions of TLS. >=20 >=20 > > The title of Section 3 could be a bit clearer. > Proposed:=20 > SHA-1 Usage Problematic in TLSv1.0 and TLSv1.1 >=20 > If you have a more terse suggestion, please post. I agree this should=20= > be more clear. > >=20 > > It might pay to explain what RFC 7525 is in Section 6. Why does tha= t document warrant special attention over the 70-odd other ones. >=20 > Good point, how about the following text: >=20 > PROPOSED: > RFC7525 is BCP195, "Recommendations for Secure Use of Transport Layer=20= > Security (TLS) and Datagram Transport Layer Security (DTLS)", is the=20= > mpost recent best practice document for implementing TLS and was based= =20 > off of TLSv1.2. At the time of publication, TLSv1.0 and TLSv1.1 had no= t=20 > yet been deprecated. As such, this document is called out specifically= =20 > to update text implementing the deprecation recommendations of this=20= > document.=20 >=20 > >=20 > > Otherwise, publish this. >=20 > Thank you! >=20 > I'll continue through the rest of the messages, but may have a delay=20= > when tending to other responsibilities.=20 > I am putting the proposals into a new version to upload to the git=20 > repository. >=20 > Best regards, > Kathleen >=20 > >=20 > >=20 > >=20 > > On Sat, Apr 13, 2019, at 09:28, Christopher Wood wrote: > > > This is the working group last call for the "Deprecating TLSv1.0 = and=20 > > > TLSv1.1=E2=80=9D draft available at: > > >=20 > > > https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-depre= cate/ > > >=20 > > > Please review the document and send your comments to the list by = April 26, 2019. > > >=20 > > > Thanks, > > > Chris, Joe, and Sean > > >=20 > > > _______________________________________________ > > > TLS mailing list > > > TLS@ietf.org > > > https://www.ietf.org/mailman/listinfo/tls > > > > >=20 > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls >=20 >=20 > --=20 >=20 > Best regards, > Kathleen From nobody Thu May 2 17:30:20 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE9571200D7 for ; Thu, 2 May 2019 17:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QunbXmJSUpB0 for ; Thu, 2 May 2019 17:30:16 -0700 (PDT) Received: from mail-qk1-f169.google.com (mail-qk1-f169.google.com [209.85.222.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DB27120086 for ; Thu, 2 May 2019 17:30:16 -0700 (PDT) Received: by mail-qk1-f169.google.com with SMTP id w20so2692465qka.7 for ; Thu, 02 May 2019 17:30:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=7vddY8RVJJIsUCvLfbVLI7Gc54xSvSqDR93SkYIMQvs=; b=MPUo34MdsIUo/kpoPjjQ8vPkUvacfPBMSnkSeibv+5pnwRy9+0FGDLyK8bxe1RIFji OvufFfONnRr70LePBQiUgqdN8+32r1xmanO6ikw88t+l4rI+CoM6QzMXAvGntnLo2a7E aiS/D2R2iwLYmGVqa40Vyp2KzLsmX7Q7vml/0oTBpTaTVd+cFSZEjvI3j97wEkfPEPes EFW5WM0NHVRRZKQGjO/KkRNgQm3Bikwp+tmNXJ3eb7XsTLqE0yvAkntb64yn16uXgYsu OPsUhLfaTuziOL9SsrbpxekgcIVVPzDMYoJjPOBPkWXOp8M/stV6HuWMigatqmfawM06 5W8A== X-Gm-Message-State: APjAAAUgklHl8K5TrMZI9pkRFu9ZIxFtRADoRewxHVtewtsn6l64K4PI Pxi9nY0/RQEeq+01OZf7jXM+Jg6F01+4xPkoyOiLRLju X-Google-Smtp-Source: APXvYqzQFFUIL5VrcfAbZZ+l2cczCaGBTB2fCGJIVHxpx9TaZjh/ljJx6LtKaVnzjffXfp3LXBsVY5tnV95/AZe+ub4= X-Received: by 2002:a37:6087:: with SMTP id u129mr5671680qkb.300.1556843415492; Thu, 02 May 2019 17:30:15 -0700 (PDT) MIME-Version: 1.0 From: Daniel Migault Date: Thu, 2 May 2019 20:30:04 -0400 Message-ID: To: tls Content-Type: multipart/alternative; boundary="000000000000c05cef0587f0da00" Archived-At: Subject: [TLS] RFC8446 Fig3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 00:30:18 -0000 --000000000000c05cef0587f0da00 Content-Type: text/plain; charset="UTF-8" Hi, This might have already been mentioned on the list, but unless I misinterpreter something it seems to me that the second handshake of figure 3 is missing psk_key_exchange_modes extension. Yours, Daniel Figure 3 shows a pair of handshakes in which the first handshake establishes a PSK and the second handshake uses it: Client Server Initial Handshake: ClientHello + key_share --------> ServerHello + key_share {EncryptedExtensions} {CertificateRequest*} {Certificate*} {CertificateVerify*} {Finished} <-------- [Application Data*] {Certificate*} {CertificateVerify*} {Finished} --------> <-------- [NewSessionTicket] [Application Data] <-------> [Application Data] Subsequent Handshake: ClientHello + key_share* + pre_shared_key --------> ServerHello + pre_shared_key + key_share* {EncryptedExtensions} {Finished} <-------- [Application Data*] {Finished} --------> [Application Data] <-------> [Application Data] Figure 3: Message Flow for Resumption and PSK --000000000000c05cef0587f0da00 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBkaXI9Imx0ciI+PGRpdiBkaXI9Imx0ciI+PGRpdiBkaXI9Imx0ciI+SGkswqA8ZGl2Pjxi cj48L2Rpdj48ZGl2PlRoaXMgbWlnaHQgaGF2ZSBhbHJlYWR5IGJlZW4gbWVudGlvbmVkIG9uIHRo ZSBsaXN0LCBidXQgdW5sZXNzIEkgbWlzaW50ZXJwcmV0ZXIgc29tZXRoaW5nIGl0IHNlZW1zIHRv IG1lIHRoYXQgdGhlIHNlY29uZCBoYW5kc2hha2Ugb2YgZmlndXJlIDMgaXMgbWlzc2luZyA8c3Bh biBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZToxMXB0O2ZvbnQtZmFtaWx5OkNhbGlicmksc2Fu cy1zZXJpZiI+cHNrX2tleV9leGNoYW5nZV9tb2RlcyBleHRlbnNpb24uwqA8L3NwYW4+PC9kaXY+ PGRpdj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZToxMXB0O2ZvbnQtZmFtaWx5OkNh bGlicmksc2Fucy1zZXJpZiI+PGJyPjwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuIGxhbmc9IlNWIiBz dHlsZT0iZm9udC1zaXplOjExcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmIj5Zb3Vy cyzCoDwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjEx cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmIj5EYW5pZWw8L3NwYW4+PC9kaXY+PGRp dj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZToxMXB0O2ZvbnQtZmFtaWx5OkNhbGli cmksc2Fucy1zZXJpZiI+PGJyPjwvc3Bhbj48L2Rpdj48ZGl2PsKgRmlndXJlIDMgc2hvd3MgYSBw YWlyIG9mIGhhbmRzaGFrZXMgaW4gd2hpY2ggdGhlIGZpcnN0IGhhbmRzaGFrZTxicj48L2Rpdj48 ZGl2PsKgIMKgZXN0YWJsaXNoZXMgYSBQU0sgYW5kIHRoZSBzZWNvbmQgaGFuZHNoYWtlIHVzZXMg aXQ6PC9kaXY+PGRpdj7CoDwvZGl2PjxkaXY+wqAgwqAgwqAgwqAgwqAgQ2xpZW50wqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqBTZXJ2ZXI8L2Rpdj48ZGl2PsKgPC9kaXY+PGRpdj7CoCDCoEluaXRpYWwgSGFuZHNoYWtl OjwvZGl2PjxkaXY+wqAgwqAgwqAgwqAgwqAgQ2xpZW50SGVsbG88L2Rpdj48ZGl2PsKgIMKgIMKg IMKgIMKgICsga2V5X3NoYXJlwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAtLS0tLS0tLSZndDs8L2Rp dj48ZGl2PsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFNlcnZlckhlbGxvPC9kaXY+PGRp dj7CoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCArIGtleV9zaGFyZTwvZGl2PjxkaXY+wqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAge0VuY3J5cHRlZEV4dGVuc2lvbnN9PC9kaXY+PGRpdj7CoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCB7Q2VydGlmaWNhdGVSZXF1ZXN0Kn08L2Rpdj48ZGl2PsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKge0NlcnRpZmljYXRlKn08L2Rpdj48ZGl2PsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKge0NlcnRpZmljYXRl VmVyaWZ5Kn08L2Rpdj48ZGl2PsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKge0Zpbmlz aGVkfTwvZGl2PjxkaXY+wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgJmx0Oy0tLS0tLS0twqAgwqAgwqBbQXBwbGljYXRpb24gRGF0YSpdPC9kaXY+ PGRpdj7CoCDCoCDCoCDCoCDCoCB7Q2VydGlmaWNhdGUqfTwvZGl2PjxkaXY+wqAgwqAgwqAgwqAg wqAge0NlcnRpZmljYXRlVmVyaWZ5Kn08L2Rpdj48ZGl2PsKgIMKgIMKgIMKgIMKgIHtGaW5pc2hl ZH3CoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAtLS0tLS0tLSZndDs8L2Rpdj48ZGl2PsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICZsdDstLS0tLS0t LcKgIMKgIMKgIFtOZXdTZXNzaW9uVGlja2V0XTwvZGl2PjxkaXY+wqAgwqAgwqAgwqAgwqAgW0Fw cGxpY2F0aW9uIERhdGFdwqAgwqAgwqAgwqAgJmx0Oy0tLS0tLS0mZ3Q7wqAgwqAgwqAgW0FwcGxp Y2F0aW9uIERhdGFdPC9kaXY+PGRpdj7CoDwvZGl2PjxkaXY+wqA8L2Rpdj48ZGl2PsKgIMKgU3Vi c2VxdWVudCBIYW5kc2hha2U6PC9kaXY+PGRpdj7CoCDCoCDCoCDCoCDCoCBDbGllbnRIZWxsbzwv ZGl2PjxkaXY+wqAgwqAgwqAgwqAgwqAgKyBrZXlfc2hhcmUqPC9kaXY+PGRpdj7CoCDCoCDCoCDC oCDCoCArIHByZV9zaGFyZWRfa2V5wqAgwqAgwqAgwqAgwqAgLS0tLS0tLS0mZ3Q7PC9kaXY+PGRp dj7CoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBTZXJ2ZXJIZWxsbzwvZGl2PjxkaXY+wqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqArIHByZV9zaGFyZWRfa2V5PC9kaXY+PGRpdj7CoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCsga2V5X3NoYXJlKjwvZGl2PjxkaXY+wqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg e0VuY3J5cHRlZEV4dGVuc2lvbnN9PC9kaXY+PGRpdj7CoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoHtGaW5pc2hlZH08L2Rpdj48ZGl2PsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICZsdDstLS0tLS0tLcKgIMKgIMKgW0FwcGxpY2F0aW9u IERhdGEqXTwvZGl2PjxkaXY+wqAgwqAgwqAgwqAgwqAge0ZpbmlzaGVkfcKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIC0tLS0tLS0tJmd0OzwvZGl2PjxkaXY+wqAgwqAgwqAgwqAgwqAgW0FwcGxpY2F0 aW9uIERhdGFdwqAgwqAgwqAgwqAgJmx0Oy0tLS0tLS0mZ3Q7wqAgwqAgwqAgW0FwcGxpY2F0aW9u IERhdGFdPC9kaXY+PGRpdj7CoDwvZGl2PjxkaXY+wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBGaWd1 cmUgMzogTWVzc2FnZSBGbG93IGZvciBSZXN1bXB0aW9uIGFuZCBQU0s8L2Rpdj48ZGl2Pjxicj48 L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj4NCg== --000000000000c05cef0587f0da00-- From nobody Thu May 2 17:47:13 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4985E120116; Thu, 2 May 2019 17:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ihWOGOpObkh; Thu, 2 May 2019 17:47:07 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1644E1200FD; Thu, 2 May 2019 17:47:06 -0700 (PDT) Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x430l11l017310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 2 May 2019 20:47:03 -0400 Date: Thu, 2 May 2019 19:47:01 -0500 From: Benjamin Kaduk To: Nick Sullivan Cc: draft-ietf-tls-exported-authenticator.all@ietf.org, "" Message-ID: <20190503004700.GK59871@kduck.mit.edu> References: <20190423182055.GC49657@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [TLS] AD review of draft-ietf-tls-exported-authenticator-08 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 00:47:11 -0000 Hi Nick, Thanks for these updates; generally it looks good, so only a few comments inline... On Mon, Apr 29, 2019 at 02:09:14PM -0700, Nick Sullivan wrote: > Ben, > > Thank you for the thorough review. I've added responses/comments inline and > a PR to the spec https://github.com/tlswg/tls-exported-authenticator/pull/46. > Feel free to respond in the PR for specific changes or on this thread for > structural comments. > > On Tue, Apr 23, 2019 at 11:21 AM Benjamin Kaduk wrote: > > > > Hi all, > > > > I don't think there's anything earth-shattering in here; mostly just > places > > where we can tighten things up before it gets to a broader set of > > reviewers. > > > > Thanks! > > > > -Ben > > > > Abstract, Introduction > > > > Maybe s/other party/peer/? > > How about: > > This document provides a way to authenticate one party of a Transport > Layer Security (TLS) communication to its peer using a certificate > > > Section 1 > > > > This document provides a way to authenticate one party of a Transport > > Layer Security (TLS) communication to another using a certificate > > after the session has been established. This allows both the client > > and server to prove ownership of additional identities at any time > > after the handshake has completed. This proof of authentication can > > be exported and transmitted out of band from one party to be > > validated by the other party. > > > > We need to be careful about what exactly is being proved when, and how it > > synchronizes (or doesn't) with other events/data. > > This will be a general theme throughout... > > > > multiple identities - Endpoints that are authoritative for multiple > > identities - but do not have a single certificate that includes > > all of the identities - can authenticate with those identities > > over a single connection. > > > > (The RFC Editor will do two-hyphen em dashes.) > > I didn't go back and reread the formal analysis that Jonathan sent out, > > but my recollection was that the semantics around being "jointly > > authoritative" over multiple identities are quite subtle, and that the > > wording here may be doing the reader a disservice. > > > Here's a suggested edit: > can authenticate with those identities over a single connection -> > can authenticate additional identities over a single connection I think that strikes a good balance. > Jonathan's analysis showed that the protocol provides "joint > authentication" between the certificate used in the handshake and one added > as an EA. It does not provide "joint authentication" between two EAs. > That's a subtle point, but I think it maps cleanly to this text. > > > > > > > > > > This document intends to replace much of the functionality of > > renegotiation in previous versions of TLS. It has the advantages > > over renegotiation of not requiring additional on-the-wire changes > > during a connection. For simplicity, only TLS 1.2 and later are > > supported. > > > > Well, renegotiation does many things. We need to say why we claim that > > renegotiation was widely used and for what purpose(s), and only then say > > that we provide an alternative. > > Also, the wording about "previous versions of TLS" is pretty vague -- is > > it intended to be "prior to TLS 1.3"? > > > Very good point. > > How about: > Versions of TLS prior to TLS 1.3 used renegotiation as a way to enable > post-handshake client authentication given an existing TLS connection. > The mechanism described in this document may be used to replace the > post-handshake authentication functionality provided by renegotiation. > Unlike renegotiation, exported Authenticator-based post-handshake > authentication does not require any on-the-wire changes. For simplicity, > only TLS 1.2 and later are supported. > > > > > > > > > Post-handshake authentication is defined in TLS 1.3, but it has the > > disadvantage of requiring additional state to be stored in the TLS > > state machine and it composes poorly with multiplexed connection > > protocols like HTTP/2 [RFC7540]. It is also only available for > > > > We should probably be more explicit about "composes poorly" being due to > > the authentication not being tied to a specific event at the higher > > layer (among other things). > > > How about: > Post-handshake authentication is defined in TLS 1.3, but it has the > disadvantage of requiring additional state to be stored in the TLS > state machine. Furthermore, the authentication boundaries of TLS > 1.3 post-handshake authentication align with TLS record boundaries, > which are often not aligned with the authentication boundaries of the > higher-layer protocol. For example, multiplexed connection protocols > like HTTP/2 [RFC7540] do not have a notion of which TLS record > a given message is a part of. I think this covers the important points well; thank you! > > > > > > Section 3 > > > > > > The authenticator request is a structured message that can be > > exported from either party of a TLS connection. It can be > > transmitted to the other party of the TLS connection at the > > application layer. The application layer protocol used to send the > > authenticator SHOULD use TLS as its underlying transport to keep the > > request confidential. > > > > Also to indicate which TLS connection to pull key material from? > > How about: > The authenticator request is a structured message that can be > created by either party of a TLS connection using data exported > from that connection. That's probably okay, though I don't remember if we suggest confidentiality anywhere else now that this mention has been removed. > > > > This message does not include the TLS record layer and is therefore > > not encrypted with a handshake key. > > > > We should probably reword this -- "include the TLS record layer" is > > going to confuse people. It may be as simple as just adding "framing". > > How about: > This message does not include any TLS framing and is > not encrypted with a handshake key. > > > > > > > The CertificateRequest is used to define the parameters in a request > > for an authenticator. The definition for TLS 1.3 is: > > > > struct { > > opaque certificate_request_context<0..2^8-1>; > > Extension extensions<2..2^16-1>; > > } CertificateRequest; > > > > I think we need some filler paragraph in here noting that we re-use the > > data structure but assign slightly different meanings to the fields ("as > > follows") -- otherwise it sounds like we're just repeating the whole > > definition including field descriptions, which we clearly are not > > ("[t]his value is unrelated to the certificate_request_context used in > > post-handshake authentication"). > > > > > > from pre-computing valid authenticators. This value is unrelated > > to the certificate_request_context used in post-handshake > > authentication and collisions do not need to be avoided. > > > > This text seems to invite the reader to ask "collisions between what". > > Perhaps we should just say "there is no need to ensure uniqueness > > between values used in post-handshake authentication and values used for > > exported authenticators". Though if we do that, maybe we want to follow > > up by reiterating the need for uniqueness within each class on its own. > > I think it's important to note that this *is* a recap of the > CertificateRequest > message in TLS 1.3. Maybe it would be clear if the same or similar > description > was used. > > How about an introduction: > This message reuses the structure to the CertificateRequest message in > [TLS13]. > The uniqueness requirements of the certificate_request_context apply > only to CertificateRequest messages that are used as part of > authenticator requests. > There is no impact if the value of a certificate_request_context used in > an authenticator > request matches the value of a certificate_request_context in the > handshake or > in a post-handshake message. > > And then a shorter description: > message. A certificate_request_context value MUST be unique for > each authenticator request within the scope of a connection > (preventing replay and context confusion). The > certificate_request_context SHOULD be chosen to be unpredictable > to the peer (e.g., by randomly generating it) in order to prevent > an attacker who has temporary access to the peer's private key > from pre-computing valid authenticators. > > > > > > > > > extensions: The extensions that are allowed in this structure > > include the extensions defined for CertificateRequest messages > > defined in Section 4.2. of [TLS13] and the server_name [RFC6066] > > extension, which is allowed for client-generated authenticator > > requests. > > > > Do we need to create a new "message type" for the "TLS 1.3" column in > > the registry > > ( > https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml > ) > > for future extensibility? > > This should support the same extensions supported by the corresponding > messages in TLS. To be clear, my musing was about adding "AR" (Authenticator Request" as a possibility, akin to CR, CT, CH, SH, EE, etc. But I don't really have any reasoning to support this being a useful addition, so I'm inclined to leave things as is. > > > > > > Section 4 > > > > An authenticator message can be constructed by either the client or > > the server given an established TLS connection, a certificate, and a > > corresponding private key. Clients MUST NOT send an authenticator > > without a preceding authenticator request; for servers an > > authenticator request is optional. The authenticator uses the > > > > I think at this point in the document we haven't indicated what context > > value to use for unsolicited exported authenticators from the server. > > Do we want to say something here? > > Sure. We can say that it is chosen by the server here, then later the > uniqueness requirement is stated. Text: > corresponding private key. Clients MUST NOT send an authenticator > without a preceding authenticator request; for servers an > authenticator request is optional. For authenticators that do not > correspond > to authenticator requests, the certificate_request_context is chosen by > the server. > > > > > > > Section 4.1 > > > > The context_value used for the exporter is empty (zero length) for > > all four values. The length of the exported value is equal to the > > > > When I first read this I felt a need to think through the consequences > > of using the empty context_value here. A statement to the effect of > > "the exporter value is used as a standard API to obtain a value that > > includes the TLS handshake transcript hash. There is no need to include > > additional context information at this stage, since the > > application-supplied context is included in the actual authenticator > > object" would probably alleviate the concerns of many readers. > > Good addition. How about: > The context_value used for the exporter is empty (zero length) for > all four values. There is no need to include additional context > information at this stage since the application-supplied context > is included in the authenticator itself. The length of the exported > value is equal to the... > > > > > > > length of the output of the hash function selected in TLS for the > > pseudorandom function (PRF). Cipher suites that do not use the TLS > > PRF MUST define a hash function that can be used for this purpose or > > > > Process-wise this is not great wording, seemingly attempting to bind the > > specifications of (already extant?) TLS ciphers to do more work. It's > > probably better to phrase it like "exported authenticators cannot be > > used with cipher suites that do not use the TLS PRF and have not defined > > a hash function for this purpose". > > Good simplification, I'll take it: > length of the output of the hash function selected in TLS for the > pseudorandom function (PRF). Exported authenticators cannot be > used with cipher suites that do not use the TLS PRF and have not defined > a hash function for this purpose. Call this hash function the > authenticator hash. > > The last line was added to make references to this hash easier. > > > > > > > If the connection is TLS 1.2, the master secret MUST have been > > computed with the extended master secret [RFC7627] to avoid key > > synchronization attacks. > > > > Let's rephrase this as "Exported Authenticators MUST NOT be generated or > > accepted on connectons not using the extended master secret [RFC7627] > > extension, to avoid key synchronization attacks", to be very explicit > > about the prohibited behavior. > > Agreed. > > > > > > > section 4.2 > > > > If an authenticator request is present, the extensions used to guide > > the construction of these messages are taken from the authenticator > > request. Unrecognized extensions MUST be ignored. If the > > certificate_request_context from the authenticator request has > > already been used in the connection, then no authenticator should be > > > > What does "used" mean? > > How about: > If the peer creating the certificate_request_context has already created > or > correctly validated an authenticator with the same value, then no > authenticator > > > > > > > Only servers can provide an > > authenticator without a corresponding request. [...] > > > > This statement duplicates a requirement already stated above. > > We can safely remove this line. > > > > > > > ClientHello extensions are used to determine permissible extensions > > in the Certificate message. > > > > I'd suggest reiterating the "negotiation" model for extensions, and that > > you generally can't send something in a response that you didn't receive > > in a request (with, of course, the hardcoded exceptions listed in the > > initial spec for that functionality). > > Not sure the right way to word this. Here's a shot: > ClientHello extensions are used to determine permissible extensions > in the Certificate message. This follows the general model for > extensions in TLS in which extensions can only be included > as part of a Certificate message if they were previously sent as > part of a CertificateRequest message or ClientHello message. This is pretty good. I think I want to add ", to ensure that the recipient will be able to process such extensions" to the end, to show the motivation for it. > > > > > > Section 4.2.1 > > > > In addition to "signature_algorithms" and > > "signature_algorithms_cert", the "server_name" [RFC6066], > > "certificate_authorities" (Section 4.2.4. of [TLS13]), and > > "oid_filters" (Section 4.2.5. of [TLS13]) extensions are used to > > guide certificate selection. The extensions, or others that might > > affect certificate selection, are taken from the authenticator > > request if present, or the TLS handshake if not. > > > > The text about "taken from the authenticator request if present, or the > > TLS handshake if not" seems to be duplicating previous discussions. > > > > Maybe go with "commonly used [to guide certifciate selection]"? We > > don't limit what can be used for that purpose in core spec, IIRC. > > How about we just remove that sentence? > > > > > > > I'm a little reluctant to bring this up, as it's fairly tangential to > > this document, but there seems to be some general disagreement in the > > community about whether the SNI usage model is a proper "negotiation", > > where the recipient has to ack the offered value in order for both > > parties to agree what server name is in use, versus an assertive model > > where the sender just says "this is who I'm trying to talk to" and > > decides from the received certificate whether that's the case. > > But it doesn't look like we have a way to echo back the accepted SNI in > > this message flow.... > > > > Alternative certificate formats such as [RFC7250] Raw Public Keys are > > not supported in this version of the specification. > > > > Even if we call out some things that aren't supported, we probably still > > want to explicitly state what format we do support. > > Let's use: > Only the X509 certificate type in [TLS13] is supported. > Alternative certificate formats such as [RFC7250] Raw Public Keys are > not supported in this version of the specification. > > > > > > > If an authenticator request was provided, the Certificate message > > MUST contain only extensions present in the authenticator request. > > Otherwise, the Certificate message MUST contain only extensions > > present in the TLS handshake. > > > > "Present in the TLS handshake" could mean SH or EE, too (but we just > > mean CH). Also, this is the third time we say that! > > If we're not exactly repeating anymore since the earlier statement only > applies to extensions, and this to the certificate itself. I'll re-word to > make sure it's specific to the Certificate message: > If an authenticator request is present, the signature algorithm MUST be > chosen > from one of the signature schemes present in the authenticator request. > Otherwise, the > signature algorithm used should be chosen from the > "signature_algorithms" sent > by the peer in the TLS ClientHello. > > > > > > > Section 4.2.2 > > > > If an authenticator request is present, the signature algorithm MUST > > be chosen from one of the signature schemes in the authenticator > > request. Otherwise, the signature algorithm used should be chosen > > from the "signature_algorithms" sent by the peer in the TLS > > handshake. > > > > This text could probably be tightened up. Specifically, we mean in the > > CH if we are falling back to the handshake values, and I don't think we > > say what to do if we're using TLS 1.2 and "signature_algorithms" wasn't > > sent in the ClientHello. > > Proposed change: > Otherwise, the signature algorithm used should be chosen > from the "signature_algorithms" sent by the peer in the ClientHello of > the TLS > handshake. There are no available signature algorithms, then no > authenticator should be constructed. > > > > > > > Where Hash is the hash function negotiated by TLS. If the > > authenticator request is not present, it is omitted from this > > construction (that is, it is zero length). > > > > Above, we say that this Hash could be defined on a per-ciphersuite > > basis post-facto; does this text need to be changed to be consistent? > > Yes. Change: > Where Hash is the authenticator hash defined in section 4.1. > > > > > failed CertificateVerify validation, it may be helpful for the > > application to confirm that both peers share the same connection > > using a value derived from the connection secrets before taking a > > user-visible action. > > > > We may want to define a new exporter for that, here, to keep people from > > rolling their own custom (read: broken) scheme. > > Hmm. Maybe that should be a separate spec? I'm not sure we should add > additional mechanisms of this sort into this spec. Fair enough. > > > > > > Also, we could say something about needing to identify (by context?) > > which TLS connection to use for a given EA validation... > > I'm not sure we need to be prescriptive about this. It should be clear > which connection is used from the validate/authenticate API (noticed this > was missing and added it in the PR). > > > > > > > Section 4.2.3 > > > > Maybe give the hash output a good name so we don't get confused about > > Hash vs. HMAC? > > > > The HMAC is computed using the same hash function using the Finished > > MAC Key as a key. > > > > Change: > The HMAC is computed using the authenticator hash with the Finished MAC > Key as a key. > > > > > > > comma after "function"? > > > > Section 4.2.4 > > > > Do we want to reiterate that the record layer framing is not used? > > Ok: > This message does not include any TLS framing. > > > > > > > A given authenticator can be validated by checking the validity of > > the CertificateVerify message given the authenticator request (if > > used) and recomputing the Finished message to see if it matches. > > > > "can be" is not very strong language; do we want to be more proscriptive > > about what needs to be done for proper validation? > > Sure: > An authenticator is valid if the CertificateVerify message is correctly > constructed given the authenticator request (if > used) and the Finished message matches the expected value. When > validating an authenticator, a constant-time > comparison SHOULD be used. > > > > > > Also, is a constant time comparison going to be needed? > > Yes, I think so. Otherwise, some bits of the correct finished message may > leak. > > > > > > > Section 5 > > > > Same comments as above about a comma, and naming the Hash output. > > Noted. > > > > > > > Section 6 > > > > it is possible to implement it at the application layer. TLS > > implementations supporting the use of exported authenticators MUST > > provide application programming interfaces by which clients and > > servers may request and verify exported authenticator messages. > > > > Some people will complain that the MUST is not enforcable by the peer. > > Perhaps saying why we want that property would help, though. > > Good point. I think a SHOULD is more appropriate because the existence of > the API is not enforceable by the peer. > > > > > > > > > o the connection is TLS 1.2 and the extended master secret [RFC7627] > > was not used > > > > nit: "extension", "negotiated" > > Will add. > > > > > > > Section 6.1 > > > > The "request" API takes as input: > > > > o certificate_request_context (from 0 to 255 bytes) > > > > How do I pick this context value? Is it always going to be input from > > the application layer or might I need to pick something (randomly) > > within the TLS stack? > > Application layer. > > > > > > > o set of extensions to include (this MUST include > > signature_algorithms) > > > > It returns an authenticator request, which is a sequence of octets > > that includes a CertificateRequest message. > > > > "includes" or "is"/"comprises"? > > Comprises. Changed. > > > > > Section 6.3 > > > > The "authenticate" takes as input: > > > > nit: "API" > > Will add. > > > > > > > o a signer (either the private key associated with the certificate, > > or interface to perform private key operation) for each chain > > > > If I'm doing a spontaneous server-driven EA but I have multiple possible > > chains I could use, is there guidance to give about who should do the > > picking (application vs. TLS stack) and what the choice should be? > > I don't think TLS provides any guidance, I don't think we need to either. > > > > > > > o an optional authenticator request or certificate_request_context > > (from 0 to 255 bytes) > > > > Why the choice? > > This could be phrased better. The authenticator needs a > certificate_request_context, so you can send it explicitly (spontaneous) or > extract it from the authenticator request. Removing optional fixes this. > > > > > > > It returns either the exported authenticator or an empty > > authenticator as a sequence of octets. It is RECOMMENDED that the > > logic for selecting the certificates and extensions to include in the > > exporter is implemented in the TLS library. Implementing this in the > > TLS library lets the implementer take advantage of existing extension > > and certificate selection logic. > > > > Also to more easily remember what extensions were in CH, right? > > Yes. > > > > > > > It is also possible to implement this API outside of the TLS library > > using TLS exporters. This may be preferable in cases where the > > application does not have access to a TLS library with these APIs or > > when TLS is handled independently of the application layer protocol. > > > > It's harder to remember what extensions were sent in the ClientHello in > > this case, though. > > Right. There might be a need for another API to expose the set of client > hello extensions that were present. > > > > > > > Section 6.4 > > > > What do we do if a triggered and spontaneous EA race, w.r.t. the input > > to the validation process. Do we need to check the context that we're > > trying to validate? > > Do you mean if they both have the same context should this API fail for the > second one? We don't explicitly fail if the context is repeated here. We I think the scenario I had in mind didn't require a collision in the context value, but relied on the fact that for spontaneous EAs the server can pick an arbitrary context value, so the client has to be prepared to accept one and process it. So, the validate API might be called with the authenticator request from the client but the authenticator sent spontaneously by the server. The API implementation needs to check that the context value matches, when the authenticator request is supplied. To some extent this is obvious, but I'm never very well calibrated on how obvious is too obvious to be worth mentioning. > should spell out what happens: > The API MUST return a failure if the certificate_request_context of the > authenticator was used in a > previously validated authenticator. > > > > > It returns the certificate chain and extensions and a status to > > indicate whether the authenticator is valid or not. If the > > authenticator was empty - that is, it did not contain a certificate - > > the certificate chain will contain no certificates. > > > > Should we say what we expect the caller to be doing with the certificate > > chain? > > I don't think it's necessary. > > > > > Also, is an empty authenticator going to be considered "valid"? > > Yes. > > > > > > > Section 8 > > > > The Certificate/Verify/Finished pattern intentionally looks like the > > TLS 1.3 pattern which now has been analyzed several times. In the > > case where the client presents an authenticator to a server, [SIGMAC] > > presents a relevant framework for analysis. > > > > Why is it only in that case? > > I guess it covers both. How about: > The Certificate/Verify/Finished pattern intentionally looks like the > TLS 1.3 pattern which now has been analyzed several times. For example, > [SIGMAC] presents a relevant framework for analysis. > > > > > > > o This property makes it difficult to formally prove that a server > > is jointly authoritative over multiple certificates, rather than > > individually authoritative over each. > > > > I mentioned this already, but these difficulties should be mentioned > > earlier/throughout, and we should think about providing some usage > > guidance for use patterns believed to be safe. > > > > o There is no indication in the TLS layer about which point in time > > an authenticator was computed. Any feedback about the time of > > creation or validation of the authenticator should be tracked as > > part of the application layer semantics if required. > > > > IIUC, all we know is that it's tied to this connection, plus the > > semantics of whatever additional data the application put into the > > context field. Should we say that more explicitly? > > Yes. I like that phrasing. At the end of the paragraph before the bullets: > Authenticators are independent and unidirectional. There is no explicit > state change > inside TLS when an authenticator is either created or validated. The > application in > possession of a validated authenticator can rely on any semantics > associated with data > in the certificate_request_context. Please go ahead and land these edits/the PR and publish a new version when you get a chance. -Ben From nobody Thu May 2 17:47:30 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB52E120677 for ; Thu, 2 May 2019 17:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=x6ZFK7N/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=h/l2Ljah Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eIRVahHZJHfQ for ; Thu, 2 May 2019 17:47:20 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F2D5120682 for ; Thu, 2 May 2019 17:47:20 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 9783022703 for ; Thu, 2 May 2019 20:47:19 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Thu, 02 May 2019 20:47:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=MbNi6uLRzaYgxFshC9EJ62RSA7EMXis WmX2XoAEwvrU=; b=x6ZFK7N/pAZ885TFA7zzqX2AS29qgU+QYBFOAfKfGWpYnzV Sp4MYm9BjppAhbajQQO2FnyBEc5pInoT6QkUB8jBcA0txn86vTnZ3DneRCMXpMQ8 pm+e/lF3GiDKfPanpml2NbvDKme3KSOjYQ/227HXRGtKwDEbU8tQLJx1udglgk9+ fhvm+Kyur64ffZMjG+HeXw9fjkg8knawyribz41f/ccOq1MUqMtq7x5AV1Z84unI RRGF8AVqAhKGS+vqZ+f4cM6e/V4BI0Uq0+vQzKq5kjUH1F7kJ5ATalofb/xEb5Bc T+KxRLAOg9+VBbtrpztoEUW8bvWQOVRaDB4QnjQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=MbNi6u LRzaYgxFshC9EJ62RSA7EMXisWmX2XoAEwvrU=; b=h/l2LjahgnZ5tOC0N3DzGO /DyJnnrj8ZDvq0js9yAu9TelNnjeEW51fZj4BbarSSqpqpo53I5iJoXlHAEVa+Le AfhekjJy85EI1zHBEOiGacphTIYWu7RfRG76IfvqDEpUH5jX47uo81ZXpYEL+qBM YbZ5D+UCvFKhjHwS+thCWbEFM9RLS6p5purIDjs5ZCfUzaYAfUIbg++jfFKff2da RnSzwlf+/6mDJULKed1ZYOb2MMQCAZ/ySqtPYq6WsG8r+RFuwSlhwhhHgmXfCd3W Jv8VbKqifJBFXvWKDqlDY5hEIHXF+/Dul/xJz+PkWN0Z50Mu/t6zu1J6BcFpfREg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrjedtgdeflecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehivghtfhdrohhrghenucfrrghrrg hmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvthenucevlhhushht vghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2B05D7C6D9; Thu, 2 May 2019 20:47:19 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-449-gfb3fc5a-fmstable-20190430v1 Mime-Version: 1.0 Message-Id: <421a5a6c-283a-4f01-a5f8-c456153618ca@www.fastmail.com> In-Reply-To: References: Date: Thu, 02 May 2019 20:47:21 -0400 From: "Martin Thomson" To: tls@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [TLS] RFC8446 Fig3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 00:47:29 -0000 That's right. You might open an editorial erratum, which I would suggest be held for document update. Note that there is no promise that the list of extensions is complete, as this doesn't show the supported_versions or signature_schemes extension either, but the omission is probably not great in this case, since the PSK modes are highly relevant. On Fri, May 3, 2019, at 10:30, Daniel Migault wrote: > Hi, > > This might have already been mentioned on the list, but unless I > misinterpreter something it seems to me that the second handshake of > figure 3 is missing psk_key_exchange_modes extension. > > Yours, > Daniel > > Figure 3 shows a pair of handshakes in which the first handshake > establishes a PSK and the second handshake uses it: > Client Server > Initial Handshake: > ClientHello > + key_share --------> > ServerHello > + key_share > {EncryptedExtensions} > {CertificateRequest*} > {Certificate*} > {CertificateVerify*} > {Finished} > <-------- [Application Data*] > {Certificate*} > {CertificateVerify*} > {Finished} --------> > <-------- [NewSessionTicket] > [Application Data] <-------> [Application Data] > Subsequent Handshake: > ClientHello > + key_share* > + pre_shared_key --------> > ServerHello > + pre_shared_key > + key_share* > {EncryptedExtensions} > {Finished} > <-------- [Application Data*] > {Finished} --------> > [Application Data] <-------> [Application Data] > Figure 3: Message Flow for Resumption and PSK > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Thu May 2 18:04:30 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCE2512011C for ; Thu, 2 May 2019 18:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZqxnUKjAtfv for ; Thu, 2 May 2019 18:04:25 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C66891200EA for ; Thu, 2 May 2019 18:04:25 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 1B044B81E0A; Thu, 2 May 2019 18:04:13 -0700 (PDT) To: ekr@rtfm.com, rdd@cert.org, kaduk@mit.edu, caw@heapingbits.net, joe@salowey.net, sean+ietf@sn3rd.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: daniel.migault@ericsson.com, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20190503010413.1B044B81E0A@rfc-editor.org> Date: Thu, 2 May 2019 18:04:13 -0700 (PDT) Archived-At: Subject: [TLS] [Editorial Errata Reported] RFC8446 (5717) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 01:04:28 -0000 The following errata report has been submitted for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5717 -------------------------------------- Type: Editorial Reported by: Daniel Migault Section: 2.2. Original Text ------------- Figure 3 shows a pair of handshakes in which the first handshake establishes a PSK and the second handshake uses it: Client Server Initial Handshake: ClientHello + key_share --------> ServerHello + key_share {EncryptedExtensions} {CertificateRequest*} {Certificate*} {CertificateVerify*} {Finished} <-------- [Application Data*] {Certificate*} {CertificateVerify*} {Finished} --------> <-------- [NewSessionTicket] [Application Data] <-------> [Application Data] Subsequent Handshake: ClientHello + key_share* + pre_shared_key --------> ServerHello + pre_shared_key + key_share* {EncryptedExtensions} {Finished} <-------- [Application Data*] {Finished} --------> [Application Data] <-------> [Application Data] Figure 3: Message Flow for Resumption and PSK Corrected Text -------------- Figure 3 shows a pair of handshakes in which the first handshake establishes a PSK and the second handshake uses it: Client Server Initial Handshake: ClientHello + key_share --------> ServerHello + key_share {EncryptedExtensions} {CertificateRequest*} {Certificate*} {CertificateVerify*} {Finished} <-------- [Application Data*] {Certificate*} {CertificateVerify*} {Finished} --------> <-------- [NewSessionTicket] [Application Data] <-------> [Application Data] Subsequent Handshake: ClientHello + key_share* + psk_key_exchange_modes + pre_shared_key --------> ServerHello + pre_shared_key + key_share* {EncryptedExtensions} {Finished} <-------- [Application Data*] {Finished} --------> [Application Data] <-------> [Application Data] Figure 3: Message Flow for Resumption and PSK Notes ----- The pre_shared_key requires the pre_share_key extension. As mentioned by Martin Thompson figures do not necessarily guarantee all extensions to be mentioned. However in this case, that would be clarifying to have both extensions mentioned on the figure. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8446 (draft-ietf-tls-tls13-28) -------------------------------------- Title : The Transport Layer Security (TLS) Protocol Version 1.3 Publication Date : August 2018 Author(s) : E. Rescorla Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Thu May 2 18:06:10 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8D512011C for ; Thu, 2 May 2019 18:06:08 -0700 (PDT) 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_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOU4E5pvFhRG for ; Thu, 2 May 2019 18:06:06 -0700 (PDT) Received: from mail-qk1-f179.google.com (mail-qk1-f179.google.com [209.85.222.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 889C212004D for ; Thu, 2 May 2019 18:06:06 -0700 (PDT) Received: by mail-qk1-f179.google.com with SMTP id d5so2721684qko.12 for ; Thu, 02 May 2019 18:06:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3yAntQVMV+25RWKxjXoM7TOhH2FzjvkP8w2v2lo1ZzE=; b=X3UqA+qleOoarySBx5p1U4Lq3thegeKLuMyTmKpbqf62FV0iQHCSZS4pzgTPBchASv GtDBgTIMcXKVsdX7tbGU11s7sqG7nsRFvHM6xe2SmuYo1QgCgwNUB275ATEJTwpYrQL+ aeFAZ09T/gthtA4kIyBsM6g/sAhqHZkiXDA8oY1VeqvhcAMsx2NvUI60pccunJwU8wQM +5/X6e/57V+ftWLJAHEHdQ8ykIhgAn5sxKGQvUJ89C70sAXPg8i9qJwzx2JOIZpITMAv 6oNU5n/jSxW9deJXECQjK61Tn5l5Adp/sQOXIGtDh3FGhKPgr3x/7hNpDhioqOWoGiEN YbMA== X-Gm-Message-State: APjAAAV+71U5Id2xAbyVBmjNA1k4ZIfafO/MmwMDLNBjWv6jydJIoh+A lYMquh5lkUe3pg63bTKs/f1vM6Nk4daSEEjokNMaTA== X-Google-Smtp-Source: APXvYqyVJ7o12dDph5eQsNdq02Pxacp/8a0FPxPVIwvlRpFpVsMTfpt/IQWv/2BpURHIp4vdwWFEn12FKA2TJu51hRg= X-Received: by 2002:a05:620a:129c:: with SMTP id w28mr5381498qki.232.1556845565654; Thu, 02 May 2019 18:06:05 -0700 (PDT) MIME-Version: 1.0 References: <421a5a6c-283a-4f01-a5f8-c456153618ca@www.fastmail.com> In-Reply-To: <421a5a6c-283a-4f01-a5f8-c456153618ca@www.fastmail.com> From: Daniel Migault Date: Thu, 2 May 2019 21:05:54 -0400 Message-ID: To: Martin Thomson Cc: tls Content-Type: multipart/alternative; boundary="000000000000e93b3a0587f15ad5" Archived-At: Subject: Re: [TLS] RFC8446 Fig3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 01:06:09 -0000 --000000000000e93b3a0587f15ad5 Content-Type: text/plain; charset="UTF-8" thanks, I just submitted the erratum. Yours, Daniel On Thu, May 2, 2019 at 8:48 PM Martin Thomson wrote: > That's right. You might open an editorial erratum, which I would suggest > be held for document update. > > Note that there is no promise that the list of extensions is complete, as > this doesn't show the supported_versions or signature_schemes extension > either, but the omission is probably not great in this case, since the PSK > modes are highly relevant. > > On Fri, May 3, 2019, at 10:30, Daniel Migault wrote: > > Hi, > > > > This might have already been mentioned on the list, but unless I > > misinterpreter something it seems to me that the second handshake of > > figure 3 is missing psk_key_exchange_modes extension. > > > > Yours, > > Daniel > > > > Figure 3 shows a pair of handshakes in which the first handshake > > establishes a PSK and the second handshake uses it: > > Client Server > > Initial Handshake: > > ClientHello > > + key_share --------> > > ServerHello > > + key_share > > {EncryptedExtensions} > > {CertificateRequest*} > > {Certificate*} > > {CertificateVerify*} > > {Finished} > > <-------- [Application Data*] > > {Certificate*} > > {CertificateVerify*} > > {Finished} --------> > > <-------- [NewSessionTicket] > > [Application Data] <-------> [Application Data] > > Subsequent Handshake: > > ClientHello > > + key_share* > > + pre_shared_key --------> > > ServerHello > > + pre_shared_key > > + key_share* > > {EncryptedExtensions} > > {Finished} > > <-------- [Application Data*] > > {Finished} --------> > > [Application Data] <-------> [Application Data] > > Figure 3: Message Flow for Resumption and PSK > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000e93b3a0587f15ad5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
thanks, I just submitted the erratum.=C2=A0
Yours,=C2= =A0
Daniel=C2=A0

On Thu, May 2, 2019 at 8:48 PM Martin Thoms= on <mt@lowentropy.net> wrote= :
That's rig= ht.=C2=A0 You might open an editorial erratum, which I would suggest be hel= d for document update.

Note that there is no promise that the list of extensions is complete, as t= his doesn't show the supported_versions or signature_schemes extension = either, but the omission is probably not great in this case, since the PSK = modes=C2=A0 are highly relevant.

On Fri, May 3, 2019, at 10:30, Daniel Migault wrote:
> Hi,
>
> This might have already been mentioned on the list, but unless I
> misinterpreter something it seems to me that the second handshake of <= br> > figure 3 is missing psk_key_exchange_modes extension.
>
> Yours,
> Daniel
>
>=C2=A0 Figure 3 shows a pair of handshakes in which the first handshake=
>=C2=A0 establishes a PSK and the second handshake uses it:
>=C2=A0 Client Server
>=C2=A0 Initial Handshake:
>=C2=A0 ClientHello
>=C2=A0 + key_share -------->
>=C2=A0 ServerHello
>=C2=A0 + key_share
>=C2=A0 {EncryptedExtensions}
>=C2=A0 {CertificateRequest*}
>=C2=A0 {Certificate*}
>=C2=A0 {CertificateVerify*}
>=C2=A0 {Finished}
>=C2=A0 <-------- [Application Data*]
>=C2=A0 {Certificate*}
>=C2=A0 {CertificateVerify*}
>=C2=A0 {Finished} -------->
>=C2=A0 <-------- [NewSessionTicket]
>=C2=A0 [Application Data] <-------> [Application Data]
>=C2=A0 Subsequent Handshake:
>=C2=A0 ClientHello
>=C2=A0 + key_share*
>=C2=A0 + pre_shared_key -------->
>=C2=A0 ServerHello
>=C2=A0 + pre_shared_key
>=C2=A0 + key_share*
>=C2=A0 {EncryptedExtensions}
>=C2=A0 {Finished}
>=C2=A0 <-------- [Application Data*]
>=C2=A0 {Finished} -------->
>=C2=A0 [Application Data] <-------> [Application Data]
>=C2=A0 Figure 3: Message Flow for Resumption and PSK
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000e93b3a0587f15ad5-- From nobody Thu May 2 18:56:39 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC1F0120153 for ; Thu, 2 May 2019 18:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=0azr0WAT; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=wgr6VaCI Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ypbt80aaQ0NU for ; Thu, 2 May 2019 18:56:36 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C473912004D for ; Thu, 2 May 2019 18:56:35 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id F30A522C10 for ; Thu, 2 May 2019 21:56:34 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Thu, 02 May 2019 21:56:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=DiS0VSceAkRFbjKRvWATG+VUTcT7vuh nanxTzgY5CzA=; b=0azr0WATfxhHELQOimtSZuHZosVhuhwIHOhfYBRGeV4IhM/ SjHKiFaF92xXISsNGnq3ofrmPQmX4hmrAAhV0+nv+ChcN0ZuiPKAp2Wa5D45C3Dg F+I1X24zj3zx+tQbzeDQfgwJMjkpKdLh8I/qWRTaZzTMUU3+vY007std2c/oa0Rh 8VbUqfdOTgIJB/VvJiF+/twnNfYqtg+/ixjWGdKkcAPBjOB1nc+oNedPCDTLqsM5 DNxcs7xWIrnYsrXTbcKorGNPVfHT0yhkldroKA0DqWR75fjlVVQwGzpLok2PzjN2 FCxN41u15C7VPchtcTk9OVD7zNzAflRJ9TjwhRA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=DiS0VS ceAkRFbjKRvWATG+VUTcT7vuhnanxTzgY5CzA=; b=wgr6VaCI4ZmZdrepu5Nsbt 8j015i6fX+5QFfDSg9XYVSNA5hIY5/O/u20GfcAMXOrAL0YbFCQYZFwxcVliQ4FQ rMjlg5TkBJiNzDc74TH2W1p/NmBl/5GWL2vqwAT1y6dbTwqkzi2UIzX5Lhqsi759 FT2QmuRhyFG9OmNznql4IMcaAf9tXhvVMVaImQQGmI7/Y8xjSHZaM9ju8gkcwnVh f1Rt2xn1Dn4616fdAcBltfzhsWXheMHixwVJY0bZt2LO9HjU82ZmKroOLMiYpqEQ 8nQ41Nhb2/TCD7aLgr/jaiLC1FzBVgXQ239m57TAonqxAZr0gzb/Rp1UL3ozcN8Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrjedtgdehfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehrfhgtqdgvughithhorhdrohhrgh dpihgvthhfrdhorhhgnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhht rhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7168B7C6D9; Thu, 2 May 2019 21:56:34 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-449-gfb3fc5a-fmstable-20190430v1 Mime-Version: 1.0 Message-Id: <1079aa6b-7f8d-4855-aac6-d5ea99f07ee7@www.fastmail.com> In-Reply-To: <20190503010413.1B044B81E0A@rfc-editor.org> References: <20190503010413.1B044B81E0A@rfc-editor.org> Date: Thu, 02 May 2019 21:56:36 -0400 From: "Martin Thomson" To: tls@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [TLS] [Editorial Errata Reported] RFC8446 (5717) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 01:56:38 -0000 Two fixes required, but then I think HFDU is appropriate: 1. Misspelling of names. 2. The pre_shared_key extension requires the use of the psk_key_exchange_modes extension. On Fri, May 3, 2019, at 11:04, RFC Errata System wrote: > The following errata report has been submitted for RFC8446, > "The Transport Layer Security (TLS) Protocol Version 1.3". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5717 > > -------------------------------------- > Type: Editorial > Reported by: Daniel Migault > > Section: 2.2. > > Original Text > ------------- > > Figure 3 shows a pair of handshakes in which the first handshake > establishes a PSK and the second handshake uses it: > > Client Server > > Initial Handshake: > ClientHello > + key_share --------> > ServerHello > + key_share > {EncryptedExtensions} > {CertificateRequest*} > {Certificate*} > {CertificateVerify*} > {Finished} > <-------- [Application Data*] > {Certificate*} > {CertificateVerify*} > {Finished} --------> > <-------- [NewSessionTicket] > [Application Data] <-------> [Application Data] > > > Subsequent Handshake: > ClientHello > + key_share* > + pre_shared_key --------> > ServerHello > + pre_shared_key > + key_share* > {EncryptedExtensions} > {Finished} > <-------- [Application Data*] > {Finished} --------> > [Application Data] <-------> [Application Data] > > Figure 3: Message Flow for Resumption and PSK > > > Corrected Text > -------------- > > Figure 3 shows a pair of handshakes in which the first handshake > establishes a PSK and the second handshake uses it: > > Client Server > > Initial Handshake: > ClientHello > + key_share --------> > ServerHello > + key_share > {EncryptedExtensions} > {CertificateRequest*} > {Certificate*} > {CertificateVerify*} > {Finished} > <-------- [Application Data*] > {Certificate*} > {CertificateVerify*} > {Finished} --------> > <-------- [NewSessionTicket] > [Application Data] <-------> [Application Data] > > > Subsequent Handshake: > ClientHello > + key_share* > + psk_key_exchange_modes > + pre_shared_key --------> > > ServerHello > + pre_shared_key > + key_share* > {EncryptedExtensions} > {Finished} > <-------- [Application Data*] > {Finished} --------> > [Application Data] <-------> [Application Data] > > Figure 3: Message Flow for Resumption and PSK > > > Notes > ----- > The pre_shared_key requires the pre_share_key extension. As mentioned > by Martin Thompson figures do not necessarily guarantee all extensions > to be mentioned. However in this case, that would be clarifying to have > both extensions mentioned on the figure. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC8446 (draft-ietf-tls-tls13-28) > -------------------------------------- > Title : The Transport Layer Security (TLS) Protocol Version 1.3 > Publication Date : August 2018 > Author(s) : E. Rescorla > Category : PROPOSED STANDARD > Source : Transport Layer Security > Area : Security > Stream : IETF > Verifying Party : IESG > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Thu May 2 19:12:17 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A505120183 for ; Thu, 2 May 2019 19:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KrzCXgIYGquH for ; Thu, 2 May 2019 19:12:14 -0700 (PDT) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C09DA12016E for ; Thu, 2 May 2019 19:12:13 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id y8so3754720ljd.3 for ; Thu, 02 May 2019 19:12:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rNJSLMVKwL5GpMyrDsxXe0YFbXfHYKCOYorBiZiSQA8=; b=qkIc+0+YobIM3bYZrfXra24E1yeP0lq1NtvHacUnp3tvk0DF1Y1f9psvjjELJ+bfB/ gULD3eMUDriJolKpDX7d6D6oL/kELivIFIrp8saYuFltHL6FQpS/88JtXpuMRT2y/i2b LCi1omtafMo4Mtk6btA54y8vobQvRFBc/xeOiY8uHQteqgqw+nkBoi3tpVF9E8lcgr0m VM858P6KlXGqWZERN8VhE/EUHTNR8WbRPW4YJZrii7zcH40F1O3CyPV/7gUkGSjn3dda HT++l2Up8u5fhAxJGPrPiOe61YbpAbwxYSlge0ZdpwEiBhO26xU3PRSw0O1RCcKpGrZf trEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rNJSLMVKwL5GpMyrDsxXe0YFbXfHYKCOYorBiZiSQA8=; b=sL96Tkirz0nFmnrDDKuR0O70rCHxfx+hLKGvGYdZjO9/OODIQXcXjVBEDnZcfHAi9P mTXNbYmb+BiAAcdo8n4qrTJq4sH0knqr6JdDx6Xt6tLVn+j/Tf2SFg75YvlHyx7Ck+l+ PpuTodue7faAFmm2NpuFeYR/CkGNcO+3tKiy0Q86aYng1UjrCxN67BKqwR1WES1KqGXs PkU2btfoK2i45MYZWxbLocgldQvfWxH7KLkVxm44pij2JtwxnOiaSvjHfLptjhmkEzjT lDY6aELHyXqSdmvCoUst6mhWeKb6U2ANhYS/msEHr3fkrfhHQukk+CEFNVrZIetLx8Eh Qlgg== X-Gm-Message-State: APjAAAVP6mZwKIkKCXkHxj2+TdyOvIql250eqUo+L5m5X2nsszGBTFht eYVo6OpdQ9m0cujrJT5hroZGMcEspqHTcYFDXSjMi55f X-Google-Smtp-Source: APXvYqzZJFUkmP4uTN2kLclmKfnWxJUiDQoJxnJD6wQN+l7TMn61KFX3imeUf3QlrawDY/71fewfkIOJbvrFeXti9Mw= X-Received: by 2002:a2e:5d1:: with SMTP id 200mr3294993ljf.59.1556849531883; Thu, 02 May 2019 19:12:11 -0700 (PDT) MIME-Version: 1.0 References: <20190503010413.1B044B81E0A@rfc-editor.org> <1079aa6b-7f8d-4855-aac6-d5ea99f07ee7@www.fastmail.com> In-Reply-To: <1079aa6b-7f8d-4855-aac6-d5ea99f07ee7@www.fastmail.com> From: Eric Rescorla Date: Thu, 2 May 2019 19:11:33 -0700 Message-ID: To: Martin Thomson Cc: "" Content-Type: multipart/alternative; boundary="0000000000005127ca0587f247eb" Archived-At: Subject: Re: [TLS] [Editorial Errata Reported] RFC8446 (5717) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 02:12:16 -0000 --0000000000005127ca0587f247eb Content-Type: text/plain; charset="UTF-8" MT: why do you not think "confirmed"? -Ekr On Thu, May 2, 2019 at 6:56 PM Martin Thomson wrote: > Two fixes required, but then I think HFDU is appropriate: > > 1. Misspelling of names. > > 2. The pre_shared_key extension requires the use of the > psk_key_exchange_modes extension. > > On Fri, May 3, 2019, at 11:04, RFC Errata System wrote: > > The following errata report has been submitted for RFC8446, > > "The Transport Layer Security (TLS) Protocol Version 1.3". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata/eid5717 > > > > -------------------------------------- > > Type: Editorial > > Reported by: Daniel Migault > > > > Section: 2.2. > > > > Original Text > > ------------- > > > > Figure 3 shows a pair of handshakes in which the first handshake > > establishes a PSK and the second handshake uses it: > > > > Client Server > > > > Initial Handshake: > > ClientHello > > + key_share --------> > > ServerHello > > + key_share > > {EncryptedExtensions} > > {CertificateRequest*} > > {Certificate*} > > {CertificateVerify*} > > {Finished} > > <-------- [Application Data*] > > {Certificate*} > > {CertificateVerify*} > > {Finished} --------> > > <-------- [NewSessionTicket] > > [Application Data] <-------> [Application Data] > > > > > > Subsequent Handshake: > > ClientHello > > + key_share* > > + pre_shared_key --------> > > ServerHello > > + pre_shared_key > > + key_share* > > {EncryptedExtensions} > > {Finished} > > <-------- [Application Data*] > > {Finished} --------> > > [Application Data] <-------> [Application Data] > > > > Figure 3: Message Flow for Resumption and PSK > > > > > > Corrected Text > > -------------- > > > > Figure 3 shows a pair of handshakes in which the first handshake > > establishes a PSK and the second handshake uses it: > > > > Client Server > > > > Initial Handshake: > > ClientHello > > + key_share --------> > > ServerHello > > + key_share > > {EncryptedExtensions} > > {CertificateRequest*} > > {Certificate*} > > {CertificateVerify*} > > {Finished} > > <-------- [Application Data*] > > {Certificate*} > > {CertificateVerify*} > > {Finished} --------> > > <-------- [NewSessionTicket] > > [Application Data] <-------> [Application Data] > > > > > > Subsequent Handshake: > > ClientHello > > + key_share* > > + psk_key_exchange_modes > > + pre_shared_key --------> > > > > ServerHello > > + pre_shared_key > > + key_share* > > {EncryptedExtensions} > > {Finished} > > <-------- [Application Data*] > > {Finished} --------> > > [Application Data] <-------> [Application Data] > > > > Figure 3: Message Flow for Resumption and PSK > > > > > > Notes > > ----- > > The pre_shared_key requires the pre_share_key extension. As mentioned > > by Martin Thompson figures do not necessarily guarantee all extensions > > to be mentioned. However in this case, that would be clarifying to have > > both extensions mentioned on the figure. > > > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC8446 (draft-ietf-tls-tls13-28) > > -------------------------------------- > > Title : The Transport Layer Security (TLS) Protocol > Version 1.3 > > Publication Date : August 2018 > > Author(s) : E. Rescorla > > Category : PROPOSED STANDARD > > Source : Transport Layer Security > > Area : Security > > Stream : IETF > > Verifying Party : IESG > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000005127ca0587f247eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBkaXI9Imx0ciI+PGRpdj5NVDogd2h5IGRvIHlvdSBub3QgdGhpbmsgJnF1b3Q7Y29uZmly bWVkJnF1b3Q7PzwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+LUVrcjwvZGl2PjxkaXY+PGJyPjwv ZGl2PjwvZGl2Pjxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+PGRpdiBkaXI9Imx0ciIgY2xh c3M9ImdtYWlsX2F0dHIiPk9uIFRodSwgTWF5IDIsIDIwMTkgYXQgNjo1NiBQTSBNYXJ0aW4gVGhv bXNvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm10QGxvd2VudHJvcHkubmV0Ij5tdEBsb3dlbnRyb3B5 Lm5ldDwvYT4mZ3Q7IHdyb3RlOjxicj48L2Rpdj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVv dGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlk IHJnYigyMDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFleCI+VHdvIGZpeGVzIHJlcXVpcmVkLCBi dXQgdGhlbiBJIHRoaW5rIEhGRFUgaXMgYXBwcm9wcmlhdGU6PGJyPg0KPGJyPg0KMS4gTWlzc3Bl bGxpbmcgb2YgbmFtZXMuPGJyPg0KPGJyPg0KMi4gVGhlIHByZV9zaGFyZWRfa2V5IGV4dGVuc2lv biByZXF1aXJlcyB0aGUgdXNlIG9mIHRoZSBwc2tfa2V5X2V4Y2hhbmdlX21vZGVzIGV4dGVuc2lv bi48YnI+DQo8YnI+DQpPbiBGcmksIE1heSAzLCAyMDE5LCBhdCAxMTowNCwgUkZDIEVycmF0YSBT eXN0ZW0gd3JvdGU6PGJyPg0KJmd0OyBUaGUgZm9sbG93aW5nIGVycmF0YSByZXBvcnQgaGFzIGJl ZW4gc3VibWl0dGVkIGZvciBSRkM4NDQ2LDxicj4NCiZndDsgJnF1b3Q7VGhlIFRyYW5zcG9ydCBM YXllciBTZWN1cml0eSAoVExTKSBQcm90b2NvbCBWZXJzaW9uIDEuMyZxdW90Oy48YnI+DQomZ3Q7 IDxicj4NCiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQom Z3Q7IFlvdSBtYXkgcmV2aWV3IHRoZSByZXBvcnQgYmVsb3cgYW5kIGF0Ojxicj4NCiZndDsgPGEg aHJlZj0iaHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9lcnJhdGEvZWlkNTcxNyIgcmVsPSJub3Jl ZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9lcnJhdGEv ZWlkNTcxNzwvYT48YnI+DQomZ3Q7IDxicj4NCiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7IFR5cGU6IEVkaXRvcmlhbDxicj4NCiZndDsgUmVwb3J0 ZWQgYnk6IERhbmllbCBNaWdhdWx0ICZsdDs8YSBocmVmPSJtYWlsdG86ZGFuaWVsLm1pZ2F1bHRA ZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGFuaWVsLm1pZ2F1bHRAZXJpY3Nzb24uY29t PC9hPiZndDs8YnI+DQomZ3Q7IDxicj4NCiZndDsgU2VjdGlvbjogMi4yLjxicj4NCiZndDsgPGJy Pg0KJmd0OyBPcmlnaW5hbCBUZXh0PGJyPg0KJmd0OyAtLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7wqAgRmlndXJlIDMgc2hvd3MgYSBwYWlyIG9mIGhhbmRzaGFrZXMgaW4gd2hpY2gg dGhlIGZpcnN0IGhhbmRzaGFrZTxicj4NCiZndDvCoCDCoCBlc3RhYmxpc2hlcyBhIFBTSyBhbmQg dGhlIHNlY29uZCBoYW5kc2hha2UgdXNlcyBpdDo8YnI+DQomZ3Q7wqAgPGJyPg0KJmd0O8KgIMKg IMKgIMKgIMKgIMKgQ2xpZW50wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBTZXJ2ZXI8YnI+DQomZ3Q7wqAgPGJyPg0K Jmd0O8KgIMKgIEluaXRpYWwgSGFuZHNoYWtlOjxicj4NCiZndDvCoCDCoCDCoCDCoCDCoCDCoENs aWVudEhlbGxvPGJyPg0KJmd0O8KgIMKgIMKgIMKgIMKgIMKgKyBrZXlfc2hhcmXCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoC0tLS0tLS0tJmd0Ozxicj4NCiZndDvCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoFNlcnZlckhlbGxvPGJyPg0KJmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgKyBrZXlfc2hhcmU8YnI+DQomZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB7RW5jcnlwdGVkRXh0 ZW5zaW9uc308YnI+DQomZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB7Q2VydGlmaWNhdGVSZXF1ZXN0Kn08 YnI+DQomZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAge0NlcnRpZmljYXRlKn08YnI+DQom Z3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAge0NlcnRpZmljYXRlVmVyaWZ5Kn08YnI+DQomZ3Q7wqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAge0ZpbmlzaGVkfTxicj4NCiZndDvCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCZsdDstLS0tLS0t LcKgIMKgIMKgW0FwcGxpY2F0aW9uIERhdGEqXTxicj4NCiZndDvCoCDCoCDCoCDCoCDCoCDCoHtD ZXJ0aWZpY2F0ZSp9PGJyPg0KJmd0O8KgIMKgIMKgIMKgIMKgIMKge0NlcnRpZmljYXRlVmVyaWZ5 Kn08YnI+DQomZ3Q7wqAgwqAgwqAgwqAgwqAgwqB7RmluaXNoZWR9wqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgLS0tLS0tLS0mZ3Q7PGJyPg0KJmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgJmx0Oy0tLS0tLS0twqAgwqAgwqAgW05ld1Nlc3Np b25UaWNrZXRdPGJyPg0KJmd0O8KgIMKgIMKgIMKgIMKgIMKgW0FwcGxpY2F0aW9uIERhdGFdwqAg wqAgwqAgwqAgJmx0Oy0tLS0tLS0mZ3Q7wqAgwqAgwqAgW0FwcGxpY2F0aW9uIERhdGFdPGJyPg0K Jmd0O8KgIDxicj4NCiZndDvCoCA8YnI+DQomZ3Q7wqAgwqAgU3Vic2VxdWVudCBIYW5kc2hha2U6 PGJyPg0KJmd0O8KgIMKgIMKgIMKgIMKgIMKgQ2xpZW50SGVsbG88YnI+DQomZ3Q7wqAgwqAgwqAg wqAgwqAgwqArIGtleV9zaGFyZSo8YnI+DQomZ3Q7wqAgwqAgwqAgwqAgwqAgwqArIHByZV9zaGFy ZWRfa2V5wqAgwqAgwqAgwqAgwqAgLS0tLS0tLS0mZ3Q7PGJyPg0KJmd0O8KgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgU2VydmVySGVsbG88YnI+DQomZ3Q7wqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgKyBwcmVfc2hhcmVkX2tleTxicj4NCiZndDvCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCArIGtleV9zaGFyZSo8YnI+DQomZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB7RW5jcnlwdGVkRXh0 ZW5zaW9uc308YnI+DQomZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAge0Zpbmlz aGVkfTxicj4NCiZndDvCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCZsdDstLS0tLS0tLcKgIMKgIMKgW0FwcGxpY2F0aW9uIERhdGEqXTxicj4N CiZndDvCoCDCoCDCoCDCoCDCoCDCoHtGaW5pc2hlZH3CoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAt LS0tLS0tLSZndDs8YnI+DQomZ3Q7wqAgwqAgwqAgwqAgwqAgwqBbQXBwbGljYXRpb24gRGF0YV3C oCDCoCDCoCDCoCAmbHQ7LS0tLS0tLSZndDvCoCDCoCDCoCBbQXBwbGljYXRpb24gRGF0YV08YnI+ DQomZ3Q7wqAgPGJyPg0KJmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEZpZ3VyZSAzOiBNZXNz YWdlIEZsb3cgZm9yIFJlc3VtcHRpb24gYW5kIFBTSzxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IENvcnJlY3RlZCBUZXh0PGJyPg0KJmd0OyAtLS0tLS0tLS0tLS0tLTxicj4NCiZndDsg PGJyPg0KJmd0O8KgIEZpZ3VyZSAzIHNob3dzIGEgcGFpciBvZiBoYW5kc2hha2VzIGluIHdoaWNo IHRoZSBmaXJzdCBoYW5kc2hha2U8YnI+DQomZ3Q7wqAgwqAgZXN0YWJsaXNoZXMgYSBQU0sgYW5k IHRoZSBzZWNvbmQgaGFuZHNoYWtlIHVzZXMgaXQ6PGJyPg0KJmd0O8KgIDxicj4NCiZndDvCoCDC oCDCoCDCoCDCoCDCoENsaWVudMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgU2VydmVyPGJyPg0KJmd0O8KgIDxicj4N CiZndDvCoCDCoCBJbml0aWFsIEhhbmRzaGFrZTo8YnI+DQomZ3Q7wqAgwqAgwqAgwqAgwqAgwqBD bGllbnRIZWxsbzxicj4NCiZndDvCoCDCoCDCoCDCoCDCoCDCoCsga2V5X3NoYXJlwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAtLS0tLS0tLSZndDs8YnI+DQomZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqBTZXJ2ZXJIZWxsbzxicj4NCiZndDvCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCsga2V5X3NoYXJlPGJyPg0KJmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKge0VuY3J5cHRlZEV4 dGVuc2lvbnN9PGJyPg0KJmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKge0NlcnRpZmljYXRlUmVxdWVzdCp9 PGJyPg0KJmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHtDZXJ0aWZpY2F0ZSp9PGJyPg0K Jmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIHtDZXJ0aWZpY2F0ZVZlcmlmeSp9PGJyPg0KJmd0O8KgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHtGaW5pc2hlZH08YnI+DQomZ3Q7wqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAmbHQ7LS0tLS0t LS3CoCDCoCDCoFtBcHBsaWNhdGlvbiBEYXRhKl08YnI+DQomZ3Q7wqAgwqAgwqAgwqAgwqAgwqB7 Q2VydGlmaWNhdGUqfTxicj4NCiZndDvCoCDCoCDCoCDCoCDCoCDCoHtDZXJ0aWZpY2F0ZVZlcmlm eSp9PGJyPg0KJmd0O8KgIMKgIMKgIMKgIMKgIMKge0ZpbmlzaGVkfcKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIC0tLS0tLS0tJmd0Ozxicj4NCiZndDvCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCZsdDstLS0tLS0tLcKgIMKgIMKgIFtOZXdTZXNz aW9uVGlja2V0XTxicj4NCiZndDvCoCDCoCDCoCDCoCDCoCDCoFtBcHBsaWNhdGlvbiBEYXRhXcKg IMKgIMKgIMKgICZsdDstLS0tLS0tJmd0O8KgIMKgIMKgIFtBcHBsaWNhdGlvbiBEYXRhXTxicj4N CiZndDvCoCA8YnI+DQomZ3Q7wqAgPGJyPg0KJmd0O8KgIMKgIFN1YnNlcXVlbnQgSGFuZHNoYWtl Ojxicj4NCiZndDvCoCDCoCDCoCDCoCDCoCDCoENsaWVudEhlbGxvPGJyPg0KJmd0O8KgIMKgIMKg IMKgIMKgIMKgKyBrZXlfc2hhcmUqPGJyPg0KJmd0O8KgIMKgIMKgIMKgIMKgIMKgKyBwc2tfa2V5 X2V4Y2hhbmdlX21vZGVzwqAgwqAgwqAgwqAgPGJyPg0KJmd0O8KgIMKgIMKgIMKgIMKgIMKgKyBw cmVfc2hhcmVkX2tlecKgIMKgIMKgIMKgIMKgIC0tLS0tLS0tJmd0Ozxicj4NCiZndDsgPGJyPg0K Jmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgU2VydmVySGVsbG88YnI+DQomZ3Q7 wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgKyBwcmVfc2hhcmVkX2tleTxicj4NCiZndDvCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCArIGtleV9zaGFyZSo8YnI+DQomZ3Q7wqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqB7RW5jcnlwdGVkRXh0ZW5zaW9uc308YnI+DQomZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAge0ZpbmlzaGVkfTxicj4NCiZndDvCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCZsdDstLS0tLS0tLcKgIMKgIMKgW0FwcGxp Y2F0aW9uIERhdGEqXTxicj4NCiZndDvCoCDCoCDCoCDCoCDCoCDCoHtGaW5pc2hlZH3CoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCAtLS0tLS0tLSZndDs8YnI+DQomZ3Q7wqAgwqAgwqAgwqAgwqAgwqBb QXBwbGljYXRpb24gRGF0YV3CoCDCoCDCoCDCoCAmbHQ7LS0tLS0tLSZndDvCoCDCoCDCoCBbQXBw bGljYXRpb24gRGF0YV08YnI+DQomZ3Q7wqAgPGJyPg0KJmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIEZpZ3VyZSAzOiBNZXNzYWdlIEZsb3cgZm9yIFJlc3VtcHRpb24gYW5kIFBTSzxicj4NCiZn dDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE5vdGVzPGJyPg0KJmd0OyAtLS0tLTxicj4NCiZndDsg VGhlIHByZV9zaGFyZWRfa2V5IHJlcXVpcmVzIHRoZSBwcmVfc2hhcmVfa2V5IGV4dGVuc2lvbi4g QXMgbWVudGlvbmVkIDxicj4NCiZndDsgYnkgTWFydGluIFRob21wc29uIGZpZ3VyZXMgZG8gbm90 IG5lY2Vzc2FyaWx5IGd1YXJhbnRlZSBhbGwgZXh0ZW5zaW9ucyA8YnI+DQomZ3Q7IHRvIGJlIG1l bnRpb25lZC4gSG93ZXZlciBpbiB0aGlzIGNhc2UsIHRoYXQgd291bGQgYmUgY2xhcmlmeWluZyB0 byBoYXZlIDxicj4NCiZndDsgYm90aCBleHRlbnNpb25zIG1lbnRpb25lZCBvbiB0aGUgZmlndXJl Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBJbnN0cnVjdGlvbnM6PGJyPg0KJmd0OyAtLS0tLS0tLS0t LS0tPGJyPg0KJmd0OyBUaGlzIGVycmF0dW0gaXMgY3VycmVudGx5IHBvc3RlZCBhcyAmcXVvdDtS ZXBvcnRlZCZxdW90Oy4gSWYgbmVjZXNzYXJ5LCBwbGVhc2U8YnI+DQomZ3Q7IHVzZSAmcXVvdDtS ZXBseSBBbGwmcXVvdDsgdG8gZGlzY3VzcyB3aGV0aGVyIGl0IHNob3VsZCBiZSB2ZXJpZmllZCBv cjxicj4NCiZndDsgcmVqZWN0ZWQuIFdoZW4gYSBkZWNpc2lvbiBpcyByZWFjaGVkLCB0aGUgdmVy aWZ5aW5nIHBhcnR5wqAgPGJyPg0KJmd0OyBjYW4gbG9nIGluIHRvIGNoYW5nZSB0aGUgc3RhdHVz IGFuZCBlZGl0IHRoZSByZXBvcnQsIGlmIG5lY2Vzc2FyeS4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyBSRkM4NDQ2 IChkcmFmdC1pZXRmLXRscy10bHMxMy0yOCk8YnI+DQomZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyBUaXRsZcKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg OiBUaGUgVHJhbnNwb3J0IExheWVyIFNlY3VyaXR5IChUTFMpIFByb3RvY29sIFZlcnNpb24gMS4z PGJyPg0KJmd0OyBQdWJsaWNhdGlvbiBEYXRlwqAgwqAgOiBBdWd1c3QgMjAxODxicj4NCiZndDsg QXV0aG9yKHMpwqAgwqAgwqAgwqAgwqAgwqA6IEUuIFJlc2NvcmxhPGJyPg0KJmd0OyBDYXRlZ29y ecKgIMKgIMKgIMKgIMKgIMKgIDogUFJPUE9TRUQgU1RBTkRBUkQ8YnI+DQomZ3Q7IFNvdXJjZcKg IMKgIMKgIMKgIMKgIMKgIMKgIDogVHJhbnNwb3J0IExheWVyIFNlY3VyaXR5PGJyPg0KJmd0OyBB cmVhwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgOiBTZWN1cml0eTxicj4NCiZndDsgU3RyZWFtwqAg wqAgwqAgwqAgwqAgwqAgwqAgOiBJRVRGPGJyPg0KJmd0OyBWZXJpZnlpbmcgUGFydHnCoCDCoCDC oDogSUVTRzxicj4NCiZndDsgPGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgVExTIG1haWxpbmcgbGlzdDxicj4NCiZndDsg PGEgaHJlZj0ibWFpbHRvOlRMU0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlRMU0BpZXRmLm9y ZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdGxzIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RsczwvYT48YnI+DQomZ3Q7PGJyPg0KPGJyPg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpUTFMgbWFp bGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlRMU0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPlRMU0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3RscyIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHM8L2E+PGJyPg0KPC9ibG9ja3F1 b3RlPjwvZGl2Pg0K --0000000000005127ca0587f247eb-- From nobody Thu May 2 19:14:23 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84CCF12016E for ; Thu, 2 May 2019 19:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=TOWkTh5q; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=GrnP4CtW Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8LjX5_5UWuq for ; Thu, 2 May 2019 19:14:19 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E942120139 for ; Thu, 2 May 2019 19:14:19 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 5C61B21C39; Thu, 2 May 2019 22:14:18 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Thu, 02 May 2019 22:14:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm2; bh=mgXI5ggbPkOWf4cWiD69ev9BGwIw TwoUyCxumyoEf8o=; b=TOWkTh5qYPEnyJKD33Fb58GIM1RJVIh4Ii5PzO82iXHy vRoSxfhGRW4LUrrgZlQPe0z+fZsYBD7ErrGGfjcniwDiTj7tH9pCq7pYDZzjTmkT 3s3TG8ET0QUSrzmd/g5WrCfcGX2gXpn9Y8W3s530SDUfCMvWxzDAj3ZaO+G+tV4D hJt067I5zjFIBvF8d7hdN6XqQ95SQida0h0UofK+QGvKQdXEwFiQAfiDRa97hU5m MaPsTrsOexUTryXGBq1hrgy4T2yftr9T6jiIdC1kvALqkMMWXXWLnR4HFamHcOfu xfMvJ4WWXoTuusXVVKvh7wW8Q++1rc6uC96q97KE+w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=mgXI5g gbPkOWf4cWiD69ev9BGwIwTwoUyCxumyoEf8o=; b=GrnP4CtWymVHcad+ckJdPY k1rwTY+AQz5H7q/UtNWePha2F3EIA6mxxnnCZxXfmKOOzeewohgMVBDnwoJ10Lqv kuAoezVr43n7st+Xtt5k/UmBflI+Du9b9vtomRQgXWK0MZyW3cp6UTRTPYtxczFX 9sB0sRYo1tfveyp9KLHOracG8Wr65kr4idxXCgGkdwIQjaeM8KrC03f4GlRVvaYY PwanXfuhfemHUGAfYjq0lJFsX+nV02SmKLIerIOUs1MVa7woyEmJFMoNaOnQ8OWt G3pEeC7I/vm0hrWtQI3VJQRl6w10YSzi+eRLqQ2oXDIn/Ct08l8rnSinrkmoJ77w == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrjedtgdehjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofi gvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0D37C7C6D9; Thu, 2 May 2019 22:14:18 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-449-gfb3fc5a-fmstable-20190430v1 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20190503010413.1B044B81E0A@rfc-editor.org> <1079aa6b-7f8d-4855-aac6-d5ea99f07ee7@www.fastmail.com> Date: Thu, 02 May 2019 22:14:20 -0400 From: "Martin Thomson" To: "'Eric Rescorla'" Cc: "" Content-Type: text/plain Archived-At: Subject: Re: [TLS] [Editorial Errata Reported] RFC8446 (5717) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 02:14:21 -0000 On Fri, May 3, 2019, at 12:12, Eric Rescorla wrote: > MT: why do you not think "confirmed"? It seems like we use HFDU for this sort of thing and it's not like it's strictly *wrong* here. From nobody Fri May 3 05:50:52 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6DF51200F7 for ; Fri, 3 May 2019 05:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osHSzzqwVL12 for ; Fri, 3 May 2019 05:50:48 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B32871200B9 for ; Fri, 3 May 2019 05:50:48 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2D0FDC0AF7A3; Fri, 3 May 2019 12:50:48 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.83]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4FC2D50A8B; Fri, 3 May 2019 12:50:47 +0000 (UTC) From: Hubert Kario To: tls@ietf.org, mrex@sap.com Date: Fri, 03 May 2019 14:50:46 +0200 Message-ID: <5441930.X76MtM1CnQ@pintsize.usersys.redhat.com> In-Reply-To: <20190430234952.21F5C404C@ld9781.wdf.sap.corp> References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <7d37f7ca-e253-4c95-9cf7-2d16b0b6a0aa@www.fastmail.com> <20190430234952.21F5C404C@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart15431965.e0pMHQ4D0Y"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Fri, 03 May 2019 12:50:48 +0000 (UTC) Archived-At: Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 12:50:51 -0000 --nextPart15431965.e0pMHQ4D0Y Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Wednesday, 1 May 2019 01:49:52 CEST Martin Rex wrote: > Martin Thomson wrote: > > On Sat, Apr 27, 2019, at 07:29, Viktor Dukhovni wrote: > >> The sound-bite version is: first raise the ceiling, *then* the floor. > >=20 > > Yep. We've done the ceiling bit twice now. > > Once in 2008 when we published TLS 1.2 and then in 2018 > > with the publication of TLS 1.3. I'd say we're overdue for the floor b= it. >=20 > Just that this rationale is a blatant lie. >=20 > It is formally provable that from the three protocol versions: >=20 > TLSv1.0, TLSv1.1, TLSv1.2 >=20 > the weakest one is TLSv1.2, because of the royally stupid downgrade > in the strength of digitally signed. >=20 >=20 > Disabling TLSv1.0 will only result in lots of interop failures > and pain, but no improvement in security. We've been over this Martin, the theoretical research shows that for Merkle- Damg=C3=A5rd functions, combining them doesn't increase their security=20 significantly. And the practical research: https://eprint.iacr.org/2016/131.pdf https://www.iacr.org/archive/asiacrypt2009/59120136/59120136.pdf only confirms that. So, please, use a bit less inflammatory language when you have no factual=20 arguments behind your assertions. =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart15431965.e0pMHQ4D0Y Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAlzMOSYACgkQkqjRuAHS 9fXEShAAgwEkuTgSsVf79WcCH1WgIrRZE2xmLCne/nkjNQzpLxQuWxZEjfov3WjA siUQmgoPdYJZDMkLOiEXYXM3ruySIyo4APQTuNen3+Nh3qdiRYhxLaM39rvutRQ8 +rvnCwOnsAQ0QjsAEp3kHcWHE8QJv3eOUeO8EMJmHxz38yczkOAIFGJE9hzXOBYJ IztWu2Nfwm3FYtFhPzcJZqlFS+fpi4fUcSuvn0iQmITfHUXRC40UL7+ZQoWccUH0 rdFIA+oCtR8fUoNCJhXSz/exj5THaSQnVVLzGFUm5XMo9jZCjA+4vabevFCzTv14 Ve1v6UqzaKP/s7Ve84tZG0Ic9eifwyIfVzHwbHIsh2Fv/GT9ra1Y/Z7B8wy0QtVF HAIRyIwqVz2nh4/E+/2l5XZIN30EXDhGjmwDF3wJIaYbLZyiAuvVZ03iz5PCuRoe 3jbV3PsHg3k5tpMxqDny9aAjPZ2RcIuhA73LuqJrhEJmmU3SWdFzOBnU6vQgcNxr Ky8iGClBCHQr312IUbOdnadUU5pgUDtkwQjUgFEUuG30E/J1t6MUxmskiyCK1XeQ nbEusGLIFi+n+ZVyM0vBbJlER7IbRHcVmMvabCfAwbQsD4N/5bQ0TBWFaEG8WA6x 7oBtppdKd8UJ1qsgdNREfdWrcLyv4h8suZByS/8Eajf2tdZUNP4= =//GX -----END PGP SIGNATURE----- --nextPart15431965.e0pMHQ4D0Y-- From nobody Fri May 3 07:03:38 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C466D1200CD for ; Fri, 3 May 2019 07:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9hajHFox-T3S for ; Fri, 3 May 2019 07:03:35 -0700 (PDT) Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B299812002F for ; Fri, 3 May 2019 07:03:35 -0700 (PDT) Received: by mail-oi1-x232.google.com with SMTP id t70so4492224oif.5 for ; Fri, 03 May 2019 07:03:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=copfu2SMO4qRMMmgRez2SQvK420uvhUp3WV/e/P8YG0=; b=fy69YL01TG4Iv/B3kfPvtlhGCUxG1TwtveW3uC23miTCkHsefw4BMtkLI2bWKgGHRf uCoLca6ROV4ySAG1UZhszgpEfJ4kEuwOnkiTk4wyHw1yl22RcxrNcN/u0AxhOnMS1+pk JrdKJMpzCXy8FmEa6GJq18UlvU+xVHKwPQPd0I3BgSPE4M8F7kOOyGKW/8jVYkBa3n7J 89M4m1GlAJv2xRYnJHo3wSZMgd3bOL/4fEJASVfOohW7ckj/4Xm/ulQzrYkT1k0vu6X2 EI7hzrdir0DwWOGN5rsiw1LEcbobZJXtbcE2bzl0UrWDOPNZcLmbv+9ns9cHVqS3Ed7q 75qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=copfu2SMO4qRMMmgRez2SQvK420uvhUp3WV/e/P8YG0=; b=N2HO0MQQBFkcXRR1GAmKrpil3BjMgI3zSujsH/SiXl7++vPyYlAGSYEXTxKqilm6HU gEd96zW58ESQrtDyp8QCNcZKhQt7Bb7XAe/6z1SrWLHMEO2E5p6kMUsZqcUIiugkLID9 9K/+Nwus/rJ6YCqEKvYL7qCWo+cSqSlp0mil0kuzciuEmzAMNoZb3Tpf4TJiE+qOepgr zMfVtEWCJ7IYAITAKkqgUFsVDKsHsCd3a3xxUm3pgMVKS6L53PmjYKNbqqpM4wa+VD0R d0+4QsiQmwmsdj6AQIisXp4iAAnUR7+QFDHzJYjUkpTp3BHnh2L+gDoT+wImuVXMsuaq ziKQ== X-Gm-Message-State: APjAAAWHANLTqIBvMg/4ugbO0Xm46gNbnY1yjayhTe9iUjyahnwHgKin o7PCQGZ8DhkjgoNc9jxhhsCHMDcV4o33RJCWqJm+RGj2 X-Google-Smtp-Source: APXvYqyDdCn6Klq8vdQn2ED6h+8WBT/0xyruJ9PhBQThHPkszmmeFnOkPbASK8Nnn0bOho0sEao4ud5fbUuz0Sp5a/M= X-Received: by 2002:aca:5a07:: with SMTP id o7mr5981434oib.114.1556892214855; Fri, 03 May 2019 07:03:34 -0700 (PDT) MIME-Version: 1.0 References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <4d34a22a-3d77-4fe8-9c8e-e2128a7a80f8@www.fastmail.com> In-Reply-To: From: Kathleen Moriarty Date: Fri, 3 May 2019 10:02:57 -0400 Message-ID: To: Martin Thomson Cc: "" Content-Type: multipart/alternative; boundary="0000000000006b9bcf0587fc370d" Archived-At: Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 14:03:38 -0000 --0000000000006b9bcf0587fc370d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, May 2, 2019 at 7:51 PM Martin Thomson wrote: > Thanks Kathleen, these look like good changes. > > Nits in the proposed BCP195 section: Lose the "p" in mpost and s/off of/o= n/ > Thank you, Martin! > > On Fri, May 3, 2019, at 01:12, Kathleen Moriarty wrote: > > Thank you for your feedback in this review. Responses inline as to how > > I propose it is addressed: > > > > On Sat, Apr 13, 2019 at 12:16 AM Martin Thomson > wrote: > > > Section 1.1 doesn't say *how* those listed documents are updated. > Might pay to include a few works on how. > > > > Thank you, that was helpful feedback. I changed the introduction text > > as follows: > > OLD: > > This document updates these RFCs that normatively reference TLSv1.0 or > > TLSv1.1 or DTLS1.0 and have not been obsoleted. > > NEW: > > This document updates the following RFCs that normatively reference > > TLSv1.0 or TLSv1.1 or DTLS1.0. The update is to obsolete usage of these > > older versions. Fallback to these versions are prohibited through this > > update. > > > > > Section 2 can be cut down a lot. The quote from another document is > longer than the rest of the text. In many ways, saying that the IETF is > moving last is not a great thing to memorialize in RFC, as much as it is > useful in an Internet-Draft or in argumentation in support of publication > of the doc. > > > > A bunch has been cut out already, but I propose also cutting out the > > following text to address your specific point (well taken): > > 1st paragraph and last 2. > > > > REMOVE: > > Industry has actively followed guidance provided by NIST and the PCI > > Council to deprecate TLSv1.0 and TLSv1.1 by June 30, 2018. TLSv1.2 > > should remain a minimum baseline for TLS support at this time. > > > > The Canadian government treasury board have also mandated that these > > old versions of TLS not be used. > > > > Various companies and web sites have announced plans to deprecate > > these old versions of TLS. > > > > > > > The title of Section 3 could be a bit clearer. > > Proposed: > > SHA-1 Usage Problematic in TLSv1.0 and TLSv1.1 > > > > If you have a more terse suggestion, please post. I agree this should > > be more clear. > > > > > > It might pay to explain what RFC 7525 is in Section 6. Why does that > document warrant special attention over the 70-odd other ones. > > > > Good point, how about the following text: > > > > PROPOSED: > > RFC7525 is BCP195, "Recommendations for Secure Use of Transport Layer > > Security (TLS) and Datagram Transport Layer Security (DTLS)", is the > > mpost recent best practice document for implementing TLS and was based > > off of TLSv1.2. At the time of publication, TLSv1.0 and TLSv1.1 had not > > yet been deprecated. As such, this document is called out specifically > > to update text implementing the deprecation recommendations of this > > document. > > > > > > > > Otherwise, publish this. > > > > Thank you! > > > > I'll continue through the rest of the messages, but may have a delay > > when tending to other responsibilities. > > I am putting the proposals into a new version to upload to the git > > repository. > > > > Best regards, > > Kathleen > > > > > > > > > > > > > > On Sat, Apr 13, 2019, at 09:28, Christopher Wood wrote: > > > > This is the working group last call for the "Deprecating TLSv1.0 > and > > > > TLSv1.1=E2=80=9D draft available at: > > > > > > > > > https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/ > > > > > > > > Please review the document and send your comments to the list by > April 26, 2019. > > > > > > > > Thanks, > > > > Chris, Joe, and Sean > > > > > > > > _______________________________________________ > > > > TLS mailing list > > > > TLS@ietf.org > > > > https://www.ietf.org/mailman/listinfo/tls > > > > > > > > > > _______________________________________________ > > > TLS mailing list > > > TLS@ietf.org > > > https://www.ietf.org/mailman/listinfo/tls > > > > > > -- > > > > Best regards, > > Kathleen > --=20 Best regards, Kathleen --0000000000006b9bcf0587fc370d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, May 2, 2019 at 7:51 PM Martin= Thomson <mt@lowentropy.net>= wrote:
Thanks K= athleen, these look like good changes.=C2=A0 =C2=A0

Nits in the proposed BCP195 section: Lose the "p" in mpost and s/= off of/on/

Thank you, Martin!
=C2=A0

On Fri, May 3, 2019, at 01:12, Kathleen Moriarty wrote:
> Thank you for your feedback in this review. Responses inline as to how=
> I propose it is addressed:
>
> On Sat, Apr 13, 2019 at 12:16 AM Martin Thomson <mt@lowentropy.net> wrote:
> > Section 1.1 doesn't say *how* those listed documents are upda= ted. Might pay to include a few works on how.
>
> Thank you, that was helpful feedback. I changed the introduction text =
> as follows:
> OLD:
> This document updates these RFCs that normatively reference TLSv1.0 or=
> TLSv1.1 or DTLS1.0 and have not been obsoleted.
> NEW:
>=C2=A0 This document updates the following RFCs that normatively refere= nce
> TLSv1.0 or TLSv1.1 or DTLS1.0. The update is to obsolete usage of thes= e
> older versions. Fallback to these versions are prohibited through this=
> update.
>
> >=C2=A0 Section 2 can be cut down a lot. The quote from another doc= ument is longer than the rest of the text. In many ways, saying that the IE= TF is moving last is not a great thing to memorialize in RFC, as much as it= is useful in an Internet-Draft or in argumentation in support of publicati= on of the doc.
>
> A bunch has been cut out already, but I propose also cutting out the <= br> > following text to address your specific point (well taken):
> 1st paragraph and last 2.
>
> REMOVE:
>=C2=A0 Industry has actively followed guidance provided by NIST and the= PCI
>=C2=A0 Council to deprecate TLSv1.0 and TLSv1.1 by June 30, 2018. TLSv1= .2
>=C2=A0 should remain a minimum baseline for TLS support at this time. >
>=C2=A0 The Canadian government treasury board have also mandated that t= hese
>=C2=A0 old versions of TLS not be used.
>
>=C2=A0 Various companies and web sites have announced plans to deprecat= e
>=C2=A0 these old versions of TLS.
>
>
> >=C2=A0 The title of Section 3 could be a bit clearer.
> Proposed:
> SHA-1 Usage Problematic in TLSv1.0 and TLSv1.1
>
> If you have a more terse suggestion, please post. I agree this should =
> be more clear.
> >
> >=C2=A0 It might pay to explain what RFC 7525 is in Section 6. Why = does that document warrant special attention over the 70-odd other ones. >
> Good point, how about the following text:
>
> PROPOSED:
> RFC7525 is BCP195, "Recommendations for Secure Use of Transport L= ayer
> Security (TLS) and Datagram Transport Layer Security (DTLS)", is = the
> mpost recent best practice document for implementing TLS and was based=
> off of TLSv1.2. At the time of publication, TLSv1.0 and TLSv1.1 had no= t
> yet been deprecated. As such, this document is called out specifically=
> to update text implementing the deprecation recommendations of this > document.
>
> >
> >=C2=A0 Otherwise, publish this.
>
> Thank you!
>
> I'll continue through the rest of the messages, but may have a del= ay
> when tending to other responsibilities.
> I am putting the proposals into a new version to upload to the git > repository.
>
> Best regards,
> Kathleen
>
> >
> >
> >
> >=C2=A0 On Sat, Apr 13, 2019, at 09:28, Christopher Wood wrote:
> >=C2=A0 > This is the working group last call for the "Depr= ecating TLSv1.0 and
> >=C2=A0 > TLSv1.1=E2=80=9D draft available at:
> >=C2=A0 >
> >=C2=A0 > https://d= atatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/
> >=C2=A0 >
> >=C2=A0 > Please review the document and send your comments to t= he list by April 26, 2019.
> >=C2=A0 >
> >=C2=A0 > Thanks,
> >=C2=A0 > Chris, Joe, and Sean
> >=C2=A0 >
> >=C2=A0 > _______________________________________________
> >=C2=A0 > TLS mailing list
> >=C2=A0 > TLS@= ietf.org
> >=C2=A0 > https://www.ietf.org/mailman/listinfo/= tls
> >=C2=A0 >
> >
> >=C2=A0 _______________________________________________
> >=C2=A0 TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
>
>
> --
>
> Best regards,
> Kathleen


--

Best regards,
Kathleen
--0000000000006b9bcf0587fc370d-- From nobody Fri May 3 07:57:00 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64BAC12029E for ; Fri, 3 May 2019 07:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cCeufGSJrncv for ; Fri, 3 May 2019 07:56:57 -0700 (PDT) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C76D12028A for ; Fri, 3 May 2019 07:56:57 -0700 (PDT) Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 44wZwR1KJHzykF; Fri, 3 May 2019 16:56:55 +0200 (CEST) X-purgate-ID: 152705::1556895415-0000020D-EA97DC8F/0/0 X-purgate-size: 939 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail07.wdf.sap.corp (Postfix) with ESMTPS id 44wZwQ5ZK5zGp2R; Fri, 3 May 2019 16:56:54 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id B6421404C; Fri, 3 May 2019 16:56:54 +0200 (CEST) In-Reply-To: <5441930.X76MtM1CnQ@pintsize.usersys.redhat.com> References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <7d37f7ca-e253-4c95-9cf7-2d16b0b6a0aa@www.fastmail.com> <20190430234952.21F5C404C@ld9781.wdf.sap.corp> <5441930.X76MtM1CnQ@pintsize.usersys.redhat.com> To: Hubert Kario Date: Fri, 3 May 2019 16:56:54 +0200 (CEST) CC: tls@ietf.org, mrex@sap.com, Martin Thomson Reply-To: mrex@sap.com MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" Message-Id: <20190503145654.B6421404C@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 14:56:59 -0000 Hubert Kario wrote: >=20 > We've been over this Martin, the theoretical research shows that for Merk= le- > Damg=E5rd functions, combining them doesn't increase their security=20 > significantly. You are completely misunderstanding the results. The security is greatly increased! Nobody is afraid of the exhaustive search preimage attacks. What folks with a little crypto clue are afraid of is significantly-faster-than-exhaustive-search real-time preimage attacks. And this is where TLSv1.0 + TLSv1.1 (rsa,SHA1+MD5) is *significantly* stronger than TLSv1.2 (rsa,MD5) *cough* -- which a depressingly high number of clueless implementers actually implemented, see SLOTH TLSv1.2 (rsa,SHA1) That is also trivially formally provable. Assume that a real-time preimage attack for *one* of the functions is discovered, and compare the resulting efforts. =20 -Martin From nobody Fri May 3 08:23:41 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21361120103 for ; Fri, 3 May 2019 08:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwBUyrAIdTo6 for ; Fri, 3 May 2019 08:23:36 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DFD1120114 for ; Fri, 3 May 2019 08:23:35 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E089530DBC2F; Fri, 3 May 2019 15:23:34 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.83]) by smtp.corp.redhat.com (Postfix) with ESMTP id 2268A5D967; Fri, 3 May 2019 15:23:33 +0000 (UTC) From: Hubert Kario To: mrex@sap.com Cc: tls@ietf.org, Martin Thomson Date: Fri, 03 May 2019 17:23:28 +0200 Message-ID: <2000542.anm9dvXMO9@pintsize.usersys.redhat.com> In-Reply-To: <20190503145654.B6421404C@ld9781.wdf.sap.corp> References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <5441930.X76MtM1CnQ@pintsize.usersys.redhat.com> <20190503145654.B6421404C@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4092880.ByyheKsWbP"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.46]); Fri, 03 May 2019 15:23:34 +0000 (UTC) Archived-At: Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 15:23:39 -0000 --nextPart4092880.ByyheKsWbP Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Friday, 3 May 2019 16:56:54 CEST Martin Rex wrote: > Hubert Kario wrote: > > We've been over this Martin, the theoretical research shows that for > > Merkle- Damg=C3=A5rd functions, combining them doesn't increase their s= ecurity > > significantly. >=20 > You are completely misunderstanding the results. >=20 > The security is greatly increased! >=20 > Nobody is afraid of the exhaustive search preimage attacks. >=20 > What folks with a little crypto clue are afraid of is > significantly-faster-than-exhaustive-search real-time preimage attacks. > And this is where >=20 > TLSv1.0 + TLSv1.1 (rsa,SHA1+MD5) >=20 > is *significantly* stronger than >=20 > TLSv1.2 (rsa,MD5) *cough* -- which a depressingly high number of cluele= ss > implementers actually implemented, see SLOTH > TLSv1.2 (rsa,SHA1) >=20 >=20 > That is also trivially formally provable. I'm eagerly waiting on your published paper on the topic. =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart4092880.ByyheKsWbP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAlzMXPAACgkQkqjRuAHS 9fVh1w/+OFUwNAVdWKmkYEcsajfeKGLp7egtKD7BbIKO9rxbR13W63vFLvtQhkLK JuhqdnftVH+HWwRmdz+AbdOjRZjTVF4b7fw1V2OLVFh344Etn6RM9qsiz+zqV1wj 2Z/2WJpIyseWHSEfy+5A1eMmy8EB81MuaJFU/grCTt8uS34YU/YqPeXAOG9Y40lM o3ZTLaokdeC8NIOqzrmEI74EZIuXsxdyWSwpgBarvqCT9MAOrwhKDIIZUrx1ou23 2WYXw6aef+oHMFiOLAu6EJhVcUSQyHZeERxNM+gsVlOsEq6EoG+CKREXICuv/J4M hZl3vNQnon4ZnPDWzl4ElIIC5ENkvc25oFlEYO7JanzEOrU2kr6/8dmU0dLhGm8Y AX9R/MSHnR2zm991qROkQZQ4IZoedG+PCYpbfv4KLKg4aKujCC/ejKaCNNIed/Yr WziNtOzlRByS1VG/u6E0mMkq1u39trla/RQrO59ki4reWMCj2VBMh8DQ2RPvY7bf S4XKAFS5Dh80TZEsThLk6flfHQ6gNt2u0YwCWSB2r3crEs8Wf6mBo8M0sm6IlVSc Z5O0CkPSgYAudFlecQXONArRanmodjXAihE9ISpDmegVdjH9vjjobcMfmfLh4j/H g8Lzd0UwG66yyILYRCnm2UbvSxESPJmCGfkHmGIc9q7SBp/GFXI= =7i2t -----END PGP SIGNATURE----- --nextPart4092880.ByyheKsWbP-- From reiher@componolit.com Fri May 3 05:43:34 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B39212015D for ; Fri, 3 May 2019 05:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9H74_q7ifyRp for ; Fri, 3 May 2019 05:43:33 -0700 (PDT) Received: from mail.kofje.de (mail.kofje.de [87.106.138.10]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F0851200B7 for ; Fri, 3 May 2019 05:43:32 -0700 (PDT) Received: from [192.168.188.31] (ip-81-201-155-53.static.reverse.dsi.net [81.201.155.53]) by mail.kofje.de (Postfix) with ESMTPSA id 345A911280BC; Fri, 3 May 2019 14:43:30 +0200 (CEST) From: Tobias Reiher Openpgp: preference=signencrypt Autocrypt: addr=reiher@componolit.com; prefer-encrypt=mutual; keydata= mDMEW+WgCxYJKwYBBAHaRw8BAQdACZ7HEcKNFROJA/GJfwepYDJreIYQ/uqelk6uvNsWm9u0 JVRvYmlhcyBSZWloZXIgPHJlaWhlckBjb21wb25vbGl0LmNvbT6IlgQTFggAPhYhBJAYjDCm DClnhPomtThH+WcLNQ9HBQJb5aALAhsDBQkB4TOABQsJCAcCBhUKCQgLAgQWAgMBAh4BAheA AAoJEDhH+WcLNQ9H74ABAJ9oIrtAoRhTCgTmazKrLzyvpvTlzzdckfSVkmKxd95SAP0VrQEp pKCv5xF4Z1RzlT2YhjzQET1u8SCT2ceAM7sZDLg4BFvloAsSCisGAQQBl1UBBQEBB0Aw4YPO tmpsBilwlanzRVNM4QwQPE9EJr4Hct8TyqqAQAMBCAeIfgQYFggAJhYhBJAYjDCmDClnhPom tThH+WcLNQ9HBQJb5aALAhsMBQkB4TOAAAoJEDhH+WcLNQ9HmpUA/3K/AI0PkWgRAjzy3bpq Yod59Q+gLUaMLdJEyYiHyasAAP9sLYaJdiWm6o43UNGMgZIClyOQ7aViMxqFW7fsumSvCw== Organization: Componolit GmbH To: tls@ietf.org Cc: senier@componolit.com Message-ID: <1f5befb5-0338-1135-1acf-31d06470d572@componolit.com> Date: Fri, 3 May 2019 14:43:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Fri, 03 May 2019 08:35:27 -0700 Subject: [TLS] Deprecated signature algorithms in RFC8446 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 12:55:35 -0000 Hi, the example handshake traces for TLS 1.3 (RFC8448) seems not to fully comply to the TLS 1.3 standard (RFC8446). RFC8446 in 4.2.3. says that an implementation must not offer deprecated algorithms in the signature algorithms extension: "In TLS 1.2, the extension contained hash/signature pairs. The pairs are encoded in two octets, so SignatureScheme values have been allocated to align with TLS 1.2's encoding. Some legacy pairs are left unallocated. These algorithms are deprecated as of TLS 1.3. They MUST NOT be offered or negotiated by any implementation. In particular, MD5 [SLOTH], SHA-224, and DSA MUST NOT be used." RFC8448 shows in 3. an example with a ClientHello message containing a signature algorithms extension with the deprecated algorithms 0x0402, 0x0502, 0x0602, and 0x0202, which all refer to the DSA algorithm, which must not be used with TLS 1.3. Best regards, Tobias Reiher -- Componolit GmbH · Königsbrücker Straße 124 · 01099 Dresden · Germany Amtsgericht Dresden · HRB 36670 · Sitz Dresden Geschäftsführer: Alexander Senier · USt-IdNr. (EU VATIN): DE312113634 http://componolit.com · @Componolit From nobody Fri May 3 09:53:58 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 104B8120272 for ; Fri, 3 May 2019 09:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fS1zeFKOQH8R for ; Fri, 3 May 2019 09:53:49 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD3BF1201A0 for ; Fri, 3 May 2019 09:53:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1556902429; x=1588438429; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=vH6HlI+64eC1Xx4OeaEhRh0sCx+aIrv9pKMzFgk+/Zo=; b=h9lXRcmHWeTE/sFiWeXE9p5nqaQ9beaU2jgDsIu29lGIc2+LBR4fvxzC aSxuelm7WQCtw7DCVhpX+8Ianu6wVgEuGwmcZmtcNTo4GtIOgh37VE7uJ oxxstnAMCKQ7GimCCE1CMr1VSxpFh0zI6DY2zgQvrtmr9/voBoSiXwIxt y+wN7DNvAMzJp/+nYB2lT4aBg7SbxNzbnflnsyPfj35qThkt1+8P8r0Jj +BcprrfQyYOzD0DHchxdMDXMNLdShOkfA007w6mOkYL7eXjOamRJgUCWR E4B18X7kvyvuYCN8js5QVVfcb3370zXi6ynV6s4lt7WnlGFGj0wGAw96w w==; X-IronPort-AV: E=Sophos;i="5.60,426,1549882800"; d="scan'208";a="60188578" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.8 - Outgoing - Outgoing Received: from uxcn13-ogg-e.uoa.auckland.ac.nz ([10.6.2.8]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 04 May 2019 04:53:45 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-e.UoA.auckland.ac.nz (10.6.2.8) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 4 May 2019 04:53:45 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Sat, 4 May 2019 04:53:45 +1200 From: Peter Gutmann To: Hubert Kario , "tls@ietf.org" , "mrex@sap.com" Thread-Topic: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" Thread-Index: AQHU+8+QtjVLqWiyz0WqN1BpourjtKZM43YAgADkD4CAAGW4gIADRbgAgAMrEACAA/7YAIABDIIe Date: Fri, 3 May 2019 16:53:44 +0000 Message-ID: <1556902416424.28526@cs.auckland.ac.nz> References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <7d37f7ca-e253-4c95-9cf7-2d16b0b6a0aa@www.fastmail.com> <20190430234952.21F5C404C@ld9781.wdf.sap.corp>, <5441930.X76MtM1CnQ@pintsize.usersys.redhat.com> In-Reply-To: <5441930.X76MtM1CnQ@pintsize.usersys.redhat.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 16:53:52 -0000 Hubert Kario writes:=0A= =0A= >And the practical research:=0A= >https://eprint.iacr.org/2016/131.pdf=0A= >https://www.iacr.org/archive/asiacrypt2009/59120136/59120136.pdf=0A= >only confirms that.=0A= =0A= That would be the practical research that says:=0A= =0A= Due to these constraints, the practical impact of our second preimage att= ack=0A= is limited and its main significance is theoretical.=0A= =0A= This is obviously some strange use of the word "practical" that I wasn't=0A= previously aware of.=0A= =0A= The other one is a bit too vague to comment on:=0A= =0A= would lead to an attack on the combiner MD5 || SHA-1 with complexity less= =0A= than 2^59 (assuming the type 1 collision attack on SHA-1 is fast enough).= =0A= =0A= "assuming" and "fast enough" could mean anything ("this leads to an attack = on=0A= AES-GCM with complexity less than 2^59 assuming the key recovery attack on= =0A= AES-128 is fast enough"). However earlier on the paper says:=0A= =0A= Let=92s further assume that a breakthrough in cryptanalysis of SHA-1 brin= gs=0A= down the complexity of a collision search attack to 2^52. We know that th= e=0A= best collision search attacks on MD5 are as fast as 2^15=0A= =0A= So what's being shown is that the strength is 2^59 assuming some unspecifie= d=0A= but pretty spectacular new attack on SHA-1 suddenly turns up, rather than e= .g.=0A= 2^(52+15) =3D 2^67.=0A= =0A= Even with the appearance of this imaginary new attack, the security of=0A= MD5||SHA1 is still better than either MD5 or SHA-1 by itself, which is what= =0A= TLS 1.2 specifies. So I think Martin's point is proven.=0A= =0A= Peter.= From nobody Fri May 3 10:20:44 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22DE91202FD for ; Fri, 3 May 2019 10:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.339 X-Spam-Level: X-Spam-Status: No, score=-1.339 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=1.363, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjP3zfGgwBWT for ; Fri, 3 May 2019 10:20:41 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A9011202F8 for ; Fri, 3 May 2019 10:20:41 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.27/8.16.0.27) with SMTP id x43HCqM6009198; Fri, 3 May 2019 18:20:27 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : content-transfer-encoding : in-reply-to; s=jan2016.eng; bh=qvA2GQCwrJrPbUVzbAaE8/XEN8NhKGCk124du96x/40=; b=NdYkMnPrMVZ9R8NYnxWQrcGNOStDdWUKDHofCcwW5ycqq8kGf4PrQOY5KBY4YWv43wZp 3IsjFOj3MH8spn3GX5QAzUvW8skIusMpPwKYw4zsqxt8WfVMdRgLt33sxTNqult2Pff5 nF/qNH4azZWj3GcjZAy/tdVi+o5gvAdS+KU0oQjSiblZcX36+GZZLGGXNxl+SmU88Zbz UvcGjTQKtP1syIvDACQHPvpXRKzt97wbCNLhaLc2dGmgVCuAw0OgaSyQlys/BI4RGWrm Ul5bwOV/9VhxkjHk6Eb4hNNfLk5D1/+UN43bHDsgd6nI4APfag5lwGTHEgyobJ27nUSO 9Q== Received: from prod-mail-ppoint4 (prod-mail-ppoint4.akamai.com [96.6.114.87] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2s8p13rqxg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 03 May 2019 18:20:26 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x43HJwcN028129; Fri, 3 May 2019 13:20:25 -0400 Received: from prod-mail-relay11.akamai.com ([172.27.118.250]) by prod-mail-ppoint4.akamai.com with ESMTP id 2s4jdxy6v9-1; Fri, 03 May 2019 13:20:25 -0400 Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 17B231FC6B; Fri, 3 May 2019 17:20:24 +0000 (GMT) Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from ) id 1hMbrD-0006jo-6m; Fri, 03 May 2019 12:20:23 -0500 Date: Fri, 3 May 2019 12:20:22 -0500 From: Benjamin Kaduk To: Peter Gutmann Cc: Hubert Kario , "tls@ietf.org" , "mrex@sap.com" Message-ID: <20190503172022.GH4464@akamai.com> References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <7d37f7ca-e253-4c95-9cf7-2d16b0b6a0aa@www.fastmail.com> <20190430234952.21F5C404C@ld9781.wdf.sap.corp> <5441930.X76MtM1CnQ@pintsize.usersys.redhat.com> <1556902416424.28526@cs.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1556902416424.28526@cs.auckland.ac.nz> User-Agent: Mutt/1.5.24 (2015-08-30) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-03_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905030111 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-03_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905030111 Archived-At: Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 17:20:43 -0000 On Fri, May 03, 2019 at 04:53:44PM +0000, Peter Gutmann wrote: > Hubert Kario writes: > > >And the practical research: > >https://eprint.iacr.org/2016/131.pdf > >https://www.iacr.org/archive/asiacrypt2009/59120136/59120136.pdf > >only confirms that. > > That would be the practical research that says: > > Due to these constraints, the practical impact of our second preimage attack > is limited and its main significance is theoretical. > > This is obviously some strange use of the word "practical" that I wasn't > previously aware of. > > The other one is a bit too vague to comment on: > > would lead to an attack on the combiner MD5 || SHA-1 with complexity less > than 2^59 (assuming the type 1 collision attack on SHA-1 is fast enough). > > "assuming" and "fast enough" could mean anything ("this leads to an attack on > AES-GCM with complexity less than 2^59 assuming the key recovery attack on > AES-128 is fast enough"). However earlier on the paper says: > > Let’s further assume that a breakthrough in cryptanalysis of SHA-1 brings > down the complexity of a collision search attack to 2^52. We know that the > best collision search attacks on MD5 are as fast as 2^15 > > So what's being shown is that the strength is 2^59 assuming some unspecified > but pretty spectacular new attack on SHA-1 suddenly turns up, rather than e..g. > 2^(52+15) = 2^67. > > Even with the appearance of this imaginary new attack, the security of > MD5||SHA1 is still better than either MD5 or SHA-1 by itself, which is what > TLS 1.2 specifies. So I think Martin's point is proven. I'll make the obligatory note that SHA-2 is fine, and if you decide that neither MD5 nor SHA1 are in great shape and decide to not use them at all (whether along or in combination), you are also doing fine. It's not like publishing another RFC is going to magically change the behavior of the already deployed systems that people are currently using these things with, after all, and if someone does change their system, are really going to recommend they go to TLS 1.0 with MD5||SHA1 rather than TLS 1.2 with SHA2? -Ben From nobody Fri May 3 10:30:48 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 037B11202D0 for ; Fri, 3 May 2019 10:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRzpWyo9-2rA for ; Fri, 3 May 2019 10:30:45 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA42B1202C9 for ; Fri, 3 May 2019 10:30:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1556904645; x=1588440645; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=FktJ5CKG1hb4l3jmBZWxB2ow8YQ7N59w78OvKzXt3ao=; b=BgHsETv3KuHcn0a9q5RwNpfbhc9fM2eVSsHRe9uQy2TZDQmIwKznbcZW JbuxgDrAsMEj0hpZQ7w1f72d+1CiWQxcT/Imauuga6/M+qBq8gxfimCsC F8HZ/wg2N/rdaPwpVL0WRI1nPa6bvLA8cXcPzzhlVHSLzCM/4rZb0kN8X eGOS1RDQW2VKtuK8AXPpae5TGdze3439911Wb6DbYCqE1AYw8RZRG4sID FFn5Uc7h5tbC6alE+54RlPQ9BQtv68VwnQaA+bDNNCo7gbTCdKE7A3/Qz /7XzbPgma2rhtDYFkC3pMrGTMtRX5OBUHScCt30gDEl/rmTWZjeke3b4n Q==; X-IronPort-AV: E=Sophos;i="5.60,426,1549882800"; d="scan'208";a="60192461" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.3 - Outgoing - Outgoing Received: from smtp.uoa.auckland.ac.nz (HELO uxcn13-ogg-b.UoA.auckland.ac.nz) ([10.6.2.3]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 04 May 2019 05:30:39 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-b.UoA.auckland.ac.nz (10.6.2.3) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 4 May 2019 05:30:39 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Sat, 4 May 2019 05:30:38 +1200 From: Peter Gutmann To: Benjamin Kaduk CC: Hubert Kario , "tls@ietf.org" , "mrex@sap.com" Thread-Topic: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" Thread-Index: AQHU+8+QtjVLqWiyz0WqN1BpourjtKZM43YAgADkD4CAAGW4gIADRbgAgAMrEACAA/7YAIABDIIe//8+0QCAAMtvyg== Date: Fri, 3 May 2019 17:30:38 +0000 Message-ID: <1556904629782.23087@cs.auckland.ac.nz> References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <7d37f7ca-e253-4c95-9cf7-2d16b0b6a0aa@www.fastmail.com> <20190430234952.21F5C404C@ld9781.wdf.sap.corp> <5441930.X76MtM1CnQ@pintsize.usersys.redhat.com> <1556902416424.28526@cs.auckland.ac.nz>,<20190503172022.GH4464@akamai.com> In-Reply-To: <20190503172022.GH4464@akamai.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 17:30:47 -0000 Benjamin Kaduk writes:=0A= =0A= >I'll make the obligatory note that SHA-2 is fine=0A= =0A= Sure, and that was the really strange thing with TLS 1.2, why not just say= =0A= SHA-2 or better only, rather than adding mechanisms that were much, much=0A= weaker than its predecessors? So the simple fix is just to use SHA-2 only = for=0A= TLS 1.2.=0A= =0A= >if someone does change their system, are really going to recommend they go= to=0A= >TLS 1.0 with MD5||SHA1 rather than TLS 1.2 with SHA2?=0A= =0A= That would be one argument for an RFC, MUST SHA-2 only or MUST NOT MD5 and= =0A= SHA-1 in 1.2. Which is pretty much what TLS-LTS says. Or at least it take= s=0A= the SHA-2-suites-mandatory path which implies no MD5 or SHA-1, I guess I=0A= should also add an explicit MUST NOT MD5 and SHA-1.=0A= =0A= Having said that, given an RFC saying MUST NOT 1.0 and 1.1 which is what th= e=0A= original discussion was about, why not also add MUST NOT MD5 and SHA1 in TL= S=0A= 1.2 to the text?=0A= =0A= Peter.=0A= From nobody Fri May 3 10:36:44 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 632861202FC for ; Fri, 3 May 2019 10:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qj5RhrH-KhMu for ; Fri, 3 May 2019 10:36:41 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0B271202F8 for ; Fri, 3 May 2019 10:36:40 -0700 (PDT) Received: from [10.200.0.109] (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id 9FD882BA3B for ; Fri, 3 May 2019 13:36:39 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Viktor Dukhovni In-Reply-To: <1556904629782.23087@cs.auckland.ac.nz> Date: Fri, 3 May 2019 13:36:39 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: IETF TLS WG Message-Id: References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <7d37f7ca-e253-4c95-9cf7-2d16b0b6a0aa@www.fastmail.com> <20190430234952.21F5C404C@ld9781.wdf.sap.corp> <5441930.X76MtM1CnQ@pintsize.usersys.redhat.com> <1556902416424.28526@cs.auckland.ac.nz> <20190503172022.GH4464@akamai.com> <1556904629782.23087@cs.auckland.ac.nz> To: IETF TLS WG X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 17:36:43 -0000 > On May 3, 2019, at 1:30 PM, Peter Gutmann = wrote: >=20 > Having said that, given an RFC saying MUST NOT 1.0 and 1.1 which is = what the > original discussion was about, why not also add MUST NOT MD5 and SHA1 = in TLS > 1.2 to the text? And perhaps MUST EtM, ... which starts to look a lot like "must = TLS-LTS"... :-) If we really are raising the floor, just the protocol version is = ultimately only part of the story. The whole story is TLS 1.2 minus a lot of options = plus a few requirements. --=20 Viktor. From nobody Fri May 3 12:57:34 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69A1B120052 for ; Fri, 3 May 2019 12:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozhqSatWILHs for ; Fri, 3 May 2019 12:57:31 -0700 (PDT) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02EEF12016B for ; Fri, 3 May 2019 12:57:31 -0700 (PDT) Received: by mail-lf1-x12d.google.com with SMTP id o16so5214250lfl.7 for ; Fri, 03 May 2019 12:57:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ElbXEfR+QUVEOQMxVbwgUMWClbIFbhleTKeEfd8pTkk=; b=xA9TS1Qm9qJ/HHDzAxrBVbxnJo118chYtnMmr04WVhcYJIUWL8Bd9SM3vzqFj2rK7J ZnVPuQt8rCEveVUopBWF/QBNg8i64VrwhKsmAqkEsuaUmaiLn2wMtPWRh+oaUC7iXxXQ UwJOsqiCvbldyIH775AXq8NKKULbkzGDbQDIeTNiZJ5duCPm4memOmHDLLAfkr3Tf0X9 T18CYqCT31xPDiFAdR1JHt0acZMU8O8eWj1dZxCrHRMrjFDleph1zXZUcGDwt7yVjEZs 5rsiW+mWfU4sZAPwiM2jGhGtEefRH2B0xHSVs5VQG3PZlBBy+aUqREfI2L/hVT7I1v4C IiFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ElbXEfR+QUVEOQMxVbwgUMWClbIFbhleTKeEfd8pTkk=; b=JN5kx5lXj+EB1iZ0BBCbP8+Mv2rGWI0nYJo4Ww2NREAXom40uzBsG8Fjun9BGEbUnV qZ/gld1LZi1j03K0o9bVO/1y7iB+kA256ethl+iKSEyd5DvNJEIhYju6nZ0eJ89C7OmW 4DzBq9AApujd7lB1XKRX5e418MhEAAe3car68OQIj3YvSNGA6q7n1tEZtGM7yYNr/TOe TgciK4Ktm3Jc5FPNKutZrfr8Gt3SAN8ycVg6ZnIw/NoyXK457tSgll4QdLYIpG61STVL tbKnMT1xKKnpsSAQ9VgpHOX977vePDe/zw0oTQlxdtZTcYcQqH+e4YGC1y/H/b5HjI8O S1Mg== X-Gm-Message-State: APjAAAUFy7mtRLRnn0/E35gch/w+3S+1j1TIQKf4+q0WPrlb2cm3Gu0R ZryiEMb+BDZMKqYCooH0MEX3W5ehXU4EODCrBaWhyQ== X-Google-Smtp-Source: APXvYqwd+hmzM5fmJ4XO5A621st7wFoIa5KB+wQXkUX/J2VEEU9ifOmmoRNkfFZMrIvi/TUV+R3mLRGNpKYz1l5xfcg= X-Received: by 2002:ac2:4109:: with SMTP id b9mr5869207lfi.90.1556913449122; Fri, 03 May 2019 12:57:29 -0700 (PDT) MIME-Version: 1.0 References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <7d37f7ca-e253-4c95-9cf7-2d16b0b6a0aa@www.fastmail.com> <20190430234952.21F5C404C@ld9781.wdf.sap.corp> <5441930.X76MtM1CnQ@pintsize.usersys.redhat.com> <1556902416424.28526@cs.auckland.ac.nz> <20190503172022.GH4464@akamai.com> <1556904629782.23087@cs.auckland.ac.nz> In-Reply-To: <1556904629782.23087@cs.auckland.ac.nz> From: Eric Rescorla Date: Fri, 3 May 2019 12:56:50 -0700 Message-ID: To: Peter Gutmann Cc: Benjamin Kaduk , "tls@ietf.org" Content-Type: multipart/alternative; boundary="00000000000014d336058801296d" Archived-At: Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 19:57:34 -0000 --00000000000014d336058801296d Content-Type: text/plain; charset="UTF-8" On Fri, May 3, 2019 at 10:31 AM Peter Gutmann wrote: > Having said that, given an RFC saying MUST NOT 1.0 and 1.1 which is what > the > original discussion was about, why not also add MUST NOT MD5 and SHA1 in > TLS > 1.2 to the text? > This seems like a reasonable proposal. -Ekr > Peter. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --00000000000014d336058801296d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, May 3, 2019 at 10:31 AM Peter= Gutmann <pgut001@cs.auckla= nd.ac.nz> wrote:
Having said that, given an RFC saying MUST NOT 1.0 and 1.1 which is what th= e
original discussion was about, why not also add MUST NOT MD5 and SHA1 in TL= S
1.2 to the text?

This seems like a reas= onable proposal.

-Ekr


Peter.

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--00000000000014d336058801296d-- From nobody Fri May 3 13:09:22 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8896E120180 for ; Fri, 3 May 2019 13:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FjtO8oQ2hqII for ; Fri, 3 May 2019 13:09:18 -0700 (PDT) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DF36120052 for ; Fri, 3 May 2019 13:09:18 -0700 (PDT) Received: by mail-qt1-x82b.google.com with SMTP id g4so8147697qtq.10 for ; Fri, 03 May 2019 13:09:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=TbuT3Mlb0hYuueCd0INXggz0iF0IP7oXbOv/l2vWuyM=; b=ZsI2KxI3HjjzLcAXOrdEJtsCIlzchItny/r+/O37bAbOnefntVWPTXok/YfjPHGej7 jRBwS43wxxW38H9FrWKoYm8veMSLpylRkSJGSAxQb884TIbOtWwAdLfrs1tMawFmXpoY oEEYCaUKqkSYn8EAkkfacr88JYDqkCSqy7gdy+2Na94iGRjPh8Aez6ESeg7sfyIVH37f 3vo4JoW0W64ze0CEr2nFbf62IuPK0MMZjf5sLD3V4uNyVXDTUMO4Km9YvcqE+OL5d49d rnzFJ2AH6l8CUN/jK3tZ6iwo/uZgMolX+Lg5RpBkU3eXxdVUDj96gTXDVD13kWwpcd2y gJVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=TbuT3Mlb0hYuueCd0INXggz0iF0IP7oXbOv/l2vWuyM=; b=uQpr6MoGsZ+LGgR1cgwW4bwkaeqhouCYShRWP86BkoFqGg4sN5m4vLGKalv2cqcKhD ol4uJRPAMiR1EMGCg2ZpVHSa7quy7wsI0vMgMhSmK31HVTGeVzs8/d2tJCZii1qQTu70 ZLzRnOwtEq8ODhO7KfPwyrj+2nNLUXHyiKNzXRRD4be8FY8tccjhcRncUaez9lkGuQxo 6M/m00Ixz7SnTTg+5hqDEHMOgvbQIHOpuXjrXb55c7N0rzHW7VHdaMQX8hHgnx89UxjX cloCUD4uXrIdtFkM7eZtek15T/BE+uK3eIHGCCThCPiOWHd15M5qrTBWNKqN+8lJbPX0 INiA== X-Gm-Message-State: APjAAAXIO4U6Mo6G0LJp6s+9WEDiSL79cl7DXNbmrFIJqaj4DCDuVBz7 h5aqMHFzbmi/EfZ6HORz8c4oCowj1es= X-Google-Smtp-Source: APXvYqyOucwqFcPoozsyieNx+Lf2Maz6dTGcNIZCjlYh0RNWYPpivHDKCs9sYVw/lBx1M3C0I23ORg== X-Received: by 2002:a0c:b917:: with SMTP id u23mr9967399qvf.81.1556914157850; Fri, 03 May 2019 13:09:17 -0700 (PDT) Received: from [192.168.1.210] (209-6-124-146.s3472.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [209.6.124.146]) by smtp.gmail.com with ESMTPSA id p1sm1841946qkb.43.2019.05.03.13.09.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 May 2019 13:09:17 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-D1CBF52E-26A4-448E-ACCE-95D481541870 Mime-Version: 1.0 (1.0) From: Kathleen Moriarty X-Mailer: iPhone Mail (15E216) In-Reply-To: Date: Fri, 3 May 2019 16:09:16 -0400 Cc: Peter Gutmann , "tls@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: <1F7FC950-358D-4D5C-963B-B7B837AE49DA@gmail.com> References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <7d37f7ca-e253-4c95-9cf7-2d16b0b6a0aa@www.fastmail.com> <20190430234952.21F5C404C@ld9781.wdf.sap.corp> <5441930.X76MtM1CnQ@pintsize.usersys.redhat.com> <1556902416424.28526@cs.auckland.ac.nz> <20190503172022.GH4464@akamai.com> <1556904629782.23087@cs.auckland.ac.nz> To: Eric Rescorla Archived-At: Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 20:09:21 -0000 --Apple-Mail-D1CBF52E-26A4-448E-ACCE-95D481541870 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sent from my mobile device > On May 3, 2019, at 3:56 PM, Eric Rescorla wrote: >=20 >=20 >=20 >> On Fri, May 3, 2019 at 10:31 AM Peter Gutmann = wrote: >> Having said that, given an RFC saying MUST NOT 1.0 and 1.1 which is what t= he >> original discussion was about, why not also add MUST NOT MD5 and SHA1 in T= LS >> 1.2 to the text? >=20 > This seems like a reasonable proposal. If added, should this just be in the updates section for RFC7525? Best regards, Kathleen=20 >=20 > -Ekr >=20 >>=20 >> Peter. >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail-D1CBF52E-26A4-448E-ACCE-95D481541870 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Sent from my mobile device

On May 3, 2019, at 3:56 PM, Eric Rescorla <ekr@rtfm.com> wrote:



On Fri, May 3, 2019 at 10:31 AM Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:
Having said that, given an RFC saying MUST NOT 1.0 and 1.1 which is what the
original discussion was about, why not also add MUST NOT MD5 and SHA1 in TLS
1.2 to the text?

This seems like a reasonable proposal.

If added, should this just be in the updates section for RFC7525?

Best regards,
Kathleen 

-Ekr


Peter.

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--Apple-Mail-D1CBF52E-26A4-448E-ACCE-95D481541870-- From nobody Fri May 3 13:40:17 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21014120260 for ; Fri, 3 May 2019 13:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Exl6oDFjPJmu for ; Fri, 3 May 2019 13:40:13 -0700 (PDT) Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B422F1200F8 for ; Fri, 3 May 2019 13:40:13 -0700 (PDT) Received: by mail-ot1-x329.google.com with SMTP id b18so6485817otq.3 for ; Fri, 03 May 2019 13:40:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=enOkVSaKEZXPlHt4M9rW8XeC1vuCtFD92gz9oqR715c=; b=a9c6KxDbRjm3zfVl/UkmL8/xv5DHkOL6LklOwR9Nz/LiKdK75+vdpCbAfNchFU049Y z2jEhwx3e3satK08oIfNa3dFvTbgts4btmwmoUTWWdEFW8n0/Hb0rSVYMXCvTt2U8AJ9 Km55eh8T2JOk8F+KQswLTQ5qlxw7fglaChUQa5zZSn3GOuujUwVRBvv0sUk7VYR7CWu/ iFRaHD5K9DLe/rBnCjrw15R8bSDa/08+oUm/lLNbbSUqnm9sTtHWmebQDXslsYOfhFTw o8S02cNACebxGl99fTTL/ocW0c+TJqGvVfg1PEPGFg7FkQoSuR9QOmR7aSAIu8H8sFpQ Erqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=enOkVSaKEZXPlHt4M9rW8XeC1vuCtFD92gz9oqR715c=; b=juGsM5RpN3g1nEOl2qf103PK2tYr6o2p5VscD+yI0fRoELAF5Cqj8qpW76eADHBbwc 0KjlrD69ascgL1M6yJ8qCdLjV+fk8rrqzHeN6W4ZlMoyAQMCJLjyFgNJcQ1uHtTF68vE HS1W4aQE3pL+4bsKydcem+Q3VccTxiabYx6L0k/WcVzTcmtBk0t58a+OY/6FvFg4NyA5 EtsUASRbXmz3VPpSca/7nbd3dCyEUChZtt2zS271vQXDYV+Iiu1j9o6cfdNE+aawqFZQ oUj7FE9rZ3IoX5I+j/I2pk07DUxiUZCNSTDQYE9bgnS0aw0lA0hpNRfF//y9KXjt4hFm dbgA== X-Gm-Message-State: APjAAAXlFguSeXpaaACqj6ZZCPYOslAH2fiobWyCRA0xcPKdP3oY5Rz/ S0Em3kDMQzqRkhMg1Nobm9s30PRci9duwcBj+nE= X-Google-Smtp-Source: APXvYqxn1KggX24LNj9aQy+TNGAnMNrWHGjOn8Ur8Dw7AYxUKFiHaiyBV/gvF4/2mskVTTYD/10CCB2f2ALgyzam1+E= X-Received: by 2002:a9d:72c8:: with SMTP id d8mr8040200otk.149.1556916013020; Fri, 03 May 2019 13:40:13 -0700 (PDT) MIME-Version: 1.0 References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <7d37f7ca-e253-4c95-9cf7-2d16b0b6a0aa@www.fastmail.com> <20190430234952.21F5C404C@ld9781.wdf.sap.corp> <5441930.X76MtM1CnQ@pintsize.usersys.redhat.com> <1556902416424.28526@cs.auckland.ac.nz> <20190503172022.GH4464@akamai.com> <1556904629782.23087@cs.auckland.ac.nz> <1F7FC950-358D-4D5C-963B-B7B837AE49DA@gmail.com> In-Reply-To: <1F7FC950-358D-4D5C-963B-B7B837AE49DA@gmail.com> From: Kathleen Moriarty Date: Fri, 3 May 2019 16:39:36 -0400 Message-ID: To: Eric Rescorla Cc: Peter Gutmann , "tls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000e6b975058801c16b" Archived-At: Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 20:40:16 -0000 --000000000000e6b975058801c16b Content-Type: text/plain; charset="UTF-8" On Fri, May 3, 2019 at 4:09 PM Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > > > Sent from my mobile device > > On May 3, 2019, at 3:56 PM, Eric Rescorla wrote: > > > > On Fri, May 3, 2019 at 10:31 AM Peter Gutmann > wrote: > >> Having said that, given an RFC saying MUST NOT 1.0 and 1.1 which is what >> the >> original discussion was about, why not also add MUST NOT MD5 and SHA1 in >> TLS >> 1.2 to the text? >> > > This seems like a reasonable proposal. > > > If added, should this just be in the updates section for RFC7525? > If done here, the text below would change to MUST and we'd likely need another WGLC, correct? When using RSA, servers SHOULD authenticate using certificates with at least a 2048-bit modulus for the public key. In addition, the use of the SHA-256 hash algorithm is RECOMMENDED (see [CAB-Baseline ] for more details). Clients SHOULD indicate to servers that they request SHA-256, by using the "Signature Algorithms" extension defined in TLS 1.2. The MUST NOT for SHA-1 is not clearly stated in RFC7525 as far as I can see. Proposed: When using RSA, servers SHOULD authenticate using certificates with at least a 2048-bit modulus for the public key. In addition, the use of the SHA-256 hash algorithm is the minimum requirement, SHA-1 MUST not be used (see [CAB-Baseline ] for more details). Clients SHOULD indicate to servers that they request SHA-256, by using the "Signature Algorithms" extension defined in TLS 1.2. MD5 is not discussed in the current version of RFC7525. Best regards, Kathleen > Best regards, > Kathleen > > > -Ekr > > >> Peter. >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > -- Best regards, Kathleen --000000000000e6b975058801c16b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, May 3, 2019 at 4:09 PM Kathle= en Moriarty <kathlee= n.moriarty.ietf@gmail.com> wrote:


Sent from my mobile device
On May 3, 2019, at 3:56 PM, Eric Rescorla <ekr@rtfm.com> wrote:



On Fri, May 3, 201= 9 at 10:31 AM Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:
Having said that, given an RFC saying MUST NOT 1.0 and 1.1 which is what th= e
original discussion was about, why not also add MUST NOT MD5 and SHA1 in TL= S
1.2 to the text?

This seems like a reas= onable proposal.

If adde= d, should this just be in the updates section for RFC7525?

If done here, the text below would change to MUST and= we'd likely need another WGLC, correct?

   When using RSA, servers S=
HOULD authenticate using certificates with
   at least a 2048-bit modulus for the public key.  In addition, the use
   of the SHA-256 hash algorithm is RECOMMENDED (see [CAB-Baseline] for
   more details).  Clients SHOULD indicate to servers that they request
   SHA-256, by using the "Signature Algorithms" extension defined=
 in
   TLS 1.2.

The MUST NOT for SH=
A-1 is not clearly stated in RFC7525 as far as I can see.

Proposed:
   When using RSA, =
servers SHOULD authenticate using certificates with
   at least a 2048-bit modulus for the public key.  In addition, the use
   of the SHA-256 hash algorithm is the minimum requirement, SHA-1 MUST not=
 be used (see [CAB-Baseline] for
   more details).  Clients SHOULD indicate to servers that they request
   SHA-256, by using the "Signature Algorithms" extension defined=
 in
   TLS 1.2.

MD5 is not discussed in the current version of RFC752=
5.

Best regards,
Kathleen=

Best regards,
Kathleen=C2=A0

-Ekr


Peter.

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


-- =

Be= st regards,
Kathleen
--000000000000e6b975058801c16b-- From nobody Fri May 3 13:50:48 2019 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 77FAA120260; Fri, 3 May 2019 13:50:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tls@ietf.org Message-ID: <155691664643.7200.1423596873930644188@ietfa.amsl.com> Date: Fri, 03 May 2019 13:50:46 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-exported-authenticator-09.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list 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 May 2019 20:50:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : Exported Authenticators in TLS Author : Nick Sullivan Filename : draft-ietf-tls-exported-authenticator-09.txt Pages : 12 Date : 2019-05-03 Abstract: This document describes a mechanism in Transport Layer Security (TLS) to provide an exportable proof of ownership of a certificate that can be transmitted out of band and verified by the peer. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-exported-authenticator-09 https://datatracker.ietf.org/doc/html/draft-ietf-tls-exported-authenticator-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-exported-authenticator-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 3 19:46:31 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 883ED120370 for ; Fri, 3 May 2019 19:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLJb3O0su17x for ; Fri, 3 May 2019 19:46:27 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD648120088 for ; Fri, 3 May 2019 19:46:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1556937986; x=1588473986; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=0KST1kYNbyHfq6c9QyEZTTevZeOKHr5KL+/QPyeJv/Y=; b=AyyPVgQpPi+0Zx7BzVDt1vrXMFMHldfs44N5x7GkTcmrkYz7KmVSsUQN TfIAVPzUuWV8FNln4gtSGpF9DSh0IEuM7hn/m4xY9xlfVc5M4hyvQI0LF DhtyoSbhp275a/afy++hSnexMhYZZhv0hpuHDNq9PZ2ga1iO5nurIQvWE OvaOaaHjqEB0HT3MvAZgUs/iQlwwYBrM10BU5WC+uqmhpIWdVZbViiLm7 V/KNC3OmtMaXI9QcZZCPYpPezVVwgb5PjfjN7wI5iHLbgZnsXZGxe3M/N Wbw+7j24m/08AhBnDNqA6+0pz+4u8hW42BRa6sNxNVNaZbJ+xYYi8OXcy g==; X-IronPort-AV: E=Sophos;i="5.60,428,1549882800"; d="scan'208";a="60249186" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.2 - Outgoing - Outgoing Received: from uxcn13-ogg-a.uoa.auckland.ac.nz ([10.6.2.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 04 May 2019 14:46:23 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-a.UoA.auckland.ac.nz (10.6.2.2) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 4 May 2019 14:46:23 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Sat, 4 May 2019 14:46:23 +1200 From: Peter Gutmann To: Kathleen Moriarty , Eric Rescorla CC: "tls@ietf.org" Thread-Topic: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" Thread-Index: AQHU+8+QtjVLqWiyz0WqN1BpourjtKZM43YAgADkD4CAAGW4gIADRbgAgAMrEACAA/7YAIABDIIe//8+0QCAAMtvyv//YEgAgAADegCAAAh5AIABLdvl Date: Sat, 4 May 2019 02:46:22 +0000 Message-ID: <1556937973484.34949@cs.auckland.ac.nz> References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <7d37f7ca-e253-4c95-9cf7-2d16b0b6a0aa@www.fastmail.com> <20190430234952.21F5C404C@ld9781.wdf.sap.corp> <5441930.X76MtM1CnQ@pintsize.usersys.redhat.com> <1556902416424.28526@cs.auckland.ac.nz> <20190503172022.GH4464@akamai.com> <1556904629782.23087@cs.auckland.ac.nz> <1F7FC950-358D-4D5C-963B-B7B837AE49DA@gmail.com>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 04 May 2019 02:46:29 -0000 S2F0aGxlZW4gTW9yaWFydHkgPGthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tPuKAiyB3 cml0ZXM6Cgo+TUQ1IGlzIG5vdCBkaXNjdXNzZWQgaW4gdGhlIGN1cnJlbnQgdmVyc2lvbiBvZiBS RkM3NTI1LgoKSSB3b3VsZCBhZGQgaXQsIGlmIHRoaXMgaXMgZ3VpZGFuY2UgZm9yIGdlbmVyYWwg dXNlIHRoZW4gaXQgc2hvdWxkIGNvdmVyIGFsbAp0aGUgYmFzZXMsIGlmIFNIQS0xIGlzIGEgTVVT VCBOT1QgdGhlbiBNRDUgaXMgYSBSRUFMTFkgUkVBTExZIFJFQUxMWSBNVVNUIE5PVC4KCihUZWNo bmljYWxseSBTSEEtMSBpcyBzdGlsbCBzYWZlIGZvciBlcGhlbWVyYWwgc2lnbmluZywgaS5lLiBs b2NhdGlvbnMgd2hlcmUKYW4gYXR0YWNrZXIgY2FuJ3Qgc3BlbmQgYXJiaXRyYXJ5IGFtb3VudHMg b2YgdGltZSB3b3JraW5nIG9uIHByZWNvbXB1dGVkIGRhdGEsCndoaWNoIGlzIG1vc3Qgb2YgVExT IGJlY2F1c2Ugb2YgdGhlIG5vbmNlcyBpbiB0aGUgaGFuZHNoYWtlIGFuZCB0aGUgZmFjdCB0aGF0 CmNvbm5lY3Rpb25zIHdpbGwgcXVpY2tseSB0aW1lIG91dCBpZiBub3RoaW5nIGFycml2ZXMsIGJ1 dCBzaW5jZSBUTFMgMS4yIGhhcwpTSEEtMiBidWlsdCBpbiBhbHJlYWR5IHRoZXJlJ3MgcHJvYmFi bHkgbGl0dGxlIHBvaW50IGluIHNlcGFyYXRpbmcgb3V0IHdoZXJlClNIQS0xIGlzIHNhZmUgdnMu IHdoZXJlIGl0IGlzbid0KS4KClBldGVyLgo= From nobody Sat May 4 06:00:59 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C60C12008A for ; Sat, 4 May 2019 06:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYjsMI1eJMjO for ; Sat, 4 May 2019 06:00:54 -0700 (PDT) Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1FB4120074 for ; Sat, 4 May 2019 06:00:54 -0700 (PDT) Received: by mail-oi1-x233.google.com with SMTP id y64so6463699oia.7 for ; Sat, 04 May 2019 06:00:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=H9ch/3ogWZEfV0+6uArBrSugq3FJEQCFxnJKAYOiuQE=; b=RZLJqBKFfxbYX/h7sMK1IWPrH8hGUVb9LiyvP565N2hwdfKpXscLNt4s6l05O6qxnh 8sBYjSFMFE4A2hnwZu21fhXij71jy/LRHLQEVtYNos/xT4Kz4l1reO2D0pKkZG6ABRjf V948qK3tgc8WovIGLd4QZbAR+t3cnOkDSWfIvl7+llF2ceMsBfzuym+WUaelqUf3+3Bv Sw0OdeRmj0K2lATvQ4wFZ9lwW7BvMcvpUjvYa5XZZA/zd2YgYzA7EgPJtpACuCE324sC c5q36PORww2+IBoUnuQ6dYBKdPJB9+pwLKnenDbsnbNwC7p+UFJvAN6iRGCybwUKeEsr 0Nng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=H9ch/3ogWZEfV0+6uArBrSugq3FJEQCFxnJKAYOiuQE=; b=F9ceEMeksFKmy7e/MnT6YoFgYWpBlAg/Wl+KZos32OpT1OgxM8T241//g6H5G8u+yo Vyu9/4wWXfLbRmUGAmcJbmvSs/7q6Lf3A7m5ss0lYf/Benv7NMhRV3GQimnYd9v34NAd l4vHX23aiYNP2G5dZhCnNjvmKX42zz+1m3bOwACpsjMiaTbm2DrGUy4iEdsi6Ghyrvlc 0H+8PwtTO0pallllek5CU4yewUDSwOl/Ys0ipFeKaOIL7ezY+oQt0zlY7eenLMMkc+2l aDqKEkQHcoJfhedhi6XOp2FoVhE7WYchYoAuAwdTysY1hbblKs+AzmZVBskZArsqaXVz 6HOw== X-Gm-Message-State: APjAAAUJWU4Hn5E570DXTp+fJBZ7GSiP8VPFccLrzNJuEag7tMc78MDs TQ94KXDqByw5XbL7BwbN/ZfxBihsa0elrrxpklGrqWpw4tg= X-Google-Smtp-Source: APXvYqyg2X5fExP6gKGfJ8bQq77owMs1OC4BlD7SmzD3RUFviaYHMRU/g/MPAWU256vXknYHjsYgnWIgQAgF4yeECIY= X-Received: by 2002:aca:3e56:: with SMTP id l83mr2325530oia.111.1556974854030; Sat, 04 May 2019 06:00:54 -0700 (PDT) MIME-Version: 1.0 References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <7d37f7ca-e253-4c95-9cf7-2d16b0b6a0aa@www.fastmail.com> <20190430234952.21F5C404C@ld9781.wdf.sap.corp> <5441930.X76MtM1CnQ@pintsize.usersys.redhat.com> <1556902416424.28526@cs.auckland.ac.nz> <20190503172022.GH4464@akamai.com> <1556904629782.23087@cs.auckland.ac.nz> <1F7FC950-358D-4D5C-963B-B7B837AE49DA@gmail.com> <1556937973484.34949@cs.auckland.ac.nz> In-Reply-To: <1556937973484.34949@cs.auckland.ac.nz> From: Kathleen Moriarty Date: Sat, 4 May 2019 09:00:17 -0400 Message-ID: To: Peter Gutmann Cc: Eric Rescorla , "tls@ietf.org" Content-Type: multipart/alternative; boundary="0000000000001948d905880f75bf" Archived-At: Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 04 May 2019 13:00:57 -0000 --0000000000001948d905880f75bf Content-Type: text/plain; charset="UTF-8" On Fri, May 3, 2019 at 10:46 PM Peter Gutmann wrote: > Kathleen Moriarty writes: > > >MD5 is not discussed in the current version of RFC7525. > > I would add it, if this is guidance for general use then it should cover > all > the bases, if SHA-1 is a MUST NOT then MD5 is a REALLY REALLY REALLY MUST > NOT. > > (Technically SHA-1 is still safe for ephemeral signing, i.e. locations > where > an attacker can't spend arbitrary amounts of time working on precomputed > data, > which is most of TLS because of the nonces in the handshake and the fact > that > connections will quickly time out if nothing arrives, but since TLS 1.2 has > SHA-2 built in already there's probably little point in separating out > where > SHA-1 is safe vs. where it isn't). > Sure, I agree, but needed to look through prior documents first. Since it wasn't in RFC7525 as a recommendation and the minimum baseline was above MD5, I suspect that is why it is not mentioned. If there is support (and no disagreements) the text above could be added and include SHA-1 and MD5 MUST NOT be used. The minimum baseline is already set above it though in the statement. WG decision is appreciated on this point and proposed text for RFC 7525. Proposed: When using RSA, servers SHOULD authenticate using certificates with at least a 2048-bit modulus for the public key. In addition, the use of the SHA-256 hash algorithm is the minimum requirement, SHA-1 and MD5 MUST not be used (see [CAB-Baseline ] for more details). Clients SHOULD indicate to servers that they request SHA-256, by using the "Signature Algorithms" extension defined in TLS 1.2. Best regards, Kathleen > > Peter. > -- Best regards, Kathleen --0000000000001948d905880f75bf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, May 3, 2019 at 10:46 PM Peter= Gutmann <pgut001@cs.auckla= nd.ac.nz> wrote:
Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> writes:
>MD5 is not discussed in the current version of RFC7525.

I would add it, if this is guidance for general use then it should cover al= l
the bases, if SHA-1 is a MUST NOT then MD5 is a REALLY REALLY REALLY MUST N= OT.

(Technically SHA-1 is still safe for ephemeral signing, i.e. locations wher= e
an attacker can't spend arbitrary amounts of time working on precompute= d data,
which is most of TLS because of the nonces in the handshake and the fact th= at
connections will quickly time out if nothing arrives, but since TLS 1.2 has=
SHA-2 built in already there's probably little point in separating out = where
SHA-1 is safe vs. where it isn't).

= Sure, I agree, but needed to look through prior documents first.=C2=A0 Sinc= e it wasn't in RFC7525 as a recommendation and the minimum baseline was= above MD5, I suspect that is why it is not mentioned.=C2=A0 =C2=A0If there= is support (and no disagreements) the text above could be added and includ= e SHA-1 and MD5 MUST NOT be used.=C2=A0 The minimum baseline is already set= above it though in the statement.

WG decision is = appreciated on this point and proposed text for RFC 7525.

Proposed:
   When using RSA, servers SHOULD authenticate using certificates wit=
h
   at least a 2048-bit modulus for the public key.  In addition, the use
   of the SHA-256 hash algorithm is the minimum requirement, SHA-1 and MD5 =
MUST not be used (see [CAB-Baseline] for
   more details).  Clients SHOULD indicate to servers that they request
   SHA-256, by using the "Signature Algorithms" extension defined=
 in
   TLS 1.2.

Best regards,
Ka= thleen

Peter.


--

Best regards,
Kathleen
--0000000000001948d905880f75bf-- From nobody Sun May 5 04:11:43 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31A9D120140 for ; Sun, 5 May 2019 04:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Bhl7l0jbdVU for ; Sun, 5 May 2019 04:11:39 -0700 (PDT) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9298120126 for ; Sun, 5 May 2019 04:11:38 -0700 (PDT) Received: by mail-ed1-x532.google.com with SMTP id e56so11843698ede.7 for ; Sun, 05 May 2019 04:11:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version:thread-index :content-language; bh=pwM/6GMBh4G3Wf5ip4khvugDQNsOS9Z9a2NS3fVB84Y=; b=AsSnKyUPVse/0Z5mM8znTLsyD3k4NkDeUUUWSc2RnxoREbeJLFL9pr/hD1p5+fRpbH YIFJvsnKc7YQ1K3v+RHC561A9x/W7t4uoQiUurWTNU+A1diO/71yH0tMG7Akc/wfmxLt zKDQ1M6Q9bi53ivuaNJcpfYZsj82ivbig0hV0/d0Lyk1wdNCd0gZf3o7dFpF0+fdJEd0 k+xe5ApEncfU0vXU3NzSAfHcTT3S6ubFcZRarMHmKAQsB7YQR+DDL5JWeeXovKITBZmh kwYGHM37WNBrRvI+9iIap3FGSM5IttJgecZbabXhUMpaVoWdJfncsvWHvjU5mN5oMPJi TOTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :thread-index:content-language; bh=pwM/6GMBh4G3Wf5ip4khvugDQNsOS9Z9a2NS3fVB84Y=; b=g/8NNgZsDlNnCCsF1yn9mICH415VqfTdjjCvD3vSs0wku6bi8aozWPqU7wHnEDodSc WJiGhh09OeTODD3sBFfP5dJBhPpcrt7cd0xsDs7U4zvpJbfUAp3WtphbVIRW2dWI9qSm dkiU7CXcZp7IgYqZtDVoWJZmtkwR6Jw34l1DTQdllMuPhzMhVr7XbtUyV7bcPxvf+qc8 AVOwbSPtoUILmWCgeRjyvq903SUiPtLsiVa3ElCHQ88jzngiVL4mFuBDpRjN5LF9gxfU LpeB0bzxoPSvhg8I8R6P8ZZI8PndOkQv6qyOhB2jAULk/sM4w7gEIyZvMAt0hkF2ZiGe Jobw== X-Gm-Message-State: APjAAAUCovl0TYaBjL23NMmNOaSbtuJpBIWhheuU2ehkjnKM4ZSKO9gy coop76Zg1P5tZ4aIdXvhyRMQWCOS X-Google-Smtp-Source: APXvYqwiUfvP6cPF1K8K3t2ACa+FHMyQdJl25SpiMTTlMK/5M5Nk+UwBqE4ZzSeMsyhR3gm9GFPNAg== X-Received: by 2002:a05:6402:13cf:: with SMTP id a15mr19728590edx.70.1557054697206; Sun, 05 May 2019 04:11:37 -0700 (PDT) Received: from zeropki ([31.10.159.222]) by smtp.gmail.com with ESMTPSA id s15sm2102938edm.6.2019.05.05.04.11.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 May 2019 04:11:36 -0700 (PDT) From: To: Date: Sun, 5 May 2019 13:11:27 +0200 Message-ID: <00d601d50333$49253bd0$db6fb370$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D7_01D50344.0CAE59F0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdUDLZFEqb3m45urTxKWiK30IbrAiA== Content-Language: en-ca Archived-At: Subject: [TLS] Question regarding TLS 1.3 session resumption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 05 May 2019 11:11:41 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00D7_01D50344.0CAE59F0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Good afternoon all, =20 The RFC 8446 mentions key schedule, resumption_master_secret and new = session ticket and I am not quite sure if I understand the session resumption behavior correctly. =20 My understanding is that both the client and server calculate all the secrets of the key schedule therefore both the client and server know = the value of the resumption_master_secret, therefore both sides calculate, =20 PSK =3D HKDF-Expand-Label(resumption_master_secret, "resumption", ticket_nonce, Hash.length) =20 and the server sends back to the client the PSK (unencrypted, which acts = as an input into the HKDF-Extract to calculate the 0-RTT encryption key) + = new session ticket (encrypted using the session ticket key). Upon resumption = the PSK is provided as an input into the key schedule together with new = ECDHE parameters to assure forward secrecy of the resumed session + the new session ticket is sent to the server as a reminder it is a resumed = session. =20 If the session ticket is opaque to the client then the client needs to = store session information of the initial session (cipher suite, key exchange, etc..) + PSK and session ticket and the server needs to store only the session encryption key to resume session. Correct? =20 My question is what key is encrypting the session ticket (is it a = symmetric key that is generated by the webserver/SSL library for each session? In = my Apache 2.4.39 and openssl 1.1.1b testing the TLS 1.3 resumption works without specifying the SSLSessionTicketKeyFile directive) and what information is stored in the ticket (is it cipher suite, key exchange?? = The full key schedule is executed anew for resumed session and new crypto. material is generated so there is no need for the ticket to contain master_secret or anything similar like in TLS 1.2, so what exactly does = the ticket contain?). =20 Thank you, =20 Luk=E1=B9 Geyer ------=_NextPart_000_00D7_01D50344.0CAE59F0 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

Go= od afternoon all,

 

Th= e RFC 8446 mentions key schedule, resumption_master_secret and new = session ticket and I am not quite sure if I understand the session = resumption behavior correctly.

 

My= understanding is that both the client and server calculate all the = secrets of the key schedule therefore both the client and server know = the value of the resumption_master_secret, therefore both sides = calculate,

 

PSK =3D = HKDF-Expand-Label(resumption_master_secret,

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "resumption", = ticket_nonce, Hash.length)

 

an= d the server sends back to the client the PSK (unencrypted, which acts = as an input into the HKDF-Extract to calculate the 0-RTT encryption key) = + new session ticket (encrypted using the session ticket key). Upon = resumption the PSK is provided as an input into the key schedule = together with new ECDHE parameters to assure forward secrecy of the = resumed session + the new session ticket is sent to the server as a = reminder it is a resumed session.

 

If= the session ticket is opaque to the client then the client needs to = store session information of the initial session (cipher suite, key = exchange, etc..) + PSK and session ticket and the server needs to store = only the session encryption key to resume session. = Correct?

 

My= question is what key is encrypting the session ticket (is it a = symmetric key that is generated by the webserver/SSL library for each = session? In my Apache 2.4.39 and openssl 1.1.1b testing the TLS 1.3 = resumption works without specifying the SSLSessionTicketKeyFile = directive) and what information is stored in the ticket (is it cipher = suite, key exchange?? The full key schedule is executed anew for resumed = session and new crypto. material is generated so there is no need for = the ticket to contain master_secret or anything similar like in TLS 1.2, = so what exactly does the ticket contain?).

 

Th= ank you,

 

Lu= k=E1= =B9 Geyer

------=_NextPart_000_00D7_01D50344.0CAE59F0-- From nobody Sun May 5 06:03:41 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9AAF1201C6 for ; Sun, 5 May 2019 06:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gy0S_Og7iPUE for ; Sun, 5 May 2019 06:03:37 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90CBC1201B7 for ; Sun, 5 May 2019 06:03:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id E2C564F919; Sun, 5 May 2019 16:03:32 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id fKHVZN1NSb82; Sun, 5 May 2019 16:03:32 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 552FA2309; Sun, 5 May 2019 16:03:30 +0300 (EEST) Date: Sun, 5 May 2019 16:03:29 +0300 From: Ilari Liusvaara To: geyer.lukas@gmail.com Cc: tls@ietf.org Message-ID: <20190505130329.GA797233@LK-Perkele-VII> References: <00d601d50333$49253bd0$db6fb370$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <00d601d50333$49253bd0$db6fb370$@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Question regarding TLS 1.3 session resumption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 05 May 2019 13:03:40 -0000 On Sun, May 05, 2019 at 01:11:27PM +0200, geyer.lukas@gmail.com wrote: > Good afternoon all, > > > The RFC 8446 mentions key schedule, resumption_master_secret and new session > ticket and I am not quite sure if I understand the session resumption > behavior correctly. > > > My understanding is that both the client and server calculate all the > secrets of the key schedule therefore both the client and server know the > value of the resumption_master_secret, therefore both sides calculate, > > > > PSK = HKDF-Expand-Label(resumption_master_secret, > > "resumption", ticket_nonce, Hash.length) > > > > and the server sends back to the client the PSK (unencrypted, which acts as > an input into the HKDF-Extract to calculate the 0-RTT encryption key) + new > session ticket (encrypted using the session ticket key). Upon resumption the > PSK is provided as an input into the key schedule together with new ECDHE > parameters to assure forward secrecy of the resumed session + the new > session ticket is sent to the server as a reminder it is a resumed session. The session ticket can also be a server-side database pointer. Which is highly recommended if ticket allows 0-RTT. And protocol allows skipping ECDHE, but that is of course a bad idea. The reason why the ticket_nonce exists is to have all the tickets have computationally independent keys, even if derived from the same connection. > If the session ticket is opaque to the client then the client needs to store > session information of the initial session (cipher suite, key exchange, > etc..) + PSK and session ticket and the server needs to store only the > session encryption key to resume session. Correct? IIRC, one does need key exchange type of initial session. The information that needs to be stored includes: - The ticket itself - Expiry time of authentication (can not be extended). - Expiry time for ticket (as sent by server) - Hash function used by initial session - What key exchange modes are supported for this ticket (if multiple are supported). - Cipher used by initial session (0-RTT only). - Maximum 0-RTT size (0-RTT only). - Ticket age masking value - The PSK key data. If client demands forward secrecy, one can leave supported kex modes out and just discard all tickets that do not support PFS. Note that if connection was resumed, the expiry time of authentication is copied from the ticket that was used to create the session, there is no way to extend it. Tickets that have expired either the ticket itself or the authentication are deleted and must not be used. > My question is what key is encrypting the session ticket (is it a symmetric > key that is generated by the webserver/SSL library for each session? In my > Apache 2.4.39 and openssl 1.1.1b testing the TLS 1.3 resumption works > without specifying the SSLSessionTicketKeyFile directive) and what > information is stored in the ticket (is it cipher suite, key exchange?? The > full key schedule is executed anew for resumed session and new crypto. > material is generated so there is no need for the ticket to contain > master_secret or anything similar like in TLS 1.2, so what exactly does the > ticket contain?). The key (unless tickets are actually database pointers) should be symmetric key generated by the server and frequently automatically rotated (with overlapping validity windows). Of course, many implementations do not properly autorotate the key. The ticket contains things like (assuming 0-RTT is not supported, like it should not): - The PSK key data - Expiry time of the ticket. - Ticket age masking value. - Hash function used by initial session If expiry time has passed, the attempt to use the ticket must be rejected. Same if the calculated ticket age and the unmasked ticket age disagree too much (but beware that there are pretty bad clocks out there... The mechanism can not correct even first-order error) And yes, the tickets do not contain anything like master_secret. The TLS 1.2 session ticket mechanism is a security disaster (with many small mistakes combining into one big problem). -Ilari From nobody Sun May 5 15:36:24 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E487120123 for ; Sun, 5 May 2019 15:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-8u5BRHcEtV for ; Sun, 5 May 2019 15:36:21 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A967F120112 for ; Sun, 5 May 2019 15:36:21 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B3917B81F13; Sun, 5 May 2019 15:36:20 -0700 (PDT) To: martin.thomson@gmail.com, rdd@cert.org, kaduk@mit.edu, caw@heapingbits.net, joe@salowey.net, sean+ietf@sn3rd.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: mt@lowentropy.net, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20190505223620.B3917B81F13@rfc-editor.org> Date: Sun, 5 May 2019 15:36:20 -0700 (PDT) Archived-At: Subject: [TLS] [Technical Errata Reported] RFC8448 (5720) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 05 May 2019 22:36:23 -0000 The following errata report has been submitted for RFC8448, "Example Handshake Traces for TLS 1.3". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5720 -------------------------------------- Type: Technical Reported by: Martin Thomson Section: GLOBAL Original Text ------------- 00 0d 00 20 00 1e 04 03 05 03 06 03 02 03 08 04 08 05 08 06 04 01 05 01 06 01 02 01 04 02 05 02 06 02 02 02 Corrected Text -------------- 00 0d 00 18 00 16 04 03 05 03 06 03 02 03 08 04 08 05 08 06 04 01 05 01 06 01 02 01 Notes ----- The traces all show DSA signature schemes in ClientHello messages. The use of these is prohibited by RFC 8446. To be compliant, these would be removed. Note that this isn't a simple substitution as implied above. The length fields on all of the messages would also need to be reduced by 8 in addition to making the substitution. The value of the PSK binders used in the resumption case in Section 4 would need to be recalculated also. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8448 (draft-ietf-tls-tls13-vectors-07) -------------------------------------- Title : Example Handshake Traces for TLS 1.3 Publication Date : January 2019 Author(s) : M. Thomson Category : INFORMATIONAL Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Sun May 5 16:00:37 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3092E120122 for ; Sun, 5 May 2019 16:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=MUYVIJLX; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=At6f/E1w Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jCli4dg2b1V7 for ; Sun, 5 May 2019 16:00:34 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4779D120106 for ; Sun, 5 May 2019 16:00:34 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 7985821B10 for ; Sun, 5 May 2019 19:00:33 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Sun, 05 May 2019 19:00:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm2; bh=eUn1C 4Z351inono9pzxG1+XoSIdg7dSyXyVFAv++4hw=; b=MUYVIJLXQE/VVvnKekgzQ V2NTq/Tm18Xxp+tYNv893JP70T44P3GPbunQTvJg1MPP211F/mbDB5qt1oY2nmdt 3TKwwcspYdlF2ueINRKqvEkOPQ1roENmcPv2xfWarVcg1FsmRlEBz9VLELaAMVEQ ZNsJ6lvClCwB/Bc+j+qA6072Hg2RMMdxBeRt11UIKW6QlVre058tMxO6zbZy6f+h 2v28THWmJnWHG3JkiEEA23mkCHDxeyj+BavIQ55tzGjr91aOxybhVouISWQmupTb net6Cx1xVWqXSVFE+DoWFurd530un1cI7pPvvTpw245TdvKokZvd2kdLcjHofrlp g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=eUn1C4Z351inono9pzxG1+XoSIdg7dSyXyVFAv++4 hw=; b=At6f/E1wimaBQ/XXueMTr5M9fYMUxXJ3lHkoNACsjxaN0YbEczZDA4aYy dldV/gjMpghA0vEGLxViXBW1l5jjLiFhznv60p6LKLRQp6bm5mmYwikAg6qS/+pw TuWeMhaqVAGMCM+yehFDoe8wzu3t3iYowo7E1ccCHGehyuJjA/VnpUYq+OZVCEpo wTxgqLeaiisADZb7hxKk5kLM/v7W6Phw+f+/NhizkNFgRr/TZ5q+k+5DC3y2WUXK 0e7BXa6TTIKLUTTs2dpK1yWorLa9lRo9mt1LUXxTHH66SZYc4bafFN3Ct1kylwoz lQBFI1J8lF3uwVMZJTlZMuru7Zuvw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrjeeigddukecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucffohhmrghinheptghomhhpohhnohhlihhtrdgtoh hmpdhivghtfhdrohhrghdpmhhoiihilhhlrgdrohhrghenucfrrghrrghmpehmrghilhhf rhhomhepmhhtsehlohifvghnthhrohhphidrnhgvthenucevlhhushhtvghrufhiiigvpe dt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id D71307C6D9; Sun, 5 May 2019 19:00:32 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-449-gfb3fc5a-fmstable-20190430v1 Mime-Version: 1.0 Message-Id: In-Reply-To: <1f5befb5-0338-1135-1acf-31d06470d572@componolit.com> References: <1f5befb5-0338-1135-1acf-31d06470d572@componolit.com> Date: Sun, 05 May 2019 19:00:36 -0400 From: "Martin Thomson" To: tls@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Deprecated signature algorithms in RFC8446 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 05 May 2019 23:00:36 -0000 Thanks for noticing that Tobias. I've opened an erratum, but am still w= aiting for the RFC editor's email confirming it. I'll pass that along w= hen that comes through. (This is the result of a bug in NSS, so in case you are interested: http= s://bugzilla.mozilla.org/show_bug.cgi?id=3D1549225) On Sat, May 4, 2019, at 01:35, Tobias Reiher wrote: > Hi, >=20 > the example handshake traces for TLS 1.3 (RFC8448) seems not to fully > comply to the TLS 1.3 standard (RFC8446). >=20 > RFC8446 in 4.2.3. says that an implementation must not offer deprecate= d > algorithms in the signature algorithms extension: >=20 > "In TLS 1.2, the extension contained hash/signature pairs. The > pairs are encoded in two octets, so SignatureScheme values have > been allocated to align with TLS 1.2's encoding. Some legacy > pairs are left unallocated. These algorithms are deprecated as of > TLS 1.3. They MUST NOT be offered or negotiated by any > implementation. In particular, MD5 [SLOTH], SHA-224, and DSA > MUST NOT be used." >=20 > RFC8448 shows in 3. an example with a ClientHello message containing a= > signature algorithms extension with the deprecated algorithms 0x0402, > 0x0502, 0x0602, and 0x0202, which all refer to the DSA algorithm, whic= h > must not be used with TLS 1.3. >=20 > Best regards, >=20 > Tobias Reiher >=20 > --=20 > Componolit GmbH =C2=B7 K=C3=B6nigsbr=C3=BCcker Stra=C3=9Fe 124 =C2=B7 = 01099 Dresden =C2=B7 Germany > Amtsgericht Dresden =C2=B7 HRB 36670 =C2=B7 Sitz Dresden > Gesch=C3=A4ftsf=C3=BChrer: Alexander Senier =C2=B7 USt-IdNr. (EU VATIN= ): DE312113634 >=20 > http://componolit.com =C2=B7 @Componolit >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Sun May 5 16:12:27 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD26C1200F7 for ; Sun, 5 May 2019 16:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-oW-IJEm1Ma for ; Sun, 5 May 2019 16:12:24 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D64F61200C1 for ; Sun, 5 May 2019 16:12:23 -0700 (PDT) Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x45NCCD8012786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 5 May 2019 19:12:15 -0400 Date: Sun, 5 May 2019 18:12:12 -0500 From: Benjamin Kaduk To: RFC Errata System Cc: martin.thomson@gmail.com, rdd@cert.org, caw@heapingbits.net, joe@salowey.net, sean+ietf@sn3rd.com, mt@lowentropy.net, tls@ietf.org Message-ID: <20190505231212.GA19509@kduck.mit.edu> References: <20190505223620.B3917B81F13@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190505223620.B3917B81F13@rfc-editor.org> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [TLS] [Technical Errata Reported] RFC8448 (5720) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 05 May 2019 23:12:26 -0000 I guess we want Hold For Document Update? -Ben On Sun, May 05, 2019 at 03:36:20PM -0700, RFC Errata System wrote: > The following errata report has been submitted for RFC8448, > "Example Handshake Traces for TLS 1.3". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5720 > > -------------------------------------- > Type: Technical > Reported by: Martin Thomson > > Section: GLOBAL > > Original Text > ------------- > 00 0d 00 20 00 1e 04 03 05 03 06 03 02 03 08 04 08 05 > 08 06 04 01 05 01 06 01 02 01 04 02 05 02 06 02 02 02 > > > > Corrected Text > -------------- > 00 0d 00 18 00 16 04 03 05 03 06 03 02 03 08 04 08 05 > 08 06 04 01 05 01 06 01 02 01 > > Notes > ----- > The traces all show DSA signature schemes in ClientHello messages. The use of these is prohibited by RFC 8446. To be compliant, these would be removed. > > Note that this isn't a simple substitution as implied above. The length fields on all of the messages would also need to be reduced by 8 in addition to making the substitution. The value of the PSK binders used in the resumption case in Section 4 would need to be recalculated also. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC8448 (draft-ietf-tls-tls13-vectors-07) > -------------------------------------- > Title : Example Handshake Traces for TLS 1.3 > Publication Date : January 2019 > Author(s) : M. Thomson > Category : INFORMATIONAL > Source : Transport Layer Security > Area : Security > Stream : IETF > Verifying Party : IESG From nobody Sun May 5 20:32:01 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 420E11200B5 for ; Sun, 5 May 2019 20:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=m/i1BEHT; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=4ojMr92S Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbUDQnqpFkIx for ; Sun, 5 May 2019 20:31:58 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B71A8120086 for ; Sun, 5 May 2019 20:31:58 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 104852204E for ; Sun, 5 May 2019 23:31:58 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Sun, 05 May 2019 23:31:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=j1WFE0gW+LU3ZnwgQbG9cKt+L/D7Et8 c+rKBB+AAoh8=; b=m/i1BEHTnR87+0/jKzXZkwgR6ae/Llmk8YbkiyeMg7IRwTK FdkxqvEPoZcWmi4miy/pmrk9t4N+3dwFRx7WmQnZVNQ2LpkPCaW6qYnWjSGowydN ysU2zvCRaq5lYl1JrIlI/zaC2vckWeZUpQtZxXUcR8Vc1YVN9g6EPnJQ5MZbkVb5 1W3iqsM1M5jO4MEgmG/ZlZTdcz6c/CRQ5VxW6DbJt2WRdlLrXGRrxSI/LLBFzPzu 4G3+mBnz7zegqStUtyrKfDgEHufvqelIDzy6ECHHtZW+etX6NJRHR/wJKJ0eBbph 9idDjuceNU/2TN97cT8yWabSdUhww5hlW8OJyRg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=j1WFE0 gW+LU3ZnwgQbG9cKt+L/D7Et8c+rKBB+AAoh8=; b=4ojMr92SsrhkCVXGy6ZXO4 gNlIlFzsEOE10oD6Et05+uSpchPjLuks+Au706crzUliP7rDtPWx4c8s9dcpcM39 zL2uaKMbSdBRZ90s5/m7zsPG/lxjQ6bd3PNJO7Q1fvLe9eayiDGlw2rcmZx4pDE+ /0gVgzpnVhDaSkWy/eq+JJ2J0+mbM6x2Uh9cc4KYszVmmgIN//OQfG1Z9SIqhiSO D37rcilT8lBrVbRPD1wLYnJie9JZdHXGsLSZs8hIWWTmPTac9EaSKuYvClW5F7GU EJjBmFLWQParzv5z3TqqfS1Zg40Eqwybd86R/mlzAdMxi5kzTA9mXS/fSWCYpicQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrjeeigdejgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofi gvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9E85C7C6D9; Sun, 5 May 2019 23:31:57 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-449-gfb3fc5a-fmstable-20190430v1 Mime-Version: 1.0 Message-Id: <3d44bd29-05de-47e2-bc18-4624eca069eb@www.fastmail.com> In-Reply-To: <00d601d50333$49253bd0$db6fb370$@gmail.com> References: <00d601d50333$49253bd0$db6fb370$@gmail.com> Date: Sun, 05 May 2019 23:31:57 -0400 From: "Martin Thomson" To: tls@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [TLS] Question regarding TLS 1.3 session resumption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 03:32:00 -0000 Ilari answered your question, but this jumped out: On Sun, May 5, 2019, at 21:11, geyer.lukas@gmail.com wrote: > [...] both sides calculate, > PSK = [...] > and the server sends back to the client the PSK (unencrypted [...]) The PSK never gets sent. As you say, both sides can calculate the same value. > My question is what key is encrypting the session ticket (is it a > symmetric key that is generated by the webserver/SSL library for each > session? If you want a bad design choice, NSS uses RSA encryption using a key from one of its certificates to encrypt a symmetric key that we use with CBC. The symmetric key is used for all tickets once it is recovered, so the asymmetric encryption/decryption costs are paid just once when the system runs. The ways in which this design is bad are lengthy enough that I won't bother to list them. A better scheme would use a straight symmetric key with an AEAD, but there are historical deployment reasons for that design. From nobody Sun May 5 20:32:39 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 216D01200CC for ; Sun, 5 May 2019 20:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XpaKuELxLL2C for ; Sun, 5 May 2019 20:32:35 -0700 (PDT) Received: from mail-ot1-x343.google.com (mail-ot1-x343.google.com [IPv6:2607:f8b0:4864:20::343]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0082F1200C3 for ; Sun, 5 May 2019 20:32:34 -0700 (PDT) Received: by mail-ot1-x343.google.com with SMTP id g24so10249575otq.2 for ; Sun, 05 May 2019 20:32:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=+ZWTAwgwmKNgRVUKoriHc4NkRDoEi+Z6qNaMxK1tVRM=; b=OxDbXhZ9erYlzWG8s1h0pO3/1RtEcuUp5iWnedGVNLjVVdVkVYDA5x53c/0htT0SCp GkCQAE0Cmz6rcVXvs1xPjpenjgwnOFgsqViW2zStRpquPx/9tWwsrqBhSwtns1PCTqUn +wWVeKswC00lIWx00c64pAM/AJbmfEgvnqhLCTzCQougGyWxIK6OWtUMUnQBzFH/Jc9J 4QNjA5bnS8uF5FEwRK6lbm4I65sYeJXcYfvPuiCowZWaq0MpegXlPC+bIu6SHtKcOPc4 UUkdwKyhtYQoD9luXkBxx7filxHW9O7efKWbiNizragMHQkvK8Cksa5Bv5HgDFNVhT9W FeYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=+ZWTAwgwmKNgRVUKoriHc4NkRDoEi+Z6qNaMxK1tVRM=; b=S8gEchs8jzNt0/O9Z6Fr7WILMHIlvTBslcOO6oZpgbuAO8MI2wWqsyda9WLoJLr/9k 3uLls4zPXr1GqtfQ5giaM0oneudP2MoHIxDJYhE9/8M0cu1TgFRridZzCU0kqz4MdICG rJsXMip8HlhEUylBuIJ1lvOcMFhK4vBrXJcQ4kV2rO26ClYE9mJ3OPvKIM1dp+aBG3GB kdoFxCZRyvLDmHXGcL+KVrfq1FSnOenO0rn8LhHVP+ubNAK8OStL3mVujfOzelb3POVs H2MAh6JG321W+ne/i0dG4z5TRKZPdkQSGJcOPBlzgcm2u2JH3blLCHhodUe3BYqJtEbk 98YA== X-Gm-Message-State: APjAAAXd4MBe31Ww15hwS3X2mm7+EODeZhfZDQLFe30wqUeBI/eCaNrM IbT2E1OYSsnVrFfz/dKajE/IZ8N2//zBUdEj62M= X-Google-Smtp-Source: APXvYqwXHHVq/+digPBiiJtxYAwErebhpUhhipxYBe7q/9S+qXa2iKDcPfVIYPJZzq4kVRON6yfVGp9c9gJJqsvTR0U= X-Received: by 2002:a9d:5c7:: with SMTP id 65mr16967372otd.9.1557113554319; Sun, 05 May 2019 20:32:34 -0700 (PDT) MIME-Version: 1.0 References: <20190505223620.B3917B81F13@rfc-editor.org> <20190505231212.GA19509@kduck.mit.edu> In-Reply-To: <20190505231212.GA19509@kduck.mit.edu> From: Martin Thomson Date: Mon, 6 May 2019 13:32:22 +1000 Message-ID: To: Benjamin Kaduk Cc: RFC Errata System , rdd@cert.org, caw@heapingbits.net, Joseph Salowey , sean+ietf@sn3rd.com, mt@lowentropy.net, "" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] [Technical Errata Reported] RFC8448 (5720) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 03:32:37 -0000 That would work for me. On Mon, May 6, 2019 at 9:12 AM Benjamin Kaduk wrote: > > I guess we want Hold For Document Update? > > -Ben > > On Sun, May 05, 2019 at 03:36:20PM -0700, RFC Errata System wrote: > > The following errata report has been submitted for RFC8448, > > "Example Handshake Traces for TLS 1.3". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata/eid5720 > > > > -------------------------------------- > > Type: Technical > > Reported by: Martin Thomson > > > > Section: GLOBAL > > > > Original Text > > ------------- > > 00 0d 00 20 00 1e 04 03 05 03 06 03 02 03 08 04 08 05 > > 08 06 04 01 05 01 06 01 02 01 04 02 05 02 06 02 02 02 > > > > > > > > Corrected Text > > -------------- > > 00 0d 00 18 00 16 04 03 05 03 06 03 02 03 08 04 08 05 > > 08 06 04 01 05 01 06 01 02 01 > > > > Notes > > ----- > > The traces all show DSA signature schemes in ClientHello messages. The= use of these is prohibited by RFC 8446. To be compliant, these would be r= emoved. > > > > Note that this isn't a simple substitution as implied above. The lengt= h fields on all of the messages would also need to be reduced by 8 in addit= ion to making the substitution. The value of the PSK binders used in the r= esumption case in Section 4 would need to be recalculated also. > > > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC8448 (draft-ietf-tls-tls13-vectors-07) > > -------------------------------------- > > Title : Example Handshake Traces for TLS 1.3 > > Publication Date : January 2019 > > Author(s) : M. Thomson > > Category : INFORMATIONAL > > Source : Transport Layer Security > > Area : Security > > Stream : IETF > > Verifying Party : IESG From nobody Sun May 5 21:18:05 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6EA120088 for ; Sun, 5 May 2019 21:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=G+J0xydG; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=1ILtFIoV Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qyTiPLwvPtq for ; Sun, 5 May 2019 21:18:03 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3D4C120075 for ; Sun, 5 May 2019 21:18:02 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 155C626238 for ; Mon, 6 May 2019 00:18:02 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Mon, 06 May 2019 00:18:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=PmhiZge4D4qcUSxG4KSQzMVuCilSZQO 2WJ03yrUKfeU=; b=G+J0xydGmnc4QezyzmYjcXISCShc33o53uz2DXy7KWOmBA8 D4d33hl82uHJ8ahRiv/ChDvUTq+Jbr1LBnlYiIw+SR1jYQh9pJL09O/M/FNmoP99 VaQlEqCwxH2U/beenTJE6E2MzFv4hpzDUz8OTmFpZV4Tr3oso9r7rMOj59q48WKX HrGxsJPiXJJeTeNNPQsgOPhC9nNauSILi0t9WiHMej3rwZ4QDU6HSvfL8dqcJMcL laQhAR8LCVBcje3hbeX7Fa+yqTxeaZ6o/M8khGHnb4yGuSGbhaTYGW5Lnv4njknh gBdoAzsDjsz6mhF7Iv2AcsMO8rFM36Tt2WKdIRg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=PmhiZg e4D4qcUSxG4KSQzMVuCilSZQO2WJ03yrUKfeU=; b=1ILtFIoVsSZs6dDZkMTNpL l0uQj/sRkDIO9B1wbJp8wnfpINyMY21PUrbELECSdJn1nAup+Eel7tiNTyTpAxiV u+rVb9k9VzwCi+CtZm7+chC308AK3fGIIoHYkwO8otK6W2mkBL/T6Br6NtkAIYn1 8o5RlW5yNJMR3+xVc8WuId7gj3KZWcGx7aoU4XVB6UVQokKtLdmJL15GV/erpJ3r EMpEQzjAFum9cF6cbTZztp5/RLGqmnH6wzSmQ37NJDC7omG/pMvR6AV+MfMUNRIW q+vC0Dwv51AxFOqoFcAVV2MsyILbWqleRzoQjcdjfkZ/ynp8/88UD8GNdltGcxsA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrjeeigdekgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehivghtfhdrohhrghenucfrrghrrg hmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvthenucevlhhushht vghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 905067C6D9; Mon, 6 May 2019 00:18:01 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-449-gfb3fc5a-fmstable-20190430v1 Mime-Version: 1.0 Message-Id: <45f6682b-8a58-4547-80a5-8a42107d60a1@www.fastmail.com> In-Reply-To: References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <7d37f7ca-e253-4c95-9cf7-2d16b0b6a0aa@www.fastmail.com> <20190430234952.21F5C404C@ld9781.wdf.sap.corp> <5441930.X76MtM1CnQ@pintsize.usersys.redhat.com> <1556902416424.28526@cs.auckland.ac.nz> <20190503172022.GH4464@akamai.com> <1556904629782.23087@cs.auckland.ac.nz> <1F7FC950-358D-4D5C-963B-B7B837AE49DA@gmail.com> <1556937973484.34949@cs.auckland.ac.nz> Date: Mon, 06 May 2019 00:18:00 -0400 From: "Martin Thomson" To: tls@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 04:18:04 -0000 On Sat, May 4, 2019, at 23:01, Kathleen Moriarty wrote: > WG decision is appreciated on this point and proposed text for RFC 7525. > > Proposed: When using RSA, servers SHOULD authenticate using > certificates with > at least a 2048-bit modulus for the public key. In addition, the use > of the SHA-256 hash algorithm is the minimum requirement, SHA-1 and > MD5 MUST not be used (see [CAB-Baseline > ] for > more details). Clients SHOULD indicate to servers that they request > SHA-256, by using the "Signature Algorithms" extension defined in > TLS 1.2. Whether the chairs want this here or in a new thread, I fully endorse this. I don't think that I can safely turn SHA-1 off today, but it's definitely on the list. We don't even have code for MD5 in the stack any more, except for the weird paired hash thing in TLS <1.2. From nobody Mon May 6 04:19:12 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F7D3120059 for ; Mon, 6 May 2019 04:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nnq0Rly6zwDd for ; Mon, 6 May 2019 04:19:09 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF8DF120058 for ; Mon, 6 May 2019 04:19:08 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C45D33084031; Mon, 6 May 2019 11:19:07 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.83]) by smtp.corp.redhat.com (Postfix) with ESMTP id 026B52708C; Mon, 6 May 2019 11:19:06 +0000 (UTC) From: Hubert Kario To: mrex@sap.com Cc: tls@ietf.org, Martin Thomson Date: Mon, 06 May 2019 13:18:55 +0200 Message-ID: <5707914.oG825gbWTC@pintsize.usersys.redhat.com> In-Reply-To: <20190503145654.B6421404C@ld9781.wdf.sap.corp> References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <5441930.X76MtM1CnQ@pintsize.usersys.redhat.com> <20190503145654.B6421404C@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2707469.Cs2EVW077G"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.40]); Mon, 06 May 2019 11:19:07 +0000 (UTC) Archived-At: Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 11:19:11 -0000 --nextPart2707469.Cs2EVW077G Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Friday, 3 May 2019 16:56:54 CEST Martin Rex wrote: > Hubert Kario wrote: > > We've been over this Martin, the theoretical research shows that for > > Merkle- Damg=C3=A5rd functions, combining them doesn't increase their s= ecurity > > significantly. >=20 > You are completely misunderstanding the results. >=20 > The security is greatly increased! like I said, that were the follow up papers the original is still Joux: https://www.iacr.org/archive/crypto2004/31520306/multicollisions.pdf > TLSv1.2 (rsa,MD5) *cough* -- which a depressingly high number of cluele= ss > implementers actually implemented, see SLOTH SLOTH? You mean the same one in which Bhargavan and Leurent write: Concatenation: To strengthen protocols against collisions in any one= =20 hash function, it may be tempting to use a combination of two =20 independent hash functions. For example, TLS versions up to 1.1 use a=20 concatenation of MD5 and SHA-1. While the output length of this=20 construction is 288 bits, it does not offer the security of a 288-= bit=20 hash function. In particular, Joux described a multi-collision attack th= at =20 breaks the concatenation of two hash functions with roughly the sa= me =20 effort as breaking the strongest one of the two [18]. =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart2707469.Cs2EVW077G Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAlzQGB8ACgkQkqjRuAHS 9fUh1RAAh5FoYo/7UMYpIZjRyl2UbyG1dG74v7G/lsVHhZo67qjBfkGjjkwDNwnN Or5YzcSCmVVkLxI2eOQKg2uq4APFRlHsORWqWD74zaIvh1Q6cHm0y+NaKPXFkMEj y9v2tDZedUgyabxolV/IeqLJGEr51llkfkxDP2TS1pOEsN/afZQtEfei31m5sG8H 6WdqqdaxSbS4Oj7rvbw6tOaaa9cJPt4eCkEiENxwJQJr5P1ZfuOa4c/F8FXnuByH hWM2lYf0WdKTTbpgAP9Fradw1dm4yByhKvXpKN1FdMTSPu4/tOQUr9uDqdgVLrQz hvtpsbn8OtSdSI3+Yb5FfmHzXXYFtNpCegM5x6qC3SigUeQxpqUnHX58iGTuY996 vqz4lspjVOvKKXakIYnSVdgT3DltylGWMLCF98OeDMmjxU/+/vr9DWtPFhHoA4x8 J9kkPKw6poSITvDJ+Yx3qxLZsFg0jSzp9E9gDOgdlduOu0FvUO6ViHnGtqP67DkC iAYbfz65+wviWffQ2yEcSUxjIuyxalLHRyx/IQfp1cjF0ycGW6SXIQySD0fmYEuo EN1MnqpkHikU6FvW64GIOdFCAuCCRm40nBTwCjro3Z1MWqAcPoZj1heR7ZYCcCQM L7m89rX0pQktHaOrQJCzeaA8DHO7V8vfHq/YSjlZdmO6a5jOyVg= =ND21 -----END PGP SIGNATURE----- --nextPart2707469.Cs2EVW077G-- From nobody Mon May 6 04:21:51 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 134BB120145 for ; Mon, 6 May 2019 04:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYeuPW6-9Z2z for ; Mon, 6 May 2019 04:21:47 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A546C120058 for ; Mon, 6 May 2019 04:21:47 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D586659479; Mon, 6 May 2019 11:21:46 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.83]) by smtp.corp.redhat.com (Postfix) with ESMTP id 082B160C47; Mon, 6 May 2019 11:21:45 +0000 (UTC) From: Hubert Kario To: Peter Gutmann Cc: Benjamin Kaduk , "tls@ietf.org" , "mrex@sap.com" Date: Mon, 06 May 2019 13:21:44 +0200 Message-ID: <16747558.couhpb2nsq@pintsize.usersys.redhat.com> In-Reply-To: <1556904629782.23087@cs.auckland.ac.nz> References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <20190503172022.GH4464@akamai.com> <1556904629782.23087@cs.auckland.ac.nz> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart22571370.Bt9SG6LhGm"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Mon, 06 May 2019 11:21:47 +0000 (UTC) Archived-At: Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 11:21:49 -0000 --nextPart22571370.Bt9SG6LhGm Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Friday, 3 May 2019 19:30:38 CEST Peter Gutmann wrote: > Benjamin Kaduk writes: > >I'll make the obligatory note that SHA-2 is fine >=20 > Sure, and that was the really strange thing with TLS 1.2, why not just say > SHA-2 or better only, rather than adding mechanisms that were much, much > weaker than its predecessors? So the simple fix is just to use SHA-2 only > for TLS 1.2. I don't know as I wasn't there when that was discussed, but one reason coul= d=20 be the same as the problems we are facing now with RSA-PSS in TLS 1.3:=20 smartcards and HSMs that are limited to old algorithms. Also, don't forget that signature_algorithms, at least in theory[1], was=20 supposed to also influence server certificate selection, and SHA-1 was used= in=20 vast majority of certificates in PKI. > >if someone does change their system, are really going to recommend they = go > >to TLS 1.0 with MD5||SHA1 rather than TLS 1.2 with SHA2? >=20 > That would be one argument for an RFC, MUST SHA-2 only or MUST NOT MD5 and > SHA-1 in 1.2. Which is pretty much what TLS-LTS says. Or at least it ta= kes > the SHA-2-suites-mandatory path which implies no MD5 or SHA-1, I guess I > should also add an explicit MUST NOT MD5 and SHA-1. >=20 > Having said that, given an RFC saying MUST NOT 1.0 and 1.1 which is what = the > original discussion was about, why not also add MUST NOT MD5 and SHA1 in > TLS 1.2 to the text? I've already suggested it with the draft authors, the conclusion was that i= t=20 probably should be a separate RFC. 1 - while in practice one popular implementation actually used it as a=20 "required" list =E2=80=93 it would abort connections when the sigalg o= f the=20 certificate it had wasn't included in the ClientHello =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart22571370.Bt9SG6LhGm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAlzQGMgACgkQkqjRuAHS 9fXjhhAAjbfi65U1EdmfMpz0Q2fuOweBdn09N4c+rAPnApArZ/HcFdndykzB5B60 xoZnoq8iFl9Lz+AMKTidVVhEv6blBLrNrY5I+p5a0frUc350oMZ5iJyX3BPI6gmB tfjDNzGnf6FIy6EugSmgZWbq2+L/yDrBT6mxvDAeVHy6Aql5PeRf1tiakJr0/63K y75z5meoGL/0wqu70coSA28MZXdKRvLEap8kjm4pzsM6CnMFMJbGfG/JfBkMoG72 CqQSqapaGsM7hPA9Xo1ZDJAAVg3kBZT3uVWmRAi+IaiQ7zvXTxBp4phirXxfVRS2 mDx1x9QELU4udOZ/S0gtsy42ANSRtDq3Nc4KgRYa+mG/E0NrxR65YF5O3a3Nzb2x OJAhKDMzMthc4pF11p24RE0ngn2ibgmu2U0ZVLOGMRK/YbUtlq3C1ZFjqBDnYiun 1q4CjpBiesUhQiTRFL5DzQSVri9xtcms/wi0WJXq0Jpz+saAm2DZOoSZA/4VT7Sm 1816Xa1LD6cAbwGPMzLhRO9oPfbE+DsSIuHqnMkLfa9M3jZpoL0qbR0Lzm4IdmDK Zgzpw5UWJ82KktTxrVW8++JKJMM03HN8tj4E3dLBZKF6ihTsK+NBHpeY/UYdHAYF RcqeQ2BlfK0oJ7faFrEcrw7mvgsEeIIWkWLi9GDK8KXLal5T0c8= =53up -----END PGP SIGNATURE----- --nextPart22571370.Bt9SG6LhGm-- From nobody Mon May 6 04:40:23 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43F7F120119 for ; Mon, 6 May 2019 04:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTwSFQnrqBFI for ; Mon, 6 May 2019 04:40:19 -0700 (PDT) Received: from mail-yw1-xc42.google.com (mail-yw1-xc42.google.com [IPv6:2607:f8b0:4864:20::c42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CF1E120021 for ; Mon, 6 May 2019 04:40:19 -0700 (PDT) Received: by mail-yw1-xc42.google.com with SMTP id w18so10032888ywa.12 for ; Mon, 06 May 2019 04:40:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=TUvcegDMFlc6ofBgKNqRREaXN25F2lhRYaXc1V7VT+k=; b=KynlqxrAyRjOUebH71y/4oOiuzNkkJ0ehWJTkGqbGQrV4VU0We6s2A28FajYYkkPuO D4agk5K0tuxDnTlTDu1nBGGSNx78oK4F+bRYHszFiMuaKnp5hs/gMN48Bz3nGExzmzGz 0syfqkBSFOyOP1Kw/Oy/Nlf7emVCQD6sKZJXlWlLNr1A6TGtUyEjoqKzu4aRDUXX57wC cnwNTZfZKyhGogJIxODYn3dlycwbnSouyTkqevx86ND8VCoBQVAeItLl3OLSeSKAJixk OEC9DYviIqOB3KfaTt/4wBoHZ57krWu9u4vl17U4wnge8n+ICc/g68qV3+fquKQTt7tV TvwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=TUvcegDMFlc6ofBgKNqRREaXN25F2lhRYaXc1V7VT+k=; b=GUGDmMvOFtnCC+We5xH4z/RyQMtP4zxAgoZRarCk0Io1TKQFo7DmYZHdIo4XFdXqMH S8x1RmuXTRG5YbFXZIbsfW/1MKAiJMfG1C8ej4d4YFfzm1EaENnOZ9LOB8zqxycjUnnA 5/EO647EwJeykg3bN0aEEXjtu/cwjvMkO6Itf0gDeEjGtDX2a5q6kHvVPOaIJTINrMhc ajB1mkF4KZwG26BR7nriNxy9l2J8LXmZz2uwKEZxRhcQgMtfezAjrX+CH0r5YhKcQyEm AM/zNdziKS/HoExU0FSyVCE/tQtln6bwT4ymikKDT9RotOtOTLt3pQRSlHKpwtxv6vCO 8TrA== X-Gm-Message-State: APjAAAVZ5G+AlW7t5Q5GGbqefaS1mJvq0hJsWj8k4tmPBSA1nA/konkO F6Hgl2QsG5UXDfUIWaOi87dCyyWRZsYlAbAbPwG1Zko0 X-Google-Smtp-Source: APXvYqxfAkoybGoj/ij5UFOmy7JqPC7uI0MrRZ/TpfHSsUr96FUMhE7P8AcrmX+aa/LPKTTUGy9vHRa7tY28pVzWupg= X-Received: by 2002:a81:8842:: with SMTP id y63mr16621926ywf.178.1557142818325; Mon, 06 May 2019 04:40:18 -0700 (PDT) MIME-Version: 1.0 References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <7d37f7ca-e253-4c95-9cf7-2d16b0b6a0aa@www.fastmail.com> <20190430234952.21F5C404C@ld9781.wdf.sap.corp> <5441930.X76MtM1CnQ@pintsize.usersys.redhat.com> <1556902416424.28526@cs.auckland.ac.nz> <20190503172022.GH4464@akamai.com> <1556904629782.23087@cs.auckland.ac.nz> In-Reply-To: <1556904629782.23087@cs.auckland.ac.nz> From: =?UTF-8?Q?T=C3=B6ma_Gavrichenkov?= Date: Mon, 6 May 2019 14:39:52 +0300 Message-ID: To: Peter Gutmann Cc: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 11:40:21 -0000 On Fri, May 3, 2019 at 8:31 PM Peter Gutmann wr= ote: > why not also add MUST NOT MD5 and SHA1 in TLS 1.2 to the text? Because the document has now such a direct and ambitious title that ~most of the target audience won't even read the text beyond the title, hence this message won't be delivered. This is exactly the trick (but with exactly the opposite sign) PCI SSC performed three years ago when they published the document called "Migrating from SSL and Early TLS, version 1.1" and the general public widely believed that the document deprecated TLS 1.1 while what it literally meant under "Early TLS" was ultimately TLS 1.0. Only the *document version* was 1.1, but it was enough for quite a lot of people who sometimes didn't even read the document at all but rather sticked to short summaries by Arstechnica, The Register and the likes (who, in turn, quite frequently don't read documents carefully themselves). Might play well though if the title is changed. -- T=C3=B6ma From nobody Mon May 6 04:58:13 2019 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6474C120192; Mon, 6 May 2019 04:58:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tls@ietf.org Message-ID: <155714388231.6723.4595690802872592508@ietfa.amsl.com> Date: Mon, 06 May 2019 04:58:02 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-dtls-connection-id-05.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list 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 May 2019 11:58:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : Connection Identifiers for DTLS 1.2 Authors : Eric Rescorla Hannes Tschofenig Thomas Fossati Filename : draft-ietf-tls-dtls-connection-id-05.txt Pages : 15 Date : 2019-05-06 Abstract: This document specifies the Connection ID (CID) construct for the Datagram Transport Layer Security (DTLS) protocol version 1.2. A CID is an identifier carried in the record layer header that gives the recipient additional information for selecting the appropriate security association. In "classical" DTLS, selecting a security association of an incoming DTLS record is accomplished with the help of the 5-tuple. If the source IP address and/or source port changes during the lifetime of an ongoing DTLS session then the receiver will be unable to locate the correct security context. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-dtls-connection-id-05 https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls-connection-id-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-dtls-connection-id-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 6 07:39:27 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAD5C12018E for ; Mon, 6 May 2019 07:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4FI5p4mSElTE for ; Mon, 6 May 2019 07:39:23 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87BE7120052 for ; Mon, 6 May 2019 07:39:23 -0700 (PDT) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x46Eb7WW013546; Mon, 6 May 2019 15:39:21 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=dhCCg+FGQZU4a1nJWZw8h7SMMX0mmOyW0b0EXf9fFfg=; b=Wt5UTuQW9w1E8iU/0m+nc49//pmQRcaLx/gSQsAoYOMAOAFEaHdskLmYmcGyITWBFLd9 aOGFjsLnal//fvwJxwEpGLX3s8v2XbseBTC0j0cTrWMMcGOzL3+GP1yK62meEBmLR0Wc 534f4ZxePwshhWTZ72nl6ubKX9gfLsrD+1ftrQjK9nPuk28ibTqUSK7cU9LarLz+0bUX q46BiONRQ5Eipom2Fjo3X98pssIAvM0kKgVMaWfsf4WHJadJgdQJdJ0nzxzxZT7ZtquB WAkDosIEHk6+KB7SNFupLAuBysejbg/EWcCI4lGBuwF2j8mIjlpKHNi5vBPoWL7twq3X Qw== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2s90um7xkm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 06 May 2019 15:39:20 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x46EP3q1004307; Mon, 6 May 2019 10:39:20 -0400 Received: from prod-mail-relay11.akamai.com ([172.27.118.250]) by prod-mail-ppoint2.akamai.com with ESMTP id 2s962vwews-1; Mon, 06 May 2019 10:39:20 -0400 Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 5205C1FC74; Mon, 6 May 2019 14:39:18 +0000 (GMT) Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from ) id 1hNelx-0003WU-Fd; Mon, 06 May 2019 09:39:17 -0500 Date: Mon, 6 May 2019 09:39:17 -0500 From: Benjamin Kaduk To: Kathleen Moriarty Cc: "tls@ietf.org" Message-ID: <20190506143916.GJ4464@akamai.com> References: <20190430234952.21F5C404C@ld9781.wdf.sap.corp> <5441930.X76MtM1CnQ@pintsize.usersys.redhat.com> <1556902416424.28526@cs.auckland.ac.nz> <20190503172022.GH4464@akamai.com> <1556904629782.23087@cs.auckland.ac.nz> <1F7FC950-358D-4D5C-963B-B7B837AE49DA@gmail.com> <1556937973484.34949@cs.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-06_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905060124 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-06_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905060126 Archived-At: Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 14:39:26 -0000 On Sat, May 04, 2019 at 09:00:17AM -0400, Kathleen Moriarty wrote: > On Fri, May 3, 2019 at 10:46 PM Peter Gutmann > wrote: > > > Kathleen Moriarty writes: > > > > >MD5 is not discussed in the current version of RFC7525. > > > > I would add it, if this is guidance for general use then it should cover > > all > > the bases, if SHA-1 is a MUST NOT then MD5 is a REALLY REALLY REALLY MUST > > NOT. > > > > (Technically SHA-1 is still safe for ephemeral signing, i.e. locations > > where > > an attacker can't spend arbitrary amounts of time working on precomputed > > data, > > which is most of TLS because of the nonces in the handshake and the fact > > that > > connections will quickly time out if nothing arrives, but since TLS 1.2 has > > SHA-2 built in already there's probably little point in separating out > > where > > SHA-1 is safe vs. where it isn't). > > > > Sure, I agree, but needed to look through prior documents first. Since it > wasn't in RFC7525 as a recommendation and the minimum baseline was above > MD5, I suspect that is why it is not mentioned. If there is support (and > no disagreements) the text above could be added and include SHA-1 and MD5 > MUST NOT be used. The minimum baseline is already set above it though in > the statement. > > WG decision is appreciated on this point and proposed text for RFC 7525. > > Proposed: > > When using RSA, servers SHOULD authenticate using certificates with > at least a 2048-bit modulus for the public key. In addition, the use > of the SHA-256 hash algorithm is the minimum requirement, SHA-1 and > MD5 MUST not be used (see [CAB-Baseline > ] for > more details). Clients SHOULD indicate to servers that they request > SHA-256, by using the "Signature Algorithms" extension defined in > TLS 1.2. We'd probably want to wordsmith it a bit more, as there's not exactly a strict ordering on hash function strength, and "minimum requirement" could be taken to mean "MUST use SHA-256", which is presumably not the intent. -Ben From nobody Mon May 6 07:43:13 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C6FD120173 for ; Mon, 6 May 2019 07:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlX42cWFTkc4 for ; Mon, 6 May 2019 07:43:08 -0700 (PDT) Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F13DE120191 for ; Mon, 6 May 2019 07:43:07 -0700 (PDT) Received: by mail-oi1-x22f.google.com with SMTP id r136so1086083oie.7 for ; Mon, 06 May 2019 07:43:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ln8S7wil1Vm1UGZgGXEjxnuevtTk7VCebwCTh+D2pa4=; b=VvAwp+X22HoMORiKknVjLyApgCJ7MdyHnqEgno4gppj1URjrr56Ws7K8wr+JuNpjR7 9L4ZrN2JBBKnEz72ekfcHzjDL8ZEY06vIYItnIalkWYX50lyD7Jkbie6SjgBEeecGMn1 kr/1g4F0P60C1WcvXLuTMk7sT0UPo7FHwaU2R0vjqzHguN2txoym1a1yF9RCXyBcaqFn 5r6uNod/UMU3VrAKDLOVdFMI2dbqWT6Le1CV9cIFUPkYENPULiDWiNE7jwximQtUyEe/ Jipc+9h9nRRtZMmbr9Ey0IUkJZURdi0z+mvAUvdpFNyTVgJJPlmtmB0GVV3S38Rd3Pmb pqFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ln8S7wil1Vm1UGZgGXEjxnuevtTk7VCebwCTh+D2pa4=; b=k9BGGyWaKjPV1xEfLoX8zTkb+bk9P/Xg3c/2ZaDtuRE2MCCyg6B1xRBhniMhR6A9G5 3pM/+jOK96pvIYrXz+B0vAdVaUwiYJwmgl50prmTBhFCFolmkr60Z1X44wqsmOyepNq4 hS8Od5KTYOJTLm+f/V2xt9ypZFpmmqUQgj11l8tK4BPHIymAWtS0IR9jc9ggIv0bJwbp vAGwfw/cQIt4ACI9is48WJjmUl9PItFDBJQs/n9rGc1ehSSXFOwvfgMkYFb9JoRxtRiE nG0YD11n+Pwt86IqYcNyADgm3ndmixbJOzVEZ5SYk9Lq4qJTaUldstfgxhQed9aDtDF/ aAoQ== X-Gm-Message-State: APjAAAUqgF7owOf0x2dpQ46PhVqDyYLvAn93I5hffq8cIYsOQnFz7m8h UGipj/59VAGtHQ2lNNotCdMJpTsxtIzAmsFIb5A= X-Google-Smtp-Source: APXvYqz3cMoyZOK/PLfvf5f7pF6ASG+xKzvgJzkj1U9uLT5zJPz4ix7tr514WUSdEX40I3xacsNh3PvekEQhxIf6LwM= X-Received: by 2002:aca:b156:: with SMTP id a83mr1289243oif.119.1557153787227; Mon, 06 May 2019 07:43:07 -0700 (PDT) MIME-Version: 1.0 References: <20190430234952.21F5C404C@ld9781.wdf.sap.corp> <5441930.X76MtM1CnQ@pintsize.usersys.redhat.com> <1556902416424.28526@cs.auckland.ac.nz> <20190503172022.GH4464@akamai.com> <1556904629782.23087@cs.auckland.ac.nz> <1F7FC950-358D-4D5C-963B-B7B837AE49DA@gmail.com> <1556937973484.34949@cs.auckland.ac.nz> <20190506143916.GJ4464@akamai.com> In-Reply-To: <20190506143916.GJ4464@akamai.com> From: Kathleen Moriarty Date: Mon, 6 May 2019 10:42:30 -0400 Message-ID: To: Benjamin Kaduk Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="0000000000005934370588391e1e" Archived-At: Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 14:43:11 -0000 --0000000000005934370588391e1e Content-Type: text/plain; charset="UTF-8" On Mon, May 6, 2019 at 10:39 AM Benjamin Kaduk wrote: > On Sat, May 04, 2019 at 09:00:17AM -0400, Kathleen Moriarty wrote: > > On Fri, May 3, 2019 at 10:46 PM Peter Gutmann > > > wrote: > > > > > Kathleen Moriarty writes: > > > > > > >MD5 is not discussed in the current version of RFC7525. > > > > > > I would add it, if this is guidance for general use then it should > cover > > > all > > > the bases, if SHA-1 is a MUST NOT then MD5 is a REALLY REALLY REALLY > MUST > > > NOT. > > > > > > (Technically SHA-1 is still safe for ephemeral signing, i.e. locations > > > where > > > an attacker can't spend arbitrary amounts of time working on > precomputed > > > data, > > > which is most of TLS because of the nonces in the handshake and the > fact > > > that > > > connections will quickly time out if nothing arrives, but since TLS > 1.2 has > > > SHA-2 built in already there's probably little point in separating out > > > where > > > SHA-1 is safe vs. where it isn't). > > > > > > > Sure, I agree, but needed to look through prior documents first. Since > it > > wasn't in RFC7525 as a recommendation and the minimum baseline was above > > MD5, I suspect that is why it is not mentioned. If there is support > (and > > no disagreements) the text above could be added and include SHA-1 and MD5 > > MUST NOT be used. The minimum baseline is already set above it though in > > the statement. > > > > WG decision is appreciated on this point and proposed text for RFC 7525. > > > > Proposed: > > > > When using RSA, servers SHOULD authenticate using certificates with > > at least a 2048-bit modulus for the public key. In addition, the use > > of the SHA-256 hash algorithm is the minimum requirement, SHA-1 and > > MD5 MUST not be used (see [CAB-Baseline > > ] for > > more details). Clients SHOULD indicate to servers that they request > > SHA-256, by using the "Signature Algorithms" extension defined in > > TLS 1.2. > > We'd probably want to wordsmith it a bit more, as there's not exactly a > strict ordering on hash function strength, and "minimum requirement" > could be taken to mean "MUST use SHA-256", which is presumably not the > intent. > If this goes in, suggestions are welcome as we're trying to wrap this up. If it's a separate document, then I think we're done with the last call comments. Thanks, Kathleen > > -Ben > -- Best regards, Kathleen --0000000000005934370588391e1e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, May 6, 2019 at 10:39 AM Benja= min Kaduk <bkaduk@akamai.com>= ; wrote:
On Sat,= May 04, 2019 at 09:00:17AM -0400, Kathleen Moriarty wrote:
> On Fri, May 3, 2019 at 10:46 PM Peter Gutmann <pgut001@cs.auckland.ac.nz>= ;
> wrote:
>
> > Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> writes:=
> >
> > >MD5 is not discussed in the current version of RFC7525.
> >
> > I would add it, if this is guidance for general use then it shoul= d cover
> > all
> > the bases, if SHA-1 is a MUST NOT then MD5 is a REALLY REALLY REA= LLY MUST
> > NOT.
> >
> > (Technically SHA-1 is still safe for ephemeral signing, i.e. loca= tions
> > where
> > an attacker can't spend arbitrary amounts of time working on = precomputed
> > data,
> > which is most of TLS because of the nonces in the handshake and t= he fact
> > that
> > connections will quickly time out if nothing arrives, but since T= LS 1.2 has
> > SHA-2 built in already there's probably little point in separ= ating out
> > where
> > SHA-1 is safe vs. where it isn't).
> >
>
> Sure, I agree, but needed to look through prior documents first.=C2=A0= Since it
> wasn't in RFC7525 as a recommendation and the minimum baseline was= above
> MD5, I suspect that is why it is not mentioned.=C2=A0 =C2=A0If there i= s support (and
> no disagreements) the text above could be added and include SHA-1 and = MD5
> MUST NOT be used.=C2=A0 The minimum baseline is already set above it t= hough in
> the statement.
>
> WG decision is appreciated on this point and proposed text for RFC 752= 5.
>
> Proposed:
>
>=C2=A0 =C2=A0 When using RSA, servers SHOULD authenticate using certifi= cates with
>=C2=A0 =C2=A0 at least a 2048-bit modulus for the public key.=C2=A0 In = addition, the use
>=C2=A0 =C2=A0 of the SHA-256 hash algorithm is the minimum requirement,= SHA-1 and
> MD5 MUST not be used (see [CAB-Baseline
> <https://tools.ietf.org/html/rfc7525#ref= -CAB-Baseline>] for
>=C2=A0 =C2=A0 more details).=C2=A0 Clients SHOULD indicate to servers t= hat they request
>=C2=A0 =C2=A0 SHA-256, by using the "Signature Algorithms" ex= tension defined in
>=C2=A0 =C2=A0 TLS 1.2.

We'd probably want to wordsmith it a bit more, as there's not exact= ly a
strict ordering on hash function strength, and "minimum requirement&qu= ot;
could be taken to mean "MUST use SHA-256", which is presumably no= t the
intent.

If this goes in, suggestions ar= e welcome as we're trying to wrap this up.=C2=A0 If it's a separate= document, then I think we're done with the last call comments.

Thanks,
Kathleen

-Ben


--

Best regards,
Kathleen
--0000000000005934370588391e1e-- From nobody Mon May 6 10:44:57 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB981200B5 for ; Mon, 6 May 2019 10:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWQETk1ossPM for ; Mon, 6 May 2019 10:44:53 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ACBA120047 for ; Mon, 6 May 2019 10:44:53 -0700 (PDT) Received: from LLE2K16-MBX03.mitll.ad.local (LLE2K16-MBX03.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTPS id x46Hip6b028475 for ; Mon, 6 May 2019 13:44:51 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: "tls@ietf.org" Thread-Topic: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" Thread-Index: AQHU8YeGU9jNpECQ9EaWaASOKOjpG6ZN/x8AgAAFIACAAOQOgIAAZbmAgANFuACAAysPAIAD/tgAgABD4wCAAAdxAIAAAt4AgARP7QCAACf5AA== Date: Mon, 6 May 2019 17:44:48 +0000 Message-ID: <785E42E7-83FB-411F-8726-989CC8B734BC@ll.mit.edu> References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <20190503172022.GH4464@akamai.com> <1556904629782.23087@cs.auckland.ac.nz> <16747558.couhpb2nsq@pintsize.usersys.redhat.com> In-Reply-To: <16747558.couhpb2nsq@pintsize.usersys.redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.18.0.190414 x-originating-ip: [172.25.1.85] Content-Type: text/plain; charset="utf-8" Content-ID: <91E06C29BF76484DA4DFA7AA57594C19@ll.mit.edu> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-06_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=917 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905060150 Archived-At: Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 17:44:56 -0000 T24gNS82LzE5LCA3OjIyIEFNLCAiVExTIG9uIGJlaGFsZiBvZiBIdWJlcnQgS2FyaW8iIDx0bHMt Ym91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgaGthcmlvQHJlZGhhdC5jb20+IHdyb3RlOg0K ICAgID4gU3VyZSwgYW5kIHRoYXQgd2FzIHRoZSByZWFsbHkgc3RyYW5nZSB0aGluZyB3aXRoIFRM UyAxLjIsIHdoeSBub3QganVzdCBzYXkNCiAgICA+IFNIQS0yIG9yIGJldHRlciBvbmx5LCByYXRo ZXIgdGhhbiBhZGRpbmcgbWVjaGFuaXNtcyB0aGF0IHdlcmUgbXVjaCwgbXVjaA0KICAgID4gd2Vh a2VyIHRoYW4gaXRzIHByZWRlY2Vzc29ycz8gIFNvIHRoZSBzaW1wbGUgZml4IGlzIGp1c3QgdG8g dXNlIFNIQS0yIG9ubHkNCiAgICA+IGZvciBUTFMgMS4yLg0KICAgIA0KICAgIEkgZG9uJ3Qga25v dyBhcyBJIHdhc24ndCB0aGVyZSB3aGVuIHRoYXQgd2FzIGRpc2N1c3NlZCwgYnV0IG9uZSByZWFz b24gY291bGQgDQogICAgYmUgdGhlIHNhbWUgYXMgdGhlIHByb2JsZW1zIHdlIGFyZSBmYWNpbmcg bm93IHdpdGggUlNBLVBTUyBpbiBUTFMgMS4zOiANCiAgICBzbWFydGNhcmRzIGFuZCBIU01zIHRo YXQgYXJlIGxpbWl0ZWQgdG8gb2xkIGFsZ29yaXRobXMuDQoNCkhTTXMgYXJlIG1vcmUgbGlrZWx5 IHRoYW4gbm90IHRvIHN1cHBvcnQgU0hBLTIuIFNtYXJ0Y2FyZHMgcmFyZWx5IHBlcmZvcm0gaGFz aCB0aGVtc2VsdmVzLCByZWx5aW5nIG9uIHRoZSBzb2Z0d2FyZSB0aGF0IHVzZXMgdGhlbS4NCg0K DQogICAgQWxzbywgZG9uJ3QgZm9yZ2V0IHRoYXQgc2lnbmF0dXJlX2FsZ29yaXRobXMsIGF0IGxl YXN0IGluIHRoZW9yeVsxXSwgd2FzIA0KICAgIHN1cHBvc2VkIHRvIGFsc28gaW5mbHVlbmNlIHNl cnZlciBjZXJ0aWZpY2F0ZSBzZWxlY3Rpb24sIGFuZCBTSEEtMSB3YXMgdXNlZCBpbiANCiAgICB2 YXN0IG1ham9yaXR5IG9mIGNlcnRpZmljYXRlcyBpbiBQS0kuDQoNCkFsYXMuIE9ubHkgaW4gc29t ZSAoYWxiZWl0IGxhcmdlKSBlbmNsYXZlcy4NCg0KDQo= From nobody Mon May 6 10:51:24 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C88412008A for ; Mon, 6 May 2019 10:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-xdzQx4rvMt for ; Mon, 6 May 2019 10:51:19 -0700 (PDT) Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58D44120047 for ; Mon, 6 May 2019 10:51:19 -0700 (PDT) Received: by mail-oi1-x22b.google.com with SMTP id 143so10263082oii.4 for ; Mon, 06 May 2019 10:51:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UfWpg3PgFbCNMaoEhgS+XxvKRXfkw4RExvLAx1eOi7s=; b=jArGbECBz7+3bjuFh/Z0HBFWSMIseubXDCNwYFPIauPxjFSbT0epW2ra84p0AYXS79 9bt5MpfdaXFg+F6X8Yu77Lv6tW8LKpDatwA3FVYqQvBR+4Sb0Y3EUXtQd1UonrDhnu91 AxIa3Sdk1MPooHKRFzEF3ciXSl12LJrAQslWBtN3u8od4UyvW9fQlrcT2O+Puju5n8pj 7nwM5EAnLIBBzF+9bfxVMbxB2JZZwzS+VpFhwrTbTMrz/EtVZDQXyFqtd9vUGbivSBzP 3D4Wrj4dPe5JtTLjwUJ1eUpJ/wTIzf2Ju00Cktl8Tz2OiGFmbYS/V75lGjZEvgJmbEDk 5saQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UfWpg3PgFbCNMaoEhgS+XxvKRXfkw4RExvLAx1eOi7s=; b=OZRfbtucQKHuWORtZuq7ao//MgvOvASPzMPhdtoUTBaBuUrQAkMPkI6so8ZAuezBIB tXuEA+liD3a6WNHo0CjOQgX25qiw1mr/EDNDnm+hNN7OqWP8nc9vDj425j8W0WjWNJM8 z7iKxYajbmCh0q9HW2HYrJxvz1LovIT3xtcNVRo7VIf9UDPJqRny/OPlf7rlnBv2qt3Y kz7UOg8RlD91++4rLngg6adEh1sKOC3ha3fE4t6CUVN9DagkBuRRdaIw0FDM2+Q3WbDj TIU+Kr3uU6/31/XFob21YZJPLMqkFafROlyqFKPfJIZqam67KnAKVgu/lA8GhVFs/6DB 859Q== X-Gm-Message-State: APjAAAVszG3NpBhYyU44Hrm7nfX0BNQxgLeqkqVZdPJtvU3VwhpI1m5S hQoZUeYDjclwLjxHbvuKJf7eJ9a0n/rLKS3BbV0= X-Google-Smtp-Source: APXvYqy4cFpuIHGIU/VmpOtJt+AJ8SxkHNZ3KQJMTwW73evWonywHLqB9auRb4Mu8XxFq6+jSu481XgjobZxhkyee+Q= X-Received: by 2002:aca:5a07:: with SMTP id o7mr1977173oib.114.1557165078734; Mon, 06 May 2019 10:51:18 -0700 (PDT) MIME-Version: 1.0 References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <20190503172022.GH4464@akamai.com> <1556904629782.23087@cs.auckland.ac.nz> <16747558.couhpb2nsq@pintsize.usersys.redhat.com> <785E42E7-83FB-411F-8726-989CC8B734BC@ll.mit.edu> In-Reply-To: <785E42E7-83FB-411F-8726-989CC8B734BC@ll.mit.edu> From: Kathleen Moriarty Date: Mon, 6 May 2019 13:50:42 -0400 Message-ID: To: "Blumenthal, Uri - 0553 - MITLL" Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="0000000000005ff42605883bbff5" Archived-At: Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 17:51:22 -0000 --0000000000005ff42605883bbff5 Content-Type: text/plain; charset="UTF-8" On Mon, May 6, 2019 at 1:45 PM Blumenthal, Uri - 0553 - MITLL < uri@ll.mit.edu> wrote: > On 5/6/19, 7:22 AM, "TLS on behalf of Hubert Kario" on behalf of hkario@redhat.com> wrote: > > Sure, and that was the really strange thing with TLS 1.2, why not > just say > > SHA-2 or better only, rather than adding mechanisms that were much, > much > > weaker than its predecessors? So the simple fix is just to use > SHA-2 only > > for TLS 1.2. > > I don't know as I wasn't there when that was discussed, but one reason > could > be the same as the problems we are facing now with RSA-PSS in TLS 1.3: > smartcards and HSMs that are limited to old algorithms. > > HSMs are more likely than not to support SHA-2. Smartcards rarely perform > hash themselves, relying on the software that uses them. > > > Also, don't forget that signature_algorithms, at least in theory[1], > was > supposed to also influence server certificate selection, and SHA-1 was > used in > vast majority of certificates in PKI. > > Alas. Only in some (albeit large) enclaves. > Is this better suited for another (short) draft? Best, Kathleen > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Best regards, Kathleen --0000000000005ff42605883bbff5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, May 6, 2019 at 1:45 PM Blumen= thal, Uri - 0553 - MITLL <uri@ll.mit.e= du> wrote:
tls-bounces@ietf.org= on behalf of hkario= @redhat.com> wrote:
=C2=A0 =C2=A0 > Sure, and that was the really strange thing with TLS 1.2= , why not just say
=C2=A0 =C2=A0 > SHA-2 or better only, rather than adding mechanisms that= were much, much
=C2=A0 =C2=A0 > weaker than its predecessors?=C2=A0 So the simple fix is= just to use SHA-2 only
=C2=A0 =C2=A0 > for TLS 1.2.

=C2=A0 =C2=A0 I don't know as I wasn't there when that was discusse= d, but one reason could
=C2=A0 =C2=A0 be the same as the problems we are facing now with RSA-PSS in= TLS 1.3:
=C2=A0 =C2=A0 smartcards and HSMs that are limited to old algorithms.

HSMs are more likely than not to support SHA-2. Smartcards rarely perform h= ash themselves, relying on the software that uses them.


=C2=A0 =C2=A0 Also, don't forget that signature_algorithms, at least in= theory[1], was
=C2=A0 =C2=A0 supposed to also influence server certificate selection, and = SHA-1 was used in
=C2=A0 =C2=A0 vast majority of certificates in PKI.

Alas. Only in some (albeit large) enclaves.

=
Is this better suited for another (short) draft?=C2=A0=C2=A0

Best,
Kathleen=C2=A0


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


--

Best regards,
Kathleen
--0000000000005ff42605883bbff5-- From nobody Mon May 6 11:36:42 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39CD2120272 for ; Mon, 6 May 2019 11:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9VREbMwEHAy for ; Mon, 6 May 2019 11:36:27 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AAA61201CF for ; Mon, 6 May 2019 11:36:27 -0700 (PDT) Received: from [10.200.0.109] (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id 4660D46C79 for ; Mon, 6 May 2019 14:36:26 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Viktor Dukhovni In-Reply-To: <5707914.oG825gbWTC@pintsize.usersys.redhat.com> Date: Mon, 6 May 2019 14:36:25 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: IETF TLS WG Message-Id: References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <5441930.X76MtM1CnQ@pintsize.usersys.redhat.com> <20190503145654.B6421404C@ld9781.wdf.sap.corp> <5707914.oG825gbWTC@pintsize.usersys.redhat.com> To: IETF TLS WG X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 18:36:40 -0000 > On May 6, 2019, at 7:18 AM, Hubert Kario wrote: >=20 > ncatenation: To strengthen protocols against collisions in any = one =20 > hash function, it may be tempting to use a combination of = two =20 > independent hash functions. For example, TLS versions up to 1.1 use = a=20 > concatenation of MD5 and SHA-1. While the output length of = this=20 > construction is 288 bits, it does not offer the security of a = 288-bit=20 > hash function. In particular, Joux described a multi-collision = attack that =20 > breaks the concatenation of two hash functions with roughly = the same =20 > effort as breaking the strongest one of the two [18]. With the proviso that the attack on the second hash function is = *generic* (i.e. 2^{n/2} brute-force). Thus the attack on SHA-1 + MD5, has a cost of 64 * cost of SHA-1 collision + O(2^64) MD5 operations (with the = associated memory costs of finding the collision). Yes, it is far from as strong as a real 288-bit hash, and one would not choose the construction in a new standard, but in *practice* it is = likely stronger than SHA-1, even if it is far from the strength one might = na=C3=AFvely hope for. The hypothetical Joux multi-collision attack on SHA1-MD5 would have to = attack the protocol in a way that can make use of collisions rather than the = much harder to find pre-images. Are you aware of any attacks that reduce the pre-image resistance of SHA-1+MD5 to that of SHA-1? There's quite a gap between (rightly) concluding that concatenated hash functions are not a good crypto building block, to concluding that a particular construction is no stronger in practice in a particular protocol. Which is not to say that I have a concrete stength estimate for = SHA-1+MD5=20 vs. SHA-1 in TLS. Rather, the practical implication of the = multi-collisions attacks is more subtle than the basic theoretical conclusion that = invalidates their na=C3=AFve strength estimate. --=20 Viktor. From nobody Mon May 6 11:41:58 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2326E120233 for ; Mon, 6 May 2019 11:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rqId52Z4tsTv for ; Mon, 6 May 2019 11:41:42 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89B1F12022B for ; Mon, 6 May 2019 11:41:42 -0700 (PDT) Received: by straasha.imrryr.org (Postfix, from userid 1001) id DBE7446C9D; Mon, 6 May 2019 14:41:41 -0400 (EDT) Date: Mon, 6 May 2019 14:41:41 -0400 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20190506184141.GL67454@straasha.imrryr.org> Reply-To: tls@ietf.org References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <20190503172022.GH4464@akamai.com> <1556904629782.23087@cs.auckland.ac.nz> <16747558.couhpb2nsq@pintsize.usersys.redhat.com> <785E42E7-83FB-411F-8726-989CC8B734BC@ll.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.4 (2019-03-13) Archived-At: Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 18:41:57 -0000 On Mon, May 06, 2019 at 01:50:42PM -0400, Kathleen Moriarty wrote: > Is this better suited for another (short) draft? SHA-1 certificates are history now. If we're raising the floor, it should IMHO be safe to deprecate the MD5 and SHA-1 signature algorithms from TLS 1.2. Does anyone have evidence of medium to long-term requirements for continued SHA-1 sigalg support? -- Viktor. From nobody Mon May 6 12:02:50 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 302691200EF for ; Mon, 6 May 2019 12:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.508 X-Spam-Level: X-Spam-Status: No, score=-9.508 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHqxQOhb61gb for ; Mon, 6 May 2019 12:02:37 -0700 (PDT) Received: from mail-qt1-x841.google.com (mail-qt1-x841.google.com [IPv6:2607:f8b0:4864:20::841]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D55AF1201D3 for ; Mon, 6 May 2019 12:02:36 -0700 (PDT) Received: by mail-qt1-x841.google.com with SMTP id a17so1948522qth.3 for ; Mon, 06 May 2019 12:02:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=dF7ATGstTE0nmOi7ZDEoep0QltzEvI5uEBAOsic7Wj4=; b=YAnw5wrDHsDQB2reHuo23AXsKNm1pR7jI9N8bp2o6HLVCBG/Gmn1sco+4uxdyLVbuG XL6VGhpTHxUi0doayWPDsC9xpKveycR/TJbuk0QIQKgzFo77YlKKg/EiPDt7F+DnuSTD /fPM0XfiWc7YosBSCdkoD65RNGUcj/Jw38rbs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=dF7ATGstTE0nmOi7ZDEoep0QltzEvI5uEBAOsic7Wj4=; b=tn0ldtWl0lIANqILiwr3ALzCKiEQaCJohSrR/7AGkS3xqyxzktCAZ9odvYL3ku+a3W Qpmem7mdYhRHC+mklIaWj8zcIBMxu/eVpVOyUU+qEAO0Ml/l3DB4L0+We9JhL4/Aq9Ux tGuIU1qMjSYqxYgO+XkOcUpDyqe3lliKUc19r0lsUO/TX65w3Y30NL6VQvLLAjYpEfkG iq1IrIQVJkhF50OTrC4tR/gcoOUVlHms/ShnUAm54jbv4rzriGTrL4B0aKLIL/DtR1wO h1AlWuZKXeSUCE7kZd5JVma8VGYOF/YheVtnb87ao1oog8IhnAc0m7mlk9OdZgoKE/eF DNfw== X-Gm-Message-State: APjAAAVkz1AJVjs9vu/JzYFcVKxyncY8QDcaNYChLQKiSla2kjI+M71Z fvVX4D4UORqEJVQZQlon0uLS3OH4PMH8lE1tID5daZQ= X-Google-Smtp-Source: APXvYqy1dscDmCeSOS5Afh8PSB/X+L6Bu3zNa2mp6W3bT9NtjrQBqog2cmb8dT0+w092iQt+Lbgs8ncEmcQ9CWc7mwc= X-Received: by 2002:ac8:2df9:: with SMTP id q54mr22687678qta.10.1557169355631; Mon, 06 May 2019 12:02:35 -0700 (PDT) MIME-Version: 1.0 References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <20190503172022.GH4464@akamai.com> <1556904629782.23087@cs.auckland.ac.nz> <16747558.couhpb2nsq@pintsize.usersys.redhat.com> <785E42E7-83FB-411F-8726-989CC8B734BC@ll.mit.edu> <20190506184141.GL67454@straasha.imrryr.org> In-Reply-To: <20190506184141.GL67454@straasha.imrryr.org> From: David Benjamin Date: Mon, 6 May 2019 14:02:18 -0500 Message-ID: To: "" Content-Type: multipart/alternative; boundary="0000000000004c9a2905883cbe1d" Archived-At: Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 19:02:49 -0000 --0000000000004c9a2905883cbe1d Content-Type: text/plain; charset="UTF-8" On Mon, May 6, 2019 at 1:43 PM Viktor Dukhovni wrote: > On Mon, May 06, 2019 at 01:50:42PM -0400, Kathleen Moriarty wrote: > > > Is this better suited for another (short) draft? > > SHA-1 certificates are history now. If we're raising the floor, > it should IMHO be safe to deprecate the MD5 and SHA-1 signature > algorithms from TLS 1.2. > > Does anyone have evidence of medium to long-term requirements for > continued SHA-1 sigalg support? > I've been following this one for some time now. Sadly, we still see quite a lot of SHA-1 sigalg usage with RSA, even more than we see TLS 1.0 and 1.1. (We already removed SHA-1 with ECDSA a couple years ago.) Some of it is because older Schannel will preferentially sign SHA-1 when offered, which is not a problem for removal but confounds metrics. Some of it is a bug in older OpenSSLs where, on connections with SNI, it loses track of the peer signature algorithm preferences and then assumes SHA-1 by default. Some of it is load balancers which implemented TLS 1.2 but failed to actually implement sigalg negotiation, and thus only sign SHA-1. This is a consequence of text in RFC 5246 which says, when the extension is missing, the server should take SHA-1 as default. With the benefit of hindsight, I think that was a mistake. It meant bugs like OpenSSL's get papered over with SHA-1, and any implementors that chose to only sign one algorithm would pick SHA-1. https://tools.ietf.org/html/rfc5246#section-7.4.1.4.1 (This is not to say there shouldn't be text in this document or another that discourages those, or requires servers be able to sign some SHA-2 hash. But I don't expect those to be removable on the web until after TLS 1.0 and 1.1.) David --0000000000004c9a2905883cbe1d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, May 6, 2019 at 1:43 PM Viktor Duk= hovni <ietf-= dane@dukhovni.org> wrote:
On Mon, May 06, 2019 at 01:50:4= 2PM -0400, Kathleen Moriarty wrote:

> Is this better suited for another (short) draft?

SHA-1 certificates are history now.=C2=A0 If we're raising the floor, it should IMHO be safe to deprecate the MD5 and SHA-1 signature
algorithms from TLS 1.2.

Does anyone have evidence of medium to long-term requirements for
continued SHA-1 sigalg support?

I'v= e been following this one for some time now. Sadly, we still see quite a lo= t of SHA-1 sigalg usage with RSA, even more than we see TLS 1.0 and 1.1. (W= e already removed SHA-1 with ECDSA a couple years ago.) Some of it is becau= se older Schannel will preferentially sign SHA-1 when offered, which is not= a problem for removal but confounds metrics. Some of it is a bug in older = OpenSSLs where, on connections with SNI, it loses track of the peer signatu= re algorithm preferences and then assumes SHA-1 by default. Some of it is l= oad balancers which implemented TLS 1.2 but failed to actually implement si= galg negotiation, and thus only sign SHA-1.

This i= s a consequence of text in RFC 5246 which says, when the extension is missi= ng, the server should take SHA-1 as default. With the benefit of hindsight,= I think that was a mistake. It meant bugs like OpenSSL's get papered o= ver with SHA-1, and any implementors that chose to only sign one algorithm = would pick SHA-1.

(This is not to say there shou= ldn't be text in this document or another that discourages those, or re= quires servers be able to sign some SHA-2 hash. But I don't expect thos= e to be removable on the web until after TLS 1.0 and 1.1.)

David
--0000000000004c9a2905883cbe1d-- From nobody Mon May 6 16:52:51 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 601B7120124; Mon, 6 May 2019 16:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBzpBMN_SOo9; Mon, 6 May 2019 16:52:48 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE1F712011A; Mon, 6 May 2019 16:52:48 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 8BF00B81E0C; Mon, 6 May 2019 16:52:46 -0700 (PDT) To: mt@lowentropy.net, martin.thomson@gmail.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: kaduk@mit.edu, iesg@ietf.org, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20190506235246.8BF00B81E0C@rfc-editor.org> Date: Mon, 6 May 2019 16:52:46 -0700 (PDT) Archived-At: Subject: [TLS] [Errata Held for Document Update] RFC8448 (5720) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 23:52:50 -0000 The following errata report has been held for document update for RFC8448, "Example Handshake Traces for TLS 1.3". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5720 -------------------------------------- Status: Held for Document Update Type: Technical Reported by: Martin Thomson Date Reported: 2019-05-05 Held by: Benjamin Kaduk (IESG) Section: GLOBAL Original Text ------------- 00 0d 00 20 00 1e 04 03 05 03 06 03 02 03 08 04 08 05 08 06 04 01 05 01 06 01 02 01 04 02 05 02 06 02 02 02 Corrected Text -------------- 00 0d 00 18 00 16 04 03 05 03 06 03 02 03 08 04 08 05 08 06 04 01 05 01 06 01 02 01 Notes ----- The traces all show DSA signature schemes in ClientHello messages. The use of these is prohibited by RFC 8446. To be compliant, these would be removed. Note that this isn't a simple substitution as implied above. The length fields on all of the messages would also need to be reduced by 8 in addition to making the substitution. The value of the PSK binders used in the resumption case in Section 4 would need to be recalculated also. -------------------------------------- RFC8448 (draft-ietf-tls-tls13-vectors-07) -------------------------------------- Title : Example Handshake Traces for TLS 1.3 Publication Date : January 2019 Author(s) : M. Thomson Category : INFORMATIONAL Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Mon May 6 16:57:37 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA7A212011A for ; Mon, 6 May 2019 16:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9DfEGbaYv3F for ; Mon, 6 May 2019 16:57:33 -0700 (PDT) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 237D31200EA for ; Mon, 6 May 2019 16:57:33 -0700 (PDT) Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 44yfmq0B85zyWL; Tue, 7 May 2019 01:57:31 +0200 (CEST) X-purgate-ID: 152705::1557187051-0000020D-46E57FB9/0/0 X-purgate-size: 1804 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail07.wdf.sap.corp (Postfix) with ESMTPS id 44yfmp3D4RzGpH3; Tue, 7 May 2019 01:57:30 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 5F16C404C; Tue, 7 May 2019 01:57:30 +0200 (CEST) In-Reply-To: <5707914.oG825gbWTC@pintsize.usersys.redhat.com> References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <5441930.X76MtM1CnQ@pintsize.usersys.redhat.com> <20190503145654.B6421404C@ld9781.wdf.sap.corp> <5707914.oG825gbWTC@pintsize.usersys.redhat.com> To: Hubert Kario Date: Tue, 7 May 2019 01:57:30 +0200 (CEST) CC: mrex@sap.com, tls@ietf.org, Martin Thomson Reply-To: mrex@sap.com MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" Message-Id: <20190506235730.5F16C404C@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 23:57:36 -0000 Hubert Kario wrote: > On Friday, 3 May 2019 16:56:54 CEST Martin Rex wrote: >> Hubert Kario wrote: >> > We've been over this Martin, the theoretical research shows that for >> > Merkle- Damg=E5rd functions, combining them doesn't increase their sec= urity >> > significantly. >>=20 >> You are completely misunderstanding the results. >>=20 >> The security is greatly increased! >=20 > like I said, that were the follow up papers >=20 > the original is still Joux: > https://www.iacr.org/archive/crypto2004/31520306/multicollisions.pdf Thanks to Peter Gutmann for the summary: https://mailarchive.ietf.org/arch/msg/tls/g0MDCdZcHsvZefv4V8fssXMeEHs which you may have missed. >=20 >> TLSv1.2 (rsa,MD5) *cough* -- which a depressingly high number of cluel= ess >> implementers actually implemented, see SLOTH >=20 > SLOTH? SLOTH is a brainfart in the TLSv1.2 spec which is blatently obvious. If (md5,rsa) was actually shipped in a TLSv1.2 implementation, it indicates a dysfunctional (or crypto-clueless) QA for the project. The erroneous implementation of (md5,rsa) was silently removed from openssl *without* CVE, after I privately complained about this brainfart having been added to openssl. I ranted about the TLSv1.2 digitally_signed brainfart in rfc5246 on the IETF TLS WG mailing list here (01-Oct-2013): https://mailarchive.ietf.org/arch/msg/tls/l_R94xX7myvL9x8I_7L7NiDjV9w assuming that crypto clue and common sense should work. Looking at what was still affected by the problem end of 2014, it seems that you *MUST* hit TLS implementors with a CVE https://www.mitls.org/pages/attacks/SLOTH#disclosure and can not rely on crypto-clue and common sense. -Martin From nobody Tue May 7 03:34:55 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 809B91200B6 for ; Tue, 7 May 2019 03:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKDsUOKRHc-8 for ; Tue, 7 May 2019 03:34:51 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9223120043 for ; Tue, 7 May 2019 03:34:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1557225290; x=1588761290; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=M6Tmce0FSHIT4kI6sfptKWBnzUGRLJmrb762koS7XVo=; b=T6Cbuq5ZdA4GM7ZFu5Bc+TxG9ZE2pb3QfBsZaEAVmBw9ZVKN2+PQe9yp IabE+Z55dDjCG+lypoujzqrrH5B9CbEtG2Vib5wrZd7paPSBXKX7VCLUW Ws+iYMt144pY3kRzg2Zkzn4bDvBKAWiC9r6iGRSN8OglpgJI2yfXcP0zd l7gKHnl1Txpnc3RACpQupRks9fki6Txf5+Q70+1YwYZkWevJG1wBRmmln Bq5sHCDFdqj8GDNYE6zkp3YxjgEgUA6D8sUna7CURAc6YJf0nkxlNczJx edQKZOva0sN9ypUWRdm4oDsfm/H17tzPDh8CUzyeo3U9QUa0J9hWR9DzQ Q==; X-IronPort-AV: E=Sophos;i="5.60,441,1549882800"; d="scan'208";a="60899354" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.5 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-d.UoA.auckland.ac.nz) ([10.6.3.5]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 07 May 2019 22:34:46 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 7 May 2019 22:34:46 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Tue, 7 May 2019 22:34:46 +1200 From: Peter Gutmann To: David Benjamin , "" Thread-Topic: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" Thread-Index: AQHU+8+QtjVLqWiyz0WqN1BpourjtKZM43YAgADkD4CAAGW4gIADRbgAgAMrEACAA/7YAIABDIIe//8+0QCAAMtvyoADh1wAgABrBwCAAAGmAIAADj+AgAAFwgCAAc082Q== Date: Tue, 7 May 2019 10:34:46 +0000 Message-ID: <1557225285132.64735@cs.auckland.ac.nz> References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <20190503172022.GH4464@akamai.com> <1556904629782.23087@cs.auckland.ac.nz> <16747558.couhpb2nsq@pintsize.usersys.redhat.com> <785E42E7-83FB-411F-8726-989CC8B734BC@ll.mit.edu> <20190506184141.GL67454@straasha.imrryr.org>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 10:34:54 -0000 David Benjamin writes:=0A= =0A= >It meant bugs like OpenSSL's get papered over with SHA-1=0A= =0A= That affects a whole lot more than just OpenSSL, a bit like ECDSA means P25= 6=0A= so hash means SHA-1. Try switching to SHA-2 (in non-TLS usage) and you'll= =0A= find all the implementations that simply default to SHA-1, or, worse, skip = any=0A= algorithm indication that may be present and just assume the other side wil= l=0A= do SHA-1. Which so far has worked well enough that no-one's noticed that ot= her=0A= options don't.=0A= =0A= Peter.=0A= From nobody Tue May 7 04:12:35 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 787B21200A3 for ; Tue, 7 May 2019 04:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzRwdlEps0jO for ; Tue, 7 May 2019 04:12:31 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB73B120075 for ; Tue, 7 May 2019 04:12:30 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 75F683002729; Tue, 7 May 2019 11:12:30 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-200-47.brq.redhat.com [10.40.200.47]) by smtp.corp.redhat.com (Postfix) with ESMTP id 531FC5EDE4; Tue, 7 May 2019 11:12:29 +0000 (UTC) From: Hubert Kario To: mrex@sap.com Cc: tls@ietf.org, Martin Thomson Date: Tue, 07 May 2019 13:12:21 +0200 Message-ID: <4282272.YYoj4h4VMi@pintsize.usersys.redhat.com> In-Reply-To: <20190506235730.5F16C404C@ld9781.wdf.sap.corp> References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <5707914.oG825gbWTC@pintsize.usersys.redhat.com> <20190506235730.5F16C404C@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart17699942.mGFvqpWJvC"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.46]); Tue, 07 May 2019 11:12:30 +0000 (UTC) Archived-At: Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 11:12:33 -0000 --nextPart17699942.mGFvqpWJvC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Tuesday, 7 May 2019 01:57:30 CEST Martin Rex wrote: > Hubert Kario wrote: > > On Friday, 3 May 2019 16:56:54 CEST Martin Rex wrote: > >> Hubert Kario wrote: > >> > We've been over this Martin, the theoretical research shows that for > >> > Merkle- Damg=C3=A5rd functions, combining them doesn't increase their > >> > security > >> > significantly. > >>=20 > >> You are completely misunderstanding the results. > >>=20 > >> The security is greatly increased! > >=20 > > like I said, that were the follow up papers > >=20 > > the original is still Joux: > > https://www.iacr.org/archive/crypto2004/31520306/multicollisions.pdf >=20 > Thanks to Peter Gutmann for the summary: >=20 > https://mailarchive.ietf.org/arch/msg/tls/g0MDCdZcHsvZefv4V8fssXMeEHs >=20 > which you may have missed. yes, Joux paper also shows that attacking MD5||SHA1 is harder than attackin= g =20 SHA1 alone but that doesn't matter, what matters is _how much harder it is_ and Joux=20 paper says that it's less than a work factor of two, something also knows a= s a=20 "rounding error" for cryptographic attacks =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart17699942.mGFvqpWJvC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAlzRaBUACgkQkqjRuAHS 9fWEohAAjcr5kUPiQrIFshqutsf6hL9XzuRSGwMe7q33wQDMN5vFhCPQB7o2iRDt wDvq9n5PKCVsc8SCF6bR8U1mVcyqs3ctvQYcNt1vAEhExEiF0CD4MafeZLAa4yFg e6yPo3pPSb/K38LLf+awmXl1dqOz83TgnWuo5PDr/fhZ+wvSNx8J2rCR5s3c4piI lZ+otjVC5jxawjThyOe9ZCsiXrMMozJWqiQg+ylzOI5kHzNqLtx8AygIm/nyIJji uCU3sfwmxO+5pib+rb4S1iUG6JI1Vye5hlFsE0PfWb0SU0D2p6UC2mFYrFtdXeI0 xPZuYno2f0bARVZ8U7MHzUJN/5SZLMLcP5WwiVOZfC1c8rqMLZwtW63twmBEMdJF i4y42JbEPppti2zURmwx8jTVNnNxgFWvWdMTG90Z+YyM7ocWROJWTiqAsypnX/70 TU5pRWr7xhcsWHATRwaR+ENCzXXs1+0AZcLwAGNrp+jVwqfIt3s/KdAlUHScsZE1 HIUoQIl+lXLhgzpnBmRkEVsgMDsdZfOtZ5Fso2jq4+h3p/rcm8AqwLb+E8uE8XFh nsNR+mPtQbUq6Bg3zErOsl3WBtgzAkJn89ci31IxQQEyG98dpvO0TOE8Nk7oCA/I i77vIddyHPKdM1Nw2phNDFAG1s5qKvFtg11A3XUrJ3tcvyCQZy4= =05WO -----END PGP SIGNATURE----- --nextPart17699942.mGFvqpWJvC-- From nobody Tue May 7 17:32:05 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8094212013A for ; Tue, 7 May 2019 17:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnhIKcUiAsZA for ; Tue, 7 May 2019 17:32:00 -0700 (PDT) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DB4712006E for ; Tue, 7 May 2019 17:32:00 -0700 (PDT) Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 44zHV62dklzHg; Wed, 8 May 2019 02:31:58 +0200 (CEST) X-purgate-ID: 152705::1557275518-00000214-0923F7FC/0/0 X-purgate-size: 1474 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail07.wdf.sap.corp (Postfix) with ESMTPS id 44zHV50ny8zGp28; Wed, 8 May 2019 02:31:57 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 11F3B404C; Wed, 8 May 2019 02:31:57 +0200 (CEST) In-Reply-To: <4282272.YYoj4h4VMi@pintsize.usersys.redhat.com> References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <5707914.oG825gbWTC@pintsize.usersys.redhat.com> <20190506235730.5F16C404C@ld9781.wdf.sap.corp> <4282272.YYoj4h4VMi@pintsize.usersys.redhat.com> To: Hubert Kario Date: Wed, 8 May 2019 02:31:57 +0200 (CEST) CC: mrex@sap.com, tls@ietf.org, Martin Thomson Reply-To: mrex@sap.com MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20190508003157.11F3B404C@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 00:32:04 -0000 Hubert Kario wrote: >> >> Thanks to Peter Gutmann for the summary: >> >> https://mailarchive.ietf.org/arch/msg/tls/g0MDCdZcHsvZefv4V8fssXMeEHs >> >> which you may have missed. > > yes, Joux paper also shows that attacking MD5||SHA1 is harder than attacking > SHA1 alone > > but that doesn't matter, what matters is _how much harder it is_ and Joux > paper says that it's less than a work factor of two, something also knows > as a "rounding error" for cryptographic attacks collision attacks and real-time 2nd preimage attacks on randomly keyed hashes are substantially different things. simple math seems hard. TLSv1.0 + TLSv1.1 both use (rsa, MD5||SHA1) TLSv1.2 (rfc5246) permitted (rsa, MD5) and allows (rsa,SHA1) if we assumed that there *existed* (it currently doesn't, mind you) a successful preimage attack on MD5 with effort 2^20 a successful preimage attack on SHA1 with effort 2^56 then if Joux would apply not just to multicollisons, but also 2nd preimage, then the efforts would be: TLSv1.2 (rsa,MD5) 2^20 TLSv1.2 (rsa,SHA1) 2^56 TLSv1.0 (rsa, MD5||SHA1) >= 2^57 (slightly more than the stronger of the two) Comparing TLSv1.0 (rsa,MD5||SHA1) 2^57 with TLSv1.2 (rsa,MD5) 2^20 A factor 2^37 is significantly more than "marginally stronger". If you are aware of successfull 2nd preimage attacks on either MD5 or SHA1, please provide references. -Martin From nobody Wed May 8 07:27:59 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1950120129 for ; Wed, 8 May 2019 07:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=wN1V8ZrH; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=pZot8Bkw Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R74FPzbQny4Y for ; Wed, 8 May 2019 07:27:54 -0700 (PDT) Received: from new4-smtp.messagingengine.com (new4-smtp.messagingengine.com [66.111.4.230]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAD4312010C for ; Wed, 8 May 2019 07:27:54 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailnew.nyi.internal (Postfix) with ESMTP id B6CF71581A; Wed, 8 May 2019 10:27:52 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Wed, 08 May 2019 10:27:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm1; bh=CCDA+dzFxK0+E51mO6YXW1KqjFdI eT+k8dM3B0U+Ynw=; b=wN1V8ZrHgVwLXYVrGQU4ps//wVVXYzRi8SYEMbOfqlom I7uWX9djgWFz8+pf7k2tnJ31CLUOI6mrSZAwRUlYsrWF/ha91PozopuAZ+lY+x7a nfykKTMtwNlQ9ChDVwUVYtNAS8T7b9rvDmvFGST74dzsTZhrwOvb9Rp1MqwqZGUP 6CTuCvyPtw+3kfE2zJRmA5gSZL+eE+ewiByh5G/Kz625ZrnT/3tYYXe0MXAw+43k l0xYFFP+5mnMUfigunrfQ95VJUDudHusM8Zsvj/cRmiZJgqS6NctRXCRtIJZ6Eyk +DzBlQWrWDwrTcSBOfKO6d7g0KaBFWooCUulznCJOg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=CCDA+d zFxK0+E51mO6YXW1KqjFdIeT+k8dM3B0U+Ynw=; b=pZot8BkwUhrZy7qIwO9VSj jtqTHAYrkP1uUGOdpaY8O2aMydOELXuUIL0G/NGtye0JoiN7M0SHmxlpvXSxN5hH 7LUbprvzog/DahTYDerhCO5sJ59/Iq9ABzS71dGDSPXrthaQSh2GnEoTDhxf5P1B isov0p5GmEILZ/ArSdazTZ+DvqHDE1GF65oGq4xIo3RbyHShTgUv9agK62BMmN7/ 4cEXB+i0EClgqQ2lY3YJilevO/1FMVMKtv7kLIfeYTpw7xdWluLyxL0wWBC/Yjf/ 5X0ORqMMH5yhNXLQTzrV6hE4cfEwf4W/6anW5auMo/shdujhsqcOf7XXgp3Wb1XQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrkeefgdejiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfvehhrhhi shhtohhphhgvrhcuhghoohgufdcuoegtrgifsehhvggrphhinhhgsghithhsrdhnvghtqe enucffohhmrghinheprhhftgdqvgguihhtohhrrdhorhhgnecurfgrrhgrmhepmhgrihhl fhhrohhmpegtrgifsehhvggrphhinhhgsghithhsrdhnvghtnecuvehluhhsthgvrhfuih iivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1E06F2614B; Wed, 8 May 2019 10:27:48 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-449-gfb3fc5a-fmstable-20190430v1 Mime-Version: 1.0 Message-Id: <1fa3f1ec-af1b-4cfa-8806-0df2ea3ede9a@www.fastmail.com> In-Reply-To: References: <20190505223620.B3917B81F13@rfc-editor.org> <20190505231212.GA19509@kduck.mit.edu> Date: Wed, 08 May 2019 10:27:47 -0400 From: "Christopher Wood" To: "Martin Thomson" , "Benjamin Kaduk" Cc: "RFC Errata System" , rdd@cert.org, "Joe Salowey" , sean+ietf@sn3rd.com, "Martin Thomson" , "TLS@ietf.org" Content-Type: text/plain Archived-At: Subject: Re: [TLS] [Technical Errata Reported] RFC8448 (5720) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 14:27:57 -0000 +1 On Sun, May 5, 2019, at 8:32 PM, Martin Thomson wrote: > That would work for me. > > On Mon, May 6, 2019 at 9:12 AM Benjamin Kaduk wrote: > > > > I guess we want Hold For Document Update? > > > > -Ben > > > > On Sun, May 05, 2019 at 03:36:20PM -0700, RFC Errata System wrote: > > > The following errata report has been submitted for RFC8448, > > > "Example Handshake Traces for TLS 1.3". > > > > > > -------------------------------------- > > > You may review the report below and at: > > > http://www.rfc-editor.org/errata/eid5720 > > > > > > -------------------------------------- > > > Type: Technical > > > Reported by: Martin Thomson > > > > > > Section: GLOBAL > > > > > > Original Text > > > ------------- > > > 00 0d 00 20 00 1e 04 03 05 03 06 03 02 03 08 04 08 05 > > > 08 06 04 01 05 01 06 01 02 01 04 02 05 02 06 02 02 02 > > > > > > > > > > > > Corrected Text > > > -------------- > > > 00 0d 00 18 00 16 04 03 05 03 06 03 02 03 08 04 08 05 > > > 08 06 04 01 05 01 06 01 02 01 > > > > > > Notes > > > ----- > > > The traces all show DSA signature schemes in ClientHello messages. The use of these is prohibited by RFC 8446. To be compliant, these would be removed. > > > > > > Note that this isn't a simple substitution as implied above. The length fields on all of the messages would also need to be reduced by 8 in addition to making the substitution. The value of the PSK binders used in the resumption case in Section 4 would need to be recalculated also. > > > > > > Instructions: > > > ------------- > > > This erratum is currently posted as "Reported". If necessary, please > > > use "Reply All" to discuss whether it should be verified or > > > rejected. When a decision is reached, the verifying party > > > can log in to change the status and edit the report, if necessary. > > > > > > -------------------------------------- > > > RFC8448 (draft-ietf-tls-tls13-vectors-07) > > > -------------------------------------- > > > Title : Example Handshake Traces for TLS 1.3 > > > Publication Date : January 2019 > > > Author(s) : M. Thomson > > > Category : INFORMATIONAL > > > Source : Transport Layer Security > > > Area : Security > > > Stream : IETF > > > Verifying Party : IESG > From nobody Wed May 8 08:48:34 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67247120074 for ; Wed, 8 May 2019 08:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=QWR789NM; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=05M8Pgvd Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwQUJF4qIksK for ; Wed, 8 May 2019 08:48:28 -0700 (PDT) Received: from wnew3-smtp.messagingengine.com (wnew3-smtp.messagingengine.com [64.147.123.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1101C1200B7 for ; Wed, 8 May 2019 08:48:28 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailnew.west.internal (Postfix) with ESMTP id 1475F489 for ; Wed, 8 May 2019 11:48:27 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Wed, 08 May 2019 11:48:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=PXPy4ANEskLW4h2apa6dznRgXfwobpu KpKagtvHl2uc=; b=QWR789NM7rby/e7lv9ua5BLYyUVjJ4WXRRO6DWrd2Svi4IK mhLFIwMyWHXtcCvR/kuUM1LNSnPiQJjVC7Be3gmgDErFiJLzAh7wN4l6zjOEJ/HE 40tpIBZpkZ66Kyug4Pr1C9s0dsDISdUhVvo26UBcQ2do+cVIMT7MCzLKhsYEjzIp p2xWE5Q8aNAHJ6rOU/xp/V3Z2pWRYp/4UYHDr0MqIUQwVHcrEBEiKIZ3/boDE6fs lYUpTawPGNtWFd47td7UX7j4aAnXcDU7C4zeCjfDMhKB9NCWURHVv8wA0gTH++1N lNNqeMniD/goMP94MNNcR5cBgN62CqB6vYdy2nw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=PXPy4A NEskLW4h2apa6dznRgXfwobpuKpKagtvHl2uc=; b=05M8PgvdXhppBTyHidCYdc JFT4etNehkId0a7jbPt55CoM06Q4cgYl/eZ7A+0SuN30U5Ebm0N5OfJON86Wt+CU vJEYa57ajRSdhaioEQrOwj25GVH+FcAdK0Iqcq0F6QQiw8XUmbHcO1xgHrVkp+r+ UhHV4t3WKzCREZNL/2rlBRnKcbdb0+L8y3i+xIxIgYqpFVjyKD62Wo3IMWa5k2Yn XEw6me+2Qx1zvW4uB5U0hExnh/+DLiJiLX2hoOcUPLluMqFuc+KvZXw0oS7Uydq/ 2keeONfxL5rFWGgnmsxh6z5AT4m110PzHiKDB6K4wUYymVbtdpHi24Asy8CdXtGQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrkeefgdelfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdevhhhrihhsthhophhhvghrucghohhougdfuceotggrfies hhgvrghpihhnghgsihhtshdrnhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrtghomh enucfrrghrrghmpehmrghilhhfrhhomheptggrfieshhgvrghpihhnghgsihhtshdrnhgv thenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id B3830260C3; Wed, 8 May 2019 11:48:25 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-449-gfb3fc5a-fmstable-20190430v1 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 08 May 2019 11:48:20 -0400 From: "Christopher Wood" To: "TLS@ietf.org" Content-Type: text/plain Archived-At: Subject: Re: [TLS] draft-ietf-tls-dtls13-31 comments X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 15:48:32 -0000 Thanks for the review, David! Please see inline below for comments. On Wed, Apr 3, 2019, at 12:43 PM, David Benjamin wrote: > Hi all, > > I read through draft-ietf-tls-dtls13-31 and gathered a bunch of > comments. I uploaded https://github.com/tlswg/dtls13-spec/pull/85 for > the easy bits. The remainder I figured I should send to the list. > Hopefully this is a usable format. Apologies for the very late look > over it. I haven't had time to page it in before now. > > In section 4, I assume that if not negotiated, CID cannot be present > and the receiver rejects any records with it? It might be worth > spelling that out explicitly. That's my understanding as well. > Section 4.2.1 reads odd to me. I assume the references to 1 and 2 are > just as an example and not a particular oddity from those epochs. Maybe > stick a "for example" or say "earlier and later epoch". It also says > that during the handshake, "implementations MUST accept packets from > the old epoch", which is ambiguous as there are several epochs in the > handshake. That sentence also runs counter to the SHOULD immediately at > the start of the paragraph, which is odd. Agreed that some clarifying text would help hear. > Section 4..5.1 talks about timing channels for the sequence number. > Note even uncompressing the sequence number (finding the right upper > bytes) introduces a timing channel. Granted, it is a much much weaker > one than record deprotection, but invalid DTLS records being non-fatal > means signals can be amplified.... Perhaps the text could acknowledge this additional, albeit smaller timing channel? > Section 5 says that implementations MUST ignore ChangeCipherSpec > messages. This contradicts section 4.1, which does not include > change_cipher_spec as one of the possible record rtypes for > DTLSPlaintext. It does fall through to section 4.5.2, but 4.5.2 allows > for implementations to reject these. (Is there actually a need to > ignore them in DTLS 1.3 if the middlebox hacks aren't applicable?) Perhaps 4.1 could leave a comment saying change_cipher_spec is not permitted, along with a forward pointer to Section 5? > I don't understand the last paragraph of section 5.1. What's it trying > to describe? If the client got its hands on an invalid cookie, there's > no recovering that handshake. The server won't accept the cookie, and > the client won't accept a second HRR. Perhaps what's missing is precisely that clarifying statement. Namely, that clients which find themselves in such a situation cannot recover. > Section 5.3 says that the supported_versions extension is used without > modification from TLS 1.3, but that still leaves its contents > ambiguous. Is DTLS 1.3 0304 or fefc? I assume 0304 since fefc isn't > mentioned. But then how are DTLS 1.0 and DTLS 1.2 encoded? (One could > imagine omitting them, but that doesn't match how TLS 1.3 did it.) I > assume they remain feff and fefd, so we don't need to answer whether > DTLS 1.0 is 0301 or 0302. Either way, this should probably be spelled > out. My interpretation was 0304 as well. > This is a nitpick and exists in DTLS 1.2 too, but section 5.4 uses the > term "maximum handshake fragment size", but nowhere else in the > document is the term defined or referenced. This means the largest > handshake fragment such that the resulting DTLS record fits in a > packet. (Though even that's incomplete because you might have > previously allocated a smaller fragment and then have less room left > for the next fragment. It gets further messier when packing fragments > into records and having to worry about when you are and aren't forced > to add a record boundary for epoch change...) +1 -- defining this term would be good. > > Section 5.9 is weird. With warning alerts gone, all alerts are fatal. > Either you've torn down all local state and don't resend alerts (I > suspect most applications just do this, for better or worse), or maybe > you're hanging around for a while to resend them. If the latter, you > probably don't want to be trying to detect that the offending record > got resent, since that involves processing records out of a connection > in an error state. It seems better to blindly retransmit on every > packet until you get bored. > > Relatedly, what does close_notify mean in DTLS? This draft and DTLS 1.2 > don't seem to make any mention of it. Bidirectional shutdown doesn't > make much sense. Not sure if unidirectional is meaningful, given lack > of retransmits. Maybe a best effort thing to save the peer a timeout. +1 > > Section 6.1 says: > > Implementations that receive a payload with an epoch value for which > no corresponding cipher state can be determined MUST generate a > "unexpected_message" alert. > > This seems to be cover data from the next epoch, which contradicts > section 4.2.1. (If I receive, say, EncryptedExtensions before > ServerHello, I can't determine the cipher state for that epoch.) > Section 4.2.1 says you should either buffer or drop those records, not > reject them. Good catch. This should probably be cleaned up to ensure out-of-order handshake packets are handled correctly and do not yield an alert. > > Section 7 defines ACKs with a uint64 record_number. I assume this is a > concatenated epoch and sequence number, but I don't see anywhere > defines this. Perhaps just write it as: > > struct { > uint16 epoch; > uint48 sequence_number; > } RecordNumber; > > struct { > RecordNumber record_numbers<0..2^16-1>; > } ACK; Good clarification! > > Relatedly, what is the "record sequence number" input to the AEAD (RFC > 8446, section 5.3)? DTLS believes that the "sequence number" is 48 > bits, but the rest of TLS 1.3 is written expecting a 64-bit sequence > number. Using the concatenation is simplest and also matches RFC 7905, > but should be mentioned explicitly. (RFC 6347 didn't have text to this > effect because it only had AES-GCM which, in (D)TLS 1.2, used explicit > IVs.) > > (I will probably have other comments on the ACK bits, but I think I > need to digest it more carefully to try to understand what's going on. > It does seem a little overkill for what is ultimately a small handful > of packets...) Sounds good. Thanks again for the review! Ekr, Hannes, Nagendra: can you please have a look through the comments and try to address them? Best, Chris From nobody Wed May 8 19:24:59 2019 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A169F120229; Wed, 8 May 2019 19:24:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Sean Turner via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Cc: Sean Turner , iesg-secretary@ietf.org, tls-chairs@ietf.org, sean@sn3rd.com, tls@ietf.org Message-ID: <155736869765.22686.7086155881125442695.idtracker@ietfa.amsl.com> Date: Wed, 08 May 2019 19:24:57 -0700 Archived-At: Subject: [TLS] Publication has been requested for draft-ietf-tls-certificate-compression-05 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list 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 May 2019 02:24:58 -0000 Sean Turner has requested publication of draft-ietf-tls-certificate-compression-05 as Proposed Standard on behalf of the TLS working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-tls-certificate-compression/ From nobody Wed May 8 23:09:01 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0644912008C for ; Wed, 8 May 2019 23:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtNdEObKDUDF for ; Wed, 8 May 2019 23:08:56 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D782F120052 for ; Wed, 8 May 2019 23:08:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1557382136; x=1588918136; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=0lNR96zuL/xqCwS0m7V9fWtMB0W52houPBxhlE75avo=; b=eXlon9k8M1pc4NbLL5UK1N1zBpEBn2KrxxDWHTw2FTzdrKw3dNuJ4Xcl XP8Nt0scM0MbvbQP0318vh/V0UE91zv7ClicKbyZbkOMSpT+nuoS8Tgxs jsh7nTnpVlEk5jPtdszbp+EjP0N4w3uIdip7vTiKrwxgiiTV7KXTcMPp1 D0VfFr2OYoKFFcQcWcGB4MrsRT8oNs1jXs8+601+hx5A1rHLWLyaKYBtI V7G+qHuyIl0afQ7JM1OppAGnb98UwTrC7NjtS5caIvPH1iebnNoJme5Ei fmencoptUMijI9stY0Bp17OG+2BV14QEsuBXYcq5LAsw6E8EjZ1fsJyHK w==; X-IronPort-AV: E=Sophos;i="5.60,448,1549882800"; d="scan'208";a="61309338" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.5 - Outgoing - Outgoing Received: from uxcn13-tdc-d.uoa.auckland.ac.nz ([10.6.3.5]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 09 May 2019 18:08:52 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 9 May 2019 18:08:50 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Thu, 9 May 2019 18:08:50 +1200 From: Peter Gutmann To: Benjamin Kaduk , Kathleen Moriarty CC: "tls@ietf.org" Thread-Topic: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" Thread-Index: AQHU+8+QtjVLqWiyz0WqN1BpourjtKZM43YAgADkD4CAAGW4gIADRbgAgAMrEACAA/7YAIABDIIe//8+0QCAAMtvyv//YEgAgAADegCAAAh5AIABLdvl///kJYAAaApugACeHOyW Date: Thu, 9 May 2019 06:08:50 +0000 Message-ID: <1557382125808.42665@cs.auckland.ac.nz> References: <20190430234952.21F5C404C@ld9781.wdf.sap.corp> <5441930.X76MtM1CnQ@pintsize.usersys.redhat.com> <1556902416424.28526@cs.auckland.ac.nz> <20190503172022.GH4464@akamai.com> <1556904629782.23087@cs.auckland.ac.nz> <1F7FC950-358D-4D5C-963B-B7B837AE49DA@gmail.com> <1556937973484.34949@cs.auckland.ac.nz> , <20190506143916.GJ4464@akamai.com> In-Reply-To: <20190506143916.GJ4464@akamai.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 06:08:59 -0000 Benjamin Kaduk writes:=0A= =0A= >We'd probably want to wordsmith it a bit more, as there's not exactly a=0A= >strict ordering on hash function strength, and "minimum requirement" could= be=0A= >taken to mean "MUST use SHA-256", which is presumably not the intent.=0A= =0A= You could just say "use SHA-2", which covers the whole family. Now in=0A= practice "SHA-2" means "SHA-256" so it'll be the same as saying SHA-256=0A= directly, but the more generic SHA-2 leaves it open to interpretation for t= he=0A= three people who use something other than SHA-256.=0A= =0A= Peter.=0A= From nobody Wed May 8 23:41:19 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3A4912011A for ; Wed, 8 May 2019 23:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=d3G9Qs4C; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=tzqs5gv9 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHWTBDvrr0vM for ; Wed, 8 May 2019 23:41:16 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2782120114 for ; Wed, 8 May 2019 23:41:15 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 193EA346 for ; Thu, 9 May 2019 02:41:15 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Thu, 09 May 2019 02:41:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=dccMHKT+ml2Q2ZOHDvni85HrJiNMdFe 2+Wpe1C+bGZs=; b=d3G9Qs4CHv82+da+KNdBGJ6A3bJhZOxacXKI8XnPzWVRpE9 sW8S2YWSFF9QDPbxD3WmU+LCiqxi/amaPsF3HPS9Gfsfu4/n/tcebJDzw9JHjFRE 1FSLp9HoIIr6R+MqVtECbZgQk/388qNCLeOgE0V61L3BXXFcWBbJ4lkAHiDE4s7x R5Wv+Yu2wj2MbGlC7fh8A57gvYEBwcSaD7zyXFfLx5oQajLY+ksNMx4WG5tU+TNy RYNKExZ9GTglKqEgFlXa9sO8/vUoUglXYaYAxe3qM/SR7e1rFAGEZXWS3xj8tFn3 Kd1tiYtoSKCea4skBR+jj/Av+Pp3y3QW0HpU64w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=dccMHK T+ml2Q2ZOHDvni85HrJiNMdFe2+Wpe1C+bGZs=; b=tzqs5gv9wPLT7qLMrtY8Ez IHpz2pBOOIkX4zt15D88Jre5FtV4uaXTYCwu484V81V8Nt9caN3rymkOdxz3+bp0 chm34g7IRa/JBb203+JtqOWKriTtBjT5yJxa/LbrhQrShiB5Va81XeD0kr+folIe Y7EjgNg6sgm7wZOlUofh5Z3G8jQ5rOupQXBDDNYfeqzuBYmLWsDGLZWdlIKr71+D SRld5SekXc0jScy07/tsJjBDNoRQezKLMi1jBN0q4yCxCmYiOaD/+qdSQaim1/Jb wRuGts8xtoRrnI/4x29uKn8/m2MqSGMS4BXVq4lwc9ZJFSVVOyowgabFu2Lv7low == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrkeeggddutdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehloh ifvghnthhrohhphidrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 258897C6D9; Thu, 9 May 2019 02:41:14 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-449-gfb3fc5a-fmstable-20190430v1 Mime-Version: 1.0 Message-Id: <64cadfbb-46c7-4b95-906b-a04f66dcc5d7@www.fastmail.com> In-Reply-To: <1557382125808.42665@cs.auckland.ac.nz> References: <20190430234952.21F5C404C@ld9781.wdf.sap.corp> <5441930.X76MtM1CnQ@pintsize.usersys.redhat.com> <1556902416424.28526@cs.auckland.ac.nz> <20190503172022.GH4464@akamai.com> <1556904629782.23087@cs.auckland.ac.nz> <1F7FC950-358D-4D5C-963B-B7B837AE49DA@gmail.com> <1556937973484.34949@cs.auckland.ac.nz> <20190506143916.GJ4464@akamai.com> <1557382125808.42665@cs.auckland.ac.nz> Date: Thu, 09 May 2019 02:41:15 -0400 From: "Martin Thomson" To: tls@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 06:41:18 -0000 On Thu, May 9, 2019, at 16:09, Peter Gutmann wrote: > You could just say "use SHA-2", which covers the whole family. Now in > practice "SHA-2" means "SHA-256" so it'll be the same as saying SHA-256 > directly, but the more generic SHA-2 leaves it open to interpretation for the > three people who use something other than SHA-256. Though I don't think we'll see it happen any time soon, I don't think we want to completely close the door on new hash functions. SHA-3 might be dead, but that doesn't mean we won't eventually be motivated to move to another one. >From memory, we see a non-trivial amount of SHA-384, though that might just be in its pairing with AES-256-GCM. It's routinely paired with P-384, which we do get a little bit of. We even have P-521 in quantities large enough that we can't turn it off, which is likely paired with SHA-512. From nobody Thu May 9 02:25:34 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84403120090 for ; Thu, 9 May 2019 02:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMWpLGBWqIz7 for ; Thu, 9 May 2019 02:25:31 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B03B120088 for ; Thu, 9 May 2019 02:25:31 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 65B878124B; Thu, 9 May 2019 09:25:26 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-200-43.brq.redhat.com [10.40.200.43]) by smtp.corp.redhat.com (Postfix) with ESMTP id 63EBA5D9D1; Thu, 9 May 2019 09:25:24 +0000 (UTC) From: Hubert Kario To: mrex@sap.com Cc: tls@ietf.org, Martin Thomson Date: Thu, 09 May 2019 11:25:17 +0200 Message-ID: <14984380.sTCEapK0kV@pintsize.usersys.redhat.com> In-Reply-To: <20190508003157.11F3B404C@ld9781.wdf.sap.corp> References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <4282272.YYoj4h4VMi@pintsize.usersys.redhat.com> <20190508003157.11F3B404C@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2253522.FU5mkEJXQy"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Thu, 09 May 2019 09:25:30 +0000 (UTC) Archived-At: Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 09:25:34 -0000 --nextPart2253522.FU5mkEJXQy Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Wednesday, 8 May 2019 02:31:57 CEST Martin Rex wrote: > Hubert Kario wrote: > >> Thanks to Peter Gutmann for the summary: > >> https://mailarchive.ietf.org/arch/msg/tls/g0MDCdZcHsvZefv4V8fssXMe= EHs > >>=20 > >> which you may have missed. > >=20 > > yes, Joux paper also shows that attacking MD5||SHA1 is harder than > > attacking SHA1 alone > >=20 > > but that doesn't matter, what matters is _how much harder it is_ and Jo= ux > > paper says that it's less than a work factor of two, something also kno= ws > > as a "rounding error" for cryptographic attacks >=20 > collision attacks and real-time 2nd preimage attacks on randomly keyed > hashes are substantially different things. >=20 > simple math seems hard. >=20 >=20 > TLSv1.0 + TLSv1.1 both use (rsa, MD5||SHA1) >=20 > TLSv1.2 (rfc5246) permitted (rsa, MD5) and allows (rsa,SHA1) side note on that, with ECDSA, all three versions use (ecdsa, sha1) so=20 everything we are discussing applies to RSA and RSA only > if we assumed that there *existed* (it currently doesn't, mind you) >=20 > a successful preimage attack on MD5 with effort 2^20 > a successful preimage attack on SHA1 with effort 2^56 >=20 > then if Joux would apply not just to multicollisons, but also 2nd preimag= e, >=20 > then the efforts would be: >=20 > TLSv1.2 (rsa,MD5) 2^20 > TLSv1.2 (rsa,SHA1) 2^56 >=20 > TLSv1.0 (rsa, MD5||SHA1) >=3D 2^57 (slightly more than the stronger of = the > two) >=20 >=20 > Comparing TLSv1.0 (rsa,MD5||SHA1) 2^57 with TLSv1.2 (rsa,MD5) 2^20 >=20 > A factor 2^37 is significantly more than "marginally stronger". MD5 was deprecated and removed by basically every library and can't be used= in=20 TLS 1.2, I specifically meant SHA1 > If you are aware of successfull 2nd preimage attacks on > either MD5 or SHA1, please provide references. "attacks only get better with time" =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart2253522.FU5mkEJXQy Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAlzT8f0ACgkQkqjRuAHS 9fU97hAAhvSechQvjgelU2wfocUeUAVqmnw7vpx5Zv3KPd2h6gAbOKUgymK8ZZdr 68vSnGP1XwJLpJMsCWQEAI2qr4JNCO9h76ECW4E5spaR4+sa9mOwU2HEBpwR8tIH /FrIwgcsK2br4+h+wH3Wt6+TB1WnWYjCO4QXxcycSKZhyKw3IIfKXOVVa0sbMI5L /zSSSQ9IVbf2tj0Qa+PB2bRw22EdG6afkrL0132Fi/wF7sw2efrqcslwHVid3b9A shWCR/LMQHfy+oj6DAGJQbE7QqE60lQb/clY8ZcteekcxgqKDbiO0MSdGxoXQ5CQ oiEeGx6G0Xm9HSksOZGXorAcvrChOFqXbt6EwJn+YYWWyPjzEfj/AWaZABdvJS01 Tz1AWkaHputpC5TdoV8+t8RQqHQ+7UF6Y1DljJfVl7MKC5745Vcn4EbaeIgMGmPC dDHO/n3K+sW9la9/ymkH1aNQrobaS2E8Wc4CdSN/zWC2lIgZw7kaHQ8o0825waEC WEuisSSxCtTKVrF4QNt/0D4Ss+N4pOg0n+44u4o9Ma2CSsW31OemjcuPEiXB6/Ih D8+IVimRKNjszR8m8NS9g360fU1B41rdSqBXrV+w6U/nnCHHFuGqsiKA3vCxkqel BfKDb3174lsfl+GSkZMcUc5iJI9CNX/qZ67ZFZ3x/U6FfcWJgoI= =oGmE -----END PGP SIGNATURE----- --nextPart2253522.FU5mkEJXQy-- From nobody Thu May 9 06:26:38 2019 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DF64512015A; Thu, 9 May 2019 06:26:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tls@ietf.org Message-ID: <155740839181.24680.1599934148855154869@ietfa.amsl.com> Date: Thu, 09 May 2019 06:26:31 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-tls13-cert-with-extern-psk-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list 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 May 2019 13:26:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : TLS 1.3 Extension for Certificate-based Authentication with an External Pre-Shared Key Author : Russ Housley Filename : draft-ietf-tls-tls13-cert-with-extern-psk-01.txt Pages : 10 Date : 2019-05-09 Abstract: This document specifies a TLS 1.3 extension that allows a server to authenticate with a combination of a certificate and an external pre- shared key (PSK). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-tls13-cert-with-extern-psk-01 https://datatracker.ietf.org/doc/html/draft-ietf-tls-tls13-cert-with-extern-psk-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-tls13-cert-with-extern-psk-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 9 06:29:38 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47DCA1200E5 for ; Thu, 9 May 2019 06:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5eVp4aMrC6U for ; Thu, 9 May 2019 06:29:31 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3BA61200DB for ; Thu, 9 May 2019 06:29:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 7E83A300AA2 for ; Thu, 9 May 2019 09:10:13 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id FLfv3COWpe2H for ; Thu, 9 May 2019 09:10:11 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id AB0243005D6 for ; Thu, 9 May 2019 09:10:11 -0400 (EDT) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_C53D6F5B-F692-458B-AB08-6710A3AA0DE9" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Thu, 9 May 2019 09:29:28 -0400 References: <155740839181.24680.1599934148855154869@ietfa.amsl.com> To: IETF TLS In-Reply-To: <155740839181.24680.1599934148855154869@ietfa.amsl.com> Message-Id: <4F70AF3B-83B7-47A6-8284-4EC14B3429F7@vigilsec.com> X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-tls13-cert-with-extern-psk-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 13:29:35 -0000 --Apple-Mail=_C53D6F5B-F692-458B-AB08-6710A3AA0DE9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I received some editorial suggestions by private email during WG Last = Call. This update implements those suggestions. Here is the URL for the diff: = https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-tls-tls13-cert-with-extern-= psk-00&url2=3Ddraft-ietf-tls-tls13-cert-with-extern-psk-01&difftype=3D--hw= diff = Enjoy, Russ > On May 9, 2019, at 9:26 AM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Transport Layer Security WG of the = IETF. >=20 > Title : TLS 1.3 Extension for Certificate-based = Authentication with an External Pre-Shared Key > Author : Russ Housley > Filename : = draft-ietf-tls-tls13-cert-with-extern-psk-01.txt > Pages : 10 > Date : 2019-05-09 >=20 > Abstract: > This document specifies a TLS 1.3 extension that allows a server to > authenticate with a combination of a certificate and an external = pre- > shared key (PSK). >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk= / >=20 > There are also htmlized versions available at: > = https://tools.ietf.org/html/draft-ietf-tls-tls13-cert-with-extern-psk-01 > = https://datatracker.ietf.org/doc/html/draft-ietf-tls-tls13-cert-with-exter= n-psk-01 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-tls13-cert-with-extern-= psk-01 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ --Apple-Mail=_C53D6F5B-F692-458B-AB08-6710A3AA0DE9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = received some editorial suggestions by private email during WG Last = Call.  This update implements those suggestions.

Here is the URL for the diff: https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-tls-tls13-cert-w= ith-extern-psk-00&url2=3Ddraft-ietf-tls-tls13-cert-with-extern-psk-01&= amp;difftype=3D--hwdiff

Enjoy,
  Russ


On May 9, 2019, at 9:26 AM, internet-drafts@ietf.org wrote:


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

=        Title =           : TLS 1.3 = Extension for Certificate-based Authentication with an External = Pre-Shared Key
=        Author =          : Russ Housley
= Filename        : = draft-ietf-tls-tls13-cert-with-extern-psk-01.txt
Pages =           : 10
= Date =            : = 2019-05-09

Abstract:
=   This document specifies a TLS 1.3 extension that allows a = server to
  authenticate with a combination of = a certificate and an external pre-
  shared key = (PSK).


The IETF datatracker = status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with= -extern-psk/

There are also htmlized = versions available at:
https://tools.ietf.org/html/draft-ietf-tls-tls13-cert-with-exte= rn-psk-01
https://datatracker.ietf.org/doc/html/draft-ietf-tls-tls13-cert= -with-extern-psk-01

A diff from the = previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-tls13-cert-w= ith-extern-psk-01


Please = note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at = tools.ietf.org.

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

= --Apple-Mail=_C53D6F5B-F692-458B-AB08-6710A3AA0DE9-- From nobody Thu May 9 07:11:19 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0170412027E for ; Thu, 9 May 2019 07:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FnBGYvMFfW6G for ; Thu, 9 May 2019 07:11:01 -0700 (PDT) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B6DA1202FD for ; Thu, 9 May 2019 07:11:01 -0700 (PDT) Received: by mail-io1-xd2c.google.com with SMTP id f22so1512380iol.11 for ; Thu, 09 May 2019 07:11:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=TPoGIk15fm0cbekkJ7seR9k9wMqyajJQv6o3BTVtdVk=; b=Dc+thns0ofowL+a0e4X+09CkMCTkK72lUet7m5DgIbMy42w6BlLg2jVaIKR0SZNJwv q4HEx8LirOqZpWIzqPIiIp6nlSghc6aRiW+yVqLg1FVTBz57v4KNGim7KbfcX9CahhIy a40N9GvvWYzW73kl6KkkcuvEmFsWHrA/UOTfiN91c8YtH0IBmc4GlAsN7Eek3SJn3geV p7QrgORp4Wczqr1uqRgO/2rzMDpI7Z6lPaF8AAE7d2KrUUrlWAUP4vku59nBgGcOHi0F Q44TdeN1iXp8awGC5IeXoyAlR5IvUmulTurCkFaqhBx2fYI2uPaynV77Igmhaj/jZ0ZU RVHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=TPoGIk15fm0cbekkJ7seR9k9wMqyajJQv6o3BTVtdVk=; b=neW9r1urm1aASAWL2leabcSzltxcfO6N7qcGHwo8jK2T6ltdC3Mj3bixDYMvP22+B7 aHlAU6Vqyh8fpYg0RIMdZd28fI9TzuYOGwtF9dSap++1+m8lR5XQfWFg18hWePfsdAEB 25b1Z7GYb8kdIvE6dJQU2/MO3L0tu3vKFBaBmlMPgMA9eyNorGV3THUcZuHVZ4cmAbEn /o8C8AViJWIu8g+IxXxZ2B0XUCQ7PV+c2rQDRPVI39UiHUENEqcbYqNnEQh7Ec/VZgKp 7gMyTHnRcFC+6xJKxV4LSU3t+y1TrcBdtbFpLNkXRX16j5MTgBIEz0ddsoo13HdTg4Hn PxXA== X-Gm-Message-State: APjAAAVNCMKFLksQDk4acWyEvXml/o77p3qdqu8aFBPSWvG3Gtwhpc2P FEfHJdqVXqCsATOXRzvwTz1iEingNPFuTX3Y4RhS4NkP X-Google-Smtp-Source: APXvYqyafo4rciiHRlWGYrkUnhkEabNif1HY4WWhvj5v3a/156vvsYV0RPI/P0gSWl2jsDq42k9C2pSt42tBiDv6o54= X-Received: by 2002:a6b:c945:: with SMTP id z66mr2618781iof.191.1557411060404; Thu, 09 May 2019 07:11:00 -0700 (PDT) MIME-Version: 1.0 From: Loganaden Velvindron Date: Thu, 9 May 2019 18:10:48 +0400 Message-ID: To: "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [TLS] Proposal to deprecate sha1 and md5 for digital signatures in TLS 1.2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 14:11:10 -0000 Hi all, Following the recent thread on TLS 1.0 and TLS 1.1 deprecation, we came up with a proposal to deprecate md5 and sha1 for digital signatures in the TLS 1.2 spec. Please find the draft at this url: https://tools.ietf.org/html/draft-lvelvindron-tls-md5-sha1-deprecate-03 We look forward to your feedback. From nobody Thu May 9 15:24:58 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 588D11200F8 for ; Thu, 9 May 2019 15:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjooDKoWHzp6 for ; Thu, 9 May 2019 15:24:52 -0700 (PDT) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E43C1200EC for ; Thu, 9 May 2019 15:24:52 -0700 (PDT) Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 450SZV177zzyR5; Fri, 10 May 2019 00:24:50 +0200 (CEST) X-purgate-ID: 152705::1557440690-00000218-9DA1C408/0/0 X-purgate-size: 4645 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail07.wdf.sap.corp (Postfix) with ESMTPS id 450SZT4xSGzGnyX; Fri, 10 May 2019 00:24:49 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 9C553404C; Fri, 10 May 2019 00:24:49 +0200 (CEST) In-Reply-To: <14984380.sTCEapK0kV@pintsize.usersys.redhat.com> References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <4282272.YYoj4h4VMi@pintsize.usersys.redhat.com> <20190508003157.11F3B404C@ld9781.wdf.sap.corp> <14984380.sTCEapK0kV@pintsize.usersys.redhat.com> To: Hubert Kario Date: Fri, 10 May 2019 00:24:49 +0200 (CEST) CC: mrex@sap.com, tls@ietf.org, Martin Thomson Reply-To: mrex@sap.com MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20190509222449.9C553404C@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 22:24:57 -0000 Hubert Kario wrote: >On Wednesday, 8 May 2019 02:31:57 CEST Martin Rex wrote: >> Hubert Kario wrote: >>>> Thanks to Peter Gutmann for the summary: >>>> https://mailarchive.ietf.org/arch/msg/tls/g0MDCdZcHsvZefv4V8fssXMeEHs >>>> >>>> which you may have missed. >>> >>> yes, Joux paper also shows that attacking MD5||SHA1 is harder than >>> attacking SHA1 alone >>> >>> but that doesn't matter, what matters is _how much harder it is_ and Joux >>> paper says that it's less than a work factor of two, something also knows >>> as a "rounding error" for cryptographic attacks >> >> collision attacks and real-time 2nd preimage attacks on randomly keyed >> hashes are substantially different things. >> >> simple math seems hard. >> >> >> TLSv1.0 + TLSv1.1 both use (rsa, MD5||SHA1) >> >> TLSv1.2 (rfc5246) permitted (rsa, MD5) and allows (rsa,SHA1) > > side note on that, with ECDSA, all three versions use (ecdsa, sha1) so > everything we are discussing applies to RSA and RSA only (EC)DSA is fatally flawed (design flaw), no-one should be using it. EdDSA once it becomes available, might be OK. I guess that all existing TLS implementations with ECDSA support might be leaking (enough info to compute) the ECDSA private key to a mere passive observer of a few thousand full TLS_ECHDE_ECDSA_ handshakes. > > MD5 was deprecated and removed by basically every library > and can't be used in TLS 1.2, I specifically meant SHA1 MD5 deprecated ? Nope, glaring emtpy: https://www.rfc-editor.org/errata_search.php?rfc=5246 MD5 removed ? Mostly, but several implementors had to be prodded with with CVE-2015-7575 (SLOTH) to remove it. The real issue at hand is: Prohibiting TLSv1.0 and TLSv1.1 is going to result in lots of interop problems, while at the same time providing *ZERO* security benefit. The installed base of software which is limited to TLSv1.0 for outgoing TLS-protected communication is huge. What *WOULD* provide *HUGE* benefit, would be to remove the dangerous "protocol version downgrade dance" from careless applications, that is the actual problem known as POODLE, because this subverts the cryptographic procection of the TLS handshake protocol. We've known this downgrade dance to be a problem since the discussion of what became rfc5746. Prohibiting automatic protoocol version downgrade dances is going to ensure that two communication peers that support TLSv1.2 will not negotiate a lower TLS protocol version. If applications doing downgrade dances had at least a basic amount of risk management, and would refuse to perform an unlimited amount of downgrades automatically and secretly, then everyone would be much better of. I've seen web browsers doing this entirely without risk management, and wasn't there some Java class which also did this? And PLEASE stop unconditionally bashing SHA-1 I am constantly seeing crypto-clueless folks, including some national governmental agencies, that are giving out their own TLS recommendations, which are typically sterile of scientific rationale, and it's pretty obvious those folks either haven't read US NIST SP 800-57 part 1 rev.4 or not understood it. In particular Table 3 on top of page 54, about the signficant difference between sha1WithRsaEncryption and HMAC-SHA1 e.g. when used for integrity protection by a TLS cipher suites such as the TLSv1.2 MTI cipher suite TLS_RSA_WITH_AES_128_CBC_SHA. Security Digital Signatures and HMAC, Key Derivation Functions Strength hash-only applications Random Number Generation no <=80 no no no no SHA-1 no no no no no no no no no no no no no no 112 SHA-224,SHA-512/224,SHA3-224 128 SHA-256,SHA-512/256,SHA3-256 SHA-1 192 SHA-384,SHA3-384 SHA-224,SHA-512/224 >=256 SHA-512,SHA3-512 SHA-256,SHA-512/256,SHA-384 SHA-512, SHA3-512 In particular, if you compare HMAC-SHA1 to the shorter&weaker GMAC integrity protection afforded by AES-GCM cipher suites (rfc5288,rfc5289) or the even shorter&weaker integrity protection afforded by AES-CCM cipher suites (rfc6655). Lots of folks erroneously believe that TLS_RSA_WITH_AES_128_GCM_SHA256 and more so TLS_RSA_WITH_AES_256_GCM_SHA384 would provider stronger integrity protection than TLS_RSA_WITH_AES_128_CBC_SHA while in reality, it is just the opposite. -Martin From nobody Thu May 9 18:46:58 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02438120047 for ; Thu, 9 May 2019 18:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=jPha13pl; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=u9l3nQP6 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kdcM4mksRIZz for ; Thu, 9 May 2019 18:46:54 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C85A120004 for ; Thu, 9 May 2019 18:46:54 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id F140D41B for ; Thu, 9 May 2019 21:46:53 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Thu, 09 May 2019 21:46:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=m2RpA+IKmVlY/xOnAUPAiQHjkjxEOVn C9kEWtCbEqJE=; b=jPha13plaHpjnMitlRwGawRTH4tLHjNE2L827yFLaAGRYOr m12im5Y4EdVm+Q89wWBnu+Ir0BbwsMarff38OpN5Q3P06xpw7KAS0MYvkHpipkQH /RmGXTgaWhH9Q7gGbJy9yltV9Te/seUco6UZr9Yve+6y0LL3gOSJO1w2M/zkyR44 FXbuxPP0VPZ2cRBZLCyQy0WcFy9Ho/sTptEUs7/TRtssJzU0zIvTU9pjMyea3XJ7 1EuLKUHTN6WSopMu6foQ8wk+Kp7NzGyt9J+M6revlryXunULgv7ZsKkZFg9FbxqD XUSwO6hl0bDgtegpjDLbmhF4qVA611g78deJtgA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=m2RpA+ IKmVlY/xOnAUPAiQHjkjxEOVnC9kEWtCbEqJE=; b=u9l3nQP6VI3EeZ3L6gBhmT 4BYrGSbCx30gCC7bj5a/fD4bs6nCX7TpC37d7JL6nVsmbG9krDYHGCU92YAR4hiS FtiYJIo5hOR1yGE8WdBLZGfI73CUgMBoDu1EVZCvf+eFusTH/qr/mq5qz6QDasD4 tl1/tPf3+zU62M3K8n2Tm1DYE6K2VAZADyuZIIBHRVONLGzz3VZHzas4UXjOVdMS wbz/4BcokzGSXggnCB+dtThaPKPwKL54o4RVQp74BTfv+wpveiPj+e7GP/XlQzzF p5nZtc9UUUFdKTm2M6plKukagi0x2Ds1Sw1VLoLn5PIxvnUdmORt3dh96ec3LZfA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrkeeigdduheegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucffohhmrghinhepihgvthhfrdhorhhgnecurfgrrh grmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvghtnecuvehluhhs thgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id D2CD07C3DB; Thu, 9 May 2019 21:46:52 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-449-gfb3fc5a-fmstable-20190430v1 Mime-Version: 1.0 Message-Id: <528b8748-6f99-4167-9075-891286b8bc26@www.fastmail.com> In-Reply-To: References: Date: Thu, 09 May 2019 21:46:44 -0400 From: "Martin Thomson" To: tls@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [TLS] =?utf-8?q?Proposal_to_deprecate_sha1_and_md5_for_digital_s?= =?utf-8?q?ignatures_in_TLS_1=2E2?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 01:46:57 -0000 It might pay to spend more time on explaining what you are trying to do. The goal appears to be to remove a dependency on signature schemes that include these weaker hash functions. But the introduction just says that the functions are bad. You should be very clear about what effect this has on the use of SHA-1 in HMAC for record protection. It looks like you don't intend to deprecate that. Say that. The change to the enum is silly. Overall, I think that the updates to 5246 are unnecessary. Concentrate on 7525. The 7525 text starts with "When using RSA", so it could be read to not apply to ECDSA. That would be a mistake. I recommend splitting the paragraph into talking about the group size (the first sentence) and a separate paragraph on hash functions used as part of the signing process. As part of that, this probably needs to be a MUST: "Clients SHOULD indicate to servers that they request SHA-256, by using the "Signature Algorithms" extension defined in TLS 1.2." And then I think we should publish something. Like David, I'm acutely aware of the compatibility hazard that this presents, but it's no less worth doing. On Fri, May 10, 2019, at 00:12, Loganaden Velvindron wrote: > Hi all, > > Following the recent thread on TLS 1.0 and TLS 1.1 deprecation, we > came up with a proposal to deprecate md5 and sha1 for digital > signatures in the TLS 1.2 spec. > > Please find the draft at this url: > https://tools.ietf.org/html/draft-lvelvindron-tls-md5-sha1-deprecate-03 > > We look forward to your feedback. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Thu May 9 23:04:34 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3C7120170 for ; Thu, 9 May 2019 23:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k6BsNbxK2xj2 for ; Thu, 9 May 2019 23:04:30 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 431CD12015D for ; Thu, 9 May 2019 23:04:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1557468271; x=1589004271; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=CnKi7oMuWTD8AyXkPGpnk7ZkDjWpGLbLhjh7wosnACA=; b=lLRYvB8IKh8vC7wJgFO4dE159BbPOS8RH5L19ZEjdD5xXFtnKqC1KrXy 9YB9ZVXBgQX5msbLQPU5HFgCjPXD3Tr6J0V5fNF8R1/9EnqzFZ13lb19g 1no+uJtfla7MrfaevTlKVkDYIDDZZB3uUS0MvfMMxDU4awmjHqoljbr73 tjKx5FWQD8uo+N1rnEYDqbxgyDRmpCSnEZQo1/hhBUQrOvzwHpVeuf2RX kIl1CdvwA176r518S1JeSVsXdAwvQeJvfejhNAAjLdlJs/zrOXiFSUKEe H6Yj0clRkCEdXGW8lqUSXWIIXocp+sBF5FiNXrYJev/9SUJe2qhkb7IVO w==; X-IronPort-AV: E=Sophos;i="5.60,452,1549882800"; d="scan'208";a="61500013" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.8 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-ogg-e.UoA.auckland.ac.nz) ([10.6.2.8]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 10 May 2019 18:04:25 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-e.UoA.auckland.ac.nz (10.6.2.8) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 10 May 2019 18:04:24 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Fri, 10 May 2019 18:04:23 +1200 From: Peter Gutmann To: Hubert Kario , "mrex@sap.com" CC: "tls@ietf.org" Thread-Topic: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" Thread-Index: AQHU+8+QtjVLqWiyz0WqN1BpourjtKZM43YAgADkD4CAAGW4gIADRbgAgAMrEACAA/7YAIAAIz4AgAR6F4CAANPyAIAAvI2AgADfaICAAidXgIAA2c2AgAFJXos= Date: Fri, 10 May 2019 06:04:23 +0000 Message-ID: <1557468257899.11927@cs.auckland.ac.nz> References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <4282272.YYoj4h4VMi@pintsize.usersys.redhat.com> <20190508003157.11F3B404C@ld9781.wdf.sap.corp> <14984380.sTCEapK0kV@pintsize.usersys.redhat.com>, <20190509222449.9C553404C@ld9781.wdf.sap.corp> In-Reply-To: <20190509222449.9C553404C@ld9781.wdf.sap.corp> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 06:04:33 -0000 Martin Rex writes:=0A= =0A= >What *WOULD* provide *HUGE* benefit, would be to remove the dangerous=0A= >"protocol version downgrade dance" from careless applications, that is the= =0A= >actual problem known as POODLE, because this subverts the cryptographic=0A= >procection of the TLS handshake protocol.=0A= =0A= Is there anything apart from web browsers that engage in this silliness? I= 've=0A= never seen it, it's always just "connect with the one true protocol version= =0A= and suite" and that's it.=0A= =0A= Now admittedly that might be TLS 1.0 with RSA key exchange being selected a= s=0A= the one true protocol suite (in 2019!), but at least they don't do a downgr= ade=0A= dance.=0A= =0A= >And PLEASE stop unconditionally bashing SHA-1=0A= =0A= +1. It goes well beyond TLS, I've had some totally inane arguments with=0A= people who just seem to want to repeat "SHA-1 bad! SHA-1 bad! SHA-1 bad!"= =0A= without being able to explain why it's bad when questioned, i.e. there's no= =0A= actual attack possible. It's a problem when used with long-term signatures= =0A= like certs. It's typically not a problem when used with anything else.=0A= =0A= Peter.=0A= From nobody Fri May 10 10:08:33 2019 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 88363120094; Fri, 10 May 2019 10:08:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tls@ietf.org Message-ID: <155750811149.25889.4946708630935802141@ietfa.amsl.com> Date: Fri, 10 May 2019 10:08:31 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-oldversions-deprecate-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list 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 May 2019 17:08:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : Deprecating TLSv1.0 and TLSv1.1 Authors : Kathleen Moriarty Stephen Farrell Filename : draft-ietf-tls-oldversions-deprecate-04.txt Pages : 22 Date : 2019-05-10 Abstract: This document, if approved, formally deprecates Transport Layer Security (TLS) versions 1.0 [RFC2246] and 1.1 [RFC4346] and moves these documents to the historic state. These versions lack support for current and recommended cipher suites, and various government and industry profiles of applications using TLS now mandate avoiding these old TLS versions. TLSv1.2 has been the recommended version for IETF protocols since 2008, providing sufficient time to transition away from older versions. Products having to support older versions increase the attack surface unnecessarily and increase opportunities for misconfigurations. Supporting these older versions also requires additional effort for library and product maintenance. This document also deprecates Datagram TLS (DTLS) version 1.0 [RFC6347] (but not DTLS version 1.2, and there is no DTLS version 1.1). This document updates many RFCs that normatively refer to TLSv1.0 or TLSv1.1 as described herein. This document also updates RFC 7525 and hence is part of BCP195. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-oldversions-deprecate-04 https://datatracker.ietf.org/doc/html/draft-ietf-tls-oldversions-deprecate-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-oldversions-deprecate-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 13 04:30:30 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1E35120122 for ; Mon, 13 May 2019 04:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yXGTxcIPnoaY for ; Mon, 13 May 2019 04:30:27 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E7A2120121 for ; Mon, 13 May 2019 04:30:27 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B2D9D37E79; Mon, 13 May 2019 11:30:26 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-200-37.brq.redhat.com [10.40.200.37]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8EA4663BB4; Mon, 13 May 2019 11:30:25 +0000 (UTC) From: Hubert Kario To: mrex@sap.com Cc: tls@ietf.org, Martin Thomson Date: Mon, 13 May 2019 13:30:24 +0200 Message-ID: <29960808.K0e8lGuAtk@pintsize.usersys.redhat.com> In-Reply-To: <20190509222449.9C553404C@ld9781.wdf.sap.corp> References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <14984380.sTCEapK0kV@pintsize.usersys.redhat.com> <20190509222449.9C553404C@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1978465.3IOum5hbF4"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Mon, 13 May 2019 11:30:26 +0000 (UTC) Archived-At: Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 11:30:29 -0000 --nextPart1978465.3IOum5hbF4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Friday, 10 May 2019 00:24:49 CEST Martin Rex wrote: > Hubert Kario wrote: > > MD5 was deprecated and removed by basically every library > > and can't be used in TLS 1.2, I specifically meant SHA1 >=20 > MD5 deprecated ? Nope, glaring emtpy: > https://www.rfc-editor.org/errata_search.php?rfc=3D5246 >=20 > MD5 removed ? Mostly, but several implementors had to be prodded with > with CVE-2015-7575 (SLOTH) to remove it. I meant in practice > The real issue at hand is: >=20 > Prohibiting TLSv1.0 and TLSv1.1 is going to result in lots of > interop problems, while at the same time providing *ZERO* > security benefit. that's your opinion, not an established fact > The installed base of software which is limited to TLSv1.0 > for outgoing TLS-protected communication is huge. >=20 >=20 > What *WOULD* provide *HUGE* benefit, would be to remove the > dangerous "protocol version downgrade dance" from careless applications, > that is the actual problem known as POODLE, because this subverts the > cryptographic procection of the TLS handshake protocol. > =20 > We've known this downgrade dance to be a problem since the discussion > of what became rfc5746. Prohibiting automatic protoocol version > downgrade dances is going to ensure that two communication peers > that support TLSv1.2 will not negotiate a lower TLS protocol version. which exact piece of popular software actually still does that? It ain't cu= rl,=20 it ain't Chrome, it ain't Firefox. It also isn't something done automatical= ly=20 by any TLS implementation that's even remotely popular: OpenSSL, NSS, GnuTL= S,=20 schannel, Secure Transport, go... > If applications doing downgrade dances had at least a basic amount > of risk management, and would refuse to perform an unlimited amount > of downgrades automatically and secretly, then everyone would be > much better of. >=20 > I've seen web browsers doing this entirely without risk management, > and wasn't there some Java class which also did this? >=20 >=20 >=20 > And PLEASE stop unconditionally bashing SHA-1 that's a strawman, I was talking about SHA-1 signatures =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart1978465.3IOum5hbF4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAlzZVVAACgkQkqjRuAHS 9fX0Ig//aOUf8tv/ZZj4/dDa03+mzjjWc/pw2zIRmh71hRQxUZ+Rn/EW2nnSiatt WIWNVkif4y9miSYYza7qe7IT3RgL1cB+u75d+yi3DQ0SF8SnLBBQ9CfCl03n7U4N 7a/4I/ruBCyODuKZVAqWWGi3ix63viciu2Iug3ZCG7srRxQIxCd0TS/t9GDNWh9V DssQ2n2y6OK+RsbpTU8NkiqtPqw8qDTAm1vTjZb6QmVN7HNgFhH2Ri88Z2JsHEar wa5b+e9wY/gchn5UKYmHed3JjWHXR8E2riFpXWDmYwF++Hz/2mTbLc1uFymPi+cr mMF6xpgNSJ+GEq8aegw/cpj25d9akF4WIuWyrtquTy9jYUf27HDBLO7BdDTdBanX CvgyYMd9uKxxwHtP2zBRNiAgDt4ClKQs5LqnTYyRES3pYs/rdXbFGkobl9aKAbHm M7P7bbY+z79ubMtCY72V5Dd+89PI0DLywi1Rq9qdkRl3Gf/py1edHLyFDvswrMdv 7YkNzN1VoX0IejH0fbhalu3TJoGsfh2GCjvyhb2xVQqm71O3GrO8ddTco+wA6gpw 2q1gRmHh5U+Sm6lhbYpKtFLYimtYUytz1NwSjM7H5EERqaqknpVekMBKU4zyYXZl cCueKHaVvUAimR+UidViyhVAVcrtDFyR1+QRD1KjmaPjRW9Rkw8= =1clK -----END PGP SIGNATURE----- --nextPart1978465.3IOum5hbF4-- From nobody Mon May 13 09:55:21 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 016D5120135 for ; Mon, 13 May 2019 09:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-WQ_H7yp3s3 for ; Mon, 13 May 2019 09:55:18 -0700 (PDT) Received: from mail.felixhandte.com (felixhandte.com [54.172.180.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D46412004F for ; Mon, 13 May 2019 09:55:18 -0700 (PDT) Received: from [172.30.220.221] (unknown [163.114.130.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.felixhandte.com (Postfix) with ESMTPSA id 0990E2EAFD; Mon, 13 May 2019 16:55:16 +0000 (UTC) To: Alessandro Ghedini , Victor Vasiliev Cc: "tls@ietf.org" References: <270001f2-1b81-652c-8f43-f03d9b00ac2a@felixhandte.com> <20190404204542.GA7403@pinky.flat11.house> From: "W. Felix Handte" Message-ID: Date: Mon, 13 May 2019 12:55:16 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190404204542.GA7403@pinky.flat11.house> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Certificate Compression: Add Zstd Code Point? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 16:55:20 -0000 Hey all, In case anyone is interested in testing inter-operability: I've landed support for Zstd certificate compression in Facebook's implementation of TLS 1.3 [1]. I've also deployed that support to Facebook's servers. Best, Felix [1] https://github.com/facebookincubator/fizz On 4/4/19 4:45 PM, Alessandro Ghedini wrote: > On Mon, Apr 01, 2019 at 06:09:16PM -0400, Victor Vasiliev wrote: >> This sounds reasonable to me. I currently don't have a plan for >> implementing this, but since zstd is well-defined and has an RFC published >> (that I can easily cite), I see no reason not to add it. >> >> I wrote up a PR: https://github.com/tlswg/certificate-compression/pull/26. >> I will merge it before the last call, unless there are objections. > > This seems pretty inoffensive (just one more allocated codepoint), and it's > already been a few days and nobody seems to object. > > We'd like to submit a new draft version so we can finally go to WGLC, so if > nobody objects by tomorrow I'll just merge the PR and upload the draft. > > Cheers > From nobody Mon May 13 23:34:55 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87BCE1200BA for ; Mon, 13 May 2019 23:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rW6k9yAum1cM for ; Mon, 13 May 2019 23:34:51 -0700 (PDT) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0E52120092 for ; Mon, 13 May 2019 23:34:51 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id s20so12096353ioj.7 for ; Mon, 13 May 2019 23:34:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xdLvnUC5cYpIToGj2KA2icbcbmGdhVy5l7C7Yfe0etE=; b=JoFXNWH3GML/6azcyci1ALeG/EkpiKCrKpdxwaxWw3nSsh4P5gzfSOfsTLYZWCX7AI Gu7A7NUQjAoZzbpPdxlSdMfgKDJldAboes+tUpwWcH9FWh/gVtL7z7/ZrBjmuVWgFCR7 FnrRFgkweqVP1ciaJh9jGPscyTFBKw/kZw4k2w9OcyoISTqjJf1scOjJmvt4U86D0qpR h+ttsOrVH233HPyIEwpd9k+vUtBMclbL9Z8sQFoEHZGwCqRPotWKFoaIW/60ZDUMMMtx OxT/C3BxN4jIwpC8jVNgiwt0Ck7SPdqGs9S3/wcR23ud0VxE73zuSCjE3YO4ICaoi0ok b6NQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xdLvnUC5cYpIToGj2KA2icbcbmGdhVy5l7C7Yfe0etE=; b=ELYSJMOznY+evECOMDVhrFkR0GH7IexD9AipA4RRymVEmA2keVa13trSfaDyrlWxJv 5cFlZG4oFXuqd+OEghhyEJusXu+MIuXcFzK663sAsrgyR3updKxImR4w7z4Hh65RDByp uK2Bicrn4nZgtmXoLZI35oeAtGa8/e6+MKJ5AnPXcnfxp7p6ierxA1ZFDx3Yh0BKbk2T 888ox57MF54Qzfx8tvYefpbp7EdlUcgFm29DobR1ygiUig0RxIb2p1VenHKRCfw0OPb0 mNV81zPHUELYsZVmhlZaaLCH+ob2lK1VXGJWF+KNj5LEwx0CBg4oajwc7pM4MPi5H6q9 Y0vw== X-Gm-Message-State: APjAAAU3yXUiu3zyKCNbKXUcLtmexwPDwd0sPjb6G7D1i4qwGyUWBhau xsKzXeAyg5f/2oSbterJ66QAMcJxy1WruON3rYQQwYZ5nEo= X-Google-Smtp-Source: APXvYqxOVviqwvZUcoRSyLwi4j06kfOBzqanhgHBBlz6hDKEwfQpXYVoP5RHTLmmIQRejwTj9OBG4dMkEBcYT7p6fF4= X-Received: by 2002:a6b:c945:: with SMTP id z66mr18288717iof.191.1557815690970; Mon, 13 May 2019 23:34:50 -0700 (PDT) MIME-Version: 1.0 References: <528b8748-6f99-4167-9075-891286b8bc26@www.fastmail.com> In-Reply-To: <528b8748-6f99-4167-9075-891286b8bc26@www.fastmail.com> From: Loganaden Velvindron Date: Tue, 14 May 2019 10:34:38 +0400 Message-ID: To: Martin Thomson Cc: "" Content-Type: multipart/alternative; boundary="000000000000e2ca440588d33a87" Archived-At: Subject: Re: [TLS] Proposal to deprecate sha1 and md5 for digital signatures in TLS 1.2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 14 May 2019 06:34:54 -0000 --000000000000e2ca440588d33a87 Content-Type: text/plain; charset="UTF-8" [comments in-line] On Fri, May 10, 2019 at 5:47 AM Martin Thomson wrote: > It might pay to spend more time on explaining what you are trying to do. > > The goal appears to be to remove a dependency on signature schemes that > include these weaker hash functions. But the introduction just says that > the functions are bad. > > We've updated the draft. > You should be very clear about what effect this has on the use of SHA-1 in > HMAC for record protection. It looks like you don't intend to deprecate > that. Say that. > > Added. > The change to the enum is silly. Overall, I think that the updates to > 5246 are unnecessary. Concentrate on 7525. > > Removed change to enum. > The 7525 text starts with "When using RSA", so it could be read to not > apply to ECDSA. That would be a mistake. I recommend splitting the > paragraph into talking about the group size (the first sentence) and a > separate paragraph on hash functions used as part of the signing process. > > This change was also incorporated. > As part of that, this probably needs to be a MUST: "Clients SHOULD > indicate to servers that they request SHA-256, by using the "Signature > Algorithms" extension defined in TLS 1.2." > > And then I think we should publish something. Like David, I'm acutely > aware of the compatibility hazard that this presents, but it's no less > worth doing. > > We also agree with you. Latest draft is here: https://www.ietf.org/id/draft-lvelvindron-tls-md5-sha1-deprecate-04.txt > > On Fri, May 10, 2019, at 00:12, Loganaden Velvindron wrote: > > Hi all, > > > > Following the recent thread on TLS 1.0 and TLS 1.1 deprecation, we > > came up with a proposal to deprecate md5 and sha1 for digital > > signatures in the TLS 1.2 spec. > > > > Please find the draft at this url: > > https://tools.ietf.org/html/draft-lvelvindron-tls-md5-sha1-deprecate-03 > > > > We look forward to your feedback. > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000e2ca440588d33a87 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
[comments in-line]

On Fri, May 10, 20= 19 at 5:47 AM Martin Thomson <mt@lo= wentropy.net> wrote:
It might pay to spend more time on explaining what you are tryi= ng to do.

The goal appears to be to remove a dependency on signature schemes that inc= lude these weaker hash functions.=C2=A0 But the introduction just says that= the functions are bad.

We've updated the draft.
=C2=A0
You should be very clear about what effect this has on the use of SHA-1 in = HMAC for record protection.=C2=A0 It looks like you don't intend to dep= recate that.=C2=A0 Say that.

Added.=C2=A0
The change to the enum is silly.=C2=A0 Overall, I think that the updates to= 5246 are unnecessary.=C2=A0 Concentrate on 7525.

Removed change to enum.=C2=A0
The 7525 text starts with "When using RSA", so it could be read t= o not apply to ECDSA.=C2=A0 That would be a mistake.=C2=A0 I recommend spli= tting the paragraph into talking about the group size (the first sentence) = and a separate paragraph on hash functions used as part of the signing proc= ess.

This change was also incorporated.=C2=A0
As part of that, this probably needs to be a MUST: "Clients SHOULD ind= icate to servers that they request SHA-256, by using the "Signature Al= gorithms" extension defined in TLS 1.2."

And then I think we should publish something.=C2=A0 Like David, I'm acu= tely aware of the compatibility hazard that this presents, but it's no = less worth doing.

We also agree with you.
Latest draft is her= e:

On Fri, May 10, 2019, at 00:12, Loganaden Velvindron wrote:
> Hi all,
>
> Following the recent thread on TLS 1.0 and TLS 1.1 deprecation, we
> came up with a proposal to deprecate md5 and sha1 for digital
> signatures in the TLS 1.2 spec.
>
> Please find the draft at this url:
> https://tools.ietf.org/h= tml/draft-lvelvindron-tls-md5-sha1-deprecate-03
>
> We look forward to your feedback.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000e2ca440588d33a87-- From nobody Tue May 14 04:24:41 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 921DA12006B for ; Tue, 14 May 2019 04:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OoiXHZpoRB7K for ; Tue, 14 May 2019 04:24:38 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99E771200A4 for ; Tue, 14 May 2019 04:24:38 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C2F70307EA86; Tue, 14 May 2019 11:24:37 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.83]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0866219C70; Tue, 14 May 2019 11:24:36 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Date: Tue, 14 May 2019 13:24:35 +0200 Message-ID: <2977635.mFCBgFvPmQ@pintsize.usersys.redhat.com> In-Reply-To: References: <528b8748-6f99-4167-9075-891286b8bc26@www.fastmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2201379.uxvmKTXWxM"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.44]); Tue, 14 May 2019 11:24:37 +0000 (UTC) Archived-At: Subject: Re: [TLS] Proposal to deprecate sha1 and md5 for digital signatures in TLS 1.2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 14 May 2019 11:24:40 -0000 --nextPart2201379.uxvmKTXWxM Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Tuesday, 14 May 2019 08:34:38 CEST Loganaden Velvindron wrote: > Latest draft is here: > https://www.ietf.org/id/draft-lvelvindron-tls-md5-sha1-deprecate-04.txt why did you drop SHA-1 from Section 4 and 5? the note about SHA-1 in HMAC applies to ciphersuites, to state explicitly t= hat=20 ciphersuites like TLS_DHE_RSA_WITH_AES_128_CBC_SHA are _not_ deprecated by = it SKE and CV don't use HMAC =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart2201379.uxvmKTXWxM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAlzapXMACgkQkqjRuAHS 9fWR8xAAhZ2qirDoxVUYgFp7p1KBja4aBJNqErz9Kj6lsWohN7bALS5wAlZUxjYG q3ffTsIQpwZsc7KYtMrS3HaCeC5jG63ut+Ct7k4mHK96fs2+qcNL1ZwblZN1Oiuj uos3OZv1XBTjKGS0jCpQOpyhTLJPOaRk+TIk1JXPdR9x0vg2oSXtEcsi89OOiPQ+ BCT2Y+NTZH2fcDVrAZwNiY8HxHbcSPijf872s8VWbaDdYEN2b2lo4jBxjoJ5f1v8 f7Rbla+ar+g8ikvUInDDYGcEb3ypameFP1zhm0HPOLDCx7qp/V6nRXA98At9UiIG BGT5sFWkHGFqCeaezDft9sU2VF/8LgoDzIYdQ5xQZZZmgvMgrBMKL6jpt4BSKiJ/ Sv4YUYOBZkM9RsC77px3uC23E4sFnheuI4bwBY1ceXA190LGqjwOQo8AZQzqRN6a IA8wEKHY2whgnpX+sROUDeSwKrRDVWoLfXLstg1Q2Y7OCNk330Ln9Vaet+1Aa/Va 5cJ1vZIT/TJ/BFab955F3sEG5ZFSfWnv6fiiDWHGg5PeuZLm3PH7Nf4oSahzfPWA zcfEmXXnYRhmzsF/pRfvpmWyR8f0+Xg4CyilAH/QYZMipQVQQOMukh/M0NVenwp4 Uip4VYje/9rFRFvi1Dz1PopQmJrbeOUlOWN/mq/ADQGc6RXsVEA= =trLv -----END PGP SIGNATURE----- --nextPart2201379.uxvmKTXWxM-- From nobody Tue May 14 06:35:16 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9831200EB for ; Tue, 14 May 2019 06:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8tcATjSaBxhL for ; Tue, 14 May 2019 06:35:12 -0700 (PDT) Received: from de-out1.bosch-org.com (de-out1.bosch-org.com [139.15.230.186]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48FE2120019 for ; Tue, 14 May 2019 06:35:12 -0700 (PDT) Received: from fe0vm1650.rbesz01.com (unknown [139.15.230.188]) by si0vms0217.rbdmz01.com (Postfix) with ESMTPS id 453Jb03MjNz4f3kbF; Tue, 14 May 2019 15:35:08 +0200 (CEST) Received: from si0vm4642.rbesz01.com (unknown [10.58.172.176]) by fe0vm1650.rbesz01.com (Postfix) with ESMTPS id 453Jb0368Zz1CN; Tue, 14 May 2019 15:35:08 +0200 (CEST) X-AuditID: 0a3aad12-bfbff70000006e39-ae-5cdac40c07cc Received: from si0vm1950.rbesz01.com ( [10.58.173.29]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by si0vm4642.rbesz01.com (SMG Outbound) with SMTP id 9B.C8.28217.C04CADC5; Tue, 14 May 2019 15:35:08 +0200 (CEST) Received: from SI-MBX2033.de.bosch.com (si-mbx2033.de.bosch.com [10.3.230.36]) by si0vm1950.rbesz01.com (Postfix) with ESMTPS id 453Jb01jQhz5fH; Tue, 14 May 2019 15:35:08 +0200 (CEST) Received: from SI-MBX2033.de.bosch.com (10.3.230.36) by SI-MBX2033.de.bosch.com (10.3.230.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1713.5; Tue, 14 May 2019 15:35:08 +0200 Received: from SI-MBX2033.de.bosch.com ([fe80::88a0:7dd8:cf69:6aaa]) by SI-MBX2033.de.bosch.com ([fe80::88a0:7dd8:cf69:6aaa%4]) with mapi id 15.01.1713.006; Tue, 14 May 2019 15:35:07 +0200 From: "Kraus Achim (INST/ECS4)" To: Joseph Salowey CC: "" Thread-Topic: [TLS] early code-point assignment request for draft-ietf-tls-dtls-connection-id-04 Thread-Index: AQHU6+zYPURRBhCsPUmtiEDNGivddaY9LFsAgAAXIwCALZFGUA== Date: Tue, 14 May 2019 13:35:07 +0000 Message-ID: <20ad6d9c60bd4ee09f8f3256b509b5c3@bosch-si.com> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.81.84] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA22Tf0wbZRjHedtre3S95Xq060OBCRU1/gI2mSLTafSfxZhsLMYY0sS146CN tMVeQSCZaYZObJOJsFYGQTZkSAyErnYymIFSMFJmyphCsWMzMMLmNhLdkhEQO+96Ze0f/vPm eb/f9/M+z/u9HC6kzuJq3Gi20VazrlIjlmLS4v6s52UTEW3Bw2OKoh+8o5Kie9MO9Lpgf3f3 umD/z8MeyUFBqfSVMrrSWENb8/cdlhoGl89gVceVtdOheWRHfoUD4TiQhTCzlu9AUpwiWwVw 5o5Xwm8uIvD6GhC/WUXwpcMXd/wI7g59wm5ScTFZDM2nx2O1gswF+zc/iblaSD4OLdGFmJ5G 6mAi/JeYa6cg9eD8tZQ//gY4/jmJcTVGPgGdM2ux4wS5F8bD/UK+1ySCjaFrQs5IJUvA63HG akRmgcczLeR7qSCy3CngaiBJ6P6R14FUwp83oiK+fgwavngg4WYQkk/DwHA+j+bASedivK8c gqeWsSakaku6tS1BtCURbUnEaYR9h5SMsaDGVPhi4e48q55m6gt25R2xmLyI/1bUBXRurjyA SBxpZETRWERLiXQ1TJ0pgPbgAo2SuHFiXktt11vK6gw6xvC+tbqSZjRqIvPyW1oq7ZHMVOtN RoYxWswBBLhQoyBKc1iOKNPV1dNWC48FUAaOaVREBX5AS5EVOhv9AU1X0dYtdy+Oa4AoD7Az yK10BV1bbqy0bdmaLAKlpKRQO5Kd5LYCPDWAXsBlbO8p7hkEU6UzMcaKOJ7O49SWmkCn0AHc 37XYIcSDa9y6OnazQ0hhZouZVquI17hxSI4yVJsfTaPOJOZWw1pKmWQkbryNfkdsnmmEj4Nl 7O+RmAOIDC46eVxMQLvPsgzpkkHQNyWAjc96MQj0hDFoXBoTwcK9FjFs/tsjhjsNTRK4fr1Z ApvhT7fBwMPGbTDa3rwdRr4apGBi5oQC5qOX2OXuuBJa3T0qiLb+BrDUNwvQ1TqSDq5zoXS4 NdyYwRrrmbB4fmAnXBkK7oS+hf5sGF2ZzIZb9vVs1nXlwPJgSy5cdd/Pha+PLTwJF9znn7rN hixgQ37ZGAvZprP9T8hxNfE6tR25/dB++IFoZTNPde3vzolLH32oeTPkfHdlfGRSjkVfNX1v lmystPjlkdW3j/Y/Gz546HLxxR2ujz3vvVOiPdR11Xyzu/4XZW+6vXPpOS0zdtw7S7iCJX9g fqPspRRC/+2+PU3iIx2R0MAVkftUkXP2aG9k/r6v1tYHn8+tD2tD7RqMMeh2PSO0Mrr/AI0g 7Xq4BAAA Archived-At: Subject: Re: [TLS] early code-point assignment request for draft-ietf-tls-dtls-connection-id-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 14 May 2019 13:35:15 -0000 SGkgSm9lLA0KDQo+IHJlcXVlc3QgdG8gb3VyIEFEDQogDQppcyB0aGVyZSBhbiAiZXhwZWN0ZWQg ZGF0ZSIgZm9yIHRoYXQgcmVxdWVzdGVkIGFzc2lnbm1lbnQgb2YgZWFybHkgY29kZS1wb2ludHM/ DQpJIHRyaWVkIHRvIGZpbmQgc29tZXRoaW5nIG9uIHRoZSBJQU5BIHBhZ2UsIGJ1dCB3YXNuJ3Qg c3VjY2Vzc2Z1bC4NCiANCk1pdCBmcmV1bmRsaWNoZW4gR3LDvMOfZW4gLyBCZXN0IHJlZ2FyZHMg DQoNCkFjaGltIEtyYXVzDQoNCihJTlNUL0VDUzQpIA0KQm9zY2jCoFNvZnR3YXJlIElubm92YXRp b25zwqBHbWJIIHwgU3R1dHRnYXJ0ZXIgU3RyYcOfZSAxMzAgfCA3MTMzMiBXYWlibGluZ2VuIHwg R0VSTUFOWSB8IGh0dHA6Ly93d3cuYm9zY2gtc2kuY29tIA0KDQpTaXR6OiBCZXJsaW4sIFJlZ2lz dGVyZ2VyaWNodDogQW10c2dlcmljaHQgQ2hhcmxvdHRlbmJ1cmc7IEhSQiAxNDg0MTEgQg0KQXVm c2ljaHRzcmF0c3ZvcnNpdHplbmRlcjogRHIuLUluZy4gVGhvcnN0ZW4gTMO8Y2tlOyBHZXNjaMOk ZnRzZsO8aHJ1bmc6IERyLiBTdGVmYW4gRmVyYmVyLCBNaWNoYWVsIEhhaG4sIERyLiBBbGVrc2Fu ZGFyIE1pdHJvdmljDQoNCg0KDQpGcm9tOiBUTFMgPHRscy1ib3VuY2VzQGlldGYub3JnPiBPbiBC ZWhhbGYgT2YgSm9zZXBoIFNhbG93ZXkNClNlbnQ6IE1vbnRhZywgMTUuIEFwcmlsIDIwMTkgMTc6 MTgNClRvOiBBY2hpbSBLcmF1cyA8YWNoaW1rcmF1c0BnbXgubmV0Pg0KQ2M6IDx0bHNAaWV0Zi5v cmc+IDx0bHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW1RMU10gZWFybHkgY29kZS1wb2ludCBh c3NpZ25tZW50IHJlcXVlc3QgZm9yIGRyYWZ0LWlldGYtdGxzLWR0bHMtY29ubmVjdGlvbi1pZC0w NA0KDQpObyBjb25jZXJucyBmcm9tIHRoZSB3b3JraW5nIGdyb3VwIHNvIEkgbWFkZSB0aGUgcmVx dWVzdCB0byBvdXIgQUQuwqDCoA0KDQpDaGVlcnMsDQoNCkpvZQ0KDQpPbiBNb24sIEFwciAxNSwg MjAxOSBhdCA2OjU1IEFNIEFjaGltIEtyYXVzIDxtYWlsdG86YWNoaW1rcmF1c0BnbXgubmV0PiB3 cm90ZToNCkhlbGxvIEpvZSwNCg0KZGlkIHRoZSB3b3JraW5nIGdyb3VwIHJlY2VpdmUgYW55IGNv bmNlcm5zIGFib3V0IHRoZSBlYXJseSBjb2RlLXBvaW50DQphc3NpZ25tZW50PyBJIGhvcGUgbm90 LiBIYW5uZXMgZGlkIGFnYWluIGEgdmVyeSBncmVhdCBqb2IgYW5kIHNvIEkNCmNsb3NlZCBteSBv cGVuIGlzc3VlcyBvbiB0aGUgZ2l0aHViIHJlcG8uDQpJcyB0aGVyZSBhbnkgc2NoZWR1bGUgZm9y IHRoZSBlYXJseSBjb2RlLXBvaW50IGFzc2lnbm1lbnQ/DQpJIHBsYW4gYSBuZXh0IGVjbGlwc2Ut Y2FsaWZvcm5pdW0gbWlsZXN0b25lIHJlbGVhc2UgYW5kIGl0IHdvdWxkIGJlIHZlcnkNCmdyZWF0 LCBpZiBJIGNvdWxkIGluY2x1ZGUgdGhlIHZhbHVlcyBvZiB0aGUgZWFybHkgYXNzaWduZWQgY29k ZS1wb2ludHMuDQoNCmJlc3QgcmVnYXJkcw0KQWNoaW0gS3JhdXMNCg0KQW0gMDUuMDQuMTkgdW0g MjI6MTggc2NocmllYiBKb3NlcGggU2Fsb3dleToNCj4gV2UgaGF2ZSByZWNlaXZlZCBhIHJlcXVl c3QgZm9yIGVhcmx5IGNvZGUtcG9pbnQgYXNzaWdubWVudCBvZiB2YWx1ZXMgZm9yDQo+IGRyYWZ0 LWlldGYtdGxzLWR0bHMtY29ubmVjdGlvbi1pZC0wNC7CoCBXZSBiZWxpZXZlIHRoYXQgb25seSBl ZGl0b3JpYWwNCj4gY2hhbmdlcyBhcmUgcGVuZGluZy4gUGxlYXNlIHJlc3BvbmQgdG8gdGhpcyBs aXN0IG9mIHlvdSBoYXZlIGNvbmNlcm5zDQo+IGFib3V0IHRoZXNlIGFzc2lnbm1lbnRzIGJ5IEFw cmlsIDEyLCAyMDE5Lg0KPg0KPiBUaGFua3MsDQo+DQo+IEpvZSwgU2VhbiBhbmQgQ2hyaXMNCj4N Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gVExT IG1haWxpbmcgbGlzdA0KPiBtYWlsdG86VExTQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdGxzDQo+DQo= From nobody Tue May 14 07:53:03 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE641200B3 for ; Tue, 14 May 2019 07:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGhmov4DpBkx for ; Tue, 14 May 2019 07:52:57 -0700 (PDT) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31FAB12006E for ; Tue, 14 May 2019 07:52:57 -0700 (PDT) Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 453LJf34tjzycc; Tue, 14 May 2019 16:52:50 +0200 (CEST) X-purgate-ID: 152705::1557845570-0000020D-73FF3FEE/0/0 X-purgate-size: 2749 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail07.wdf.sap.corp (Postfix) with ESMTPS id 453LJd6LXVzGp2q; Tue, 14 May 2019 16:52:49 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id C6DDB404C; Tue, 14 May 2019 16:52:49 +0200 (CEST) In-Reply-To: <29960808.K0e8lGuAtk@pintsize.usersys.redhat.com> References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <14984380.sTCEapK0kV@pintsize.usersys.redhat.com> <20190509222449.9C553404C@ld9781.wdf.sap.corp> <29960808.K0e8lGuAtk@pintsize.usersys.redhat.com> To: Hubert Kario Date: Tue, 14 May 2019 16:52:49 +0200 (CEST) CC: mrex@sap.com, tls@ietf.org, Martin Thomson Reply-To: mrex@sap.com MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20190514145249.C6DDB404C@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 14 May 2019 14:53:01 -0000 Hubert Kario wrote: > Martin Rex wrote: >> Hubert Kario wrote: >>> MD5 was deprecated and removed by basically every library >>> and can't be used in TLS 1.2, I specifically meant SHA1 >> >> MD5 deprecated ? Nope, glaring emtpy: >> https://www.rfc-editor.org/errata_search.php?rfc=5246 >> >> MD5 removed ? Mostly, but several implementors had to be prodded with >> with CVE-2015-7575 (SLOTH) to remove it. > > I meant in practice > >> The real issue at hand is: >> >> Prohibiting TLSv1.0 and TLSv1.1 is going to result in lots of >> interop problems, while at the same time providing *ZERO* >> security benefit. > > that's your opinion, not an established fact You got this backwards. There is a bold assertion that disabling TLSv1.0 and TLSv1.1 (alone) would provide security benefits, but a complete lack of proof. On digitally_signed, is proven that TLSv1.2 as defined by rfc5246 is the weakest of them all. >> >> What *WOULD* provide *HUGE* benefit, would be to remove the >> dangerous "protocol version downgrade dance" from careless applications, >> that is the actual problem known as POODLE, because this subverts the >> cryptographic procection of the TLS handshake protocol. >> >> We've known this downgrade dance to be a problem since the discussion >> of what became rfc5746. Prohibiting automatic protoocol version >> downgrade dances is going to ensure that two communication peers >> that support TLSv1.2 will not negotiate a lower TLS protocol version. > > which exact piece of popular software actually still does that? > It ain't curl, it ain't Chrome, it ain't Firefox. It definitely was implemented in Chrome and Firefox, which is how this poor document got onto standards track: https://tools.ietf.org/html/rfc7507 TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks > > It also isn't something done automatically > by any TLS implementation that's even remotely popular: > OpenSSL, NSS, GnuTLS, schannel, Secure Transport, go... It is impossible to do this transparently, because the a connection is ususable after a fatal TLS hanshake failure (or unexpected socket closure). Any application-level cleartext negotiation will have to be repeated as well, and the TLS implementation typically does not know about it. (such as HTTP CONNECT or STARTTLS) The POODLE paper https://www.openssl.org/~bodo/ssl-poodle.pdf asserts that many clients doing downgrade dances exist, and at the time of publication, this includes Mozilla Firefox, Google Chrome and Microsoft Internet Explorer. -Martin From nobody Tue May 14 09:32:46 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA0212008B for ; Tue, 14 May 2019 09:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.508 X-Spam-Level: X-Spam-Status: No, score=-9.508 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJQIqKLjCa7y for ; Tue, 14 May 2019 09:32:41 -0700 (PDT) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEF2E120044 for ; Tue, 14 May 2019 09:32:41 -0700 (PDT) Received: by mail-qt1-x832.google.com with SMTP id m32so16690240qtf.0 for ; Tue, 14 May 2019 09:32:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6SbL0Bx/r6e0sSytXVYkPF+AlYEWQivYSMEUpfIYhg0=; b=aWiTRN8BBH2VgX/Hl5egdvqnvCkBbFLlsI+1zf8BLQYU02RnObtehsCD8suPvgzkJJ wsozWC+pbJN3oQKXu2PDbUaMQVqVHisCnsSEHKPdxIGuf6DFEJSbF47X+w/HMeqhXPXA ABboZa1ulOlsZEsUCo314Rk+2c3+GnO9frBgs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6SbL0Bx/r6e0sSytXVYkPF+AlYEWQivYSMEUpfIYhg0=; b=baTimfHDK+5/A/UjiN9PC+JCZiFJ5Qrr5LZanipI6lGX6vfguX9ZzWK9tYDSD5fzac MxOI5JABAKguAb/3VZIsnaSTcKTXBwqnnzi9s82EnvXRSilWPtST0tLZG3n1chs0V7QJ qZ1iim5fo2QPfrpAybz2Joy1XqGFrocB3P+f+MozFsaKiuGQ9uEys8JhB7026xX9y6CV V7rE59G8zlUxH3fbgwLu+NvF/sWTsREIKcFbBhAt064CHznadGlpiC6gl2EqpvPJFVP4 UnZYHar6xcj8x3qRgHbKVjgigmilFRwEc2sYsD+d4VfS8HhlbOWjFRwY6tngaKJKYHNY Brfw== X-Gm-Message-State: APjAAAUE/WmpjE7A4QesnRZtA/IqEMfqwT2fE0dAWLbFwqYUOWE18fEJ FXas1xTfzrpsuA5CZb6zRV17yrK+AUeNhG9aPlIS X-Google-Smtp-Source: APXvYqy6s7rTix4ivAM0sUAMKcu0v6R4fnmxUnm6Bq2pMXc2jApCGO35hH44jDjI4xQ1c9x5jXvfh1t1OJM79TVJJGI= X-Received: by 2002:a0c:fd67:: with SMTP id k7mr28140809qvs.152.1557851560602; Tue, 14 May 2019 09:32:40 -0700 (PDT) MIME-Version: 1.0 References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <14984380.sTCEapK0kV@pintsize.usersys.redhat.com> <20190509222449.9C553404C@ld9781.wdf.sap.corp> <29960808.K0e8lGuAtk@pintsize.usersys.redhat.com> <20190514145249.C6DDB404C@ld9781.wdf.sap.corp> In-Reply-To: <20190514145249.C6DDB404C@ld9781.wdf.sap.corp> From: David Benjamin Date: Tue, 14 May 2019 12:32:23 -0400 Message-ID: To: mrex@sap.com Cc: Hubert Kario , "" Content-Type: multipart/alternative; boundary="000000000000e25ab50588db94d9" Archived-At: Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 14 May 2019 16:32:45 -0000 --000000000000e25ab50588db94d9 Content-Type: text/plain; charset="UTF-8" > > > which exact piece of popular software actually still does that? > > It ain't curl, it ain't Chrome, it ain't Firefox. > > It definitely was implemented in Chrome and Firefox, which is how this > poor document got onto standards track: > > https://tools.ietf.org/html/rfc7507 > > TLS Fallback Signaling Cipher Suite Value (SCSV) > for Preventing Protocol Downgrade Attacks > > > > > It also isn't something done automatically > > by any TLS implementation that's even remotely popular: > > OpenSSL, NSS, GnuTLS, schannel, Secure Transport, go... > > It is impossible to do this transparently, because the a connection > is ususable after a fatal TLS hanshake failure (or unexpected socket > closure). > > Any application-level cleartext negotiation will have to be repeated > as well, and the TLS implementation typically does not know about it. > (such as HTTP CONNECT or STARTTLS) > > The POODLE paper > https://www.openssl.org/~bodo/ssl-poodle.pdf > > asserts that many clients doing downgrade dances exist, and at the > time of publication, this includes Mozilla Firefox, Google Chrome and > Microsoft Internet Explorer. > Chrome has not done a downgrade dance for over three years now (Chrome 50, released in April 2016), even for TLS 1.3. Indeed much of the fuss around TLS 1.3 was so clients could avoid repeating this mess. David --000000000000e25ab50588db94d9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> which exact piece of popular software actually stil= l does that?
> It ain't curl, it ain't Chrome, it ain't Firefox.

It definitely was implemented in Chrome and Firefox, which is how this
poor document got onto standards track:

=C2=A0 =C2=A0https://tools.ietf.org/html/rfc7507

=C2=A0TLS Fallback Signaling Cipher Suite Value (SCSV)
=C2=A0 =C2=A0 for Preventing Protocol Downgrade Attacks

>
> It also isn't something done automatically
> by any TLS implementation that's even remotely popular:
> OpenSSL, NSS, GnuTLS, schannel, Secure Transport, go...

It is impossible to do this transparently, because the a connection
is ususable after a fatal TLS hanshake failure (or unexpected socket closur= e).

Any application-level cleartext negotiation will have to be repeated
as well, and the TLS implementation typically does not know about it.
(such as HTTP CONNECT or STARTTLS)

The POODLE paper
=C2=A0 =C2=A0https://www.openssl.org/~bodo/ssl-poodle.= pdf

asserts that many clients doing downgrade dances exist, and at the
time of publication, this includes Mozilla Firefox, Google Chrome and
Microsoft Internet Explorer.

Chrome has= not done a downgrade dance for over three years now (Chrome 50, released i= n April 2016), even for TLS 1.3. Indeed much of the fuss around TLS 1.3 was= so clients could avoid repeating this mess.=C2=A0

David
--000000000000e25ab50588db94d9-- From nobody Tue May 14 10:33:29 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2FE8120137 for ; Tue, 14 May 2019 10:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id knTpRiimPAPd for ; Tue, 14 May 2019 10:33:23 -0700 (PDT) Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BFDF1200B1 for ; Tue, 14 May 2019 10:33:23 -0700 (PDT) Received: by mail-ot1-x330.google.com with SMTP id l17so16057049otq.1 for ; Tue, 14 May 2019 10:33:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gBVkkHFAhgK84i5xt0m6mgrAdSCuhZfn/Stg9UA3Bxc=; b=UZjFFcw0uuO2ghwXaCQtDrZpk7ZZOgTn3YZBfnPeYiE++Zj0eV8BBoXPVxgx74Z/4V mbagMeTeLJgZaTMoLRTlTy7BnkghosqJWF0CAAvYLQGQ4JbcdJ6qB/H9AKDdAAkSLZvh kaJ46Iv1vD6Qspp9dHWp+ujejV3894u6TODb7N83bpB7ii1MC1rgQA9jso4iGNztnZNS TdnNGLxW64f3CCC8iCLa7j2h9OgAgABHflrsqZ+4gb8LTSYzPcJoWin56bia7RNeg130 9zUV0PoKOyKv+8BfWjheVoIikws1tFSZdUjXSIaV4sroxYHvC7j3ZwYzB71k7sgYHoiB 1EhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gBVkkHFAhgK84i5xt0m6mgrAdSCuhZfn/Stg9UA3Bxc=; b=cTK4G2hvK5nDm8ZgSODMolOXD+pg6Sl9ICuLhe0GNFoSEF9fgilZpZRvOI5vVBVo7s VtE9FQ+/x96qxR0sQxnXs+ZjeiIRmsTSUgmBIxVzoi+tj3WY0lZ+twY+3uIXNzPsLCFY Q0tl8ysfwjJzWvU8R33tezrUf+jTQEIEjo3GdYW7tvJW438i1ckiBpcjoGXyi2gaC5cX 8K/HePj8rilnkJmZujc7AHab8qQ7wGoNVD9hlqQs69fdPMOkaA+xRSZbIG8eiD1ic6a9 XsgXoNbRy4RYv7dOMRmuCdrFj8wUXkN0fyUbs4kWRVSZ0gAth1tMoTUaPEzzo8Fju1Xu TXXA== X-Gm-Message-State: APjAAAWvQvYKIsuzszTHJVVYeXuaqV3r2E2fj5GxtdPSDFydhlJy6D4S XI5KwrBao6MSdSJg3YLrUqpwe5i4wVO16wk2Us3F+P3a X-Google-Smtp-Source: APXvYqyaGWtH+UGaRWmJCfIh+w3khpTBhYzGkdIWDqT6Y3YVV9bFe4LlfK6tB/XGniZ3UIQF26WdB9BO/F6MI+n/z6M= X-Received: by 2002:a05:6830:1383:: with SMTP id d3mr2485688otq.319.1557855202970; Tue, 14 May 2019 10:33:22 -0700 (PDT) MIME-Version: 1.0 References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <14984380.sTCEapK0kV@pintsize.usersys.redhat.com> <20190509222449.9C553404C@ld9781.wdf.sap.corp> <29960808.K0e8lGuAtk@pintsize.usersys.redhat.com> <20190514145249.C6DDB404C@ld9781.wdf.sap.corp> In-Reply-To: From: Kathleen Moriarty Date: Tue, 14 May 2019 13:32:46 -0400 Message-ID: To: David Benjamin Cc: mrex@sap.com, "" Content-Type: multipart/alternative; boundary="000000000000fc10180588dc6d0e" Archived-At: Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 14 May 2019 17:33:28 -0000 --000000000000fc10180588dc6d0e Content-Type: text/plain; charset="UTF-8" On Tue, May 14, 2019 at 12:33 PM David Benjamin wrote: > > which exact piece of popular software actually still does that? >> > It ain't curl, it ain't Chrome, it ain't Firefox. >> >> It definitely was implemented in Chrome and Firefox, which is how this >> poor document got onto standards track: >> >> https://tools.ietf.org/html/rfc7507 >> >> TLS Fallback Signaling Cipher Suite Value (SCSV) >> for Preventing Protocol Downgrade Attacks >> >> > >> > It also isn't something done automatically >> > by any TLS implementation that's even remotely popular: >> > OpenSSL, NSS, GnuTLS, schannel, Secure Transport, go... >> >> It is impossible to do this transparently, because the a connection >> is ususable after a fatal TLS hanshake failure (or unexpected socket >> closure). >> >> Any application-level cleartext negotiation will have to be repeated >> as well, and the TLS implementation typically does not know about it. >> (such as HTTP CONNECT or STARTTLS) >> >> The POODLE paper >> https://www.openssl.org/~bodo/ssl-poodle.pdf >> >> asserts that many clients doing downgrade dances exist, and at the >> time of publication, this includes Mozilla Firefox, Google Chrome and >> Microsoft Internet Explorer. >> > > Chrome has not done a downgrade dance for over three years now (Chrome 50, > released in April 2016), even for TLS 1.3. Indeed much of the fuss around > TLS 1.3 was so clients could avoid repeating this mess. > Martin, There's also value in people having fewer choices as security problems are often the result of misconfigurations. A lower number of protocols to support, chose from, and configure correctly is helpful to the larger number of implementers. Additionally, there is at least one library that planned to remove support for 1.0 and 1.1. This means that is product teams need to continue support, they have to run an older version of the library, plus newer ones for 1.3. This gets messy and increases the chance of error. The chance of misconfiguration is not insignificant (by product teams or implementers of those products). Best regards, Kathleen > > David > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Best regards, Kathleen --000000000000fc10180588dc6d0e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, May 14, 2019 at 12:33 PM Davi= d Benjamin <davidben@chromium.o= rg> wrote:
> which exact piece of popular software actually st= ill does that?
> It ain't curl, it ain't Chrome, it ain't Firefox.

It definitely was implemented in Chrome and Firefox, which is how this
poor document got onto standards track:

=C2=A0 =C2=A0https://tools.ietf.org/html/rfc7507

=C2=A0TLS Fallback Signaling Cipher Suite Value (SCSV)
=C2=A0 =C2=A0 for Preventing Protocol Downgrade Attacks

>
> It also isn't something done automatically
> by any TLS implementation that's even remotely popular:
> OpenSSL, NSS, GnuTLS, schannel, Secure Transport, go...

It is impossible to do this transparently, because the a connection
is ususable after a fatal TLS hanshake failure (or unexpected socket closur= e).

Any application-level cleartext negotiation will have to be repeated
as well, and the TLS implementation typically does not know about it.
(such as HTTP CONNECT or STARTTLS)

The POODLE paper
=C2=A0 =C2=A0https://www.openssl.org/~bodo/ssl-poodle.= pdf

asserts that many clients doing downgrade dances exist, and at the
time of publication, this includes Mozilla Firefox, Google Chrome and
Microsoft Internet Explorer.

Chrome has= not done a downgrade dance for over three years now (Chrome 50, released i= n April 2016), even for TLS 1.3. Indeed much of the fuss around TLS 1.3 was= so clients could avoid repeating this mess.=C2=A0

Martin,

There's also= value in people having fewer choices as security problems are often the re= sult of misconfigurations.=C2=A0 A lower number of protocols to support, ch= ose from, and configure correctly is helpful to the larger number of implem= enters.=C2=A0 Additionally, there is at least one library that planned to r= emove support for 1.0 and 1.1.=C2=A0 This means that is product teams need = to continue support, they have to run an older version of the library, plus= newer ones for 1.3.=C2=A0 This gets messy and increases the chance of erro= r.=C2=A0 The chance of misconfiguration is not insignificant (by product te= ams or implementers of those products).

Best regar= ds,
Kathleen
=C2=A0

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


--

Best regards,
Kathleen
--000000000000fc10180588dc6d0e-- From nobody Tue May 14 11:09:52 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75D45120155 for ; Tue, 14 May 2019 11:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.668 X-Spam-Level: X-Spam-Status: No, score=-1.668 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id idd_hkudU3gX for ; Tue, 14 May 2019 11:09:48 -0700 (PDT) Received: from mail-qt1-f194.google.com (mail-qt1-f194.google.com [209.85.160.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A06CC120137 for ; Tue, 14 May 2019 11:09:48 -0700 (PDT) Received: by mail-qt1-f194.google.com with SMTP id a39so132736qtk.2 for ; Tue, 14 May 2019 11:09:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kQYCteSKARGhY/AgzlcPOezQJjnM87/2HYwJ3iaBrzg=; b=Wdl2g2CXCG6454EdVKpNrXtLgAhtGSMGNpx8jeEbX5ZxRtMH1nsstcAMotNoDJOBSa Jq3ncJlwzouewwKXzUnGN4i7ss58Qw/ZOnARfvj2+/52x/EhFQJFms7el1HPtFNAZWXt NX54fl1Fl5TkMIJeJjRIHkIAi6V14F55pKThvwTziwRBKPtJXiezZCgURjsONcaw8CKO AfC/q2tUgUfqHSsRgUvHilT6JLFsV2wpdkgxkeTjmhXUbL4ilhWgfeay5ZVkaD0izNac XHZOdO4wuj9dCtMAC4gKc8cGoQhZtDRvnmSNpSv2DYsKXexkD3tixDOVTgZgQDedLKuU VIEQ== X-Gm-Message-State: APjAAAW/OKLJDuehCIb898AYirkb8sfSQJx5fIckBAb9BS0wHOj5LOAT hQ3KMaU+B8iEAPwn7EC1mzYxbH1xa88APxZDNiY= X-Google-Smtp-Source: APXvYqzET514Spl/xB6BajKWlHwQ0T03As2ZlPJ9rYMd/+hzoStcQ57J8cTfRyS86HSP+5RnrUf1S5NZMUSb2wL5dOI= X-Received: by 2002:a0c:929a:: with SMTP id b26mr29391971qvb.148.1557857387547; Tue, 14 May 2019 11:09:47 -0700 (PDT) MIME-Version: 1.0 References: <528b8748-6f99-4167-9075-891286b8bc26@www.fastmail.com> <2977635.mFCBgFvPmQ@pintsize.usersys.redhat.com> In-Reply-To: <2977635.mFCBgFvPmQ@pintsize.usersys.redhat.com> From: Daniel Migault Date: Tue, 14 May 2019 14:09:36 -0400 Message-ID: To: Hubert Kario Cc: tls Content-Type: multipart/alternative; boundary="00000000000032110f0588dcf01c" Archived-At: Subject: Re: [TLS] Proposal to deprecate sha1 and md5 for digital signatures in TLS 1.2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 14 May 2019 18:09:50 -0000 --00000000000032110f0588dcf01c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Please find some comments. Yours, Daniel Introduction I would suggest a reference to rfc6194 for sha1 digest as well as for hmac-sha1. I believe more text in the introduction may be needed to expose how the document impacts TLS 1.2. Typically, the impacted structure is HashAlgorithm, This structure is used by SignatureAndHashAlgorithm which defines the Signature Algorithms extension and is included in messages such as CertificateRequest In addition a number of messages rely on this extension (, ServerKeyExchange, CertificateVerify) and they will be impacted by the current document. Updating the HashAlgorithm registry was caught in the previous version by updating the enum. While this is not the standard procedure to deprecate a registry entry, I believe the intention was there. I would rather suggest to do that in the IANA section.. section 2: I am wondering whether SHOULD NOT could be replaced by MUST NOT. On the one hand, deprecation should be smooth, but on the other hand I am reading that rfc6194 and rfc6151 already started the deprecation. I would rather favour MUST NOT. Maybe we need to also indicate that MD5 or SHA-1 are ignored by the receiver. section 3: The title section maybe should be Certificate Request (without 's'). Similarly to the previous section I would suggest MUST NOT and specifying how the client would behave upon receiving MD5 or SHA-1 as hash. I believe SHA-1 has been dropped in section 4 and 5. section 6: The current rfc5246 rely on default sha-1 and md5. To ease interoperability I am wondering if we strongly recommend to provide the signature algorithm extension in addition to the default sha256. section 7: The new text is missing a capital letter: s/severs/Servers. Unless i am missing something, I would limit the update to the scope of the draft and leave the sentence discussing the group unchanged. . In the following paragraph and s/MUST not/MUST NOT/. I believe the IANA section is missing: TLS HashAlgorithm should have the values 1 md5 Y [RFCTBD] 2 sha1 Y [RFCTBD] Yours, Daniel On Tue, May 14, 2019 at 7:25 AM Hubert Kario wrote: > On Tuesday, 14 May 2019 08:34:38 CEST Loganaden Velvindron wrote: > > Latest draft is here: > > https://www.ietf.org/id/draft-lvelvindron-tls-md5-sha1-deprecate-04.txt > > why did you drop SHA-1 from Section 4 and 5? > > the note about SHA-1 in HMAC applies to ciphersuites, to state explicitly > that > ciphersuites like TLS_DHE_RSA_WITH_AES_128_CBC_SHA are _not_ deprecated b= y > it > > SKE and CV don't use HMAC > > -- > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech > Republic_______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --00000000000032110f0588dcf01c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

Please find som= e comments.=C2=A0

Yours,=C2=A0
Daniel

Introduction=C2=A0

I would suggest= a reference to rfc6194 for sha1 digest as well as for hmac-sha1.=C2=A0

I believe more text in the introduction may be needed= to expose how the document impacts TLS 1.2.=C2=A0
=C2=A0
Typically, the= impacted structure is HashAlgorithm, This structure is used by=C2=A0SignatureAndHashAlgorithm which defi= nes the Signature Algorithms extension and is included in messages such as= =C2=A0Certifica= teRequest=C2=A0= In addition a number of messages rely on this extension (, ServerKeyExchan= ge, CertificateVerify) and they will be impacted by the current document.= =C2=A0

Updating the HashAlgorithm=C2=A0registry was caught in the previous version= by updating the enum. While this is not the standard procedure to deprecat= e a registry entry, I believe the intention was there. I would=C2=A0rather= =C2=A0suggest to do that in the IANA section..=C2=A0

section 2= :

I am wondering whether SHOULD NOT could be replaced by=C2=A0 MU= ST NOT. On the one hand, deprecation should be smooth, but on the other han= d I am reading that rfc6194 and rfc6151 already started the deprecation. I = would rather favour MUST NOT.=C2=A0 =C2=A0

Maybe w= e need to also indicate that MD5 or SHA-1 are ignored by the receiver.

section 3:

The title section = maybe should be Certificate Request (without 's').=C2=A0
= Similarly to the previous section I would suggest MUST NOT and specifying h= ow the client would behave upon receiving MD5 or SHA-1 as hash.=C2=A0 =C2= =A0

I believe SHA-1 has been dropped in section 4 and 5= .=C2=A0

section 6:

The current = rfc5246 rely on default sha-1 and md5. To ease interoperability I am wonder= ing if we strongly recommend to provide the signature algorithm extension i= n addition to the default sha256.=C2=A0=C2=A0

sect= ion 7:

The new text is missing a capital letter: s= /severs/Servers.=C2=A0

Unless i am missing somethi= ng, I would limit the update to the scope of the draft and leave the senten= ce discussing the group unchanged. .=C2=A0=C2=A0

I= n the following paragraph and s/MUST not/MUST NOT/.

I believe the IANA section is missing:

TLS HashA= lgorithm should have the values=C2=A0

1 md5 Y [RFCTBD]
2 sha1 Y<= span style=3D"white-space:pre"> [RFCTBD]

=C2=A0 = =C2=A0
Yours,=C2=A0
Daniel
=C2=A0
=

On Tue, May 14, 2019 at 7:2= 5 AM Hubert Kario <hkario@redhat.com> wrote:
On Tuesday, 14 May 2019 08:34:38 CEST Loganaden Velvindr= on wrote:
> Latest draft is here:
> https://www.ietf.org/id/= draft-lvelvindron-tls-md5-sha1-deprecate-04.txt

why did you drop SHA-1 from Section 4 and 5?

the note about SHA-1 in HMAC applies to ciphersuites, to state explicitly t= hat
ciphersuites like TLS_DHE_RSA_WITH_AES_128_CBC_SHA are _not_ deprecated by = it

SKE and CV don't use HMAC

--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00=C2=A0 Brno, Czech Republic= _______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--00000000000032110f0588dcf01c-- From nobody Tue May 14 11:11:33 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 007EE120155 for ; Tue, 14 May 2019 11:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bxt9HR8pI5GW for ; Tue, 14 May 2019 11:11:30 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F4A01200A3 for ; Tue, 14 May 2019 11:11:30 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1ECCB3092678; Tue, 14 May 2019 18:11:30 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.83]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3A22A12A68; Tue, 14 May 2019 18:11:29 +0000 (UTC) From: Hubert Kario To: mrex@sap.com Cc: tls@ietf.org, Martin Thomson Date: Tue, 14 May 2019 20:11:28 +0200 Message-ID: <12276928.OsXPxM6NY9@pintsize.usersys.redhat.com> In-Reply-To: <20190514145249.C6DDB404C@ld9781.wdf.sap.corp> References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <29960808.K0e8lGuAtk@pintsize.usersys.redhat.com> <20190514145249.C6DDB404C@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2792222.aEXbVoH1CH"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.43]); Tue, 14 May 2019 18:11:30 +0000 (UTC) Archived-At: Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 14 May 2019 18:11:32 -0000 --nextPart2792222.aEXbVoH1CH Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Tuesday, 14 May 2019 16:52:49 CEST Martin Rex wrote: > Hubert Kario wrote: > > Martin Rex wrote: > >> Hubert Kario wrote: > >>> MD5 was deprecated and removed by basically every library > >>> and can't be used in TLS 1.2, I specifically meant SHA1 > >>=20 > >> MD5 deprecated ? Nope, glaring emtpy: > >> https://www.rfc-editor.org/errata_search.php?rfc=3D5246 > >>=20 > >> MD5 removed ? Mostly, but several implementors had to be prodded with > >>=20 > >> with CVE-2015-7575 (SLOTH) to remove it. > >=20 > > I meant in practice > >=20 > >> The real issue at hand is: > >> Prohibiting TLSv1.0 and TLSv1.1 is going to result in lots of > >> interop problems, while at the same time providing *ZERO* > >> security benefit. > >=20 > > that's your opinion, not an established fact >=20 > You got this backwards. >=20 > There is a bold assertion that disabling TLSv1.0 and TLSv1.1 (alone) > would provide security benefits, but a complete lack of proof. there are attacks, like BEAST, that TLS 1.0 is vulnerable to that TLS 1.1 a= nd=20 TLS 1.2 are not - that's a fact there are ciphersuites that are invulnerable to Lucky13 and similar style o= f=20 attacks that can not be used with TLS 1.0 or TLS 1.1 - that's a fact that doesn't sound to me like "ZERO security benefit", and similar issues w= ere=20 the reason why we generally don't use SSL2 and SSL3 any more and why RFC 75= 68=20 was published > On digitally_signed, is proven that TLSv1.2 as defined by rfc5246 > is the weakest of them all. yes, provided that: - MD5 is actually in use - or Joux does not hold and MD5+SHA1 is _meaningfully_ stronger[1] than SH= A-1=20 alone *and* SHA-1 is actually in use those are big if's 1 - where meaningfully =3D at least by a work factor of 2^10 =20 > >> What *WOULD* provide *HUGE* benefit, would be to remove the > >> dangerous "protocol version downgrade dance" from careless > >> applications, > >> that is the actual problem known as POODLE, because this subverts the > >> cryptographic procection of the TLS handshake protocol. > >> =20 > >> We've known this downgrade dance to be a problem since the discussion > >> of what became rfc5746. Prohibiting automatic protoocol version > >> downgrade dances is going to ensure that two communication peers > >> that support TLSv1.2 will not negotiate a lower TLS protocol version. > >=20 > > which exact piece of popular software actually still does that? > > It ain't curl, it ain't Chrome, it ain't Firefox. >=20 > It definitely was implemented in Chrome and Firefox, which is how this > poor document got onto standards track: key words: "still" and "was" =20 > The POODLE paper > https://www.openssl.org/~bodo/ssl-poodle.pdf >=20 > asserts that many clients doing downgrade dances exist, and at the > time of publication, this includes Mozilla Firefox, Google Chrome and > Microsoft Internet Explorer. either we consider clients that haven't been updated for half a decade now = to=20 be of importance, then disabling support for old protocol versions has=20 meaningful security benefit, or we ignore them as they include insignifican= t=20 percentage of users and are vulnerable to much easier attacks anyway so, which way is it? =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart2792222.aEXbVoH1CH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAlzbBNAACgkQkqjRuAHS 9fW47w//RJ+HhEkvtUS/sRjicVIsfDzLYXI7oCpMjb6oEaHxC4Ft4hegSxyVtCyp r3/KcO5kmJbWKB70W7ow2o2yIQ63lIpC6YrW4Y8P+HCaFhakDQu4k+4dNs/Cl+Kk zNgfaJxgEi0EvC4VUnGSy+ZyKtBtVtsc+N5ntDUGZmmkFJHO0C5kV8IrAsjYSCvp TLDDZTp1KHva9/wRUSGS2xckghJNY08ZyDNk2Ro54gz0FILt1nJIW4IGazyQGVr+ dKjFvoR7ClrJz9GzawjDufWFhW9Fy9daezky2qbOEyHjIdh/vbYUazsynShWuP+c MqhO64qQzV/aPUxpBM7cBMg0r2O4+exhND4vQcLv/4rCKdXSlhthcAa7cJ9ZKAn7 X1ihia4xw4cnJ8DRfwGe7td1T0OfG7gZy2O+zJpy8V81bwAt4RJ1zt98oiPMaLxA frzZe1rbVXhuf9RNpttjyYtfs6XsHjqlqvGlGb1DNn7DS6LKSaXfxj/LCmiQN0qe 3RQ3rpSGQQlH+viMdvmF0mXh1IbFeIMS6FB+kLr7YFAB9RPDV6ewmGAPMz/So2Sb E/TIHohL71c7aC3lQ2ifWR5/km9m/CkqkzWefJBs4yglkolxPnu+2H2z8McqAuHo UecgtREMQo5TnKflBjwTJuhvwlQxltKVkfbg8dLcuf/8WppWyqQ= =uJLA -----END PGP SIGNATURE----- --nextPart2792222.aEXbVoH1CH-- From nobody Tue May 14 11:16:32 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74DFB120155 for ; Tue, 14 May 2019 11:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fn1edq2BczIh for ; Tue, 14 May 2019 11:16:29 -0700 (PDT) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27B80120096 for ; Tue, 14 May 2019 11:16:29 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id p2so38577iol.2 for ; Tue, 14 May 2019 11:16:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hBG//gYy4I1AaZdylZTcy8nNbHKlnj1TVu8a1lCtD5A=; b=YjzIdR8e5ouGq0D7dSpOzF8K4RCh/BnU6xKeGWYUHALAD5+E38JkHA1XKvQcBADNTl ziI6iHp+9dwbFDVPgTSgLjBXZgieIOAw4I/9PN4td/oV7QYPvb21/k3Dx7M1nOQDVU8x Qar+OlCImYC7O7D1qBwm5VbKWmgwknmK+spVkNuPhwfv51T6xjMlus0fn1fHABOk2Zl2 hhI6rvk82Du/QcUnKy6heNCjcVDuTRbxj2gW1n0IZCgdXfxKhaZaIeY3p1448gj4AU6v ZFjiuCmpwQ+7hZGK8Sn/aKATJCyYSvuhh54vfqw1ZJ/sM60MAqpoCpnIMrvlsqEOxkes YJ2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hBG//gYy4I1AaZdylZTcy8nNbHKlnj1TVu8a1lCtD5A=; b=FjhQcTJpXg/2bmzQC9yln3u7y91Q/UfonX4jmFQC3alB1B5cCHyxXOJKSW/7m8BaZI VB7W3i1S1J7mPItfLQjX1sWCx1SAN+x1CUdKf4ATkBL3s7pa/0EGzFIJ9QpDfab/wGrg qpEWHu1/9Ugj0pNJ4i5RlsWOWdNIQlh/2cJMh6vDyZ39+yrGxQDndRsQ5INjduA4R9Si B5YfIF/eGv8h4JoA+vDRkphYAnrRrHX9XiQTxMcgDNjCxPWftEI3YMsVV8F1UkFN3mwW DE58qEqRNZ1qs8ZY/weJjGvuIX3qGjqynbfik24/kG8pyNHCi+vpR1m012/INMxi+g5l 0G/w== X-Gm-Message-State: APjAAAXbJySW6P+88AKPcCaNqZwHsesJaUh7n5ulI5t3sWBwpH8LOCbP 8dd47aaEZloK0Wp1Zog6rueBoaEsgOO4DBV2yL4= X-Google-Smtp-Source: APXvYqy8qZhzUisUBMCqzm7efm8ROISfIRxfjNb8zlPo/z9cew5IXL/PEoOEtoz+EHOMzopkTattftDRQNVvdfYpEvY= X-Received: by 2002:a5d:9dd2:: with SMTP id 18mr188992ioo.7.1557857788457; Tue, 14 May 2019 11:16:28 -0700 (PDT) MIME-Version: 1.0 References: <528b8748-6f99-4167-9075-891286b8bc26@www.fastmail.com> <2977635.mFCBgFvPmQ@pintsize.usersys.redhat.com> In-Reply-To: <2977635.mFCBgFvPmQ@pintsize.usersys.redhat.com> From: Loganaden Velvindron Date: Tue, 14 May 2019 22:16:17 +0400 Message-ID: To: Hubert Kario Cc: "" , Martin Thomson Content-Type: multipart/alternative; boundary="0000000000001777660588dd0840" Archived-At: Subject: Re: [TLS] Proposal to deprecate sha1 and md5 for digital signatures in TLS 1.2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 14 May 2019 18:16:32 -0000 --0000000000001777660588dd0840 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, May 14, 2019 at 3:24 PM Hubert Kario wrote: > On Tuesday, 14 May 2019 08:34:38 CEST Loganaden Velvindron wrote: > > Latest draft is here: > > https://www.ietf.org/id/draft-lvelvindron-tls-md5-sha1-deprecate-04.txt > > why did you drop SHA-1 from Section 4 and 5? > > It was done following this comment from David Cooper. " [..] While they may be subject to collision attacks, SHA-1 is still considered secure in cases in which collision resistance is not required, and I do not believe that collision resistance is required when SHA-1 is used to create the "signatures" in the ServerKeyExchange and CertificateVerify messages. " > the note about SHA-1 in HMAC applies to ciphersuites, to state explicitly > that > ciphersuites like TLS_DHE_RSA_WITH_AES_128_CBC_SHA are _not_ deprecated b= y > it > > SKE and CV don't use HMAC > --=20 > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --0000000000001777660588dd0840 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, May 14, 2019 at 3:24 PM Huber= t Kario <hkario@r= edhat.com> wrote:
On Tuesday, 14 May 2019 08:34:38 CEST Loganaden Velvindron wrote= :
> Latest draft is here:
> https://www.ietf.org/id/= draft-lvelvindron-tls-md5-sha1-deprecate-04.txt

why did you drop SHA-1 from Section 4 and 5?

It was done following this comment from David Cooper.=
"
[..] While they may be subject to collision att= acks, SHA-1 is still considered secure in cases in which collision resistan= ce is not required, and I do not believe that collision resistance is requi= red when SHA-1 is used to create the "signatures" in the ServerKe= yExchange and CertificateVerify messages.
"
=C2=A0
the note about SHA-1 in HMAC applies to ciphersuites, to state explicitly t= hat
ciphersuites like TLS_DHE_RSA_WITH_AES_128_CBC_SHA are _not_ deprecated by = it

SKE and CV don't use HMAC=C2=A0
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00=C2=A0 Brno, Czech Republic=
--0000000000001777660588dd0840-- From nobody Tue May 14 11:26:30 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A09C212017E for ; Tue, 14 May 2019 11:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2FDJygQfeze for ; Tue, 14 May 2019 11:26:15 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 045F4120046 for ; Tue, 14 May 2019 11:26:09 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B0C603086232; Tue, 14 May 2019 18:26:08 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.83]) by smtp.corp.redhat.com (Postfix) with ESMTP id 313E85D72E; Tue, 14 May 2019 18:26:08 +0000 (UTC) From: Hubert Kario To: Daniel Migault Cc: tls Date: Tue, 14 May 2019 20:26:01 +0200 Message-ID: <2162072.cel6DGkFtN@pintsize.usersys.redhat.com> In-Reply-To: References: <2977635.mFCBgFvPmQ@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1696327.GYAV1sHTnv"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.42]); Tue, 14 May 2019 18:26:08 +0000 (UTC) Archived-At: Subject: Re: [TLS] Proposal to deprecate sha1 and md5 for digital signatures in TLS 1.2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 14 May 2019 18:26:29 -0000 --nextPart1696327.GYAV1sHTnv Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Tuesday, 14 May 2019 20:09:36 CEST Daniel Migault wrote: > section 2: >=20 > I am wondering whether SHOULD NOT could be replaced by MUST NOT. On the > one hand, deprecation should be smooth, but on the other hand I am reading > that rfc6194 and rfc6151 already started the deprecation. I would rather > favour MUST NOT. >=20 > Maybe we need to also indicate that MD5 or SHA-1 are ignored by the > receiver. that was the intention behind my suggestion for SHOULD NOT - i.e. the serve= r=20 MUST be able to handle ClientHello that does advertise them, but in practic= e=20 ignore them based on required handling for SKE and CV =20 > section 3: >=20 > The title section maybe should be Certificate Request (without 's'). > Similarly to the previous section I would suggest MUST NOT and specifying > how the client would behave upon receiving MD5 or SHA-1 as hash. same as above =20 > section 6: >=20 > The current rfc5246 rely on default sha-1 and md5. To ease interoperabili= ty > I am wondering if we strongly recommend to provide the signature algorithm > extension in addition to the default sha256. no, sha-1 is the default in case the extension is omitted, but then we also= =20 specify that if the extension is omitted now, the negotiation MUST fail the recommendation for sha256 is that it in practice has to be included in = the=20 extension as some servers use the extension to select server certificate, s= o=20 omitting sha256 there will cause the connection to fail this is also partially the reason for a SHOULD NOT instead of MUST NOT for= =20 section 2 and 3 =E2=80=93 I do not know how those servers handle interactio= n between=20 SHA-1 missing in the extension and root CA (self-signed certificate) being= =20 signed by SHA-1 =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart1696327.GYAV1sHTnv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAlzbCDkACgkQkqjRuAHS 9fWoeA/8C76winFYwN57dkDgb5qxOrwKr9HBLkrvcmk4ntzCFHayxrEy5plMqVv7 W2VU+IOzOCjcDeqc8+Ma8tyTUVl2T7i7Ab2D0uReo2n2aZI1MnFg2SHS1lxyuuAf 5m6q3+D4oNEqKCCbGBKShJE8OYaNPaNYQzUTyKUyZiFkevuHzwM5doOzy6Hzh5EH Sx+Vlg9doYUhkOR0royhF6/twxeGzITrWes/i3AvpmiPUrbgh5OwBGrikag4rWXa d9x60nAhoGadLu05HdDAx403XPvc4Nx+JfdSgra+5oj6bmeZ1nI8dZA/3yZufWGy AOeCrdqqnkuxcfL9vrSzGZWb0nsuO8bkqAkcD5cVEzpXlOqydDDDg9s2t5/4s0Oo zKfQ9Nk9OqUFhCQ1Zi0hVlgZrpUKFP1Ik6a8g6ndss/857aTlYVkYnqbZfNiedQG cHNu8ohDaoPBincj6Axnq2xJxHrojfnGOnLBg3Vd9n09HGdYMfGgmtPsNUapmy3T tV5RLNzCzRMExhKtEHROCRMFdsj4GSj1To7cP4Drjm3GUlWXiUGQqjY3AsTj3jGH 8DZY3sDl9zSPgcNtDlTX+7BTzLAFrTOPKAbnv9N0mWlziMwUK8fnEGLBywfFP/Us fNYjUCfg93qx4eKRG2Zc5wK5bxV9/7lndQGFFqELllLEqpY2yfU= =dD3+ -----END PGP SIGNATURE----- --nextPart1696327.GYAV1sHTnv-- From nobody Tue May 14 11:57:28 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C260C1200B1 for ; Tue, 14 May 2019 11:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5euMKbyvexrH for ; Tue, 14 May 2019 11:57:24 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C456D1200B5 for ; Tue, 14 May 2019 11:57:20 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4BDB4C04D318; Tue, 14 May 2019 18:57:20 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.83]) by smtp.corp.redhat.com (Postfix) with ESMTP id 82CB0608B9; Tue, 14 May 2019 18:57:19 +0000 (UTC) From: Hubert Kario To: Loganaden Velvindron Cc: "" , Martin Thomson Date: Tue, 14 May 2019 20:57:18 +0200 Message-ID: <10904461.vh6UM9T2du@pintsize.usersys.redhat.com> In-Reply-To: References: <2977635.mFCBgFvPmQ@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2868793.0BG0zVrM6B"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Tue, 14 May 2019 18:57:20 +0000 (UTC) Archived-At: Subject: Re: [TLS] Proposal to deprecate sha1 and md5 for digital signatures in TLS 1.2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 14 May 2019 18:57:27 -0000 --nextPart2868793.0BG0zVrM6B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Tuesday, 14 May 2019 20:16:17 CEST Loganaden Velvindron wrote: > On Tue, May 14, 2019 at 3:24 PM Hubert Kario wrote: > > On Tuesday, 14 May 2019 08:34:38 CEST Loganaden Velvindron wrote: > > > Latest draft is here: > > > https://www.ietf.org/id/draft-lvelvindron-tls-md5-sha1-deprecate-04.t= xt > >=20 > > why did you drop SHA-1 from Section 4 and 5? >=20 > It was done following this comment from David Cooper. >=20 > " > [..] While they may be subject to collision attacks, SHA-1 is still > considered secure in cases in which collision resistance is not required, > and I do not believe that collision resistance is required when SHA-1 is > used to create the "signatures" in the ServerKeyExchange and > CertificateVerify messages. > " SLOTH paper disagrees on that as far as CertificateVerify message is concer= ned SP 800-52 rev-2 does not provide much in terms of justification why SLOTH=20 paper would be wrong and allows for SHA-1 signatures only in TLS 1.0 and TL= S=20 1.1, it does not explicitly state that SHA-1 signatures in TLS 1.2 are=20 allowed... =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart2868793.0BG0zVrM6B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAlzbD44ACgkQkqjRuAHS 9fWEQA/+MV4uFE8KiG3S8LfgMy3jbkTMC88ivoy+71/QlbFEzFakj9YWIxDRZwXU 8HLFz6Tn5VJE59u2mvyu7/f+lgC40DO9yWbXvRtgANW7v+YducHO/qShr5/oWK5k kBRXSJQQT6jOPd4CtjvKKTZptuNiETPCgv7u9phH73wEWxCVqwxDSCOQjpvE/epB KyGtngwFyvfC0J0RA82HBd6g/0hpVmV8OGkhL6PeekkOdo8DCDkwNgQtiRFoNYxZ QtlXBQqDD+GtHAzS42V9luTQV+WlaszCjABjvnt9ZiLlzi5qxArbuQHsOsmoDpKM LyQf9V0HE2ScOVD+pTzHJUX029eqqQWjQTgcDFDQTqyAHfwSW3TE0TvL2/WpxT7m sQrjRQ0kOAkj3Db1NFqvykTC0YZ59eI/F3Sv8YZ2DDDiQy5K9S+XOcpRPBzlp105 P+5an1pc7VMZJ11LNIPWwhUNpLi+SslZj/3ANaB/nEG7JHNQ7hBWNnc6meSHaS4p 5zqEL6/r4ryPTCXkDCp083So++Rh4QDYHrTZlIl5buwVbgqwBCViR4dviKHGbG1c bcT0uNXGSgnVREYt4wX9kxR8ClWDXLycDg0GrjsyfCW1XlhR6Ae46Jit/WD/kDru GKBuuXOSQyKKvpzTK2LulfGEzmdHNyRMgGjPl3l9OI0Yvn01T3M= =2uY2 -----END PGP SIGNATURE----- --nextPart2868793.0BG0zVrM6B-- From nobody Tue May 14 12:13:30 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC62A1200D7 for ; Tue, 14 May 2019 12:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.668 X-Spam-Level: X-Spam-Status: No, score=-1.668 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6iKHXGXLNBy for ; Tue, 14 May 2019 12:13:26 -0700 (PDT) Received: from mail-qt1-f174.google.com (mail-qt1-f174.google.com [209.85.160.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD25E1200DE for ; Tue, 14 May 2019 12:13:25 -0700 (PDT) Received: by mail-qt1-f174.google.com with SMTP id m32so400860qtf.0 for ; Tue, 14 May 2019 12:13:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oP8POdvj3g2sLIPqiRVAV78OgMl2iZ/JhkzJ0wfNOQM=; b=gYVUQlaj8uxiW6TbF1hZSguVZ38xpa+TIil0bQfi8UgeBauI7BqE9TFT89VpsGR7D9 wFsqqq0SkW01y2IJZTtaWv2k4y287rKDo3L0KWjN8Xh8lggpO+1R+cbuZncVyQ3rxzBX gG9ysHWnAvK4pV5fJpG1lhw0/gh+3nt3klT3m7NDicwCNA+jz0Mnx8VMrxVMeqYDI7zA Pk8za0yb5f4XbBY0aaa6xT1n9U+F5RglpPG1+Nkt8HZp8SYsZy1NK86wlX6D9NxoB9du FfR1D7J5TPws/jadV05zW2JpqaCWtElwM3lI06NXV37D9WtGJuOTDkgr18j38Oz3Cu1A JqTA== X-Gm-Message-State: APjAAAXqoORsrn95aWrO+YRTPv88sGnfNxR6AwFFkdX9/9qGY/g3i3ln bhqTB7MWyk5T2H6B14CZ+pQKddkc4rO+XOBQ7+8= X-Google-Smtp-Source: APXvYqxuWzKEZfSMfJxA+WnHyQgocS1ecyYzmZuWSS7QduJSFpXuWtigdg5dvNCm61EEeapd6Io7sdVGm6Su7qJ9nXc= X-Received: by 2002:ac8:1082:: with SMTP id a2mr31099673qtj.231.1557861204709; Tue, 14 May 2019 12:13:24 -0700 (PDT) MIME-Version: 1.0 References: <2977635.mFCBgFvPmQ@pintsize.usersys.redhat.com> <2162072.cel6DGkFtN@pintsize.usersys.redhat.com> In-Reply-To: <2162072.cel6DGkFtN@pintsize.usersys.redhat.com> From: Daniel Migault Date: Tue, 14 May 2019 15:13:13 -0400 Message-ID: To: Hubert Kario Cc: tls Content-Type: multipart/alternative; boundary="000000000000b7565e0588ddd391" Archived-At: Subject: Re: [TLS] Proposal to deprecate sha1 and md5 for digital signatures in TLS 1.2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 14 May 2019 19:13:29 -0000 --000000000000b7565e0588ddd391 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, May 14, 2019 at 2:27 PM Hubert Kario wrote: > On Tuesday, 14 May 2019 20:09:36 CEST Daniel Migault wrote: > > section 2: > > > > I am wondering whether SHOULD NOT could be replaced by MUST NOT. On th= e > > one hand, deprecation should be smooth, but on the other hand I am > reading > > that rfc6194 and rfc6151 already started the deprecation. I would rathe= r > > favour MUST NOT. > > > > Maybe we need to also indicate that MD5 or SHA-1 are ignored by the > > receiver. > > that was the intention behind my suggestion for SHOULD NOT - i.e. the > server > MUST be able to handle ClientHello that does advertise them, but in > practice > ignore them based on required handling for SKE and CV > > got it, then the text needs to be explicit in each case we should not hide ourselves behind a vague SHOULD. > > section 3: > > > > The title section maybe should be Certificate Request (without 's'). > > Similarly to the previous section I would suggest MUST NOT and specifyi= ng > > how the client would behave upon receiving MD5 or SHA-1 as hash. > > same as above > > > section 6: > > > > The current rfc5246 rely on default sha-1 and md5. To ease > interoperability > > I am wondering if we strongly recommend to provide the signature > algorithm > > extension in addition to the default sha256. > > no, sha-1 is the default in case the extension is omitted, but then we > also > specify that if the extension is omitted now, the negotiation MUST fail > the recommendation for sha256 is that it in practice has to be included i= n > the > extension as some servers use the extension to select server certificate, > so > omitting sha256 there will cause the connection to fail > > Works for me. I believe the reasoning worth being mentioning. In addition= , the section update of 5246 coudl also emphasis changes are not limited to the NEW text. > this is also partially the reason for a SHOULD NOT instead of MUST NOT fo= r > section 2 and 3 =E2=80=93 I do not know how those servers handle interact= ion > between > SHA-1 missing in the extension and root CA (self-signed certificate) bein= g > signed by SHA-1 > > I had the same question ;-) and of course not the response. I believe that we should clarify this and document the choice for MUST/SHOULD. > -- > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech > Republic_______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000b7565e0588ddd391 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, May 14, 2019 at 2:27 PM Huber= t Kario <hkario@redhat.com> = wrote:
On Tuesda= y, 14 May 2019 20:09:36 CEST Daniel Migault wrote:
> section 2:
>
> I am wondering whether SHOULD NOT could be replaced by=C2=A0 MUST NOT.= On the
> one hand, deprecation should be smooth, but on the other hand I am rea= ding
> that rfc6194 and rfc6151 already started the deprecation. I would rath= er
> favour MUST NOT.
>
> Maybe we need to also indicate that MD5 or SHA-1 are ignored by the > receiver.

that was the intention behind my suggestion for SHOULD NOT - i.e. the serve= r
MUST be able to handle ClientHello that does advertise them, but in practic= e
ignore them based on required handling for SKE and CV


got it, then the text needs to be expl= icit in each case we should not hide ourselves behind a vague SHOULD.
=
=C2=A0
> section 3:
>
> The title section maybe should be Certificate Request (without 's&= #39;).
> Similarly to the previous section I would suggest MUST NOT and specify= ing
> how the client would behave upon receiving MD5 or SHA-1 as hash.

same as above

> section 6:
>
> The current rfc5246 rely on default sha-1 and md5. To ease interoperab= ility
> I am wondering if we strongly recommend to provide the signature algor= ithm
> extension in addition to the default sha256.

no, sha-1 is the default in case the extension is omitted, but then we also=
specify that if the extension is omitted now, the negotiation MUST fail
the recommendation for sha256 is that it in practice has to be included in = the
extension as some servers use the extension to select server certificate, s= o
omitting sha256 there will cause the connection to fail

Works for me. I believe the reasoning worth being men= tioning. In addition, the section update of 5246 coudl also emphasis change= s are not limited to the NEW text.=C2=A0
=C2=A0=C2=A0
this is also partially the reason for a SHOULD NOT instead of MUST NOT for =
section 2 and 3 =E2=80=93 I do not know how those servers handle interactio= n between
SHA-1 missing in the extension and root CA (self-signed certificate) being =
signed by SHA-1

I had the same question ;-) and of course not the res= ponse.=C2=A0 I believe that we should clarify this and document the choice = for MUST/SHOULD.=C2=A0 =C2=A0=C2=A0
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00=C2=A0 Brno, Czech Republic= _______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000b7565e0588ddd391-- From nobody Tue May 14 13:41:51 2019 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B45C120224; Tue, 14 May 2019 13:41:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tls@ietf.org Message-ID: <155786650930.30258.5108155458558803129@ietfa.amsl.com> Date: Tue, 14 May 2019 13:41:49 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-external-psk-importer-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list 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, 14 May 2019 20:41:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : Importing External PSKs for TLS Authors : David Benjamin Christopher A. Wood Filename : draft-ietf-tls-external-psk-importer-00.txt Pages : 8 Date : 2019-05-14 Abstract: This document describes an interface for importing external PSK (Pre- Shared Key) into TLS 1.3. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-external-psk-importer/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-00 https://datatracker.ietf.org/doc/html/draft-ietf-tls-external-psk-importer-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 14 13:53:06 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CED9C120128 for ; Tue, 14 May 2019 13:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImXCAvyFzVqv for ; Tue, 14 May 2019 13:53:01 -0700 (PDT) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15593120118 for ; Tue, 14 May 2019 13:53:01 -0700 (PDT) Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 453VJC0kXHz6F; Tue, 14 May 2019 22:52:59 +0200 (CEST) X-purgate-ID: 152705::1557867179-0000020D-97A14CC5/0/0 X-purgate-size: 2456 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail07.wdf.sap.corp (Postfix) with ESMTPS id 453VJB2zfPzGp7W; Tue, 14 May 2019 22:52:58 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 5C457404C; Tue, 14 May 2019 22:52:58 +0200 (CEST) In-Reply-To: <12276928.OsXPxM6NY9@pintsize.usersys.redhat.com> References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <29960808.K0e8lGuAtk@pintsize.usersys.redhat.com> <20190514145249.C6DDB404C@ld9781.wdf.sap.corp> <12276928.OsXPxM6NY9@pintsize.usersys.redhat.com> To: Hubert Kario Date: Tue, 14 May 2019 22:52:58 +0200 (CEST) CC: mrex@sap.com, tls@ietf.org, Martin Thomson Reply-To: mrex@sap.com MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20190514205258.5C457404C@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 14 May 2019 20:53:04 -0000 Hubert Kario wrote: > > there are attacks, like BEAST, that TLS 1.0 is vulnerable to that > TLS 1.1 and TLS 1.2 are not - that's a fact there are ciphersuites > that are invulnerable to Lucky13 and similar style of attacks that > can not be used with TLS 1.0 or TLS 1.1 - that's a fact BEAST is an attack against Web Browsers (and the abuse known as SSL-VPNs), it is *NO* attack against TLS -- whose design properties are described in appendix F of rfc5246, and there is a trivial workaround for those few apps that were affected. Continued mentioning of BEAST really only means one thing: severe crypto-cluelessness. http://www.educatedguesswork.org/2011/11/rizzoduong_beast_countermeasur.html There are two things that BEAST showed: Running arbitrary attacker-supplied active content is a bad idea! Performing protocol version downgrade dances is a bad idea. Lucky thirteen applies equally to all three: TLSv1.0, TLSv1.1 and TLSv1.2, but was a real-world issue only for borked implementations of DTLS (those implementations that were providing a no-limits guessing oracle. > > that doesn't sound to me like "ZERO security benefit", You seem to be confusing the difference between (1) ensuring that TLSv1.2 support is enabled with (2) disabling TLSv1.0 + TLSv1.1 support. If you do (1), then (2) does not add security benefits. > >> On digitally_signed, is proven that TLSv1.2 as defined by rfc5246 >> is the weakest of them all. > > yes, provided that: > - MD5 is actually in use > - or Joux does not hold and MD5+SHA1 is _meaningfully_ stronger[1] > than SHA-1 alone *and* SHA-1 is actually in use MD5 || SHA-1 is **ALWAYS** meaninfully stronger than SHA-1 alone, *NO* if! > >> The POODLE paper >> https://www.openssl.org/~bodo/ssl-poodle.pdf >> >> asserts that many clients doing downgrade dances exist, and at the >> time of publication, this includes Mozilla Firefox, Google Chrome and >> Microsoft Internet Explorer. > > either we consider clients that haven't been updated for half a decade now to > be of importance, then disabling support for old protocol versions has > meaningful security benefit, or we ignore them as they include insignificant > percentage of users and are vulnerable to much easier attacks anyway > > so, which way is it? MSIE seems to still be doing downgrade dances _today_, btw. -Martin From nobody Wed May 15 06:21:05 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B079A120117 for ; Wed, 15 May 2019 06:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSDVTLKW-vUS for ; Wed, 15 May 2019 06:21:01 -0700 (PDT) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9898A12007A for ; Wed, 15 May 2019 06:21:01 -0700 (PDT) Received: by mail-qk1-x732.google.com with SMTP id j20so1454158qke.1 for ; Wed, 15 May 2019 06:21:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=DbyBmEXTNjIJi7sx5CW9Yp0Yr3fi9KEgr3+inzAL9cc=; b=iifl2zPcs6fahcGKllZ2YGpgz3bTPKAcjx6UXhJhG5LhSBpotWJl8IrCjdpeVeQQCB pwfvFTLqh/Znj2rA/Jch7TU5SfHWD++dRaF5q3KpoEZKVqvZCB2ElvbGbhBVuunE+QoU ZHnNOrM0HB/Ec/CGqFZRzEUITfwduGhe1S8M6ar8JlIUwZ1NvO0zh6hznCPw9gogPll2 GTGF3ysMd7amaj4qXsY6NnrsjMeRO3zJtbxk/al6DaRB/dmcFjox+xOBhkdEquGE5tQA /MI74D5jCCkXgmVtDIV4l/qEHWAo2cBqH7Cq/tPgJk03IjQ3rfrlWeq8qqAB5FHIIsTq K2RA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=DbyBmEXTNjIJi7sx5CW9Yp0Yr3fi9KEgr3+inzAL9cc=; b=HbRv+RqlynshC9Ze31URzt8YOYEn9RmGT7vfg44C7HyCLos71bees/oTKjViQJoQST KqdasFUIjpAR8MhN/wvEJPAMbmmJxWGue++6qtY/BrV+4ddvhlG+nGMH52vIEoR9NgR0 lVqZF4lJPZ1mLxYYcrEVx+Rc8Mxcu/smfWIoyKSeulOhJqR6FI7agBOn0+KKiuxNqdxy EI8i98CM2eaAjgPI4VjdMNFGip34jFb4LU0hVp2zGn86bsoj/KWOoybMMdxrYpUAf3ex SrAHBRxkIvTmrAMSrCuLMs8hFBlUtsb+RHtSgbIam0306Lc2JTXOREj8yj9pTU0LW+zA FeYw== X-Gm-Message-State: APjAAAXtMfGUPmvUgEsIbFBH0Xef3bH24p0skSoiSxKkUFYYCpoxOVBu m+UEZFLrCagm7Z2AxHkCBcavgAmQ0Gb52SrNvb+6vsT7x8c= X-Google-Smtp-Source: APXvYqx0J7pdPmJv3jbJxqqhY3YVDSzMCd6o+1ld81B0LCxLZNZ7UoUJK51Gg3B+0r+8dORWxTK14bMU7v1TZhdRbfA= X-Received: by 2002:a37:4c02:: with SMTP id z2mr21733747qka.1.1557926460272; Wed, 15 May 2019 06:21:00 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Joseph Salowey Date: Wed, 15 May 2019 06:20:48 -0700 Message-ID: To: "" Content-Type: multipart/alternative; boundary="0000000000004044b00588ed05c6" Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-tls13-cert-with-extern-psk X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 15 May 2019 13:21:04 -0000 --0000000000004044b00588ed05c6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The last call has come and gone without any comment. Please indicate if you have reviewed the draft even if you do not have issues to raise so the chairs can see who has reviewed it. Also indicate if you have any plans to implement the draft. On Tue, Apr 9, 2019 at 8:51 PM Joseph Salowey wrote: > This is the working group last call for the "TLS 1.3 Extension for > Certificate-based Authentication with an External Pre-Shared Key=E2=80=9D= draft > available at > https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-ps= k/. > Please review the document and send your comments to the list by 2359 UTC > on 23 April 2019. > > Thanks, > Chris, Joe, and Sean > --0000000000004044b00588ed05c6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The last call has come and gone without any comment.=C2=A0= Please indicate if you have reviewed the draft even if you do not have iss= ues to raise so the chairs can see who has reviewed it.=C2=A0 Also indicate= if you have any plans to implement the draft.=C2=A0

On Tue, Apr 9, 2019 at = 8:51 PM Joseph Salowey <joe@salowey.n= et> wrote:
This is the = working group last call for the "TLS 1.3 Extension for Certificate-bas= ed Authentication with an External Pre-Shared Key=E2=80=9D draft available = at=C2=A0https://datatracker.ietf.org/doc/dra= ft-ietf-tls-tls13-cert-with-extern-psk/. Please review the document and= send your comments to the list by 2359 UTC on 23 April 2019.

Thanks,
Chris, Joe, and Sean=
--0000000000004044b00588ed05c6-- From nobody Wed May 15 06:55:58 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9E1312016D for ; Wed, 15 May 2019 06:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUcDZ0lixLLf for ; Wed, 15 May 2019 06:55:52 -0700 (PDT) Received: from p3plsmtpa07-08.prod.phx3.secureserver.net (p3plsmtpa07-08.prod.phx3.secureserver.net [173.201.192.237]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DDCD12013E for ; Wed, 15 May 2019 06:55:51 -0700 (PDT) Received: from [10.100.18.100] ([67.132.53.226]) by :SMTPAUTH: with ESMTPSA id QuNqhPOmScrCXQuNqhRjJM; Wed, 15 May 2019 06:55:51 -0700 User-Agent: Microsoft-MacOutlook/10.19.0.190512 Date: Wed, 15 May 2019 06:55:49 -0700 From: Peter Yee To: Joseph Salowey , "" Message-ID: <1205A475-F14A-4553-9AAA-4DE8DAE79D99@akayla.com> Thread-Topic: [TLS] WGLC for draft-ietf-tls-tls13-cert-with-extern-psk References: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3640748150_1929125452" X-CMAE-Envelope: MS4wfLImopJLukOi7D83cbk5jttEuxHQuD8KayHacP+4hZDc0dXextKKYJS7GPwQpLw32R4xVKMoZEMrx3ZhCO3a6YuTIt6di8kcZE29KVAFLmosK2OmUZCp OmUuUbxWiCApUMInjLGF4W76UWYINr+wgkBXKl7UjqJF/PHJH2tPsxeKPYiQchoaMczv3AcW9LsQAw== Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-tls13-cert-with-extern-psk X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 15 May 2019 13:55:57 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3640748150_1929125452 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Joe, =20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I reviewed the draft and sent comments direc= tly to Russ in the form of a marked up Word document (which is why I didn=E2=80=99= t previously post my input to the list).=C2=A0 I=E2=80=99ve no problems with the docum= ent advancing based on Russ=E2=80=99 -01 update. =20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -Peter =20 On 5/15/19, 6:20 AM, "TLS on behalf of Joseph Salowey" wrote: =20 The last call has come and gone without any comment. Please indicate if yo= u have reviewed the draft even if you do not have issues to raise so the cha= irs can see who has reviewed it. Also indicate if you have any plans to imp= lement the draft.=20 =20 On Tue, Apr 9, 2019 at 8:51 PM Joseph Salowey wrote: This is the working group last call for the "TLS 1.3 Extension for Certific= ate-based Authentication with an External Pre-Shared Key=E2=80=9D draft available = at https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-ps= k/. Please review the document and send your comments to the list by 2359 UT= C on 23 April 2019. =20 Thanks, Chris, Joe, and Sean _______________________________________________ TLS mailing list TLS@ietf.o= rg https://www.ietf.org/mailman/listinfo/tls=20 --B_3640748150_1929125452 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Joe,

 <= /o:p>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I reviewed the dr= aft and sent comments directly to Russ in the form of a marked up Word docum= ent (which is why I didn=E2=80=99t previously post my input to the list).=C2=A0 I=E2=80=99ve= no problems with the document advancing based on Russ=E2=80=99 -01 update.

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -Peter

<= p class=3DMsoNormal> 

On 5/15/= 19, 6:20 AM, "TLS on behalf of Joseph Salowey" <tls-bounces@ietf.org on behalf of joe@salowey.net> wrote:

<= div>

 

Th= e last call has come and gone without any comment.  Please indicate if = you have reviewed the draft even if you do not have issues to raise so the c= hairs can see who has reviewed it.  Also indicate if you have any plans= to implement the draft. 

&= nbsp;

On Tue, Apr 9, 2019 at 8:51 PM J= oseph Salowey <joe@salowey.net> w= rote:

<= div>

This is = the working group last call for the "TLS 1.3 Extension for Certificate-= based Authentication with an External Pre-Shared Key=E2=80=9D draft available at&n= bsp;https://datatracker.ietf.org/doc/draft-ietf-tl= s-tls13-cert-with-extern-psk/. Please review the document and send your = comments to the list by 2359 UTC on 23 April 2019.

 

Thanks,
Chris, Joe, and Sean

_________= ______________________________________ TLS mailing list TLS@ietf.org https:/= /www.ietf.org/mailman/listinfo/tls

--B_3640748150_1929125452-- From nobody Wed May 15 08:31:13 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3792F120141 for ; Wed, 15 May 2019 08:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtMlpfjCZbb8 for ; Wed, 15 May 2019 08:31:09 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BAA3120117 for ; Wed, 15 May 2019 08:31:09 -0700 (PDT) Received: from [10.47.60.43] ([50.226.42.131]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id x4FFTA3l068683 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 15 May 2019 08:29:11 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host [50.226.42.131] claimed to be [10.47.60.43] From: "Paul Hoffman" To: "Joseph Salowey" Cc: tls@ietf.org Date: Wed, 15 May 2019 11:31:05 -0400 X-Mailer: MailMate (1.12.4r5594) Message-ID: <0A444AFA-33D4-417A-AF90-DF0E94C6E2BC@vpnc.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-tls13-cert-with-extern-psk X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 15 May 2019 15:31:11 -0000 On 15 May 2019, at 9:20, Joseph Salowey wrote: > The last call has come and gone without any comment. Please indicate > if > you have reviewed the draft even if you do not have issues to raise so > the > chairs can see who has reviewed it. Also indicate if you have any > plans to > implement the draft. I have read the draft and it seems fine. It follows the same methodology used in draft-ietf-ipsecme-qr-ikev2, which was heavily reviewed in the IPsecME Working Group. I cannot speak to whether this draft uses the right incantations for a TLS extension, but the rationale and design are straightforward. Assuming that someone who understands TLS extensions is comfortable with Sections 4 and 5, it should be moved to IETF Last Call. --Paul Hoffman From nobody Fri May 17 14:06:49 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BFF1120169 for ; Fri, 17 May 2019 14:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i35Jy6SGk5zi for ; Fri, 17 May 2019 14:06:47 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CAA312011C for ; Fri, 17 May 2019 14:06:47 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 3EB7EB81D0A; Fri, 17 May 2019 14:06:31 -0700 (PDT) To: tim@dierks.org, ekr@rtfm.com, rdd@cert.org, kaduk@mit.edu, caw@heapingbits.net, joe@salowey.net, sean+ietf@sn3rd.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: wafi930428@gmail.com, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20190517210631.3EB7EB81D0A@rfc-editor.org> Date: Fri, 17 May 2019 14:06:31 -0700 (PDT) Archived-At: Subject: [TLS] [Technical Errata Reported] RFC5246 (5722) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 17 May 2019 21:06:48 -0000 The following errata report has been submitted for RFC5246, "The Transport Layer Security (TLS) Protocol Version 1.2". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5722 -------------------------------------- Type: Technical Reported by: wafi Section: RFC 2119 Original Text ------------- Corrected Text -------------- Notes ----- Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5246 (draft-ietf-tls-rfc4346-bis-10) -------------------------------------- Title : The Transport Layer Security (TLS) Protocol Version 1.2 Publication Date : August 2008 Author(s) : T. Dierks, E. Rescorla Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Fri May 17 14:31:10 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCB821200B1 for ; Fri, 17 May 2019 14:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XGrgm4uqxYNS for ; Fri, 17 May 2019 14:31:06 -0700 (PDT) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22CAF120073 for ; Fri, 17 May 2019 14:31:06 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id v18so6334901lfi.1 for ; Fri, 17 May 2019 14:31:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rLUo9Ww0rT8Shh2WnEziHfk/Qy7wNfymWG9u2DkXlSs=; b=gjAaJgsiRfdKFt760DABNtYqyoSKzO5QjdVSsW81saLNhMNFPwxw5PNUoaZU2WoFM4 fyCNM8vkZax+2mbDx6pzjU3urIUJ1nf5Aytnpg4aWy2VtCE4AvHZS7VaQEE6g0wPkFV9 7mm4qw4Ml1BWjH0z0Hpd5CVp+cdhcCxxY8gXZEJrqdwdjwPzNhBKrBh0cM+Aa8P8z9mn eww9bQvkMn3D0jqaLBbcZ8cFqVLOETt3uFtCuf7763dGoYZBatlKg2aKUk/fFGuxMemw IzmnmA056gzemg653iHFOnlkhGOsLELjiQX1R3hWkmBYZCVHRCmK6ZUzpp5uk6XFUXBz rIWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rLUo9Ww0rT8Shh2WnEziHfk/Qy7wNfymWG9u2DkXlSs=; b=GFkmmYWt/ZppT9HfGCS28Co6KLWZFdbAf6kRUqeRFHt4Z5TmKC+PTQSeuG/yVQ0YW2 cqpc4K/fTu7rNDutqj3BV2P8P+faQ9GYlPI+sGDjRRDcrX/GuANv/xqOYgWKkiA4hcgl +W0x8nAvR8E+p3zYhK9y6pDvDM/V7ZtBKDiF8HI9PnKKc0LMDcwcRH+5piofwXj75Im2 BHTnJFQILI9i/bugJuBP7yxUU58lm5+8JIVAySM7QOCEpRvnGOgiV/aLz9y5TX6lguIG lodSAD4d30Vjl1WMJrY1vedBiB3P3V/lt/eqxO6Z0M6gzHl/DI5HPJkGq8vTLpQL27zX x5EQ== X-Gm-Message-State: APjAAAX4CqccwBmg8o5Zs+ux3z7GbPOaEPVtEKRZom/8j+1gWOKG41jp 8xzBsuXXtPswMgZYfriWtCM4rzvYNu5KvQSd8VDCnw== X-Google-Smtp-Source: APXvYqzQCFF+rHarIid0bggv60xO60K1sgerBngmuGEyDMR/h1g38plqMajp2C/bOC5cGRPK8Qej0ZgXOpSZEew+QWg= X-Received: by 2002:ac2:483c:: with SMTP id 28mr10084256lft.93.1558128664284; Fri, 17 May 2019 14:31:04 -0700 (PDT) MIME-Version: 1.0 References: <20190517210631.3EB7EB81D0A@rfc-editor.org> In-Reply-To: <20190517210631.3EB7EB81D0A@rfc-editor.org> From: Eric Rescorla Date: Fri, 17 May 2019 14:30:27 -0700 Message-ID: To: RFC Errata System Cc: Tim Dierks , Roman Danyliw , Benjamin Kaduk , Christopher Wood , Joseph Salowey , sean+ietf@sn3rd.com, wafi930428@gmail.com, "" Content-Type: multipart/alternative; boundary="0000000000008c9ff705891c1940" Archived-At: Subject: Re: [TLS] [Technical Errata Reported] RFC5246 (5722) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 17 May 2019 21:31:09 -0000 --0000000000008c9ff705891c1940 Content-Type: text/plain; charset="UTF-8" Unless I am confused, this has no content, so I think probably we should reject it. On Fri, May 17, 2019 at 2:06 PM RFC Errata System wrote: > The following errata report has been submitted for RFC5246, > "The Transport Layer Security (TLS) Protocol Version 1.2". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5722 > > -------------------------------------- > Type: Technical > Reported by: wafi > > Section: RFC 2119 > > Original Text > ------------- > > > Corrected Text > -------------- > > > Notes > ----- > > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC5246 (draft-ietf-tls-rfc4346-bis-10) > -------------------------------------- > Title : The Transport Layer Security (TLS) Protocol Version > 1.2 > Publication Date : August 2008 > Author(s) : T. Dierks, E. Rescorla > Category : PROPOSED STANDARD > Source : Transport Layer Security > Area : Security > Stream : IETF > Verifying Party : IESG > --0000000000008c9ff705891c1940 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Unless I am confused, this has no content, so I think prob= ably we should reject it.

On Fri, May 17, 2019 at 2:06 PM RFC Errata Sy= stem <rfc-editor@rfc-editor= .org> wrote:
The following errata report has been submitted for RFC5246,
"The Transport Layer Security (TLS) Protocol Version 1.2".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5722

--------------------------------------
Type: Technical
Reported by: wafi <wafi930428@gmail.com>

Section: RFC 2119

Original Text
-------------


Corrected Text
--------------


Notes
-----


Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, ple= ase
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party=C2=A0
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC5246 (draft-ietf-tls-rfc4346-bis-10)
--------------------------------------
Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: The Transport= Layer Security (TLS) Protocol Version 1.2
Publication Date=C2=A0 =C2=A0 : August 2008
Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: T. Dierks, E. Rescorla<= br> Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD
Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Transport Layer Se= curity
Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Security
Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
--0000000000008c9ff705891c1940-- From nobody Sun May 19 01:07:28 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60ABB12007A for ; Sun, 19 May 2019 01:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=vzOTObHW; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=egV5+SaY Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N7umCFhRUHDr for ; Sun, 19 May 2019 01:07:25 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E499F120072 for ; Sun, 19 May 2019 01:07:24 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 20B2C3A4 for ; Sun, 19 May 2019 04:07:23 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Sun, 19 May 2019 04:07:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=NXd0idr32OLTAVlOECcxiS9n7aF9LDf +E7DwOaYuMZY=; b=vzOTObHWMbGX7B7mrFL3dmyaLDntIrVRadfANgOQUmsUIYp 2JjNIOwoeVN58eDw5+qxRvzRwIPtiroCkRUTOldum4VPDZMv///UGYc2y51bFoEw CwzduGZsLcVDOcW0pwwIABxRMxAuF63D/Vpcllcf+rTtOTp4JnOjnYAu4SC54o32 Ekwz4pxbQ1xT96EMY9miziLzYeGUKNf2zdElrq53PKCLzlUz8QSCRqYhnNdaijbo MOdRVy4/indWs5TsXy/fVe0DyAocC47mjTsR35jyD5vlu/Vs+mT99L1m47Xau/+4 oNV4GKbVbn3wmBiBpwDNy03D4hddoCHZu4/aUdw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=NXd0id r32OLTAVlOECcxiS9n7aF9LDf+E7DwOaYuMZY=; b=egV5+SaYn7cIkfAXIQV2pL 8RfbbwXyy2BZU+7vBnqbuM7dTWoV4MmGzvIF0XV3KdmVcLVQQC8ijt4xKWGnVT4P Rr3j5CQt8R9WtQWAT0Zl+QuwlHR+J6vUEEuA7oqBGkIwFa4ZZUwml8uxXtfx0pa8 PQpFHK2+1Wk/LF+maL7VIKWwFSUS3ZWRU4FYNv/o/9r3YzPbgQFuPpanFmsj6BBU 0JPYjn3kYafK/D4BuuwAiQRCtq55ZvSrbAXseULQ7Zmw7iSP7030ZE8lq3MHyPp1 t8AgtCJDFDmbjtPyu8n7NAbFtP4wiMDsDkytOxSfcP1QRs/QL3010LC4Wk+FPtOQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddruddtiedgtdduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucffohhmrghinheprhhftgdqvgguihhtohhrrdhorh hgpdhivghtfhdrohhrghenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghn thhrohhphidrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 536577C3E9; Sun, 19 May 2019 04:07:22 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-549-ge400f56-fmstable-20190516v3 Mime-Version: 1.0 Message-Id: <2541c646-861a-4478-b789-a0b9770fbaf8@www.fastmail.com> In-Reply-To: References: <20190517210631.3EB7EB81D0A@rfc-editor.org> Date: Sun, 19 May 2019 08:07:22 +0000 From: "Martin Thomson" To: tls@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [TLS] [Technical Errata Reported] RFC5246 (5722) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 19 May 2019 08:07:27 -0000 Unless it is a very subtle hint that the RFC should cite RFC 8174, that is. On Fri, May 17, 2019, at 21:31, Eric Rescorla wrote: > Unless I am confused, this has no content, so I think probably we > should reject it. > > On Fri, May 17, 2019 at 2:06 PM RFC Errata System > > wrote: > > The following errata report has been submitted for RFC5246, > > "The Transport Layer Security (TLS) Protocol Version 1.2". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata/eid5722 > > > > -------------------------------------- > > Type: Technical > > Reported by: wafi > > > > Section: RFC 2119 > > > > Original Text > > ------------- > > > > > > Corrected Text > > -------------- > > > > > > Notes > > ----- > > > > > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC5246 (draft-ietf-tls-rfc4346-bis-10) > > -------------------------------------- > > Title : The Transport Layer Security (TLS) Protocol Version 1.2 > > Publication Date : August 2008 > > Author(s) : T. Dierks, E. Rescorla > > Category : PROPOSED STANDARD > > Source : Transport Layer Security > > Area : Security > > Stream : IETF > > Verifying Party : IESG > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Mon May 20 02:28:54 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8CC1200D7 for ; Mon, 20 May 2019 02:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ezhfharRBpt for ; Mon, 20 May 2019 02:28:51 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8217D120020 for ; Mon, 20 May 2019 02:28:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1558344531; x=1589880531; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=6CkhPcYzXe6UQu+GD6ME3Q8RTPT+ZRi5jfxhhpSnbvY=; b=sqVet6XqBKy+9cbqG0+WyG2uT2e3g0SxBFCy4m8RxVrndbP0WMncCv2i nJqLROHfE6/MohoVJ0QXQntAY9YiUEbOmZfqMJZ5rUaLytaH5OwUwNSbK G/4q5gC9DnRcQnMNzoXvH2gGmNIwHj6siZ3iZTHGE04FP3/VQFAJ90Wzo AB5AxndXPDi08paBRTwmQ2brQiBmSR/dRyuYcdC8iYdsECCEntwvH8Tu3 +iVxintR9WloKne59scbQcTRF+uVqAS5ble6ItI1HQy04jEc1oTCx40c5 6xDeLRodQcwp/VlrE2pmVqpPZ2R3KsghDHOIQSqxrrELIzAngnEVuPF3U w==; X-IronPort-AV: E=Sophos;i="5.60,491,1549882800"; d="scan'208";a="63245785" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.4 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-c.UoA.auckland.ac.nz) ([10.6.3.4]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 20 May 2019 21:28:47 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-c.UoA.auckland.ac.nz (10.6.3.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 20 May 2019 21:28:46 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Mon, 20 May 2019 21:28:45 +1200 From: Peter Gutmann To: Hubert Kario , "mrex@sap.com" CC: "tls@ietf.org" Thread-Topic: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" Thread-Index: AQHU+8+QtjVLqWiyz0WqN1BpourjtKZM43YAgADkD4CAAGW4gIADRbgAgAMrEACAA/7YAIAAIz4AgAR6F4CAANPyAIAAvI2AgADfaICAAidXgIAA2c2AgAWSfACAAcrjgIAAN4AAgAAtHwCACXd8UA== Date: Mon, 20 May 2019 09:28:44 +0000 Message-ID: <1558344512756.70167@cs.auckland.ac.nz> References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <29960808.K0e8lGuAtk@pintsize.usersys.redhat.com> <20190514145249.C6DDB404C@ld9781.wdf.sap.corp> <12276928.OsXPxM6NY9@pintsize.usersys.redhat.com>, <20190514205258.5C457404C@ld9781.wdf.sap.corp> In-Reply-To: <20190514205258.5C457404C@ld9781.wdf.sap.corp> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 09:28:53 -0000 Martin Rex writes:=0A= =0A= >BEAST is an attack against Web Browsers (and the abuse known as SSL-VPNs),= it=0A= >is *NO* attack against TLS =0A= =0A= That actually applies to an awful lot of recent attacks on TLS - they're=0A= attacks that rely on web software that's actively cooperating with the=0A= attacker, not attacks on TLS per se. Similar issues affect numerous attack= s=0A= on CMS (branded as S/MIME in email) and OpenPGP, they require mail software= =0A= that actively cooperates with the attacker.=0A= =0A= For any new attack on a protocol like TLS, you really need a three-stage=0A= summary of what's vulnerable:=0A= =0A= 1. Web-based use of TLS: Pretty much everything.=0A= 2. Non-web-based use of TLS: Very little.=0A= 3. Non-web-based with a few basic mitigations (EMS, EtM): Nothing, or close= to it.=0A= =0A= Peter.=0A= From nobody Mon May 20 09:16:17 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAE0312017A for ; Mon, 20 May 2019 09:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJZomk3GBpP2 for ; Mon, 20 May 2019 09:16:11 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86A5A1201D0 for ; Mon, 20 May 2019 09:16:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id E919A1C3DA9; Mon, 20 May 2019 09:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gaV94LLtxIC4; Mon, 20 May 2019 09:15:47 -0700 (PDT) Received: from [172.31.98.5] (unknown [68.252.211.155]) by c8a.amsl.com (Postfix) with ESMTPA id A294B1C3D05; Mon, 20 May 2019 09:15:47 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Megan Ferguson In-Reply-To: <20190517210631.3EB7EB81D0A@rfc-editor.org> Date: Mon, 20 May 2019 09:16:10 -0700 Cc: Tim Dierks , Eric Rescorla , rdd@cert.org, kaduk@mit.edu, caw@heapingbits.net, Joseph Salowey , sean+ietf@sn3rd.com, "" Content-Transfer-Encoding: quoted-printable Message-Id: <7C12A147-A0EF-427C-A20E-B10C4BAED1D5@amsl.com> References: <20190517210631.3EB7EB81D0A@rfc-editor.org> To: RFC System X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [TLS] [Technical Errata Reported] RFC5246 (5722) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 16:16:13 -0000 Greetings, FYI - This report has been deleted as junk. Thank you. RFC Editor/mf On May 17, 2019, at 2:06 PM, RFC Errata System = wrote: > The following errata report has been submitted for RFC5246, > "The Transport Layer Security (TLS) Protocol Version 1.2". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5722 >=20 > -------------------------------------- > Type: Technical > Reported by: wafi >=20 > Section: RFC 2119 >=20 > Original Text > ------------- >=20 >=20 > Corrected Text > -------------- >=20 >=20 > Notes > ----- >=20 >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC5246 (draft-ietf-tls-rfc4346-bis-10) > -------------------------------------- > Title : The Transport Layer Security (TLS) Protocol = Version 1.2 > Publication Date : August 2008 > Author(s) : T. Dierks, E. Rescorla > Category : PROPOSED STANDARD > Source : Transport Layer Security > Area : Security > Stream : IETF > Verifying Party : IESG >=20 From nobody Mon May 20 12:20:32 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D061B1200FB for ; Mon, 20 May 2019 12:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwLAyj4uvb1r for ; Mon, 20 May 2019 12:20:21 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 209571200F3 for ; Mon, 20 May 2019 12:20:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 708ED300AE4 for ; Mon, 20 May 2019 15:01:02 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 5Aqw3VJabq2O for ; Mon, 20 May 2019 15:01:00 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id D0576300474; Mon, 20 May 2019 15:00:59 -0400 (EDT) From: Russ Housley Message-Id: <623BD5EA-1D76-494C-B87D-55FD1156EBD6@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_2EF8A70F-3F7E-455F-AA20-2513440F5261" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Mon, 20 May 2019 15:20:16 -0400 In-Reply-To: Cc: IETF TLS To: Joe Salowey References: X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-tls13-cert-with-extern-psk X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 19:20:26 -0000 --Apple-Mail=_2EF8A70F-3F7E-455F-AA20-2513440F5261 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 TLS 1.3 Extension for Certificate-based Authentication with an External = PSK ensures the US Government has a quantum-resistant option for TLS in = the interim years until post-quantum algorithms emerge from the NIST = process. For this reason, there is an intent to specify this extension = in future procurements. Russ > On May 15, 2019, at 9:20 AM, Joseph Salowey wrote: >=20 > The last call has come and gone without any comment. Please indicate = if you have reviewed the draft even if you do not have issues to raise = so the chairs can see who has reviewed it. Also indicate if you have = any plans to implement the draft.=20 >=20 > On Tue, Apr 9, 2019 at 8:51 PM Joseph Salowey > wrote: > This is the working group last call for the "TLS 1.3 Extension for = Certificate-based Authentication with an External Pre-Shared Key=E2=80=9D = draft available at = https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk= / = . Please review the document and send your comments to the list by = 2359 UTC on 23 April 2019. >=20 > Thanks, > Chris, Joe, and Sean --Apple-Mail=_2EF8A70F-3F7E-455F-AA20-2513440F5261 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
TLS 1.3 Extension for Certificate-based Authentication with = an External PSK ensures the US Government has a quantum-resistant option = for TLS in the interim years until post-quantum algorithms emerge from = the NIST process. For this reason, there is an intent to specify this = extension in future procurements.

Russ


On May 15, 2019, at 9:20 AM, Joseph Salowey = <joe@salowey.net> = wrote:

The last call has come and gone without any = comment.  Please indicate if you have reviewed the draft even if = you do not have issues to raise so the chairs can see who has reviewed = it.  Also indicate if you have any plans to implement the = draft. 

On Tue, Apr 9, 2019 at 8:51 PM Joseph = Salowey <joe@salowey.net> wrote:
This is the working = group last call for the "TLS 1.3 Extension for Certificate-based = Authentication with an External Pre-Shared Key=E2=80=9D draft available = at https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with= -extern-psk/. Please review the document and send your comments to = the list by 2359 UTC on 23 April 2019.

Thanks,
Chris, Joe, and = Sean

= --Apple-Mail=_2EF8A70F-3F7E-455F-AA20-2513440F5261-- From nobody Mon May 20 12:41:32 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64EA612010E for ; Mon, 20 May 2019 12:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bR4Q8MqLfwET for ; Mon, 20 May 2019 12:41:29 -0700 (PDT) Received: from llmx3.ll.mit.edu (LLMX3.LL.MIT.EDU [129.55.12.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27D91120048 for ; Mon, 20 May 2019 12:41:28 -0700 (PDT) Received: from LLE2K16-MBX02.mitll.ad.local (LLE2K16-MBX02.mitll.ad.local) by llmx3.ll.mit.edu (unknown) with ESMTPS id x4KJfQ3O040869 for ; Mon, 20 May 2019 15:41:26 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: IETF TLS Thread-Topic: [TLS] WGLC for draft-ietf-tls-tls13-cert-with-extern-psk Thread-Index: AQHU71Dl4FuLhOFUaEet5GHjTbcLfaZspnEAgAhAFwD//8LZAA== Date: Mon, 20 May 2019 19:41:24 +0000 Message-ID: <71EB9B8A-C410-4A35-A0FE-3E2BE89E7C65@ll.mit.edu> References: <623BD5EA-1D76-494C-B87D-55FD1156EBD6@vigilsec.com> In-Reply-To: <623BD5EA-1D76-494C-B87D-55FD1156EBD6@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.18.0.190414 x-originating-ip: [172.25.1.84] Content-Type: multipart/alternative; boundary="_000_71EB9B8AC4104A35A0FE3E2BE89E7C65llmitedu_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-20_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905200122 Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-tls13-cert-with-extern-psk X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 19:41:31 -0000 --_000_71EB9B8AC4104A35A0FE3E2BE89E7C65llmitedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSByZXZpZXdlZCB0aGlzIGRyYWZ0ICjigJxicm93c2VkIHRocm91Z2jigJ0gd291bGQgYmUgYSBt b3JlIGhvbmVzdCBzdGF0ZW1lbnQpLiBJIGRpZG7igJl0IHNwb3QgYW4gb2J2aW91cyBwcm9ibGVt IHdpdGggaXQuDQoNCk9uZSBxdWVzdGlvbiB0aGF0IEkgaGF2ZSBhZnRlciByZWFkaW5nIGl0OiBJ IHVuZGVyc3RhbmQgd2h5IG9uZSB3YW50cyB0byBpbXBsZW1lbnQgdGhpcyBleHRlbnNpb24sIGJ1 dCBJIGRvbuKAmXQgc2VlIGhvdyB0aGUgdHdvIGVuZHBvaW50cyB3b3VsZCBhcnJpdmUgYXQgdGhh dCBleHRlcm5hbCBQU0suDQoNCkZyb206IFRMUyA8dGxzLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJl aGFsZiBvZiBSdXNzIEhvdXNsZXkgPGhvdXNsZXlAdmlnaWxzZWMuY29tPg0KRGF0ZTogTW9uZGF5 LCBNYXkgMjAsIDIwMTkgYXQgMzoyMSBQTQ0KVG86IEpvZSBTYWxvd2V5IDxqb2VAc2Fsb3dleS5u ZXQ+DQpDYzogSUVURiBUTFMgPHRsc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbVExTXSBXR0xD IGZvciBkcmFmdC1pZXRmLXRscy10bHMxMy1jZXJ0LXdpdGgtZXh0ZXJuLXBzaw0KDQpUTFMgMS4z IEV4dGVuc2lvbiBmb3IgQ2VydGlmaWNhdGUtYmFzZWQgQXV0aGVudGljYXRpb24gd2l0aCBhbiBF eHRlcm5hbCBQU0sgZW5zdXJlcyB0aGUgVVMgR292ZXJubWVudCBoYXMgYSBxdWFudHVtLXJlc2lz dGFudCBvcHRpb24gZm9yIFRMUyBpbiB0aGUgaW50ZXJpbSB5ZWFycyB1bnRpbCBwb3N0LXF1YW50 dW0gYWxnb3JpdGhtcyBlbWVyZ2UgZnJvbSB0aGUgTklTVCBwcm9jZXNzLiBGb3IgdGhpcyByZWFz b24sIHRoZXJlIGlzIGFuIGludGVudCB0byBzcGVjaWZ5IHRoaXMgZXh0ZW5zaW9uIGluIGZ1dHVy ZSBwcm9jdXJlbWVudHMuDQoNClJ1c3MNCg0KDQoNCk9uIE1heSAxNSwgMjAxOSwgYXQgOToyMCBB TSwgSm9zZXBoIFNhbG93ZXkgPGpvZUBzYWxvd2V5Lm5ldDxtYWlsdG86am9lQHNhbG93ZXkubmV0 Pj4gd3JvdGU6DQoNClRoZSBsYXN0IGNhbGwgaGFzIGNvbWUgYW5kIGdvbmUgd2l0aG91dCBhbnkg Y29tbWVudC4gIFBsZWFzZSBpbmRpY2F0ZSBpZiB5b3UgaGF2ZSByZXZpZXdlZCB0aGUgZHJhZnQg ZXZlbiBpZiB5b3UgZG8gbm90IGhhdmUgaXNzdWVzIHRvIHJhaXNlIHNvIHRoZSBjaGFpcnMgY2Fu IHNlZSB3aG8gaGFzIHJldmlld2VkIGl0LiAgQWxzbyBpbmRpY2F0ZSBpZiB5b3UgaGF2ZSBhbnkg cGxhbnMgdG8gaW1wbGVtZW50IHRoZSBkcmFmdC4NCg0KT24gVHVlLCBBcHIgOSwgMjAxOSBhdCA4 OjUxIFBNIEpvc2VwaCBTYWxvd2V5IDxqb2VAc2Fsb3dleS5uZXQ8bWFpbHRvOmpvZUBzYWxvd2V5 Lm5ldD4+IHdyb3RlOg0KVGhpcyBpcyB0aGUgd29ya2luZyBncm91cCBsYXN0IGNhbGwgZm9yIHRo ZSAiVExTIDEuMyBFeHRlbnNpb24gZm9yIENlcnRpZmljYXRlLWJhc2VkIEF1dGhlbnRpY2F0aW9u IHdpdGggYW4gRXh0ZXJuYWwgUHJlLVNoYXJlZCBLZXnigJ0gZHJhZnQgYXZhaWxhYmxlIGF0IGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdGxzLXRsczEzLWNlcnQt d2l0aC1leHRlcm4tcHNrLy4gUGxlYXNlIHJldmlldyB0aGUgZG9jdW1lbnQgYW5kIHNlbmQgeW91 ciBjb21tZW50cyB0byB0aGUgbGlzdCBieSAyMzU5IFVUQyBvbiAyMyBBcHJpbCAyMDE5Lg0KDQpU aGFua3MsDQpDaHJpcywgSm9lLCBhbmQgU2Vhbg0KDQoNCg== --_000_71EB9B8AC4104A35A0FE3E2BE89E7C65llmitedu_ Content-Type: text/html; charset="utf-8" Content-ID: <9EC14EC72C77154F888BC05704683009@ll.mit.edu> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5JIHJldmlld2VkIHRoaXMg ZHJhZnQgKOKAnGJyb3dzZWQgdGhyb3VnaOKAnSB3b3VsZCBiZSBhIG1vcmUgaG9uZXN0IHN0YXRl bWVudCkuIEkgZGlkbuKAmXQgc3BvdCBhbiBvYnZpb3VzIHByb2JsZW0gd2l0aCBpdC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPk9uZSBxdWVzdGlvbiB0aGF0IEkg aGF2ZSBhZnRlciByZWFkaW5nIGl0OiBJIHVuZGVyc3RhbmQgd2h5IG9uZSB3YW50cyB0byBpbXBs ZW1lbnQgdGhpcyBleHRlbnNpb24sIGJ1dCBJIGRvbuKAmXQgc2VlIGhvdyB0aGUgdHdvIGVuZHBv aW50cyB3b3VsZCBhcnJpdmUgYXQgdGhhdCBleHRlcm5hbCBQU0suDQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+VExTICZsdDt0bHMtYm91 bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIFJ1c3MgSG91c2xleSAmbHQ7aG91c2xleUB2 aWdpbHNlYy5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPk1vbmRheSwgTWF5IDIwLCAyMDE5IGF0 IDM6MjEgUE08YnI+DQo8Yj5UbzogPC9iPkpvZSBTYWxvd2V5ICZsdDtqb2VAc2Fsb3dleS5uZXQm Z3Q7PGJyPg0KPGI+Q2M6IDwvYj5JRVRGIFRMUyAmbHQ7dGxzQGlldGYub3JnJmd0Ozxicj4NCjxi PlN1YmplY3Q6IDwvYj5SZTogW1RMU10gV0dMQyBmb3IgZHJhZnQtaWV0Zi10bHMtdGxzMTMtY2Vy dC13aXRoLWV4dGVybi1wc2s8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+VExTIDEuMyBFeHRlbnNpb24gZm9yIENlcnRpZmljYXRlLWJhc2VkIEF1 dGhlbnRpY2F0aW9uIHdpdGggYW4gRXh0ZXJuYWwgUFNLIGVuc3VyZXMgdGhlIFVTIEdvdmVybm1l bnQgaGFzIGEgcXVhbnR1bS1yZXNpc3RhbnQgb3B0aW9uIGZvciBUTFMgaW4gdGhlIGludGVyaW0g eWVhcnMgdW50aWwgcG9zdC1xdWFudHVtIGFsZ29yaXRobXMgZW1lcmdlIGZyb20gdGhlIE5JU1QN CiBwcm9jZXNzLiBGb3IgdGhpcyByZWFzb24sIHRoZXJlIGlzIGFuIGludGVudCB0byBzcGVjaWZ5 IHRoaXMgZXh0ZW5zaW9uIGluIGZ1dHVyZSBwcm9jdXJlbWVudHMuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+UnVzczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPk9uIE1h eSAxNSwgMjAxOSwgYXQgOToyMCBBTSwgSm9zZXBoIFNhbG93ZXkgJmx0OzxhIGhyZWY9Im1haWx0 bzpqb2VAc2Fsb3dleS5uZXQiPmpvZUBzYWxvd2V5Lm5ldDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5UaGUgbGFzdCBjYWxsIGhhcyBjb21lIGFu ZCBnb25lIHdpdGhvdXQgYW55IGNvbW1lbnQuJm5ic3A7IFBsZWFzZSBpbmRpY2F0ZSBpZiB5b3Ug aGF2ZSByZXZpZXdlZCB0aGUgZHJhZnQgZXZlbiBpZiB5b3UgZG8gbm90IGhhdmUgaXNzdWVzIHRv IHJhaXNlIHNvIHRoZSBjaGFpcnMgY2FuIHNlZSB3aG8gaGFzIHJldmlld2VkIGl0LiZuYnNwOyBB bHNvIGluZGljYXRlIGlmIHlvdSBoYXZlDQogYW55IHBsYW5zIHRvIGltcGxlbWVudCB0aGUgZHJh ZnQuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPk9uIFR1ZSwg QXByIDksIDIwMTkgYXQgODo1MSBQTSBKb3NlcGggU2Fsb3dleSAmbHQ7PGEgaHJlZj0ibWFpbHRv OmpvZUBzYWxvd2V5Lm5ldCI+am9lQHNhbG93ZXkubmV0PC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmIj5UaGlzIGlzIHRoZSB3b3JraW5nIGdyb3VwIGxhc3QgY2Fs bCBmb3IgdGhlICZxdW90O1RMUyAxLjMgRXh0ZW5zaW9uIGZvciBDZXJ0aWZpY2F0ZS1iYXNlZCBB dXRoZW50aWNhdGlvbiB3aXRoIGFuIEV4dGVybmFsIFByZS1TaGFyZWQgS2V54oCdIGRyYWZ0IGF2 YWlsYWJsZSBhdCZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWlldGYtdGxzLXRsczEzLWNlcnQtd2l0aC1leHRlcm4tcHNrLyIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdGxzLXRsczEz LWNlcnQtd2l0aC1leHRlcm4tcHNrLzwvYT4uDQogUGxlYXNlIHJldmlldyB0aGUgZG9jdW1lbnQg YW5kIHNlbmQgeW91ciBjb21tZW50cyB0byB0aGUgbGlzdCBieSAyMzU5IFVUQyBvbiAyMyBBcHJp bCAyMDE5Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5r cyw8YnI+DQpDaHJpcywgSm9lLCBhbmQgU2Vhbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGJy Pg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_71EB9B8AC4104A35A0FE3E2BE89E7C65llmitedu_-- From nobody Mon May 20 13:58:06 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92AC8120026 for ; Mon, 20 May 2019 13:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id htcaeWsDyCU0 for ; Mon, 20 May 2019 13:58:01 -0700 (PDT) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A070120072 for ; Mon, 20 May 2019 13:58:01 -0700 (PDT) Received: by mail-qt1-x82d.google.com with SMTP id k24so17990518qtq.7 for ; Mon, 20 May 2019 13:58:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=DlF+K+KyODEKlxrKbyiHzZ2b1NlGyGUg07C4GdnmY6Q=; b=IJPKjCPbvv6M/1hufxVb5EUB2y9j2BnqMVggexfeYR8Lo7HQSD5qOKneS8Omz6cv7/ B5DErPWMVdViSRGmg0NBNXT1e5WWDUGXQm48qpUserjaVjdTjSdSq910nz4YzZ2J1VuO gAAR1zPlBYEJ20H+NuctwrmroBzdtejbi1GMw1hsawAxe0837QhMciIc7Drvj6J15obi xOWFK2snDEVTQnXVPYLH0mzDKHWuXiFAQGHqNUvsjLuQBW75LGnnUAagm+LbPCISGMhh mFm5huY0kD9efkpTu5iv7Ux6CYt9KStc8aQD+zndHg0e0B5alzzcZyUawm8gensMb8aX RK2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=DlF+K+KyODEKlxrKbyiHzZ2b1NlGyGUg07C4GdnmY6Q=; b=qLgoM9cqgzfIAf13PgBwpqj4ZMZf65Rw2MOs5GSDfW7LmNoX6M4qyq9kjhH5zV0C4g 8LHY1JWDAEhsZWz57AFjCc7WZxKRcoZC/dtn6gkwZVci3RlbOqkX7Qs4nXJ4jxuIT9M9 qMWjuHpMnKviXMMQeh/v41+BLJjazZ0m5TNdAsUtTdNJ9Rtr1waaHuJLokZzde5xhNek 05n1NE0Eku0i8CRg3VTP6m9UQnQLCqfNZDXknbqLhGF955YSDGmbCdDbymtd3tHdsvOj URqEtEIlEcSVFzNLN3QG99uzH1EgpTrrILSrP4N7FJpGgwRBsH9GyG9e10jcqJpCH/2q O87g== X-Gm-Message-State: APjAAAXQNd2FIb9SyQLpcGre3dtRz3oDuu8HCzva1VZ0MsWLtcXL5DiH HdKI/Tm6QSdMDgfJ6ZEW2KqwwF08ia0= X-Google-Smtp-Source: APXvYqy5Ww0ORmVj1Ccu06Gc8APBVU+3O67vXwD9YYO4sv1bkYp/sNRk2qp5KK7Qdk6YClLt4sr94Q== X-Received: by 2002:a0c:9ac8:: with SMTP id k8mr61733998qvf.132.1558385880200; Mon, 20 May 2019 13:58:00 -0700 (PDT) Received: from ?IPv6:2601:152:4400:437c:5d1b:33bc:c6d:abc3? ([2601:152:4400:437c:5d1b:33bc:c6d:abc3]) by smtp.gmail.com with ESMTPSA id n190sm8480616qkb.83.2019.05.20.13.57.59 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 May 2019 13:57:59 -0700 (PDT) To: tls@ietf.org References: <623BD5EA-1D76-494C-B87D-55FD1156EBD6@vigilsec.com> <71EB9B8A-C410-4A35-A0FE-3E2BE89E7C65@ll.mit.edu> From: Michael StJohns Message-ID: Date: Mon, 20 May 2019 16:57:56 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <71EB9B8A-C410-4A35-A0FE-3E2BE89E7C65@ll.mit.edu> Content-Type: multipart/alternative; boundary="------------3C815B7118BA21657640FFE4" Content-Language: en-US Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-tls13-cert-with-extern-psk X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 20:58:05 -0000 This is a multi-part message in MIME format. --------------3C815B7118BA21657640FFE4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 5/20/2019 3:41 PM, Blumenthal, Uri - 0553 - MITLL wrote: > > I reviewed this draft (“browsed through” would be a more honest > statement). I didn’t spot an obvious problem with it. > > One question that I have after reading it: I understand why one wants > to implement this extension, but I don’t see how the two endpoints > would arrive at that external PSK. > Sadly - we're back to the 1980's in terms of key management. The obvious answers are a) they meet to exchange keys, b) they're given a key through a KDC, c) they get them in the mail. (and I'm really not kidding about (c)) Mike > *From: *TLS on behalf of Russ Housley > > *Date: *Monday, May 20, 2019 at 3:21 PM > *To: *Joe Salowey > *Cc: *IETF TLS > *Subject: *Re: [TLS] WGLC for draft-ietf-tls-tls13-cert-with-extern-psk > > TLS 1.3 Extension for Certificate-based Authentication with an > External PSK ensures the US Government has a quantum-resistant option > for TLS in the interim years until post-quantum algorithms emerge from > the NIST process. For this reason, there is an intent to specify this > extension in future procurements. > > Russ > > > > On May 15, 2019, at 9:20 AM, Joseph Salowey > wrote: > > The last call has come and gone without any comment.  Please > indicate if you have reviewed the draft even if you do not have > issues to raise so the chairs can see who has reviewed it.  Also > indicate if you have any plans to implement the draft. > > On Tue, Apr 9, 2019 at 8:51 PM Joseph Salowey > wrote: > > This is the working group last call for the "TLS 1.3 Extension > for Certificate-based Authentication with an External > Pre-Shared Key” draft available at > https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk/. > Please review the document and send your comments to the list > by 2359 UTC on 23 April 2019. > > Thanks, > Chris, Joe, and Sean > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --------------3C815B7118BA21657640FFE4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 5/20/2019 3:41 PM, Blumenthal, Uri - 0553 - MITLL wrote:

I reviewed this draft (“browsed through” would be a more honest statement). I didn’t spot an obvious problem with it.

 

One question that I have after reading it: I understand why one wants to implement this extension, but I don’t see how the two endpoints would arrive at that external PSK.

Sadly - we're back to the 1980's in terms of key management.   The obvious answers are a) they meet to exchange keys, b) they're given a key through a KDC, c) they get them in the mail. (and I'm really not kidding about (c))

Mike


 

From: TLS <tls-bounces@ietf.org> on behalf of Russ Housley <housley@vigilsec.com>
Date: Monday, May 20, 2019 at 3:21 PM
To: Joe Salowey <joe@salowey.net>
Cc: IETF TLS <tls@ietf.org>
Subject: Re: [TLS] WGLC for draft-ietf-tls-tls13-cert-with-extern-psk

 

TLS 1.3 Extension for Certificate-based Authentication with an External PSK ensures the US Government has a quantum-resistant option for TLS in the interim years until post-quantum algorithms emerge from the NIST process. For this reason, there is an intent to specify this extension in future procurements.

 

Russ

 



On May 15, 2019, at 9:20 AM, Joseph Salowey <joe@salowey.net> wrote:

 

The last call has come and gone without any comment.  Please indicate if you have reviewed the draft even if you do not have issues to raise so the chairs can see who has reviewed it.  Also indicate if you have any plans to implement the draft. 

 

On Tue, Apr 9, 2019 at 8:51 PM Joseph Salowey <joe@salowey.net> wrote:

This is the working group last call for the "TLS 1.3 Extension for Certificate-based Authentication with an External Pre-Shared Key” draft available at https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk/. Please review the document and send your comments to the list by 2359 UTC on 23 April 2019.

 

Thanks,
Chris, Joe, and Sean




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


--------------3C815B7118BA21657640FFE4-- From nobody Mon May 20 14:11:58 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03D3D120058 for ; Mon, 20 May 2019 14:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.196 X-Spam-Level: X-Spam-Status: No, score=-4.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjBKE0hGNUUZ for ; Mon, 20 May 2019 14:11:53 -0700 (PDT) Received: from llmx3.ll.mit.edu (LLMX3.LL.MIT.EDU [129.55.12.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61CCD12004E for ; Mon, 20 May 2019 14:11:52 -0700 (PDT) Received: from LLE2K16-MBX02.mitll.ad.local (LLE2K16-MBX02.mitll.ad.local) by llmx3.ll.mit.edu (unknown) with ESMTPS id x4KLBosS001175; Mon, 20 May 2019 17:11:51 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: Michael StJohns , "tls@ietf.org" Thread-Topic: [TLS] WGLC for draft-ietf-tls-tls13-cert-with-extern-psk Thread-Index: AQHU71Dl4FuLhOFUaEet5GHjTbcLfaZspnEAgAhAFwD//8LZAIAAWHEA///A0oA= Date: Mon, 20 May 2019 21:11:49 +0000 Message-ID: <18193F45-9A43-432C-AE7C-009B0F237598@ll.mit.edu> References: <623BD5EA-1D76-494C-B87D-55FD1156EBD6@vigilsec.com> <71EB9B8A-C410-4A35-A0FE-3E2BE89E7C65@ll.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.18.0.190414 x-originating-ip: [172.25.1.90] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3641217109_740760349" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-20_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905200132 Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-tls13-cert-with-extern-psk X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 21:11:57 -0000 --B_3641217109_740760349 Content-type: multipart/alternative; boundary="B_3641217109_1126335286" --B_3641217109_1126335286 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable One question that I have after reading it: I understand why one wants to im= plement this extension, but I don=E2=80=99t see how the two endpoints would arrive= at that external PSK.=20 Sadly - we're back to the 1980's in terms of key management. The obvious = answers are a) they meet to exchange keys, b) they're given a key through a = KDC, c) they get them in the mail. (and I'm really not kidding about (c)) I don=E2=80=99t think I get it. There=E2=80=99s a ton of submissions at NIST PQC, most = came with some formal proofs. I can=E2=80=99t believe none of them is good enough.= Anything from that pool should be better than nothing=E2=80=A6? Also, if you do have a running KDC, why would you want/need TLS 1.3 ECDHE i= n addition to it?=20 Would such a pre-shared key be long-term (i.e., good/used for many connecti= ons), or is it going to be a use-once thing? =20 =20 From: TLS on behalf of Russ Housley Date: Monday, May 20, 2019 at 3:21 PM To: Joe Salowey Cc: IETF TLS Subject: Re: [TLS] WGLC for draft-ietf-tls-tls13-cert-with-extern-psk =20 TLS 1.3 Extension for Certificate-based Authentication with an External PSK= ensures the US Government has a quantum-resistant option for TLS in the int= erim years until post-quantum algorithms emerge from the NIST process. For t= his reason, there is an intent to specify this extension in future procureme= nts. =20 Russ =20 On May 15, 2019, at 9:20 AM, Joseph Salowey wrote: =20 The last call has come and gone without any comment. Please indicate if yo= u have reviewed the draft even if you do not have issues to raise so the cha= irs can see who has reviewed it. Also indicate if you have any plans to imp= lement the draft.=20 =20 On Tue, Apr 9, 2019 at 8:51 PM Joseph Salowey wrote: This is the working group last call for the "TLS 1.3 Extension for Certific= ate-based Authentication with an External Pre-Shared Key=E2=80=9D draft available = at https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-ps= k/. Please review the document and send your comments to the list by 2359 UT= C on 23 April 2019. =20 Thanks, Chris, Joe, and Sean _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls =20 --B_3641217109_1126335286 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

One question that I have after reading it: I understand why one wants = to implement this extension, but I don=E2=80=99t see how the two endpoints would a= rrive at that external PSK.

Sadly - we're back to the 1980's in terms of key management.   T= he obvious answers are a) they meet to exchange keys, b) they're given a key= through a KDC, c) they get them in the mail. (and I'm really not kidding ab= out (c))

I don=E2=80=99t think I g= et it. There=E2=80=99s a ton of submissions at NIST PQC, most came with some forma= l proofs. I can=E2=80=99t believe none of them is good enough. Anything from that = pool should be better than nothing=E2=80=A6?

Also, if you do have a running KDC, why would you want/nee= d TLS 1.3 ECDHE in addition to it?

Would such a pre-shared key be long-term (i.e., good/used for= many connections), or is it going to be a use-once thing?=

 

 

From: TLS <tls-bounces@ietf.org> on behalf of Russ Housley <housle= y@vigilsec.com>
Date: Monday, May 20, 2019 at 3:21 PM
To: Joe Salowey <joe@salowey.net>= ;
Cc: IETF TLS <tls@ietf.org&= gt;
Subject: Re: [TLS] WGLC for draft-ietf-tls-tls13-cert-with= -extern-psk

 

TLS 1.3 Extension for Certificate-based Authentication with an= External PSK ensures the US Government has a quantum-resistant option for T= LS in the interim years until post-quantum algorithms emerge from the NIST p= rocess. For this reason, there is an intent to specify this extension in fut= ure procurements.

 

Russ

 




On Ma= y 15, 2019, at 9:20 AM, Joseph Salowey <= joe@salowey.net> wrote:

 

The last call has come and gone without any comment.&nbs= p; Please indicate if you have reviewed the draft even if you do not have is= sues to raise so the chairs can see who has reviewed it.  Also indicate= if you have any plans to implement the draft. 

 

On Tue, Apr 9, 2019 at 8:51 PM Jos= eph Salowey <joe@salowey.net> wro= te:

This is the working gro= up last call for the "TLS 1.3 Extension for Certificate-based Authentic= ation with an External Pre-Shared Key=E2=80=9D draft available at https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-wi= th-extern-psk/. Please review the document and send your comments to the= list by 2359 UTC on 23 April 2019.

 

Thanks,
Chris, Joe, and Sean





_________________________=
______________________
TLS mai=
ling list
TLS@ietf.org
https://www.ietf.org/mailma=
n/listinfo/tls

=  

--B_3641217109_1126335286-- --B_3641217109_740760349 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUaQYJKoZIhvcNAQcCoIIUWjCCFFYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EkMwggTzMIID26ADAgECAhNZAAA7OAR1RlCMr77iAAAAADs4MA0GCSqGSIb3DQEBCwUAMFEx CzAJBgNVBAYTAlVTMR8wHQYDVQQKDBZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQL DANQS0kxEzARBgNVBAMMCk1JVExMIENBLTUwHhcNMTgwODI4MjE0NTEyWhcNMjEwODI3MjE0 NTEyWjBhMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEP MA0GA1UECxMGUGVvcGxlMSAwHgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMTTNa5OBrrq5KAlNpaLYYINgEbyE5tvhKFn IXkybBuZ4x75hMtQuLRfw9F2KSPY5RLgcrxVX+r/rGnP0V/Kmteo3u+RZ0LIVez2IOVeXnKR AGGj3KGkmHxteZA0eZt480Lq9Ir74T+7hsyDeB5D6ZPYkVP/eS7/2zbkvkdbu74YIRUrvEYx WTcVPvk0xrp6kcmlRaGiQF5QFQmpzgRMZXV4C+DCEw0a+Ojg6zNwvFht/i2xxATvYGD4xEgH oOxu/X9NQWO8mJ4hVaCQgme9YNgUaTFllUxboN+JEC5IhEYweknsx2yQKReYunGGfrJ1PBTd cHADL0w9H3mIM6K4hQcCAwEAAaOCAbIwggGuMB0GA1UdDgQWBBR8IHruqPneP7HtsHn66Riy qeGe0zAOBgNVHQ8BAf8EBAMCBsAwHwYDVR0jBBgwFoAUL++7xg0du+lq/qxn8wc7CHb2S1kw MwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybC9sbGNhNTBm BggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXR0 by9sbGNhNTAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3NwMD0GCSsG AQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXL3jKH/4pzAgFk AgEIMCIGA1UdJQEB/wQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMBkGA1UdEQQSMBCBDnVy aUBsbC5taXQuZWR1MBgGA1UdIAQRMA8wDQYLKoZIhvcSAgEDAQgwJwYJKwYBBAGCNxQCBBoe GABMAEwAVQBzAGUAcgBTAGkAZwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEAdbqmeCDfWiCd xx+8WfciO5FkqlkexCT5V4OJUFbrEETW8aE0NaYz+GJJJY7G8HBpOhu2quFpwbQnqWZ80eJF iMJNUantotsGdzIJcgqdy6l7zlBHewG+R5ydKB0/42FI15iClyK5GmoWeY0HU4fv/NvJlKmT 9tpkxl9IBbhj0WDkMaPbluyUeN73Pi78iSmfatq8Zwiwci2tW6IYfKinOnogr09i/yU8yDFL ogoRBt26TrMeaT18tBTS8bYpSw40oqQwkj/mR3k5McsPfC9kiUgE685kP56YQMvozwAsd952 J07HC25DCjh1O//X4LwRtioeeMayIrYYz87vq8MA6DCCBMAwggOooAMCAQICAQYwDQYJKoZI hvcNAQELBQAwVjELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRv cnkxDDAKBgNVBAsTA1BLSTEYMBYGA1UEAxMPTUlUTEwgUm9vdCBDQS0yMB4XDTE3MDMwMjEy MDAwMFoXDTI2MDMwMjIzNTk1OVowUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoMFk1JVCBMaW5j b2xuIExhYm9yYXRvcnkxDDAKBgNVBAsMA1BLSTETMBEGA1UEAwwKTUlUTEwgQ0EtNTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKeagw69OR/DuerX2atZrMZpr5DzdS/T4BNd PerqSv5YTEgwhnzsLvhYJxFem87u6/Hse8yxhYAUdb3fBDCGPK3Ecg5mAo0nhWcZUNSX4oju DSf35mO3eEHceEdty9t735jiPP5fMKIuXY5pi8gIpvG9sFIIu08R5lDrHpNvoQrTKbSC9h4c 7eS65j5IkckyW1usuchUvGNms1VLvvNcq+7pDeFJ2REgHuQmARd8v6n/P/an3hsQRnZOdDPR OQ6Mb4mrtSVeUVG2+xhwM8RAPdQ2RmxZxeALWFcbxMaSdRwCGUbFWGUqUUuY13vfjax4bLaz 1jE0OdIT55dO1vQjkssCAwEAAaOCAZwwggGYMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0O BBYEFC/vu8YNHbvpav6sZ/MHOwh29ktZMB8GA1UdIwQYMBaAFP/JyWVMU4DxqQw8Ia6CKsfu +DL7MA4GA1UdDwEB/wQEAwIBhjBnBggrBgEFBQcBAQRbMFkwLgYIKwYBBQUHMAKGImh0dHA6 Ly9jcmwubGwubWl0LmVkdS9nZXR0by9MTFJDQTIwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3Nw LmxsLm1pdC5lZHUvb2NzcDA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLmxsLm1pdC5l ZHUvZ2V0Y3JsL0xMUkNBMjCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3 EgIBAwEIMA0GCyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0G CyqGSIb3EgIBAwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIB AwEQMA0GCSqGSIb3DQEBCwUAA4IBAQAwlhHAs8n3Urt7aYDY2PXRbSjkkwdiRpr5y0vz/Fjx DMgcUjkiP6LJ2k830oJif/hLLzRPdo2hiQWVLQZFBeF/SeyJjtNYnAArDgCI7/Infv+hEpGC 3JGJy9onpGOUcJcE5qUUvD1S2mh0/j+J0LnWXHOyiVpBmtoGNV7s8v3k+FLsP7bY198ifMt0 hvUMF/ng3A5V88iAAG3EfV+FmuNrsSFH1GhTDkTU7qJZoC4//FaFJNAVaWHIDT+SQiL38ddp jSFieFyNxs8+qOnJ8iFIWONeGOoru3bA+tKsEUsVRucuI2WBAeu81gXkiqAh+dIFYiubet8u Gllkn/Enth/oMIIDijCCAnKgAwIBAgIBATANBgkqhkiG9w0BAQsFADBWMQswCQYDVQQGEwJV UzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRgwFgYD VQQDEw9NSVRMTCBSb290IENBLTIwHhcNMTYwNDIwMTIwMDAwWhcNMzUwNDE5MjM1OTU5WjBW MQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UE CxMDUEtJMRgwFgYDVQQDEw9NSVRMTCBSb290IENBLTIwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQC/dagEQY44m2bi5y9p/q8ogU+zzBq0J3pKbCr9d5E2js/eM8jE0/AXf3xE YNSY8khcDuJ3MPqPSikUhb6QupjJ717vzw9XR2pomVfzzXx80NtIT7wHqGJ6opNHtV84jvhR VARQpVEW5EXDq5Vi6+B7DZOP8LZ0R57ft6u5CXmceRtXY6xadns77K35613odFxpcuU/2rxY qADcHu+Q5UgwIqgC5paP4EWrsr5Y2SLKL8p04f0mY6lvJEriNwDvFsucXwkVRI2DlzhjUEms Vpm2QJ4bo2b2nnbgaWWREXM+CmPxWJxX4Ar72tjTt1PHTaRii1Ocq7LRjEEDCxRfEBATAgMB AAGjYzBhMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFP/JyWVMU4DxqQw8Ia6CKsfu+DL7 MB8GA1UdIwQYMBaAFP/JyWVMU4DxqQw8Ia6CKsfu+DL7MA4GA1UdDwEB/wQEAwIBhjANBgkq hkiG9w0BAQsFAAOCAQEAeph8R//cnlowqGVhDQ+dQBswHyNlKv38e+N84XTRysVQJ9Kuobwl DCj5L+KrrqBynrYUSAnR9CQOBWDqb4LYROjUuhaJLGFgJ9xIhAQKWOVfBHzAVJrIXzbZLr0i q8eF2rh3nyNTqBiLqyyNTi/Cy+xUtEkqT+b8KD/DyBbpgczlqEEPr/kJx6XZ8juhKayQ733X 6i2sLXVh8PAIW/PsCbSv4r2JWFJa1riGYi5XRgGJrTt5kpI7TYs+BDxg7PeS7Ri36aHxVZEq 7HYJxiMymT5YNXQEynvm2pvqmoEWRwq8QFerGD7z4b+6aOKLgfRzmS8mFpDLKRuY4qbE70hw kjCCBPYwggPeoAMCAQICE1kAADs5fl+jQ6IgrREAAAAAOzkwDQYJKoZIhvcNAQELBQAwUTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoMFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsM A1BLSTETMBEGA1UEAwwKTUlUTEwgQ0EtNTAeFw0xODA4MjgyMTQ1MjlaFw0yMTA4MjcyMTQ1 MjlaMGExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQ8w DQYDVQQLEwZQZW9wbGUxIDAeBgNVBAMTF0JsdW1lbnRoYWwuVXJpLjUwMDEwNTg0MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAjlVzX1Epz/r2WbCGiAM6OPM9BuZzyzpnqvM/ qhQcCzAMgKplbA+34VNsqvRhMCpE2xMQ3hiJbR85Er581G8KWjSl2IKqPcPANBktEjgNqTXJ OxS1V7fmiiZBte077QDQv8KjBiuL9Qp5EbWLX/RxdJ/iYDHR533CHZKit0BvyjYW45TQHamm eqOujVUW6AcdfpA6CBp4sU6mtPmCdNlSaozfv93gMYH1cN1NCLXjjNBLBJYqRpROGzIP0IdJ E1wHv0cG+VkZIz4GQhtrI92FAC7PjIqw5kRY/H/oucyi3MF69KzCcIN/671qMKAyeN5ZutlE 37GhgS6HJxfIrZvz8wIDAQABo4IBtTCCAbEwHQYDVR0OBBYEFNlSmrtGxxy/jbJT1RDjC+iM 6XinMA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAWgBQv77vGDR276Wr+rGfzBzsIdvZLWTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsL2xsY2E1MGYG CCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5sbC5taXQuZWR1L2dldHRv L2xsY2E1MCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQuZWR1L29jc3AwPQYJKwYB BAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SACAWQC AQkwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGQYDVR0RBBIwEIEO dXJpQGxsLm1pdC5lZHUwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMBCDAnBgkrBgEEAYI3FAIE Gh4YAEwATABVAHMAZQByAEUAbgBjAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IBAQALI3piGL0s Ck4+l/rTKlJXZaZXeyqeuyt2U9Nb5qbjAwr8z/k9ma3mMVW1doSuRZh2tsx2N6jaj8b03YOe sU6HPuQNgz0cL0Af+tYJ+hKQj8LY3pGr+4OdEl9qjrXDK/fuoq1qc12Sn6t7IvF1U+d+hWsP 9VmWLhRXby7hcG5gOSNc/LKIf5tvf3kWfE61MDdTPjU6Gl2+vqgs8S7LQg/gw98rnAOZLoZd wH7N72xgSn4MnETtYBuRbljnfpY+X+t9ab+TpkLUo9VJEzuZL5q2TjhU6DM8teSXpO7rNjy0 xzN+vkXSibUl83wbnSzhANQa2wyDNb4tdUOEUPbjGdSiMYIB7jCCAeoCAQEwaDBRMQswCQYD VQQGEwJVUzEfMB0GA1UECgwWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECwwDUEtJ MRMwEQYDVQQDDApNSVRMTCBDQS01AhNZAAA7OAR1RlCMr77iAAAAADs4MAkGBSsOAwIaBQCg XTAjBgkqhkiG9w0BCQQxFgQUGIGSzTjWMZDFEsU7FHKg0y0ulPIwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwNTIwMjExMTQ5WjANBgkqhkiG9w0BAQEF AASCAQBHOylBV9W8oTeGjccZipc8S9GAAcdjl+O9rGb9z+zjK6pgjPZ+ik64MjOgHOsOB3ZP 1e8jLbQOQA4f1xixJcPVA0moOkESLNPgwtIbJ0j3fhw1ueD+G/YK44AsMmGuyxl4kFlkmid4 6gL2Q++xzGa+pvjNZI9dtBALllvMaAwr4+x7x0Cl6miCKPhQxFCSxdGVrdqvuEloQtwN0KqR jgif49yPonoyPHseWZU3vLkm0s+5Ot+M68HnulKD/ThsMJV9MR5p1YJ8Z6U+tmAsrDkQCLhi 9/H8L2t6HyZXeRRGOZdfENnPRoh8QM7hxDxXIjOmIUsAqagT+TTn83a07HGV --B_3641217109_740760349-- From nobody Mon May 20 17:26:02 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D791F1200EA for ; Mon, 20 May 2019 17:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2tUyRz1TaGO for ; Mon, 20 May 2019 17:25:58 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [198.0.208.83]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 971D0120090 for ; Mon, 20 May 2019 17:25:58 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id DEA6333D2B3; Tue, 21 May 2019 00:25:57 +0000 (UTC) Sender: geoffk@localhost.localdomain To: Joseph Salowey Cc: "" References: From: Geoffrey Keating Date: 20 May 2019 17:25:57 -0700 In-Reply-To: Message-ID: Lines: 32 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-tls13-cert-with-extern-psk X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 21 May 2019 00:26:01 -0000 Joseph Salowey writes: > The last call has come and gone without any comment. Please indicate if > you have reviewed the draft even if you do not have issues to raise so the > chairs can see who has reviewed it. Also indicate if you have any plans to > implement the draft. I looked at the draft. My understanding of the draft (and I think it would have helped if it contained a diagram showing the resulting TLS handshake) is that it's specifying the existing psk_dhe_ke flow, to which it adds a certificate-based signature over the handshake, which it doesn't specify but works the same way as in RFC 8446 when there is no PSK. This is somewhat confusing because the draft is written as if it starts with a certificate-based TLS flow and somehow adds a PSK; it repeats all the RFC 8446 PSK machinery, but doesn't explain how the certificate interacts with it, and raises questions like "are there two DH operations or just one?". I think the draft could have been a lot shorter. Conversely, one area where the draft could have been longer would be to explain how exactly this produces quantum-resistance in the presence of a secret shared key. It appears that it relies on the HKDF-Expand function being quantum-resistant. That seems like an important thing to document, given that we don't have fully functional quantum cryptanalysis yet and so don't know exactly what might be quantum-resistant or not. However, once you're past that, the resulting protocol seems quite simple (as an addition to psk_dhe_ke) and I have no objections to it. From nobody Tue May 21 06:37:42 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F28112012D for ; Tue, 21 May 2019 06:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QODq9TwJLSDx for ; Tue, 21 May 2019 06:37:31 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15408120141 for ; Tue, 21 May 2019 06:37:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id A4B7E3005AB for ; Tue, 21 May 2019 09:18:12 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id WEsSEAtduxzd for ; Tue, 21 May 2019 09:18:10 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id B1863300A46; Tue, 21 May 2019 09:18:10 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_9EE031DC-2A34-41A7-BF1F-4D932209FC8C" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 21 May 2019 09:37:28 -0400 In-Reply-To: <71EB9B8A-C410-4A35-A0FE-3E2BE89E7C65@ll.mit.edu> Cc: IETF TLS To: Uri Blumenthal References: <623BD5EA-1D76-494C-B87D-55FD1156EBD6@vigilsec.com> <71EB9B8A-C410-4A35-A0FE-3E2BE89E7C65@ll.mit.edu> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-tls13-cert-with-extern-psk X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 21 May 2019 13:37:34 -0000 --Apple-Mail=_9EE031DC-2A34-41A7-BF1F-4D932209FC8C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Uri: Out-of-band distribution is used. This draft makes no attempt at = picking one of the many ways to do that. Russ > On May 20, 2019, at 3:41 PM, Blumenthal, Uri - 0553 - MITLL = wrote: >=20 > I reviewed this draft (=E2=80=9Cbrowsed through=E2=80=9D would be a = more honest statement). I didn=E2=80=99t spot an obvious problem with = it. > =20 > One question that I have after reading it: I understand why one wants = to implement this extension, but I don=E2=80=99t see how the two = endpoints would arrive at that external PSK. > =20 > From: TLS > on = behalf of Russ Housley > > Date: Monday, May 20, 2019 at 3:21 PM > To: Joe Salowey > > Cc: IETF TLS > > Subject: Re: [TLS] WGLC for draft-ietf-tls-tls13-cert-with-extern-psk > =20 > TLS 1.3 Extension for Certificate-based Authentication with an = External PSK ensures the US Government has a quantum-resistant option = for TLS in the interim years until post-quantum algorithms emerge from = the NIST process. For this reason, there is an intent to specify this = extension in future procurements. > =20 > Russ > =20 >=20 >=20 >> On May 15, 2019, at 9:20 AM, Joseph Salowey > wrote: >> =20 >> The last call has come and gone without any comment. Please indicate = if you have reviewed the draft even if you do not have issues to raise = so the chairs can see who has reviewed it. Also indicate if you have = any plans to implement the draft.=20 >> =20 >> On Tue, Apr 9, 2019 at 8:51 PM Joseph Salowey > wrote: >>> This is the working group last call for the "TLS 1.3 Extension for = Certificate-based Authentication with an External Pre-Shared Key=E2=80=9D = draft available at = https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk= / = . Please review the document and send your comments to the list by = 2359 UTC on 23 April 2019. >>> =20 >>> Thanks, >>> Chris, Joe, and Sean >=20 >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls = --Apple-Mail=_9EE031DC-2A34-41A7-BF1F-4D932209FC8C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Uri:

Out-of-band distribution is used.  This draft makes no = attempt at picking one of the many ways to do that.

Russ


On May 20, 2019, at 3:41 PM, Blumenthal, Uri = - 0553 - MITLL <uri@ll.mit.edu> wrote:

I reviewed this draft (=E2=80=9Cbrow= sed through=E2=80=9D would be a more honest statement). I didn=E2=80=99t = spot an obvious problem with it.
 
One question that = I have after reading it: I understand why one wants to implement this = extension, but I don=E2=80=99t see how the two endpoints would arrive at = that external PSK.
 
From: TLS <tls-bounces@ietf.org> on = behalf of Russ Housley <housley@vigilsec.com>
Date: Monday, May 20, 2019 at = 3:21 PM
To: Joe Salowey <joe@salowey.net>
Cc: IETF = TLS <tls@ietf.org>
Subject: Re: [TLS] WGLC for = draft-ietf-tls-tls13-cert-with-extern-psk
 
TLS 1.3 Extension = for Certificate-based Authentication with an External PSK ensures the US = Government has a quantum-resistant option for TLS in the interim years = until post-quantum algorithms emerge from the NIST process. For this = reason, there is an intent to specify this extension in future = procurements.
 
Russ
 


On May 15, 2019, at 9:20 AM, Joseph = Salowey <joe@salowey.net> = wrote:
 
The last call has = come and gone without any comment.  Please indicate if you have = reviewed the draft even if you do not have issues to raise so the chairs = can see who has reviewed it.  Also indicate if you have any plans = to implement the draft. 
 
On Tue, = Apr 9, 2019 at 8:51 PM Joseph Salowey <joe@salowey.net> wrote:
This= is the working group last call for the "TLS 1.3 Extension for = Certificate-based Authentication with an External Pre-Shared Key=E2=80=9D = draft available at https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with= -extern-psk/. Please review the document and send your comments to = the list by 2359 UTC on 23 April 2019.
 
Thanks,
Chris, Joe, and = Sean
<= /div>


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

= --Apple-Mail=_9EE031DC-2A34-41A7-BF1F-4D932209FC8C-- From nobody Tue May 21 06:39:36 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5555912006A for ; Tue, 21 May 2019 06:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FTfov6874Lk for ; Tue, 21 May 2019 06:39:33 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B377120041 for ; Tue, 21 May 2019 06:39:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 372FB300A9E for ; Tue, 21 May 2019 09:20:15 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id sIXzcaWWOZwx for ; Tue, 21 May 2019 09:20:13 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 13B003005AB; Tue, 21 May 2019 09:20:13 -0400 (EDT) From: Russ Housley Message-Id: <68386DDF-788B-4170-99C6-82469262DDF2@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_86AC13F1-04D7-440B-89B4-609043250F6A" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 21 May 2019 09:39:31 -0400 In-Reply-To: <18193F45-9A43-432C-AE7C-009B0F237598@ll.mit.edu> Cc: IETF TLS To: Uri Blumenthal References: <623BD5EA-1D76-494C-B87D-55FD1156EBD6@vigilsec.com> <71EB9B8A-C410-4A35-A0FE-3E2BE89E7C65@ll.mit.edu> <18193F45-9A43-432C-AE7C-009B0F237598@ll.mit.edu> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-tls13-cert-with-extern-psk X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 21 May 2019 13:39:35 -0000 --Apple-Mail=_86AC13F1-04D7-440B-89B4-609043250F6A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Uri: As my note said, "... until post-quantum algorithms emerge from the NIST = process." Russ > On May 20, 2019, at 5:11 PM, Blumenthal, Uri - 0553 - MITLL = wrote: >=20 > One question that I have after reading it: I understand why one wants = to implement this extension, but I don=E2=80=99t see how the two = endpoints would arrive at that external PSK.=20 > Sadly - we're back to the 1980's in terms of key management. The = obvious answers are a) they meet to exchange keys, b) they're given a = key through a KDC, c) they get them in the mail. (and I'm really not = kidding about (c)) >=20 > I don=E2=80=99t think I get it. There=E2=80=99s a ton of submissions = at NIST PQC, most came with some formal proofs. I can=E2=80=99t believe = none of them is good enough. Anything from that pool should be better = than nothing=E2=80=A6? > Also, if you do have a running KDC, why would you want/need TLS 1.3 = ECDHE in addition to it?=20 > Would such a pre-shared key be long-term (i.e., good/used for many = connections), or is it going to be a use-once thing? > =20 >> =20 >> From: TLS on = behalf of Russ Housley = >> Date: Monday, May 20, 2019 at 3:21 PM >> To: Joe Salowey >> Cc: IETF TLS >> Subject: Re: [TLS] WGLC for draft-ietf-tls-tls13-cert-with-extern-psk >> =20 >> TLS 1.3 Extension for Certificate-based Authentication with an = External PSK ensures the US Government has a quantum-resistant option = for TLS in the interim years until post-quantum algorithms emerge from = the NIST process. For this reason, there is an intent to specify this = extension in future procurements. >> =20 >> Russ >> =20 >>=20 >>=20 >>=20 >>> On May 15, 2019, at 9:20 AM, Joseph Salowey > wrote: >>> =20 >>> The last call has come and gone without any comment. Please = indicate if you have reviewed the draft even if you do not have issues = to raise so the chairs can see who has reviewed it. Also indicate if = you have any plans to implement the draft.=20 >>> =20 >>> On Tue, Apr 9, 2019 at 8:51 PM Joseph Salowey > wrote: >>>> This is the working group last call for the "TLS 1.3 Extension for = Certificate-based Authentication with an External Pre-Shared Key=E2=80=9D = draft available at = https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk= / = . Please review the document and send your comments to the list by = 2359 UTC on 23 April 2019. >>>> =20 >>>> Thanks, >>>> Chris, Joe, and Sean >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls = =20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls = --Apple-Mail=_86AC13F1-04D7-440B-89B4-609043250F6A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Uri:

As = my note said, "... until post-quantum algorithms emerge from the = NIST process."

Russ


On May = 20, 2019, at 5:11 PM, Blumenthal, Uri - 0553 - MITLL <uri@ll.mit.edu> = wrote:

One question that I have after reading it: I understand why = one wants to implement this extension, but I don=E2=80=99t see how the = two endpoints would arrive at that external PSK. 

Sadly = - we're back to the 1980's in terms of key management.   The = obvious answers are a) they meet to exchange keys, b) they're given a = key through a KDC, c) they get them in the mail. (and I'm really not = kidding about (c))

I don=E2=80=99t think I get it. = There=E2=80=99s a ton of submissions at NIST PQC, most came with some = formal proofs. I can=E2=80=99t believe none of them is good enough. = Anything from that pool should be better than nothing=E2=80=A6?
Also, if you do have a running KDC, why would you = want/need TLS 1.3 ECDHE in addition to it? 
Would such a pre-shared key be long-term (i.e., = good/used for many connections), or is it going to be a use-once = thing?
 
 
From: TLS <tls-bounces@ietf.org> on behalf of Russ = Housley <housley@vigilsec.com>
Date: Monday, May 20, 2019 at = 3:21 PM
To: Joe Salowey <joe@salowey.net>
Cc: IETF = TLS <tls@ietf.org>
Subject: Re: [TLS] WGLC for = draft-ietf-tls-tls13-cert-with-extern-psk
 
TLS 1.3 Extension for Certificate-based = Authentication with an External PSK ensures the US Government has a = quantum-resistant option for TLS in the interim years until post-quantum = algorithms emerge from the NIST process. For this reason, there is an = intent to specify this extension in future procurements.
 
Russ
 



On May 15, 2019, at 9:20 AM, Joseph = Salowey <joe@salowey.net> = wrote:
 
The last call has come and = gone without any comment.  Please indicate if you have reviewed the = draft even if you do not have issues to raise so the chairs can see who = has reviewed it.  Also indicate if you have any plans to implement = the draft. 
 
On Tue, = Apr 9, 2019 at 8:51 PM Joseph Salowey <joe@salowey.net> wrote:
This= is the working group last call for the "TLS 1.3 Extension for = Certificate-based Authentication with an External Pre-Shared Key=E2=80=9D = draft available at https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with= -extern-psk/. Please review the document and send your comments to = the list by 2359 UTC on 23 April 2019.
 
Thanks,
Chris, Joe, and = Sean
<= /div>





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

 

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

= --Apple-Mail=_86AC13F1-04D7-440B-89B4-609043250F6A-- From nobody Tue May 21 06:48:48 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1C35120043; Tue, 21 May 2019 06:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97nPPaqa8FUS; Tue, 21 May 2019 06:48:38 -0700 (PDT) Received: from mx1.cnes.fr (mx1.cnes.fr [194.199.174.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22C67120041; Tue, 21 May 2019 06:48:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.60,495,1549929600"; d="scan'208,217";a="7936522" X-IPAS-Result: =?us-ascii?q?A2GLAQBtAORc/wEBeAplHAEBAQQBAQcEAQGBUgYBAQsBg?= =?us-ascii?q?Q6BAlgRUSESMqh6gn2CVYMnFIFnCQEBAQEBAQEBASsJAQIBAYRAAoInIzUID?= =?us-ascii?q?gEDAQEBBAEBAQECAQECAmkcDIVOATBMEgEFEBVWJgEEAQ0NE4MIgR1tD6gDG?= =?us-ascii?q?oQtQYUoBoE0AYFfjAeBV4VrAgMBgSU6gzqCJgSSVJVPBwKBK2QDggyEH4ZAh?= =?us-ascii?q?i1yi3EDiUaJPoMYhnKQTwE2gVczGieDOYsRhT9CgVEIi3IBgSABAQ?= X-URL-LookUp-ScanningError: 1 From: Kuhn Nicolas To: "tsvwg@ietf.org" , IETF QUIC WG , "'tls@ietf.org'" CC: "'emile.stephan@orange.com'" , "'gorry@erg.abdn.ac.uk'" , Kuhn Nicolas Thread-Topic: Updates on the "Transport parameters for 0-RTT connections" draft Thread-Index: AdUP24Zg+1VIa8FMRoKfDVG/fwUlTg== Date: Tue, 21 May 2019 13:47:28 +0000 Deferred-Delivery: Tue, 21 May 2019 13:48:27 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tm-as-product-ver: SMEX-11.0.0.4255-8.100.1062-24628.005 x-tm-as-result: No--19.463400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_F3B0A07CFD358240926B78A680E166FF1EBEEF69TWMBXP03cnesnet_" MIME-Version: 1.0 Archived-At: Subject: [TLS] Updates on the "Transport parameters for 0-RTT connections" draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 21 May 2019 13:48:41 -0000 --_000_F3B0A07CFD358240926B78A680E166FF1EBEEF69TWMBXP03cnesnet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, Following the different feedbacks on this draft, we have proposed an update= d version on the "Transport parameters for 0-RTT connections". https://datatracker.ietf.org/doc/draft-kuhn-quic-0rtt-bdp/ The draft proposes a solution where path characteristics are shared between= the peers to improve the ingress traffic for 0-RTT connections. The difference with version 01 are mainly based on the received feedback. In short, we now a BDP_metadata structure so that various path parameters c= an be exposed to the client (MTU, RTT, bandwidth, loss-rate). We have also added a section to discuss what happens when BDP is used incor= rectly. Let us know if we have any views or interest in this proposal. Cheers, Nico for the authors --_000_F3B0A07CFD358240926B78A680E166FF1EBEEF69TWMBXP03cnesnet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

Following the different feedbac= ks on this draft, we have proposed an updated version on the “Transpo= rt parameters for 0-RTT connections”.

https://datatracker.ietf.org/doc/dr= aft-kuhn-quic-0rtt-bdp/

 

The draft proposes a solution w= here path characteristics are shared between the peers to improve the ingre= ss traffic for 0-RTT connections.

 

The difference with version 01 = are mainly based on the received feedback.

In short, we now a BDP_metadata= structure so that various path parameters can be exposed to the client (MT= U, RTT, bandwidth, loss-rate).

We have also added a section to= discuss what happens when BDP is used incorrectly.

 

Let us know if we have any view= s or interest in this proposal.

 

Cheers,

 

Nico for the authors=

 

--_000_F3B0A07CFD358240926B78A680E166FF1EBEEF69TWMBXP03cnesnet_-- From nobody Tue May 21 06:54:19 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0087F120043 for ; Tue, 21 May 2019 06:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIq5tJSPyxqD for ; Tue, 21 May 2019 06:54:16 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AFF2120041 for ; Tue, 21 May 2019 06:54:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 1AFA5300ABC for ; Tue, 21 May 2019 09:34:58 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 2w6AsffgMDeF for ; Tue, 21 May 2019 09:34:56 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 6E88F3005AB; Tue, 21 May 2019 09:34:56 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: Date: Tue, 21 May 2019 09:54:13 -0400 Cc: Joe Salowey , IETF TLS Content-Transfer-Encoding: quoted-printable Message-Id: <1B76BDA6-5641-43A9-894F-2D70AEE9AC09@vigilsec.com> References: To: Geoffrey Keating X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-tls13-cert-with-extern-psk X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 21 May 2019 13:54:18 -0000 Geoffrey: >=20 > The last call has come and gone without any comment. Please indicate = if >> you have reviewed the draft even if you do not have issues to raise = so the >> chairs can see who has reviewed it. Also indicate if you have any = plans to >> implement the draft. >=20 > I looked at the draft. >=20 > My understanding of the draft (and I think it would have helped if it > contained a diagram showing the resulting TLS handshake) is that it's > specifying the existing psk_dhe_ke flow, to which it adds a > certificate-based signature over the handshake, which it doesn't > specify but works the same way as in RFC 8446 when there is no PSK. I am pleased to add text that will make it more clear, but you are the = first one to ask. Please see slides 5 and 6 of the presentation at IETF 104: = https://datatracker.ietf.org/meeting/104/materials/slides-104-tls-slides-i= etf104-tls13-cert-with-extern-psk-00 > This is somewhat confusing because the draft is written as if it > starts with a certificate-based TLS flow and somehow adds a PSK; it > repeats all the RFC 8446 PSK machinery, but doesn't explain how the > certificate interacts with it, and raises questions like "are there > two DH operations or just one?". I think the draft could have been a > lot shorter. One (EC)DH exchange. I agree that there is a fair amount of context in the draft. That was = an attempt to avoid the confusion that you claim in the previous = paragraph. > Conversely, one area where the draft could have been longer would be = to > explain how exactly this produces quantum-resistance in the presence > of a secret shared key. It appears that it relies on the HKDF-Expand > function being quantum-resistant. That seems like an important thing > to document, given that we don't have fully functional quantum > cryptanalysis yet and so don't know exactly what might be > quantum-resistant or not. Hash functions are quantum-resistant. Shor's algorithm means that you = might want to use one that 2x longer than previously chosen. The same = is true for symmetric encryption algorithm keys. I can add a paragraph to the security considerations that HKDF and the = underlying hash function are assumed to be quantum-resistant. > However, once you're past that, the resulting protocol seems quite > simple (as an addition to psk_dhe_ke) and I have no objections to it. Thanks. Russ From nobody Tue May 21 07:11:33 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A129120158 for ; Tue, 21 May 2019 07:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNQRlVcw3p94 for ; Tue, 21 May 2019 07:11:31 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22C2F120157 for ; Tue, 21 May 2019 07:11:31 -0700 (PDT) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x4LE2h3C020783; Tue, 21 May 2019 15:11:29 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=UcoxRxHOGhmcPwCWI/KAMtnPIT7l28f86eV9QMxOU9w=; b=ovGwy80EtW+JnD0zL7KfSjXXyuE6/qaQgIWuWzJbS369RGrUzTuEsUN0btVE4okV1X6s YRMtuYV4ycJKVtlCARN5dl2JTmzW6V+ez4qILpl3c1b/Tq+638Tq5sHRUsg68ZaZ/dRE B/uqS/Nj7lsnKfOTxFBK/Y3HDCz60SZgx8A36EPTavXt2qAbL6pUeWUPcTJ5v/yATioz S58hOHtzl/h0H0ddgF2W1hDMn+vhXsM/1xlIjogApjRp9mc7JybZThD7XYv7tcYfmMqJ igS2LQQBvV0W/YMA4N41NZf/9L1BpZWu76DJ7Ac+ex3Yx5UnQOJVIJnm4hjfK6dRRuXI Ng== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2skw3hvm26-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 21 May 2019 15:11:29 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x4LE2Xm3012385; Tue, 21 May 2019 10:11:28 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.30]) by prod-mail-ppoint1.akamai.com with ESMTP id 2sjdcvm13q-5 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 21 May 2019 10:11:28 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.27.107) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 21 May 2019 07:11:22 -0700 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1473.003; Tue, 21 May 2019 09:11:22 -0500 From: "Salz, Rich" To: "Blumenthal, Uri - 0553 - MITLL" , Michael StJohns , "tls@ietf.org" Thread-Topic: [TLS] WGLC for draft-ietf-tls-tls13-cert-with-extern-psk Thread-Index: AQHVCyEWGyDDTpoLN0uov+yfvYZJUqZ0v6sAgAAF6ACAABViAIAAA+GAgADZyoA= Date: Tue, 21 May 2019 14:11:21 +0000 Message-ID: <39577FA2-8F08-49AB-A436-BB05F6034EC5@akamai.com> References: <623BD5EA-1D76-494C-B87D-55FD1156EBD6@vigilsec.com> <71EB9B8A-C410-4A35-A0FE-3E2BE89E7C65@ll.mit.edu> <18193F45-9A43-432C-AE7C-009B0F237598@ll.mit.edu> In-Reply-To: <18193F45-9A43-432C-AE7C-009B0F237598@ll.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.19.0.190512 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.37.44] Content-Type: multipart/alternative; boundary="_000_39577FA28F0849ABA436BB05F6034EC5akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-21_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905210088 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-21_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905210088 Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-tls13-cert-with-extern-psk X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 21 May 2019 14:11:33 -0000 --_000_39577FA28F0849ABA436BB05F6034EC5akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgSSBkb27igJl0IHRoaW5rIEkgZ2V0IGl0LiBUaGVyZeKAmXMgYSB0b24gb2Ygc3VibWlz c2lvbnMgYXQgTklTVCBQUUMsIG1vc3QgY2FtZSB3aXRoIHNvbWUgZm9ybWFsIHByb29mcy4gSSBj YW7igJl0IGJlbGlldmUgbm9uZSBvZiB0aGVtIGlzIGdvb2QgZW5vdWdoLiBBbnl0aGluZyBmcm9t IHRoYXQgcG9vbCBzaG91bGQgYmUgYmV0dGVyIHRoYW4gbm90aGluZ+KApj8NCg0KV2Ugd2FudCB0 byB3YWl0IHVudGlsIE5JU1QgZGVjaWRlcyBhbmQgbm90IGp1bXAgdGhlIGd1bi4NCg0KICAqICAg QWxzbywgaWYgeW91IGRvIGhhdmUgYSBydW5uaW5nIEtEQywgd2h5IHdvdWxkIHlvdSB3YW50L25l ZWQgVExTIDEuMyBFQ0RIRSBpbiBhZGRpdGlvbiB0byBpdD8NCg0KSSBiZWxpZXZlIHRoaXMgaXMg S0RDIGFzIGEgZ2VuZXJpYyB0ZXJtLCBub3QgS2VyYmVyb3MuICBNYW55IGVudGVycHJpc2VzIGhh dmUgYSB3YXkgdG8gZGlzdHJpYnV0ZSBrZXlzIHRvIGVudGl0aWVzLg0K --_000_39577FA28F0849ABA436BB05F6034EC5akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <27736FB8E8BBDF42B8530277A655BC95@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEx LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0Zv bGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFs MA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJn aW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1l OiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9 DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1h aWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0 IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo1MzAxOTMwMjY7DQoJbXNv LWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNzAzNjE0MDg4IDE0 MDU2NDg4MjYgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2 OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1z dGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFzdC1mb250LWZhbWls eTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KQGxpc3QgbDA6bGV2 ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGww OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwN Cgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgc3R5bGU9Im1zby1saXN0OmwwIGxldmVsMSBs Zm8xIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+SSBkb27igJl0IHRoaW5rIEkgZ2V0 IGl0LiBUaGVyZeKAmXMgYSB0b24gb2Ygc3VibWlzc2lvbnMgYXQgTklTVCBQUUMsIG1vc3QgY2Ft ZSB3aXRoIHNvbWUgZm9ybWFsIHByb29mcy4gSSBjYW7igJl0IGJlbGlldmUgbm9uZSBvZiB0aGVt IGlzIGdvb2QgZW5vdWdoLiBBbnl0aGluZyBmcm9tIHRoYXQgcG9vbCBzaG91bGQgYmUgYmV0dGVy IHRoYW4NCiBub3RoaW5n4oCmPzwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwPldlIHdh bnQgdG8gd2FpdCB1bnRpbCBOSVNUIGRlY2lkZXMgYW5kIG5vdCBqdW1wIHRoZSBndW4uPG86cD48 L286cD48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgc3R5bGU9Im1zby1saXN0OmwwIGxldmVs MSBsZm8xIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+QWxzbywgaWYgeW91IGRvIGhh dmUgYSBydW5uaW5nIEtEQywgd2h5IHdvdWxkIHlvdSB3YW50L25lZWQgVExTIDEuMyBFQ0RIRSBp biBhZGRpdGlvbiB0byBpdD8NCjwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwPkkgYmVs aWV2ZSB0aGlzIGlzIEtEQyBhcyBhIGdlbmVyaWMgdGVybSwgbm90IEtlcmJlcm9zLiZuYnNwOyBN YW55IGVudGVycHJpc2VzIGhhdmUgYSB3YXkgdG8gZGlzdHJpYnV0ZSBrZXlzIHRvIGVudGl0aWVz LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_39577FA28F0849ABA436BB05F6034EC5akamaicom_-- From nobody Tue May 21 12:46:14 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A28312009E for ; Tue, 21 May 2019 12:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vcyDPItqo-P4 for ; Tue, 21 May 2019 12:46:10 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FA2D120096 for ; Tue, 21 May 2019 12:46:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id A3FCD300AE4 for ; Tue, 21 May 2019 15:26:51 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id YnYaWZEl5idz for ; Tue, 21 May 2019 15:26:50 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 1475C300471; Tue, 21 May 2019 15:26:50 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: Date: Tue, 21 May 2019 15:46:07 -0400 Cc: Joe Salowey , IETF TLS Content-Transfer-Encoding: quoted-printable Message-Id: <171CD4CD-BB93-4F96-AD75-97EBA3540A92@vigilsec.com> References: To: Geoffrey Keating X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-tls13-cert-with-extern-psk X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 21 May 2019 19:46:12 -0000 > On May 20, 2019, at 8:25 PM, Geoffrey Keating = wrote: >=20 > Joseph Salowey writes: >=20 >> The last call has come and gone without any comment. Please indicate = if >> you have reviewed the draft even if you do not have issues to raise = so the >> chairs can see who has reviewed it. Also indicate if you have any = plans to >> implement the draft. >=20 > I looked at the draft. >=20 > My understanding of the draft (and I think it would have helped if it > contained a diagram showing the resulting TLS handshake) is that it's > specifying the existing psk_dhe_ke flow, to which it adds a > certificate-based signature over the handshake, which it doesn't > specify but works the same way as in RFC 8446 when there is no PSK. >=20 > This is somewhat confusing because the draft is written as if it > starts with a certificate-based TLS flow and somehow adds a PSK; it > repeats all the RFC 8446 PSK machinery, but doesn't explain how the > certificate interacts with it, and raises questions like "are there > two DH operations or just one?". I think the draft could have been a > lot shorter. >=20 > Conversely, one area where the draft could have been longer would be = to > explain how exactly this produces quantum-resistance in the presence > of a secret shared key. It appears that it relies on the HKDF-Expand > function being quantum-resistant. That seems like an important thing > to document, given that we don't have fully functional quantum > cryptanalysis yet and so don't know exactly what might be > quantum-resistant or not. >=20 > However, once you're past that, the resulting protocol seems quite > simple (as an addition to psk_dhe_ke) and I have no objections to it. I think that the necessary property is that HKDF reman a PRF. I suggest the following additions to the Security Considerations: If the external PSK is known to any party other than the client and the server, then the external PSK MUST NOT be the sole basis for authentication. The reasoning is explained in [K2016] (see Section 4.2). When this extension is used, authentication is based on certificates, not the external PSK. In this extension, the external PSK regains the forward secrecy if the (EC)DH key agreement is ever broken by cryptanalysis or the future invention of a large-scale quantum computer. As long as the attacker does not know the PSK and the key derivation algorithm remains unbroken, the attacker cannot derive the session secrets even if they are able to compute the (EC)DH shared secret. TLS 1.3 key derivation makes use of the HKDF algorithm, which depends upon the HMAC construction and a hash function. This extension provides the desired protection for the session secrets as long as HMAC with the selected hash function is a pseudorandom function (PRF) [GGM1986]. [GGM1986] Goldreich, O., Goldwasser, S., and S. Micali, "How to construct random functions", J. ACM 1986 (33), pp. 792-807, 1986. [K2016] Krawczyk, H., "A Unilateral-to-Mutual Authentication Compiler for Key Exchange (with Applications to Client Authentication in TLS 1.3)", IACR ePrint 2016/711, August 2016. Russ From nobody Tue May 21 14:09:08 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B92091200FB for ; Tue, 21 May 2019 14:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dB4aqF98sIza for ; Tue, 21 May 2019 14:09:04 -0700 (PDT) Received: from mail-io1-f68.google.com (mail-io1-f68.google.com [209.85.166.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E2D61200A4 for ; Tue, 21 May 2019 14:09:04 -0700 (PDT) Received: by mail-io1-f68.google.com with SMTP id g16so80550iom.9 for ; Tue, 21 May 2019 14:09:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bVO+GGnJdztMKFN/PViXuPNjuYUFL8hzFezP1MxONbs=; b=uO+DV+yQQTnvXF/ui63cf/hEbiVFmzHAU9UpLEyzEbJGfymFHoKSbCun/Kg5NEXtFZ raqZ2Rm++/24GoKe71vu0rvz8hAKJLeTomnUL2zQx1noGeu4FUScEvZ7y/tMq+N7vtPf hhkO96yzTu5u74bHVDV7ydI4u7ml1uuS0QRgbnxo58agiR8XujCca+AIqEDxW6jCMtHh qyE8L+0KKGIWnfNxhpqBlpEyBWxmh8bvEiq+k09IyMpYE0gBOq4JjUHPgDyEmz7p0sLp lBMS+8rMB3hGXZMb8u+dWzKeSdORcy79Ugy/yiRtycaNjakRDA9HjH1k3JZfbVPIsqJ5 NLLQ== X-Gm-Message-State: APjAAAWAD31KDboQG53ttFlcVEW4U6IUHb1TkzEIBOmgUd7Ox4kSiCbT Lr1WKzQlvrFXv9AUScoP0MNeHDiWemClcfw/LiXsPgrZ X-Google-Smtp-Source: APXvYqxklCKNRdYmQLtlnZo64t6sYsWspnc6s+TPdBRTBz+krIn/qEH5f9XnvReHkAolQPyx2T2G88RDtU/6ogF8NOI= X-Received: by 2002:a5d:9d07:: with SMTP id j7mr30981683ioj.39.1558472943121; Tue, 21 May 2019 14:09:03 -0700 (PDT) MIME-Version: 1.0 References: <171CD4CD-BB93-4F96-AD75-97EBA3540A92@vigilsec.com> In-Reply-To: <171CD4CD-BB93-4F96-AD75-97EBA3540A92@vigilsec.com> From: Hugo Krawczyk Date: Tue, 21 May 2019 17:08:37 -0400 Message-ID: To: Russ Housley Cc: Geoffrey Keating , IETF TLS Content-Type: multipart/alternative; boundary="0000000000002aba0f05896c42eb" Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-tls13-cert-with-extern-psk X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 21 May 2019 21:09:07 -0000 --0000000000002aba0f05896c42eb Content-Type: text/plain; charset="UTF-8" A clarification on the text suggest below by Russ. The way I see it, the external PSK as used in draft-ietf-tls-tls13-cert-with-extern-psk is not intended as a means of authentication but as a way of regaining forward secrecy in case the (EC)DHE mechanism is ever broken (e.g., by cryptanalysis or by a quantum computer). Indeed, as long as the future attacker does not learn the PSK and the key derivation remains unbroken (e.g., HMAC is still a secure PRF (*)), that attacker cannot derive the session secrets even if it can compute the (EC)DHE value. When looking at the mechanism in this way, questions like whether this is a PSK-with-ECDHE mechanism with added signatures or a regular 1.5 RTT with added PSK authentication are easily answered. It is a regular 1.5 RTT where a PSK has been added to the key derivation for the sake of quantum-resistant forward secrecy. In this case, one should see authentication as fully relying on certificate-based signatures. So, even if parties other than the communicating client and server know the PSK, this endangers the secrecy of PSK and its forward security effect, but not the authenticity of the handshake. The above is my interpretation of the draft based on a superficial reading. I have not studied it carefully enough to validate the design or understand the full implication to TLS 1.3. Yet, it seems that the above conceptual approach may help understanding the goal of the draft and analyzing its security. (*) The design of HKDF has as an explicit goal to support the case of secret salt in HKDF-Extract in which case the security of HKDF relies solely on HMAC being a secure PRF (which is the most studied aspect of HMAC). Using the PSK as input to the KDF achieves this property. Hugo On Tue, May 21, 2019 at 3:46 PM Russ Housley wrote: > > > > On May 20, 2019, at 8:25 PM, Geoffrey Keating wrote: > > > > Joseph Salowey writes: > > > >> The last call has come and gone without any comment. Please indicate if > >> you have reviewed the draft even if you do not have issues to raise so > the > >> chairs can see who has reviewed it. Also indicate if you have any > plans to > >> implement the draft. > > > > I looked at the draft. > > > > My understanding of the draft (and I think it would have helped if it > > contained a diagram showing the resulting TLS handshake) is that it's > > specifying the existing psk_dhe_ke flow, to which it adds a > > certificate-based signature over the handshake, which it doesn't > > specify but works the same way as in RFC 8446 when there is no PSK. > > > > This is somewhat confusing because the draft is written as if it > > starts with a certificate-based TLS flow and somehow adds a PSK; it > > repeats all the RFC 8446 PSK machinery, but doesn't explain how the > > certificate interacts with it, and raises questions like "are there > > two DH operations or just one?". I think the draft could have been a > > lot shorter. > > > > Conversely, one area where the draft could have been longer would be to > > explain how exactly this produces quantum-resistance in the presence > > of a secret shared key. It appears that it relies on the HKDF-Expand > > function being quantum-resistant. That seems like an important thing > > to document, given that we don't have fully functional quantum > > cryptanalysis yet and so don't know exactly what might be > > quantum-resistant or not. > > > > However, once you're past that, the resulting protocol seems quite > > simple (as an addition to psk_dhe_ke) and I have no objections to it. > > I think that the necessary property is that HKDF reman a PRF. > > I suggest the following additions to the Security Considerations: > > If the external PSK is known to any party other than the client and > the server, then the external PSK MUST NOT be the sole basis for > authentication. The reasoning is explained in [K2016] (see > Section 4.2). When this extension is used, authentication is based > on certificates, not the external PSK. > > In this extension, the external PSK regains the forward secrecy if the > (EC)DH key agreement is ever broken by cryptanalysis or the future > invention of a large-scale quantum computer. As long as the attacker > does not know the PSK and the key derivation algorithm remains > unbroken, the attacker cannot derive the session secrets even if they > are able to compute the (EC)DH shared secret. > > TLS 1.3 key derivation makes use of the HKDF algorithm, which depends > upon the HMAC construction and a hash function. This extension > provides the desired protection for the session secrets as long as > HMAC with the selected hash function is a pseudorandom function (PRF) > [GGM1986]. > > > [GGM1986] Goldreich, O., Goldwasser, S., and S. Micali, "How to > construct random functions", J. ACM 1986 (33), pp. > 792-807, 1986. > > [K2016] Krawczyk, H., "A Unilateral-to-Mutual Authentication > Compiler for Key Exchange (with Applications to Client > Authentication in TLS 1.3)", IACR ePrint 2016/711, August > 2016. > > Russ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000002aba0f05896c42eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
A clarification on the text suggest bel= ow by Russ.

The way I = see it, the external PSK as used in draft-ietf-tls-tls13-cert-with-extern-p= sk is not intended as a means of authentication but as a way of regaining f= orward secrecy in case the (EC)DHE mechanism is ever broken (e.g., by crypt= analysis or by a quantum computer). Indeed, as long as the future attacker = does not learn the PSK and the key derivation remains unbroken (e.g., HMAC = is still a secure PRF (*)), that attacker cannot derive the session secrets= even if it can compute the (EC)DHE value. When looking at the mechanism in= this way, questions like whether this is a PSK-with-ECDHE mechanism with a= dded signatures or a regular 1.5 RTT with added PSK authentication are easi= ly answered. It is a regular 1.5 RTT where a PSK has been added to the key = derivation for the sake of quantum-resistant forward secrecy. In this case,= one should see authentication as fully relying on certificate-based signat= ures. So, even if parties other than the communicating client and server kn= ow the PSK, this endangers the secrecy of PSK and its forward security effe= ct, but not the authenticity of the handshake.

The above is my inter= pretation of the draft based on a superficial reading. I have not studied i= t carefully enough to validate the design or understand the full implicatio= n to TLS 1.3. Yet, it seems that the above conceptual approach may help und= erstanding the goal of the draft and analyzing its security.

(*) The= design of HKDF has as an explicit goal to support the case of secret salt = in HKDF-Extract in which case the security of HKDF relies solely on HMAC be= ing a secure PRF (which is the most studied aspect of HMAC). Using the PSK = as input to the KDF achieves this property.

Hugo

=
On Tue, Ma= y 21, 2019 at 3:46 PM Russ Housley <housley@vigilsec.com> wrote:


> On May 20, 2019, at 8:25 PM, Geoffrey Keating <geoffk@geoffk.org> wrote:
>
> Joseph Salowey <joe@salowey.net> writes:
>
>> The last call has come and gone without any comment.=C2=A0 Please = indicate if
>> you have reviewed the draft even if you do not have issues to rais= e so the
>> chairs can see who has reviewed it.=C2=A0 Also indicate if you hav= e any plans to
>> implement the draft.
>
> I looked at the draft.
>
> My understanding of the draft (and I think it would have helped if it<= br> > contained a diagram showing the resulting TLS handshake) is that it= 9;s
> specifying the existing psk_dhe_ke flow, to which it adds a
> certificate-based signature over the handshake, which it doesn't > specify but works the same way as in RFC 8446 when there is no PSK. >
> This is somewhat confusing because the draft is written as if it
> starts with a certificate-based TLS flow and somehow adds a PSK; it > repeats all the RFC 8446 PSK machinery, but doesn't explain how th= e
> certificate interacts with it, and raises questions like "are the= re
> two DH operations or just one?".=C2=A0 I think the draft could ha= ve been a
> lot shorter.
>
> Conversely, one area where the draft could have been longer would be t= o
> explain how exactly this produces quantum-resistance in the presence > of a secret shared key.=C2=A0 It appears that it relies on the HKDF-Ex= pand
> function being quantum-resistant.=C2=A0 That seems like an important t= hing
> to document, given that we don't have fully functional quantum
> cryptanalysis yet and so don't know exactly what might be
> quantum-resistant or not.
>
> However, once you're past that, the resulting protocol seems quite=
> simple (as an addition to psk_dhe_ke) and I have no objections to it.<= br>
I think that the necessary property is that HKDF reman a PRF.

I suggest the following additions to the Security Considerations:

=C2=A0 If the external PSK is known to any party other than the client and<= br> =C2=A0 the server, then the external PSK MUST NOT be the sole basis for
=C2=A0 authentication.=C2=A0 The reasoning is explained in [K2016] (see
=C2=A0 Section 4.2).=C2=A0 When this extension is used, authentication is b= ased
=C2=A0 on certificates, not the external PSK.

=C2=A0 In this extension, the external PSK regains the forward secrecy if t= he
=C2=A0 (EC)DH key agreement is ever broken by cryptanalysis or the future =C2=A0 invention of a large-scale quantum computer.=C2=A0 As long as the at= tacker
=C2=A0 does not know the PSK and the key derivation algorithm remains
=C2=A0 unbroken, the attacker cannot derive the session secrets even if the= y
=C2=A0 are able to compute the (EC)DH shared secret.

=C2=A0 TLS 1.3 key derivation makes use of the HKDF algorithm, which depend= s
=C2=A0 upon the HMAC construction and a hash function.=C2=A0 This extension=
=C2=A0 provides the desired protection for the session secrets as long as =C2=A0 HMAC with the selected hash function is a pseudorandom function (PRF= )
=C2=A0 [GGM1986].


=C2=A0 [GGM1986]=C2=A0 Goldreich, O., Goldwasser, S., and S. Micali, "= How to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0construct random functions&= quot;, J. ACM 1986 (33), pp.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0792-807, 1986.

=C2=A0 [K2016]=C2=A0 =C2=A0 Krawczyk, H., "A Unilateral-to-Mutual Auth= entication
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Compiler for Key Exchange (= with Applications to Client
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authentication in TLS 1.3)&= quot;, IACR ePrint 2016/711, August
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02016.

Russ

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000002aba0f05896c42eb-- From nobody Wed May 22 10:23:07 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0A44120089 for ; Wed, 22 May 2019 10:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWRaaXSF-7bR for ; Wed, 22 May 2019 10:23:03 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4911120059 for ; Wed, 22 May 2019 10:23:02 -0700 (PDT) Received: from [66.113.192.14] (helo=xsmtp05.mail2web.com) by mx35.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1hTUx9-0002Ik-2u for tls@ietf.org; Wed, 22 May 2019 19:23:00 +0200 Received: from [10.5.2.12] (helo=xmail02.myhosting.com) by xsmtp05.mail2web.com with esmtp (Exim 4.63) (envelope-from ) id 1hTUx2-0001q8-A1 for tls@ietf.org; Wed, 22 May 2019 13:22:54 -0400 Received: (qmail 9665 invoked from network); 22 May 2019 17:22:47 -0000 Received: from unknown (HELO [172.16.0.40]) (Authenticated-user:_huitema@huitema.net@[194.168.27.109]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 22 May 2019 17:22:47 -0000 From: Christian Huitema To: Joseph Salowey , TLS References: <9f82ec83-2776-4de3-6f6d-94df8650c2b7@huitema.net> Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <4b07e2c6-1f26-c09b-d0a2-05c7147782e9@huitema.net> Date: Wed, 22 May 2019 10:22:45 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <9f82ec83-2776-4de3-6f6d-94df8650c2b7@huitema.net> Content-Type: multipart/alternative; boundary="------------2726FCB1731633C9FA7920AE" Content-Language: en-US X-Originating-IP: 66.113.192.14 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.192.14 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.192.14@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: ham X-Spampanel-Outgoing-Evidence: Combined (0.03) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0fbJ1LThpDP3PaEa+mzHFASpSDasLI4SayDByyq9LIhV02R2z3PiVDF2 6XM1gyf22UTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDoOWO0i/H75teRGzF9TgV+efH zJ6mVE7ewsipSVIfs4agEtCbOYYvOlPvOZAn+HDyk4hYVdSH4ilEX20H0GUoaK5W7igYn3BiPC/Q ULfehIyZ3JKVmi72ocgY5kMQSjs7M7F7B+H4BOgiABPpiHhZIYO9VfqOHRAHONTkoyWcypaN9bEz YXQ5Bq54+8sOLcJpXof3r8kfRxpez5OlfYJRQkKHj8GhSvnXG6aqAO+QA5zAmfg+QMjm0Wxe7G4F AAR6avERpop5LF7RavHozgbn9YqgREAoh06jutiTfFzl2G4uss8347yATkLSIXqnQVGKSPZLLSx3 /6BTpL6UXmT8yFSCJlnatpQUVkDyz9+HEa34l0QmPyjhxxYY4z85MF0ZIK/1NH5THMtlYvyHAYGO GlmJIjyKo/pbSDRNIEOEwlMcz873cIRxyN1uC++vIKvC6BczixKau3SVCHUjX//EjwdGlBUgKAML u7sQPYTayDbBSkwfFiqy8SYXtjACFtFXGnzJ7s3eFVZ4C2RdLXH5Zayp/agYZfrnDk8+IFUpab7m 9Ql4Ld7qe/xoNQPgy7UpxcIWHOi9y3yF+Ot2t6dhJc2bXYMFScrLivfWmWkJo22CHZOREywSBAd6 WuRFS3mx7pmoT48k/PN+B8rUfZ1qhnApWvKu8MGVl/WqPa2OphI8CVsONrMJuGzuoGnKTKcymM5H 5NK8ObCxL+Ab3gHeBGp1PWox/HcVwRsYfOuMC9EDvRTWmuYW5XPvbs91Tlwpf5AUf1kCAsFmubjw BGSJFQZlJF8UKGQcpLF8m4y5fNSIlEy3YgJZkOfaaqfw0pD+E4vXmYOrZ6ynPfzK8qbeqosYcSFD ZkSOre2YUe/WyPr4xM5tUrEfL92iWzfzWX2vJeNfaj+DKN82dVVpaMxSGA== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-tls13-cert-with-extern-psk X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 17:23:05 -0000 This is a multi-part message in MIME format. --------------2726FCB1731633C9FA7920AE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Weird. I sent this message this morning, and it did not arrive on the list. On 5/22/2019 1:09 AM, Christian Huitema wrote: > On 5/15/2019 6:20 AM, Joseph Salowey wrote: >> The last call has come and gone without any comment.  Please indicate >> if you have reviewed the draft even if you do not have issues to >> raise so the chairs can see who has reviewed it.  Also indicate if >> you have any plans to implement the draft.  >> >> On Tue, Apr 9, 2019 at 8:51 PM Joseph Salowey > > wrote: >> >> This is the working group last call for the "TLS 1.3 Extension >> for Certificate-based Authentication with an External Pre-Shared >> Key” draft available >> at https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk/. >> Please review the document and send your comments to the list by >> 2359 UTC on 23 April 2019. >> > > My only comment regards the trade-off in this draft between privacy > and resilience. The proposed method uses PSK to provide greater > resilience against quantum-capable attackers, and as Russ says this is > something that the US government cares about. But at the same time, > the use of PSK requires inserting a PSK-ID in the client hello, which > is sent in clear text. So we have a trade-off: government > communications are less likely to be decrypted, but the PSK-ID will > help track government employees. It might make sense to describe the > trade-off explicitly in the draft, maybe in the security section. > > -- Christian Huitema > --------------2726FCB1731633C9FA7920AE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Weird. I sent this message this morning, and it did not arrive on the list.

On 5/22/2019 1:09 AM, Christian Huitema wrote:
On 5/15/2019 6:20 AM, Joseph Salowey wrote:
The last call has come and gone without any comment.  Please indicate if you have reviewed the draft even if you do not have issues to raise so the chairs can see who has reviewed it.  Also indicate if you have any plans to implement the draft. 

On Tue, Apr 9, 2019 at 8:51 PM Joseph Salowey <joe@salowey.net> wrote:
This is the working group last call for the "TLS 1.3 Extension for Certificate-based Authentication with an External Pre-Shared Key” draft available at https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk/. Please review the document and send your comments to the list by 2359 UTC on 23 April 2019.


My only comment regards the trade-off in this draft between privacy and resilience. The proposed method uses PSK to provide greater resilience against quantum-capable attackers, and as Russ says this is something that the US government cares about. But at the same time, the use of PSK requires inserting a PSK-ID in the client hello, which is sent in clear text. So we have a trade-off: government communications are less likely to be decrypted, but the PSK-ID will help track government employees. It might make sense to describe the trade-off explicitly in the draft, maybe in the security section.

-- Christian Huitema

--------------2726FCB1731633C9FA7920AE-- From nobody Wed May 22 11:06:29 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 759431202DA for ; Wed, 22 May 2019 11:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xiHk92JsfbCm for ; Wed, 22 May 2019 11:06:16 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFF00120320 for ; Wed, 22 May 2019 11:06:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 72651300AE1 for ; Wed, 22 May 2019 13:46:46 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id fJaDvSwzYnMr for ; Wed, 22 May 2019 13:46:44 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 55E45300471; Wed, 22 May 2019 13:46:44 -0400 (EDT) From: Russ Housley Message-Id: <9FF3B61C-2EEE-42EC-84CD-615096609DE4@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_9C9AABC8-204A-47C8-92EE-4806281E5FA8" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 22 May 2019 14:06:01 -0400 In-Reply-To: <9f82ec83-2776-4de3-6f6d-94df8650c2b7@huitema.net> Cc: IETF TLS , Joe Salowey To: Christian Huitema References: <9f82ec83-2776-4de3-6f6d-94df8650c2b7@huitema.net> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-tls13-cert-with-extern-psk X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 18:06:28 -0000 --Apple-Mail=_9C9AABC8-204A-47C8-92EE-4806281E5FA8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Christian: > On 5/15/2019 6:20 AM, Joseph Salowey wrote: >> The last call has come and gone without any comment. Please indicate = if you have reviewed the draft even if you do not have issues to raise = so the chairs can see who has reviewed it. Also indicate if you have = any plans to implement the draft.=20 >>=20 >> On Tue, Apr 9, 2019 at 8:51 PM Joseph Salowey > wrote: >> This is the working group last call for the "TLS 1.3 Extension for = Certificate-based Authentication with an External Pre-Shared Key=E2=80=9D = draft available at = https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk= / = . Please review the document and send your comments to the list by = 2359 UTC on 23 April 2019. > My only comment regards the trade-off in this draft between privacy = and resilience. The proposed method uses PSK to provide greater = resilience against quantum-capable attackers, and as Russ says this is = something that the US government cares about. But at the same time, the = use of PSK requires inserting a PSK-ID in the client hello, which is = sent in clear text. So we have a trade-off: government communications = are less likely to be decrypted, but the PSK-ID will help track = government employees. It might make sense to describe the trade-off = explicitly in the draft, maybe in the security section. >=20 I suggest the following additional section for this document: Privacy Considerations Appendix E.6 of [RFC8446] discusses identity exposure attacks on PSKs. The guidance in this section remains relevant. This extension makes use of external PSKs to improve resilience against attackers that gain access to a large-scale quantum computer in the future. This extension is always accompanied by the "pre_shared_key" extension to provide the PSK identities in plaintext in the ClientHello message. Passive observation of the these PSK identities will aid an attacker to track users of this extension. Does that address your comment? Russ --Apple-Mail=_9C9AABC8-204A-47C8-92EE-4806281E5FA8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 =20 =20

Christian:

On 5/15/2019 6:20 AM, Joseph = Salowey wrote:
The last call has come and gone = without any comment.  Please indicate if you have reviewed the draft = even if you do not have issues to raise so the chairs can see who has reviewed it.  Also indicate if you have any plans to implement the draft. 

On Tue, Apr 9, 2019 at = 8:51 PM Joseph Salowey <joe@salowey.net> wrote:
This is the working group last call for the "TLS 1.3 Extension for Certificate-based Authentication with an External Pre-Shared Key=E2=80=9D draft available = at https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with= -extern-psk/. Please review the document and send your comments to the list by 2359 UTC on 23 April = 2019.

My only comment regards the trade-off in this draft between privacy and resilience. The proposed method uses PSK to provide greater resilience against quantum-capable attackers, and as Russ says this is something that the US government cares about. But at the same time, the use of PSK requires inserting a PSK-ID in the client hello, which is sent in clear text. So we have a trade-off: government communications are less likely to be decrypted, but the PSK-ID will help track government employees. It might make sense to describe the trade-off explicitly in the draft, maybe in the security = section.


I suggest the following additional = section for this document:

  = Privacy Considerations

   Appendix E.6 of [RFC8446] discusses identity = exposure attacks on
   PSKs.  The guidance in this section remains = relevant.

   This extension makes use of external PSKs to = improve resilience
   against attackers that gain access to a = large-scale quantum computer
   in the future.  This = extension is always accompanied by the
   "pre_shared_key" extension = to provide the PSK identities in plaintext
   in the ClientHello message. =  Passive observation of the these PSK
   identities will aid an = attacker to track users of this extension.

Does that address your = comment?

Russ

= --Apple-Mail=_9C9AABC8-204A-47C8-92EE-4806281E5FA8-- From nobody Thu May 23 13:56:37 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0B291200BA for ; Thu, 23 May 2019 13:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KUVDAAGXlxHf for ; Thu, 23 May 2019 13:56:32 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9FD5120020 for ; Thu, 23 May 2019 13:56:31 -0700 (PDT) Received: from [66.113.192.14] (helo=xsmtp04.mail2web.com) by mx61.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1hTulI-0004oD-KD for tls@ietf.org; Thu, 23 May 2019 22:56:30 +0200 Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp04.mail2web.com with esmtp (Exim 4.63) (envelope-from ) id 1hTulC-0002Jc-3r for tls@ietf.org; Thu, 23 May 2019 16:56:23 -0400 Received: (qmail 466 invoked from network); 23 May 2019 20:56:17 -0000 Received: from unknown (HELO [172.16.0.187]) (Authenticated-user:_huitema@huitema.net@[194.168.27.109]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 23 May 2019 20:56:16 -0000 To: Russ Housley Cc: IETF TLS , Joe Salowey References: <9f82ec83-2776-4de3-6f6d-94df8650c2b7@huitema.net> <9FF3B61C-2EEE-42EC-84CD-615096609DE4@vigilsec.com> From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <797055dd-15ac-53e8-4024-b3b3191fc7bc@huitema.net> Date: Thu, 23 May 2019 13:56:12 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <9FF3B61C-2EEE-42EC-84CD-615096609DE4@vigilsec.com> Content-Type: multipart/alternative; boundary="------------35B6C461B29BA322E868EE58" Content-Language: en-US X-Originating-IP: 66.113.192.14 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.192.14 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.192.14@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: ham X-Spampanel-Outgoing-Evidence: Combined (0.07) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0fbJ1LThpDP3PaEa+mzHFASpSDasLI4SayDByyq9LIhVz+GLSW3dLsi4 gfIipNTAQ0TNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDoOWO0i/H75teRGzF9TgV+efH zJ6mVE7ewsipSVIfs4arLY/uFp/SWrst5APmQNCyk4hYVdSH4ilEX20H0GUoaFpDrbUoFLnouvTs 61dA7MqZ3JKVmi72ocgY5kMQSjs7M7F7B+H4BOgiABPpiHhZIYO9VfqOHRAHONTkoyWcypaN9bEz YXQ5Bq54+8sOLcJpXof3r8kfRxpez5OlfYJRQkKHj8GhSvnXG6aqAO+QA5zAmfg+QMjm0Wxe7G4F AAR6avERpop5LF7RavHozgbn9YqgREAoh06jutiTfFzl2G4uss8347yATkLSIXqnQVGKSPZLLSx3 /6BTpL6UXmT8yFSCJlnatpQUVkDyz9+HEa34l0QmPyjhxxYY4z85MF0ZIK/1NH5THMtlYvyHAYGO GlmJIjyKo/pbSDRNIEOEwlMcz873cIRxyN1uC++vIKvC6PXxe2Gv17u0wqODRfOs3ui5SOqBSIci sDhvTZZ3UNA0ZK4tidpoeTbzFS//kyqYX0cxHiikldnEhneXee2OH4lkqscAyrkBm40BZdkty3fL EDK8hX5Mjj3K6v45KP9rHGWcfOjtTSOQwERm6qbTgncW4cIAGcb2cNTwDakbhAiw/i9M01ZUff8x GCyJrXM9z+ovG3e5b1xe16jgiakdFm1FaMSuGkF3ElAHy1sj37By2DNwOgV373pfDhBQ21Od3MUB FzOaGm9hK+fonV+pbSyKx2dXkl2oCrRQgdySoHDTVEM4ypmhD+J8YYFIP3hxCDRZgQnFYkq0SOLr mvxpF7Ozr+HlBNv4rXAGTFZjslUYQV5S2tL01oGmO4has73rVGkGolmtL78gKYrUH0FYKQ9Pgug7 9YBnmeXEg9rPBx23byv3CjhKpQiDxiH2EAzSjxi6dtTjIuf/XjLzh/HKpg== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-tls13-cert-with-extern-psk X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 20:56:35 -0000 This is a multi-part message in MIME format. --------------35B6C461B29BA322E868EE58 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 5/22/2019 11:06 AM, Russ Housley wrote: > > Christian: > >> On 5/15/2019 6:20 AM, Joseph Salowey wrote: >>> The last call has come and gone without any comment.  Please >>> indicate if you have reviewed the draft even if you do not have >>> issues to raise so the chairs can see who has reviewed it.  Also >>> indicate if you have any plans to implement the draft.  >>> >>> On Tue, Apr 9, 2019 at 8:51 PM Joseph Salowey >> > wrote: >>> >>> This is the working group last call for the "TLS 1.3 Extension >>> for Certificate-based Authentication with an External Pre-Shared >>> Key” draft available >>> at https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk/. >>> Please review the document and send your comments to the list by >>> 2359 UTC on 23 April 2019. >>> >> My only comment regards the trade-off in this draft between privacy >> and resilience. The proposed method uses PSK to provide greater >> resilience against quantum-capable attackers, and as Russ says this >> is something that the US government cares about. But at the same >> time, the use of PSK requires inserting a PSK-ID in the client hello, >> which is sent in clear text. So we have a trade-off: government >> communications are less likely to be decrypted, but the PSK-ID will >> help track government employees. It might make sense to describe the >> trade-off explicitly in the draft, maybe in the security section. >> > > I suggest the following additional section for this document: > >   Privacy Considerations > >    Appendix E.6 of [RFC8446] discusses identity exposure attacks on >    PSKs.  The guidance in this section remains relevant. > >    This extension makes use of external PSKs to improve resilience >    against attackers that gain access to a large-scale quantum computer >    in the future.  This extension is always accompanied by the >    "pre_shared_key" extension to provide the PSK identities in plaintext >    in the ClientHello message.  Passive observation of the these PSK >    identities will aid an attacker to track users of this extension. > > Does that address your comment? Yes, although "passive observation will help" is somewhat more benign than what I would have written. If the "government employee" is some agent in a foreign country, they may want to think twice before using the proposed option. Or alternatively, you may want a solution in which the PSK-ID is randomized using some ESNI-like process. -- Christian Huitema --------------35B6C461B29BA322E868EE58 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 5/22/2019 11:06 AM, Russ Housley wrote:

Christian:

On 5/15/2019 6:20 AM, Joseph Salowey wrote:
The last call has come and gone without any comment.  Please indicate if you have reviewed the draft even if you do not have issues to raise so the chairs can see who has reviewed it.  Also indicate if you have any plans to implement the draft. 

On Tue, Apr 9, 2019 at 8:51 PM Joseph Salowey <joe@salowey.net> wrote:
This is the working group last call for the "TLS 1.3 Extension for Certificate-based Authentication with an External Pre-Shared Key” draft available at https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk/. Please review the document and send your comments to the list by 2359 UTC on 23 April 2019.

My only comment regards the trade-off in this draft between privacy and resilience. The proposed method uses PSK to provide greater resilience against quantum-capable attackers, and as Russ says this is something that the US government cares about. But at the same time, the use of PSK requires inserting a PSK-ID in the client hello, which is sent in clear text. So we have a trade-off: government communications are less likely to be decrypted, but the PSK-ID will help track government employees. It might make sense to describe the trade-off explicitly in the draft, maybe in the security section.


I suggest the following additional section for this document:

  Privacy Considerations

   Appendix E.6 of [RFC8446] discusses identity exposure attacks on
   PSKs.  The guidance in this section remains relevant.

   This extension makes use of external PSKs to improve resilience
   against attackers that gain access to a large-scale quantum computer
   in the future.  This extension is always accompanied by the
   "pre_shared_key" extension to provide the PSK identities in plaintext
   in the ClientHello message.  Passive observation of the these PSK
   identities will aid an attacker to track users of this extension.

Does that address your comment?

Yes, although "passive observation will help" is somewhat more benign than what I would have written. If the "government employee" is some agent in a foreign country, they may want to think twice before using the proposed option. Or alternatively, you may want a solution in which the PSK-ID is randomized using some ESNI-like process.

-- Christian Huitema

--------------35B6C461B29BA322E868EE58-- From nobody Wed May 29 12:51:42 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45BEA12001B for ; Wed, 29 May 2019 12:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3BcZf_ZkzzW7 for ; Wed, 29 May 2019 12:51:36 -0700 (PDT) Received: from mail-it1-x132.google.com (mail-it1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2049A120125 for ; Wed, 29 May 2019 12:51:36 -0700 (PDT) Received: by mail-it1-x132.google.com with SMTP id m3so6049854itl.1 for ; Wed, 29 May 2019 12:51:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mbaz9opo0OXaGxKRAqoSRcIh0vOFntda8gH8dJpYi28=; b=K1VN0dvvTfXc9e8/AgCJ9qTfEHDRtyPN8bk5qGpiTFODijkSDfuxrlFWzRS/8ji4CV RvwR9COFwdNge+0XUIM6+z1hEYyXMVivRSLn0C+Q+ex52uCuPGBguGIN0vOErGJ2yh2n jHIyC3dikp5aG/hz7Y01vwHRDWDulhSOB9UJaDiKdfH/UzFH/9jYY8/tZKvizI9VR5xM Y2Oj0x6tTIZJ52//nw16AHaa8lJPd+BpXjxnDA3+h3FWJfkQUhnDr3c7SaD6KuxdA1yW OneYMqnzLG9oKd9hHvFWGtAHdx56fV1jOb00ww0P4DkL7/QDKVLjcoHx8tnlLFV7BGTj 7GLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mbaz9opo0OXaGxKRAqoSRcIh0vOFntda8gH8dJpYi28=; b=Myaq+WavEzGNI1XOMIuuzxZaPHP4Q7MUUZFfF9SB7Vuv5UxMGKZ+mgSZceLWwyJpY2 owyaGdvZsXK753Rf0tR8giB/qv/nx1Sib144+kLYYYZ22WPSZrNxvohmd9sskgI50iEj F2im0KfcUZE0Tm0pxn6zE1ouP2lRWaWPj4JXPgAvBvenfknDthYE0PyKBV6JJkRDEDed 6av/lBJ6uZitnlim74Ry5dy2FF/95WjAxZ6jm62NlQolkB7Txxv41yIP6e5uE+mHtNWB 13t4Sxwdeqspoay7B2FFg6+hICd9FBMTF7EaOrJSM9a1sJXC0gYX/OWaKHK7XJGStazT AQjA== X-Gm-Message-State: APjAAAWaQAK8hspcqtHAPSqaQ7cf+iHYPESdCKmTbjykmir8+wc/eGFY iYkjl0zYdigkcw9n0G6kl847K0oxApHj66ZmR2M= X-Google-Smtp-Source: APXvYqxkAGQ/bBeCgyUHy2Puf4n1UVb+WqEfn/AjhgvUief3YAJXsJqOS11p19JaMMZZLEJxIZV+XahqJPkIhxjVbKU= X-Received: by 2002:a24:eec1:: with SMTP id b184mr9298155iti.61.1559159495361; Wed, 29 May 2019 12:51:35 -0700 (PDT) MIME-Version: 1.0 References: <2977635.mFCBgFvPmQ@pintsize.usersys.redhat.com> <10904461.vh6UM9T2du@pintsize.usersys.redhat.com> In-Reply-To: <10904461.vh6UM9T2du@pintsize.usersys.redhat.com> From: Loganaden Velvindron Date: Wed, 29 May 2019 23:51:24 +0400 Message-ID: To: Hubert Kario Cc: "" , Martin Thomson Content-Type: multipart/alternative; boundary="000000000000de8927058a0c1b83" Archived-At: Subject: Re: [TLS] Proposal to deprecate sha1 and md5 for digital signatures in TLS 1.2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 19:51:40 -0000 --000000000000de8927058a0c1b83 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, May 14, 2019 at 10:57 PM Hubert Kario wrote: > On Tuesday, 14 May 2019 20:16:17 CEST Loganaden Velvindron wrote: > > On Tue, May 14, 2019 at 3:24 PM Hubert Kario wrote: > > > On Tuesday, 14 May 2019 08:34:38 CEST Loganaden Velvindron wrote: > > > > Latest draft is here: > > > > > https://www.ietf.org/id/draft-lvelvindron-tls-md5-sha1-deprecate-04.txt > > > > > > why did you drop SHA-1 from Section 4 and 5? > > > > It was done following this comment from David Cooper. > > > > " > > [..] While they may be subject to collision attacks, SHA-1 is still > > considered secure in cases in which collision resistance is not require= d, > > and I do not believe that collision resistance is required when SHA-1 i= s > > used to create the "signatures" in the ServerKeyExchange and > > CertificateVerify messages. > > " > > SLOTH paper disagrees on that as far as CertificateVerify message is > concerned > > SP 800-52 rev-2 does not provide much in terms of justification why SLOTH > paper would be wrong and allows for SHA-1 signatures only in TLS 1.0 and > TLS > 1.1, it does not explicitly state that SHA-1 signatures in TLS 1.2 are > allowed... > Hello All, We've updated the document based on the feedback we've got: We've re-added deprecating sha-1 in ServerKeyExchange and CertificateVerify= : https://tools.ietf.org/html/draft-lvelvindron-tls-md5-sha1-deprecate-05 --=20 > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --000000000000de8927058a0c1b83 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, May 14, 2019 at 10:57 PM Hube= rt Kario <hkario@redhat.com>= wrote:
On Tuesd= ay, 14 May 2019 20:16:17 CEST Loganaden Velvindron wrote:
> On Tue, May 14, 2019 at 3:24 PM Hubert Kario <hkario@redhat.com> wrote:
> > On Tuesday, 14 May 2019 08:34:38 CEST Loganaden Velvindron wrote:=
> > > Latest draft is here:
> > > https://www.ie= tf.org/id/draft-lvelvindron-tls-md5-sha1-deprecate-04.txt
> >
> > why did you drop SHA-1 from Section 4 and 5?
>
> It was done following this comment from David Cooper.
>
> "
> [..] While they may be subject to collision attacks, SHA-1 is still > considered secure in cases in which collision resistance is not requir= ed,
> and I do not believe that collision resistance is required when SHA-1 = is
> used to create the "signatures" in the ServerKeyExchange and=
> CertificateVerify messages.
> "

SLOTH paper disagrees on that as far as CertificateVerify message is concer= ned

SP 800-52 rev-2 does not provide much in terms of justification why SLOTH <= br> paper would be wrong and allows for SHA-1 signatures only in TLS 1.0 and TL= S
1.1, it does not explicitly state that SHA-1 signatures in TLS 1.2 are
allowed...

Hello All,

We've updated the document based on the feedback we've got:=

We've re-added deprecating sha-1 in ServerKey= Exchange and CertificateVerify:

--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00=C2=A0 Brno, Czech Republic=
--000000000000de8927058a0c1b83-- From nobody Thu May 30 20:26:52 2019 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BDA5212001A; Thu, 30 May 2019 20:26:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: kaduk@mit.edu, tls-chairs@ietf.org, joe@salowey.net, tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155927320969.13412.6181605390918285890.idtracker@ietfa.amsl.com> Date: Thu, 30 May 2019 20:26:49 -0700 Archived-At: Subject: [TLS] tls - New Meeting Session Request for IETF 105 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list 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 May 2019 03:26:50 -0000 A new meeting session request has just been submitted by Joseph A. Salowey, a Chair of the tls working group. --------------------------------------------------------- Working Group Name: Transport Layer Security Area Name: Security Area Session Requester: Joseph Salowey Number of Sessions: 2 Length of Session(s): 2 Hours, 1 Hour Number of Attendees: 120 Conflicts to Avoid: First Priority: teep taps suit secdispatch saag stir rtcweb quic perc mls httpbis dnsop tokbind dispatch curdle cfrg acme uta git Second Priority: dprive ace Third Priority: tcpinc lamps sidrops People who must be present: Eric Rescorla Rich Salz Sean Turner Joseph A. Salowey Yoav Nir Benjamin Kaduk Christopher A. Wood Nick Sullivan Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri May 31 12:26:45 2019 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A892A1200FA; Fri, 31 May 2019 12:26:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tls@ietf.org Message-ID: <155933080362.6454.10888785403345021219@ietfa.amsl.com> Date: Fri, 31 May 2019 12:26:43 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-tls13-cert-with-extern-psk-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list 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 May 2019 19:26:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : TLS 1.3 Extension for Certificate-based Authentication with an External Pre-Shared Key Author : Russ Housley Filename : draft-ietf-tls-tls13-cert-with-extern-psk-02.txt Pages : 12 Date : 2019-05-31 Abstract: This document specifies a TLS 1.3 extension that allows a server to authenticate with a combination of a certificate and an external pre- shared key (PSK). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-tls13-cert-with-extern-psk-02 https://datatracker.ietf.org/doc/html/draft-ietf-tls-tls13-cert-with-extern-psk-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-tls13-cert-with-extern-psk-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 31 12:37:37 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 941611200F4 for ; Fri, 31 May 2019 12:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IwiLMwVfOVUf for ; Fri, 31 May 2019 12:37:33 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5786120096 for ; Fri, 31 May 2019 12:37:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id B7909300AB7 for ; Fri, 31 May 2019 15:18:15 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id q-QYKa2HmYTV for ; Fri, 31 May 2019 15:18:14 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 6EE8D300471 for ; Fri, 31 May 2019 15:18:14 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 31 May 2019 15:37:30 -0400 References: <155933080362.6454.10888785403345021219@ietfa.amsl.com> To: IETF TLS In-Reply-To: <155933080362.6454.10888785403345021219@ietfa.amsl.com> Message-Id: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-tls13-cert-with-extern-psk-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 19:37:35 -0000 I made the updates based on the discussion that came after the WG Last = Call: Section 5: the external PSK can be known to parties other than the = client and server. Section 7: Addition of 5 paragraphs about the reason it is okay for the = external PSK can be known to parties other than the client and server, = and also the need for HKDF to be a PRF to obtain quantum resistance. Section 8: Added the privacy considerations. Section 9: Added more people to Acknowledgements. Section 10: Added [GGM1986] and [K2016] as informational references. Russ > On May 31, 2019, at 3:26 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Transport Layer Security WG of the = IETF. >=20 > Title : TLS 1.3 Extension for Certificate-based = Authentication with an External Pre-Shared Key > Author : Russ Housley > Filename : = draft-ietf-tls-tls13-cert-with-extern-psk-02.txt > Pages : 12 > Date : 2019-05-31 >=20 > Abstract: > This document specifies a TLS 1.3 extension that allows a server to > authenticate with a combination of a certificate and an external = pre- > shared key (PSK). >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk= / >=20 > There are also htmlized versions available at: > = https://tools.ietf.org/html/draft-ietf-tls-tls13-cert-with-extern-psk-02 > = https://datatracker.ietf.org/doc/html/draft-ietf-tls-tls13-cert-with-exter= n-psk-02 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-tls13-cert-with-extern-= psk-02 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 31 14:31:51 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71CF4120058 for ; Fri, 31 May 2019 14:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OIEn8vmh0IEQ for ; Fri, 31 May 2019 14:31:47 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [198.0.208.83]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CDE8120041 for ; Fri, 31 May 2019 14:31:47 -0700 (PDT) Received: from [10.0.1.6] (c-73-170-252-126.hsd1.ca.comcast.net [73.170.252.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by dragaera.releasedominatrix.com (Postfix) with ESMTP id 4E77633D012; Fri, 31 May 2019 21:31:46 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Geoff Keating In-Reply-To: Date: Fri, 31 May 2019 14:31:44 -0700 Cc: Russ Housley , IETF TLS Content-Transfer-Encoding: quoted-printable Message-Id: References: <171CD4CD-BB93-4F96-AD75-97EBA3540A92@vigilsec.com> To: Hugo Krawczyk X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-tls13-cert-with-extern-psk X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 21:31:50 -0000 > On 21 May 2019, at 2:08 pm, Hugo Krawczyk = wrote: >=20 > A clarification on the text suggest below by Russ. >=20 > The way I see it, the external PSK as used in = draft-ietf-tls-tls13-cert-with-extern-psk is not intended as a means of = authentication but as a way of regaining forward secrecy in case the = (EC)DHE mechanism is ever broken (e.g., by cryptanalysis or by a quantum = computer). It=E2=80=99s a bit problematic if the expected use of the draft is with = quantum-resistant certificates, because TLS doesn=E2=80=99t support = those yet. If that=E2=80=99s the intent, shouldn=E2=80=99t the draft say something = like "The server MUST choose a quantum-resistant algorithm when = considering those listed in signature_algorithms_cert and/or = signature_algorithms. The client MUST supply at least one = quantum-resistant algorithm in signature_algorithms, and in = signature_algorithms_cert if present.=E2=80=9D ? But that makes it = unimplementable until such an algorithm is specified...= From nobody Fri May 31 14:59:19 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4791F120114 for ; Fri, 31 May 2019 14:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.196 X-Spam-Level: X-Spam-Status: No, score=-4.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPIlYea8dgjf for ; Fri, 31 May 2019 14:59:16 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D03812011C for ; Fri, 31 May 2019 14:59:15 -0700 (PDT) Received: from LLE2K16-MBX03.mitll.ad.local (LLE2K16-MBX03.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTPS id x4VLx6nc026701; Fri, 31 May 2019 17:59:12 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: Geoff Keating , IETF TLS Thread-Topic: [TLS] WGLC for draft-ietf-tls-tls13-cert-with-extern-psk Thread-Index: AQHU71Dl4FuLhOFUaEet5GHjTbcLfaZspnEAgAiVf4CAAUQmgIAAFw2AgA+9xQD//8SPgA== Date: Fri, 31 May 2019 21:59:00 +0000 Message-ID: References: <171CD4CD-BB93-4F96-AD75-97EBA3540A92@vigilsec.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.18.0.190414 x-originating-ip: [172.25.1.90] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3642170340_1667773171" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-31_15:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905310133 Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-tls13-cert-with-extern-psk X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 21:59:18 -0000 --B_3642170340_1667773171 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable On 5/31/2019, 17:34, "TLS on behalf of Geoff Keating" wrote: >> On 21 May 2019, at 2:08 pm, Hugo Krawczyk w= rote: >>=20 >> A clarification on the text suggest below by Russ. >>=20 >> The way I see it, the external PSK as used in draft-ietf-tls-tls13-c= ert-with-extern-psk is not intended as >> a means of authentication but as a way of regaining forward secrecy = in case the (EC)DHE mechanism >> is ever broken (e.g., by cryptanalysis or by a quantum computer). > > It=E2=80=99s a bit problematic if the expected use of the draft is with qu= antum-resistant > certificates... This is not the intent/expected use.=20 =20 The intent is to protect the content of the session against being recorded = now and decrypted later. In short, no problem. --B_3642170340_1667773171 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUfQYJKoZIhvcNAQcCoIIUbjCCFGoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghJDMIIE8zCCA9ugAwIBAgITWQADhvrZHqbUs3XjIgAAAAOG+jANBgkqhkiG9w0BAQsF ADBRMQswCQYDVQQGEwJVUzEfMB0GA1UECgwWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoG A1UECwwDUEtJMRMwEQYDVQQDDApNSVRMTCBDQS01MB4XDTE5MDEwODE0MjgyMloXDTIyMDEw NzE0MjgyMlowYTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRv cnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRtVpCB2qzc1ia4sI2Dq+YEUHS29Ca pM5d0jBAdvQgFnXmTe4Ur0onMJkqYpatbmJAKl9lHMYDMvwemI3DG+0ebyXkVan3lPbawoba Zy7yQzAPvbQ/KSqemihH1SrGp3jF522kmW8o64wzHGaZRgo4LK8xO2TiwdebuBLA+MUh6NqS 3hBVPZ3xb9nVynJ5EIq8XWb/LYpfvgovs5kUL1m1Cl62NQ8+lW6qEUMfgmgY/Sx5DR9Uo9mC DS4IurVXijIK5E4NhYDmkI6KhxgnB0A2iyD/afGlqiIXs2dfOK28smGfFry9HEO5O8n1JI+5 QdzkBce3h/P3i5VE1zCOaF9RAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUhatfAqb0g782Agbd cbDwogD9b+MwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFC/vu8YNHbvpav6sZ/MHOwh2 9ktZMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvbGxj YTUwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUv Z2V0dG8vbGxjYTUwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9 BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+K cwIBZAIBCDAiBgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAZBgNVHREEEjAQ gQ51cmlAbGwubWl0LmVkdTAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMCcGCSsGAQQBgjcU AgQaHhgATABMAFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBACRKYQxz VfdiOo93iNBw7krEv7svK30nqiiMQhPDEuSTUcLUyvEeBT29w+vKil/y6TQ/0LDoKAB0zH+k YPKanaWec44CLyccDyEqUqdIy+GC24JTnGldjc+9sUgKrNWB7dP6pU7jc8o1KC3XJr1al8gf F3qIGk3A0r2zZK8/dOfAGKbDLJAxw5uMwYjqQA61Qt8H428AKVEluGGgNxwGRwt3E8mPmDD2 cr4bl3b2rZTZNRTha8kvsvgh/u1SWfFWutPi26pIsXiJ10ysySW6qeZ2WNPnyIwKFdrvt4W0 AJc2CtcJCZrkfHjkHWARI/JDPln9ZdzxDGYOrpOXDbO40SgwggTAMIIDqKADAgECAgEGMA0G CSqGSIb3DQEBCwUAMFYxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJv cmF0b3J5MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD01JVExMIFJvb3QgQ0EtMjAeFw0xNzAz MDIxMjAwMDBaFw0yNjAzMDIyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKDBZNSVQg TGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLDANQS0kxEzARBgNVBAMMCk1JVExMIENBLTUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCnmoMOvTkfw7nq19mrWazGaa+Q83Uv 0+ATXT3q6kr+WExIMIZ87C74WCcRXpvO7uvx7HvMsYWAFHW93wQwhjytxHIOZgKNJ4VnGVDU l+KI7g0n9+Zjt3hB3HhHbcvbe9+Y4jz+XzCiLl2OaYvICKbxvbBSCLtPEeZQ6x6Tb6EK0ym0 gvYeHO3kuuY+SJHJMltbrLnIVLxjZrNVS77zXKvu6Q3hSdkRIB7kJgEXfL+p/z/2p94bEEZ2 TnQz0TkOjG+Jq7UlXlFRtvsYcDPEQD3UNkZsWcXgC1hXG8TGknUcAhlGxVhlKlFLmNd7342s eGy2s9YxNDnSE+eXTtb0I5LLAgMBAAGjggGcMIIBmDASBgNVHRMBAf8ECDAGAQH/AgEAMB0G A1UdDgQWBBQv77vGDR276Wr+rGfzBzsIdvZLWTAfBgNVHSMEGDAWgBT/ycllTFOA8akMPCGu girH7vgy+zAOBgNVHQ8BAf8EBAMCAYYwZwYIKwYBBQUHAQEEWzBZMC4GCCsGAQUFBzAChiJo dHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExSQ0EyMCcGCCsGAQUFBzABhhtodHRwOi8v b2NzcC5sbC5taXQuZWR1L29jc3AwNAYDVR0fBC0wKzApoCegJYYjaHR0cDovL2NybC5sbC5t aXQuZWR1L2dldGNybC9MTFJDQTIwgZIGA1UdIASBijCBhzANBgsqhkiG9xICAQMBBjANBgsq hkiG9xICAQMBCDANBgsqhkiG9xICAQMBBzANBgsqhkiG9xICAQMBCTANBgsqhkiG9xICAQMB CjANBgsqhkiG9xICAQMBCzANBgsqhkiG9xICAQMBDjANBgsqhkiG9xICAQMBDzANBgsqhkiG 9xICAQMBEDANBgkqhkiG9w0BAQsFAAOCAQEAMJYRwLPJ91K7e2mA2Nj10W0o5JMHYkaa+ctL 8/xY8QzIHFI5Ij+iydpPN9KCYn/4Sy80T3aNoYkFlS0GRQXhf0nsiY7TWJwAKw4AiO/yJ37/ oRKRgtyRicvaJ6RjlHCXBOalFLw9UtpodP4/idC51lxzsolaQZraBjVe7PL95PhS7D+22Nff InzLdIb1DBf54NwOVfPIgABtxH1fhZrja7EhR9RoUw5E1O6iWaAuP/xWhSTQFWlhyA0/kkIi 9/HXaY0hYnhcjcbPPqjpyfIhSFjjXhjqK7t2wPrSrBFLFUbnLiNlgQHrvNYF5IqgIfnSBWIr m3rfLhpZZJ/xJ7Yf6DCCA4owggJyoAMCAQICAQEwDQYJKoZIhvcNAQELBQAwVjELMAkGA1UE BhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEY MBYGA1UEAxMPTUlUTEwgUm9vdCBDQS0yMB4XDTE2MDQyMDEyMDAwMFoXDTM1MDQxOTIzNTk1 OVowVjELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAK BgNVBAsTA1BLSTEYMBYGA1UEAxMPTUlUTEwgUm9vdCBDQS0yMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAv3WoBEGOOJtm4ucvaf6vKIFPs8watCd6Smwq/XeRNo7P3jPIxNPw F398RGDUmPJIXA7idzD6j0opFIW+kLqYye9e788PV0dqaJlX8818fNDbSE+8B6hieqKTR7Vf OI74UVQEUKVRFuRFw6uVYuvgew2Tj/C2dEee37eruQl5nHkbV2OsWnZ7O+yt+etd6HRcaXLl P9q8WKgA3B7vkOVIMCKoAuaWj+BFq7K+WNkiyi/KdOH9JmOpbyRK4jcA7xbLnF8JFUSNg5c4 Y1BJrFaZtkCeG6Nm9p524GllkRFzPgpj8VicV+AK+9rY07dTx02kYotTnKuy0YxBAwsUXxAQ EwIDAQABo2MwYTAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBT/ycllTFOA8akMPCGugirH 7vgy+zAfBgNVHSMEGDAWgBT/ycllTFOA8akMPCGugirH7vgy+zAOBgNVHQ8BAf8EBAMCAYYw DQYJKoZIhvcNAQELBQADggEBAHqYfEf/3J5aMKhlYQ0PnUAbMB8jZSr9/HvjfOF00crFUCfS rqG8JQwo+S/iq66gcp62FEgJ0fQkDgVg6m+C2ETo1LoWiSxhYCfcSIQECljlXwR8wFSayF82 2S69IqvHhdq4d58jU6gYi6ssjU4vwsvsVLRJKk/m/Cg/w8gW6YHM5ahBD6/5Ccel2fI7oSms kO991+otrC11YfDwCFvz7Am0r+K9iVhSWta4hmIuV0YBia07eZKSO02LPgQ8YOz3ku0Yt+mh 8VWRKux2CcYjMpk+WDV0BMp75tqb6pqBFkcKvEBXqxg+8+G/umjii4H0c5kvJhaQyykbmOKm xO9IcJIwggT2MIID3qADAgECAhNZAAA7OX5fo0OiIK0RAAAAADs5MA0GCSqGSIb3DQEBCwUA MFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKDBZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYD VQQLDANQS0kxEzARBgNVBAMMCk1JVExMIENBLTUwHhcNMTgwODI4MjE0NTI5WhcNMjEwODI3 MjE0NTI5WjBhMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9y eTEPMA0GA1UECxMGUGVvcGxlMSAwHgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAI5Vc19RKc/69lmwhogDOjjzPQbmc8s6 Z6rzP6oUHAswDICqZWwPt+FTbKr0YTAqRNsTEN4YiW0fORK+fNRvClo0pdiCqj3DwDQZLRI4 Dak1yTsUtVe35oomQbXtO+0A0L/CowYri/UKeRG1i1/0cXSf4mAx0ed9wh2SordAb8o2FuOU 0B2ppnqjro1VFugHHX6QOggaeLFOprT5gnTZUmqM37/d4DGB9XDdTQi144zQSwSWKkaUThsy D9CHSRNcB79HBvlZGSM+BkIbayPdhQAuz4yKsOZEWPx/6LnMotzBevSswnCDf+u9ajCgMnje WbrZRN+xoYEuhycXyK2b8/MCAwEAAaOCAbUwggGxMB0GA1UdDgQWBBTZUpq7Rsccv42yU9UQ 4wvojOl4pzAOBgNVHQ8BAf8EBAMCBSAwHwYDVR0jBBgwFoAUL++7xg0du+lq/qxn8wc7CHb2 S1kwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybC9sbGNh NTBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVkdS9n ZXR0by9sbGNhNTAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3NwMD0G CSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXr0HCD6+0g AgFkAgEJMCUGA1UdJQQeMBwGBFUdJQAGCCsGAQUFBwMEBgorBgEEAYI3CgMEMBkGA1UdEQQS MBCBDnVyaUBsbC5taXQuZWR1MBgGA1UdIAQRMA8wDQYLKoZIhvcSAgEDAQgwJwYJKwYBBAGC NxQCBBoeGABMAEwAVQBzAGUAcgBFAG4AYwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEACyN6 Yhi9LApOPpf60ypSV2WmV3sqnrsrdlPTW+am4wMK/M/5PZmt5jFVtXaErkWYdrbMdjeo2o/G 9N2DnrFOhz7kDYM9HC9AH/rWCfoSkI/C2N6Rq/uDnRJfao61wyv37qKtanNdkp+reyLxdVPn foVrD/VZli4UV28u4XBuYDkjXPyyiH+bb395FnxOtTA3Uz41Ohpdvr6oLPEuy0IP4MPfK5wD mS6GXcB+ze9sYEp+DJxE7WAbkW5Y536WPl/rfWm/k6ZC1KPVSRM7mS+atk44VOgzPLXkl6Tu 6zY8tMczfr5F0om1JfN8G50s4QDUGtsMgzW+LXVDhFD24xnUojGCAf4wggH6AgEBMGgwUTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoMFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsM A1BLSTETMBEGA1UEAwwKTUlUTEwgQ0EtNQITWQADhvrZHqbUs3XjIgAAAAOG+jANBglghkgB ZQMEAgEFAKBpMC8GCSqGSIb3DQEJBDEiBCDJqJEN5HvLdp4alNCqx5CiY5C1qNY10KOAbAxg IApXWjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xOTA1MzEy MTU5MDBaMA0GCSqGSIb3DQEBAQUABIIBAC+3TozNS7rrqFrNLntwF4DO5GtQSJtl6bZ6yxbD hte6euo+rKH1FFGacsCGp/Q+BGRcZFQiZ4Dj5128lYc8t+2+Y+c9beQ2xuQjoi7aVfoQYEfz WDGN9lSoWr3U9qxPZCYHN8/Rl8Hm+ozm5Pj9daN/c2pasQojGdaji9gStudWze2j2LmvoW5x G1Lh9hLbpHjl2MMphoL5wS+gXJnioAbGbtgg6IRzCSF11HSm6lVEXkaBBbnqwPb9qTK4He99 Hn6nqv+aFdt1MrDz9kwx1QB4A8iVG2AjlvAs8u/b3hvPBHrMXOXwlcHn0+gKIYGU22BJ8BIF cWVglTBba8xgDIc= --B_3642170340_1667773171-- From nobody Fri May 31 15:11:14 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46CD21200FF for ; Fri, 31 May 2019 15:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4nxbayeq-gF for ; Fri, 31 May 2019 15:11:12 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7B9F12004D for ; Fri, 31 May 2019 15:11:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id A002D300AAB for ; Fri, 31 May 2019 17:51:53 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id jFSiOiQti9OW for ; Fri, 31 May 2019 17:51:52 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 4165E3000D6; Fri, 31 May 2019 17:51:52 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: Date: Fri, 31 May 2019 18:11:08 -0400 Cc: Hugo Krawczyk , IETF TLS Content-Transfer-Encoding: quoted-printable Message-Id: <25104BB6-CC8A-4575-A308-0B712A855320@vigilsec.com> References: <171CD4CD-BB93-4F96-AD75-97EBA3540A92@vigilsec.com> To: Geoff Keating X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-tls13-cert-with-extern-psk X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 May 2019 22:11:13 -0000 > On May 31, 2019, at 5:31 PM, Geoff Keating wrote: >=20 >=20 >=20 >> On 21 May 2019, at 2:08 pm, Hugo Krawczyk = wrote: >>=20 >> A clarification on the text suggest below by Russ. >>=20 >> The way I see it, the external PSK as used in = draft-ietf-tls-tls13-cert-with-extern-psk is not intended as a means of = authentication but as a way of regaining forward secrecy in case the = (EC)DHE mechanism is ever broken (e.g., by cryptanalysis or by a quantum = computer). >=20 > It=E2=80=99s a bit problematic if the expected use of the draft is = with quantum-resistant certificates, because TLS doesn=E2=80=99t support = those yet. That is not the way I read Hugo's note, and that is certainly not called = for by this draft. Quite the opposite. Russ