From nobody Fri Jun 2 09:51:02 2017 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E8269126579; Fri, 2 Jun 2017 09:51:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.52.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149642226089.31851.17116126246404213590@ietfa.amsl.com> Date: Fri, 02 Jun 2017 09:51:00 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-cms-eddsa-signatures-06.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 16:51:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : Use of EdDSA Signatures in the Cryptographic Message Syntax (CMS) Author : Russ Housley Filename : draft-ietf-curdle-cms-eddsa-signatures-06.txt Pages : 8 Date : 2017-06-02 Abstract: This document specifies the conventions for using Edwards-curve Digital Signature Algorithm (EdDSA) for curve25519 and curve448 in the Cryptographic Message Syntax (CMS). For each curve, EdDSA defines the PureEdDSA and HashEdDSA modes. However, the HashEdDSA mode is not used with the CMS. In addition, no context string is used with the CMS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-eddsa-signatures/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-cms-eddsa-signatures-06 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-cms-eddsa-signatures-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-cms-eddsa-signatures-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 2 09:52:09 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99AB8126E64 for ; Fri, 2 Jun 2017 09:52: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, 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 x_lGs7WQ6uz0 for ; Fri, 2 Jun 2017 09:52:06 -0700 (PDT) Received: from mail.smeinc.net (x-bolt-wan.smeinc.net [209.135.219.146]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94F98126CE8 for ; Fri, 2 Jun 2017 09:52:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id B6B1B30058F for ; Fri, 2 Jun 2017 12:52:05 -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 47Tu8suCvAzw for ; Fri, 2 Jun 2017 12:52:04 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 0A75A30054B; Fri, 2 Jun 2017 12:52:04 -0400 (EDT) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_9FB61BD1-37B2-4806-9AF3-411A1DB24E80" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 2 Jun 2017 12:52:03 -0400 References: <149642226116.31851.74626701815316204.idtracker@ietfa.amsl.com> Cc: curdle To: Eric Rescorla Message-Id: <2A911F08-1C7F-42A6-B829-D905F125F65F@vigilsec.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] New Version Notification for draft-ietf-curdle-cms-eddsa-signatures-06.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 16:52:09 -0000 --Apple-Mail=_9FB61BD1-37B2-4806-9AF3-411A1DB24E80 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I think this is ready for IETF Last Call. Russ > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-ietf-curdle-cms-eddsa-signatures-06.txt > Date: June 2, 2017 at 12:51:01 PM EDT > To: "Russ Housley" >=20 >=20 > A new version of I-D, draft-ietf-curdle-cms-eddsa-signatures-06.txt > has been successfully submitted by Russ Housley and posted to the > IETF repository. >=20 > Name: draft-ietf-curdle-cms-eddsa-signatures > Revision: 06 > Title: Use of EdDSA Signatures in the Cryptographic = Message Syntax (CMS) > Document date: 2017-06-02 > Group: curdle > Pages: 8 > URL: = https://www.ietf.org/internet-drafts/draft-ietf-curdle-cms-eddsa-signature= s-06.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-eddsa-signatures/ > Htmlized: = https://tools.ietf.org/html/draft-ietf-curdle-cms-eddsa-signatures-06 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-curdle-cms-eddsa-signatur= es-06 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-curdle-cms-eddsa-signatures= -06 >=20 > Abstract: > This document specifies the conventions for using Edwards-curve > Digital Signature Algorithm (EdDSA) for curve25519 and curve448 in > the Cryptographic Message Syntax (CMS). For each curve, EdDSA > defines the PureEdDSA and HashEdDSA modes. However, the HashEdDSA > mode is not used with the CMS. In addition, no context string is > used with the CMS. >=20 >=20 >=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 > The IETF Secretariat >=20 --Apple-Mail=_9FB61BD1-37B2-4806-9AF3-411A1DB24E80 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I think this is ready for IETF Last Call.

Russ



Begin = forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-ietf-curdle-cms-eddsa-signatures-06.txt
Date: = June 2, 2017 at 12:51:01 PM = EDT
To: = "Russ Housley" <housley@vigilsec.com>


A new version = of I-D, draft-ietf-curdle-cms-eddsa-signatures-06.txt
has = been successfully submitted by Russ Housley and posted to the
IETF repository.

Name: = draft-ietf-curdle-cms-eddsa-signatures
Revision: 06
Title:= = Use of EdDSA Signatures in the Cryptographic Message Syntax = (CMS)
Document date: 2017-06-02
Group:= = curdle
Pages: 8
URL: =            https://www.ietf.org/internet-drafts/draft-ietf-curdle-cms-edds= a-signatures-06.txt
Status: =         https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-eddsa-si= gnatures/
Htmlized: =       https://tools.ietf.org/html/draft-ietf-curdle-cms-eddsa-signatu= res-06
Htmlized: =       https://datatracker.ietf.org/doc/html/draft-ietf-curdle-cms-edd= sa-signatures-06
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-curdle-cms-eddsa= -signatures-06

Abstract:
=   This document specifies the conventions for using = Edwards-curve
  Digital Signature Algorithm = (EdDSA) for curve25519 and curve448 in
  the = Cryptographic Message Syntax (CMS).  For each curve, EdDSA
  defines the PureEdDSA and HashEdDSA modes. =  However, the HashEdDSA
  mode is not used = with the CMS.  In addition, no context string is
=   used with the CMS.




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

The IETF Secretariat


= --Apple-Mail=_9FB61BD1-37B2-4806-9AF3-411A1DB24E80-- From nobody Fri Jun 2 10:06:37 2017 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 587A212762F; Fri, 2 Jun 2017 10:06:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.52.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149642319630.31903.6438106270107096729@ietfa.amsl.com> Date: Fri, 02 Jun 2017 10:06:36 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-cms-ecdh-new-curves-08.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 17:06:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : Use of the Elliptic Curve Diffie-Hellman Key Agreement Algorithm with X25519 and X448 in the Cryptographic Message Syntax (CMS) Author : Russ Housley Filename : draft-ietf-curdle-cms-ecdh-new-curves-08.txt Pages : 16 Date : 2017-06-02 Abstract: This document describes the conventions for using Elliptic Curve Diffie-Hellman (ECDH) key agreement algorithm using curve25519 and curve448 in the Cryptographic Message Syntax (CMS). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-ecdh-new-curves/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-cms-ecdh-new-curves-08 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-cms-ecdh-new-curves-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-cms-ecdh-new-curves-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 2 10:10:23 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41EF4126557 for ; Fri, 2 Jun 2017 10:10:21 -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 n667DaKdPIfK for ; Fri, 2 Jun 2017 10:10:20 -0700 (PDT) Received: from mail.smeinc.net (x-bolt-wan.smeinc.net [209.135.219.146]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4AAC1205F0 for ; Fri, 2 Jun 2017 10:10:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id F37FA300580 for ; Fri, 2 Jun 2017 13:10:18 -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 hb_PxZy9Uz7t for ; Fri, 2 Jun 2017 13:10:17 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id C98DC3004CA for ; Fri, 2 Jun 2017 13:10:17 -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 10.3 \(3273\)) Date: Fri, 2 Jun 2017 13:10:17 -0400 References: <149642319630.31903.6438106270107096729@ietfa.amsl.com> To: curdle In-Reply-To: <149642319630.31903.6438106270107096729@ietfa.amsl.com> Message-Id: <5DC14923-656A-40C6-8A7F-3C88B77E4F49@vigilsec.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-cms-ecdh-new-curves-08.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 17:10:21 -0000 I believe this update addresses the IETF Last Call comments. Please let = me know if I missed any. Russ > On Jun 2, 2017, at 1:06 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 CURves, Deprecating and a Little more = Encryption of the IETF. >=20 > Title : Use of the Elliptic Curve Diffie-Hellman Key = Agreement Algorithm with X25519 and X448 in the Cryptographic Message = Syntax (CMS) > Author : Russ Housley > Filename : draft-ietf-curdle-cms-ecdh-new-curves-08.txt > Pages : 16 > Date : 2017-06-02 >=20 > Abstract: > This document describes the conventions for using Elliptic Curve > Diffie-Hellman (ECDH) key agreement algorithm using curve25519 and > curve448 in the Cryptographic Message Syntax (CMS). >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-ecdh-new-curves/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-curdle-cms-ecdh-new-curves-08 > = https://datatracker.ietf.org/doc/html/draft-ietf-curdle-cms-ecdh-new-curve= s-08 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-curdle-cms-ecdh-new-curves-= 08 >=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 Jun 2 13:39:49 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04629127B5A for ; Fri, 2 Jun 2017 13:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, 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=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 evIv51sFh0Af for ; Fri, 2 Jun 2017 13:39:46 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::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 34720127869 for ; Fri, 2 Jun 2017 13:39:46 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id o83so558727lff.3 for ; Fri, 02 Jun 2017 13:39:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=IPc0hEZgWgKDVNuSaAeJ1GANbg8iQwB5oBXT5YSzsE8=; b=TcrZF7qJrVJbAS6kLxu52kNFkiTMvzIEzcSzKHdz8JH9TxVSFi7VR9tE4NcJ4AcGxQ QRoHa3RPxwAXjJVyEEExF5epDtU9BOQ4rcx90vxszRWKezoth6yyFy6flp7NVSDCjRgj IqAXUI7DzgPkoAAujskkxBvUW/s5H5f+FjDhW7Cu1vRkgtTFKHRZURg6JwlWRdZ7r4yI vG5bj7CiW5NtsYotXlXpisu/24MXTqaUdn7jg0N/kZgMvwOKkYst2EF5k5cHjQRvXLa+ Pz4U9F7c4y0AX4y5Zt9QbNDRpqg0U/SOZNc8ZoL/cSXpLmI3tu7GMDm4sRwEA+eEojGv YiyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=IPc0hEZgWgKDVNuSaAeJ1GANbg8iQwB5oBXT5YSzsE8=; b=KuVxRb7PiR8R7Xtz57oEuFZd5n1jKoS+RJnFqjOQdKyB7RSRU4hMSPk8fr29VVsx47 7aoGCALL9FVHc5Xs26FpEYtUCf4AX0+lfGzEwkdKyJHvDcfhsTf7XmNaJsSnvhYM2KuV WDtGwqDdPrOs+AZxqsw3YlXyQh6pPontPEP2JXyFfh6KTu1tY+oFN595SBfXUKZ6opkx uiOmVzyY4GOkPRn0RMOP/TYOGVW6ju5JQE5FjGFihFDNaZaYM8znkGN2FE9RNLo4QPSe GPMSvKT+BDKt8Elgs3hBOOnxU/d3LlC0I9Eay8wFQzrfGcqfh/xNUsLfc7egX0LDJbYg nnFg== X-Gm-Message-State: AODbwcBQTUnlzLx48C7cEmIqJcW3bgTru/+gKkuBALcgbTeGB578LUqK 1at41QYZ2kmlI/C35nqiO0cTcV4/YEfw X-Received: by 10.25.20.38 with SMTP id k38mr1036981lfi.142.1496435983522; Fri, 02 Jun 2017 13:39:43 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.0.14 with HTTP; Fri, 2 Jun 2017 13:39:43 -0700 (PDT) From: Daniel Migault Date: Fri, 2 Jun 2017 16:39:43 -0400 X-Google-Sender-Auth: tOcWNmbA1laWM3SiX6DHzOFeb_E Message-ID: To: curdle Content-Type: multipart/alternative; boundary="001a114067b43a21700551002731" Archived-At: Subject: [Curdle] WGLC draft-schaad-curdle-oid-registry X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 20:39:48 -0000 --001a114067b43a21700551002731 Content-Type: text/plain; charset="UTF-8" Hi, This email starts a WGLC for draft-schaad-curdle-oid-registry[1]. The draft received significant comments during the WG adoption and is expected to be close to its final version. Please provide your feed backs by June 16. Yours, Rich and Daniel [1] https://datatracker.ietf.org/doc/draft-schaad-curdle-oid-registry/ --001a114067b43a21700551002731 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

This email starts a WGLC for draft-schaad-curd= le-oid-registry[1]. The draft received significant comments during the WG a= doption and is expected to be close to its final version. Please provide yo= ur feed backs by June 16.

Yours,
Ric= h and Daniel
--001a114067b43a21700551002731-- From nobody Fri Jun 2 13:41:55 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19BAF129BE8 for ; Fri, 2 Jun 2017 13:41:54 -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 ozlzfOTyGSMB for ; Fri, 2 Jun 2017 13:41:52 -0700 (PDT) Received: from mail.smeinc.net (x-bolt-wan.smeinc.net [209.135.219.146]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57DE4127869 for ; Fri, 2 Jun 2017 13:41:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C0FA2300541 for ; Fri, 2 Jun 2017 16:41: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 qvpQd44TnSEk for ; Fri, 2 Jun 2017 16:41:50 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 1C410300265; Fri, 2 Jun 2017 16:41:50 -0400 (EDT) From: Russ Housley Message-Id: <6B06F5B2-B8A9-47FD-B53F-77B27DF45077@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_419BD2AC-1C2A-47CE-B49A-BA3B26D3638F" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 2 Jun 2017 16:41:49 -0400 In-Reply-To: Cc: curdle To: Daniel Migault References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] WGLC draft-schaad-curdle-oid-registry X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 20:41:54 -0000 --Apple-Mail=_419BD2AC-1C2A-47CE-B49A-BA3B26D3638F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The comments that I made have been addressed, and I think the document = is ready for publication. Russ > On Jun 2, 2017, at 4:39 PM, Daniel Migault = wrote: >=20 > Hi,=20 >=20 > This email starts a WGLC for draft-schaad-curdle-oid-registry[1]. The = draft received significant comments during the WG adoption and is = expected to be close to its final version. Please provide your feed = backs by June 16.=20 >=20 > Yours,=20 > Rich and Daniel=20 >=20 > [1] https://datatracker.ietf.org/doc/draft-schaad-curdle-oid-registry/ = >=20 --Apple-Mail=_419BD2AC-1C2A-47CE-B49A-BA3B26D3638F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii The comments that I made have been addressed, and I think the = document is ready for publication.

Russ


On Jun 2, 2017, at 4:39 PM, = Daniel Migault <daniel.migault@ericsson.com> wrote:

Hi,

This email starts a WGLC = for draft-schaad-curdle-oid-registry[1]. The draft received significant = comments during the WG adoption and is expected to be close to its final = version. Please provide your feed backs by June 16.

Yours,
Rich and Daniel

[1] https://datatracker.ietf.org/doc/draft-schaad-curdle-oid-regist= ry/


= --Apple-Mail=_419BD2AC-1C2A-47CE-B49A-BA3B26D3638F-- From nobody Fri Jun 2 15:18:47 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC87F129422 for ; Fri, 2 Jun 2017 15:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.802 X-Spam-Level: X-Spam-Status: No, score=-4.802 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPxzoq5GSuT5 for ; Fri, 2 Jun 2017 15:18:44 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0118.outbound.protection.outlook.com [104.47.36.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCD96129418 for ; Fri, 2 Jun 2017 15:18:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=tsXMI5lF6OHg6N0ZzKqy+iX63v159/pIfoWE3QHQRbA=; b=dUkgwhH/iIWtXNLeiOephUzM0RzjyHDm2OE0sHmWHz+FRwbUP2cRCK1DKbP7lfWaE/J4mN0HCcNSg4gKYvLQQigOif7UBjebU5AfeFpRpTlbdPCLzRRqBdbbwL2QrZPkxyovcmGWEoCBqIYfMdre+TtjPQpl3+tHRLrGUxOjx/k= Received: from DM5PR05CA0025.namprd05.prod.outlook.com (10.174.188.142) by BLUPR05MB1970.namprd05.prod.outlook.com (10.162.224.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1157.3; Fri, 2 Jun 2017 22:18:42 +0000 Received: from BY2NAM05FT021.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e52::204) by DM5PR05CA0025.outlook.office365.com (2603:10b6:4:39::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1157.3 via Frontend Transport; Fri, 2 Jun 2017 22:18:42 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; ericsson.com; dkim=none (message not signed) header.d=none;ericsson.com; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by BY2NAM05FT021.mail.protection.outlook.com (10.152.100.158) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1075.12 via Frontend Transport; Fri, 2 Jun 2017 22:18:41 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 2 Jun 2017 15:18:40 -0700 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v52MIeSc005051; Fri, 2 Jun 2017 15:18:40 -0700 (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id 68BB51141B; Fri, 2 Jun 2017 15:18:39 -0700 (PDT) To: Daniel Migault CC: curdle In-Reply-To: References: Comments: In-reply-to: Daniel Migault message dated "Fri, 02 Jun 2017 16:39:43 -0400." From: "Mark D. Baushke" Date: Fri, 2 Jun 2017 15:18:39 -0700 Message-ID: <8023.1496441919@eng-mail01.juniper.net> Sender: MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39450400003)(39400400002)(39410400002)(39860400002)(39840400002)(2980300002)(199003)(189002)(9170700003)(6266002)(38730400002)(47776003)(53936002)(7126002)(8676002)(7846003)(356003)(6246003)(5660300001)(55016002)(2906002)(6392003)(305945005)(6916009)(53416004)(2950100002)(478600001)(76176999)(7696004)(50466002)(50986999)(230783001)(76506005)(54356999)(86362001)(8936002)(189998001)(5003940100001)(106466001)(81166006)(229853002)(4326008)(110136004)(77096006)(117636001)(2810700001)(105596002)(558084003)(48376002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB1970; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM05FT021; 1:HBLEFt4kQHuRQKJ31kUEP2TwwR1dZdiMVmbBlEhC5/hH+IGfX32loAg/0H4FfjgXjjznbjvG72zT+jlfIe0crEJ4KsXaTF+uMH7dS8EccdcZRqY1ZDmexLy8tC98azsJZw2p0RF779QZDvbm4eI4shr3BcfMngYIk+ub4pvlckTNdduWfi8OZT3HYCKLLsgnT0kD3YjNdCeqxx6TAjCX1mj7LIRtAibr603tstvd+siHwQH2b9RrMJAswnQ2490B8pu3WIeXX53TBFQBUHx7IR2/rF3xzs/gjol9V4dYnsXodtcKkIGJimh3QAmF2y7eqeE8hOG1g7nE/Sw3XWboZ+Pu1dZnMFJOvnHbOZWmh3ogWktWZKdCe3iqFKVmegCl3akywvxpm04hgwbpYILa9wn0MkR1kSy1IUTxoo1A7EhFr1tJTonZVKyZjHSAUJ8r6VuDKTyc1G918zdcGoFlSDzqZf3fIhBJsFJjJc/9usbs/hVsJ8RU3VboY1T8LDtgnh+oS48hM5IwJzzqtLi7lRJ2/3anY5gGif/i/wA/sBM= X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BLUPR05MB1970: X-MS-Office365-Filtering-Correlation-Id: 8314a578-76e4-4f5b-8621-08d4aa055373 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:BLUPR05MB1970; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB1970; 3:2/9zqhmzyDFsY863IoT/5Fy8WKNkRJdaYKqU/a18cCmUL4eC81TtPgYwbY1xStTeaaWwfqHkaoPXqbaaoddEoTzu9zNdwdwrRWCOn45icMTpMtvmziLdpRnJaXYXQzdmbostxuJ0AMF+2TyMKpnHNFz7sS+QckDd70Jo1CCzEFLng0uCpSCyqzXmneUPiG89TxeVeZIY3NgwFdf26L05dP8gbPiEhkTOTBPGiHnzZGCu+dlQKPOeG5JHARYrd3SW7YbK5bsRfY1YvaYDW2olPkVRA80ry6OchU4ZGyx3ougup0QMWDc2mIik6xU56Nyp24mWZvqsgYySwyKEzUcHoev3mToGGcSrU9nVNE7i7hYwYG4dZXVRIBcAiV+BA+TmM0IMbASCXJu9hVVzaLBBTAgDDVwM4Hu1WTNhdqeV+VcEy98YWBMkkcpQ0QQlaJum+WptcGBVDVomlBPOWYUbMKxQAUPNdUq1cg2RcSaS9wvjeBOhR7yWG3rkENDsBAGw X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB1970; 25:2yA9neKloa7HnzV7S+3xD8jB1T8/i9lvHgmikT9uF/nOH2C08qRoqaH4fwwt2YEIvDOSu/sMyBrY7/jDbZ/+qQDL0BBbbjlqbNa918iwuFXT8NhoTpXJJ/skaxbZ8SzLi3Bc17lzOjgrVLDLX0N5L9Sj4NV5TTb4lYptNIe6DHoSdZRKM4Q2cqyy49SG/PHSiW13a68Z6DwyPazC9GZGyu0TnOuaiYzzm7vaG/FUo2oXWXPGCiwzn4wcLY0BfD7cICOpTKF0Qavnx+2c4kNHMNoRszhTXTRMVR0sWrahfEtLRkGK/3Sx2iCzUbOVaLXzgB3EP4AC1eQK3D+OC98X8x45WavKfs3+4wCU+91Nhe00HoK2X60ZYmF+vH8ajydG+K2mTuelmdyrHvE2zw3HajMVigkjxCuneEAD4boOad9KEo5AWsm8sPY4IqJV3QbHQSrci6v7IlLCSQmAyW1DZrfUzvKOlIqYvuTcNexuYgk=; 31:XHHlNqeNBxmn9HuypPpwFE9jHNNT4CyBcAofcOlRuaYV33mUg1fpdXPzaLkZsGRPvI+BxYghYmvaSNrXwFv2/Ull9mTHoexMMq0TewItzN1jsz5tX119YXJzKsGhkyCt+Mb57Ikz/U4QdDmOZ8IQRKWF6S+tM9ePX0Pa+EziA8zETPFO6BCnjffBUF8tVB02YU7k4x8oiUd35Duf65c1+RRQ0PWrVJju2nymW2Zc4Gv25vwaVx0BBFX2cBOgqQIFcXDjyIbwG1yYPyx+VZbLLw== X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB1970; 20:KyXDgDaMNP/JW+FXtj36ha3HLaspFTJ8RWp+wvxmMj0kmHAXYcTMVUh7NZvxp8VNhChokpdb/cF2x3o3KeQT9lJEamib2A8zozM1YoFwLIAyrPBfUbICz++65WG86OSvd3DwzeZcrlkHgNKlUH3D+VFoHmpyRgF9YHTetqWf2vzHwW2gf20cgPwQagvmd0OjcGS3gNeDRIFjwckIhZBhYl94vRyvPwrQlPNY/pv/Y31LXfnEAuXYMlQBBDDWE5k4CrN4kCSG+bJfpdeEuc/BT61DfSLLMDwgRxu0bR3Bu+AGWCYtiwLsDawpFsvrROmVPQztFiNlxngIGUIUnaD4EYPk4uLL20vfLoqLI8A94ER+CSco6gnnDa22qAIs7MxsGwXRAWgCsYb0qAAVjEp+4iHL3cPhMObw7/CGF0Ur2cTRBiGq8ddw4SNYBSzZ4tkeaQQR2NPvm9xPokIuH2VUBGuuWn/DOVvhJG4SpdQoM/0UqleWu8ejepj5T4DBPtwU X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(13018025)(13016025)(5005006)(3002001)(100000703101)(100105400095)(93006095)(93003095)(10201501046)(6055026)(6041248)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR05MB1970; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR05MB1970; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR05MB1970; 4:TZMRbJbC90Yi+OAlfy21QOwkmfjxbgW5whmQh29XTB?= =?us-ascii?Q?9mbl/kh9Io2a8GJXjtF+p1ctwKTZzRDCROkclEATDSor7TSKHTzfGDRvch+E?= =?us-ascii?Q?ENpeqoWKpasMYi5Sr+1ixYSjV/TrbSC7ohviEQ1NoOZVGFrNAm/XBlSR71ir?= =?us-ascii?Q?Puzt74RUQsPbYO3pRKwNvHUvu1l5jJt5jJBsb7CaiNymfvXj6/vB4NjpYdZm?= =?us-ascii?Q?XtcPAGQc1z+oT4OYA03t5diPy9sL5iMUnaDSxEzBDdkmdroLlsspU6F/odss?= =?us-ascii?Q?OSJTH6zLC+UgVFOUHkVQEmP+UWEzwb9vXWYvRVDGmXr/L3tT0B7ZhoC/2taW?= =?us-ascii?Q?nqtbCSsvWvU1o5fUtWBmOCS5CkZDH8etakbXvPV6dhvKLv0w2qZ7Jvb/UPHA?= =?us-ascii?Q?dkeARaxLbE7Tklv6Qa4Sy+5+R3FC+RsfZKj0oiMBO9xBWOr7TDe0iACJHXuc?= =?us-ascii?Q?k0JwRpTLvA1JFO8H4zEnasHtU8IXX3dbAIJrvMPTARwLU0+jyTmLbU19d3Fs?= =?us-ascii?Q?r6q4aaPQ6goBKXxgEyR1e7Tj4jE5Y+QUcQQQoH2si/pu/hylWZGLbadsomaz?= =?us-ascii?Q?bWfKdHWP7hs1/xxjZyVyWlPFAyeAWc+NGUaM9r1CHdjargxFaBIRTEhtLuGZ?= =?us-ascii?Q?G65VnCOXSRtsY5X5ykW9lMo2xXzVy9fUAp8ri/NeTizthPQiuMnKDRoTmtH2?= =?us-ascii?Q?1OqII/UngFm8r8aHPkumDAwQ99YjeC4pxkLKwP4BrOFojw6NbqUqF8GyHklC?= =?us-ascii?Q?CQG19WBMZnYGdKg+ZYJsY80XOoNmaH4zuGKSaUSsuO3MEWZRqjvKYeuqyizH?= =?us-ascii?Q?ctsrwnOFq+IFWOyc32a7xXbIo6jzslR26OzJthCoD9VRpNsY/omI0GZbxAU+?= =?us-ascii?Q?LFPasun8X8o+oE4OxvmHiipdlifBiSX15DCNhjSXfPGWZYAZn08hGusAB96A?= =?us-ascii?Q?7H7O6qUoNsYJsojcXk/SKu0GfEr3ANrK953fc/Jtm6/qSbLQRqiv4gfKin5L?= =?us-ascii?Q?fe5ffRSvq+zf9cVTaQapnJYe6NO5plcYESZXD/zADyX0iwM7RZCSuIJTH6nA?= =?us-ascii?Q?3lhFk9iMLVcrr53fmyVEoA1LbBQUn+MwRh2Ayce1VG0yf/K582pKC2cFTOw8?= =?us-ascii?Q?nxybt52IHsDvFyKXfTZ7qjCFFaJOLZVaKfYnWJyOHFD2DQCLZj3tZOCvtXr7?= =?us-ascii?Q?0KW3CGLQaJCcxIICY52GUnhkXI1las4Y+H?= X-Forefront-PRVS: 03264AEA72 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR05MB1970; 23:tHtKdkc59PcUB8JgkPPwIw/y7hjMdtGPPTXROCMbg?= =?us-ascii?Q?lbr6BTWjRWT12QqJt7WGmQSX4l8hOmIybwjtLWeBXs3zOxMGVQqoksEI1vv7?= =?us-ascii?Q?kQTktP3y5rsycevZfAyQE/sv1Best1lFxa+KbG12C5lmyWa/Z7uRtaz4c7PL?= =?us-ascii?Q?g8l1T2sYdqvUvQDpjYKP7lwaTWbDXvxCpm5TzKBeNHs2dqWc16qfYYQMla6n?= =?us-ascii?Q?RpIfkwIa93qrRWS9ip8j9iWdPV1coBuz+5knh7gsaI2dAA18Z5CPpAly6V42?= =?us-ascii?Q?3WrETWcIM2bpiopK73WC30eCLNJLViHHJuG6QkrPufjiWN8BOv+ajpmSN8Cs?= =?us-ascii?Q?rVonFHC2ntUwnJkxJyhQXrxuQbDUWzoXWnHKp17TmpA9belCxNO1/iJEvFaf?= =?us-ascii?Q?WOiWV6E6I/mfDNyuB02K7vYuepz5MEDcTwhSwIPw2voYN8jXAfyqec5kEdxS?= =?us-ascii?Q?UBOa3++85mM3PiNEl1uC9dXKYHe0v6IhMHjeS+QAV27DZr291F2I811de1QM?= =?us-ascii?Q?0fMUCbKDKQzj3VFyyBRzfqdmtq0mHXvfrIaIuXum0HIwgMJIGwM1Gy8yCyyz?= =?us-ascii?Q?Ctm/FSGvH3DyySWGaN6xVjJz1ZL39GNDFRr23POden4ItgnFxOEGLWGivf4I?= =?us-ascii?Q?gNKI7XV2Uekwuazcyal7NYDMezxaBmv6MLf9+M8tLAeVasBgqBdTw0Y9i2i+?= =?us-ascii?Q?wTS+jRPrZvvSNzSBTBmUCX2oHlcgRiatGOyjhZsowlghuG5fpC5EtM8ymhqe?= =?us-ascii?Q?AO2oG2P3mvyJ7DV2YOhUNJK9ulcJIPseNAk4cbNAarplFrkRxXeqaW/olK8U?= =?us-ascii?Q?xrMv0m2Eowze5L64V32Q6ZeLYFGkmVSa1/S81Zpm/zxVjwEKc91GrYcyh8CJ?= =?us-ascii?Q?v259BLf+NNRbUQjq75JRi8dzlkScJJ2QMh1a9PLXSvy3JuJT+EcsokBfzMmR?= =?us-ascii?Q?A/zDfJ2wB52PURmYSwxugDNqLM9IKoPchLgQPfSmwK5Wok5bXuXyOB6wNRxT?= =?us-ascii?Q?93fUu2GSoYUblgkcaS9XYvuVAK4b95rGpzSPHdbts7YGyfc1ItIfEQLaNq88?= =?us-ascii?Q?Jsb6PyNURY2XtY2ZCflZDu/G5lhor8N1s29s3RRuT+EJnYxyyG1UacFcdm/M?= =?us-ascii?Q?OfQ7Eu3Xq3DINbOUD4FMNFsouDLUWpumBfPxD79CcPrDICNjXFEgWHuVL1DE?= =?us-ascii?Q?zNLP11PHxsjzbrW/4ajHC2yhPKSnX5Vw2ah4Yi8Zdf+qxziX/7BlGMWlJTvg?= =?us-ascii?Q?nwgH0DIJ7R2cRr45nCduphbj3LpFsIqdHnqJz/1ilmH1v0pYhoe+BNUd/IcH?= =?us-ascii?B?dz09?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB1970; 6:Fyh8YNHVgB6jbM5Cj42tV1N62XR6BylWnlj/w7Lzl/XCYMQoRXug9dOMvWKNK2gHKX+XFhoqUHH7Sa0bsKQLABPfXPM3KfHeIAKPZEpLXqqGjts/OnNHE/DSW9Ky2Uxo/qK3eJE3G8d+jIMhJDpGNOJN+ogoNVnvHFKdJYqu/sJrEiwh25NOWLXSxJb8K9plGNfgmHEtp06ZOpZeB5E93YZuTTSwrN4nMYM9APqWXPCOlU3NDC4Vz0s1vOFagqvtKzWhPAIPwAGMMVWJvEucgLiAUEREQYBb18QeUC5N9uS+WNZkiBKJI69lDYdQRtnjRUfeoZ3idtSm2BjJv1+bTvJD3dwajZgM5rsCOHT6CpNUE9eOc+5ZvtiPRPCTOacUYcOXudjcJ/boXl0q5/ybFN4Rg+/xMgMBSid78WPEdsyRZj6DhV1+H/0gvJ6SeK7Lk4T2kfZk9R24WbvrgQc27pPULPZ20veLsJWQ353/Wp7bwcypSqO5K7GraDNwLg3kpQFSzlepm1c3eAwCbmVbu73ac5PCnjqIa1XwSz7rIpM= X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB1970; 5:jOVRjxVZqduM5WzuaMRkGDX++/6ZIMnfoY4pG2DWpFZw1cCYYV4IwYKflWwxyknp97leUJ/MwRRCASVre+uU8+BBbZGzBzuRAXaoeyPV+MpjyApdgR3x/0etUMbsYOKqzdlum+ctKlNfAi+NvgqW+082FNL4O0+NcCMwsReYQxyilWwJATF2sSUGYRyFZPgifwdeMemBo/Zeb5Er+/pSS3L9vgntClbF4O4wSfUKJ0rCSx5vbFOBWeUSqTPDBMjIDIEhV1emNGZm87MMD66tJq5BdI+D4W7RVM3oeublHCUGrdfi/IZNY0M5ImeBvphm4I4QfUtvARvC+26Cftx6G2o+dgiYEp3GCn6Eh+2XfZAUGosvYDOaHyvxUzNcKYqS6viVhlfcH3dk8L+Y8B7UUd31MXZ7oNSv8q7B2W3B1IzMxK/sWI0NlRyttTDq8n6NsFicYDZTykGoMr7gD1cUmA2558SO+tt/Q0r94MBqvVenNI/tE89VJo+eyBRo6Si4; 24:LvqzYh6buSdyn+PpXJeye4vOBOA9+stQiZKgAqz8FQR2oSrz+rEFiBxQr67skHOld/PhHtBejIQ/XEQBdF867IZeAFGe7PI1Xa6jBKbNO4g= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB1970; 7:YFpRBVuGUAb0RujTsgvEwpER+RWJSxXbV78c39ZpD9H4G6pJn3vEx3+R6iTDlSIaaxWLACO7IJYZGxpWYPEREszx6BybbL1GfKj5jO3dqWgndKFaNuWxCiWX6pAtBg69Z4bBeZ6Os5pYnh4QGyo/y/4jlncNYtg1lEdSkxJonqlT8VvC5K01tCPD0ecSXbL7qWzc2HzUNNaIfWtM54SRHn8CRjendJkejR9oSjO1rdfrT6WcXTBoAhw/pzdXmYTpgvjCTBQYnAB0zWHS33beeFtAty2duduAu205L3awRPDsOfYBdYDcL1vozL8VjZjWDBGePPkDiVSRF6oKrtHgoQ== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Jun 2017 22:18:41.4838 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.12]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB1970 Archived-At: Subject: Re: [Curdle] WGLC draft-schaad-curdle-oid-registry X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 22:18:46 -0000 The comments that I made for draft-schaad-curdle-oid-registry have been addressed, and I think the document is ready for publication. -- Mark From nobody Sat Jun 3 06:48:44 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF4A5128ACA for ; Sat, 3 Jun 2017 06:48:42 -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 (1024-bit key) header.d=sn3rd.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 2as4j1HrYUTG for ; Sat, 3 Jun 2017 06:48:41 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::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 15EE912E034 for ; Sat, 3 Jun 2017 06:48:41 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id r63so42451925itc.1 for ; Sat, 03 Jun 2017 06:48:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WGqMwB0BinLlyQbDTXOIoGC1AcssPjRuojc56cQCQVg=; b=hjl6MBZb+3+94DqZyX1c38qfz3JH5tAolYrE05r4A+7m6DnKwd+RhxDyY2ip5niwAr bwc9S8QqJ38kUxfNl7qIv/5/shUrEjODxb+YzzHuSgL4iWNHLWY9huCP20lsNY3dZtRo Y6BIhjVwVSjF0uOFQKgHy7eZpFcOPMdKbRcgw= 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=WGqMwB0BinLlyQbDTXOIoGC1AcssPjRuojc56cQCQVg=; b=Jwfl5wJ1NnVIBuN8+mTEj3SnF4wJ4frOQJVYo4CFUbW4x8NB3N6GvunFHIar4y0Z33 GcpvI/vSscI1ianVqTR1eB9HAoKUBsM/pPnGgofk7velsQfemLmQxv7cB/EZ0i4I4EmY xymJekzV6sFndbVObwk3vc3MQ12hWAre2d+ZhGee2AN7bKCpz1o5ccPDdpTte7wBb9ed 1yXEsLqz0PA/vYFVm3NHzINnYpAKkvWUWkw7ZBgJMG1pjKsXrLJZqB6Dwa06YR47EfEK v01ClJnZvvRCCPuF7iqGlfUxPzQI2tduqGHqxBro2v41ACPPT5SSWFDf5l+cQ1Ik8kcX EznA== X-Gm-Message-State: AODbwcDhYYydvpzzaCtesumHksB4yCgiM7i023pNgRXyXdTwufYElGAp ELd+x7zfcUp5lKwy X-Received: by 10.36.82.85 with SMTP id d82mr4325591itb.13.1496497720401; Sat, 03 Jun 2017 06:48:40 -0700 (PDT) Received: from [5.5.33.180] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id o125sm11311703ioo.21.2017.06.03.06.48.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 03 Jun 2017 06:48:39 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sean Turner In-Reply-To: Date: Sat, 3 Jun 2017 09:48:37 -0400 Cc: curdle Content-Transfer-Encoding: quoted-printable Message-Id: <3895FA29-6856-4024-955F-D8C0CBADF42A@sn3rd.com> References: To: Daniel Migault X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] WGLC draft-schaad-curdle-oid-registry X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 13:48:43 -0000 I hadn=E2=80=99t read it before, but it does what it says it=E2=80=99s = going to do and it=E2=80=99s pretty darn short and straight forward. = Ship it! spt > On Jun 2, 2017, at 16:39, Daniel Migault = wrote: >=20 > Hi,=20 >=20 > This email starts a WGLC for draft-schaad-curdle-oid-registry[1]. The = draft received significant comments during the WG adoption and is = expected to be close to its final version. Please provide your feed = backs by June 16.=20 >=20 > Yours,=20 > Rich and Daniel=20 >=20 > [1] https://datatracker.ietf.org/doc/draft-schaad-curdle-oid-registry/ > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Sat Jun 3 07:20:37 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2183A129B95 for ; Sat, 3 Jun 2017 07:20:33 -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 8v9-mKSoK6OJ for ; Sat, 3 Jun 2017 07:20:29 -0700 (PDT) Received: from mail.smeinc.net (x-bolt-wan.smeinc.net [209.135.219.146]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34ED2129BCE for ; Sat, 3 Jun 2017 07:20:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 7475C300564 for ; Sat, 3 Jun 2017 10:20:28 -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 6-VEYyEEfVtN for ; Sat, 3 Jun 2017 10:20:27 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 5F1AD3004B7; Sat, 3 Jun 2017 10:20:27 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <1496143890.7897.6.camel@redhat.com> Date: Sat, 3 Jun 2017 10:20:26 -0400 Cc: curdle@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <1496143890.7897.6.camel@redhat.com> To: Nikos Mavrogiannopoulos X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] test vectors for draft-ietf-curdle-cms-eddsa-signatures-05 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 14:20:33 -0000 I am working with Jim Schaad to produce some test vectors. They may do = in a separate document; something similar to RFC4134. Russ > On May 30, 2017, at 7:31 AM, Nikos Mavrogiannopoulos = wrote: >=20 > Hi, > The latest draft-ietf-curdle-cms-eddsa-signatures-05 does not contain > any test structures with eddsa signed data. While the text seems > sufficiently precise to implement that, I think it is a good practice > to include test vectors in an appendix similarly to draft-ietf-curdle- > pkix-04. >=20 > regards, > Nikos >=20 From nobody Sun Jun 4 06:54:01 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA95B129515 for ; Sun, 4 Jun 2017 06:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, 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 ecCYUVkFwg0o for ; Sun, 4 Jun 2017 06:53:59 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (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 399A6129511 for ; Sun, 4 Jun 2017 06:53:59 -0700 (PDT) X-AuditID: c6180641-379ff700000037f2-42-5933ca95f7bd Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 38.30.14322.59AC3395; Sun, 4 Jun 2017 10:53:44 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0339.000; Sun, 4 Jun 2017 09:53:58 -0400 From: Daniel Migault To: "curdle@ietf.org" Thread-Topic: draft-ietf-curdle-ssh-modp-dh-sha2 ready to be sent to IESG Thread-Index: AdLdOeilXvXsIR8oQZOq4yJ31Me1WQ== Date: Sun, 4 Jun 2017 13:53:55 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118C7203D@eusaamb107.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_2DD56D786E600F45AC6BDE7DA4E8A8C118C7203Deusaamb107erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJLMWRmVeSWpSXmKPExsUyuXSPt+6MU8aRBg2z+C22LpzF7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujFOfWpkLPphWPLg3namBcaFBFyMnh4SAicTsLZcZuxi5OIQE jjJKrO77ywrhLGOUWHm7gxmkik3ASKLtUD87iC0ioC5x4tAOVhBbWMBFYs6TGUwQcU+JB98f AdVzANl6EgsP5oKEWQRUJPZ29YOV8Ar4SsyZ/o4RxGYUEJP4fmoNWJxZQFzi1pP5TBAHCUgs 2XOeGcIWlXj5+B8rhK0k8fH3fHaI+nyJpVtfsEPMFJQ4OfMJywRGwVlIRs1CUjYLSRlEXEdi we5PbBC2tsSyha+ZYewzBx4zIYsvYGRfxchRWlyQk5tuZLiJERjgxyTYHHcw7u31PMQowMGo xMMrfMg4Uog1say4MvcQowQHs5II79eHQCHelMTKqtSi/Pii0pzU4kOM0hwsSuK878ovRAgJ pCeWpGanphakFsFkmTg4pRoYFRxtZhS3TzjhFcdpV3zrwUy26K6XBWHsek/CNO0+5h994Z3x IlXse9r5ORsKD5gV7GdcsEGymCNNcUbU01unLy1yuOtW83v2WzOWb9O3ases1ploo6+kuynV 3kfQq/lM+//Vc9/M3HrK3CDUJfqXgM7lIK+rKlP4lJ/P5Anase5Ii6n6+rwWJZbijERDLeai 4kQAdnrmkmwCAAA= Archived-At: Subject: [Curdle] draft-ietf-curdle-ssh-modp-dh-sha2 ready to be sent to IESG X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2017 13:54:01 -0000 --_000_2DD56D786E600F45AC6BDE7DA4E8A8C118C7203Deusaamb107erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi everyone, Thank you for all the reviews and feed backs for draft-ietf-curdle-ssh-modp= -dh-sha2 [1]. It has been in WGLC for quite some time and seems ready to be= sent to the IESG. We will send it to the IESG in the few next days. If you= have anything to say about the draft or the shepherd write up [2], feel fr= ee to raise your opinion as soon as possible. Yours, Daniel [1] https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-modp-dh-sha2/ [2] https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-modp-dh-sha2/she= pherdwriteup/ [Ericsson] DANIEL MIGAULT Researcher Research Ericsson 8500 Boulevard Decarie H4P 2N2 Montreal, Canada Phone +1 514 345 7900 46628 Mobile +1 514 452 2160 daniel.migault@ericsson.com www.ericsson.com [http://www.ericsson.com/current_campaign] Legal entity: Ericsson Canada Inc., registered office in Montreal. This Com= munication is Confidential. We only send and receive email on the basis of = the terms set out at www.ericsson.com/email_disclaimer --_000_2DD56D786E600F45AC6BDE7DA4E8A8C118C7203Deusaamb107erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi everyone,

 

Thank you for all the reviews and feed backs for dra= ft-ietf-curdle-ssh-modp-dh-sha2 [1]. It has been in WGLC for quite some tim= e and seems ready to be sent to the IESG. We will send it to the IESG in th= e few next days. If you have anything to say about the draft or the shepherd write up [2], feel free to raise yo= ur opinion as soon as possible.

 

Yours,

Daniel

 

[1] https://datatracker.ietf.org/doc/draft-ietf-curd= le-ssh-modp-dh-sha2/

[2] https://datatracker.ietf.org/doc/draft-ietf-curd= le-ssh-modp-dh-sha2/shepherdwriteup/

 

 

3D"Ericsson"

DANIEL MIGAULT
Researcher
Research


Ericsson
8500 Boulevard Decarie
H4P 2N2 Montreal, Canada
Phone +1 514 345 7900 46628
Mobile +1 514 452 2160
daniel.migault@ericsson.com
www.ericsson.com



3D"http://www.eric=

 

Legal entity: Ericsson Canada Inc., regi= stered office in Montreal. This Communication is Confidential. We only send= and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer

--_000_2DD56D786E600F45AC6BDE7DA4E8A8C118C7203Deusaamb107erics_-- From nobody Sun Jun 4 09:01:20 2017 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E7DDE127275; Sun, 4 Jun 2017 09:01:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.52.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149659207982.3109.3423627384109154487@ietfa.amsl.com> Date: Sun, 04 Jun 2017 09:01:19 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-cms-ecdh-new-curves-09.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2017 16:01:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : Use of the Elliptic Curve Diffie-Hellman Key Agreement Algorithm with X25519 and X448 in the Cryptographic Message Syntax (CMS) Author : Russ Housley Filename : draft-ietf-curdle-cms-ecdh-new-curves-09.txt Pages : 17 Date : 2017-06-04 Abstract: This document describes the conventions for using Elliptic Curve Diffie-Hellman (ECDH) key agreement algorithm using curve25519 and curve448 in the Cryptographic Message Syntax (CMS). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-ecdh-new-curves/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-cms-ecdh-new-curves-09 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-cms-ecdh-new-curves-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-cms-ecdh-new-curves-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 Sun Jun 4 09:02:33 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC1A129504 for ; Sun, 4 Jun 2017 09:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 j8Olpc73tlsi for ; Sun, 4 Jun 2017 09:02:29 -0700 (PDT) Received: from mail.smeinc.net (x-bolt-wan.smeinc.net [209.135.219.146]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B05DB127275 for ; Sun, 4 Jun 2017 09:02:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id DE974300567 for ; Sun, 4 Jun 2017 12:02:28 -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 MOMG9X7uQE0Q for ; Sun, 4 Jun 2017 12:02:27 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 6EAB5300494; Sun, 4 Jun 2017 12:02:27 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <149659207982.3109.3423627384109154487@ietfa.amsl.com> Date: Sun, 4 Jun 2017 12:02:27 -0400 Cc: Eric Rescorla Content-Transfer-Encoding: quoted-printable Message-Id: <9AF6EDF0-6C3A-4E48-BE8A-1D888483B994@vigilsec.com> References: <149659207982.3109.3423627384109154487@ietfa.amsl.com> To: curdle X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-cms-ecdh-new-curves-09.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2017 16:02:31 -0000 I missed the Gen-ART review comment from Roni Even. This revision = addresses those comments. Russ > On Jun 4, 2017, at 12:01 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 CURves, Deprecating and a Little more = Encryption of the IETF. >=20 > Title : Use of the Elliptic Curve Diffie-Hellman Key = Agreement Algorithm with X25519 and X448 in the Cryptographic Message = Syntax (CMS) > Author : Russ Housley > Filename : draft-ietf-curdle-cms-ecdh-new-curves-09.txt > Pages : 17 > Date : 2017-06-04 >=20 > Abstract: > This document describes the conventions for using Elliptic Curve > Diffie-Hellman (ECDH) key agreement algorithm using curve25519 and > curve448 in the Cryptographic Message Syntax (CMS). >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-ecdh-new-curves/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-curdle-cms-ecdh-new-curves-09 > = https://datatracker.ietf.org/doc/html/draft-ietf-curdle-cms-ecdh-new-curve= s-09 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-curdle-cms-ecdh-new-curves-= 09 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Sun Jun 4 09:09:31 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D2BA120727 for ; Sun, 4 Jun 2017 09:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] autolearn=unavailable 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 Zmvj3ovdeUBI for ; Sun, 4 Jun 2017 09:09:21 -0700 (PDT) Received: from mail.smeinc.net (x-bolt-wan.smeinc.net [209.135.219.146]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FD531277BB for ; Sun, 4 Jun 2017 09:09:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 6EB0130056C for ; Sun, 4 Jun 2017 12:09:20 -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 6KFGuwd_ih3H for ; Sun, 4 Jun 2017 12:09:18 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 4C955300265; Sun, 4 Jun 2017 12:09:18 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <149570983670.8681.5001417855088402577@ietfa.amsl.com> Date: Sun, 4 Jun 2017 12:09:18 -0400 Cc: IETF Gen-ART , curdle , IETF Content-Transfer-Encoding: 7bit Message-Id: References: <149570983670.8681.5001417855088402577@ietfa.amsl.com> To: Roni Even X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] Genart last call review of draft-ietf-curdle-cms-ecdh-new-curves-07 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2017 16:09:23 -0000 Roni: Thanks for the review. I believe that -09 resolves your comments. Russ > On May 25, 2017, at 6:57 AM, Roni Even wrote: > > Reviewer: Roni Even > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-curdle-cms-ecdh-new-curves-?? > Reviewer: Roni Even > Review Date: 2017-05-25 > IETF LC End Date: 2017-05-28 > IESG Telechat date: Not scheduled for a telechat > > Summary: > The document is ready for publication as a standard track RFC > > Major issues: > > Minor issues: > > Nits/editorial comments: > > In general it was easy to read and follow. Maybe it will be good to > repeat in section 3.2 the definition of KeyAgreeRecipientInfo . This > is done is section 2 for ECC-CMS-SharedInfo but it is not crucial. > > 1. There is no ToC > 2. In section 2.2 fourth paragraph "is used two places" - "in two .." > > > > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Sun Jun 4 19:50:05 2017 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B3D3012778E; Sun, 4 Jun 2017 19:49:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.52.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149663099768.3234.6289962833790815289@ietfa.amsl.com> Date: Sun, 04 Jun 2017 19:49:57 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-des-des-des-die-die-die-02.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 02:49:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : Deprecate 3DES and RC4 in Kerberos Authors : Benjamin Kaduk Michiko Short Filename : draft-ietf-curdle-des-des-des-die-die-die-02.txt Pages : 9 Date : 2017-06-04 Abstract: The 3DES and RC4 encryption types are steadily weakening in cryptographic strength, and the deprecation process should be begun for their use in Kerberos. Accordingly, RFC 4757 is moved to Obsolete status, as none of the encryption types it specifies should be used, and RFC 3961 is updated to note the deprecation of the triple-DES encryption types. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-des-des-des-die-die-die/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-des-des-des-die-die-die-02 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-des-des-des-die-die-die-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-des-des-des-die-die-die-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 Sun Jun 4 19:51:19 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2ACB126BFD for ; Sun, 4 Jun 2017 19:51:18 -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, RP_MATCHES_RCVD=-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 mLmQZBUo4DfR for ; Sun, 4 Jun 2017 19:51:17 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (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 0C28F126CD8 for ; Sun, 4 Jun 2017 19:51:16 -0700 (PDT) X-AuditID: 1209190c-c53ff70000001d26-d9-5934c723b982 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 56.A0.07462.327C4395; Sun, 4 Jun 2017 22:51:15 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id v552pEuP017113 for ; Sun, 4 Jun 2017 22:51:15 -0400 Received: from kduck.kaduk.org (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.13.8/8.12.4) with ESMTP id v552pB2F018521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 4 Jun 2017 22:51:14 -0400 Date: Sun, 4 Jun 2017 21:51:11 -0500 From: Benjamin Kaduk To: curdle@ietf.org Message-ID: <20170605025111.GW39245@kduck.kaduk.org> References: <149663099768.3234.6289962833790815289@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <149663099768.3234.6289962833790815289@ietfa.amsl.com> User-Agent: Mutt/1.7.1 (2016-10-04) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrEIsWRmVeSWpSXmKPExsUixG6noqt83CTSYHu/pcXWhbOYHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVMe3Gd5aCj/wVZ2/fYWlgPMzTxcjJISFgIrF1UxtLFyMXh5DA YiaJvQ9fs4AkhASOMUpMeG0HkXjFJPFl62p2kASLgIrEvM8fGUFsNiC7ofsycxcjB4eIgLBE zwJJkLCwQIhEy+LZ7CBhXqAFl5cbQ4x0krjWPI8VxOYVEJQ4OfMJ2CpmAS2JG/9eMoGUMwtI Syz/xwES5hRwlph98CjYUlEBZYm/h++xTGDkn4WkexaS7lkI3QsYmVcxyqbkVunmJmbmFKcm 6xYnJ+blpRbpGurlZpbopaaUbmIEBR2nJM8OxjNvvA4xCnAwKvHwHkgziRRiTSwrrsw9xCjJ waQkynt6LVCILyk/pTIjsTgjvqg0J7X4EKMEB7OSCG+GNVCONyWxsiq1KB8mJc3BoiTOK6HR GCEkkJ5YkpqdmlqQWgSTleHgUJLg3XQUqFGwKDU9tSItM6cEIc3EwQkynAdoONsxkOHFBYm5 xZnpEPlTjIpS4rz3jgAlBEASGaV5cL2gpCCRvb/mFaM40CvCvJcOAVXxABMKXPcroMFMQINP TzMGGVySiJCSamA8kfitNv17nsS5NAeugqmGLB4fIu/EZT5XEjz8jCFq9pIlE5f3eVo3rplw QjCt5qDM9b3G375LqPuEq5ya3GLP6fXSWV70+kuxnpeWj1v/2szZ/7BPtOnAyV7xLO17z/7v 3Dhdtte26+CMkvPGC1jvL1gmuv7orZ1P+pgvxu/NP3HbuobNelm7EktxRqKhFnNRcSIAkj66 PuUCAAA= Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-des-des-des-die-die-die-02.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 02:51:19 -0000 This just updates the reference for the IANA registries to have the actual URL for the registry on the web, instead of referencing the RFC that created the registries. -Ben On Sun, Jun 04, 2017 at 07:49:57PM -0700, 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 CURves, Deprecating and a Little more Encryption of the IETF. > > Title : Deprecate 3DES and RC4 in Kerberos > Authors : Benjamin Kaduk > Michiko Short > Filename : draft-ietf-curdle-des-des-des-die-die-die-02.txt > Pages : 9 > Date : 2017-06-04 > > Abstract: > The 3DES and RC4 encryption types are steadily weakening in > cryptographic strength, and the deprecation process should be begun > for their use in Kerberos. Accordingly, RFC 4757 is moved to > Obsolete status, as none of the encryption types it specifies should > be used, and RFC 3961 is updated to note the deprecation of the > triple-DES encryption types. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-curdle-des-des-des-die-die-die/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-curdle-des-des-des-die-die-die-02 > https://datatracker.ietf.org/doc/html/draft-ietf-curdle-des-des-des-die-die-die-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-des-des-des-die-die-die-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/ > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Mon Jun 5 02:39:45 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE09128D69 for ; Mon, 5 Jun 2017 02:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.923 X-Spam-Level: X-Spam-Status: No, score=-6.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 bZAvtEMx5Lev for ; Mon, 5 Jun 2017 02:39:41 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D6EB128BB7 for ; Mon, 5 Jun 2017 02:39:41 -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 AD1D34E34C; Mon, 5 Jun 2017 09:39:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com AD1D34E34C Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=simo@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com AD1D34E34C Received: from ovpn-116-81.phx2.redhat.com (ovpn-116-81.phx2.redhat.com [10.3.116.81]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E14EF8523D; Mon, 5 Jun 2017 09:39:39 +0000 (UTC) Message-ID: <1496655577.929.112.camel@redhat.com> From: Simo Sorce To: Benjamin Kaduk , curdle@ietf.org Date: Mon, 05 Jun 2017 05:39:37 -0400 In-Reply-To: <20170521202553.GQ39245@kduck.kaduk.org> References: <20170521202553.GQ39245@kduck.kaduk.org> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit 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.38]); Mon, 05 Jun 2017 09:39:40 +0000 (UTC) Archived-At: Subject: Re: [Curdle] review of draft-ietf-curdle-gss-keyex-sha2-00 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 09:39:43 -0000 On Sun, 2017-05-21 at 15:25 -0500, Benjamin Kaduk wrote: > Generally, this document is in good shape, and I think we should move > it forward. > > My main comment/objection is that the security considerations should > note that the combination of GSS key exchange, GSS delegated > credentials, and use of insecure DNS to modify the requested server > principal name result in a situation where an attacker can easily > obtain a valid TGT+key for the client principal.  Obviously, RFCs > 4462, 4120, etc. all implore us to not use insecure DNS in such a > fashion, but nonetheless major Kerberos libraries continue to do so. > At MIT we have disabled GSS key exchange for ssh because we default > to GSS credential delegation. I am quite hesitant to call additional security considerations in a document that is substantially just updating an existing document without introducing any new security related method that needs additional considerations. However I added a reference to the Security Considerations of 4120 as well. I do not think we should really do more, this issue is (or should be) a well know problem and in no way specific to SSH key exchanges. > Some other nit-level comments: meta-nit, your page numbers seem to be off a bit, I hope you're reading the document I posted in curdle and not a previous version. > On page 8, in step 5 of the procedure, do we want to give a > reference or two for the shared-secret computation above the > existing prose? What do you have in mind? I think we already have all the relevant references at the top or in the 1st step. >   (Also, is the d_U and q_V terminology standard from > some related document?  I did not see them in RFC 4462.) No, they are new handles used to avoid repeating the client or service specific value. IE, d_U stands for 'd_C for the client or d_S for the server' and q_V stands for 'q_S for the client or q_C for the server'. Do you think this is confusing ? > Also on page 8, step 6 could further clarify that this only occurs > when the server's final call to GSS_Accept_sec_context() returns > GSS_S_COMPLETE; anything else is an error condition. Already explained in step 8, I think that is sufficient. > Relatedly, the > way the GSS context negotiation loop's exit conditions are split > between step 6 and step 2 confused me a little on first read, but it > seems correct, and along with the RFC 7546 reference I think readers > will be okay. It is really hard to condense everything in few steps and maintain perfect clarity on all fronts, but I think the current text strikes the right balance, between being more informative than the document we replace, without being overly verbose and distracting from the actual core of the matter and has enough references to clarify with original documents any doubts one may have. > On page 11, the description of the HASH input has a couple of > inconsistencies -- in RFC 4462, V_S is the server's "version" > string, though here we have it as the server's "identification" > string.  I don't think that's a problem per se, but wanted to note > it just in case.  Also, V_S excludes CR and LF, but V_C excludes CR > and NL; we should probably be consistent about NL vs. LF. Thanks for pointing these out, I am fixing these to say server version for consistency with 4462 and will use NL again for consistency with 4462 which is itself inconsistent as it uses CRLF in some places ... > In sections 5.2.2 and later we continue to include refeferences for > MD5, DER, and Base64; RFC 4462 only included those references in the > first corresponding subsection.  At this point, it's probably not > worth making any changes, though. I agree it is not worth making changes here. > And one editorial note: > > On page 6, "non- zero" should not have a space. Thanks. I will submit -01 with these corrections shortly. Simo. From nobody Mon Jun 5 02:49:38 2017 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C0F801292F4; Mon, 5 Jun 2017 02:49:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.52.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149665616974.3164.5012210735172888291@ietfa.amsl.com> Date: Mon, 05 Jun 2017 02:49:29 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-gss-keyex-sha2-01.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 09:49:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : GSS-API Key Exchange with SHA2 Authors : Simo Sorce Hubert Kario Filename : draft-ietf-curdle-gss-keyex-sha2-01.txt Pages : 16 Date : 2017-06-05 Abstract: This document specifies additions and amendments to SSH GSS-API Methods [RFC4462]. It defines a new key exchange method that uses SHA-2 for integrity and deprecates weak DH groups. The purpose of this specification is to modernize the cryptographic primitives used by GSS Key Exchanges. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-gss-keyex-sha2/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-gss-keyex-sha2-01 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-gss-keyex-sha2-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-gss-keyex-sha2-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 Mon Jun 5 02:56:50 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D08C1293FD for ; Mon, 5 Jun 2017 02:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.922 X-Spam-Level: X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 1hIxbbeh_W59 for ; Mon, 5 Jun 2017 02:56: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 115121267BB for ; Mon, 5 Jun 2017 02:56:47 -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 A424FC0587CC; Mon, 5 Jun 2017 09:56:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com A424FC0587CC Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=simo@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com A424FC0587CC Received: from ovpn-116-81.phx2.redhat.com (ovpn-116-81.phx2.redhat.com [10.3.116.81]) by smtp.corp.redhat.com (Postfix) with ESMTPS id DC7B27E9C0; Mon, 5 Jun 2017 09:56:45 +0000 (UTC) Message-ID: <1496656603.929.114.camel@redhat.com> From: Simo Sorce To: Benjamin Kaduk , curdle@ietf.org Date: Mon, 05 Jun 2017 05:56:43 -0400 In-Reply-To: <1496655577.929.112.camel@redhat.com> References: <20170521202553.GQ39245@kduck.kaduk.org> <1496655577.929.112.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit 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.32]); Mon, 05 Jun 2017 09:56:46 +0000 (UTC) Archived-At: Subject: Re: [Curdle] review of draft-ietf-curdle-gss-keyex-sha2-00 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 09:56:48 -0000 On Mon, 2017-06-05 at 05:39 -0400, Simo Sorce wrote: > On Sun, 2017-05-21 at 15:25 -0500, Benjamin Kaduk wrote: > > Generally, this document is in good shape, and I think we should > > move > > it forward. > > > > My main comment/objection is that the security considerations > > should > > note that the combination of GSS key exchange, GSS delegated > > credentials, and use of insecure DNS to modify the requested server > > principal name result in a situation where an attacker can easily > > obtain a valid TGT+key for the client principal.  Obviously, RFCs > > 4462, 4120, etc. all implore us to not use insecure DNS in such a > > fashion, but nonetheless major Kerberos libraries continue to do > > so. > > At MIT we have disabled GSS key exchange for ssh because we default > > to GSS credential delegation. > > I am quite hesitant to call additional security considerations in a > document that is substantially just updating an existing document > without introducing any new security related method that needs > additional considerations. However I added a reference to the > Security > Considerations of 4120 as well. I do not think we should really do > more, this issue is (or should be) a well know problem and in no way > specific to SSH key exchanges. I posted a new draft with the corrections noted below but with the exception of adding 4120 as I stated here. Although krb5 is the most (or only ?) mechanism RFC 4462 and this draft are definitely not mechanism specific (they only recommend against using SPNEGO not any other mechanism), and it doesn't feel right to me to add security considerations to a specific mechanism (delegation is a krb5 mechanism feature in this case, not a feature of the SSH Key exchange) in an amendment document that is not changing anything with regard to the initial RFC 4462 security properties. If you do not agree, please provide language that you think would be appropriate. If anyone else has comments on whether we should add or not additional, mechanism specific, security considerations, please let me know. Simo. > > Some other nit-level comments: > > meta-nit, your page numbers seem to be off a bit, I hope you're > reading > the document I posted in curdle and not a previous version. > > > On page 8, in step 5 of the procedure, do we want to give a > > reference or two for the shared-secret computation above the > > existing prose? > > What do you have in mind? I think we already have all the relevant > references at the top or in the 1st step. > > >   (Also, is the d_U and q_V terminology standard from > > some related document?  I did not see them in RFC 4462.) > > No, they are new handles used to avoid repeating the client or > service > specific value. > IE, d_U stands for 'd_C for the client or d_S for the server' and > q_V stands for 'q_S for the client or q_C for the server'. > Do you think this is confusing ? > > > Also on page 8, step 6 could further clarify that this only occurs > > when the server's final call to GSS_Accept_sec_context() returns > > GSS_S_COMPLETE; anything else is an error condition. > > Already explained in step 8, I think that is sufficient. > > > Relatedly, the > > way the GSS context negotiation loop's exit conditions are split > > between step 6 and step 2 confused me a little on first read, but > > it > > seems correct, and along with the RFC 7546 reference I think > > readers > > will be okay. > > It is really hard to condense everything in few steps and maintain > perfect clarity on all fronts, but I think the current text strikes > the > right balance, between being more informative than the document we > replace, without being overly verbose and distracting from the actual > core of the matter and has enough references to clarify with original > documents any doubts one may have. > > > On page 11, the description of the HASH input has a couple of > > inconsistencies -- in RFC 4462, V_S is the server's "version" > > string, though here we have it as the server's "identification" > > string.  I don't think that's a problem per se, but wanted to note > > it just in case.  Also, V_S excludes CR and LF, but V_C excludes CR > > and NL; we should probably be consistent about NL vs. LF. > > Thanks for pointing these out, I am fixing these to say server > version > for consistency with 4462 and will use NL again for consistency with > 4462 which is itself inconsistent as it uses CRLF in some places ... > > > In sections 5.2.2 and later we continue to include refeferences for > > MD5, DER, and Base64; RFC 4462 only included those references in > > the > > first corresponding subsection.  At this point, it's probably not > > worth making any changes, though. > > I agree it is not worth making changes here. > > > And one editorial note: > > > > On page 6, "non- zero" should not have a space. > > Thanks. > I will submit -01 with these corrections shortly. > > Simo. > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Mon Jun 5 14:50:23 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55BFA129544; Mon, 5 Jun 2017 14:50:21 -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 vsVSsAc6XT9K; Mon, 5 Jun 2017 14:50:17 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (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 30F541200FC; Mon, 5 Jun 2017 14:50:17 -0700 (PDT) X-AuditID: c618062d-50fff7000000248b-8c-5935e64b05de Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id AA.1D.09355.B46E5395; Tue, 6 Jun 2017 01:16:28 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0339.000; Mon, 5 Jun 2017 17:50:17 -0400 From: Daniel Migault To: "draft-ietf-curdle-des-des-des-die-die-die@ietf.org" CC: "curdle-chairs@ietf.org" , "curdle@ietf.org" Thread-Topic: [Curdle] I-D Action: draft-ietf-curdle-des-des-des-die-die-die-02.txt Thread-Index: AQHS3aaCHJbgDFl8wUGQWusYjzQpD6IV1O6AgABoXZA= Date: Mon, 5 Jun 2017 21:50:16 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118C72387@eusaamb107.ericsson.se> References: <149663099768.3234.6289962833790815289@ietfa.amsl.com> <20170605025111.GW39245@kduck.kaduk.org> In-Reply-To: <20170605025111.GW39245@kduck.kaduk.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyuXRPlK7PM9NIg74JRhYzezYwW2xdOIvZ 4mnXESYHZo8lS34yBTBGcdmkpOZklqUW6dslcGVs2XSbrWCJccW6V+uYGxi7NbsYOTkkBEwk rp4+wNrFyMUhJHCUUaKvZSszhLOMUeLzh32MIFVsAkYSbYf62bsYOThEBPIlGo+6g4SZBWIk bv6dzg5iCwuESJxa2MMEYosIhEocvTMHqtxK4sgMsBIWARWJv/tPgk3kFfCV2Dl3CwuILSSQ K3Hj+EcmkHJOAVOJa0dMQMKMAmIS30+tYYLYJC5x68l8JoiTBSSW7DnPDGGLSrx8/I8VwlaS +Ph7PjtEvY7Egt2f2CBsbYllC18zQ6wVlDg58wnLBEbRWUjGzkLSMgtJyywkLQsYWVYxcpQW F+TkphsZbGIERsIxCTbdHYz3p3seYhTgYFTi4eW/aBopxJpYVlyZe4hRgoNZSYSXcS9QiDcl sbIqtSg/vqg0J7X4EKM0B4uSOO+E8xcihATSE0tSs1NTC1KLYLJMHJxSDYz8hzM7HzyNqlm5 L/qeUo6oXPyqwmt5Xzm/vhDO5+BLDdK4LDtbU3nqKbvv12ZPKMg5su3b+hfOH8zbvZN1JnXy zHTTF2e6sHHxvqBbc9cqT9rl485n++fRhaaC+L/6RYIV4owfr7tf5tRRPptyqv/jqVnL769f Y/7ze6UMp+Ib6cvqXziuz36qxFKckWioxVxUnAgA9wwFVoACAAA= Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-des-des-des-die-die-die-02.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 21:50:21 -0000 Hi,=20 Thanks for updating the draft. I have found some small nits, but overall th= e draft seems ready to me to be sent to the IESG. I have prepared the sheph= erd write-up [1]. I believe 03 will be sent it to the IESG.=20 If anyone has additional comments, please let us know as soon as possible. Yours,=20 Daniel [1] https://datatracker.ietf.org/doc/draft-ietf-curdle-des-des-des-die-die-= die/shepherdwriteup/ COMMENT A) """ However, both Windows XP and Windows Server 2003 are already out of their official support periods. It is now believed that all machines that might be broken by disabling RC4 are unsupported, and concerns about breaking them will be reduced. That should facilitate the removal of RC4 from common use. """ Maybe that is my English and I might misinterpret the text, but it do not f= ind appropriated to mention we are not concerned by breaking some systems. = I also feel that the text can be interpreted as a commercial argument to "b= uy the new release". Maybe it might be more appropriated to say that as uns= upported, their numbers is expected to be quite low, then that such machine= s are unlikely to operate on managed networks where Kerberos is deployed. = If that is the case, it is the responsibility of the network administrator = to address appropriately this issue. But I am fine with the conclusion: Tha= t should facilitate the removal of RC4 from common use. COMMENT B)=20 Maybe some references could be provided for the cited Kerberos implementati= ons. =20 MIT Kerberos; https://web.mit.edu/kerberos/ Heimdal Kerberos: https://www.h5l.org/ COMMENT C)=20 The URL does not appear in the references.=20 [MS-NLMP] Microsoft Corporation, "[MS-NLMP]: NT LAN Manager (NTLM) Authentication Protocol", May 2014. [IANA-KRB] Internet Assigned Numbers Authority, "IANA Kerberos Parameters Registry", March 2017. I suppose this is an issue in the xml, and maybe the following syntax could= solve this issue: OLD:=20 [MS-NLMP]: NT LAN Ma= nager (NTLM) Authentication Protocol Microsoft Corporation IANA Kerberos Parameters Registry Internet Assigned Numbers Authority NEW: [MS-NLMP]: NT LAN Ma= nager (NTLM) Authentication Protocol Microsoft Corporation IANA Kerberos Parameters Registry Internet Assigned Numbers Authority =09 COMMENT D)=20 The RFC6150 is informational and is listed in the normative section. I beli= eve it should be in the informational reference section.=20 [RFC6150] Turner, S. and L. Chen, "MD4 to Historic Status", RFC 6150, DOI 10.17487/RFC6150, March 2011, . COMMENT E)=20 s/Similarly, IANA Is requested/ Similarly, IANA is requested -----Original Message----- From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Benjamin Kaduk Sent: Sunday, June 04, 2017 10:51 PM To: curdle@ietf.org Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-des-des-des-die-die-die= -02.txt This just updates the reference for the IANA registries to have the actual = URL for the registry on the web, instead of referencing the RFC that create= d the registries. -Ben On Sun, Jun 04, 2017 at 07:49:57PM -0700, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the CURves, Deprecating and a Little more En= cryption of the IETF. >=20 > Title : Deprecate 3DES and RC4 in Kerberos > Authors : Benjamin Kaduk > Michiko Short > Filename : draft-ietf-curdle-des-des-des-die-die-die-02.txt > Pages : 9 > Date : 2017-06-04 >=20 > Abstract: > The 3DES and RC4 encryption types are steadily weakening in > cryptographic strength, and the deprecation process should be begun > for their use in Kerberos. Accordingly, RFC 4757 is moved to > Obsolete status, as none of the encryption types it specifies should > be used, and RFC 3961 is updated to note the deprecation of the > triple-DES encryption types. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-curdle-des-des-des-die-die > -die/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-curdle-des-des-des-die-die-die- > 02 > https://datatracker.ietf.org/doc/html/draft-ietf-curdle-des-des-des-die-d= ie-die-02 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-curdle-des-des-des-die-di > e-die-02 >=20 >=20 > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at tools.iet= f.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle From nobody Tue Jun 6 09:13:23 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5867126C83; Tue, 6 Jun 2017 09:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 6SQYRf0Sbav9; Tue, 6 Jun 2017 09:13:18 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0112.outbound.protection.outlook.com [104.47.42.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67569129496; Tue, 6 Jun 2017 09:13:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6EVK07/Y1yfudLP+3aoq8JMXsASJ9pwAxIf+AqOQI8k=; b=UIxu17VxvEVMrH2Im5Bxqb9+EvhBcMEyG+s9tQhuRdn0FfuQOn6gIUBmVdX2Ru12wdbb1C43u8tukhIdNPsv2PqbYIguWVptujZEcgFgAK4f+A8siIDg0Z34Ttw6aLyekPaqituRvVF8ox6s6ALe4XvgLCtYL5NNPRTLv6mMZFk= Received: from BLUPR0301MB1554.namprd03.prod.outlook.com (10.162.214.12) by BLUPR0301MB1553.namprd03.prod.outlook.com (10.162.214.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1157.12; Tue, 6 Jun 2017 16:13:16 +0000 Received: from BLUPR0301MB1554.namprd03.prod.outlook.com ([10.162.214.12]) by BLUPR0301MB1554.namprd03.prod.outlook.com ([10.162.214.12]) with mapi id 15.01.1143.019; Tue, 6 Jun 2017 16:13:16 +0000 From: Michiko Short To: Daniel Migault , "draft-ietf-curdle-des-des-des-die-die-die@ietf.org" CC: "curdle-chairs@ietf.org" , "curdle@ietf.org" Thread-Topic: [Curdle] I-D Action: draft-ietf-curdle-des-des-des-die-die-die-02.txt Thread-Index: AQHS3aaCHJbgDFl8wUGQWusYjzQpD6IV1O6AgABoXZCAAcOiIA== Date: Tue, 6 Jun 2017 16:13:16 +0000 Message-ID: References: <149663099768.3234.6289962833790815289@ietfa.amsl.com> <20170605025111.GW39245@kduck.kaduk.org> <2DD56D786E600F45AC6BDE7DA4E8A8C118C72387@eusaamb107.ericsson.se> In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C118C72387@eusaamb107.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ericsson.com; dkim=none (message not signed) header.d=none; ericsson.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:8::681] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR0301MB1553; 7:wLyIOj3TjyUqQWElOLzu/XRAQgtYbq5Tr32Bl9dgWYTwxAueZyrZQ3Sqen+Mubvh8adjlF7iuD+XtxeMkhMyxbkgCGLuBke5rFgQoTmA/3u/9IA2AMZU3pdlIYlPyIA3vlTsAwjtu+fAR32fo/1GVthdm2GybB8TKE3808IHu+cFpBoL59USfKfALRrIezXhUwg26LczszscDNZP7uD00oBsIIrU4PMbUOTz3RsgkSMIUwzx3BPuaQxb3l2C1V4cwOSbdj0O+E6MBUNkf/Wi8mMP34kiYk7FCmRnqFhYGjzEPQ7FiMFkb4dZhdnkbeIVcjDRWTAmYT/uU/PXVW25//iXfKbCiHvPBy+usMXxT/Q= x-ms-traffictypediagnostic: BLUPR0301MB1553: x-ms-office365-filtering-correlation-id: f7c04439-f3be-4548-0ca9-08d4acf6f082 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:BLUPR0301MB1553; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(158342451672863)(189930954265078)(219752817060721); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(100000703101)(100105400095)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123560025)(20161123564025)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR0301MB1553; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR0301MB1553; x-forefront-prvs: 033054F29A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39450400003)(39400400002)(39860400002)(39840400002)(39850400002)(377424004)(377454003)(13464003)(24454002)(3905003)(33656002)(2950100002)(53546009)(50986999)(54356999)(76176999)(6506006)(575784001)(86612001)(3280700002)(3660700001)(7696004)(77096006)(25786009)(189998001)(6436002)(86362001)(8936002)(81166006)(74316002)(7736002)(305945005)(8676002)(9686003)(6306002)(122556002)(478600001)(10290500003)(14454004)(230783001)(5660300001)(966005)(55016002)(53936002)(99286003)(54906002)(6246003)(6116002)(102836003)(10090500001)(8990500004)(4326008)(5005710100001)(38730400002)(229853002)(2900100001)(2906002)(2501003); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0301MB1553; H:BLUPR0301MB1554.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jun 2017 16:13:16.1507 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0301MB1553 Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-des-des-des-die-die-die-02.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 16:13:22 -0000 Also why do we only call out Windows. Perhaps the better option is to list = all which of our versions support AES? For example: Windows has supported AES since 2007 with the release of Windows Vista & 20= 08 with the release of Windows Server 2008, therefore numbers of Windows wh= ich required RC4 should be low. MIT has... Heimdal has.. -----Original Message----- From: Daniel Migault [mailto:daniel.migault@ericsson.com]=20 Sent: Monday, June 5, 2017 2:50 PM To: draft-ietf-curdle-des-des-des-die-die-die@ietf.org Cc: curdle-chairs@ietf.org; curdle@ietf.org Subject: RE: [Curdle] I-D Action: draft-ietf-curdle-des-des-des-die-die-die= -02.txt Hi,=20 Thanks for updating the draft. I have found some small nits, but overall th= e draft seems ready to me to be sent to the IESG. I have prepared the sheph= erd write-up [1]. I believe 03 will be sent it to the IESG.=20 If anyone has additional comments, please let us know as soon as possible. Yours, Daniel [1] https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdata= tracker.ietf.org%2Fdoc%2Fdraft-ietf-curdle-des-des-des-die-die-die%2Fshephe= rdwriteup%2F&data=3D02%7C01%7Cmichikos%40microsoft.com%7Cbcc759a2ac824a5e02= 6608d4ac5cddff%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636322962250114= 126&sdata=3Dkjynmx5IEKqTpLmmzE5AftZdS4PxJ12uSKn%2B%2F3Ay7b8%3D&reserved=3D0 COMMENT A) """ However, both Windows XP and Windows Server 2003 are already out of their official support periods. It is now believed that all machines that might be broken by disabling RC4 are unsupported, and concerns about breaking them will be reduced. That should facilitate the removal of RC4 from common use. """ Maybe that is my English and I might misinterpret the text, but it do not f= ind appropriated to mention we are not concerned by breaking some systems. = I also feel that the text can be interpreted as a commercial argument to "b= uy the new release". Maybe it might be more appropriated to say that as uns= upported, their numbers is expected to be quite low, then that such machine= s are unlikely to operate on managed networks where Kerberos is deployed. = If that is the case, it is the responsibility of the network administrator = to address appropriately this issue. But I am fine with the conclusion: Tha= t should facilitate the removal of RC4 from common use. COMMENT B) Maybe some references could be provided for the cited Kerberos implementati= ons. =20 MIT Kerberos; https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A= %2F%2Fweb.mit.edu%2Fkerberos%2F&data=3D02%7C01%7Cmichikos%40microsoft.com%7= Cbcc759a2ac824a5e026608d4ac5cddff%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C= 0%7C636322962250114126&sdata=3DuXgb5iakspN%2FI%2Bj9yqfrkKbcXbKHkaRwM5oDWJU7= PuU%3D&reserved=3D0 Heimdal Kerberos: https://na01.safelinks.protection.outlook.com/?url=3Dhttp= s%3A%2F%2Fwww.h5l.org%2F&data=3D02%7C01%7Cmichikos%40microsoft.com%7Cbcc759= a2ac824a5e026608d4ac5cddff%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636= 322962250124134&sdata=3DzCRCdJ24R93jirCIwfNT2ifgPG28%2FQlfoHjIQfKreBs%3D&re= served=3D0 COMMENT C)=20 The URL does not appear in the references.=20 [MS-NLMP] Microsoft Corporation, "[MS-NLMP]: NT LAN Manager (NTLM) Authentication Protocol", May 2014. [IANA-KRB] Internet Assigned Numbers Authority, "IANA Kerberos Parameters Registry", March 2017. I suppose this is an issue in the xml, and maybe the following syntax could= solve this issue: OLD:=20 [MS-NLMP]: NT LAN Ma= nager (NTLM) Authentication Protocol Microsoft Corporation IANA Kerberos Parameters Registry Internet Assigned Numbers Authority NEW: [MS-NLMP]: NT LAN Ma= nager (NTLM) Authentication Protocol Microsoft Corporation IANA Kerberos Parameters Registry Internet Assigned Numbers Authority =09 COMMENT D)=20 The RFC6150 is informational and is listed in the normative section. I beli= eve it should be in the informational reference section.=20 [RFC6150] Turner, S. and L. Chen, "MD4 to Historic Status", RFC 6150, DOI 10.17487/RFC6150, March 2011, . COMMENT E)=20 s/Similarly, IANA Is requested/ Similarly, IANA is requested -----Original Message----- From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Benjamin Kaduk Sent: Sunday, June 04, 2017 10:51 PM To: curdle@ietf.org Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-des-des-des-die-die-die= -02.txt This just updates the reference for the IANA registries to have the actual = URL for the registry on the web, instead of referencing the RFC that create= d the registries. -Ben On Sun, Jun 04, 2017 at 07:49:57PM -0700, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the CURves, Deprecating and a Little more En= cryption of the IETF. >=20 > Title : Deprecate 3DES and RC4 in Kerberos > Authors : Benjamin Kaduk > Michiko Short > Filename : draft-ietf-curdle-des-des-des-die-die-die-02.txt > Pages : 9 > Date : 2017-06-04 >=20 > Abstract: > The 3DES and RC4 encryption types are steadily weakening in > cryptographic strength, and the deprecation process should be begun > for their use in Kerberos. Accordingly, RFC 4757 is moved to > Obsolete status, as none of the encryption types it specifies should > be used, and RFC 3961 is updated to note the deprecation of the > triple-DES encryption types. >=20 >=20 > The IETF datatracker status page for this draft is: > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat > racker.ietf.org%2Fdoc%2Fdraft-ietf-curdle-des-des-des-die-die&data=3D02% > 7C01%7Cmichikos%40microsoft.com%7Cbcc759a2ac824a5e026608d4ac5cddff%7C7 > 2f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636322962250124134&sdata=3DW9D > 1cNitX3lTbDk82Viu4VSSxX%2FlZxH9RCk%2BUS56jM8%3D&reserved=3D0 > -die/ >=20 > There are also htmlized versions available at: > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools > .ietf.org%2Fhtml%2Fdraft-ietf-curdle-des-des-des-die-die-die-&data=3D02% > 7C01%7Cmichikos%40microsoft.com%7Cbcc759a2ac824a5e026608d4ac5cddff%7C7 > 2f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636322962250124134&sdata=3DgJQ > NwHRax8r5cRudXHHHRFK9aS0hLSfD6HNf6vBkwFg%3D&reserved=3D0 > 02 > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat > racker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-curdle-des-des-des-die-die-d > ie-02&data=3D02%7C01%7Cmichikos%40microsoft.com%7Cbcc759a2ac824a5e026608 > d4ac5cddff%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63632296225012 > 4134&sdata=3DwcJm7JdAsBBznGfPi3c5WRJ1Jgt5jdBQIDhC5EkM4Gk%3D&reserved=3D0 >=20 > A diff from the previous version is available at: > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i > etf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-curdle-des-des-des-die-di&data=3D0 > 2%7C01%7Cmichikos%40microsoft.com%7Cbcc759a2ac824a5e026608d4ac5cddff%7 > C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636322962250124134&sdata=3DE > hrVb769fbxn41qg7kVeBZIMk2jycmQRFJ26yil%2BO1c%3D&reserved=3D0 > e-die-02 >=20 >=20 > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at tools.iet= f.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i > etf.org%2Fmailman%2Flistinfo%2Fcurdle&data=3D02%7C01%7Cmichikos%40micros > oft.com%7Cbcc759a2ac824a5e026608d4ac5cddff%7C72f988bf86f141af91ab2d7cd > 011db47%7C1%7C0%7C636322962250124134&sdata=3DDcfGyzuZ89ur3shrhsefQ6N0fIM > %2Fw%2BiVBvl%2FC0CD3%2FQ%3D&reserved=3D0 _______________________________________________ Curdle mailing list Curdle@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf= .org%2Fmailman%2Flistinfo%2Fcurdle&data=3D02%7C01%7Cmichikos%40microsoft.co= m%7Cbcc759a2ac824a5e026608d4ac5cddff%7C72f988bf86f141af91ab2d7cd011db47%7C1= %7C0%7C636322962250134142&sdata=3D0K2JfDATGftlKs81oowUfCPupD%2B8YavdBrxhxTb= lpCc%3D&reserved=3D0 From nobody Thu Jun 8 12:55:22 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3DC12932A for ; Thu, 8 Jun 2017 12:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, 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=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 kKQGk9F4lJ8x for ; Thu, 8 Jun 2017 12:55:18 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ACF81242F5 for ; Thu, 8 Jun 2017 12:55:18 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id a136so22168239lfa.0 for ; Thu, 08 Jun 2017 12:55:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=dldLuGH4hqazX/6hFZJXC73JlfxqmrdBDi7JddhtP4A=; b=bzwUvr2rIo7liTMtUGaOg0rBpFBduK71ondxe4qWCHg9IPUMopfAO1PI/EQaFgtqUA bH80LqZTGmTYpAtzU3gq3MM67oPMgTj8kTgi9XzhfbJPax7AkZOnhGMfpqTHgdIWkzwU hHwka8Nvg9iCTr2xyxxoWPk9buMv70Aa4BI9En3MmrqMtUMmquH0EkwfohO1Efuq9tqQ 0d2dFbdg0dQ3bK6jGjIo46QccWsjcCTQJfW+CwFADPibnAQ7vUUtPMzck0ukzBLMTDi1 E66zam47izplHHEYFPnbKzBwp/6Pzlu1oVMtS82X4D2Uljon+D6GPebj6DmbnuFOVuAU g5CQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=dldLuGH4hqazX/6hFZJXC73JlfxqmrdBDi7JddhtP4A=; b=VaM5F6oMEcGMF47sgFu1HdW9Tsrk+572rUK1qlwk1dzoAcHreJbgrA5sbeschdwhDd KFRqPn+MbqoxX8LojKFAl52BUCS4BeSpID3nmq6s/tWD0RTITp1UTFgi6EfAwZ2FSfq4 Wm3BLs6VpyVcArreXetHxI4ZHwFheCF4KygK3TUn3sgl7PMHE0nXT2Wzrr3P69EM8RKW fq2o8Zl8Dr2M3DGlm+UqDvQ9RUwyMQABzHR3uBC6IPz6TwI4sQC9og4B6n00z9MTvQxn pMjue/c8lXiqpSc08/rDufBwj6KgyUu1sL8pRshgClvo0rjgVna2Lg+XIvwCuLOBHczU JqJQ== X-Gm-Message-State: AODbwcC4+HXcf1ZJEGzvxAPpb5sw8FliZkPdWWH/faiQpfmMU9mQffkG epA8/sccSCoUFHbAmTQDxeuRovXoNqAy X-Received: by 10.46.76.1 with SMTP id z1mr11744996lja.128.1496951715964; Thu, 08 Jun 2017 12:55:15 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.0.30 with HTTP; Thu, 8 Jun 2017 12:55:15 -0700 (PDT) In-Reply-To: <3895FA29-6856-4024-955F-D8C0CBADF42A@sn3rd.com> References: <3895FA29-6856-4024-955F-D8C0CBADF42A@sn3rd.com> From: Daniel Migault Date: Thu, 8 Jun 2017 15:55:15 -0400 X-Google-Sender-Auth: AhpxWzBX40oOvuf4_XY2QqwqFtU Message-ID: To: Sean Turner Cc: curdle Content-Type: multipart/alternative; boundary="f403045ea6da46af960551783bec" Archived-At: Subject: Re: [Curdle] WGLC draft-schaad-curdle-oid-registry X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 19:55:21 -0000 --f403045ea6da46af960551783bec Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Thank you for updating the draft Jim and Rick. While reviewing the draft for the shepherd -write up I came with a few comments/questions. Please find my comments below. Yours, Daniel COMMENT A) The type of the draft is currently "informational". According to RFC 2026 I am more incline to consider that BCP would be more appropriated. Any thoughts on that ? The draft does not discuss any technical content. The draft describes the set of OIDs that have been donated. In some ways, it also assigns OIDs that have not been assigned by any other RFCs ( but only version-03 of the pkix draft). It also describes the creation of an IANA registry table, as well as update procedure for adding new entries which includes, parameters to provide, the review process to follow and the way the arc can be extended. In that sense according to RFC2026 the document is essentially documenting IETF operations and so BCP seems the appropriated type. COMMENT B) It might my fault as I commented on the earlier version the references [ I-D.ietf-curdle-pkix ] for id-EdDSA25516-ph and id-EdDSA448-ph. It looks confusing to have OIDs reserved for a specific Description while not being assigned. As we have the intention to keep these OIDs, I think you opened a better path to have a RFC as a reference than having an old version of a draft. I interpret the the following text as explaining why we ended up with id-EdDSA25516-ph and id-EdDSA448-ph. """ After those registrations were done, there were still some unused values that can be used for other security groups, there were still some unused values. """ Placing the current document as the Reference would clarify, in my opinion, the status of these OIDs. It may be useful to add some text that provides more explication with an reference to [I-D.ietf-curdle-pkix ]-03. As the RFC editor will probably replace [I-D.ietf-curdle-pkix ] with the RFC number, It might also be better to have a specific informational reference. COMMENT C) The draft says: """ IANA is asked to create one new registry table.2.1 . "SMI Security for Cryptographic Algorithms" Registry Within the SMI-numbers registry, add an "SMI Security for Cryptographic Algorithms" table with the three columns: """ Maybe we should also specify that the SMI Security for Cryptographic Algorithm registry is a sub-item of the "SMI Security Codes Registries". I believe it would be useful to have an URL as an informational reference for both the "SMI-numbers registry" as well as for "SMI Security Codes Registries". https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-= 26 Although I am not aware of a registration procedure for these tables and the current, I believe it would be useful to specify explicitly all fields associated to the table. - Registration: Procedure Although it can be inferred from the current text. I believe it is helpful to the IANA to have the exact filed value associated to all fields. - Description: The description is usually the arc ID, maybe in our case we should add the range of provided OIDs. - Reference: It seems to me that the current document would be appropriated. - Expert: The Registration Procedure mentions Expert review. I am not sure experts should be listed in the in the RFC RFC5226 appointed by IESG. On Sat, Jun 3, 2017 at 9:48 AM, Sean Turner wrote: > I hadn=E2=80=99t read it before, but it does what it says it=E2=80=99s go= ing to do and > it=E2=80=99s pretty darn short and straight forward. Ship it! > > spt > > > On Jun 2, 2017, at 16:39, Daniel Migault > wrote: > > > > Hi, > > > > This email starts a WGLC for draft-schaad-curdle-oid-registry[1]. The > draft received significant comments during the WG adoption and is expecte= d > to be close to its final version. Please provide your feed backs by June = 16. > > > > Yours, > > Rich and Daniel > > > > [1] https://datatracker.ietf.org/doc/draft-schaad-curdle-oid-registry/ > > _______________________________________________ > > Curdle mailing list > > Curdle@ietf.org > > https://www.ietf.org/mailman/listinfo/curdle > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --f403045ea6da46af960551783bec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Thank you for u= pdating the draft Jim and Rick. While reviewing the draft for the shepherd = -write up I came with a few comments/questions.=C2=A0 Please find my commen= ts below.

Yours,
Daniel
=C2= =A0
COMMENT A)

The type of the draft is current= ly "informational". According to RFC 2026 I am more incline to co= nsider that BCP would be more appropriated. Any thoughts on that ?

<= /div>
The draft does not discuss any technical content. The draft descr= ibes the set of OIDs that have been donated. In some ways, it also assigns = OIDs that have not been assigned by any other RFCs ( but only version-03 of= the pkix draft). It also describes the creation of an IANA registry table,= as well as update procedure for adding new entries which includes, paramet= ers to provide, the review process to follow and the way the arc can be ext= ended.

In that sense according to RFC2026 the document is essential= ly documenting IETF operations and so BCP seems the appropriated type.
<= br>
COMMENT B)

It might my fault as I commented on the ea= rlier version the references [I-D.ietf-curdle-pki= x] for=20 id-EdDSA25516-ph and id-EdDSA448-ph. It looks confusing to have OIDs reserv= ed for a specific Description while not being assigned. As we have the inte= ntion to keep these OIDs, I think you opened a better path to have a RFC as= a reference than having an old version of a draft.

I interpret the= the following text as explaining why we ended up with=20 id-EdDSA25516-ph and id-EdDSA448-ph.

"""
   After those registrations were
   done, there were still some unused values that can be used for other
   security groups, there were still some unused values.
""&qu=
ot;

Placing the current document as the Reference would clarif= y, in my opinion, the status of these OIDs. It may be useful to add some te= xt that provides more explication with an reference to [I-D.ietf-curdle-pkix]-03. As the RFC editor will probably replac= e [I-D.ietf-curdle-pkix] with the RFC number,= It might also be better to have a specific informational reference.=C2=A0 = =C2=A0



COMMENT C)

The draft sa= ys:

"""
IANA is asked=
 to create one new registry table.

2.1.  "SMI Security for Cryptographic Algorithms"=
; Registry

Within the SMI-numbers registry, add an "SMI Security for
Cryptographic Algorithms" table with the three columns:
&qu= ot;""
Maybe we should also specify that the SMI Security = for Cryptographic=20 Algorithm registry is a sub-item of the "SMI Security Codes Registries= ".


I believe it would be useful to have an URL as an infor= mational=20 reference for both the "SMI-numbers registry" as well as for &quo= t;SMI Security Codes Registries".

https://www.iana.org/assignm= ents/smi-numbers/smi-numbers.xhtml
https://www.iana.o= rg/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-26

Although I am not aware of a registration procedure for these tables and = the current, I believe it would be useful to specify explicitly all fields = associated to the table.
=C2=A0=C2=A0=C2=A0 - Registration: Proce= dure Although it can be inferred from the current text. I believe it is hel= pful to the IANA to have the exact filed value associated to all fields.
=C2=A0=C2=A0=C2=A0 - Description: The description is usually the ar= c ID, maybe in our case we should add the range of provided OIDs.
<= div>
=C2=A0=C2=A0=C2=A0 - Reference: It seems to me that the curre= nt document would be appropriated.
=C2=A0 =C2=A0 - Expert: Th= e Registration Procedure mentions Expert review. I am not sure experts shou= ld be listed in the in the RFC RFC5226=C2=A0 appointed by IESG.=C2=A0
<= /div>
=C2=A0
=C2=A0
=C2=A0

On= Sat, Jun 3, 2017 at 9:48 AM, Sean Turner <sean@sn3rd.com> wrot= e:
I hadn=E2=80=99t read it before, but i= t does what it says it=E2=80=99s going to do and it=E2=80=99s pretty darn s= hort and straight forward.=C2=A0 Ship it!

spt

> On Jun 2, 2017, at 16:39, Daniel Migault <daniel.migault@ericsson.com> wrote:
>
> Hi,
>
> This email starts a WGLC for draft-schaad-curdle-oid-registry[1].= The draft received significant comments during the WG adoption and is expe= cted to be close to its final version. Please provide your feed backs by Ju= ne 16.
>
> Yours,
> Rich and Daniel
>
> [1] https://datatracker.ietf.= org/doc/draft-schaad-curdle-oid-registry/
> __________________= _____________________________
> Curdle mailing list
> Curdle@ietf.org
> https://www.ietf.org/mailman/listinfo/curdle

_______________________________________________
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle

--f403045ea6da46af960551783bec-- From nobody Thu Jun 8 14:36:54 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E138129459 for ; Thu, 8 Jun 2017 14:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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=augustcellars.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 4ggjHyfsEVmh for ; Thu, 8 Jun 2017 14:36:48 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF2EE128D40 for ; Thu, 8 Jun 2017 14:36:47 -0700 (PDT) Content-Type: multipart/alternative; boundary="----=_NextPart_000_03B0_01D2E064.A53326B0" Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1496957804; h=from:subject:to:date:message-id; bh=SQ9mXreYs+78LQmoPEafts6pRqTtITO4bBXO4d811vA=; b=CAeigQnsxjaIhpXcnD2XpXZoQNouKNqYOiIGw31ek5nQzt+kkKihaNe3lfhJUyEMKaABrpqs9Iy ZK8uArrURaxTZ0FaH1DNpfK8AvMaw0LqPMvdz1onK1mtU/MS88sVm04pH9F9pRU7UtfAgXhEjVbtF EbyuWcXYYM362mpJJqbmsTsfCqh2IFnHbrc5MtSLKhMzvi/PkrPuYg43hgByOHz5P7jzZKVxYBGab 2lXVNvfnz1nZu8sDR3vBjuoS6kLV4+afPjvxTc5nbwmbKZgLLoWzy6TlV2f9LpywfsHhqPDACfu/Y FKPM1Mme5Znej0ljEB7oiu9M3VZ6V0IhS4mA== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 8 Jun 2017 14:36:43 -0700 Received: from Hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 8 Jun 2017 14:36:41 -0700 From: Jim Schaad To: 'Daniel Migault' , 'Sean Turner' CC: 'curdle' References: <3895FA29-6856-4024-955F-D8C0CBADF42A@sn3rd.com> In-Reply-To: Date: Thu, 8 Jun 2017 14:36:39 -0700 Message-ID: <03af01d2e09f$518e7c40$f4ab74c0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJb1xZwqGaWy4iJzjCFcw91l4MwcAKUrU/kAn9JjwCg4OMk4A== X-Originating-IP: [24.21.96.37] Archived-At: Subject: Re: [Curdle] WGLC draft-schaad-curdle-oid-registry X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 21:36:51 -0000 ------=_NextPart_000_03B0_01D2E064.A53326B0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Daniel = Migault Sent: Thursday, June 8, 2017 12:55 PM To: Sean Turner Cc: curdle Subject: Re: [Curdle] WGLC draft-schaad-curdle-oid-registry =20 Hi,=20 Thank you for updating the draft Jim and Rick. While reviewing the draft = for the shepherd -write up I came with a few comments/questions. Please = find my comments below. Yours,=20 Daniel =20 COMMENT A)=20 The type of the draft is currently "informational". According to RFC = 2026 I am more incline to consider that BCP would be more appropriated. = Any thoughts on that ? The draft does not discuss any technical content. The draft describes = the set of OIDs that have been donated. In some ways, it also assigns = OIDs that have not been assigned by any other RFCs ( but only version-03 = of the pkix draft). It also describes the creation of an IANA registry = table, as well as update procedure for adding new entries which = includes, parameters to provide, the review process to follow and the = way the arc can be extended.=20 In that sense according to RFC2026 the document is essentially = documenting IETF operations and so BCP seems the appropriated type. [JLS] I am not sure how you would presume that this could be a BCP? = What practices are we recommending that be followed? I think that this = makes far more sense as informational. There is nothing that says that = an informational draft be technical. Lots of informational drafts are = about procedures or about thought processes. I would keep this where it = is. =20 COMMENT B)=20 It might my fault as I commented on the earlier version the references = [I-D.ietf-curdle-pkix = ] for id-EdDSA25516-ph and id-EdDSA448-ph. It looks = confusing to have OIDs reserved for a specific Description while not = being assigned. As we have the intention to keep these OIDs, I think you = opened a better path to have a RFC as a reference than having an old = version of a draft.=20 I interpret the the following text as explaining why we ended up with = id-EdDSA25516-ph and id-EdDSA448-ph.=20 """ After those registrations were done, there were still some unused values that can be used for other security groups, there were still some unused values. """ Placing the current document as the Reference would clarify, in my = opinion, the status of these OIDs. It may be useful to add some text = that provides more explication with an reference to = [I-D.ietf-curdle-pkix = ]-03. As the RFC editor will probably replace = [I-D.ietf-curdle-pkix = ] with the RFC number, It might also be better to have = a specific informational reference. =20 [JLS] There is a request in the XML that the RFC editor make sure that = this specific reference point to the version of the ID and not the RFC. = However, it gets messy if you have [draft] and [draft-3] I the same = document as well. Visually, it is currently a hard thing to do. COMMENT C) The draft says: """ IANA is asked to create one new registry table. = 2.1. "SMI Security for Cryptographic Algorithms" Registry =20 Within the SMI-numbers registry, add an "SMI Security for Cryptographic Algorithms" table with the three columns: """ Maybe we should also specify that the SMI Security for Cryptographic = Algorithm registry is a sub-item of the "SMI Security Codes Registries". = I believe it would be useful to have an URL as an informational = reference for both the "SMI-numbers registry" as well as for "SMI = Security Codes Registries".=20 https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-number= s-26 Although I am not aware of a registration procedure for these tables and = the current, I believe it would be useful to specify explicitly all = fields associated to the table.=20 - Registration: Procedure Although it can be inferred from the = current text. I believe it is helpful to the IANA to have the exact = filed value associated to all fields.=20 - Description: The description is usually the arc ID, maybe in our = case we should add the range of provided OIDs. - Reference: It seems to me that the current document would be = appropriated. - Expert: The Registration Procedure mentions Expert review. I am = not sure experts should be listed in the in the RFC RFC5226 appointed = by IESG. =20 =20 [JLS] This is really a bit of a mess, because it does not really belong = under the SMI Security Codes section if one were being string. It is = not prefixed with the OID defined for that section. It is unfortunate = that Russ had all of the PKIX and S/MIME registries placed below that = section. However using the registry template associated with that would = not really be correct. I may talk to IANA during the process of final = registration to see if we can create a new header and move all of the = registries into that new header but I don=E2=80=99t want to do that as = part of this document as it probably would be messy to state. This type = of decision is normally made on the fly during the registration process = and is not normally called out explicitly. =20 Experts are normally suggested by the authors, chairs or shepherds of = the document during the IESG review process at the request of the AD.=20 =20 We will end up with an entry that looks like = https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#security-s= mime-3 which provides a template of what is defined here. =20 jim =20 =20 =20 On Sat, Jun 3, 2017 at 9:48 AM, Sean Turner > wrote: I hadn=E2=80=99t read it before, but it does what it says it=E2=80=99s = going to do and it=E2=80=99s pretty darn short and straight forward. = Ship it! spt > On Jun 2, 2017, at 16:39, Daniel Migault > wrote: > > Hi, > > This email starts a WGLC for draft-schaad-curdle-oid-registry[1]. The = draft received significant comments during the WG adoption and is = expected to be close to its final version. Please provide your feed = backs by June 16. > > Yours, > Rich and Daniel > > [1] https://datatracker.ietf.org/doc/draft-schaad-curdle-oid-registry/ > _______________________________________________ > Curdle mailing list > Curdle@ietf.org =20 > https://www.ietf.org/mailman/listinfo/curdle _______________________________________________ Curdle mailing list Curdle@ietf.org =20 https://www.ietf.org/mailman/listinfo/curdle =20 ------=_NextPart_000_03B0_01D2E064.A53326B0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

 

From: = Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Daniel = Migault
Sent: Thursday, June 8, 2017 12:55 PM
To: = Sean Turner <sean@sn3rd.com>
Cc: curdle = <curdle@ietf.org>
Subject: Re: [Curdle] WGLC = draft-schaad-curdle-oid-registry

 

Hi, =

Thank you for updating the draft Jim and = Rick. While reviewing the draft for the shepherd -write up I came with a = few comments/questions.  Please find my comments = below.

Yours, =

Daniel

 

COMMENT A)

The type of the draft = is currently "informational". According to RFC 2026 I am more = incline to consider that BCP would be more appropriated. Any thoughts on = that ?

The draft does not discuss any technical = content. The draft describes the set of OIDs that have been donated. In = some ways, it also assigns OIDs that have not been assigned by any other = RFCs ( but only version-03 of the pkix draft). It also describes the = creation of an IANA registry table, as well as update procedure for = adding new entries which includes, parameters to provide, the review = process to follow and the way the arc can be extended.

In that = sense according to RFC2026 the document is essentially documenting IETF = operations and so BCP seems the appropriated type.

[JLS] I am not sure how you would presume that = this could be a BCP?=C2=A0 What practices are we recommending that be = followed?=C2=A0 I think that this makes far more sense as = informational.=C2=A0 There is nothing that says that an informational = draft be technical.=C2=A0 Lots of informational drafts are about = procedures or about thought processes.=C2=A0 I would keep this where it = is.

 

COMMENT B)

It might my fault as I commented on = the earlier version the references [I-D.ietf-curdle-pkix] for id-EdDSA25516-ph = and id-EdDSA448-ph. It looks confusing to have OIDs reserved for a = specific Description while not being assigned. As we have the intention = to keep these OIDs, I think you opened a better path to have a RFC as a = reference than having an old version of a draft.

I interpret the = the following text as explaining why we ended up with id-EdDSA25516-ph = and id-EdDSA448-ph. =

"""

=C2=A0=C2=A0 After those =
registrations were
=C2=A0=C2=A0 done, there were =
still some unused values that can be used for =
other
=C2=A0=C2=A0 security groups, there were =
still some unused values.
"""


Placing the current = document as the Reference would clarify, in my opinion, the status of = these OIDs. It may be useful to add some text that provides more = explication with an reference to [I-D.ietf-curdle-pkix]-03. As the RFC editor = will probably replace [I-D.ietf-curdle-pkix] with the RFC number, = It might also be better to have a specific informational = reference.   

[JLS] There = is a request in the XML that the RFC editor make sure that this specific = reference point to the version of the ID and not the RFC. However, it = gets messy if you have [draft] and [draft-3] I the same document as = well.=C2=A0 Visually, it is currently a hard thing to = do.

COMMENT = C)

The draft = says:

"""

IANA is asked to =
create one new registry table.

2.1.=C2=A0 "SMI Security for = Cryptographic Algorithms" = Registry

 
Within =
the SMI-numbers registry, add an "SMI Security =
for
Cryptographic Algorithms" table with the =
three columns:

"""

Maybe we should also = specify that the SMI Security for Cryptographic Algorithm registry is a = sub-item of the "SMI Security Codes Registries".


I = believe it would be useful to have an URL as an informational reference = for both the "SMI-numbers registry" as well as for "SMI = Security Codes Registries".

h= ttps://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml
https://www.iana.org/assignments/smi-numbers/smi-numbers.xh= tml#smi-numbers-26

Although = I am not aware of a registration procedure for these tables and the = current, I believe it would be useful to specify explicitly all fields = associated to the table.

    - Registration: Procedure Although = it can be inferred from the current text. I believe it is helpful to the = IANA to have the exact filed value associated to all fields. =

    - = Description: The description is usually the arc ID, maybe in our case we = should add the range of provided = OIDs.

    - Reference: It seems to me that = the current document would be appropriated.

    - Expert: The Registration Procedure = mentions Expert review. I am not sure experts should be listed in the in = the RFC RFC5226  appointed by IESG.  =

 

[JLS] This is really a = bit of a mess, because it does not really belong under the SMI Security = Codes section if one were being string.=C2=A0 It is not prefixed with = the OID defined for that section.=C2=A0 It is unfortunate that Russ had = all of the PKIX and S/MIME registries placed below that section.=C2=A0 = However using the registry template associated with that would not = really be correct.=C2=A0 I may talk to IANA during the process of final = registration to see if we can create a new header and move all of the = registries into that new header but I don=E2=80=99t want to do that as = part of this document as it probably would be messy to state.=C2=A0 This = type of decision is normally made on the fly during the registration = process and is not normally called out = explicitly.

 

Experts are normally = suggested by the authors, chairs or shepherds of the document during the = IESG review process at the request of the AD.

 

We will end up with an = entry that looks like https://www.iana.org/assignments/smi-numbers/smi-numbers.= xhtml#security-smime-3 which provides a template of what is defined = here.

 

jim

 

  =

 

On Sat, = Jun 3, 2017 at 9:48 AM, Sean Turner <sean@sn3rd.com> = wrote:

I = hadn=E2=80=99t read it before, but it does what it says it=E2=80=99s = going to do and it=E2=80=99s pretty darn short and straight = forward.  Ship it!

spt

> = _______________________________________________
> Curdle mailing = list
> Curdle@ietf.org
> https://www.ietf.org/mailman/listinfo/curdle
_______________________________________________
Curdle mailing = list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle

 

------=_NextPart_000_03B0_01D2E064.A53326B0-- From nobody Sat Jun 10 12:50:09 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC971267BB for ; Sat, 10 Jun 2017 12:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, 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=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 LfVilCEzrIQd for ; Sat, 10 Jun 2017 12:50:05 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 528BA126C3D for ; Sat, 10 Jun 2017 12:50:05 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id m77so14840169lfe.0 for ; Sat, 10 Jun 2017 12:50:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=5BNWviA8TH/5dHjl/xLlSO2iboDnqriAEaruPKii/4E=; b=DbyX3FoWRGh4y2dtUkfgyxYIcdcSmlO6DPFIOcmEUiuK+24Qu2mmjreDLdiST+z9r5 W48QI+3+kjoAFCwR0ZrmOsrWF1STdfl3eD0qbbinzZqSyB2kuAyk0U5KmCity6k3grT+ ZA41f4k7yZhJh/mTp4LrD+RAXAgdJtWjfS8ESgWN6KCW6Zp8faUbg4TCbLJiJAnr/qbz UaKxgOHn1PH0BUmuMXIjCVWrG6ZsjkE7D2A4+0VuyTQcaXShdji80rrlYlWQZ9KloDKg i+4ITlFG13FvPLzYaP+JGWdanlpfbom14MTFiaChZVUUX1UmGef+Wa2+5tLnAQM3YTuZ aj9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=5BNWviA8TH/5dHjl/xLlSO2iboDnqriAEaruPKii/4E=; b=DMNcGGBOT9y0jclQ/ZA7rfU9pY4dku8mwJOXI17LzYlMuCUdGJw6gyKu7wqq7Tr9gw h36pgKh05Z+htcZM6osgnn7uqJnkWuvTsvgCWOGR1sy07lpkjqGcOcQbS1onGJprKIRH tJoTl0qISafNUL+AA3eGY3wS+NsMCad8RjCNqUnckkQTs2XdlB96TaFFPByggKbN6BoI tYnohDugGlAQtvWqc6Sw+XiQ0m3ygws3IZO6uiu6pXIpPU1nuba0C6IqNO7HAsGi+HYB Lp6tCJp75XPPUaQ524Vx/mEvyW6l/8a0Hv0obZHiYtOz/8c39N+nRYeWx1UnGRoDsBVb tWBg== X-Gm-Message-State: AKS2vOw36510IqeaSgDgImgC7nnW7dlBGFg4Gmwq0kkVhXjUHFM/WoQZ PnLp1WviW+GlZYOmxFjJUMiitGT3EhL8 X-Received: by 10.25.125.67 with SMTP id y64mr1729686lfc.147.1497124203369; Sat, 10 Jun 2017 12:50:03 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.15.26 with HTTP; Sat, 10 Jun 2017 12:50:02 -0700 (PDT) From: Daniel Migault Date: Sat, 10 Jun 2017 15:50:02 -0400 X-Google-Sender-Auth: Oq2tEyo4zt1U5a23NgIoL93AAAE Message-ID: To: curdle Content-Type: multipart/alternative; boundary="001a114a575c53a1060551a0644a" Archived-At: Subject: [Curdle] Review of draft-ietf-curdle-ssh-dh-group-exchange X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 19:50:08 -0000 --001a114a575c53a1060551a0644a Content-Type: text/plain; charset="UTF-8" Hi, Thank you for writing the draft. The draft is pretty clear and it is nice you provided explicitly the sections that needs to be updated. I believe the document is ready for WGLC. Yours, Daniel Please find my comments below: COMMENT A) I suggest to have the motivations of raising the minimum value in the introduction instead of in the content of the document. I suggest something around the following lines for the introduction: Recent research [LOGJAM] strongly suggests that DH groups that are 1024 bits can be broken by state actors, and possibly an organization with enough computing resources. The authors show how they are able to break 768 bits DH group and extrapolate the attack to 1024 bits DH groups. In their analysis, they show that breaking 1024 bits can be done with enough computing resources. [RFC4419] specifies a recommended minimum size of 1024 bits for k, which is the modulus length of the DH Group. It also suggests that in all cases, the size of the group needs be at least 1024 bits. This document updates [RFC4419] so that the minimum recommended size be 2048 bits. COMMENT B) I suggest the document expresses a recommendation outside the scope of the update, and that updates of 4419 are left as informational. Of course in our case, the main recommendation is similar to one update. I expect the main message of the document to be: Servers and clients SHOULD support groups with a modulus length of k bits, where 2048 <= k <= 8192. So, I suggest something around the following lines for the section 2: Servers and clients SHOULD support groups with a modulus length of k bits where 2048 <= k <= 8192. This document updates [RFC4419] as described below: * section 3 Paragraph 9 is updated as follows: Servers and clients SHOULD support groups with a modulus length of k bits where 2048 <= k <= 8192. The recommended minimum values for min and max are 2048 and 8192, respectively. * Section 3 Paragraph 11 is updated as follows: In all cases, the size of the group SHOULD be at least 2048 bits. --001a114a575c53a1060551a0644a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Thank you for w= riting the draft. The draft is pretty clear and it is nice you provided exp= licitly the sections that needs to be updated. I believe the document is re= ady for WGLC.

Yours,
Daniel

Please find my comments below:

COMMENT A)

I suggest to = have the motivations of raising the minimum value in the introduction instead of in the content of the document.
= =C2=A0
I suggest something around the following lines for the introducti= on:

=C2=A0=C2=A0 Recent research [LOGJAM] strongly suggests that DH = groups that are
=C2=A0=C2=A0 1024 bits can be broken by state actors, an= d possibly an organization
=C2=A0=C2=A0 with enough computing resources.= =C2=A0 The authors show how they are able
=C2=A0=C2=A0 to break 768 bits= DH group and extrapolate the attack to 1024 bits DH
=C2=A0=C2=A0 groups= .=C2=A0 In their analysis, they show that breaking 1024 bits can be
=C2= =A0=C2=A0 done with enough computing resources.
=C2=A0=C2=A0
=C2=A0= =C2=A0 [RFC4419] specifies a recommended minimum size of 1024 bits for k,=C2=A0=C2=A0 which is the modulus length of the DH Group.=C2=A0 It also s= uggests that
=C2=A0=C2=A0 in all cases, the size of the group needs be a= t least 1024 bits.
=C2=A0=C2=A0 This document updates [RFC4419] so that = the minimum recommended size
=C2=A0=C2=A0 be 2048 bits.


COMMENT B)

I suggest the document expresses a recommendation = outside the scope of the update, and that updates of 4419 are left as infor= mational. Of course in our case, the main recommendation is similar to one = update.

I expect the main message of the document to be:
Servers and clients SHOULD support groups with a modul=
us length of k
   bits, where 2048 <=3D k <=3D 8192.

So, I suggest some= thing around the following lines for the section 2:

=C2=A0=C2=A0 Ser= vers and clients SHOULD support groups with a modulus length of k
=C2= =A0=C2=A0 bits where 2048 <=3D k <=3D 8192.

=C2=A0=C2=A0
= =C2=A0=C2=A0 This document updates [RFC4419] as described below:
=C2=A0= =C2=A0 * section 3 Paragraph 9 is updated as follows: Servers and clients <= br>=C2=A0=C2=A0 SHOULD support groups with a modulus length of k bits where=
=C2=A0=C2=A0 2048 <=3D k <=3D 8192.=C2=A0 The recommended minimu= m values for min and max
=C2=A0=C2=A0 are 2048 and 8192, respectively.= =C2=A0
=C2=A0=C2=A0
=C2=A0=C2=A0 * Section 3 Paragraph 11 is update= d as follows: In all cases, the size
=C2=A0=C2=A0 of the group SHOULD be= at least 2048 bits.






--001a114a575c53a1060551a0644a-- From nobody Sun Jun 11 10:44:53 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 596B412969E for ; Sun, 11 Jun 2017 10:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, 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=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 4kfCRLzUqI_g for ; Sun, 11 Jun 2017 10:44:50 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85560129601 for ; Sun, 11 Jun 2017 10:44:49 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id o83so43708951lff.3 for ; Sun, 11 Jun 2017 10:44:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ix45UY85nzgydaXghLicth6e73arqIHGRhEEuX9vn6s=; b=ApE0B4kowiqji8iL2CivfPHGsisRFrzu9iDBYbEy6uBLgzlUBVGvzEghRBtcIWOXTA lon5/tksoy9C7L1AjaiuBScPmpU4+yDbYHyYuEyNFpGxBmK+RgnjjCjQTpywBUgJRmiv PQZogmYslTqQV3G+QRC2dF0ypAVT00tBMJz0guq8dgRabedYZKiiPhu/xbiHF7zy0IGX iRc15iM23iwg+N/jB04cciO7Gas2bQAY39Mjye3p8fv1y3OAijh6FoFdrRsdJvcQcnXO vmK5m4sAAoMT1dOgZNNmIRSjuZSf0cHDJlqEFi/Np/6DLBYG2jWXSvvIlS4h9iG+XeZx 6Zaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ix45UY85nzgydaXghLicth6e73arqIHGRhEEuX9vn6s=; b=gM7kdrWtnoJrrcDxeTRJ4Qf07IcAAsMf3pCERmhhMjcdBjjvOiZ5bJPog9eH52bbJb qhMlVJ1DW62Ba+g3cl2GK+Qoq/gJADf8jaNtaZ8doeqEIqeOMsIrOW64hc+xn32AQ8pR KOxxviNFqXfRT/yn0BRHMFuKi8TLExLJKse7osBP5gYa5PjQvBA3EoiUW8vyyIxwGyiS SoQiebf/0ckIRvAN89Tkv/sbocoZxo3c2fsjedhSUNZgP1aggtaxhQqhSuCAmkER1MYu J1WeIK0fENCDLtqJIZq4H8c68gq5XUj6tx4FY99ADFcjIIelNG05+88OU6TbM/Z07htB dFiw== X-Gm-Message-State: AODbwcBswF/AoXCYw7krQeiDFLhQ2XOqXTSDZwAnEIzHjcbgmOS+0/Tw cVpsFPfWJbyKcqJFBZMPNfSuEDwAyQ== X-Received: by 10.46.21.73 with SMTP id 9mr13464129ljv.118.1497203087811; Sun, 11 Jun 2017 10:44:47 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.15.26 with HTTP; Sun, 11 Jun 2017 10:44:47 -0700 (PDT) In-Reply-To: <1496656603.929.114.camel@redhat.com> References: <20170521202553.GQ39245@kduck.kaduk.org> <1496655577.929.112.camel@redhat.com> <1496656603.929.114.camel@redhat.com> From: Daniel Migault Date: Sun, 11 Jun 2017 13:44:47 -0400 X-Google-Sender-Auth: YzrIAxmKHLUu5WNsAZj9Oit4Mzo Message-ID: To: Simo Sorce Cc: Benjamin Kaduk , curdle Content-Type: multipart/alternative; boundary="f403045f776a34adf70551b2c265" Archived-At: Subject: Re: [Curdle] review of draft-ietf-curdle-gss-keyex-sha2-00 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2017 17:44:52 -0000 --f403045f776a34adf70551b2c265 Content-Type: text/plain; charset="UTF-8" Hi, Does the current version reached consensus ? If anyone thinks otherwise please raise your concern as soon as possible. We would like to have this draft in WGLC next week. Yours, Daniel On Mon, Jun 5, 2017 at 5:56 AM, Simo Sorce wrote: > On Mon, 2017-06-05 at 05:39 -0400, Simo Sorce wrote: > > On Sun, 2017-05-21 at 15:25 -0500, Benjamin Kaduk wrote: > > > Generally, this document is in good shape, and I think we should > > > move > > > it forward. > > > > > > My main comment/objection is that the security considerations > > > should > > > note that the combination of GSS key exchange, GSS delegated > > > credentials, and use of insecure DNS to modify the requested server > > > principal name result in a situation where an attacker can easily > > > obtain a valid TGT+key for the client principal. Obviously, RFCs > > > 4462, 4120, etc. all implore us to not use insecure DNS in such a > > > fashion, but nonetheless major Kerberos libraries continue to do > > > so. > > > At MIT we have disabled GSS key exchange for ssh because we default > > > to GSS credential delegation. > > > > I am quite hesitant to call additional security considerations in a > > document that is substantially just updating an existing document > > without introducing any new security related method that needs > > additional considerations. However I added a reference to the > > Security > > Considerations of 4120 as well. I do not think we should really do > > more, this issue is (or should be) a well know problem and in no way > > specific to SSH key exchanges. > > I posted a new draft with the corrections noted below but with the > exception of adding 4120 as I stated here. > > Although krb5 is the most (or only ?) mechanism RFC 4462 and this draft > are definitely not mechanism specific (they only recommend against > using SPNEGO not any other mechanism), and it doesn't feel right to me > to add security considerations to a specific mechanism (delegation is a > krb5 mechanism feature in this case, not a feature of the SSH Key > exchange) in an amendment document that is not changing anything with > regard to the initial RFC 4462 security properties. > > If you do not agree, please provide language that you think would be > appropriate. > > If anyone else has comments on whether we should add or not additional, > mechanism specific, security considerations, please let me know. > > Simo. > > > > Some other nit-level comments: > > > > meta-nit, your page numbers seem to be off a bit, I hope you're > > reading > > the document I posted in curdle and not a previous version. > > > > > On page 8, in step 5 of the procedure, do we want to give a > > > reference or two for the shared-secret computation above the > > > existing prose? > > > > What do you have in mind? I think we already have all the relevant > > references at the top or in the 1st step. > > > > > (Also, is the d_U and q_V terminology standard from > > > some related document? I did not see them in RFC 4462.) > > > > No, they are new handles used to avoid repeating the client or > > service > > specific value. > > IE, d_U stands for 'd_C for the client or d_S for the server' and > > q_V stands for 'q_S for the client or q_C for the server'. > > Do you think this is confusing ? > > > > > Also on page 8, step 6 could further clarify that this only occurs > > > when the server's final call to GSS_Accept_sec_context() returns > > > GSS_S_COMPLETE; anything else is an error condition. > > > > Already explained in step 8, I think that is sufficient. > > > > > Relatedly, the > > > way the GSS context negotiation loop's exit conditions are split > > > between step 6 and step 2 confused me a little on first read, but > > > it > > > seems correct, and along with the RFC 7546 reference I think > > > readers > > > will be okay. > > > > It is really hard to condense everything in few steps and maintain > > perfect clarity on all fronts, but I think the current text strikes > > the > > right balance, between being more informative than the document we > > replace, without being overly verbose and distracting from the actual > > core of the matter and has enough references to clarify with original > > documents any doubts one may have. > > > > > On page 11, the description of the HASH input has a couple of > > > inconsistencies -- in RFC 4462, V_S is the server's "version" > > > string, though here we have it as the server's "identification" > > > string. I don't think that's a problem per se, but wanted to note > > > it just in case. Also, V_S excludes CR and LF, but V_C excludes CR > > > and NL; we should probably be consistent about NL vs. LF. > > > > Thanks for pointing these out, I am fixing these to say server > > version > > for consistency with 4462 and will use NL again for consistency with > > 4462 which is itself inconsistent as it uses CRLF in some places ... > > > > > In sections 5.2.2 and later we continue to include refeferences for > > > MD5, DER, and Base64; RFC 4462 only included those references in > > > the > > > first corresponding subsection. At this point, it's probably not > > > worth making any changes, though. > > > > I agree it is not worth making changes here. > > > > > And one editorial note: > > > > > > On page 6, "non- zero" should not have a space. > > > > Thanks. > > I will submit -01 with these corrections shortly. > > > > Simo. > > > > _______________________________________________ > > Curdle mailing list > > Curdle@ietf.org > > https://www.ietf.org/mailman/listinfo/curdle > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --f403045f776a34adf70551b2c265 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Does=C2=A0 the current ve= rsion reached consensus ? If anyone=C2=A0 thinks otherwise please raise you= r concern as soon as possible. We would like to have this draft in WGLC nex= t week.

Yours,
Daniel

On Mon, Jun 5, 2017 at 5:56 AM, Simo= Sorce <simo@redhat.com> wrote:
On Mon, 2017-06-05 at 05:39 -0400, Simo Sorce wrote: > On Sun, 2017-05-21 at 15:25 -0500, Benjamin Kaduk wrote:
> > Generally, this document is in good shape, and I think we should<= br> > > move
> > it forward.
> >
> > My main comment/objection is that the security considerations
> > should
> > note that the combination of GSS key exchange, GSS delegated
> > credentials, and use of insecure DNS to modify the requested serv= er
> > principal name result in a situation where an attacker can easily=
> > obtain a valid TGT+key for the client principal.=C2=A0=C2=A0Obvio= usly, RFCs
> > 4462, 4120, etc. all implore us to not use insecure DNS in such a=
> > fashion, but nonetheless major Kerberos libraries continue to do<= br> > > so.
> > At MIT we have disabled GSS key exchange for ssh because we defau= lt
> > to GSS credential delegation.
>
> I am quite hesitant to call additional security considerations in a > document that is substantially just updating an existing document
> without introducing any new security related method that needs
> additional considerations. However I added a reference to the
> Security
> Considerations of 4120 as well. I do not think we should really do
> more, this issue is (or should be) a well know problem and in no way > specific to SSH key exchanges.

I posted a new draft with the corrections noted below but with the exception of adding 4120 as I stated here.

Although krb5 is the most (or only ?) mechanism RFC 4462 and this draft
are definitely not mechanism specific (they only recommend against
using SPNEGO not any other mechanism), and it doesn't feel right to me<= br> to add security considerations to a specific mechanism=C2=A0(delegation is = a
krb5 mechanism feature in this case, not a feature of the SSH Key
exchange) in an amendment document that is not changing anything with
regard to the initial RFC 4462 security properties.

If you do not agree, please provide language that you think would be
appropriate.

If anyone else has comments on whether we should add or not additional,
mechanism specific, security considerations, please let me know.

Simo.

> > Some other nit-level comments:
>
> meta-nit, your page numbers seem to be off a bit, I hope you're > reading
> the document I posted in curdle and not a previous version.
>
> > On page 8, in step 5 of the procedure, do we want to give a
> > reference or two for the shared-secret computation above the
> > existing prose?
>
> What do you have in mind? I think we already have all the relevant
> references at the top or in the 1st step.
>
> > =C2=A0=C2=A0(Also, is the d_U and q_V terminology standard from > > some related document?=C2=A0=C2=A0I did not see them in RFC 4462.= )
>
> No, they are new handles used to avoid repeating the client or
> service
> specific value.
> IE, d_U stands for 'd_C for the client or d_S for the server' = and
> q_V stands for 'q_S for the client or q_C for the server'.
> Do you think this is confusing ?
>
> > Also on page 8, step 6 could further clarify that this only occur= s
> > when the server's final call to GSS_Accept_sec_context() retu= rns
> > GSS_S_COMPLETE; anything else is an error condition.
>
> Already explained in step 8, I think that is sufficient.
>
> > Relatedly, the
> > way the GSS context negotiation loop's exit conditions are sp= lit
> > between step 6 and step 2 confused me a little on first read, but=
> > it
> > seems correct, and along with the RFC 7546 reference I think
> > readers
> > will be okay.
>
> It is really hard to condense everything in few steps and maintain
> perfect clarity on all fronts, but I think the current text strikes > the
> right balance, between being more informative than the document we
> replace, without being overly verbose and distracting from the actual<= br> > core of the matter and has enough references to clarify with original<= br> > documents any doubts one may have.
>
> > On page 11, the description of the HASH input has a couple of
> > inconsistencies -- in RFC 4462, V_S is the server's "ver= sion"
> > string, though here we have it as the server's "identifi= cation"
> > string.=C2=A0=C2=A0I don't think that's a problem per se,= but wanted to note
> > it just in case.=C2=A0=C2=A0Also, V_S excludes CR and LF, but V_C= excludes CR
> > and NL; we should probably be consistent about NL vs. LF.
>
> Thanks for pointing these out, I am fixing these to say server
> version
> for consistency with 4462 and will use NL again for consistency with > 4462 which is itself inconsistent as it uses CRLF in some places ... >
> > In sections 5.2.2 and later we continue to include refeferences f= or
> > MD5, DER, and Base64; RFC 4462 only included those references in<= br> > > the
> > first corresponding subsection.=C2=A0=C2=A0At this point, it'= s probably not
> > worth making any changes, though.
>
> I agree it is not worth making changes here.
>
> > And one editorial note:
> >
> > On page 6, "non- zero" should not have a space.
>
> Thanks.
> I will submit -01 with these corrections shortly.
>
> Simo.
>
> _______________________________________________
> Curdle mailing list
> Curdle@ietf.org
> https://www.ietf.org/mailman/listinfo/curdle

_______________________________________________
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle

--f403045f776a34adf70551b2c265-- From nobody Sun Jun 11 11:17:34 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0010E129A9C for ; Sun, 11 Jun 2017 11:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, 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=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 0H0mOR1hN_OC for ; Sun, 11 Jun 2017 11:17:31 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::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 0B7A1129A97 for ; Sun, 11 Jun 2017 11:17:31 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id o83so43836105lff.3 for ; Sun, 11 Jun 2017 11:17:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=Ff5PrYfQ8sPgvcMRIVEMrmNLQ5Rfhrkp9Uugk56lqxs=; b=kAiMyFlkcvFxJxDWF+7Rohy/50bCrZpg2oiXYUdtxb5uW5+uwGJ3RUTuGDBCiSoK// 9Jsl+GwajEDKElx2ytBsL6x08xnqZGgteVDT0csvf1HYvrFMSNJB+6n3+HF3YKNOVu+4 5f9hYmE0YkjnAKzs4DR2Qz5GlgX7WGDVBYjm+MTr2wyMc06yI5xNyoaSA3sBe+mU7wUc +HxNSxAUsKu233E3yxjXhOpAVeJvcqmul2V+oIA6ZMIiBYqOOy70PMdDrkWhPBe2HpVx k60KHqX7DWhGs4q0OkBaLOLnWpv1pKtEEh+d/s8SecHKuUJ08LD287kRwKEkQWmo1UNM NkeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=Ff5PrYfQ8sPgvcMRIVEMrmNLQ5Rfhrkp9Uugk56lqxs=; b=XceQFjfMN3rpNF7yrjF2lVZRcuq0Xp73H/juG1+3QRaZ6j6IsA/R8+4macaTd+yIFE PpYcWn/uIQDzj0k2wuLbaMesC6U5rJ/4Toc1v0QXtUI0fhHm73RPRlbWOsXfz+PHFHXP saApDo/l9oQePrP6sHyVjet7CetFHPdLNpAyFeW01x2eUvxxYU4jZgpnHCsT34d+WOKi G81Gp8imBYFNxilaPhMzlL/TSLm/WVjkLl4jwmbpmakXSuaAPQvdJq6AJZniG3PJxAfJ j2NKKSpxMthKQUKwyxqkIMdsdM6T456Wpiw/SxmRxp1g01d/vPmt8n0/BjQTGk+L4/sJ gM7A== X-Gm-Message-State: AODbwcDfvtbRz4cLuI4XQ9xGtA5yb0Fxn7ra8ohyJD83a1yhNevijbtp O0vldYQDVBkvqLG5lVuGbXi3QB7FNofN X-Received: by 10.46.83.11 with SMTP id h11mr15618127ljb.17.1497205049102; Sun, 11 Jun 2017 11:17:29 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.15.26 with HTTP; Sun, 11 Jun 2017 11:17:28 -0700 (PDT) In-Reply-To: References: From: Daniel Migault Date: Sun, 11 Jun 2017 14:17:28 -0400 X-Google-Sender-Auth: IugWD8JgjQ8ACE5PTrqA_6zG-0A Message-ID: To: curdle Content-Type: multipart/alternative; boundary="94eb2c1ce6de1b983c0551b337fe" Archived-At: Subject: Re: [Curdle] Review of draft-ietf-curdle-ssh-dh-group-exchange X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2017 18:17:33 -0000 --94eb2c1ce6de1b983c0551b337fe Content-Type: text/plain; charset="UTF-8" Hi, I believe it would also be appreciated the text also details interoperability with existing implementation using/proposing 1024 < k < 2048. Yours, Daniel On Sat, Jun 10, 2017 at 3:50 PM, Daniel Migault wrote: > Hi, > > Thank you for writing the draft. The draft is pretty clear and it is nice > you provided explicitly the sections that needs to be updated. I believe > the document is ready for WGLC. > > Yours, > Daniel > > Please find my comments below: > > COMMENT A) > > I suggest to have the motivations of raising the minimum value in the > introduction instead of in the content of the document. > > I suggest something around the following lines for the introduction: > > Recent research [LOGJAM] strongly suggests that DH groups that are > 1024 bits can be broken by state actors, and possibly an organization > with enough computing resources. The authors show how they are able > to break 768 bits DH group and extrapolate the attack to 1024 bits DH > groups. In their analysis, they show that breaking 1024 bits can be > done with enough computing resources. > > [RFC4419] specifies a recommended minimum size of 1024 bits for k, > which is the modulus length of the DH Group. It also suggests that > in all cases, the size of the group needs be at least 1024 bits. > This document updates [RFC4419] so that the minimum recommended size > be 2048 bits. > > > COMMENT B) > > I suggest the document expresses a recommendation outside the scope of the > update, and that updates of 4419 are left as informational. Of course in > our case, the main recommendation is similar to one update. > > I expect the main message of the document to be: > > Servers and clients SHOULD support groups with a modulus length of k > bits, where 2048 <= k <= 8192. > > So, I suggest something around the following lines for the section 2: > > Servers and clients SHOULD support groups with a modulus length of k > bits where 2048 <= k <= 8192. > > > This document updates [RFC4419] as described below: > * section 3 Paragraph 9 is updated as follows: Servers and clients > SHOULD support groups with a modulus length of k bits where > 2048 <= k <= 8192. The recommended minimum values for min and max > are 2048 and 8192, respectively. > > * Section 3 Paragraph 11 is updated as follows: In all cases, the size > of the group SHOULD be at least 2048 bits. > > > > > > > --94eb2c1ce6de1b983c0551b337fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I believe it would also b= e appreciated the text also details interoperability with existing implemen= tation using/proposing 1024 < k <=C2=A0 2048.

Yours,
Daniel

On Sat, Jun 10, 2017 at 3:50 PM, Daniel Migault <= ;daniel.mi= gault@ericsson.com> wrote:
=
Hi,

Thank you for w= riting the draft. The draft is pretty clear and it is nice you provided exp= licitly the sections that needs to be updated. I believe the document is re= ady for WGLC.

Yours,
Daniel

Please find my comments below:

COMMENT A)

I suggest to = have the motivations of raising the minimum value in the introduction instead of in the content of the document.
= =C2=A0
I suggest something around the following lines for the introducti= on:

=C2=A0=C2=A0 Recent research [LOGJAM] strongly suggests that DH = groups that are
=C2=A0=C2=A0 1024 bits can be broken by state actors, an= d possibly an organization
=C2=A0=C2=A0 with enough computing resources.= =C2=A0 The authors show how they are able
=C2=A0=C2=A0 to break 768 bits= DH group and extrapolate the attack to 1024 bits DH
=C2=A0=C2=A0 groups= .=C2=A0 In their analysis, they show that breaking 1024 bits can be
=C2= =A0=C2=A0 done with enough computing resources.
=C2=A0=C2=A0
=C2=A0= =C2=A0 [RFC4419] specifies a recommended minimum size of 1024 bits for k,=C2=A0=C2=A0 which is the modulus length of the DH Group.=C2=A0 It also s= uggests that
=C2=A0=C2=A0 in all cases, the size of the group needs be a= t least 1024 bits.
=C2=A0=C2=A0 This document updates [RFC4419] so that = the minimum recommended size
=C2=A0=C2=A0 be 2048 bits.


COMMENT B)

I suggest the document expresses a recommendation = outside the scope of the update, and that updates of 4419 are left as infor= mational. Of course in our case, the main recommendation is similar to one = update.

I expect the main message of the document to be:
Servers and clients SHOULD support=
 groups with a modulus length of k
   bits, where 2048 <=3D k <=3D 8192.

So, I suggest some= thing around the following lines for the section 2:

=C2=A0=C2=A0 Ser= vers and clients SHOULD support groups with a modulus length of k
=C2= =A0=C2=A0 bits where 2048 <=3D k <=3D 8192.

=C2=A0=C2=A0
= =C2=A0=C2=A0 This document updates [RFC4419] as described below:
=C2=A0= =C2=A0 * section 3 Paragraph 9 is updated as follows: Servers and clients <= br>=C2=A0=C2=A0 SHOULD support groups with a modulus length of k bits where=
=C2=A0=C2=A0 2048 <=3D k <=3D 8192.=C2=A0 The recommended minimu= m values for min and max
=C2=A0=C2=A0 are 2048 and 8192, respectively.= =C2=A0
=C2=A0=C2=A0
=C2=A0=C2=A0 * Section 3 Paragraph 11 is update= d as follows: In all cases, the size
=C2=A0=C2=A0 of the group SHOULD be= at least 2048 bits.







--94eb2c1ce6de1b983c0551b337fe-- From nobody Sun Jun 11 18:20:33 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFE7F127180 for ; Sun, 11 Jun 2017 18:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 tYk--yFcIWgq for ; Sun, 11 Jun 2017 18:20:26 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (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 7BE711200C1 for ; Sun, 11 Jun 2017 18:20:26 -0700 (PDT) X-AuditID: 12074424-2e7ff70000005c88-1e-593dec58680b Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 51.70.23688.85CED395; Sun, 11 Jun 2017 21:20:25 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id v5C1KNXM006898; Sun, 11 Jun 2017 21:20:24 -0400 Received: from kduck.kaduk.org (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.13.8/8.12.4) with ESMTP id v5C1KJ01016563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 11 Jun 2017 21:20:22 -0400 Date: Sun, 11 Jun 2017 20:20:19 -0500 From: Benjamin Kaduk To: Simo Sorce Cc: curdle@ietf.org Message-ID: <20170612012017.GI39245@kduck.kaduk.org> References: <20170521202553.GQ39245@kduck.kaduk.org> <1496655577.929.112.camel@redhat.com> <1496656603.929.114.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1496656603.929.114.camel@redhat.com> User-Agent: Mutt/1.7.1 (2016-10-04) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42IR4hRV1o18Yxtp8LqH0WLrwlnMFj/mLmJ1 YPJYsuQnk8f7fVfZApiiuGxSUnMyy1KL9O0SuDI+npjHVPDEsWL2y7gGxk6TLkZODgkBE4l7 96ewdjFycQgJLGaSOLvzCTOEs5FRYmnjJUYI5yqTxP1fW9lBWlgEVCXW7b/NBGKzCahINHRf ZgaxRQQUJBb032EBsZkFhCX+fW4FqxEWcJY4+/0VWJwXaF3/gUlsEENbGCW2/ephgkgISpyc +QSqWUdi59Y7QEUcQLa0xPJ/HBBheYnmrbPBdnEKGEmsmN3BCmKLCihL/D18j2UCo+AsJJNm IZk0C2HSLCSTFjCyrGKUTcmt0s1NzMwpTk3WLU5OzMtLLdI118vNLNFLTSndxAgKa3YXlR2M 3T3ehxgFOBiVeHg5dttGCrEmlhVX5h5ilORgUhLl3XLFJlKILyk/pTIjsTgjvqg0J7X4EKME B7OSCC+XOVA5b0piZVVqUT5MSpqDRUmcV1yjMUJIID2xJDU7NbUgtQgmK8PBoSTBG/caqFGw KDU9tSItM6cEIc3EwQkynAdouMBzkOHFBYm5xZnpEPlTjIpS4rzpr4ASAiCJjNI8uF5Q2pHI 3l/zilEc6BVh3kyQFTzAlAXX/QpoMBPQ4OsgH/EWlyQipKQaGFumtqz9x7dOQuOCrQxvSK3G b+71f9M23fNR435x9UelirHYFrOELpUT94InhahEfH527uT6VyrqC3ufu/wJ+sP8+YluRo5A Rp9x0my97Ssc1lumHJnzps7qyScmCZnm4PisSqkjazVuO4U+N1wsttKx5ZyAf8OiSTs7ai3V XOVD++Nytd9tVmIpzkg01GIuKk4EAPtW+wYWAwAA Archived-At: Subject: Re: [Curdle] review of draft-ietf-curdle-gss-keyex-sha2-00 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 01:20:29 -0000 Sorry for the slow reply; I'll try to catch both of your messages inline. On Mon, Jun 05, 2017 at 05:56:43AM -0400, Simo Sorce wrote: > On Mon, 2017-06-05 at 05:39 -0400, Simo Sorce wrote: > > On Sun, 2017-05-21 at 15:25 -0500, Benjamin Kaduk wrote: > > > Generally, this document is in good shape, and I think we should > > > move > > > it forward. > > > > > > My main comment/objection is that the security considerations > > > should > > > note that the combination of GSS key exchange, GSS delegated > > > credentials, and use of insecure DNS to modify the requested server > > > principal name result in a situation where an attacker can easily > > > obtain a valid TGT+key for the client principal.  Obviously, RFCs > > > 4462, 4120, etc. all implore us to not use insecure DNS in such a > > > fashion, but nonetheless major Kerberos libraries continue to do > > > so. > > > At MIT we have disabled GSS key exchange for ssh because we default > > > to GSS credential delegation. > > > > I am quite hesitant to call additional security considerations in a > > document that is substantially just updating an existing document > > without introducing any new security related method that needs > > additional considerations. However I added a reference to the > > Security > > Considerations of 4120 as well. I do not think we should really do > > more, this issue is (or should be) a well know problem and in no way > > specific to SSH key exchanges. Certainly in the security directorate review process we are not afraid to call out when the existing security considerations of a document being updated/reissued are inadequate, or the security properties of the environment in which it operates has changed since the initial writing -- it feels like if we leave old-and-incomplete security considerations in place, it is just because we are lazy. > I posted a new draft with the corrections noted below but with the > exception of adding 4120 as I stated here. Adding 4120 helps, but of course the admonition it contains to not use insecure DNS for principal resolution is mostly honored in the breach, so it only helps so much. > Although krb5 is the most (or only ?) mechanism RFC 4462 and this draft > are definitely not mechanism specific (they only recommend against > using SPNEGO not any other mechanism), and it doesn't feel right to me > to add security considerations to a specific mechanism (delegation is a > krb5 mechanism feature in this case, not a feature of the SSH Key > exchange) in an amendment document that is not changing anything with > regard to the initial RFC 4462 security properties. > > If you do not agree, please provide language that you think would be > appropriate. I disagree; this draft does mention setting deleg_req_flag to request delegation, so concerns relating to security considerations for delegation seem in scope to me. You probably don't even have to explicitly refer to krb5 (though maybe it is helpful to the reader to do so); something like: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% When delegating credentials, extra care must be taken to ensure that the acceptor being authenticated matches the desired ssh target. This is particularly problematic with Kerberos, as many implementations defy the prohibition against the use of insecure DNS to canonicalize service principal names; in these cases, spoofing a DNS response that points to an attacker-controlled machine with valid Kerberos credentials results in the user silently authenticating to and delegating credentials to the attacker, who can now use the user's TGT at will. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Hmm, maybe that's still too strong on the Kerberos focus, though. > If anyone else has comments on whether we should add or not additional, > mechanism specific, security considerations, please let me know. > > Simo. > > > > Some other nit-level comments: > > > > meta-nit, your page numbers seem to be off a bit, I hope you're > > reading > > the document I posted in curdle and not a previous version. I reviewed precisely the document mentioned in the email subject. Note that the page numbers appear at the bottom of the numbered page, so it can be confusing which page one is viewing when using a continuous-scroll viewing mode. > > > On page 8, in step 5 of the procedure, do we want to give a > > > reference or two for the shared-secret computation above the > > > existing prose? > > > > What do you have in mind? I think we already have all the relevant > > references at the top or in the 1st step. This was basically just the contrary-reader part of my mind thinking as I read this "compute the shared secret, but *how*?". So, just referencing RFC 5656 and draft-ietf-curdle-ssh-curves again would be enough, or even just saying "shared secret obtained using ECDH key exchange as defined in the specification for the curve in use". (Or, really, it might be fine leaving it as-is; only contrary-reader-me had an issue with it, and it was not confusing to actual-me.) It seems that the main content of what this entails is in the following text, so I am not strongly advocating for a change here. > > >   (Also, is the d_U and q_V terminology standard from > > > some related document?  I did not see them in RFC 4462.) > > > > No, they are new handles used to avoid repeating the client or > > service > > specific value. > > IE, d_U stands for 'd_C for the client or d_S for the server' and > > q_V stands for 'q_S for the client or q_C for the server'. > > Do you think this is confusing ? Not really; I was just wondering if we should expect readers to already be familiar with it, in which case a nod to the appropriate reference might be in order. > > > Also on page 8, step 6 could further clarify that this only occurs > > > when the server's final call to GSS_Accept_sec_context() returns > > > GSS_S_COMPLETE; anything else is an error condition. > > > > Already explained in step 8, I think that is sufficient. It probably is, yes. > > > Relatedly, the > > > way the GSS context negotiation loop's exit conditions are split > > > between step 6 and step 2 confused me a little on first read, but > > > it > > > seems correct, and along with the RFC 7546 reference I think > > > readers > > > will be okay. > > > > It is really hard to condense everything in few steps and maintain > > perfect clarity on all fronts, but I think the current text strikes > > the > > right balance, between being more informative than the document we > > replace, without being overly verbose and distracting from the actual > > core of the matter and has enough references to clarify with original > > documents any doubts one may have. Definitely. I think you did a fine job, and don't see a pressing need for any changes. > > > On page 11, the description of the HASH input has a couple of > > > inconsistencies -- in RFC 4462, V_S is the server's "version" > > > string, though here we have it as the server's "identification" > > > string.  I don't think that's a problem per se, but wanted to note > > > it just in case.  Also, V_S excludes CR and LF, but V_C excludes CR > > > and NL; we should probably be consistent about NL vs. LF. > > > > Thanks for pointing these out, I am fixing these to say server > > version > > for consistency with 4462 and will use NL again for consistency with > > 4462 which is itself inconsistent as it uses CRLF in some places ... Oh, I missed the internal inconsistencies in 4462. Thanks. > > > In sections 5.2.2 and later we continue to include refeferences for > > > MD5, DER, and Base64; RFC 4462 only included those references in > > > the > > > first corresponding subsection.  At this point, it's probably not > > > worth making any changes, though. > > > > I agree it is not worth making changes here. > > > > > And one editorial note: > > > > > > On page 6, "non- zero" should not have a space. > > > > Thanks. > > I will submit -01 with these corrections shortly. Thanks. The diff from the -00 looks good modulo our disagreement about the delegation security considerations [for Kerberos implementations that are non-conformant to RFC 4120]. -Ben From nobody Mon Jun 12 03:18:09 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A92FC1294F3 for ; Mon, 12 Jun 2017 03:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.923 X-Spam-Level: X-Spam-Status: No, score=-6.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 I42NZvNaUBl2 for ; Mon, 12 Jun 2017 03:18:05 -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 9393A1294F0 for ; Mon, 12 Jun 2017 03:18:05 -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 2F0B75A41; Mon, 12 Jun 2017 10:18:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 2F0B75A41 Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=simo@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 2F0B75A41 Received: from rhino.ipa.ssimo.org (ovpn-116-88.phx2.redhat.com [10.3.116.88]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 653D25C6D5; Mon, 12 Jun 2017 10:18:04 +0000 (UTC) Message-ID: <1497262681.929.209.camel@redhat.com> From: Simo Sorce To: Benjamin Kaduk Cc: curdle@ietf.org Date: Mon, 12 Jun 2017 06:18:01 -0400 In-Reply-To: <20170612012017.GI39245@kduck.kaduk.org> References: <20170521202553.GQ39245@kduck.kaduk.org> <1496655577.929.112.camel@redhat.com> <1496656603.929.114.camel@redhat.com> <20170612012017.GI39245@kduck.kaduk.org> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit 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.30]); Mon, 12 Jun 2017 10:18:05 +0000 (UTC) Archived-At: Subject: Re: [Curdle] review of draft-ietf-curdle-gss-keyex-sha2-00 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 10:18:08 -0000 On Sun, 2017-06-11 at 20:20 -0500, Benjamin Kaduk wrote: > Sorry for the slow reply; I'll try to catch both of your messages > inline. Also replying inline and trimming. > Certainly in the security directorate review process we are not > afraid to call out when the existing security considerations of a > document being updated/reissued are inadequate, or the security > properties of the environment in which it operates has changed since > the initial writing -- it feels like if we leave old-and-incomplete > security considerations in place, it is just because we are lazy. Noted. > > If you do not agree, please provide language that you think would > > be appropriate. > > I disagree; this draft does mention setting deleg_req_flag > to request delegation, so concerns relating to security > considerations for delegation seem in scope to me.  You probably > don't even have to explicitly refer to krb5 (though maybe it is > helpful to the reader to do so); something like: > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > When delegating credentials, extra care must be taken to ensure that > the acceptor being authenticated matches the desired ssh target. > This is particularly problematic with Kerberos, as many > implementations defy the prohibition against the use of insecure DNS > to canonicalize service principal names; in these cases, spoofing a > DNS response that points to an attacker-controlled machine with > valid Kerberos credentials results in the user silently > authenticating to and delegating credentials to the attacker, who > can now use the user's TGT at will. > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > Hmm, maybe that's still too strong on the Kerberos focus, though. I think one of the issues I have with your text and previous comments is the implied fact that credentials will be delegated. Looking at openssh's defaults (on Fedora/RHEL at least) delegation is disabled by default. Maybe the following slightly modified text: ####################################################################### GSSAPI mechanisms can optionally delegate credentials to the target host. In this case extra care must be taken to ensure that the acceptor being authenticated matches the target the user intended. Some mechanisms implementations (like commonly used Krb5 libraries) may use insecure DNS resolution to canonicalize the target name; in these cases, spoofing a DNS response that points to an attacker-controlled machine may results in the user silently delegating credentials to the attacker, who can now impersonate the user at will. ####################################################################### > This was basically just the contrary-reader part of my mind thinking > as I read this "compute the shared secret, but *how*?".  So, just > referencing RFC 5656 and draft-ietf-curdle-ssh-curves again would be > enough, or even just saying "shared secret obtained using ECDH key > exchange as defined in the specification for the curve in use". > (Or, really, it might be fine leaving it as-is; only > contrary-reader-me had an issue with it, and it was not confusing to > actual-me.)  It seems that the main content of what this entails is > in the following text, so I am not strongly advocating for a change > here. In this case I'll wait for more input on this. I felt that adding references here was not a big gain and made the text flow less smoothly. > Thanks.  The diff from the -00 looks good modulo our disagreement > about the delegation security considerations [for Kerberos > implementations that are non-conformant to RFC 4120]. If we can agree on the text above (feel free to add corrections) then I can add it to the Security Consideration and cut a hopefully final -02 Simo. > -Ben > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Mon Jun 12 21:25:55 2017 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2E11200F1; Mon, 12 Jun 2017 21:25:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.54.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149732795448.7714.6886250987278762657@ietfa.amsl.com> Date: Mon, 12 Jun 2017 21:25:54 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-ssh-ext-info-09.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 04:25:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : Extension Negotiation in Secure Shell (SSH) Author : Denis Bider Filename : draft-ietf-curdle-ssh-ext-info-09.txt Pages : 11 Date : 2017-06-12 Abstract: This memo updates RFC 4252, RFC 4253, and RFC 4254 to define a mechanism for SSH clients and servers to exchange information about supported protocol extensions confidentially after SSH key exchange. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-ext-info/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-ssh-ext-info-09 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-ext-info-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-ssh-ext-info-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 Mon Jun 12 21:38:07 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A35231270A7 for ; Mon, 12 Jun 2017 21:38:06 -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 KU8cYfA7DlZH for ; Mon, 12 Jun 2017 21:38:04 -0700 (PDT) Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B43CB1200F1 for ; Mon, 12 Jun 2017 21:38:04 -0700 (PDT) Received: by mail-yb0-x233.google.com with SMTP id f192so32321666yba.2 for ; Mon, 12 Jun 2017 21:38:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=IWXoRpDBTN2N+0qmJqdGcJf7ceuUmgTxuas2gePIBBw=; b=Oh9gLlVkZQT7CNOhGe5xnbmjmQ3GY1QGKSE/dgRerxTBrpdjzIwC4XbiiPX/RZ/RyH 70c4N3YNjcg92liH2TXiK2Z6xm9g2sbXkq3LvJImQnm866Q4wqL5GJKljgVdrlMtDGef wCXG0cBgQp4VsvhMZ07uBTXCL3K3UHdqhPsSXQSSCc8cYgTvIdGrsHXvJh0QkKppEBX3 CeaQBXiOcs2lO9qBEtbRmhOIkmychq/sbDcE5wuIAwKbIU3pBa9UfIWsVIF0tGnSg3OE YiGwFi/KtkJcT8U8OKimc0bTfcjwomsP/5A8UUwl1tcoL+VG8JFX+B8K/HMK3TYxxao5 O1pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=IWXoRpDBTN2N+0qmJqdGcJf7ceuUmgTxuas2gePIBBw=; b=C0PKIzDvTmsWVC2646Kb+1f7GG21BEsmnLdt6ZcBYzji3HJ4zFfn9KZKUjh/ocJa1+ IXIs/wTriDiwPmTPZ86FPABXsxVItYPzK9GmPr7EmjeClv+99riwBIyCvsvGL6YR3ljT p/skaBwDh9F0CB+tu4uSBher1KAwYKbuEI/ACeCABVZcfpgLxQW6+XZfmLQC86FZkE2E zuVw8cT3dRVLfKDYALkPm5bEglhCz59o7fUqG/7C+7Mpp4Lv7g7LXUMfIWe8hMShBhrb 1Ir8r3UeC8SN+X/atNROLPrMtKeQQCsA1qY+dkDFCaPyLxY5yfT/b/1dKVKie7Sy2MGB LRbg== X-Gm-Message-State: AKS2vOwQSzZcQzAGNP10CnfXZmZD5yHVvAVknGuwHBvLnCJzTwTOj+hX RKRF7mxFdhy7xXXWio+Cxwffcy3URw== X-Received: by 10.37.125.133 with SMTP id y127mr1819436ybc.238.1497328683882; Mon, 12 Jun 2017 21:38:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.45.2 with HTTP; Mon, 12 Jun 2017 21:38:03 -0700 (PDT) In-Reply-To: <149732795448.7714.6886250987278762657@ietfa.amsl.com> References: <149732795448.7714.6886250987278762657@ietfa.amsl.com> From: denis bider Date: Mon, 12 Jun 2017 22:38:03 -0600 Message-ID: To: curdle Content-Type: multipart/alternative; boundary="001a114dc596509c970551d000e6" Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-ssh-ext-info-09.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 04:38:07 -0000 --001a114dc596509c970551d000e6 Content-Type: text/plain; charset="UTF-8" Hello everyone, it has come to my attention that a widely used SSH implementation that supports EXT_INFO contains an oversight (uses an incorrect string decoding function) which imposes undesirable restrictions on the content of "extension-value". Regretfully, this oversight makes it so that the "delay-compression" extension cannot be sent to current versions of this application. The application does not understand the extension, but will choke on the null bytes contained in the extension-value. I trust that this was unintentional, and that the implementers will fix the oversight. This behavior was previously already against the spec, but the language that dictated this was subtle and in a different section than the definition of "extension-value". I have made the language much more overt to help implementers avoid this problem in the future. denis On Mon, Jun 12, 2017 at 10:25 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the CURves, Deprecating and a Little more > Encryption of the IETF. > > Title : Extension Negotiation in Secure Shell (SSH) > Author : Denis Bider > Filename : draft-ietf-curdle-ssh-ext-info-09.txt > Pages : 11 > Date : 2017-06-12 > > Abstract: > This memo updates RFC 4252, RFC 4253, and RFC 4254 to define a > mechanism for SSH clients and servers to exchange information about > supported protocol extensions confidentially after SSH key exchange. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-ext-info/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-curdle-ssh-ext-info-09 > https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-ext-info-09 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-ssh-ext-info-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/ > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --001a114dc596509c970551d000e6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello everyone,

it has come to my atten= tion that a widely used SSH implementation that supports EXT_INFO contains = an oversight (uses an incorrect string decoding function) which imposes und= esirable restrictions on the content of "extension-value".
<= div>
Regretfully, this oversight makes it so that the "d= elay-compression" extension cannot be sent to current versions of this= application. The application does not understand the extension, but will c= hoke on the null bytes contained in the extension-value.

I trust that this was unintentional, and that the implementers will = fix the oversight.

This behavior was previously al= ready against the spec, but the language that dictated this was subtle and = in a different section than the definition of "extension-value". = I have made the language much more overt to help implementers avoid this pr= oblem in the future.

denis



On Mon, Jun 12, 2017 at 10:25 PM, <internet-drafts@ietf.org&g= t; wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the CURves, Deprecating and a Little more Encr= yption of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Extension Negotiation in Secure Shell (SSH)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Deni= s Bider
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-curdle-ssh-ext-info-09.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 11
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-06-12

Abstract:
=C2=A0 This memo updates RFC 4252, RFC 4253, and RFC 4254 to define a
=C2=A0 mechanism for SSH clients and servers to exchange information about<= br> =C2=A0 supported protocol extensions confidentially after SSH key exchange.=


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/do= c/draft-ietf-curdle-ssh-ext-info/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-= ietf-curdle-ssh-ext-info-09
https://datatracker.ietf.org/= doc/html/draft-ietf-curdle-ssh-ext-info-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-curdle-ssh-ext-info-09


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

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

_______________________________________________
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle

--001a114dc596509c970551d000e6-- From nobody Tue Jun 13 15:35:47 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FEE3131A46 for ; Tue, 13 Jun 2017 15:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 NfapqP_uE95J for ; Tue, 13 Jun 2017 15:35:44 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 9EE8F131A41 for ; Tue, 13 Jun 2017 15:35:38 -0700 (PDT) X-AuditID: 1209190f-d97ff7000000581c-7b-594068b78e67 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 18.53.22556.7B860495; Tue, 13 Jun 2017 18:35:37 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id v5DMZZ56006997; Tue, 13 Jun 2017 18:35:35 -0400 Received: from kduck.kaduk.org (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.13.8/8.12.4) with ESMTP id v5DMZVLY001881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 13 Jun 2017 18:35:34 -0400 Date: Tue, 13 Jun 2017 17:35:31 -0500 From: Benjamin Kaduk To: Simo Sorce Cc: curdle@ietf.org Message-ID: <20170613223530.GL39245@kduck.kaduk.org> References: <20170521202553.GQ39245@kduck.kaduk.org> <1496655577.929.112.camel@redhat.com> <1496656603.929.114.camel@redhat.com> <20170612012017.GI39245@kduck.kaduk.org> <1497262681.929.209.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1497262681.929.209.camel@redhat.com> User-Agent: Mutt/1.7.1 (2016-10-04) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphleLIzCtJLcpLzFFi42IRYrdT192Z4RBp8G6JtMXWhbOYLX7MXcTq wOSxZMlPJo/3+66yBTBFcdmkpOZklqUW6dslcGW837+cteCxbMWxJ02sDYwdEl2MnBwSAiYS JzeeZ+9i5OIQEljMJPH18UlGCGcjo8TFtVeYIZyrTBI71zxnB2lhEVCVmNR7gQnEZhNQkWjo vswMYosIKEgs6L/DAmIzCwhL/PvcClYjLOAscfb7K7A4L9C61objrBBDrzNKzHv6gBUiIShx cuYTqGYdiZ1b77B1MXIA2dISy/9xQITlJZq3zgbbxSlgJLF90Xk2EFtUQFni7+F7LBMYBWch mTQLyaRZCJNmIZm0gJFlFaNsSm6Vbm5iZk5xarJucXJiXl5qka6JXm5miV5qSukmRlBgc0ry 72Cc0+B9iFGAg1GJh7fjrX2kEGtiWXFl7iFGSQ4mJVHeJXYOkUJ8SfkplRmJxRnxRaU5qcWH GCU4mJVEeJdGAuV4UxIrq1KL8mFS0hwsSuK84hqNEUIC6YklqdmpqQWpRTBZGQ4OJQne/elA jYJFqempFWmZOSUIaSYOTpDhPEDDq0BqeIsLEnOLM9Mh8qcYFaXEeeVBEgIgiYzSPLheUOKR yN5f84pRHOgVYd6/qUBVPMCkBdf9CmgwE9Dg61dsQAaXJCKkpBoY2f+WS8vEHbuys9Egf99d 919aU65z/JD7q8E8l6E0kGP6r9LX53cobOjWkxbJf3zovZlLgWT5ua0Hm2eq/u8QvTS9pnTu Xunuf4XiM1iCuuYozBfhS9/y5fmS2CsdFl+Tktim9KdYn5ZYtuGJ+rT1lzLytvXmnovrnPJ0 4oZZrItOGr6oefqhTYmlOCPRUIu5qDgRANU7b1MXAwAA Archived-At: Subject: Re: [Curdle] review of draft-ietf-curdle-gss-keyex-sha2-00 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 22:35:45 -0000 On Mon, Jun 12, 2017 at 06:18:01AM -0400, Simo Sorce wrote: > On Sun, 2017-06-11 at 20:20 -0500, Benjamin Kaduk wrote: > > > > If you do not agree, please provide language that you think would > > > be appropriate. > > > > I disagree; this draft does mention setting deleg_req_flag > > to request delegation, so concerns relating to security > > considerations for delegation seem in scope to me.  You probably > > don't even have to explicitly refer to krb5 (though maybe it is > > helpful to the reader to do so); something like: > > > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > > > When delegating credentials, extra care must be taken to ensure that > > the acceptor being authenticated matches the desired ssh target. > > This is particularly problematic with Kerberos, as many > > implementations defy the prohibition against the use of insecure DNS > > to canonicalize service principal names; in these cases, spoofing a > > DNS response that points to an attacker-controlled machine with > > valid Kerberos credentials results in the user silently > > authenticating to and delegating credentials to the attacker, who > > can now use the user's TGT at will. > > > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > > > Hmm, maybe that's still too strong on the Kerberos focus, though. > > I think one of the issues I have with your text and previous comments > is the implied fact that credentials will be delegated. Looking at > openssh's defaults (on Fedora/RHEL at least) delegation is disabled by > default. > > Maybe the following slightly modified text: > > ####################################################################### > GSSAPI mechanisms can optionally delegate credentials to the target > host. In this case extra care must be taken to ensure that the acceptor Maybe also mention "by setting the deleg_req_flag" to refer back to step 2 where this is discussed. > being authenticated matches the target the user intended. Some > mechanisms implementations (like commonly used Krb5 libraries) may use > insecure DNS resolution to canonicalize the target name; in these > cases, spoofing a DNS response that points to an attacker-controlled > machine may results in the user silently delegating credentials to the > attacker, who can now impersonate the user at will. > ####################################################################### But this looks fine to me, thanks. > > > This was basically just the contrary-reader part of my mind thinking > > as I read this "compute the shared secret, but *how*?".  So, just > > referencing RFC 5656 and draft-ietf-curdle-ssh-curves again would be > > enough, or even just saying "shared secret obtained using ECDH key > > exchange as defined in the specification for the curve in use". > > (Or, really, it might be fine leaving it as-is; only > > contrary-reader-me had an issue with it, and it was not confusing to > > actual-me.)  It seems that the main content of what this entails is > > in the following text, so I am not strongly advocating for a change > > here. > > In this case I'll wait for more input on this. I felt that adding > references here was not a big gain and made the text flow less > smoothly. Sure, I am happy to defer to your judgement. > > Thanks.  The diff from the -00 looks good modulo our disagreement > > about the delegation security considerations [for Kerberos > > implementations that are non-conformant to RFC 4120]. > > If we can agree on the text above (feel free to add corrections) then I > can add it to the Security Consideration and cut a hopefully final -02 I'm looking forward to having this document move forward. Thanks again, Ben From nobody Tue Jun 13 17:18:17 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDB8212EA56 for ; Tue, 13 Jun 2017 17:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 38UZL6LYRYw0 for ; Tue, 13 Jun 2017 17:18:13 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 142B8127BA3 for ; Tue, 13 Jun 2017 17:18:13 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id p189so81777126lfe.2 for ; Tue, 13 Jun 2017 17:18:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=AOwZGUdty7/TjmtryROYzoPQEZ2wJdKBoMn7/UYMYXM=; b=vWj6tN7+lkAjMJk9lnHU1MZYPCqTEBLMARxH22IkvxRymKLOs8EkHms4vh7R1ElGJ0 7MVB+Qo1x5zOPjVEvIMF+HHDOHPSeCjZXwSmcBxOyIJi1njpdpsUgaBWox8pRG6ATGnH P4GB29TAW6smAIm5s/7qcaybhDI5QTczupufB4x2SY51lNH+y0XyW2Y8JdBjtyrqJ3Ns OS4KG5dNVlQOtUW/9zfM4JRef5RFdD99o0q6MgYovEfgZNCj7L6+MEEmlc4doIfYYxmx Z8wW4Fyr8tUJf4HvTO2F5duA955NH8KGXmKACeaqGuNQTzppsU8TgcremdxDawrnmBDb W8dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=AOwZGUdty7/TjmtryROYzoPQEZ2wJdKBoMn7/UYMYXM=; b=Ca9blaCFjdr/K0GpW8utCLneI/DRlcUD665ljlFxbqDdsOwq3UR7XuhpzjoKWx6x6x km5MOeqHMzA652SJHniFJaxydA4nsxrcZhpmU1zU9lZa75wRQyHDAxY02sJCZIXdmvYf 8m7A/BuA5K1Eq3Wl0YNPQ7eYNcc09wRGHNP7eQ03eZk4cIYQ+WrE+ynWJXQKg2k5m6eq 4EwL8qqaD/HcBrHDFDVtZLAhMaPJZcKoWsqpxDCGsoM3I2HefR/Xfm480sBNSukLUmF9 hWdCGEFE5hUKQMjeQkDRhIaf5dBrLzU4RG9uqn7wj4AkuAlZwHBRg7k1nIf5AEtFXsYf lwUA== X-Gm-Message-State: AKS2vOyJpMldz5oPU61/zqc4HxXRgmRjpucl+YY8qNvwx4CKFnFtQrI1 N34hjVpshLai8atsCJ/D/J80y38fMA== X-Received: by 10.25.20.38 with SMTP id k38mr644133lfi.142.1497399491335; Tue, 13 Jun 2017 17:18:11 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.15.26 with HTTP; Tue, 13 Jun 2017 17:18:10 -0700 (PDT) In-Reply-To: <20170613223530.GL39245@kduck.kaduk.org> References: <20170521202553.GQ39245@kduck.kaduk.org> <1496655577.929.112.camel@redhat.com> <1496656603.929.114.camel@redhat.com> <20170612012017.GI39245@kduck.kaduk.org> <1497262681.929.209.camel@redhat.com> <20170613223530.GL39245@kduck.kaduk.org> From: Daniel Migault Date: Tue, 13 Jun 2017 20:18:10 -0400 X-Google-Sender-Auth: DhkIwxJXiDpLJTzkELYLuCNSUaA Message-ID: To: Benjamin Kaduk Cc: Simo Sorce , curdle Content-Type: multipart/alternative; boundary="001a114067b4c49df80551e07c91" Archived-At: Subject: Re: [Curdle] review of draft-ietf-curdle-gss-keyex-sha2-00 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 00:18:16 -0000 --001a114067b4c49df80551e07c91 Content-Type: text/plain; charset="UTF-8" Thanks Ben and Simo for the follow-up. Yours, Daniel On Tue, Jun 13, 2017 at 6:35 PM, Benjamin Kaduk wrote: > On Mon, Jun 12, 2017 at 06:18:01AM -0400, Simo Sorce wrote: > > On Sun, 2017-06-11 at 20:20 -0500, Benjamin Kaduk wrote: > > > > > > If you do not agree, please provide language that you think would > > > > be appropriate. > > > > > > I disagree; this draft does mention setting deleg_req_flag > > > to request delegation, so concerns relating to security > > > considerations for delegation seem in scope to me. You probably > > > don't even have to explicitly refer to krb5 (though maybe it is > > > helpful to the reader to do so); something like: > > > > > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > > > > > When delegating credentials, extra care must be taken to ensure that > > > the acceptor being authenticated matches the desired ssh target. > > > This is particularly problematic with Kerberos, as many > > > implementations defy the prohibition against the use of insecure DNS > > > to canonicalize service principal names; in these cases, spoofing a > > > DNS response that points to an attacker-controlled machine with > > > valid Kerberos credentials results in the user silently > > > authenticating to and delegating credentials to the attacker, who > > > can now use the user's TGT at will. > > > > > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > > > > > Hmm, maybe that's still too strong on the Kerberos focus, though. > > > > I think one of the issues I have with your text and previous comments > > is the implied fact that credentials will be delegated. Looking at > > openssh's defaults (on Fedora/RHEL at least) delegation is disabled by > > default. > > > > Maybe the following slightly modified text: > > > > ####################################################################### > > GSSAPI mechanisms can optionally delegate credentials to the target > > host. In this case extra care must be taken to ensure that the acceptor > > Maybe also mention "by setting the deleg_req_flag" to refer back to > step 2 where this is discussed. > > > being authenticated matches the target the user intended. Some > > mechanisms implementations (like commonly used Krb5 libraries) may use > > insecure DNS resolution to canonicalize the target name; in these > > cases, spoofing a DNS response that points to an attacker-controlled > > machine may results in the user silently delegating credentials to the > > attacker, who can now impersonate the user at will. > > ####################################################################### > > But this looks fine to me, thanks. > > > > > > This was basically just the contrary-reader part of my mind thinking > > > as I read this "compute the shared secret, but *how*?". So, just > > > referencing RFC 5656 and draft-ietf-curdle-ssh-curves again would be > > > enough, or even just saying "shared secret obtained using ECDH key > > > exchange as defined in the specification for the curve in use". > > > (Or, really, it might be fine leaving it as-is; only > > > contrary-reader-me had an issue with it, and it was not confusing to > > > actual-me.) It seems that the main content of what this entails is > > > in the following text, so I am not strongly advocating for a change > > > here. > > > > In this case I'll wait for more input on this. I felt that adding > > references here was not a big gain and made the text flow less > > smoothly. > > Sure, I am happy to defer to your judgement. > > > > Thanks. The diff from the -00 looks good modulo our disagreement > > > about the delegation security considerations [for Kerberos > > > implementations that are non-conformant to RFC 4120]. > > > > If we can agree on the text above (feel free to add corrections) then I > > can add it to the Security Consideration and cut a hopefully final -02 > > I'm looking forward to having this document move forward. > > Thanks again, > > Ben > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --001a114067b4c49df80551e07c91 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Ben and Simo for the follow-up.

<= /div>Yours,
Daniel

On Tue, Jun 13, 2017 at 6:35 PM, Benjamin Kaduk <kaduk@mi= t.edu> wrote:
On Mon, Jun 12, 2017 at 06:18:01AM -0400, Simo Sorce wrote:
> On Sun, 2017-06-11 at 20:20 -0500, Benjamin Kaduk wrote:
>
> > > If you do not agree, please pr= ovide language that you think would
> > > be appropriate.
> >
> > I disagree; this draft does mention setting deleg_req_flag
> > to request delegation, so concerns relating to security
> > considerations for delegation seem in scope to me.=C2=A0=C2=A0You= probably
> > don't even have to explicitly refer to krb5 (though maybe it = is
> > helpful to the reader to do so); something like:
> >
> > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%%
> >
> > When delegating credentials, extra care must be taken to ensure t= hat
> > the acceptor being authenticated matches the desired ssh target.<= br> > > This is particularly problematic with Kerberos, as many
> > implementations defy the prohibition against the use of insecure = DNS
> > to canonicalize service principal names; in these cases, spoofing= a
> > DNS response that points to an attacker-controlled machine with > > valid Kerberos credentials results in the user silently
> > authenticating to and delegating credentials to the attacker, who=
> > can now use the user's TGT at will.
> >
> > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%%
> >
> > Hmm, maybe that's still too strong on the Kerberos focus, tho= ugh.
>
> I think one of the issues I have with your text and previous comments<= br> > is the implied fact that credentials will be delegated. Looking at
> openssh's defaults (on Fedora/RHEL at least) delegation is disable= d by
> default.
>
> Maybe the following slightly modified text:
>
> ############################################################= ###########
> GSSAPI mechanisms can optionally delegate credentials to the target > host. In this case extra care must be taken to ensure that the accepto= r

Maybe also mention "by setting the deleg_req_flag" to= refer back to
step 2 where this is discussed.

> being authenticated matches the target the user intended. Some
> mechanisms implementations (like commonly used Krb5 libraries) may use=
> insecure DNS resolution to canonicalize the target name; in these
> cases, spoofing a DNS response that points to an attacker-controlled > machine may results in the user silently delegating credentials to the=
> attacker, who can now impersonate the user at will.
> ############################################################= ###########

But this looks fine to me, thanks.

>
> > This was basically just the contrary-reader part of my mind think= ing
> > as I read this "compute the shared secret, but *how*?".= =C2=A0=C2=A0So, just
> > referencing RFC 5656 and draft-ietf-curdle-ssh-curves again would= be
> > enough, or even just saying "shared secret obtained using EC= DH key
> > exchange as defined in the specification for the curve in use&quo= t;.
> > (Or, really, it might be fine leaving it as-is; only
> > contrary-reader-me had an issue with it, and it was not confusing= to
> > actual-me.)=C2=A0=C2=A0It seems that the main content of what thi= s entails is
> > in the following text, so I am not strongly advocating for a chan= ge
> > here.
>
> In this case I'll wait for more input on this. I felt that adding<= br> > references here was not a big gain and made the text flow less
> smoothly.

Sure, I am happy to defer to your judgement.

> > Thanks.=C2=A0=C2=A0The diff from the -00 looks good modulo our di= sagreement
> > about the delegation security considerations [for Kerberos
> > implementations that are non-conformant to RFC 4120].
>
> If we can agree on the text above (feel free to add corrections) then = I
> can add it to the Security Consideration and cut a hopefully final -02=

I'm looking forward to having this document move forward.

Thanks again,

Ben

_______________________________________________
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle

--001a114067b4c49df80551e07c91-- From nobody Wed Jun 14 08:48:50 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD31D12EC5B for ; Wed, 14 Jun 2017 08:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, 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=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 UewN-uHccbvm for ; Wed, 14 Jun 2017 08:48:47 -0700 (PDT) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1D1112EC4E for ; Wed, 14 Jun 2017 08:48:46 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id p189so4412082lfe.2 for ; Wed, 14 Jun 2017 08:48:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=N0KKhe7uRsDH9ghRVlDzNUMjsCsY3QMfPr0BFN5Hdyk=; b=BpO9Hch6KjhpvXRXFfU6kHEPLyzKxBmce4q8Jf9QKcktZXbuW3vcRK3Lc7uG3YhZJc HHPzCiuFj/8ux4RNDZRkuw0iN+iv08UiiyBSj2jCKsL9PRcrefz5bEMdDpGwgHhqMjd0 XUMcVJ3k6CwKJ+N1hFjpgOrCfTUaQ6BXbd39c9pvOVcfK6Xv01KALc2U72eutmL/3e43 +d2s0NKrpzMZo5V99FYp+XOVzE3WHUJfRfOmGUdo8R3h5BgdAsce6nji2uYUL+yDrR8r hpgVJy0ZVdLrA7kPEeV38sW3sEpqRgZwyd+FQKDU3eLptg2HIzajIOTddOAjwKrYLmP3 ie2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=N0KKhe7uRsDH9ghRVlDzNUMjsCsY3QMfPr0BFN5Hdyk=; b=f7PveUUE5IERi8+BK/Rypmm0ulG9RyjvXchowBSSKebel0fHvSx0VtJzGy0+AwtNkX 3+huqzJR7EJMIY7xgCrImAMglwq8aA1tUkAqZjMPfVBrIC190hteZ6+KMFloLEVnRkTP h4eQl7TqLKSsK8ld7ucFdzHfB/UXmbQ86jGilSBnh+ykNWZXIJf4gb5hgvIb2mH6ehuv 1gWDJoNOVvU0/Ae8svpb8Zg+t+tYTAeXrAAxGCTuI5i75S0CXuCIVSJsvxPGSsM2ymmC ZCe7xoSFqV5XEtkmT70aW23H//kfWj8cxJMSN99X6LFXiV7QBz7mxb8x5v0cg7Xa73X4 aa7A== X-Gm-Message-State: AKS2vOxCACMp0GkBdph9xvPYqUdvVYhmG07t8yGu6JZzWnwGbZJnhwlL 9+CLhG46K7QLE0rGt0F3qe13nMBKShyi X-Received: by 10.25.193.72 with SMTP id r69mr280981lff.111.1497455324694; Wed, 14 Jun 2017 08:48:44 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.15.26 with HTTP; Wed, 14 Jun 2017 08:48:44 -0700 (PDT) From: Daniel Migault Date: Wed, 14 Jun 2017 11:48:44 -0400 X-Google-Sender-Auth: SZL2PKMSnurfEShUaH7ETVPJIqY Message-ID: To: curdle Content-Type: multipart/alternative; boundary="94eb2c1953b4b21b030551ed7cb7" Archived-At: Subject: [Curdle] WGLC draft-ietf-curdle-ssh-kex-sha2 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 15:48:49 -0000 --94eb2c1953b4b21b030551ed7cb7 Content-Type: text/plain; charset="UTF-8" Hi, This email starts a WGLC for draft-ietf-curdle-ssh-kex-sha2 [1] "Key Exchange (KEX) Method Updates and Recommendations for Secure Shell (SSH)". Please review the draft and raise your concerns by June 28. . Yours, Rich and Daniel [1] https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-kex-sha2/ --94eb2c1953b4b21b030551ed7cb7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

This email starts a WGLC = for draft-ietf-curdle-ssh-kex-sha2 [1] "Key Exchange (KEX) Method Upda= tes and Recommendations for Secure Shell (SSH)".

Please review= the draft and raise your concerns by June 28.
.
Yours,
Rich and Daniel
=
--94eb2c1953b4b21b030551ed7cb7-- From nobody Thu Jun 15 11:45:03 2017 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0341200CF; Thu, 15 Jun 2017 11:45:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.54.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149755230126.11329.15786922445850892168@ietfa.amsl.com> Date: Thu, 15 Jun 2017 11:45:01 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-gss-keyex-sha2-02.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 18:45:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : GSS-API Key Exchange with SHA2 Authors : Simo Sorce Hubert Kario Filename : draft-ietf-curdle-gss-keyex-sha2-02.txt Pages : 16 Date : 2017-06-15 Abstract: This document specifies additions and amendments to SSH GSS-API Methods [RFC4462]. It defines a new key exchange method that uses SHA-2 for integrity and deprecates weak DH groups. The purpose of this specification is to modernize the cryptographic primitives used by GSS Key Exchanges. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-gss-keyex-sha2/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-gss-keyex-sha2-02 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-gss-keyex-sha2-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-gss-keyex-sha2-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 Thu Jun 15 11:55:52 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DBC012878D for ; Thu, 15 Jun 2017 11:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, 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=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 gAq7JhMnKyDL for ; Thu, 15 Jun 2017 11:55:49 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C5B1127866 for ; Thu, 15 Jun 2017 11:55:49 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id v20so14320033lfa.1 for ; Thu, 15 Jun 2017 11:55:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=zQNWYJdB1gtinkRTuMi6ybfzQ/4HkXzyQT/MQz75wxU=; b=WMcAd0qCRSoVrODPtewZgDsbyB+JySyLt5ra/ucbj9ngWxCVHzeL13p3wwVpTO99M9 dleExGldsmQSCaSOgByRbIWrM9oqK/4FaOWFl4ev/uZjHm3Rv8jhMTZtqoXNlfOg2lsG zxVa0XCDuS10vSjdMCNTnN0gB6QnPoPltn8pY29LRwOcCFlL8kEvPtl2qIJzvCrdnT/C TOrRO9rjN5Zwx39QcaNPaGjXSgdJxS8XCr086dWGRJg+xMYcAbBmwLl+rshXAY9GxFNl +cATqKacZR7OTMQPoNQFzJ1zvLrAKzTYmbWxu9M2Za1oYUGCzm2CMKSjUSCBtoZF2FpZ 2PBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=zQNWYJdB1gtinkRTuMi6ybfzQ/4HkXzyQT/MQz75wxU=; b=DigeqqVN7mxVOkJKVNwqVENWrA897kUCkOSQPiWJNaAt9wRgP3GWWhiEb9g+ARX9WW oK42LDkazecMo+toRugTQBOPSe7wfQIeV7y9LniDh6+eF5xFGsROKYrMcoX0UdYCG/4Q HHRRZBFORV20bhfCXU/ELNJxVa16kR4Y39d4EWqOJ/9bXhjKnpJw4COSm9kc5FAer8ap 1I7IUJdOawurqOcMsSjOjEyvLt/w0oqvQpuooSsTkAq2BHwSba+VUEVlEVS1h/41y6pV RI6Vr17TbpTWQ0B5B4zwwgHOGYgguoHJQWbYQx2ov5rejJsTwNiSbzqui/0ZgMr2wxXF KsPA== X-Gm-Message-State: AKS2vOy/rSytgG3nsMnoAruscf0J4TyRSmITCqklh0P+f4mEcIVsRzDk RPli4qX/Rl39jaiX6wGl1Lb3nIsIS8bV X-Received: by 10.25.125.67 with SMTP id y64mr2452650lfc.147.1497552947245; Thu, 15 Jun 2017 11:55:47 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.15.26 with HTTP; Thu, 15 Jun 2017 11:55:46 -0700 (PDT) From: Daniel Migault Date: Thu, 15 Jun 2017 14:55:46 -0400 X-Google-Sender-Auth: uCjsaJ_czpFW-MZY6R_RD7g8H_g Message-ID: To: curdle Content-Type: multipart/alternative; boundary="001a114a575c73f9130552043744" Archived-At: Subject: [Curdle] WGLC draft-ietf-curdle-gss-keyex-sha2 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 18:55:51 -0000 --001a114a575c73f9130552043744 Content-Type: text/plain; charset="UTF-8" Hi, This email starts a WGLC for draft-ietf-curdle-gss-keyex-sha2 "GSS-API Key Exchange with SHA2". Please review the draft and provide feed backs by June 29. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-gss-keyex-sha2/ Yours, Rich and Daniel --001a114a575c73f9130552043744 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

This email starts a WGLC for draft-= ietf-curdle-gss-keyex-sha2 "GSS-API Key Exchange with SHA2". Plea= se review the draft and provide feed backs by June 29. =C2=A0

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/= doc/draft-ietf-curdle-gss-keyex-sha2/

Yours,
Rich and Daniel
--001a114a575c73f9130552043744-- From nobody Thu Jun 15 19:29:49 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CFB71293F5; Thu, 15 Jun 2017 19:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 r4A6leUA2kmV; Thu, 15 Jun 2017 19:29:46 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (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 8CFB2128DF3; Thu, 15 Jun 2017 19:29:46 -0700 (PDT) X-AuditID: 12074424-56dff700000002e1-e3-59434297a455 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 00.2E.00737.79243495; Thu, 15 Jun 2017 22:29:44 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id v5G2TebI024860; Thu, 15 Jun 2017 22:29:41 -0400 Received: from kduck.kaduk.org (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.13.8/8.12.4) with ESMTP id v5G2Takf022094 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 15 Jun 2017 22:29:39 -0400 Date: Thu, 15 Jun 2017 21:29:36 -0500 From: Benjamin Kaduk To: Michiko Short Cc: Daniel Migault , "draft-ietf-curdle-des-des-des-die-die-die@ietf.org" , "curdle@ietf.org" , "curdle-chairs@ietf.org" Message-ID: <20170616022935.GM39245@kduck.kaduk.org> References: <149663099768.3234.6289962833790815289@ietfa.amsl.com> <20170605025111.GW39245@kduck.kaduk.org> <2DD56D786E600F45AC6BDE7DA4E8A8C118C72387@eusaamb107.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphleLIzCtJLcpLzFFi42IR4hRV1p3h5BxpsPG7rsXMng3MFlsXzmK2 mDJ9D5vF064jTBb/uvkcWD1+fb3K5rFkyU8mj9Ydf9kDmKO4bFJSczLLUov07RK4MhZs281Y 0MFW8aHlBVMD4zuWLkZODgkBE4n23R/Zuxi5OIQEFjNJrH3zlhXC2cgosf7wQzYI5yqTxNfH t1hBWlgEVCXe991kA7HZBFQkGrovM4PYIgJaEh8unGYBaWAW6GOS+Nf0hxEkISwQItGyeDY7 iM0LtO/GtM0sEFM7mCS2tk2ESghKnJz5BOwoZqBJN/69ZOpi5ACypSWW/+MACXMKJEo8v7AH rERUQFni7+F7LBMYBWYh6Z6FpHsWQvcCRuZVjLIpuVW6uYmZOcWpybrFyYl5ealFuuZ6uZkl eqkppZsYQQHN7qKyg7G7x/sQowAHoxIPr0KDU6QQa2JZcWXuIUZJDiYlUV5+OaAQX1J+SmVG YnFGfFFpTmrxIUYJDmYlEd5wG+dIId6UxMqq1KJ8mJQ0B4uSOK+4RmOEkEB6YklqdmpqQWoR TFaGg0NJglfHEahRsCg1PbUiLTOnBCHNxMEJMpwHaPhPB5DhxQWJucWZ6RD5U4y6HE0ftnxh EmLJy89LlRLn3Q9SJABSlFGaBzcHlIgksvfXvGIUB3pLmPcMyDoeYBKDm/QKaAkT0JKgCw4g S0oSEVJSDYzOZbLRE1iSynLN9n5ZNaHUZU/whkPurGFTW6+kPVvaYCBVEeB2Tqb+RGuc86GF 1kUxs98+XMSYEfo38+jn9jtLXhjvvm+Q3fzkH8PCnet3bjxeY7Fu6xv5TW84Dj73DHq1RlWl qUp+re/3tQL3bY5GvlmisOYGi4trdfKy3ZVz90omf272eXdNiaU4I9FQi7moOBEAHS0O9B8D AAA= Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-des-des-des-die-die-die-02.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 02:29:48 -0000 On Tue, Jun 06, 2017 at 04:13:16PM +0000, Michiko Short wrote: > Also why do we only call out Windows. Perhaps the better option is to list all which of our versions support AES? For example: > > Windows has supported AES since 2007 with the release of Windows Vista & 2008 with the release of Windows Server 2008, therefore numbers of Windows which required RC4 should be low. MIT has... Heimdal has.. That sounds like a good idea. I think that calling out the two windows versions by name/number was an artifact of the document originally being written *before* they were out of support (but they were "going to be out of support soon"), and I did a very mechanical update when preparing the version after the long hiatus. Thanks for the suggestion! -Ben From nobody Thu Jun 15 21:01:49 2017 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 749681200F3; Thu, 15 Jun 2017 21:01:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.54.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149758570844.11259.2151834891785499164@ietfa.amsl.com> Date: Thu, 15 Jun 2017 21:01:48 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-des-des-des-die-die-die-03.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 04:01:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : Deprecate 3DES and RC4 in Kerberos Authors : Benjamin Kaduk Michiko Short Filename : draft-ietf-curdle-des-des-des-die-die-die-03.txt Pages : 9 Date : 2017-06-15 Abstract: The 3DES and RC4 encryption types are steadily weakening in cryptographic strength, and the deprecation process should be begun for their use in Kerberos. Accordingly, RFC 4757 is moved to Obsolete status, as none of the encryption types it specifies should be used, and RFC 3961 is updated to note the deprecation of the triple-DES encryption types. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-des-des-des-die-die-die/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-des-des-des-die-die-die-03 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-des-des-des-die-die-die-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-des-des-des-die-die-die-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jun 15 21:05:08 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 766C7127286 for ; Thu, 15 Jun 2017 21:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 FGNtQb1OcZjj for ; Thu, 15 Jun 2017 21:05:05 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 553C91200F3 for ; Thu, 15 Jun 2017 21:05:05 -0700 (PDT) X-AuditID: 1209190e-e13ff70000003671-df-594358eed417 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 8D.50.13937.FE853495; Fri, 16 Jun 2017 00:05:03 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id v5G452wj012412 for ; Fri, 16 Jun 2017 00:05:02 -0400 Received: from kduck.kaduk.org (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.13.8/8.12.4) with ESMTP id v5G44woW012900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 16 Jun 2017 00:05:01 -0400 Date: Thu, 15 Jun 2017 23:04:58 -0500 From: Benjamin Kaduk To: curdle@ietf.org Message-ID: <20170616040458.GN39245@kduck.kaduk.org> References: <149758570844.11259.2151834891785499164@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <149758570844.11259.2151834891785499164@ietfa.amsl.com> User-Agent: Mutt/1.7.1 (2016-10-04) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCIsWRmVeSWpSXmKPExsUixCmqrfs+wjnSYOdtEYutC2cxOzB6LFny kymAMYrLJiU1J7MstUjfLoEr40bjD+aCeWIV85Y+ZmxgPCrYxcjJISFgIvH4y3H2LkYuDiGB xUwSs45vZYJwjjNKnHvxGcp5zSSxe+4kdpAWFgFViWN/jrKA2GwCKhIN3ZeZuxg5OEQEhCV6 FkiChIUFQiTuNL5gBbF5gTbMnTGTEcQWEnCWuPX2FztEXFDi5MwnYGOYBbQkbvx7yQQyhllA WmL5Pw6QMKeAi0T7+TNMILaogLLE38P3WCYw8s9C0j0LSfcshO4FjMyrGGVTcqt0cxMzc4pT k3WLkxPz8lKLdI31cjNL9FJTSjcxggNPkm8H46QG70OMAhyMSjy8Cg1OkUKsiWXFlbmHGCU5 mJREefnlgEJ8SfkplRmJxRnxRaU5qcWHGCU4mJVEeD8HO0cK8aYkVlalFuXDpKQ5WJTEecU1 GiOEBNITS1KzU1MLUotgsjIcHEoSvF/DgRoFi1LTUyvSMnNKENJMHJwgw3mAhu9wBRleXJCY W5yZDpE/xagoJc6bCdIsAJLIKM2D6wUlBons/TWvGMWBXhHmlQep4gEmFbjuV0CDmYAGB11w ABlckoiQkmpglDNZ3TnT5tGN+NsVAd1v57VumXShdoZuoZOkzzM52wTuJ09v7V/rE//qzaGF VV0f085PyLz+kvWS4Zu8y3aPecN1XkuaOypzL4i9fufeM+fGz1MnBxzmuq9/aKbxhBe+y95N Ojl/044r2dddZ4Vcq+i4UceQ8m3ptiKljx/DrV6En1eZJP4hN0aJpTgj0VCLuag4EQB71W5i 5wIAAA== Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-des-des-des-die-die-die-03.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 04:05:07 -0000 This new version should address the comments raised during shepherd review. The new text about when AES support appeared (as an alternative to RC4) is: Fortuntately, modern (i.e., supported) Kerberos implementations support a secure alternative to RC4, in the form of AES. Windows has supported AES since 2007-2008 with the release of Windows Vista and Server 2008, respectively; MIT Kerberos [MITKRB5] has fully supported AES (including the GSSAPI mechanism) since 2004 with the release of version 1.3.2; Heimdal [HEIMDAL] has fully supported AES since 2005 with the release of version 0.7. Though there may still be issues running ten-year-old unsupported software in mixed environments with new software, issues of that sort seem unlikely to be unique to Kerberos, and the aministrators of such environments are expected to be capable of devising workarounds. (I fixed the "Fortuntately" typo in my local copy already.) -Ben On Thu, Jun 15, 2017 at 09:01:48PM -0700, 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 CURves, Deprecating and a Little more Encryption of the IETF. > > Title : Deprecate 3DES and RC4 in Kerberos > Authors : Benjamin Kaduk > Michiko Short > Filename : draft-ietf-curdle-des-des-des-die-die-die-03.txt > Pages : 9 > Date : 2017-06-15 > > Abstract: > The 3DES and RC4 encryption types are steadily weakening in > cryptographic strength, and the deprecation process should be begun > for their use in Kerberos. Accordingly, RFC 4757 is moved to > Obsolete status, as none of the encryption types it specifies should > be used, and RFC 3961 is updated to note the deprecation of the > triple-DES encryption types. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-curdle-des-des-des-die-die-die/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-curdle-des-des-des-die-die-die-03 > https://datatracker.ietf.org/doc/html/draft-ietf-curdle-des-des-des-die-die-die-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-des-des-des-die-die-die-03 > > > 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/ > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Thu Jun 15 21:09:27 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D54921274D0; Thu, 15 Jun 2017 21:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 hkTy0Pv8MPkp; Thu, 15 Jun 2017 21:09:24 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (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 2CDB3126DCA; Thu, 15 Jun 2017 21:09:24 -0700 (PDT) X-AuditID: 12074424-a07ff70000005b6a-27-594359f2bac6 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id C1.70.23402.2F953495; Fri, 16 Jun 2017 00:09:23 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id v5G49Luw013045; Fri, 16 Jun 2017 00:09:21 -0400 Received: from kduck.kaduk.org (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.13.8/8.12.4) with ESMTP id v5G49H1p013732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 16 Jun 2017 00:09:19 -0400 Date: Thu, 15 Jun 2017 23:09:17 -0500 From: Benjamin Kaduk To: Daniel Migault Cc: "draft-ietf-curdle-des-des-des-die-die-die@ietf.org" , "curdle-chairs@ietf.org" , "curdle@ietf.org" Message-ID: <20170616040916.GP39245@kduck.kaduk.org> References: <149663099768.3234.6289962833790815289@ietfa.amsl.com> <20170605025111.GW39245@kduck.kaduk.org> <2DD56D786E600F45AC6BDE7DA4E8A8C118C72387@eusaamb107.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C118C72387@eusaamb107.ericsson.se> User-Agent: Mutt/1.7.1 (2016-10-04) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkleLIzCtJLcpLzFFi42IR4hTV1v0c6Rxp8P8in8XMng3MFlsXzmK2 mDJ9D5vF064jTA4sHr++XmXzWLLkJ1MAUxSXTUpqTmZZapG+XQJXRuPSoILvTBX/Dv9gaWBc zNTFyMkhIWAi8WDfC5YuRi4OIYHFTBJbXsxnhnA2Mkq0/Wtih3CuMklMPDGVDaSFRUBV4sXs Q4wgNpuAikRD92VmEFtEwEDi5YSdYDXMAtcZJZ5ssgGxhQVCJFoWz2YHsXmB1vWcucEEt6H/ 9gcWiISgxMmZT1ggmrUkbvx7CVTEAWRLSyz/xwES5hTwk9h05zjYLlEBZYm/h++xTGAUmIWk exaS7lkI3QsYmVcxyqbkVunmJmbmFKcm6xYnJ+blpRbpmuvlZpbopaaUbmIEhS67i8oOxu4e 70OMAhyMSjy8Cg1OkUKsiWXFlbmHGCU5mJREefnlgEJ8SfkplRmJxRnxRaU5qcWHGCU4mJVE eD8HO0cK8aYkVlalFuXDpKQ5WJTEecU1GiOEBNITS1KzU1MLUotgsjIcHEoSvE8jgBoFi1LT UyvSMnNKENJMHJwgw3mAhu9wBRleXJCYW5yZDpE/xajL0fRhyxcmIZa8/LxUKXHecyCDBECK Mkrz4OaAUo5E9v6aV4ziQG8J884GqeIBpiu4Sa+AljABLQm64ACypCQRISXVwGgYOu+wlNnO uviUl17pmg0dCyr8EnfuO7f5z5V17R/3b8j/NWufyeTGXsOpdz/c28i+oVm+fvWDff9eFhrl h2mt+u23Rr4uTWp22pG66Ek/QtbfFGLtOP7DpTXrnrjAzF2SngxrbZ/8eZj57vLhj8te+grr 2xlM8DaV8bwn7qP6o+TLbf25t5cpsRRnJBpqMRcVJwIAt006dhQDAAA= Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-des-des-des-die-die-die-02.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 04:09:26 -0000 On Mon, Jun 05, 2017 at 09:50:16PM +0000, Daniel Migault wrote: > Hi, > > Thanks for updating the draft. I have found some small nits, but overall the draft seems ready to me to be sent to the IESG. I have prepared the shepherd write-up [1]. I believe 03 will be sent it to the IESG. Thanks for these; they should be addressed in the -03 (just submitted). -Ben From nobody Fri Jun 16 06:18:40 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD51129C06 for ; Fri, 16 Jun 2017 06:18:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, 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=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 qYCYKcc9iWSY for ; Fri, 16 Jun 2017 06:18:36 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::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 E21DE129BFC for ; Fri, 16 Jun 2017 06:18:35 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id m77so25203628lfe.0 for ; Fri, 16 Jun 2017 06:18:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=Gj44g3Gcpfye4UK+T2ByhhtHo5iZvHBfbPOACsxUlOQ=; b=IY1yOxTc/z9LthepTzPZZ7mZzJqSRWWuNQMrREcz1a4o4ly3RnUTJQ8+PiTLTmnQ1d /tV89M47HLjo/YEpFzk/VJMdBnVmQTn7H6eJqnP0hca+peZKbrKo+2S4qDFozU4zv0RK raB4GdTccCzbioIElGRO/neQukYgkxnm5qn0754qdNrn1nt/QMwj+dh8XdS8HrEhU2m+ eaeJhD2ox4/0aHpucCT3l/9OllfjDbEezXDYfV8l7uzSiebRW+N10LafoWqmV3CwTALJ hsh7gNQsJxjd8w67U5/hjNtGk4OqGTLRIkgV4yQPRfLI8xm0gx1quCpjS3mi3zR3vgAs C8gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=Gj44g3Gcpfye4UK+T2ByhhtHo5iZvHBfbPOACsxUlOQ=; b=Oc7ymWw51mg441SpPBOZECMNT/bwibOsZ/+m7HCO8KwPTU6X71b6vbHbkuN7wYx4x7 LYpo2IYEXYsdPzxFms7/JISNLwmQYuJk9juwt29eUPdK2Yry+kdIZahNe1/fAW/UDRjn LI0K37+cmcyBQuzbaFGpYX6KD1ZqEWaIxsLnv17mxsVRSxciUE4eyOALRlYb23MdNv3O RpslcCS9WoyMyfUeJohnsMOCm3lsuoSCbAiVeVyVY5/1rFV02D0wJRb2o//638YiVDJf vJEFVv9MF4CVY2YYnUeJecxbEl03A3tTTvtvLZEoYLGJjdWkcOX4fTWaskn9DZWBHDrc i6Rw== X-Gm-Message-State: AKS2vOzXqXht4cwElOHzrCdyX6h1P/K5b50zbdhCtHNLXc4R6Yetvu2F pGkm2pxWBxhtR6n8slZKfPgtFoTe6qR2 X-Received: by 10.25.221.136 with SMTP id w8mr3084281lfi.14.1497619113739; Fri, 16 Jun 2017 06:18:33 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.15.26 with HTTP; Fri, 16 Jun 2017 06:18:33 -0700 (PDT) From: Daniel Migault Date: Fri, 16 Jun 2017 09:18:33 -0400 X-Google-Sender-Auth: yvaeuudOYUBOwXpYd_9uL3lQ1kg Message-ID: To: curdle Content-Type: multipart/alternative; boundary="94eb2c0c921c488aff0552139f07" Archived-At: Subject: [Curdle] WGLC draft-ietf-curdle-des-des-des-die-die-die-03.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 13:18:38 -0000 --94eb2c0c921c488aff0552139f07 Content-Type: text/plain; charset="UTF-8" Hi, This email starts a WGLC for draft-ietf-curdle-des-des-des-die-die-die. Please review the document and raise your concerns by June 30. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-des-des-des-die-die-die/ Yours, Rich and Daniel ---------- Forwarded message ---------- From: Date: Fri, Jun 16, 2017 at 12:01 AM Subject: [Curdle] I-D Action: draft-ietf-curdle-des-des-des-die-die-die-03.txt To: i-d-announce@ietf.org Cc: curdle@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : Deprecate 3DES and RC4 in Kerberos Authors : Benjamin Kaduk Michiko Short Filename : draft-ietf-curdle-des-des-des-die-die-die-03.txt Pages : 9 Date : 2017-06-15 Abstract: The 3DES and RC4 encryption types are steadily weakening in cryptographic strength, and the deprecation process should be begun for their use in Kerberos. Accordingly, RFC 4757 is moved to Obsolete status, as none of the encryption types it specifies should be used, and RFC 3961 is updated to note the deprecation of the triple-DES encryption types. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-des-des-des-die-die-die/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-des-des-des-die-die-die-03 https://datatracker.ietf.org/doc/html/draft-ietf-curdle- des-des-des-die-die-die-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-des- des-des-die-die-die-03 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/ _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle --94eb2c0c921c488aff0552139f07 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

This email starts a WGLC = for draft-ietf-curdle-des-des-des-die-die-die. Please review the document a= nd raise your concerns by June 30.

The IETF datatracker status page= for this draft is:
https://datatracker.ietf.= org/doc/draft-ietf-curdle-des-des-des-die-die-die/

Yours,
Rich and Daniel


---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Fri,= Jun 16, 2017 at 12:01 AM
Subject: [Curdle] I-D Action: draft-ietf-curdl= e-des-des-des-die-die-die-03.txt
To: i-d-announce@ietf.org
Cc: c= urdle@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the CURves, Deprecating and a Little more Encr= yption of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Deprecate 3DES and RC4 in Kerberos
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Benj= amin Kaduk
=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 Michiko Short
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-curdle-des-des-des-die-die-die-03.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 9
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-06-15

Abstract:
=C2=A0 =C2=A0The 3DES and RC4 encryption types are steadily weakening in =C2=A0 =C2=A0cryptographic strength, and the deprecation process should be = begun
=C2=A0 =C2=A0for their use in Kerberos.=C2=A0 Accordingly, RFC 4757 is move= d to
=C2=A0 =C2=A0Obsolete status, as none of the encryption types it specifies = should
=C2=A0 =C2=A0be used, and RFC 3961 is updated to note the deprecation of th= e
=C2=A0 =C2=A0triple-DES encryption types.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.= org/doc/draft-ietf-curdle-des-des-des-die-die-die/

There are also htmlized versions available at:
https://tools.ietf.org/html/= draft-ietf-curdle-des-des-des-die-die-die-03
https://datatracke= r.ietf.org/doc/html/draft-ietf-curdle-des-des-des-die-die-die-03<= /a>

A diff from the previous version is available at:
https://www.ietf.org= /rfcdiff?url2=3Ddraft-ietf-curdle-des-des-des-die-die-die-03<= br>

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

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

_______________________________________________
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle

--94eb2c0c921c488aff0552139f07-- From nobody Sat Jun 17 12:24:31 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F234129B73 for ; Sat, 17 Jun 2017 12:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 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_LOW=-0.7, URIBL_BLOCKED=0.001] 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 DuPso9n48e_B for ; Sat, 17 Jun 2017 12:24:27 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3715912785F for ; Sat, 17 Jun 2017 12:24:27 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id e142so29796743ywa.1 for ; Sat, 17 Jun 2017 12:24:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=GIMedgTiY0zneV3rxvA84GekNP9bz6SLYHIXbEm4d5w=; b=EZpLW/2HoIfVc/IU/ZJV5JaVyIHU4IvITA57Qv6h7en4NTV20kfsswrLUMHXoEjvQl 6XCRw3Ui01kv6XDLWTkgucdlZP5TQvXMSnfcL+Ge4ZYrUNScgfGXCaWzcH4VSVgIy/W3 Rmw2fhUyxUNECsNJkecF42L+zuEJLrjC7S7qTmIruJ4pK9YqCRORobWyGZJQOOkaAvEX ByoR5NLZM0xJR0mmzr7QKKCQQ6KNUeSmgS1/2mFR4MnXWPtl3FBB+kRdbeJiOySqtx7o LPnDCYm5ANb5HjTc/cZxePfF0fJT2JNE92TBvleIx/MZZu+aMvkUY5Ya51F/eCkjyEMy 3ZOQ== 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=GIMedgTiY0zneV3rxvA84GekNP9bz6SLYHIXbEm4d5w=; b=QVzessq1CaolRlP/NOUnDN9ONlIGpHsIVRCe1PwOW9IM4sn49OuhgfTWn/uEtidFa9 yJ6S3wLhsVX9rnTgbbmwOoElvN97CzK74G5yG2DHSfK8qih4uhbnDgZFU2aY2rpUksYW pKgjGB+9jELqnv+5W2e8+fIuCHWggRd9G/DcC9pJZMFl/qBf/T5W1VP33nFBQgbIE3Zk NBn1i4ftDFViJdF5U9Q9XJ4l4WPke+ZhQGnq17GQjj+1eGXGAcJEJhApCC4ptJ0gQKhp zd5EYotdOF9qykJd8zuNmzj7sCzm46xII05EEKJtor4UavnwhL9ngKJvdJwRPX6yl/Mt NP5Q== X-Gm-Message-State: AKS2vOzhWT8CCP9BSdu8HxdCs/Ed9rMIOJhvvdZ0eINl82A+mUy4E9g7 po7rY7HR78BHUs6yNkFAFUnfSmjnkFe2q2E1Fw== X-Received: by 10.129.172.39 with SMTP id k39mr12927621ywh.74.1497727466196; Sat, 17 Jun 2017 12:24:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.144 with HTTP; Sat, 17 Jun 2017 12:23:45 -0700 (PDT) From: Eric Rescorla Date: Sat, 17 Jun 2017 12:23:45 -0700 Message-ID: To: curdle Content-Type: multipart/alternative; boundary="f403045e56ac97e47305522cd947" Archived-At: Subject: [Curdle] AD Review: draft-ietf-curdle-ssh-modp-dh-sha2-05.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 19:24:30 -0000 --f403045e56ac97e47305522cd947 Content-Type: text/plain; charset="UTF-8" TECHNICAL The United States Information Assurance Directorate at the National Security Agency has published a FAQ [MFQ-U-OO-815099-15] suggesting both: a) DH groups using less than 3072-bits, and b) the use of SHA-2 based hashes less than SHA2-384, are no longer sufficient for transport of Top Secret information. For this reason, the new MODP groups are being introduced starting with the MODP 3072-bit group 15 are all using SHA2-512 as the hash algorithm. Unless I've badly misunderstood the situation, this rationale doesn't make much sense. The security requirements for a digest algorithm when used as part of a KDF are very different than those where it is used to make a digital signature. Is collision resistance a required security property for the KDF in the SSH key exchange? If so, why? S 5. These security estimates are very very old and I note that keylength.com estimates are all over the place, but suggest that at least some of these numbers may now be too optimistic. (For instance, the Lenstra updates equations predict that 3027 is 111 bits strong). In any case, you need to explain what this table means. I.e., what is the exponent size, because it's not clear just from reading this document. Also, you should state whether these are safe primes or not. EDITORIAL The United States Information Assurance Directorate at the National Security Agency has published a FAQ [MFQ-U-OO-815099-15] suggesting both: a) DH groups using less than 3072-bits, and b) the use of SHA-2 both -> that both based hashes less than SHA2-384, are no longer sufficient for transport of Top Secret information. For this reason, the new MODP remove "the" groups are being introduced starting with the MODP 3072-bit group 15 are all using SHA2-512 as the hash algorithm. all use The DH 2048-bit MODP group 14 is already present in most SSH implementations and most implementations already have a SHA2-256 implementation, so diffie-hellman-group14-sha256 is provided as an easy to implement and faster to use key exchange for small embedded applications. faster than what? 3072 and 512? S 5. Using a fixed set of Diffie-Hellman parameters makes them a high value target for precomputation. Generating additional sets of primes to be used, or moving to larger values is a mitigation against this issue. Care should be taken to avoid backdoored primes ([SNFS]) by using "nothing up my sleve" parameters. I'm not sure what the point of this last sentence is. Maybe you want to claim that that's how these were generated? Also, "sleeve" --f403045e56ac97e47305522cd947 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

TECHNICAL
=C2=A0 =C2=A0The U= nited States Information Assurance Directorate at the National
= =C2=A0 =C2=A0Security Agency has published a FAQ [MFQ-U-OO-815099-15] sugge= sting
=C2=A0 =C2=A0both: a) DH groups using less than 3072-bits, = and b) the use of SHA-2
=C2=A0 =C2=A0based hashes less than SHA2-= 384, are no longer sufficient for
=C2=A0 =C2=A0transport of Top S= ecret information.=C2=A0 For this reason, the new MODP
=C2=A0 =C2= =A0groups are being introduced starting with the MODP 3072-bit group 15
=C2=A0 =C2=A0are all using SHA2-512 as the hash algorithm.

Unless I've badly misunderstood the situation, this rat= ionale doesn't
make much sense. The security requirements for= a digest algorithm
when used as part of a KDF are very different= than those where it
is used to make a digital signature. Is coll= ision resistance a required
security property for the KDF in the = SSH key exchange? If so, why?


S 5.<= /div>
These security estimates are very very old and I note that
<= div>keylength.com estimates are all ov= er the place, but suggest
that at least some of these numbers may= now be too optimistic.
(For instance, the Lenstra updates equati= ons predict
that 3027 is 111 bits strong).

In any case, you need to explain what this table means.
I.e., = what is the exponent size, because it's not clear just
from r= eading this document.

Also, you should state wheth= er these are safe primes or not.


EDITORIAL
=C2=A0 =C2=A0The United States Information= Assurance Directorate at the National
=C2=A0 =C2=A0Security Agen= cy has published a FAQ [MFQ-U-OO-815099-15] suggesting
=C2=A0 =C2= =A0both: a) DH groups using less than 3072-bits, and b) the use of SHA-2

both -> that both


=C2=A0 =C2=A0based hashes less than SHA2-384, are no longer suffic= ient for
=C2=A0 =C2=A0transport of Top Secret information.=C2=A0 = For this reason, the new MODP

remove "the&quo= t;


=C2=A0 =C2=A0groups are being in= troduced starting with the MODP 3072-bit group 15
=C2=A0 =C2=A0ar= e all using SHA2-512 as the hash algorithm.

all us= e




=C2= =A0 =C2=A0The DH 2048-bit MODP group 14 is already present in most SSH
=C2=A0 =C2=A0implementations and most implementations already have a = SHA2-256
=C2=A0 =C2=A0implementation, so diffie-hellman-group14-s= ha256 is provided as an
=C2=A0 =C2=A0easy to implement and faster= to use key exchange for small embedded
=C2=A0 =C2=A0applications= .

faster than what? 3072 and 512?


S 5.
=C2=A0 =C2=A0Using a fixed set of Di= ffie-Hellman parameters makes them a high
=C2=A0 =C2=A0value targ= et for precomputation.=C2=A0 Generating additional sets of
=C2=A0= =C2=A0primes to be used, or moving to larger values is a mitigation agains= t
=C2=A0 =C2=A0this issue.=C2=A0 Care should be taken to avoid ba= ckdoored primes ([SNFS])
=C2=A0 =C2=A0by using "nothing up m= y sleve" parameters.

I'm not sure what th= e point of this last sentence is. Maybe you want
to claim that th= at's how these were generated? Also, "sleeve"

<= /div>

--f403045e56ac97e47305522cd947-- From nobody Sat Jun 17 12:31:35 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6521129503 for ; Sat, 17 Jun 2017 12:31: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, 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 fH4KjM7SC72G for ; Sat, 17 Jun 2017 12:31:33 -0700 (PDT) Received: from mail-yb0-x22d.google.com (mail-yb0-x22d.google.com [IPv6:2607:f8b0:4002:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F56C1250B8 for ; Sat, 17 Jun 2017 12:31:33 -0700 (PDT) Received: by mail-yb0-x22d.google.com with SMTP id f192so19792884yba.2 for ; Sat, 17 Jun 2017 12:31:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=d1X8cPq3mgmwy1k4htetbXmkxcjMrXtjLJyZLoK/PzY=; b=HHE8FCnBDwUwvpJg/nKsOw95hcj4+K8X9+/xAr2HBDHPfQ4Vlo/LHcKc1uFQ4lAKbp s5ECn7tHEldTE9xtjEJQr7bCIdqUOW/WuG5jQ1Fp6oeoWjUk2KHvxJ/CpnhJU9OkJCIK we+dN/YI05hc4QQ7ZRg7v425rTWJvunV/ZvjbwxB9iBIcd7o3VTz8iXTh3khvL0A7QjX xMgiZTzYOGY30rKNNa7h/5GKXYOkqbh2zRwSS9vfYGwz1zjBBOEEKXLK/UOT4aGJMzjt RDwlPYSmamIZXMqKDDIFsYF62cQwIpSFfCOh5+7AcBpeMCytYkakaEuHZleUg8loKfcN TDcQ== 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=d1X8cPq3mgmwy1k4htetbXmkxcjMrXtjLJyZLoK/PzY=; b=ayHbvXoh3uyrundZOpIet3Ki/h+xPePTJZqc0+6ZTE4zY8fvgDsuRU8K3YiTVE9GYs rXmv0NtiZFw4SaysAd1y4G8VimvyXQLo6kPZoUWD+K3Djw87pBqTzKy3FdOfGVhcLsed J9LYftCp4+bvTS1NnevPpdCc3ah2MtxaOwa+pYJ739wQaOGAQOfqo5qr5sGyZOa51CZt sHRcXqNPovSIqlZrxF3eFw6hfZ0vuaja683uYMCNdEqftV5M5or8wAoLyFIkl0RWoGbU wP81KTvSQqVgV0a4SYtHCXbKolWpsSvvJET0yfub0ZfklUAAfCxoyfPH/YnyqXh+7xMn AT9Q== X-Gm-Message-State: AKS2vOzK3XVrjss7hHUPfT3S+AhnHK7Qdj5NwQVFWxKQWCy3s88WIrzN Va5N8zzpLhKEyJiuet1AFEGsDTjEThlCN/+Jzw== X-Received: by 10.37.30.135 with SMTP id e129mr14349867ybe.71.1497727892055; Sat, 17 Jun 2017 12:31:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.144 with HTTP; Sat, 17 Jun 2017 12:30:51 -0700 (PDT) From: Eric Rescorla Date: Sat, 17 Jun 2017 12:30:51 -0700 Message-ID: To: curdle Content-Type: multipart/alternative; boundary="001a1143f2f2fa01c005522cf279" Archived-At: Subject: [Curdle] AD Review: draft-ietf-curdle-rsa-sha2-07.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 19:31:35 -0000 --001a1143f2f2fa01c005522cf279 Content-Type: text/plain; charset="UTF-8" TECHNICAL S 3. Signing and verifying using these algorithms is performed according to the RSASSA-PKCS1-v1_5 scheme in [RFC8017] using SHA-2 [SHS] as hash; MGF1 as mask function; and salt length equal to hash size. This seems incorrect. Either you are using PKCS#1 v1.5 or you are using PSS. In the former case, there is no mask function and salt. Appendix 5.3 suggests that you are not using PSS. In any case, you need to fix the inconsistency. You say in the intro that RSA was defined as 1024 bit keys. Are these keys of arbitrary length? Is there an upper or lower limit? S 5.3. Implementations SHOULD apply PKCS#1 v1.5 padding to the expected hash, THEN compare the encoded bytes with the output of the RSA operation. Why "SHOULD? S 6. A draft version of this memo also defined an algorithm name for use of 2048-bit and 3072-bit DSA keys with a 256-bit subgroup and SHA-2 256 hashing. It is possible to implement DSA securely by generating "k" deterministically as per [RFC6979]. However, a plurality of reviewers were concerned that implementers would continue to use libraries that generate "k" randomly. This is vulnerable to biased "k" generation, and extremely vulnerable to "k" reuse. This document therefore disrecommends DSA, in favor of RSA and elliptic curve cryptography. This is an odd argument given that ECDSA is often also implemented with random k. Not that I am in favor of adding DSA here. -Ekr --001a1143f2f2fa01c005522cf279 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
TECHNICAL
S 3.
=C2=A0 Signing and= verifying using these algorithms is performed according to
=C2= =A0 the RSASSA-PKCS1-v1_5 scheme in [RFC8017] using SHA-2 [SHS] as hash;
=C2=A0 MGF1 as mask function; and salt length equal to hash size.

This seems incorrect. Either you are using PKCS#1 v= 1.5 or you are
using PSS. In the former case, there is no mask fu= nction and salt.
Appendix 5.3 suggests that you are not using PSS= . In any case,
you need to fix the inconsistency.

<= /div>
You say in the intro that RSA was defined as 1024 bit keys. Are
these keys of arbitrary length? Is there an upper or lower limit?<= /div>


S 5.3.
=C2=A0 Implementat= ions SHOULD apply PKCS#1 v1.5 padding to the expected hash,
=C2= =A0 THEN compare the encoded bytes with the output of the RSA operation.

Why "SHOULD?


S 6.
=C2=A0 A draft version of this memo also defined an al= gorithm name for use of
=C2=A0 2048-bit and 3072-bit DSA keys wit= h a 256-bit subgroup and SHA-2 256
=C2=A0 hashing. It is possible= to implement DSA securely by generating "k"
=C2=A0 det= erministically as per [RFC6979]. However, a plurality of reviewers
=C2=A0 were concerned that implementers would continue to use libraries t= hat
=C2=A0 generate "k" randomly. This is vulnerable to= biased "k" generation,
=C2=A0 and extremely vulnerable= to "k" reuse. This document therefore
=C2=A0 disrecomm= ends DSA, in favor of RSA and elliptic curve cryptography.

This is an odd argument given that ECDSA is often also implemented=
with random k. Not that I am in favor of adding DSA here.
<= div>
-Ekr


--001a1143f2f2fa01c005522cf279-- From nobody Sat Jun 17 12:38:35 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84484129B97 for ; Sat, 17 Jun 2017 12:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_LOW=-0.7] 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 f0aOMe-A4YD3 for ; Sat, 17 Jun 2017 12:38:32 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::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 F17D4129B95 for ; Sat, 17 Jun 2017 12:38:31 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id e142so29842824ywa.1 for ; Sat, 17 Jun 2017 12:38:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=yJLZNZdefACUN8ANFiC5TzGdnOjVrvGTh4ugACPA8hI=; b=y1bGrw78d+Ooz6F8EScKwnFfUFOGwp5la4sQ8qzw72ckbumPT39svYwbWTHOIOB4Fn DUoGMyYVeneEPrmP62iz5V3/ayEUbv3J3Rb90EwzanbGhCDkyJV1z6WuCmBSGZ8xPpB7 H7t9JZ137Kw4awSAmYEGXXH4XcV33DOmr8zSwVaMBdwNSFafQiNUFmxh9SWLBr6Z6gVe YA2QhqyM/Wta8rRfgtfMlqf/3SjsjxdpCKXZR2Vudih4JJTScfbJvaGnIwdIs4393RIt QVYs0FbQZBt2FavCJiT+3rbcE4Qc1qrLFPmhi4dQdeDG+b2JCDfS8F80pnwDaomBR80a Hqvg== 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=yJLZNZdefACUN8ANFiC5TzGdnOjVrvGTh4ugACPA8hI=; b=B3B0I8rJVMlpAho1XHc4DfzwPj6gX1WCXVxpjmR37odYTidwK2U8I9qJz+FcsvLTRg tF7liLpZBLe1w8pdrg8+59wPrU3W+cbEyOcMeyaQWCO1oqM3XuP6SG/xvpxVSJv358d7 2vhenbVJAgFA4trsqRvvfTzROAMpjt3P83OWUQorMYz0/ceoBlhmhWj6noV6BjsK1cRb yT4kltx3RES61ijby9r4HO1TY+oHCQO+fB8lPJtlGqubdTDZrSUNjzDZxu1KCnhuC9sE OCwKDliLxM79hZum+jFo6mbK+IlKpKPqUbt3pZrZb7B3eSRlS+9nCpjH2rppZyq378qY prvw== X-Gm-Message-State: AKS2vOya5CE/3BwvdDXTy22+Jn3DQ+ZeYXpZzXgc614cLeFqEqjOLyb5 guir1riw5YI/O3ymSkjhHqYyJ18udUk6amUgfw== X-Received: by 10.129.172.39 with SMTP id k39mr12957653ywh.74.1497728311092; Sat, 17 Jun 2017 12:38:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.144 with HTTP; Sat, 17 Jun 2017 12:37:50 -0700 (PDT) From: Eric Rescorla Date: Sat, 17 Jun 2017 12:37:50 -0700 Message-ID: To: curdle Content-Type: multipart/alternative; boundary="f403045e56acf3ea5e05522d0bff" Archived-At: Subject: [Curdle] AD Review: draft-ietf-curdle-ssh-ext-info-00.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 19:38:35 -0000 --f403045e56acf3ea5e05522d0bff Content-Type: text/plain; charset="UTF-8" S 2.1. The indicator names inserted by the client and server are different to ensure that these names will not produce a match, and will be neutral with respect to key exchange algorithm negotiation. Can you explain what "neutral" means? S 2.2. If a client or server offers "ext-info-c" or "ext-info-s" respectively, it must be prepared to accept a SSH_MSG_EXT_INFO message from the peer. Can a server send ext-info-s if it did not receive ext-info-c? S 3.4. A client sends "y" to indicate its preference that the session should be elevated; "n" to not be elevated; and "d" for the server to use its default behavior. If a client does not send the "elevation" extension, the server SHOULD act as if "d" was sent. You need a citation for "elevated." --f403045e56acf3ea5e05522d0bff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

S 2.1.
=C2=A0 The indicator = names inserted by the client and server are different to
=C2=A0 e= nsure that these names will not produce a match, and will be neutral
<= div>=C2=A0 with respect to key exchange algorithm negotiation.
Can you explain what "neutral" means?

=

S 2.2.
If a client or server offers &qu= ot;ext-info-c" or "ext-info-s"
=C2=A0 respectively= , it must be prepared to accept a SSH_MSG_EXT_INFO message
=C2=A0= from the peer.

Can a server send ext-info-s if it= did not receive ext-info-c?


S 3.4.=
=C2=A0 A client sends "y" to indicate its preference t= hat the session should
=C2=A0 be elevated; "n" to not b= e elevated; and "d" for the server to use its
=C2=A0 de= fault behavior. If a client does not send the "elevation" extensi= on,
=C2=A0 the server SHOULD act as if "d" was sent.

You need a citation for "elevated."
<= div>

--f403045e56acf3ea5e05522d0bff-- From nobody Sun Jun 18 09:52:43 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D45131270FC for ; Sun, 18 Jun 2017 09:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ypvwuwFKyLl for ; Sun, 18 Jun 2017 09:52:39 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0103.outbound.protection.outlook.com [104.47.36.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98BE112949A for ; Sun, 18 Jun 2017 09:52:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=k/kC2zAEnQKSSQ/uw4essj1pEQF9tySzs6QFy+aO93g=; b=j8T0Pht5b5qfXyHwVOrXibj3LclDfvlK48D6/2SX8mcv8rQSR1glZPS4eN2UDqcPNoCo2X9zr21KPpnXmOfCphpuZoOV5k4YursespmSruop6zoml3euixpVHVatRGQU5E5f1QTPivCsptzOb/MjrJKRN4LaqxAlEC6tuNsoRXM= Received: from BLUPR05CA0053.namprd05.prod.outlook.com (10.141.20.23) by BY1PR0501MB1655.namprd05.prod.outlook.com (10.160.206.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.6; Sun, 18 Jun 2017 16:52:35 +0000 Received: from BY2NAM05FT051.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e52::207) by BLUPR05CA0053.outlook.office365.com (2a01:111:e400:855::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.6 via Frontend Transport; Sun, 18 Jun 2017 16:52:35 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.15) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.15 as permitted sender) Received: from P-EMFE01C-SAC.jnpr.net (66.129.239.15) by BY2NAM05FT051.mail.protection.outlook.com (10.152.100.188) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1157.20 via Frontend Transport; Sun, 18 Jun 2017 16:52:34 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by P-EMFE01C-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sun, 18 Jun 2017 09:52:33 -0700 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v5IGqWw2008899; Sun, 18 Jun 2017 09:52:32 -0700 (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id 760B61141B; Sun, 18 Jun 2017 09:52:32 -0700 (PDT) To: Eric Rescorla CC: curdle In-Reply-To: References: Comments: In-reply-to: Eric Rescorla message dated "Sat, 17 Jun 2017 12:23:45 -0700." From: "Mark D. Baushke" Date: Sun, 18 Jun 2017 09:52:32 -0700 Message-ID: <61120.1497804752@eng-mail01.juniper.net> Sender: MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.15; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39860400002)(39850400002)(39840400002)(39410400002)(39400400002)(2980300002)(199003)(189002)(9170700003)(7846003)(6246003)(8936002)(356003)(38730400002)(6266002)(8676002)(81166006)(106466001)(189998001)(76176999)(2906002)(50986999)(55016002)(54356999)(110136004)(6392003)(53936002)(2950100002)(7696004)(50466002)(77096006)(7126002)(4326008)(230783001)(478600001)(117636001)(47776003)(86362001)(6916009)(53416004)(105596002)(5660300001)(76506005)(305945005)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1655; H:P-EMFE01C-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM05FT051; 1:/TUQrGGYjUduWdVffMpJtxaIi7ufhZnXSNqBBC1LwZIsZb1vTIbwqgG3NRH5QZYuR173gTCO8aiKE8dfs4OZayiqpcva7EfJYwxwjgjyw5Z/8195YbwQRHrFBi6laEIt4q+t5dIdoqCR1SAsuRnxSPBJha6tbjXAm+UH2CtbTWd5Xq+7IvtgmQrt1II6vl9UV9oSsVGCtRd227NHsNx1SKTfZdE3+f6W0hWR5mGc+39FKkpx5LTt0vjooxBvc7EikWERCrvZxIA/e2kFaWexup7QXA9QteTL4hF4svFJIsyRXM0EyVgGc+I4aH4Ed6KOLTsLOkBkfhMlGJkdkQepQXlw1PAR7g6njajMLae/oua057uqh71Sk6vLomlXI42+SgesdM7ANWuU0HJR7/rpngwRxny5jrcSovyQSW0p73fyEm7taB9K77X9IarxQLYrgGIeP5/ImkHpLu2VBia+t62CpHSzowYzIesvJfEtbvb3HBQi/u38xNNOJgDRuC2/2fxtYXYl1v18SflxBjQTn7E6eJwod84qiyVorfY25ac= X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 4722b13a-0f9a-4a33-0d99-08d4b66a6b07 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500041)(300135000095)(300000501041)(300135300095)(22001)(300000502041)(300135100095)(2017030254075)(300000503041)(300135400095)(201703131423075)(201703031133081)(201702281549075)(300000504041)(300135200095)(300000505041)(300135600095)(300000506037)(300135500095); SRVR:BY1PR0501MB1655; X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1655; 3:TgHAlXbTCmbjC8Y4/dztAuOu8yTmKSzgsmK+MXWmatehxs9UiqQzPk2kQMQxF5W+PCILahvDKfeJr3FIcDa80LrdpGZ3yi9z0vENOBZopzlbsRkXd7ORj+yc5S9wcZLqx50lRlrWQS0too9DJ+Pd1yTCYCcztBr4ZiopQeLr7Wn8+2rKC+gXohMQen4+TQiPIzILyjuxhIgmVNlPwk/smstPms7ed89PKct7NebW182Z/GvC0gr6xireOY2owJE8wdT49L63JX8tiUtKUPNTWbLi82MoNFjsYCkDMyPf6k6EHJsG+rV2xnFEHbn5WresdWn8R/668Y17CPiHf5glH9Vg4JjAKrEQyxisufOUpwIDi1RkDATpE5qtuIOs6bvGmLIHeOMZBmV3wd1tsCXF7yiwbe5wcQ7jQ/js4GDDI3BiFcmEXBrZfQYVnZ8k1ZnajqmxoZADpxXzN/S2KXlNgQMREZEoNvvhWXtynMBVOYPIrMJW0uwcBG9SEwOTl1PQBdao4DdJLFNsPyMF7xliCEtlRXQDl5NkfALBZW+rRGH2NTjYfa1i0YkJbus7sPl6um1Kv4zNzfQ3TjGWTam0tAGpB2R8sKWU1KB590gEb4uZbYnQSDXZhTxWNRy5GbYKKWZW0EBVJb8vbNwiOAS+Kkoz4dc1+b/eLEOiJ+59jc8nUbUvC3oPjeEbifiMulL/JFKdAxL8CsBmPriCECO0vba6FTYrfrizSs6swLpEJj+6dUccFh1TdBknXzO9VL4i3En9uwvS803HSZ7ALl/Dz4UEKg69IJ73OtDYjwZ1bNC2GJ+ZoGop4uaMg394nnqA8r+kdt3qWIyH5Kljrgxi66qTgnIaguA4ofGOSHIlSaXHnXijfI4uDhUUzd+WNIe/8rLheLze2VenfdCZb8jyRQ== X-MS-TrafficTypeDiagnostic: BY1PR0501MB1655: X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1655; 25:jJTFqk3STQXuXpbuQx1+Pt7spMGHc50vHsQu5IDl0cKgCE3acd9IovM219mHTgVYKmF8zrFpn/PN13SdoHAJeJWikv0e0hqtU0Za2rKgEzrm4pTkhmHf2XSuqdGrLiw8n+nwQaeRY3VpOcjLhnz4acjuPt74xsK/v6Xl0paCBgtNioc6JedUikHi65VJcZ5SmvaDW0ycTFzRnZV/kDnOQBQOGLyQnAPmOMaJBdg9lrqRkwUJwEOxjMklUg6ugrSkUL0Uj2eOFHNOGkQLGYBz+D7U3q3AvxKbqUtnvGx8NfxSDWvUNkiNUEhFK5jrW/bJA699Lt9JAb9JUcsk9MCQdkDhfXpwrAcED5ExvYeqj7cMdrRKKdjtBA1jRTh3NMPl+1+NCiuGUHKH2HeYpUemVqtdZTsDhv9HAVus0cZBV6GoyVYPiWnP87FW1IQxKTZDMGgMkmVps8wrZM9rKmkvP6JIUatD0AklCygUDI83MY9m+q/4kePzjxIPKH/gOdxmMXVCF73EYL935Eg1f8vJFPh2Q3Ddu5WgJtNTghos5d2FseCG7P3M9YwauB+hw6RyVm10B10YYzNLg7LdEkvDl+ODSgz00BBzRq7oPKBQYBaVc9R5528bWq7bKFMw2HgViF762ffzoPMy/LWIC6TmQis/vx7xr+smPPy+qiqiZKmvwIURDg8j8lMVbsOc+5SqcQbaadch8kwAh5R+rbjEzCAajR3p+bwwZMukmtJjFfIEZTj5hV8vfR9RFVulFZmgjcgOb2hnBfnEy9gQY5M9DH6e4WrEU0/W1ppEJDihgEUTTP+gBxIZQ8vHpMbE4Pj95yz/akUM/UNbKSyuEf8egCr19zK5rjo9gkoBSwtUeV8D2bvC6yXmQTQUhkX1EKiwrCpcuhYOvPIVI7ZRM1lJpoJglLVEq0itI+ug2wYr418= X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1655; 31:tTO1J688nevVad4Nh+k9Xj23oB8dW3s7aGiPbEvEJ9fnZwCrt5XchjZwwCFeBSwjxbMBSmjvuXXuvnOuKauSb06JYxmEq5aKdaci++rm4ZtFS7zx3Tuhx8ClxAFg/rqxXUxe/3+2JvZTD6gvWfW8j9KLVx3PhZwd3u5llmCwHNyxov+5+y4ztGSTp9/dmpigorQYmqWgnE3M8byt9bLGAat8N0RMeJyB8+Fs6zWF15pRFR0EEG2MBnz4/1ItAfJG3V4c6WsC4FnhejiKE28WS+lmAWWewUyaMHQ82OdAWYvbp1WIrXGN12nnSlb9KtBBTLbhzwv3Vwj2EpDh+p1tN9t3RX/7Vt+sae9K1vuxTEZZocMUaIM7SzsZo+eowvTy2qRml4po+IsrHqNwqT1Zz+HKJLdj37YKSHDSJP7Co5W6a65uzBfpT54InNgz9NuWNbSyuUzLRLwpwhkhkLfvcFcURSHoCZ92PIEcgQMhAtUdQyQeK9984xS0OTMbzjVtHwtW0N8SlfPpRfdhqog3LZ4mMw02HS6nlOU4KfBVmzn/h5JUyL5sswTI4QuIBrmN0h2SIYJW2CHJEU14ON+ZSVjRF8pI/+p5uI/1T7xoYXiwbz6pDeyh6FC/9a9ok3idoJ4k3lkL0+jwIme6mjP4raNYVrZyYhkRms2vWVHqLYrbr3nDYAY/0tGMx/WeXO3jLszGxA7yye5UNycsy1YLKw== X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1655; 20:EFuzuEJXiT5hFvIe70VfY5GYgu4hn69PnocF14iNuPolxgV2Lc+o0IfY4Bje+JEBEbnKjwX4HWudswrC0qHuoD0Zc5ayRLwI5C8dq6cnjYId7mAnCcEWGU84mGYWYpCYaTUnVqS9NVyf0NaLusZB5NwdUYUl8XRZq3W7kEgi0EMFBCgVqK2akNBvs0Ab8kXt1COlmaqV27pCvEic1H/gKTpklHemovmMwJTIlYibVtf41hInIxpaxdpstSI1OKVTJUgxvv813AdoY1lLDgiP3T0Vqe0kwI5XQIUHbOFY2PMvl6ttrKYHNLsPf5uT2SXw+fAVtrp0vo71bx+HqjXpCZwXVbsLkYMULQ/IoPGwKcBvxptWspw9kkHw+SZ4bXNfR9+jIk9lgHl8bxz1uGcAgJp89rt73/wjJX/1MbDF4JoMPUeSJuAGOQit9QlXVmmu+tPhamE4vLbRRGVB9rLMzLBNQCnbXjaBZN9kyHcJ9g4VTb7D615EbE6kCfJdg4dJ X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(192374486261705); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(13018025)(13016025)(3002001)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(6055026)(6041248)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BY1PR0501MB1655; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BY1PR0501MB1655; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY1PR0501MB1655; 4:dSe/N5/DuUf877DWjrvT03A2VMShH4KBLaldMypH?= =?us-ascii?Q?d3VRzR0L/R2zUKfm/Ie9yz51k8D9ymBVDJdB5GT/2VXcEPliEnRhf8l4EwCJ?= =?us-ascii?Q?7YXEZDDz2niuskKrHabIhrG8trcTatI7wppzA1QozawNU0g+QdxkpOUOqkwc?= =?us-ascii?Q?+tlsID21HvBcSZM+ISoXlqyE655mQQe+TU7MY8DM1lqDMN3ow1t5/SZh2FKR?= =?us-ascii?Q?UTlW+VdymcV33jPHaT+3w0EsmjWfpnmFMQ2JCZX7aD/N7tefAXE9D+O4G2zZ?= =?us-ascii?Q?cWCqSP0nNOKIqTOI8OBi/4bO6aIk1yxoOZO6Mbz0q8Td/MWfi89vNW0bW7qn?= =?us-ascii?Q?yUC1acMMHvGWY4gQoVyQKpVpx2rj2RyoJiLDt+QWL/LzDsfqaeS74j/CTFSx?= =?us-ascii?Q?VN5MZFxXMbkYupVTrZHFors70a7ogZF3DNEXOXcySn391qxFNMsJQmVrD9h4?= =?us-ascii?Q?SBmY0s6VQiIWT5buWCDvzn9PUkme+l4gYDFxfOc2ML3vlHpdwjQkxQrqry4b?= =?us-ascii?Q?NUnO9/3FVxd20wuMjTC1euX76JHFPZdiCsB/uoVpXXhrBPzmwTKiS4sFvfhc?= =?us-ascii?Q?OwznVvLlxA9uI94j0Sa78xrHrD2ZBzc6nLc4SKWRgaoZTwyF7EH7PEcDZNvO?= =?us-ascii?Q?kk+Q23ohh+Ok/gwBhtpRrU6rfRmsN/cacSQoJPvkGshmlQtloUHBzNol45dI?= =?us-ascii?Q?aDSRi3M6wAXIrVynsXl9wNCEAmJdJ3t1r4CzFcaotyMqWFD1+8pUKcQeR8l7?= =?us-ascii?Q?UcC04AxgysZ0I9whiX+gV8sNfFK3C7fvHl4RUaK1ko4kDp1J4dr2ECoh85gs?= =?us-ascii?Q?wERAOxGfBg00IqsDN/XqlAxIil0jfd1BNQABvueojUQM7R5rizoJaL54xQ6X?= =?us-ascii?Q?iH/gJ5q0DZIPqRVC7+2CnN3ohWWinTHZoIm8+25rUGsvyaL/cAANpPvMemEJ?= =?us-ascii?Q?Ud7gU45fM7vjUz0FFQC762U54WUO05XpD5jjSDFGo1TfChYB9EP84mBHCs73?= =?us-ascii?Q?3DzntY+isl5+/cjE1UpObybNohtaChJyKlVJbivB33ct9/CWOjUiteDH5aKp?= =?us-ascii?Q?uFv2UCM4MTcL2/yXlVJjSZV/gRIBVpVibxREv47+z+gWpHBwn0kkTRwkCbLs?= =?us-ascii?Q?YkD3b0JyhyJKm7fO+IM/VYtKkiqj9Vf5oV951tyaRxyH4tTPGno/x/Qfo9tI?= =?us-ascii?Q?hqqZgwzJUKzDuMQyPOG/Yx8I8zzFUplOESSs5eQoUfbEyZvDPhc/TeTnmq5G?= =?us-ascii?Q?ctVEBsW1NGBo3E1xYtk=3D?= X-Forefront-PRVS: 034215E98F X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY1PR0501MB1655; 23:/OaGfbqqR2zXoHyZ4AKPBNlhlkla538A//l8ull?= =?us-ascii?Q?xSdpr0gGwmFE8ZHNaD0S0EgeTE8pROSYVs150PSDuboe2vHWe5lVat8KBbLP?= =?us-ascii?Q?eEYn/8gRVDB3IaWr+8J5qlyjpLuRwOOmg0RiCKJKZNOWxbrOAPK/ddGMNFKI?= =?us-ascii?Q?uyhGiMvlN1mbVbKbxyj2AWJS/4KToPy2X8hEQbPcijfVP1oaZQknOv9DYmyB?= =?us-ascii?Q?QS2DGsV5NGGcc0YTOr/zokQNpXQcUp+UWYRM6oTAxA7d2NndI+0d+H5y+w+x?= =?us-ascii?Q?AB+MJD59GN9iDJEYmphK//kt3T+Tp+xl03DQgK6omPe9UhjwcUVNWAbWMcXU?= =?us-ascii?Q?wlQFnjpX6CvhN3uDicY37/CM6LChI9aS/QasS2K8zx3bxr9yP2+OMNI2+LJe?= =?us-ascii?Q?YRsXfh+vFWAKGZf9nX3LUvFugh5gQaoMJKcRAPCi0i9Ffe2rhPJqJe9hq/0x?= =?us-ascii?Q?ZsyS30sOrL9B2fu/FBr4/zdH/MSbBn6NOOWt+IYtOjqDRP2k0Hnhvol09zmR?= =?us-ascii?Q?oaOzhVOXNcyOC5iFSovjEg39+jBCxYLYqjM8aizB8Uy1/QarDgB4efhAox8N?= =?us-ascii?Q?1njJynMfNASBVxYNy8hRYqMaOptSc3FAb5QS8x7E20HUNs5yKcO9RdZ+yBp6?= =?us-ascii?Q?5GM/dD+kO6C2MIhSbTZkWC+6VXZl8RF/jZdKgqw51uStLpf6FnTboSEmpUSr?= =?us-ascii?Q?sYqty9h5D0jpnWE3Rk25CsFpnaVSaTIlZOK8ahGl5MK8Tgspxdejm1jtOSiX?= =?us-ascii?Q?Y9oeJRZMWpjtanIR/PXwq6Se2r7KEiWaGXqMs7qJekcL0xtPLDmYTIVwKAwE?= =?us-ascii?Q?tB6sau8ybA4ML35tVlGDeWCyU73tky165RgpKfXCF3VZwNfgn69r3eF/0kvV?= =?us-ascii?Q?7BppvrZ3m2xSVM0limyQ7iE/uQdb5EKfpHZHmlUdtI5Lrs0H6OLm8eyCtGun?= =?us-ascii?Q?b6nfs377EcnHxTLl5tW4Ugv7RGYsKl33nmGhHL0fyMnRQsDuLH31P4CwRF+V?= =?us-ascii?Q?CmHZsrd71ivMPNuqs2/OBJGS5h64TMG9u76WSXoyJcPInw8mt7mDSzdgy7Eq?= =?us-ascii?Q?tq9LqrdLa1Z5arXUlr+Bc5TN0uefWmeHb641K6Zg8E6h6IR4SZfR4ZwwcEDF?= =?us-ascii?Q?JK8xG89nEhxqyuhLa5XgfNbPny9tmwqrzuyWmmSuoPu6NLILji9IG2w=3D?= =?us-ascii?Q?=3D?= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY1PR0501MB1655; 6:PyhFKM+F+2eg2fgNBW3zOsdcOflN2TmF9Q/FFVkw?= =?us-ascii?Q?RGKEe7Ukg9hIjCFhl15IVurkFtrTi+DooDQRcVZXHQhDpFRSGwG0ZTmCbxTv?= =?us-ascii?Q?WStuQExXeOegrfda4SbSFhRgwyGV0JNQzvuifl/SDZlSjSIZxSqZj9we3mnv?= =?us-ascii?Q?7pEa117qPgAtbrQEePD4ezhih4gZ3DjVdxhX8bv7Cq8DPT30p+Aa3ZtbPlpu?= =?us-ascii?Q?yHym+bxifgUmjTVwnblrvf7s3W1N+kFohGzjipqhFMkETJ/2+XTDNA1JxuWK?= =?us-ascii?Q?BQe0bcEeCbogzw4cTgXQj8YUVsqVvlkz3gshCubFCU1Qv0ahAjfk7XWbleYT?= =?us-ascii?Q?xImHNfL23fNgu/2Z5eo6AWw+lG1r22Cxe3oe3DU9akB8D4L9pzSgL9TObj50?= =?us-ascii?Q?RLnj2AZ8JHIF4A8cNhxD75RMWxEL1WX0mPE/BubOp+Jefj+JK9uDlnYgzy3m?= =?us-ascii?Q?Sxvh8i9yacaw7yrBxCZCbDYD0q85OXXpNfS2eCpmcYgySpbACQ+OcvIFh4iT?= =?us-ascii?Q?l2xj3sD+YtYbKNvhvhwCGyxz/WT8iLbQDdfJGx7X2AsQHNTFL7eub4kporq+?= =?us-ascii?Q?Wh+OQeoq8YVwbQD5TnqTB8PcET12Bx6pK2TyWAA5Qy+0ooFQrSi67f+QMRBw?= =?us-ascii?Q?PjoHWFUX9eNqSMXzac7a6trAyibgL7z1+1N4Tihbwz+Gv7SIEVmlFPoxbHJh?= =?us-ascii?Q?+VZK00Mtk7L19VqXfgYe5UIbbKz+4DyEY6IsrdEi7ZXGAGMehGt1vYoE1Ap5?= =?us-ascii?Q?eHhu9gmnzqsWSrxm30lUznqotaA6NRmHXYRqmzv8luDeZu+z9zDeQdupF06D?= =?us-ascii?Q?fjFmY8xivLyAT0XYSpQkZQA7Lc4XBiq7zM1IGG9urdwL96bzdJYm5MkrOeAC?= =?us-ascii?Q?zHUatCb+SYhGBVswTH+pAcyprOyYsRgYDaz8vF3tdw1IA1ifoYULRozt12Ti?= =?us-ascii?Q?agYUQo0j74Q25gIRWr3Ar/k9hoVazJ7c0k/RkfsG+8ntn4WvEccel/hIwY/O?= =?us-ascii?Q?J+GKAMdgEmRVzZSTcmlTtHEs?= X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1655; 5:XA6efJAD1Q3NKAMW4+A6rDOn0U4QdHiycHlPapxIIAx+28Bv1aCVzHL0tD8Ivfd1nfXoCznvTieR7UPRkABmbPFJPUzW8WOzWNvmpWMEGEIflMgSfDSk1y+VH3YHKxgCQ6wmPboZeF5Er+Vds7gFjm/bhVKugO5kCrv4pqqNrOk2PCiQtIM6flW7uBg85v35UASvzUvn/fDrSpxauqfWry4McE8YoR8X8QTkC7OKmlUYSFYUbAwtqlNqG8qykg4R8lfDSfXnfYn7Te4zlAC18SAiB8YykZawqs9Hh284GBOFtCTwLkrd7mkSgijL6iyiL17WngxemkSWxvr072xAPWSHExs/V38/Ac4dtyoIIpKct/ILtWu7/e+kY8Ae5K+yG75txcwkayuwnjSgp/SRShdR7VBLI0Th+t8k92PZxYJloSDFkvpRCFXIKFnro79Owi47UOMWGx064gMgS1iuxGG+K1QIyJQMyi8t9+QQyPFyKB47yxvqTmq6yyQb9VjJ; 24:0yhyXBc0GpMiIXUB8WS1aSyg1FeiTXJKY8M9mp5K20U09kbxZKRU1zoDt1UTqkPd7BpzQh7PHK4avwL100KLU0SXJkpmkDQQ7JFtKp4Whxo= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1655; 7:L9TRXzRBqnnJzOPNrszjj3uCihh/I1U1L0FaZn0axTmOU94MMGLHk7D+VqIwL65fVFxMNLiva4Oohwe3/GTVVSAZ6b0wv9aPqn89AILcFp3Mm0Ja0DdBdVIjK6ugAGpXrqtP0QsZ5JFj39g5k6i6Y0nUiIKyafPmQ1cFu6VirPxhdKtfrZJVbSqXTCZRQfuEz5koERQEsX6Dy63r5pMx0BfLrMmi4NYXnz4dVS3RCGJp34+KjhT5MTayKSpPi2LNTqVq3VWVApPY/iSlWdqdZp7BUNap2wQfST7UBKfL/+4L+oOpDgQydxOEB2zWwD/pvNQiJBk+SIaYDF0x9n9XNV4hB93RNXg1MzF7Mn6mE1RYy1IaR2SKrGip6s8l2laPtwaNKDBGzEM0vZ1E175v8eJNp952tmcLo2D6HetoX01UFttZKyHfE+2eEiMoGx+HHQjr3adlZXxJFiZcI6WyPgI/DV1uPLGj43whgCWlvZVE5Oq7DvkWJxdfCBnAJFeSE47Trpo/iWyUrcgPG+lBCnqT4RQMIglEbQvossCJngb+UKGC195JQfRfhAIN9wVVegGF22lrOyQ9VixP/van4AKGMSjKsp6dTkS2iyE9TZUY4nsD8Vu7sUzIzRy2jXJLtNOCBd9PNdZzStHh2U/H3Fm/3g4TGXhq+6mhB1tp+2KuUJbrlwixHPS18sd9sE4kGD8jTWRlmKVHnZNf4fNiBEypgpfO/BidQBhlYm0+bmT18f/R5zC2OcT0dTOcfp3fhSCWGbDs5KrR+0ndqU7WizA0qkXb50l7abTKm8SF9ho= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Jun 2017 16:52:34.2151 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.15]; Helo=[P-EMFE01C-SAC.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1655 Archived-At: Subject: Re: [Curdle] AD Review: draft-ietf-curdle-ssh-modp-dh-sha2-05.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2017 16:52:42 -0000 Hi Eric, I will rework the rationle and the security considerations sections to address your concerns. Question: Is it your contention that we should be able to use SHA256 for all of the new MODP groups because the internal state of the hash will always have more bits than the maximum amount of entropy in the Diffie-Hellman shared secret? Thank you, -- Mark From nobody Sun Jun 18 18:00:58 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7DB126B6D for ; Sun, 18 Jun 2017 18:00:57 -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=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 hWlSqAAsVM0Z for ; Sun, 18 Jun 2017 18:00:55 -0700 (PDT) Received: from mail-yb0-x231.google.com (mail-yb0-x231.google.com [IPv6:2607:f8b0:4002:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5280F1200C5 for ; Sun, 18 Jun 2017 18:00:55 -0700 (PDT) Received: by mail-yb0-x231.google.com with SMTP id f192so23935894yba.2 for ; Sun, 18 Jun 2017 18:00:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tUnL0G1N4N6puBj6k6quSRMdIgtOBs2AcXUHVBR21p0=; b=UmWV54sOtaQaKPxt4oJfIOcw40nNcPUwzG4bhvwpWoRskmOgfyZ2InjEuDQcGSLU0m 3scpNBZocLIke6SwyCWM5bnhbfpW2ZKnzhyiFf9XrtMnCwU5OLSzYt753t4rD/eUJD8D I2jDjlkOrpT/HZ+L84us5aNyx1JSS8xahy6c1D9KPGbh/n/tHa1t3eVEvYwBXY2C+gG5 THGGzSk5VeIXkZASB2PCwD3HDaKXplUef7yZNTT/bKK4JhkAEwAlIUNoYaqqi3UD0980 z+ODftxLxsw36bVgX+mlHUW3KmVebjn5LUy68JbXmecRZ3+r+7R9uqnvhUObkwBUGiGB 8Iqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tUnL0G1N4N6puBj6k6quSRMdIgtOBs2AcXUHVBR21p0=; b=Sd0bbpjn5VPKQsTArA/bA4ILXFrLJJe2u3/qrZLw42frnXcy3K8MwK5vsbBV2Zz3Mx l9MXM28/K+RrWJBRYHaBARQypUISdwL6aIwQM2NMESstfGe5ov/IRINvZYAlZz4CWrsX D7hVTrjyM4b7CaF3aB2RbXs4h5r7zAyn8DPc4UGciTfkKEK0ZQ7si1GfAbFdQliYeCvr jwyrfMWuOozzvrfmx6BC855BDGehsiwPZbFcsIesFE3KKzw93FhX+O3pi06ECI3pMpEL kjtjEUp3NB41knw/aWsFRALXv3UGlTJjmxE9P6B3F//WInOC8ph4U+Ne4iJg+Z6K9azl n0pg== X-Gm-Message-State: AKS2vOxozEIqk3JFRV4x+cKKpKw4nE4kklA4+BgbX7gNdEkHpuGp2psz nEcsybltB0mZJ5ar9/HnOaAvitLzRmI+ X-Received: by 10.37.214.12 with SMTP id n12mr17627480ybg.122.1497834054150; Sun, 18 Jun 2017 18:00:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.144 with HTTP; Sun, 18 Jun 2017 18:00:13 -0700 (PDT) In-Reply-To: <61120.1497804752@eng-mail01.juniper.net> References: <61120.1497804752@eng-mail01.juniper.net> From: Eric Rescorla Date: Sun, 18 Jun 2017 18:00:13 -0700 Message-ID: To: "Mark D. Baushke" Cc: curdle Content-Type: multipart/alternative; boundary="001a114fcb70bb1d3c055245aa40" Archived-At: Subject: Re: [Curdle] AD Review: draft-ietf-curdle-ssh-modp-dh-sha2-05.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 01:00:57 -0000 --001a114fcb70bb1d3c055245aa40 Content-Type: text/plain; charset="UTF-8" On Sun, Jun 18, 2017 at 9:52 AM, Mark D. Baushke wrote: > Hi Eric, > > I will rework the rationle and the security considerations sections to > address your concerns. > > Question: Is it your contention that we should be able to use SHA256 for > all of the new MODP groups because the internal state of the hash will > always have more bits than the maximum amount of entropy in the > Diffie-Hellman shared secret? > Yeah, that's kind of where I was going with this. Note that TLS 1.3 allows SHA-256 with every kind of group, including P-384 and X448, so there is some precedent. That said, I agree that SHA-512 is fine for this and so if that's the WG's preference or there's some technical reason I'm not aware of, I don't see a problem with SHA-512. -Ekr > Thank you, > -- Mark > --001a114fcb70bb1d3c055245aa40 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Jun 18, 2017 at 9:52 AM, Mark D. Baushke <= mdb@juniper.net>= ; wrote:
Hi Eric,

I will rework the rationle and the security considerations sections to
address your concerns.

Question: Is it your contention that we should be able to use SHA256 for all of the new MODP groups because the internal state of the hash will
always have more bits than the maximum amount of entropy in the
Diffie-Hellman shared secret?

Yeah, tha= t's kind of where I was going with this. Note that TLS 1.3 allows
=
SHA-256 with every kind of group, including P-384 and X448, so there i= s
some precedent. That said, I agree that SHA-512 is fine for thi= s and so
if that's the WG's preference or there's som= e technical reason I'm not aware
of, I don't see a proble= m with SHA-512.

-Ekr


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thank you,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mark

--001a114fcb70bb1d3c055245aa40-- From nobody Sun Jun 18 22:53:08 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D26B128D40 for ; Sun, 18 Jun 2017 22:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=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 W36S4avCGTyQ for ; Sun, 18 Jun 2017 22:53:03 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0165F128D3E for ; Sun, 18 Jun 2017 22:53:02 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id u195so51665298wmd.1 for ; Sun, 18 Jun 2017 22:53:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=l8RR3ybLTA+7t17Ol2d7cJkMuxRw+d3gufMaMuCIhIM=; b=agPt1XtaaHCo+dm4EbikhrtiarJh3896otmvpN0/WXar66c0yIEmTu81AM9TPfeAiY G920N+hRJE1Y0FRHCjxadgM/gLmtP6LWay8da0IzWgWUWaY3OwktvPLh8qi6v7vkd2oM yMbmDiaim+lZlOEnjmaCBqHaWvUJgvPVxPGaO95rA5iCTBXGev5gkgrxIOsFdVYxk8B1 edO8fzKVGT5Ox6nXEqHqHqajEyMooV8fjrU/4Wno9Bxc4lhNJVXxKi0Ppg5AaVmE3U1F 7gAn0XxxzDbAK2zIz/loi7x49Ur5Jll0skdR7mg4BcjNe2OSG4LYx8Qv75B0hDE48BzG Ghcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=l8RR3ybLTA+7t17Ol2d7cJkMuxRw+d3gufMaMuCIhIM=; b=tJMM3XMIJQprUAjHJbpd6X7dJVLMVmifOcLiHZVG3usq1BXXSNe5n1wXymlZlo/Z6J gTkWXFjlebJW/bo8d2cPoKJ7biH+8woxij9afnm3OaNB0DdC3nsXWuFF/EqSME3qGzc9 3vU+TBEz6K1e8NEpl7CZ8YYn1k/pIjtDBnh3o1aWcqZrAZheOABUvtIBl+Ey8/OymSqm jMRzaYbSh9d3+FF5wyo2aU16jaTFy5cqCyMldu1TWt+7Pme1Bjxp0iZcY8KKpPAek9F2 sZr69nsYd5uQAee3/YzxFpS6XU10Y1OuIHt4ByDa3sJtRiN5r0bsNp3XcR0HDVDD49eY X+TQ== X-Gm-Message-State: AKS2vOxjliRUU6QMQvJGwOfln7E4OQhWDigEJxQMkJzAmL8hpFn/P0Z/ E6huC0Kof20GAdfS X-Received: by 10.28.94.144 with SMTP id s138mr603531wmb.32.1497851581269; Sun, 18 Jun 2017 22:53:01 -0700 (PDT) Received: from [192.168.1.79] (124.25.176.95.rev.sfr.net. [95.176.25.124]) by smtp.googlemail.com with ESMTPSA id g2sm8980012wrg.69.2017.06.18.22.53.00 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Jun 2017 22:53:00 -0700 (PDT) From: Anders Rundgren To: curdle@ietf.org Message-ID: Date: Mon, 19 Jun 2017 07:52:58 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Curdle] RFC: Java support for CURDLE X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 05:53:05 -0000 https://github.com/bcgit/bc-java/issues/193#issuecomment-309183825 Anders From nobody Mon Jun 19 08:28:34 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7869213152B for ; Mon, 19 Jun 2017 08:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_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=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 2fhpZBC99RM1 for ; Mon, 19 Jun 2017 08:28:30 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C86E5128C83 for ; Mon, 19 Jun 2017 08:28:30 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id e142so41855817ywa.1 for ; Mon, 19 Jun 2017 08:28:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zw3H0+JJjGdBMrK4080k5cdh6jsOQF78Jdjva5gvuLE=; b=mnXpmAr/68F73zyD/UuntmPVjpVR18qSKzIBGS5d4PybsbbjSJ4s3WPFV0cV+DVOrb eyoRl1X5deZaJEtOjwU4iAYqAMD0SHmMkHmGQ4iu382PEeqMiL+Wid6cQS90uC6yjEBI bWNHAKW5ci8ui5ZSHcPnXClU5B8bWbMR0ILjYEMmd5ex+oZ88KsgmcCfc9yC5k5xkYAP 2iKgnE0ERVaYkZsYicnvETIBwaOz9AhD9nxvKVaZeC6+l6UVyJep9sX0yPJkxSWnhk/M TbolLjd8Oz3RCyGPjShenh2Of6Mim4i7c19LSbb+nwIalts988+/NqCPc7KTNoit0qx5 jasA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zw3H0+JJjGdBMrK4080k5cdh6jsOQF78Jdjva5gvuLE=; b=oNSZ8VR8VlQvKnVeKzEypqnca/Ra20Zelr3bJMThVLdKJxLPLABrhi7bRI6VVJ4AU1 QnE0u19FrlSkoSPYDkO/IsLlRjDyVjhERhUnKUd2GLZQfgyhIlTbkHCqqvzK4GtS/bGB bYop2P2AZn0+2VIAn/SLaEWoAY7MjBUo/hy3DYyaDEb+9EpA3HU7/bnA9fhjCzkG5xNW rg26kBhlAF8qowi7Y8s1mCDAwvJDgCviIXjNf/H4Lt/pWMjXD7jPKSjOUBZ86hwdR1ed GQxamhoragm66weZnohhipNoRCJLYph8JRZ1/76LJULXYSQjQtyKMy6Dwtxzms3+ktMd m+aQ== X-Gm-Message-State: AKS2vOz2buUL9T6vhQoBJtGfId2xnKgh4B7nkuSoHC9K0yFuXEe8ecMW t2FS5JVpS/cSLBsXxEAuhaHUiHPKMcYt X-Received: by 10.13.230.212 with SMTP id p203mr18242659ywe.237.1497886109877; Mon, 19 Jun 2017 08:28:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.45.2 with HTTP; Mon, 19 Jun 2017 08:28:29 -0700 (PDT) In-Reply-To: References: From: denis bider Date: Mon, 19 Jun 2017 09:28:29 -0600 Message-ID: To: Eric Rescorla Cc: curdle Content-Type: multipart/alternative; boundary="94eb2c087df27e4d2d055251c9f6" Archived-At: Subject: Re: [Curdle] AD Review: draft-ietf-curdle-rsa-sha2-07.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 15:28:33 -0000 --94eb2c087df27e4d2d055251c9f6 Content-Type: text/plain; charset="UTF-8" > Either you are using PKCS#1 v1.5 or you are using PSS. > In the former case, there is no mask function and salt. Yikes, thanks. :) This was left over from an early version that specified PSS. This was before PKCS#1 v1.5 was requested. (The change took place before any implementation was released, so all deployed implementations use PKCS#1 v1.5.) > You say in the intro that RSA was defined as 1024 bit > keys. Are these keys of arbitrary length? Is there an > upper or lower limit? I believe this may refer to the following sentence: "In [RFC4253], SSH originally defined the public key algorithms "ssh-rsa" for server and client authentication using RSA with SHA-1, and "ssh-dss" using 1024-bit DSA and SHA-1." Here, 1024-bit refers to DSA. RFC 4253 imposes no limits on RSA key sizes. > > Implementations SHOULD apply PKCS#1 v1.5 padding to the expected > > hash, THEN compare the encoded bytes with the output of [...] > Why "SHOULD? Fair point. Changed as follows: "Verifiers MUST instead apply PKCS#1 v1.5 padding to the expected hash, then compare the encoded bytes with the output of the RSA operation." > This is an odd argument given that ECDSA is often also > implemented with random k. I agree, but that is the main argument that was given by multiple people as the main reason to remove DSA from the original draft (which covered DSA in addition). denis On Sat, Jun 17, 2017 at 1:30 PM, Eric Rescorla wrote: > TECHNICAL > S 3. > Signing and verifying using these algorithms is performed according to > the RSASSA-PKCS1-v1_5 scheme in [RFC8017] using SHA-2 [SHS] as hash; > MGF1 as mask function; and salt length equal to hash size. > > This seems incorrect. Either you are using PKCS#1 v1.5 or you are > using PSS. In the former case, there is no mask function and salt. > Appendix 5.3 suggests that you are not using PSS. In any case, > you need to fix the inconsistency. > > You say in the intro that RSA was defined as 1024 bit keys. Are > these keys of arbitrary length? Is there an upper or lower limit? > > > S 5.3. > Implementations SHOULD apply PKCS#1 v1.5 padding to the expected hash, > THEN compare the encoded bytes with the output of the RSA operation. > > Why "SHOULD? > > > S 6. > A draft version of this memo also defined an algorithm name for use of > 2048-bit and 3072-bit DSA keys with a 256-bit subgroup and SHA-2 256 > hashing. It is possible to implement DSA securely by generating "k" > deterministically as per [RFC6979]. However, a plurality of reviewers > were concerned that implementers would continue to use libraries that > generate "k" randomly. This is vulnerable to biased "k" generation, > and extremely vulnerable to "k" reuse. This document therefore > disrecommends DSA, in favor of RSA and elliptic curve cryptography. > > This is an odd argument given that ECDSA is often also implemented > with random k. Not that I am in favor of adding DSA here. > > -Ekr > > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > > --94eb2c087df27e4d2d055251c9f6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Either you are using PKCS#1 v1.5 or you are using PSS= .
> In the former case, there is no mask function and salt.

Yi= kes, thanks. :) This was left over from an early version that specified PSS= . This was before PKCS#1 v1.5 was requested. (The change took place before = any implementation was released, so all deployed implementations use PKCS#1= v1.5.)


> You say in the intro that RSA was defined as 1024 b= it
> keys. Are these keys of arbitrary length? Is there an
> up= per or lower limit?

I believe this may refer to the following senten= ce:

"In [RFC4253], SSH originally defined the public key algori= thms "ssh-rsa" for server and client authentication using RSA wit= h SHA-1, and "ssh-dss" using 1024-bit DSA and SHA-1."
Here, 1024-bit refers to DSA. RFC 4253 imposes no limits on RSA key sizes.=


> > Implementations SHOULD apply PKCS#1 v1.5 padding to t= he expected
> > hash, THEN compare the encoded bytes with the outp= ut of [...]

> Why "SHOULD?

Fair point. Changed as fol= lows:

"Verifiers MUST instead apply PKCS#1 v1.5 padding to the = expected hash, then compare the encoded bytes with the output of the RSA op= eration."


> This is an odd argument given that ECDSA is = often also
> implemented with random k.

I agree, but that is t= he main argument that was given by multiple people as the main reason to re= move DSA from the original draft (which covered DSA in addition).

denis


<= br>
On Sat, Jun 17, 2017 at 1:30 PM, Eric Rescorl= a <e= kr@rtfm.com> wrote:
TECHNICAL
S 3.
=C2=A0 Signing and verify= ing using these algorithms is performed according to
=C2=A0 the R= SASSA-PKCS1-v1_5 scheme in [RFC8017] using SHA-2 [SHS] as hash;
= =C2=A0 MGF1 as mask function; and salt length equal to hash size.

This seems incorrect. Either you are using PKCS#1 v1.5 or y= ou are
using PSS. In the former case, there is no mask function a= nd salt.
Appendix 5.3 suggests that you are not using PSS. In any= case,
you need to fix the inconsistency.

You say in the intro that RSA was defined as 1024 bit keys. Are
these keys of arbitrary length? Is there an upper or lower limit?


S 5.3.
=C2=A0 Implementations SHO= ULD apply PKCS#1 v1.5 padding to the expected hash,
=C2=A0 THEN c= ompare the encoded bytes with the output of the RSA operation.
Why "SHOULD?


S 6.=
=C2=A0 A draft version of this memo also defined an algorithm na= me for use of
=C2=A0 2048-bit and 3072-bit DSA keys with a 256-bi= t subgroup and SHA-2 256
=C2=A0 hashing. It is possible to implem= ent DSA securely by generating "k"
=C2=A0 deterministic= ally as per [RFC6979]. However, a plurality of reviewers
=C2=A0 w= ere concerned that implementers would continue to use libraries that
<= div>=C2=A0 generate "k" randomly. This is vulnerable to biased &q= uot;k" generation,
=C2=A0 and extremely vulnerable to "= k" reuse. This document therefore
=C2=A0 disrecommends DSA, = in favor of RSA and elliptic curve cryptography.

T= his is an odd argument given that ECDSA is often also implemented
with random k. Not that I am in favor of adding DSA here.

-Ekr



_______________________________________________
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle

--94eb2c087df27e4d2d055251c9f6-- From nobody Mon Jun 19 09:13:26 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0EBE131546 for ; Mon, 19 Jun 2017 09:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_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=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 doi8NYFrzu_F for ; Mon, 19 Jun 2017 09:13:20 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AC1F1314D0 for ; Mon, 19 Jun 2017 09:13:20 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id 63so42346952ywr.0 for ; Mon, 19 Jun 2017 09:13:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=W/BX5xDITJ/Oy3eaHeXbPeZZhu3wnk3tiqU3z+MZGNo=; b=tOkffzeWuCQ4GRvHAozTFYuh41s/VLe5AUCy4od0zhv9WapEGY8UkICx6B2/lIZ+yL hCbUn7HJxucmLmaesx2aKDKipKKFbbCmibkEm6yEo26xu9zG8W9+fzPYnVxDtn3aesVD zESzpFnIHefDAe5LBRz8bVztT/2Ym6M4rZ/RKNmvjpvFhnsx41bA3L5BXFW+c0T4YFqP 6zE9H3omPzjYsBbGWFqOq8QZ0alOnHwwPxfhA+luB1W2ux0e+5ZY73lALirC5n7Vo+Ho ceMv0IV4bemKnc4CoXts5oKDMW9Brp0nmBqmhNN4J7didkAeekishJB4fMpHgLcM7wZJ VEMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=W/BX5xDITJ/Oy3eaHeXbPeZZhu3wnk3tiqU3z+MZGNo=; b=SSonXKgOz00uqA9/I5qH/CfarvrYXlTzwbzroSh+XVuSis2U2xx44xOyGclT5yD/vN QMHVpyrdN6m++LKnnmw+iTypmAOVORUXNHegiUDcYLbTXqmK39r1XOOWXwdfFcRVms2s VgbpXQDE/uXq0Yvii9A9hLO7WkewpOZFLVLlYS94KJwz2kRGg+Vns70xi9h66giD5xbu XW7qTz2QRkwonJAgx8J45IAjjv9lvn7IyYu5uJJnI7Qhtwn9M1uwOT5VqZ6mCf+XQ7Oo a1S/izdKpQ/ZZBKSqHH5oSvgxRg1T2h5qmXqbI3dtWaDfJhy6Uv5tqpVg1XG+Kd2Yv2n ZYdQ== X-Gm-Message-State: AKS2vOzY3o2+OJXrhXrzN+agm95S4oUBB1+L57HUe8UuLbvky82ZM+pb 3Z7kJw965Egt9HKTG+Ajx8nOoBdIGA== X-Received: by 10.13.230.212 with SMTP id p203mr18396165ywe.237.1497888799383; Mon, 19 Jun 2017 09:13:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.45.2 with HTTP; Mon, 19 Jun 2017 09:13:19 -0700 (PDT) In-Reply-To: References: From: denis bider Date: Mon, 19 Jun 2017 10:13:19 -0600 Message-ID: To: Eric Rescorla Cc: curdle Content-Type: multipart/alternative; boundary="94eb2c087df2cce9c10552526945" Archived-At: Subject: Re: [Curdle] AD Review: draft-ietf-curdle-ssh-ext-info-00.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 16:13:24 -0000 --94eb2c087df2cce9c10552526945 Content-Type: text/plain; charset="UTF-8" > Can you explain what "neutral" means? Rephrased as: "The indicator names inserted by the client and server are different to ensure these names will not produce a match, and therefore not affect the algorithm chosen in key exchange algorithm negotiation." > Can a server send ext-info-s if it did not receive ext-info-c? Certainly. RFC 4253 makes no suggestions that either client or server should wait for the other with their KEXINIT packet. The server is free to send KEXINIT before receiving anything from the client. I have made this clearer by elaborating Section 2.2. > You need a citation for "elevated." I have added the following paragraph: "The terms "elevation" and "elevated" refer to an operating system mechanism where an administrator user's logon session is associated with two security contexts: one limited, and one with administrative rights. To "elevate" such a session is to activate the security context with full administrative rights. For more information about this mechanism on Windows, see also [WINADMIN] and [WINTOKEN]." The informative references are: WINADMIN: https://blogs.msdn.microsoft.com/winsdk/2013/03/22/how-to-launch-a-process-as-a-full-administrator-when-uac-is-enabled/ WINTOKEN: https://msdn.microsoft.com/en-us/library/windows/desktop/bb530718.aspx denis On Sat, Jun 17, 2017 at 1:37 PM, Eric Rescorla wrote: > > S 2.1. > The indicator names inserted by the client and server are different to > ensure that these names will not produce a match, and will be neutral > with respect to key exchange algorithm negotiation. > > Can you explain what "neutral" means? > > > S 2.2. > If a client or server offers "ext-info-c" or "ext-info-s" > respectively, it must be prepared to accept a SSH_MSG_EXT_INFO message > from the peer. > > Can a server send ext-info-s if it did not receive ext-info-c? > > > S 3.4. > A client sends "y" to indicate its preference that the session should > be elevated; "n" to not be elevated; and "d" for the server to use its > default behavior. If a client does not send the "elevation" extension, > the server SHOULD act as if "d" was sent. > > You need a citation for "elevated." > > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > > --94eb2c087df2cce9c10552526945 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0Can you explain= what "neutral" means?

Rephrased as:

"The indicator names inserted by the client = and server are different to=C2=A0en= sure these names will not produce a match, and therefore not affect=C2=A0the algorithm chosen in key exchange = algorithm negotiation."


>=C2=A0Can a server send ext-info-s if it did not receive ext-info-c= ?

C= ertainly. RFC 4253 makes no suggestions that either client or server should= wait for the other with their KEXINIT packet. The server is free to send K= EXINIT before receiving anything from the client.

= I have made this clearer by elaborating Section 2.2.


>=C2=A0You need a cit= ation for "elevated."

I have added = the following paragraph:
=
"The terms &quo= t;elevation" and "elevated" refer to an operating system=C2= =A0mechanism where an administrator= user's logon session is associated=C2=A0with two security contexts: one limited, and one with administrat= ive=C2=A0rights. To "elevate&q= uot; such a session is to activate the security=C2=A0context with full administrative rights. For more informa= tion about=C2=A0this mechanism on W= indows, see also [WINADMIN] and [WINTOKEN]."

The informative references are:

WINADMIN:

WINTOKEN:


deni= s



On Sat, J= un 17, 2017 at 1:37 PM, Eric Rescorla <ekr@rtfm.com> wrote:

S 2.1.
=C2=A0 The indicator names inserted by the client and server are di= fferent to
=C2=A0 ensure that these names will not produce a matc= h, and will be neutral
=C2=A0 with respect to key exchange algori= thm negotiation.

Can you explain what "neutra= l" means?


S 2.2.
If = a client or server offers "ext-info-c" or "ext-info-s"<= /div>
=C2=A0 respectively, it must be prepared to accept a SSH_MSG_EXT_= INFO message
=C2=A0 from the peer.

Can a= server send ext-info-s if it did not receive ext-info-c?


S 3.4.
=C2=A0 A client sends "y"= to indicate its preference that the session should
=C2=A0 be ele= vated; "n" to not be elevated; and "d" for the server t= o use its
=C2=A0 default behavior. If a client does not send the = "elevation" extension,
=C2=A0 the server SHOULD act as = if "d" was sent.

You need a citation for= "elevated."



_______________________________________________
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle

--94eb2c087df2cce9c10552526945-- From nobody Mon Jun 19 09:17:03 2017 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 535BF131564; Mon, 19 Jun 2017 09:17: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: curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149788902229.10678.4187811321952890843@ietfa.amsl.com> Date: Mon, 19 Jun 2017 09:17:02 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-ssh-ext-info-10.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 16:17:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : Extension Negotiation in Secure Shell (SSH) Author : Denis Bider Filename : draft-ietf-curdle-ssh-ext-info-10.txt Pages : 11 Date : 2017-06-19 Abstract: This memo updates RFC 4252, RFC 4253, and RFC 4254 to define a mechanism for SSH clients and servers to exchange information about supported protocol extensions confidentially after SSH key exchange. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-ext-info/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-ssh-ext-info-10 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-ext-info-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-ssh-ext-info-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 19 09:17:17 2017 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AFEAF131556; Mon, 19 Jun 2017 09:17:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149788903168.10722.18125939945481450145@ietfa.amsl.com> Date: Mon, 19 Jun 2017 09:17:11 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-rsa-sha2-09.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 16:17:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : Use of RSA Keys with SHA-2 256 and 512 in Secure Shell (SSH) Author : Denis Bider Filename : draft-ietf-curdle-rsa-sha2-09.txt Pages : 8 Date : 2017-06-19 Abstract: This memo updates RFC 4252 and RFC 4253 to define new public key algorithms for use of RSA keys with SHA-2 hashing for server and client authentication in SSH connections. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-rsa-sha2/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-rsa-sha2-09 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-rsa-sha2-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-rsa-sha2-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 Mon Jun 19 09:29:41 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC27131590 for ; Mon, 19 Jun 2017 09:29:39 -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 eCunvxoMF6RK for ; Mon, 19 Jun 2017 09:29:36 -0700 (PDT) Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBD58131585 for ; Mon, 19 Jun 2017 09:29:34 -0700 (PDT) Received: by mail-yb0-x235.google.com with SMTP id f192so29633237yba.2 for ; Mon, 19 Jun 2017 09:29:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LRlep3JkC6E2iuPrEkMO9sU9yLeM5HYZnr6lf+N/Kfk=; b=hPJrCjUUzFbgu1bgCqVYIa1J3r0rVTrYwvWhH9lgSex2k2F55lRNKlx9j3ZFEPc3Fr ycAqjuJjGWLLPZolPC3/iLSxgkLnZZKeZrsxdHYRt9HIeYsrJIq53R/OcDJ80p7D/Q9B FWVXxkT3Y7juNwSxTQHUeXPl1Gc14Z91O/XVTHqY0+HzGb2rjVXMvkU8zKJx5cmYvKSs b615rC3xhuTmPt0C6qrwTKNoDv8yPObYVgsdOpt2BwZ1DbsXiY28/Q3QyUM5fzIqKHuE y6+dnEgtoaErGet4VJM1ieSMZGEvXlS9/tFguhtIDS0kHuJy8pPcekO3pS/Yr2Uu5A2H Nsng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LRlep3JkC6E2iuPrEkMO9sU9yLeM5HYZnr6lf+N/Kfk=; b=MiSSqTaagpjeHBpc7N/Jf4Bpv8rmyObo4XYbJJFzkPaVPaDlPehL6vg1+2C+5vhE8f ijHjUTPXH7qNL1sJ/gmEK3wHjstj8iir/ny35G9DhxwLNhfN6edqL5ceVyvwSqETBONV 69t/Tlbi88dDxBWnm99jWAhEp6y52k5HKiR779ApTUI1+MtOm07NpBKyrPUxQa32U0E6 6Z8I+WZ2yYUhsywJVaz/zfuUaVkIVahHgGMnbGLO+Ct0Fj9Uv0klQqvohN2qsu7r50Nm KPPIi56CnHtn80n4GmP8Ankur0GglCCtF+9/6P2llkw+k9DNKw/Ytsmio9usz8pyLMAj TxtA== X-Gm-Message-State: AKS2vOxPZjZF1lv/QrmB5oaS4g13ssj13k3S4VCj9bJzV9cDoL+h8r2z XGyrNOUfwWDQYQJtqntD3zGYwmDrrA== X-Received: by 10.37.125.133 with SMTP id y127mr19824310ybc.238.1497889774082; Mon, 19 Jun 2017 09:29:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.45.2 with HTTP; Mon, 19 Jun 2017 09:29:33 -0700 (PDT) In-Reply-To: References: <61120.1497804752@eng-mail01.juniper.net> From: denis bider Date: Mon, 19 Jun 2017 10:29:33 -0600 Message-ID: To: Eric Rescorla Cc: "Mark D. Baushke" , curdle Content-Type: multipart/alternative; boundary="001a114dc596e5baef055252a3d8" Archived-At: Subject: Re: [Curdle] AD Review: draft-ietf-curdle-ssh-modp-dh-sha2-05.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 16:29:39 -0000 --001a114dc596e5baef055252a3d8 Content-Type: text/plain; charset="UTF-8" I have a strong preference to keep the groups and hashes as they are, and only clarify the rationale, if necessary. I'm not sure that it is necessary to clarify the rationale, because it is not meant to be an appeal to cryptographic theory, it's an appeal to market authority. The argument being made here is not that SHA-256 is insufficient, it's that there's a substantial market which requires SHA-384 or SHA-512. On Sun, Jun 18, 2017 at 7:00 PM, Eric Rescorla wrote: > > > On Sun, Jun 18, 2017 at 9:52 AM, Mark D. Baushke wrote: > >> Hi Eric, >> >> I will rework the rationle and the security considerations sections to >> address your concerns. >> >> Question: Is it your contention that we should be able to use SHA256 for >> all of the new MODP groups because the internal state of the hash will >> always have more bits than the maximum amount of entropy in the >> Diffie-Hellman shared secret? >> > > Yeah, that's kind of where I was going with this. Note that TLS 1.3 allows > SHA-256 with every kind of group, including P-384 and X448, so there is > some precedent. That said, I agree that SHA-512 is fine for this and so > if that's the WG's preference or there's some technical reason I'm not > aware > of, I don't see a problem with SHA-512. > > -Ekr > > >> Thank you, >> -- Mark >> > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > > --001a114dc596e5baef055252a3d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have a strong preference to keep the groups and hashes a= s they are, and only clarify the rationale, if necessary.

I'm not sure that it is necessary to clarify the rationale, because i= t is not meant to be an appeal to cryptographic theory, it's an appeal = to market authority. The argument being made here is not that SHA-256 is in= sufficient, it's that there's a substantial market which requires S= HA-384 or SHA-512.

On Sun, Jun 18, 2017 at 7:00 PM, Eric Rescorla <ekr@rtfm.com&g= t; wrote:


On = Sun, Jun 18, 2017 at 9:52 AM, Mark D. Baushke <mdb@juniper.net> wrote:
Hi Eric,

I will rework the rationle and the security considerations sections to
address your concerns.

Question: Is it your contention that we should be able to use SHA256 for all of the new MODP groups because the internal state of the hash will
always have more bits than the maximum amount of entropy in the
Diffie-Hellman shared secret?

Ye= ah, that's kind of where I was going with this. Note that TLS 1.3 allow= s
SHA-256 with every kind of group, including P-384 and X448, so = there is
some precedent. That said, I agree that SHA-512 is fine = for this and so
if that's the WG's preference or there= 9;s some technical reason I'm not aware
of, I don't see a= problem with SHA-512.

-Ekr


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thank you,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mark


_______________________________________________
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle

--001a114dc596e5baef055252a3d8-- From nobody Mon Jun 19 10:11:19 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6FC129490 for ; Mon, 19 Jun 2017 10:11:17 -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=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 8RbgpyGWRe9Q for ; Mon, 19 Jun 2017 10:11:15 -0700 (PDT) Received: from mail-yb0-x22c.google.com (mail-yb0-x22c.google.com [IPv6:2607:f8b0:4002:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7470512948F for ; Mon, 19 Jun 2017 10:11:13 -0700 (PDT) Received: by mail-yb0-x22c.google.com with SMTP id e201so26066207ybb.1 for ; Mon, 19 Jun 2017 10:11:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Dt6uia/EtwzEBSSdkeAEmLuHHgyfQI/US6H/HNe4P+Y=; b=WeQsKe2bUXWAQBqxYk/eEvfHEThfHHbgqFxi72TDFkUHP2GvfxY7EDr6hGcOp4Gac4 NL1HbT2SSgUNU/NUBrGU7O7KUCANL2jQFvPzkIsBn04QdB1DA3iHmMZ4eOxfx44aAU3w aZT7zxYcioe7cmh7e2M8B9V7EagJNR35F+VGBdBIqlD8P1N879m1QFCrbZMpghx0M8uG /+W5f6f39A/yZ3j3WCyolzIshyin9mOjgh5XJ5PY46ObEiDpxsEsDeCi5HlbU6dAsL3t eo0/Ti2tmkFBgHRbvGhqKTVPOti6QS9oZh7rH13urRn0s+DVKxaUI4CfJf2DbF3d6oui RuMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Dt6uia/EtwzEBSSdkeAEmLuHHgyfQI/US6H/HNe4P+Y=; b=rD1mz1eBq442LJyaBxt/fWf+jNue9YM8/DyXjTdGbfrBDHQ8v2u2eTEGOfRmNAS6UH 6r4249qtcllbifUOGBvD/99Vue/n8zeCvQFHqlAmFeHrj3Hf6olfNcEvQnHNfyQ4dpMP zEf2h4m6dvl6guQ5/uyM+4PB4PPtIUqze75GNn7VbKPRUUK09gvQceGeNfetipkbmCvl x1YUy4/KpOH8ZTqOs+0NGHvF36kYLW/HILdyRv+1KQVy3tIlBmyrNivXp5Gc3qlm2LhK QEL4k+znyN55aatmgYCHFDS413KR3xwH/JOC3KMk8EYGXS9je5kcFnxWzSxmbhTsFetd cD9A== X-Gm-Message-State: AKS2vOyvzv0pVBJeOhGPzZhOk+1oknAxLbpJp2cJ2++GyfeXwQ9974WH Nf3W7bh7Ey7obCMJtUe30h21MmEgQP49 X-Received: by 10.37.83.65 with SMTP id h62mr18832573ybb.92.1497892272642; Mon, 19 Jun 2017 10:11:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.144 with HTTP; Mon, 19 Jun 2017 10:10:31 -0700 (PDT) In-Reply-To: References: <61120.1497804752@eng-mail01.juniper.net> From: Eric Rescorla Date: Mon, 19 Jun 2017 10:10:31 -0700 Message-ID: To: denis bider Cc: "Mark D. Baushke" , curdle Content-Type: multipart/alternative; boundary="001a113e6450d2d4bf05525338c6" Archived-At: Subject: Re: [Curdle] AD Review: draft-ietf-curdle-ssh-modp-dh-sha2-05.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 17:11:17 -0000 --001a113e6450d2d4bf05525338c6 Content-Type: text/plain; charset="UTF-8" Hmm... I can't get a copy of that sheet, but I'd be interested to see if it it really says that you can't use SHA-256-based KDFs. On Mon, Jun 19, 2017 at 9:29 AM, denis bider wrote: > I have a strong preference to keep the groups and hashes as they are, and > only clarify the rationale, if necessary. > > I'm not sure that it is necessary to clarify the rationale, because it is > not meant to be an appeal to cryptographic theory, it's an appeal to market > authority. The argument being made here is not that SHA-256 is > insufficient, it's that there's a substantial market which requires SHA-384 > or SHA-512. > > On Sun, Jun 18, 2017 at 7:00 PM, Eric Rescorla wrote: > >> >> >> On Sun, Jun 18, 2017 at 9:52 AM, Mark D. Baushke wrote: >> >>> Hi Eric, >>> >>> I will rework the rationle and the security considerations sections to >>> address your concerns. >>> >>> Question: Is it your contention that we should be able to use SHA256 for >>> all of the new MODP groups because the internal state of the hash will >>> always have more bits than the maximum amount of entropy in the >>> Diffie-Hellman shared secret? >>> >> >> Yeah, that's kind of where I was going with this. Note that TLS 1.3 allows >> SHA-256 with every kind of group, including P-384 and X448, so there is >> some precedent. That said, I agree that SHA-512 is fine for this and so >> if that's the WG's preference or there's some technical reason I'm not >> aware >> of, I don't see a problem with SHA-512. >> >> -Ekr >> >> >>> Thank you, >>> -- Mark >>> >> >> >> _______________________________________________ >> Curdle mailing list >> Curdle@ietf.org >> https://www.ietf.org/mailman/listinfo/curdle >> >> > --001a113e6450d2d4bf05525338c6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hmm... I can't get a copy of that sheet, but I'd b= e interested to see if it it really says that you can't use SHA-256-bas= ed KDFs.

On Mo= n, Jun 19, 2017 at 9:29 AM, denis bider <denisbider.ietf@gmail.com= > wrote:
I= have a strong preference to keep the groups and hashes as they are, and on= ly clarify the rationale, if necessary.

I'm not sure= that it is necessary to clarify the rationale, because it is not meant to = be an appeal to cryptographic theory, it's an appeal to market authorit= y. The argument being made here is not that SHA-256 is insufficient, it'= ;s that there's a substantial market which requires SHA-384 or SHA-512.=

=
On Sun, Jun 18, 2017 at 7:00 PM, Eric Rescorla <ekr@rtfm.com= > wrote:
<= div class=3D"h5">


On Sun, Jun 18, 2017 at 9:52 AM, Mark D. Baushke= <mdb@juniper.net> wrote:
Hi= Eric,

I will rework the rationle and the security considerations sections to
address your concerns.

Question: Is it your contention that we should be able to use SHA256 for all of the new MODP groups because the internal state of the hash will
always have more bits than the maximum amount of entropy in the
Diffie-Hellman shared secret?

Ye= ah, that's kind of where I was going with this. Note that TLS 1.3 allow= s
SHA-256 with every kind of group, including P-384 and X448, so = there is
some precedent. That said, I agree that SHA-512 is fine = for this and so
if that's the WG's preference or there= 9;s some technical reason I'm not aware
of, I don't see a= problem with SHA-512.

-Ekr


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thank you,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mark


_______________________________________________
Curdle mailing list
Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle


--001a113e6450d2d4bf05525338c6-- From nobody Mon Jun 19 10:12:54 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03FEA1315F7 for ; Mon, 19 Jun 2017 10:12:46 -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=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 yCdGXtJ8WPZp for ; Mon, 19 Jun 2017 10:12:43 -0700 (PDT) Received: from mail-yb0-x234.google.com (mail-yb0-x234.google.com [IPv6:2607:f8b0:4002:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1D0D1315EA for ; Mon, 19 Jun 2017 10:12:38 -0700 (PDT) Received: by mail-yb0-x234.google.com with SMTP id t7so29898881yba.3 for ; Mon, 19 Jun 2017 10:12:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kP8TMs3gMLgyWi3wiNOGFtOcNYObHSu/CXwr3FVTkl0=; b=MeZgujxexHjz6EfEfrGb4dkE2DEqb+xfwWN62bN3XausfmUVTWaK97lPjQ+cjO+52c tQUuxHyOqtj3mYlevIKanR4BHQ+BNymyjbooEx3A0CIlb+wwSpX0GqOSEYH2iWHJUi0X yKniclzgHbyRlrBAfQJCybRRv1xuU+271Eg66tckrjPiz9Ige0y0MgjQJ2hUnt8rdP3N 1lbdWbKUfBMQNibaZYbKpSQ8l700GbzPQKLXJVcr4bRqKFg1B1OdleH0knveJNJEQ8QD lJMKFB+bdhN6veXsf2fO4EMjLUxa3JlUbR56hVMpBH3KaPXh6Bdq7CEj8P+5UT8gM3r5 38rQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kP8TMs3gMLgyWi3wiNOGFtOcNYObHSu/CXwr3FVTkl0=; b=i7Drs4Dz0KiQYWOFvKSdp/eokAJQnmdZtgnB50LFWF/4AiliRU/9zqpudm4CJ2/ooo At/MA6feGk/0eAWK3qphK9JOq4CuwwxxTFcQp7E3kqH4/WL74UYkCd7Uj5aaEYCiuZ2P XO3ZtUZVC0bEz5OlvkZfCZT5ieehEUdh3ddGLndpeXMNHTwYV41IUEEum6ubzLLySoBQ 49w27hEKhnp2Ap/WPQ96YFeG6p3vU+eWPUHi0qIKV8l74rER+aEotMTrfswzkUeDlQmc bFdtUK/sfQ/mMOJAsm/Vqs9KwcRiDiVTGB4BTVMFsTxC2eLFgsd9kmHvVwWeNEUPr/wl jz/A== X-Gm-Message-State: AKS2vOw8mFtoEj9Bw6kFe5HYIdiIYqslVrtKSytXOYKN+gCrGy/7ctnu Zz2gfBZeAL37NXFcPyzcKg1RfBA1Tw85Sks= X-Received: by 10.37.214.12 with SMTP id n12mr20190709ybg.122.1497892357615; Mon, 19 Jun 2017 10:12:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.144 with HTTP; Mon, 19 Jun 2017 10:11:57 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Mon, 19 Jun 2017 10:11:57 -0700 Message-ID: To: denis bider Cc: curdle Content-Type: multipart/alternative; boundary="001a114fcb70e3b3460552533dda" Archived-At: Subject: Re: [Curdle] AD Review: draft-ietf-curdle-rsa-sha2-07.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 17:12:46 -0000 --001a114fcb70e3b3460552533dda Content-Type: text/plain; charset="UTF-8" On Mon, Jun 19, 2017 at 8:28 AM, denis bider wrote: > > Either you are using PKCS#1 v1.5 or you are using PSS. > > In the former case, there is no mask function and salt. > > Yikes, thanks. :) This was left over from an early version that specified > PSS. This was before PKCS#1 v1.5 was requested. (The change took place > before any implementation was released, so all deployed implementations use > PKCS#1 v1.5.) > > > > You say in the intro that RSA was defined as 1024 bit > > keys. Are these keys of arbitrary length? Is there an > > upper or lower limit? > > I believe this may refer to the following sentence: > > "In [RFC4253], SSH originally defined the public key algorithms "ssh-rsa" > for server and client authentication using RSA with SHA-1, and "ssh-dss" > using 1024-bit DSA and SHA-1." > > Here, 1024-bit refers to DSA. RFC 4253 imposes no limits on RSA key sizes. > > > > > Implementations SHOULD apply PKCS#1 v1.5 padding to the expected > > > hash, THEN compare the encoded bytes with the output of [...] > > > Why "SHOULD? > > Fair point. Changed as follows: > > "Verifiers MUST instead apply PKCS#1 v1.5 padding to the expected hash, > then compare the encoded bytes with the output of the RSA operation." > > > > This is an odd argument given that ECDSA is often also > > implemented with random k. > > I agree, but that is the main argument that was given by multiple people > as the main reason to remove DSA from the original draft (which covered DSA > in addition). > How about just "DSA is on its way out" :) > > > denis > > > > On Sat, Jun 17, 2017 at 1:30 PM, Eric Rescorla wrote: > >> TECHNICAL >> S 3. >> Signing and verifying using these algorithms is performed according to >> the RSASSA-PKCS1-v1_5 scheme in [RFC8017] using SHA-2 [SHS] as hash; >> MGF1 as mask function; and salt length equal to hash size. >> >> This seems incorrect. Either you are using PKCS#1 v1.5 or you are >> using PSS. In the former case, there is no mask function and salt. >> Appendix 5.3 suggests that you are not using PSS. In any case, >> you need to fix the inconsistency. >> >> You say in the intro that RSA was defined as 1024 bit keys. Are >> these keys of arbitrary length? Is there an upper or lower limit? >> >> >> S 5.3. >> Implementations SHOULD apply PKCS#1 v1.5 padding to the expected hash, >> THEN compare the encoded bytes with the output of the RSA operation. >> >> Why "SHOULD? >> >> >> S 6. >> A draft version of this memo also defined an algorithm name for use of >> 2048-bit and 3072-bit DSA keys with a 256-bit subgroup and SHA-2 256 >> hashing. It is possible to implement DSA securely by generating "k" >> deterministically as per [RFC6979]. However, a plurality of reviewers >> were concerned that implementers would continue to use libraries that >> generate "k" randomly. This is vulnerable to biased "k" generation, >> and extremely vulnerable to "k" reuse. This document therefore >> disrecommends DSA, in favor of RSA and elliptic curve cryptography. >> >> This is an odd argument given that ECDSA is often also implemented >> with random k. Not that I am in favor of adding DSA here. >> >> -Ekr >> >> >> >> _______________________________________________ >> Curdle mailing list >> Curdle@ietf.org >> https://www.ietf.org/mailman/listinfo/curdle >> >> > --001a114fcb70e3b3460552533dda Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jun 19, 2017 at 8:28 AM, denis bider <denisbider.ietf@= gmail.com> wrote:
> Either you are using PKCS#1 v1.5 or you are = using PSS.
> In the former case, there is no mask function and salt.<= br>
Yikes, thanks. :) This was left over from an early version th= at specified PSS. This was before PKCS#1 v1.5 was requested. (The change to= ok place before any implementation was released, so all deployed implementa= tions use PKCS#1 v1.5.)


> You say in the int= ro that RSA was defined as 1024 bit
> keys. Are these keys of arbitra= ry length? Is there an
> upper or lower limit?

I believ= e this may refer to the following sentence:

"In [RFC4253], SSH = originally defined the public key algorithms "ssh-rsa" for server= and client authentication using RSA with SHA-1, and "ssh-dss" us= ing 1024-bit DSA and SHA-1."

Here, 1024-bit refers to DSA. RFC = 4253 imposes no limits on RSA key sizes.


> &= gt; Implementations SHOULD apply PKCS#1 v1.5 padding to the expected
> > hash, THEN compare the encoded bytes with the output of [...]=

> Why "SHOULD?

Fair point. Changed as follows:
"Verifiers MUST instead apply PKCS#1 v1.5 padding to the expected ha= sh, then compare the encoded bytes with the output of the RSA operation.&qu= ot;


> This is an odd argument given that ECD= SA is often also
> implemented with random k.

I agree, = but that is the main argument that was given by multiple people as the main= reason to remove DSA from the original draft (which covered DSA in additio= n).

How about just "DSA is o= n its way out" :)
=C2=A0


denis



On Sat, Jun 17, 2017 at 1:30 PM, Eric Rescorla <ekr@rtfm.com> w= rote:
=
TECHNICAL
S 3.
=C2=A0 Signing and= verifying using these algorithms is performed according to
=C2= =A0 the RSASSA-PKCS1-v1_5 scheme in [RFC8017] using SHA-2 [SHS] as hash;
=C2=A0 MGF1 as mask function; and salt length equal to hash size.

This seems incorrect. Either you are using PKCS#1 v= 1.5 or you are
using PSS. In the former case, there is no mask fu= nction and salt.
Appendix 5.3 suggests that you are not using PSS= . In any case,
you need to fix the inconsistency.

<= /div>
You say in the intro that RSA was defined as 1024 bit keys. Are
these keys of arbitrary length? Is there an upper or lower limit?<= /div>


S 5.3.
=C2=A0 Implementat= ions SHOULD apply PKCS#1 v1.5 padding to the expected hash,
=C2= =A0 THEN compare the encoded bytes with the output of the RSA operation.

Why "SHOULD?


S 6.
=C2=A0 A draft version of this memo also defined an al= gorithm name for use of
=C2=A0 2048-bit and 3072-bit DSA keys wit= h a 256-bit subgroup and SHA-2 256
=C2=A0 hashing. It is possible= to implement DSA securely by generating "k"
=C2=A0 det= erministically as per [RFC6979]. However, a plurality of reviewers
=C2=A0 were concerned that implementers would continue to use libraries t= hat
=C2=A0 generate "k" randomly. This is vulnerable to= biased "k" generation,
=C2=A0 and extremely vulnerable= to "k" reuse. This document therefore
=C2=A0 disrecomm= ends DSA, in favor of RSA and elliptic curve cryptography.

This is an odd argument given that ECDSA is often also implemented=
with random k. Not that I am in favor of adding DSA here.
<= div>
-Ekr



_______________________________________________
Curdle mailing list
Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle


--001a114fcb70e3b3460552533dda-- From nobody Mon Jun 19 10:13:25 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAA6C131625 for ; Mon, 19 Jun 2017 10:13:22 -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=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 M0wyQ7taDjYI for ; Mon, 19 Jun 2017 10:13:20 -0700 (PDT) Received: from mail-yb0-x22d.google.com (mail-yb0-x22d.google.com [IPv6:2607:f8b0:4002:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCE7D131614 for ; Mon, 19 Jun 2017 10:13:01 -0700 (PDT) Received: by mail-yb0-x22d.google.com with SMTP id 84so30000869ybe.0 for ; Mon, 19 Jun 2017 10:13:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gFYP/w4GM7HGeQMFhKz1baN5cvKcNnVGKxmEoDrnnco=; b=uXNrfcJGnsAmQp9evF+J7BlyjUpZVptQp8TBvfY9eK5ceDtgmUGJLFkSwfp2MWtrsw dDpswMcViSrBgIT3FceQU0K36vSb2kK2cNpGKYP4b+2o1E20ZAw2vX019mkVF+h2zrWe GlEQz/8EKt0Xu4ZDqcFLlOW85wAmWoqhX2QXGjLMmjpqKqDSPTBF3/23HdT565BEaoo7 4Hv/ZWvlZ/5NkIBAEcAxtlLg4VA9JHV57KJhGUaJmRahaWty0dF1PDjas1h8XVjjxqI5 OBLVgVb29U6IdxQAZenuVtmXVFVzjq8uweXPo3JLAS3+6ZO21xCIVm6wNyHyR4zf6/BI uClg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gFYP/w4GM7HGeQMFhKz1baN5cvKcNnVGKxmEoDrnnco=; b=Lmcp1w2O5GESuC0e0Z6ibmsj5U/l6lUE6/4JwX9YGGB3hlJ5+fDOu+OL8CTSr/EgwA dD1DYL3Bwjz4JfksBsGhXGKJyQZFBgXIA2SkU04qvhBBHKTaF2mdDOy9ipi4kdWhSs35 2JkU0AzHy2QMl2WRxlasJWL08tiNYPo1K+6kibmkjwMhayTKTM1A2wQTiPguitT60nWP JaqfOx3FUOnBJtUgeXWkQKr/RuDZZf4DUUbQhTuHVk+X8LGdG5pGTuU0yFOSknoqXab5 vLEEeS3WhNewfS/W2v58pDRApR45zvtkAAUxkfedjLf9sNcG4wzpcml9pY4Atp9vnJ8o dmcg== X-Gm-Message-State: AKS2vOxe3i0bqguAZGHUkSi+V2o9YjBCYdDv0/F6xKlMmqaSvaCTpO+i RqUrMg1npaKt5beM7vjyB2HmRMFSe0F6 X-Received: by 10.37.162.104 with SMTP id b95mr19541919ybi.29.1497892380879; Mon, 19 Jun 2017 10:13:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.144 with HTTP; Mon, 19 Jun 2017 10:12:20 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Mon, 19 Jun 2017 10:12:20 -0700 Message-ID: To: denis bider Cc: curdle Content-Type: multipart/alternative; boundary="94eb2c19fcf847070e0552533f8d" Archived-At: Subject: Re: [Curdle] AD Review: draft-ietf-curdle-ssh-ext-info-00.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 17:13:23 -0000 --94eb2c19fcf847070e0552533f8d Content-Type: text/plain; charset="UTF-8" Thanks. This all looks fine. On Mon, Jun 19, 2017 at 9:13 AM, denis bider wrote: > > Can you explain what "neutral" means? > > Rephrased as: > > "The indicator names inserted by the client and server are different to ensure > these names will not produce a match, and therefore not affect the > algorithm chosen in key exchange algorithm negotiation." > > > > Can a server send ext-info-s if it did not receive ext-info-c? > > Certainly. RFC 4253 makes no suggestions that either client or server > should wait for the other with their KEXINIT packet. The server is free to > send KEXINIT before receiving anything from the client. > > I have made this clearer by elaborating Section 2.2. > > > > You need a citation for "elevated." > > I have added the following paragraph: > > "The terms "elevation" and "elevated" refer to an operating system mechanism > where an administrator user's logon session is associated with two > security contexts: one limited, and one with administrative rights. To > "elevate" such a session is to activate the security context with full > administrative rights. For more information about this mechanism on > Windows, see also [WINADMIN] and [WINTOKEN]." > > The informative references are: > > WINADMIN: > https://blogs.msdn.microsoft.com/winsdk/2013/03/22/how-to- > launch-a-process-as-a-full-administrator-when-uac-is-enabled/ > > WINTOKEN: > https://msdn.microsoft.com/en-us/library/windows/desktop/bb530718.aspx > > > denis > > > > On Sat, Jun 17, 2017 at 1:37 PM, Eric Rescorla wrote: > >> >> S 2.1. >> The indicator names inserted by the client and server are different to >> ensure that these names will not produce a match, and will be neutral >> with respect to key exchange algorithm negotiation. >> >> Can you explain what "neutral" means? >> >> >> S 2.2. >> If a client or server offers "ext-info-c" or "ext-info-s" >> respectively, it must be prepared to accept a SSH_MSG_EXT_INFO message >> from the peer. >> >> Can a server send ext-info-s if it did not receive ext-info-c? >> >> >> S 3.4. >> A client sends "y" to indicate its preference that the session should >> be elevated; "n" to not be elevated; and "d" for the server to use its >> default behavior. If a client does not send the "elevation" extension, >> the server SHOULD act as if "d" was sent. >> >> You need a citation for "elevated." >> >> >> >> _______________________________________________ >> Curdle mailing list >> Curdle@ietf.org >> https://www.ietf.org/mailman/listinfo/curdle >> >> > --94eb2c19fcf847070e0552533f8d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks. This all looks fine.

On Mon, Jun 19, 2017 at 9:13 AM, denis bi= der <denisbider.ietf@gmail.com> wrote:
>=C2=A0Can you explain what "neutral" means?

Rephrased as:

&quo= t;The indicator names inserted by the client and server are different to=C2= =A0ensure these names will not prod= uce a match, and therefore not affect=C2=A0the algorithm chosen in key exchange algorithm negotiation."


>=C2=A0Can a server send ext-info-s if it did not receive ext-info-c?

Certain= ly. RFC 4253 makes no suggestions that either client or server should wait = for the other with their KEXINIT packet. The server is free to send KEXINIT= before receiving anything from the client.

I have= made this clearer by elaborating Section 2.2.
<= br>

>=C2=A0You= need a citation for "elevated."

I have added the following paragraph:

&q= uot;The terms "elevation" and "elevated" refer to an op= erating system=C2=A0mechanism where= an administrator user's logon session is associated=C2=A0with two security contexts: one limited, and one= with administrative=C2=A0rights. T= o "elevate" such a session is to activate the security=C2=A0context with full administrative rights.= For more information about=C2=A0th= is mechanism on Windows, see also [WINADMIN] and [WINTOKEN]."

The informative references are:

=
On Sat, Jun 17, 2017 at 1:37 PM, Eric Rescorla <ekr@rtfm= .com> wrote:

S 2.1.
= =C2=A0 The indicator names inserted by the client and server are different = to
=C2=A0 ensure that these names will not produce a match, and w= ill be neutral
=C2=A0 with respect to key exchange algorithm nego= tiation.

Can you explain what "neutral" = means?


S 2.2.
If a client= or server offers "ext-info-c" or "ext-info-s"
=C2=A0 respectively, it must be prepared to accept a SSH_MSG_EXT_INFO mes= sage
=C2=A0 from the peer.

Can a server = send ext-info-s if it did not receive ext-info-c?

=
S 3.4.
=C2=A0 A client sends "y" to indi= cate its preference that the session should
=C2=A0 be elevated; &= quot;n" to not be elevated; and "d" for the server to use it= s
=C2=A0 default behavior. If a client does not send the "el= evation" extension,
=C2=A0 the server SHOULD act as if "= ;d" was sent.

You need a citation for "e= levated."



_______________________________________________
Curdle mailing list
Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle


--94eb2c19fcf847070e0552533f8d-- From nobody Tue Jun 20 07:08:28 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF5412EC78 for ; Tue, 20 Jun 2017 07:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 ZSxAnc17xSEI for ; Tue, 20 Jun 2017 07:08:12 -0700 (PDT) Received: from mail-yb0-x22e.google.com (mail-yb0-x22e.google.com [IPv6:2607:f8b0:4002:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDBBE12EC7D for ; Tue, 20 Jun 2017 07:08:04 -0700 (PDT) Received: by mail-yb0-x22e.google.com with SMTP id f192so37586494yba.2 for ; Tue, 20 Jun 2017 07:08:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sfjJJsVyHC9KoMy9UwYflIPiY1IowrI1GyUIG3iNF/Q=; b=JJ5CiFvRnDhChLEQbuL89xJQrbq7dEmedocYsSXbv8D99I27ithUf91sHIpQgnq5Gd OHG6lYI+DGDag4fx3DwHVvf4S+UtDOPNu2E1QgU/MBjblymwD8y3554hwSH2EsHsJGFL ydZizCn7Czkg2m5yJQslRf7AqUV5sXes6r4YF+oBEk9LMwjHPz1nyBDEDNov6h03XHyk Fpc0ztj4r6syWdcw4cEKg6frdnBOLNT/act+1+KyuHfuwfceqRVBpaaWrKN0XQ7kHKed Hm0od81/NDZJhaM5VUU3BWj6l/sv55TwSMwVZCtrtJY95asZlnpdZW3qNT1XXsST8WoE TKog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sfjJJsVyHC9KoMy9UwYflIPiY1IowrI1GyUIG3iNF/Q=; b=tR//uP60aZXQdVSU4GAautFy2XETW8SmGPzh8hLPvydtSFpBnaM4ko4ZO/k025ghqi QhTZ9yPWo6v4XlvXBSTq1AfXfgYGf1shwUq2QNKfmzthkjxW8LoUd6Kf49R8dydDpHhD G2gaSdGd+eVPYyhXn9Cr63DDoCNbhkF0CpmGXhDPoMi4M/KuQQk7YcOkXSyCKrqKRFvJ fRP7j/zSKLCv1eCprL2pM3qBZFcdEA88LXfaI98+DrBnIDBw7nVIPpQQnpQiaKI9dzQo BGlx6906bAsoc8oiDfxSTiQoLuA7cY0Mk2Wqc0IZIPisC3KgzhRx3ec5Vy/+G0NjhKyM VZ7A== X-Gm-Message-State: AKS2vOwlRffrg+92rrKmyNmu7jO55Qn/9QWLSKb5Lx9Y6vj1COMSuDWt 1InsydQP4Zk2XdRlDuMt04RKTa493UpC X-Received: by 10.37.189.209 with SMTP id g17mr23209262ybk.131.1497967683928; Tue, 20 Jun 2017 07:08:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.45.2 with HTTP; Tue, 20 Jun 2017 07:08:03 -0700 (PDT) In-Reply-To: References: <61120.1497804752@eng-mail01.juniper.net> From: denis bider Date: Tue, 20 Jun 2017 08:08:03 -0600 Message-ID: To: Eric Rescorla Cc: "Mark D. Baushke" , curdle Content-Type: multipart/alternative; boundary="089e0822f48cafb1b9055264c748" Archived-At: Subject: Re: [Curdle] AD Review: draft-ietf-curdle-ssh-modp-dh-sha2-05.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 14:08:26 -0000 --089e0822f48cafb1b9055264c748 Content-Type: text/plain; charset="UTF-8" It pretty much says "anything below SHA-384 ist verboten". I was able to find the document here: https://www.iad.gov/iad/library/ia-guidance/ia-solutions-for-classified/algorithm-guidance/cnsa-suite-and-quantum-computing-faq.cfm It's in a PDF that you can download. To open the page in the first place, you may likely need Firefox, which allows you to add a security exception (the website's TLS certificate is signed by a DOD authority, instead of by a public CA). On Mon, Jun 19, 2017 at 11:10 AM, Eric Rescorla wrote: > Hmm... I can't get a copy of that sheet, but I'd be interested to see if > it it really says that you can't use SHA-256-based KDFs. > > > On Mon, Jun 19, 2017 at 9:29 AM, denis bider > wrote: > >> I have a strong preference to keep the groups and hashes as they are, and >> only clarify the rationale, if necessary. >> >> I'm not sure that it is necessary to clarify the rationale, because it is >> not meant to be an appeal to cryptographic theory, it's an appeal to market >> authority. The argument being made here is not that SHA-256 is >> insufficient, it's that there's a substantial market which requires SHA-384 >> or SHA-512. >> >> On Sun, Jun 18, 2017 at 7:00 PM, Eric Rescorla wrote: >> >>> >>> >>> On Sun, Jun 18, 2017 at 9:52 AM, Mark D. Baushke >>> wrote: >>> >>>> Hi Eric, >>>> >>>> I will rework the rationle and the security considerations sections to >>>> address your concerns. >>>> >>>> Question: Is it your contention that we should be able to use SHA256 for >>>> all of the new MODP groups because the internal state of the hash will >>>> always have more bits than the maximum amount of entropy in the >>>> Diffie-Hellman shared secret? >>>> >>> >>> Yeah, that's kind of where I was going with this. Note that TLS 1.3 >>> allows >>> SHA-256 with every kind of group, including P-384 and X448, so there is >>> some precedent. That said, I agree that SHA-512 is fine for this and so >>> if that's the WG's preference or there's some technical reason I'm not >>> aware >>> of, I don't see a problem with SHA-512. >>> >>> -Ekr >>> >>> >>>> Thank you, >>>> -- Mark >>>> >>> >>> >>> _______________________________________________ >>> Curdle mailing list >>> Curdle@ietf.org >>> https://www.ietf.org/mailman/listinfo/curdle >>> >>> >> > --089e0822f48cafb1b9055264c748 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It pretty much says "anything below SHA-384 ist verbo= ten". I was able to find the document here:


It= 's in a PDF that you can download. To open the page in the first place,= you may likely need Firefox, which allows you to add a security exception = (the website's TLS certificate is signed by a DOD authority, instead of= by a public CA).


On Mon, Jun 19, 2017 at 11:10 AM, Eric Rescorla <ekr@rtfm.com= > wrote:
Hmm... I can't get a copy of that sheet, but I'd = be interested to see if it it really says that you can't use SHA-256-ba= sed KDFs.


On Mon, Jun 19, 2017 at 9:29 AM, denis bider <denisbider.ietf@gmail.com> wrote:
I have a strong preferenc= e to keep the groups and hashes as they are, and only clarify the rationale= , if necessary.

I'm not sure that it is necessary to= clarify the rationale, because it is not meant to be an appeal to cryptogr= aphic theory, it's an appeal to market authority. The argument being ma= de here is not that SHA-256 is insufficient, it's that there's a su= bstantial market which requires SHA-384 or SHA-512.

On Sun, Jun 18, 2017 at 7:00 PM, Eric Rescorla <ekr@rtfm= .com> wrote:


On Sun, Jun 18, 2017 at 9:52 AM, Mark D. Baushke <mdb@juniper.net><= /span> wrote:
Hi Eric,=

I will rework the rationle and the security considerations sections to
address your concerns.

Question: Is it your contention that we should be able to use SHA256 for all of the new MODP groups because the internal state of the hash will
always have more bits than the maximum amount of entropy in the
Diffie-Hellman shared secret?

Ye= ah, that's kind of where I was going with this. Note that TLS 1.3 allow= s
SHA-256 with every kind of group, including P-384 and X448, so = there is
some precedent. That said, I agree that SHA-512 is fine = for this and so
if that's the WG's preference or there= 9;s some technical reason I'm not aware
of, I don't see a= problem with SHA-512.

-Ekr


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thank you,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mark


_______________________________________________
Curdle mailing list
Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle



--089e0822f48cafb1b9055264c748-- From nobody Tue Jun 20 07:15:26 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2866412EC78 for ; Tue, 20 Jun 2017 07:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 3deqTg2I7GQN for ; Tue, 20 Jun 2017 07:15:12 -0700 (PDT) Received: from mail-yb0-x22d.google.com (mail-yb0-x22d.google.com [IPv6:2607:f8b0:4002:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1456112EC9B for ; Tue, 20 Jun 2017 07:14:53 -0700 (PDT) Received: by mail-yb0-x22d.google.com with SMTP id 84so37675089ybe.0 for ; Tue, 20 Jun 2017 07:14:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HivJL7gJcq8Dia1Lw5nBxrI1vxp7xwkcSuj+x9B8Kho=; b=ipskiFtKHua5ppf5qxACFZI4GTJE/SPWYo+DmfLOVy6ICeeC5I8Ik453VdcXXRbEmv pk7XYC/ESWl91WV3v8t1O1BNW5ce05y/jezmCBr5/uE1y9JBAt/9h8BEDEeqwo7lrVmU Mv5dLGqp+v1dMzHy+NutxQvfdSF2LyVV3jdg/ZKE//oMbjf9FK2hZRb0RbD4YqXFcxtm 27zMscaSkaQ4Z/ITU8dAQoDTERb3V8h67T2vzm7hXwzJ+Jxts1mKmFA5XWJdhn0I4RbY 6BiOZ2A9aNTEiZ0Olgrc9Q3mtAYAWb2/SXcXIOLs2MnTYCfx/zJAjb2f+YhSGFdvpXq/ n9uQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HivJL7gJcq8Dia1Lw5nBxrI1vxp7xwkcSuj+x9B8Kho=; b=CqVB09BHDAL3DGQlMc7t/uff7T6IJGjPqrsAnEr72BhJZYa1ou5bRql2ognDjFvpd+ S6AzVqQJxlNet+Jnk4XrA8fdSU+LNJu9tNoC3sgSPU2me1+mGkluZcTIaDC0EJIYwr3+ UFgTf970lpts21qtiG2FNm0VE/1NAwIGtU4kCPMLlpaZMLA+YzWuyDSg72z2hzaoNyNQ zOaWVJuTvTy9+Q0CTsJtg/pZAicPFW9mGwpFhOp96ciCzMMMWHZoW+S2P1m/FIVE8ZC7 RYgybqhAfNAIIu5Wuf2bLtm2Wt8FQSAtEQY5Xy0qVB96M7m/hk6OEWwx09OYb/JJa52C 7C+g== X-Gm-Message-State: AKS2vOwJMoUfjZDBluT0SAr04d0s9dqnsmWst9XHDile1hkw5cvQPDTf /suF84CF7Ea6wUeFiqTQ72ENvkGtOQ== X-Received: by 10.37.205.133 with SMTP id d127mr23352926ybf.215.1497968092311; Tue, 20 Jun 2017 07:14:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.45.2 with HTTP; Tue, 20 Jun 2017 07:14:51 -0700 (PDT) In-Reply-To: References: From: denis bider Date: Tue, 20 Jun 2017 08:14:51 -0600 Message-ID: To: Eric Rescorla Cc: curdle Content-Type: multipart/alternative; boundary="94eb2c189eec070bbc055264e0eb" Archived-At: Subject: Re: [Curdle] AD Review: draft-ietf-curdle-rsa-sha2-07.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 14:15:19 -0000 --94eb2c189eec070bbc055264e0eb Content-Type: text/plain; charset="UTF-8" I agree, but there has to be a reason it's on its way out. :) This is the one reason I know how to phrase. If there's something else I can do instead, let me know. On Mon, Jun 19, 2017 at 11:11 AM, Eric Rescorla wrote: > > > On Mon, Jun 19, 2017 at 8:28 AM, denis bider > wrote: > >> > Either you are using PKCS#1 v1.5 or you are using PSS. >> > In the former case, there is no mask function and salt. >> >> Yikes, thanks. :) This was left over from an early version that specified >> PSS. This was before PKCS#1 v1.5 was requested. (The change took place >> before any implementation was released, so all deployed implementations use >> PKCS#1 v1.5.) >> >> >> > You say in the intro that RSA was defined as 1024 bit >> > keys. Are these keys of arbitrary length? Is there an >> > upper or lower limit? >> >> I believe this may refer to the following sentence: >> >> "In [RFC4253], SSH originally defined the public key algorithms "ssh-rsa" >> for server and client authentication using RSA with SHA-1, and "ssh-dss" >> using 1024-bit DSA and SHA-1." >> >> Here, 1024-bit refers to DSA. RFC 4253 imposes no limits on RSA key sizes. >> >> >> > > Implementations SHOULD apply PKCS#1 v1.5 padding to the expected >> > > hash, THEN compare the encoded bytes with the output of [...] >> >> > Why "SHOULD? >> >> Fair point. Changed as follows: >> >> "Verifiers MUST instead apply PKCS#1 v1.5 padding to the expected hash, >> then compare the encoded bytes with the output of the RSA operation." >> >> >> > This is an odd argument given that ECDSA is often also >> > implemented with random k. >> >> I agree, but that is the main argument that was given by multiple people >> as the main reason to remove DSA from the original draft (which covered DSA >> in addition). >> > > How about just "DSA is on its way out" :) > > >> >> >> denis >> >> >> >> On Sat, Jun 17, 2017 at 1:30 PM, Eric Rescorla wrote: >> >>> TECHNICAL >>> S 3. >>> Signing and verifying using these algorithms is performed according to >>> the RSASSA-PKCS1-v1_5 scheme in [RFC8017] using SHA-2 [SHS] as hash; >>> MGF1 as mask function; and salt length equal to hash size. >>> >>> This seems incorrect. Either you are using PKCS#1 v1.5 or you are >>> using PSS. In the former case, there is no mask function and salt. >>> Appendix 5.3 suggests that you are not using PSS. In any case, >>> you need to fix the inconsistency. >>> >>> You say in the intro that RSA was defined as 1024 bit keys. Are >>> these keys of arbitrary length? Is there an upper or lower limit? >>> >>> >>> S 5.3. >>> Implementations SHOULD apply PKCS#1 v1.5 padding to the expected hash, >>> THEN compare the encoded bytes with the output of the RSA operation. >>> >>> Why "SHOULD? >>> >>> >>> S 6. >>> A draft version of this memo also defined an algorithm name for use of >>> 2048-bit and 3072-bit DSA keys with a 256-bit subgroup and SHA-2 256 >>> hashing. It is possible to implement DSA securely by generating "k" >>> deterministically as per [RFC6979]. However, a plurality of reviewers >>> were concerned that implementers would continue to use libraries that >>> generate "k" randomly. This is vulnerable to biased "k" generation, >>> and extremely vulnerable to "k" reuse. This document therefore >>> disrecommends DSA, in favor of RSA and elliptic curve cryptography. >>> >>> This is an odd argument given that ECDSA is often also implemented >>> with random k. Not that I am in favor of adding DSA here. >>> >>> -Ekr >>> >>> >>> >>> _______________________________________________ >>> Curdle mailing list >>> Curdle@ietf.org >>> https://www.ietf.org/mailman/listinfo/curdle >>> >>> >> > --94eb2c189eec070bbc055264e0eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree, but there has to be a reason it's on its way = out. :) This is the one reason I know how to phrase. If there's somethi= ng else I can do instead, let me know.

=
On Mon, Jun 19, 2017 at 11:11 AM, Eric Rescorla = <ekr= @rtfm.com> wrote:


On Mon, Jun 19, 2017 at 8:28 AM, denis bider <denisbi= der.ietf@gmail.com> wrote:
=
> Either you are using PKCS#1 v1.5 or you are usi= ng PSS.
> In the former case, there is no mask function and salt.
=
Yikes, thanks. :) This was left over from an early version that = specified PSS. This was before PKCS#1 v1.5 was requested. (The change took = place before any implementation was released, so all deployed implementatio= ns use PKCS#1 v1.5.)


> You say in the intro that RSA wa= s defined as 1024 bit
> keys. Are these keys of arbitrary length? Is = there an
> upper or lower limit?

I believe this may ref= er to the following sentence:

"In [RFC4253], SSH originally def= ined the public key algorithms "ssh-rsa" for server and client au= thentication using RSA with SHA-1, and "ssh-dss" using 1024-bit D= SA and SHA-1."

Here, 1024-bit refers to DSA. RFC 4253 imposes n= o limits on RSA key sizes.


> > Implementations SHOUL= D apply PKCS#1 v1.5 padding to the expected
> > hash, THEN = compare the encoded bytes with the output of [...]

> Why "SH= OULD?

Fair point. Changed as follows:

"Verifiers MUST in= stead apply PKCS#1 v1.5 padding to the expected hash, then compare the enco= ded bytes with the output of the RSA operation."


>= This is an odd argument given that ECDSA is often also
> implemented= with random k.

I agree, but that is the main argument that w= as given by multiple people as the main reason to remove DSA from the origi= nal draft (which covered DSA in addition).

<= /div>
How about just "DSA is on its way out" :)
<= div>
=C2=A0


denis



On Sat, Jun 17, 2017 at 1:30 PM, Eric Rescorla <ekr@rtfm.com= > wrote:
<= div class=3D"m_3155108393946745036h5">
TECHNICAL
=
S 3.
=C2=A0 Signing and verifying using these algorithms is = performed according to
=C2=A0 the RSASSA-PKCS1-v1_5 scheme in [RF= C8017] using SHA-2 [SHS] as hash;
=C2=A0 MGF1 as mask function; a= nd salt length equal to hash size.

This seems inco= rrect. Either you are using PKCS#1 v1.5 or you are
using PSS. In = the former case, there is no mask function and salt.
Appendix 5.3= suggests that you are not using PSS. In any case,
you need to fi= x the inconsistency.

You say in the intro that RSA= was defined as 1024 bit keys. Are
these keys of arbitrary length= ? Is there an upper or lower limit?


S 5.3.
=C2=A0 Implementations SHOULD apply PKCS#1 v1.5 padding t= o the expected hash,
=C2=A0 THEN compare the encoded bytes with t= he output of the RSA operation.

Why "SHOULD?<= /div>


S 6.
=C2=A0 A draft versi= on of this memo also defined an algorithm name for use of
=C2=A0 = 2048-bit and 3072-bit DSA keys with a 256-bit subgroup and SHA-2 256
<= div>=C2=A0 hashing. It is possible to implement DSA securely by generating = "k"
=C2=A0 deterministically as per [RFC6979]. However,= a plurality of reviewers
=C2=A0 were concerned that implementers= would continue to use libraries that
=C2=A0 generate "k&quo= t; randomly. This is vulnerable to biased "k" generation,
=C2=A0 and extremely vulnerable to "k" reuse. This document th= erefore
=C2=A0 disrecommends DSA, in favor of RSA and elliptic cu= rve cryptography.

This is an odd argument given th= at ECDSA is often also implemented
with random k. Not that I am i= n favor of adding DSA here.

-Ekr



_______________________________________________
Curdle mailing list
Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle



--94eb2c189eec070bbc055264e0eb-- From nobody Tue Jun 20 15:55:47 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEEF21200C1 for ; Tue, 20 Jun 2017 15:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_LOW=-0.7] 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 l0nTwhnfv0Ea for ; Tue, 20 Jun 2017 15:55:43 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38C36126C0F for ; Tue, 20 Jun 2017 15:55:43 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id l75so58149592ywc.3 for ; Tue, 20 Jun 2017 15:55:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hfDdPB08A2Q5bynFFhxXu1N91pze7ba4iPfqa2TS/V4=; b=tNJ9P86752MObvN01sMnrIsUjo+K8/0Iv+gT3bn/pt5k/+sFXMijl43hrS0+QOec5L rnMzbcRZ9pvfOkUW4eITmvIyQEFlrlmP8K1LcahaEZ/tFnHAkBZLjnWKEdFfOfdLEqss Ok6TRXw2km3fyVH+BnzaoinBC3oGufK1mfN1GAtZwHXdrjnmio1edUY934uA1XwtcVAc EAQJCP2zswt02G7EAYtnV55kTzzRz7wGNP9NyPvk3JQ8m4ywudFMdsH2zG5gNasZyZOi 35QyC5z8f4HaY4479XtUlsVAcBP3iGi/rXSFJ4oxtB+qYqdTkJS/f347m8O02VGEVPgB /0uA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hfDdPB08A2Q5bynFFhxXu1N91pze7ba4iPfqa2TS/V4=; b=Ujwo9rG1gRwXyci+C5YXnztVs/I3l+9h8ttVy9SRP6k7buwf2pLcwKBzBLIeBM3RvY xMmDOSfyq2JaZRaQx1mv3b9S8li556lx67q8TYbx96PbTTpIUJXq0Wp2tL/C7zTjvJZT RnY9Rx+L89g0TxdWuVd6rRGXnsg0xnfQhdx52Ygl6IgPoedupRdENlOYGCKietsUBADK bNYHzgu3DSzRS9+7rqOYAMFcY5zdDwhHdOtM5TE4tS5+6ytuRVgim7U1IVxlFch1Zw7I MTDvWq0MhAvuItq4ZC2ebWfqEuKDeA9zNMg9kongE0LG9TqdseE8c0uMS3rMOa5jHePD bMdw== X-Gm-Message-State: AKS2vOxw7KVQHwA2Ou0l7Wqej5EIYQ0BrS8NzvWJqWTvjkrlyj/ul3Ue Qxj4ikJ9A/cbDsMMwpA46dJYAa6cAr// X-Received: by 10.129.68.10 with SMTP id r10mr23813269ywa.85.1497999342390; Tue, 20 Jun 2017 15:55:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Tue, 20 Jun 2017 15:55:01 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Tue, 20 Jun 2017 15:55:01 -0700 Message-ID: To: denis bider Cc: curdle Content-Type: multipart/alternative; boundary="f403045eb768ad689405526c26ef" Archived-At: Subject: Re: [Curdle] AD Review: draft-ietf-curdle-rsa-sha2-07.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 22:55:46 -0000 --f403045eb768ad689405526c26ef Content-Type: text/plain; charset="UTF-8" Usually, I would say "we're getting rid of finite field" :) -Ekr On Tue, Jun 20, 2017 at 7:14 AM, denis bider wrote: > I agree, but there has to be a reason it's on its way out. :) This is the > one reason I know how to phrase. If there's something else I can do > instead, let me know. > > On Mon, Jun 19, 2017 at 11:11 AM, Eric Rescorla wrote: > >> >> >> On Mon, Jun 19, 2017 at 8:28 AM, denis bider >> wrote: >> >>> > Either you are using PKCS#1 v1.5 or you are using PSS. >>> > In the former case, there is no mask function and salt. >>> >>> Yikes, thanks. :) This was left over from an early version that >>> specified PSS. This was before PKCS#1 v1.5 was requested. (The change took >>> place before any implementation was released, so all deployed >>> implementations use PKCS#1 v1.5.) >>> >>> >>> > You say in the intro that RSA was defined as 1024 bit >>> > keys. Are these keys of arbitrary length? Is there an >>> > upper or lower limit? >>> >>> I believe this may refer to the following sentence: >>> >>> "In [RFC4253], SSH originally defined the public key algorithms >>> "ssh-rsa" for server and client authentication using RSA with SHA-1, and >>> "ssh-dss" using 1024-bit DSA and SHA-1." >>> >>> Here, 1024-bit refers to DSA. RFC 4253 imposes no limits on RSA key >>> sizes. >>> >>> >>> > > Implementations SHOULD apply PKCS#1 v1.5 padding to the expected >>> > > hash, THEN compare the encoded bytes with the output of [...] >>> >>> > Why "SHOULD? >>> >>> Fair point. Changed as follows: >>> >>> "Verifiers MUST instead apply PKCS#1 v1.5 padding to the expected hash, >>> then compare the encoded bytes with the output of the RSA operation." >>> >>> >>> > This is an odd argument given that ECDSA is often also >>> > implemented with random k. >>> >>> I agree, but that is the main argument that was given by multiple people >>> as the main reason to remove DSA from the original draft (which covered DSA >>> in addition). >>> >> >> How about just "DSA is on its way out" :) >> >> >>> >>> >>> denis >>> >>> >>> >>> On Sat, Jun 17, 2017 at 1:30 PM, Eric Rescorla wrote: >>> >>>> TECHNICAL >>>> S 3. >>>> Signing and verifying using these algorithms is performed according to >>>> the RSASSA-PKCS1-v1_5 scheme in [RFC8017] using SHA-2 [SHS] as hash; >>>> MGF1 as mask function; and salt length equal to hash size. >>>> >>>> This seems incorrect. Either you are using PKCS#1 v1.5 or you are >>>> using PSS. In the former case, there is no mask function and salt. >>>> Appendix 5.3 suggests that you are not using PSS. In any case, >>>> you need to fix the inconsistency. >>>> >>>> You say in the intro that RSA was defined as 1024 bit keys. Are >>>> these keys of arbitrary length? Is there an upper or lower limit? >>>> >>>> >>>> S 5.3. >>>> Implementations SHOULD apply PKCS#1 v1.5 padding to the expected hash, >>>> THEN compare the encoded bytes with the output of the RSA operation. >>>> >>>> Why "SHOULD? >>>> >>>> >>>> S 6. >>>> A draft version of this memo also defined an algorithm name for use of >>>> 2048-bit and 3072-bit DSA keys with a 256-bit subgroup and SHA-2 256 >>>> hashing. It is possible to implement DSA securely by generating "k" >>>> deterministically as per [RFC6979]. However, a plurality of reviewers >>>> were concerned that implementers would continue to use libraries that >>>> generate "k" randomly. This is vulnerable to biased "k" generation, >>>> and extremely vulnerable to "k" reuse. This document therefore >>>> disrecommends DSA, in favor of RSA and elliptic curve cryptography. >>>> >>>> This is an odd argument given that ECDSA is often also implemented >>>> with random k. Not that I am in favor of adding DSA here. >>>> >>>> -Ekr >>>> >>>> >>>> >>>> _______________________________________________ >>>> Curdle mailing list >>>> Curdle@ietf.org >>>> https://www.ietf.org/mailman/listinfo/curdle >>>> >>>> >>> >> > --f403045eb768ad689405526c26ef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Usually, I would say "we're getting rid of finite= field" :)

-Ekr


On Tue, Jun 20, 2017 at 7:= 14 AM, denis bider <denisbider.ietf@gmail.com> wrote= :
I agree, but there has= to be a reason it's on its way out. :) This is the one reason I know h= ow to phrase. If there's something else I can do instead, let me know.<= /div>
On Mon, Jun 19, 2017 at 11:11 AM, Eric Rescorla= <ek= r@rtfm.com> wrote:


On Mon, Jun 19, 2017 at 8:28 AM, denis bider <denisbider.ietf@gm= ail.com> wrote:
> Either you are using PKCS#1 v1.5 or you are using PSS.
= > In the former case, there is no mask function and salt.

= Yikes, thanks. :) This was left over from an early version that specified P= SS. This was before PKCS#1 v1.5 was requested. (The change took place befor= e any implementation was released, so all deployed implementations use PKCS= #1 v1.5.)


> You say in the intro that RSA was defined a= s 1024 bit
> keys. Are these keys of arbitrary length? Is there an> upper or lower limit?

I believe this may refer to the f= ollowing sentence:

"In [RFC4253], SSH originally defined the pu= blic key algorithms "ssh-rsa" for server and client authenticatio= n using RSA with SHA-1, and "ssh-dss" using 1024-bit DSA and SHA-= 1."

Here, 1024-bit refers to DSA. RFC 4253 imposes no limits on= RSA key sizes.


> > Implementations SHOULD apply PKC= S#1 v1.5 padding to the expected
> > hash, THEN compare the= encoded bytes with the output of [...]

> Why "SHOULD?
Fair point. Changed as follows:

"Verifiers MUST instead apply= PKCS#1 v1.5 padding to the expected hash, then compare the encoded bytes w= ith the output of the RSA operation."


> This is an= odd argument given that ECDSA is often also
> implemented with rando= m k.

I agree, but that is the main argument that was given by= multiple people as the main reason to remove DSA from the original draft (= which covered DSA in addition).

How about just "DSA is on its way out" :)
=C2=A0


denis



On Sat, Jun 17, 2017 at = 1:30 PM, Eric Rescorla <ekr@rtfm.com> wrote:
TECHNICAL
S 3.
= =C2=A0 Signing and verifying using these algorithms is performed according = to
=C2=A0 the RSASSA-PKCS1-v1_5 scheme in [RFC8017] using SHA-2 [= SHS] as hash;
=C2=A0 MGF1 as mask function; and salt length equal= to hash size.

This seems incorrect. Either you ar= e using PKCS#1 v1.5 or you are
using PSS. In the former case, the= re is no mask function and salt.
Appendix 5.3 suggests that you a= re not using PSS. In any case,
you need to fix the inconsistency.=

You say in the intro that RSA was defined as 1024= bit keys. Are
these keys of arbitrary length? Is there an upper = or lower limit?


S 5.3.
= =C2=A0 Implementations SHOULD apply PKCS#1 v1.5 padding to the expected has= h,
=C2=A0 THEN compare the encoded bytes with the output of the R= SA operation.

Why "SHOULD?


S 6.
=C2=A0 A draft version of this memo al= so defined an algorithm name for use of
=C2=A0 2048-bit and 3072-= bit DSA keys with a 256-bit subgroup and SHA-2 256
=C2=A0 hashing= . It is possible to implement DSA securely by generating "k"
=C2=A0 deterministically as per [RFC6979]. However, a plurality of re= viewers
=C2=A0 were concerned that implementers would continue to= use libraries that
=C2=A0 generate "k" randomly. This = is vulnerable to biased "k" generation,
=C2=A0 and extr= emely vulnerable to "k" reuse. This document therefore
= =C2=A0 disrecommends DSA, in favor of RSA and elliptic curve cryptography.<= /div>

This is an odd argument given that ECDSA is often = also implemented
with random k. Not that I am in favor of adding = DSA here.

-Ekr


=

_______________________________________________
Curdle mailing list
Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle




--f403045eb768ad689405526c26ef-- From nobody Tue Jun 20 23:50:44 2017 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 023ED126C3D; Tue, 20 Jun 2017 23:50:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149802782998.15789.8464400490485054495@ietfa.amsl.com> Date: Tue, 20 Jun 2017 23:50:30 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-ssh-dh-group-exchange-02.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 06:50:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : Increase minimum recommended modulus size to 2048 bits Authors : Loganaden Velvindron Mark D. Baushke Filename : draft-ietf-curdle-ssh-dh-group-exchange-02.txt Pages : 4 Date : 2017-06-20 Abstract: The Diffie-Hellman (DH) Group Exchange for the Secure Shell (SSH) Transport layer Protocol specifies that servers and clients should support groups with a modulus length of k bits, where the recommended minumum value is 1024 bits. Recent security research has shown that a minimum value of 1024 bits is insufficient against state-sponsored actors. As such, this document formally updates the specification such that the minimum recommended value for k is 2048 bits and the group size is 2048 bits at minimum. This RFC updates RFC4419 which allowed for DH moduli less than 2048 bits. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-dh-group-exchange/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-ssh-dh-group-exchange-02 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-dh-group-exchange-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-ssh-dh-group-exchange-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 Wed Jun 21 06:02:53 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2746128B91 for ; Wed, 21 Jun 2017 06:02:51 -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 WMYdBXSbEw_b for ; Wed, 21 Jun 2017 06:02:48 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (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 C91F8120721 for ; Wed, 21 Jun 2017 06:02:48 -0700 (PDT) X-AuditID: c618062d-8e0d79a00000248b-01-594a83428995 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id B8.4C.09355.0438A495; Wed, 21 Jun 2017 16:31:30 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0339.000; Wed, 21 Jun 2017 09:02:44 -0400 From: Daniel Migault To: "curdle@ietf.org" Thread-Topic: WGLC draft-ietf-curdle-ssh-dh-group-exchange Thread-Index: AdLqjqs7fM5/O2BzTZ20pOrtTrrdMw== Date: Wed, 21 Jun 2017 13:02:44 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118C8402C@eusaamb107.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyuXRPlK5Ts1ekwf4flhZbF85idmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxu2XC9kKnotULP5+jrmB8aVAFyMnh4SAicTic1tYuhi5OIQE jjJKPH75jhXCWc4ocXnyX0aQKjYBI4m2Q/3sILaIgLrEiUM7gIo4OIQFTCU2LdKBCFtJTN5x gBXC1pNou7sCzGYRUJWYc/YKWCuvgK/EuTlH2UBsRgExie+n1jCB2MwC4hK3nsxngjhIQGLJ nvPMELaoxMvH/1ghbCWJOa+vMUPU60gs2P2JDcLWlli28DUzxHxBiZMzn7BMYBSahWTsLCQt s5C0zELSsoCRZRUjR2lxQU5uupHBJkZgwB6TYNPdwXh/uuchRgEORiUe3lN5XpFCrIllxZW5 hxglOJiVRHg35gCFeFMSK6tSi/Lji0pzUosPMUpzsCiJ8044fyFCSCA9sSQ1OzW1ILUIJsvE wSnVwLjIJGb7u6tnLl1wm7lxb4+fq7CbL6PbhpMbu3/tXLiounx9OH9am09CkCmbUf3moLuC Exf2TbwZrJKe9p1v1umj/4QOxVtVLXor/29LWeKuXZdS1oV+VxVjFz0cu+Z86dwLLAelO++0 dQbLRe3ZPYMtcdOSyVE31oqcKTyQuP2RzF+/xKO3dEWVWIozEg21mIuKEwHcUxdtVAIAAA== Archived-At: Subject: [Curdle] WGLC draft-ietf-curdle-ssh-dh-group-exchange X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 13:02:52 -0000 Hi,=20 This mail starts a WGLC for the draft-ietf-curdle-ssh-dh-group-exchange. I = believe there are still some nits to be addressed, but overall the document= seems in good shape. Please provide your feed backs by June 5.=20 The document is available at eth url below: https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-dh-group-exchan= ge-02 Yours,=20 Rich and Daniel -----Original Message----- From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of internet-drafts@= ietf.org Sent: Wednesday, June 21, 2017 2:51 AM To: i-d-announce@ietf.org Cc: curdle@ietf.org Subject: [Curdle] I-D Action: draft-ietf-curdle-ssh-dh-group-exchange-02.tx= t A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the CURves, Deprecating and a Little more Encr= yption of the IETF. Title : Increase minimum recommended modulus size to 2048= bits Authors : Loganaden Velvindron Mark D. Baushke Filename : draft-ietf-curdle-ssh-dh-group-exchange-02.txt Pages : 4 Date : 2017-06-20 Abstract: The Diffie-Hellman (DH) Group Exchange for the Secure Shell (SSH) Transport layer Protocol specifies that servers and clients should support groups with a modulus length of k bits, where the recommended minumum value is 1024 bits. Recent security research has shown that a minimum value of 1024 bits is insufficient against state-sponsored actors. As such, this document formally updates the specification such that the minimum recommended value for k is 2048 bits and the group size is 2048 bits at minimum. This RFC updates RFC4419 which allowed for DH moduli less than 2048 bits. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-dh-group-exchange/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-ssh-dh-group-exchange-02 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-dh-group-exchan= ge-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-curdle-ssh-dh-group-exchange= -02 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle From nobody Wed Jun 21 06:14:53 2017 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BDE7B129AE9; Wed, 21 Jun 2017 06:14:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149805089176.15829.5332460159767751595@ietfa.amsl.com> Date: Wed, 21 Jun 2017 06:14:51 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-ssh-dh-group-exchange-03.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 13:14:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : Increase SSH minimum recommended DH modulus size to 2048 bits Authors : Loganaden Velvindron Mark D. Baushke Filename : draft-ietf-curdle-ssh-dh-group-exchange-03.txt Pages : 4 Date : 2017-06-21 Abstract: The Diffie-Hellman (DH) Group Exchange for the Secure Shell (SSH) Transport layer Protocol specifies that servers and clients should support groups with a modulus length of k bits, where the recommended minumum value is 1024 bits. Recent security research has shown that a minimum value of 1024 bits is insufficient against state-sponsored actors. As such, this document formally updates the specification such that the minimum recommended value for k is 2048 bits and the group size is 2048 bits at minimum. This RFC updates RFC4419 which allowed for DH moduli less than 2048 bits. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-dh-group-exchange/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-ssh-dh-group-exchange-03 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-dh-group-exchange-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-ssh-dh-group-exchange-03 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 Wed Jun 21 09:09:38 2017 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C85112EB7A; Wed, 21 Jun 2017 09:09:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149806136955.15848.6879262411018650350@ietfa.amsl.com> Date: Wed, 21 Jun 2017 09:09:29 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-ssh-modp-dh-sha2-06.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 16:09:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : More Modular Exponential (MODP) Diffie-Hellman (DH) Key Exchange (KEX) Groups for Secure Shell (SSH) Author : Mark D. Baushke Filename : draft-ietf-curdle-ssh-modp-dh-sha2-06.txt Pages : 6 Date : 2017-06-21 Abstract: This document defines added Modular Exponential (MODP) Groups for the Secure Shell (SSH) protocol using SHA-2 hashes. This document updates RFC 4250. This document updates RFC 4253. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-modp-dh-sha2/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-ssh-modp-dh-sha2-06 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-modp-dh-sha2-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-ssh-modp-dh-sha2-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 21 10:46:17 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B11F126CF6; Wed, 21 Jun 2017 10:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 Eg02z1t07UG8; Wed, 21 Jun 2017 10:46:06 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 302CC128656; Wed, 21 Jun 2017 10:46:05 -0700 (PDT) X-AuditID: 12074425-7d5ff70000003ab1-32-594ab0db6c46 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id A6.92.15025.BD0BA495; Wed, 21 Jun 2017 13:46:04 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id v5LHk2is023738; Wed, 21 Jun 2017 13:46:03 -0400 Received: from kduck.kaduk.org (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.13.8/8.12.4) with ESMTP id v5LHjw4h012961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Jun 2017 13:46:01 -0400 Date: Wed, 21 Jun 2017 12:45:58 -0500 From: Benjamin Kaduk To: Martin Rex Cc: kitten@ietf.org, curdle@ietf.org Message-ID: <20170621174558.GK39245@kduck.kaduk.org> References: <20170621034615.GH39245@kduck.kaduk.org> <20170621094935.AF6161A6BF@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170621094935.AF6161A6BF@ld9781.wdf.sap.corp> User-Agent: Mutt/1.7.1 (2016-10-04) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixCmqrHtng1ekwY5vjBZbF85itji6eRWL Re/vHcwOzB5Llvxk8pjyeStjAFMUl01Kak5mWWqRvl0CV8a6Y5+YC66IVCz+c4m9gfGQQBcj J4eEgInEor/vGbsYuTiEBBYzSUzbs44RJCEksJFRYtEVLojEVSaJVW0r2UASLAKqEjNXPmIH sdkEVCQaui8zg9giArIS0669AWtmBopvetrECmILC8RKnPrxnaWLkYODF2hb20owU0ggTeL/ ZbAbeAUEJU7OfMIC0aklcePfSyaQEmYBaYnl/zhAwpwCNhI7fn5jArFFBZQl/h6+xzKBUWAW ku5ZSLpnIXQvYGRexSibklulm5uYmVOcmqxbnJyYl5dapGuhl5tZopeaUrqJERSq7C6qOxjn /PU6xCjAwajEw2tR5xUpxJpYVlyZe4hRkoNJSZS3YxlQiC8pP6UyI7E4I76oNCe1+BCjBAez kgjvnXVAOd6UxMqq1KJ8mJQ0B4uSOK+4RmOEkEB6YklqdmpqQWoRTFaGg0NJgtd5PVCjYFFq empFWmZOCUKaiYMTZDgP0HCdNSDDiwsSc4sz0yHypxgVpcR5X4FsFQBJZJTmwfWCUolE9v6a V4ziQK8I82oAE4sQDzANwXW/AhrMBDT4xREPkMEliQgpqQZGua2hVU3v+85Vtze6fJy0NuXe qiU+P4sW5X/+LZHMuiDu7ZVVTdm8TNnXAlqf1Ni9eirLvPsDz+vbZkvEpv110zX8cFhf2PmN wbxVt9rSnD0j7EJzP7utnWvhdv7PpLXTM7Zkym0OkWeMeju/2uFcrJf63DUH/Y/YbHTb2Cfs yHTE7UPlc9Z3SizFGYmGWsxFxYkAaYfDZwADAAA= Archived-At: Subject: Re: [Curdle] [kitten] I-D Action: draft-ietf-curdle-des-des-des-die-die-die-03.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 17:46:08 -0000 Adding curdle@ for discussion of potential content changes to the draft... On Wed, Jun 21, 2017 at 11:49:35AM +0200, Martin Rex wrote: > Benjamin Kaduk wrote: > > On Mon, Jun 19, 2017 at 06:43:31PM +0200, Martin Rex wrote: > >> > >> I have always been wondering about the following issue about > >> Microsoft Kerberos and the RC4-enctype: > > > > Just to note explicitly: I am listed in the To: line of this message > > but am definitely not the right person to answer the questions here. > > Partially true, it would be good to get some light shed on that > issue from *all* Kerberos implementors (not just Microsoft). > > The new paragraph that you quoted as having been added to the I-D > currently _only_ talks about support for Kerberos AES enctypes in code. > The new text fails to mention the issue of availability of longterm secrets > in the Kerberos KDC database that are properly encoded for AES enctypes > --as a prerequisite of actually _using_ AES enctypes. > > It's not just about availability of sufficiently recent code, > but also a necessity for re-keying all accounts in the Kerberos KDC database > _after_ sufficiently recend code has been deployed. And it may not be > the deployment of new code on the KDC alone, there may be additonal > administrative changes necessary on the KDC to acutally enable use of > AES enctypes (e.g. changing the domain functional level in Active Directory) It sounds like you are asking for the addition of some text along the lines of: Software support is only a bare minimum requirement for deprecating RC4 enctypes; there may be additional logistical considerations involved such as provisioning AES keys for all principals and updating software configuration to enable AES and disable deprecated encryption types. Is that something you are asking for? Thanks, Ben > The necessity for rekeying as a prerequisite of using new entypes is > AFAIK caused by salting string2key differently in all Kerberos enctypes > (except for RC4-HMAC) and storing only the resulting outputs, and this > seems to apply to most, if not all Kerberos implementations, I believe. > > While many users in "managed" environments have traditionally been > pestered to change their user passwords on a regular basis, the same > might not be true for service accounts, which typically have plaintext > passwords configured in the registry on Windows Servers, or file-based > keytabs for traditional MIT Kerberos, and may not be subject to the > same regular re-keying as end user accounts in typical installations. > > > -Martin From nobody Wed Jun 21 11:20:37 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63A581293D6 for ; Wed, 21 Jun 2017 11:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGpKaWPp4vPa for ; Wed, 21 Jun 2017 11:20:33 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0139.outbound.protection.outlook.com [104.47.36.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE18812945C for ; Wed, 21 Jun 2017 11:20:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=njzL2Cz9ubjzxX4oxmYyPp1adg/NX3kO1EYyt2Rf2/I=; b=IsrWh1fjcpAvQRezZwC4Cbva85Vj4i09ZJyDtxdiNslaX8BXB6HE0yFbgLMYrMkaMgofGkWQg8bYfNwvbG6ekHmdTvmNKtH2ABBz5CX5WSE+ytz8J0AXueO4WEuYrSDqRVIAZJb/Ku+s843Y8WWj5OidJmoDiMEdQddSjkvDlDc= Received: from CY1PR05CA0033.namprd05.prod.outlook.com (2a01:111:e400:c5a4::43) by DM2PR0501MB1309.namprd05.prod.outlook.com (2a01:111:e400:3c1b::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.6; Wed, 21 Jun 2017 18:20:11 +0000 Received: from BY2NAM05FT034.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e52::203) by CY1PR05CA0033.outlook.office365.com (2a01:111:e400:c5a4::43) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.6 via Frontend Transport; Wed, 21 Jun 2017 18:20:11 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.15) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.15 as permitted sender) Received: from P-EMFE01C-SAC.jnpr.net (66.129.239.15) by BY2NAM05FT034.mail.protection.outlook.com (10.152.100.171) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1157.20 via Frontend Transport; Wed, 21 Jun 2017 18:20:11 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by P-EMFE01C-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 21 Jun 2017 11:20:06 -0700 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v5LIK5Z9028932; Wed, 21 Jun 2017 11:20:05 -0700 (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id 59ED11144E; Wed, 21 Jun 2017 11:20:05 -0700 (PDT) To: Curdle WG CC: SSH WG , Eric Rescorla From: "Mark D. Baushke" Date: Wed, 21 Jun 2017 11:20:05 -0700 Message-ID: <80212.1498069205@eng-mail01.juniper.net> Sender: MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.15; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39400400002)(39840400002)(39450400003)(39410400002)(39850400002)(2980300002)(189002)(199003)(9170700003)(6306002)(2906002)(8936002)(2810700001)(105596002)(106466001)(4326008)(76506005)(5660300001)(7116003)(53416004)(50466002)(356003)(7126002)(7696004)(117636001)(110136004)(305945005)(47776003)(6266002)(77096006)(86362001)(7846003)(6392003)(81166006)(38730400002)(5003940100001)(53936002)(478600001)(966005)(54356999)(50986999)(54906002)(189998001)(8676002)(6916009)(55016002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0501MB1309; H:P-EMFE01C-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM05FT034; 1:aFsPtKjrjun4HeqiStPt5foaCqkYETTSqxWW94Ful59/ZBPVAIAiJsdBdeem2/b/jQxz5DVQlVNKtpWe36NoSxTCF9sEQ5nYskKmv4CAI8jwD1ldg8Zcbhpzw/LHTP0HKceVRmLCG36nBItqIVasgAaIWmKi+nWSVhlGcqByDBt7wpyn7v4uSeDoLCvtPWGiz6zjNLOpwV5qJyHULFFmE/883yfE5jr1CjDB+dWH8CHwlqSP4a76Cu7AANTz45hEdCdouCVS7W6/hbIXYXP1vskjMcughfNZs7ZPxv66ja263+n1zUWPjdtijWKXtdmoQ3wgyDlWm9DjvUsgzGQuineP4fE/v7UfW2JYKQuSgxhifXUdRnTIWxr0P5isFZMWGxkb9zc6Gt3woDPM9tSyXZlnw/jsg0NHDbHrDU8U/44ZnXAyj4taNGd7BPVqpR1Z7KHIFffcs+bh57nK6MXL/n/S9ZHgi0KTqGkoQRpPtYz3TZuNlOs9MuBbTCdk/I5Js1uPQXnEr3jpSn9cQ6RLbxiTbRv3z3rCOByImHmRLDx3fsAfM8Z6nRPPTA8x8dbmnwWIUPx2r6KpJ4m8nDgArNu1AGG5FtkGF3m14pp3ae5kKImrRzDm4L3cHZ1sYlidZq0BFtkqc/Wklu0YHtGgjbUVAtKZeimfWxp277QHuQq7V+JvmGMLOHAoSDoZX/epY5F9FfX7+94WMa4RTpqB6RB/eddEH0kbnQfS4h5g3HsKvt3oOomKwlBW969PxAPHWvS6bLPsZ5lCA4eOuyGWxZ9/xTewTXbjzh+ODNsuD9Pm9v1UwZ1Bt4YKzJyFGpbcbeTR2Gyu+lxrDwrZD7MtqwmH6O7jIIoVs8I+7UQK6Fs= X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 27c7a0b5-cb50-49a7-d62f-08d4b8d227b6 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:DM2PR0501MB1309; X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB1309; 3:cc6l0txZwqTI/GsKn6x0KFiS6fh7JbkLF8v+e6dPwA1UuGUBaNsJrtbTxmHBJcRYhNRPNESezKm73GsIQCp0cd7Yqva0S53phOJAJwzTkuF14Ju/Kwg+ltq1C71dG3CqXFUT/V+bGqTXSOgOVpiAlUcAU+t3gOLXAWGk4QZcSw71P9Fj7eZjvn3mURXiHbprmNGPqx/ImEhIzOJM8FpoOKj6xNL3xMhRrj0wwZNUabKYlz+RG/5RjvVOfJ1CTKlYqrAthNPDNA7G1P6kgA6C4HV3aute1cRpa5dVgbWBzEZ5lIZ17WKLAu14l0SjwOjfYeDvybRTs80Os1dIsTH0YTblvcMArqelLefLgTCAl9/ApZrY1p9v3xgUOmTvFov5TouiVVcCN5tmlCMXNpo9+NKG9WSoSl2EOoBaFbmUlAgVSHAFvsdmtB+3PyE92e2K/zhWaAYKMCmxPqD3thFiwg== X-MS-TrafficTypeDiagnostic: DM2PR0501MB1309: X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB1309; 25:YY0+gQ7bpBXuFRmcrzFmyNo4iYymnJ9QZ/bjAxSp6z/U59wxUDtVO6/H56R3NTkUG49shWk/fYuIXtvF3UgHrPUWU8Q1bWNkjP4eyxHaA5J2Qi/SxubjKi/Ni4mcWr/Q/ehptW+h0oZoSlSHiz+FDYA7f1lBHmErGEthQI63u2tVOwXnhY1GUiI/O2+Zo1Wln+DJ5wx3E3Sm8nPNX5X2BV01lu3csC5t3RDtT6eRP32YI7tmWawj4MuTUWgXd1o438URQbzFPboy3SK2ySqthaNhIjwEZ177TGwgpBXudg2rPaoCR9r5AuFSU9BiOiScs5520xer6HBqv3+SGDE/goosuPNIAT3GPxltHcxaFiBo0mXf/gzw0qIwkziZtZTWQ3U/WSGToc0KwE+MnVCekcemK21v0rAs1oMLehwzvXAkBPaCMo/UOGY0MfHnyd1IaNCFDPwIw31SDothTIfZn/Kv7E03b9BjKlPgdPjln/acYpPVaWpXCKUXa8WEmz3+5RIy9oFWM7hkJM89x5auBsXwIP9CSpPmUlOFpv8bqts4g8+pX+UB4bQueJmPsXVZzfDnTNGVCzdb6G7wl5yVRyuEGIkdZEAP6RluNVCG9LLltrI7m1iCTaiBpWAwIr3j561ZQxrA0hqbHvRz/JH3ZHk4ecrG7G1+ly8mc/TMVOjE7mUE5jnVsfvhdcBy3FubeSvCR2FETf4xvD+Y72B1u3os09oP5qaCfz30d4Vy4uvWqeh3d2AM9k6HA/kI8s0GDze6t2YoZo1Ri+g4ambT1J3ZRsCkT7ZvemlrQ0Ucm0B6P1r5fluPugKTdHgVHBFEKZ2b8b37WFtcGPHd7yF7guDr4VeT6vab8AYheXjDiBugwG2FOyyxpQp6/fvbFkQEOYzjlmJZAbCGsR9EiAuQBmuxqaBL1uKfNDi3t7y0T5Q= X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB1309; 31:LjR8KaFAJ6l3MH1tMTZ9OyHL8QCo9LbAIFX4iVcwnZ+yrWsRJIHSCsiErDrxYvOt3Ov17SnEc1D1DL3AFNmzgiGSWlDdA4U/9gnICqfQv1FGuak2JR8gWGnv8REoB/WJqYM5N7JmEmNZGS+KYAc+FfKzjP8KU4eQYkaQ5/li056uMcroAMlMmoKDhDwovGLAdW3ErESNJw0gp+T8F96uftBgOy118JiuijzWPPa4NqNdLXgwEmQo35Pa9hQO3SR72wrDa49A88ypp6DRC9YPPJWCdPVfY0dfBFVsS6yoWq/Digjg9UKpA+P0lJO8dTR1F97NPSWzmJ+TUnd4cJUcooib30TRFtetrX3n/kjsnSiSNQYeRC/ROduvHh2LvU8bKDoJRhNBPyUDD9amygSfcP95WWVNJHxhpI9wysVxi3wa7fqaAqzmW9FOrMIXbmKVU0URLVD/BM3uez6zDZAQf5nQ2CF+uszypg5hUf4lIuBypBxNwFLyqAkbXqbWHk4h+5PeEHvKbxb261cuHV3CQJeLb5wO2up/P4ZZ8DICFi4pwx6jooilw2BT2uf+BBt+Qmp6e9MyR/bx5/PB1xOcr0/shDgHP+Zs2tveZqDgsgc1PR7k8YHJanUzE2nG3AwuFwh7GahuJ6IEhkECjue0LAgKi/k3f3fjqI3a+cvtL2v+4V1MgQBgpeI6iiI6kyNe X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB1309; 20:v6R8c9Wx3oslHNdbaRYsFuQqtKgewJzzgw5x964ubhlzH8vpxXZjFVMjCcM2c0VdjuTqHe+MZL+O/i4tWwc0Y6k7HZdb12RoHj4CgtwLGzqY8i5LhNv+B4XpGZ9zQNjx5AYAg0BZFZ1Vt6uaEFamOfCNv3cGQ1s8/9TohdOzzG9aVGEKQQloT70uvK9sVRErPJasRldAni3qN0jTOb1Z/CRHucXOIqh4g91rJPcsvMZ0CVC91go5RZ1+re8+fYq7wskoMJaMAjm4ReORGJPcm5zhnsg1NWbrhQTQLgsNvATSCWMaJjsOW0SrF5oW/7UK+BlLPeLdD4ucK8FhC6PBw22LomUKXmFr90u8VxSIqqvFgpY6XrQ+fcvmRp1hAQJqZEOeGgk/kdX17/8HDrZCyyaYR76hvnwmpsVH3F1QPhK6aUR4U1YNjNeHwxK13LWFWG1xZfev0AtMEsBjoWyKYg0TLuXRuGonDjncbhE95UpVXPuUqaYJJdjBtWtr0OXO X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(100405760836317); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(13018025)(8121501046)(5005006)(13016025)(10201501046)(100000703101)(100105400095)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123558100)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0501MB1309; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0501MB1309; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR0501MB1309; 4:+kWpD5wawuHXE6OLMFJQqW8X3/5sXYLLyBss6Cy1?= =?us-ascii?Q?1Y/kg8bZnbkbR6FE0eXR+6vRaFhccMpYH9z6By2OFeYv+Wqu/6gmroahQqIn?= =?us-ascii?Q?zIARt7kaUUsMFf+g+S+n6f78uIu6RgAYkptbfr403hHx2ctI3onuC1IlQ158?= =?us-ascii?Q?+5oc+ue1j8g0bJZ0nOPKZ/Ko8pE0Rp3AdrqoSENJJmcDaZRKM0+NmEM+eb9F?= =?us-ascii?Q?5xuCAyKgPjM2ubFk06l9wcwifMH+iSId4bgMAmZOItA3bIKB5/4dUOekqPd3?= =?us-ascii?Q?SR/RqPFiUaZupw4aEWFtrrl5nE/wsIl0802ZnCIw99JOsmkIyFXzpoft8VJx?= =?us-ascii?Q?SWx6h/aF7MeFneVckseRqQ3NYS1pEzRepTf1zYa4CXKL/Z0XjVfecFAbDngN?= =?us-ascii?Q?sFyCw2xsKmWRDnN8nsYpVIqj22It6P4EtFQuAsEQNKp4zGyFniV5xi+MMhjp?= =?us-ascii?Q?VdqgKJnepCWy6i3F48B8Zbsnw3jVambph2LiHnOiATzBtC9EieN6nYdPqivB?= =?us-ascii?Q?2Dexs63FXSrSe2ciULrTpxL9ezIPOsDWoYm25YqSIHpEK0AOdBcoX49xyS/I?= =?us-ascii?Q?1Hoqztsjz+yuaG0whov3htBWvqFzRtXj0M0/Rkk5gI7QSJTYs8i22+cA1Csv?= =?us-ascii?Q?wj6KvFWyXM2OnGfwu/ppe78UdevP2Oq3jn4yFJHuD8lHx41ieqcKqvbvW4Ct?= =?us-ascii?Q?PGrlT5G9ly3V1QymoNwjUo7kJVTOoXmKw67G1y3eVq7FFnXrw1TcGAvswWQB?= =?us-ascii?Q?1JyKYDHZPIZxDXOCWSO+XNVgWQvh/j2tUvEkE5SKs4z1NrB3RlqvmDSkuS1U?= =?us-ascii?Q?GeiRaQzJFNj5kfeGAo3YhXHVauxEixLKBh/XjQGnyaL8ZRuYCpqk/cSkvSpH?= =?us-ascii?Q?fFPT+Nmh2s2u3cB7+wF6WbJbDFWcH4QcPAUvs63AVK4tWjOYx8rgIPxa/94f?= =?us-ascii?Q?v+LlMjRjhQj1DEeU1zyVpzmggGBMQhhcv9fdVhBdZv/UwkX4Jc0W8gbk5gcq?= =?us-ascii?Q?t+bdKCALauvjqdokvcIDUqr7omaSgJD8scEzeGBwDc/7wO/nG78ZHNFFxu2w?= =?us-ascii?Q?Idx88ZeAjA6Wi38Ku4UdSMha2ViIIdcOjTdWoMw1Bd3wvCEWpi6/Pzrz94j4?= =?us-ascii?Q?X2hW3aIi66UMz0WqNSaTxomTZd1YRNC/BGufYVftRpsvpPkRAkurI+5WUpHi?= =?us-ascii?Q?Z0u8cUMBfGhXYDrpNnbdFwTNtw7sIeBHq5ycVF7VzVJzSOlfatxM+U0PUWeM?= =?us-ascii?Q?oyPJ6zW7OKjYr0mwxBp6ybPzzcbprd5cTWWAelNK?= X-Forefront-PRVS: 0345CFD558 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR0501MB1309; 23:PwsmVqBjwIYTZlif2+PD+vz7j/5WKoky7eRDHjX?= =?us-ascii?Q?8STG1To21owT2EzAOQpPSCNQK1Zm95ht8YgxamGjg0nxfT9PCQKZw3kOjTA3?= =?us-ascii?Q?mJ0lumvKOVkMC201RukysRvnwW0efVQdoJCP/M6pDyNhZxn3kNY900TDeJ+8?= =?us-ascii?Q?r/fxvyr3Pg6bZaN5dMm0J9UxBvJHN5jxe9cK0e2BMujBMI4r9UCg/VDYB6LW?= =?us-ascii?Q?8ZDS8yqkx9PdTFr6yoa+pI/IDXdnBu8DME+EvIDC4hpny+fJ3sH/CY8GUCnv?= =?us-ascii?Q?EJSTPCqmtWkSUdVRJEc370MwRhEkGN4dl2L7wz38IgJBRUQIcMvJgTCGW0oj?= =?us-ascii?Q?UIiXY/3MHn36+KKjughu5mVKxgZWT/xsL5stETcIeE0cJO05ja8es0ya4FxR?= =?us-ascii?Q?nt1mcNd/qi7HlSM/HBJK/0016dZKdWFvjC7fAGBKtdZGdLjZ9sDpsHn2vOT2?= =?us-ascii?Q?G66JQQY/k80UtFWQwFpzQNuufqLYQVzgt+G1mJcVhPPxRnBdUYqAS+5la0vc?= =?us-ascii?Q?l6PHpX5JxDTEnrVq2+/WTzN4moULzDsfMSCidd0E3o2PqeIEwRj982GYSBqV?= =?us-ascii?Q?l/EH0VDRtRH7vzXTMgrfFFOZMo5L5lRSMTMdNv+P4ADTRcnlSaPsktlbtmju?= =?us-ascii?Q?7mRCbxmtyLo0hPgAPU3eVcTOojA60/5fqOHFq0AS3safRHBOv0aA08A/q5qf?= =?us-ascii?Q?JbGTGFN13ssHTvKC7XLDkeMc6FEh8W3GNPyU6qfIsvBSW73XbBOJ7/eXEEim?= =?us-ascii?Q?BdjVjLIIRJ5mvEVkm80qsnuxCXtnnxZu8dwxoT0sAZG22JZSTZsm3vohEtS7?= =?us-ascii?Q?nJOndJ44xt0y/lhadMLahGz+1XR8BqZ9a6ld71GyFctDacFVHL+0JHyFOzsy?= =?us-ascii?Q?uv+CqGlChyLk5PIxLt4fH8os8HC9aJQqpMrRhczCAS28RpEZDC41Qs0492vV?= =?us-ascii?Q?oabYPeCO+vdcVqMDLdcS/b95a1fWhups9j1u6i3puJrCF+8HsplhB4IpC0jA?= =?us-ascii?Q?GZkd7yPmePmHWxe4OkNRdFvPirxnHzhu6Gv+94kCw07ZP5oWvpKSlagxSn25?= =?us-ascii?Q?pljuV2H1VtH/gi0XEoa9gTwmrSSOopUFk2prZNC6KQhyecxF/ntpQeSqtFbR?= =?us-ascii?Q?3Fq6ceMdDaYvb+NtsUSMXFF6STs3jY/Wp6HULVVMPFI5340ueIrKzBf6atlt?= =?us-ascii?Q?1aoId9BJTEa55uZy16jq1VrlHfxXHGEXDfqpo?= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR0501MB1309; 6:WWI+u6q6pAa2wyQSvLEh9kWMiRt2ik44dyaweJSU?= =?us-ascii?Q?rkjIww3fibTJfAEgJP/5UzfbPPKA6kXHXBJnJU/9Jdhd4+ELL30fQfWolIvD?= =?us-ascii?Q?SIesH5JpXto9t8/G1zpyyVp4EziEZNZ7gsQUZIpIuStoidRkXO0ZnQBfaxN9?= =?us-ascii?Q?K3flfk/ngLPisfK1CYf6vaVfUmeVO92TBON5KdF4N+PJ4I1/u0mQSlWBydOg?= =?us-ascii?Q?GK6guhsAwzWFws5pNNjRP3d60eoWoZbl2aHvLb4+iXrobss7PCn4iw0XEWlC?= =?us-ascii?Q?JLNDm89hABBb9SjI5YfKzs1vCVHEBqtSFcVKZ/L/00fhRTDQV5dx9yfC3PLf?= =?us-ascii?Q?R8fidYn4ngPgul6aItAYA86M2oOGJ4HpCc5b/Xb74Pqz+AYJlhWS9CNSbtNE?= =?us-ascii?Q?A3e/AEZPnsTDs/slNQWNeLmkhbT+4EETAv1ksl9JBB/WltTjuKdfFwZH86kD?= =?us-ascii?Q?R5rGP5PyFxK7jv9k/loXsQfZz8crKNC+7XC51O/8j+39I79CzdVbd/V+zSvm?= =?us-ascii?Q?++b0yqC4iWchnOyJnX0LcNmbQTI5N+jIfll6VBhq4d+phQnXEmvF1MtlfaBK?= =?us-ascii?Q?DUwZKb7caZ7jlwxJuLnndHZdXJJOa2xlxwbN/StruMEKDBEQtagT2KSMLpqf?= =?us-ascii?Q?gYHQE9VKhRD6+2nWS5kiFfPFzLZmVWZq8Q/0ogk+rr3z6qmrgzNaRJJNlz5+?= =?us-ascii?Q?SkRxep2lHyky4SRBnXH+IgJsjBTnxglfMFwpt8p8MbcL5EpLu71EB/UW1LEn?= =?us-ascii?Q?8kB4VAx6cQmXmSsd/BjjtfGOQe/UiZbzhCDWmAMjXYlCJRtfOSdVliu/GjOF?= =?us-ascii?Q?xWW+fhpGt8qRObZ4Y+EoyJ6+OX9dqnn7gvD0/2lS4E+qPQAd3xj5Mp8wRwnS?= =?us-ascii?Q?eGmXYLez6fS0lhGyQxnWZGK12jQrjfcrb0CscU15V/h7oKxc21oVQsw7QztI?= =?us-ascii?Q?pXDdlazAZp19AfC1hTkxNp+nuadPwlj9HeeSKwJhXegNB3QPrL+1eWTKyxAX?= =?us-ascii?Q?floNnn6KOODY3NAL+7saHBet?= X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB1309; 5:cNt9aSQYllaYUsS7ulUHywFWzHPfdlBkzKvY0YuGnxqkfEGVmcZQinFfgGtRFABKZZOS2samXU6O6EEtfOQn0hx4biEAEKAwvIwXIJ7yN6tQucFpJ9eLc4ioIMB7CVTrf/JBwvmf7DfNwP5U9GeyPG2nLyCLYFM7td1LSJIY6SlW55/kggGoc3QvcVQy+7DwmOBTb002WOXB2mVCDvuUkfxV7oypNIUf1vn3XFb3ZVrmQn2DNN1yn7kC8mf5v++I3HQGpjcRHe0+tm/oyXZFc50jbAPfAiDXdczrlcw1XZUTNNWhCAqx388xCXi1GnJU1h3apgdcn65AVSceOJ4fvgb0dq7xi7Sld7W5KPz+Qti6DPBNvU25vj82mkXiYL8B3Q+fA9vqRB5I59h9LrN0KVqY2iflzshQQGHwqLA1H3czE1O/XcLk66jvdCDeW5ZcT7zGKAfN+01U4q0Saul+HY88jlGqCXOuo5npzsStS6GkillrvNeP6Gt1xipVgHNT; 24:Rp8IVUsFQhvaFiLKowhaX5aDJloZcfhM/hUkS4fF/OVmJKrJ5oCHQUu8hlkBdOpiY7/z9pkPxU9OLJBP+fw/kJVqOwjV4JWXCzhZalQhXl0= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB1309; 7:2tK6xT87LS3BhrNRriv4gFExmmYahPDsGM59rE2qUq6VeBRfGSNVHutpxwg6MH2FblwzHN9MxWcsEz7G16byDnJAU0Kn2SOS/3OiLx5i3bev+ly2BMHdbfiVmm7CauEQJfbhA/zQwQAKrrsmN5h10/sUvVaJq0mZBwmEUBSxs7gYhhYW1Ywb9oohm83uA+64C3sgp6c17i8PWxvtudnY8HdBk6aDRA+F4OQRT41FNm1seKUjPkmE3FhBA00i1mm8V+iakewnItTrb0tToHc/7zgPP8tmiowHN/hn6SHL6kG1+S1lj3v2tgcF1D5qORoGCEC7zzFbO+v7eLmBwr4EgPqhGpv6qBrIofaIQXs3O1Mz3/oatZz7/uZvFXRqAgi8V6fr/P502yeFnehhWS0BTvYv0Z1Yp8582rzRwpQmJUe91KyZp6YHUjYZqI/E4cGd2ODsaAmXS9c2Qi4URzmWKF9kt6jdmM73PT2cPuatMibelJXgtVGSk5HUabTdDv4+wfNHN+uNbYVesZQt4CbKzae/jLANNtXf/IEJsFnihFxUTi3TDSN1o5dHjUVI4YScowSrARG5jxqsB1T5cCa7EDcUKEPNGXc/uwFRhz4j/EoWerPPynWOJ72+7tf8UlR6QH4PHteiKMzwVv3feQeZz+xGPTJ8cZ+cTMrjPRt1FbSQWekfJCJ2inH+h45lPSG8X9Ce5HNBWMmt5X5+AfDojpFvY4ALynN7FsqYexWBdKZXi91lNSc39DAawT1WhldjcpPRWjA+863h5R2IGmMF8nWQvEqSKx/oGiRq0yOfWJ4= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jun 2017 18:20:11.2675 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.15]; Helo=[P-EMFE01C-SAC.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0501MB1309 Archived-At: Subject: [Curdle] RFC 4253 possible errata X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 18:20:36 -0000 Hi Folks, While working with the IETF AD Eric Rescorla doing the AD review of draft-ietf-curdle-ssh-modp-dh-sha2, the topic came up of validation of the Diffie-Hellman public key on both client and server (peers). The RFC 4253 Section 8 writes: |8. Diffie-Hellman Key Exchange | | The Diffie-Hellman (DH) key exchange provides a shared secret that | cannot be determined by either party alone. The key exchange is | combined with a signature with the host key to provide host | authentication. This key exchange method provides explicit server | authentication as defined in Section 7. | | The following steps are used to exchange a key. In this, C is the | client; S is the server; p is a large safe prime; g is a generator | for a subgroup of GF(p); q is the order of the subgroup; V_S is S's | identification string; V_C is C's identification string; K_S is S's | public host key; I_C is C's SSH_MSG_KEXINIT message and I_S is S's | SSH_MSG_KEXINIT message that have been exchanged before this part | begins. | | 1. C generates a random number x (1 < x < q) and computes | e = g^x mod p. C sends e to S. | ...elided... | Values of 'e' or 'f' that are not in the range [1, p-1] MUST NOT be | sent or accepted by either side. If this condition is violated, the | key exchange fails. ...elided... The z in range [1, p-1] notation, specifies a closed interval which includes the end points which is equivant to 1 <= z <= p-1. The (1, p-1) notation specifies an open interval which excludes the endpoints 1 < z < p-2. Eric noted that https://tools.ietf.org/rfcmarkup?rfc=7919#section-5.1 uses open endpoints. Eric suggested that my draft should include text that is similar to the ext in the RFC 7919 to correct this errata. Before I make such a change, I wish understand if what folks have been using for the test in their implementations and get a consensus on such a change. Thank you, -- Mark From nobody Wed Jun 21 11:41:44 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F0EF129480 for ; Wed, 21 Jun 2017 11:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.334 X-Spam-Level: X-Spam-Status: No, score=-1.334 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=timeheart.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2674d3UBlMH for ; Wed, 21 Jun 2017 11:41:39 -0700 (PDT) Received: from mail-pf0-x243.google.com (mail-pf0-x243.google.com [IPv6:2607:f8b0:400e:c00::243]) (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 065ED12946C for ; Wed, 21 Jun 2017 11:41:39 -0700 (PDT) Received: by mail-pf0-x243.google.com with SMTP id y7so32327010pfd.3 for ; Wed, 21 Jun 2017 11:41:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=timeheart.net; s=mail; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IVpCwhSnSYqQF32uusF9P6hLWPfnNGRVRqY8+d3woDw=; b=d0tuSMGHKecCiQrZr5Kr4kt3bX7FC4tJGOHiHvRPz5M0OBwsTD4t08YWCUhM6t07Vd kBUKqafBnWL4OAXYFXBAhl5POgw52zAy7pqT8xy9VRDqQ+M0N9hEYqGxCwe+HdsfsERj PJ0EBLGA4RWaEZ8ks1rj4Vm1QDw14tt+0zwpw= 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=IVpCwhSnSYqQF32uusF9P6hLWPfnNGRVRqY8+d3woDw=; b=ZVgScOM8//pSFCLMMW0sP4qtGRPFqfvjfJ7bVWmUWmFxeJb0mavAFxiJw33bodwbdY y7qCNsXNXAbC5fdxdt1cajLcR8/OO305CMhQ/+PbaB5Jmob6R9BGrgeAirUiy1iiYZVe Uj5PPyLLN44zWGhqpcnBdNB1KsatsmoHF85tB99PM087PU6mIWDJmjMdiDBv1WocqyXx zlZ11qTGwDqHNLLbWohRGVPpuQ+zB3QngUTSxbEONcKHnID5QUJH97e/NNPXS6YwPATh Q61aV3ydYHhsMnowxDgPmgQdT2IknKkt2gAqiMz+9oNnXBvLDlzpJbz2MtP7wMK/ln47 oDmA== X-Gm-Message-State: AKS2vOzwCNcAmCvSL7kcIWXEe1VxTqCFtRPXjrvNucWYeARFWy8s5jpD dLZ6FrWQB5iUfFDqjf2fboKo X-Received: by 10.84.224.133 with SMTP id s5mr15138413plj.93.1498070498580; Wed, 21 Jun 2017 11:41:38 -0700 (PDT) Received: from ronfred.symc.symantec.com ([155.64.23.4]) by smtp.gmail.com with ESMTPSA id d88sm37504364pfk.133.2017.06.21.11.41.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Jun 2017 11:41:37 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ron Frederick In-Reply-To: <80212.1498069205@eng-mail01.juniper.net> Date: Wed, 21 Jun 2017 11:41:35 -0700 Cc: Curdle WG , SSH WG , Eric Rescorla Content-Transfer-Encoding: quoted-printable Message-Id: <50A8EE09-4FB3-4272-956E-E280F90E01A9@timeheart.net> References: <80212.1498069205@eng-mail01.juniper.net> To: "Mark D. Baushke" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] RFC 4253 possible errata X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 18:41:42 -0000 Hi Mark, On Jun 21, 2017, at 11:20 AM, Mark D. Baushke wrote: > While working with the IETF AD Eric Rescorla doing the = AD > review of draft-ietf-curdle-ssh-modp-dh-sha2, the topic came up of > validation of the Diffie-Hellman public key on both client and server > (peers). >=20 > The RFC 4253 Section 8 writes: >=20 > |8. Diffie-Hellman Key Exchange > | > | The Diffie-Hellman (DH) key exchange provides a shared secret that > | cannot be determined by either party alone. The key exchange is > | combined with a signature with the host key to provide host > | authentication. This key exchange method provides explicit server > | authentication as defined in Section 7. > | > | The following steps are used to exchange a key. In this, C is the > | client; S is the server; p is a large safe prime; g is a generator > | for a subgroup of GF(p); q is the order of the subgroup; V_S is = S's > | identification string; V_C is C's identification string; K_S is = S's > | public host key; I_C is C's SSH_MSG_KEXINIT message and I_S is S's > | SSH_MSG_KEXINIT message that have been exchanged before this part > | begins. > | > | 1. C generates a random number x (1 < x < q) and computes > | e =3D g^x mod p. C sends e to S. > | > ...elided... >=20 > | Values of 'e' or 'f' that are not in the range [1, p-1] MUST NOT = be > | sent or accepted by either side. If this condition is violated, = the > | key exchange fails. >=20 > ...elided... >=20 > The z in range [1, p-1] notation, specifies a closed interval which > includes the end points which is equivant to 1 <=3D z <=3D p-1. The = (1, p-1) > notation specifies an open interval which excludes the endpoints 1 < z = < > p-2. [Ron] I don=E2=80=99t understand the =E2=80=9Cp-2=E2=80=9D here. Is that = a typo? Also, if you want to convert from the closed range [1, p-1], = shouldn=E2=80=99t that to be to an open range of (0, p), which would = correspond to =E2=80=9C0 < z < p=E2=80=9D? > Eric noted that https://tools.ietf.org/rfcmarkup?rfc=3D7919#section-5.1 > uses open endpoints. >=20 > Eric suggested that my draft should include text that is similar to = the > ext in the RFC 7919 to correct this errata. [Ron] I see RFC 7919 refers to a closed range [2, p-2]. This would be a = change from what is allowed by RFC 4253 today. > Before I make such a change, I wish understand if what folks have been > using for the test in their implementations and get a consensus on = such > a change. [Ron] In asyncssh, the test I=E2=80=99m doing on e & f is =E2=80=9C1 <=3D = e < p=E2=80=9D and =E2=80=9C1 <=3D f < p", which is essentially the = half-open range of [1, p) that is equivalent to the closed range [1, = p-1] listed in RFC 4253. --=20 Ron Frederick ronf@timeheart.net From nobody Wed Jun 21 12:32:08 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3527A129484 for ; Wed, 21 Jun 2017 12:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JdpMWqydYGq7 for ; Wed, 21 Jun 2017 12:32:04 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0100.outbound.protection.outlook.com [104.47.34.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74FF3128CDB for ; Wed, 21 Jun 2017 12:32:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GUNGCclqJKs+nZJkTuNlT90U9UEwGs3hB95W/icRF2M=; b=d5rpCkN7CksJZt9mI+ys4unZH2rtmJXbqnhKcQI7c4p7/q2BoaURHVxkjV8WuLWKT5tvAzf1EkN1aLEaLTEy1Ft847nPcqj50gt2/E7L8/y4VIkJrsyLh8pvG8LrRCDBz8wsROtCc5pC17yZTDV7JO2Pe9C7BcngSYA/VrukcrM= Received: from DM5PR05CA0007.namprd05.prod.outlook.com (10.173.226.17) by BN3PR0501MB1300.namprd05.prod.outlook.com (10.160.183.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.6; Wed, 21 Jun 2017 19:32:03 +0000 Received: from DM3NAM05FT034.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e51::206) by DM5PR05CA0007.outlook.office365.com (2603:10b6:3:d4::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.6 via Frontend Transport; Wed, 21 Jun 2017 19:32:03 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.15) smtp.mailfrom=juniper.net; NetBSD.org; dkim=none (message not signed) header.d=none;NetBSD.org; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.15 as permitted sender) Received: from P-EMFE01C-SAC.jnpr.net (66.129.239.15) by DM3NAM05FT034.mail.protection.outlook.com (10.152.98.146) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1157.20 via Frontend Transport; Wed, 21 Jun 2017 19:32:02 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by P-EMFE01C-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 21 Jun 2017 12:32:02 -0700 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v5LJW1Ff011097; Wed, 21 Jun 2017 12:32:01 -0700 (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id D504011446; Wed, 21 Jun 2017 12:32:00 -0700 (PDT) To: Ron Frederick CC: Curdle WG , SSH WG , Eric Rescorla In-Reply-To: <50A8EE09-4FB3-4272-956E-E280F90E01A9@timeheart.net> References: <80212.1498069205@eng-mail01.juniper.net> <50A8EE09-4FB3-4272-956E-E280F90E01A9@timeheart.net> Comments: In-reply-to: Ron Frederick message dated "Wed, 21 Jun 2017 11:41:35 -0700." From: "Mark D. Baushke" X-Phone: +1 408 745-2952 (Office) X-Mailer: MH-E 8.6; nmh 1.2; GNU Emacs 24.3.1 X-Face: #8D_6URD2G%vC.hzU Sender: X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.15; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39400400002)(39860400002)(39450400003)(39850400002)(2980300002)(199003)(377454003)(189002)(24454002)(9170700003)(117636001)(23676002)(106466001)(966005)(478600001)(356003)(4326008)(2810700001)(50466002)(6306002)(55016002)(54906002)(305945005)(53546010)(76506005)(110136004)(86362001)(53936002)(47776003)(6246003)(53416004)(189998001)(38730400002)(8746002)(8936002)(105596002)(2950100002)(7846003)(6916009)(7126002)(8676002)(76176999)(2906002)(50226002)(50986999)(6266002)(81166006)(6392003)(7116003)(7696004)(5660300001)(77096006)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1300; H:P-EMFE01C-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DM3NAM05FT034; 1:1ZFPPIAv+l7UKVhz1GJyOGPWPlbKMGyKOU+YoTe+Sr+y6ZqsYcW5CyLqjffW1luvYXNhXgR1SBzSROML9sC1VdHrhprF3dA/LyAOiA41FMy3nTsuHjI0L+ymLrz8iSe6Worg3UcZJUmMOAeR5J1wF9zcdVcN9f5mH4Jz73k3vwOIMQDmVlxuKlnoqAKhFHdqtKIvu2GTkJixNNZpOYCqi8Mg0mltBb29Vfv8o/6Mfw3FaylFbkdsYljR2spdru4puFPm/fsgKkKySoNaY4Za0q4zk+HxwB+fCwRStnOXY1Uhh8v3Z98aO7nYU1SbFsBpz1s1pfi61dhP+NbTi/67T9LVxSBdNEPrLa8p3/bxzJijW7rA4ouMlxT+LhyfWeBv0iMaw6D5EXnziB9RbAF1Q22u2TaQrGwf970iDgSjF4RRtuyU4DcCKVWaEFj6ZHRhyqLkVFRwbXsD6uGoebgytGs4782IybfKq5Oz39EpYXTHkOHSXbJrHZvTyaHUYxcLDrZk6GPYer6aIsu0pb8GI2c4kvK2g61BlDgvUZhLKZAs8D6H0agkG5/zujgwX0hgoxlmfQIZeVSipeQ7KX/qSwEVIFVoy59XWHFDQj0RZNFXL2dZT+kA04ZqTuc2dK6ILdb7ehhzB2VACoj/qFKifzcRFZze2X8tNPTiYTamRpz9/3Btm/PygAUJIWNNG/aeNLNZCuoR3spl88SFUpS+tMNdvUeHHVoa5m4YpMcIFH9kCRzqWZsEXqWUX2yGOBBJrAzOLTk6YTFDyojw12ueAHc7F5weklDcsC9T6f1spbSHaDJN5CDnphrmFlQWaw9F3nCMbYyCWEfYrll/1V0lTJ6KND+9GBLlvGkgdrL9JtgD2N/1lSTor5yOl0tOhNFj X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 9b0c3967-4a53-474f-daf3-08d4b8dc3196 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500055)(300135000095)(300000501055)(300135300095)(22001)(300000502055)(300135100095)(2017030254075)(300000503055)(300135400095)(201703131423075)(201703031133081)(201702281549075)(300000504055)(300135200095)(300000505055)(300135600095)(300000506048)(300135500095); SRVR:BN3PR0501MB1300; X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1300; 3:Gpc0Bj4QEDCZLteUlM+ZNjlVnYIQNDDPE8Bmbw2SU8Z+lHLWzim8T8i15Eb+b40o3FpM5vV1VgbBVo2++sue7V7Qc0iWrbtqmg3DYPShlzwRWgVCJsFxyhCXSfHCKpejSAoAAvs1u8EI46v2b8o4XNAcdfutMnPsll4HkIQU8ycRqf44fJX0WZ36aV/oLVvDt3xdXralHoFVFi371/MokQjEZyoWesnk/Lrwx2+Nx+1HRy87iVjKovwbVJP2g8Kc+KV4OmLJRr88+KkKr29KAOXgh6tDYQErdtEeEnyalYfXWjhxu9JzqueqxYiRYOhgNZ9I/UD17GsGrfIPrkdYRe5IokvJgsKujv7EShNwLwKgcHQKRiftr6OSK9UXmJ8XydL5ojDt/XpYAgRwxLSeleO8hyp7XGjUwffYAbTQrU2Rwnw0rJUgRZbbUEXfO6Xp0+rg9V7ciplaPUEIl3xH0QN2nS673Sz3YNweurAYbN/+Q5L4qzr33+m+uI2URKzduhVlFlGCrxVK3RBD0wELQ2p/41XdwmtITwNDzcvesPOl6HsjlnZml/85WUu3orgS7jDkrSo2iavRAcKlm8mloTGrw+ZM7OCatft5uub03IwdhwBWuGUBoI7pae0JNI2pKgrV4xb/hwT/rM4Ysx6sRK6IcmMGe7y72zOlJBBkUEBanbp7RSDJR+yxjfY7i7Oy7Cc11m31haehUClpgcKFCPYlJ6qXhNs6JLRsiD6aIJsqt72S9Y+U9NnhBmCH0FWM9ysefgCiAfo5qcXLKhJXc1ZWOMXrtU1zS69W5NfOCjOeL8WpcoO8O2eXI+VzKWVTob9AHz6Dv67QFORE2wxgAQ6qFPc14KZOb8+c5xBmq3fPX/YAfXTp9S70PTUPGkWGT8dadFAl4uL8jMNSkqIewA== X-MS-TrafficTypeDiagnostic: BN3PR0501MB1300: X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1300; 25:c+CzhXRP7brWF4ODQNKfF1UiYIH1OpkCDW6oRlKBUYmEXaH+OPSiykxFIB7g/CkYNPsGjo//78VO3uA1U+SwvQtlNn/7mUBOzlfacyXprG0+CgWWZtLKfIffPLgvzy3vaIAuAqq1M+06lBINsFoW4fKT/K6Wt2+SplT2GD7sd5LJ9n7+XxU8DmqXMYF3UuMz9FPqYXgWlXWYokOBZmcIMLufOw8sbTptXTFRN8Ja1ty9zl2dGrANOELSzkgN4+HIQRQSnAFmQyfJ6Eaade2PGSGTR5jty796OAtVA0xcOIBAtA2FHDUYOIgC5EGdxbJu5c7TnPzytO++VkVk7TPMP0Qchr65EclxbS2c7nVjRgaQG60AcePH8mDH3Cu1f3Uh3OAC4KFeNbHhL+4Onw7cXShmUP/oHNGEN6DFqU4cwZOJcOjUt6CzR4K2sOf0VUJlmY0jYv40naMy2aFY++PkSxdJSYHs9l898EyXlNiNSCD8aFfxveTSfqXBIWryUNXwSDqtVrjZdFId5pAlB8aIYioH60arYPrO6TmkznPz924Ii1uceI2dLAVh3evVm/Tn5R1KEme5Wf+SapuBNJ50mO2M6cxoEMRQK56aEfUEjDmfzK5MpdZFvfi8Ar3EnOlnUxTxISpuNo0CxXljEsDq50G6rpTpznVQHqIx5vki1gfgY2ADfr9nwgVCN8/eHtBuJuLqrzMWkVAI+U/1surbVWdfEiYzVlFoPXa3ZGCECI4ZEmeoHt/ctvMhYlHUNW4AGVw2CGADxUkmbN1VeGyAxJP9t5C14YStabrFoNLEPwBUPh3nNJHbGOJzB3NIEVqp27A5FH1VhgAL0u+Vhi7R1gcF84Y/hTRtTQipt0QH2bchSOZl2M5Smm797jgpwNqxdMj2ch5ak1XsLgO0RcUjyVAkmsi2c/x75C0sy7FbTiI= X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1300; 31:8qx04RMPyGGWePGpINRAmI16ps12pPvnedSzu6RFmt4oNAKSIZdN+RCXUXbTIGVzq+NekgBur+YUbYi5Zum1GYxTyIXCxapVc7CnP4yg0nXw85LVsGxNNX95zj03xUK6HfyAIBErFLNGE2WUgZ4cnv/rBJ0oP4eGY11kRTcSla7OKPpsOmbrGnQcU34R1N2fEU65gRPielU1TSqcymLDA0p5EFdEE7jJI/i0SomYGfy7rfKVzoNp1uEUC5PM1V48yIOLNMnfYXg0XX/gu1A1AY9NmB8U4TmW4uwwqixitDO5NYbbgLaxBUQWM1fm9hB771w/sNGf+BfpGLGcWvjpJURrDYARQS1SNdBQJv64XESQ+L8nICSadevhlwfbTBcIfA8HDl4EMqHY98xJKIalJbLnqK2yI9w3aIF7N7l6h3pR8u2evmRPy5/rkXpFcvvXflozQpdRCRapfsIlylXlb9S9pVaK8S8s4DnlwjqkmF03Ar6R0YMnsqCSGcDn67ZR7V/qxj4Eqjp4YtPv909/2m+ouLs1AgevIeZyJVHLSwLxCvIjQzcAIp+S4bYfRgSWFeUHZ5YsJhD85w1DCgHz8a6bqI4Fw3n6BwiwyVrFtcI8AYT1mLVsGvjDviHdaVAtQb5IoEWH+QF7RadUDCqKPEgqKdU3WzGL3Iaj/WjtuaiIxXilVAxoMOiIsOR4kNSCG9jYnM6Aex2vWPT+hpMSlQ== X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1300; 20:MFu/TjbsJjjeZNV4dEGHl6ByicQRGyJDAdV55l9FbmrzH12dQNMYvC8lQ+mDYsvv6aIR8EOQEHPtHzKZwKoHVt/ipk4mWKUx2RrAP0jqM/JXfediuxyq3D2aTVXRKgDetA0QhKr5+a4StWbvcVMSqq610Ts+wFKu6V/cIr0KbC2coP11UQ3empHAfWK15h4aVKgPw6SHtT/R8olIhivFMFgJ1yVHof5TT4ohVQoDtrMdgLSyXppdJ7h/yxLy8CD+MtDHVNUzeQgsLVFokh6yaFB+y9Q5cjAJAPuZh4o0sfyfwwG8m4wxZFD4nhgtrI2/9NDGpRmuZ9EZRrnYIIZRZUrAHtxWhhD9s28wb5tNoD37aW33nj/wqBsTRUabGO1U11PwQLHPZ52y3/wLo2jwnB5XzSBKvyazIf9rt1cjvecpql4JWx2ZUPHLFFHMVoz5uz0z5oaw4lqRn6JrhbMZjiyeweQsDa+K/VTmxQwTzTZc00yMmbMYZVEE7ePB7Jgz X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(138986009662008)(100405760836317); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(13016025)(5005006)(13018025)(3002001)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(6055026)(6041248)(20161123564025)(20161123560025)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0501MB1300; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0501MB1300; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTjNQUjA1MDFNQjEzMDA7NDpSbzUwUkJhN2luamI4aUhiZEtmRTgrZGEr?= =?utf-8?B?TXhyakNweTQvbkFPRDNpdEF0RStTVzRzdU8rZW9LdERtVW9rdlk2NGtEZFhK?= =?utf-8?B?ZVZLbHJnbFV2L2h6blo0SXpGMFFKeWU1MENHKzdHTlJBTXU2VG1yZ2dQM05H?= =?utf-8?B?QUZiNjJGUzhmdVJyaTlpZmplY2ZwcHZCWFEzZURrdmZQMWhpck5pdXhNQUNn?= =?utf-8?B?R0M1UnM3eWhpZG1OYUQzUTRkcjcyb0RJamJKeWxTVkJVdzZKeHJHdDZmbEVy?= =?utf-8?B?MkU3L2MzWEhSdjYwcUhzWmdEdGtNTHBVaWVSallCQ3dIeWJRc2RvNFFORmFO?= =?utf-8?B?RzdXLzZtZFFQdjFHeDlxWDRLUGc3aE9VNzE2Rk50T2xidGFMVytreFJYMjBl?= =?utf-8?B?R1hwYi8zMjdqdjNoc3hqWlJHZUVuMTEzUnYyQmRwLzFHblI0YzZ6OFRwcUlJ?= =?utf-8?B?dktRb2htaGhBN1NMUHJEWmY0elRDYk0yK1VWZ1U3dVBEQVV0RmVHelZ0UWdh?= =?utf-8?B?NWNHWTF4ckl0enpieHhEalBVUVNEVy9PbFlZeFVzMnVKdlJmMVZnV3lvYlAw?= =?utf-8?B?MWNNVUgrMERJYkNmWFpFcUVnOEV3SWpVZldUdDVjb2xUZGxmV3A3alFjZVBw?= =?utf-8?B?QkJxSHluTkR4UjZpdU1BREFUUXFEcldmSzVhVVgya3lHM1o3anhReUFLbXk0?= =?utf-8?B?V2lDeXhqb3BrYVBqbE5sQ28rbmdBd0grb2ZpTGRhbDY5VkRwcU5hekJYUEtP?= =?utf-8?B?N1h4bkpLZ0gvWmxkTm01b2N3YVRXZGFWUG5VazU1dWVmbTBDbWtzVzdNRTRt?= =?utf-8?B?VTFjcGdFYjNoRDA3dEtqS2YwWkZXSkdueUxXTVUrOWVFNWZraGRJR2t0MjNr?= =?utf-8?B?S3N2RSttVHg4UzVQSjN3YU9GdmpVWG1nRnFzTldGRnR1WE82TmF2MlNpNGtF?= =?utf-8?B?Z2Z6YnlONUxzQnRaL1luU3FhUjQxM0p3NWgyZ0U4NXpMR0RSdHliUjFtUy93?= =?utf-8?B?THdBVHJpOWlDM3lXTS9tWmlQaGJvSzFTM1I0OHZJUDZEaFNGK1hPL0JCQXdK?= =?utf-8?B?eHhMd2tjczBZWW5Sc0lXWXZoN1pTbzQrYitsUWhvN0V6Q3czL2piOVpvVTRD?= =?utf-8?B?VkRnYkpnaGZGYSsxbUR5eDJGN2tobEIyL0hGM3pCc1NzQ2RzQmcxdVVhaElX?= =?utf-8?B?RzhmbFl1TUxESEVIRnQ3MFAxK0RZbXZtT1hJcDdDTlQvNzNiQ0REWXR0U3dS?= =?utf-8?B?eVhjb1RaUU5xV2lxNVVOSVV3RXo2K21yY0ozNjV0UW1UcG5kODRsczBYMm5a?= =?utf-8?B?OG9vUFpDSGFPcjlrWmF5SkRkMk9ocUFpMUdrMkVlaWNTcFdRdm10b25KSlB2?= =?utf-8?B?bHEyeWEvVU00c0Z5b0xZL1JwQjFXOTdRV21qeFZDcFNWUG0vVUpaYWR4U3Rm?= =?utf-8?B?SnhsNE11b3RvQzlHemJGamVIYXdHTFBTb1lTZTNPeU01RU9UUEhwOVpWV2x4?= =?utf-8?B?ZEx4eGtuSHA2N2VETHZydTlQREI2ajJGKzRRSE5rRUl6ZWp0UmdpZ2ZwS055?= =?utf-8?B?NERja2RoUEwxbXozMnljZEtzNXFvWUU2QXh4V2ZUanAzbnFnczNaQkpieXYv?= =?utf-8?B?aE9GRitnRFB4ZzI0Zm5QUGZJblR6Z1QrV1gzQUJwQmRHWkM4akxjaGZ0cndT?= =?utf-8?B?cW1sWkR1eEJUZ1RubmJBQ0JyUzNReWI0NXZlNFpGUThlc0tyNk9hREJ0Rjg4?= =?utf-8?Q?jakSO/hWVCgFUL5eHl5TlD2X+Nj5+wSAhgAFhU=3D?= X-Forefront-PRVS: 0345CFD558 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTjNQUjA1MDFNQjEzMDA7MjM6QVVWWU9RdERjWkNvcVJJYWhOWmZnYUl6?= =?utf-8?B?d0ZGSkRBUTV6V0kzTkt4UW9VeVJwNGRxSitQY1IrOVRQa0kzL2x1T0NZaXV1?= =?utf-8?B?VGdiQ3VUUGRMVXhjZkVkcVdQKzZ1cEthOE5KS1FRU2Q2bFJxakt2cmQyVzRw?= =?utf-8?B?N0l4bEpnaUl1UjNNbTBZbnZhdmlubVFlVWUvdEg5N0taM21SNFJ5ZVJxRUda?= =?utf-8?B?Qk5jUUlpeU5wR3VSVzM1eGsrL3FaV0grbDRWWWdrK1k3TXl0eElhdk1VVEIx?= =?utf-8?B?ZE5Jbmg5ZWJ3U3RucVZDR284K3dYWWg0eHRUR0xGWEdqM1QyeDJvYjRFNys3?= =?utf-8?B?ZTZuV1dRUEJlVTVZdDEwcXc1TnB2eG5HMDFZSHkybnZjeXJIT3lEdC9pSVJp?= =?utf-8?B?by85TmNiZWdGakxCVVJxblY1a1EyTUdLbG9wWWg3c2hZbW5kRkNrQk5tREtN?= =?utf-8?B?cTRTZml6SXFtT2NWbWNPV2VJeWZCT1NrdlFENDNZSCtvSk80eTExbVpyZWM1?= =?utf-8?B?NTkvYmQ4SU1vSVh1Zy8vOHAvZmNkckZSL0xxcVl2VVo5cEJqWk95dGllUmFx?= =?utf-8?B?REdMYVFFQkRDQ2F2cXM0WE9IOTZhTW1pY25SbGhPTEVPRU9pU3ByV0JDZ09X?= =?utf-8?B?YVpDOTEwcnoxT3VYemRWOUNHYXIwcldDVzdSdm5udzAxdExscFRWT3RlajBn?= =?utf-8?B?TzZRWTg2emlqd1BNTHRFUjB0YVpFMVhkMXd2K29POU1HMjc4QkFaMDZOUFNl?= =?utf-8?B?VmFCekVnU3djaTErZ0pmRCtIaEpkNDdETDZSSnRNZFhMUkpMRnZqSjJLR2dO?= =?utf-8?B?bUladkFLdFZDTUoyQUs3aldnWElvWER0OUsxdk9mYVhwTjBjeXNvaENNbHcz?= =?utf-8?B?eEhVaFpiTW9GSC9xY2VWSVRFWTBzcmJ2eW5CZHRoNkFVK1czQW01eGF2TmN0?= =?utf-8?B?QkRlWmdUQ3htMzZqUFJkWEt4UTJlZUFsdFJNdThEYUZ0NElyeGJ1cElwYWg0?= =?utf-8?B?SlZoNEtFUnQ0Q1lWK0g2dllnRG52bDJzS0dhUUltVlZ5RVgrNER6V2hrKzhm?= =?utf-8?B?WTArdHdPL2NVM3NWaFAvbENOREJCWEVaLzRXWEsyTm8rTHh6eGkwN1o2Mldt?= =?utf-8?B?bWZPYkZkR2xjdS9NVi9EbTlYS0c4OWprTFJ0QThiK2tVZTBSQ0F6Uy9kQWl3?= =?utf-8?B?SHRsbW9ucDVlaTMzeTA2alVQalM0Sy8rZUQ1cStVU1FXNXBUV0ZHWXZpbFBJ?= =?utf-8?B?VFRlazByS2I3S0lCUE9sS2hPWmFKRmpkYXA0VHNNeSszQXdZcmdOdkNZdUxx?= =?utf-8?B?K3VkaEdnQXV1VWh2Z3pYdlRSYmxHdVhyVG51UnNyZ2FBcTYxemlGTkI4c1RP?= =?utf-8?B?ckVrR212OWxvTmNJU2hQWTJlT0lTUUZGS0g5SzBlaWQ0M0RhTmdDNjB0ZExZ?= =?utf-8?B?blcwZitWRkFWQkdpbHcvUlF1MVV5Ni9rYkp3ZXZTUEUwbWRwdS9LbmpXVUt6?= =?utf-8?B?Nms3d09TWlIvNk1GK0kxS3l0VkZiRG1TTmVHdlNJaXhBN3lmSUR1MVk2Z3FE?= =?utf-8?B?azVXemFyWCtzNUJGT2pQTy81a0JJaWVpbEs0akhIUjNzL0FXWE5JR28vcllz?= =?utf-8?B?L3h1RTJnUXBKcUNSejg3QzB1MVJRODM4K1kxY29YOVJCTUl6OTg5Q0JwNE9U?= =?utf-8?B?a0s1dmRCdy84ZTRudXBTM1VYQnhDTEhBWk9UdTEySFdHUDlTRVAvclpVM2ZM?= =?utf-8?Q?kOZ6HqUZkufIj2lnC0xde6avCp7fITOYPDRkjtQ=3D?= X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTjNQUjA1MDFNQjEzMDA7NjpMK2JvMmJWN3NNcGZVbytsWGZabFljV1l4?= =?utf-8?B?a2hiTExHR053UTd1bGxDU3lhK09keE94Q1Fka2ZONndzcFM0am5SZHg1SVlh?= =?utf-8?B?QU52RUhPY1hpZHN0MTJkQzFEVklkNHErVDBKVTZsb2VyejIwd2luSXdzcjlu?= =?utf-8?B?V2FyUGJyY0N5WXJxV1d5WjhUSWhJRnRtU1B6dFQ2eVFOYWZPVXorSUx4Q050?= =?utf-8?B?emhvRDRGRUMzZmFtYVZDOWRqZVF6blNUNEpmMzRhTUI2ZHJOK1RraEVtb3p5?= =?utf-8?B?UzhhZEFreUR6czJuYlpvYkdtSGhST2Z5RkJKczR4OEpidC9LYnk1TlJvSDln?= =?utf-8?B?K0JiQlFpeG1PVzZlNFZPcHNrbmx3elJFaFVoZHF1SG8wMHNLWGFGNlhZR2hT?= =?utf-8?B?Q00zaVdYNEIwL3ZldndnQjZPVDJFY1BJQVBzbXg4ZnBzblVoZUVldUR5SjJY?= =?utf-8?B?SDVvRXRjZ2o4WlBrVmV3bGhhQWZtSjVvUHJZdThNV2x3cFpKQ2JNd2hoYVRl?= =?utf-8?B?OFZYQTFlazhYVEZQQUZKdjZsL01NN21pVWhmaHFMZm1JMHBCTlJZM2hSa1Rk?= =?utf-8?B?L2pSODQ4UHJrNmE0dStqWGIxOEpkYUZ3bzErNmFYVGxFOEJlZDhzRFVselRj?= =?utf-8?B?VXJDRnU0WUN4eU1jeXh0WW0zQU1ZeWtOZSs5ZmE3V1N6NDhRTjVjMlJsME95?= =?utf-8?B?a0F1MVJHU0JVSXQ3Y2FPMm1ENUl5akhIenF5V2VVbnkyRGtJTE82ZkVWLzNq?= =?utf-8?B?b3N3c2JjODlxbDJqZmVDcHFjUFd3Y3VkOCtHREdOVGF5SituVFpSbHlCMnky?= =?utf-8?B?N3RVRk82NDdoN3FET3AzOEJ5eHRrZWYyQkRJRDhtaEhoRlV5eEdWa1FaS3kx?= =?utf-8?B?UFNpK3J3M1JnOWNXT1gzOXB0b1lxZE5iMk1hSStXWFZNSmcxRXMwbGpzWGxX?= =?utf-8?B?d2JwcGZ4c0k4NmZ3aEdMMjJ5by9oNGFNT2RUYjhlajNHME9wZG52dnhrQ0R4?= =?utf-8?B?T1U2VDR5Zmt3SUE1UkREcjdGdU82bmNUQXpzQXJlWWlhcFFkN1lENjFUaWgx?= =?utf-8?B?TUFuVnAySjhkenJXa2dmcUgyZGhLN0xaM2dPSlphQldKd3gvczlPRHM5ekdR?= =?utf-8?B?Qnhya0VjelRCM0ZmUHVYQzFQL3FrMnA3bldpbjRNZWk1c01HUmR4QWpwazJZ?= =?utf-8?B?akIvbWhoemQvbUVMT2ZySUFVQVNrTHpaQWZwcjhrN0R1dzlnV0FZL2JlKzc5?= =?utf-8?B?MjdncGdCK1gxdlVKV0FGWXU5eklLd1AyeDU4eFR3TXNKYndjS21jeHBJemlL?= =?utf-8?B?OTFsaXl3NnhtZklIRXdFZ0tPdk1qTGNGN0Y4cVRjMGN1YlFqS0hqRFU2bUNX?= =?utf-8?Q?6mq3G7aUh?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1300; 5:9gPWqkdHq1UaiWFu2/aEFNhRBy1vG38v5CDCEWrbD/n/SdbsbdiwaEMoWM/av2Si9dd1woNmFoqLIdV4DrWRg6F9oHDeKZBf1cAe5YwKLvBf9e4UsBG1cx3liHx/EALtNgpEqqebz1klBS3B6uVkER2Tam1HdOGB09yFGBdPxjiNR4PKD/Q3ZQ+0sW6uT4UTzN+tXfeS7DpSsNeL5cyMOo6TM2zgfSDbjeaWE5zKiHOyNT5ep7qp9P4WQs0K470VtQJIAVq1gRDTvzJC6SlEf0I1nskhwoqrIef+ATjB42zL1Mq3vrCzED64lScabY99RwSbzZkgnRXQmecWaCp606RBqwejPePJjBFq6xAbxVnxO/lFe2SXRlqob6AJqLHnh3hTTWjM4jJl0Mt1s1ChzNUW3MH8QvH5a09+suSC+U0M1ssJyP7K42CnG7m7UuzlZd3QUJ4Qg2qq4ThtfrPwiKW+pczXE9PdvcR590ps7r5BB3ARIzGixdItioTq93uB; 24:RcFpSSxwtt4fPBWqiZm0/dPoS7BowekpJJedDrnQiC1yxCjvCpLoiWvCrl0p+6rqDPq3WvBl93vs6OrRy95qd5dAQBh+6rWQRvqVhd1fne4= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1300; 7:I5IHq+JUyqTe3K6A9RlbI7PKMrlwbvL+ZxMKVAEZNdK9Ji5o9gVY17IxbB0oDYW+DxtKlaRst4Em96JMCVF8Qd1GhWpaCabcD2JFvJwpvDYjR99YrQIpga4i5ftUSI/8SwDoM3Un3Pr7OTywYarV/4/yYlcUORQU0A8renRVUzPAn9/1tEhOaY+MXQ2SetNwUhRhr5XLpUgSVifwRD+0b8ZTj8aKiEnm8MO7JxzzEYiSLilWaQKnpXzgbnt9PpxjtdccakJmHMkSYEH/KRi9BBiV+pZQ62eGwm3Udx4EMQLFW6weuFlJEw9Zi79GQ/asIMAzyrH3nhvIZWyAFFkYb2TTlC2FwxMpNV3EgzAFmsg8O1Ziex9gWQZvo4OYauhsnWsDPpTvnCVXfzNlSNY+JaWruQn8sMkJrxsIU+DoQbcfERllwJs8M07SffHALAQFij/lVpYXwDOR3E3WquE6oFXM1dm47jE620HTwpl6GSzSAq44UdOVmyHqxMrHYfAG56sG6UG5ikB1LmAPList02eoQyrm1J0BTRvh3RmwmGdaZyIwu5zoHxr0Jc7PbN0i3XD84d8qSHfUkLsfw5/z/SRw3VUdi9xGYisv0mePw174melE98H3dOxLcKg+qZ5fxOLddM2WD1ba87YMMIcfXWaptyUjtGZ2gqNqmd3YS+9295iG196Kh5TTk30SH+9TlqQVt6TorCwNBh/UWX34OAaWVjc2hXo27rS3EWY3K4X0dSeX4jSgNCFdulfDMVSS+buHZdTTsuGh2I6eND6/OZkPE65dG/Zp5N6GE+0Z8QU= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jun 2017 19:32:02.6618 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.15]; Helo=[P-EMFE01C-SAC.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1300 Archived-At: Subject: Re: [Curdle] RFC 4253 possible errata X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 19:32:07 -0000 Hi Ron, Ron Frederick writes: > Hi Mark, >=20 > On Jun 21, 2017, at 11:20 AM, Mark D. Baushke wrote: > > While working with the IETF AD Eric Rescorla doing the AD > > review of draft-ietf-curdle-ssh-modp-dh-sha2, the topic came up of > > validation of the Diffie-Hellman public key on both client and server > > (peers). > >=20 > > The RFC 4253 Section 8 writes: > >=20 > > |8. Diffie-Hellman Key Exchange > > | > > | The Diffie-Hellman (DH) key exchange provides a shared secret that > > | cannot be determined by either party alone. The key exchange is > > | combined with a signature with the host key to provide host > > | authentication. This key exchange method provides explicit server > > | authentication as defined in Section 7. > > | > > | The following steps are used to exchange a key. In this, C is the > > | client; S is the server; p is a large safe prime; g is a generator > > | for a subgroup of GF(p); q is the order of the subgroup; V_S is S's > > | identification string; V_C is C's identification string; K_S is S's > > | public host key; I_C is C's SSH_MSG_KEXINIT message and I_S is S's > > | SSH_MSG_KEXINIT message that have been exchanged before this part > > | begins. > > | > > | 1. C generates a random number x (1 < x < q) and computes > > | e =3D g^x mod p. C sends e to S. > > | > > ...elided... > >=20 > > | Values of 'e' or 'f' that are not in the range [1, p-1] MUST NOT be > > | sent or accepted by either side. If this condition is violated, the > > | key exchange fails. > >=20 > > ...elided... > >=20 > > The z in range [1, p-1] notation, specifies a closed interval which > > includes the end points which is equivant to 1 <=3D z <=3D p-1. The (1,= p-1) > > notation specifies an open interval which excludes the endpoints 1 < z < > > p-2. >=20 > [Ron] I don=E2=80=99t understand the =E2=80=9Cp-2=E2=80=9D here. Is that = a typo?=20 Yes, I guess I should be careful when I touch-type numerals. It is intended to be p-1 in both cases. > Also, if you want to convert from the closed range [1, p-1], shouldn=E2= =80=99t > that to be to an open range of (0, p), which would correspond to =E2=80= =9C0 < > z < p=E2=80=9D? Yes. That is the error. I believe it should either have been written as [2, p-2] or (1, p-1). If we look at other sources such as NIST SP 800-56A revision 2, page 36 section 5.6.2.3.1 we see the verification is [2, p-2] which is also used in RFC 7919. > > Eric noted that https://tools.ietf.org/rfcmarkup?rfc=3D7919#section-5.1 > > uses open endpoints. > >=20 > > Eric suggested that my draft should include text that is similar to the > > ext in the RFC 7919 to correct this errata. >=20 > [Ron] I see RFC 7919 refers to a closed range [2, p-2]. This would be > a change from what is allowed by RFC 4253 today. Yes. > > Before I make such a change, I wish understand if what folks have been > > using for the test in their implementations and get a consensus on such > > a change. >=20 > [Ron] In asyncssh, the test I=E2=80=99m doing on e & f is =E2=80=9C1 <=3D= e < p=E2=80=9D and =E2=80=9C1 > <=3D f < p", which is essentially the half-open range of [1, p) that is > equivalent to the closed range [1, p-1] listed in RFC 4253. Okay. This implies that there would need to be an implementation change if we agree that RFC 4253 use of a closed range is an errata because an open range was intended. Or, we could agree that narrowing the range is in the best interests of the DH key exchange. -- Mark From nobody Wed Jun 21 12:39:15 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70FA01241FC for ; Wed, 21 Jun 2017 12:39:07 -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] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=secure-endpoints.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 eeGJ_5Z0c4qn for ; Wed, 21 Jun 2017 12:39:05 -0700 (PDT) Received: from sequoia-grove.secure-endpoints.com (sequoia-grove.ad.secure-endpoints.com [208.125.0.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 039A5129412 for ; Wed, 21 Jun 2017 12:39:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/relaxed; d=secure-endpoints.com; s=MDaemon; t=1498073922; x=1498678722; i=jaltman@secure-endpoints.com; q=dns/txt; h=VBR-Info:Subject:To: References:From:Openpgp:Organization:Message-ID:Date:User-Agent: MIME-Version:In-Reply-To:Content-Type; bh=EutfDKLijbA71MVk2jRWYU wXArnZCv+guRJje3U/QYk=; b=Rltd6TNpT4nFjoSu00aMEesRC5M64vmsr9AlYN 0zg/r4ZGQhUejLgXU8EYwq/RmbYgGVi3YP8T7TUCzPkqtThfRp0husVIk65jMm0/ ZZnOo7CE+M2mYfVXmZ5xQot89Pf9Jr6FCWt7234EGOowJ5QkXXfZ34Aik9UpiBv5 /Qjkw= X-MDAV-Result: clean X-MDAV-Processed: sequoia-grove.secure-endpoints.com, Wed, 21 Jun 2017 15:38:42 -0400 X-Spam-Processed: sequoia-grove.secure-endpoints.com, Wed, 21 Jun 2017 15:38:42 -0400 Received: from [IPv6:2001:470:1f07:f77:7174:9244:a061:80d1] by secure-endpoints.com (IPv6:2001:470:1f07:f77:28d9:68fb:855d:c2a5) (MDaemon PRO v17.0.2) with ESMTPSA id md50001371673.msg; Wed, 21 Jun 2017 15:38:40 -0400 VBR-Info: md=secure-endpoints.com; mc=all; mv=vbr.emailcertification.org; X-MDRemoteIP: 2001:470:1f07:f77:7174:9244:a061:80d1 X-MDHelo: [IPv6:2001:470:1f07:f77:7174:9244:a061:80d1] X-MDArrival-Date: Wed, 21 Jun 2017 15:38:40 -0400 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Return-Path: prvs=13456c59c6=jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: curdle@ietf.org X-CAV-Result: clean To: kitten@ietf.org, curdle@ietf.org References: <20170621034615.GH39245@kduck.kaduk.org> <20170621094935.AF6161A6BF@ld9781.wdf.sap.corp> <20170621174558.GK39245@kduck.kaduk.org> From: Jeffrey Altman Openpgp: id=FA444AF197F449B24CF3E699F77A735592B69A04; url=https://pgp.mit.edu Organization: Secure Endpoints Inc. Message-ID: Date: Wed, 21 Jun 2017 15:38:36 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <20170621174558.GK39245@kduck.kaduk.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040206090204090807030301" Archived-At: Subject: Re: [Curdle] [kitten] I-D Action: draft-ietf-curdle-des-des-des-die-die-die-03.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 19:39:07 -0000 This is a cryptographically signed message in MIME format. --------------ms040206090204090807030301 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 6/21/2017 1:45 PM, Benjamin Kaduk wrote: > It sounds like you are asking for the addition of some text along > the lines of: >=20 > Software support is only a bare minimum requirement for deprecating > RC4 enctypes; there may be additional logistical considerations > involved such as provisioning AES keys for all principals and > updating software configuration to enable AES and disable deprecated > encryption types. >=20 > Is that something you are asking for? >=20 > Thanks, In my opinion, such text is inappropriate for an RFC. The deprecation of the encryption type is a protocol action. The RFC is not guidance for system administrators. Such guidance should come from the protocol implementations. As such I believe the addition of text similar to the above is unnecessary for publication. Jeffrey Altman --------------ms040206090204090807030301 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DJswggYCMIIE6qADAgECAhBAAVgjEN7WFoCIXylZ1uvSMA0GCSqGSIb3DQEBCwUAMDoxCzAJ BgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEy MB4XDTE2MTEwMjAzMjQxOFoXDTE3MTEwMjAzMjQxOFowgZYxNTAzBgNVBAsMLFZlcmlmaWVk IEVtYWlsOiBqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMuY29tMSswKQYJKoZIhvcNAQkBFhxq YWx0bWFuQHNlY3VyZS1lbmRwb2ludHMuY29tMTAwLgYKCZImiZPyLGQBARMgN0YwMDAwMDEw MDAwMDE1ODIzMTBERUE3MDAwMDA3QjQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDPaPDUdwWkzLcNsJjjlDs5lo4ySDKmCgzQsuDt+VY3wP0IZBbu8f/LM3zWCH7zVRJ/XuY5 qN44jFEXwj5fGY71Esm5pKv5sUpys6Q3c6BKXiHv/IUusI3qTJ46QBEAiHu2lxB75UnIYgm+ ZbKmcAR48Z1Sl/Ku86e9GPuts9R51SeHW1pjq89LAi6C0ERuAUIK0rVZGDmKWtRNs9EykXzk mU2Z1ZLuPL0jIggFPeT8TyH6TH/XvapbC+7rHJrzuBY4NDqLgqDJUf0JidL9JeK9+IxxPCab EbVmOf5sBgO5mg92l4+f+Q4xefZcI4C7RPFdRTRWsQs7Z3DpE28BDbjDAgMBAAGjggKlMIIC oTAOBgNVHQ8BAf8EBAMCBaAwgYQGCCsGAQUFBwEBBHgwdjAwBggrBgEFBQcwAYYkaHR0cDov L2NvbW1lcmNpYWwub2NzcC5pZGVudHJ1c3QuY29tMEIGCCsGAQUFBzAChjZodHRwOi8vdmFs aWRhdGlvbi5pZGVudHJ1c3QuY29tL2NlcnRzL3RydXN0aWRjYWExMi5wN2MwHwYDVR0jBBgw FoAUpHPa72k1inXMoBl7CDL4a4nkQuwwCQYDVR0TBAIwADCCASwGA1UdIASCASMwggEfMIIB GwYLYIZIAYb5LwAGCwEwggEKMEoGCCsGAQUFBwIBFj5odHRwczovL3NlY3VyZS5pZGVudHJ1 c3QuY29tL2NlcnRpZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRtbDCBuwYIKwYBBQUHAgIw ga4agatUaGlzIFRydXN0SUQgQ2VydGlmaWNhdGUgaGFzIGJlZW4gaXNzdWVkIGluIGFjY29y ZGFuY2Ugd2l0aCAKSWRlblRydXN0J3MgVHJ1c3RJRCBDZXJ0aWZpY2F0ZSBQb2xpY3kgZm91 bmQgYXQgaHR0cHM6Ly9zZWN1cmUuaWRlbnRydXN0LmNvbS9jZXJ0aWZpY2F0ZXMvcG9saWN5 L3RzL2luZGV4Lmh0bWwwRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL3ZhbGlkYXRpb24uaWRl bnRydXN0LmNvbS9jcmwvdHJ1c3RpZGNhYTEyLmNybDAnBgNVHREEIDAegRxqYWx0bWFuQHNl Y3VyZS1lbmRwb2ludHMuY29tMB0GA1UdDgQWBBSP11Voh/Sg9hmecftn2BV5ZQd9OTAdBgNV HSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDQYJKoZIhvcNAQELBQADggEBAC9cnqRj+ViE efFsiYNMUC8tZf6PXcWDecOR5Pdv/Vd/O6y10mYyilPrcd0sJux1idTZIOzHAsh36BfBdNSt BFAuBZD66L649U3XqBnh9nbuzmCwNc3tWjOaY/Xe7R90lqrXaW0Dw0U++zwmNyCO2CRgBdrU 8cTqFpOtpe/gCAMhjajrUfb+m8Vcd5R0RVIvdljblqv2t9IXQIHwWSm8E7v302z7yW4o4iPH kegez5vq37ICikQjkkVyAJr0wtirJyQuFzMgpoWVpm0CKBiMwJPki2kiHlNiMHBr2ch4fC+H SjbMg4OzTZJCz1xhKvpyRDOM8JRb2BNSU8JjmrxZgFIwggaRMIIEeaADAgECAhEA+d5Wf8lN DHdw+WAbUtoVOzANBgkqhkiG9w0BAQsFADBKMQswCQYDVQQGEwJVUzESMBAGA1UEChMJSWRl blRydXN0MScwJQYDVQQDEx5JZGVuVHJ1c3QgQ29tbWVyY2lhbCBSb290IENBIDEwHhcNMTUw MjE4MjIyNTE5WhcNMjMwMjE4MjIyNTE5WjA6MQswCQYDVQQGEwJVUzESMBAGA1UEChMJSWRl blRydXN0MRcwFQYDVQQDEw5UcnVzdElEIENBIEExMjCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBANGRTTzPCic0kq5L6ZrUJWt5LE/n6tbPXPhGt2Egv7plJMoEpvVJJDqGqDYy maAsd8Hn9ZMAuKUEFdlx5PgCkfu7jL5zgiMNnAFVD9PyrsuF+poqmlxhlQ06sFY2hbhQkVVQ 00KCNgUzKcBUIvjv04w+fhNPkwGW5M7Ae5K5OGFGwOoRck9GG6MUVKvTNkBw2/vNMOd29VGV TtR0tjH5PS5yDXss48Yl1P4hDStO2L4wTsW2P37QGD27//XGN8K6amWB6F2XOgff/PmlQjQO ORT95PmLkwwvma5nj0AS0CVp8kv0K2RHV7GonllKpFDMT0CkxMQKwoj+tWEWJTiDKSsCAwEA AaOCAoAwggJ8MIGJBggrBgEFBQcBAQR9MHswMAYIKwYBBQUHMAGGJGh0dHA6Ly9jb21tZXJj aWFsLm9jc3AuaWRlbnRydXN0LmNvbTBHBggrBgEFBQcwAoY7aHR0cDovL3ZhbGlkYXRpb24u aWRlbnRydXN0LmNvbS9yb290cy9jb21tZXJjaWFscm9vdGNhMS5wN2MwHwYDVR0jBBgwFoAU 7UQZwNPwBovupHu+QucmVMiONnYwDwYDVR0TAQH/BAUwAwEB/zCCASAGA1UdIASCARcwggET MIIBDwYEVR0gADCCAQUwggEBBggrBgEFBQcCAjCB9DBFFj5odHRwczovL3NlY3VyZS5pZGVu dHJ1c3QuY29tL2NlcnRpZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRtbDADAgEBGoGqVGhp cyBUcnVzdElEIENlcnRpZmljYXRlIGhhcyBiZWVuIGlzc3VlZCBpbiBhY2NvcmRhbmNlIHdp dGggSWRlblRydXN0J3MgVHJ1c3RJRCBDZXJ0aWZpY2F0ZSBQb2xpY3kgZm91bmQgYXQgaHR0 cHM6Ly9zZWN1cmUuaWRlbnRydXN0LmNvbS9jZXJ0aWZpY2F0ZXMvcG9saWN5L3RzL2luZGV4 Lmh0bWwwSgYDVR0fBEMwQTA/oD2gO4Y5aHR0cDovL3ZhbGlkYXRpb24uaWRlbnRydXN0LmNv bS9jcmwvY29tbWVyY2lhbHJvb3RjYTEuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEF BQcDBDAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0OBBYEFKRz2u9pNYp1zKAZewgy+GuJ5ELsMA0G CSqGSIb3DQEBCwUAA4ICAQAN4YKu0vv062MZfg+xMSNUXYKvHwvZIk+6H1pUmivyDI4I6A3w Wzxlr83ZJm0oGIF6PBsbgKJ/fhyyIzb+vAYFJmyI8I/0mGlc+nIQNuV2XY8cypPoVJKgpnzp /7cECXkX8R4NyPtEn8KecbNdGBdEaG4a7AkZ3ujlJofZqYdHxN29tZPdDlZ8fR36/mAFeCEq 0wOtOOc0Eyhs29+9MIZYjyxaPoTS+l8xLcuYX3RWlirRyH6RPfeAi5kySOEhG1quNHe06QIw pigjyFT6v/vRqoIBr7WpDOSt1VzXPVbSj1PcWBgkwyGKHlQUOuSbHbHcjOD8w8wHSDbL+L2h e8hNN54doy1e1wJHKmnfb0uBAeISoxRbJnMMWvgAlH5FVrQWlgajeH/6NbYbBSRxALuEOqEQ epmJM6qz4oD2sxdq4GMN5adAdYEswkY/o0bRKyFXTD3mdqeRXce0jYQbWm7oapqSZBccFvUg YOrB78tB6c1bxIgaQKRShtWR1zMM0JfqUfD9u8Fg7G5SVO0IG/GcxkSvZeRjhYcbTfqF2eAg prpyzLWmdr0mou3bv1Sq4OuBhmTQCnqxAXr4yVTRYHkp5lCvRgeJAme1OTVpVPth/O7HJ7Vu EP9GOr6kCXCXmjB4P3UJ2oU0NqfoQdcSSSt9hliALnExTEjii20B2nSDojGCAxQwggMQAgEB ME4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEXMBUGA1UEAxMOVHJ1c3RJ RCBDQSBBMTICEEABWCMQ3tYWgIhfKVnW69IwDQYJYIZIAWUDBAIBBQCgggGXMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3MDYyMTE5MzgzN1owLwYJKoZI hvcNAQkEMSIEIEsb8ekdJXn7gDhyE5lUoN/iAd3Fq3pC19Ar36fIlKRUMF0GCSsGAQQBgjcQ BDFQME4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEXMBUGA1UEAxMOVHJ1 c3RJRCBDQSBBMTICEEABWCMQ3tYWgIhfKVnW69IwXwYLKoZIhvcNAQkQAgsxUKBOMDoxCzAJ BgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEy AhBAAVgjEN7WFoCIXylZ1uvSMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF Kw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAWd0Fsv22CvqVuLmz67Qw sY92GEwzAuJ3BZa9Y5MoRRO32LBwcDbYGRqEa7ce805KxN6uGQVlBDxU1Q5xTtcv2SGp3bBl mrDreVkKSHtbp4ELkFxByq0ooaO2v/PUam3o0vcQ48lIk8fl2VuW9SKY7NTbVJVpcMoVDMzC v4KY3b1cxTeHzL3aOxC8ARDeLDkftmiX6wErZh7JX6nfbDvFD2LCpuJBHK1m5s6aJPks7stm Mvhqgyp+U143BJToco3RkW0JB5MrTg0UOLvCJNLN+cmmoCf26i63Ac3aGoTaXo4nO51gLlWu JG1FAF7Iz95InUF8CcAdkmT1anvrEwvKdAAAAAAAAA== --------------ms040206090204090807030301-- From nobody Wed Jun 21 22:31:08 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19411126D05 for ; Wed, 21 Jun 2017 22:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.335 X-Spam-Level: X-Spam-Status: No, score=-1.335 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=timeheart.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUXcBjSBvHZg for ; Wed, 21 Jun 2017 22:31:04 -0700 (PDT) Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::241]) (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 CDBFA1200CF for ; Wed, 21 Jun 2017 22:31:04 -0700 (PDT) Received: by mail-pg0-x241.google.com with SMTP id u62so1117187pgb.0 for ; Wed, 21 Jun 2017 22:31:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=timeheart.net; s=mail; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=cbrLFbC89qhf3PpoNGa4vgTnkyOF+F7gG9C8Qit/988=; b=aq1oUzHowdfdsR9Ck44zdn5+fQDsnM7ZX3MZtC+EpUKdviuXjaIYjXuBCgMwYGWoC2 5HPwPmHO6GToM7xiTr96dz2Bs1YZQcDWvl9h+0drmE2D8fyV1lgWx81Ye4SLDsJ+nzxS x41Qt2d4s0RA5vRAAx+U49Cm7tvr7XWUtYV4A= 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=cbrLFbC89qhf3PpoNGa4vgTnkyOF+F7gG9C8Qit/988=; b=rYzxTXf809Zn1FEeRvAMmCVMc+716X0WNGivc4aQf43DRwYP5257GF9CmAGA5sPwyK qh/MdMfTdtHH6hOjm/AVtGHfEfxNT9OJzkzbzmV1W/X6Ycj/xl42m5y+CCQkdtB3OCLx n5OICvj5r7B4JzToO/sw3z1hjtkGokDL0//a/2pLzBxgKSOdDg/63qQmaYR+8RR5lgyf 0T9+t2aHCdJgUNHYoXlRrtSQi32qYmA+bsH+TPTqY4rnq6cu+9KSiZhCyyzeZs/mMhA+ HTM0gdwO+9i/02QBz1/m5jH712KgbNLtlAleSwojLL638VxL4BykxtDmbDSHETVjA29d pICA== X-Gm-Message-State: AKS2vOx+qQ2xkSXW/FiXYpnPSm8lKfKoS7X1LuDNO2os70mssodexj5P CNcfa0/TTUhddlKs X-Received: by 10.84.216.70 with SMTP id f6mr910129plj.79.1498109464256; Wed, 21 Jun 2017 22:31:04 -0700 (PDT) Received: from 74-93-13-193-sfba.hfc.comcastbusiness.net (74-93-13-193-SFBA.hfc.comcastbusiness.net. [74.93.13.193]) by smtp.gmail.com with ESMTPSA id r129sm942402pfr.112.2017.06.21.22.31.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Jun 2017 22:31:03 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ron Frederick In-Reply-To: <91495.1498073520@eng-mail01.juniper.net> Date: Wed, 21 Jun 2017 22:31:02 -0700 Cc: Curdle WG , SSH WG , Eric Rescorla Content-Transfer-Encoding: quoted-printable Message-Id: <8921418C-1876-446B-8216-C29127B22B0A@timeheart.net> References: <80212.1498069205@eng-mail01.juniper.net> <50A8EE09-4FB3-4272-956E-E280F90E01A9@timeheart.net> <91495.1498073520@eng-mail01.juniper.net> To: "Mark D. Baushke" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] RFC 4253 possible errata X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 05:31:07 -0000 Hi Mark, On Jun 21, 2017, at 12:32 PM, Mark D. Baushke wrote: >>> The z in range [1, p-1] notation, specifies a closed interval which >>> includes the end points which is equivant to 1 <=3D z <=3D p-1. The = (1, p-1) >>> notation specifies an open interval which excludes the endpoints 1 < = z < >>> p-2. >>=20 >> [Ron] I don=E2=80=99t understand the =E2=80=9Cp-2=E2=80=9D here. Is = that a typo?=20 >=20 > Yes, I guess I should be careful when I touch-type numerals. It is > intended to be p-1 in both cases. >=20 >> Also, if you want to convert from the closed range [1, p-1], = shouldn=E2=80=99t >> that to be to an open range of (0, p), which would correspond to =E2=80= =9C0 < >> z < p=E2=80=9D? >=20 > Yes. >=20 > That is the error. I believe it should either have been written as [2, > p-2] or (1, p-1). >=20 > If we look at other sources such as NIST SP 800-56A revision 2, page = 36 > section 5.6.2.3.1 we see the verification is [2, p-2] which is also = used > in RFC 7919. [Ron] Interesting. I just checked the OpenSSH code, and it looks like it = is already enforcing [2, p-2], so that would support considering this to = be an error in the RFC, and would also suggest I should change my = implementation to avoid picking a value that OpenSSH would reject if I = was doing a DH exchange with it. >>> Before I make such a change, I wish understand if what folks have = been >>> using for the test in their implementations and get a consensus on = such >>> a change. >>=20 >> [Ron] In asyncssh, the test I=E2=80=99m doing on e & f is =E2=80=9C1 = <=3D e < p=E2=80=9D and =E2=80=9C1 >> <=3D f < p", which is essentially the half-open range of [1, p) that = is >> equivalent to the closed range [1, p-1] listed in RFC 4253. >=20 > Okay. >=20 > This implies that there would need to be an implementation change if = we > agree that RFC 4253 use of a closed range is an errata because an open > range was intended. Or, we could agree that narrowing the range is in > the best interests of the DH key exchange. [Ron] If there=E2=80=99s a mix of implementations out there, that would = argue that making all of them use the narrower range would be best. In = additional to bringing this in line with RFC 7919, it would help to = avoid a rare but possible interoperability problem. --=20 Ron Frederick ronf@timeheart.net From nobody Thu Jun 22 00:43:06 2017 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A00A9126CD8; Thu, 22 Jun 2017 00:42:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149811737863.30580.17844240860986769225@ietfa.amsl.com> Date: Thu, 22 Jun 2017 00:42:58 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-ssh-dh-group-exchange-04.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 07:42:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : Increase SSH minimum recommended DH modulus size to 2048 bits Authors : Loganaden Velvindron Mark D. Baushke Filename : draft-ietf-curdle-ssh-dh-group-exchange-04.txt Pages : 4 Date : 2017-06-22 Abstract: The Diffie-Hellman (DH) Group Exchange for the Secure Shell (SSH) Transport layer Protocol specifies that servers and clients should support groups with a modulus length of k bits, where the recommended minumum value is 1024 bits. Recent security research has shown that a minimum value of 1024 bits is insufficient against state-sponsored actors. As such, this document formally updates the specification such that the minimum recommended value for k is 2048 bits and the group size is 2048 bits at minimum. This RFC updates RFC4419 which allowed for DH moduli less than 2048 bits. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-dh-group-exchange/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-ssh-dh-group-exchange-04 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-dh-group-exchange-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-ssh-dh-group-exchange-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 Thu Jun 22 01:32:22 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE32128AB0 for ; Thu, 22 Jun 2017 01:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_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_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=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 hioXCACfbyu8 for ; Thu, 22 Jun 2017 01:32:07 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA2171273E2 for ; Thu, 22 Jun 2017 01:32:07 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id v7so3316006ywc.2 for ; Thu, 22 Jun 2017 01:32:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OsIsVWySQbHM9Ty2+eg8F1tdONN5gHWsGPZM0X0DRgk=; b=Nb6+OxyLbJDqksywqOdw05kl7F5Kd75WI9kmxmbO5QUyk1ifs8TUtvz0aTEvFeSpNG +f36SnKjA6QhvQxAQVBeJG844O5wDzVWWlRyRhY+yDgdVoBztqMMu7eCnHVXqhMrh4yZ TygS9PLrv1VglZoikIFj++LJfVr1J6I/SLqRE3VRb1owgAFGFGqYNPlCAkTE66SmD4Zs dxtnajvumyjvrRdHS+nFijEcr2Hs9lTmMBhvJHuIUmTz2pPEwKvfvU/22asvxaamuJHp H4qSI5upIXB1irlgVCtZUNjtdjhd3KqWijWVitV0jgCrGb+ijPtk0Jteglp6VOY3dSCq FVag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OsIsVWySQbHM9Ty2+eg8F1tdONN5gHWsGPZM0X0DRgk=; b=q6oFQUwqFrj1Q0Tkt+0p6p2bUNAsDVTSQnCXlu8URtpTFQRPzsORVmYR3frwQhPNA7 W2NLrX6v7stqhM+ljmS8+/M5VAKn3BjqUMtKSAVSFLVawlis8+WRfAAOOmAApjXTdWti OSKdvRTeMBXR5vwJW1I/93bkO8kc8IS3KSMaZRl6/TPWUsGv4kCwjVbJdKeJFRO8Trtq biKNpVSvLcOmlde7jnwQj9wjl/sgzSI9s386WC3QK8s9AKYTw/wEpybwIlvBOeKsnzC5 30ntTbIMy12fl7vmlX2Q51Zgdq0kZgtYliPmGUe6+HHMq7yY7m5a5RBqbgcx8CFLPuC/ j4ww== X-Gm-Message-State: AKS2vOxFy02/Tu7BDQggQdaUNAR0Ic/vs6zC7lafrpFtLIofj+Bassnw 9F/N0q6DeO3c1U5yTQyWPwB0odgkIQ== X-Received: by 10.13.212.70 with SMTP id w67mr964161ywd.63.1498120326964; Thu, 22 Jun 2017 01:32:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.163.131 with HTTP; Thu, 22 Jun 2017 01:32:06 -0700 (PDT) In-Reply-To: <80212.1498069205@eng-mail01.juniper.net> References: <80212.1498069205@eng-mail01.juniper.net> From: denis bider Date: Thu, 22 Jun 2017 02:32:06 -0600 Message-ID: To: "Mark D. Baushke" Cc: Curdle WG , Eric Rescorla Content-Type: multipart/alternative; boundary="001a114fb568eb6f1705528851a1" Archived-At: Subject: Re: [Curdle] RFC 4253 possible errata X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 08:32:11 -0000 --001a114fb568eb6f1705528851a1 Content-Type: text/plain; charset="UTF-8" (Removing the SSH mailing list from CC under the presumption that most of those who are interested are already subscribed to Curdle, and don't want duplicate messages.) Correct me if I'm wrong, but I'm not seeing a way that a cooperating implementation would send "e" or "f" that violates this requirement in either way. The likelihood of accidentally generating e=1, or f=p-1, is orders of magnitude lower than accidentally generating one of Satoshi's Bitcoin private keys. If I got a genie lamp that lets me generate numbers like this on accident, I'd rather generate Satoshi's private key. So therefore, it's not meaningful to talk about compatibility here. It's meaningful to talk about contributing behavior ("e" or "f" is random), non-contributing behavior ("e" or "f" is fixed but valid), or sabotaging the DH key exchange ("e" or "f" is invalid and results in an insecure key exchange). Which view in particular are we talking about here? Because valid implementations (contributing or non-contributing) will not be sending f=1 or e=p-1. Ever. denis On Wed, Jun 21, 2017 at 12:20 PM, Mark D. Baushke wrote: > Hi Folks, > > While working with the IETF AD Eric Rescorla doing the AD > review of draft-ietf-curdle-ssh-modp-dh-sha2, the topic came up of > validation of the Diffie-Hellman public key on both client and server > (peers). > > The RFC 4253 Section 8 writes: > > |8. Diffie-Hellman Key Exchange > | > | The Diffie-Hellman (DH) key exchange provides a shared secret that > | cannot be determined by either party alone. The key exchange is > | combined with a signature with the host key to provide host > | authentication. This key exchange method provides explicit server > | authentication as defined in Section 7. > | > | The following steps are used to exchange a key. In this, C is the > | client; S is the server; p is a large safe prime; g is a generator > | for a subgroup of GF(p); q is the order of the subgroup; V_S is S's > | identification string; V_C is C's identification string; K_S is S's > | public host key; I_C is C's SSH_MSG_KEXINIT message and I_S is S's > | SSH_MSG_KEXINIT message that have been exchanged before this part > | begins. > | > | 1. C generates a random number x (1 < x < q) and computes > | e = g^x mod p. C sends e to S. > | > ...elided... > > | Values of 'e' or 'f' that are not in the range [1, p-1] MUST NOT be > | sent or accepted by either side. If this condition is violated, the > | key exchange fails. > > ...elided... > > The z in range [1, p-1] notation, specifies a closed interval which > includes the end points which is equivant to 1 <= z <= p-1. The (1, p-1) > notation specifies an open interval which excludes the endpoints 1 < z < > p-2. > > Eric noted that https://tools.ietf.org/rfcmarkup?rfc=7919#section-5.1 > uses open endpoints. > > Eric suggested that my draft should include text that is similar to the > ext in the RFC 7919 to correct this errata. > > Before I make such a change, I wish understand if what folks have been > using for the test in their implementations and get a consensus on such > a change. > > Thank you, > -- Mark > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --001a114fb568eb6f1705528851a1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(Removing the SSH mailing list from CC under the pres= umption that most of those who are interested are already subscribed to Cur= dle, and don't want duplicate messages.)

Correct me= if I'm wrong, but I'm not seeing a way that a cooperating implemen= tation would send "e" or "f" that violates this require= ment in either way. The likelihood of accidentally generating e=3D1, or f= =3Dp-1, is orders of magnitude lower than accidentally generating one of Sa= toshi's Bitcoin private keys. If I got a genie lamp that lets me genera= te numbers like this on accident, I'd rather generate Satoshi's pri= vate key.

So therefore, it's not meaningful to talk = about compatibility here. It's meaningful to talk about contributing be= havior ("e" or "f" is random), non-contributing behavio= r ("e" or "f" is fixed but valid), or sabotaging the DH= key exchange ("e" or "f" is invalid and results in an = insecure key exchange).

Which view in particular a= re we talking about here? Because valid implementations (contributing or no= n-contributing) will not be sending f=3D1 or e=3Dp-1. Ever.

<= /div>
denis



On Wed, Jun 21, 2017 at 12:20 PM, M= ark D. Baushke <mdb@juniper.net> wrote:
Hi Folks,

While working with the IETF AD Eric Rescorla <ekr@rtfm.com> doing the AD
review of draft-ietf-curdle-ssh-modp-dh-sha2, the topic came up of
validation of the Diffie-Hellman public key on both client and server
(peers).

The RFC 4253 Section 8 writes:

|8.=C2=A0 Diffie-Hellman Key Exchange
|
|=C2=A0 =C2=A0The Diffie-Hellman (DH) key exchange provides a shared secret= that
|=C2=A0 =C2=A0cannot be determined by either party alone.=C2=A0 The key exc= hange is
|=C2=A0 =C2=A0combined with a signature with the host key to provide host |=C2=A0 =C2=A0authentication.=C2=A0 This key exchange method provides expli= cit server
|=C2=A0 =C2=A0authentication as defined in Section 7.
|
|=C2=A0 =C2=A0The following steps are used to exchange a key.=C2=A0 In this= , C is the
|=C2=A0 =C2=A0client; S is the server; p is a large safe prime; g is a gene= rator
|=C2=A0 =C2=A0for a subgroup of GF(p); q is the order of the subgroup; V_S = is S's
|=C2=A0 =C2=A0identification string; V_C is C's identification string; = K_S is S's
|=C2=A0 =C2=A0public host key; I_C is C's SSH_MSG_KEXINIT message and I= _S is S's
|=C2=A0 =C2=A0SSH_MSG_KEXINIT message that have been exchanged before this = part
|=C2=A0 =C2=A0begins.
|
|=C2=A0 =C2=A01. C generates a random number x (1 < x < q) and comput= es
|=C2=A0 =C2=A0 =C2=A0 e =3D g^x mod p.=C2=A0 C sends e to S.
|
...elided...

|=C2=A0 =C2=A0Values of 'e' or 'f' that are not in the rang= e [1, p-1] MUST NOT be
|=C2=A0 =C2=A0sent or accepted by either side.=C2=A0 If this condition is v= iolated, the
|=C2=A0 =C2=A0key exchange fails.

...elided...

The z in range [1, p-1] notation, specifies a closed interval which
includes the end points which is equivant to 1 <=3D z <=3D p-1. The (= 1, p-1)
notation specifies an open interval which excludes the endpoints 1 < z &= lt;
p-2.

Eric noted that https://tools.ietf.org/r= fcmarkup?rfc=3D7919#section-5.1
uses open endpoints.

Eric suggested that my draft should include text that is similar to the
ext in the RFC 7919 to correct this errata.

Before I make such a change, I wish understand if what folks have been
using for the test in their implementations and get a consensus on such
a change.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thank you,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mark

_______________________________________________
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle

--001a114fb568eb6f1705528851a1-- From nobody Thu Jun 22 01:51:40 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13A88127419 for ; Thu, 22 Jun 2017 01:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Qoc22cUEgYP for ; Thu, 22 Jun 2017 01:51:35 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0124.outbound.protection.outlook.com [104.47.38.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F21251200C1 for ; Thu, 22 Jun 2017 01:51:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XLaEmoZ65QBvy6K/NjSsEDhdQjcJ2oMfH2KQTSHaFI8=; b=Ke2itXpde3iCtTAD1/VdqW3npQTjvTNLxrZTXcacbE20DKp5a+k0K7IdzrYtT2ORVxc5bmwU24VWKxNLu6i9P8zVY8Bxg+qIifYL2Tanc+v8f4n+/Zzfr5h3N7nlrszWBgOWJFKrbZ6rwqqDlNA9j+806ZDd2ygDnt2Dg3z0hA0= Received: from BLUPR05CA0060.namprd05.prod.outlook.com (10.141.20.30) by BY2PR05MB1974.namprd05.prod.outlook.com (10.163.32.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.6; Thu, 22 Jun 2017 08:51:32 +0000 Received: from DM3NAM05FT003.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e51::201) by BLUPR05CA0060.outlook.office365.com (2a01:111:e400:855::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.6 via Frontend Transport; Thu, 22 Jun 2017 08:51:32 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.15) smtp.mailfrom=juniper.net; gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.15 as permitted sender) Received: from P-EMFE01C-SAC.jnpr.net (66.129.239.15) by DM3NAM05FT003.mail.protection.outlook.com (10.152.98.108) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1157.20 via Frontend Transport; Thu, 22 Jun 2017 08:51:32 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by P-EMFE01C-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 22 Jun 2017 01:51:01 -0700 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v5M8p1du028295; Thu, 22 Jun 2017 01:51:01 -0700 (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id C5D1A11446; Thu, 22 Jun 2017 01:51:00 -0700 (PDT) To: denis bider CC: Curdle WG , Eric Rescorla In-Reply-To: References: <80212.1498069205@eng-mail01.juniper.net> Comments: In-reply-to: denis bider message dated "Thu, 22 Jun 2017 02:32:06 -0600." From: "Mark D. Baushke" Date: Thu, 22 Jun 2017 01:51:00 -0700 Message-ID: <63844.1498121460@eng-mail01.juniper.net> Sender: MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.15; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39400400002)(39860400002)(39450400003)(39840400002)(39850400002)(2980300002)(189002)(199003)(9170700003)(77096006)(2810700001)(76506005)(81166006)(54906002)(6392003)(53416004)(7846003)(5660300001)(106466001)(229853002)(117636001)(50986999)(54356999)(76176999)(105596002)(7126002)(189998001)(7696004)(478600001)(8676002)(39060400002)(55016002)(5003940100001)(4326008)(305945005)(2950100002)(8936002)(2906002)(356003)(6916009)(53936002)(50466002)(48376002)(86362001)(110136004)(6246003)(6266002)(47776003)(38730400002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB1974; H:P-EMFE01C-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:ovrnspm; MX:1; A:1; PTR:InfoDomainNonexistent; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DM3NAM05FT003; 1:4thEN/6f+kUiWvgvapN6KrAL3TnvsYbCMUfjBJks3Hxaeo5LV0uHmVU1IH3cszzPrQpdQuJKIFE8yRNJp9RpypsI5uSsOoXiTx61CHMS28ZsXHJY9RTKReEGnjWK4FaMJL1OU2EBFEVqmOQFgi3IRviLER5NbWn0YaFV7cOYl04oblvR7PbmDI1azUFhvVabvmcriEjKdb2u4ClORCJK6isRO25deN3bLNMQUYGZHEQwqeMgVrWvR82AHawVhcycwd8TuTpSUd/VkaRojn3k5hUNsVgo47sKIvEL6OpUH3+1KbsSiAISUXpvAEgPIjjPrV/DTkVql6blxaQjEfZUMlNryE64UT/tANHiV6BsvmHV9vMojrRMshDt+KP6AeSsjBFwB4TByCzlzjinbyrvxHhEmoZ8XA7c7Hxjp69cUNJ5ZyGM0kHcXRudxUZ+Jl2yQiVtkzGRrdj2p0MgavCF0W35j/1aWR9OTmqPvHxMNPTBOZ7pxjajij+fdoSkWxVLn/uXRGIpNlh9pvXBhTDcidRjR2E+Ix3B6RxBzamDHv9QDon/dmJ3m9km8qAIK+EnHInrSLlqtK7orGmVFUoxVvo3QuTUAgPLXxs0/hEsoaMk1g153TakKV0FmrVqcjAWV4S5B4Gpk9T9NLYRvgnMiBs16cHLBjGPrrmZSUOg6sY= X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 8dbf4091-9f47-4e85-c403-08d4b94be1b4 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:BY2PR05MB1974; X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB1974; 3:yb0O0bc2RRUb2G+a6kk3fg92B8Cd/7pe97fNmQP1PvQIy7bpTsN995q/qXP3C25V63E+ycXCbqKPowM8W4WEgsMHPtEyQKCFvkdEfVqahhk+BpeJJeF3jz3zKRd3EacigHf3gn7w+NANx0GA2ro/z3XTIdHWjJT5/3lycA4kvgPShD8Ywh2N7L90PShBGM8bqzqMWlqlBFboak1QI6GrcNroRgQyE8krsumKBKif0U/qaMm9MI+jworW4aOfNG52/IS3vh0YLFcon5YMM71N3Z1mrADba7yOsL5a9UTfQWXdP4F2Y6M+KVCU57wJE+l14+qjOWC4Zkbe9zti9Mlrp/KAoHSPg/eAFV/SvKkMfjIIOUDy8BnqeZwiaHeoyOl1sxdNFa9ZHeiWHgKykJtqEWEzwU1YCB80qAg3y7WV2qt4QXqt3kS6nSsY5R9rTiQCqCufWpLq+dyanb29fCGATSx6ASKSQ2b6goI8yVLJ4N1VMhj/ClJBW5mvsMy8t7zT X-MS-TrafficTypeDiagnostic: BY2PR05MB1974: X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB1974; 25:Vndyp92IQbuIG0hNKdzs5V7dbuCjaKkqc7kAfyVaglIVcMF2igjZ/uinpOscfBbVW7LYxbeVob/YyFx9WK6AQ41Vw4B9ldZrBdI3J32LYUsPic3DxwQUpFJ32/a0G3ucEKRvDwqO9guV5desB8OPNDD8adpgXQ2LAIMlYt4F7YdsqmSVH3CGm0zytyKsF3u9slh9odKO9rPyUXTcg7gMeb9YJytHDbWb6EfcZI8uIr2wEPfhQR2VRFZ8HWra7A1Ld86HIwiKyoo2P982ArAFL9TCSlMDLevn1ES2lEonNo21LuO508xyorhf3+3wP97JioKes2g6h7kagyGAr2PyHef6Tt9YFokYFcFcLB6nVG444s9gzzY6RA0rojfxYs7O+ro2uoURdYtBfiguCB+jkGvYT9S8w7Yo6jfVPeT/RUsvs80S7+50CkQ1aku7XR3uYOXUhthe+qf62yOOMqqjLZtQoYnSErQ5kpy7CAH8XwkHHlJ3JBtYajfia+CnKUtUxyFCTDRHWUClDGumoJSg0j6LyVIwebBssI8HpuPsxoy35Tt2ur/0I6d3wMOI5tGoJgSD5xP2Sa0IKTz6Qxmq6zN1yQWg0jHANrXvSZlMT7E2EbNK3a0XtLvhTjN3oxx4yRN08YknqZJcwqaCyNZpXm3Q1yC9zMu4nHj/xIb1ueF6No1jytHl07RN75THB7V4ZuPGfZgveOWRNYtbvp7hEUfcS1J5tMutqA62HMZaDtU6QkdOCdLyjhAU23xyYrIfuNHOD1gIqBiMctszZ6D6ymHGFKitnLiu6UbOQClc7efG+iTcwhnn4ZquSiK+vYUONIs9uDok0G4zqaqSAp81o0952LLjKlohxXsCEBCVuzhL018l5ovrwb9ameaxHKoidd1okDzeekuAqcZXovt7fb7K4l1Ad+puVhGq11rmS2g= X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB1974; 31:wZGYFmScW21bS1mCYqzt057LPdQJn5tFB32JAtpQSGW5PfwiwWMfJNdCdjR/+UWqMHPIsVmd1LoA5nJQZTyMnAYeDHrIIPJ0c8T7se8y9YNI0m6qy+cv1U/iwYhs0nbJoLsmFG18XqDCF5cKJcCQIveP59JbxgHvH4Qv8nH4VpcO9IezYUEpdQ6rb8CRzH5pIHxfKg5SmZJWiSIsrlglYhbak+hdg6wT7jK2TH6NggTTqAe2aZaOkLbPGrgo6Yf2BlHu2B/kC84TinmIZBm8kMlFdpxKte9ChxFKHOUCnb2+mYI8De+4q49K6SEVHaB1oIR/bQmbpZ41N3bfLiCBskWriXBa1FkEDmksQwfFu0Pb4mgbZpQaEBtYujMu9XeGUd0KovS0/vWln7qj8xpNYIQtwIV0+ofE5uYGRdXUu3pf/eu94hkY7feCht9tgTaNJufIIhAO2vBx/1E5YfC0coBjXpo9jalKhVbeHFZHllvFijdd0Ov6SxToDlY8ggvBvxrWhR9XcAldvx7NL+IdR/ZWtJBLBFqOF0s1yJ+U3snsxUbVyoYktv7alGuErnPzdptuSC9+GdbwWXWcv7vO1y7JuuszKFJlFM14+lI88DpuLdZJPh+mlOJJHm2eHtWpS3jVvnkZ/qbD+LLC2dUL8UFjtJzrkFdSw56fNiwTZOxos/muJHq+m4seIQSFWlJtouagWxElMhfrV9TrSG+aEg== X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB1974; 20:yeCaOcgzbrBXvJnxXVLsx/B7OsCXQTst+L/nRpCiONY/gp1KofPFG9RMiNwzw2Og8x7rOFC5pNdV7DSp3lJ3H7xo0ceGe9sOlon+go8ae8UIQS9eFM+ELs59ZCZDjee+L8NOgRKcOdh4LAeQ121UeUPGjzyzfDGxu0Y2TwxFwsZK2znKBFF4w154O3cpLwbFkX3r1q1RtLGWKZsga0EfT0avkRT6Fyu7Am0biT/LnVQtX1o+F3W6zfts+LX/5PZHuPf7B63QExMHaC/0mWP5NrQdgQrEWU39V6FkNRWoiE0P8yxu/NKCzucwQASQaIH3KFfa8G9XnweDjO/AWnp7chrrruC1TkRKQA2yukXCkNEMO1WDwviieu0IqDcEqERVryZGwKNB558TjZVvlAnZEkauEypdiIemYFFSR0jc/bP8DYFU8l9yUhRP/8Eqf2RfpYj7egHuJ3lpWgTLdR/V9mKZeFxY7gtBZpnk8RrMgZpbg7e8SMng1VkqgEbFhn4a X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(13016025)(8121501046)(13018025)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(20161123562025)(20161123555025)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BY2PR05MB1974; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BY2PR05MB1974; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2PR05MB1974; 4:OgArW5RAlNECy2fw/KIuwMPSAp1MeiXo3Pt/UWOYqP?= =?us-ascii?Q?S9GMLx5gA8MX2G9xoCx1nhk1Sy5MAOnSTtcRH+FyMxeyRUwQj/5ctR8mdOfd?= =?us-ascii?Q?nGZces+CtB2JdUsEI7/HAoIVSgy9PcKEKk3GQuGWIrtnrvEN3t2otLau1ePz?= =?us-ascii?Q?ojLkADKsdCiLxfKadsbUzZKoWBc3KyEp1LqHI4P4Sb0OStzFvlA3nB9J0s0W?= =?us-ascii?Q?rGfuM2OPiliCEdfclkJwb5VidJBlL6/DtSN/FoLOqb+ZFRrtHYob6VO9Rh1a?= =?us-ascii?Q?0/lAhOCplRc3LZ0f6jp06sXLQumJjPtTH2ObI44rL+Eejz/APPhszHwqDpJ1?= =?us-ascii?Q?GheVbDrwvr2OM2zJEsbQTjljC4Y0Pyn1As7vN7cSXKSxGFMOiAZbiTcySyLn?= =?us-ascii?Q?r5I8Du4W7JtYrAiO8O+wxBf0MOOkXBFQSkWR+ygGbbgM/zHICN7O4UPpq83d?= =?us-ascii?Q?qlY/b+qVLmZeKw71kStt1mUvWBZIeezZzxFduY4D2bLGLQKjtkhcN1Lxb0+I?= =?us-ascii?Q?tbl1Ci3L++rSNQR2X62ZM8POXoLJVV7fV1SklcXC9Tqz18tFzhpo+cnKH/c+?= =?us-ascii?Q?8P9oLVg1YxVdA2wAftiIzNQfu6qIfJCWPtztuQn8nDt2hCtHZ1Q/TzmOFPUO?= =?us-ascii?Q?U96sk7Oo1SK721v0SprbgszvMlfEyP49MYT3ecBMxmauSeG+w8z2F83DytvR?= =?us-ascii?Q?pbmgfCQ1HiivPJyARCw89YIAc8Iq7cPRpZDXCz6WZ4hCFOaSZF3mty3xSwh5?= =?us-ascii?Q?NkrfIKSk3xZ4VYAZ/nnYRODRfgO7LK8L/fAobufIlS5Xk3mTVRBbrpb/pa2m?= =?us-ascii?Q?0FvtCXeHwPTPmevVjv54cJNMO1cqOZ5CKW53JvrWDKdKARShL2EwKnivQDFb?= =?us-ascii?Q?FQvegoi1v+IAmZeYwVO57HbeAvQKsgm/YJa77GA7eqmWrS9FEs/Utz2l2S8Q?= =?us-ascii?Q?6BVcLM+yyu12suOkUMK7C2QP32qbrIvPC8otLOhM74bagk7447J24ORxp9Ja?= =?us-ascii?Q?RTRjGnaO0/jtDL/Ohi/Y1VoSwsdXbmm8rALGDLW/212zJTWWfpbMgBsd4Np/?= =?us-ascii?Q?5aG8K3UDNAT+nOcRLpxOXgRnpsBao6c2p9r+55GUUDx4zvvSqvB9VrPz/5ID?= =?us-ascii?Q?MyO3F6vznxjNtaN3xO4ml5xbbTmE+tcL1OiHj6lzv8NaZsfNdk9wzdVyN2GZ?= =?us-ascii?Q?iMuM/m/Z5Avh0waYchFcYusZGkZQU/DVW9?= X-Forefront-PRVS: 03468CBA43 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2PR05MB1974; 23:cECbYezprH9nHI4qawI9RZxUk9aQTE+1+BC2SjOwL?= =?us-ascii?Q?eQxQv0tiyzywn+HIQKSl/dICJHIihajd+6KwXtu8q8B2sLMBZgRRceGig9p0?= =?us-ascii?Q?O1lVafw1ekF5auoPr5g8PxmruE3w3RQx5Je+y0I8Z1+swbE+S1LYYEuVHnXt?= =?us-ascii?Q?3h+gcfTQB1NjR1tJ9OmWdNdJ1W9peT6SPoYW7UetaYk3Z4dNvbHAVr9WZgvb?= =?us-ascii?Q?l3uUBT7dbqCxoMeAmKf80IDJDYD73zOx8lEO+XAsJCcewW4v5YuFGjy+yWFh?= =?us-ascii?Q?cgnniu2TSlVA65nqUIT5hwWKL4VHqcOQjR8utmcBZJHNzHuyO68a7JEWgS4u?= =?us-ascii?Q?spcOilGmbr1MVSN6fqhk31yoJ5fIfEBIPu97w+OBF461Tww+qQWD5CbKgYQT?= =?us-ascii?Q?9x154xykSc+udUm+xrBevimaCo10AyL6f+u9vwfdf7quYexjxWcPg5gtpKbO?= =?us-ascii?Q?W9LTwFl0tGXi4xwIYSIBAQiErdX9NudZciPGwdRXIFRN6jqmKjhqb4u+TzLz?= =?us-ascii?Q?m+MQWqZK+xgCLKTw6aQtiK8ohc2G3rnG8jwmiBZw45TppNz7J+lRA/+Mc9lr?= =?us-ascii?Q?HAbRsNJXQtfGiQ2hiThmwdRXPq4VXw39JaPYQP0DjyUvvrL/gu1hzb36GTnf?= =?us-ascii?Q?VuTiVYvCgET3FwqlYgOSd6llXud0ktHiLUEHcrhQ1xbMmgUMadGs1gjI7hFP?= =?us-ascii?Q?JrnBWSjTD/xmSTu9jgSmnZ5xQqM5mRz+9XTBY2EhngNsoADDIfJpvSxOZf3v?= =?us-ascii?Q?J8xoMcL71b9h7JVGQhQoWDAOzLf8WPfFCWySvyuSGM+yHywsZ/J03snFpcdb?= =?us-ascii?Q?Wya4ptpiiVcAYTtufcqQc2zUWJfDo1fAEIeJXHO63MwRfaIFIUSkeHSOniej?= =?us-ascii?Q?gS58nPw7qHQRBQQdrWLKo4MqDV15vfZAbSF+NEMNpZRl2bqgJcypk4HqlFiC?= =?us-ascii?Q?xRtu+zIt3TMBu8xlDveylwCyyCSK7VfAOCdcVSzMjU7+N9iFzk8CVMTiGaG4?= =?us-ascii?Q?OcnKBIxH7o4sk0rZdkAm7oCbKF3FlcWrkXnhFiKLplAJzZ6kDOMp6rGR5O3X?= =?us-ascii?Q?fc5NTHO+fTqxneNTyjOphXHIdW3NLaog/swaWlHu0lN91umNZortdSK1mGSh?= =?us-ascii?Q?VMDhw8LBf91YkZrNinVDXnhCoVXbe0yNwmIZATQWYnSk00GKqjpqQ1Yg64S+?= =?us-ascii?Q?CI4vI/bHITK6Ko/3sO8Zgdy7nf1SZUuZUA88EEOjF8HJ2aQ/k/7djTyqiKe9?= =?us-ascii?Q?0kux4BXjko5oDI+fcR5Vovg0nw5wL8zHC4B7j9pfspll5uEQkU3kQrZZgoGj?= =?us-ascii?B?QT09?= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2PR05MB1974; 6:OG99Bl5gKaUS6I6x/P/+25no+fQCXD0z2hBbZPNQRq?= =?us-ascii?Q?nJbB8NMhXzYukIQnwevhKxlQGiW8eJiil9RB8M3nYO2Qw/m3XgSghIied/1K?= =?us-ascii?Q?q6k3XebsAqWLyhnKbsf6NlQHBf9gaYS04id9yZ1ShJqYWywKE3/h+YqpJLFq?= =?us-ascii?Q?lKiH8k2U8/y8VhbGOHa/eiC0AL6hHv5GYeMGudWNkN/ZsSSyndGULfIKDvNR?= =?us-ascii?Q?HD9PTHmpsFTmPE+R275drmDHqhQJqvA16alBSz2togYxENOLiDoycdmRlURe?= =?us-ascii?Q?EAvQT3DK9JNPjo9OlAWpziUCcH1InWs0cq5Nq5npPc5hKVcOREk+iuWCBRgl?= =?us-ascii?Q?fApAWu/ktROEnoWhYYkVG/tvbznEKH54JnAo0iYUmeXS5Ca/w9rQjmcLuEHN?= =?us-ascii?Q?XwegkSb8z2XFXHKjRc3Vy0ZbRmRHqzLD4w7utK+YqOTryEF+EMgBSvn+fmXp?= =?us-ascii?Q?trkoh9QuawvlBc3il55Mbaq/Fhcr07eR92fLvP+ehwEMiin1yLbawE34mjdS?= =?us-ascii?Q?RBI0m62t6sEWy1nvF+ZjyUuBm5lqr/ZVJv0Ax3LJb0yFYMpj6BwQ/heKRkBo?= =?us-ascii?Q?p1vDpAvfjzJtSiYShbDiWeG1SQ/qCpyY8ZQs2MGzl1+KQyFNZG0EnUMXZWTs?= =?us-ascii?Q?80iX8wN14pTKNOvkfRtHFFAj2updk6EnCwU0a+Z6KZFm0i0oVs9fi95jqTDR?= =?us-ascii?Q?AetSIjtuAx3ppRADG9fsHHXyclbWQOUPy+4umiEVML0p947XacJVTmoh1D4E?= =?us-ascii?Q?Anj2eo/Wpj5NN3F49EZQX8wrJOITdk4VInsFpG/ewT/78xbZoQzG+50oN38T?= =?us-ascii?Q?3J5p5gVk7W6CYw26HRlHEP/UZxWvwINcquf1zUiWQRnWEQLKcIvXY2ob/iCE?= =?us-ascii?Q?gguWYQXpwwKRRmzm6w5xJd5mOekhFN+yfSvxcEem9qGM/dABPNkdMsDIHFhH?= =?us-ascii?Q?tiXdmow/Ji5xs1ZfohTgt01P2LhW0uIbrEcJxG85Ut0zRexJvcda3fnxnrcC?= =?us-ascii?Q?PFjVLYCyxE2aY3d0AY8QE9?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB1974; 5:OD2DVU2Y9YBsjpOZDsQ75bU/vytslaQTddpyXEG7WqfKNM+MXpif231VGjCo3UAKqK0Lls2QZXnnauMOM5O+xRNfcOYCD/F9xd+bg+NAd6eyw336w7m04SoYHvaL+qyWcDR1qcpXN1jbgka/996bKCNhSXZa66kLp4AVXk3fH8RwP7lcfceAySm43keAulxT7PJyzdDTN3XheulkPTym2G5dGR6aWqka49+pmlXjCmrgDmGWIR10yQlygHGLuopYa1/QW1nKq01suynXH+3OsSKByvXKH+hMu0+9kHmDiIbIGY9I/I1DmcyyLFzMDme5gbqX8/gR27SHkUuRuR17NFo+LtzNsnha+ye4C9OIJ/9aPHlI3l6niPjHQWnjFADmATT4Flb7c3h7XMUj4I86ApeW3j35yR8jn4mw8EEQJuSCtYDhrkn/PH9Cuu2aJy59ykYwsAxK3fpbYDLR2MntMpdaFu0PEyYpbYbTANrX7A/Cd9V0XR8iY9L1YFIuRvaI; 24:2pKnwZISrtcnOZyeQA8Vk6NK3fR2lxRnfETsf469MB4hwvC5Dw8CFn5f9NUKr31QaHRhStPOQfVR15UO2oeiDCvntQ+1CQCuu8SFPP/vT80= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB1974; 7:pUhAK4+UUSvhAY5uWbBnyZuOEZi9IO4DNxaRt+GKSBAflUgxHT6on/9aJ9QUVkMXV8Vqi1XrLV26spB2MzbFUP/ylu24DWU9lezdQ4peUYJSSOUNwAQT0XMtv4yMy9exjRpBLrTKKWScRcOzzYg3VmpYAv6NSEq5Sl3O1K+8/w6NmezMEAthfbou4qayyfgX0EKAwd/6TxETqkmrphkI59Scs96Dhpkm2ZKIkq1KMZkd+OP0ZkknF/VKEJb4YlAcvQxo+KCqdVp5d3irTxXvdp0WqdV72OsRXOmfy9RtgFUJz0BIN8qB3cMDzpa+oDNIIIo3IEcz6Kxk5w+CJLIBfJvCTwFRS4Pn20Mempxxw8STp/wVQSM6hShM5vSKkRWbwvRrLDZwJWhUz8u6MFgIWjurJEcE50NrdiJrTUtKqJFftfGGj1/VvSECCe0G4OyuFF9xyVDKZuBtnv0ODHLe6rDIdWVZwVIstjbNVelwSfyytp58V9Vdq+6/5oWLfi2leBX0lwIXcbwcGLPOTcljxI6R7hACqyeUXQcDMsuz4ylAuqSZpaJCeMuwyZu+hkdjQb6GBct0ISiOmjzyeV4TnQUDSHXt3MQHrfMpIzKfg6rJRXiQBDxmSIqkadQqtrovjgr35LgqVZfk15QXZ8LLtHO471ie8YTZyzFgT5xo0OjulXRCZm51OD3T5yc7FVc9u7dUdGbdAyLL12QPKz1roZru7ldwNz118reky+4pogitzGaS9CmJKoCkA3o8muLYIJwP0KcQ8b8VPVMksxzo5JdeZPybIZoG4KmtKR/bq2c= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jun 2017 08:51:32.3363 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.15]; Helo=[P-EMFE01C-SAC.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB1974 Archived-At: Subject: Re: [Curdle] RFC 4253 possible errata X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 08:51:38 -0000 Hi denis, denis bider writes: > (Removing the SSH mailing list from CC under the presumption that most of > those who are interested are already subscribed to Curdle, and don't want > duplicate messages.) > > Correct me if I'm wrong, but I'm not seeing a way that a cooperating > implementation would send "e" or "f" that violates this requirement in > either way. The likelihood of accidentally generating e=1, or f=p-1, is > orders of magnitude lower than accidentally generating one of Satoshi's > Bitcoin private keys. If I got a genie lamp that lets me generate numbers > like this on accident, I'd rather generate Satoshi's private key. Yes, I would NOT expect an honest and correct implementation to send the public key of e=1 or e=p-1 (or f=1 or f=p-1). The check is there to detect and fail interoperability from malicous peers. > So therefore, it's not meaningful to talk about compatibility here. It's > meaningful to talk about contributing behavior ("e" or "f" is random), > non-contributing behavior ("e" or "f" is fixed but valid), or sabotaging > the DH key exchange ("e" or "f" is invalid and results in an insecure key > exchange). > > Which view in particular are we talking about here? Because valid > implementations (contributing or non-contributing) will not be sending f=1 > or e=p-1. Ever. I believe we are likely talking about a malicious peer or an invalid implementation. I am asking if it desirable that I include the following text into draft-ietf-curdle-ssh-modp-dh-sha2-07 | 4. Checking the Peer's DH Public Key | | As specified in [RFC4253] Section 3 contains a small errata when | checking e (client public key) and f (server public key) values: | | Values of 'e' or 'f' that are not in the range [1, p-1] MUST NOT | be sent or accepted by either side. If this condition is | violated, the key exchange fails. | | The problem is that the range should have been an open bound (1, p-1) | which means 1 < e < p-1 and 1 < f < p-1. This document ammends that | document text as follows: | | DH Public key values MUST be checked and both 1 < e < p-1 and 1 < | f < p-1 and values not within these bounds MUST NOT be sent or | accepted by either side. If this condition is violated, the key | exchange fails. Or, perhaps: Values of 'e' or 'f' that are not in the range [2, p-2] MUST NOT be sent or accepted by either side. If this condition is violated, the key exchange fails. | | This simple check ensures that the remote peer is properly behaved | and isn't forcing the local system into the 2-element subgroup. Or, perhaps some other set of text that basically specifies the tightening of boundary checks. I ask this as Eric was concerned that argument validation was not being properly handled for Diffie-Hellman MODP groups as compared to how TLS does the job. Thanks, -- Mark From nobody Thu Jun 22 01:54:51 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BCD4127078 for ; Thu, 22 Jun 2017 01:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_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_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=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 GvEIclIXlP2J for ; Thu, 22 Jun 2017 01:54:48 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 747DF1200C1 for ; Thu, 22 Jun 2017 01:54:48 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id e142so3501204ywa.1 for ; Thu, 22 Jun 2017 01:54:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=l15lbnIee3tti4JnOqBowBBItD6buJlba8EckE60ofw=; b=qblylyXD8qu2208z1OYFAtPwmBZ7N+wf/m8qpks9QdXTyUv38+pjT4BdNeqF6NE/I5 D28Ejv9CydLV2uYLQfCLNjU97YWAx8cIv4bj1xSRGh58xdhpkHXOAh6Dd0uXA61T+6ao qxRvCeVmgBwR7wX8+z7acmjflQ/mh+NWJj9SOABaE5MSfb7V5pYZZ4Z+BAn603C+gjJb S2gaBYg9MsotWKXQyQRs7KxC5cH/4unSMNB2LQgaB2pGR5nKe1269srdY9JrUhaL5SJO CLsfPzMXX1OffARSFeFK5O5SXMvmhdHaHGS+2fw9gWzeTcq82psIYRRSVaVP1rvhnPMs hFlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=l15lbnIee3tti4JnOqBowBBItD6buJlba8EckE60ofw=; b=gJnSVXfsbYYglieB3zygxf1qI4Qq0fIV1Yn5OhbI5mxY5u283I+TJDNDsqN4CjoIjQ hgD8o2eAb3ods0zIH05G7P/2TYJF/4E1WAnExQoqn5JhIqOnYAiU0Itoa425oGjJarKL vPeglVq4FwFfBjfWid4wT+mZzat+BSPWERgFAGqXSsF2YdMFGQcxjPzaFolo4nVaRngx +bEB+mvTpoUBL1bLpzmHuHKETN8fJzbngtFB6LmQDFr1qjcLKocLoc+Y8o1lXq0cCIsv J2go8KjtnUSS37c1fPXh3JHz9Qqr1hqagB51U12iV7m99G6haxgZnVVwqzaQD6AJkYo6 DYYA== X-Gm-Message-State: AKS2vOzDZkr4cpsyAwmVKNUSJNy7dPOcTYq0k/1WiE/53b8Rg8dyd7cw 0nw6FERRD05P9Cys9GCu4AqEoNmmHw== X-Received: by 10.129.40.149 with SMTP id o143mr935903ywo.154.1498121687772; Thu, 22 Jun 2017 01:54:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.174.65 with HTTP; Thu, 22 Jun 2017 01:54:47 -0700 (PDT) In-Reply-To: <63844.1498121460@eng-mail01.juniper.net> References: <80212.1498069205@eng-mail01.juniper.net> <63844.1498121460@eng-mail01.juniper.net> From: denis bider Date: Thu, 22 Jun 2017 02:54:47 -0600 Message-ID: To: "Mark D. Baushke" Cc: Curdle WG , Eric Rescorla Content-Type: multipart/alternative; boundary="001a1140865a07b5d7055288a315" Archived-At: Subject: Re: [Curdle] RFC 4253 possible errata X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 08:54:50 -0000 --001a1140865a07b5d7055288a315 Content-Type: text/plain; charset="UTF-8" In this case I think Eric's concern is well-founded, and the errata should be added. It appears there is no interoperability issue, there is simply a failure of the spec to correctly document effective defense against malicious peers. This needs to be corrected. On Thu, Jun 22, 2017 at 2:51 AM, Mark D. Baushke wrote: > Hi denis, > > denis bider writes: > > > (Removing the SSH mailing list from CC under the presumption that most of > > those who are interested are already subscribed to Curdle, and don't want > > duplicate messages.) > > > > Correct me if I'm wrong, but I'm not seeing a way that a cooperating > > implementation would send "e" or "f" that violates this requirement in > > either way. The likelihood of accidentally generating e=1, or f=p-1, is > > orders of magnitude lower than accidentally generating one of Satoshi's > > Bitcoin private keys. If I got a genie lamp that lets me generate numbers > > like this on accident, I'd rather generate Satoshi's private key. > > Yes, I would NOT expect an honest and correct implementation to send the > public key of e=1 or e=p-1 (or f=1 or f=p-1). The check is there to > detect and fail interoperability from malicous peers. > > > So therefore, it's not meaningful to talk about compatibility here. It's > > meaningful to talk about contributing behavior ("e" or "f" is random), > > non-contributing behavior ("e" or "f" is fixed but valid), or sabotaging > > the DH key exchange ("e" or "f" is invalid and results in an insecure key > > exchange). > > > > Which view in particular are we talking about here? Because valid > > implementations (contributing or non-contributing) will not be sending > f=1 > > or e=p-1. Ever. > > I believe we are likely talking about a malicious peer or an invalid > implementation. > > I am asking if it desirable that I include the following text into > draft-ietf-curdle-ssh-modp-dh-sha2-07 > > | 4. Checking the Peer's DH Public Key > | > | As specified in [RFC4253] Section 3 contains a small errata when > | checking e (client public key) and f (server public key) values: > | > | Values of 'e' or 'f' that are not in the range [1, p-1] MUST NOT > | be sent or accepted by either side. If this condition is > | violated, the key exchange fails. > | > | The problem is that the range should have been an open bound (1, p-1) > | which means 1 < e < p-1 and 1 < f < p-1. This document ammends that > | document text as follows: > | > | DH Public key values MUST be checked and both 1 < e < p-1 and 1 < > | f < p-1 and values not within these bounds MUST NOT be sent or > | accepted by either side. If this condition is violated, the key > | exchange fails. > > Or, perhaps: > > Values of 'e' or 'f' that are not in the range [2, p-2] MUST NOT > be sent or accepted by either side. If this condition is > violated, the key exchange fails. > > | > | This simple check ensures that the remote peer is properly behaved > | and isn't forcing the local system into the 2-element subgroup. > > Or, perhaps some other set of text that basically specifies the > tightening of boundary checks. > > I ask this as Eric was concerned that argument validation was not being > properly handled for Diffie-Hellman MODP groups as compared to how TLS > does the job. > > Thanks, > -- Mark > --001a1140865a07b5d7055288a315 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In this case I think Eric's concern is well-founded, a= nd the errata should be added. It appears there is no interoperability issu= e, there is simply a failure of the spec to correctly document effective de= fense against malicious peers. This needs to be corrected.


On Thu, Jun 22, 2017 at 2= :51 AM, Mark D. Baushke <mdb@juniper.net> wrote:
Hi denis,

denis bider <denisbider.iet= f@gmail.com> writes:

> (Removing the SSH mailing list from CC under the presumption that most= of
> those who are interested are already subscribed to Curdle, and don'= ;t want
> duplicate messages.)
>
> Correct me if I'm wrong, but I'm not seeing a way that a coope= rating
> implementation would send "e" or "f" that violates= this requirement in
> either way. The likelihood of accidentally generating e=3D1, or f=3Dp-= 1, is
> orders of magnitude lower than accidentally generating one of Satoshi&= #39;s
> Bitcoin private keys. If I got a genie lamp that lets me generate numb= ers
> like this on accident, I'd rather generate Satoshi's private k= ey.

Yes, I would NOT expect an honest and correct implementation to send= the
public key of e=3D1 or e=3Dp-1 (or f=3D1 or f=3Dp-1). The check is there to=
detect and fail interoperability from malicous peers.

> So therefore, it's not meaningful to talk about compatibility here= . It's
> meaningful to talk about contributing behavior ("e" or "= ;f" is random),
> non-contributing behavior ("e" or "f" is fixed but= valid), or sabotaging
> the DH key exchange ("e" or "f" is invalid and res= ults in an insecure key
> exchange).
>
> Which view in particular are we talking about here? Because valid
> implementations (contributing or non-contributing) will not be sending= f=3D1
> or e=3Dp-1. Ever.

I believe we are likely talking about a malicious peer or an invalid=
implementation.

I am asking if it desirable that I include the following text into
draft-ietf-curdle-ssh-modp-dh-sha2-07

| 4.=C2=A0 Checking the Peer's DH Public Key
|
|=C2=A0 =C2=A0 As specified in [RFC4253] Section 3 contains a small errata = when
|=C2=A0 =C2=A0 checking e (client public key) and f (server public key) val= ues:
|
|=C2=A0 =C2=A0 =C2=A0 =C2=A0Values of 'e' or 'f' that are n= ot in the range [1, p-1] MUST NOT
|=C2=A0 =C2=A0 =C2=A0 =C2=A0be sent or accepted by either side.=C2=A0 If th= is condition is
|=C2=A0 =C2=A0 =C2=A0 =C2=A0violated, the key exchange fails.
|
|=C2=A0 =C2=A0 The problem is that the range should have been an ope= n bound (1, p-1)
|=C2=A0 =C2=A0 which means 1 < e < p-1 and 1 < f < p-1.=C2=A0 T= his document ammends that
|=C2=A0 =C2=A0 document text as follows:
|
|=C2=A0 =C2=A0 =C2=A0 =C2=A0DH Public key values MUST be checked and both 1= < e < p-1 and 1 <
|=C2=A0 =C2=A0 =C2=A0 =C2=A0f < p-1 and values not within these bounds M= UST NOT be sent or
|=C2=A0 =C2=A0 =C2=A0 =C2=A0accepted by either side.=C2=A0= If this condition is violated, the key
|=C2=A0 =C2=A0 =C2=A0 =C2=A0exchange fails.

Or, perhaps:

=C2=A0 =C2=A0 =C2=A0 =C2=A0Values of 'e' or 'f' that are no= t in the range [2, p-2] MUST NOT
=C2=A0 =C2=A0 =C2=A0 =C2=A0be sent or accepted by either s= ide.=C2=A0 If this condition is
=C2=A0 =C2=A0 =C2=A0 =C2=A0violated, the key exchange fails.

|
|=C2=A0 =C2=A0 This simple check ensures that the remote peer is pro= perly behaved
|=C2=A0 =C2=A0 and isn't forcing the local system into the 2-element su= bgroup.

Or, perhaps some other set of text that basically specifies the
tightening of boundary checks.

I ask this as Eric was concerned that argument validation was not being
properly handled for Diffie-Hellman MODP groups as compared to how TLS
does the job.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mark

--001a1140865a07b5d7055288a315-- From nobody Thu Jun 22 02:01:56 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56C24127419 for ; Thu, 22 Jun 2017 02:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9eZM6aTXW7V4 for ; Thu, 22 Jun 2017 02:01:53 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0137.outbound.protection.outlook.com [104.47.40.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06A86127078 for ; Thu, 22 Jun 2017 02:01:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=O+yPte9yKbWJyhn9KohWA8YkbENOJaR/QB5G4u3HVf4=; b=dfBZt1KeiUXfb3aIqbfYCkAIvj/NlmeP0NJcZbhvGCngfhZXlEQr3eArysUgWVtRqRElAW7rhExsX+rNlboVoh8k4IK9UZKbgqFY3ugU0cDh9+31lBAFwTIJL716N5j93U599UZM8rpdGNIXeQtofckuxIAQ1X6NAyR+YdHhNQA= Received: from MWHPR05CA0012.namprd05.prod.outlook.com (10.168.242.150) by CY1PR0501MB1306.namprd05.prod.outlook.com (10.160.226.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.6; Thu, 22 Jun 2017 09:01:51 +0000 Received: from BY2NAM05FT007.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e52::204) by MWHPR05CA0012.outlook.office365.com (2603:10b6:300:59::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1220.5 via Frontend Transport; Thu, 22 Jun 2017 09:01:51 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.15) smtp.mailfrom=juniper.net; gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.15 as permitted sender) Received: from P-EMFE01C-SAC.jnpr.net (66.129.239.15) by BY2NAM05FT007.mail.protection.outlook.com (10.152.100.144) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1157.20 via Frontend Transport; Thu, 22 Jun 2017 09:01:50 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by P-EMFE01C-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 22 Jun 2017 02:01:50 -0700 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v5M91nRP030839; Thu, 22 Jun 2017 02:01:49 -0700 (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id BA4131141B; Thu, 22 Jun 2017 02:01:47 -0700 (PDT) To: denis bider CC: Curdle WG , Eric Rescorla In-Reply-To: References: <80212.1498069205@eng-mail01.juniper.net> <63844.1498121460@eng-mail01.juniper.net> Comments: In-reply-to: denis bider message dated "Thu, 22 Jun 2017 02:54:47 -0600." From: "Mark D. Baushke" Date: Thu, 22 Jun 2017 02:01:47 -0700 Message-ID: <69116.1498122107@eng-mail01.juniper.net> Sender: MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.15; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39400400002)(39850400002)(39860400002)(39410400002)(39840400002)(39450400003)(2980300002)(199003)(189002)(9170700003)(8676002)(356003)(81166006)(54356999)(76176999)(2906002)(50986999)(86362001)(47776003)(8936002)(2810700001)(5003940100001)(50466002)(53936002)(6266002)(110136004)(6246003)(93886004)(38730400002)(48376002)(117636001)(5660300001)(39060400002)(106466001)(189998001)(305945005)(6392003)(7846003)(7126002)(478600001)(54906002)(53416004)(77096006)(6916009)(229853002)(76506005)(4326008)(55016002)(7696004)(2950100002)(105596002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1306; H:P-EMFE01C-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:ovrnspm; A:1; MX:1; PTR:InfoDomainNonexistent; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM05FT007; 1:4KdqIydsBkhq4BOoZ0wLRmT9wa/MWPOc7Bmjem6R5GqwLJTjtXcYeh58PJLgeaxDI3u/XcEOZOquglbLVa4ZJ/oBnqyCZsqWFO/yLGPAQQaNHenlQMFjT0cnPxBOWLtJJMjKKDz7xQU62ip5WCXfiOufK/G2c+JnnvFXl55Aa7h3zfRAisFr0QVBF3r2JZ6xW5bT4CDOM6cJ3COYfCuc0sRS1VS1IXGU0/P6WZUkMLas4a40uerwYtbCrFyEMMvj7morFYg5yUuNgLwUO6OBsBU8DnvILN7OxvI6BCH3PUnehPXBMAJ0H+xFHSByizFRHn1U7QSmNvsA16BxSoYpsmO+N/yysv3araJzI+KFt72RY8S7G21TZXJ31TTQ/GYLHOVz8f6gta2ufE72rj2/WbIJxiLDWbyYeWw5f4xg+935tPQkKtUP8Mn0ksVI1yECTzoggP1WpriPxzYQ30WaNi90KSpJ3Mv5+Ug788p9UccZ2Q4Jj3ZZD89TTubqisis X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: b4e2e0ec-5669-41df-4a9e-08d4b94d5261 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:CY1PR0501MB1306; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1306; 3:veSSqx65bsFIqZs9wetdbbSU3NxQtgbwXO+6eRdqWdodmlmFtyY/LYwqLHpkOwFakcCtVnUUslPR6nEUoBS4iIuYnhk+TAkLAWjEHvSC1Fy6kjw21enO6Q1380Jbs8brl+ZwwXc+p6iQ16/A7Xwsz1NcKJnsWiYTqYJGrOm5AETj7hO2/5sx1BLVx4r14yokgwxD2OJOqcswz0tZlUVxjRC+AwyrJuZozvF0MfQx0DctQ4UyywF74OZTyVuX0SJIs11llhBbn2WQZn8AgrhtZOsmqhBIsb3HgbzAkIuBgCAP0/1wargIZpYm1sy7gSTjd4fpZ1zeHBPcmHgit7OS1+Uu/KVRdWZD924BrQvhyTHPQHdZXtyrR6ap69jjMaAug8FfpudgwqPcfDbpA2t6t8GBX+F/xc4WeSD2ZHWQnNpwaGwBzr3HwyQg9M7JKA9+yY0PHsggRCklLLsom/ez4Q== X-MS-TrafficTypeDiagnostic: CY1PR0501MB1306: X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1306; 25:N+g0yhflk4/LeY0JUK2+QS5e8WDxUOv4L4wk37Bx3rnKzZeQ4gGd+nK0lhoXLdTPFKjlHyjhcuZGz16FlPSWwTcFbVFoVXUBbtTImra5kyNyIx1yg6y0yrk4cNjOTe9e9OULrIk2pWVarWnItWlOh8GGpzndMmpf+TGSqxE9+ykpVaDMIhU4XhWyg+anDJJZHCMV5wWMsvdYfineYhXKKnzAi+eE7n5Y9aLHbz9tvt8IHl7vs4/5FeI0KOrCAj5rHXVioxReBX6y+8aybjOLYTC966+nydY5r3OYgY4z1S7MbxD66gKa10cH9v8R5RLFN3dEnj8k4KmoEmOnqVY9uBL55W9AFouy7PP4ETERxcZu4Bo+7IZ7Cn6i0pNddw53JBw2riguegPUgnXn/DlTuwELu0kne+YxtUia6H9brKQJRbG8KMLJpCNr+YjFSq8lkrkScRq4ryEAxmiaO5uxmNkxtTC1icNgb/5kWx5e88U=; 31:iNVMRUPtMVvkEsvOOFihIvDnFg53YnKZiJtSWx0Ys75OTL9fYITUZOkO5uJmOCL8d/C7J2HNhiuFcKgXT5L9wIqReZn921FQWKsLYQ8QUOpuxWBcBJjElPY93htzB8G/oOgzngA5vPbowmKTB3yyyV1QM8tgb3Wfsoei7/TeA12yWKg7EY9ak9KVfqwpQcE4UU8mS2dTykonIgead13EhAjoP3oR0OrltY0zuhYQaZQtKFKqheYggzYJIdGEIfCj3SLy7Ict+lngOtuIoAfELw== X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1306; 20:ZnMROwU6Q616WBHAFmYNSqmAj/KQHsVS15A18pFB5TIXeUgYzP3QJkp50RclFfoC5U8Hs6sQNxCdvzJMEulbIGTGeo/1Nnh9AauTL3XaVA/bkKUs4lfrZgy/S36si6tO2fPSvGXfvGR1BrCJlXEPYVBgZ1KErg+FKLazhzjI7V1oMpBBQHdl1cq7uzKbhFdy4sAytLMamLaQ4dzx8z+TkSiF2DZF+Gb8x7iDMt265SYzaWH+ZJvjasOAHQJaJhZ/LedPp4nVXkLZBE0m4/yVPHkSqHBjMyED3WGQTgpIbIsHzcWrenbHJIjsEp7uHZwwYbXQxd6Xo7L55UlP47jD6gRtEu/RsnUiFEIoPsgtuJdcA4j1UItOcf1mi71kdNS6hRuRuwSmnkNe2aS5eYEPUKAnkEzVS2ZhQwcxoUPIMFmz8Id+RcvJflyQxt1GxvADiFoLLCDtw6HyYZi4UbEI/CqSsD/5d6Pcl6ZH+GQP6eeJExxZwvucutRpqADzVxuu X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(13018025)(8121501046)(5005006)(13016025)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123558100)(20161123560025)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR0501MB1306; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR0501MB1306; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR0501MB1306; 4:omQrlRBAvLisQdPq5u0740XOr/dFRdK8IhbmBUJX?= =?us-ascii?Q?iLv6hg1dtrovAd/0b/HCXozSQZhGZI10/3sD8Le3L8K+mQoVz9z3cDiXiv/W?= =?us-ascii?Q?aZJCMFhN86aTSzH8oCFOxRiQkRm8OUJqiD5HCmQ9E+OIejv78IJEcR2reFdE?= =?us-ascii?Q?IQrzjY/V+odGP4vvVfmPCcc3i5S2Ze/1YnBua23lIe49V25aWJRHtQ5w6/HQ?= =?us-ascii?Q?EVnjbyHDkuLuuEAcnhBQ97C+eeAbSlb1+indOxCZ6pSuA6mLCtR4bhNOpT5V?= =?us-ascii?Q?bn0uKIB1/xKiGPgV8UBFfuPd+KKA0e4sZ9EqGvCkx3zagzdqcbxMs1/lbG8i?= =?us-ascii?Q?8KwZvXJoMr7Rnb3yJzoJ5WH1Pa7YgAwuaQgh/9ymu3m3BkcNu2kBcABwW6SG?= =?us-ascii?Q?zc+eSdG2IQDThKOAdJJjjETQLcD4JUvcC4YvVVPH/BeCHS/CX6wQPZ7Rw5Dq?= =?us-ascii?Q?iMNg3miFiX7s8tuzfe1GmYCu9tMw84ytZbLxN1O5X9YcCMHHk5zNXSi6GIGX?= =?us-ascii?Q?+f6XeAbRonyl+t5D7WZZASqac754YdABghkmkPAtsYBdKWAeaoyfvm8FAH+i?= =?us-ascii?Q?LEocr3KubY66jBeIiVmij3aI9Q6jS179LE1t/rZdnrlSKU4FpALDgOkz/Nsg?= =?us-ascii?Q?3d4dNStMRDfwuOVL1UDxcArVVO5sBOvCVzdPfVlFBU228CXGjotpRMnYdbg8?= =?us-ascii?Q?W6fGk5wCuJUT+iY4/+T1fuLUN4STU4KkDoYKb1Lxvog8zb8KtlABgHVEgWpF?= =?us-ascii?Q?fj/mE0CZPuu9HYrXKnKNSjj5TqI6J0GAxZYjmvJTpVAAnq+/fjMhuFqWVUjx?= =?us-ascii?Q?EjfSCzCWfDuus8190qST228ZcftyBrEhuwdMssCgaGn9mpDMFX9Aw8ePAz76?= =?us-ascii?Q?iTvn0wvtEXjypvR/9T+whiGINtXfWhHIw5nASMR1Vsqg4GCzGhelt4TGCg3N?= =?us-ascii?Q?6mLNTzJYFIs+XgOxb1/ECSzAwPHFMRfEhVEUoOc8Smk4RDyI8faHOO9ZdXH3?= =?us-ascii?Q?FsPKGqt3vgHWh/0xLL8hUsk8QnuN5Yu7g1/hQrmi4Rn6q2iRIKO+EOgDopKn?= =?us-ascii?Q?nkgh/QhCE0+W61Y0q0KWz3l4M2QvgyzZEW/QVCM0Dc64zq7mXvCMMbg7SkPI?= =?us-ascii?Q?twU4yiRof9ZwvUJdWT0g6nqt1kWrQ6AGkmNOs11f97psNgT5nCPXReneBn8R?= =?us-ascii?Q?axDcC8B4RFBLqJy4NH8WtXW0GP4E4uzHP7bj?= X-Forefront-PRVS: 03468CBA43 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR0501MB1306; 23:yh3AlKEs71jJ6tGqgokP1x9YbdTj+9uxREesWCD?= =?us-ascii?Q?UuL5TY6/Ubv8nzNaNww83tDNK9bTQ/7Benk8Q5kvFVvZX46lz4C/HdFGzuGX?= =?us-ascii?Q?wK2EjD+wCLyKv5whgBBY0fTaEXRymMGm42p6NBfktpZrN4Z+Sjmr1v4mCXG1?= =?us-ascii?Q?TBTagnMPJ4RrYqSnGS3X3GEzaHzi6R/2QPKKtjOnxQiwc/q8+vVPWhlN6LvD?= =?us-ascii?Q?VPaAIebTRjWoxsvmjV4L9q+0/b011cx250jHmgXoWErEArn5FDHOdJtirzcL?= =?us-ascii?Q?lbYjVNvk+twqVwLjJfUkt6mPbWdBiAy2UT/jXcRH5e84AF2GEGFPqpkKF5Un?= =?us-ascii?Q?G37cHklNx5VKAgOI0mFoiXCQe9bjocsPCv6eDP6POw5RM3BIKo9FP+0BC3Ir?= =?us-ascii?Q?zCZNKzmHCNHHZWerLqOWldT+5tBvUQ5vDyJdLJnuGa/VIT7JcCGGsdAJ01Z4?= =?us-ascii?Q?u63FVm8gNKKvJ7jJa5aArjUv0lSwTCSosgQPq1RBOv6VOiUwwa6DPBAaFfFX?= =?us-ascii?Q?r23nuoG5moV1vBGirBP/RFvAJg9o2UzRwRyRgFt4IGwUPw4reqIPVLBkIg21?= =?us-ascii?Q?ynOXQQr52L+BmTjydFT/a7i2oE6tQqrn4S8qFU2Tqt7lujDcxY9qQJ/7i7sn?= =?us-ascii?Q?ytAodVhbrzd0snonRtoL38IeZfhPMXZTmfT+LLNUo8KI1oJrtxm7HQPBVa0c?= =?us-ascii?Q?AxePZkrtxmjoNL9zd9THcxXy12A8vkSc+rHYWNirn/fE1PGtTXS9hma4NOaA?= =?us-ascii?Q?LAjGlCakN8cA5TTgvhLpGREg/Oi0w0qfnT8UK2+epSwZoHPoep4NmQGER10K?= =?us-ascii?Q?XvXfgrVI0jKKhMEfht2j8hjd/dMauALbOA+gohj1rNfCbJrkISBvtgJRKB/4?= =?us-ascii?Q?KqmDry7yJCLNTB31ksiqdoNGw8D50675QfzJsBJ/yJXS8nvGObKpDjB4ApJg?= =?us-ascii?Q?1pvAKzb1y0c2McQvc0wnhv5MBlv9LSEc+9Mv1a6hWxjB2HG1XDgKF6qcUwsu?= =?us-ascii?Q?skVBlowAR5+wrkMtI0GXPehtST42M4/wJrZTGgl6tQ+NJUJ4SwQVOJZjBk95?= =?us-ascii?Q?d79QlCJ4ekFH1225fCbKoxLbQsurV/nA3nm8ySPThccQSpR1iLVbSbpVf5T9?= =?us-ascii?Q?tBW+TQnZj2y6lS4BXVnY8v06tMEn+9TvVbDCdCV6SGD20vS176/kZL6XYwar?= =?us-ascii?Q?jVDEb2R3ZHKVgBvSdlfik9/wknzZ7Op9mWGZ+WxW6srztfmfeL4/vaXZ7vWb?= =?us-ascii?Q?Bymsr+bifBiZBMOtf+dLVg/VPdmpWBQ3kz1eD5/cTglUg3boFCnLLkViyQV7?= =?us-ascii?Q?N9jqy5Yimt3iEb4rxJUZwRXY=3D?= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR0501MB1306; 6:3q4UjrrDZAD5pO7d4i7YslK20cwHdcR1Znfv/liU?= =?us-ascii?Q?ZuRiDWnJiHCyqa6PL4LnR4N4hsQuqPhCQ6cqxOtZLpEeOu+E8/IXHYDkH/St?= =?us-ascii?Q?EXejmWAniQaGXaVOAowQOtlY0UhdQRhtv1p00KxAkUlZfk919NiNSuAREmFM?= =?us-ascii?Q?GJ9vfZ5US7SzVnQtcdLY9u8EroIKHYNYM7rfvGnN8qvXkYSXpFOpANpSP2Is?= =?us-ascii?Q?/xgR/IFjJ+YVWtOjvPweiEwVLRK6WPIq5N0zDK+GYQ/UwITKrFTasw9E4UgH?= =?us-ascii?Q?ZjMSfKMne8FeKhvlJAjOKnL6jf9dGFB0hElIpyfP1j/hXPc0a8l4qHXN2HVN?= =?us-ascii?Q?F4Z75OnrPakyLqm6vqS42ynsPSY6dymgqEVxtsjdZ6wIIPCPNAd05hro58AC?= =?us-ascii?Q?SZMmKKEO1h7YOw7jNjIqcRbhFA1oEWDdbovQWVxK05pR1F2jY9Bxf9T40/xB?= =?us-ascii?Q?JH5LCDb0ZgGEDjviDZ3CjhwxTYBDNw9mRQhGEBq6TzMA7PP2ooKlxU1GlhUy?= =?us-ascii?Q?fRzLA9zMplOA7zzBLNwbjNZCBgmUZKqq1fza/P/eApkgQ4d2lL4AmeblugMJ?= =?us-ascii?Q?L4kRF9uc4kzYAbi+Up8kT+uLRZtsnvD8ZxqblAd8db/BZd1DwRpSp1JcyY56?= =?us-ascii?Q?WLFf5WID9pUpVFcG0IrJi0ohW9ZgYq753uf0PF0ODOoBuUziXmmQmx7gfsm+?= =?us-ascii?Q?0ELAgM/r4gGamHm64mCmWcrDgv+G+LbJO+noc0TYC8YM1lVJckRGgb17kn5G?= =?us-ascii?Q?0qECTCprliLp8YpC3vtCGTMHW3SxmjEhVvqNxaeyFyyjKWIIRhcCkwgAy/BD?= =?us-ascii?Q?SsZ6b/32TyfV1iK8wgNsBWAAUtIkA1t7/zH9tyz0PtLpujI/hDbh0iPH8Qbl?= =?us-ascii?Q?jLDMBcmAH3ckW5OkfKE07uy8wofSJKGbnARaBDOT85IXVhgDrCHZEzdfyyHE?= =?us-ascii?Q?MCah+ntJa4roDjUFn3JxxDhmrIU0pFwDwWsFg8wkPwRS7PQ+XnVSJ9kpwMw3?= =?us-ascii?Q?LqfHZ1r5OgcqTOrI2ZdLCL1f?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1306; 5:FYKr0ty4iwjYIEmn+BZoTx58JEPCUn0bqwdjZLxFI5s9ROZNpPHAGVh3FhV/6TbX9+yEidsra8NykzwXf3W+hauEH32ze5bbIqlRu1guuw5IVIYpYGaLgP58imQj+GykRHqtCwWS52n1vFFnCnT6iBW1GwqM6CwDXw+0dfh0YrLCDRQPNs3n22RVoFlk4eLgbgGApKGpT2XNJ86L1OubngvpoTWGxzViAZ1ofL0Mdq+rCce5yzl9NXhXLw8DmVOvCsQaVfrhNcYuye9zzLARMsnkGl1H0bSaO1TQ976NeNskh2Wi9O+Mz1xdqZjP8YD8vxnu6ZikgF9cGb4Vr7Ik10VijbhxGzXQGEy9i/zOhuj/7xCs6/ELhopI8NYWCqQqoljpq2cIbRPRu26IfsShWJA582c91ViV0+gduMZqUHF9kRyNpkacIzbSH40yG5egZfbowP78SD7ftHKixu7TAULqUN4q2BFrQP4KRpSezJ4E3JD7wrYvcs7IWXor5Utc; 24:GK4uG67ZQJFlj9RmSXbUy3LeK8XqSi+mX3XdbA+vT5JE7voSbVzhJhSz6hR6Dp8hAcXpTF8tcAzoDyQQKohgVusk7VgTH14EaTyxKOhvrkM= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1306; 7:iTRnFsu46v2uka2FBQbzED6Ge187n3uYX3ONZu8GO0+/ymkr1CiX46unaSOtO31UD6DR4bye6ELQXnB+NnNjv7oOGWxjTPnGCglbDkmW6H68KCEj+HyA8Q7Kk6SXdlD9MdHxoWqPCcWi4Nlvql1UpwJHp0cxUlUrHOTB7mWTg+L0dk/0kJeAdCKibma3wobkk0mYNi8XekE6fvWtVh/QOvtpXvWDwhDqs5km9CEfDavgwq8g7Hpbdb6JHJ/kpd0G9QxsPxGhIO9FTBVtMA8sGDkrhTyXpq+WrY+jbqel/OSNIjHqA7YTwW74k4hZhzt+UrhOOnnLwgVNNMC6jvoElargTvIeeibH8QYbR1o9ALAJqJls0f7lbuuYgYzHpQSDBM0pEtl0jC3UtzFFaWpSf225LYGN+lVnA7rFcVHiF7tzNzEGmv6kWFPWxABR5AySD0sYPLR/3XSkK357IqHn1lRxTFJJ6UozytseqzalzhVXhENUlQOLW6sjS/RoXcMWEpqwVB+JriDmJ8fhZ9piTtDDiRL+twBq7Xwrqzz3tZ/Nyi9HqZMoCLpMvGNCTMEmb/yLjmrUJT+8SZvD/YXwdlS+vd6AZd8xofZ0AJMdBGPt5HXm2aKj973JRykc5jY1V9f6PyUaG3QyPFjEeA9AoMo2dNZZzMJngShL6kWXVyOBf/+8niIwlEQsKDHiABEKo/rA4lvd3giJbPlNBS947xv4jBG9a9vzY+Tscy6KBf4JnR+TCDm1yVYZAvYH+n1R5MISkviII98IEygY3eZudRRNlLxmGUI+0lvPm3qad2I= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jun 2017 09:01:50.9623 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.15]; Helo=[P-EMFE01C-SAC.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1306 Archived-At: Subject: Re: [Curdle] RFC 4253 possible errata X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 09:01:55 -0000 denis bider writes: > In this case I think Eric's concern is well-founded, and the errata should > be added. It appears there is no interoperability issue, there is simply a > failure of the spec to correctly document effective defense against > malicious peers. This needs to be corrected. Thank you. This is my belief as well. Does anyone have a preferences between these equivalent notations? 1 < e < p-1 (1, p-1) 2 <= e <= p-2 [2, p-2] for the Errata as a replacement for [1, p-1] currently in the RFC4253? -- Mark From nobody Thu Jun 22 02:19:06 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF57128DF6 for ; Thu, 22 Jun 2017 02:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 p109lRZN8zRK for ; Thu, 22 Jun 2017 02:19:03 -0700 (PDT) Received: from mail-yb0-x22a.google.com (mail-yb0-x22a.google.com [IPv6:2607:f8b0:4002:c09::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 72E63128DE5 for ; Thu, 22 Jun 2017 02:19:03 -0700 (PDT) Received: by mail-yb0-x22a.google.com with SMTP id 84so2886764ybe.0 for ; Thu, 22 Jun 2017 02:19:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eGM7TPeM72/AkSkeG0yP2qeNkE1jzjZ6MJZE8SuXN7Y=; b=B9hvlDz5EwfYec1SgCgI4PhmHzAwIkwRZGDQiBd0UEk91nBcPtAgo3DGOhW7uk8aUX ZsH8H5+KcoOTHq0Ty87Xx5KV2MXufkVmhNYvnROta0y2dix5rsV5s8zISDiYAeG8NM7j F7iYG/JxOFl/l7eB+sSI+pKY4u3XsCXQ9nfcreMjzzO2soAWr7JhbQFNXJFOcutG2/17 zWp5mPFCnQGL9+3fuF2lWjxThlFMlCzrEv//AOTvrtk9zpfGQnOKOyaiHOSfHCwLHMOV gZl6Hjxw2/rD1d4ljdNmRwdR1N3O3xJgU0A6u/eTQAgdqfscDo8VCU2q+4sY+1zdkPI7 T1Tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eGM7TPeM72/AkSkeG0yP2qeNkE1jzjZ6MJZE8SuXN7Y=; b=V7yzqUMIrkHX3OAxl1QUD7zwo7DwRioBFJx5pqo9nhqspSyr9qqw5VjBT1Uk0HDepz xgUT665AJpLkIf1GvzsGhIrWNi2KD2Ix2rGc9EQT8AnQZ5A0mHegMO+pIl7scSqu6BHB KJrnVqvyOfBijpGaL1wds1Xlv5VbZKP+WK/nYI2jqU3O+FYzbes0NBgf8gvimgqBe7/X 9qNaxN4fMZHNJ6KC0ERbu/S1QQvBnDL+ac8BU5zPAZETuvYQEVwf7tGOnszJaIrR3J7v BnnmKSO/1RcsCHFFctIztDm7FrUHoJkqIVXodtA3ntvgF31KOvN7OEDglMewhiGS0Pnp OM1g== X-Gm-Message-State: AKS2vOzwJbdwkRDrBqvSoHXX2s9sUcDjulroFc77MC37FATqPjdVOF0b 2eLs7W+mx2slbMBHP1eQ7wgS9yerBg== X-Received: by 10.37.171.212 with SMTP id v78mr920699ybi.21.1498123142681; Thu, 22 Jun 2017 02:19:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.174.65 with HTTP; Thu, 22 Jun 2017 02:19:02 -0700 (PDT) In-Reply-To: <69116.1498122107@eng-mail01.juniper.net> References: <80212.1498069205@eng-mail01.juniper.net> <63844.1498121460@eng-mail01.juniper.net> <69116.1498122107@eng-mail01.juniper.net> From: denis bider Date: Thu, 22 Jun 2017 03:19:02 -0600 Message-ID: To: "Mark D. Baushke" Cc: Curdle WG , Eric Rescorla Content-Type: multipart/alternative; boundary="94eb2c07b618bfdcfa055288f933" Archived-At: Subject: Re: [Curdle] RFC 4253 possible errata X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 09:19:05 -0000 --94eb2c07b618bfdcfa055288f933 Content-Type: text/plain; charset="UTF-8" 2 <= e <= p-2 appears to be least ambiguous to me. My second choice would be [2, p-2]. If these closed forms are misinterpreted as open forms, the ramifications are minimal (there will be some implementation that won't accept e=2, big deal). But if the open forms are misinterpreted as closed forms, the ramifications are substantial (there will be implementations that will accept e=1, which is a security risk). On Thu, Jun 22, 2017 at 3:01 AM, Mark D. Baushke wrote: > denis bider writes: > > > In this case I think Eric's concern is well-founded, and the errata > should > > be added. It appears there is no interoperability issue, there is simply > a > > failure of the spec to correctly document effective defense against > > malicious peers. This needs to be corrected. > > Thank you. This is my belief as well. > > Does anyone have a preferences between these equivalent notations? > > 1 < e < p-1 > > (1, p-1) > > 2 <= e <= p-2 > > [2, p-2] > > for the Errata as a replacement for [1, p-1] currently in the RFC4253? > > -- Mark > --94eb2c07b618bfdcfa055288f933 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
2 <=3D e <=3D p-2 appears to be least ambiguous to m= e. My second choice would be [2, p-2].

If these closed f= orms are misinterpreted as open forms, the ramifications are minimal (there= will be some implementation that won't accept e=3D2, big deal). But if= the open forms are misinterpreted as closed forms, the ramifications are s= ubstantial (there will be implementations that will accept e=3D1, which is = a security risk).=C2=A0

On Thu, Jun 22, 2017 at 3:01 AM, Mark D. Baushke <mdb@juni= per.net> wrote:
denis bider <denisbid= er.ietf@gmail.com> writes:

> In this case I think Eric's concern is well-founded, and the errat= a should
> be added. It appears there is no interoperability issue, there is simp= ly a
> failure of the spec to correctly document effective defense against > malicious peers. This needs to be corrected.

Thank you. This is my belief as well.

Does anyone have a preferences between these equivalent notations?

=C2=A0 =C2=A0 =C2=A01 < e < p-1

=C2=A0 =C2=A0 =C2=A0(1, p-1)

=C2=A0 =C2=A0 =C2=A02 <=3D e <=3D p-2

=C2=A0 =C2=A0 =C2=A0[2, p-2]

for the Errata as a replacement for [1, p-1] currently in the RFC4253?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mark

--94eb2c07b618bfdcfa055288f933-- From nobody Thu Jun 22 05:25:33 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79002128D64 for ; Thu, 22 Jun 2017 05:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=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=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 dFmfALuKCRAc for ; Thu, 22 Jun 2017 05:25:30 -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 952721287A0 for ; Thu, 22 Jun 2017 05:25:30 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5MCO2LW026173; Thu, 22 Jun 2017 13:25:27 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=jgcRitEkqfGhsD+6tWtToGArvNYPE6G13hFitaurCko=; b=PvDr05h6RYemoX1Y68NEiCO/m8pHS4XHn+IfxgOVaOj/gqOww5jY+bAGdumZuOu+DWsb queRyn1WY+vQ1mHyWEMICV+nOzyTuEiSkolIdXdALd/a0T2W8+s9fJ9xDYo1d3ePfwKn Llg+inkSDVI6/Emw/ImYKThRefaerqlyqAiYgMrOIYe3QwLOcMx9awY75BW5EL1w5m/s Apezfg64DxCShHp6b0qfxt/JS9d0Vwn64VZHrCBDbgyTDmh/M9Zs8vQYF47/Q5DoAaRa PrA5TZSnokcSuy5lJmd0OsHN6Um5TJqFFZIdv87NdkKqnSUN4dvZKV+EBZqI+kyXrCyf Dg== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2b863f2caw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 22 Jun 2017 13:25:26 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5MCLWwi004761; Thu, 22 Jun 2017 08:25:26 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint1.akamai.com with ESMTP id 2b4yrvjrwf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 22 Jun 2017 08:25:26 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 22 Jun 2017 08:25:24 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Thu, 22 Jun 2017 08:25:24 -0400 From: "Salz, Rich" To: denis bider , "Mark D. Baushke" CC: Curdle WG , Eric Rescorla Thread-Topic: [Curdle] RFC 4253 possible errata Thread-Index: AQHS6rsZysHCwH0NiEimnADj8kBt1aIw0acA///CcC2AAEPngP//vvkigABHzQD///DrQA== Date: Thu, 22 Jun 2017 12:25:23 +0000 Message-ID: <39c35fa10cb44904934c1c18961d338e@usma1ex-dag1mb1.msg.corp.akamai.com> References: <80212.1498069205@eng-mail01.juniper.net> <63844.1498121460@eng-mail01.juniper.net> <69116.1498122107@eng-mail01.juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.55] Content-Type: multipart/alternative; boundary="_000_39c35fa10cb44904934c1c18961d338eusma1exdag1mb1msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-22_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706220214 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-22_05:, , 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 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706220214 Archived-At: Subject: Re: [Curdle] RFC 4253 possible errata X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 12:25:32 -0000 --_000_39c35fa10cb44904934c1c18961d338eusma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSwgcGxlYXNlIHVzZSAyIDw9IGUgPD0gcC0yDQo= --_000_39c35fa10cb44904934c1c18961d338eusma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uaG9lbnpiDQoJe21z by1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj b2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5JIGFncmVlLCBwbGVhc2UgdXNlIDIgJmx0Oz0gZSAmbHQ7PSBwLTI8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_39c35fa10cb44904934c1c18961d338eusma1exdag1mb1msgcorpak_-- From nobody Thu Jun 22 07:50:18 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC4D5129A96 for ; Thu, 22 Jun 2017 07:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_LOW=-0.7] 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 CGR3LlPeMIdh for ; Thu, 22 Jun 2017 07:50:03 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::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 EDF771296C9 for ; Thu, 22 Jun 2017 07:50:02 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id e142so6861130ywa.1 for ; Thu, 22 Jun 2017 07:50:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Cy07Y7H16O2XZLxz6S28xhdm3DN1+JkvrKzpLunnvkY=; b=p+egnLx5mbWzE82zpvF6BDB4a6d1icWHZkwzW7gEN+0pSjHEfeDn1iE4r9pvgTwRoe Arhmczmnljom+oQbvwFMSlsCykbVqIo0oZux0WobXLlw6Lid+HfDgQlyIOYWSmNEuINT P4Clm87uVDY83KVB7Z2Urp/dK+cS6vN74hDMxVa94mGMhWuPhGayg7yHCjdwYlDed3PF IJvxNnLkGdcP+0M5nrnskcnxGnZ7XpHFJoeISV+4rGHqlMZRy8Ezu7I5kh9iv4Lc2/Rq AmtKIEBxd7BvzC68m1i+FF7ClW3Q3WETPCsexpGmdfmNByJB0kL8CqJDYau4nDDj7IgP ce8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Cy07Y7H16O2XZLxz6S28xhdm3DN1+JkvrKzpLunnvkY=; b=qj4eaUIqTVIGOWRIzQV2LJ8NP67PXWRuKlHhtD9wlm5E7NAAqqqIYKlXbDmDSehCxE aIygQnLZcXZeKSPf9pcGymzRB01/vg9Exh0OvcWlTGl7Z/uLfmOLv05W9CNJVx6zHlbS oZHvm7LPgWZRW13CsCvjjyyMcGB/IbktZVDj/PIHMpL12nJvbO/wOcWYYY5kGEr1gqZk mEi+UwiR2GODlx1oN9ihccvtJ7AE1iivpLvbMBhhpbtGBfrJ6l0wOm9xG7wsbHFxAC10 Ch3D6ooY6W6fuimhE9o9vA790hwivm8ABez1MXRkC3KtNt5dxdP+Ko4GCGm15I0tpeLa 8j5Q== X-Gm-Message-State: AKS2vOzX+MucSMFaDPSFc7HnXphcHdpfr6Uvq1vuoN/Q5EJ1kqcA9uvh UciOqAV84qiKPajHnKT5ZNWN/zP7e5cz X-Received: by 10.129.71.213 with SMTP id u204mr2156627ywa.270.1498143002088; Thu, 22 Jun 2017 07:50:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Thu, 22 Jun 2017 07:49:21 -0700 (PDT) In-Reply-To: <39c35fa10cb44904934c1c18961d338e@usma1ex-dag1mb1.msg.corp.akamai.com> References: <80212.1498069205@eng-mail01.juniper.net> <63844.1498121460@eng-mail01.juniper.net> <69116.1498122107@eng-mail01.juniper.net> <39c35fa10cb44904934c1c18961d338e@usma1ex-dag1mb1.msg.corp.akamai.com> From: Eric Rescorla Date: Thu, 22 Jun 2017 07:49:21 -0700 Message-ID: To: "Salz, Rich" Cc: denis bider , "Mark D. Baushke" , Curdle WG Content-Type: multipart/alternative; boundary="001a114c6ec076de1b05528d99fc" Archived-At: Subject: Re: [Curdle] RFC 4253 possible errata X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 14:50:05 -0000 --001a114c6ec076de1b05528d99fc Content-Type: text/plain; charset="UTF-8" FWIW, 7919 uses "1 < Y < p-1" -Ekr On Thu, Jun 22, 2017 at 5:25 AM, Salz, Rich wrote: > I agree, please use 2 <= e <= p-2 > --001a114c6ec076de1b05528d99fc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
FWIW, 7919 uses "1 < Y < p-1"

-Ekr




On Thu, Jun 22, 2017 at = 5:25 AM, Salz, Rich <rsalz@akamai.com> wrote:

I agree, please use 2 <=3D e <=3D p-2<= u>


--001a114c6ec076de1b05528d99fc-- From nobody Thu Jun 22 08:05:49 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2064129AC4 for ; Thu, 22 Jun 2017 08:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, 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=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 tt2dnAipuB7w for ; Thu, 22 Jun 2017 08:05:45 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA5DC129AC6 for ; Thu, 22 Jun 2017 08:05:44 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id l13so14217287lfl.1 for ; Thu, 22 Jun 2017 08:05:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=EFMpLwqD860FnV+qzWesUUnd+48YOLcgShsfksgvTAY=; b=kC1rj+WCL2TW+iuljnF9uE0uZ+STp3sLGtrCgZEdabFzrOsvToaL7SQehEB8Mdledz ivDJTmXmp8yw3+ceqTLihZdg51/ri36Xo3aJfFhlk3ub+uqcSG3Nh2I6q6YaujZbiNJL RlriXwpGHWoyXpt0abdshKljlEUJaS1peb4WbwiQIBMJWOBh5wxt6shdVWxhi4I/AXxS lLcQPMIsfYjqNstJS9kWY4PBBGP9+NZCZ9MTX1eotyTvEK1gfk9zbJCw9yCDpt9Cfhzf UV2IcargJeRQGbo3o/wgOWCfUZh+P06HSOw0R2FvZ+GRJzFUsOjyztEZpemW/u0UWa37 jy+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=EFMpLwqD860FnV+qzWesUUnd+48YOLcgShsfksgvTAY=; b=Eeh2EeiUpx9Uy21K9E/K3/D1O4pw7q6vxj8n4pha+qg9HRvDShFd2VtlCZqyzozP0g RbDqdoIPEsCmKr9AAZjY7US0t22cr1Bm9ZNIrA6glrtY3Zi2l0DZwxRhwjgKzPgCRH+Y zrOBXLkOa7BQo9TRZdkLdK2Y/742jQxS6xlQYz7pcLw3paKtS72z6df5DewqkL17/u5o QLVkoJisiffCYiJJ5laODFcPFfgvQHuR4KIGPxV73NDqRf524zPOch9aT7aU1VsMyP6s TkhXYc/l7dCvNn6bRo0UVkKNuZsimhdP9BftlRAPB/+KoF3fogQLxBiXAlJKCLRe4+pf cBQA== X-Gm-Message-State: AKS2vOxixtY+3VyUqvoiwZ5wlUcJcgECaAfXmGhaRtYNlvqT8NXkFS62 eOl7dxzCyaLdizU7aEMAJa4KTwbHhQ== X-Received: by 10.25.221.4 with SMTP id u4mr1042935lfg.14.1498143943046; Thu, 22 Jun 2017 08:05:43 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.15.26 with HTTP; Thu, 22 Jun 2017 08:05:42 -0700 (PDT) In-Reply-To: References: <80212.1498069205@eng-mail01.juniper.net> <63844.1498121460@eng-mail01.juniper.net> <69116.1498122107@eng-mail01.juniper.net> <39c35fa10cb44904934c1c18961d338e@usma1ex-dag1mb1.msg.corp.akamai.com> From: Daniel Migault Date: Thu, 22 Jun 2017 11:05:42 -0400 X-Google-Sender-Auth: 8sYmWH3QonUY8f7qLv4YAnwj7UM Message-ID: To: Eric Rescorla Cc: "Salz, Rich" , Curdle WG , denis bider , "Mark D. Baushke" Content-Type: multipart/alternative; boundary="94eb2c0c8b508c3e8f05528dd1fb" Archived-At: Subject: Re: [Curdle] RFC 4253 possible errata X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 15:05:48 -0000 --94eb2c0c8b508c3e8f05528dd1fb Content-Type: text/plain; charset="UTF-8" (1, p-1) might be ambiguous. As far as I am concerned, I am more used to the ]1, p-1[ notation. <= vs < notation does not seem ambiguous. I tend to prefer < but only for aesthetic. Yours, Daniel On Thu, Jun 22, 2017 at 10:49 AM, Eric Rescorla wrote: > FWIW, 7919 uses "1 < Y < p-1" > > -Ekr > > > > > On Thu, Jun 22, 2017 at 5:25 AM, Salz, Rich wrote: > >> I agree, please use 2 <= e <= p-2 >> > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > > --94eb2c0c8b508c3e8f05528dd1fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(1, p-1) might be ambiguous. As far as I am conc= erned, I am more used to the ]1, p-1[ notation. <=3D vs < notation do= es not seem ambiguous. I tend to prefer < but only for aesthetic.
Yours,
Daniel=C2=A0 =C2=A0

On Thu, Jun 22, 2017 at 10:49 AM, Eric Res= corla <ekr@rtfm.com> wrote:
FWIW, 7919 uses "1 < Y < p-1"

<= div>-Ekr




On Thu, Jun 22, 2017 at 5:25 AM, Salz, Rich = <rsalz@akamai.com<= /a>> wrote:

I agree, please use 2 <=3D e <=3D p-2<= u>



_______________________________________________
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle

--94eb2c0c8b508c3e8f05528dd1fb-- From nobody Thu Jun 22 20:57:01 2017 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C994C129BB6; Thu, 22 Jun 2017 20:56:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149819021878.17379.4905829448440625422@ietfa.amsl.com> Date: Thu, 22 Jun 2017 20:56:58 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-ssh-modp-dh-sha2-07.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 03:56:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : More Modular Exponential (MODP) Diffie-Hellman (DH) Key Exchange (KEX) Groups for Secure Shell (SSH) Author : Mark D. Baushke Filename : draft-ietf-curdle-ssh-modp-dh-sha2-07.txt Pages : 7 Date : 2017-06-22 Abstract: This document defines added Modular Exponential (MODP) Groups for the Secure Shell (SSH) protocol using SHA-2 hashes. This document updates RFC 4250. This document updates RFC 4253. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-modp-dh-sha2/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-ssh-modp-dh-sha2-07 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-modp-dh-sha2-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-ssh-modp-dh-sha2-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 23 05:04:02 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E222128DF3; Fri, 23 Jun 2017 05:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.421 X-Spam-Level: X-Spam-Status: No, score=-6.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.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 jUGokK51kq4Q; Fri, 23 Jun 2017 05:03:44 -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 DA7FB12EAB4; Fri, 23 Jun 2017 05:03:43 -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 3wvHCy0vkVz1JNd; Fri, 23 Jun 2017 14:03:42 +0200 (CEST) X-purgate-ID: 152705::1498219422-00000861-5EF00B1F/0/0 X-purgate-size: 2879 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail07.wdf.sap.corp (Postfix) with ESMTP id 3wvHCx616HzGp0x; Fri, 23 Jun 2017 14:03:41 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id C93721A6BE; Fri, 23 Jun 2017 14:03:41 +0200 (CEST) In-Reply-To: <20170621174558.GK39245@kduck.kaduk.org> To: Benjamin Kaduk Date: Fri, 23 Jun 2017 14:03:41 +0200 (CEST) CC: Martin Rex , kitten@ietf.org, curdle@ietf.org Reply-To: mrex@sap.com X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20170623120341.C93721A6BE@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Subject: Re: [Curdle] [kitten] I-D Action: draft-ietf-curdle-des-des-des-die-die-die-03.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 12:03:46 -0000 Benjamin Kaduk wrote: > Adding curdle@ for discussion of potential content changes to the > draft... > > On Wed, Jun 21, 2017 at 11:49:35AM +0200, Martin Rex wrote: >> >> Partially true, it would be good to get some light shed on that >> issue from *all* Kerberos implementors (not just Microsoft). >> >> The new paragraph that you quoted as having been added to the I-D >> currently _only_ talks about support for Kerberos AES enctypes in code. >> The new text fails to mention the issue of availability of longterm secrets >> in the Kerberos KDC database that are properly encoded for AES enctypes >> --as a prerequisite of actually _using_ AES enctypes. >> >> It's not just about availability of sufficiently recent code, >> but also a necessity for re-keying all accounts in the Kerberos KDC database >> _after_ sufficiently recend code has been deployed. And it may not be >> the deployment of new code on the KDC alone, there may be additonal >> administrative changes necessary on the KDC to acutally enable use of >> AES enctypes (e.g. changing the domain functional level in Active Directory) > > > It sounds like you are asking for the addition of some text along > the lines of: > > Software support is only a bare minimum requirement for deprecating > RC4 enctypes; there may be additional logistical considerations > involved such as provisioning AES keys for all principals and > updating software configuration to enable AES and disable deprecated > encryption types. > > Is that something you are asking for? Yes, thank your. This sounds good to me. I consider it even more helpful than the reference to particular versions of particular OpenSource Kerberos implementations, because this is a characteristic that is sort-of implied by how kerberos-enctypes keys are created (derived by string2key) and probably affect all implementations of Kerberos, yet it is non-obvious to consumers of the technology. There is a substantial difference between cipher suites in TLS, where key length, strength and algorithm for the symmetric crypto is mostly irrelevant to the (PKI) credentials, and where using new TLS cipher suites and deprecating old TLS cipher suites does not have a rekeying requirement. I do believe that it is very appropriate to provide such kind of a guidance in an RFC, so that it this recommendation for deprecation becomes more comprehensible and the trade-offs clearer to mere consumers of the Kerberos technology, readers that aren't Kerberos protocol experts and senior Kerberos implementers. When making admins sufficiently aware of predictable interop-problems, we may actually see more administrative deprecation of weak Kerberos enctypes than leaving them in the dark, and it helps reducing the amount of stumped users, helpdesks and admins. -Martin From nobody Fri Jun 23 17:08:35 2017 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DF7E7129B4D; Fri, 23 Jun 2017 17:06:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: curdle@ietf.org, ekr@rtfm.com X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149826281990.7840.17266624580714749604.idtracker@ietfa.amsl.com> Date: Fri, 23 Jun 2017 17:06:59 -0700 Archived-At: Subject: [Curdle] curdle - Requested session has been scheduled for IETF 99 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 00:07:00 -0000 Dear Daniel Migault, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. curdle Session 1 (0:30:00) Monday, Morning Session I 0930-1200 Room Name: Congress Hall III size: 250 --------------------------------------------- Special Note: 11:30-12:00 Request Information: --------------------------------------------------------- Working Group Name: CURves, Deprecating and a Little more Encryption Area Name: Security Area Session Requester: Daniel Migault Number of Sessions: 1 Length of Session(s): 30 Minutes Number of Attendees: 15 Conflicts to Avoid: First Priority: acme anima cfrg dnsop dots homenet ipsecme irtfopen lamps lpwan lwig nfvrg quic saag sacm secevent nvo3 tls People who must be present: Eric Rescorla Rich Salz Daniel Migault Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sat Jun 24 05:06:49 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 741501293E4; Sat, 24 Jun 2017 05:06:47 -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 S3WSHbCsCALJ; Sat, 24 Jun 2017 05:06:46 -0700 (PDT) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::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 BF884128D6F; Sat, 24 Jun 2017 05:06:45 -0700 (PDT) Received: by mail-wr0-x22b.google.com with SMTP id 77so96646682wrb.1; Sat, 24 Jun 2017 05:06:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=4BbWtbZ6v3Mv8cwlgw8IrCStlDTnGZWAOz2oApIK2Kk=; b=Ag763WJsNXkW7UhpAOSfXMCM6EYgHkGFXO0Q5pkInphDoDwtOQgVtKF+R1RQIB9Q04 q1T9oKmYEX3zlp8fYaWlRwPdqQ68LvG5AiYSUch/Vga/n5/as52GUaksntqq210emZaT 0JbZZ+gDoMgucBhQA7mWXA08JBts5qcLJyCFnxkTiUlj4r0WOJtE3FyD92DuJBkyV0WU pi7525liZyVjDEfcgVgBlP2WeHIDZbyNxg7A4kZQAeVOH8tgmW9c6l8ANtFf9JUleRR3 jNLckhEpfvzZuotpgag13Afsnj4US2FibLO5a3Kl7iO8okdulUPJ9ZZfn1NDp85mBahm /CgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=4BbWtbZ6v3Mv8cwlgw8IrCStlDTnGZWAOz2oApIK2Kk=; b=WFJcpXc9Yx/TxTYlxv9L1MtX7dszYuPmswwI36SmnNgXRhxYqvzi3y2ApJkPIkskuH T53mD6AqOH6mzGYlTMcvmkFVi4MUD6OM5MxeGfPASHVk8sww0B0rg7iKetq7wgQX57dx rx7siKp+Y9m/0XJGlHk5A5OWRZ97Ij+R8JISGrk1lF5PBCFnStuboaeP3B/gvEW4OyHU utg+BSvV0grEDgRQeBNQqd6KT9A7YWmKjND/CC0WNKSwxSOk49AzcxNPuCjvNOBR7Lwf 0nSyn3RjlWCw6gQnn7TTGvbq7x83krhA88Y//aQpu7O/VVxy/sXFgk53eCyxWGLGUr+9 C4eQ== X-Gm-Message-State: AKS2vOxztVpmrWPGu5r1nO1cb/i1Z+XqR/jJCUN73urdrkrqhpNkTIsU HrFWUhYho2NoJ1ps X-Received: by 10.80.179.181 with SMTP id s50mr9386306edd.57.1498306004181; Sat, 24 Jun 2017 05:06:44 -0700 (PDT) Received: from [192.168.1.79] (124.25.176.95.rev.sfr.net. [95.176.25.124]) by smtp.googlemail.com with ESMTPSA id n26sm1371475edd.51.2017.06.24.05.06.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 24 Jun 2017 05:06:42 -0700 (PDT) To: curdle@ietf.org, jose@ietf.org From: Anders Rundgren Message-ID: <490f2735-0d76-2104-039f-e05e87536ee9@gmail.com> Date: Sat, 24 Jun 2017 14:06:39 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [Curdle] java-cfrg-spec X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 12:06:47 -0000 Since I'm only a user of cryptography rather than a cryptographer, I would be very happy to get some feedback on this proposal, including pull requests. https://github.com/cyberphone/java-cfrg-spec Anders From nobody Sun Jun 25 19:11:53 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F37B3127873; Sun, 25 Jun 2017 19:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 NuXnhJtSQDQm; Sun, 25 Jun 2017 19:11:43 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (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 40BA1128D3E; Sun, 25 Jun 2017 19:11:43 -0700 (PDT) X-AuditID: 12074422-975ff70000003ff1-a2-59506d5d30a2 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id E5.F4.16369.D5D60595; Sun, 25 Jun 2017 22:11:41 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id v5Q2Be6M031932; Sun, 25 Jun 2017 22:11:40 -0400 Received: from kduck.kaduk.org (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.13.8/8.12.4) with ESMTP id v5Q2BZja020527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 25 Jun 2017 22:11:39 -0400 Date: Sun, 25 Jun 2017 21:11:35 -0500 From: Benjamin Kaduk To: Martin Rex , jaltman@secure-endpoints.com Cc: kitten@ietf.org, curdle@ietf.org Message-ID: <20170626021135.GF17840@kduck.kaduk.org> References: <20170621174558.GK39245@kduck.kaduk.org> <20170623120341.C93721A6BE@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170623120341.C93721A6BE@ld9781.wdf.sap.corp> User-Agent: Mutt/1.7.1 (2016-10-04) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFIsWRmVeSWpSXmKPExsUixCmqrBubGxBp8GiijcXWhbOYLf6snMRm cXTzKhaL3t87mB1YPJYs+cnkMeXzVkaPk33nWQOYo7hsUlJzMstSi/TtErgy/n9rYiy4I1Xx r/EpYwPjIdEuRk4OCQETiTmLf7F3MXJxCAksZpLoW9wO5WxklHjwbDMLhHOVSWLzlkksIC0s AqoSU5f/BrPZBFQkGrovM4PYIgLWEtuXrWUDsZmB4pueNrGC2MICsRKnfnwHq+cFWnfn/W0w W0ggTeL6+x/MEHFBiZMzn7BA9GpJ3Pj3kqmLkQPIlpZY/o8DJMwpYCOxbOIrsPGiAsoSfw/f Y5nAKDALSfcsJN2zELoXMDKvYpRNya3SzU3MzClOTdYtTk7My0st0jXVy80s0UtNKd3ECApi dhelHYwT/3kdYhTgYFTi4c2wDIgUYk0sK67MPcQoycGkJMrb6O8fKcSXlJ9SmZFYnBFfVJqT WnyIUYKDWUmENyMRqJw3JbGyKrUoHyYlzcGiJM4rrtEYISSQnliSmp2aWpBaBJOV4eBQkuDl ywFqFCxKTU+tSMvMKUFIM3FwggznARpu7AYyvLggMbc4Mx0if4pRUUqcd3k2UEIAJJFRmgfX C0oyEtn7a14xigO9IsxrDLKCB5ig4LpfAQ1mAho8Y40PyOCSRISUVANjfmvAuWXcvHL39U66 rfRWFfhT9nRve+PXpdpGBT8XM823n6vDMD199/3F57bPS5Ry0Lk+dStnMJvHt5/tCXePbZxc XLXi8ZmotQqRd34cNcip0FlSG3ZZysDbj6P28QaD/ppdzSG9sSd95Nk7hHim255nLVeIN3Nq Mu66/1Bnytxf11+c7mRTYinOSDTUYi4qTgQAaH0zUg0DAAA= Archived-At: Subject: Re: [Curdle] [kitten] I-D Action: draft-ietf-curdle-des-des-des-die-die-die-03.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 02:11:45 -0000 Hi Martin, On Fri, Jun 23, 2017 at 02:03:41PM +0200, Martin Rex wrote: > Benjamin Kaduk wrote: > > > > It sounds like you are asking for the addition of some text along > > the lines of: > > > > Software support is only a bare minimum requirement for deprecating > > RC4 enctypes; there may be additional logistical considerations > > involved such as provisioning AES keys for all principals and > > updating software configuration to enable AES and disable deprecated > > encryption types. > > > > Is that something you are asking for? > > Yes, thank your. This sounds good to me. I consider it even more > helpful than the reference to particular versions of particular > OpenSource Kerberos implementations, because this is a characteristic > that is sort-of implied by how kerberos-enctypes keys are created > (derived by string2key) and probably affect all implementations of > Kerberos, yet it is non-obvious to consumers of the technology. Thank you for clarifying your comment into a request. > > There is a substantial difference between cipher suites in TLS, where > key length, strength and algorithm for the symmetric crypto is mostly > irrelevant to the (PKI) credentials, and where using new TLS cipher suites > and deprecating old TLS cipher suites does not have a rekeying requirement. To some extent this is inherent in Kerberos's use of symmetric crypto for authentication, as opposed to TLS which uses asymmetric crypto for authentication and switches to symmetric crypto for efficiency for bulk data transfer. (Jeffrey Altman wrote:) % In my opinion, such text is inappropriate for an RFC. The deprecation % of the encryption type is a protocol action. The RFC is not guidance % for system administrators. Such guidance should come from the protocol % implementations. % % As such I believe the addition of text similar to the above is % unnecessary for publication. > > I do believe that it is very appropriate to provide such kind of a > guidance in an RFC, so that it this recommendation for deprecation > becomes more comprehensible and the trade-offs clearer to mere consumers > of the Kerberos technology, readers that aren't Kerberos protocol experts > and senior Kerberos implementers. In general I tend to hew more to Jeffrey's track that protocol specifications should limit themseles to protocol-level work. I could see some grounds for an exception here, though, in that the deployment difficulties are inherent to any Kerberos deployment that follows best practice of not storing user passwords (only derived keys). Given Jeffrey's reasoning, I do not think my above "proposed text" (to get clarification from Martin) should be used as-is; if we do want to provide the clarification that Martin wants, I would want to rephrase things somewhat. But, it still seems unclear where the WG consensus lies on the question of including any guidance at all, here. Can others please weigh in? > When making admins sufficiently aware of predictable interop-problems, > we may actually see more administrative deprecation of weak Kerberos > enctypes than leaving them in the dark, and it helps reducing the amount > of stumped users, helpdesks and admins. Admins are more likely to read software-provided documentation than protocol specs; this argument seems speculative to me. -Ben From nobody Tue Jun 27 05:46:13 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF49129B05 for ; Tue, 27 Jun 2017 05:46: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, HTML_MESSAGE=0.001, 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 QqY7CJFgVQfN for ; Tue, 27 Jun 2017 05:46:10 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (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 A71E2129ADE for ; Tue, 27 Jun 2017 05:46:10 -0700 (PDT) X-AuditID: c6180641-bd7ff70000001788-79-59520d31e059 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 67.DB.06024.13D02595; Tue, 27 Jun 2017 09:45:53 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0352.000; Tue, 27 Jun 2017 08:46:09 -0400 From: Daniel Migault To: "curdle@ietf.org" Thread-Topic: IETF time slot / next step for CURDLE Thread-Index: AdLvQ0gS6mGD0VDZSnmHX/N5hNLS8w== Date: Tue, 27 Jun 2017 12:46:08 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118C878F5@eusaamb107.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_2DD56D786E600F45AC6BDE7DA4E8A8C118C878F5eusaamb107erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyuXRPgq4hb1CkwbqnZhZbF85idmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxu6lZQWvJSsOvF3L1sB4SKyLkZNDQsBEYv7mRtYuRi4OIYGj jBI7ll1kAkkICSxnlJj0MgbEZhMwkmg71M8OYosIqEucOLSDFcQWFtCXWHh3FjNE3ERi2b6l jBC2nsSMq+fAalgEVCUmPv8HZHNw8Ar4SlxojAUJMwqISXw/tQZsFbOAuMStJ/OZIO4RkFiy 5zwzhC0q8fLxP1YIW0ni4+/57CBjmAXyJdY22YGEeQUEJU7OfMIygVFwFpJJsxCqZiGpgijR kViw+xMbhK0tsWzha2YY+8yBx0zI4gsY2VcxcpQWF+TkphsZbmIEBvYxCTbHHYx7ez0PMQpw MCrx8PKwBUUKsSaWFVfmHmKU4GBWEuHldQIK8aYkVlalFuXHF5XmpBYfYpTmYFES531XfiFC SCA9sSQ1OzW1ILUIJsvEwSnVwLiqIKT0i+imwCA9Pi/zEzpds96d2PUg7eWkarl9N66vbSjm j1+arr34oMBe59JNj6xW7HUwiFddaN1xqP/MS9+FZ5UUzHmNJT/+kap2fffSydWB91aSc6FA lwxHx6x6mflXLvifmbLvupngvElnrvdlvb8cdZBtTVrArU+nXVycj+yb3RC+Y4ISS3FGoqEW c1FxIgBhUzbQaAIAAA== Archived-At: Subject: [Curdle] IETF time slot / next step for CURDLE X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 12:46:12 -0000 --_000_2DD56D786E600F45AC6BDE7DA4E8A8C118C878F5eusaamb107erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We will have a short session at the next IETF. In order to prepare the sess= ion we would like to understand if anyone would request a slot for presenti= ng. If so, please let us know. As we are close to have all our document sent to the IESG, we would like to= understand if you see any future work items. Please provide any thoughts o= n the mailing list. Yours, Daniel and Rich --_000_2DD56D786E600F45AC6BDE7DA4E8A8C118C878F5eusaamb107erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

We will have a short session at the next IETF. In or= der to prepare the session we would like to understand if anyone would requ= est a slot for presenting. If so, please let us know.

 

As we are close to have all our document sent to the= IESG, we would like to understand if you see any future work items. Please= provide any thoughts on the mailing list.

 

Yours,

Daniel and Rich

--_000_2DD56D786E600F45AC6BDE7DA4E8A8C118C878F5eusaamb107erics_-- From nobody Tue Jun 27 06:58:18 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E883A129B2B for ; Tue, 27 Jun 2017 06:58:16 -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 HEOZpPgN5F9A for ; Tue, 27 Jun 2017 06:58:14 -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 9ABB3129B11 for ; Tue, 27 Jun 2017 06:58:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id DF72D3004D8 for ; Tue, 27 Jun 2017 09:58: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 2PBZZA5_orvn for ; Tue, 27 Jun 2017 09:58:12 -0400 (EDT) Received: from [5.5.33.101] (vpn.snozzages.com [204.42.252.17]) by mail.smeinc.net (Postfix) with ESMTPSA id D20EC30026D; Tue, 27 Jun 2017 09:58:11 -0400 (EDT) From: Russ Housley Message-Id: <81B91E89-9FF9-46D7-A03A-B6AE16BF086C@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_A5D6EF85-0F0D-4AE3-ACCE-AF99688DFBB0" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 27 Jun 2017 09:58:12 -0400 In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C118C878F5@eusaamb107.ericsson.se> Cc: curdle To: Daniel Migault , Rich Salz References: <2DD56D786E600F45AC6BDE7DA4E8A8C118C878F5@eusaamb107.ericsson.se> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] IETF time slot / next step for CURDLE X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 13:58:17 -0000 --Apple-Mail=_A5D6EF85-0F0D-4AE3-ACCE-AF99688DFBB0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This is the status of my two documents: -- draft-ietf-curdle-cms-ecdh-new-curves =E2=80=94 waiting to be put on = the IESG telechat agenda -- draft-ietf-curdle-cms-eddsa-signatures =E2=80=94 waiting for IETF = Last Call If the IESG or IETF Last Call raises an issue, then we can talk about = it. Nothing to say at this point. Russ > On Jun 27, 2017, at 8:46 AM, Daniel Migault = wrote: >=20 > Hi,=20 > =20 > We will have a short session at the next IETF. In order to prepare the = session we would like to understand if anyone would request a slot for = presenting. If so, please let us know. > =20 > As we are close to have all our document sent to the IESG, we would = like to understand if you see any future work items. Please provide any = thoughts on the mailing list. > =20 > Yours,=20 > Daniel and Rich > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle = --Apple-Mail=_A5D6EF85-0F0D-4AE3-ACCE-AF99688DFBB0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 This is the status of my two documents:

 -- = draft-ietf-curdle-cms-ecdh-new-curves =E2=80=94 waiting to be put on the = IESG telechat agenda

 -- = draft-ietf-curdle-cms-eddsa-signatures =E2=80=94 waiting for IETF Last = Call

If the IESG or = IETF Last Call raises an issue, then we can talk about it.  Nothing = to say at this point.

Russ



On = Jun 27, 2017, at 8:46 AM, Daniel Migault <daniel.migault@ericsson.com> wrote:

Hi, 
 
We will = have a short session at the next IETF. In order to prepare the session = we would like to understand if anyone would request a slot for = presenting. If so, please let us know.
 
As we are close to have all our = document sent to the IESG, we would like to understand if you see any = future work items. Please provide any thoughts on the mailing list.
 
Yours, 
Daniel = and Rich
_______________________________________________
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle

= --Apple-Mail=_A5D6EF85-0F0D-4AE3-ACCE-AF99688DFBB0-- From nobody Tue Jun 27 08:26:33 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 100CE129B5D for ; Tue, 27 Jun 2017 08:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40vQ6cxvu-0q for ; Tue, 27 Jun 2017 08:26:29 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0123.outbound.protection.outlook.com [104.47.32.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39412129B7E for ; Tue, 27 Jun 2017 08:26:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=p3Z+O22oiB0YAQw4r/AmOxEn1J14+GAxEPNJzsmQRgE=; b=Vte5ZavuvHHoSzD2kNWU6YciJQV+2egKKAgGnIdxt30NWW6gWQrzSuPiXRcVv/BIFWSaIy3yKqQzo5O2W7XUFszUEXsbufxyHfqvhJDcA1XAkje6/vBs/9y8x0B/og3JmmXoHlkxBWi88mGz/E+GhzyPp6K+0UgCI72ACrmQ6JU= Received: from SN1PR0501CA0019.namprd05.prod.outlook.com (2a01:111:e400:52fe::29) by DM2PR0501MB1279.namprd05.prod.outlook.com (2a01:111:e400:3c1b::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1220.5; Tue, 27 Jun 2017 15:26:27 +0000 Received: from BY2NAM05FT021.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e52::205) by SN1PR0501CA0019.outlook.office365.com (2a01:111:e400:52fe::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1220.5 via Frontend Transport; Tue, 27 Jun 2017 15:26:27 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.15) smtp.mailfrom=juniper.net; ericsson.com; dkim=none (message not signed) header.d=none;ericsson.com; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.15 as permitted sender) Received: from P-EMFE01C-SAC.jnpr.net (66.129.239.15) by BY2NAM05FT021.mail.protection.outlook.com (10.152.100.158) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1157.20 via Frontend Transport; Tue, 27 Jun 2017 15:26:27 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by P-EMFE01C-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 27 Jun 2017 08:26:04 -0700 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v5RFQ4EO016516; Tue, 27 Jun 2017 08:26:04 -0700 (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id DADE61144E; Tue, 27 Jun 2017 08:26:03 -0700 (PDT) To: Daniel Migault CC: "curdle@ietf.org" In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C118C878F5@eusaamb107.ericsson.se> References: <2DD56D786E600F45AC6BDE7DA4E8A8C118C878F5@eusaamb107.ericsson.se> Comments: In-reply-to: Daniel Migault message dated "Tue, 27 Jun 2017 12:46:08 -0000." From: "Mark D. Baushke" Date: Tue, 27 Jun 2017 08:26:03 -0700 Message-ID: <99335.1498577163@eng-mail01.juniper.net> Sender: MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.15; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39400400002)(39410400002)(39450400003)(39860400002)(39850400002)(2980300002)(189002)(199003)(9170700003)(76176999)(50986999)(7126002)(5660300001)(2950100002)(77096006)(2906002)(54356999)(2810700001)(305945005)(6916009)(38730400002)(110136004)(6246003)(6266002)(7846003)(55016002)(53936002)(81166006)(356003)(8936002)(6392003)(8676002)(76506005)(105596002)(53416004)(478600001)(4326008)(7696004)(86362001)(106466001)(189998001)(5003940100001)(47776003)(50466002)(117636001)(229853002)(97876018)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0501MB1279; H:P-EMFE01C-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM05FT021; 1:1W9dzOB7rXggW+3ASqtK7NlSdwIKAsKzp71n7EMP4dLz5BeALT9gTXOB74JVwGA/crJfn63I06kKCSesODdIqaCT2MJReZwWyNu29H2CPM3F3ILrhN9p5YMCCUorBP+0N8KTcZ6R2WR/KirRP2xTCKjSsf7sYzmF0v8sLV1ufvjHWy5jQP8mTJPu3ziL81E2v428FpibBZWPq4LkhSUcrBW3c9ahWEZ5QTJLJfCrkCkCNd3y0GO1QxNFGEXxxd571Cd0qwcv1bRHIDK50UNBebVxT0nhWXwtjoeeimS8jjmMSrk+YBZKIi/UJg+lyKMv29wtSW78uzx6gzT/UFSYAF+juLSTmLhioAtduIAOGxdj9vuKlk6StgJ1DYAAS1GrXGyhvPBLolxM3aJeiwHF8OJJIsIE4hD1gtCDe01FgAMZ7wUIqhk1VVHVs1SxIp7oNe/vSifCDmluuLRzt3nHe8+HdrtvZxAO4U1TEBIeXcW69YzqzORXvzFWfQ7p4gFYhTeVl49GXSM3KK78YIrwCGTcqayyRRVVAwPcmAXUgB8JTT8PTB/+Lj2YmQIcsAx7mvTN8O5NfRTvR7qmmJMZET2BXqv0ME09lgDuRaEAyeGJgtfIuiNKZrQJEx04ZxOqsGYh8h8fjXo6aqokyyjVQulLscd28eMTpxKpjIGDDVJfW2zGvqV5d5Zwq1V2JjLSNgX67Dy9xKc4BwEDcqnI6Y5z92cT+/cfqGYvZtT9HvLzCutgxRLLMPjTTPlBy733zl4weO87RKanJHz1/ejMj2XEU8YFAVBvpjMMHUfLYAa3cZWOn52WzLAjLsmTOGEZ8ipEzuZiRuirv9SPr43PSs5jUoysI92p/Bh3FWs64IdzWSYeNllsMxOGzlA/iRTQ X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f98cccdf-ea25-463d-0618-08d4bd70e109 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254075)(300000503095)(300135400095)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095); SRVR:DM2PR0501MB1279; X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB1279; 3:bIWk0NJRUegBUJaONoC1uH0cU4oVmgX3uK/aw86obMdE7v9olHbZpkeOsgehymTO8WzW9MqFImO3guGih0HXKms6u3w+8WWXxA2zLBobqCaoTtrgHWxUBmZKBffn7bNPGG/Bc4xOfql43am6ZdkgpoWET0DowmDBvdmSSYrZVBBoFZJbuim+INGpYDfH7AkX+N8NCrlY9tHJsAI8xTgMz8aVwAn545YKVsEeG5Krev1k4RassEQ3CD4ILc9+sJNExOZaBM1u82hZsyJCu9Nyv0eqCxpm67euIvysoPU+GxOX2paLRsrHe3iIlP7fT7VZQVQTuUF5AP3Gxi2i852XDRVvKNo2+hJXh2aS7W5kWhnv89+AlWDYMGdnqTvyudtAFhBugSkf0qlQcYc54zyzve6uMXrtpQa2aI1ws0vLVy7Qv5mreu9tjl/5tB0Z/q+ux6s0uoVQ/W6D7FQea0s3PKVhSlf6XDrXVM+lsHWOmdMoti9i3ZhS9hxgeax5n9Qifq68pHgGQDSXquZ4tIXAGY692nBCBrpB2t+Ys/wT1viiBw8MTYRZBPe/hSh161SzZ/IKaRDJKuezg9iCy4IDR68b446Tns2yQis5jWiIarfFDjV2cr9FoyaFs107Ci0eff3QTTb+p1cHfgjY7lfE/31Y8LFM47f+sA0vApFXI4oOs+HNjJvcZr1f63ZR74zhANfKiD99LRNnOEWTckUXPOBku87bvg1xsFsuXn2s8vH0PVG6vQwRORdrcmXzrV+jwES9dAyRedxZC7smV1jGckFOFPPZ0OMjbPVQUSaI2BB3a2VbN7ng9/b66FKy+kpcFOKdXq3FT8FVrJy/x+b45SR9sth4plLmSc7mIld1xJg= X-MS-TrafficTypeDiagnostic: DM2PR0501MB1279: X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB1279; 25:754qrzwLLQFRHx5PbuPFUu6hyC6/GCBWgrl2OVuOKmUA/7b5l1rIISQgslo+30y+b9hhS7hC+kR9gG+Zv9qrMWj/4i/5QcudNbxIm6rOH1MP9y8T2ho37Jo8Lwe2k2WNsyYhjzThempVkn4YRUSwl6QmeHoaDWs9DEx2NWYeuGd2S10sImDePiH6p21tFrjXb0aY8mELNvKPK0XvuIVqEdVwASJLzl2Hnvwbj2P24+uu1mSz3AVU5LNe+4MoX7+PElGSrAKBOUOgIfW8Ttzeu2s/M1L7dDa84huEPwy+Utjk+WKUlMBlhISNy96ZmCRLlunlalewIpCj0BxINVDp8YyU8G2nUWNaFIgRjpOO7xArWBhlHHAkV5zpi75Q+EIjXgO/cufwadg4Ru19i7+7+u+lQl1pNYRAVFdhdijV4Gx9jmCCHSnf7VkRDAnZ0TZRVUrb4CkXuf+OFmpegO2/TXSgWm6cIGVJLHxbrqz9W0oKWcUgLg0RcNdKKAn9vAIPXCkTu1Zi0yQb778V/FnicNSUzK5MV7lJtn6/nyd0VkyCpqNpACSeZsuktbZwMHvTj3eY6AFHXU+NjlNGS8Tm+UMk5yk6sZ6dEjCuqzdjat7O6NMqRL8Gs1U00FYQjEyF34f3L1Wia+0Loq5GKxcIlIC1g9BRUMzOSTwTtsUt523TNWuRouP/wTfs1WOIeLU8+SMeNRK15pbDra/xksoVPNy2iX617PWW/pWmmO24rzo1SA/5pkVZuSRVBhPrSNN9Q83aYmsv21OKSGpAkyMy/NJM5aboWBnsb++lwx+AtGo92BVQ4LmPjbAxKTEY41oVvKPTwZ2UWDlJolRbaQ8XLa82oCjr5NCmcGmRMQxGoUm4B7gDGOJmwl4wrKLoi/ihD8/Lo5Tb44R4SNtg3q0zyuT3pOhrL4wcAmFgkvnJ4FQ= X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB1279; 31:a4pNYd4YWsU0hto5a/j/lplf9M2XZnK/iBlq2NolRPW96ILbFWWymPuzI2bgRsaepijgkpg3CxPvU1USeiK5ffp63EXUEjFof2r7me6sFGhOS61yraq0rSsHalnac0rXvj+fiSz+2+Nuxgqn+/okwwUTiB0p9H+dHR2T99x3coKvatHbN1QFBS+giJUGizva9CXQnKdmjuenQtXtzgFrYH9BHu1dRYfna+Dt5OGJe9MpvKxhm9A0i6I92PcnJL62Z5PfN0nsqNLZywpla5u6+158urFyeDA7v19maSGYCVB8hCuNG8+yI9rrqfLrAdlJyYeWK/us/g8KhvRmbsnT64M/w9T3ewaUpxrKy0fv6nhhPCs8UD+uAJZSdhm6RczIYpE/AanJdO0cgNrYKnZgYbeVs2+hyBvEFvSyfTAQz9kpAvxpg9mS3dVMF7CXiSJVwaGce0POLt9yGEj8REtrz6Bjijlx6QANP4sNkbFJnP4RBxOO7CyaeSOlN2SfXQUUXGNOpK/zwPROlrD8VkJqbhAEykJfSFEtarorpkf9h8oitIelrQe3xQSHNU9BhLjTUXAuYMIb326YX4IG2deZVrDKj37F41Ywhh2pLtM95mVfnGSWK5UEjExonMcDSc5ehZtvdAIAbLlTyovBwRk9C2skzW17rznCjNmu4CEye6RlEnk7dTaVZiVFOwvVlviq+yhsfbuHaJT6Etdwcyu+tw== X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB1279; 20:6Un6vAmOINGTlQDBkfn3kkiOofvlYpUYxinbZWXl/0YA1wQjMG9Q5iZtpqnq/3ZUHOntRzzpTvmm/XDFj0nyjj79l0dxVE8U6/BYF81nUNzjGCUD3NXJpn1jI/F3dz6z01SERvYnTmGL8vqhuDYlkFWg/OibukeViT9t6wvXMR1UinOyYv9Y9oflJ3y6QAL/BcnbVatCGGY4htEDAragQrolnMd27BiH3lpF33NMMLmvsb9U0ZPjNOTW4GDVJzHm6p/wgJrgcCwWOiOPJsfc+s2boiavYsEgroYbOoUZcYYd2VvqTq60EP5FVTMeAlboDJYa4WxYNoQI4tXKQqZZRJFkHZ6Pt6TqFe4XMMZPkXsqjdVHq+XThZx2eyyNgiUFeWjOoUe6kBo3do8suG7Yd+p5b9gPqpbokbld+F8CUA+na0X8sVvThR2KuwWi1v2J93ss0vngCnOio12tXcQA4RtVKFq1Ih6XIKbysKApIRQFwRSpXigzZgJgxfbTmpKP X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(37575265505322)(278178393323532)(236129657087228)(148574349560750); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(13018025)(8121501046)(13016025)(5005006)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(3002001)(6055026)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0501MB1279; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0501MB1279; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR0501MB1279; 4:xk6VaZSbnrGszx68VTNHDzOeLxhGEkaCu9Qczrrc?= =?us-ascii?Q?tOp3DXDivvtRj+LKoVeOoTDCQuoowFhcIv7S7qXp+cfE5AUbdt5Dv4WjlqwP?= =?us-ascii?Q?ZXhSFht4hyXrLZNVR4dI9heFNB9MoG9fBeeKXtnjKwVsciotJoTaqcvYSYvf?= =?us-ascii?Q?ctYnxjhJcMnnhd3SoPX8VjBrSyORfeQ1vYoG5JSGdf/b5hm9lgbg1J4/Qpk1?= =?us-ascii?Q?n7ab9rCdagID2Sc1IV/ZI9f5R2HYzmx3VW1FHiBnoSbYP5zT3lO5IHgCcnJl?= =?us-ascii?Q?xCL8T/q0e1nKMbEWIpltm9loD8fhpQdNXgecbefaznJlEM/Ev5ivTMxw020F?= =?us-ascii?Q?Iqud6H+8O6AZsrswmjqUHG738n2bm8Q1tfSCtJgcA8PvZvabHdtdj9IAKDhu?= =?us-ascii?Q?61GGmwYzoRwwduxetCI0RyDR17VWVMPCsu+FOdPpmkPk4pyNMzMLWMj31LgG?= =?us-ascii?Q?mEwi7Mf9L2aMT+LiT7mVixU9TWVDHA8GVWkEnCN4iM0tyCBC4LLdIaCeDdGc?= =?us-ascii?Q?KEpzJN0S1OSBeGRwXutYuxLy7ZSrWOkcC4zx/XKv1iAnHNoGgDm7dayGk80+?= =?us-ascii?Q?C6Tk5rxs/diZHyYk4Z0pITriVN1oDJcIiGSUuZeT8Vvwo6MPmdqoPEm6+iBD?= =?us-ascii?Q?4SZAUiRnVdUjLCtyW3etiDB9BDC0d/4iv2AZVFT2SwhKQ3IhCVPyswodcOTA?= =?us-ascii?Q?eTiwEmiIKWpKfVzUGeCg5Tw+UmszxNDTbbFeJv5PGIA8funGj26uwVJTJxPA?= =?us-ascii?Q?Ir/2brk9WmtudN3Bz7+XFGerzc/PXglhJxr4aLF/XrQSRU8ysYs8eWVwIBcf?= =?us-ascii?Q?F+VimpZnh2emvguHdca+W0ATLWJjuGn4uF4WG/MAvuuGIr7IoM+Gvmh4dYxa?= =?us-ascii?Q?xE44mx0aME0gwNt6Je7RmkPp6/Fm6rIrkYHl9gMrCJ7ZtOUep1O3SN1dkrFf?= =?us-ascii?Q?gWB0eWPFIKuRspSNKMsLAWLT4o5oVtzJvd5SSY9SIFtMz4GHKmNFP0VjsWUz?= =?us-ascii?Q?jo3wycCcXmYEAijPz0y1oZvYWhHbNyaeuDcUZQgItS1m3DLvQAOkTEVN7e6l?= =?us-ascii?Q?6NjcpG8JBmGjnRKxutr+jH1mNYKT3lqIXR2JO1yIWToJJKjeycq4W2ZFntPh?= =?us-ascii?Q?5JwLnNMvdXMcsxmSLceQYXVyIXLhNUjGWWxdbOX7NU0KwnJN9gUbmLDmr4Up?= =?us-ascii?Q?HtfGDaN7XXqecgngSmIkhvheCEnizF9UUcdtlai4ID6QfTSjIj9PlYNEsIi7?= =?us-ascii?Q?/lm6EDlzy93AemS3eN7UC49er3AehVQR+V+soAuwQyUvypF2FZWxy2sZP9sN?= =?us-ascii?Q?QrHJfMacTpYoF7MjRk1L03BJvHs3kuuXmGL/cbLup3vvmxRYGll5nuKV13fP?= =?us-ascii?Q?5PfmDQ=3D=3D?= X-Forefront-PRVS: 0351D213B3 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR0501MB1279; 23:mrjBk/Jcga9pGgrzLigW7WIu2viiVRonzocgWLL?= =?us-ascii?Q?ARhNxdJeVLXnfgwSn4IjQnXi7ZdK1NAB1t17BAlgkiaWixBisBtaoSTwxPQt?= =?us-ascii?Q?QKq/Ge25GQFvWyfP0aSRZziB8YPmB9EwiEoGTGykDFlOLJtIuu8lFX8w4Fad?= =?us-ascii?Q?1y95zQSbryoKIeTAwskERMEbTZv+vgHD6tmsWoTbudx6pzZv0yxEeyWNpwe/?= =?us-ascii?Q?qG1+T7MkIrl9r9k5klf4D3BeGf5CVsROg9cB7ASQvHHPZ9A50GuhSE0TDqva?= =?us-ascii?Q?LTU21mkJvCAGdeFs4StFMo2MPcUfzRwRdMt+ai3UcI3VVCJ/hOnNz8lzbjhQ?= =?us-ascii?Q?HV36hKSD0Ckp6zNx/4gauDoGJHRg2PbTRbmijBnDiJ3SA7RchIlSw/nGwRPP?= =?us-ascii?Q?6kkcO1lKehUzqrReeeNkcE9p6FMYI9wC6UmB9bTPZyf8ratrJJjYVOjWpTBC?= =?us-ascii?Q?TzVMOJMxonR4NAARNH3AzhAzPZGN5br/BARZ76AZNE+Gkt12uAXdYtrGtbaV?= =?us-ascii?Q?r4v+o7NRXEs7c0m/zuyMuRbHGjbnr3ohIfeM+/Eo/7pQwPKN1KrqASimoBMY?= =?us-ascii?Q?vaQTb+jWIuLgfKQeS3gCEIiPw26aa0e2ZGBO2iv/MfuyAnoI+u6SfLR7kohN?= =?us-ascii?Q?xE1oM2gUdIARco5elGe/GJjBlp0MIf6WBLlsHwNcz04QK+ps0FluDp8boeur?= =?us-ascii?Q?qSlim3N8nlf80o7hHgeTvCbDJvOpGqlBRw3S2O6JfpcQ8iwcnYRuWYCIBYAJ?= =?us-ascii?Q?HubtYGBPUV/zvhQqXuM39qzlug0R9GADKGiKfhzuIHhhJDtuLJONRv0/ABEf?= =?us-ascii?Q?pFbSeFJE0BqBGUbwFecoMYV+946X/EPEESw9U35OkNp6LS3CvPCYS+EkxSVg?= =?us-ascii?Q?vP29k04Iv13Dpar6ezUox9OQoXc8Cfsl6z7WNldLSE2M21/9DEDIQ5ZIW72g?= =?us-ascii?Q?xUW3JD1gXU0pQDW2udGXIMnLG6UFGGGlK8ncA9jviBPYK4eV0u2qwuS3gxI6?= =?us-ascii?Q?dh8cCmRme1/7kYERtOeHD5vQk3W8OSPIh9KUvjYWuYuFJPRgDkXFc2QPTvaJ?= =?us-ascii?Q?Q1zQUiJ/CWT993GaApWW0gyxRblsSTMmwcUTDCsPEjrEFqZg5oj+xT+48jVq?= =?us-ascii?Q?zIOZtW/mrY9+9Q73r5i/oImJ4ZKXIxY3tfU+z5m6X9+JrwTgoKAm5c9xcARq?= =?us-ascii?Q?R8PS4Z2KPgrhehEryUIaC3Dby5sTPIekKIu1VB2tU/B/kjNzk67sVLasKAA?= =?us-ascii?Q?=3D=3D?= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR0501MB1279; 6:/fCKN96akMovmGjhnpkhcK4LmfwbQK5tP6OXrTt/?= =?us-ascii?Q?nsfFDN1uzTYUXzNY1P1/KA/TPTz4quoWtVZabt9EU8JuRjUjj80OocK9Vctf?= =?us-ascii?Q?Ag5HvtDJFNXBM19KC8SbHXzL92K3cFvQuh1UQZ/lUvJrVWHF0S1u8MQ+f1Aq?= =?us-ascii?Q?XOpAnxdcziZr0LzgrJlTtaRQb17HpBVpqVWTwID61Ps1+Poi/rLb5NIaoedx?= =?us-ascii?Q?E24fdi6yF9/4gP8g4h1Curk0rY4gxpXB2pCXiray6TLcae5hSRici2Xj3MYl?= =?us-ascii?Q?G77j2tsnsQjNfLnisKqCkN/NAsFzMWKm5A/p/M2RvC0ppHlkAxp/apiBg9Zn?= =?us-ascii?Q?o8YFIe31IMFf0mAA9JwqIOtlwgAtdFnWOD6vs8GTfDEGRwZDSmGlN8utSgZs?= =?us-ascii?Q?ul6u2kHj0xwDHPjn9xVId7kfxriiLnUEwsum0FnSS5BRS57dbVzqzbX/VaDv?= =?us-ascii?Q?NEuY06c8c4ajmCeyoTyfMWfWsflvBlGfE2SJoZDXBPU8uXjHobOGc7gurjf7?= =?us-ascii?Q?pIQADDUowDcOTbqYwbogSboSycOs+tpxufHBnhKlxzAZ0KBibpKxffSRAcTK?= =?us-ascii?Q?IOBPDKTF6UVsEb1Qqfts6xT6NbNg7M3RB2O5a3J2vRZKuCPRUpNUJwS6MBss?= =?us-ascii?Q?Tnd+HxFkKfx8TCvENG6U7M84tONb4eZw4CJjRVnDNf0uANqL9NRV6Kp/8A3N?= =?us-ascii?Q?e2ABkUGuHbdo3UzGYY/HBHdsBZQp0CL+UALBB0r/48AHmHf+KFthGqD1rSTK?= =?us-ascii?Q?uWICEETzGSGXVPxyxUrBM9CEG2CpjVJZoLIhSMZ93441eW02b+D9c2kS6Tvy?= =?us-ascii?Q?MnuWKkDyl6aYYgs02hPGIsRFJ/eWAGvej7W4SzI0tEVNWEZjMe44CvpOFh5A?= =?us-ascii?Q?6lMkke+6SfMkgr2epkY3xxurQXu+qrHz23RSYT90+8KL4m3qWyM75qFKEAT8?= =?us-ascii?Q?+gwiMTVkzzOM/owiMX0UuwaVDqZ+xDpRPB40hFZV5JfTg+BBhWUCZMCIOWYO?= =?us-ascii?Q?l4W3H94byJLHt0m6gOoWCkVc?= X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB1279; 5:IirDRvcR0eYYCFbMPzSO6xoCghKIrwonyXCJ5wYA2LvCqDpyPfyJzDwDkASSzZlHo0DWVpySIuhXassmENJrQlLT5HmwI+CwwI2pYXcJ07iVz+egOSiQcRNkDEt5TX6HbwjLkNELl1JsOLxTEDDmM0Zhlf9p7UoFsUjYWfIjHVGlHub/PA73Bi+48KrP8u7ceh3l5pVCnGRAOpv2bP8ILZlQS/wUvOGzviDNNcW46vB7RPPYmTPhUrLo5obXL7z3MuQnQoJYAYiioys63ojN7i4SiShomUiZ8qouH78WWRh6rNKBhOLAvLl5Vhi6sIWm77dMIFuw6jW5Ah5lfKo+rfATDPBRCp/48CtBEI0mEceTpmkGDmWJnV0Y4ns76Wy8toUVq0WnIMilmOTikz6b63VXSxr4uleuadZGO8CfVKSiasN2kH5aW9H/+UQhjVFdiwpjNXfdpP1vX5ZmVNw+6p+f7+Rbav5+5JxU0F57cpo1Jn3shWwTGFuUILwJvD9d; 24:Abowd8J05DCsYAUN4vAvtrKPeD1IHsgHNxTY1MGex3A2Pe9AE9AcEVP5GfV+FpW+Zg+YCt5SUuneUZqgHSWz/FBGDo+43Q0FThUKZosZ/Y8= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB1279; 7:p5280bN4COEZLeaP2GjP8FaRHeJnbbQG1n9DcJ5zwJoH+r0P34k6nzrNle4WkgE/je2VmaDzkfXTEb9bokuG9kS+0VOHvHenK94cMLc8RM0WkfkGStQEhFEenQYi/4KeNuDB2qtCrsRtn2z/zQFiCeXji8xMlOCxAizbeSWCywxcx3Gh6X9eL+hDtO32kF6pu15AfXPJnXkBtyOeLrT0flr1lUrKWfP4brqRb5YkXEOwDmGdIR0MUdHQix+2900pfs7AwNgdO/f9zG+iukYOWWxljy+gPzcPhDGhg/yBR4sbWoXT1bRbmBazUo/GOFNxhSEQ8jkdXnB9dRWoMb8s1lZfe2AEbVEmVo5giFVm/D1TTBO0Ujh+HpsC+9IHBTXOHqXmdQHqxU+UWABFjHdfT95OUrQkinAqukj6CMyJnME99stpqCDm22V4llhFjzwLxmGBeRVx649SnJmf97vwbVjY4UJL0rT2SyXH5FPFu4tZ13bWB5Kve97yukWla/4AsEAaqiLjEgExpgvLYq44WzMv6qaTFb5eRUv5tpk15DeoK6oNVgyEF+q/giJ2mOgaN/dAoX0VFICOUS/SR0cmNDpsjCx8vAWgQwciF+PUtNG3iah24EJyvu/YiwrP89bPDADogaNNiZND3d2jQ9VMu3lLlmzP69JtD6h0pE2uiX49/AHJfZEXo0heI1tNIkEDg/H+CMBspN+mYX964M7aeov5VZpUpwXWB3qVGrQYnFTVbEkDUENYWQhSpcwc0WcsoaDUpRb40LjCIY9qCOR4kXrWpo+96DYayq2J13upaUw= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jun 2017 15:26:27.3346 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.15]; Helo=[P-EMFE01C-SAC.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0501MB1279 Archived-At: Subject: Re: [Curdle] IETF time slot / next step for CURDLE X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 15:26:33 -0000 Hi Daniel, Daniel Migault writes: > We will have a short session at the next IETF. In order to prepare the > session we would like to understand if anyone would request a slot for > presenting. If so, please let us know. I will not be able to attend the IETF 99 in Prague. > As we are close to have all our document sent to the IESG, we would > like to understand if you see any future work items. Please provide > any thoughts on the mailing list. There are a number of expired and dead drafts that should probbly be finished (ssh-ed25519, dnskey-ed25519, pkix-eddsa, pkix-newcurves). I think some work on a better way to create Diffie-Hellman primes may also be good to consider. There should be a way to use provable primes that are not backdoored and do not leak bits due to using a generator which does not generate a q-ordered subgroup. I would very much like to see this used as long term we know that the use of fixed groups makes an attractive target for precomputation. To be fair, this group may also want to start looking at Post-Qutanum-Cryptographic algorithms as well. Or, perhaps that will be a new working group for the future. -- Mark From nobody Tue Jun 27 09:20:51 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E39D129601 for ; Tue, 27 Jun 2017 09:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-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 pHlgodRND_KA for ; Tue, 27 Jun 2017 09:20:46 -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 47DB4129B95 for ; Tue, 27 Jun 2017 09:20:44 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5RGH92j004239; Tue, 27 Jun 2017 17:20:41 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=l06zPbGkWlv8HUlfF/nfFtMWiSIH8LKxuwutnWjdzUE=; b=j287qhcaKeP91XTxRsFTWv9nskY5tvIcHhvqzzKkZaLeKtSGmxaNIB976u1nIvhu+f93 UnvQdzhOhiP/QhOiz/UCD60679dbsXIq0DFd2ybDfJijr034WYb6SA5zxJe3BG46Z41n t202WAjWjdDbiSqYLKz/3vDcR4QrX1eeWMhOeUxOU6nDmt10jQtqkrGjKJuHK7Ojqx2g kNzlYHCtwVJEUvo+BNAEuLrKUXmxR4cXtTEsHFHy3NDOlYxRsL5hLno8j2t4zFqnFsJ8 w0uK+Tyc+doY1HFWtU7zebGIcIJtOyz3WbwhP6MzzK8yY4FgITBU0T3g4ASEezm2SxRq xg== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2bbt3w883n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 27 Jun 2017 17:20:41 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5RGHKbk031062; Tue, 27 Jun 2017 12:20:40 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint2.akamai.com with ESMTP id 2b9kdv22g3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 27 Jun 2017 12:20:40 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 27 Jun 2017 12:20:39 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Tue, 27 Jun 2017 12:20:39 -0400 From: "Salz, Rich" To: "Mark D. Baushke" , Daniel Migault CC: "curdle@ietf.org" Thread-Topic: [Curdle] IETF time slot / next step for CURDLE Thread-Index: AdLvQ0gS6mGD0VDZSnmHX/N5hNLS8wAFn41iAAHIdqA= Date: Tue, 27 Jun 2017 16:20:39 +0000 Message-ID: References: <2DD56D786E600F45AC6BDE7DA4E8A8C118C878F5@eusaamb107.ericsson.se> <99335.1498577163@eng-mail01.juniper.net> In-Reply-To: <99335.1498577163@eng-mail01.juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.114] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-27_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706270262 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-27_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 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706270262 Archived-At: Subject: Re: [Curdle] IETF time slot / next step for CURDLE X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 16:20:50 -0000 > There are a number of expired and dead drafts that should probbly be > finished (ssh-ed25519, dnskey-ed25519, pkix-eddsa, pkix-newcurves). Yes, probably. > I think some work on a better way to create Diffie-Hellman primes may als= o > be good to consider. This might be a good thing to do, but I'd really prefer we create a new WG = for it. This one definitely has the history of "don't create, just update = algorithms to use what was already specified." I think that's a big change= in mindset, and perhaps the participants, so I think a new group is better= . > To be fair, this group may also want to start looking at Post-Qutanum- > Cryptographic Same answer, same reason :) From nobody Tue Jun 27 09:24:18 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B75E4126B7E for ; Tue, 27 Jun 2017 09:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 3yTvWJS-3qkt for ; Tue, 27 Jun 2017 09:24:14 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 8F2771271DF for ; Tue, 27 Jun 2017 09:24:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id DD72F253F5; Tue, 27 Jun 2017 19:24:11 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id d8UtemQCOP5A; Tue, 27 Jun 2017 19:24:11 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 7B929C4; Tue, 27 Jun 2017 19:24:08 +0300 (EEST) Date: Tue, 27 Jun 2017 19:24:08 +0300 From: Ilari Liusvaara To: "Mark D. Baushke" Cc: Daniel Migault , "curdle@ietf.org" Message-ID: <20170627162408.2nfznul3xhbsnnam@LK-Perkele-VII> References: <2DD56D786E600F45AC6BDE7DA4E8A8C118C878F5@eusaamb107.ericsson.se> <99335.1498577163@eng-mail01.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <99335.1498577163@eng-mail01.juniper.net> User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Curdle] IETF time slot / next step for CURDLE X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 16:24:17 -0000 On Tue, Jun 27, 2017 at 08:26:03AM -0700, Mark D. Baushke wrote: > Hi Daniel, > > Daniel Migault writes: > > > As we are close to have all our document sent to the IESG, we would > > like to understand if you see any future work items. Please provide > > any thoughts on the mailing list. > > There are a number of expired and dead drafts that should probbly be > finished (ssh-ed25519, dnskey-ed25519, pkix-eddsa, pkix-newcurves). ssh-ed25519 actually seems dead, and I can't find any repacment draft. Note, there are existing implementations here that could be documented. dnskey-ed25519 was superceded, replacement is RFC 8080. pkix-eddsa and pkix-newcurves merged into pkix, currently sent to IESG (what's up with that currently, last log entry is from beginnning of may?). > I think some work on a better way to create Diffie-Hellman primes may > also be good to consider. There should be a way to use provable primes > that are not backdoored and do not leak bits due to using a generator > which does not generate a q-ordered subgroup. I would very much like to > see this used as long term we know that the use of fixed groups makes an > attractive target for precomputation. Basically, there are no known bad primes for ECC except the too small ones. However, the prime choice makes major impact on performance. Therefore in most cases, the primes should be selected for performance. The main problems with Edwards curves is cofactor of at least 4. That may be problematic for some more exotic ECC algorithms (where just clearing the cofactor doesn't work). There are some rather clever tricks for representations that behave like there is no cofactor. The main advantages of Edwards curves is fast unified arithmetic, which makes implementation in side-channel silent way reasonably easy. Complete Edwards curves also map into complete Montgomery curves, which are handy for implementing ECDH. Then there is the two-edged sword of having the neutral point be like other points. It is sure nice for side-channel silent implementations, but can cause problems with some algorithms, especially in misuse situations (CryptoNote recently had a security issue due to misuse of Ed25519). > To be fair, this group may also want to start looking at > Post-Qutanum-Cryptographic algorithms as well. Or, perhaps that will be > a new working group for the future. For PQC, I think most that should be done in this group is integration tests (for discovering hidden problems with things like message sizes). Those are at most experimential with extra warnings that there is very little evidence that the algorithm is any good, and should not be implemented except for testing. -Ilari