From nobody Fri Mar 3 15:56: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 68AC212967A; Fri, 3 Mar 2017 15:55:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148858532142.15846.5683923164009508358.idtracker@ietfa.amsl.com> Date: Fri, 03 Mar 2017 15:55:21 -0800 Archived-At: Cc: curdle@ietf.org, stephen.farrell@cs.tcd.ie Subject: [Curdle] curdle - Requested session has been scheduled for IETF 98 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 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, 03 Mar 2017 23:55:21 -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 (1:00:00) Monday, Afternoon Session III 1710-1810 Room Name: Montreux 3 size: 80 --------------------------------------------- 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): 1 Hour Number of Attendees: 20 Conflicts to Avoid: First Priority: lamps acme trans sacm tcpinc saag ipsecme i2nsf tls radext Second Priority: dots People who must be present: Rich Salz Stephen Farrell Daniel Migault Resources Requested: Projector in room Special Requests: --------------------------------------------------------- From nobody Mon Mar 6 07:58: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 14C78129865 for ; Mon, 6 Mar 2017 07:58:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 LbXG5So7Wf0J for ; Mon, 6 Mar 2017 07:58:23 -0800 (PST) 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 26439129522 for ; Mon, 6 Mar 2017 07:58:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 940A3300448 for ; Mon, 6 Mar 2017 10:58:22 -0500 (EST) 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 chhSjQgK3EPo for ; Mon, 6 Mar 2017 10:58:21 -0500 (EST) Received: from russhousleymbp.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id C0BE0300266 for ; Mon, 6 Mar 2017 10:58:21 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 6 Mar 2017 10:58:35 -0500 References: <148880412594.6555.2087937598510853337.idtracker@ietfa.amsl.com> To: curdle@ietf.org In-Reply-To: <148880412594.6555.2087937598510853337.idtracker@ietfa.amsl.com> Message-Id: <75669986-8814-421C-94E4-60428544D69C@vigilsec.com> X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [Curdle] Progressing with draft-ietf-curdle-cms-ecdh-new-curves X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 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, 06 Mar 2017 15:58:24 -0000 I do not recall seeing an answer to the question asked in the IANA = Considerations: 10. IANA Considerations Three object identifiers for the Key Agreement Algorithm Identifiers in Sections 7 are needed. Are they going to come from an IANA registry or from the registry that assigned the object identifiers in [ID.curdle-pkix]? I am fine with either approach; However, some people have wanted short = OIDs for the CFRG curves. I would like to get this wrapped up soon. Russ From nobody Mon Mar 6 08:30: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 9AD74129623; Mon, 6 Mar 2017 08:29:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Matthew Miller To: X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148881779563.15035.3355290317294020544.idtracker@ietfa.amsl.com> Date: Mon, 06 Mar 2017 08:29:55 -0800 Archived-At: Cc: curdle@ietf.org, draft-ietf-curdle-cms-chacha20-poly1305.all@ietf.org, ietf@ietf.org Subject: [Curdle] Review of draft-ietf-curdle-cms-chacha20-poly1305-04 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 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, 06 Mar 2017 16:29:55 -0000 Reviewer: Matthew Miller Review result: Ready [ re-posting to get it onto the mailing list archives; some bugs prevented it the first time ] 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 < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq >. Document: draft-ietf-curdle-cms-chacha20-poly1305-04 Reviewer: Matthew A. Miller Review Date: 2016-12-16 IETF LC End Date: 2016-12-16 IESG Telechat date: N/A Summary: Ready to be published as a Proposed Standards document. Major issues: NONE Minor issues: NONE Nits/editorial comments: NONE Non-issues: Nits is reporting a downref to RFC 7539 (ChaCha20 and Poly1035). However it is standard practice for cryptographic algorithm documents to be Informational rather than Standards Track, therefore I don't think there's a real concern here. Nits is also reporting downrefs for X680 and X690, but I believe these are acceptable as they define ASN.1. From nobody Mon Mar 6 16:48:23 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 A5F13129A89; Mon, 6 Mar 2017 16:48:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148884769967.15043.4480315708485555299.idtracker@ietfa.amsl.com> Date: Mon, 06 Mar 2017 16:48:19 -0800 Archived-At: Cc: curdle@ietf.org Subject: [Curdle] I-D Action: draft-ietf-curdle-ssh-modp-dh-sha2-02.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 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, 07 Mar 2017 00:48:19 -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-02.txt Pages : 5 Date : 2017-03-06 Abstract: This document defines added Modular Exponential (MODP) Groups for the Secure Shell (SSH) protocol using SHA-2 hashes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-modp-dh-sha2/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-curdle-ssh-modp-dh-sha2-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-ssh-modp-dh-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 Mar 9 12:18: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 70FFD12946E for ; Thu, 9 Mar 2017 12:18:07 -0800 (PST) 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, 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 Se_LYtulTWCl for ; Thu, 9 Mar 2017 12:18:06 -0800 (PST) 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 88440129466 for ; Thu, 9 Mar 2017 12:18:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id EC7E4300448 for ; Thu, 9 Mar 2017 15:18:05 -0500 (EST) 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 7lkhZbt0ZA5N for ; Thu, 9 Mar 2017 15:18:05 -0500 (EST) Received: from russhousleymbp.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 0DC413002BC for ; Thu, 9 Mar 2017 15:18:05 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 9 Mar 2017 15:18:04 -0500 References: <148880412594.6555.2087937598510853337.idtracker@ietfa.amsl.com> <75669986-8814-421C-94E4-60428544D69C@vigilsec.com> To: curdle@ietf.org In-Reply-To: <75669986-8814-421C-94E4-60428544D69C@vigilsec.com> Message-Id: <6C7D22F4-0918-4EF4-B2A4-249061CD49D5@vigilsec.com> X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Curdle] Progressing with draft-ietf-curdle-cms-ecdh-new-curves X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 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, 09 Mar 2017 20:18:07 -0000 We really need to sort this issue. The S/MIME 4.0 specification has a = MUST dependency on draft-ietf-curdle-cms-ecdh-new-curves, and it cannot = be implemented unless object identifiers are assigned. Russ > On Mar 6, 2017, at 10:58 AM, Russ Housley = wrote: >=20 > I do not recall seeing an answer to the question asked in the IANA = Considerations: >=20 > 10. IANA Considerations >=20 > Three object identifiers for the Key Agreement Algorithm Identifiers > in Sections 7 are needed. Are they going to come from an IANA > registry or from the registry that assigned the object identifiers = in > [ID.curdle-pkix]? >=20 > I am fine with either approach; However, some people have wanted short = OIDs for the CFRG curves. >=20 > I would like to get this wrapped up soon. >=20 > Russ >=20 From nobody Thu Mar 9 13:45:00 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 84791129498 for ; Thu, 9 Mar 2017 13:44:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.368 X-Spam-Level: X-Spam-Status: No, score=-2.368 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.229, 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 Bg6x-XUNVq18 for ; Thu, 9 Mar 2017 13:44:57 -0800 (PST) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::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 5720C129435 for ; Thu, 9 Mar 2017 13:44:57 -0800 (PST) Received: by mail-it0-x234.google.com with SMTP id g138so75508286itb.0 for ; Thu, 09 Mar 2017 13:44:57 -0800 (PST) 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=O+AJx41tZlu9x8aQZ6JGhxvclIxwXxPzqC89tLwicTk=; b=QONg4QgHrr+XbxOd9MIw1UfjXRixRRAfvtuzbRGFLbRJ/fzpe1nY5p6oCbcKFead+L 0eKKOAO22fHqlbLyhG2PCqJsK33ae8uTcwFAy9Cmdrfya2U0bZMd7Py7dF9dS4p8nA8w ShzLih/Hri0yAlg245sxRWWmc9OZ69ozG8m1sOw99rF0t2dM1VZzA9vznY4cXO6A6Qwy Bf9a6PTEmovA0yr07SEh/WrOvdg/f8HT34S8Le1Cs5z5tCtT0rHPTeoOcziMjR5+9VHg v3nKtA0HZlJ2ghXU+JIKDIowtLZ+CtigltB4GfX6Zm0MnHP4qQ8aYEwl7bUqNqLJS02V aBWg== 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=O+AJx41tZlu9x8aQZ6JGhxvclIxwXxPzqC89tLwicTk=; b=n0k4Phr9axT1Dhdz0XqrnxVAeJNDzKojEPVfaa1Gno2124zX8xivfUZC8rdp7uHej+ OKd0CR2A0ptsgnYWyi5J8dSW5QRFjjw8IawGv9EiYn8D1naHDuCqqXAWXsTrzqBhntZ4 0pEA6I9PpFpdUMxWjSbznPRbV4Kj6ukWF3DGhYTneQBGODDH1SDcxQxQe1w2jTMEwxqF jUlwXzceT2KLrttTDxjEWpcjcb2+c9DnOSY/TuuLI9S46hABTTllEL3x7ktg8Rm7UsKv 9O6CyXTwFCwD/siBE6K6By7cv/T0ZjkMLNN/zv29lPOKqeDQxKTIHrcakWlGbKhGK1v+ +2RQ== X-Gm-Message-State: AMke39nxn5ElkORRQ12LaLO7JSzJWDov9LYmk3//YfbgkiEd+QIsfeHzHVTrhjcmFO0z9hM80vySfuDNPcN0Hg== X-Received: by 10.36.125.143 with SMTP id b137mr32904736itc.120.1489095896700; Thu, 09 Mar 2017 13:44:56 -0800 (PST) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.35.213 with HTTP; Thu, 9 Mar 2017 13:44:56 -0800 (PST) In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> References: <1481295892.20432.16.camel@redhat.com> <0e1701d254c6$46509670$d2f1c350$@augustcellars.com> <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> From: Daniel Migault Date: Thu, 9 Mar 2017 16:44:56 -0500 X-Google-Sender-Auth: MsPrByOBeG84vHKjtDGWq8LLYgU Message-ID: To: Nikos Mavrogiannopoulos , Brian Smith Content-Type: multipart/alternative; boundary=001a11444814f59dcd054a53279a Archived-At: Cc: "Dang, Quynh \(Fed\)" , "Salz, Rich" , Jim Schaad , Phillip Hallam-Baker , Curdle Subject: Re: [Curdle] Some work for the group X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 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, 09 Mar 2017 21:44:59 -0000 --001a11444814f59dcd054a53279a Content-Type: text/plain; charset=UTF-8 Hi, The pkix draft blocks the publication of other drafts so we need to move it forward as soon as possible. The blocking discussion whether or not we should have the EdDSA prehash version for CA. Currently, the choice between the two variants is rather seen as a policy choice from the CA and I have not seen any strong argument for not having this variant. Interoperability issue has been raised, but not exposed. If there are any strong argument against having the two variants please provide them clearly by March 14 on the list. If we have no strong reasons against having the two variants, I suggest we agree on an updated version with the two variants before the IETF in Chicago. Does it sounds reasonable for everyone ? Yours, Daniel On Mon, Feb 20, 2017 at 9:32 AM, Daniel Migault wrote: > Thanks for the information Nikos. > > I agree that we should find a concensus on whether the pre-hashed version > should considered or not. > > One reason for not considering it is interoperability issue. Could we > describe them a bit deeper ? > > Yours, > > Daniel > > -----Original Message----- > From: Nikos Mavrogiannopoulos [mailto:nmav@redhat.com] > Sent: Monday, February 20, 2017 4:39 AM > To: Brian Smith > Cc: Daniel Migault ; Phillip Hallam-Baker < > phill@hallambaker.com>; Dang, Quynh (Fed) ; Jim > Schaad ; Curdle ; Salz, Rich < > rsalz@akamai.com> > Subject: Re: [Curdle] Some work for the group > > On Thu, 2017-02-02 at 19:13 -1000, Brian Smith wrote: > > Nikos Mavrogiannopoulos wrote: > > > Brian Smith wrote: > > > > Besides the security issue, my understanding is that using the > > > > prehash variant would result in lots of interop failures as, > > > > AFAICT, there isn't going to be much support for it in > > > > verification libraries. > > > > > > Isn't that orthogonal to the question? If the prehash version is > > > going to cause interop issues is not affected by the text quoted > > > above. > > > Your > > > comment is on whether including the prehashed version at all. > > > > No, it's not orthogonal. If we don't include the prehash version at > > all, there won't be interop failures. Again, I don't see any > > significant support for the prehash variant on the verification side. > > As I said your argument is about adding this variant, and not about the > actual question which is whether it should be treated specially with > regards to CA usage. > > > It's a bad idea to let or encourage CAs sign things using an algorithm > > that most verifiers are unlikely to implement. > > Could you please clarify what do you mean by most? (I personally intended > to implement only the prehashed variant not the other because it is the > only variant that be used with HSMs). However, if there is a consensus that > the prehashed variant shouldn't be used, we shouldn't drag it in the > proposal. > > regards, > Nikos > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --001a11444814f59dcd054a53279a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

The pkix draft blocks the publ= ication of other drafts so=C2=A0 we need to move it forward as soon as poss= ible. The blocking discussion whether or not we should have the EdDSA preha= sh version for CA. Currently, the choice between the two variants is rather= seen as a policy choice from the CA and I have not seen any strong argumen= t for not having this variant. Interoperability issue has been raised, but = not exposed.

If there are any strong argument against having the tw= o variants please provide them clearly by March 14 on the list.

If = we have no strong reasons against having the two variants, I suggest we agr= ee on an updated version with the two variants=C2=A0 before the IETF in Chi= cago. Does it sounds reasonable for everyone ?

Yours,
Daniel





On Mon, Feb 20, 2017 at 9:32 A= M, Daniel Migault <daniel.migault@ericsson.com> wr= ote:
Thanks for the information Nikos.
I agree that we should find a concensus on whether the pre-hashed version s= hould considered or not.

One reason for not considering it is interoperability issue. Could we descr= ibe them a bit deeper ?

Yours,

Daniel

-----Original Message-----
From: Nikos Mavrogiannopoulos [mailto:nm= av@redhat.com]
Sent: Monday, February 20, 2017 4:39 AM
To: Brian Smith <brian@briansmit= h.org>
Cc: Daniel Migault <danie= l.migault@ericsson.com>; Phillip Hallam-Baker <phill@hallambaker.com>; Dang, Quynh (Fed) <= ;quynh.dang@nist.gov>; Jim Sc= haad <ietf@augustcellars.com>; Curdle <curdle@ietf.org&g= t;; Salz, Rich <rsalz@akamai.com= >
Subject: Re: [Curdle] Some work for the group

On Thu, 2017-02-02 at 19:13 = -1000, Brian Smith wrote:
> Nikos Mavrogiannopoulos <nmav@re= dhat.com> wrote:
> > Brian Smith wrote:
> > > Besides the security issue, my understanding is that using t= he
> > > prehash variant would result in lots of interop failures as,=
> > > AFAICT, there isn't going to be much support for it in > > > verification libraries.
> >
> > Isn't that orthogonal to the question? If the prehash version= is
> > going to cause interop issues is not affected by the text quoted<= br> > > above.
> > Your
> > comment is on whether including the prehashed version at all.
>
> No, it's not orthogonal. If we don't include the prehash versi= on at
> all, there won't be interop failures. Again, I don't see any > significant support for the prehash variant on the verification side.<= br>
As I said your argument is about adding this variant, and not about the act= ual question which is whether it should be treated specially with regards t= o CA usage.

> It's a bad idea to let or encourage CAs sign things using an algor= ithm
> that most verifiers are unlikely to implement.

Could you please clarify what do you mean by most? (I personally intended t= o implement only the prehashed variant not the other because it is the only= variant that be used with HSMs). However, if there is a consensus that the= prehashed variant shouldn't be used, we shouldn't drag it in the p= roposal.

regards,
Nikos

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

--001a11444814f59dcd054a53279a-- From nobody Thu Mar 9 13:56: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 14007129420 for ; Thu, 9 Mar 2017 13:56:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.229, 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 9xbUtKyiol0X for ; Thu, 9 Mar 2017 13:56:16 -0800 (PST) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::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 0B95E127735 for ; Thu, 9 Mar 2017 13:56:16 -0800 (PST) Received: by mail-it0-x22e.google.com with SMTP id h10so136820550ith.1 for ; Thu, 09 Mar 2017 13:56:16 -0800 (PST) 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=DIZgzWuvg5fc2eq8DNIF5+O9HuqDs60FihCsySKKbG0=; b=XSZX+B3fERgAZRfbKi4f6Eqc0qSvGMGE2b9mV0D7DHyeM44jEdwxZkgMKGruqQMFxv cbZtqHkqS/QqnX8kY759BXanE10VVZcpn/fMPVhEVHl0qDjj7zrcaUcyTeGtGqqtJBRr iXAIkEmKZcWX3WihcAtjpCaEewH3eVWNeeWQ/Q3fMLYKL1jMMU5Fl09xOd8sL31ZE42Q YefPdujv14nDCpR1jje0gkzmHdyt96m52buwaHi6T7YdB+aAoVfGN4XTt7EEv2aDCxYp BCvepIJ2qzTC2RSpT4eFzeebeYZ+ZW4z7/dTRkROZt7x87jIXollhp4yB3yIt3TPW2mI 8odw== 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=DIZgzWuvg5fc2eq8DNIF5+O9HuqDs60FihCsySKKbG0=; b=Nek/c5rUs7yr9vuylBhhJhYhCECQN5islAvY4ggiQJTh2PG7t+izCOFB+Wsxian/bE 8oV9Z1S+6aCyWi2m0QJ1EOo3umHVUZfXelJoHrq5qx6hM4gM39P+BCbYG05qHafWm/9k Yhg16Gb7QfOa74Uas3fn7Mnx48KMQwE/C+8d9LaZfNtYG3jacnM7avvRNFpHo1xA/lHd NcwaYR/3dEe19eReEDRWI/qllNZENcJla6LKFJc+ZctEeTwBLYtvohtbCTkDuW31IG9b jkRWVbfPFXUZKMhy+8bh7E0LyVtul2DW4olbuw1Nk/dJq6E5n05lvkl04lwP7CtVgLWU 17iA== X-Gm-Message-State: AMke39k53R8KLmuCPSnfuXD+iu2/qHC5XkoMJVpZ21msdOpJLfB37X4AGXdnNgKR9E6X1rKBz9m2aTYtwyz+Ng== X-Received: by 10.36.164.75 with SMTP id v11mr14254354iti.101.1489096575195; Thu, 09 Mar 2017 13:56:15 -0800 (PST) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.35.213 with HTTP; Thu, 9 Mar 2017 13:56:14 -0800 (PST) From: Daniel Migault Date: Thu, 9 Mar 2017 16:56:14 -0500 X-Google-Sender-Auth: 8rtvpI_FMIKgz6eb8l2CI_fR6Ag Message-ID: To: curdle Content-Type: multipart/alternative; boundary=f403045fbba866a059054a53501d Archived-At: Subject: [Curdle] questions on draft-ietf-curdle-cms-eddsa-signatures-03.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 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, 09 Mar 2017 21:56:18 -0000 --f403045fbba866a059054a53501d Content-Type: text/plain; charset=UTF-8 Hi, I read draft-ietf-curdle-cms-eddsa-signatures-03.txt and have a few questions. Please find my questions/comments inline. Yours, Daniel Use of EdDSA Signatures in the Cryptographic Message Syntax (CMS) 2. EdDSA Signature Algorithm One of the parameters of the EdDSA algorithm is the "prehash" function. This may be the identity function, resulting in an algorithm called PureEdDSA, or a collision-resistant hash function, resulting in an algorithm called HashEdDSA. In most situations the CMS SignedData includes signed attributes, including the message digest of the content. Since HashEdDSA offers no benefit when signed attributes are present, only PureEdDSA is used with the CMS. MGLT: My understanding of the two latest sentences is that, in most cases the CMS when used with signed attributes may specify the hash of the content. As prehashing is performed by CMS, there is no need to have a pre hash variant version. >From the two sentences it may appear that without signed attributes, they might be some advantages of having HashEdDSA over PureEdDSA. If that is the case, maybe we should provide them and then motivate our choice. What is unclear to me is why signed attributed make it different ? My understanding is that in any case digestAlgorithm is used to compute the digest of the eContent and when defined additional signed attributes. I am also wondering if we were using the prehash variant a combination of digestAlgorithm with the prehash function would not be problematic. At least, the signing operation would not be performed on the same content this might add unnecessary overhead. If that is the case, it would provide a generic motivation to only consider PureHash with CMS. My understanding of EdDSA is that when PureEdDSA is possible, it is always recommended over HashEdDSA. I assume this is also recommended for CMS. 2.3. Message Digest Algorithm Identifiers When the signer includes signed attributes, a message digest algorithm is used to compute the message digest on the eContent value. When signing with Ed25519, the message digest algorithm MUST be SHA-512 [RFC4634]. When signing with Ed448, the message digest algorithm MUST be SHAKE256 [FIPS202] with a 512-bit output value. MGLT: I am wondering why the digestAlgorithm cannot be the identity. Signing with Ed25519 uses SHA-512 as part of the signing operation, and signing with Ed448 uses SHAKE256 as part of the signing operation. MGLT: I am wondering if the text above wants to specify that the digest algorithm specified are already part of the signature and as such no additional hash functions really need to be added or if there is another motivation for this text. For convenience, the object identifiers and parameter syntax for these algorithms are repeated here: MGLT: IOD are repeated, maybe we could add a reference where these have been defined. -- Note that the ref becomes clearer on the next page. 2.4. EdDSA Signatures The id-Ed25519 and id-Ed448 object identifiers are also used for signature values. When used to identify signature algorithms, the AlgorithmIdentifier parameters field MUST be absent. MGLT: I do not understand why id-Ed25519 and id-Ed448 are used for the signature value. My understanding is that the Signer Info carries the signature algorithm, which defines the signature. 3. Signed-data Conventions The processing depends on whether the signer includes signed attributes. The inclusion of signed attributes is preferred, but the conventions for signed-data without signed attributes are provided for completeness. MGLT: Maybe we could briefly explain or provide a reference why signed attributes are preferred. 3.1. Signed-data Conventions With Signed Attributes The SignedData digestAlgorithms field includes the identifiers of the message digest algorithms used by one or more signer. There MAY be any number of elements in the collection, including zero. When signing with Ed25519, the digestAlgorithm SHOULD include id-sha512, and if present, the algorithm parameters field MUST be absent. When signing with Ed448, the digestAlgorithm SHOULD include id-shake256-len, and if present, the algorithm parameters field MUST also be present, and the parameter MUST contain 512, encoded as a positive integer value. MGLT: For which reason do we have a SHOULD and not a MUST, as the hash function specified have a MUST status in te message digest identifier. 3.2. Signed-data Conventions Without Signed Attributes --f403045fbba866a059054a53501d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I read draft-ietf-curdle-c= ms-eddsa-signatures-03.txt and have a few questions. Please find my questio= ns/comments inline.

Yours,
Daniel=C2=A0

=C2=A0=C2=A0 Use of EdDSA Signatures in the Cryptographic Messa= ge Syntax (CMS)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 <draft-ietf-curdle-cms-eddsa-signatures-03.txt>

2= .=C2=A0 EdDSA Signature Algorithm

=C2=A0=C2=A0 One of the parameters= of the EdDSA algorithm is the "prehash"
=C2=A0=C2=A0 function= .=C2=A0 This may be the identity function, resulting in an
=C2=A0=C2=A0 = algorithm called PureEdDSA, or a collision-resistant hash function,
=C2= =A0=C2=A0 resulting in an algorithm called HashEdDSA.=C2=A0 In most situati= ons the
=C2=A0=C2=A0 CMS SignedData includes signed attributes, includin= g the message
=C2=A0=C2=A0 digest of the content. Since HashEdDSA offers= no benefit when signed
=C2=A0=C2=A0 attributes are present, only PureEd= DSA is used with the CMS.

MGLT: My understanding of the two latest s= entences is that, in most cases the CMS when used with signed attributes ma= y specify the hash of the content. As prehashing is performed by CMS, there= is no need to have a pre hash variant version.

From the two senten= ces it may appear that without signed attributes, they might be some advant= ages of having HashEdDSA over PureEdDSA. If that is the case, maybe we shou= ld provide them and then motivate our choice.=C2=A0=C2=A0
=C2=A0
Wha= t is unclear to me is why signed attributed make it different ? My understa= nding is that in any case digestAlgorithm is used to compute the digest of = the eContent and when defined additional signed attributes.=C2=A0

<= br>I am also wondering if we were using the prehash variant a combination o= f digestAlgorithm with the prehash function would not be problematic. At le= ast, the signing operation would not be performed on the same content this = might add unnecessary overhead. If that is the case, it would provide a gen= eric motivation to only consider PureHash with CMS.=C2=A0

My unders= tanding of EdDSA is that when PureEdDSA is possible, it is always recommend= ed over HashEdDSA. I assume this is also recommended for CMS.=C2=A0
=C2= =A0

2.3.=C2=A0 Message Digest Algorithm Identifiers

=C2=A0=C2= =A0 When the signer includes signed attributes, a message digest
=C2=A0= =C2=A0 algorithm is used to compute the message digest on the eContent
= =C2=A0=C2=A0 value.=C2=A0 When signing with Ed25519, the message digest alg= orithm MUST
=C2=A0=C2=A0 be SHA-512 [RFC4634].=C2=A0 When signing with E= d448, the message digest
=C2=A0=C2=A0 algorithm MUST be SHAKE256 [FIPS20= 2] with a 512-bit output value.

MGLT: I am wondering why the digestA= lgorithm cannot be the identity.

=C2=A0=C2=A0 Signing with Ed25519 = uses SHA-512 as part of the signing operation,
=C2=A0=C2=A0 and signing = with Ed448 uses SHAKE256 as part of the signing
=C2=A0=C2=A0 operation.<= br>
MGLT: I am wondering if the text above wants to specify that the dig= est algorithm specified are already part of the signature and as such no ad= ditional hash functions really need to be added or if there is another moti= vation for this text.=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0
=C2=A0=C2=A0
= =C2=A0=C2=A0 For convenience, the object identifiers and parameter syntax f= or
=C2=A0=C2=A0 these algorithms are repeated here:

=C2=A0MGLT: I= OD are repeated, maybe we could add a reference where these have been defin= ed. -- Note that the ref becomes clearer on the next page.
=C2=A0
2.4= .=C2=A0 EdDSA Signatures

=C2=A0=C2=A0 The id-Ed25519 and id-Ed448 ob= ject identifiers are also used for
=C2=A0=C2=A0 signature values.=C2=A0 = When used to identify signature algorithms, the
=C2=A0=C2=A0 AlgorithmId= entifier parameters field MUST be absent.

MGLT: I do not understand = why id-Ed25519 and id-Ed448 are used for the signature value. My understand= ing is that the Signer Info carries the signature algorithm, which defines = the signature.=C2=A0
=C2=A0=C2=A0
3.=C2=A0 Signed-data Conventions<= br>
=C2=A0=C2=A0 The processing depends on whether the signer includes s= igned
=C2=A0=C2=A0 attributes.

=C2=A0=C2=A0 The inclusion of sign= ed attributes is preferred, but the conventions
=C2=A0=C2=A0 for signed-= data without signed attributes are provided for
=C2=A0=C2=A0 completenes= s.
=C2=A0=C2=A0
MGLT: Maybe we could briefly explain or provide a re= ference why signed attributes are preferred.=C2=A0=C2=A0

3.1.=C2=A0= Signed-data Conventions With Signed Attributes

=C2=A0=C2=A0 The Sig= nedData digestAlgorithms field includes the identifiers of the
=C2=A0=C2= =A0 message digest algorithms used by one or more signer.=C2=A0 There MAY b= e
=C2=A0=C2=A0 any number of elements in the collection, including zero.= =C2=A0 When
=C2=A0=C2=A0 signing with Ed25519, the digestAlgorithm SHOUL= D include id-sha512,
=C2=A0=C2=A0 and if present, the algorithm paramete= rs field MUST be absent.=C2=A0 When

=C2=A0=C2=A0 signing with Ed448,= the digestAlgorithm SHOULD include
=C2=A0=C2=A0 id-shake256-len, and if= present, the algorithm parameters field MUST
=C2=A0=C2=A0 also be prese= nt, and the parameter MUST contain 512, encoded as a
=C2=A0=C2=A0 positi= ve integer value.

=C2=A0MGLT: For which reason do we have a SHOULD a= nd not a MUST, as the hash function specified have a MUST status in te mess= age digest identifier.=C2=A0=C2=A0=C2=A0
=C2=A0=C2=A0

3.2.=C2= =A0 Signed-data Conventions Without Signed Attributes


--f403045fbba866a059054a53501d-- From nobody Thu Mar 9 18:25: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 4C5B8129477 for ; Thu, 9 Mar 2017 18:25:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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, RP_MATCHES_RCVD=-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=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 Ky6uRAm47_T2 for ; Thu, 9 Mar 2017 18:25:12 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id A059A1294CE for ; Thu, 9 Mar 2017 18:25:01 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 2452E496C0F; Thu, 9 Mar 2017 23:13:19 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 0EB79496C03; Thu, 9 Mar 2017 23:13:19 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1489101199; bh=SVgMYUM8cfYHWxLl8KrQrTZgy8/2ySM4yA2NTKcxYKw=; l=349; h=From:To:Date:References:In-Reply-To:From; b=uPnbw5B91P9/uJiuyIGpIj5CTwVOMOXsbeYQtRDbSMf28Je9C+tQL8qDKzzTIJqsa idfaww403mgra5Q0DiqyfYGvtVGoKH+Fvu4TKudabRmJ4O2fUWkLO/YVVQPwirUYth teDm7oUbw8U/Cl1GfoYJ9DNJKKW4qqKqTHBF8DoQ= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id E8FFC1E07C; Thu, 9 Mar 2017 23:13:18 +0000 (GMT) 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.1178.4; Thu, 9 Mar 2017 18:13:18 -0500 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.1178.000; Thu, 9 Mar 2017 18:13:18 -0500 From: "Salz, Rich" To: Russ Housley , "curdle@ietf.org" Thread-Topic: [Curdle] Progressing with draft-ietf-curdle-cms-ecdh-new-curves Thread-Index: AQHSlpKB9wbKTt8dhUCoUNZsmfJ5RaGNSzAA///c6IA= Date: Thu, 9 Mar 2017 23:13:18 +0000 Message-ID: References: <148880412594.6555.2087937598510853337.idtracker@ietfa.amsl.com> <75669986-8814-421C-94E4-60428544D69C@vigilsec.com> <6C7D22F4-0918-4EF4-B2A4-249061CD49D5@vigilsec.com> In-Reply-To: <6C7D22F4-0918-4EF4-B2A4-249061CD49D5@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.72] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Curdle] Progressing with draft-ietf-curdle-cms-ecdh-new-curves X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 02:25:19 -0000 > We really need to sort this issue. The S/MIME 4.0 specification has a MU= ST > dependency on draft-ietf-curdle-cms-ecdh-new-curves, and it cannot be > implemented unless object identifiers are assigned. You want the chairs to just pick an arc? Or do you have a preference that = you'd like the WG to use? Or the wg-chairs to pressure for? From nobody Fri Mar 10 00:25: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 0737C1295B9 for ; Fri, 10 Mar 2017 00:25:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGxjq3Pqeawe for ; Fri, 10 Mar 2017 00:25:04 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CD5F1293D9 for ; Fri, 10 Mar 2017 00:25:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id DABB7BEB0; Fri, 10 Mar 2017 08:24:58 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9cvZxLhF8Fm; Fri, 10 Mar 2017 08:24:50 +0000 (GMT) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2831FBE73; Fri, 10 Mar 2017 08:24:50 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1489134290; bh=RYZo7OGpQ5sUTIB+R+kOqUp78CPb9amcxPZLGSummmQ=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=cTNjmpOqtzX0TPPyIw0g0Aw2DyizFa6BxDxVznBPUZ5zuRG0/N5HSQRxS8uCX9RMD S/oHnrdFAPWu+ypZbJSC9RaEWUn8hq1PsGWd6/5bwOq1+K+a8HXXwM0ndHnxvkes3A kcGWWYtV38LuxC1XY3uCKqnDyraAZjV96UEhcq6k= To: Daniel Migault , Nikos Mavrogiannopoulos , Brian Smith References: <1481295892.20432.16.camel@redhat.com> <0e1701d254c6$46509670$d2f1c350$@augustcellars.com> <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Fri, 10 Mar 2017 08:24:49 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="UVuDJPuSi17EEw11bH6tFk5l5C56jvHuo" Archived-At: Cc: "Dang, Quynh \(Fed\)" , "Salz, Rich" , Jim Schaad , Phillip Hallam-Baker , Curdle Subject: Re: [Curdle] Some work for the group X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 08:25:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UVuDJPuSi17EEw11bH6tFk5l5C56jvHuo Content-Type: multipart/mixed; boundary="9bxcjM19XpIaF6bwUj6l2Bb6OSGHTjpNr"; protected-headers="v1" From: Stephen Farrell To: Daniel Migault , Nikos Mavrogiannopoulos , Brian Smith Cc: "Dang, Quynh (Fed)" , "Salz, Rich" , Jim Schaad , Phillip Hallam-Baker , Curdle Message-ID: Subject: Re: [Curdle] Some work for the group References: <1481295892.20432.16.camel@redhat.com> <0e1701d254c6$46509670$d2f1c350$@augustcellars.com> <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> In-Reply-To: --9bxcjM19XpIaF6bwUj6l2Bb6OSGHTjpNr Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 09/03/17 21:44, Daniel Migault wrote: > Hi, >=20 > The pkix draft blocks the publication of other drafts so we need to mo= ve > it forward as soon as possible. The blocking discussion whether or not = we > should have the EdDSA prehash version for CA. Currently, the choice bet= ween > the two variants is rather seen as a policy choice from the CA and I ha= ve > not seen any strong argument for not having this variant. Interoperabil= ity > issue has been raised, but not exposed. >=20 > If there are any strong argument against having the two variants please= > provide them clearly by March 14 on the list. >=20 > If we have no strong reasons against having the two variants, I suggest= we > agree on an updated version with the two variants before the IETF in > Chicago. Does it sounds reasonable for everyone ? Sorry - I don't recall the arguments for supporting both. And we ought I think be against multiple options where those are not needed. Can you summarise the argument as to why we need both variants? (A pointer to the list archive will be fine if that's all that's needed.) Thanks, S. >=20 > Yours, > Daniel >=20 >=20 >=20 >=20 >=20 > On Mon, Feb 20, 2017 at 9:32 AM, Daniel Migault > wrote: >=20 >> Thanks for the information Nikos. >> >> I agree that we should find a concensus on whether the pre-hashed vers= ion >> should considered or not. >> >> One reason for not considering it is interoperability issue. Could we >> describe them a bit deeper ? >> >> Yours, >> >> Daniel >> >> -----Original Message----- >> From: Nikos Mavrogiannopoulos [mailto:nmav@redhat.com] >> Sent: Monday, February 20, 2017 4:39 AM >> To: Brian Smith >> Cc: Daniel Migault ; Phillip Hallam-Baker= < >> phill@hallambaker.com>; Dang, Quynh (Fed) ; Jim >> Schaad ; Curdle ; Salz, Rich = < >> rsalz@akamai.com> >> Subject: Re: [Curdle] Some work for the group >> >> On Thu, 2017-02-02 at 19:13 -1000, Brian Smith wrote: >>> Nikos Mavrogiannopoulos wrote: >>>> Brian Smith wrote: >>>>> Besides the security issue, my understanding is that using the >>>>> prehash variant would result in lots of interop failures as, >>>>> AFAICT, there isn't going to be much support for it in >>>>> verification libraries. >>>> >>>> Isn't that orthogonal to the question? If the prehash version is >>>> going to cause interop issues is not affected by the text quoted >>>> above. >>>> Your >>>> comment is on whether including the prehashed version at all. >>> >>> No, it's not orthogonal. If we don't include the prehash version at >>> all, there won't be interop failures. Again, I don't see any >>> significant support for the prehash variant on the verification side.= >> >> As I said your argument is about adding this variant, and not about th= e >> actual question which is whether it should be treated specially with >> regards to CA usage. >> >>> It's a bad idea to let or encourage CAs sign things using an algorith= m >>> that most verifiers are unlikely to implement. >> >> Could you please clarify what do you mean by most? (I personally inten= ded >> to implement only the prehashed variant not the other because it is th= e >> only variant that be used with HSMs). However, if there is a consensus= that >> the prehashed variant shouldn't be used, we shouldn't drag it in the >> proposal. >> >> regards, >> Nikos >> >> _______________________________________________ >> Curdle mailing list >> Curdle@ietf.org >> https://www.ietf.org/mailman/listinfo/curdle >> >=20 >=20 >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle >=20 --9bxcjM19XpIaF6bwUj6l2Bb6OSGHTjpNr-- --UVuDJPuSi17EEw11bH6tFk5l5C56jvHuo Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYwmLRAAoJEC88hzaAX42i+HIH/0E6FxFEHkNmdZlXEBtKHy/l k0IRg9TP+zvbHLJqh+UJ7h58OyRhjMJB8LQS1aVk3jYVPxGaY5WCKVFSEkc5O5wt IoUaKQKVIkIrwuGTDtHu1I5E7yHGMBW0VGuLq4+nfvRfxDVxn+b7cGhZwEf6xM2d yT1TtUZ6/xwgIK5XcWC+SfqhOh+zDVByn1YY1sr8/sYUUIbcs29NybKqzei3gp+X qEjYmBF1452aQLkpwNFp48m8uZxsTUjueh0LXulz6IoQD47hfMJYKXoEbptZLl6O /ad9hlxUvU/9zF26HcYqYNVLzetbVDkIcUHHLUZfJGysyUAP2dGLUwqBnT+DMFg= =8ea6 -----END PGP SIGNATURE----- --UVuDJPuSi17EEw11bH6tFk5l5C56jvHuo-- From nobody Fri Mar 10 00:46:00 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 4300E1295B9 for ; Fri, 10 Mar 2017 00:45:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.229, 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 eNOSIySPx3W0 for ; Fri, 10 Mar 2017 00:45:55 -0800 (PST) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FC6E126B6D for ; Fri, 10 Mar 2017 00:45:55 -0800 (PST) Received: by mail-io0-x231.google.com with SMTP id l7so44550139ioe.3 for ; Fri, 10 Mar 2017 00:45:55 -0800 (PST) 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=RrzK7NfJK0yUxowQ8RGjez+LulbHrsYXoOZmJdt7gRQ=; b=Ii+rk+Sx2iVBl4n2zqBJFySyw3ITLbhC0Lqwe5ofUMPwRRncQYAEYTm1Lr0jU8Z3FO ARHrWGBOkpzzeUa7Seaf1oYgawJjeHOBUWcK6gCRzdEGbQ9WsvlbiNRAg5BRN5J0g4Kr kUuz80+XSQ+SnbZsvKYQGMub4AqsYDGRJDQbcYDYlnk9sxYr60YvtsHFqejN9jL5tWR6 1yBQy/czO13UauMsjcNcoexpYPx5dvsxWtqvx9wM78NPKLYJ+3S1DeWKAdeW+s0Txb0g 7OR0QVAO+Ghjc5vo4avC1Di73+lrvMjKalnD9aFPuLntXsZLdP4yLmKSxshBCAg/vtVp 2Ipw== 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=RrzK7NfJK0yUxowQ8RGjez+LulbHrsYXoOZmJdt7gRQ=; b=kc69BoCV9oT7iFV9FDv8CftanzVUrQgIJ2wHAzrwuI/MznXh3twmjAQukHwkOJLgJy 5wlip8axBerZGBIDJInP+lga9OoYaFN5QcY2amhkdqrA0c/kaTi0kdpVgLn/XIgqP2Ho iYW/ebD1EQUKEGnuUu59uh2zAtWVvxBVXXHufbNq5j7VNbTJclfyO3OU/DyIIufQG2UU nLwIey1VsR4g9lmaMeTn3LA4fvjbpWsG3WLABLXfDs/rbkeInNsXIHnsAvK1b99dcMHp eIt9UxCKvnyukAc8+iwSdFnl9v+R04EFNWYKoAhYNhScFpiAWitynFHFh94uBlLfY21m 6AeQ== X-Gm-Message-State: AMke39nd+GAB3821ec682ib/WWqpSGPEHLhbnvneR181eXjO3UDsmsEO8xwTjlgYPP9gJwXmy1ijQLLsnCyqVw== X-Received: by 10.107.174.27 with SMTP id x27mr15033697ioe.35.1489135554943; Fri, 10 Mar 2017 00:45:54 -0800 (PST) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.35.213 with HTTP; Fri, 10 Mar 2017 00:45:53 -0800 (PST) In-Reply-To: References: <1481295892.20432.16.camel@redhat.com> <0e1701d254c6$46509670$d2f1c350$@augustcellars.com> <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> From: Daniel Migault Date: Fri, 10 Mar 2017 03:45:53 -0500 X-Google-Sender-Auth: AIjt4EM-Us5HNYtYZy6fnuTo1Oc Message-ID: To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a11449ffcc6873d054a5c6394 Archived-At: Cc: Curdle , Phillip Hallam-Baker , Brian Smith , "Salz, Rich" , Jim Schaad , "Dang, Quynh \(Fed\)" , Nikos Mavrogiannopoulos Subject: Re: [Curdle] Some work for the group X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 08:45:58 -0000 --001a11449ffcc6873d054a5c6394 Content-Type: text/plain; charset=UTF-8 I believe [1] that started the thread we have not really been able to find consensus. [2] provides one justification for restricting the adoption of only one variant, but I do not see this strongly supported. My understanding of the situation is that there is a demand for supporting both variant and we do not have strong argument saying only one needs to be supported. If a single variant is adopted for now, I would like to avoid is to design something that prevent the adoption of the pother variant later if needed. Yours, Daniel [1] https://www.ietf.org/mail-archive/web/curdle/current/msg00544.html [2] https://www.ietf.org/mail-archive/web/curdle/current/msg00561.html On Fri, Mar 10, 2017 at 3:24 AM, Stephen Farrell wrote: > > > On 09/03/17 21:44, Daniel Migault wrote: > > Hi, > > > > The pkix draft blocks the publication of other drafts so we need to move > > it forward as soon as possible. The blocking discussion whether or not we > > should have the EdDSA prehash version for CA. Currently, the choice > between > > the two variants is rather seen as a policy choice from the CA and I have > > not seen any strong argument for not having this variant. > Interoperability > > issue has been raised, but not exposed. > > > > If there are any strong argument against having the two variants please > > provide them clearly by March 14 on the list. > > > > If we have no strong reasons against having the two variants, I suggest > we > > agree on an updated version with the two variants before the IETF in > > Chicago. Does it sounds reasonable for everyone ? > > Sorry - I don't recall the arguments for supporting both. > And we ought I think be against multiple options where > those are not needed. > > Can you summarise the argument as to why we need both > variants? (A pointer to the list archive will be fine > if that's all that's needed.) > > Thanks, > S. > > > > > Yours, > > Daniel > > > > > > > > > > > > On Mon, Feb 20, 2017 at 9:32 AM, Daniel Migault < > daniel.migault@ericsson.com > >> wrote: > > > >> Thanks for the information Nikos. > >> > >> I agree that we should find a concensus on whether the pre-hashed > version > >> should considered or not. > >> > >> One reason for not considering it is interoperability issue. Could we > >> describe them a bit deeper ? > >> > >> Yours, > >> > >> Daniel > >> > >> -----Original Message----- > >> From: Nikos Mavrogiannopoulos [mailto:nmav@redhat.com] > >> Sent: Monday, February 20, 2017 4:39 AM > >> To: Brian Smith > >> Cc: Daniel Migault ; Phillip Hallam-Baker > < > >> phill@hallambaker.com>; Dang, Quynh (Fed) ; Jim > >> Schaad ; Curdle ; Salz, Rich < > >> rsalz@akamai.com> > >> Subject: Re: [Curdle] Some work for the group > >> > >> On Thu, 2017-02-02 at 19:13 -1000, Brian Smith wrote: > >>> Nikos Mavrogiannopoulos wrote: > >>>> Brian Smith wrote: > >>>>> Besides the security issue, my understanding is that using the > >>>>> prehash variant would result in lots of interop failures as, > >>>>> AFAICT, there isn't going to be much support for it in > >>>>> verification libraries. > >>>> > >>>> Isn't that orthogonal to the question? If the prehash version is > >>>> going to cause interop issues is not affected by the text quoted > >>>> above. > >>>> Your > >>>> comment is on whether including the prehashed version at all. > >>> > >>> No, it's not orthogonal. If we don't include the prehash version at > >>> all, there won't be interop failures. Again, I don't see any > >>> significant support for the prehash variant on the verification side. > >> > >> As I said your argument is about adding this variant, and not about the > >> actual question which is whether it should be treated specially with > >> regards to CA usage. > >> > >>> It's a bad idea to let or encourage CAs sign things using an algorithm > >>> that most verifiers are unlikely to implement. > >> > >> Could you please clarify what do you mean by most? (I personally > intended > >> to implement only the prehashed variant not the other because it is the > >> only variant that be used with HSMs). However, if there is a consensus > that > >> the prehashed variant shouldn't be used, we shouldn't drag it in the > >> proposal. > >> > >> regards, > >> Nikos > >> > >> _______________________________________________ > >> 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 > > > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > > --001a11449ffcc6873d054a5c6394 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I believe [1] that started the thread we ha= ve not really been able to find consensus.=C2=A0 [2] provides one justifica= tion for restricting the adoption of only one variant, but I do not see thi= s strongly supported.

My understanding of the situation is th= at there is a demand for supporting both variant and we do not have strong = argument saying only one needs to be supported.
If a single variant is = adopted for now, I would like to avoid is to design something that prevent = the adoption of the pother variant later if needed.

Yours,
Daniel
=

On Fri, Mar 10, 2= 017 at 3:24 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie>= wrote:


On 09/03/17 21:44, Daniel Migault wrote:
> Hi,
>
> The pkix draft blocks the publication of other drafts so=C2=A0 we need= to move
> it forward as soon as possible. The blocking discussion whether or not= we
> should have the EdDSA prehash version for CA. Currently, the choice be= tween
> the two variants is rather seen as a policy choice from the CA and I h= ave
> not seen any strong argument for not having this variant. Interoperabi= lity
> issue has been raised, but not exposed.
>
> If there are any strong argument against having the two variants pleas= e
> provide them clearly by March 14 on the list.
>
> If we have no strong reasons against having the two variants, I sugges= t we
> agree on an updated version with the two variants=C2=A0 before the IET= F in
> Chicago. Does it sounds reasonable for everyone ?

Sorry - I don't recall the arguments for supporting both.
And we ought I think be against multiple options where
those are not needed.

Can you summarise the argument as to why we need both
variants? (A pointer to the list archive will be fine
if that's all that's needed.)

Thanks,
S.

>
> Yours,
> Daniel
>
>
>
>
>
> On Mon, Feb 20, 2017 at 9:32 AM, Daniel Migault <daniel.migault@ericsson.com
>> wrote:
>
>> Thanks for the information Nikos.
>>
>> I agree that we should find a concensus on whether the pre-hashed = version
>> should considered or not.
>>
>> One reason for not considering it is interoperability issue. Could= we
>> describe them a bit deeper ?
>>
>> Yours,
>>
>> Daniel
>>
>> -----Original Message-----
>> From: Nikos Mavrogiannopoulos [mailto:nmav@redhat.com]
>> Sent: Monday, February 20, 2017 4:39 AM
>> To: Brian Smith <brian@= briansmith.org>
>> Cc: Daniel Migault <daniel.migault@ericsson.com>; Phillip Hallam-Baker <
>> phill@hallambaker.com= >; Dang, Quynh (Fed) <quynh.da= ng@nist.gov>; Jim
>> Schaad <ietf@augustce= llars.com>; Curdle <curdle@iet= f.org>; Salz, Rich <
>> rsalz@akamai.com>
>> Subject: Re: [Curdle] Some work for the group
>>
>> On Thu, 2017-02-02 at 19:13 -1000, Brian Smith wrote:
>>> Nikos Mavrogiannopoulos <nmav@redhat.com> wrote:
>>>> Brian Smith wrote:
>>>>> Besides the security issue, my understanding is that u= sing the
>>>>> prehash variant would result in lots of interop failur= es as,
>>>>> AFAICT, there isn't going to be much support for i= t in
>>>>> verification libraries.
>>>>
>>>> Isn't that orthogonal to the question? If the prehash = version is
>>>> going to cause interop issues is not affected by the text = quoted
>>>> above.
>>>> Your
>>>> comment is on whether including the prehashed version at a= ll.
>>>
>>> No, it's not orthogonal. If we don't include the preha= sh version at
>>> all, there won't be interop failures. Again, I don't s= ee any
>>> significant support for the prehash variant on the verificatio= n side.
>>
>> As I said your argument is about adding this variant, and not abou= t the
>> actual question which is whether it should be treated specially wi= th
>> regards to CA usage.
>>
>>> It's a bad idea to let or encourage CAs sign things using = an algorithm
>>> that most verifiers are unlikely to implement.
>>
>> Could you please clarify what do you mean by most? (I personally i= ntended
>> to implement only the prehashed variant not the other because it i= s the
>> only variant that be used with HSMs). However, if there is a conse= nsus that
>> the prehashed variant shouldn't be used, we shouldn't drag= it in the
>> proposal.
>>
>> regards,
>> Nikos
>>
>> _______________________________________________
>> Curdle mailing list
>> Curdle@ietf.org
>> https://www.ietf.org/mailman/listinfo/curd= le
>>
>
>
>
> _______________________________________________
> 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

--001a11449ffcc6873d054a5c6394-- From nobody Fri Mar 10 01:01:16 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 49E0312971B for ; Fri, 10 Mar 2017 01:01:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PuasBt70wx1s for ; Fri, 10 Mar 2017 01:01:13 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC8BA129715 for ; Fri, 10 Mar 2017 01:01:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 268E9BED4; Fri, 10 Mar 2017 09:01:10 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzRwSvQJTVQB; Fri, 10 Mar 2017 09:01:03 +0000 (GMT) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 57499BEE3; Fri, 10 Mar 2017 09:01:02 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1489136463; bh=vA4Sl/oyy8IyPaQgB6Y+Da+AZUEpHblWxtwNtQLxOGU=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=E3GvyCmkIxDpV+dWKcB9dMWdzCqKlPMEfqLeIO2xG6Bo029MF5/+s+kpPKOEnaH8X mPwBk+BLDBGweeTKbzGGKx9QOw2SWbHMpjDsfisqWQOwTWpLIx8AGWpPesFkd9JlBr QgvbM6uUxj2/RktsElz90U2P0XN1HWdWSR8RgDm4= To: Daniel Migault References: <1481295892.20432.16.camel@redhat.com> <0e1701d254c6$46509670$d2f1c350$@augustcellars.com> <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Fri, 10 Mar 2017 09:01:01 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="btxkD7eWDrpPOqpmntn94DonkNNreEIRB" Archived-At: Cc: Curdle , Phillip Hallam-Baker , Brian Smith , "Salz, Rich" , Jim Schaad , Nikos Mavrogiannopoulos , "Dang, Quynh \(Fed\)" Subject: Re: [Curdle] Some work for the group X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 09:01:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --btxkD7eWDrpPOqpmntn94DonkNNreEIRB Content-Type: multipart/mixed; boundary="8nmc0jmFdKNwIcbDXnMMIEcRm46Q6xkjX"; protected-headers="v1" From: Stephen Farrell To: Daniel Migault Cc: Curdle , Phillip Hallam-Baker , Brian Smith , "Salz, Rich" , Jim Schaad , "Dang, Quynh (Fed)" , Nikos Mavrogiannopoulos Message-ID: Subject: Re: [Curdle] Some work for the group References: <1481295892.20432.16.camel@redhat.com> <0e1701d254c6$46509670$d2f1c350$@augustcellars.com> <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> In-Reply-To: --8nmc0jmFdKNwIcbDXnMMIEcRm46Q6xkjX Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks Daniel, On 10/03/17 08:45, Daniel Migault wrote: > I believe [1] that started the thread we have not really been able to f= ind > consensus. [2] provides one justification for restricting the adoption= of > only one variant, but I do not see this strongly supported. >=20 > My understanding of the situation is that there is a demand for support= ing > both variant and we do not have strong argument saying only one needs t= o be > supported. FWIW, I'm not sure that I've seen any strong support for adding the pre-hash variant from those who implement or deploy but I might have missed that. I don't think "but we might want to do it in future" is good enough for that. The reason I'm pushing back on this is that if we get even a few CAs using pre-hash then everyone else will have to, or else we'll end up with a lack of interop. Such interop breakage would provide a strong argument to not define both options IMO. > If a single variant is adopted for now, I would like to avoid is to des= ign > something that prevent the adoption of the pother variant later if need= ed. That seems perfectly reasonable. Though even if an RFC says "you MUST NOT do X" we can always later obsolete or update that with another RFC that says "now you can do x":-) Cheers, S. >=20 > Yours, > Daniel >=20 > [1] https://www.ietf.org/mail-archive/web/curdle/current/msg00544.html > [2] https://www.ietf.org/mail-archive/web/curdle/current/msg00561.html >=20 > On Fri, Mar 10, 2017 at 3:24 AM, Stephen Farrell > wrote: >=20 >> >> >> On 09/03/17 21:44, Daniel Migault wrote: >>> Hi, >>> >>> The pkix draft blocks the publication of other drafts so we need to = move >>> it forward as soon as possible. The blocking discussion whether or no= t we >>> should have the EdDSA prehash version for CA. Currently, the choice >> between >>> the two variants is rather seen as a policy choice from the CA and I = have >>> not seen any strong argument for not having this variant. >> Interoperability >>> issue has been raised, but not exposed. >>> >>> If there are any strong argument against having the two variants plea= se >>> provide them clearly by March 14 on the list. >>> >>> If we have no strong reasons against having the two variants, I sugge= st >> we >>> agree on an updated version with the two variants before the IETF in= >>> Chicago. Does it sounds reasonable for everyone ? >> >> Sorry - I don't recall the arguments for supporting both. >> And we ought I think be against multiple options where >> those are not needed. >> >> Can you summarise the argument as to why we need both >> variants? (A pointer to the list archive will be fine >> if that's all that's needed.) >> >> Thanks, >> S. >> >>> >>> Yours, >>> Daniel >>> >>> >>> >>> >>> >>> On Mon, Feb 20, 2017 at 9:32 AM, Daniel Migault < >> daniel.migault@ericsson.com >>>> wrote: >>> >>>> Thanks for the information Nikos. >>>> >>>> I agree that we should find a concensus on whether the pre-hashed >> version >>>> should considered or not. >>>> >>>> One reason for not considering it is interoperability issue. Could w= e >>>> describe them a bit deeper ? >>>> >>>> Yours, >>>> >>>> Daniel >>>> >>>> -----Original Message----- >>>> From: Nikos Mavrogiannopoulos [mailto:nmav@redhat.com] >>>> Sent: Monday, February 20, 2017 4:39 AM >>>> To: Brian Smith >>>> Cc: Daniel Migault ; Phillip Hallam-Bak= er >> < >>>> phill@hallambaker.com>; Dang, Quynh (Fed) ; Jim= >>>> Schaad ; Curdle ; Salz, Ric= h < >>>> rsalz@akamai.com> >>>> Subject: Re: [Curdle] Some work for the group >>>> >>>> On Thu, 2017-02-02 at 19:13 -1000, Brian Smith wrote: >>>>> Nikos Mavrogiannopoulos wrote: >>>>>> Brian Smith wrote: >>>>>>> Besides the security issue, my understanding is that using the >>>>>>> prehash variant would result in lots of interop failures as, >>>>>>> AFAICT, there isn't going to be much support for it in >>>>>>> verification libraries. >>>>>> >>>>>> Isn't that orthogonal to the question? If the prehash version is >>>>>> going to cause interop issues is not affected by the text quoted >>>>>> above. >>>>>> Your >>>>>> comment is on whether including the prehashed version at all. >>>>> >>>>> No, it's not orthogonal. If we don't include the prehash version at= >>>>> all, there won't be interop failures. Again, I don't see any >>>>> significant support for the prehash variant on the verification sid= e. >>>> >>>> As I said your argument is about adding this variant, and not about = the >>>> actual question which is whether it should be treated specially with= >>>> regards to CA usage. >>>> >>>>> It's a bad idea to let or encourage CAs sign things using an algori= thm >>>>> that most verifiers are unlikely to implement. >>>> >>>> Could you please clarify what do you mean by most? (I personally >> intended >>>> to implement only the prehashed variant not the other because it is = the >>>> only variant that be used with HSMs). However, if there is a consens= us >> that >>>> the prehashed variant shouldn't be used, we shouldn't drag it in the= >>>> proposal. >>>> >>>> regards, >>>> Nikos >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> >> _______________________________________________ >> Curdle mailing list >> Curdle@ietf.org >> https://www.ietf.org/mailman/listinfo/curdle >> >> >=20 >=20 >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle >=20 --8nmc0jmFdKNwIcbDXnMMIEcRm46Q6xkjX-- --btxkD7eWDrpPOqpmntn94DonkNNreEIRB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYwmtNAAoJEC88hzaAX42iNN4IALq4lfgLXWry2HD0CkGr2LVO o1x2FgBmDIZbuRwxu6mhA9TIS4ZQU7kcv/goeP1aNnE8W5GdWibco29AZATfHkhP gs7qMDUYFPYjiqpZMDUR1cxEVOAf/xuQlLH3mkJ1wbOmbr/GxvMLEtQwWntKMONi bZJkU0dnf+invP1X25uUfqan51ZlWPUXWI9RrpWSya5d+eLWYBCwm7OMMbPaXta5 jSJSRyhSlWeaS+v3Y92EqIoKJZa73luUqEPc9iMotESnrdRd574YUcy5h0ZPO5vt idm00NLr3uM/ET5E5eo3D+oK/fsJgiT5/zrobRmsjibuszaH8DVOV6f5Vb/SzUU= =belL -----END PGP SIGNATURE----- --btxkD7eWDrpPOqpmntn94DonkNNreEIRB-- From nobody Fri Mar 10 08:14: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 ED92B129979 for ; Fri, 10 Mar 2017 08:14:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 Hnzl37CtBVvf for ; Fri, 10 Mar 2017 08:14:33 -0800 (PST) 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 A052D129661 for ; Fri, 10 Mar 2017 08:14:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 09C0A3004AE for ; Fri, 10 Mar 2017 11:14:33 -0500 (EST) 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 NRaUCSE-0gRw for ; Fri, 10 Mar 2017 11:14:32 -0500 (EST) Received: from [10.5.245.234] (wsip-98-172-24-238.dc.dc.cox.net [98.172.24.238]) by mail.smeinc.net (Postfix) with ESMTPSA id 4307A30024A; Fri, 10 Mar 2017 11:14:30 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Russ Housley In-Reply-To: Date: Fri, 10 Mar 2017 11:14:29 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <727936E0-E1E4-42B0-BB5A-D3EFB23ED034@vigilsec.com> References: <148880412594.6555.2087937598510853337.idtracker@ietfa.amsl.com> <75669986-8814-421C-94E4-60428544D69C@vigilsec.com> <6C7D22F4-0918-4EF4-B2A4-249061CD49D5@vigilsec.com> To: Rich Salz X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "curdle@ietf.org" Subject: Re: [Curdle] Progressing with draft-ietf-curdle-cms-ecdh-new-curves X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 16:14:37 -0000 Rich: >> We really need to sort this issue. The S/MIME 4.0 specification has = a MUST >> dependency on draft-ietf-curdle-cms-ecdh-new-curves, and it cannot be >> implemented unless object identifiers are assigned. >=20 > You want the chairs to just pick an arc? Or do you have a preference = that you'd like the WG to use? Or the wg-chairs to pressure for? I think we have two choices: (1) get the OIDs from the same arc that was used in curdle-pkix; or (2) get the OIDs from the S/MIME arc manages by IANA. Either one works for me. Russ From nobody Fri Mar 10 08:35:30 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 0FCB2128B38 for ; Fri, 10 Mar 2017 08:35:30 -0800 (PST) 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 VPh4f1hkg6Ix for ; Fri, 10 Mar 2017 08:35:28 -0800 (PST) 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 E440912949E for ; Fri, 10 Mar 2017 08:35:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 2F5B23004AE for ; Fri, 10 Mar 2017 11:35:27 -0500 (EST) 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 yods22Lcq9-R for ; Fri, 10 Mar 2017 11:35:25 -0500 (EST) Received: from russhousleymbp.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 58A6130024A; Fri, 10 Mar 2017 11:35:25 -0500 (EST) From: Russ Housley Message-Id: <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_A201BB6A-86C0-4C0E-A085-BB789C3D296C" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Fri, 10 Mar 2017 11:35:24 -0500 In-Reply-To: To: Daniel Migault References: <1481295892.20432.16.camel@redhat.com> <0e1701d254c6$46509670$d2f1c350$@augustcellars.com> <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Curdle Subject: Re: [Curdle] Some work for the group X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 16:35:30 -0000 --Apple-Mail=_A201BB6A-86C0-4C0E-A085-BB789C3D296C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Does anyone see the need for pre-hash for anything other than CRLs? Russ > On Mar 9, 2017, at 4:44 PM, Daniel Migault = wrote: >=20 > Hi,=20 >=20 > The pkix draft blocks the publication of other drafts so we need to = move it forward as soon as possible. The blocking discussion whether or = not we should have the EdDSA prehash version for CA. Currently, the = choice between the two variants is rather seen as a policy choice from = the CA and I have not seen any strong argument for not having this = variant. Interoperability issue has been raised, but not exposed.=20 >=20 > If there are any strong argument against having the two variants = please provide them clearly by March 14 on the list.=20 >=20 > If we have no strong reasons against having the two variants, I = suggest we agree on an updated version with the two variants before the = IETF in Chicago. Does it sounds reasonable for everyone ? >=20 > Yours,=20 > Daniel=20 >=20 >=20 >=20 >=20 >=20 > On Mon, Feb 20, 2017 at 9:32 AM, Daniel Migault = > = wrote: > Thanks for the information Nikos. >=20 > I agree that we should find a concensus on whether the pre-hashed = version should considered or not. >=20 > One reason for not considering it is interoperability issue. Could we = describe them a bit deeper ? >=20 > Yours, >=20 > Daniel >=20 > -----Original Message----- > From: Nikos Mavrogiannopoulos [mailto:nmav@redhat.com = ] > Sent: Monday, February 20, 2017 4:39 AM > To: Brian Smith > > Cc: Daniel Migault >; Phillip Hallam-Baker = >; Dang, Quynh = (Fed) >; Jim Schaad = >; Curdle = >; Salz, Rich > > Subject: Re: [Curdle] Some work for the group >=20 > On Thu, 2017-02-02 at 19:13 -1000, Brian Smith wrote: > > Nikos Mavrogiannopoulos > = wrote: > > > Brian Smith wrote: > > > > Besides the security issue, my understanding is that using the > > > > prehash variant would result in lots of interop failures as, > > > > AFAICT, there isn't going to be much support for it in > > > > verification libraries. > > > > > > Isn't that orthogonal to the question? If the prehash version is > > > going to cause interop issues is not affected by the text quoted > > > above. > > > Your > > > comment is on whether including the prehashed version at all. > > > > No, it's not orthogonal. If we don't include the prehash version at > > all, there won't be interop failures. Again, I don't see any > > significant support for the prehash variant on the verification = side. >=20 > As I said your argument is about adding this variant, and not about = the actual question which is whether it should be treated specially with = regards to CA usage. >=20 > > It's a bad idea to let or encourage CAs sign things using an = algorithm > > that most verifiers are unlikely to implement. >=20 > Could you please clarify what do you mean by most? (I personally = intended to implement only the prehashed variant not the other because = it is the only variant that be used with HSMs). However, if there is a = consensus that the prehashed variant shouldn't be used, we shouldn't = drag it in the proposal. >=20 > regards, > Nikos >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle = >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle --Apple-Mail=_A201BB6A-86C0-4C0E-A085-BB789C3D296C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Does anyone see the need for pre-hash for anything other than = CRLs?

Russ


On = Mar 9, 2017, at 4:44 PM, Daniel Migault <daniel.migault@ericsson.com> wrote:

Hi,

The pkix draft blocks the publication of other drafts = so  we need to move it forward as soon as possible. The blocking = discussion whether or not we should have the EdDSA prehash version for = CA. Currently, the choice between the two variants is rather seen as a = policy choice from the CA and I have not seen any strong argument for = not having this variant. Interoperability issue has been raised, but not = exposed.

If there are any strong argument = against having the two variants please provide them clearly by March 14 = on the list.

If we have no strong reasons = against having the two variants, I suggest we agree on an updated = version with the two variants  before the IETF in Chicago. Does it = sounds reasonable for everyone ?

Yours,
Daniel





On Mon, Feb 20, 2017 at 9:32 AM, = Daniel Migault <daniel.migault@ericsson.com> wrote:
Thanks for the = information Nikos.

I agree that we should find a concensus on whether the pre-hashed = version should considered or not.

One reason for not considering it is interoperability issue. Could we = describe them a bit deeper ?

Yours,

Daniel

-----Original Message-----
From: Nikos Mavrogiannopoulos [mailto:nmav@redhat.com]
Sent: Monday, February 20, 2017 4:39 AM
To: Brian Smith <brian@briansmith.org>
Cc: Daniel Migault <daniel.migault@ericsson.com>; Phillip Hallam-Baker = <phill@hallambaker.com>; Dang, Quynh (Fed) <quynh.dang@nist.gov>; Jim Schaad <ietf@augustcellars.com>; Curdle <curdle@ietf.org>; = Salz, Rich <rsalz@akamai.com>
Subject: Re: [Curdle] Some work for the group

On Thu, 2017-02-02 at = 19:13 -1000, Brian Smith wrote:
> Nikos Mavrogiannopoulos <nmav@redhat.com> wrote:
> > Brian Smith wrote:
> > > Besides the security issue, my understanding is that = using the
> > > prehash variant would result in lots of interop failures = as,
> > > AFAICT, there isn't going to be much support for it in
> > > verification libraries.
> >
> > Isn't that orthogonal to the question? If the prehash version = is
> > going to cause interop issues is not affected by the text = quoted
> > above.
> > Your
> > comment is on whether including the prehashed version at = all.
>
> No, it's not orthogonal. If we don't include the prehash version = at
> all, there won't be interop failures. Again, I don't see any
> significant support for the prehash variant on the verification = side.

As I said your argument is about adding this variant, and not about the = actual question which is whether it should be treated specially with = regards to CA usage.

> It's a bad idea to let or encourage CAs sign things using an = algorithm
> that most verifiers are unlikely to implement.

Could you please clarify what do you mean by most? (I personally = intended to implement only the prehashed variant not the other because = it is the only variant that be used with HSMs). However, if there is a = consensus that the prehashed variant shouldn't be used, we shouldn't = drag it in the proposal.

regards,
Nikos

_______________________________________________
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

= --Apple-Mail=_A201BB6A-86C0-4C0E-A085-BB789C3D296C-- From nobody Fri Mar 10 08:48:20 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 3774512962E for ; Fri, 10 Mar 2017 08:48:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 ZUBwQiE4kwKX for ; Fri, 10 Mar 2017 08:48:18 -0800 (PST) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 5683812949E for ; Fri, 10 Mar 2017 08:48:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 91F5222F51; Fri, 10 Mar 2017 18:48:16 +0200 (EET) 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 6faFUezacHEj; Fri, 10 Mar 2017 18:48:16 +0200 (EET) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 5D86C27F; Fri, 10 Mar 2017 18:48:16 +0200 (EET) Date: Fri, 10 Mar 2017 18:48:10 +0200 From: Ilari Liusvaara To: Russ Housley Message-ID: <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: Daniel Migault , Curdle Subject: Re: [Curdle] Some work for the group X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 16:48:20 -0000 On Fri, Mar 10, 2017 at 11:35:24AM -0500, Russ Housley wrote: > Does anyone see the need for pre-hash for anything other than CRLs? I don't. AFAICT, even 4kB is plenty for most certificates (even blogspot certs, which have lots of SANs fit into 4kB). The only objects in PKIX that aren't very likely to fit into 4kB are CRLs. -Ilari From nobody Fri Mar 10 09:13:30 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 89D4012967D for ; Fri, 10 Mar 2017 09:13:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 mc3C4oSmIjWg for ; Fri, 10 Mar 2017 09:13:27 -0800 (PST) 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 612591295FD for ; Fri, 10 Mar 2017 09:13:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 8E7BD3004AF for ; Fri, 10 Mar 2017 12:13:26 -0500 (EST) 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 K9if0_5u5d0G for ; Fri, 10 Mar 2017 12:13:25 -0500 (EST) Received: from russhousleymbp.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 0E06E3002C4; Fri, 10 Mar 2017 12:13:25 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Russ Housley In-Reply-To: Date: Fri, 10 Mar 2017 12:13:24 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Daniel Migault X-Mailer: Apple Mail (2.3259) Archived-At: Cc: curdle Subject: Re: [Curdle] questions on draft-ietf-curdle-cms-eddsa-signatures-03.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 17:13:28 -0000 Daniel: > Use of EdDSA Signatures in the Cryptographic Message Syntax (CMS) > >=20 > 2. EdDSA Signature Algorithm >=20 > One of the parameters of the EdDSA algorithm is the "prehash" > function. This may be the identity function, resulting in an > algorithm called PureEdDSA, or a collision-resistant hash function, > resulting in an algorithm called HashEdDSA. In most situations the > CMS SignedData includes signed attributes, including the message > digest of the content. Since HashEdDSA offers no benefit when = signed > attributes are present, only PureEdDSA is used with the CMS. >=20 > MGLT: My understanding of the two latest sentences is that, in most = cases the CMS when used with signed attributes may specify the hash of = the content. As prehashing is performed by CMS, there is no need to have = a pre hash variant version.=20 >=20 > =46rom the two sentences it may appear that without signed attributes, = they might be some advantages of having HashEdDSA over PureEdDSA. If = that is the case, maybe we should provide them and then motivate our = choice. =20 > =20 > What is unclear to me is why signed attributed make it different ? My = understanding is that in any case digestAlgorithm is used to compute the = digest of the eContent and when defined additional signed attributes. =20= CMS supports signatures with and without signed attributes. In most = cases, signed attributes are present. When signed attributes are = present, the message-digest attribute MUST be one of the attributes. It = was signed to work like this: IF (signed attributes are absent) THEN md =3D Hash(content) ELSE message-digest attribute =3D Hash(content); md =3D Hash(DER(SignedAttributes)) Sign(md) > I am also wondering if we were using the prehash variant a combination = of digestAlgorithm with the prehash function would not be problematic. = At least, the signing operation would not be performed on the same = content this might add unnecessary overhead. If that is the case, it = would provide a generic motivation to only consider PureHash with CMS. =20= Yes, HashEdDSA could be useful when signed attributes are present. I = was not including HashEdDSA in this document because curdle-pkix did not = support that algorithm. If that changes (as is being discussed on a = separate thread), then it should be supported here as well. > My understanding of EdDSA is that when PureEdDSA is possible, it is = always recommended over HashEdDSA. I assume this is also recommended for = CMS. =20 We could RECOMMEND PureEdDSA when signed attributes are present, and we = could RECOMMEND PureEdDSA when signed attributes are absent, but the = content is not very large. > 2.3. Message Digest Algorithm Identifiers >=20 > When the signer includes signed attributes, a message digest > algorithm is used to compute the message digest on the eContent > value. When signing with Ed25519, the message digest algorithm = MUST > be SHA-512 [RFC4634]. When signing with Ed448, the message digest > algorithm MUST be SHAKE256 [FIPS202] with a 512-bit output value. >=20 > MGLT: I am wondering why the digestAlgorithm cannot be the identity.=20= Since CMS allows multiple signatures on the content, the idea is to tell = the implementation which hash functions are needed in a field that = appears before the content that needs to be hashed. > Signing with Ed25519 uses SHA-512 as part of the signing operation, > and signing with Ed448 uses SHAKE256 as part of the signing > operation. >=20 > MGLT: I am wondering if the text above wants to specify that the = digest algorithm specified are already part of the signature and as such = no additional hash functions really need to be added or if there is = another motivation for this text. =20 This is the rationale for the earlier statement. > For convenience, the object identifiers and parameter syntax for > these algorithms are repeated here: >=20 > MGLT: IOD are repeated, maybe we could add a reference where these = have been defined. -- Note that the ref becomes clearer on the next = page. These OIDs all come from the NIST website, but NIST does not publish an = ASN.1 module that includes them. Most of them appear in the ASN.1 module in the curdle-pkix document. I = should probably add a module to this document too. > 2.4. EdDSA Signatures >=20 > The id-Ed25519 and id-Ed448 object identifiers are also used for > signature values. When used to identify signature algorithms, the > AlgorithmIdentifier parameters field MUST be absent. >=20 > MGLT: I do not understand why id-Ed25519 and id-Ed448 are used for the = signature value. My understanding is that the Signer Info carries the = signature algorithm, which defines the signature. =20 SignerInfo ::=3D SEQUENCE { version CMSVersion, sid SignerIdentifier, digestAlgorithm DigestAlgorithmIdentifier, signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, signatureAlgorithm SignatureAlgorithmIdentifier, signature SignatureValue, unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } This text is talking about the SignatureAlgorithmIdentifier, which uses = the same OID as the subject public key in the certificate that will be = used to validate the signature. > 3. Signed-data Conventions >=20 > The processing depends on whether the signer includes signed > attributes. >=20 > The inclusion of signed attributes is preferred, but the = conventions > for signed-data without signed attributes are provided for > completeness. > =20 > MGLT: Maybe we could briefly explain or provide a reference why signed = attributes are preferred. =20 This is a statement about what most implementation do. S/MIME says that = sending agents SHOULD include signed attributes, and I cannot think of = any that don=E2=80=99t do so. > 3.1. Signed-data Conventions With Signed Attributes >=20 > The SignedData digestAlgorithms field includes the identifiers of = the > message digest algorithms used by one or more signer. There MAY be > any number of elements in the collection, including zero. When > signing with Ed25519, the digestAlgorithm SHOULD include id-sha512, > and if present, the algorithm parameters field MUST be absent. = When >=20 > signing with Ed448, the digestAlgorithm SHOULD include > id-shake256-len, and if present, the algorithm parameters field = MUST > also be present, and the parameter MUST contain 512, encoded as a > positive integer value. >=20 > MGLT: For which reason do we have a SHOULD and not a MUST, as the = hash function specified have a MUST status in te message digest = identifier. =20 This is at odds with your comment on section 2. I=E2=80=99m fine with = making this a MUST. Russ From nobody Fri Mar 10 13:33: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 A174612949F for ; Fri, 10 Mar 2017 13:33:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4GhVnTumHEU2 for ; Fri, 10 Mar 2017 13:33:11 -0800 (PST) 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 9B5C312948C for ; Fri, 10 Mar 2017 13:33:11 -0800 (PST) X-AuditID: c6180641-c53ff70000000a06-58-58c2d53e2147 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by (Symantec Mail Security) with SMTP id 9D.6B.02566.E35D2C85; Fri, 10 Mar 2017 17:33:05 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0319.002; Fri, 10 Mar 2017 16:33:07 -0500 From: Daniel Migault To: Russ Housley , Rich Salz Thread-Topic: [Curdle] Progressing with draft-ietf-curdle-cms-ecdh-new-curves Thread-Index: AQHSlpKFJ/gWWK7n0UiSLwMk+HMA2qGNSzAAgAAw9QCAAR1RgIAABFXQ Date: Fri, 10 Mar 2017 21:33:07 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118BA41A1@eusaamb107.ericsson.se> References: <148880412594.6555.2087937598510853337.idtracker@ietfa.amsl.com> <75669986-8814-421C-94E4-60428544D69C@vigilsec.com> <6C7D22F4-0918-4EF4-B2A4-249061CD49D5@vigilsec.com> <727936E0-E1E4-42B0-BB5A-D3EFB23ED034@vigilsec.com> In-Reply-To: <727936E0-E1E4-42B0-BB5A-D3EFB23ED034@vigilsec.com> 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+NgFvrBLMWRmVeSWpSXmKPExsUyuXRPlK7j1UMRBtens1psXTiL2eLVi5vs Fv+3dLI4MHtMPrKA2WPJkp9MHqvufGENYI7isklJzcksSy3St0vgypjfHVWwkbPiQNdOxgbG U+xdjJwcEgImEktuTWLpYuTiEBJYzygxpfs2E4SznFFiR9dhRpAqNgEjibZD/UAdHBwiAq4S F1vlQMLMAuoS33o6mEFsYQEfifcHLkKV+Er8a8kHCYsIuElc/tcHVsIioCqxast2NhCbF6hk 78PPUHu3M0lMvnsTLMEp4CDRee4UC4jNKCAm8f3UGiaIXeISt57MZ4I4WkBiyZ7zzBC2qMTL x/9YIWwliTmvrzFD1OtILNj9iQ3C1pZYtvA1M8RiQYmTM5+wTGAUnYVk7CwkLbOQtMxC0rKA kWUVI0dpcUFObrqR4SZGYHwck2Bz3MG4t9fzEKMAB6MSD69B+6EIIdbEsuLK3EOMEhzMSiK8 XQKHI4R4UxIrq1KL8uOLSnNSiw8xSnOwKInzXg+5Hy4kkJ5YkpqdmlqQWgSTZeLglGpgnGAQ +WK1+q5Nn/+ueym5/uWN3+rbp+cu+Xs4aILu/pJPfQ8eB77hfyScsbfMXXhdxq3iE+p5+6ff c7d93Kz6RV3hNONEnx2zZ2vfL+mZWqvjtjuLxfx0Sg3vc5fAXacShIJ5XmXUr5d12vGKzU9n /8SV9QVmMVsnG7tZT5Q5U/nJqHuNyLPU5UosxRmJhlrMRcWJAEbX/VaLAgAA Archived-At: Cc: "curdle@ietf.org" Subject: Re: [Curdle] Progressing with draft-ietf-curdle-cms-ecdh-new-curves X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 21:33:13 -0000 Hi,=20 Please provide your preference by Tuesday March 14.=20 (1) get the OIDs from the same arc that was used in curdle-pkix; or (2) get the OIDs from the S/MIME arc manages by IANA. Yours,=20 Daniel -----Original Message----- From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Russ Housley Sent: Friday, March 10, 2017 11:14 AM To: Rich Salz Cc: curdle@ietf.org Subject: Re: [Curdle] Progressing with draft-ietf-curdle-cms-ecdh-new-curve= s Rich: >> We really need to sort this issue. The S/MIME 4.0 specification has=20 >> a MUST dependency on draft-ietf-curdle-cms-ecdh-new-curves, and it=20 >> cannot be implemented unless object identifiers are assigned. >=20 > You want the chairs to just pick an arc? Or do you have a preference tha= t you'd like the WG to use? Or the wg-chairs to pressure for? I think we have two choices: (1) get the OIDs from the same arc that was used in curdle-pkix; or (2) get the OIDs from the S/MIME arc manages by IANA. Either one works for me. Russ _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle From nobody Fri Mar 10 13:39: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 A9AB512948C for ; Fri, 10 Mar 2017 13:39:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z76nDIFCrIAV for ; Fri, 10 Mar 2017 13:39:50 -0800 (PST) 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 864C7129452 for ; Fri, 10 Mar 2017 13:39:50 -0800 (PST) X-AuditID: c618062d-d5fff700000009d8-de-58c32e0c6319 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by (Symantec Mail Security) with SMTP id 1A.1E.02520.C0E23C85; Fri, 10 Mar 2017 23:51:56 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0319.002; Fri, 10 Mar 2017 16:39:49 -0500 From: Daniel Migault To: Russ Housley Thread-Topic: [Curdle] questions on draft-ietf-curdle-cms-eddsa-signatures-03.txt Thread-Index: AQHSmR//36gyino1N0G6VRpt0AMYXKGOpNEA///x9eA= Date: Fri, 10 Mar 2017 21:39:49 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118BA41C0@eusaamb107.ericsson.se> References: In-Reply-To: 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyuXRPoC6P3uEIg7mz1S22LpzFbPHqxU12 ByaPJUt+MnmsuvOFNYApissmJTUnsyy1SN8ugSuj5/YmpoIjvhWX/51hbWA84t3FyMkhIWAi MePxNNYuRi4OIYH1jBIr1mxnh3CWM0p8XtrKDFLFJmAk0Xaonx3EFhFQl/g7/wKYzSwgI9H2 8xMTiC0sECTxc+YsqJpgiTt7VzFD2FYSK3f9YAWxWQRUJfZPXQsW5xXwldja/JoNYlkbo8T2 q3OBEhwcnAIOEttfpYLUMAqISXw/tYYJYpe4xK0n85kgrhaQWLLnPDOELSrx8vE/VghbSWLO 62tgY5gFNCXW79KHaFWUmNL9kB1iraDEyZlPWCYwis5CMnUWQscsJB2zkHQsYGRZxchRWlyQ k5tuZLCJERgLxyTYdHcw3p/ueYhRgINRiYd3w/dDEUKsiWXFlbmHGCU4mJVEeLsEDkcI8aYk VlalFuXHF5XmpBYfYpTmYFES541bfT9cSCA9sSQ1OzW1ILUIJsvEwSnVwBipJip9wfvP6537 theWbnA+vrJwY6q5ycMvbksTAhhXRyhsk7Z6nRex0+nQkqWXvOcXyjFeV+DYyPrX8NcLSe7D 3eszQn9m9H0+kvd0rtLek40p0vHSPXc0F2p3l1902C+kWhyrH3pk0tcrNxOv/1Uz6d2eEbp2 r6bR7w07F/ZuXvFeYc0j5jNKLMUZiYZazEXFiQBmTtqLgQIAAA== Archived-At: Cc: curdle Subject: Re: [Curdle] questions on draft-ietf-curdle-cms-eddsa-signatures-03.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 21:39:51 -0000 VGhhbmsgeW91IFJ1c3MgZm9yIHRoZSByZXNwb25zZXMuIFRoZXkgd2VyZSB1c2VmdWwgdG8gbWUu DQoNCllvdXJzLCANCkRhbmllbA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog UnVzcyBIb3VzbGV5IFttYWlsdG86aG91c2xleUB2aWdpbHNlYy5jb21dIA0KU2VudDogRnJpZGF5 LCBNYXJjaCAxMCwgMjAxNyAxMjoxMyBQTQ0KVG86IERhbmllbCBNaWdhdWx0IDxkYW5pZWwubWln YXVsdEBlcmljc3Nvbi5jb20+DQpDYzogY3VyZGxlIDxjdXJkbGVAaWV0Zi5vcmc+DQpTdWJqZWN0 OiBSZTogW0N1cmRsZV0gcXVlc3Rpb25zIG9uIGRyYWZ0LWlldGYtY3VyZGxlLWNtcy1lZGRzYS1z aWduYXR1cmVzLTAzLnR4dA0KDQpEYW5pZWw6DQoNCj4gICAgVXNlIG9mIEVkRFNBIFNpZ25hdHVy ZXMgaW4gdGhlIENyeXB0b2dyYXBoaWMgTWVzc2FnZSBTeW50YXggKENNUykNCj4gICAgICAgICAg ICAgPGRyYWZ0LWlldGYtY3VyZGxlLWNtcy1lZGRzYS1zaWduYXR1cmVzLTAzLnR4dD4NCj4gDQo+ IDIuICBFZERTQSBTaWduYXR1cmUgQWxnb3JpdGhtDQo+IA0KPiAgICBPbmUgb2YgdGhlIHBhcmFt ZXRlcnMgb2YgdGhlIEVkRFNBIGFsZ29yaXRobSBpcyB0aGUgInByZWhhc2giDQo+ICAgIGZ1bmN0 aW9uLiAgVGhpcyBtYXkgYmUgdGhlIGlkZW50aXR5IGZ1bmN0aW9uLCByZXN1bHRpbmcgaW4gYW4N Cj4gICAgYWxnb3JpdGhtIGNhbGxlZCBQdXJlRWREU0EsIG9yIGEgY29sbGlzaW9uLXJlc2lzdGFu dCBoYXNoIGZ1bmN0aW9uLA0KPiAgICByZXN1bHRpbmcgaW4gYW4gYWxnb3JpdGhtIGNhbGxlZCBI YXNoRWREU0EuICBJbiBtb3N0IHNpdHVhdGlvbnMgdGhlDQo+ICAgIENNUyBTaWduZWREYXRhIGlu Y2x1ZGVzIHNpZ25lZCBhdHRyaWJ1dGVzLCBpbmNsdWRpbmcgdGhlIG1lc3NhZ2UNCj4gICAgZGln ZXN0IG9mIHRoZSBjb250ZW50LiBTaW5jZSBIYXNoRWREU0Egb2ZmZXJzIG5vIGJlbmVmaXQgd2hl biBzaWduZWQNCj4gICAgYXR0cmlidXRlcyBhcmUgcHJlc2VudCwgb25seSBQdXJlRWREU0EgaXMg dXNlZCB3aXRoIHRoZSBDTVMuDQo+IA0KPiBNR0xUOiBNeSB1bmRlcnN0YW5kaW5nIG9mIHRoZSB0 d28gbGF0ZXN0IHNlbnRlbmNlcyBpcyB0aGF0LCBpbiBtb3N0IGNhc2VzIHRoZSBDTVMgd2hlbiB1 c2VkIHdpdGggc2lnbmVkIGF0dHJpYnV0ZXMgbWF5IHNwZWNpZnkgdGhlIGhhc2ggb2YgdGhlIGNv bnRlbnQuIEFzIHByZWhhc2hpbmcgaXMgcGVyZm9ybWVkIGJ5IENNUywgdGhlcmUgaXMgbm8gbmVl ZCB0byBoYXZlIGEgcHJlIGhhc2ggdmFyaWFudCB2ZXJzaW9uLiANCj4gDQo+IEZyb20gdGhlIHR3 byBzZW50ZW5jZXMgaXQgbWF5IGFwcGVhciB0aGF0IHdpdGhvdXQgc2lnbmVkIGF0dHJpYnV0ZXMs IHRoZXkgbWlnaHQgYmUgc29tZSBhZHZhbnRhZ2VzIG9mIGhhdmluZyBIYXNoRWREU0Egb3ZlciBQ dXJlRWREU0EuIElmIHRoYXQgaXMgdGhlIGNhc2UsIG1heWJlIHdlIHNob3VsZCBwcm92aWRlIHRo ZW0gYW5kIHRoZW4gbW90aXZhdGUgb3VyIGNob2ljZS4gICANCj4gIA0KPiBXaGF0IGlzIHVuY2xl YXIgdG8gbWUgaXMgd2h5IHNpZ25lZCBhdHRyaWJ1dGVkIG1ha2UgaXQgZGlmZmVyZW50ID8gTXkg dW5kZXJzdGFuZGluZyBpcyB0aGF0IGluIGFueSBjYXNlIGRpZ2VzdEFsZ29yaXRobSBpcyB1c2Vk IHRvIGNvbXB1dGUgdGhlIGRpZ2VzdCBvZiB0aGUgZUNvbnRlbnQgYW5kIHdoZW4gZGVmaW5lZCBh ZGRpdGlvbmFsIHNpZ25lZCBhdHRyaWJ1dGVzLiAgDQoNCkNNUyBzdXBwb3J0cyBzaWduYXR1cmVz IHdpdGggYW5kIHdpdGhvdXQgc2lnbmVkIGF0dHJpYnV0ZXMuICBJbiBtb3N0IGNhc2VzLCBzaWdu ZWQgYXR0cmlidXRlcyBhcmUgcHJlc2VudC4gIFdoZW4gc2lnbmVkIGF0dHJpYnV0ZXMgYXJlIHBy ZXNlbnQsIHRoZSBtZXNzYWdlLWRpZ2VzdCBhdHRyaWJ1dGUgTVVTVCBiZSBvbmUgb2YgdGhlIGF0 dHJpYnV0ZXMuICBJdCB3YXMgc2lnbmVkIHRvIHdvcmsgbGlrZSB0aGlzOg0KDQogICAgICBJRiAo c2lnbmVkIGF0dHJpYnV0ZXMgYXJlIGFic2VudCkNCiAgICAgIFRIRU4gbWQgPSBIYXNoKGNvbnRl bnQpDQogICAgICBFTFNFIG1lc3NhZ2UtZGlnZXN0IGF0dHJpYnV0ZSA9IEhhc2goY29udGVudCk7 DQogICAgICAgICAgIG1kID0gSGFzaChERVIoU2lnbmVkQXR0cmlidXRlcykpDQoNCiAgICAgIFNp Z24obWQpDQoNCj4gSSBhbSBhbHNvIHdvbmRlcmluZyBpZiB3ZSB3ZXJlIHVzaW5nIHRoZSBwcmVo YXNoIHZhcmlhbnQgYSBjb21iaW5hdGlvbiBvZiBkaWdlc3RBbGdvcml0aG0gd2l0aCB0aGUgcHJl aGFzaCBmdW5jdGlvbiB3b3VsZCBub3QgYmUgcHJvYmxlbWF0aWMuIEF0IGxlYXN0LCB0aGUgc2ln bmluZyBvcGVyYXRpb24gd291bGQgbm90IGJlIHBlcmZvcm1lZCBvbiB0aGUgc2FtZSBjb250ZW50 IHRoaXMgbWlnaHQgYWRkIHVubmVjZXNzYXJ5IG92ZXJoZWFkLiBJZiB0aGF0IGlzIHRoZSBjYXNl LCBpdCB3b3VsZCBwcm92aWRlIGEgZ2VuZXJpYyBtb3RpdmF0aW9uIHRvIG9ubHkgY29uc2lkZXIg UHVyZUhhc2ggd2l0aCBDTVMuICANCg0KWWVzLCBIYXNoRWREU0EgY291bGQgYmUgdXNlZnVsIHdo ZW4gc2lnbmVkIGF0dHJpYnV0ZXMgYXJlIHByZXNlbnQuICBJIHdhcyBub3QgaW5jbHVkaW5nIEhh c2hFZERTQSBpbiB0aGlzIGRvY3VtZW50IGJlY2F1c2UgY3VyZGxlLXBraXggZGlkIG5vdCBzdXBw b3J0IHRoYXQgYWxnb3JpdGhtLiAgSWYgdGhhdCBjaGFuZ2VzIChhcyBpcyBiZWluZyBkaXNjdXNz ZWQgb24gYSBzZXBhcmF0ZSB0aHJlYWQpLCB0aGVuIGl0IHNob3VsZCBiZSBzdXBwb3J0ZWQgaGVy ZSBhcyB3ZWxsLg0KDQo+IE15IHVuZGVyc3RhbmRpbmcgb2YgRWREU0EgaXMgdGhhdCB3aGVuIFB1 cmVFZERTQSBpcyBwb3NzaWJsZSwgaXQgaXMgYWx3YXlzIHJlY29tbWVuZGVkIG92ZXIgSGFzaEVk RFNBLiBJIGFzc3VtZSB0aGlzIGlzIGFsc28gcmVjb21tZW5kZWQgZm9yIENNUy4gIA0KDQpXZSBj b3VsZCBSRUNPTU1FTkQgUHVyZUVkRFNBIHdoZW4gc2lnbmVkIGF0dHJpYnV0ZXMgYXJlIHByZXNl bnQsIGFuZCB3ZSBjb3VsZCBSRUNPTU1FTkQgUHVyZUVkRFNBIHdoZW4gc2lnbmVkIGF0dHJpYnV0 ZXMgYXJlIGFic2VudCwgYnV0IHRoZSBjb250ZW50IGlzIG5vdCB2ZXJ5IGxhcmdlLg0KDQoNCj4g Mi4zLiAgTWVzc2FnZSBEaWdlc3QgQWxnb3JpdGhtIElkZW50aWZpZXJzDQo+IA0KPiAgICBXaGVu IHRoZSBzaWduZXIgaW5jbHVkZXMgc2lnbmVkIGF0dHJpYnV0ZXMsIGEgbWVzc2FnZSBkaWdlc3QN Cj4gICAgYWxnb3JpdGhtIGlzIHVzZWQgdG8gY29tcHV0ZSB0aGUgbWVzc2FnZSBkaWdlc3Qgb24g dGhlIGVDb250ZW50DQo+ICAgIHZhbHVlLiAgV2hlbiBzaWduaW5nIHdpdGggRWQyNTUxOSwgdGhl IG1lc3NhZ2UgZGlnZXN0IGFsZ29yaXRobSBNVVNUDQo+ICAgIGJlIFNIQS01MTIgW1JGQzQ2MzRd LiAgV2hlbiBzaWduaW5nIHdpdGggRWQ0NDgsIHRoZSBtZXNzYWdlIGRpZ2VzdA0KPiAgICBhbGdv cml0aG0gTVVTVCBiZSBTSEFLRTI1NiBbRklQUzIwMl0gd2l0aCBhIDUxMi1iaXQgb3V0cHV0IHZh bHVlLg0KPiANCj4gTUdMVDogSSBhbSB3b25kZXJpbmcgd2h5IHRoZSBkaWdlc3RBbGdvcml0aG0g Y2Fubm90IGJlIHRoZSBpZGVudGl0eS4gDQoNClNpbmNlIENNUyBhbGxvd3MgbXVsdGlwbGUgc2ln bmF0dXJlcyBvbiB0aGUgY29udGVudCwgdGhlIGlkZWEgaXMgdG8gdGVsbCB0aGUgaW1wbGVtZW50 YXRpb24gd2hpY2ggaGFzaCBmdW5jdGlvbnMgYXJlIG5lZWRlZCBpbiBhIGZpZWxkIHRoYXQgYXBw ZWFycyBiZWZvcmUgdGhlIGNvbnRlbnQgdGhhdCBuZWVkcyB0byBiZSBoYXNoZWQuDQoNCj4gICAg U2lnbmluZyB3aXRoIEVkMjU1MTkgdXNlcyBTSEEtNTEyIGFzIHBhcnQgb2YgdGhlIHNpZ25pbmcg b3BlcmF0aW9uLA0KPiAgICBhbmQgc2lnbmluZyB3aXRoIEVkNDQ4IHVzZXMgU0hBS0UyNTYgYXMg cGFydCBvZiB0aGUgc2lnbmluZw0KPiAgICBvcGVyYXRpb24uDQo+IA0KPiBNR0xUOiBJIGFtIHdv bmRlcmluZyBpZiB0aGUgdGV4dCBhYm92ZSB3YW50cyB0byBzcGVjaWZ5IHRoYXQgdGhlIGRpZ2Vz dCBhbGdvcml0aG0gc3BlY2lmaWVkIGFyZSBhbHJlYWR5IHBhcnQgb2YgdGhlIHNpZ25hdHVyZSBh bmQgYXMgc3VjaCBubyBhZGRpdGlvbmFsIGhhc2ggZnVuY3Rpb25zIHJlYWxseSBuZWVkIHRvIGJl IGFkZGVkIG9yIGlmIHRoZXJlIGlzIGFub3RoZXIgbW90aXZhdGlvbiBmb3IgdGhpcyB0ZXh0LiAg IA0KDQpUaGlzIGlzIHRoZSByYXRpb25hbGUgZm9yIHRoZSBlYXJsaWVyIHN0YXRlbWVudC4NCg0K PiAgICBGb3IgY29udmVuaWVuY2UsIHRoZSBvYmplY3QgaWRlbnRpZmllcnMgYW5kIHBhcmFtZXRl ciBzeW50YXggZm9yDQo+ICAgIHRoZXNlIGFsZ29yaXRobXMgYXJlIHJlcGVhdGVkIGhlcmU6DQo+ IA0KPiAgTUdMVDogSU9EIGFyZSByZXBlYXRlZCwgbWF5YmUgd2UgY291bGQgYWRkIGEgcmVmZXJl bmNlIHdoZXJlIHRoZXNlIGhhdmUgYmVlbiBkZWZpbmVkLiAtLSBOb3RlIHRoYXQgdGhlIHJlZiBi ZWNvbWVzIGNsZWFyZXIgb24gdGhlIG5leHQgcGFnZS4NCg0KVGhlc2UgT0lEcyBhbGwgY29tZSBm cm9tIHRoZSBOSVNUIHdlYnNpdGUsIGJ1dCBOSVNUIGRvZXMgbm90IHB1Ymxpc2ggYW4gQVNOLjEg bW9kdWxlIHRoYXQgaW5jbHVkZXMgdGhlbS4NCg0KTW9zdCBvZiB0aGVtIGFwcGVhciBpbiB0aGUg QVNOLjEgbW9kdWxlIGluIHRoZSBjdXJkbGUtcGtpeCBkb2N1bWVudC4gIEkgc2hvdWxkIHByb2Jh Ymx5IGFkZCBhIG1vZHVsZSB0byB0aGlzIGRvY3VtZW50IHRvby4NCg0KDQo+ICAyLjQuICBFZERT QSBTaWduYXR1cmVzDQo+IA0KPiAgICBUaGUgaWQtRWQyNTUxOSBhbmQgaWQtRWQ0NDggb2JqZWN0 IGlkZW50aWZpZXJzIGFyZSBhbHNvIHVzZWQgZm9yDQo+ICAgIHNpZ25hdHVyZSB2YWx1ZXMuICBX aGVuIHVzZWQgdG8gaWRlbnRpZnkgc2lnbmF0dXJlIGFsZ29yaXRobXMsIHRoZQ0KPiAgICBBbGdv cml0aG1JZGVudGlmaWVyIHBhcmFtZXRlcnMgZmllbGQgTVVTVCBiZSBhYnNlbnQuDQo+IA0KPiBN R0xUOiBJIGRvIG5vdCB1bmRlcnN0YW5kIHdoeSBpZC1FZDI1NTE5IGFuZCBpZC1FZDQ0OCBhcmUg dXNlZCBmb3IgdGhlIHNpZ25hdHVyZSB2YWx1ZS4gTXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IHRo ZSBTaWduZXIgSW5mbyBjYXJyaWVzIHRoZSBzaWduYXR1cmUgYWxnb3JpdGhtLCB3aGljaCBkZWZp bmVzIHRoZSBzaWduYXR1cmUuICANCg0KICAgICAgU2lnbmVySW5mbyA6Oj0gU0VRVUVOQ0Ugew0K ICAgICAgICB2ZXJzaW9uIENNU1ZlcnNpb24sDQogICAgICAgIHNpZCBTaWduZXJJZGVudGlmaWVy LA0KICAgICAgICBkaWdlc3RBbGdvcml0aG0gRGlnZXN0QWxnb3JpdGhtSWRlbnRpZmllciwNCiAg ICAgICAgc2lnbmVkQXR0cnMgWzBdIElNUExJQ0lUIFNpZ25lZEF0dHJpYnV0ZXMgT1BUSU9OQUws DQogICAgICAgIHNpZ25hdHVyZUFsZ29yaXRobSBTaWduYXR1cmVBbGdvcml0aG1JZGVudGlmaWVy LA0KICAgICAgICBzaWduYXR1cmUgU2lnbmF0dXJlVmFsdWUsDQogICAgICAgIHVuc2lnbmVkQXR0 cnMgWzFdIElNUExJQ0lUIFVuc2lnbmVkQXR0cmlidXRlcyBPUFRJT05BTCB9DQoNClRoaXMgdGV4 dCBpcyB0YWxraW5nIGFib3V0IHRoZSBTaWduYXR1cmVBbGdvcml0aG1JZGVudGlmaWVyLCB3aGlj aCB1c2VzIHRoZSBzYW1lIE9JRCBhcyB0aGUgc3ViamVjdCBwdWJsaWMga2V5IGluIHRoZSBjZXJ0 aWZpY2F0ZSB0aGF0IHdpbGwgYmUgdXNlZCB0byB2YWxpZGF0ZSB0aGUgc2lnbmF0dXJlLg0KDQoN Cj4gMy4gIFNpZ25lZC1kYXRhIENvbnZlbnRpb25zDQo+IA0KPiAgICBUaGUgcHJvY2Vzc2luZyBk ZXBlbmRzIG9uIHdoZXRoZXIgdGhlIHNpZ25lciBpbmNsdWRlcyBzaWduZWQNCj4gICAgYXR0cmli dXRlcy4NCj4gDQo+ICAgIFRoZSBpbmNsdXNpb24gb2Ygc2lnbmVkIGF0dHJpYnV0ZXMgaXMgcHJl ZmVycmVkLCBidXQgdGhlIGNvbnZlbnRpb25zDQo+ICAgIGZvciBzaWduZWQtZGF0YSB3aXRob3V0 IHNpZ25lZCBhdHRyaWJ1dGVzIGFyZSBwcm92aWRlZCBmb3INCj4gICAgY29tcGxldGVuZXNzLg0K PiAgICANCj4gTUdMVDogTWF5YmUgd2UgY291bGQgYnJpZWZseSBleHBsYWluIG9yIHByb3ZpZGUg YSByZWZlcmVuY2Ugd2h5IHNpZ25lZCBhdHRyaWJ1dGVzIGFyZSBwcmVmZXJyZWQuICAgDQoNClRo aXMgaXMgYSBzdGF0ZW1lbnQgYWJvdXQgd2hhdCBtb3N0IGltcGxlbWVudGF0aW9uIGRvLiAgUy9N SU1FIHNheXMgdGhhdCBzZW5kaW5nIGFnZW50cyBTSE9VTEQgaW5jbHVkZSBzaWduZWQgYXR0cmli dXRlcywgYW5kIEkgY2Fubm90IHRoaW5rIG9mIGFueSB0aGF0IGRvbuKAmXQgZG8gc28uDQoNCg0K PiAzLjEuICBTaWduZWQtZGF0YSBDb252ZW50aW9ucyBXaXRoIFNpZ25lZCBBdHRyaWJ1dGVzDQo+ IA0KPiAgICBUaGUgU2lnbmVkRGF0YSBkaWdlc3RBbGdvcml0aG1zIGZpZWxkIGluY2x1ZGVzIHRo ZSBpZGVudGlmaWVycyBvZiB0aGUNCj4gICAgbWVzc2FnZSBkaWdlc3QgYWxnb3JpdGhtcyB1c2Vk IGJ5IG9uZSBvciBtb3JlIHNpZ25lci4gIFRoZXJlIE1BWSBiZQ0KPiAgICBhbnkgbnVtYmVyIG9m IGVsZW1lbnRzIGluIHRoZSBjb2xsZWN0aW9uLCBpbmNsdWRpbmcgemVyby4gIFdoZW4NCj4gICAg c2lnbmluZyB3aXRoIEVkMjU1MTksIHRoZSBkaWdlc3RBbGdvcml0aG0gU0hPVUxEIGluY2x1ZGUg aWQtc2hhNTEyLA0KPiAgICBhbmQgaWYgcHJlc2VudCwgdGhlIGFsZ29yaXRobSBwYXJhbWV0ZXJz IGZpZWxkIE1VU1QgYmUgYWJzZW50LiAgV2hlbg0KPiANCj4gICAgc2lnbmluZyB3aXRoIEVkNDQ4 LCB0aGUgZGlnZXN0QWxnb3JpdGhtIFNIT1VMRCBpbmNsdWRlDQo+ICAgIGlkLXNoYWtlMjU2LWxl biwgYW5kIGlmIHByZXNlbnQsIHRoZSBhbGdvcml0aG0gcGFyYW1ldGVycyBmaWVsZCBNVVNUDQo+ ICAgIGFsc28gYmUgcHJlc2VudCwgYW5kIHRoZSBwYXJhbWV0ZXIgTVVTVCBjb250YWluIDUxMiwg ZW5jb2RlZCBhcyBhDQo+ICAgIHBvc2l0aXZlIGludGVnZXIgdmFsdWUuDQo+IA0KPiAgTUdMVDog Rm9yIHdoaWNoIHJlYXNvbiBkbyB3ZSBoYXZlIGEgU0hPVUxEIGFuZCBub3QgYSBNVVNULCBhcyB0 aGUgaGFzaCBmdW5jdGlvbiBzcGVjaWZpZWQgaGF2ZSBhIE1VU1Qgc3RhdHVzIGluIHRlIG1lc3Nh Z2UgZGlnZXN0IGlkZW50aWZpZXIuICAgIA0KDQpUaGlzIGlzIGF0IG9kZHMgd2l0aCB5b3VyIGNv bW1lbnQgb24gc2VjdGlvbiAyLiAgSeKAmW0gZmluZSB3aXRoIG1ha2luZyB0aGlzIGEgTVVTVC4N Cg0KUnVzcw0KDQo= From nobody Fri Mar 10 23:35: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 9FED412953D for ; Fri, 10 Mar 2017 23:35:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.451 X-Spam-Level: X-Spam-Status: No, score=-0.451 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7RMJvqumfKd for ; Fri, 10 Mar 2017 23:35:16 -0800 (PST) Received: from mail01.sigterm.no (mail01.sigterm.no [193.150.121.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAC5F12951B for ; Fri, 10 Mar 2017 23:35:15 -0800 (PST) Received: from smtp.postman.i2p (unknown [193.150.121.26]) by postman.meeh.i2p (Postfix) with ESMTP id 50A992E10AE for ; Sat, 11 Mar 2017 08:35:10 +0100 (CET) X-Virus-Scanned: clamav-milter 0.97 on milter.postman.i2p To: curdle@ietf.org, Russ Housley , Daniel Kahn Gillmor , Peter Gutmann References: <7d6cfe29-8d4c-436e-fe8a-0cbee915b29e@mail.i2p> X-Mailer: smtp.postman.i2p - Official I2P Mailer From: str4d MIME-Version: 1.0 In-Reply-To: <7d6cfe29-8d4c-436e-fe8a-0cbee915b29e@mail.i2p> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="bKPr5cxTWBBkOAoG0sQk57lm355SQb8ck" Message-Id: <20170311061838.879BAADF28@smtp.postman.i2p> Date: Sat, 11 Mar 2017 06:18:38 +0000 (UTC) Archived-At: Subject: Re: [Curdle] AlgorithmIdentifier parameters in draft-ietf-curdle-pkix-03 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 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, 11 Mar 2017 07:35:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bKPr5cxTWBBkOAoG0sQk57lm355SQb8ck Content-Type: multipart/mixed; boundary="VKXudkIdpNvEcHQQOG64lR1UccRRCxAeR"; protected-headers="v1" X-Mailer: smtp.postman.i2p - Official I2P Mailer From: str4d To: curdle@ietf.org, Russ Housley , Daniel Kahn Gillmor , Peter Gutmann Subject: Re: AlgorithmIdentifier parameters in draft-ietf-curdle-pkix-03 References: <7d6cfe29-8d4c-436e-fe8a-0cbee915b29e@mail.i2p> In-Reply-To: <7d6cfe29-8d4c-436e-fe8a-0cbee915b29e@mail.i2p> --VKXudkIdpNvEcHQQOG64lR1UccRRCxAeR Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 02/19/2017 02:14 AM, str4d wrote: > Hi all, >=20 > In draft-ietf-curdle-pkix-03 there is very clear language around the > expected behaviour of parser implementations regarding > AlgorithmIdentifier parameters: >=20 [snip] > The problem is that the Sun AlgorithmId class always adds a NULL when > encoding if there are no parameters, for compatibility with Solaris [4]= =2E > So AFAICT it is presently impossible for me to write an implementation > that simultaneously: >=20 > - follows draft-ietf-curdle-pkix-03 correctly > - can retrieve EdDSA keys from a default Java keystore >=20 > Is anyone in the WG aware of a workaround for this, or have links to > past WG discussion on this point? I would think that Oracle should at > least be made aware of this issue, but even if they changes this in Jav= a > 10, that doesn't help my implementation run on earlier Java versions. > The only alternatives I see at this point are: >=20 > - Remove the NULL restriction from draft-ietf-curdle-pkix-03 > - Require that my library not be used with incompatible keystores (but > a) I have yet to find a way to enforce this via the JCA, other than jus= t > refusing to implement support for PKCS8EncodedKeySpec, which is not > particularly usable, and b) I don't yet know of a keystore that *will* > implement this properly) I have found the correspondence in the Curdle WG ML that added the NULL restriction; I have copied in the relevant members to hopefully jog this conversation. If there is no further discussion, then I will have no alternative but to be non-compliant with the eventual RFC, as I have been unable to find a way for my library to work with the default Java keystore :( Peter Gutmann wrote: > Daniel Kahn Gillmor writes: > > Implementaions MUST NOT accept any of these OIDs with the > > parameters field present, even if parameters has a value > > of NULL. > > > >If we can convince the early implementations to hard-fail on that, > >we can discourage anyone from generating those values in newer > >implementations. > > +1. For once there's no argument for supporting existing broken > implementations, we can get it right from the start I apologise for providing one :/ Cheers(-ish), Jack --VKXudkIdpNvEcHQQOG64lR1UccRRCxAeR-- --bKPr5cxTWBBkOAoG0sQk57lm355SQb8ck Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYw5akAAoJEGppFNr76gDau1AP/3rbibSN6HuCmB+6t/lLNvSA L760ovJqUvSM4ffWznQO2NYUAfES6AhLYZ1GFHZKVZGRjAKkFHvjRkj1SVnzXaVE euwE21ZL2nmAO/FMqXXs0JPewNMJhYxEaQ72T0o3mwH+87k5dwgAAJtNNmI/sVIq M7fWG3kevQ3kQKLjHpJtUEK77wqEVKsLoVBwND2rOdmq27MFeL9VV9AXXQSh+dcG eUZ7ugBfSM4G8Q+TfgnmRTX3StfEF9BD0cTxfCuir4KFqVoOfwbz0I6z6nnkvgBE ZkQKVg/BqeKweW5WKRYUAl68nTbOYViW3B43qHwp4A7CBD+S4EdMmAX+kZmIvsna R6eoNWuskOiDkk6naEd1XaiGa28lH+hgqqYESD8AAKYc8NYLjH3oHOCSkWm+FEcR plGkrizmpaIoWCjX0VVoJhj/iFKo5FXzS7D38f+XHeQRyIgrXSR2Gjq225hL80QJ bU8Mtyv8ECNNV76tWmtd0dQjD+PGrKsf99MsqBe7CwnKnhkQNycJvEONWr4xMW1k GNiyBcOA63rfJQQEh9kytREVev1U9RuXg3EIYifmlJzZLJ8LMpYxzPbvSgkygay3 +QjxZIy0QIv0z0fuDtXlOiy8lUXmKCiKLBsrWrrr6Zcqsy6bk8n187nXpW7URKMH J0DHycbT8K+nvQXPD7EG =sPBu -----END PGP SIGNATURE----- --bKPr5cxTWBBkOAoG0sQk57lm355SQb8ck-- From nobody Fri Mar 10 23:47: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 8EAFE1294F8 for ; Fri, 10 Mar 2017 23:47:54 -0800 (PST) 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 0OyiHcRJ98sv for ; Fri, 10 Mar 2017 23:47:53 -0800 (PST) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::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 052CF1293FD for ; Fri, 10 Mar 2017 23:47:53 -0800 (PST) Received: by mail-it0-x233.google.com with SMTP id m27so8632955iti.1 for ; Fri, 10 Mar 2017 23:47:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=LZXD3dAnrVVTvldVD1SHaTEPqvMiBZxy1p8MK1i905g=; b=iE9KEXQPA6G2oolP+SvQhstTZEpS3oxh0vPex0ZRshZ+CoEry6wpxzf3mcktJekxMJ yd2t1zpwdfVUHeKbLBvIQHy2vB25T2kuQMs7l1SdYaSlsQrKFPz7e+pPxQh8xCemEg9a U0XtboKWFD2zSHKrvbv7prZydiYRyJhxL+jxhADbf8LrrGi9DjH8hQWVNZAptTVLWRkt YzOqVWIUPWrnmnGgl6v/4J+A0Zyfe1aCArWAq5OI6Mqxz0Q0AssYeeCyye7cDmoX55AX z6PXBQqQ0rC8SwKZQZw6qVJh2oRBATfQnOg7U0npFH49E2lQ5PigM8IW92oCoq81aLpW LaJA== 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=LZXD3dAnrVVTvldVD1SHaTEPqvMiBZxy1p8MK1i905g=; b=MKmX56mrgnMerro31dgF/JSkxQFPsd4vBKQNellNRiVpwz02ubiaOcGwPtZOBfSJEb qqocVeA07hIT8oK7B/bFDa+JvBgDDoBK9HdnC5gsduWRMJ+M8SE54BRCfclsUqo7FuZ9 jN2qobpWgPYthL9ebiPdUKT0/Z/R3qMB1SVA3f88ShTDfwgHYUoHSB19I9XPBrUvu4zp 3AYH3an+kJbSgFS85rW7b+Sy4pxqMI48g0VGbCB31PvNmv5veI/R72rLciGPVr2/n6YT PCvI7kMqZu+lgwBa96daN7+sHkJbiO5PGmxhOLPm+xbI9+LgDoTAH+Qc0yWuFgaFM0B8 MHAQ== X-Gm-Message-State: AFeK/H3IRoebOEmPWJ5/I206q3MjrNzaTtlcRK+EaXeDANigwgZk/N2FqKwN8TdmpsfinqP+70lA+QGqvhAvrg== X-Received: by 10.36.194.67 with SMTP id i64mr2734241itg.68.1489218472221; Fri, 10 Mar 2017 23:47:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.166.130 with HTTP; Fri, 10 Mar 2017 23:47:51 -0800 (PST) From: Loganaden Velvindron Date: Sat, 11 Mar 2017 11:47:51 +0400 Message-ID: To: curdle@ietf.org Content-Type: multipart/alternative; boundary=94eb2c08906007cdc7054a6fb2b8 Archived-At: Subject: [Curdle] Update to RFC 4419 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 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, 11 Mar 2017 07:47:54 -0000 --94eb2c08906007cdc7054a6fb2b8 Content-Type: text/plain; charset=UTF-8 Hi All, I started working on a small update to RFC 4419, regarding minimum recommended bit size for k, where k is the modulus length. https://tools.ietf.org/id/draft-lvelvindron-dh-group-exchange-00.txt This reflects changes that have taken place in OpenSSH, following the logjam paper. https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf --94eb2c08906007cdc7054a6fb2b8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi All,

I started working on a small up= date to RFC 4419, regarding minimum recommended bit size for k, where k is = the modulus length.


This reflects changes that have taken place in OpenSSH, following the lo= gjam paper.



--94eb2c08906007cdc7054a6fb2b8-- From nobody Sun Mar 12 17:37: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 F013512944D for ; Sun, 12 Mar 2017 17:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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=junipernetworks.onmicrosoft.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 0vpUCVZDFphZ for ; Sun, 12 Mar 2017 17:37:38 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0094.outbound.protection.outlook.com [104.47.34.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8659E12940C for ; Sun, 12 Mar 2017 17:37:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6jP+NOMPRWCTlq3+Z3GMgr5S4+YsCsbDZkuZ7GJh0lc=; b=MKSaRlHeWDjPA3jlzldqUHahKMyCbo9NoosXuNHvbLbLzAkARBGtdzxE/JhFT6weEDy3lF3t9CLY1Zt0nsYM0OL8eRCr8A28ABCcjTwDgEQuNdFyX9rylB5vWFkhOGMybWIwIF2HK7bV5E5NBhzli67FQrx4NTCrTKmsBHPZZ9M= Received: from SN1PR05CA0034.namprd05.prod.outlook.com (10.163.68.172) by BY2PR0501MB1752.namprd05.prod.outlook.com (10.163.154.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.977.5; Mon, 13 Mar 2017 00:37:37 +0000 Received: from BN1AFFO11FD038.protection.gbl (2a01:111:f400:7c10::100) by SN1PR05CA0034.outlook.office365.com (2a01:111:e400:5197::44) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.977.5 via Frontend Transport; Mon, 13 Mar 2017 00:37:37 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.18) 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.18 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.18) by BN1AFFO11FD038.mail.protection.outlook.com (10.58.52.242) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.961.10 via Frontend Transport; Mon, 13 Mar 2017 00:37:36 +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; Sun, 12 Mar 2017 17:37:27 -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 v2D0bQQx029909; Sun, 12 Mar 2017 17:37:26 -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 E4CE611446; Sun, 12 Mar 2017 17:37:25 -0700 (PDT) To: From: "Mark D. Baushke" X-Phone: +1 408 745-2952 (Work) X-Mailer: MH-E 8.6; nmh 1.2; GNU Emacs 24.3.1 X-Face: #8D_6URD2G%vC.hzU 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.18; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39450400003)(39850400002)(39860400002)(2980300002)(199003)(189002)(9170700003)(77096006)(50466002)(7696004)(48376002)(6916009)(189998001)(8936002)(8676002)(50986999)(81166006)(50226002)(5003940100001)(2810700001)(106466001)(53416004)(76506005)(6392003)(7846003)(117636001)(230783001)(105596002)(2351001)(47776003)(305945005)(86362001)(55016002)(7126002)(356003)(5660300001)(53936002)(2906002)(38730400002)(6266002)(110136004)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0501MB1752; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD038; 1:GvQfIxnWZl3hyZqckCn2tavl1SMf09PGDLbOZCp3WClkb+oYLD6JDstLhjgdnY0go60RqZttGvRIrAIxbBamSlGawL2+umrDjSdF6eI2wl8zi0gg8WuCaFu+KZMcJ5eNWW9dz86hx1vqUA2eFI2MLkPvLXrpTvCtMuAMvOEB8S4xQ0KXuR9oopz+sfMuIvwE4jP9hd58XQCJD+ZTQ2LEaoHduAct+jgUuuylHLOz5sUpKwyL7bpUH4EKtlhBfFTl8UY70aScDu26K7a6X1tqgZ1IWy1jeVFr01eNvJOUGgaDNK/lRWcKBAtSoThc9SBEN05jNu8NLjnMebzsPMHLx+rAd3lrhs0iQ1f4bc1dWi5V6uLUimqfNcSWNKUyzn791jHDjVnEn8zJcMXWis/xXoyHxJqyct6ukLJZ2uThds4ebOXx1tsI1GFxlFvgsfo9mVb3lEIKXEYJIST1SI4T0JJYJ4szdsnCZDv3X5K7I1OZ4bG3LSjGlP5Bq3RwbWtxLrSS7TmhP/24gpDRpCdjU6Wi04ewoSMM6mIjSkZSeMc= X-MS-Office365-Filtering-Correlation-Id: 54740249-bdc4-4dbc-1eee-08d469a925ce X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BY2PR0501MB1752; X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB1752; 3:zE3Uoz5/jCkdvy0d7ZZwvcRtHG782opaJjZbdYvDdVq2pbDY1faRDHXLDs3bu+k6v1otFC+5QS90ff1GsreFXtGf6ZXgwuZ6QuARslz0Z2HpTmQs6fFCL3SYT7YHSttOl/QbkH2/Sr/Q9lfCTRLQkj2T+g6B0DFiTVZIuCKnJvpKNCmm9SLNej61SduUMJWrkpXNKDiexH2qbA3imjHwvocK7p3X+YCMQBZ3ZnTKaDbnRjYzs4Wwi9y0PlAPU6XGwcg88ogfG/06mQon23M0U6iSZRZCBDSVI61gaEayZutpFlPuIhvqM0zU3AvmST+umhSM7CaUlnwJE8agcnC/n+4NahLFVSD4S+nh129EknRkMAIWPAe95txYSVNeNKjx; 25:b/mc1AzUjWSGxHSJeUwR90Tau3Wudqf5yADu8YCZ1rlk1mpplYQC+hpvfUiFnZTtKS2sYOgJbEI5BY5IQ7kKXHDSGVJmJ+FSWc027UCwAp0DHL3IQlDIDl9Cz0XaE09ooiBUT9BnEWyP1cwCNlOD+b8sIBRBFrMBaUehUdztT5rKETiMQihK+WVDG/2487KyWjm2jq+J5CnF3YdVhZXSwNJb7xeCC6gZAy1dm4KYxyA7AApt7ggpSwBIR7zGBqjCJongLfMKtF2u01g2MCbWpCarDa6pRk1pA9SQqcrODSW7lzbDaR2DwElg56jyEoWbkAtKws7T7M7R6BRc3Qeki+HSPslpGXivOZLhXixOUFuXWX8icTbZYPv0SOtIHHSlmYKuJWZarLS4JOcjSsMUwRhodrTalDFFwEyOOnO8vtZ4ZxyFg2ydxxWqgjznnOUxuuy5v6t9kY6FnmjGbRatWQ== X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB1752; 31:0cVeYGspDQu4io0drhVenP5CODlQ++Tjpv6y+nSwPSYv3IuL36HtQtemxIx3KwEIyBkTXY3qWDj1H24xY6QA6DIvdYZAz+8lGRyAP245fugJLqzwr7wJGHstd4iJj614Ge8JfzJm/e9eK9cJA2teGKDZeDOn4m/G5v/lLyX3BelR9OFrQvE1upADqT4SaQ7tvHsf2jChoGTVDCFGpSChrpHz8AZ9gYJkxO7YVl1IPdr/UNQmD0oqrjI0pMO03d9rP0v1waEm9mlVaRLSi05GwQ==; 20:wQTAj7m6WwSWBQfxWGuT0B331dRFGwPgBUPehQsTybhrzOwUfSaLDkCwXiC+iJySIewEeqWQqxmx3A8iG+MUxUX5r8hC1akVlXYyAaTlujpo3G0naPUTtjR7N/zhsaay4XZgdp6ERjzm/JAdiCDXRIx/Hq8GU42li8CaAOXBTrK4vpYi1jD6y7tsrmncx/ViVP0SDEcTbRV6rjNQaSOmqmJ4Lwkic3EbUxbkL14KNJiVTMN1PPXDJD8KFwKhacRSbqd86t+yWgRD6FQu1xI3S7DLNhDPknZb776pslSqbkNYcpOs/6ccOUMdDt+u5YiC1yYzAGtEdIya0X3tM4WxEPufAuMVDJY87f4P2rqIm2XKPOMRxJue3jm6aTS7kyQ2uEbzN6dmCEBWAm8eOCsvcFQr/1Taq+EyOX8/x3qcixeK7gkrYWgq4mTcRH625NBAdPWycp7g6s0pXIX8quNYAMzPdXCXHzVS7h4k1ood5HI9UMNRCTKZke46J6jGYLiC X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(100405760836317); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(13018025)(13023025)(13024025)(13015025)(13017025)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123558025)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(6072148); SRVR:BY2PR0501MB1752; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0501MB1752; X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB1752; 4:5mDKNk3fzpfE7kYLX/9sXNpw9MChp5oXaZ887AZKtZ50l1tm5A+e2i/mGOrANYnVv2sFPOcYXOHJ5DnXv+9siYAkTRDWcwPtXCEOdO/TmzQ8IVtq0+QAfnJtvMejf7HAQewU6uLSYfmlLBpzImYe+Ka/wfHgzXP4rXfn8xZg2RttaFMDaQF8WF7kRwRfEPHIWLps2O0qtvo08btFOLmvQ4QrrH2gpzwiVyrJoAT75oEUVr9GDqKlGlt34UFGq39AEvRawz9+nNyGvaPOsMLR5IYCoHBIYMOKUp8ofSk/ulOwqcYKdsGJU9XIxw40PSSCRmmmkO+0eKHkgXz6qU1rpEocIfarBK2HCx0r1H6E6HfnvizH355cPp1vjS5F8n75UvHvQnjRIolVkt5HELdR1qGRae7r3JuHPwFIBFtSgbtyspghqsk7M1zi/blm2Sy2dsbNnVnU+FEix/8WzpbJ+YzrwdqZ4+yxwt+O5UxGkW2mQ3Rw998QsWUhhe1sRTcUvkQ6NaCAftyVo/HlyOSkrwgKNBIhJ46yT64MqO8GZ6d3LvCGc5ZTXL41vINdHx+KmgYSrqFgr7qeuJTBG/wUPwk6yIpc6MlGyqXdRxdcfJqiB4M3YD1EF7mYspu0imBNmJBrl3uViApD/p604cQoXDHaYrF/h97K4po2W41IR1So8Q3242QCzcvws197cAgNPOQt0CQZ9Cy9y0Wu3U3wrMJP/XjgUEJ7V/08dG/Py3MwcEl3Fxv9OEzHoIkqBCxC/usX4ZrktQwmEwZ7Vp06lg== X-Forefront-PRVS: 0245702D7B X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2PR0501MB1752; 23:2dPDMDPhG793SbJYwmvgOqKahR8EZUr6h9eLNxB?= =?us-ascii?Q?ozI5e4vvfvc69WP1NJ7x11PWvU5D/zTjDcIbwxvC6rRSYcb1OI3JbyLT6PO3?= =?us-ascii?Q?OvmAEiL2pDVB0ipGKQhzhrguoo+I5SS7hcv6RssGDawb0f/Z86qGFUaGEYgH?= =?us-ascii?Q?jN2r5R5yfYFKlmWXyxP8qhOMk3tWU4KxG60V5RGlvnUtHs9KZFt4XukGSGBY?= =?us-ascii?Q?TTrR49c40Yn/nSpmciWegcq4K+KkBgxdOyV2yBB0YKfAK1/yUPkj6iucFZvc?= =?us-ascii?Q?MskepPzhBqBvUWKjUB9LoOhcNd2pbEsnchQRdhdJFGyIC2iYBOxw09IYXU3S?= =?us-ascii?Q?aUA9PR0eBhbnMtNgFAWOscVFEe+/hhhrFtJBBv8HMymZSwmzrkSfgT7pdQ86?= =?us-ascii?Q?PyhRQ6+ngYeErkzw+/+gsi2NnkDbqPuz762E38RsgrBOz/OePE+vdyUBS1Hc?= =?us-ascii?Q?2Gg8/0M3Xu7qCDDaGz5hQq499TikbUsn7FuCLHiEO1TGRDSS0GPiem8X9kQY?= =?us-ascii?Q?UzAuQd2G8ERd7nYPJ63DuZSnFBLtDSLIStikLFIV24ohGa0yr/7Af0WurxZC?= =?us-ascii?Q?fKS79luEaRKtZWDhnqz4WEZCqhLYkYvgjCN+ZtNqeV/np0sm/n7XOJVGdF2+?= =?us-ascii?Q?CMpogwIdh95U0uGcscJqnDqlBD48k7SXueYwi/mdDSLIbJiR9Tl09QfWpZl8?= =?us-ascii?Q?HnDMuvmGUcw6yNY78QDITTdpIIEBiGWT4F2V+ufTjwDzzPtpy0ek9EI21DKH?= =?us-ascii?Q?OPN+Q6dNqNGCFAoI0OqxqGmP/Kt883QeOqv2KChAEpYql/m2PekTmWxHSoKQ?= =?us-ascii?Q?54Kut9ArWB8iRHumeUMqOJAWEYJh2Yed61Zvfi0GMe3pXXW4DVAgZlhqYiHQ?= =?us-ascii?Q?t85+dafJPK3MAdYpXDhFV1SGqhlfU6iuTVRs6/meS/mbFllwgdPbHERGnAFf?= =?us-ascii?Q?AoThAWbzR+bRtXL6TD1EFIakCFtFS2q2cBjvTRpaBLHdnLtC+ILUVR3OtzER?= =?us-ascii?Q?+owqfYqcnqIp5LMvEtP4JscDaiFs8J5XL5ryFByNLUhqQ3k3kkRSMAWSjWNt?= =?us-ascii?Q?hYlUlQKamP9/YfcgTTTzR8gYQqMsBUzVs0vb/d6u4/d9qeG4fkg=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB1752; 6:HDx3XM4u+tU8WXWHdaOAWu1vg3fDTbj/GeIb+4exAppY3CnYvjMD9gxYAFNYUSxx1HsPXdwfdMgdHPXbJTeqTJm8Yrm3X3xIT2+cHxzZ4Wreo4Y8j+0L8+99ogEeQv/YvQZxCXBbnCCG41TPKEJ8Ncju2lCq3j9mO5Cu/uEMWfUq42PsMfAND3tn9/g22nC5ttoWqGgzR/0AfVjXRxENgzeFcLuMfZomRulJUDXiI+8jADrQ1uzttyKKPWdXRCRXuh+axLSexERoMYEeoQW8F/nan78MzGVFRF0ZmEG0Gc6dRP9TExqnBFmsV0a2iJyAxU5cQ63Mhjr2ZyAv6xVnVT9brfHwo6YubcwQKXtwNjx6AEyUYzrZI9G5uaY8gxec422gDt6MTk3RKOa77I1KQ9M1KCwLHRGNKXrR6OOcxCA=; 5:5nTtqtYr5Ri0IuRGjR1Emh/jc98p9q6uw7YCUyQWVEC/oRVhbcrv9i5qptV0TTydd1TfpgZZ4DJ28peMKKVaMG+P1ButWdGejcs95X5wtbaupQ0e6p/8T4HueP7sMxJ+vhJA4Pf2SDKlUw28+/unuoLCJnBDAmC1uoaXMO61D30=; 24:VmqOxLZGto5DW50RNfbbWJ7oF/eDUd00oFm/Rq5rSXR+jDPP8/ezMQghrS71Eycrk3y2fmh+Q1f7vS7e87z8FqJThWada3XC+zwvq/p+2lk= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB1752; 7:28YmcTExNDpqEB5mS0MW1jWgivxfvHic3At5Ku95Z516mULI7G0z5HT5Qoka0xwzHAeccD+n4vEcrlV8cLdAkR/NTgJ0NoEUrDRp6Tch7UudXwPGZIlmgmm+4oGSz7Gtva/eyK3I6/YnCeS6F0jnhm1L+k9KuuAyPOX22ybAlxairLifE65sbsarW7sLxbt3CHYoZiF3Xfu7pQOHn+RaIf5T4jivkMyvBNFikEVDORT+D2r1X07yRX4jis2cSF6vl5yrRS5sGyB2QNze5r6plPBaFZgZob1QONmVpxHg9GDVuR4gYjnanUHZ6rLEdAPoA9RNQdhZC1PsqXxdpOlS7A== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Mar 2017 00:37:36.6837 (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.18]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0501MB1752 Archived-At: Subject: [Curdle] is draft-ietf-curdle-ssh-curves-00 dead? X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 00:37:40 -0000 Hi, I am about to republish my draft-ietf-curdle-ssh-kex-sha2-05 before it expires. I am curious if I should remove curve25519-sha256 and curve448-sha512 or not. They reference the expired draft-ietf-curdle-ssh-curves-00 right now. I can easily remove them. Is there consensus that they are not a good alternative for a Key Exchange Algorithm? Thank you, -- Mark From nobody Mon Mar 13 01:04:57 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 CB22D129502 for ; Mon, 13 Mar 2017 01:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, 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=denisbider.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 LNNQrALH8_oZ for ; Mon, 13 Mar 2017 01:04:54 -0700 (PDT) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7A4D1294B2 for ; Mon, 13 Mar 2017 01:04:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=denisbider.com; s=mail; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to: references; bh=vW2Dyua7Aw6OLHjq1cPIhcgL1EtK761F18NOZ3hLlmk=; b=WabThqp67+45baLWNAHZRtYVXoRRym1bK5Hn0qU30bT7rW7OctRX+f9kRxVtEo88bgjjoy4X4tvS6 CML88AzLnCMoy1RaLaihWC83evXJ5khmKoK/M9s1IAvzD4JaWWg1xiJd9dnNsHA0Yp8cZ2NKooPsjo Z75MFZAu7hQfcsyEdW/5IzPLH3oTHukvSPBa2OoOKyi5OSfPUcHBttyp1YX+wGYxB0yQZ8dK5nYsRF tW473jm1ly8UXj41I0gPpweeB7v3xj0pe4Nbha4xMCqG3KS6yWqKCbmZSq1vA9PHr6vkJYFs2uCXC1 ehP7pO/X9hRlQlsstPDVr/qDDFUS2TA== X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)); Mon, 13 Mar 2017 08:04:48 +0000 Message-ID: <0480C0BDB01647CFB3B60FF2B8816AF2@Khan> From: "denis bider \(Bitvise\)" To: , "Mark D. Baushke" References: <16611.1489365445@eng-mail01.juniper.net> In-Reply-To: <16611.1489365445@eng-mail01.juniper.net> Date: Mon, 13 Mar 2017 02:04:51 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0090_01D29B9E.339693D0" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [Curdle] is draft-ietf-curdle-ssh-curves-00 dead? X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 08:04:56 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0090_01D29B9E.339693D0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Bitvise SSH Server, SSH Client, and the FlowSsh library support = curve25519-sha256 as an alias for curve25519-sha256@libssh.org. I would definitely keep them included. There is relatively strong user = demand for this algorithm and there=E2=80=99s no reason it should go = completely without mention. If the draft specifying the standard name has expired, that=E2=80=99s = more of a testament to the ineffective and glacial nature of the IETF = process =E2=80=93 where things become =E2=80=9Cstandard=E2=80=9D right = about the time they=E2=80=99re already obsolete - rather than a = deficiency of the draft, or the algorithm. denis From: Mark D. Baushke=20 Sent: Sunday, March 12, 2017 18:37 To: curdle@ietf.org=20 Subject: [Curdle] is draft-ietf-curdle-ssh-curves-00 dead? Hi, I am about to republish my draft-ietf-curdle-ssh-kex-sha2-05 before it expires. I am curious if I should remove curve25519-sha256 and curve448-sha512 or not. They reference the expired draft-ietf-curdle-ssh-curves-00 right now. I can easily remove them. Is there consensus that they are not a good alternative for a Key Exchange Algorithm? Thank you, -- Mark _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle ------=_NextPart_000_0090_01D29B9E.339693D0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Bitvise SSH Server, SSH Client, and the FlowSsh library support=20 curve25519-sha256 as an alias for curve25519-sha256@libssh.org= .
 
I would definitely keep them included. There is relatively strong = user=20 demand for this algorithm and there=E2=80=99s no reason it should go = completely without=20 mention.
 
If the draft specifying the standard name has expired, = that=E2=80=99s more of a=20 testament to the ineffective and glacial nature of the IETF process = =E2=80=93 where=20 things become =E2=80=9Cstandard=E2=80=9D right about the time = they=E2=80=99re already obsolete - rather=20 than a deficiency of the draft, or the algorithm.
 
denis
 
 
Sent: Sunday, March 12, 2017 18:37
Subject: [Curdle] is draft-ietf-curdle-ssh-curves-00=20 dead?
 
Hi,

I=20 am about to republish my draft-ietf-curdle-ssh-kex-sha2-05
before it=20 expires.

I am curious if I should remove curve25519-sha256 and=20 curve448-sha512
or not. They reference the expired=20 draft-ietf-curdle-ssh-curves-00
right now.

I can easily remove = them.=20 Is there consensus that they are not a good
alternative for a Key = Exchange=20 Algorithm?

Thank you,
--=20 Mark

_______________________________________________
Curdle = mailing=20 list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle
------=_NextPart_000_0090_01D29B9E.339693D0-- From nobody Mon Mar 13 05:10:14 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 B51DA12959A for ; Mon, 13 Mar 2017 05:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=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 oeSfZxN8mnNk for ; Mon, 13 Mar 2017 05:10:11 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id AB335129597 for ; Mon, 13 Mar 2017 05:10:11 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 136E14F09E; Mon, 13 Mar 2017 12:10:11 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id F180D4F034; Mon, 13 Mar 2017 12:10:10 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1489407010; bh=ry7DqD2TH9MCHe3G9zi8uDUWdPtz0hqOOIEftwgv28E=; l=536; h=From:To:Date:References:In-Reply-To:From; b=kpato9rNJgKFVwFw7fGU6vdkIYkXLe/aJLNB/FhUPJ5AREhBTtJXt9mEZRU1pCuZs rp77KqCx6L+eDnNLkI7Q7x879MesbVqkb6QGPQNdXj01wvLVSqB7jpNX6o6ZX3EQ+/ kWxGvhfw9V+KZfi1yuEe2NiKY3GsanFq0ylkMk94= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id EDFA41FC88; Mon, 13 Mar 2017 12:10:10 +0000 (GMT) Received: from USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 13 Mar 2017 08:10:10 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 13 Mar 2017 08:10:10 -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.1178.000; Mon, 13 Mar 2017 08:10:10 -0400 From: "Salz, Rich" To: "Mark D. Baushke" , "curdle@ietf.org" Thread-Topic: [Curdle] is draft-ietf-curdle-ssh-curves-00 dead? Thread-Index: AQHSm5IIjzSzJ8ful0arWlEW08HMqqGSrgeA Date: Mon, 13 Mar 2017 12:10:10 +0000 Message-ID: References: <16611.1489365445@eng-mail01.juniper.net> In-Reply-To: <16611.1489365445@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.39.74] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Curdle] is draft-ietf-curdle-ssh-curves-00 dead? X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 12:10:13 -0000 > I am about to republish my draft-ietf-curdle-ssh-kex-sha2-05 before it > expires. >=20 > I am curious if I should remove curve25519-sha256 and curve448-sha512 or > not. They reference the expired draft-ietf-curdle-ssh-curves-00 right now= . Simon and Aris, Do you have plans to update your draft? If you are overloaded, would it be= helpful if we got a volunteer to co-author to help move it forward? -- =20 Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz@jabber.at Twitter: RichSalz From nobody Mon Mar 13 07:45: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 48A031294F1 for ; Mon, 13 Mar 2017 07:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.348 X-Spam-Level: X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, 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 M7T99YHKPG06 for ; Mon, 13 Mar 2017 07:45:21 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::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 A662B1296C6 for ; Mon, 13 Mar 2017 07:45:15 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id m27so29838265iti.0 for ; Mon, 13 Mar 2017 07:45:15 -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=duM/vPqr7xPq8rciAFyhwYfGIJ5psolh0GVjmU796Hs=; b=WmZAayPmPc/osuOJsG5nmdb4tlea6/4NgMHeUAEz5Jc+MYzKlAUQdE+TZnf4DxEnjT mcxJm+2n1ukib7TtB+WqNyPgFNt8WfWHXgcTnoq4tEM7u0nD9tDcDddBnuGUY848D188 FpraFJzL94CBKbV2BxXnmM5ngZli9FvhHxfsbNG76m2WQpSUXdjHMvMr3cG/421CRdoy p/2zdg9bm7CmzGk9kXKtaY/ACUgA9keKZB8jMmBI6oMM5sF83kmXkid6ceDuABkLNNqO 8JnNluhxJLUp5deTEWK01KhBfzANDC2UBOZ5tQmpw7pJAbF3wqnw60SDwRiUdRj2vemt XuXw== 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=duM/vPqr7xPq8rciAFyhwYfGIJ5psolh0GVjmU796Hs=; b=tb9w0dtX/+D7XyQcgCVqzB8xVGhnpjuMu9rGsDJd4yNl9fbF16IfNBgzDIVgSXEBqN buYeFhlxJT24/iD5as80hT9ypFB8S2hoer4U3OPOo5nS9L/jBI2wdRhWFeuSVrEVU8Qv wHQhqRVRiAXinQJfvl3Did3LYwgHkEDC1Tk4czg1QUmL5PGL3f5BXowhWSn3IZRpSJ4f seZv4fIFMIuBvIYG35DJ3m7fAbT2mQOggDYiwlm54Q+sjCYmR3VQ+fq2YGsZKFFKfBSE i5dVRtwuHqNwA0zBJaR6W++GnaJKUOCNsVj80xMgJS2JOZGKQvjjJ8kzpRfthCQ57e++ blEA== X-Gm-Message-State: AFeK/H2Tniy9cZApUqTC8vuvnBqFXohahfQkQ2LHI38olWlWbZFXK2Ro04GKz+EXmau8PmWe9hhnD6M+mWtGqQ== X-Received: by 10.36.206.6 with SMTP id v6mr10403048itg.48.1489416315110; Mon, 13 Mar 2017 07:45:15 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.35.213 with HTTP; Mon, 13 Mar 2017 07:45:14 -0700 (PDT) In-Reply-To: <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> From: Daniel Migault Date: Mon, 13 Mar 2017 10:45:14 -0400 X-Google-Sender-Auth: bZGY5JUMvXVxneISnnFXZ4rdTgM Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=94eb2c0b0c586290a0054a9dc2e2 Archived-At: Cc: Curdle , Russ Housley Subject: Re: [Curdle] Some work for the group X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 14:45:22 -0000 --94eb2c0b0c586290a0054a9dc2e2 Content-Type: text/plain; charset=UTF-8 Hi, My current understanding is that the consensus on using the pure variant only except for CRL, and that CRL may use the prehash. If anyone disagrees, please let us know. Yours, Daniel On Fri, Mar 10, 2017 at 11:48 AM, Ilari Liusvaara wrote: > On Fri, Mar 10, 2017 at 11:35:24AM -0500, Russ Housley wrote: > > Does anyone see the need for pre-hash for anything other than CRLs? > > I don't. AFAICT, even 4kB is plenty for most certificates (even blogspot > certs, which have lots of SANs fit into 4kB). > > The only objects in PKIX that aren't very likely to fit into 4kB are > CRLs. > > > -Ilari > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --94eb2c0b0c586290a0054a9dc2e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

My current understan= ding is that the consensus on using the pure variant only except for CRL, a= nd that CRL may use the prehash.

If anyone disagrees, please = let us know.

Yours,
Daniel =C2=A0 =C2=A0


On Fri, Mar 10, 2017 at 11:48 AM, Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
On Fri, Mar 10, 2017 at 11:35:24AM -0500, Russ Ho= usley wrote:
> Does anyone see the need for pre-hash for anything other than CRLs?
I don't. AFAICT, even 4kB is plenty for most certificates (even = blogspot
certs, which have lots of SANs fit into 4kB).

The only objects in PKIX that aren't very likely to fit into 4kB are CRLs.


-Ilari

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

--94eb2c0b0c586290a0054a9dc2e2-- From nobody Mon Mar 13 08:40: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 BE1DE1296F6 for ; Mon, 13 Mar 2017 08:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.903 X-Spam-Level: X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 nz3eCy2aBuZ8 for ; Mon, 13 Mar 2017 08:40:20 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CD43129480 for ; Mon, 13 Mar 2017 08:40:20 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 422E712E049 for ; Mon, 13 Mar 2017 15:40:21 +0000 (UTC) Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.3.156]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v2DFeJvi026543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 13 Mar 2017 11:40:20 -0400 Message-ID: <1489419619.3159.25.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Curdle Date: Mon, 13 Mar 2017 16:40:19 +0100 In-Reply-To: References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Mon, 13 Mar 2017 15:40:21 +0000 (UTC) Archived-At: Subject: Re: [Curdle] Some work for the group X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 15:40:21 -0000 On Mon, 2017-03-13 at 10:45 -0400, Daniel Migault wrote: > Hi,  > > My current understanding is that the consensus on using the pure > variant only except for CRL, and that CRL may use the prehash.  > If anyone disagrees, please let us know. I am not sure what are you asking to disagree with. What would agreeing with that statement imply? I have not seen, in the mailing list at least, a discussion which can be summarized as the consensus is that only CRLs may use the prehash.  If for example, it works for CRLs why not for signing large files? To clarify, my point is raising the issue with the pre-hashed algorithm previously, is to prevent hashing context-specific algorithms or algorithms with restrictions in a new document. If an algorithm is bad or has no usefulness, it should not be defined at all, period. If it is known to be of use, has no weaknesses and can be used fine, there should be no exceptions or asterisks. If your intention is to put another MUST NOT for that particular algorithm, I'm against this. regards, Nikos From nobody Mon Mar 13 08:44: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 12A7212962E for ; Mon, 13 Mar 2017 08:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=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 hiBBlZsIcJpj for ; Mon, 13 Mar 2017 08:44:20 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB3712941A for ; Mon, 13 Mar 2017 08:44:20 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 90312200037; Mon, 13 Mar 2017 15:44:19 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 7A2BF200006; Mon, 13 Mar 2017 15:44:19 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1489419859; bh=Vy0+gf/qbJnvNR8Wx3rs/JOby8rvTbkjTtVZaUMK1GA=; l=736; h=From:To:Date:References:In-Reply-To:From; b=LUq36qsIQzORC/ebSZA+kTs9E8o3Z7yrG9KTuflsY2tWIH+3qo4SACR65975bKfXc nw7BXP5ZgjoH2pZg5J5bjOGnKM+SJBrrh07WROvYG4VaLiuowIGizXj2ZiAEvYBxXQ 0gHVbIuYcjH1lQJ6fIQHTHz2bmoW3+SKm1sqM2nA= Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 51D051E080; Mon, 13 Mar 2017 15:44:19 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 13 Mar 2017 11:44:18 -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.1178.000; Mon, 13 Mar 2017 11:44:18 -0400 From: "Salz, Rich" To: Nikos Mavrogiannopoulos , Curdle Thread-Topic: [Curdle] Some work for the group Thread-Index: AQHScQapPZALJc3H1k6dKeAsT1IqsaFPVh8AgABRoQCAB4KXgIAbEqWAgABR0gCAGx+/AIABO9kAgAADkQCABIPiAIAAD2SA//+9XyA= Date: Mon, 13 Mar 2017 15:44:17 +0000 Message-ID: <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> <1489419619.3159.25.camel@redhat.com> In-Reply-To: <1489419619.3159.25.camel@redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.17] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Curdle] Some work for the group X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 15:44:21 -0000 VGhlIHByZS1oYXNoIGlzIG5vdCBrbm93biB0byBiZSBiYWQsIGFsdGhvdWdoIGl0IGNhbiBiZSBy aXNreSBmb3Igc29tZSBzeXN0ZW1zLiBUaGUgZ29hbCBpcyB0byBub3QgaGF2ZSByaXNreSB0aGlu Z3MgaWYgd2UgZG9uJ3QgbmVlZCB0aGVtLiBTbyBmYXIsIHRoZSBvbmx5IHVzZS1jYXNlIHRoYXQg aGFzIGhhZCBzdXBwb3J0IGlzIENSTCdzLCB3aGljaCBhcmUgbGVzcyBsaWtlbHkgdG8gYmUgcmlz a3kgc2luY2UgdGhlIHNhbWUga2V5cGFpciBnZW5lcmFsbHkgc2lnbnMgY2VydGlmaWNhdGVzLiBJ biB0aGUgaW50ZXJlc3Qgb2YgcHJvZ3Jlc3NpbmcgdGhlIGRyYWZ0LCB3ZSBhcmUgYXNraW5nIGlm IHByZS1oYXNoIGlzIGEgTUFZIGZvciBDUkwncyBhbmQgYSBTSE9VTEQgTk9UIG9yIE1VU1QgTk9U IGZvciBhbGwgb3RoZXIgdXNlcy4NCg0KLS0gIA0KU2VuaW9yIEFyY2hpdGVjdCwgQWthbWFpIFRl Y2hub2xvZ2llcw0KTWVtYmVyLCBPcGVuU1NMIERldiBUZWFtDQpJTTogcmljaHNhbHpAamFiYmVy LmF0IFR3aXR0ZXI6IFJpY2hTYWx6DQo= From nobody Mon Mar 13 10:22: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 9955C129891 for ; Mon, 13 Mar 2017 10:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GCk2nv1L5jWd for ; Mon, 13 Mar 2017 10:22:10 -0700 (PDT) Received: from mail-wr0-x241.google.com (mail-wr0-x241.google.com [IPv6:2a00:1450:400c:c0c::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 432741294CA for ; Mon, 13 Mar 2017 10:22:10 -0700 (PDT) Received: by mail-wr0-x241.google.com with SMTP id u48so20956145wrc.1 for ; Mon, 13 Mar 2017 10:22:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Nt38plZDtG312PXhx6xzLrKLhzhI+oi6T7QcSfCrq5Y=; b=Asj4OptSYVaNdiCLm/H+VWGMNX5HDczNsLJlYcPmnFPbtuzVedqufuibqSmEF/t0c8 uhkNWZWksTEDS2WnO89xZnt0f9N5oALBfwTNSzOMrgqDi0bKy28zMJpze7akBGL5Izi7 yYMjKzXjVibok6Q2U4TGqKypfiGKpuqWfRPNl76jHETCAYBY3ULhnKCojYSYuAJMlPQU q0SxKbjK7xZKwq6eefP6yEJwRD2ZXsz2IiZdSq/yeRoj2xZLG36DlCxObUKdC0s7kBXx 4tatbRkYJwo4XmFmLI2ivkvRxMrxuT7jjD0usPQ0IusClAVTWWck37DBnnPSaa1ot6I6 KLyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Nt38plZDtG312PXhx6xzLrKLhzhI+oi6T7QcSfCrq5Y=; b=tRPJ2YNDlEedqaHlzVcnonyimfaJX6I3J+9cTa6m4k8HTPwVDmrc93x7kmCcg/YgX+ GkGXrhxPu8sFdLeRE2mUCanc/yAMO5byczDrnOnY8+xZTaqxuuFJ0rk48CLWgETfcROR smBq95oMAmdSo+1OnLea2E+lltAbnNJTjxKBiP+PI3m4Dw36pb3JG+S60cEe4pX0vzBL iTHvYJEeDwb1xwrMu06gy0c+CcMk1mVS9Q92uLcFT/lmKeW1gVPM41tyNokG635NwNS5 IcWwlCZQtUIvt9/xIHVQZXjb5B4p3iCbMoCD5p0xCdc1NgoCL7phqD6mWMDiWcVgpiZQ xt9w== X-Gm-Message-State: AMke39nTpwjLx9fYZu1i+F84QBgKdGffX7nznj8pB5n0R95TpJT3rjN+VAX+AKCUJ245Aw== X-Received: by 10.223.130.214 with SMTP id 80mr30085542wrc.43.1489425728683; Mon, 13 Mar 2017 10:22:08 -0700 (PDT) Received: from users-mbp.mshome.net ([176.12.144.108]) by smtp.gmail.com with ESMTPSA id t195sm12061124wmt.32.2017.03.13.10.22.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Mar 2017 10:22:07 -0700 (PDT) From: Yoav Nir Message-Id: <43102E1B-C072-4CE2-9A3E-CDEDE1536AFB@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_9E0EE427-8BD5-4F1E-B09A-AEE0D023C63C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 13 Mar 2017 19:21:33 +0200 In-Reply-To: <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> To: Rich Salz References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> <1489419619.3159.25.camel@redhat.com> <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Nikos Mavrogiannopoulos , Curdle Subject: Re: [Curdle] Some work for the group X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 17:22:14 -0000 --Apple-Mail=_9E0EE427-8BD5-4F1E-B09A-AEE0D023C63C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Speaking as an implementer of a relying party, if pre-hash is a MAY for = CRLs on the CA side, it becomes a MUST on the relying party side. I MAY = receive a CRL signed with pre-hashed EdDSA, so I MUST implement it if I = want interoperability. I also MUST implement the non pre-hashed EdDSA, = because certificates are very likely to be signed with that. So unless there=E2=80=99s a very good reason to sign CRLs with the = pre-hashed version, I=E2=80=99d rather that it be MUST NOT for all uses. The claim has been made that future hardware (current hardware does not = implement EdDSA) will not be able to hold an entire CRL all at once in = memory, and therefore will need to be fed this CRL one chunk at a time, = implying the need for a pre-hash. However, the size of CRLs is entirely = determined by CA policy. The size of a CRL is bounded by the number of = certificates that share the same CDP. A CA can set this value to any = number from 1 to all the certificates ever issued, and it can set the = value so that it fits the hardware limitations without pre-hashing. I don=E2=80=99t think forcing the relying parties (all several billions = of them) to implement both variations is better than forcing CAs to = adjust the parameter of ce > On 13 Mar 2017, at 17:44, Salz, Rich wrote: >=20 > The pre-hash is not known to be bad, although it can be risky for some = systems. The goal is to not have risky things if we don't need them. So = far, the only use-case that has had support is CRL's, which are less = likely to be risky since the same keypair generally signs certificates. = In the interest of progressing the draft, we are asking if pre-hash is a = MAY for CRL's and a SHOULD NOT or MUST NOT for all other uses. >=20 > -- > Senior Architect, Akamai Technologies > Member, OpenSSL Dev Team > IM: richsalz@jabber.at Twitter: RichSalz > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle --Apple-Mail=_9E0EE427-8BD5-4F1E-B09A-AEE0D023C63C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJYxtUdAAoJELhJCxUKWMyZ9bYH/24RXaagVQp13BeKg5pQWSFU 6knjw1hxDWhz/julNyVZbyufbiTn0hkLg6Vzw0Laoj3AZyXybFBlhFlQUvJs/o4Q zJFxCdcsDDuK/9IXGeeTEykfRp27oRjf0PW5SR+tILcebKzhoKdVjNNVa9k4In8w E6cLXTQO0Tx4SgGqSDZzN0Y8RUPB4AoCUMnDACThk2cCs6se6slAhDruQg6oe35P Wu9yXTvJR9Vu37Kns7MjPGXfXrQEjc0piUUM4UrAolCY3qXVKgJSU6f8griybVIg eCMHsEoy9YhI2hcP0QuKJTJ770nOtKnf9tYjAmlsh09xDMY8MHuHMmzGm01ICkk= =Fj5C -----END PGP SIGNATURE----- --Apple-Mail=_9E0EE427-8BD5-4F1E-B09A-AEE0D023C63C-- From nobody Mon Mar 13 13:02:29 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 67DFA129AFB for ; Mon, 13 Mar 2017 13:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2SOmGtJrSm8 for ; Mon, 13 Mar 2017 13:02:26 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B27DF129AF8 for ; Mon, 13 Mar 2017 13:02:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4F262BEAA; Mon, 13 Mar 2017 20:02:21 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X41PqXf45XRy; Mon, 13 Mar 2017 20:02:16 +0000 (GMT) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 49996BE8A; Mon, 13 Mar 2017 20:02:16 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1489435336; bh=mkKAFYnW8kbxWwpTM6xt4GCDnnmEG3F201lkFMyNmAk=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=OBRn5KKC6RH1lde6+f/tmkW3S4ncoNknQ4dutx3N9C6aYZeLlIIzvT9lM5vupl6Dj XkfHKNbeFZ6MfdMZXurVRxb1XQGE8ICoXuY3N8oig8hd/7rS/mwRc8czXFTVJG0hyD uvb0NdVPc/ta6bJ9385rxpBGKknDxJeDhKKLUmeI= To: Yoav Nir , Rich Salz References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> <1489419619.3159.25.camel@redhat.com> <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> <43102E1B-C072-4CE2-9A3E-CDEDE1536AFB@gmail.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <75ef8dec-03b6-4eb0-fba0-3812d4df5659@cs.tcd.ie> Date: Mon, 13 Mar 2017 20:02:15 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <43102E1B-C072-4CE2-9A3E-CDEDE1536AFB@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="O5Aben9LHgtjPsgDejXvNNMQu5U2L8T9O" Archived-At: Cc: Nikos Mavrogiannopoulos , Curdle Subject: Re: [Curdle] Some work for the group X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 20:02:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --O5Aben9LHgtjPsgDejXvNNMQu5U2L8T9O Content-Type: multipart/mixed; boundary="beRxj4sknrn2kaDx4vuG4ap6ctwXev1vv"; protected-headers="v1" From: Stephen Farrell To: Yoav Nir , Rich Salz Cc: Nikos Mavrogiannopoulos , Curdle Message-ID: <75ef8dec-03b6-4eb0-fba0-3812d4df5659@cs.tcd.ie> Subject: Re: [Curdle] Some work for the group References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> <1489419619.3159.25.camel@redhat.com> <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> <43102E1B-C072-4CE2-9A3E-CDEDE1536AFB@gmail.com> In-Reply-To: <43102E1B-C072-4CE2-9A3E-CDEDE1536AFB@gmail.com> --beRxj4sknrn2kaDx4vuG4ap6ctwXev1vv Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 13/03/17 17:21, Yoav Nir wrote: > Speaking as an implementer of a relying party, if pre-hash is a MAY > for CRLs on the CA side, it becomes a MUST on the relying party side. > I MAY receive a CRL signed with pre-hashed EdDSA, so I MUST implement > it if I want interoperability. I also MUST implement the non > pre-hashed EdDSA, because certificates are very likely to be signed > with that. >=20 > So unless there=E2=80=99s a very good reason to sign CRLs with the pre-= hashed > version, I=E2=80=99d rather that it be MUST NOT for all uses. >=20 > The claim has been made that future hardware (current hardware does > not implement EdDSA) will not be able to hold an entire CRL all at > once in memory, and therefore will need to be fed this CRL one chunk > at a time, implying the need for a pre-hash. However, the size of > CRLs is entirely determined by CA policy. The size of a CRL is > bounded by the number of certificates that share the same CDP. A CA > can set this value to any number from 1 to all the certificates ever > issued, and it can set the value so that it fits the hardware > limitations without pre-hashing. >=20 > I don=E2=80=99t think forcing the relying parties (all several billions= of > them) to implement both variations is better than forcing CAs to > adjust the parameter of ce With no hats: +1 There's also the argument about rarely exercised code paths bring a recipe for bad outcomes. It seems like the pre-hash stuff will all be part of such code-paths. S. >=20 >> On 13 Mar 2017, at 17:44, Salz, Rich wrote: >>=20 >> The pre-hash is not known to be bad, although it can be risky for >> some systems. The goal is to not have risky things if we don't need >> them. So far, the only use-case that has had support is CRL's, >> which are less likely to be risky since the same keypair generally >> signs certificates. In the interest of progressing the draft, we >> are asking if pre-hash is a MAY for CRL's and a SHOULD NOT or MUST >> NOT for all other uses. >>=20 >> -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team=20 >> IM: richsalz@jabber.at Twitter: RichSalz=20 >> _______________________________________________ Curdle mailing >> list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle >=20 >=20 >=20 > _______________________________________________ Curdle mailing list=20 > Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle >=20 --beRxj4sknrn2kaDx4vuG4ap6ctwXev1vv-- --O5Aben9LHgtjPsgDejXvNNMQu5U2L8T9O Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYxvrHAAoJEC88hzaAX42iCcUH/0shUjvlxYzqhcyLnYw7pz+0 ZaTBnEcYVRW9VYFane8Jr7skuCr7wKprJDM0nrH2X1RgpJbKESd5D0Xha33ycfaP DhSiiZIxVA8DOTq+oXAMSPaRU5QgwknL0UMyrew+1fbRKXMlbwm6PDIvBFg+vnrh wzi3d+BoD8VPHiO7USyW8epnRL81bFC6lVm6dUoi108cvD92aqq9W59V6CqFkSLP ZosULtg/BUzaU0p9oYO4/ZVeQs2ILURjP6A8lGCpIOhJM3Nw6sVRhT2qeV6C2BBs wLCtHjhqMprwYUd3wP+D/8ZeVMLrefynC1g0AG1Kq74/vI4L3ZanqfpkAI2PMoQ= =Iiw7 -----END PGP SIGNATURE----- --O5Aben9LHgtjPsgDejXvNNMQu5U2L8T9O-- From nobody Mon Mar 13 13:18: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 749101294BF for ; Mon, 13 Mar 2017 13:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=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 i0AVehzTRTN0 for ; Mon, 13 Mar 2017 13:18:56 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 910D3129446 for ; Mon, 13 Mar 2017 13:18:56 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 1600543340C; Mon, 13 Mar 2017 20:18:56 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id EDEBE433401; Mon, 13 Mar 2017 20:18:55 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1489436335; bh=MYDVk/EVWdl81mcOApo0XFBKXMMFGjS8ZI6Ombd0ej0=; l=390; h=From:To:CC:Date:References:In-Reply-To:From; b=mhYjaj30RKNZVmyfw94PxXzk9nU61OYhsewCTfU0bgXXE10LM1hkm/77Rn3PfiCs2 tyi32w4rxIRyGs0POiWvsfSh4JhFk/D6AQnerRJUz3Da5XpqPTkLTzphLohl/lSK/b MFj1DhVKQ/164BQpX5HgBfRZ5x0hLbMnY8iC8s04= Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id EA3D41FC8D; Mon, 13 Mar 2017 20:18:55 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 13 Mar 2017 16:18:55 -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.1178.000; Mon, 13 Mar 2017 16:18:55 -0400 From: "Salz, Rich" To: Stephen Farrell , Yoav Nir Thread-Topic: [Curdle] Some work for the group Thread-Index: AQHScQapPZALJc3H1k6dKeAsT1IqsaFPVh8AgABRoQCAB4KXgIAbEqWAgABR0gCAGx+/AIABO9kAgAADkQCABIPiAIAAD2SA//+9XyCAAF7qgIAALOaA///BU9A= Date: Mon, 13 Mar 2017 20:18:54 +0000 Message-ID: References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> <1489419619.3159.25.camel@redhat.com> <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> <43102E1B-C072-4CE2-9A3E-CDEDE1536AFB@gmail.com> <75ef8dec-03b6-4eb0-fba0-3812d4df5659@cs.tcd.ie> In-Reply-To: <75ef8dec-03b6-4eb0-fba0-3812d4df5659@cs.tcd.ie> 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.17] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Nikos Mavrogiannopoulos , Curdle Subject: Re: [Curdle] Some work for the group X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 20:18:57 -0000 U3BlYWtpbmcgYXMgYW4gaW5kaXZpZHVhbCwgYW5kIGEgbWVtYmVyIG9mIGEgdGVhbSBsaWtlbHkg dG8gaW1wbGVtZW50IHRoaXMgKE9wZW5TU0wpLCBJIGFtIGFsc28gYWdhaW5zdCBwcmUtaGFzaDsg SSB0aGluayBZb2F2IGhhcyBwcm92aWRlZCBhbiBhZGVxdWF0ZSB3b3JrLWFyb3VuZC4NCg0KLS0g IA0KU2VuaW9yIEFyY2hpdGVjdCwgQWthbWFpIFRlY2hub2xvZ2llcw0KTWVtYmVyLCBPcGVuU1NM IERldiBUZWFtDQpJTTogcmljaHNhbHpAamFiYmVyLmF0IFR3aXR0ZXI6IFJpY2hTYWx6DQoNCg== From nobody Tue Mar 14 00:59: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 54885126CD8 for ; Tue, 14 Mar 2017 00:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.903 X-Spam-Level: X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 48Dc7i2YYNzs for ; Tue, 14 Mar 2017 00:59:46 -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 CDDF71294A6 for ; Tue, 14 Mar 2017 00:59:45 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 864CD3B716; Tue, 14 Mar 2017 07:59:46 +0000 (UTC) Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.3.26]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v2E7xiLi013218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 14 Mar 2017 03:59:45 -0400 Message-ID: <1489478384.23155.1.camel@redhat.com> From: Nikos Mavrogiannopoulos To: "Salz, Rich" , Curdle Date: Tue, 14 Mar 2017 08:59:44 +0100 In-Reply-To: <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> <1489419619.3159.25.camel@redhat.com> <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Tue, 14 Mar 2017 07:59:46 +0000 (UTC) Archived-At: Subject: Re: [Curdle] Some work for the group X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 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, 14 Mar 2017 07:59:48 -0000 On Mon, 2017-03-13 at 15:44 +0000, Salz, Rich wrote: > The pre-hash is not known to be bad, although it can be risky for > some systems. The goal is to not have risky things if we don't need > them. I guess your definition of risky here is that it is as secure as the existing signature schemes? > So far, the only use-case that has had support is CRL's, which are > less likely to be risky since the same keypair generally signs > certificates. In the interest of progressing the draft, we are asking > if pre-hash is a MAY for CRL's and a SHOULD NOT or MUST NOT for all > other uses. I disagree. It should not be defined _at all_. There is very little point to define a signature scheme which is used for some purposes only. It would be unique, and would introduce complexity that is unnecessary. There are other signature schemes that work fine irrespective of the input size. regards, Nikos From nobody Tue Mar 14 02:00: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 A98CE1294E0 for ; Tue, 14 Mar 2017 02:00: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, 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 Cx15L0S6H2HE for ; Tue, 14 Mar 2017 02:00:20 -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 04155129469 for ; Tue, 14 Mar 2017 02:00:19 -0700 (PDT) X-AuditID: c6180641-0291898000000a06-e8-58c76acc36b1 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by (Symantec Mail Security) with SMTP id 29.80.02566.CCA67C85; Tue, 14 Mar 2017 05:00:13 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0319.002; Tue, 14 Mar 2017 05:00:18 -0400 From: Daniel Migault To: curdle Thread-Topic: Multiple WGLC Thread-Index: AdKcoRzefuKObAUvSL+sk19Vkzo63g== Date: Tue, 14 Mar 2017 09:00:17 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118BA5A70@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_2DD56D786E600F45AC6BDE7DA4E8A8C118BA5A70eusaamb107erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUyuXRPuO7ZrOMRBvOfclhsXTiL2YHRY8mS n0wBjFFcNimpOZllqUX6dglcGZOe3WEv2OJYcexvE0sD41TrLkZODgkBE4mmte1MXYxcHEIC 6xkljqw4zAbhLGeU+PhsDztIFZuAkUTboX4wW0RARuJ1911mEFtYQFxiybdLQDYHWPzQEg6I Ej2JRQ3TwMIsAqoSa65ngIR5BXwl3jzoZgWxGQXEJL6fWsMEYjMDTbn1ZD4TxD0CEkv2nGeG sEUlXj7+xwphK0l8/D2fHaI+X+LUqUvsEDMFJU7OfMIygVFwFpJRs5CUzUJSBhHXkViw+xMb hK0tsWzha2YY+8yBx0zI4gsY2VcxcpQWF+TkphsZbmIEhvcxCTbHHYx7ez0PMQpwMCrx8G6o PhYhxJpYVlyZe4hRgoNZSYT378rjEUK8KYmVValF+fFFpTmpxYcYpTlYlMR5r4fcDxcSSE8s Sc1OTS1ILYLJMnFwSjUwctrYFvw8InuV++mR1/y7GTas+f/GbVsHs+8Xr7VrxfneKzd5rLAR XsHseb+mvNFgq35ZlN0M8dkOdsocuzpldzsyWCxYeTh+/a7s4P2nGR3P8OtO/brvVfzv6vcq 9p12kWecmW+f/sb0vvNq9u9jqVdmrAs1zNY8qvsl942pJQt7sLlPbT6nEktxRqKhFnNRcSIA EbL4BmsCAAA= Archived-At: Subject: [Curdle] Multiple WGLC X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 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, 14 Mar 2017 09:00:22 -0000 --_000_2DD56D786E600F45AC6BDE7DA4E8A8C118BA5A70eusaamb107erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, This emails starts a WGLC on the following drafts: - draft-ietf-curdle-rsa-sha2-03 [1] - draft-ietf-curdle-ssh-ext-info-02 [2] - draft-ietf-curdle-ssh-kex-sha2-05 [3] - draft-ietf-curdle-ssh-modp-dh-sha2-02 [4] Please provide your comments by March 28 on the mailing list. In order to ease tracking comments/reviews/issue raised, please make sure t= hese are handled in a specific thread. Make sure the draft name is mentione= d in the mail subject. Yours, Daniel [1] https://datatracker.ietf.org/doc/draft-ietf-curdle-rsa-sha2/ [2] https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-ext-info/ [3] https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-kex-sha2/ [4] https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-modp-dh-sha2/ [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_2DD56D786E600F45AC6BDE7DA4E8A8C118BA5A70eusaamb107erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

This emails starts a WGLC on the following drafts:

    - draft-ietf-curdle-rsa-sha2-03 [= 1]

    - draft-ietf-curdle-ssh-ext-info-= 02 [2]

    - draft-ietf-curdle-ssh-kex-sha2-= 05 [3]

    - draft-ietf-curdle-ssh-modp-dh-s= ha2-02 [4]

 

Please provide your comments by March 28 on the mail= ing list.

 

In order to ease tracking comments/reviews/issue rai= sed, please make sure these are handled in a specific thread. Make sure the= draft name is mentioned in the mail subject.

 

Yours,

Daniel

 

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

[2] https://datatracker.ietf.org/doc/draft-ietf-curd= le-ssh-ext-info/

[3] https://datatracker.ietf.org/doc/draft-ietf-curd= le-ssh-kex-sha2/

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

 

 

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_2DD56D786E600F45AC6BDE7DA4E8A8C118BA5A70eusaamb107erics_-- From nobody Tue Mar 14 02:32: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 F084D129515 for ; Tue, 14 Mar 2017 02:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.903 X-Spam-Level: X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 q4P27shJlmWW for ; Tue, 14 Mar 2017 02:32:49 -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 7AD8D12952D for ; Tue, 14 Mar 2017 02:32:49 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3FD4880F6D for ; Tue, 14 Mar 2017 09:32:50 +0000 (UTC) Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.3.26]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v2E9Wm6R011016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 14 Mar 2017 05:32:49 -0400 Message-ID: <1489483968.23155.9.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Curdle Date: Tue, 14 Mar 2017 10:32:48 +0100 In-Reply-To: <1489478384.23155.1.camel@redhat.com> References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> <1489419619.3159.25.camel@redhat.com> <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> <1489478384.23155.1.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Tue, 14 Mar 2017 09:32:50 +0000 (UTC) Archived-At: Subject: Re: [Curdle] Some work for the group X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 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, 14 Mar 2017 09:32:51 -0000 On Tue, 2017-03-14 at 08:59 +0100, Nikos Mavrogiannopoulos wrote: > >  So far, the only use-case that has had support is CRL's, which are > > less likely to be risky since the same keypair generally signs > > certificates. In the interest of progressing the draft, we are > > asking > > if pre-hash is a MAY for CRL's and a SHOULD NOT or MUST NOT for all > > other uses. > > I disagree. It should not be defined _at all_. There is very little > point to define a signature scheme which is used for some purposes > only. It would be unique, and would introduce complexity that is > unnecessary. There are other signature schemes that work fine > irrespective of the input size. And to clarify further. If I remember well, I had added the pre-hashed option in the early draft of Simon and my hope was to spark discussion and decide on a single variant, _not_ to have both in the final document. I was expecting the pre-hashed to be standardized due to the fact that it does not require changes to existing APIs to be used, and does not require the whole data for signing. The other option would need more implementation work, but on the other hand bring additional benefits in terms of digital signature guarantees. That's why I insist on dropping the pre-hashed variant at this point. If there is no support for it being the main algorithm, it should not be there. Supporting both variants with one specially limited, it would only lead to incompatibilities and complex code. Incompatibilities because some implementations will chose the easy path of including the variant that fits their existing design (pre-hashed more likely), and complex code because at some point they will figure they have to support both variants to be compatible with certs or CRLs issued by XYZ CA. If there is need for the pre-hashed variant, it can be done in a different document. regards, Nikos From nobody Tue Mar 14 04:50:04 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 BE525129569 for ; Tue, 14 Mar 2017 04:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=nistgov.onmicrosoft.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 hWXrOqrqqw1i for ; Tue, 14 Mar 2017 04:50:01 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0116.outbound.protection.outlook.com [23.103.200.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7870A129568 for ; Tue, 14 Mar 2017 04:50:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=R4NjM3jb9vGFt/DTI2BwPq4OprEOgSmYGdX7J3mU9y8=; b=IIkKGPT5pZir63E2XdJi67GHy9jpfxhX27XvoQ1ACYzWpjDf9kHE/lbO+SW8h00tFgmfmzvSRm2GKeTvNueo7Bd8Hjwej3r3YF54mXtK+oyU0SQIXawuerArutRuPmBjSqkFcZHIQaRIteBC/BRT//LlOG0Q8qIvFQAjfDOSbSg= Received: from CY4PR09MB1464.namprd09.prod.outlook.com (10.173.191.22) by CY4PR09MB1463.namprd09.prod.outlook.com (10.173.191.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.14; Tue, 14 Mar 2017 11:49:59 +0000 Received: from CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) by CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) with mapi id 15.01.0961.020; Tue, 14 Mar 2017 11:49:59 +0000 From: "Dang, Quynh (Fed)" To: Yoav Nir , "rsalz@akamai.com" Thread-Topic: [Curdle] Some work for the group Thread-Index: AQHSUiKs3PWVL7wFScuPYdGzcgHHmKD/tuoAgAUxWICAA8bVAIAAjpmAgDQrVACAEdcRAIAAUaIAgAeCl4CAGwHggIAAUdMAgBswggCAATvZAIAAA5EAgASUpgCAAA9kgIAAARyAgAAbLYCAAQNjAA== Date: Tue, 14 Mar 2017 11:49:59 +0000 Message-ID: References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> <1489419619.3159.25.camel@redhat.com> <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> <43102E1B-C072-4CE2-9A3E-CDEDE1536AFB@gmail.com> In-Reply-To: <43102E1B-C072-4CE2-9A3E-CDEDE1536AFB@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.222.9] x-microsoft-exchange-diagnostics: 1; CY4PR09MB1463; 7:pKVDyjblkPXjYRGKNBV/Ii5fu2iI8JIVaCenJMKiQFhEbWd/HPGs61eQW2LIzJEmDuvnAetP7riwVS4zIiNY2Pru9HXI9P5u0G4BMYOCP0ip2kTFwuKxlMcSkafcLtY53jrxP7U3ZqKEmWyrX0bTxDXhnifTUcAoLfyzdo3tWoPXqrBkmE476me4suV2Bg0oxt4rc/MV1DQw+/WqLr8NFW+9iPTN0RNA4yvt8YZSiSCm9Dq8V3iF5FKvWPRiBhLlnWozX6DB8sSzxzBddOwluV3nEphRCDPU8kgdaE3dR5kBViBf+j5/4n+TATdchmiom6+pvkkDhHoE9Z0SKeBuuQ== x-ld-processed: 2ab5d82f-d8fa-4797-a93e-054655c61dec,ExtAddr x-ms-office365-filtering-correlation-id: 84c540eb-4357-4a5d-7ecc-08d46ad03e24 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR09MB1463; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(148322886591682); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(20161123558025)(6072148); SRVR:CY4PR09MB1463; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1463; x-forefront-prvs: 02462830BE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39410400002)(39850400002)(39840400002)(39450400003)(39860400002)(377454003)(24454002)(2950100002)(53936002)(5660300001)(7906003)(99286003)(6486002)(77096006)(86362001)(2501003)(102836003)(3846002)(6116002)(6506006)(4001350100001)(54906002)(54896002)(6306002)(25786008)(83506001)(6512007)(6436002)(36756003)(2906002)(236005)(606005)(66066001)(229853002)(3660700001)(189998001)(3280700002)(76176999)(2900100001)(106116001)(50986999)(54356999)(38730400002)(6246003)(4326008)(68736007)(122556002)(39060400002)(8676002)(8936002)(81166006)(81156014)(7736002)(93886004)(53546007); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1463; H:CY4PR09MB1464.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D4ED4D1B31675qdangnistgov_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Mar 2017 11:49:59.2271 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1463 Archived-At: Cc: Nikos Mavrogiannopoulos , Curdle Subject: Re: [Curdle] Some work for the group X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 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, 14 Mar 2017 11:50:04 -0000 --_000_D4ED4D1B31675qdangnistgov_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Yoav, Is it reasonable to think that there will be constrained devices which need= to handle CRL lists ? If the answer is yes, without the pre-hash option, those devices would need= to either: (1) buffer large messages (costly) or (2) verify multiple CRL l= ists every time (costly) if the CA creates multiple CRL lists every time wi= th the non-prehash option. If only one option were to be used, the pre-hash would be the best choice b= ecause it works well everywhere, not like the non-prehash one. Quynh. From: Curdle > on b= ehalf of Yoav Nir > Date: Monday, March 13, 2017 at 12:21 PM To: "rsalz@akamai.com" > Cc: Nikos Mavrogiannopoulos >, Curd= le > Subject: Re: [Curdle] Some work for the group Speaking as an implementer of a relying party, if pre-hash is a MAY for CRL= s on the CA side, it becomes a MUST on the relying party side. I MAY receiv= e a CRL signed with pre-hashed EdDSA, so I MUST implement it if I want inte= roperability. I also MUST implement the non pre-hashed EdDSA, because cert= ificates are very likely to be signed with that. So unless there=92s a very good reason to sign CRLs with the pre-hashed ver= sion, I=92d rather that it be MUST NOT for all uses. The claim has been made that future hardware (current hardware does not imp= lement EdDSA) will not be able to hold an entire CRL all at once in memory,= and therefore will need to be fed this CRL one chunk at a time, implying t= he need for a pre-hash. However, the size of CRLs is entirely determined by= CA policy. The size of a CRL is bounded by the number of certificates that= share the same CDP. A CA can set this value to any number from 1 to all th= e certificates ever issued, and it can set the value so that it fits the ha= rdware limitations without pre-hashing. I don=92t think forcing the relying parties (all several billions of them) = to implement both variations is better than forcing CAs to adjust the param= eter of ce On 13 Mar 2017, at 17:44, Salz, Rich > wrote: The pre-hash is not known to be bad, although it can be risky for some syst= ems. The goal is to not have risky things if we don't need them. So far, th= e only use-case that has had support is CRL's, which are less likely to be = risky since the same keypair generally signs certificates. In the interest = of progressing the draft, we are asking if pre-hash is a MAY for CRL's and = a SHOULD NOT or MUST NOT for all other uses. -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz@jabber.at Twitter: RichSalz _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle --_000_D4ED4D1B31675qdangnistgov_ Content-Type: text/html; charset="Windows-1252" Content-ID: <45ED0DC9D3439A45BACCDD985ED65220@namprd09.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hi Yoav,

Is it reasonable to think that there will be constrained devices which= need to handle CRL lists ?

If the answer is yes, without the pre-hash option, those devices would= need to either: (1) buffer large messages (costly) or (2) verify multiple = CRL lists every time (costly) if the CA creates multiple CRL lists every ti= me with the non-prehash option. 

If only one option were to be used, the pre-hash would be the best cho= ice because it works well everywhere, not like the non-prehash one.

Quynh. 

From: Curdle <curdle-bounces@ietf.org> on behalf of Yoav = Nir <ynir.ietf@gmail.com><= br> Date: Monday, March 13, 2017 at 12:= 21 PM
To: "rsalz@akamai.com" <rsalz@akamai.com>
Cc: Nikos Mavrogiannopoulos <nmav@redhat.com>, Curdle <curdle@ietf.org>
Subject: Re: [Curdle] Some work for= the group

Speaking as an implementer of a relying party, if pre-hash is a MAY fo= r CRLs on the CA side, it becomes a MUST on the relying party side. I MAY r= eceive a CRL signed with pre-hashed EdDSA, so I MUST implement it if I want= interoperability.  I also MUST implement the non pre-hashed EdDSA, because certificates are very likely t= o be signed with that.

So unless there=92s a very good reason to sign CRLs with the pre-hashe= d version, I=92d rather that it be MUST NOT for all uses.

The claim has been made that future hardware (current hardware does no= t implement EdDSA) will not be able to hold an entire CRL all at once in me= mory, and therefore will need to be fed this CRL one chunk at a time, imply= ing the need for a pre-hash. However, the size of CRLs is entirely determined by CA policy. The size of a CRL is= bounded by the number of certificates that share the same CDP. A CA can se= t this value to any number from 1 to all the certificates ever issued, and = it can set the value so that it fits the hardware limitations without pre-hashing.

I don=92t think forcing the relying parties (all several billions of t= hem) to implement both variations is better than forcing CAs to adjust the = parameter of ce

On 13 Mar 2017, at 17:44, Salz, Rich <rsalz@akamai.com> wrote:
The pre-hash is not known to be bad, although it can be risky for some= systems. The goal is to not have risky things if we don't need them. So fa= r, the only use-case that has had support is CRL's, which are less likely t= o be risky since the same keypair generally signs certificates. In the interest of progressing the draft, we= are asking if pre-hash is a MAY for CRL's and a SHOULD NOT or MUST NOT for= all other uses.
--
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richsalz@jabber.at Twitt= er: RichSalz
_______________________________________________
Curdle mailing list


 --_000_D4ED4D1B31675qdangnistgov_-- From nobody Tue Mar 14 05:37:24 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 77C0812969A for ; Tue, 14 Mar 2017 05:37:23 -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 eJQjMKk3Kns2 for ; Tue, 14 Mar 2017 05:37:21 -0700 (PDT) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::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 CDF76129581 for ; Tue, 14 Mar 2017 05:37:20 -0700 (PDT) Received: by mail-wr0-x235.google.com with SMTP id g10so123162787wrg.2 for ; Tue, 14 Mar 2017 05:37:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=tD7oJJoedzwpj1U6B072MnyRazgBli1vUPy4GiKdBOg=; b=uO2PENXhhjLaVm1UXBjTSykuw8YMglQDkivkJXWxt6J9aMyZfyCGlC6NWX9OQhK7Hm vbeDe5WiC4EXsRypHqSxDxnJv6/DXOYzs+ylyI18eFXBuHHeCEHXBZTaP9k92hqFmzwy qDz/I51WRAK7POt6n35regFmNlfbCz+L5pinmryw5+sFKh3vZD96/PesWWIA3t5JhNVP M+cagm/90Ukpujbakmk0/Q0GUqN7ubS6n9HAz3MXNK8nTJqUHmspjQyS1LFDKBFgnESV N5BKn/3NCEd28YKbDP+plBUQarshfHkQJaFxoMV4ugzd5QuirNIcRzZvH6DoKURCnNLI 5X+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=tD7oJJoedzwpj1U6B072MnyRazgBli1vUPy4GiKdBOg=; b=MvfO2xfklErg0vf9age1GDVpvO88WKKkyfO96lEdwtHD+22zpfVGHtLHJmJolfyEFn 74zQR0/zXbdnZGC6r7+wRC/FlDubfc9Zrbg2CeDkFUnpuifbTnBCG4IKWh+HvDBSqh7U 6rryjGZIdHjQZhAXl4uYY7aa4vNmXgkdEZtR1vD7EH8Jx4VJxS+mnBibubnGA5n9hq3o H2TiNdpkGbSmBDp6d6TPIvm4FJ9BM25H3HxSkzE4U/ogNyjTphkBzQ97u3ehPuDPmGj6 5YYH7h7KSnWsUECDQ5+xbmtAVm5wd98Kc6+xtVorx0HQ1khd04DbkOv400sV21sLTGXg 2rQg== X-Gm-Message-State: AMke39lrhhXrs5jnSAxvDWB+0buQ8VpBhZtbBDukH2UOUWRPdzq6jkk2G3ZcyGCRepUusg== X-Received: by 10.223.134.98 with SMTP id 31mr36095621wrw.69.1489495039363; Tue, 14 Mar 2017 05:37:19 -0700 (PDT) Received: from [172.24.251.163] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id w207sm15351371wmw.1.2017.03.14.05.37.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Mar 2017 05:37:18 -0700 (PDT) From: Yoav Nir Message-Id: <0DE34F3E-A2D2-4396-B12C-D9FD30DC3723@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_8B456346-83A4-43A8-9448-F33DFCD7962B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Tue, 14 Mar 2017 14:37:14 +0200 In-Reply-To: To: "Dang, Quynh (Fed)" References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> <1489419619.3159.25.camel@redhat.com> <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> <43102E1B-C072-4CE2-9A3E-CDEDE1536AFB@gmail.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Nikos Mavrogiannopoulos , Rich Salz , Curdle Subject: Re: [Curdle] Some work for the group X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 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, 14 Mar 2017 12:37:23 -0000 --Apple-Mail=_8B456346-83A4-43A8-9448-F33DFCD7962B Content-Type: multipart/alternative; boundary="Apple-Mail=_6F9BE9E5-0709-4C33-84D5-8413DFA06788" --Apple-Mail=_6F9BE9E5-0709-4C33-84D5-8413DFA06788 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The code that I write generally runs on devices no weaker than phones. I = don=E2=80=99t know if there are constrained devices that will need to = handle CRLs. The trend seems to be moving away from CRLs and adopting = OCSP responses instead. It seems odd to me to believe that embedded systems will process CRLs in = a time where web browsers running on PCs have stopped doing that. Even = if they do, making really small CRLs for them seems like a good idea. = But stapling OCSP responses seems like an even better idea. Yoav > On 14 Mar 2017, at 13:49, Dang, Quynh (Fed) = wrote: >=20 > Hi Yoav, >=20 > Is it reasonable to think that there will be constrained devices which = need to handle CRL lists ? >=20 > If the answer is yes, without the pre-hash option, those devices would = need to either: (1) buffer large messages (costly) or (2) verify = multiple CRL lists every time (costly) if the CA creates multiple CRL = lists every time with the non-prehash option. >=20 > If only one option were to be used, the pre-hash would be the best = choice because it works well everywhere, not like the non-prehash one. >=20 > Quynh. >=20 > From: Curdle > on behalf of Yoav Nir = > > Date: Monday, March 13, 2017 at 12:21 PM > To: "rsalz@akamai.com " > > Cc: Nikos Mavrogiannopoulos >, Curdle > > Subject: Re: [Curdle] Some work for the group >=20 >> Speaking as an implementer of a relying party, if pre-hash is a MAY = for CRLs on the CA side, it becomes a MUST on the relying party side. I = MAY receive a CRL signed with pre-hashed EdDSA, so I MUST implement it = if I want interoperability. I also MUST implement the non pre-hashed = EdDSA, because certificates are very likely to be signed with that. >>=20 >> So unless there=E2=80=99s a very good reason to sign CRLs with the = pre-hashed version, I=E2=80=99d rather that it be MUST NOT for all uses. >>=20 >> The claim has been made that future hardware (current hardware does = not implement EdDSA) will not be able to hold an entire CRL all at once = in memory, and therefore will need to be fed this CRL one chunk at a = time, implying the need for a pre-hash. However, the size of CRLs is = entirely determined by CA policy. The size of a CRL is bounded by the = number of certificates that share the same CDP. A CA can set this value = to any number from 1 to all the certificates ever issued, and it can set = the value so that it fits the hardware limitations without pre-hashing. >>=20 >> I don=E2=80=99t think forcing the relying parties (all several = billions of them) to implement both variations is better than forcing = CAs to adjust the parameter of ce >>=20 >>> On 13 Mar 2017, at 17:44, Salz, Rich > wrote: >>> The pre-hash is not known to be bad, although it can be risky for = some systems. The goal is to not have risky things if we don't need = them. So far, the only use-case that has had support is CRL's, which are = less likely to be risky since the same keypair generally signs = certificates. In the interest of progressing the draft, we are asking if = pre-hash is a MAY for CRL's and a SHOULD NOT or MUST NOT for all other = uses. >>> -- >>> Senior Architect, Akamai Technologies >>> Member, OpenSSL Dev Team >>> IM: richsalz@jabber.at Twitter: RichSalz >>> _______________________________________________ >>> Curdle mailing list >>> Curdle@ietf.org >>> https://www.ietf.org/mailman/listinfo/curdle = >>=20 --Apple-Mail=_6F9BE9E5-0709-4C33-84D5-8413DFA06788 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The code that I write generally runs on devices no weaker = than phones. I don=E2=80=99t know if there are constrained devices that = will need to handle CRLs. The trend seems to be moving away from CRLs = and adopting OCSP responses instead.  

It seems odd to me to believe that = embedded systems will process CRLs in a time where web browsers running = on PCs have stopped doing that. Even if they do, making really small = CRLs for them seems like a good idea.  But stapling OCSP responses = seems like an even better idea.

Yoav

On 14 Mar 2017, at 13:49, Dang, Quynh (Fed) <quynh.dang@nist.gov>= wrote:

Hi Yoav,

Is it reasonable to think that there will be constrained = devices which need to handle CRL lists ?

If the answer is yes, without the pre-hash option, those = devices would need to either: (1) buffer large messages (costly) or (2) = verify multiple CRL lists every time (costly) if the CA creates multiple = CRL lists every time with the non-prehash option. 

If only one option were to be used, the pre-hash would = be the best choice because it works well everywhere, not like the = non-prehash one.

Quynh. 

From: Curdle <curdle-bounces@ietf.org> on behalf of Yoav Nir <ynir.ietf@gmail.com>
Date: Monday, March = 13, 2017 at 12:21 PM
To: "rsalz@akamai.com" <rsalz@akamai.com>
Cc: Nikos = Mavrogiannopoulos <nmav@redhat.com>, Curdle <curdle@ietf.org>
Subject: Re: [Curdle] = Some work for the group

Speaking as an implementer of a relying party, if = pre-hash is a MAY for CRLs on the CA side, it becomes a MUST on the = relying party side. I MAY receive a CRL signed with pre-hashed EdDSA, so = I MUST implement it if I want interoperability.  I also MUST implement the non pre-hashed EdDSA, because certificates are very = likely to be signed with that.

So unless there=E2=80=99s a very good reason to sign = CRLs with the pre-hashed version, I=E2=80=99d rather that it be MUST NOT = for all uses.

The claim has been made that future hardware (current = hardware does not implement EdDSA) will not be able to hold an entire = CRL all at once in memory, and therefore will need to be fed this CRL = one chunk at a time, implying the need for a pre-hash. However, the size of CRLs is entirely determined by CA policy. The size of a CRL = is bounded by the number of certificates that share the same CDP. A CA = can set this value to any number from 1 to all the certificates ever = issued, and it can set the value so that it fits the hardware limitations without pre-hashing.

I don=E2=80=99t think forcing the relying parties (all = several billions of them) to implement both variations is better than = forcing CAs to adjust the parameter of ce

On 13 Mar 2017, at 17:44, Salz, Rich <rsalz@akamai.com> = wrote:
The pre-hash is not known to be bad, although it can be = risky for some systems. The goal is to not have risky things if we don't = need them. So far, the only use-case that has had support is CRL's, = which are less likely to be risky since the same keypair generally signs certificates. In the interest of progressing the draft, = we are asking if pre-hash is a MAY for CRL's and a SHOULD NOT or MUST = NOT for all other uses.
--
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richsalz@jabber.at Twitter: RichSalz
_______________________________________________
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle

= --Apple-Mail=_6F9BE9E5-0709-4C33-84D5-8413DFA06788-- --Apple-Mail=_8B456346-83A4-43A8-9448-F33DFCD7962B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJYx+P7AAoJELhJCxUKWMyZKjwIAMu1R3fXjK9fCczVlvvsXoiP JFEMT0SXjSfY6yMSXgjYO0ZAARYmC0047HQXU/wnaqHGwJgwK3sMb1fTsC7HYlNG b7lDUe6W3a/gARewSn3aWECSOp74FfCII52/L5/NHtG4uZPN0wWA4UbbrVuQGOkd p/LvnL2xOpmFNBXD24vHM4VPklC7+FCgkM1IjCFb+97Qs0u2hg+sf+ODQklidfVj gdsP2eWtng+fmXh4guoyv6NpksULn9xkKsiHMXxQxIKBv4a5LRJfo7I8nLlVCzij jI6gz3b0K1Bl2f0Gmhp1QgvCRqoMoK4WcalfWuiXf/T0G4eB5PZV26lqd7XPyM4= =ucOe -----END PGP SIGNATURE----- --Apple-Mail=_8B456346-83A4-43A8-9448-F33DFCD7962B-- From nobody Tue Mar 14 05:44:38 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 AF7B712952B for ; Tue, 14 Mar 2017 05:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=nistgov.onmicrosoft.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 qKM71guEwwCm for ; Tue, 14 Mar 2017 05:44:35 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0110.outbound.protection.outlook.com [23.103.201.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD88D129547 for ; Tue, 14 Mar 2017 05:44:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=l7/zSkTnj4g8R3ISmtFjj+8eZQoGLtUBBpZJUkdUUCY=; b=T66DYqv6AkJtFlV694cCml2icj3djn7aY0WaEW/EadwTL1267j3FuXguJjBsErR1+I3qB3xi7LzhUW1kmAk7W/qy3tPnfP16m4EJV4etfepq9IDdz4MnvsipDwLMsBYeE3GpMDY4LMAJLGAyIdz1KaAJXxJa8RnQNb1Fr9yfF40= Received: from CY4PR09MB1464.namprd09.prod.outlook.com (10.173.191.22) by CY4PR09MB1461.namprd09.prod.outlook.com (10.173.191.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.17; Tue, 14 Mar 2017 12:44:33 +0000 Received: from CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) by CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) with mapi id 15.01.0961.020; Tue, 14 Mar 2017 12:44:32 +0000 From: "Dang, Quynh (Fed)" To: Yoav Nir , "Dang, Quynh (Fed)" Thread-Topic: [Curdle] Some work for the group Thread-Index: AQHSUiKs3PWVL7wFScuPYdGzcgHHmKD/tuoAgAUxWICAA8bVAIAAjpmAgDQrVACAEdcRAIAAUaIAgAeCl4CAGwHggIAAUdMAgBswggCAATvZAIAAA5EAgASUpgCAAA9kgIAAARyAgAAbLYCAAQNjAIAAP4IA///PvIA= Date: Tue, 14 Mar 2017 12:44:32 +0000 Message-ID: References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> <1489419619.3159.25.camel@redhat.com> <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> <43102E1B-C072-4CE2-9A3E-CDEDE1536AFB@gmail.com> <0DE34F3E-A2D2-4396-B12C-D9FD30DC3723@gmail.com> In-Reply-To: <0DE34F3E-A2D2-4396-B12C-D9FD30DC3723@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.222.9] x-microsoft-exchange-diagnostics: 1; CY4PR09MB1461; 7:fM9wUIxwVsJqZRRuuVECDF8SK3s1QEpaVrdmq5CwRSmUugKX2nLbe5Yb456J3sS+KldvM2c2VUQE1h7cxK6NKWIdFNcVgeKiUhHYHB8cUvRginXfqCdW1gU5EdnLBMlhkLi4j1/Y4aSen70LX6/VaiguDKfvix/gbdkdH7KNAKFfJw6unaQ1WLyrZ5fQO2BK+dYZfyaDPt/UtzdF0T4pw8rGF+i09S0xPDhFTjrm0awaKjd/MBLIkjVSGueHdKY8Px0MEJuFrr27VRdn6xYA9/1S+T5ay8UZYL5jmcH07fJtwglDgVRItxSNrQkHgRsyzvRtLVeZQH0ZnhyQzTXSow== x-ld-processed: 2ab5d82f-d8fa-4797-a93e-054655c61dec,ExtAddr x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(39840400002)(39450400003)(39850400002)(39410400002)(24454002)(377454003)(189998001)(122556002)(39060400002)(83506001)(102836003)(6116002)(2906002)(106116001)(6512007)(54896002)(6306002)(4326008)(81166006)(93886004)(3280700002)(2900100001)(54906002)(53546007)(8936002)(8676002)(81156014)(38730400002)(68736007)(6246003)(3660700001)(66066001)(4001350100001)(7736002)(50986999)(5660300001)(3846002)(7906003)(229853002)(6506006)(86362001)(2950100002)(6436002)(77096006)(25786008)(606005)(99286003)(236005)(53936002)(36756003)(54356999)(76176999)(6486002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1461; H:CY4PR09MB1464.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; x-ms-office365-filtering-correlation-id: 269890b8-bf66-41af-f4cb-08d46ad7dceb x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR09MB1461; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(148322886591682)(65766998875637); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(20161123558025)(6072148); SRVR:CY4PR09MB1461; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1461; x-forefront-prvs: 02462830BE spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D4ED5DAD3169Dqdangnistgov_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Mar 2017 12:44:32.1235 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1461 Archived-At: Cc: Nikos Mavrogiannopoulos , "rsalz@akamai.com" , Curdle Subject: Re: [Curdle] Some work for the group X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 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, 14 Mar 2017 12:44:38 -0000 --_000_D4ED5DAD3169Dqdangnistgov_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable From: Yoav Nir > Date: Tuesday, March 14, 2017 at 7:37 AM To: 'Quynh' > Cc: Rich Salz >, Nikos Mavrogiann= opoulos >, Curdle > Subject: Re: [Curdle] Some work for the group The code that I write generally runs on devices no weaker than phones. I do= n=92t know if there are constrained devices that will need to handle CRLs. = The trend seems to be moving away from CRLs and adopting OCSP responses ins= tead. It seems odd to me to believe that embedded systems will process CRLs in a = time where web browsers running on PCs have stopped doing that. Even if the= y do, making really small CRLs for them seems like a good idea. That would be costly because they need to verify multiple signatures every = time. Quynh. But stapling OCSP responses seems like an even better idea. Yoav On 14 Mar 2017, at 13:49, Dang, Quynh (Fed) > wrote: Hi Yoav, Is it reasonable to think that there will be constrained devices which need= to handle CRL lists ? If the answer is yes, without the pre-hash option, those devices would need= to either: (1) buffer large messages (costly) or (2) verify multiple CRL l= ists every time (costly) if the CA creates multiple CRL lists every time wi= th the non-prehash option. If only one option were to be used, the pre-hash would be the best choice b= ecause it works well everywhere, not like the non-prehash one. Quynh. From: Curdle > on b= ehalf of Yoav Nir > Date: Monday, March 13, 2017 at 12:21 PM To: "rsalz@akamai.com" > Cc: Nikos Mavrogiannopoulos >, Curd= le > Subject: Re: [Curdle] Some work for the group Speaking as an implementer of a relying party, if pre-hash is a MAY for CRL= s on the CA side, it becomes a MUST on the relying party side. I MAY receiv= e a CRL signed with pre-hashed EdDSA, so I MUST implement it if I want inte= roperability. I also MUST implement the non pre-hashed EdDSA, because cert= ificates are very likely to be signed with that. So unless there=92s a very good reason to sign CRLs with the pre-hashed ver= sion, I=92d rather that it be MUST NOT for all uses. The claim has been made that future hardware (current hardware does not imp= lement EdDSA) will not be able to hold an entire CRL all at once in memory,= and therefore will need to be fed this CRL one chunk at a time, implying t= he need for a pre-hash. However, the size of CRLs is entirely determined by= CA policy. The size of a CRL is bounded by the number of certificates that= share the same CDP. A CA can set this value to any number from 1 to all th= e certificates ever issued, and it can set the value so that it fits the ha= rdware limitations without pre-hashing. I don=92t think forcing the relying parties (all several billions of them) = to implement both variations is better than forcing CAs to adjust the param= eter of ce On 13 Mar 2017, at 17:44, Salz, Rich > wrote: The pre-hash is not known to be bad, although it can be risky for some syst= ems. The goal is to not have risky things if we don't need them. So far, th= e only use-case that has had support is CRL's, which are less likely to be = risky since the same keypair generally signs certificates. In the interest = of progressing the draft, we are asking if pre-hash is a MAY for CRL's and = a SHOULD NOT or MUST NOT for all other uses. -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz@jabber.at Twitter: RichSalz _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle --_000_D4ED5DAD3169Dqdangnistgov_ Content-Type: text/html; charset="Windows-1252" Content-ID: <1EF645A72D117D4CB4B96CDECD739A65@namprd09.prod.outlook.com> Content-Transfer-Encoding: quoted-printable


From: Yoav Nir <ynir.ietf@gmail.com>
Date: Tuesday, March 14, 2017 at 7:= 37 AM
To: 'Quynh' <Quynh.Dang@nist.gov>
Cc: Rich Salz <rsalz@akamai.com>, Nikos Mavrogiannopoulos <nmav@redhat.com>, Curdle <curdle@ietf.org>
Subject: Re: [Curdle] Some work for= the group

The code that I write generally runs on devices no weaker than phones. I do= n=92t know if there are constrained devices that will need to handle CRLs. = The trend seems to be moving away from CRLs and adopting OCSP responses ins= tead.  

It seems odd to me to believe that embedded systems will pr= ocess CRLs in a time where web browsers running on PCs have stopped doing t= hat. Even if they do, making really small CRLs for them seems like a good i= dea.

That would be costly because they need to verify multiple signatures e= very time. 

Quynh. 


 But stapling OCSP responses seems like an even better= idea.

Yoav

On 14 Mar 2017, at 13:49, Dang, Quynh (Fed) <quynh.dang@nist.gov> wrote:
Hi Yoav,

Is it reasonable to think that there will be constrained de= vices which need to handle CRL lists ?

If the answer is yes, without the pre-hash option, those de= vices would need to either: (1) buffer large messages (costly) or (2) verif= y multiple CRL lists every time (costly) if the CA creates multiple CRL lis= ts every time with the non-prehash option. 

If only one option were to be used, the pre-hash would be t= he best choice because it works well everywhere, not like the non-prehash o= ne.

Quynh. 

From: Curdle <curdle-bounces@ietf.org&= gt; on behalf of Yoav Nir <ynir.ietf@gmail.com>
Date: Monday, March 13, = 2017 at 12:21 PM
To: "rsalz@akamai.com" <rsalz@akamai.com>
Cc: Nikos Mavrogiannopou= los <nmav@redhat.com&g= t;, Curdle <curdle@ietf.or= g>
Subject: Re: [Curdle] So= me work for the group

Speaking as an implementer of a relying party, if pre-hash = is a MAY for CRLs on the CA side, it becomes a MUST on the relying party si= de. I MAY receive a CRL signed with pre-hashed EdDSA, so I MUST implement i= t if I want interoperability.  I also MUST implement the non pre-hashed EdDSA, because certificates are very lik= ely to be signed with that.

So unless there=92s a very good reason to sign CRLs with th= e pre-hashed version, I=92d rather that it be MUST NOT for all uses.

The claim has been made that future hardware (current hardw= are does not implement EdDSA) will not be able to hold an entire CRL all at= once in memory, and therefore will need to be fed this CRL one chunk at a = time, implying the need for a pre-hash. However, the size of CRLs is entirely determined by CA policy. The size of= a CRL is bounded by the number of certificates that share the same CDP. A = CA can set this value to any number from 1 to all the certificates ever iss= ued, and it can set the value so that it fits the hardware limitations without pre-hashing.

I don=92t think forcing the relying parties (all several bi= llions of them) to implement both variations is better than forcing CAs to = adjust the parameter of ce

On 13 Mar 2017, at 17:44, Salz, Rich <rsalz@akamai.com> wrote:
The pre-hash is not known to be bad, although it can be ris= ky for some systems. The goal is to not have risky things if we don't need = them. So far, the only use-case that has had support is CRL's, which are le= ss likely to be risky since the same keypair generally signs certificates. In the interest of progressing the d= raft, we are asking if pre-hash is a MAY for CRL's and a SHOULD NOT or MUST= NOT for all other uses.
--
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richsa= lz@jabber.at Twitter: RichSalz
_______________________________________________
Curdle mailing list
Curdle@ietf.o= rg
https://www.ietf.org/mailman/listinfo/curdle



 --_000_D4ED5DAD3169Dqdangnistgov_-- From nobody Tue Mar 14 05:51: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 E663112952B for ; Tue, 14 Mar 2017 05:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s_ab4Del4nP6 for ; Tue, 14 Mar 2017 05:50:56 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A183F129558 for ; Tue, 14 Mar 2017 05:43:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id ED0A4BE7C; Tue, 14 Mar 2017 12:43:46 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8S5ts2hznDfG; Tue, 14 Mar 2017 12:43:40 +0000 (GMT) Received: from [10.87.48.75] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 314FFBE7B; Tue, 14 Mar 2017 12:43:40 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1489495420; bh=jqCs7uYc3rMHHfcEB7C23cVwVDQx3GRSBPFH2T8l4DU=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=i4zhwWoH1JXcS6IYVQl2l2prSapHW3oeEYZA/B/Ey7mlweieDhl35Bqd4BDfRaBFB XdOJlMiLqUws5HifHZy+AOIFRGIo82smXJyAw/5PDuvI9XQOzPzakeL+GeEhONBo+s fdMBt1wbxFNkJpkssPDZt8R4kHxAXfMFf6puboMQ= To: "Dang, Quynh (Fed)" , Yoav Nir , "rsalz@akamai.com" References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> <1489419619.3159.25.camel@redhat.com> <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> <43102E1B-C072-4CE2-9A3E-CDEDE1536AFB@gmail.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Tue, 14 Mar 2017 12:43:37 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="xmkn87t2jn9gX3DunQbl5glKjge96Cpv0" Archived-At: Cc: Nikos Mavrogiannopoulos , Curdle Subject: Re: [Curdle] Some work for the group X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 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, 14 Mar 2017 12:50:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xmkn87t2jn9gX3DunQbl5glKjge96Cpv0 Content-Type: multipart/mixed; boundary="tcxLNoFoaKgEsGi9xgNuTugAl1Q6nFl5B"; protected-headers="v1" From: Stephen Farrell To: "Dang, Quynh (Fed)" , Yoav Nir , "rsalz@akamai.com" Cc: Nikos Mavrogiannopoulos , Curdle Message-ID: Subject: Re: [Curdle] Some work for the group References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> <1489419619.3159.25.camel@redhat.com> <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> <43102E1B-C072-4CE2-9A3E-CDEDE1536AFB@gmail.com> In-Reply-To: --tcxLNoFoaKgEsGi9xgNuTugAl1Q6nFl5B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, (No hats still:-) On 14/03/17 11:49, Dang, Quynh (Fed) wrote: > Hi Yoav, >=20 > Is it reasonable to think that there will be constrained devices > which need to handle CRL lists ? One could imagine a universe in which that mattered, but it is not this universe. Memory constrained devices that need to consume giant CRLs do not seem to be real. But feel free to point me at a product data sheet if there is one. IMO real constrained devices will not be downloading giant CRLs for power and/or bandwidth reasons. (Well, and because it'd be silly;-) >=20 > If the answer is yes, without the pre-hash option, those devices > would need to either: (1) buffer large messages (costly) or (2) > verify multiple CRL lists every time (costly) if the CA creates > multiple CRL lists every time with the non-prehash option. >=20 > If only one option were to be used, the pre-hash would be the best > choice because it works well everywhere, not like the non-prehash > one. "Everywhere" there really meaning "that other universe where giant CRLs for memory constrained devices matter"? I think we can ditch or otherwise say to not use the pre-hash stuff safely. Adding it or allowing its use is less safe. (I'm not as hardline as Nikos that it ought not be defined at all, but only because if we don't define it now with a MUST NOT or SHOULD NOT, then someone will come along later and define it causing all the confusion/complexity anyway so I don't see that omitting it here gains that much, but I'd be ok with doing so.) Cheers, S. >=20 > Quynh. >=20 > From: Curdle > > on behalf > of Yoav Nir > Date: > Monday, March 13, 2017 at 12:21 PM To: > "rsalz@akamai.com" > > Cc: Nikos > Mavrogiannopoulos >, Curdle > > Subject: Re: [Curdle] Some > work for the group >=20 > Speaking as an implementer of a relying party, if pre-hash is a MAY > for CRLs on the CA side, it becomes a MUST on the relying party side. > I MAY receive a CRL signed with pre-hashed EdDSA, so I MUST implement > it if I want interoperability. I also MUST implement the non > pre-hashed EdDSA, because certificates are very likely to be signed > with that. >=20 > So unless there=E2=80=99s a very good reason to sign CRLs with the pre-= hashed > version, I=E2=80=99d rather that it be MUST NOT for all uses. >=20 > The claim has been made that future hardware (current hardware does > not implement EdDSA) will not be able to hold an entire CRL all at > once in memory, and therefore will need to be fed this CRL one chunk > at a time, implying the need for a pre-hash. However, the size of > CRLs is entirely determined by CA policy. The size of a CRL is > bounded by the number of certificates that share the same CDP. A CA > can set this value to any number from 1 to all the certificates ever > issued, and it can set the value so that it fits the hardware > limitations without pre-hashing. >=20 > I don=E2=80=99t think forcing the relying parties (all several billions= of > them) to implement both variations is better than forcing CAs to > adjust the parameter of ce >=20 > On 13 Mar 2017, at 17:44, Salz, Rich > > wrote: The pre-hash is > not known to be bad, although it can be risky for some systems. The > goal is to not have risky things if we don't need them. So far, the > only use-case that has had support is CRL's, which are less likely to > be risky since the same keypair generally signs certificates. In the > interest of progressing the draft, we are asking if pre-hash is a MAY > for CRL's and a SHOULD NOT or MUST NOT for all other uses. -- Senior > Architect, Akamai Technologies Member, OpenSSL Dev Team IM: > richsalz@jabber.at Twitter: RichSalz=20 > _______________________________________________ Curdle mailing list=20 > Curdle@ietf.org=20 > https://www.ietf.org/mailman/listinfo/curdle >=20 >=20 >=20 >=20 >=20 > _______________________________________________ Curdle mailing list=20 > Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle >=20 --tcxLNoFoaKgEsGi9xgNuTugAl1Q6nFl5B-- --xmkn87t2jn9gX3DunQbl5glKjge96Cpv0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYx+V5AAoJEC88hzaAX42ilekIAJaQXZkgabAnXXNu8sHTA6Gs bPfzbTYhMXr+ZHbGQ8w6rBMPkccWL755odU2NuLLcuF7PJpcUTGm7/YleyXDy6JG FKsYdc1QTO/aYQA6uGtfoycWp+tqhNvC+h0cUrXfQQpcYtNRadwuVAQBB9qocHQP bSN+JTaBrNaT+gtLR47YCDOjAC4qRaQw01xtR/EwyxO2kG57ASGFLLgm04NvDou+ XvnK7M8rKsxWPWE8ztRGGbN5vP6bvEL7Z8Y4xVYlirbLUIHx2PODen/g9rMzQDnG u3H2Pss4CamFfb1Ll6vJ2ctnNIdoz9OctwCLUy/AENLK8pWfr1TV99Xdz87xipA= =ISYc -----END PGP SIGNATURE----- --xmkn87t2jn9gX3DunQbl5glKjge96Cpv0-- From nobody Tue Mar 14 05:51: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 54F60128874 for ; Tue, 14 Mar 2017 05:51:55 -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 tf1GBnt-wesx for ; Tue, 14 Mar 2017 05:51:53 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 725AB127735 for ; Tue, 14 Mar 2017 05:51:53 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id t189so63057234wmt.1 for ; Tue, 14 Mar 2017 05:51:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=XFUYSWwR8ywgastZU5CPdUeYigGMwgfjn/FyCF5YJNo=; b=bSBOoXQkAqWfIXv/4pxR7yd8BA8+zSPUTW7MIByu54L+HK6+Uugj6r6wE6WcFhyjq4 hE6TAk2s993/JDwx4mhWmqoZjG83/gMa8q5bz4E8YP+8TJNiAi1FeMTldFzFQELNCIJC v3TeXTVA/zSOMdrMQFHBvyPJk3cyvnx+9PJSiSIThkGYRMxjAN3nlsR7nhGv+ZEWaKVB 9roF134+NcioFczZkRnhySYvuG6+5eIfa4HMLtFCNw2eu+ptTnepfVQrP7Qvw4UgJle0 aXFmGA+QfZBqqyXh9Srkh7dRlQVPVorfjIKzoCpG4z4/qpZoq1RtyvdqmwNVJ/cwHfWW /9Zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=XFUYSWwR8ywgastZU5CPdUeYigGMwgfjn/FyCF5YJNo=; b=M+9W51VgDGAloSKshPbrX2hkdsobaKVFeDFWdFgxAvBFGBlPEDMOzn1CjGK1IP6bvA WX9KcSSQ3uKaiEAzDQeabpRsYuKPp9M/YgrzS/HOIqg5xTuxHmj6cRpK15uJ1cKe3PBx /vbXp99TGkXsif2AcPK289OyMvqNGWwL2CjKLR+YkZLIBCD1BMGcAWxOsLVbPBu050Uh sEeHhb8elK8koJgk1A+9K3F2I6oP3X4pj6CxtCf9z6bhLV3rjoY2TeWbFFaIdbNZMkim uas6bf8EWtAobW2XvFWdN6une8oZ/I7MX+ZHf9yA92z/GP0Jy6YjdC6TLcNWFnbMOGR4 TWfA== X-Gm-Message-State: AFeK/H3fV+C7sBanbY2X9137aLUABn4V5w7HGBGoGN4WvEKOwEC8Sofysakk29v3Ww+GFg== X-Received: by 10.28.54.89 with SMTP id d86mr14242598wma.137.1489495911991; Tue, 14 Mar 2017 05:51:51 -0700 (PDT) Received: from [172.24.251.163] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id o15sm28969418wra.61.2017.03.14.05.51.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Mar 2017 05:51:51 -0700 (PDT) From: Yoav Nir Message-Id: <77E2E1CD-6397-4646-A8C7-6ABFD976B1DA@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_F02B7578-5255-4AC8-83BE-93B2C7A01172"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Tue, 14 Mar 2017 14:51:47 +0200 In-Reply-To: To: "Dang, Quynh (Fed)" References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> <1489419619.3159.25.camel@redhat.com> <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> <43102E1B-C072-4CE2-9A3E-CDEDE1536AFB@gmail.com> <0DE34F3E-A2D2-4396-B12C-D9FD30DC3723@gmail.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Nikos Mavrogiannopoulos , Rich Salz , Curdle Subject: Re: [Curdle] Some work for the group X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 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, 14 Mar 2017 12:51:55 -0000 --Apple-Mail=_F02B7578-5255-4AC8-83BE-93B2C7A01172 Content-Type: multipart/alternative; boundary="Apple-Mail=_C6C20764-95D1-43C1-A153-6B540E650B3C" --Apple-Mail=_C6C20764-95D1-43C1-A153-6B540E650B3C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 14 Mar 2017, at 14:44, Dang, Quynh (Fed) = wrote: >=20 >=20 >=20 > From: Yoav Nir > > Date: Tuesday, March 14, 2017 at 7:37 AM > To: 'Quynh' > > Cc: Rich Salz >, Nikos = Mavrogiannopoulos >, Curdle = > > Subject: Re: [Curdle] Some work for the group >=20 >> The code that I write generally runs on devices no weaker than = phones. I don=E2=80=99t know if there are constrained devices that will = need to handle CRLs. The trend seems to be moving away from CRLs and = adopting OCSP responses instead. >>=20 >> It seems odd to me to believe that embedded systems will process CRLs = in a time where web browsers running on PCs have stopped doing that. = Even if they do, making really small CRLs for them seems like a good = idea. >=20 >=20 > That would be costly because they need to verify multiple signatures = every time. Why? I don=E2=80=99t know much about embedded devices but I do know = that they almost always connect to the same server (often a cloud-based = mothership) all the time. These are not browsers. Yoav --Apple-Mail=_C6C20764-95D1-43C1-A153-6B540E650B3C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 14 Mar 2017, at 14:44, Dang, Quynh (Fed) <quynh.dang@nist.gov>= wrote:



From: Yoav Nir <ynir.ietf@gmail.com>
Date: Tuesday, March = 14, 2017 at 7:37 AM
To: 'Quynh' <Quynh.Dang@nist.gov>
Cc: Rich Salz <rsalz@akamai.com>, = Nikos Mavrogiannopoulos <nmav@redhat.com>, Curdle <curdle@ietf.org>
Subject: Re: [Curdle] = Some work for the group

The code that I write generally runs on devices no weaker than phones. I = don=E2=80=99t know if there are constrained devices that will need to = handle CRLs. The trend seems to be moving away from CRLs and adopting = OCSP responses instead.  

It seems odd to me to believe that embedded systems will = process CRLs in a time where web browsers running on PCs have stopped = doing that. Even if they do, making really small CRLs for them seems = like a good idea.

That would be costly because they need to verify = multiple signatures every = time. 

Why?  I don=E2=80=99t know much about embedded devices = but I do know that they almost always connect to the same server (often = a cloud-based mothership) all the time.  These are not = browsers.

Yoav

= --Apple-Mail=_C6C20764-95D1-43C1-A153-6B540E650B3C-- --Apple-Mail=_F02B7578-5255-4AC8-83BE-93B2C7A01172 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJYx+dkAAoJELhJCxUKWMyZGGoH/1cMO8qwI4KSrq6yR+0Ibnry bht4aJDkmpK2W2K4HVV8s7FyupviOrr+OLq2a8VMAyP0iA/xbTktujOM2fevybH2 sZBBH/+a7OAVpRX86Ga1gLWj06U+iPglh1L7TZaXfz+6jLJu9Zotb0TW0z0AkHkj VDZJYlir6CDWt/kCINee6HR9EWPWEe/fZhfKdObRe6bSpKC0OBvJ0NW2tVic45jp aaKuFGnR8T1eGSfYzHaL1Q2EXV2U3WJt/JmccU1Ew27Il/bEOiFEm+C3Cv0QVkCS /iXsbP7/2QyJGXp9v9+GftFoG2UxahQL1u3XQ7dKvrjTRMjvtLuz1NAMozs+JKQ= =/Y27 -----END PGP SIGNATURE----- --Apple-Mail=_F02B7578-5255-4AC8-83BE-93B2C7A01172-- From nobody Tue Mar 14 06:18:38 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 E90D2129500 for ; Tue, 14 Mar 2017 06:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=nistgov.onmicrosoft.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 9aDv-vA8k9KF for ; Tue, 14 Mar 2017 06:18:32 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0139.outbound.protection.outlook.com [23.103.200.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 B57EB129498 for ; Tue, 14 Mar 2017 06:18:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Myr062GiYFv7smp2ozsBWyREIUfUO+C3hWkMQWXj7Lw=; b=YQhWVtYaUVThSSlPEvDaTYiDDVAVQQ7JPbm9m4mZjD6XGbdmdzVT/cR343eidM8kHNdAPf5bhL9i/M6X4bhamTEVWlMBwSZLQLXjOvGROZLbqmBrGSv4Zq17MKI8JQNx2DDCEltpL52Gok5lnBNtnsyvK/TCRm8+YSvBv4KUElY= Received: from CY4PR09MB1464.namprd09.prod.outlook.com (10.173.191.22) by CY4PR09MB1461.namprd09.prod.outlook.com (10.173.191.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.17; Tue, 14 Mar 2017 13:18:30 +0000 Received: from CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) by CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) with mapi id 15.01.0961.020; Tue, 14 Mar 2017 13:18:30 +0000 From: "Dang, Quynh (Fed)" To: Stephen Farrell , "Dang, Quynh (Fed)" , Yoav Nir , "rsalz@akamai.com" Thread-Topic: [Curdle] Some work for the group Thread-Index: AQHSUiKs3PWVL7wFScuPYdGzcgHHmKD/tuoAgAUxWICAA8bVAIAAjpmAgDQrVACAEdcRAIAAUaIAgAeCl4CAGwHggIAAUdMAgBswggCAATvZAIAAA5EAgASUpgCAAA9kgIAAARyAgAAbLYCAAQNjAIAAQUqA///XcYA= Date: Tue, 14 Mar 2017 13:18:29 +0000 Message-ID: References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> <1489419619.3159.25.camel@redhat.com> <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> <43102E1B-C072-4CE2-9A3E-CDEDE1536AFB@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 authentication-results: cs.tcd.ie; dkim=none (message not signed) header.d=none;cs.tcd.ie; dmarc=none action=none header.from=nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.222.9] x-microsoft-exchange-diagnostics: 1; CY4PR09MB1461; 7:gMOSovb4a7WGN+y9Wt7BKISODXSXEv/NpAeBXaXsi2stOfqIjsuh74OnUxs6DV79a8UFDjN7YpSncKq/Z9zDxUICOYDaLYb6jbfeyhC9eLKTThkALMlgcEeLGjXeLpMqESf+EtbUtXeqivAqjTKg29T9UtzIwW4xQZ3/QkQgkGyuwaj7L7bYPWMrH56x7WOE0Ne41YA9lo27dQ+gV7KsMADs8Uvc6zbTRXKs5bfb/a12mv7hDM20zcx4nOFTP5ZXMQlVyxA9OGLdYxq6qUdKIQSwBHh+XJnCCPkJsQxvm/fWmFhAnwi2bRUOM2Yp4TcGhPDmaH5ObYS2efdc+mIqYQ== x-ld-processed: 2ab5d82f-d8fa-4797-a93e-054655c61dec,ExtAddr x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(39410400002)(39450400003)(39860400002)(39840400002)(39850400002)(377454003)(24454002)(2950100002)(6436002)(25786008)(86362001)(606005)(77096006)(50986999)(7736002)(229853002)(7906003)(6506006)(3846002)(5660300001)(53936002)(36756003)(76176999)(6486002)(54356999)(2501003)(99286003)(236005)(54896002)(6512007)(106116001)(6306002)(39060400002)(83506001)(102836003)(189998001)(122556002)(2906002)(6116002)(6246003)(81156014)(38730400002)(68736007)(4001350100001)(66066001)(3660700001)(3280700002)(2900100001)(4326008)(81166006)(93886004)(54906002)(8676002)(8936002)(53546007); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1461; H:CY4PR09MB1464.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; x-ms-office365-filtering-correlation-id: a79edd53-fe68-4aae-1529-08d46adc9bad x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR09MB1461; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(32856632585715)(148322886591682)(65766998875637)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(20161123558025)(6072148); SRVR:CY4PR09MB1461; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1461; x-forefront-prvs: 02462830BE spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D4ED61C5316A7qdangnistgov_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Mar 2017 13:18:29.9810 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1461 Archived-At: Cc: Nikos Mavrogiannopoulos , Curdle Subject: Re: [Curdle] Some work for the group X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 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, 14 Mar 2017 13:18:37 -0000 --_000_D4ED61C5316A7qdangnistgov_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Stephen, Your point is very perfect to me! We, the IETF, are a very important international standard body and our stan= dards and recommendations have tremendous impact on improving security and = services that the internet provides. I would like our products to continue to provide great solutions to as many= users as possible. At least, when signing large files, the pre-hash work= s better than the non-prehash. And, the hash-then-sign scheme has worked we= ll since the digital signature was invented when the hash function is secur= e. Regards, Quynh. From: Stephen Farrell > Date: Tuesday, March 14, 2017 at 7:43 AM To: 'Quynh' >, Yoav Nir >, "rsalz@akamai.com" > Cc: Nikos Mavrogiannopoulos >, Curd= le > Subject: Re: [Curdle] Some work for the group Hiya, (No hats still:-) On 14/03/17 11:49, Dang, Quynh (Fed) wrote: Hi Yoav, Is it reasonable to think that there will be constrained devices which need to handle CRL lists ? One could imagine a universe in which that mattered, but it is not this universe. Memory constrained devices that need to consume giant CRLs do not seem to be real. But feel free to point me at a product data sheet if there is one. IMO real constrained devices will not be downloading giant CRLs for power and/or bandwidth reasons. (Well, and because it'd be silly;-) If the answer is yes, without the pre-hash option, those devices would need to either: (1) buffer large messages (costly) or (2) verify multiple CRL lists every time (costly) if the CA creates multiple CRL lists every time with the non-prehash option. If only one option were to be used, the pre-hash would be the best choice because it works well everywhere, not like the non-prehash one. "Everywhere" there really meaning "that other universe where giant CRLs for memory constrained devices matter"? I think we can ditch or otherwise say to not use the pre-hash stuff safely. Adding it or allowing its use is less safe. (I'm not as hardline as Nikos that it ought not be defined at all, but only because if we don't define it now with a MUST NOT or SHOULD NOT, then someone will come along later and define it causing all the confusion/complexity anyway so I don't see that omitting it here gains that much, but I'd be ok with doing so.) Cheers, S. Quynh. From: Curdle > on behalf of Yoav Nir > Date: Monday, March 13, 2017 at 12:21 PM To: "rsalz@akamai.com" > Cc: Ni= kos Mavrogiannopoulos >, Curdle > Subject: = Re: [Curdle] Some work for the group Speaking as an implementer of a relying party, if pre-hash is a MAY for CRLs on the CA side, it becomes a MUST on the relying party side. I MAY receive a CRL signed with pre-hashed EdDSA, so I MUST implement it if I want interoperability. I also MUST implement the non pre-hashed EdDSA, because certificates are very likely to be signed with that. So unless there=92s a very good reason to sign CRLs with the pre-hashed version, I=92d rather that it be MUST NOT for all uses. The claim has been made that future hardware (current hardware does not implement EdDSA) will not be able to hold an entire CRL all at once in memory, and therefore will need to be fed this CRL one chunk at a time, implying the need for a pre-hash. However, the size of CRLs is entirely determined by CA policy. The size of a CRL is bounded by the number of certificates that share the same CDP. A CA can set this value to any number from 1 to all the certificates ever issued, and it can set the value so that it fits the hardware limitations without pre-hashing. I don=92t think forcing the relying parties (all several billions of them) to implement both variations is better than forcing CAs to adjust the parameter of ce On 13 Mar 2017, at 17:44, Salz, Rich > wrote:= The pre-hash is not known to be bad, although it can be risky for some systems. The goal is to not have risky things if we don't need them. So far, the only use-case that has had support is CRL's, which are less likely to be risky since the same keypair generally signs certificates. In the interest of progressing the draft, we are asking if pre-hash is a MAY for CRL's and a SHOULD NOT or MUST NOT for all other uses. -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz@jabber.at Tw= itter: RichSalz _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listin= fo/curdle --_000_D4ED61C5316A7qdangnistgov_ Content-Type: text/html; charset="Windows-1252" Content-ID: <9F1F815CF1D07342B161EE264AD121F2@namprd09.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Stephen,

Your point is very perfect to me!

We, the IETF, are a very important international standard body and our= standards and recommendations have tremendous impact on improving security= and services that the internet provides.

I would like our products to continue to provide great solutions to as= many users as possible.   At least, when signing large files, the pre= -hash works better than the non-prehash. And, the hash-then-sign scheme has= worked well since the digital signature was invented when the hash function is secure.  

Regards,
Quynh. 

From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Date: Tuesday, March 14, 2017 at 7:= 43 AM
To: 'Quynh' <Quynh.Dang@nist.gov>, Yoav Nir <ynir.ietf@gmail.com>, "rsalz@akamai.com" <rsalz@akamai.com>
Cc: Nikos Mavrogiannopoulos <nmav@redhat.com>, Curdle <curdle@ietf.org>
Subject: Re: [Curdle] Some work for= the group


Hiya,

(No hats still:-)

On 14/03/17 11:49, Dang, Quynh (Fed) wrote:
Hi Yoav,
Is it reasonable to think that there will be constrained devices
which need to handle CRL lists ?

One could imagine a universe in which that mattered, but it
is not this universe. Memory constrained devices that need to
consume giant CRLs do not seem to be real. But feel free
to point me at a product data sheet if there is one.

IMO real constrained devices will not be downloading giant
CRLs for power and/or bandwidth reasons. (Well, and because
it'd be silly;-)

If the answer is yes, without the pre-hash option, those devices
would need to either: (1) buffer large messages (costly) or (2)
verify multiple CRL lists every time (costly) if the CA creates
multiple CRL lists every time with the non-prehash option.
If only one option were to be used, the pre-hash would be the best
choice because it works well everywhere, not like the non-prehash
one.

"Everywhere" there really meaning "that other universe = where
giant CRLs for memory constrained devices matter"?

I think we can ditch or otherwise say to not use the pre-hash
stuff safely. Adding it or allowing its use is less safe.

(I'm not as hardline as Nikos that it ought not be defined at
all, but only because if we don't define it now with a MUST
NOT or SHOULD NOT, then someone will come along later and
define it causing all the confusion/complexity anyway so I
don't see that omitting it here gains that much, but I'd be
ok with doing so.)

Cheers,
S.

Quynh.
From: Curdle
Monday, March 13, 2017 at 12:21 PM To:
"rsalz@akamai.com<mailto:rsalz@akamai.com>"
Mavrogiannopoulos <nmav@redhat.c= om<mailto:nmav@redhat.com>= >, Curdle
<curdle@ietf.org<mailto:curdle@ietf.org>> Subject:= Re: [Curdle] Some
work for the group
Speaking as an implementer of a relying party, if pre-hash is a MAY
for CRLs on the CA side, it becomes a MUST on the relying party side.<= /div>
I MAY receive a CRL signed with pre-hashed EdDSA, so I MUST implement<= /div>
it if I want interoperability.  I also MUST implement the no= n
pre-hashed EdDSA, because certificates are very likely to be signed
with that.
So unless there=92s a very good reason to sign CRLs with the pre-hashe= d
version, I=92d rather that it be MUST NOT for all uses.
The claim has been made that future hardware (current hardware does
not implement EdDSA) will not be able to hold an entire CRL all at
once in memory, and therefore will need to be fed this CRL one chunk
at a time, implying the need for a pre-hash. However, the size of
CRLs is entirely determined by CA policy. The size of a CRL is
bounded by the number of certificates that share the same CDP. A CA
can set this value to any number from 1 to all the certificates ever
issued, and it can set the value so that it fits the hardware
limitations without pre-hashing.
I don=92t think forcing the relying parties (all several billions of
them) to implement both variations is better than forcing CAs to
adjust the parameter of ce
On 13 Mar 2017, at 17:44, Salz, Rich
<rsalz@akamai.com<mailto:rsalz@akamai.com>> wrote= : The pre-hash is
not known to be bad, although it can be risky for some systems. The
goal is to not have risky things if we don't need them. So far, the
only use-case that has had support is CRL's, which are less likely to<= /div>
be risky since the same keypair generally signs certificates. In the
interest of progressing the draft, we are asking if pre-hash is a MAY<= /div>
for CRL's and a SHOULD NOT or MUST NOT for all other uses. -- Senior
Architect, Akamai Technologies Member, OpenSSL Dev Team IM:
_______________________________________________ Curdle mailing list
_______________________________________________ Curdle mailing list


--_000_D4ED61C5316A7qdangnistgov_-- From nobody Tue Mar 14 08:05:11 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 C784D129654 for ; Tue, 14 Mar 2017 08:05:09 -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 9zsl9DrWBZ-V for ; Tue, 14 Mar 2017 08:05:08 -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 B3E0312965A for ; Tue, 14 Mar 2017 08:05:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id D664830048E for ; Tue, 14 Mar 2017 11:05:02 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id KmiNguI9VWiz for ; Tue, 14 Mar 2017 11:05:01 -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 A1631300267; Tue, 14 Mar 2017 11:05:01 -0400 (EDT) From: Russ Housley Message-Id: <2E96A8A2-923A-4597-A175-2581966C0F1E@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_91A8377B-5B91-4B0B-8D8D-2FD5344C0F60" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Tue, 14 Mar 2017 11:05:04 -0400 In-Reply-To: Cc: Curdle To: Quynh Dang References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> <1489419619.3159.25.camel@redhat.com> <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> <43102E1B-C072-4CE2-9A3E-CDEDE1536AFB@gmail.com> <0DE34F3E-A2D2-4396-B12C-D9FD30DC3723@gmail.com> X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Curdle] Some work for the group X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.21 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, 14 Mar 2017 15:05:10 -0000 --Apple-Mail=_91A8377B-5B91-4B0B-8D8D-2FD5344C0F60 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Mar 14, 2017, at 8:44 AM, Dang, Quynh (Fed) = wrote: >=20 >> Even if they do, making really small CRLs for them seems like a good = idea. >=20 >=20 > That would be costly because they need to verify multiple signatures = every time.=20 Quynh: That is not correct. The CRL Distribution Point (CRLDP) extension in a = certificate identifies the (small) CRL that will include the certificate = if it is ever revoked. The replying party only needs to check the = identified CRL. See Section 4.2.1.13 of RFC 5280 if you want details. Russ --Apple-Mail=_91A8377B-5B91-4B0B-8D8D-2FD5344C0F60 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Mar 14, 2017, at 8:44 AM, Dang, Quynh (Fed) <quynh.dang@nist.gov>= wrote:

Even if they do, = making really small CRLs for them seems like a good = idea.

That would be costly because = they need to verify multiple signatures every = time. 

Quynh:

That is not correct.  The CRL Distribution Point (CRLDP) = extension in a certificate identifies the (small) CRL that will include = the certificate if it is ever revoked.  The replying party only = needs to check the identified CRL.  See Section 4.2.1.13 of = RFC 5280 if you want details.

Russ

= --Apple-Mail=_91A8377B-5B91-4B0B-8D8D-2FD5344C0F60-- From nobody Tue Mar 14 10:04: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 627E9132989 for ; Tue, 14 Mar 2017 10:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=nistgov.onmicrosoft.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 LQx4fxMWXb6e for ; Tue, 14 Mar 2017 10:04:46 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0095.outbound.protection.outlook.com [23.103.201.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FA76132979 for ; Tue, 14 Mar 2017 10:04:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2gu6qY0+Gq6l2xftMYv3BHIL13ECJ5EbgUOG60pjYdA=; b=wDzI/wpd9FflN/zqymnnzltOsAHD2DcAMyQ4F0JNbhHw/k+zOr/EjTkrMtWV1Oo6gpHJBRDKCRiL3Ny6TR++s1xaax5UWTu3ooZr1hiSpD8i4Asi7OzoFQjEcybckhUn8rtJvacPGAq5Zs6hGGFWeT87iwTn1y0wvNrCPn3txBA= Received: from CY4PR09MB1464.namprd09.prod.outlook.com (10.173.191.22) by CY4PR09MB1462.namprd09.prod.outlook.com (10.173.191.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.11; Tue, 14 Mar 2017 17:04:44 +0000 Received: from CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) by CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) with mapi id 15.01.0961.020; Tue, 14 Mar 2017 17:04:44 +0000 From: "Dang, Quynh (Fed)" To: Russ Housley , "Dang, Quynh (Fed)" CC: Curdle Thread-Topic: [Curdle] Some work for the group Thread-Index: AQHSUiKs3PWVL7wFScuPYdGzcgHHmKD/tuoAgAUxWICAA8bVAIAAjpmAgDQrVACAEdcRAIAAUaIAgAeCl4CAGwHggIAAUdMAgBswggCAATvZAIAAA5EAgASUpgCAAA9kgIAAARyAgAAbLYCAAQNjAIAAP4IA///PvICAAFmRAP//7yGA Date: Tue, 14 Mar 2017 17:04:44 +0000 Message-ID: References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> <1489419619.3159.25.camel@redhat.com> <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> <43102E1B-C072-4CE2-9A3E-CDEDE1536AFB@gmail.com> <0DE34F3E-A2D2-4396-B12C-D9FD30DC3723@gmail.com> <2E96A8A2-923A-4597-A175-2581966C0F1E@vigilsec.com> In-Reply-To: <2E96A8A2-923A-4597-A175-2581966C0F1E@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 authentication-results: vigilsec.com; dkim=none (message not signed) header.d=none;vigilsec.com; dmarc=none action=none header.from=nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.222.9] x-microsoft-exchange-diagnostics: 1; CY4PR09MB1462; 7:YrFUhEWtCgjdXf5IJggfE62fkUBRUbiqmKS6fDq+gtAsFPJ9Hh+LIK+YQdCiT2u/+KeIiFPOcIInLwg1xkVHrfWLuaAuLttqG60duJqf4kncEQ9sAlJvFXsY9zB/5q6YTplX6JrRIdZgyS1d8Dd4sHwDvahmtNaAtFOEFbNJgKJ2+4dxLxyNS7HvQ+lc+sXu4BxKTmkG7o0PBvBAxvx2SeESJuPvC2WM0MsfitVDQVadAPm2NB/FxABSWuqsuo243HmaM1vbb8bg/xcxFwDrKdA2SR9PHQ5iqYVjBlJ1QL8eA64iB/IhxuMoalIeRDXA7ipe2rmUWEZRZMEnL0hNUA== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(39850400002)(39450400003)(39410400002)(39840400002)(24454002)(377454003)(38730400002)(6246003)(8936002)(81166006)(50986999)(4326008)(7736002)(66066001)(2900100001)(8676002)(53546007)(36756003)(106116001)(93886004)(122556002)(54356999)(76176999)(2906002)(3660700001)(6512007)(3280700002)(54896002)(4001350100001)(99286003)(6436002)(25786008)(53936002)(236005)(83506001)(229853002)(189998001)(6506006)(6486002)(77096006)(5660300001)(2950100002)(102836003)(86362001)(6116002)(3846002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1462; H:CY4PR09MB1464.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-ms-office365-filtering-correlation-id: f0c2bb5c-d511-4162-6258-08d46afc3661 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR09MB1462; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123558025)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(6072148); SRVR:CY4PR09MB1462; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1462; x-forefront-prvs: 02462830BE spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D4ED97B4316E9qdangnistgov_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Mar 2017 17:04:44.1065 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1462 Archived-At: Subject: Re: [Curdle] Some work for the group X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.21 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, 14 Mar 2017 17:04:48 -0000 --_000_D4ED97B4316E9qdangnistgov_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Russ, From: Russ Housley > Date: Tuesday, March 14, 2017 at 10:05 AM To: 'Quynh' > Cc: Curdle > Subject: Re: [Curdle] Some work for the group On Mar 14, 2017, at 8:44 AM, Dang, Quynh (Fed) > wrote: Even if they do, making really small CRLs for them seems like a good idea. That would be costly because they need to verify multiple signatures every = time. Quynh: That is not correct. The CRL Distribution Point (CRLDP) extension in a cer= tificate identifies the (small) CRL that will include the certificate if it= is ever revoked. The replying party only needs to check the identified CR= L. See Section 4.2.1.13 of RFC 5280 if you want details. Right. So, the CA now needs to manage a growing number of distribution poin= ts for their certificates. I don=92t see why the CA likes to do that to avo= id a hash off-line. Quynh. Russ --_000_D4ED97B4316E9qdangnistgov_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Russ, 

From: Russ Housley <housley@vigilsec.com>
Date: Tuesday, March 14, 2017 at 10= :05 AM
To: 'Quynh' <Quynh.Dang@nist.gov>
Cc: Curdle <curdle@ietf.org>
Subject: Re: [Curdle] Some work for= the group


On Mar 14, 2017, at 8:44 AM, Dang, Quynh (Fed) <quynh.dang@nist.gov> wrot= e:

Even if they do, making really small CRLs for them seems li= ke a good idea.

That would be costly because they need to verify multiple signatures every = time. 

Quynh:

That is not correct.  The CRL Distribution Point (CRLD= P) extension in a certificate identifies the (small) CRL that will include = the certificate if it is ever revoked.  The replying party only needs = to check the identified CRL.  See Section 4.2.1.13 of RFC 5280 if you want details.

Right. So, the CA now needs to manage a growing number of distribution= points for their certificates. I don=92t see why the CA likes to do that t= o avoid a hash off-line. 

Quynh. 



Russ

 --_000_D4ED97B4316E9qdangnistgov_-- From nobody Tue Mar 14 10:11: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 671201329B7 for ; Tue, 14 Mar 2017 10:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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, RP_MATCHES_RCVD=-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=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 xdj4Gtj60KFx for ; Tue, 14 Mar 2017 10:10:59 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 54B7F1329B6 for ; Tue, 14 Mar 2017 10:10:59 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 515F7433441; Tue, 14 Mar 2017 17:10:58 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 3876A433417; Tue, 14 Mar 2017 17:10:58 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1489511458; bh=iLkphT+4MFrEaMDYtpa/h9ezKjpOhC1WjDyCHMqxYSk=; l=312; h=From:To:CC:Date:References:In-Reply-To:From; b=G3WV+r9aepyVIxw8ZCJ60HWZUe48l0P0SbjzZYqGETnMcQfUqCd0XUzirDIEcdMIk xtWowgqPMOwtA+rfntW04n1WlmLl4FdE3MhwxAsyxZVpoDXLS9vC25mx7pOgrYS/FH zFSp3AchhnHJazx9Crs/eS0GGfeVkkkMOTla5yxU= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 364AA1FC88; Tue, 14 Mar 2017 17:10:58 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 14 Mar 2017 10:10:57 -0700 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.1178.000; Tue, 14 Mar 2017 13:10:57 -0400 From: "Salz, Rich" To: "Dang, Quynh (Fed)" , Russ Housley CC: Curdle Thread-Topic: [Curdle] Some work for the group Thread-Index: AQHScQapPZALJc3H1k6dKeAsT1IqsaFPVh8AgABRoQCAB4KXgIAbEqWAgABR0gCAGx+/AIABO9kAgAADkQCABIPiAIAAD2SA//+9XyCAAF7qgIABNbGAgAANNACAAAIKAIAAJ0QAgAAhbwD//75lgA== Date: Tue, 14 Mar 2017 17:10:57 +0000 Message-ID: <613a973ed0e347a1bcaed5082b7731ae@usma1ex-dag1mb1.msg.corp.akamai.com> References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> <1489419619.3159.25.camel@redhat.com> <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> <43102E1B-C072-4CE2-9A3E-CDEDE1536AFB@gmail.com> <0DE34F3E-A2D2-4396-B12C-D9FD30DC3723@gmail.com> <2E96A8A2-923A-4597-A175-2581966C0F1E@vigilsec.com> 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.35.10] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Curdle] Some work for the group X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.21 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, 14 Mar 2017 17:11:00 -0000 > Right. So, the CA now needs to manage a growing number of distribution po= ints for their certificates. I don=92t see why the CA likes to do that to a= void a hash off-line.=A0 They can be defined algorithmically, such as {fixedurl}/cert-serial-number = Or perhaps truncated part of the serial number. From nobody Tue Mar 14 10:11:36 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 5CFFC129505 for ; Tue, 14 Mar 2017 10:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=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 v1H1Geu4Eeq6 for ; Tue, 14 Mar 2017 10:11:32 -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 B287513298E for ; Tue, 14 Mar 2017 10:04:09 -0700 (PDT) X-AuditID: c6180641-c3fff70000000a06-22-58c7dc30cba9 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by (Symantec Mail Security) with SMTP id 4A.5C.02566.03CD7C85; Tue, 14 Mar 2017 13:04:02 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0319.002; Tue, 14 Mar 2017 13:04:06 -0400 From: Daniel Migault To: str4d , "curdle@ietf.org" , "Russ Housley" , Daniel Kahn Gillmor , Peter Gutmann Thread-Topic: [Curdle] AlgorithmIdentifier parameters in draft-ietf-curdle-pkix-03 Thread-Index: AQHSmjoNZQEwZli+4U29roY+QitXtKGUhdiA Date: Tue, 14 Mar 2017 17:04:05 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118BA5C93@eusaamb107.ericsson.se> References: <7d6cfe29-8d4c-436e-fe8a-0cbee915b29e@mail.i2p> <20170311061838.879BAADF28@smtp.postman.i2p> In-Reply-To: <20170311061838.879BAADF28@smtp.postman.i2p> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyuXSPn67RneMRBi+n6FtsXTiL2aK1+zOT xasXN9ktXr57zmrRcOkGmwOrx8XGA0weZ7vbWT3OfWlj9Viy5CeTx6o7X1gDWKO4bFJSczLL Uov07RK4MqYf/sJa8E6u4u7i+AbGDrkuRk4OCQETiU97FzN1MXJxCAmsZ5R4eegeK4SznFFi /cf7rCBVbAJGEm2H+tlBEiICRxklnsx5zNjFyMEhLBAscf2QH0iNiECIxLI3S9ggbCOJCyuX gfWyCKhK3Hu3kh2knFfAV+LrRBOQsJBAlsTL0+fBwpwClhJ9W+RBwowCYhLfT61hArGZBcQl bj2ZzwRxp4DEkj3nmSFsUYmXj/+xQthKEnNeX2MGGcMsoCmxfpc+RKuixJTuh+wgNq+AoMTJ mU9YJjCKzEIydRZCxywkHbOQdCxgZFnFyFFaXJCTm25kuIkRGCnHJNgcdzDu7fU8xCjAwajE w2tw9niEEGtiWXFl7iFGCQ5mJRFefqkTEUK8KYmVValF+fFFpTmpxYcYpTlYlMR5r4fcDxcS SE8sSc1OTS1ILYLJMnFwSjUwZsfVf6us7St6MY+fb9eVd59uLvv4e0VBsf+MRsnj0TvuB0VM m1JnkznFTNNgfYtUQkhx4sbk5umdf6YVzVywbO66LL5dkSsPnl68OVRhU2qbkJtszDSzA97W vUVlIs21/z/MYvHvNmtmC/KYnRbY2848n3NC/OalX8Qvy1tba3LJPBOXLbqtxFKckWioxVxU nAgASgLP5pACAAA= Archived-At: Subject: Re: [Curdle] AlgorithmIdentifier parameters in draft-ietf-curdle-pkix-03 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.21 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, 14 Mar 2017 17:11:33 -0000 SGksIA0KDQpXZSBuZWVkIHRvIHNvcnQgdGhpcyBvdXQuIEFueW9uZSBmcm9tIE9yYWNsZSBjYW4g cHJvdmlkZSBmZWVkYmFja3MgPyANCg0KUGxlYXNlIGxldCB1cyBrbm93IGlmIHRoZXJlIGlzIGFu eSBjb25zZW5zdXMgb24gcmVsYXhpbmcgdGhlIE1VU1QgTk9UIGFjY2VwdCBwYXJhbWV0ZXJzIGV2 ZW4gTlVMTCA/DQoNCllvdXJzLCANCkRhbmllbA0KIA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogQ3VyZGxlIFttYWlsdG86Y3VyZGxlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBzdHI0ZA0KU2VudDogU2F0dXJkYXksIE1hcmNoIDExLCAyMDE3IDE6MTkgQU0NClRv OiBjdXJkbGVAaWV0Zi5vcmc7IFJ1c3MgSG91c2xleSA8aG91c2xleUB2aWdpbHNlYy5jb20+OyBE YW5pZWwgS2FobiBHaWxsbW9yIDxka2dAZmlmdGhob3JzZW1hbi5uZXQ+OyBQZXRlciBHdXRtYW5u IDxwZ3V0MDAxQGNzLmF1Y2tsYW5kLmFjLm56Pg0KU3ViamVjdDogUmU6IFtDdXJkbGVdIEFsZ29y aXRobUlkZW50aWZpZXIgcGFyYW1ldGVycyBpbiBkcmFmdC1pZXRmLWN1cmRsZS1wa2l4LTAzDQoN Ck9uIDAyLzE5LzIwMTcgMDI6MTQgQU0sIHN0cjRkIHdyb3RlOg0KPiBIaSBhbGwsDQo+IA0KPiBJ biBkcmFmdC1pZXRmLWN1cmRsZS1wa2l4LTAzIHRoZXJlIGlzIHZlcnkgY2xlYXIgbGFuZ3VhZ2Ug YXJvdW5kIHRoZSANCj4gZXhwZWN0ZWQgYmVoYXZpb3VyIG9mIHBhcnNlciBpbXBsZW1lbnRhdGlv bnMgcmVnYXJkaW5nIA0KPiBBbGdvcml0aG1JZGVudGlmaWVyIHBhcmFtZXRlcnM6DQo+IA0KDQpb c25pcF0NCg0KPiBUaGUgcHJvYmxlbSBpcyB0aGF0IHRoZSBTdW4gQWxnb3JpdGhtSWQgY2xhc3Mg YWx3YXlzIGFkZHMgYSBOVUxMIHdoZW4gDQo+IGVuY29kaW5nIGlmIHRoZXJlIGFyZSBubyBwYXJh bWV0ZXJzLCBmb3IgY29tcGF0aWJpbGl0eSB3aXRoIFNvbGFyaXMgWzRdLg0KPiBTbyBBRkFJQ1Qg aXQgaXMgcHJlc2VudGx5IGltcG9zc2libGUgZm9yIG1lIHRvIHdyaXRlIGFuIGltcGxlbWVudGF0 aW9uIA0KPiB0aGF0IHNpbXVsdGFuZW91c2x5Og0KPiANCj4gLSBmb2xsb3dzIGRyYWZ0LWlldGYt Y3VyZGxlLXBraXgtMDMgY29ycmVjdGx5DQo+IC0gY2FuIHJldHJpZXZlIEVkRFNBIGtleXMgZnJv bSBhIGRlZmF1bHQgSmF2YSBrZXlzdG9yZQ0KPiANCj4gSXMgYW55b25lIGluIHRoZSBXRyBhd2Fy ZSBvZiBhIHdvcmthcm91bmQgZm9yIHRoaXMsIG9yIGhhdmUgbGlua3MgdG8gDQo+IHBhc3QgV0cg ZGlzY3Vzc2lvbiBvbiB0aGlzIHBvaW50PyBJIHdvdWxkIHRoaW5rIHRoYXQgT3JhY2xlIHNob3Vs ZCBhdCANCj4gbGVhc3QgYmUgbWFkZSBhd2FyZSBvZiB0aGlzIGlzc3VlLCBidXQgZXZlbiBpZiB0 aGV5IGNoYW5nZXMgdGhpcyBpbiANCj4gSmF2YSAxMCwgdGhhdCBkb2Vzbid0IGhlbHAgbXkgaW1w bGVtZW50YXRpb24gcnVuIG9uIGVhcmxpZXIgSmF2YSB2ZXJzaW9ucy4NCj4gVGhlIG9ubHkgYWx0 ZXJuYXRpdmVzIEkgc2VlIGF0IHRoaXMgcG9pbnQgYXJlOg0KPiANCj4gLSBSZW1vdmUgdGhlIE5V TEwgcmVzdHJpY3Rpb24gZnJvbSBkcmFmdC1pZXRmLWN1cmRsZS1wa2l4LTAzDQo+IC0gUmVxdWly ZSB0aGF0IG15IGxpYnJhcnkgbm90IGJlIHVzZWQgd2l0aCBpbmNvbXBhdGlibGUga2V5c3RvcmVz IChidXQNCj4gYSkgSSBoYXZlIHlldCB0byBmaW5kIGEgd2F5IHRvIGVuZm9yY2UgdGhpcyB2aWEg dGhlIEpDQSwgb3RoZXIgdGhhbiANCj4ganVzdCByZWZ1c2luZyB0byBpbXBsZW1lbnQgc3VwcG9y dCBmb3IgUEtDUzhFbmNvZGVkS2V5U3BlYywgd2hpY2ggaXMgDQo+IG5vdCBwYXJ0aWN1bGFybHkg dXNhYmxlLCBhbmQgYikgSSBkb24ndCB5ZXQga25vdyBvZiBhIGtleXN0b3JlIHRoYXQgDQo+ICp3 aWxsKiBpbXBsZW1lbnQgdGhpcyBwcm9wZXJseSkNCg0KSSBoYXZlIGZvdW5kIHRoZSBjb3JyZXNw b25kZW5jZSBpbiB0aGUgQ3VyZGxlIFdHIE1MIHRoYXQgYWRkZWQgdGhlIE5VTEwgcmVzdHJpY3Rp b247IEkgaGF2ZSBjb3BpZWQgaW4gdGhlIHJlbGV2YW50IG1lbWJlcnMgdG8gaG9wZWZ1bGx5IGpv ZyB0aGlzIGNvbnZlcnNhdGlvbi4gSWYgdGhlcmUgaXMgbm8gZnVydGhlciBkaXNjdXNzaW9uLCB0 aGVuIEkgd2lsbCBoYXZlIG5vIGFsdGVybmF0aXZlIGJ1dCB0byBiZSBub24tY29tcGxpYW50IHdp dGggdGhlIGV2ZW50dWFsIFJGQywgYXMgSSBoYXZlIGJlZW4gdW5hYmxlIHRvIGZpbmQgYSB3YXkg Zm9yIG15IGxpYnJhcnkgdG8gd29yayB3aXRoIHRoZSBkZWZhdWx0IEphdmEga2V5c3RvcmUgOigN Cg0KUGV0ZXIgR3V0bWFubiA8cGd1dDAwMUBjcy5hdWNrbGFuZC5hYy5uej4gd3JvdGU6DQo+IERh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD4gd3JpdGVzOg0KPiA+ICAg SW1wbGVtZW50YWlvbnMgTVVTVCBOT1QgYWNjZXB0IGFueSBvZiB0aGVzZSBPSURzIHdpdGggdGhl DQo+ID4gICBwYXJhbWV0ZXJzIGZpZWxkIHByZXNlbnQsIGV2ZW4gaWYgcGFyYW1ldGVycyBoYXMg YSB2YWx1ZQ0KPiA+ICAgb2YgTlVMTC4NCj4gPg0KPiA+SWYgd2UgY2FuIGNvbnZpbmNlIHRoZSBl YXJseSBpbXBsZW1lbnRhdGlvbnMgdG8gaGFyZC1mYWlsIG9uIHRoYXQsIHdlIA0KPiA+Y2FuIGRp c2NvdXJhZ2UgYW55b25lIGZyb20gZ2VuZXJhdGluZyB0aG9zZSB2YWx1ZXMgaW4gbmV3ZXIgDQo+ ID5pbXBsZW1lbnRhdGlvbnMuDQo+DQo+ICsxLiAgRm9yIG9uY2UgdGhlcmUncyBubyBhcmd1bWVu dCBmb3Igc3VwcG9ydGluZyBleGlzdGluZyBicm9rZW4NCj4gaW1wbGVtZW50YXRpb25zLCB3ZSBj YW4gZ2V0IGl0IHJpZ2h0IGZyb20gdGhlIHN0YXJ0DQoNCkkgYXBvbG9naXNlIGZvciBwcm92aWRp bmcgb25lIDovDQoNCkNoZWVycygtaXNoKSwNCkphY2sNCg0K From nobody Tue Mar 14 10:19:42 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 8D4851329CF for ; Tue, 14 Mar 2017 10:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=nistgov.onmicrosoft.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 XhVrMiXoXi-B for ; Tue, 14 Mar 2017 10:19:35 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0104.outbound.protection.outlook.com [23.103.201.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 266CA1329CC for ; Tue, 14 Mar 2017 10:19:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=TLWF649KkkuiaiMrxrMeFNGMlz4WMBLPX2IjH/J1cvc=; b=Z23VVvR+5eFco+VVVmaIRJJWCwy9cBwNCID2kBe+aPk5/w2T3tNTANOItYPrJUt5RGD8acdZehDU85pFXxkTMPxjz+8h4N2hzt09NMVpDFA6gKT/zd6kSydDHb3MVaWdkqafIvQEeqs532z60AyCzsOxSuhC0BT9jtwJaEKdhHI= Received: from CY4PR09MB1464.namprd09.prod.outlook.com (10.173.191.22) by CY4PR09MB1464.namprd09.prod.outlook.com (10.173.191.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.17; Tue, 14 Mar 2017 17:19:32 +0000 Received: from CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) by CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) with mapi id 15.01.0961.020; Tue, 14 Mar 2017 17:19:32 +0000 From: "Dang, Quynh (Fed)" To: "rsalz@akamai.com" , "Dang, Quynh (Fed)" , Russ Housley CC: Curdle Thread-Topic: [Curdle] Some work for the group Thread-Index: AQHSUiKs3PWVL7wFScuPYdGzcgHHmKD/tuoAgAUxWICAA8bVAIAAjpmAgDQrVACAEdcRAIAAUaIAgAeCl4CAGwHggIAAUdMAgBswggCAATvZAIAAA5EAgASUpgCAAA9kgIAAARyAgAAbLYCAAQNjAIAAP4IA///PvICAAFmRAP//7yGAgAA0C4D//9AZAA== Date: Tue, 14 Mar 2017 17:19:32 +0000 Message-ID: References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> <1489419619.3159.25.camel@redhat.com> <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> <43102E1B-C072-4CE2-9A3E-CDEDE1536AFB@gmail.com> <0DE34F3E-A2D2-4396-B12C-D9FD30DC3723@gmail.com> <2E96A8A2-923A-4597-A175-2581966C0F1E@vigilsec.com> <613a973ed0e347a1bcaed5082b7731ae@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: <613a973ed0e347a1bcaed5082b7731ae@usma1ex-dag1mb1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 authentication-results: akamai.com; dkim=none (message not signed) header.d=none;akamai.com; dmarc=none action=none header.from=nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.222.9] x-microsoft-exchange-diagnostics: 1; CY4PR09MB1464; 7:oJKIbG0jFWqfGnnaYH2ragf2sd50q/ijM7Vpv4mqEBF0hJs+NajAAqD/8aMW2bgC230OXpOxdObCzfVaBeY4XMibaupzfZLl4PLvsh7upLU6Zv8u6ua0WLIrpEVI05B7FaIkeT8bMqHwtt1bXKULDzxi4zaV75ZSGqlnEJRcQqqagCu1zmjh+kVgbfCHGtZORl928vqVeSDCpqEKIR59Gq+X6Mz5CnOEELauD6wCuWM1FAcVB6E/7P1fHU5YbtokQl0wSdTS5lBV9WPeygWUg/prNj7SI/hVBb2lK6VpkuYBnpzKSY7rRE15//2s7utPZvWiiRHvkSYFIn2QTrr1HQ== x-ld-processed: 2ab5d82f-d8fa-4797-a93e-054655c61dec,ExtAddr x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(39410400002)(39840400002)(39850400002)(39860400002)(39450400003)(377454003)(40224003)(6246003)(36756003)(83506001)(25786008)(93886004)(5660300001)(54896002)(99286003)(236005)(6512007)(2900100001)(7736002)(4326008)(122556002)(53936002)(4001350100001)(106116001)(77096006)(2950100002)(81166006)(8936002)(8676002)(6486002)(2906002)(38730400002)(2501003)(3846002)(189998001)(102836003)(76176999)(229853002)(54356999)(3280700002)(50986999)(6506006)(86362001)(3660700001)(53546007)(6436002)(66066001)(6116002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1464; H:CY4PR09MB1464.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-ms-office365-filtering-correlation-id: bb7505d0-d251-42ad-228c-08d46afe47d4 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR09MB1464; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123558025)(20161123562025)(20161123564025)(20161123560025)(6072148); SRVR:CY4PR09MB1464; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1464; x-forefront-prvs: 02462830BE spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D4ED9D7D3170Cqdangnistgov_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Mar 2017 17:19:32.4073 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1464 Archived-At: Subject: Re: [Curdle] Some work for the group X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.21 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, 14 Mar 2017 17:19:40 -0000 --_000_D4ED9D7D3170Cqdangnistgov_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable From: "Salz, Rich" > Date: Tuesday, March 14, 2017 at 12:10 PM To: 'Quynh' >, Russ Housley= > Cc: Curdle > Subject: RE: [Curdle] Some work for the group Right. So, the CA now needs to manage a growing number of distribution poin= ts for their certificates. I don=92t see why the CA likes to do that to avo= id a hash off-line. They can be defined algorithmically, such as {fixedurl}/cert-serial-number = Or perhaps truncated part of the serial number. Currently, it is so simple: just an URI. That method would require some sor= t of management scheme here. If a fixed URL is used, the client must verify= the right digital signature among many others. Quynh. --_000_D4ED9D7D3170Cqdangnistgov_ Content-Type: text/html; charset="Windows-1252" Content-ID: <38578766EA7215438202087A9309EADD@namprd09.prod.outlook.com> Content-Transfer-Encoding: quoted-printable


From: "Salz, Rich" <rsalz@akamai.com>
Date: Tuesday, March 14, 2017 at 12= :10 PM
To: 'Quynh' <Quynh.Dang@nist.gov>, Russ Housley <housley@vigilsec.com>
Cc: Curdle <curdle@ietf.org>
Subject: RE: [Curdle] Some work for= the group

Right. So, the CA now needs to manage a growing number of distribution= points for their certificates. I don=92t see why the CA likes to do that t= o avoid a hash off-line. 

They can be defined algorithmically, such as {fixedurl}/cert-serial-nu= mber  Or perhaps truncated part of the serial number.

Currently, it is so simple: just an URI. That method would require som= e sort of management scheme here. If a fixed URL is used, the client must v= erify the right digital signature among many others.

Quynh. 


 --_000_D4ED9D7D3170Cqdangnistgov_-- From nobody Tue Mar 14 10:26:30 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 4DBAE1329E9 for ; Tue, 14 Mar 2017 10:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=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 RnkBimgVw6Jo for ; Tue, 14 Mar 2017 10:26:28 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 05CDB1329E5 for ; Tue, 14 Mar 2017 10:26:28 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 36730433433; Tue, 14 Mar 2017 17:26:27 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 2035743340D; Tue, 14 Mar 2017 17:26:27 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1489512387; bh=h+9M9JdJY4v9Enx3XQJIOBcO5Poh0txjYZ/O7euMZiE=; l=3281; h=From:To:CC:Date:References:In-Reply-To:From; b=Zzta0yF7Tc6ye1sdcN5V6vQceKuuDbwbkDq5U+YqzDhDn16R3a3JZsUqRvUydD9nJ ac1AJBL0G+Hmhqo7OKkIBA95a42vKFHAEae/CWbYmmYGFRmBjBQ3r5/8E+I90k11g4 77sUANvd9Cf0ffktboWxtof6dwiaqGotoTeNOlbI= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 2026C1FC8D; Tue, 14 Mar 2017 17:26:27 +0000 (GMT) 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.1178.4; Tue, 14 Mar 2017 13:26:26 -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.1178.000; Tue, 14 Mar 2017 13:26:26 -0400 From: "Salz, Rich" To: "Dang, Quynh (Fed)" , Russ Housley CC: Curdle Thread-Topic: [Curdle] Some work for the group Thread-Index: AQHScQapPZALJc3H1k6dKeAsT1IqsaFPVh8AgABRoQCAB4KXgIAbEqWAgABR0gCAGx+/AIABO9kAgAADkQCABIPiAIAAD2SA//+9XyCAAF7qgIABNbGAgAANNACAAAIKAIAAJ0QAgAAhbwD//75lgIAARb0A//+9IvA= Date: Tue, 14 Mar 2017 17:26:26 +0000 Message-ID: <2a1c4915e6af4775bdc8eb9637513245@usma1ex-dag1mb1.msg.corp.akamai.com> References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> <1489419619.3159.25.camel@redhat.com> <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> <43102E1B-C072-4CE2-9A3E-CDEDE1536AFB@gmail.com> <0DE34F3E-A2D2-4396-B12C-D9FD30DC3723@gmail.com> <2E96A8A2-923A-4597-A175-2581966C0F1E@vigilsec.com> <613a973ed0e347a1bcaed5082b7731ae@usma1ex-dag1mb1.msg.corp.akamai.com> 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.35.10] Content-Type: multipart/alternative; boundary="_000_2a1c4915e6af4775bdc8eb9637513245usma1exdag1mb1msgcorpak_" MIME-Version: 1.0 Archived-At: Subject: Re: [Curdle] Some work for the group X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.21 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, 14 Mar 2017 17:26:29 -0000 --_000_2a1c4915e6af4775bdc8eb9637513245usma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I am sorry I wasn=92t being clear. The crlDP is in the certificate. The C= A can generate the value algorithmically and divide it up into as small pie= ces as needed, statelessly. A client can fetch just the CRL(s) it needs. = A CA for IoT doesn=92t need one CRL that covers all devices, and pre-hash d= oesn=92t seem needed (not speaking as chair). --_000_2a1c4915e6af4775bdc8eb9637513245usma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

I am sorry I wasn=92t bei= ng clear.  The crlDP is in the certificate.  The CA can generate = the value algorithmically and divide it up into as small pieces as needed, statelessly.  A client can fetch just the CRL(s) it needs.  A CA= for IoT doesn=92t need one CRL that covers all devices, and pre-hash doesn= =92t seem needed (not speaking as chair).

--_000_2a1c4915e6af4775bdc8eb9637513245usma1exdag1mb1msgcorpak_-- From nobody Tue Mar 14 10:35: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 026431329EB for ; Tue, 14 Mar 2017 10:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=nistgov.onmicrosoft.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 Xcn0YoWP0j5y for ; Tue, 14 Mar 2017 10:35:45 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0098.outbound.protection.outlook.com [23.103.201.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1C211329DE for ; Tue, 14 Mar 2017 10:35:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=01BAaE/VH1TWsd9A9Lno5WK4TBONq4sVHzqTZigxG5E=; b=NYkOR2Zo2p2lulrP+HzerdMs6nrfundwNcKUcgitYRf7P0YAV0mbo19mBFZTPV8uDWSNZjyP4ERNe1IMMZ9tVJwe+TYd0cAmlia+7srj3buavZHY1Fc2GP/3e25s5iFtHvpPRt1697t2ed9uGJvWBKJLYR0krSOV0RD/PY4KYh8= Received: from CY4PR09MB1464.namprd09.prod.outlook.com (10.173.191.22) by CY4PR09MB1464.namprd09.prod.outlook.com (10.173.191.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.17; Tue, 14 Mar 2017 17:35:42 +0000 Received: from CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) by CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) with mapi id 15.01.0961.020; Tue, 14 Mar 2017 17:35:42 +0000 From: "Dang, Quynh (Fed)" To: "rsalz@akamai.com" , "Dang, Quynh (Fed)" , Russ Housley CC: Curdle Thread-Topic: [Curdle] Some work for the group Thread-Index: AQHSUiKs3PWVL7wFScuPYdGzcgHHmKD/tuoAgAUxWICAA8bVAIAAjpmAgDQrVACAEdcRAIAAUaIAgAeCl4CAGwHggIAAUdMAgBswggCAATvZAIAAA5EAgASUpgCAAA9kgIAAARyAgAAbLYCAAQNjAIAAP4IA///PvICAAFmRAP//7yGAgAA0C4D//9AZAAAGh2gA///QSIA= Date: Tue, 14 Mar 2017 17:35:42 +0000 Message-ID: References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> <1489419619.3159.25.camel@redhat.com> <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> <43102E1B-C072-4CE2-9A3E-CDEDE1536AFB@gmail.com> <0DE34F3E-A2D2-4396-B12C-D9FD30DC3723@gmail.com> <2E96A8A2-923A-4597-A175-2581966C0F1E@vigilsec.com> <613a973ed0e347a1bcaed5082b7731ae@usma1ex-dag1mb1.msg.corp.akamai.com> <2a1c4915e6af4775bdc8eb9637513245@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: <2a1c4915e6af4775bdc8eb9637513245@usma1ex-dag1mb1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 authentication-results: akamai.com; dkim=none (message not signed) header.d=none;akamai.com; dmarc=none action=none header.from=nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.222.9] x-microsoft-exchange-diagnostics: 1; CY4PR09MB1464; 7:R/ltUQzNI/C2dijyYyWlklnPnP4O10W3L12PFZq+Ik7fp5womilwzFIMBj/ct78eQUp0lQmpSFhvxCSMmdawamsxBdHHmQJHhslj6OuTDDJGCiK/AFG74zjoXSKv9/L2NM7OR5WvRTAsST0rH8ZqP/BW8pXWiPXnURJ1FD5Ohjuiv/Ml2kIBfSYEvH+Pp/gT45mJaFp6C+XrnylJ5SiTLsX1dq1GuyXgk2j2BgdyeHeENxAhSyhRNRc4QRSQimfAtmz6qPaEXlXRhQZimicDbr6ak53/b0kGX8WCGuajXF4HiMjSsgJRS5japq14VRVUu0G9DuIn35NG2g73CxizFA== x-ld-processed: 2ab5d82f-d8fa-4797-a93e-054655c61dec,ExtAddr x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(39860400002)(39850400002)(39840400002)(39450400003)(39410400002)(377454003)(6486002)(8676002)(2906002)(38730400002)(2501003)(81166006)(8936002)(77096006)(106116001)(2950100002)(3660700001)(53546007)(86362001)(6116002)(6436002)(66066001)(790700001)(189998001)(102836003)(76176999)(3846002)(229853002)(6506006)(50986999)(54356999)(3280700002)(5660300001)(93886004)(6512007)(6306002)(2900100001)(54896002)(99286003)(236005)(6246003)(25786008)(83506001)(36756003)(53936002)(4001350100001)(7736002)(4326008)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1464; H:CY4PR09MB1464.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-ms-office365-filtering-correlation-id: dd2dba83-7c08-41e5-ea72-08d46b008a02 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR09MB1464; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123558025)(20161123562025)(20161123564025)(20161123560025)(6072148); SRVR:CY4PR09MB1464; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1464; x-forefront-prvs: 02462830BE spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D4EDA0A73171Aqdangnistgov_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Mar 2017 17:35:42.3990 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1464 Archived-At: Subject: Re: [Curdle] Some work for the group X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.21 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, 14 Mar 2017 17:35:47 -0000 --_000_D4EDA0A73171Aqdangnistgov_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable From: "Salz, Rich" > Date: Tuesday, March 14, 2017 at 12:26 PM To: 'Quynh' >, Russ Housley= > Cc: Curdle > Subject: RE: [Curdle] Some work for the group I am sorry I wasn=92t being clear. The crlDP is in the certificate. The C= A can generate the value algorithmically and divide it up into as small pie= ces as needed, statelessly. A client can fetch just the CRL(s) it needs. This creates things more complicated and more room for errors for both side= s unnecessarily. A CA for IoT doesn=92t need one CRL that covers all devices, and pre-hash d= oesn=92t seem needed (not speaking as chair). The point is which option works better. Quynh. --_000_D4EDA0A73171Aqdangnistgov_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable


From: "Salz, Rich" <rsalz@akamai.com>
Date: Tuesday, March 14, 2017 at 12= :26 PM
To: 'Quynh' <Quynh.Dang@nist.gov>, Russ Housley <housley@vigilsec.com>
Cc: Curdle <curdle@ietf.org>
Subject: RE: [Curdle] Some work for= the group

I am sorry I wasn=92t being clear.&= nbsp; The crlDP is in the certificate.  The CA can generate the value = algorithmically and divide it up into as small pieces as needed, statelessly.  A client can fetch just the CRL(s) it needs.=  


This creates things more complicated and more room for errors for both= sides unnecessarily. 

A CA for IoT doesn=92t need one CRL= that covers all devices, and pre-hash doesn=92t seem needed (not speaking = as chair).

The point is which option works better.

Quynh. 

 --_000_D4EDA0A73171Aqdangnistgov_-- From nobody Tue Mar 14 10:41:48 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 9CDDF1298A8 for ; Tue, 14 Mar 2017 10:41: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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0SxDeiSLtmAg for ; Tue, 14 Mar 2017 10:41:45 -0700 (PDT) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e: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 611D5129882 for ; Tue, 14 Mar 2017 10:41:45 -0700 (PDT) Received: by mail-pg0-x22d.google.com with SMTP id b129so94011885pgc.2 for ; Tue, 14 Mar 2017 10:41:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=G84C522Pg12/Y0pBOZJnwQ7eul++GaAfWhNuLhlqPrA=; b=LaPQtXOxNxhO5tLPFAEiVGv7SSOp16nlNsnQwc9aBhg068WBC3us55/HA1heIe4Hx+ uGHgKqV6TV92AwLt5SYM9Yh9pANb9SxRBYuK6zXhd+jN3rr2HRjJPiAP+sOknRKVKxj4 PKqDxyZQbzJFThytGTJNtxJnU448TNIQmyIR8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=G84C522Pg12/Y0pBOZJnwQ7eul++GaAfWhNuLhlqPrA=; b=Ti4VEvR+SJfvA62PKHrJoZq67rZVNa1IUtHgq1pKt7ba8FtS8ms7mn67L065fV/45b B1PpWnt2io48WQ4S63gLu6yi19s5FdGGCgObFdccx4mGZt0J7gYwbQofFdxHHw6IZyAk R0pwN7SbE7gFa9JOECxok4mfxp1JFnudzjuBUfrw3ljYkaZ7PR0mLPQrp4ntcYPPrAcJ qkHQTTKmlIH/yNB45bNlE2KYltKwUv4Aep0WyvXDOSOjbIYyrC+FvNo5ZcSC4VzBV2Zl iv3Tmsvs+5c40HfbRudgHv4+GDNi5aFg1SI1/IZMXKl7O7mBbO1yvFQqeOQv8UHlV0rm TIkA== X-Gm-Message-State: AMke39mEv6tIvRxr2dBV7F+xLx36/KWnZy4TbNMnoHBSr2qUXmvXhLg8WeFNAhxOTDHUPYvasJVPVyAF+9Y2T5Nm X-Received: by 10.98.160.193 with SMTP id p62mr45337732pfl.67.1489513304799; Tue, 14 Mar 2017 10:41:44 -0700 (PDT) MIME-Version: 1.0 References: <7d6cfe29-8d4c-436e-fe8a-0cbee915b29e@mail.i2p> <20170311061838.879BAADF28@smtp.postman.i2p> <2DD56D786E600F45AC6BDE7DA4E8A8C118BA5C93@eusaamb107.ericsson.se> In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C118BA5C93@eusaamb107.ericsson.se> From: David Benjamin Date: Tue, 14 Mar 2017 17:41:33 +0000 Message-ID: To: Daniel Migault , str4d , "curdle@ietf.org" , Russ Housley , Daniel Kahn Gillmor , Peter Gutmann Content-Type: multipart/alternative; boundary=001a1140eed46c14aa054ab45773 Archived-At: Subject: Re: [Curdle] AlgorithmIdentifier parameters in draft-ietf-curdle-pkix-03 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.21 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, 14 Mar 2017 17:41:47 -0000 --001a1140eed46c14aa054ab45773 Content-Type: text/plain; charset=UTF-8 No, we should not relax the MUST NOT. We've learned from the previous algorithms here that multiple options for encodings are an unnecessary source of complexity and interop headaches. There should only be one encoding and parsers need to enforce this to avoid an ecosystem mess. On Tue, Mar 14, 2017 at 1:11 PM Daniel Migault wrote: > Hi, > > We need to sort this out. Anyone from Oracle can provide feedbacks ? > > Please let us know if there is any consensus on relaxing the MUST NOT > accept parameters even NULL ? > > Yours, > Daniel > > > -----Original Message----- > From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of str4d > Sent: Saturday, March 11, 2017 1:19 AM > To: curdle@ietf.org; Russ Housley ; Daniel Kahn > Gillmor ; Peter Gutmann > Subject: Re: [Curdle] AlgorithmIdentifier parameters in > draft-ietf-curdle-pkix-03 > > On 02/19/2017 02:14 AM, str4d wrote: > > Hi all, > > > > In draft-ietf-curdle-pkix-03 there is very clear language around the > > expected behaviour of parser implementations regarding > > AlgorithmIdentifier parameters: > > > > [snip] > > > The problem is that the Sun AlgorithmId class always adds a NULL when > > encoding if there are no parameters, for compatibility with Solaris [4]. > > So AFAICT it is presently impossible for me to write an implementation > > that simultaneously: > > > > - follows draft-ietf-curdle-pkix-03 correctly > > - can retrieve EdDSA keys from a default Java keystore > > > > Is anyone in the WG aware of a workaround for this, or have links to > > past WG discussion on this point? I would think that Oracle should at > > least be made aware of this issue, but even if they changes this in > > Java 10, that doesn't help my implementation run on earlier Java > versions. > > The only alternatives I see at this point are: > > > > - Remove the NULL restriction from draft-ietf-curdle-pkix-03 > > - Require that my library not be used with incompatible keystores (but > > a) I have yet to find a way to enforce this via the JCA, other than > > just refusing to implement support for PKCS8EncodedKeySpec, which is > > not particularly usable, and b) I don't yet know of a keystore that > > *will* implement this properly) > > I have found the correspondence in the Curdle WG ML that added the NULL > restriction; I have copied in the relevant members to hopefully jog this > conversation. If there is no further discussion, then I will have no > alternative but to be non-compliant with the eventual RFC, as I have been > unable to find a way for my library to work with the default Java keystore > :( > > Peter Gutmann wrote: > > Daniel Kahn Gillmor writes: > > > Implementaions MUST NOT accept any of these OIDs with the > > > parameters field present, even if parameters has a value > > > of NULL. > > > > > >If we can convince the early implementations to hard-fail on that, we > > >can discourage anyone from generating those values in newer > > >implementations. > > > > +1. For once there's no argument for supporting existing broken > > implementations, we can get it right from the start > > I apologise for providing one :/ > > Cheers(-ish), > Jack > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --001a1140eed46c14aa054ab45773 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
No, we should not relax the MUST NOT. We've learned fr= om the previous algorithms here that multiple options for encodings are an = unnecessary source of complexity and interop headaches. There should only b= e one encoding and parsers need to enforce this to avoid an ecosystem mess.=

On Tue, Mar 14, 2017 a= t 1:11 PM Daniel Migault <daniel.migault@ericsson.com> wrote:
Hi,

We need to sort this out. Anyone from Oracle can provide feedbacks ?

Please let us know if there is any consensus on relaxing the MUST NOT accep= t parameters even NULL ?

Yours,
Daniel


-----Original Message-----
From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of str4d<= br class=3D"gmail_msg"> Sent: Saturday, March 11, 2017 1:19 AM
To: curdle@ietf.org; Russ Housley <housley@vigilsec.com>; Da= niel Kahn Gillmor <dkg@fifthhorseman.net>; Peter Gutmann <= pgut001@cs.auckland.ac.nz>
Subject: Re: [Curdle] AlgorithmIdentifier parameters in draft-ietf-curdle-p= kix-03

On 02/19/2017 02:14 AM, str4d wrote:
> Hi all,
>
> In draft-ietf-curdle-pkix-03 there is very clear language around the > expected behaviour of parser implementations regarding
> AlgorithmIdentifier parameters:
>

[snip]

> The problem is that the Sun AlgorithmId class always adds a NULL when<= br class=3D"gmail_msg"> > encoding if there are no parameters, for compatibility with Solaris [4= ].
> So AFAICT it is presently impossible for me to write an implementation=
> that simultaneously:
>
> - follows draft-ietf-curdle-pkix-03 correctly
> - can retrieve EdDSA keys from a default Java keystore
>
> Is anyone in the WG aware of a workaround for this, or have links to > past WG discussion on this point? I would think that Oracle should at<= br class=3D"gmail_msg"> > least be made aware of this issue, but even if they changes this in > Java 10, that doesn't help my implementation run on earlier Java v= ersions.
> The only alternatives I see at this point are:
>
> - Remove the NULL restriction from draft-ietf-curdle-pkix-03
> - Require that my library not be used with incompatible keystores (but=
> a) I have yet to find a way to enforce this via the JCA, other than > just refusing to implement support for PKCS8EncodedKeySpec, which is > not particularly usable, and b) I don't yet know of a keystore tha= t
> *will* implement this properly)

I have found the correspondence in the Curdle WG ML that added the NULL res= triction; I have copied in the relevant members to hopefully jog this conve= rsation. If there is no further discussion, then I will have no alternative= but to be non-compliant with the eventual RFC, as I have been unable to fi= nd a way for my library to work with the default Java keystore :(

Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:
> Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:
> >=C2=A0 =C2=A0Implementaions MUST NOT accept any of these OIDs with= the
> >=C2=A0 =C2=A0parameters field present, even if parameters has a va= lue
> >=C2=A0 =C2=A0of NULL.
> >
> >If we can convince the early implementations to hard-fail on that,= we
> >can discourage anyone from generating those values in newer
> >implementations.
>
> +1.=C2=A0 For once there's no argument for supporting existing bro= ken
> implementations, we can get it right from the start

I apologise for providing one :/

Cheers(-ish),
Jack

_______________________________________________
Curdle mailing list
Cu= rdle@ietf.org
https://www.ietf.org/mailman/listinf= o/curdle
--001a1140eed46c14aa054ab45773-- From nobody Tue Mar 14 10:53: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 F330F12E05B for ; Tue, 14 Mar 2017 10:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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, RP_MATCHES_RCVD=-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=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 VmfCVf_uULrC for ; Tue, 14 Mar 2017 10:53:46 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 95F5F120072 for ; Tue, 14 Mar 2017 10:53:46 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 41836496C08; Tue, 14 Mar 2017 17:53:46 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 2A05F496C01; Tue, 14 Mar 2017 17:53:46 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1489514026; bh=TknqJj3/Li1iQzCwFNU5yREwFGmxID8fFC7jAuJUaF4=; l=411; h=From:To:CC:Date:References:In-Reply-To:From; b=PE0mFMwYVajysCGLmbvkNqsE908dzCX50QGDOLa1gsrEGmyq642v2cahkfU8CRdem kWLUNhQPZwX9xCRXCrWGrd67stmaBdbIuLn133vI4p7nIhS+Xj/JE0M3D0wMKKWadS 7z04MoKKOriamV4jKEERX+a12itPLCfLrFii9JCM= Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 08DFE1E080; Tue, 14 Mar 2017 17:53:46 +0000 (GMT) Received: from USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 14 Mar 2017 13:53:45 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 14 Mar 2017 13:53:45 -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.1178.000; Tue, 14 Mar 2017 13:53:45 -0400 From: "Salz, Rich" To: "Dang, Quynh (Fed)" , Russ Housley CC: Curdle Thread-Topic: [Curdle] Some work for the group Thread-Index: AQHScQapPZALJc3H1k6dKeAsT1IqsaFPVh8AgABRoQCAB4KXgIAbEqWAgABR0gCAGx+/AIABO9kAgAADkQCABIPiAIAAD2SA//+9XyCAAF7qgIABNbGAgAANNACAAAIKAIAAJ0QAgAAhbwD//75lgIAARb0A//+9IvAACOxnAAAHy6XQ Date: Tue, 14 Mar 2017 17:53:44 +0000 Message-ID: <566c222d539d4685941fabbc168c9699@usma1ex-dag1mb1.msg.corp.akamai.com> References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> <1489419619.3159.25.camel@redhat.com> <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> <43102E1B-C072-4CE2-9A3E-CDEDE1536AFB@gmail.com> <0DE34F3E-A2D2-4396-B12C-D9FD30DC3723@gmail.com> <2E96A8A2-923A-4597-A175-2581966C0F1E@vigilsec.com> <613a973ed0e347a1bcaed5082b7731ae@usma1ex-dag1mb1.msg.corp.akamai.com> <2a1c4915e6af4775bdc8eb9637513245@usma1ex-dag1mb1.msg.corp.akamai.com> 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.35.10] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Curdle] Some work for the group X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.21 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, 14 Mar 2017 17:53:50 -0000 > This creates things more complicated and more room for errors for both si= des unnecessarily.=A0 Since the replying party already needs to know about crlDP, how does it com= plicate clients? I can see that it is a bit more work for CA's. > The point is which option works better. There are many metrics to consider, including if having two algorithms glob= ally deployed is part of being better. From nobody Tue Mar 14 11:00: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 A43391288EF for ; Tue, 14 Mar 2017 11:00:39 -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 E8G4BCvW2QOY for ; Tue, 14 Mar 2017 11:00:38 -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 568151294AD for ; Tue, 14 Mar 2017 11:00:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id B9B073004AF for ; Tue, 14 Mar 2017 14:00:37 -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 321jSmrxnWNn for ; Tue, 14 Mar 2017 14:00:32 -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 02CC730009D; Tue, 14 Mar 2017 14:00:31 -0400 (EDT) From: Russ Housley Message-Id: <107FEF81-4578-4096-AF76-336C24478039@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_C04F67B2-12E1-48EF-B380-C398DBC06AF0" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Tue, 14 Mar 2017 14:00:31 -0400 In-Reply-To: Cc: Curdle To: Quynh Dang References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> <1489419619.3159.25.camel@redhat.com> <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> <43102E1B-C072-4CE2-9A3E-CDEDE1536AFB@gmail.com> <0DE34F3E-A2D2-4396-B12C-D9FD30DC3723@gmail.com> <2E96A8A2-923A-4597-A175-2581966C0F1E@vigilsec.com> X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Curdle] Some work for the group X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.21 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, 14 Mar 2017 18:00:39 -0000 --Apple-Mail=_C04F67B2-12E1-48EF-B380-C398DBC06AF0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Quynh: > Right. So, the CA now needs to manage a growing number of distribution = points for their certificates. I don=E2=80=99t see why the CA likes to = do that to avoid a hash off-line.=20 This is not the list for this discussion, but CAs use CRLDP so that they = can manage the maximum size of the CRLs. This helps relying parties by = avoiding the latency for a large download. Russ --Apple-Mail=_C04F67B2-12E1-48EF-B380-C398DBC06AF0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Quynh:

Right. So, the CA now needs to = manage a growing number of distribution points for their certificates. I = don=E2=80=99t see why the CA likes to do that to avoid a hash = off-line. 

This is not = the list for this discussion, but CAs use CRLDP so that they can manage = the maximum size of the CRLs.  This helps relying parties by = avoiding the latency for a large download.

Russ


= --Apple-Mail=_C04F67B2-12E1-48EF-B380-C398DBC06AF0-- From nobody Tue Mar 14 11:13:29 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 A587E124B0A for ; Tue, 14 Mar 2017 11:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=nistgov.onmicrosoft.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 Pb2A_cTET7RA for ; Tue, 14 Mar 2017 11:13:26 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0117.outbound.protection.outlook.com [23.103.201.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C24B5126E62 for ; Tue, 14 Mar 2017 11:13:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=G3GVFv26oVEa6y1ptkXf0FRiyGGxSAbz3900GQ0q7dY=; b=wcYk4CFAvpLKZ7SZovDR/aS47tFArWwTPPqe2ZoQedARKB/QwFIjrd+E7TTVCZUO9yMHna6X0HJ8lH3QEznlrTCwGYyRwnI22sSoiLXJ/jfw9nm0uWPv2tHgG4+k4vNXxAIn6vTzs7Z6ouIJQLmCU4Gluw0+3RuevDu1uAfR1Ds= Received: from CY4PR09MB1464.namprd09.prod.outlook.com (10.173.191.22) by CY4PR09MB1464.namprd09.prod.outlook.com (10.173.191.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.17; Tue, 14 Mar 2017 17:58:06 +0000 Received: from CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) by CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) with mapi id 15.01.0961.020; Tue, 14 Mar 2017 17:58:05 +0000 From: "Dang, Quynh (Fed)" To: "rsalz@akamai.com" , "Dang, Quynh (Fed)" , Russ Housley CC: Curdle Thread-Topic: [Curdle] Some work for the group Thread-Index: AQHSUiKs3PWVL7wFScuPYdGzcgHHmKD/tuoAgAUxWICAA8bVAIAAjpmAgDQrVACAEdcRAIAAUaIAgAeCl4CAGwHggIAAUdMAgBswggCAATvZAIAAA5EAgASUpgCAAA9kgIAAARyAgAAbLYCAAQNjAIAAP4IA///PvICAAFmRAP//7yGAgAA0C4D//9AZAAAGh2gA///QSICAADdYAP//zukA Date: Tue, 14 Mar 2017 17:58:05 +0000 Message-ID: References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> <1489419619.3159.25.camel@redhat.com> <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> <43102E1B-C072-4CE2-9A3E-CDEDE1536AFB@gmail.com> <0DE34F3E-A2D2-4396-B12C-D9FD30DC3723@gmail.com> <2E96A8A2-923A-4597-A175-2581966C0F1E@vigilsec.com> <613a973ed0e347a1bcaed5082b7731ae@usma1ex-dag1mb1.msg.corp.akamai.com> <2a1c4915e6af4775bdc8eb9637513245@usma1ex-dag1mb1.msg.corp.akamai.com> <566c222d539d4685941fabbc168c9699@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: <566c222d539d4685941fabbc168c9699@usma1ex-dag1mb1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 authentication-results: akamai.com; dkim=none (message not signed) header.d=none;akamai.com; dmarc=none action=none header.from=nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.222.9] x-microsoft-exchange-diagnostics: 1; CY4PR09MB1464; 7:41vu6J79XgPcdkZVa/45qWYZJ9JaxUSgt+kO1hGa1VMC3aD30V5vRiotrLmnv+oq1hqyeQaGJ2DQWL3CQ93Tm1pIVvHcldYEupeLCy8yzwTOKC6gjV/vQVWXb4oPO6xBJHnOY8VI2SBNJ6f66LTGU1p8JiEqBnm8znKeWzXk2fwdWZNbynPTGqPQPykBmjfaUzE050AN2PQVFomGOvPLjMrwC7Osp0R/JGCdMqMtWhR7Sm2nwLJxbZVl7ooWxjDKOEuZMhCxrdgqE7jZ/SG1qUtATImgYZgCcSowPsxTNB3ox03gwBkkfFuQfSfQnGiEMgFHjMv7kiinjLekRR5DTA== x-ld-processed: 2ab5d82f-d8fa-4797-a93e-054655c61dec,ExtAddr x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(39410400002)(39450400003)(39860400002)(39840400002)(39850400002)(377454003)(51444003)(6246003)(36756003)(83506001)(25786008)(93886004)(5660300001)(54896002)(99286003)(236005)(6512007)(2900100001)(4326008)(7736002)(122556002)(53936002)(4001350100001)(106116001)(77096006)(81166006)(8936002)(6486002)(2906002)(8676002)(38730400002)(2501003)(2950100002)(3846002)(189998001)(102836003)(76176999)(229853002)(54356999)(3280700002)(50986999)(6506006)(86362001)(3660700001)(53546007)(6436002)(66066001)(6116002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1464; H:CY4PR09MB1464.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-ms-office365-filtering-correlation-id: cd6ee119-6575-43fe-e422-08d46b03aaab x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR09MB1464; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123560025)(20161123562025)(20161123558025)(20161123555025)(6072148); SRVR:CY4PR09MB1464; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1464; x-forefront-prvs: 02462830BE spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D4EDA70C31726qdangnistgov_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Mar 2017 17:58:05.7006 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1464 Archived-At: Subject: Re: [Curdle] Some work for the group X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.21 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, 14 Mar 2017 18:13:28 -0000 --_000_D4EDA70C31726qdangnistgov_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: "Salz, Rich" > Date: Tuesday, March 14, 2017 at 12:53 PM To: 'Quynh' >, Russ Housley= > Cc: Curdle > Subject: RE: [Curdle] Some work for the group This creates things more complicated and more room for errors for both side= s unnecessarily. Since the replying party already needs to know about crlDP, how does it com= plicate clients? I can see that it is a bit more work for CA's. The point is which option works better. There are many metrics to consider, including if having two algorithms glob= ally deployed is part of being better. Hi Rich, I think that only the pre-hash version would be the best. Quynh. --_000_D4EDA70C31726qdangnistgov_ Content-Type: text/html; charset="us-ascii" Content-ID: <6C7BA39B95EC87488FCB535274826097@namprd09.prod.outlook.com> Content-Transfer-Encoding: quoted-printable


From: "Salz, Rich" <rsalz@akamai.com>
Date: Tuesday, March 14, 2017 at 12= :53 PM
To: 'Quynh' <Quynh.Dang@nist.gov>, Russ Housley <housley@vigilsec.com>
Cc: Curdle <curdle@ietf.org>
Subject: RE: [Curdle] Some work for= the group

This creates things more complicated and more room for errors for both= sides unnecessarily. 

Since the replying party already needs to know about crlDP, how does i= t complicate clients?  I can see that it is a bit more work for C= A's.

The point is which option works better.

There are many metrics to consider, including if having two algorithms= globally deployed is part of being better.

Hi Rich,

I think that only the pre-hash version  would be the best. <= /div>

Quynh. 


 --_000_D4EDA70C31726qdangnistgov_-- From nobody Tue Mar 14 11:37: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 43682129980 for ; Tue, 14 Mar 2017 11:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nKXLeUCNEo79 for ; Tue, 14 Mar 2017 11:37:40 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69E1A1294E9 for ; Tue, 14 Mar 2017 11:37:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CD0ACBED4; Tue, 14 Mar 2017 18:37:37 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0Mtw73w_SQR; Tue, 14 Mar 2017 18:37:32 +0000 (GMT) Received: from [10.87.48.75] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C0189BE2E; Tue, 14 Mar 2017 18:37:31 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1489516652; bh=ekzrqM7u9JRHsUQSReKHvtXRJINODoGRFJV6ZtZfRYk=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=mA/7f7JtXyqJRmqz8ntbWa1oWnYvtF81RiY6XT1pYUV+iXtlIuqitfKA4EwOPNit5 dMamYwpNSeCrrvMuuh6Xg5WqQU3LS3njMYycilXPvTSIWmHYYAg2vpogy7k4boMAG0 b2dgU89XpYtY4NqeVo2Uvc9vMPInbmop98tPK7Yo= To: "Dang, Quynh (Fed)" , Yoav Nir , "rsalz@akamai.com" References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> <1489419619.3159.25.camel@redhat.com> <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> <43102E1B-C072-4CE2-9A3E-CDEDE1536AFB@gmail.com> Cc: Nikos Mavrogiannopoulos , Curdle From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <44379acc-ccf9-eaf8-31cf-ef2611e9dd0f@cs.tcd.ie> Date: Tue, 14 Mar 2017 18:37:31 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vwNd5ipCdoOo2FsjIUbVV3TJKle0OmF6V" Archived-At: Subject: Re: [Curdle] Some work for the group 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, 14 Mar 2017 18:37:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --vwNd5ipCdoOo2FsjIUbVV3TJKle0OmF6V Content-Type: multipart/mixed; boundary="PrdECXni0O39gUDDUj2KUtUaXvKCwdu1r"; protected-headers="v1" From: Stephen Farrell To: "Dang, Quynh (Fed)" , Yoav Nir , "rsalz@akamai.com" Cc: Nikos Mavrogiannopoulos , Curdle Message-ID: <44379acc-ccf9-eaf8-31cf-ef2611e9dd0f@cs.tcd.ie> Subject: Re: [Curdle] Some work for the group References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> <1489419619.3159.25.camel@redhat.com> <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> <43102E1B-C072-4CE2-9A3E-CDEDE1536AFB@gmail.com> In-Reply-To: --PrdECXni0O39gUDDUj2KUtUaXvKCwdu1r Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Quynh, I'm sorry but I've no idea how your mail is responsive to mine. To re-iterate: there is IMO no justification at all for pre-hash based on constrained devices and CRLs. Your arguments that there are are unconvincing. And nobody has pointed at any real device that does need pre-hash. Cheers, S. On 14/03/17 13:18, Dang, Quynh (Fed) wrote: > Stephen, >=20 > Your point is very perfect to me! >=20 > We, the IETF, are a very important international standard body and our = standards and recommendations have tremendous impact on improving securit= y and services that the internet provides. >=20 > I would like our products to continue to provide great solutions to as = many users as possible. At least, when signing large files, the pre-has= h works better than the non-prehash. And, the hash-then-sign scheme has w= orked well since the digital signature was invented when the hash functio= n is secure. >=20 > Regards, > Quynh. >=20 > From: Stephen Farrell > > Date: Tuesday, March 14, 2017 at 7:43 AM > To: 'Quynh' >, Yoav Nir= >, "rsalz@akamai.com" > > Cc: Nikos Mavrogiannopoulos >, = Curdle > > Subject: Re: [Curdle] Some work for the group >=20 >=20 > Hiya, >=20 > (No hats still:-) >=20 > On 14/03/17 11:49, Dang, Quynh (Fed) wrote: > Hi Yoav, > Is it reasonable to think that there will be constrained devices > which need to handle CRL lists ? >=20 > One could imagine a universe in which that mattered, but it > is not this universe. Memory constrained devices that need to > consume giant CRLs do not seem to be real. But feel free > to point me at a product data sheet if there is one. >=20 > IMO real constrained devices will not be downloading giant > CRLs for power and/or bandwidth reasons. (Well, and because > it'd be silly;-) >=20 > If the answer is yes, without the pre-hash option, those devices > would need to either: (1) buffer large messages (costly) or (2) > verify multiple CRL lists every time (costly) if the CA creates > multiple CRL lists every time with the non-prehash option. > If only one option were to be used, the pre-hash would be the best > choice because it works well everywhere, not like the non-prehash > one. >=20 > "Everywhere" there really meaning "that other universe where > giant CRLs for memory constrained devices matter"? >=20 > I think we can ditch or otherwise say to not use the pre-hash > stuff safely. Adding it or allowing its use is less safe. >=20 > (I'm not as hardline as Nikos that it ought not be defined at > all, but only because if we don't define it now with a MUST > NOT or SHOULD NOT, then someone will come along later and > define it causing all the confusion/complexity anyway so I > don't see that omitting it here gains that much, but I'd be > ok with doing so.) >=20 > Cheers, > S. >=20 > Quynh. > From: Curdle > > on behalf > of Yoav Nir > Date: > Monday, March 13, 2017 at 12:21 PM To: > "rsalz@akamai.com" > > Cc= : Nikos > Mavrogiannopoulos >, Curdle > > Subje= ct: Re: [Curdle] Some > work for the group > Speaking as an implementer of a relying party, if pre-hash is a MAY > for CRLs on the CA side, it becomes a MUST on the relying party side. > I MAY receive a CRL signed with pre-hashed EdDSA, so I MUST implement > it if I want interoperability. I also MUST implement the non > pre-hashed EdDSA, because certificates are very likely to be signed > with that. > So unless there=E2=80=99s a very good reason to sign CRLs with the pre-= hashed > version, I=E2=80=99d rather that it be MUST NOT for all uses. > The claim has been made that future hardware (current hardware does > not implement EdDSA) will not be able to hold an entire CRL all at > once in memory, and therefore will need to be fed this CRL one chunk > at a time, implying the need for a pre-hash. However, the size of > CRLs is entirely determined by CA policy. The size of a CRL is > bounded by the number of certificates that share the same CDP. A CA > can set this value to any number from 1 to all the certificates ever > issued, and it can set the value so that it fits the hardware > limitations without pre-hashing. > I don=E2=80=99t think forcing the relying parties (all several billions= of > them) to implement both variations is better than forcing CAs to > adjust the parameter of ce > On 13 Mar 2017, at 17:44, Salz, Rich > > wr= ote: The pre-hash is > not known to be bad, although it can be risky for some systems. The > goal is to not have risky things if we don't need them. So far, the > only use-case that has had support is CRL's, which are less likely to > be risky since the same keypair generally signs certificates. In the > interest of progressing the draft, we are asking if pre-hash is a MAY > for CRL's and a SHOULD NOT or MUST NOT for all other uses. -- Senior > Architect, Akamai Technologies Member, OpenSSL Dev Team IM: > richsalz@jabber.at Twitter: RichSalz > _______________________________________________ Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > _______________________________________________ Curdle mailing list > Curdle@ietf.org https://www.ietf.org/mailman/li= stinfo/curdle >=20 >=20 >=20 --PrdECXni0O39gUDDUj2KUtUaXvKCwdu1r-- --vwNd5ipCdoOo2FsjIUbVV3TJKle0OmF6V Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYyDhrAAoJEC88hzaAX42iCqkIAL1DTVks09t2v5oBr6OPm8Ox yuTUh16HLstpMTIEDnOhrKZoLF+ZvtqA32C3R9KgYZlBOVRl+h+RaUiThpyr0ii5 56wQ1z9946sGJiVBe97QKi4QonrHrJ/xqd+7BidET6UcFmeT/7FLbEBX9M305tht C5JyF2w8bmuqYx0H0hMhAgbBBLvmEbM8ozK2fgTAg/h1hQOFq2IXgfzma9UHaV21 a04sFVQzee1lJnRtkBk10Adtz3v+nad/B0C6q0+5/W68F58aa7hMlmrIkVAkaFLZ pa62AEKsrhJpFEfx9GW3J78VOiUQx98rBS49x9qffjl8iMOuw+omY5rUNve0HqI= =UvaD -----END PGP SIGNATURE----- --vwNd5ipCdoOo2FsjIUbVV3TJKle0OmF6V-- From nobody Tue Mar 14 15:49: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 2B9B0131614 for ; Tue, 14 Mar 2017 15:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbCrGLkafcea for ; Tue, 14 Mar 2017 15:49:48 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) by ietfa.amsl.com (Postfix) with ESMTP id 08AC1129B4C for ; Tue, 14 Mar 2017 15:49:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1489531788; x=1521067788; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=CbmPnEKE12JSYfUu2fY6+fVNGw/NE7DfFDS76w2XKHY=; b=lIpDLqP9jpXOYxqEPE8BqrehekSfwNakhwCKmmpiosE34y0bAL4KIJ5e mbux/kER8ENpofd3uwHiLcTn4UIQC/6/YB04J+eICHM27lG7rx1Nu/QIb 6zUfDrLytFBh7386Y9qfDVoecXkDCBeXDKDmduklgqbEEAPkvctYHqh1u BLJwyAYHaTlABnCr0pUYchpYQuNOJVf+JbeUkU1uqSAQa+Pu/eSbQuOXX saBZGueR8t5/91arAdt5zoooXRExpnvYU02zolHfbMShy/Cch8Cy71G1y qIIaCVTS+l/eT54wEWSu2KzsDb2Zb4vwWdWyzymP0sUftuQHuHYKKWhwD Q==; X-IronPort-AV: E=Sophos;i="5.36,165,1486378800"; d="scan'208";a="142510377" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.2 - Outgoing - Outgoing Received: from smtp.uoa.auckland.ac.nz (HELO uxcn13-tdc-a.UoA.auckland.ac.nz) ([10.6.3.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 15 Mar 2017 11:49:15 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-a.UoA.auckland.ac.nz (10.6.3.2) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 15 Mar 2017 11:49:15 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1178.000; Wed, 15 Mar 2017 11:49:15 +1300 From: Peter Gutmann To: Yoav Nir , "Dang, Quynh (Fed)" CC: Nikos Mavrogiannopoulos , Rich Salz , Curdle Thread-Topic: [Curdle] Some work for the group Thread-Index: AQHScQasYv1qbtR3EECCo4rUC94EmqFOKF8AgABRogCAB4KXgIAbAeCAgABR0wCAGzCCAIABO9kAgAADkQCABJSmAIAAD2SAgAABHICAABstgIABNbGAgAANNACAAYST9w== Date: Tue, 14 Mar 2017 22:49:14 +0000 Message-ID: <1489531750610.15665@cs.auckland.ac.nz> References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> <1489419619.3159.25.camel@redhat.com> <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> <43102E1B-C072-4CE2-9A3E-CDEDE1536AFB@gmail.com> , <0DE34F3E-A2D2-4396-B12C-D9FD30DC3723@gmail.com> In-Reply-To: <0DE34F3E-A2D2-4396-B12C-D9FD30DC3723@gmail.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Curdle] Some work for the group 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, 14 Mar 2017 22:49:50 -0000 Yoav Nir writes:=0A= =0A= >It seems odd to me to believe that embedded systems will process CRLs in a= =0A= >time where web browsers running on PCs have stopped doing that. Even if th= ey=0A= >do, making really small CRLs for them seems like a good idea.=A0 But stapl= ing=0A= >OCSP responses seems like an even better idea.=0A= =0A= SCADA stuff typically doesn't process CRLs, but for an entirely different= =0A= reason than you think.=A0 If you revoke a process controller's cert, it can= take=0A= it offline, which is the worst thing that can happen.=A0 So CRLs are ignore= d, as=0A= is OCSP.=A0 Expiry dates in certs are also ignored (I'm currently involved = in a=0A= discussion over whether setting an expiry year of '9999' is valid according= to=0A= the X.509 spec), for the same reason, and because in SCADA you care about= =0A= availability, not enforcing the CA's 12-month billing cycle.=0A= =0A= Also, ID information is frequently ignored because there's no meaningful wa= y=0A= to represent it in a cert, the device is identified by post-cert-use protoc= ols=0A= (e.g. DNP3 when run over TLS).=0A= =0A= The only bit that consistently isn't ignored is the public key.=A0 You=0A= parse/pass over the cert contents until you get to the subjectPublicKeyInfo= ,=0A= then extract what's there and go with that.=0A= =0A= Peter.= From nobody Tue Mar 14 15:55:30 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 B1F1D129BC6 for ; Tue, 14 Mar 2017 15:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bW5EXvvJhvYY for ; Tue, 14 Mar 2017 15:55:27 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF7B1129B4C for ; Tue, 14 Mar 2017 15:55:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 28F57BE80; Tue, 14 Mar 2017 22:55:24 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qx_-Q2D39yEN; Tue, 14 Mar 2017 22:55:23 +0000 (GMT) Received: from [10.87.48.75] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8DE96BE5F; Tue, 14 Mar 2017 22:55:22 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1489532123; bh=ju4Q1L4aoavmSk3DEF09zUP2xtwZqYWZ/f5KS5e/6EY=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=j6z1Q94i/G08+GrIS0zFfpcy1P+SitiEs2GDl2ngnwjWzs2nrznR/0HsOp/dJRWIp HItcV9l+PeBvNl15we28k/f21+BK4GMNxBknPqlGE18xLubhSXcQfU/CoGUvagOvXQ 2I7Wb1UMt6oziOb1y+DKLcz/HE5hXt5OMOaUnnjM= To: Peter Gutmann , Yoav Nir , "Dang, Quynh (Fed)" References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> <1489419619.3159.25.camel@redhat.com> <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> <43102E1B-C072-4CE2-9A3E-CDEDE1536AFB@gmail.com> <0DE34F3E-A2D2-4396-B12C-D9FD30DC3723@gmail.com> <1489531750610.15665@cs.auckland.ac.nz> Cc: Nikos Mavrogiannopoulos , Rich Salz , Curdle From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Tue, 14 Mar 2017 22:55:22 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <1489531750610.15665@cs.auckland.ac.nz> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="gaBgJAebFNuT6L22OGNpVdMj5toE949RK" Archived-At: Subject: Re: [Curdle] Some work for the group 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, 14 Mar 2017 22:55:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gaBgJAebFNuT6L22OGNpVdMj5toE949RK Content-Type: multipart/mixed; boundary="rxx7I6583J9tjAc99xvQ6QGuUaHOKoCJB"; protected-headers="v1" From: Stephen Farrell To: Peter Gutmann , Yoav Nir , "Dang, Quynh (Fed)" Cc: Nikos Mavrogiannopoulos , Rich Salz , Curdle Message-ID: Subject: Re: [Curdle] Some work for the group References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> <1489419619.3159.25.camel@redhat.com> <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> <43102E1B-C072-4CE2-9A3E-CDEDE1536AFB@gmail.com> <0DE34F3E-A2D2-4396-B12C-D9FD30DC3723@gmail.com> <1489531750610.15665@cs.auckland.ac.nz> In-Reply-To: <1489531750610.15665@cs.auckland.ac.nz> --rxx7I6583J9tjAc99xvQ6QGuUaHOKoCJB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 14/03/17 22:49, Peter Gutmann wrote: > (I'm currently involved in a > discussion over whether setting an expiry year of '9999' is valid accor= ding to > the X.509 spec), We standardised a value for "never." I forget where that's defined but I bet Russ knows:-) S. --rxx7I6583J9tjAc99xvQ6QGuUaHOKoCJB-- --gaBgJAebFNuT6L22OGNpVdMj5toE949RK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYyHTaAAoJEC88hzaAX42iUQEH/1SMfpw/MdlUqM/2qkdnVllr 0QrMXC6MLnTZ8FnOObPEWpIkYfThrb5jgIHgYCxh5wNQo6v/khM8TAEArolcOdTv cagExIoEjAoUGrcVw85jmzQLZYCji3dn6OLkCCQXJdKEuT5WGHClU52Xnd2yjBli 8Lfqte0BSRYZQSzv10gpI1CVlpNGk+MTrMtfGaJ/fypCfGhe1o8DPOZGb4tABs4T S9Os2i2KXzdL0jf2RMy/GaNy5gPPC+R6+ZBx1cib5vSDNU5CnW/pMssxFN8kfEF1 oiJVq5UeMzGl/BynDQxJY6CzALMejaQShsh6if+4h7FDL9LJTzt5yFVxoKjzmnk= =+Da3 -----END PGP SIGNATURE----- --gaBgJAebFNuT6L22OGNpVdMj5toE949RK-- From nobody Tue Mar 14 15:58: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 F19CA129B4C for ; Tue, 14 Mar 2017 15:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSke7xI2DyGi for ; Tue, 14 Mar 2017 15:58:36 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBCC7129440 for ; Tue, 14 Mar 2017 15:58:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 49C0DBE80; Tue, 14 Mar 2017 22:58:35 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXJ-9T37b114; Tue, 14 Mar 2017 22:58:33 +0000 (GMT) Received: from [10.87.48.75] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 16AB4BE7C; Tue, 14 Mar 2017 22:58:33 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1489532313; bh=ipCFZIRM0wuzN9UGPOdXE5O17xvigN+y7AaVOZdmSMQ=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=xzUiwOjtRmcwa7UMLRBNa1a/abEGbhP1RLQU6ZnbmTXmKeNnaEGQR0xIAd1OXn/AD xh6XOTnpiSJPAJrKwz26bh5DxPeDHlyIPI2suty/M4zzSOo2/2S7JRkNM0qgapOF3p NeiSmIqNwN8JHuwxPUshl/e4fxXJD27iP1WaIA6g= To: Peter Gutmann , Yoav Nir , "Dang, Quynh (Fed)" References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> <1489419619.3159.25.camel@redhat.com> <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> <43102E1B-C072-4CE2-9A3E-CDEDE1536AFB@gmail.com> <0DE34F3E-A2D2-4396-B12C-D9FD30DC3723@gmail.com> <1489531750610.15665@cs.auckland.ac.nz> Cc: Nikos Mavrogiannopoulos , Rich Salz , Curdle From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5aeb75ca-fc99-6728-4efe-b3c92223e8d3@cs.tcd.ie> Date: Tue, 14 Mar 2017 22:58:32 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="l5OiH9PQDCrwcDx4DjFBV1nKVG5Ec6SoV" Archived-At: Subject: Re: [Curdle] Some work for the group 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, 14 Mar 2017 22:58:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --l5OiH9PQDCrwcDx4DjFBV1nKVG5Ec6SoV Content-Type: multipart/mixed; boundary="a0gUAHxCorJbxiPkxXihP9RF6NIpuaMJ7"; protected-headers="v1" From: Stephen Farrell To: Peter Gutmann , Yoav Nir , "Dang, Quynh (Fed)" Cc: Nikos Mavrogiannopoulos , Rich Salz , Curdle Message-ID: <5aeb75ca-fc99-6728-4efe-b3c92223e8d3@cs.tcd.ie> Subject: Re: [Curdle] Some work for the group References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> <1489419619.3159.25.camel@redhat.com> <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> <43102E1B-C072-4CE2-9A3E-CDEDE1536AFB@gmail.com> <0DE34F3E-A2D2-4396-B12C-D9FD30DC3723@gmail.com> <1489531750610.15665@cs.auckland.ac.nz> In-Reply-To: --a0gUAHxCorJbxiPkxXihP9RF6NIpuaMJ7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 14/03/17 22:55, Stephen Farrell wrote: >=20 >=20 > On 14/03/17 22:49, Peter Gutmann wrote: >> (I'm currently involved in a >> discussion over whether setting an expiry year of '9999' is valid acco= rding to >> the X.509 spec), >=20 > We standardised a value for "never." I forget where that's defined > but I bet Russ knows:-) Ah - there it is, in 5280:-) [1] " To indicate that a certificate has no well-defined expiration date, the notAfter SHOULD be assigned the GeneralizedTime value of 99991231235959Z. " S. [1] https://tools.ietf.org/html/rfc5280#section-4.1.2.5 >=20 > S. >=20 >=20 >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle >=20 --a0gUAHxCorJbxiPkxXihP9RF6NIpuaMJ7-- --l5OiH9PQDCrwcDx4DjFBV1nKVG5Ec6SoV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYyHWYAAoJEC88hzaAX42ii5cIAJF7p8L1RBE/PA4fh1lyewnP 79nLbriZ0lGw03uqiBTe0VCpt2/8fF5Cq/oC3yMQfvEseydVrf4tT1pc9q7Xp4Mj ebeBbUiJLzhKtZeEx3PFc/As8O9bfJ7khbwfc05ILOTTTPEEZGNYkGwBzQE8D5Xy v1D0wUBSanLJjAAxjalDI/wVAdmV5ULpwooRAkSMpAd39VF64wbZQ510IUjxC4Gg h4t0jPYVbmpxYygiAX6TJRQdumFIh3uWD/zCOqDUf4tFVJaGw+Bo+w9BEcbWqsP2 w4nsKzLBZ9Q4CRNnrtBkRtKIk2ua2VHCOKpcpY/Pgpa2NYvTI8xhPhv4FSbQ1RQ= =44Iw -----END PGP SIGNATURE----- --l5OiH9PQDCrwcDx4DjFBV1nKVG5Ec6SoV-- From nobody Tue Mar 14 16:04: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 DD0D5129BC6 for ; Tue, 14 Mar 2017 16:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[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 IcWyt66bbU0D for ; Tue, 14 Mar 2017 16:04:52 -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 3971E129440 for ; Tue, 14 Mar 2017 16:04:52 -0700 (PDT) X-AuditID: c618062d-d73ff700000009d8-23-58c88820db4c Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by (Symantec Mail Security) with SMTP id 6E.0B.02520.02888C85; Wed, 15 Mar 2017 01:17:37 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0319.002; Tue, 14 Mar 2017 19:04:49 -0400 From: Daniel Migault To: 'Russ Housley' , 'Rich Salz' CC: "'curdle@ietf.org'" Thread-Topic: [Curdle] Progressing with draft-ietf-curdle-cms-ecdh-new-curves Thread-Index: AQHSlpKFJ/gWWK7n0UiSLwMk+HMA2qGNSzAAgAAw9QCAAR1RgIAABFXQgAXxrtA= Date: Tue, 14 Mar 2017 23:04:49 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118BA5E71@eusaamb107.ericsson.se> References: <148880412594.6555.2087937598510853337.idtracker@ietfa.amsl.com> <75669986-8814-421C-94E4-60428544D69C@vigilsec.com> <6C7D22F4-0918-4EF4-B2A4-249061CD49D5@vigilsec.com> <727936E0-E1E4-42B0-BB5A-D3EFB23ED034@vigilsec.com> <2DD56D786E600F45AC6BDE7DA4E8A8C118BA41A1@eusaamb107.ericsson.se> In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C118BA41A1@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyuXRPlK5ix4kIg49PTSy2LpzFbPHqxU12 i/9bOlkcmD0mH1nA7LFkyU8mj1V3vrAGMEdx2aSk5mSWpRbp2yVwZfzv/cVa0MFb8fHVe+YG xtNcXYycHBICJhKvFl9j6WLk4hASWM8oMWd3MyOEs5xR4lDDOiaQKjYBI4m2Q/3sILaIgKfE 0e/fWEFsZgFNiZOT54LFhQV8JN4fuAhkcwDV+Er8a8mHKPeTmLR1AdgYFgFVie/f25lBbF6g kjmvH4KNERL4zSRxfoYBiM0JVP/k2A+wOKOAmMT3U2uYIFaJS9x6Mp8J4mgBiSV7zjND2KIS Lx//Y4WwlSQ+/p7PDlGvI7Fg9yc2CFtbYtnC11B7BSVOznzCMoFRdBaSsbOQtMxC0jILScsC RpZVjBylxQU5uelGBpsYgRFyTIJNdwfj/emehxgFOBiVeHgLWE9ECLEmlhVX5h5ilOBgVhLh jc4CCvGmJFZWpRblxxeV5qQWH2KU5mBREueNW30/XEggPbEkNTs1tSC1CCbLxMEp1cBoNjeh adL2+G790LU7Z5/eKll0/Ysow4V0dWdG0085BobMXPOL2P1Vlp6dqVrM3FS/2uJnRnr6njY1 wfLNdbM6VNPamtsYGrIFZc72np8jsst2KmtqUaDoY788z74Ingbm+SlvBDh9r0px7roybfq+ 3vn/HDQCTZRd3mc3TfVWurnLKfoBpxJLcUaioRZzUXEiANbNaRiMAgAA Archived-At: Subject: Re: [Curdle] Progressing with draft-ietf-curdle-cms-ecdh-new-curves 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, 14 Mar 2017 23:04:54 -0000 Hi,=20 We have seen no support for option 1 and we are missing contact information= to move forward with this option. As a result, we chose to go with option = 2.=20 Yours,=20 Rich and Daniel -----Original Message----- From: Daniel Migault=20 Sent: Friday, March 10, 2017 4:33 PM To: Russ Housley ; Rich Salz Cc: curdle@ietf.org Subject: RE: [Curdle] Progressing with draft-ietf-curdle-cms-ecdh-new-curve= s Hi,=20 Please provide your preference by Tuesday March 14.=20 (1) get the OIDs from the same arc that was used in curdle-pkix; or (2) get the OIDs from the S/MIME arc manages by IANA. Yours,=20 Daniel -----Original Message----- From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Russ Housley Sent: Friday, March 10, 2017 11:14 AM To: Rich Salz Cc: curdle@ietf.org Subject: Re: [Curdle] Progressing with draft-ietf-curdle-cms-ecdh-new-curve= s Rich: >> We really need to sort this issue. The S/MIME 4.0 specification has=20 >> a MUST dependency on draft-ietf-curdle-cms-ecdh-new-curves, and it=20 >> cannot be implemented unless object identifiers are assigned. >=20 > You want the chairs to just pick an arc? Or do you have a preference tha= t you'd like the WG to use? Or the wg-chairs to pressure for? I think we have two choices: (1) get the OIDs from the same arc that was used in curdle-pkix; or (2) get the OIDs from the S/MIME arc manages by IANA. Either one works for me. Russ _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle From nobody Tue Mar 14 16:11:29 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 99461129B23 for ; Tue, 14 Mar 2017 16:11:27 -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 Pg4LDZIvu3te for ; Tue, 14 Mar 2017 16:11:26 -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 24F60129440 for ; Tue, 14 Mar 2017 16:11:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 774B73004E6 for ; Tue, 14 Mar 2017 19:11:25 -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 b5IdSKJO1gws for ; Tue, 14 Mar 2017 19:11:23 -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 36122300483; Tue, 14 Mar 2017 19:11:23 -0400 (EDT) From: Russ Housley Message-Id: <2DFA84BC-7BDA-4EEC-AF7D-A90B14B7E1E6@vigilsec.com> Content-Type: multipart/signed; boundary="Apple-Mail=_82A8EECE-6540-4868-AA59-2FDA63E872B7"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Tue, 14 Mar 2017 19:11:19 -0400 In-Reply-To: Cc: Yoav Nir , Quynh Dang , Nikos Mavrogiannopoulos , Rich Salz , Curdle To: Stephen Farrell , Peter Gutmann References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> <1489419619.3159.25.camel@redhat.com> <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> <43102E1B-C072-4CE2-9A3E-CDEDE1536AFB@gmail.com> <0DE34F3E-A2D2-4396-B12C-D9FD30DC3723@gmail.com> <1489531750610.15665@cs.auckland.ac.nz> X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Curdle] Some work for the group 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, 14 Mar 2017 23:11:28 -0000 --Apple-Mail=_82A8EECE-6540-4868-AA59-2FDA63E872B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Mar 14, 2017, at 6:55 PM, Stephen Farrell = wrote: >=20 > On 14/03/17 22:49, Peter Gutmann wrote: >> (I'm currently involved in a >> discussion over whether setting an expiry year of '9999' is valid = according to >> the X.509 spec), >=20 > We standardised a value for "never." I forget where that's defined > but I bet Russ knows:-) To indicate that a certificate has no well-defined expiration date, the notAfter SHOULD be assigned the GeneralizedTime value of 99991231235959Z. Russ --Apple-Mail=_82A8EECE-6540-4868-AA59-2FDA63E872B7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAljIeJoACgkQiuTu0PWcEct/xgCfbAk/KoVlxbhqLQpFCgzMS9GH vjkAn2bGo8eGe5XhvlGeva4T5hBdbXQB =G7ge -----END PGP SIGNATURE----- --Apple-Mail=_82A8EECE-6540-4868-AA59-2FDA63E872B7-- From nobody Tue Mar 14 19:25:20 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 6F2D5131838 for ; Tue, 14 Mar 2017 19:25:18 -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 O2wjyV4Zrj78 for ; Tue, 14 Mar 2017 19:25:16 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9185A131837 for ; Tue, 14 Mar 2017 19:25:16 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id p64so3160588qke.1 for ; Tue, 14 Mar 2017 19:25:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6kc4X3As7L4EoIWUo5HXwK9Nx57Nwig98jWdm4cHI2M=; b=KIVG+B4mvhkFxCmiczMpA76sgp9j7EzTHx1RQrw1bKf5ta8xbRC4fOmSp5IclNBbJ4 EfPcVvqxkcp2Yty9GzquFacjXjpK2JQyv3PdgHLsHAs+btTtOajkHrc4PuFScGPWAsC2 zBk+X6bAYMokXuwjqbeZyPrgOaM0J395qJi7gWP0fPXteIgFPhQ3ktkwjInMN2fGI1C1 God4fF7H0pyVsiF5qJcBB1af0Ree5LsBdffpvMS0VnV/9xiysdOfBKWGgtcEkJCxId3c Rz3JwymaEog7w5aDCOkqFwKSREMRDAUKTPxEwpcmP6yJkfNi2KuQ/VfYFfszToLDC+Is 9tjw== 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=6kc4X3As7L4EoIWUo5HXwK9Nx57Nwig98jWdm4cHI2M=; b=d78f41nmNg6QGzBnkwABYc+IWadLCPW+FPCyhWgSH29RIerOVOUrK5llH4jKMWsf1j +wyuwZv2zvVA1ODbO/MkcCt8ke5Z19CYsESJpLURHn0cV4pYX3/meTKnXnzPfmaSRmtB stfPIE8+of+pAkEH0IxiYnJjznQcJW76yCjf4V7RQVqzeqAT/dsTRK3us6vL/R7Psf3l x7Co7/N3qv0naKFLCt6Q91eX2p2+95usDV37nDI/1EmT9auUZdwpfZApOtL2+8HM5LzQ HXWmcnL3VAuoCaf8Q8F+exFK0BjZb4Rfk7fAP4PHJLH5d2ar44p7K/EpBvEZqwqJbZ9I ad7Q== X-Gm-Message-State: AFeK/H2QAtBUtVjBZDxqAP6GpT4G3v013G2SmeRYjCeSZA5KpSnzc2JYLN9PvcXEP8qpOg== X-Received: by 10.55.7.138 with SMTP id 132mr859819qkh.114.1489544715769; Tue, 14 Mar 2017 19:25:15 -0700 (PDT) Received: from [192.168.1.2] (pool-74-96-119-167.washdc.fios.verizon.net. [74.96.119.167]) by smtp.gmail.com with ESMTPSA id 63sm365422qta.37.2017.03.14.19.25.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Mar 2017 19:25:14 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: santosh.chokhani@gmail.com X-Mailer: iPhone Mail (14D27) In-Reply-To: <566c222d539d4685941fabbc168c9699@usma1ex-dag1mb1.msg.corp.akamai.com> Date: Tue, 14 Mar 2017 22:25:13 -0400 Cc: "Dang, Quynh (Fed)" , Russ Housley , Curdle Content-Transfer-Encoding: quoted-printable Message-Id: References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> <1489419619.3159.25.camel@redhat.com> <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> <43102E1B-C072-4CE2-9A3E-CDEDE1536AFB@gmail.com> <0DE34F3E-A2D2-4396-B12C-D9FD30DC3723@gmail.com> <2E96A8A2-923A-4597-A175-2581966C0F1E@vigilsec.com> <613a973ed0e347a1bcaed5082b7731ae@usma1ex-dag1mb1.msg.corp.akamai.com> <2a1c4915e6af4775bdc8eb9637513245@usma1ex-dag1mb1.msg.corp.akamai.com> <566c222d539d4685941fabbc168c9699@usma1ex-dag1mb1.msg.corp.akamai.com> To: "Salz, Rich" Archived-At: Subject: Re: [Curdle] Some work for the group 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, 15 Mar 2017 02:25:18 -0000 It complicates the clients by requiring the client to make sure that it got t= he correct partition. Sent from my iPhone On Mar 14, 2017, at 1:53 PM, Salz, Rich wrote: >> This creates things more complicated and more room for errors for both si= des unnecessarily.=20 >=20 > Since the replying party already needs to know about crlDP, how does it co= mplicate clients? I can see that it is a bit more work for CA's. >=20 >> The point is which option works better. >=20 > There are many metrics to consider, including if having two algorithms glo= bally deployed is part of being better. >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Tue Mar 14 19:26: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 354A4131838 for ; Tue, 14 Mar 2017 19:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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, RP_MATCHES_RCVD=-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=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 5V7jm948Q2nw for ; Tue, 14 Mar 2017 19:26:34 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 3FEB1131824 for ; Tue, 14 Mar 2017 19:26:34 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 8D6BC433441; Wed, 15 Mar 2017 02:26:33 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 772AA43340D; Wed, 15 Mar 2017 02:26:33 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1489544793; bh=7JoSBL/KSkBu1D0rGtUwsz/g711CPEgHxPZPxE5fbuU=; l=217; h=From:To:CC:Date:References:In-Reply-To:From; b=zh+8nJ0ATCLC61G1MEXeUBhjt5QOXjeTMl5ISjpJ44QunLJC+Lor/lbEPFmejPaxa Xy7+eEfpUx7OuXAyvCX2+U27TZOAOwq2c5PYJdssuMSWoLYimvFotjWXeQqjzNXv36 zbyF/S4kof5mS7aC7R64oDxv6BdSDeNiesvwjoNs= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 6BC331FC8D; Wed, 15 Mar 2017 02:26:33 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 14 Mar 2017 19:26:32 -0700 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.1178.000; Tue, 14 Mar 2017 22:26:32 -0400 From: "Salz, Rich" To: "santosh.chokhani@gmail.com" CC: "Dang, Quynh (Fed)" , Russ Housley , Curdle Thread-Topic: [Curdle] Some work for the group Thread-Index: AQHScQapPZALJc3H1k6dKeAsT1IqsaFPVh8AgABRoQCAB4KXgIAbEqWAgABR0gCAGx+/AIABO9kAgAADkQCABIPiAIAAD2SA//+9XyCAAF7qgIABNbGAgAANNACAAAIKAIAAJ0QAgAAhbwD//75lgIAARb0A//+9IvAACOxnAAAHy6XQAAqymoAACFms0A== Date: Wed, 15 Mar 2017 02:26:32 +0000 Message-ID: <834e94815b1d4bf883f9a54e8698c81c@usma1ex-dag1mb1.msg.corp.akamai.com> References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> <1489419619.3159.25.camel@redhat.com> <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> <43102E1B-C072-4CE2-9A3E-CDEDE1536AFB@gmail.com> <0DE34F3E-A2D2-4396-B12C-D9FD30DC3723@gmail.com> <2E96A8A2-923A-4597-A175-2581966C0F1E@vigilsec.com> <613a973ed0e347a1bcaed5082b7731ae@usma1ex-dag1mb1.msg.corp.akamai.com> <2a1c4915e6af4775bdc8eb9637513245@usma1ex-dag1mb1.msg.corp.akamai.com> <566c222d539d4685941fabbc168c9699@usma1ex-dag1mb1.msg.corp.akamai.com> 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.35.10] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Curdle] Some work for the group 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, 15 Mar 2017 02:26:35 -0000 > It complicates the clients by requiring the client to make sure that it g= ot the > correct partition. It is in the certificate as the crlDistributionPoint extension, which the c= lient should already handle From nobody Tue Mar 14 19:36: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 C13AF129408 for ; Tue, 14 Mar 2017 19:36:23 -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 ywhRDqNS9hSE for ; Tue, 14 Mar 2017 19:36:22 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d: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 02A9D129468 for ; Tue, 14 Mar 2017 19:36:22 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id y76so3293446qkb.0 for ; Tue, 14 Mar 2017 19:36:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XAnqb1cqn02pi9wB1lalUW9PodbL+CnoN+jpuKufudg=; b=uq1a4SuHj0vPtqoK56C653HIDwxDtQDXtkCiLDhNySjh22c16S9kFIetsSVr2mqOcE vm7FNOykmbrJfF6wRJBnPv4memQQW6CyxSIhDvh5/ttsd3qRdDMoiuCNnYoO4A9mMT8b 42kMVmlqf4yTHc3jMPRaYXzNB+rM4x/xD91ZW/I3uQs25y40lTaTRDJZRKUXHGLDrkae kcRlST1l2Pk5aCVPTRQfpIKaJSHwdDCbgKbrBBfeoB+w/3Jao57UJsqvCpe2B1ya95lu WkPLNlj4Re9TZgTNgr5ySKeywK2fHN6b7k1T/dYJ/N4GyZC7oqam6kEEDyJsKwidhoWp /aPA== 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=XAnqb1cqn02pi9wB1lalUW9PodbL+CnoN+jpuKufudg=; b=DriHGhWuF/iS12PQXRFxTqTuBkYsamMzTr/JfBeR6oWGmQKhkaJbMBqi8wUJ99eVkX 5LTp3UMRoOqmVSRuQ740kHnP1ArI8Cs3G68j1mSv7vlLS7/haGF+jYcQpPJtPmXozP5h SGrrHhiLqpeUAVHfysolSRp5Tvh/3w1JK7FJdgL9feY/RnRvpy8+N6rvIFXaBy26YLp4 0SomZJtWAIn4iOCp8ZW8ad369ZsgyB4NtCK1bIGA3uvwhFvyHcLhCU6niVY0cnQFtmB3 q3h3VYETYOhtSZIXkuUHBGAJ4AsHW1t4aVREXKx7aM6YqtSVZ7ajJH3V1yi1MRGQtTlW qQRA== X-Gm-Message-State: AFeK/H0GdULQ4B/xulnN6+EbETj8TOykDAtD3eMUXSWDclxEn5KHpNBfqEk8ph3jFWmObg== X-Received: by 10.55.169.135 with SMTP id s129mr774033qke.91.1489545381265; Tue, 14 Mar 2017 19:36:21 -0700 (PDT) Received: from [192.168.1.2] (pool-74-96-119-167.washdc.fios.verizon.net. [74.96.119.167]) by smtp.gmail.com with ESMTPSA id q40sm390463qtq.21.2017.03.14.19.36.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Mar 2017 19:36:20 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: santosh.chokhani@gmail.com X-Mailer: iPhone Mail (14D27) In-Reply-To: <834e94815b1d4bf883f9a54e8698c81c@usma1ex-dag1mb1.msg.corp.akamai.com> Date: Tue, 14 Mar 2017 22:36:19 -0400 Cc: "Dang, Quynh (Fed)" , Russ Housley , Curdle Content-Transfer-Encoding: quoted-printable Message-Id: <8DF51F29-E5FD-4D42-8B6E-F15DF95E5C38@gmail.com> References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> <1489419619.3159.25.camel@redhat.com> <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> <43102E1B-C072-4CE2-9A3E-CDEDE1536AFB@gmail.com> <0DE34F3E-A2D2-4396-B12C-D9FD30DC3723@gmail.com> <2E96A8A2-923A-4597-A175-2581966C0F1E@vigilsec.com> <613a973ed0e347a1bcaed5082b7731ae@usma1ex-dag1mb1.msg.corp.akamai.com> <2a1c4915e6af4775bdc8eb9637513245@usma1ex-dag1mb1.msg.corp.akamai.com> <566c222d539d4685941fabbc168c9699@usma1ex-dag1mb1.msg.corp.akamai.com> <834e94815b1d4bf883f9a54e8698c81c@usma1ex-dag1mb1.msg.corp.akamai.com> To: "Salz, Rich" Archived-At: Subject: Re: [Curdle] Some work for the group 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, 15 Mar 2017 02:36:24 -0000 It probably not relate to the topic at hand but what you say is insufficient= . See RFC 5280 or use common sense=20 When the CA signs bunch of partitions to mitigate substitution attack the ID= P in the partition must be matched with the CDP in the certificate I won't belabor this but suggest you read section 6 of RFC 5280 carefully.=20= Sent from my iPhone On Mar 14, 2017, at 10:26 PM, Salz, Rich wrote: >> It complicates the clients by requiring the client to make sure that it g= ot the >> correct partition. >=20 > It is in the certificate as the crlDistributionPoint extension, which the c= lient should already handle From nobody Tue Mar 14 19:41:57 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 3CBC412946C for ; Tue, 14 Mar 2017 19:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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, RP_MATCHES_RCVD=-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=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 nbAu1bp9Xhu1 for ; Tue, 14 Mar 2017 19:41:55 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 4E024129468 for ; Tue, 14 Mar 2017 19:41:55 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id BFCA1496C1D; Wed, 15 Mar 2017 02:41:54 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id A9DA4496C18; Wed, 15 Mar 2017 02:41:54 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1489545714; bh=XPVZhlA5W6H2+mvMFSOqBI3Dh4lf2EPVZWPJs0jTGpw=; l=423; h=From:To:CC:Date:References:In-Reply-To:From; b=Ex9C9UV3pdKd9FVvuEzmn0shl1TG2Vd0pVwqI1cyIzIEis6w2pCfEsy8dohz47dkF hg2xLs1G1v49O3OKR4kT6tBsQzeQqNjsYCpH2Ji8lraDI9uo/ZT8VTicZG4LVmpO15 qEe2lnaSwk+SDOCLX+tBPsdR1Jer1gEpU/dtiC1k= Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 8E6AA98082; Wed, 15 Mar 2017 02:41:54 +0000 (GMT) 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.1178.4; Tue, 14 Mar 2017 22:41:54 -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.1178.000; Tue, 14 Mar 2017 22:41:53 -0400 From: "Salz, Rich" To: "santosh.chokhani@gmail.com" CC: "Dang, Quynh (Fed)" , Russ Housley , Curdle Thread-Topic: [Curdle] Some work for the group Thread-Index: AQHScQapPZALJc3H1k6dKeAsT1IqsaFPVh8AgABRoQCAB4KXgIAbEqWAgABR0gCAGx+/AIABO9kAgAADkQCABIPiAIAAD2SA//+9XyCAAF7qgIABNbGAgAANNACAAAIKAIAAJ0QAgAAhbwD//75lgIAARb0A//+9IvAACOxnAAAHy6XQAAqymoAACFms0P//wEyAgABCB9A= Date: Wed, 15 Mar 2017 02:41:53 +0000 Message-ID: <4cd9781fe28f4b998d322c722c2dc83e@usma1ex-dag1mb1.msg.corp.akamai.com> References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> <1489419619.3159.25.camel@redhat.com> <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> <43102E1B-C072-4CE2-9A3E-CDEDE1536AFB@gmail.com> <0DE34F3E-A2D2-4396-B12C-D9FD30DC3723@gmail.com> <2E96A8A2-923A-4597-A175-2581966C0F1E@vigilsec.com> <613a973ed0e347a1bcaed5082b7731ae@usma1ex-dag1mb1.msg.corp.akamai.com> <2a1c4915e6af4775bdc8eb9637513245@usma1ex-dag1mb1.msg.corp.akamai.com> <566c222d539d4685941fabbc168c9699@usma1ex-dag1mb1.msg.corp.akamai.com> <834e94815b1d4bf883f9a54e8698c81c@usma1ex-dag1mb1.msg.corp.akamai.com> <8DF51F29-E5FD-4D42-8B6E-F15DF95E5C38@gmail.com> In-Reply-To: <8DF51F29-E5FD-4D42-8B6E-F15DF95E5C38@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.10] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Curdle] Some work for the group 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, 15 Mar 2017 02:41:56 -0000 =20 > I won't belabor this but suggest you read section 6 of RFC 5280 carefully= . Please do explain more. If the key signing an entire CRL is the same as th= e key signing CDP CRL's, and the revocation list is partitioned solely to m= ake it smaller, such as to fit in an IoT lightbulb, then what changes? But separate from that, do you want pre-hash signatures supported? You wou= ld be the second person.=20 From nobody Tue Mar 14 23:24: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 E3B8A1294D7 for ; Tue, 14 Mar 2017 23:24: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, 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 u0zcY8-87EOk for ; Tue, 14 Mar 2017 23:24:24 -0700 (PDT) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::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 22E5A1294F8 for ; Tue, 14 Mar 2017 23:24:24 -0700 (PDT) Received: by mail-wr0-x229.google.com with SMTP id u108so4169770wrb.3 for ; Tue, 14 Mar 2017 23:24:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=tgnOfNyCITTpgmH+ak2K8R7IvOdJkF0XserhYwF7+q8=; b=HK6rjfAB9bcqOL6GJ78J2GTA1+VKnTUM8Jc2mX1aC0nPTe4WVklW9vy0b7vRAvP6vi mXZZ+vcIa1MHu5zq1VPIOq/uUfnzY127mF2ByQFFQtZnRvsYkHmYwoMEyc1UCtvx71wa AQVGvM7RYGnd8SzpD4EDmVCS9u4Alt1eFwAfvD9LOf+gMkmJo25En/VhBwvl+r2BQ2J6 /mrXios1Qp+xS1QK7w38ri04YnAtl0xBWzCcCFCkEDnI/8MG7KDJjrZ1TBpaSV/VbLgv mKveZvPW2NwvDnFOVvPDtqa/vwjbTcKpfxXpIMfFAd9eMo1S7rOCls7VT5dti7gKrsEP SBvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=tgnOfNyCITTpgmH+ak2K8R7IvOdJkF0XserhYwF7+q8=; b=msFG/2SKYsjODIQLXdP+kq01UzkflGTdHfGTlF9DNMsBo6EK85Ha/oOCBBnMOkSfIu 32DEkP1fIgnP4Y6MjM8g6BmxpnNO4hiV81qIYawigLX25pur8MAXVomXFr4J5ysdROQA v0BKvHm/aD3jm7qnwZ168BY4gXp7pGq2i7je16qi/4TC6EvPMRx8x16SZveXU/qU2J7t gd4AEwJYbb/9m24dVuXxECFUOecIQ+I6v+QMGjoAQV149kHpdofM2OUz4mGF7iSWlK8X r+qOGI5GuClDhlxQ+hH7vRZLdICs7wS9p7M0egNOmvc0URiqXMGYIf3Fud6Rjwbho09+ Wizg== X-Gm-Message-State: AFeK/H0ZZI4ETaUi9zuQRCeIGDPnhJnhxZeydOQ+x92G1v6PRMcmiRDIdAvpkWRibi21Wg== X-Received: by 10.223.164.216 with SMTP id h24mr1215781wrb.128.1489559062580; Tue, 14 Mar 2017 23:24:22 -0700 (PDT) Received: from [192.168.137.86] ([109.253.147.134]) by smtp.gmail.com with ESMTPSA id p93sm1018462wrc.67.2017.03.14.23.24.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Mar 2017 23:24:21 -0700 (PDT) From: Yoav Nir Message-Id: <677388C4-1985-444E-9704-E5ACC52E39B9@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_30DCE7BF-67BC-4B9F-A04E-30D198CD3D7B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 15 Mar 2017 08:24:15 +0200 In-Reply-To: <8DF51F29-E5FD-4D42-8B6E-F15DF95E5C38@gmail.com> Cc: Rich Salz , "Dang, Quynh (Fed)" , Curdle , Russ Housley To: santosh.chokhani@gmail.com References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> <1489419619.3159.25.camel@redhat.com> <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> <43102E1B-C072-4CE2-9A3E-CDEDE1536AFB@gmail.com> <0DE34F3E-A2D2-4396-B12C-D9FD30DC3723@gmail.com> <2E96A8A2-923A-4597-A175-2581966C0F1E@vigilsec.com> <613a973ed0e347a1bcaed5082b7731ae@usma1ex-dag1mb1.msg.corp.akamai.com> <2a1c4915e6af4775bdc8eb9637513245@usma1ex-dag1mb1.msg.corp.akamai.com> <566c222d539d4685941fabbc168c9699@usma1ex-dag1mb1.msg.corp.akamai.com> <834e94815b1d4bf883f9a54e8698c81c@usma1ex-dag1mb1.msg.corp.akamai.com> <8DF51F29-E5FD-4D42-8B6E-F15DF95E5C38@gmail.com> X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Curdle] Some work for the group 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, 15 Mar 2017 06:24:26 -0000 --Apple-Mail=_30DCE7BF-67BC-4B9F-A04E-30D198CD3D7B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Santosh Partitioning one big CRL into two CRLs makes things more complicated. = That is true. But partitioning the CRL into 1000 small pieces instead of 100 = medium-sized pieces adds a little processing requirement to the CA, but = no additional complexity for either side. As it is, all CAs partition their CRLs. The complexity already exists on = all sides. And relying parties have to make sure they got the right CRL = anyway since they have no way of knowing whether or not the CA = partitions the CRL. So in summary, CRLs are already partitioned. We don=E2=80=99t think CRL = processing is even a thing on constrained devices, but in case we=E2=80=99= re wrong all that is needed to make CRLs smaller is a tweak of parameter = on the CA with zero additional code. Yoav > On 15 Mar 2017, at 4:36, santosh.chokhani@gmail.com wrote: >=20 > It probably not relate to the topic at hand but what you say is = insufficient. See RFC 5280 or use common sense >=20 > When the CA signs bunch of partitions to mitigate substitution attack = the IDP in the partition must be matched with the CDP in the certificate >=20 > I won't belabor this but suggest you read section 6 of RFC 5280 = carefully. >=20 > Sent from my iPhone >=20 > On Mar 14, 2017, at 10:26 PM, Salz, Rich wrote: >=20 >>> It complicates the clients by requiring the client to make sure that = it got the >>> correct partition. >>=20 >> It is in the certificate as the crlDistributionPoint extension, which = the client should already handle >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle --Apple-Mail=_30DCE7BF-67BC-4B9F-A04E-30D198CD3D7B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJYyN4QAAoJELhJCxUKWMyZY/gH+weAixvpj3YZa8PpCN9h7Ayd UO2SZZPOGCEdSR84/mHf2orRPEQKnFlDkPcGWYWV948E/j4XJDd8n2vRTPfsz2Ik j1iKNzgISUzVOunc5mftk/pX6gvgXnodaz7lULCup/nU9JC68HKZuFXu1Llyipdn gCBoKf4VwCZxdhGC6XAk759b6lCyHFQ0Zhq1JSMfIvRXnYnHEGaxfR/s/TRf29UE XMBXyViUcAWAE5z7c/yLOJ1/DbAFQGANR+v6SZUXBDZMyQMCk9gfpF34Vbj/WvBt ucPPItIKZnvhttJxECsVua6UUfix7m6clonmeAF1xsnYZoBsi0Dx3WiCxfeuhIA= =rQ5i -----END PGP SIGNATURE----- --Apple-Mail=_30DCE7BF-67BC-4B9F-A04E-30D198CD3D7B-- From nobody Wed Mar 15 09:49: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 EC960131715 for ; Wed, 15 Mar 2017 09:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=docusign2com.onmicrosoft.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 Gx85oYPFNlmw for ; Wed, 15 Mar 2017 09:49:29 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0117.outbound.protection.outlook.com [104.47.34.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FEA81316A1 for ; Wed, 15 Mar 2017 09:49:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=DOCUSIGN2COM.onmicrosoft.com; s=selector1-docusign-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5L1N0z3b1OmMA1p5mrtKwxM90KavffXWKSgSUl9TFJU=; b=BZSJvfObK62tgIepSJpbvoyxm9DLZz0xG4qTmYmdyOw7lP8LiIKQrDJ7ubeyIO5Co0zSvOIJ+eXePdMCvtZq30udAvUVozdmoBQzUxfkQzqvu1r9OKJpc8L92nudMuyoy6JotGWAbwiBG6yxJqXrk78qiM6bfZpSYtaYrn6TB4w= Received: from BN6PR04MB0820.namprd04.prod.outlook.com (10.172.199.13) by BN6PR04MB0821.namprd04.prod.outlook.com (10.172.199.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Wed, 15 Mar 2017 16:49:27 +0000 Received: from BN6PR04MB0820.namprd04.prod.outlook.com ([10.172.199.13]) by BN6PR04MB0820.namprd04.prod.outlook.com ([10.172.199.13]) with mapi id 15.01.0947.020; Wed, 15 Mar 2017 16:49:27 +0000 From: Erwann Abalea To: Peter Gutmann CC: Yoav Nir , "Dang, Quynh (Fed)" , Nikos Mavrogiannopoulos , Rich Salz , Curdle Thread-Topic: [Curdle] Some work for the group Thread-Index: AQHSnawbC99O1fEtmUmh0p1q5qL8BQ== Date: Wed, 15 Mar 2017 16:49:27 +0000 Message-ID: <7C8644BA-F890-4A1A-886B-50AC1A43D9A7@docusign.com> References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> <1489419619.3159.25.camel@redhat.com> <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> <43102E1B-C072-4CE2-9A3E-CDEDE1536AFB@gmail.com> <0DE34F3E-A2D2-4396-B12C-D9FD30DC3723@gmail.com> <1489531750610.15665@cs.auckland.ac.nz> In-Reply-To: <1489531750610.15665@cs.auckland.ac.nz> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cs.auckland.ac.nz; dkim=none (message not signed) header.d=none;cs.auckland.ac.nz; dmarc=none action=none header.from=docusign.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [84.14.125.226] x-ms-office365-filtering-correlation-id: c109954d-9923-4507-42e2-08d46bc33e6e x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR04MB0821; x-microsoft-exchange-diagnostics: 1; BN6PR04MB0821; 7:9pwqKvEvADWtN748jk5NHnt6iXiuPx8p0jkWI+4j4lGIyj6+II3txMalFkf1+JuuaMgWW15pFi4d0TUNC/XBuQLXggf5u3wvo/+PJVOhvH/YVUklH7zAYs5yuygyoVrm3twrViSSp5Qvf9oV4M/H+8OURqb8nQY3/E00whoznv/+RDgcBMw3UT1tfeMhIZUP/4dH59TuwbqD6XAeTKRhB6nEf0fp/Qp7eNY99Q+uOP0C0EXybuj/uVyuHDwlYgvGcLJDp+s+dcds0AnecyAxdv8Daa+1Gdgiu9PZ79UXrxsS+95JpHj2WBV6okLreLVp2GTD96GInkp8iiowGzM3tw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123555025)(20161123564025)(20161123560025)(20161123558025)(20161123562025)(6072148); SRVR:BN6PR04MB0821; BCL:0; PCL:0; RULEID:; SRVR:BN6PR04MB0821; x-forefront-prvs: 02475B2A01 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39410400002)(39830400002)(52314003)(6506006)(229853002)(38730400002)(110136004)(2900100001)(8676002)(305945005)(83716003)(6436002)(86362001)(77096006)(66066001)(3660700001)(82746002)(53936002)(25786008)(6486002)(8656002)(93886004)(99286003)(6512007)(4326008)(54906002)(6246003)(39060400002)(102836003)(36756003)(2950100002)(8936002)(6116002)(3280700002)(2906002)(6916009)(76176999)(5660300001)(3846002)(54356999)(50986999)(33656002)(81166006)(7736002)(122556002)(189998001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR04MB0821; H:BN6PR04MB0820.namprd04.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-ID: <732271903BF4994282959B12B11E3853@namprd04.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: docusign.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Mar 2017 16:49:27.4569 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 237e701c-327f-4cad-a5a1-dda2412d89d9 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR04MB0821 Archived-At: Subject: Re: [Curdle] Some work for the group 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, 15 Mar 2017 16:49:33 -0000 > Le 14 mars 2017 =E0 23:49, Peter Gutmann a = =E9crit : >=20 > Yoav Nir writes: >=20 >> It seems odd to me to believe that embedded systems will process CRLs in= a >> time where web browsers running on PCs have stopped doing that. Even if = they >> do, making really small CRLs for them seems like a good idea. But stapl= ing >> OCSP responses seems like an even better idea. >=20 > SCADA stuff typically doesn't process CRLs, but for an entirely different > reason than you think. If you revoke a process controller's cert, it can= take > it offline, which is the worst thing that can happen. So CRLs are ignore= d, as > is OCSP. Expiry dates in certs are also ignored (I'm currently involved = in a > discussion over whether setting an expiry year of '9999' is valid accordi= ng to > the X.509 spec), 31/12/9999 is a valid date (so far). 31/12/1999 23:59:59 may not exist (we don=92t know yet if a negative leap s= econd will be introduced), and it may not be the last second of the day (po= sitive leap second). However, as a magical value, 99992131235959Z is a corr= ect GeneralizedTime. 99991231235960 is also a correct GeneralizedTime. 99991231240000 isn=92t. Anyway, for X.509, the nextUpdate field of a CRL is optional. Only RFC2459+= makes it mandatory. X.509 CRL processing algorithm (Annex C) correctly handles a missing nextUp= date. Cordialement, Erwann Abalea From nobody Wed Mar 15 09:56:30 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 CFEDD13171C for ; Wed, 15 Mar 2017 09:56:28 -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 jxcxcLsMyXs0 for ; Wed, 15 Mar 2017 09:56:27 -0700 (PDT) Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::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 EF1AB1316A1 for ; Wed, 15 Mar 2017 09:56:26 -0700 (PDT) Received: by mail-wm0-x241.google.com with SMTP id x124so14348wmf.3 for ; Wed, 15 Mar 2017 09:56:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=vDuwmTx2Jw18F39h5dd2doaZwPG7sAeSEkAt6AhitK0=; b=FqfkVGAetzf5oP4kP5yY64WripdNCpf4tf+U2QFizvt5Q7FIyAYCdIefMcwvX0NYdI 0bqQEFnLfNvh8wlgLieWuTI5/UGaimuJrT8S7enf5J+VDWm2+DTt0/uWg6ee2guOwZ55 73E3UQ10C9Sk7aK/p8EDN9nGgyGBp/tA1lLdc7MP5gaq4pn1S8klxIHwuSXvC+BHbWLs BWjfEmqCaMw0CD6g1mrpzWGmLtlhWaepkvU+NMc89tNzTINFDYIL12/Va+cteOKO+MbY NKcEMEJebIVllKjz8ijZA7EG7euhjPyNsVtYF0rTbyNbN/u+sOgv10UScUKh3ncLDExu Ta0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=vDuwmTx2Jw18F39h5dd2doaZwPG7sAeSEkAt6AhitK0=; b=AOhOUocvLx0wg32QH7FvJMyynm2ODIYOB58Eg1qRqLtgQicl6ClSWm4THSQtW1BC7O CZIrbfe3irSGBhUFQt0WL0YP+VC1VoEdvgpaAsTQpfF60sR+K7LhtdOatp8sQGVwJkMj i0xU/aWak7mKJ+rV7sQPdI3kWNn6cJKoofpLmM91M94gY8j6XbDi1tsv+wPmZGJVM8I8 ZG06GHfY1CbFmyaXGjJACA+YNWlHo7Oq4+H8Z+kxhU4rU2pM5o73jqZFkrr5wUVVLBCw DIyuVGGC+hQtOIbpShIyCdgje1dWg8Mo/boKl3YWtzu/gZ4XUvFyE5RzZsIOJtT5LMq0 Ypkg== X-Gm-Message-State: AFeK/H3Qgp+3JGsqnBeQorQVKJzBm8DJtf21B4LsU9Er4Vy6W2v2Esv4QUN/Abcxt1Dtbg== X-Received: by 10.28.197.133 with SMTP id v127mr19144783wmf.120.1489596985496; Wed, 15 Mar 2017 09:56:25 -0700 (PDT) Received: from [192.168.137.86] ([109.253.147.134]) by smtp.gmail.com with ESMTPSA id s18sm1145287wmb.18.2017.03.15.09.56.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Mar 2017 09:56:24 -0700 (PDT) From: Yoav Nir Message-Id: <688F96A1-4CDC-42C3-B240-075D79D78A9C@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_77D3E26D-2F68-47F2-9A7F-431AF281B037"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 15 Mar 2017 18:56:20 +0200 In-Reply-To: <7C8644BA-F890-4A1A-886B-50AC1A43D9A7@docusign.com> Cc: Peter Gutmann , "Dang, Quynh (Fed)" , Nikos Mavrogiannopoulos , Rich Salz , Curdle To: Erwann Abalea References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> <1489419619.3159.25.camel@redhat.com> <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> <43102E1B-C072-4CE2-9A3E-CDEDE1536AFB@gmail.com> <0DE34F3E-A2D2-4396-B12C-D9FD30DC3723@gmail.com> <1489531750610.15665@cs.auckland.ac.nz> <7C8644BA-F890-4A1A-886B-50AC1A43D9A7@docusign.com> X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Curdle] Some work for the group 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, 15 Mar 2017 16:56:29 -0000 --Apple-Mail=_77D3E26D-2F68-47F2-9A7F-431AF281B037 Content-Type: multipart/alternative; boundary="Apple-Mail=_EE9C58A5-A176-49B1-91D9-9D442B483C37" --Apple-Mail=_EE9C58A5-A176-49B1-91D9-9D442B483C37 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 15 Mar 2017, at 18:49, Erwann Abalea = wrote: >=20 >>=20 >> Le 14 mars 2017 =C3=A0 23:49, Peter Gutmann = a =C3=A9crit : >>=20 >> Yoav Nir writes: >>=20 >>> It seems odd to me to believe that embedded systems will process = CRLs in a >>> time where web browsers running on PCs have stopped doing that. Even = if they >>> do, making really small CRLs for them seems like a good idea. But = stapling >>> OCSP responses seems like an even better idea. >>=20 >> SCADA stuff typically doesn't process CRLs, but for an entirely = different >> reason than you think. If you revoke a process controller's cert, it = can take >> it offline, which is the worst thing that can happen. So CRLs are = ignored, as >> is OCSP. Expiry dates in certs are also ignored (I'm currently = involved in a >> discussion over whether setting an expiry year of '9999' is valid = according to >> the X.509 spec), >=20 > 31/12/9999 is a valid date (so far). > 31/12/1999 23:59:59 may not exist I was there=E2=80=A6 ;-) --Apple-Mail=_EE9C58A5-A176-49B1-91D9-9D442B483C37 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 15 Mar 2017, at 18:49, Erwann Abalea <Erwann.Abalea@docusign.com> wrote:


Le 14 mars 2017 =C3=A0 23:49, Peter = Gutmann <pgut001@cs.auckland.ac.nz> a =C3=A9crit :

Yoav Nir <ynir.ietf@gmail.com>= writes:

It seems odd to me to believe that embedded systems will = process CRLs in a
time where web browsers running on PCs = have stopped doing that. Even if they
do, making really = small CRLs for them seems like a good idea.  But stapling
OCSP responses seems like an even better idea.

SCADA stuff typically doesn't = process CRLs, but for an entirely different
reason than = you think.  If you revoke a process controller's cert, it can = take
it offline, which is the worst thing that can happen. =  So CRLs are ignored, as
is OCSP.  Expiry dates = in certs are also ignored (I'm currently involved in a
discussion over whether setting an expiry year of '9999' is = valid according to
the X.509 spec),

31/12/9999 is a valid date (so far).
31/12/1999 23:59:59 = may not exist

I was = there=E2=80=A6

;-)
= --Apple-Mail=_EE9C58A5-A176-49B1-91D9-9D442B483C37-- --Apple-Mail=_77D3E26D-2F68-47F2-9A7F-431AF281B037 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJYyXI1AAoJELhJCxUKWMyZBD4IAL5GkeWH7zgW82jxkPMUAGMW pXTI6r5WyGXJTin51joBd1MUlU7MjVyYVpAl8zTDMsfsa+bMbCEeBL56fDQ+cslz UPokXL/MlNBZVEM4aFhWM8UjOsnf1D7lmk2HrI94SzrSBu/Ohtr9iqHABfH+Oyhr U3YUtRTSgIxvWyrUCzNINoEnAsC0xvEtKPD/Ga3NW8J6vEP183epvBW0k7a/ldDR NJIGzQaWYDqhvD4AdahQQuGYmOnfJNzzF9Fsk8D52opdtoiUJW+pdfHPofUGga1F A0UpbmKxyJjIFibrLPDAc1R0JegTiUZh5pOzPYMd3qwWSfqI7qYKOjRWJUus7GA= =MGcY -----END PGP SIGNATURE----- --Apple-Mail=_77D3E26D-2F68-47F2-9A7F-431AF281B037-- From nobody Wed Mar 15 10:10: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 3A397131726 for ; Wed, 15 Mar 2017 10:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.697 X-Spam-Level: X-Spam-Status: No, score=-4.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, 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=docusign2com.onmicrosoft.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 oGqSd11RXcSf for ; Wed, 15 Mar 2017 10:10:21 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0138.outbound.protection.outlook.com [104.47.34.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12513131720 for ; Wed, 15 Mar 2017 10:10:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=DOCUSIGN2COM.onmicrosoft.com; s=selector1-docusign-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vtKZRiPgy68JQzC//gdtmkgpLnweQRGnmZqO/JQCCo0=; b=AnCWr6OT7rZD6bkdbhkphx29U7cC/tVMCPwXPI/udemusNRE0k50FP1OkycnAkR5oSDx+5+RIqEz7tMtCnEdChGysi+zjn4oG6tvZtE5/zsRaIAfrkHD4MFhb7ZF2QQi8xVmUCE7h2ovh0qYW987iIFJ7G777UUbymDv5YuXzsg= Received: from BN6PR04MB0820.namprd04.prod.outlook.com (10.172.199.13) by BN6PR04MB0818.namprd04.prod.outlook.com (10.172.199.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Wed, 15 Mar 2017 17:10:18 +0000 Received: from BN6PR04MB0820.namprd04.prod.outlook.com ([10.172.199.13]) by BN6PR04MB0820.namprd04.prod.outlook.com ([10.172.199.13]) with mapi id 15.01.0947.020; Wed, 15 Mar 2017 17:10:18 +0000 From: Erwann Abalea To: Stephen Farrell CC: "Dang, Quynh (Fed)" , Yoav Nir , "rsalz@akamai.com" , Nikos Mavrogiannopoulos , Curdle Thread-Topic: [Curdle] Some work for the group Thread-Index: AQHSna8FC99O1fEtmUmh0p1q5qL8BQ== Date: Wed, 15 Mar 2017 17:10:18 +0000 Message-ID: <1E86BFBF-0A3B-4CF8-998D-AD85B5090599@docusign.com> References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> <1489419619.3159.25.camel@redhat.com> <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> <43102E1B-C072-4CE2-9A3E-CDEDE1536AFB@gmail.com> <44379acc-ccf9-eaf8-31cf-ef2611e9dd0f@cs.tcd.ie> In-Reply-To: <44379acc-ccf9-eaf8-31cf-ef2611e9dd0f@cs.tcd.ie> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cs.tcd.ie; dkim=none (message not signed) header.d=none;cs.tcd.ie; dmarc=none action=none header.from=docusign.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [84.14.125.226] x-ms-office365-filtering-correlation-id: 36657db5-fe04-4bd6-1483-08d46bc6282e x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR04MB0818; x-microsoft-exchange-diagnostics: 1; BN6PR04MB0818; 7:yGaEEwxPn4vspmTph6fO7CIJhNqCGPuWMIGOI1r19/hzxQlJC+g3gfLx4VXgYxSU5jqD7nHbUUmL2WQKGsaM25EPb6+yLVSxokzR2UMRgBMm/6J2ZrsPAD8i0Yvs5Cw1H/9DlfLXO2Ha5/q5iHZTyton1mgR0xidLzxVFRRp9+rMIry0ps4gr1iwIcnmGRAw3v7iOMjo5WftzSVCrvVP+r/yW31fwbUENI+XAaFj6Yn7umUFPU/pdn1n435wQl+uPoIbr2klD5zmzRlosd6b7IJY5fXcCZMLOEIr+IHMd/7pNBbf51ViG5LlXEA798Aatk9Aq8DaMj7OEnJv1eAwsw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(32856632585715)(148322886591682)(65766998875637)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123558025)(20161123560025)(6072148); SRVR:BN6PR04MB0818; BCL:0; PCL:0; RULEID:; SRVR:BN6PR04MB0818; x-forefront-prvs: 02475B2A01 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39410400002)(39830400002)(24454002)(377454003)(8676002)(36756003)(66066001)(2906002)(7736002)(4326008)(6506006)(81166006)(6436002)(6512007)(38730400002)(229853002)(77096006)(189998001)(3660700001)(54356999)(5660300001)(102836003)(99286003)(6116002)(53936002)(6306002)(53546007)(50986999)(33656002)(3846002)(122556002)(76176999)(86362001)(6486002)(54906002)(6246003)(8936002)(2950100002)(83716003)(110136004)(93886004)(82746002)(2900100001)(6916009)(305945005)(39060400002)(25786008)(3280700002)(8656002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR04MB0818; H:BN6PR04MB0820.namprd04.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: docusign.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Mar 2017 17:10:18.6106 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 237e701c-327f-4cad-a5a1-dda2412d89d9 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR04MB0818 Archived-At: Subject: Re: [Curdle] Some work for the group 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, 15 Mar 2017 17:10:25 -0000 Qm9uam91ciwNCg0KPiBMZSAxNCBtYXJzIDIwMTcgw6AgMTk6MzcsIFN0ZXBoZW4gRmFycmVsbCA8 c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT4gYSDDqWNyaXQgOg0KPiANCj4gDQo+IEhpIFF1eW5o LA0KPiANCj4gSSdtIHNvcnJ5IGJ1dCBJJ3ZlIG5vIGlkZWEgaG93IHlvdXIgbWFpbCBpcyByZXNw b25zaXZlIHRvIG1pbmUuDQo+IA0KPiBUbyByZS1pdGVyYXRlOiB0aGVyZSBpcyBJTU8gbm8ganVz dGlmaWNhdGlvbiBhdCBhbGwgZm9yIHByZS1oYXNoDQo+IGJhc2VkIG9uIGNvbnN0cmFpbmVkIGRl dmljZXMgYW5kIENSTHMuDQo+IA0KPiBZb3VyIGFyZ3VtZW50cyB0aGF0IHRoZXJlIGFyZSBhcmUg dW5jb252aW5jaW5nLg0KPiANCj4gQW5kIG5vYm9keSBoYXMgcG9pbnRlZCBhdCBhbnkgcmVhbCBk ZXZpY2UgdGhhdCBkb2VzIG5lZWQNCj4gcHJlLWhhc2guDQoNCkkgZGlkLiBPbiBTYWZlbmV0IEx1 bmFDQTQgKEkgZG9u4oCZdCByZW1lbWJlciB0aGUgZmlybXdhcmUgdmVyc2lvbiksIHNlbmRpbmcg bW9yZSB0aGFuIDIgb3IgM01CIGZvciBzaWduaW5nICh3aXRoIGEgQ0tNX1JTQV9QS0NTIG1lY2hh bmlzbSkgcmV0dXJucyBhbiBlcnJvci4NCkkgZG9u4oCZdCByZW1lbWJlciB0aGUgZXhhY3QgZXJy b3IsIHdlIHN3aXRjaGVkIHRvIGhhc2ggdGhlIHBheWxvYWQgb24gY2FsbGVyIHNpZGUsIGFuZCBJ IGRvbuKAmXQga25vdyBpZiB0aGUgZXJyb3IgcGVyc2lzdHMgd2l0aCBsYXRlciB2ZXJzaW9ucyAo THVuYUNBNCBpcyBhIGRpc2NvbnRpbnVlZCBwcm9kdWN0KS4NCg0KQ29yZGlhbGVtZW50LA0KRXJ3 YW5uIEFiYWxlYQ0KDQo+IA0KPiBDaGVlcnMsDQo+IFMuDQo+IA0KPiBPbiAxNC8wMy8xNyAxMzox OCwgRGFuZywgUXV5bmggKEZlZCkgd3JvdGU6DQo+PiBTdGVwaGVuLA0KPj4gDQo+PiBZb3VyIHBv aW50IGlzIHZlcnkgcGVyZmVjdCB0byBtZSENCj4+IA0KPj4gV2UsIHRoZSBJRVRGLCBhcmUgYSB2 ZXJ5IGltcG9ydGFudCBpbnRlcm5hdGlvbmFsIHN0YW5kYXJkIGJvZHkgYW5kIG91ciBzdGFuZGFy ZHMgYW5kIHJlY29tbWVuZGF0aW9ucyBoYXZlIHRyZW1lbmRvdXMgaW1wYWN0IG9uIGltcHJvdmlu ZyBzZWN1cml0eSBhbmQgc2VydmljZXMgdGhhdCB0aGUgaW50ZXJuZXQgcHJvdmlkZXMuDQo+PiAN Cj4+IEkgd291bGQgbGlrZSBvdXIgcHJvZHVjdHMgdG8gY29udGludWUgdG8gcHJvdmlkZSBncmVh dCBzb2x1dGlvbnMgdG8gYXMgbWFueSB1c2VycyBhcyBwb3NzaWJsZS4gICBBdCBsZWFzdCwgd2hl biBzaWduaW5nIGxhcmdlIGZpbGVzLCB0aGUgcHJlLWhhc2ggd29ya3MgYmV0dGVyIHRoYW4gdGhl IG5vbi1wcmVoYXNoLiBBbmQsIHRoZSBoYXNoLXRoZW4tc2lnbiBzY2hlbWUgaGFzIHdvcmtlZCB3 ZWxsIHNpbmNlIHRoZSBkaWdpdGFsIHNpZ25hdHVyZSB3YXMgaW52ZW50ZWQgd2hlbiB0aGUgaGFz aCBmdW5jdGlvbiBpcyBzZWN1cmUuDQo+PiANCj4+IFJlZ2FyZHMsDQo+PiBRdXluaC4NCj4+IA0K Pj4gRnJvbTogU3RlcGhlbiBGYXJyZWxsIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPG1haWx0 bzpzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPj4NCj4+IERhdGU6IFR1ZXNkYXksIE1hcmNoIDE0 LCAyMDE3IGF0IDc6NDMgQU0NCj4+IFRvOiAnUXV5bmgnIDxRdXluaC5EYW5nQG5pc3QuZ292PG1h aWx0bzpRdXluaC5EYW5nQG5pc3QuZ292Pj4sIFlvYXYgTmlyIDx5bmlyLmlldGZAZ21haWwuY29t PG1haWx0bzp5bmlyLmlldGZAZ21haWwuY29tPj4sICJyc2FsekBha2FtYWkuY29tPG1haWx0bzpy c2FsekBha2FtYWkuY29tPiIgPHJzYWx6QGFrYW1haS5jb208bWFpbHRvOnJzYWx6QGFrYW1haS5j b20+Pg0KPj4gQ2M6IE5pa29zIE1hdnJvZ2lhbm5vcG91bG9zIDxubWF2QHJlZGhhdC5jb208bWFp bHRvOm5tYXZAcmVkaGF0LmNvbT4+LCBDdXJkbGUgPGN1cmRsZUBpZXRmLm9yZzxtYWlsdG86Y3Vy ZGxlQGlldGYub3JnPj4NCj4+IFN1YmplY3Q6IFJlOiBbQ3VyZGxlXSBTb21lIHdvcmsgZm9yIHRo ZSBncm91cA0KPj4gDQo+PiANCj4+IEhpeWEsDQo+PiANCj4+IChObyBoYXRzIHN0aWxsOi0pDQo+ PiANCj4+IE9uIDE0LzAzLzE3IDExOjQ5LCBEYW5nLCBRdXluaCAoRmVkKSB3cm90ZToNCj4+IEhp IFlvYXYsDQo+PiBJcyBpdCByZWFzb25hYmxlIHRvIHRoaW5rIHRoYXQgdGhlcmUgd2lsbCBiZSBj b25zdHJhaW5lZCBkZXZpY2VzDQo+PiB3aGljaCBuZWVkIHRvIGhhbmRsZSBDUkwgbGlzdHMgPw0K Pj4gDQo+PiBPbmUgY291bGQgaW1hZ2luZSBhIHVuaXZlcnNlIGluIHdoaWNoIHRoYXQgbWF0dGVy ZWQsIGJ1dCBpdA0KPj4gaXMgbm90IHRoaXMgdW5pdmVyc2UuIE1lbW9yeSBjb25zdHJhaW5lZCBk ZXZpY2VzIHRoYXQgbmVlZCB0bw0KPj4gY29uc3VtZSBnaWFudCBDUkxzIGRvIG5vdCBzZWVtIHRv IGJlIHJlYWwuIEJ1dCBmZWVsIGZyZWUNCj4+IHRvIHBvaW50IG1lIGF0IGEgcHJvZHVjdCBkYXRh IHNoZWV0IGlmIHRoZXJlIGlzIG9uZS4NCj4+IA0KPj4gSU1PIHJlYWwgY29uc3RyYWluZWQgZGV2 aWNlcyB3aWxsIG5vdCBiZSBkb3dubG9hZGluZyBnaWFudA0KPj4gQ1JMcyBmb3IgcG93ZXIgYW5k L29yIGJhbmR3aWR0aCByZWFzb25zLiAoV2VsbCwgYW5kIGJlY2F1c2UNCj4+IGl0J2QgYmUgc2ls bHk7LSkNCj4+IA0KPj4gSWYgdGhlIGFuc3dlciBpcyB5ZXMsIHdpdGhvdXQgdGhlIHByZS1oYXNo IG9wdGlvbiwgdGhvc2UgZGV2aWNlcw0KPj4gd291bGQgbmVlZCB0byBlaXRoZXI6ICgxKSBidWZm ZXIgbGFyZ2UgbWVzc2FnZXMgKGNvc3RseSkgb3IgKDIpDQo+PiB2ZXJpZnkgbXVsdGlwbGUgQ1JM IGxpc3RzIGV2ZXJ5IHRpbWUgKGNvc3RseSkgaWYgdGhlIENBIGNyZWF0ZXMNCj4+IG11bHRpcGxl IENSTCBsaXN0cyBldmVyeSB0aW1lIHdpdGggdGhlIG5vbi1wcmVoYXNoIG9wdGlvbi4NCj4+IElm IG9ubHkgb25lIG9wdGlvbiB3ZXJlIHRvIGJlIHVzZWQsIHRoZSBwcmUtaGFzaCB3b3VsZCBiZSB0 aGUgYmVzdA0KPj4gY2hvaWNlIGJlY2F1c2UgaXQgd29ya3Mgd2VsbCBldmVyeXdoZXJlLCBub3Qg bGlrZSB0aGUgbm9uLXByZWhhc2gNCj4+IG9uZS4NCj4+IA0KPj4gIkV2ZXJ5d2hlcmUiIHRoZXJl IHJlYWxseSBtZWFuaW5nICJ0aGF0IG90aGVyIHVuaXZlcnNlIHdoZXJlDQo+PiBnaWFudCBDUkxz IGZvciBtZW1vcnkgY29uc3RyYWluZWQgZGV2aWNlcyBtYXR0ZXIiPw0KPj4gDQo+PiBJIHRoaW5r IHdlIGNhbiBkaXRjaCBvciBvdGhlcndpc2Ugc2F5IHRvIG5vdCB1c2UgdGhlIHByZS1oYXNoDQo+ PiBzdHVmZiBzYWZlbHkuIEFkZGluZyBpdCBvciBhbGxvd2luZyBpdHMgdXNlIGlzIGxlc3Mgc2Fm ZS4NCj4+IA0KPj4gKEknbSBub3QgYXMgaGFyZGxpbmUgYXMgTmlrb3MgdGhhdCBpdCBvdWdodCBu b3QgYmUgZGVmaW5lZCBhdA0KPj4gYWxsLCBidXQgb25seSBiZWNhdXNlIGlmIHdlIGRvbid0IGRl ZmluZSBpdCBub3cgd2l0aCBhIE1VU1QNCj4+IE5PVCBvciBTSE9VTEQgTk9ULCB0aGVuIHNvbWVv bmUgd2lsbCBjb21lIGFsb25nIGxhdGVyIGFuZA0KPj4gZGVmaW5lIGl0IGNhdXNpbmcgYWxsIHRo ZSBjb25mdXNpb24vY29tcGxleGl0eSBhbnl3YXkgc28gSQ0KPj4gZG9uJ3Qgc2VlIHRoYXQgb21p dHRpbmcgaXQgaGVyZSBnYWlucyB0aGF0IG11Y2gsIGJ1dCBJJ2QgYmUNCj4+IG9rIHdpdGggZG9p bmcgc28uKQ0KPj4gDQo+PiBDaGVlcnMsDQo+PiBTLg0KPj4gDQo+PiBRdXluaC4NCj4+IEZyb206 IEN1cmRsZQ0KPj4gPGN1cmRsZS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpjdXJkbGUtYm91bmNl c0BpZXRmLm9yZz48bWFpbHRvOmN1cmRsZS1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmDQo+ PiBvZiBZb2F2IE5pciA8eW5pci5pZXRmQGdtYWlsLmNvbTxtYWlsdG86eW5pci5pZXRmQGdtYWls LmNvbT48bWFpbHRvOnluaXIuaWV0ZkBnbWFpbC5jb20+PiBEYXRlOg0KPj4gTW9uZGF5LCBNYXJj aCAxMywgMjAxNyBhdCAxMjoyMSBQTSBUbzoNCj4+ICJyc2FsekBha2FtYWkuY29tPG1haWx0bzpy c2FsekBha2FtYWkuY29tPjxtYWlsdG86cnNhbHpAYWthbWFpLmNvbT4iDQo+PiA8cnNhbHpAYWth bWFpLmNvbTxtYWlsdG86cnNhbHpAYWthbWFpLmNvbT48bWFpbHRvOnJzYWx6QGFrYW1haS5jb20+ PiBDYzogTmlrb3MNCj4+IE1hdnJvZ2lhbm5vcG91bG9zIDxubWF2QHJlZGhhdC5jb208bWFpbHRv Om5tYXZAcmVkaGF0LmNvbT48bWFpbHRvOm5tYXZAcmVkaGF0LmNvbT4+LCBDdXJkbGUNCj4+IDxj dXJkbGVAaWV0Zi5vcmc8bWFpbHRvOmN1cmRsZUBpZXRmLm9yZz48bWFpbHRvOmN1cmRsZUBpZXRm Lm9yZz4+IFN1YmplY3Q6IFJlOiBbQ3VyZGxlXSBTb21lDQo+PiB3b3JrIGZvciB0aGUgZ3JvdXAN Cj4+IFNwZWFraW5nIGFzIGFuIGltcGxlbWVudGVyIG9mIGEgcmVseWluZyBwYXJ0eSwgaWYgcHJl LWhhc2ggaXMgYSBNQVkNCj4+IGZvciBDUkxzIG9uIHRoZSBDQSBzaWRlLCBpdCBiZWNvbWVzIGEg TVVTVCBvbiB0aGUgcmVseWluZyBwYXJ0eSBzaWRlLg0KPj4gSSBNQVkgcmVjZWl2ZSBhIENSTCBz aWduZWQgd2l0aCBwcmUtaGFzaGVkIEVkRFNBLCBzbyBJIE1VU1QgaW1wbGVtZW50DQo+PiBpdCBp ZiBJIHdhbnQgaW50ZXJvcGVyYWJpbGl0eS4gIEkgYWxzbyBNVVNUIGltcGxlbWVudCB0aGUgbm9u DQo+PiBwcmUtaGFzaGVkIEVkRFNBLCBiZWNhdXNlIGNlcnRpZmljYXRlcyBhcmUgdmVyeSBsaWtl bHkgdG8gYmUgc2lnbmVkDQo+PiB3aXRoIHRoYXQuDQo+PiBTbyB1bmxlc3MgdGhlcmXigJlzIGEg dmVyeSBnb29kIHJlYXNvbiB0byBzaWduIENSTHMgd2l0aCB0aGUgcHJlLWhhc2hlZA0KPj4gdmVy c2lvbiwgSeKAmWQgcmF0aGVyIHRoYXQgaXQgYmUgTVVTVCBOT1QgZm9yIGFsbCB1c2VzLg0KPj4g VGhlIGNsYWltIGhhcyBiZWVuIG1hZGUgdGhhdCBmdXR1cmUgaGFyZHdhcmUgKGN1cnJlbnQgaGFy ZHdhcmUgZG9lcw0KPj4gbm90IGltcGxlbWVudCBFZERTQSkgd2lsbCBub3QgYmUgYWJsZSB0byBo b2xkIGFuIGVudGlyZSBDUkwgYWxsIGF0DQo+PiBvbmNlIGluIG1lbW9yeSwgYW5kIHRoZXJlZm9y ZSB3aWxsIG5lZWQgdG8gYmUgZmVkIHRoaXMgQ1JMIG9uZSBjaHVuaw0KPj4gYXQgYSB0aW1lLCBp bXBseWluZyB0aGUgbmVlZCBmb3IgYSBwcmUtaGFzaC4gSG93ZXZlciwgdGhlIHNpemUgb2YNCj4+ IENSTHMgaXMgZW50aXJlbHkgZGV0ZXJtaW5lZCBieSBDQSBwb2xpY3kuIFRoZSBzaXplIG9mIGEg Q1JMIGlzDQo+PiBib3VuZGVkIGJ5IHRoZSBudW1iZXIgb2YgY2VydGlmaWNhdGVzIHRoYXQgc2hh cmUgdGhlIHNhbWUgQ0RQLiBBIENBDQo+PiBjYW4gc2V0IHRoaXMgdmFsdWUgdG8gYW55IG51bWJl ciBmcm9tIDEgdG8gYWxsIHRoZSBjZXJ0aWZpY2F0ZXMgZXZlcg0KPj4gaXNzdWVkLCBhbmQgaXQg Y2FuIHNldCB0aGUgdmFsdWUgc28gdGhhdCBpdCBmaXRzIHRoZSBoYXJkd2FyZQ0KPj4gbGltaXRh dGlvbnMgd2l0aG91dCBwcmUtaGFzaGluZy4NCj4+IEkgZG9u4oCZdCB0aGluayBmb3JjaW5nIHRo ZSByZWx5aW5nIHBhcnRpZXMgKGFsbCBzZXZlcmFsIGJpbGxpb25zIG9mDQo+PiB0aGVtKSB0byBp bXBsZW1lbnQgYm90aCB2YXJpYXRpb25zIGlzIGJldHRlciB0aGFuIGZvcmNpbmcgQ0FzIHRvDQo+ PiBhZGp1c3QgdGhlIHBhcmFtZXRlciBvZiBjZQ0KPj4gT24gMTMgTWFyIDIwMTcsIGF0IDE3OjQ0 LCBTYWx6LCBSaWNoDQo+PiA8cnNhbHpAYWthbWFpLmNvbTxtYWlsdG86cnNhbHpAYWthbWFpLmNv bT48bWFpbHRvOnJzYWx6QGFrYW1haS5jb20+PiB3cm90ZTogVGhlIHByZS1oYXNoIGlzDQo+PiBu b3Qga25vd24gdG8gYmUgYmFkLCBhbHRob3VnaCBpdCBjYW4gYmUgcmlza3kgZm9yIHNvbWUgc3lz dGVtcy4gVGhlDQo+PiBnb2FsIGlzIHRvIG5vdCBoYXZlIHJpc2t5IHRoaW5ncyBpZiB3ZSBkb24n dCBuZWVkIHRoZW0uIFNvIGZhciwgdGhlDQo+PiBvbmx5IHVzZS1jYXNlIHRoYXQgaGFzIGhhZCBz dXBwb3J0IGlzIENSTCdzLCB3aGljaCBhcmUgbGVzcyBsaWtlbHkgdG8NCj4+IGJlIHJpc2t5IHNp bmNlIHRoZSBzYW1lIGtleXBhaXIgZ2VuZXJhbGx5IHNpZ25zIGNlcnRpZmljYXRlcy4gSW4gdGhl DQo+PiBpbnRlcmVzdCBvZiBwcm9ncmVzc2luZyB0aGUgZHJhZnQsIHdlIGFyZSBhc2tpbmcgaWYg cHJlLWhhc2ggaXMgYSBNQVkNCj4+IGZvciBDUkwncyBhbmQgYSBTSE9VTEQgTk9UIG9yIE1VU1Qg Tk9UIGZvciBhbGwgb3RoZXIgdXNlcy4gLS0gU2VuaW9yDQo+PiBBcmNoaXRlY3QsIEFrYW1haSBU ZWNobm9sb2dpZXMgTWVtYmVyLCBPcGVuU1NMIERldiBUZWFtIElNOg0KPj4gcmljaHNhbHpAamFi YmVyLmF0PG1haWx0bzpyaWNoc2FsekBqYWJiZXIuYXQ+PG1haWx0bzpyaWNoc2FsekBqYWJiZXIu YXQ+IFR3aXR0ZXI6IFJpY2hTYWx6DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXyBDdXJkbGUgbWFpbGluZyBsaXN0DQo+PiBDdXJkbGVAaWV0Zi5vcmc8 bWFpbHRvOkN1cmRsZUBpZXRmLm9yZz48bWFpbHRvOkN1cmRsZUBpZXRmLm9yZz4NCj4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY3VyZGxlDQo+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBDdXJkbGUgbWFpbGluZyBsaXN0DQo+ PiBDdXJkbGVAaWV0Zi5vcmc8bWFpbHRvOkN1cmRsZUBpZXRmLm9yZz4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jdXJkbGUNCj4+IA0KPj4gDQo+PiANCj4gDQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEN1cmRsZSBtYWls aW5nIGxpc3QNCj4gQ3VyZGxlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vY3VyZGxlDQoNCg== From nobody Wed Mar 15 10:59: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 A1EBD13175D for ; Wed, 15 Mar 2017 10:59:54 -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 DIx7DyDvNYOZ for ; Wed, 15 Mar 2017 10:59:50 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::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 D836B13175A for ; Wed, 15 Mar 2017 10:59:49 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id r45so18754309qte.3 for ; Wed, 15 Mar 2017 10:59:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=it+AOQ6JCOPKyNGCMvstdQtviHlqP9zNH1qc8L3dhfE=; b=QL+CHhncyV/zm9xoxEZOUZnuSyUbCOajN70Bu+r2nDw8fas5MvbURKFRvcNyZE1YUV 6XhXvV8N5VMSHgokD/y9An9L3u8PCd4wWizhaZCBnHxN1CudsylkgbH4q4WP6Mtfm9yQ KjHaQXwsELCGTzk6nOkzCeBd89KVtI9g9avDYJ2UOR4FraLQCAR9/lgpMzkd0H00Q0XY EWzXDVLTdDdTe7z0th06RYgFAWsQlz80U+9da1q7DiG+OnLhwkeBtuZzCx/w5Z+D37y8 R+GEou2SvMGMJ30D4yhu03x3ibVuYf9/Fl89aIvD6eTQ4K86/DbU0Cuv9ckiXikb0wr1 LR0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=it+AOQ6JCOPKyNGCMvstdQtviHlqP9zNH1qc8L3dhfE=; b=OAta4uLAawhPVYrmElHO7EVot/VGR/bYU7sSxdfLA73PhKKHBjSsKZ3Svu9YN5qXgH PVtJmnYTBNIjwTErPNYLoSlz5Sk+WCiSvJTgklqHqFKPsLVOnajDW+XkzQaVjkq7jKNF I3WF0NKOSt37ppOL+VAKEksHNXPZf08FH8bn57k+rYvL2SYoyH6mMaoD/IhNFZYi//Ck zRs+ykZBbqGsCcryggwP4ogxzvhjelvdjOybXbuonrBIj/npdRogkfo3ZvUxGeaLY0ML hz1Z941G4dydjPGtw0bFeYeg637s8bIl9zOns+iRfYb0Fd3YGTRQkbyF/UP12WZFHkPj DR2A== X-Gm-Message-State: AFeK/H0oo2Js7DJMm8n7uUPUBEhU6CJhPvyvH2s1sNB4slkl8FlXJ8aCMvc6LbvfGyFZYg== X-Received: by 10.200.51.152 with SMTP id c24mr4455502qtb.31.1489600788889; Wed, 15 Mar 2017 10:59:48 -0700 (PDT) Received: from SantoshBrain (pool-74-96-119-167.washdc.fios.verizon.net. [74.96.119.167]) by smtp.gmail.com with ESMTPSA id h184sm1763920qkf.68.2017.03.15.10.59.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Mar 2017 10:59:48 -0700 (PDT) From: "Santosh Chokhani" To: "'Salz, Rich'" Cc: "'Dang, Quynh \(Fed\)'" , "'Russ Housley'" , "'Curdle'" References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> <1489419619.3159.25.camel@redhat.com> <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> <43102E1B-C072-4CE2-9A3E-CDEDE1536AFB@gmail.com> <0DE34F3E-A2D2-4396-B12C-D9FD30DC3723@gmail.com> <2E96A8A2-923A-4597-A175-2 581966C0F1E@vigilsec.com> <613a973ed0e347a1bcaed5082b7731ae@usma1ex-dag1mb1.msg.corp.akamai.com> <2a1c4915e6af4775bdc8eb9637513245@usma1ex-dag1mb1.msg.corp.akamai.com> <566c222d539d4685941fabbc168c9699@usma1ex-dag1mb1.msg.corp.akamai.com> <834e94815b1d4bf883f9a54e8698c81c@usma1ex-dag1mb1.msg.corp.akamai.com> <8DF51F29-E5FD-4D42-8B6E-F15DF95E5C38@gmail.com> <4cd9781fe28f4b998d322c722c2dc83e@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: <4cd9781fe28f4b998d322c722c2dc83e@usma1ex-dag1mb1.msg.corp.akamai.com> Date: Wed, 15 Mar 2017 13:59:47 -0400 Message-ID: <013d01d29db5$efc963c0$cf5c2b40$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQH7a1GVMbQ/bQ7p7K+bnul2pGQeZgIftmjhAWf1dKACVOmfRwKTC6dvAgNsJxADpB5/SgF/ueRfAiMrveIBAZqo4gHWx5ZVAu6CEAcCDaJCMQDuMBrAAsMEUjcByccJWQGECBnGAdqa1gsByYlsuQIqLpS7AlMJZGQCCqh8PgLsIHttAoRlMSQCxi09OAGyuXR/AV2UOKsCJNvPmQHbfBKdn3SImLA= Content-Language: en-us Archived-At: Subject: Re: [Curdle] Some work for the group 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, 15 Mar 2017 17:59:55 -0000 Rich, I have not read up on the pre hash to opine. So, I will pass on it since I do not want to render an uninformed opinion. That is why I said this does not relate to issue at hand....(because I do not have an opinion, informed or otherwise). Also, I do not implement things. So, my views if there are any would be useful in security and interoperability context. I am happy to answer your question on CRL. (I chimed in because I did not wish implementers to implement PK enablement insecurely). So, let us say that CA signs full and complete CRL and partitions CRL1, CRL2, CRLn. What determines that a CRL is full and complete, is the absence of IDP in CRL. I am keeping this simple to not get into indirect CRL etc. So, when the client does not see an critical IDP extension, it knows the CRL is complete and can use it to determine the revocation status of any certificate issued by the CA. Now, let us say that a Certificate with serial X has CRL DP whose DP point is X. Let us say CA asserts X in the IDP of CRLm. Now, if you went to the CRL DP, assuming we do not trust the Internet and the CRL DP serving resource (which typically is not CA), if it served any of the CRLs other than CRLm, you are guaranteed to not see X in the list even if revoked. That is because the CA advertises it to appear only in CRLm. To mitigate this threat, the DP in CRL DP of the certificate must be matched to the DP in IDP if IDP is present and DP is present in the IDP. All of this is codified in X.509 and in 5280. If you still wish to discuss, I recommend we have a private communication since I am sure this is either old hat to folks on the list or they do not care. -----Original Message----- From: Salz, Rich [mailto:rsalz@akamai.com] Sent: Tuesday, March 14, 2017 10:42 PM To: santosh.chokhani@gmail.com Cc: Dang, Quynh (Fed) ; Russ Housley ; Curdle Subject: RE: [Curdle] Some work for the group > I won't belabor this but suggest you read section 6 of RFC 5280 carefully. Please do explain more. If the key signing an entire CRL is the same as the key signing CDP CRL's, and the revocation list is partitioned solely to make it smaller, such as to fit in an IoT lightbulb, then what changes? But separate from that, do you want pre-hash signatures supported? You would be the second person. From nobody Wed Mar 15 11:03: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 280DF131767 for ; Wed, 15 Mar 2017 11:03:18 -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 K5pwkzzSOfji for ; Wed, 15 Mar 2017 11:03:16 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d: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 1C78A13175D for ; Wed, 15 Mar 2017 11:03:16 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id 1so19708989qkl.3 for ; Wed, 15 Mar 2017 11:03:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=y0XIl5QgaY1Ro7YSTsGjCKdSTq3bvm+ZHtQX2oFdLag=; b=L+nOBTegjwpWlMPGsDuNaDRFFrycEVMZsJ6Kww6OSamskDaVj3uagEluGOL01nPEwf 4bwUWKm2Ng7jjuJSIVZfrgVXpFyRU9TQakb7rK7e1HXQmcCyooTCg+r+0IXQbJdkNmao l1XVOID21zZHLtIHNUUSMRXcesyovG0STbP/8t/uA8Q+toXGwNpFYGQgQjNs+3danAol Gif2HEbtk5wcMmsbYwVG/KpsD2VEJAVip8B3K0+Z+LR/O+OOF/iPibJYVhmsmE3IUcHf 3uIK/0SI8oXEF/WLVzUIpvnp5CcWLxR8DddWAZ1rZ3xzT6MjHfhFgpecyeQ1YGEJhUBc I24Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=y0XIl5QgaY1Ro7YSTsGjCKdSTq3bvm+ZHtQX2oFdLag=; b=dDHPYrkhEYeGdyeW+yZfTzRTTQA0zeAz1Y6nVmKDg3/rRaeL6l2J39oE2jtvha18Ce j6yBJXPlGfCB7fvUU1S0wiY4VUccErytli4H9LkdWv234VdNfb1uBQ+l6hCH05YZopt/ o5WBXEsWQiS//pZ2DVv4dvC6cw2dDJMrr8G+qU9PHvbaMjnlrdleuqhNON8jAMKeNoGH XTGpF7AhNYh5Fr3goLG1N7foLckeEhQ/IlCcZzyBQWNfNY0yBoZWHOz+qzQchH6Z0hkB 0blt1kUioYxcUD9fepooXLpZlG5EJCBycmAL7LBCV/I3LWnfmeJpqFgT7q2NWybDUhie RCTw== X-Gm-Message-State: AFeK/H1pWKZsg17ZmoZo0DbB3ofjciXHpWz59xOwDzVnBZ+JlCQuXv2YAnmGzb0LKNSsiQ== X-Received: by 10.55.45.133 with SMTP id t127mr3918083qkh.218.1489600995205; Wed, 15 Mar 2017 11:03:15 -0700 (PDT) Received: from SantoshBrain (pool-74-96-119-167.washdc.fios.verizon.net. [74.96.119.167]) by smtp.gmail.com with ESMTPSA id v24sm1781161qkv.54.2017.03.15.11.03.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Mar 2017 11:03:14 -0700 (PDT) From: "Santosh Chokhani" To: "'Yoav Nir'" Cc: "'Rich Salz'" , "'Dang, Quynh \(Fed\)'" , "'Curdle'" , "'Russ Housley'" References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> <1489419619.3159.25.camel@redhat.com> <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> <43102E1B-C072-4CE2-9A3E-CDEDE1536AFB@gmail.com> <0DE34F3E-A2D2-4396-B12C-D9FD30DC3723@gmail.com> <2E96A8A2-923A-4597-A175-2 581966C0F1E@vigilsec.com> <613a973ed0e347a1bcaed5082b7731ae@usma1ex-dag1mb1.msg.corp.akamai.com> <2a1c4915e6af4775bdc8eb9637513245@usma1ex-dag1mb1.msg.corp.akamai.com> <566c222d539d4685941fabbc168c9699@usma1ex-dag1mb1.msg.corp.akamai.com> <834e94815b1d4bf883f9a54e8698c81c@usma1ex-dag1mb1.msg.corp.akamai.com> <8DF51F29-E5FD-4D42-8B6E-F15DF95E5C38@gmail.com> <677388C4-1985-444E-9704-E5ACC52E39B9@gmail.com> In-Reply-To: <677388C4-1985-444E-9704-E5ACC52E39B9@gmail.com> Date: Wed, 15 Mar 2017 14:03:14 -0400 Message-ID: <014601d29db6$6aca57a0$405f06e0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQH7a1GVMbQ/bQ7p7K+bnul2pGQeZgIftmjhAWf1dKACVOmfRwKTC6dvAgNsJxADpB5/SgF/ueRfAiMrveIBAZqo4gHWx5ZVAu6CEAcCDaJCMQDuMBrAAsMEUjcByccJWQGECBnGAdqa1gsByYlsuQIqLpS7AlMJZGQCCqh8PgLsIHttAoRlMSQCxi09OAGyuXR/AV2UOKsCJNvPmQErcs1bn3oMl3A= Content-Language: en-us Archived-At: Subject: Re: [Curdle] Some work for the group 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, 15 Mar 2017 18:03:18 -0000 Yoav, For most of your comments, I agree. But I would not say most CA partition CRL or how do you know you got the = right partition.=20 Implementations I deal with issue CRL without IDP ensuring CRL are = complete. IDP in CRL is supposed to be critical so that relying parties = know that it could be a partition. I am being succinct rather than a = big discussion on it. You can read the X.509 Normative Annex or RFC = 5280 get additional details and refinements. -----Original Message----- From: Yoav Nir [mailto:ynir.ietf@gmail.com]=20 Sent: Wednesday, March 15, 2017 2:24 AM To: santosh.chokhani@gmail.com Cc: Rich Salz ; Dang, Quynh (Fed) = ; Curdle ; Russ Housley = Subject: Re: [Curdle] Some work for the group Hi, Santosh Partitioning one big CRL into two CRLs makes things more complicated. = That is true. But partitioning the CRL into 1000 small pieces instead of 100 = medium-sized pieces adds a little processing requirement to the CA, but = no additional complexity for either side. As it is, all CAs partition their CRLs. The complexity already exists on = all sides. And relying parties have to make sure they got the right CRL = anyway since they have no way of knowing whether or not the CA = partitions the CRL. So in summary, CRLs are already partitioned. We don=E2=80=99t think CRL = processing is even a thing on constrained devices, but in case = we=E2=80=99re wrong all that is needed to make CRLs smaller is a tweak = of parameter on the CA with zero additional code. Yoav > On 15 Mar 2017, at 4:36, santosh.chokhani@gmail.com wrote: >=20 > It probably not relate to the topic at hand but what you say is=20 > insufficient. See RFC 5280 or use common sense >=20 > When the CA signs bunch of partitions to mitigate substitution attack=20 > the IDP in the partition must be matched with the CDP in the=20 > certificate >=20 > I won't belabor this but suggest you read section 6 of RFC 5280 = carefully. >=20 > Sent from my iPhone >=20 > On Mar 14, 2017, at 10:26 PM, Salz, Rich wrote: >=20 >>> It complicates the clients by requiring the client to make sure that = >>> it got the correct partition. >>=20 >> It is in the certificate as the crlDistributionPoint extension, which = >> the client should already handle >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Wed Mar 15 11: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 B7D84131797 for ; Wed, 15 Mar 2017 11:32:07 -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=redhoundsoftware.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 WyXpkgjGlbpN for ; Wed, 15 Mar 2017 11:32:06 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::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 DFC2D131796 for ; Wed, 15 Mar 2017 11:32:05 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id x35so19550661qtc.2 for ; Wed, 15 Mar 2017 11:32:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=pEE0JWCcj1D2UzOzmA8jVpEd/76XXf0lPTlZ/zzEZNM=; b=t7RrxaMDOpXKcX8QZmRx5vTbgWKot3sKIF6F79mkJ5YzdRMNKIcCW2ugGFtAHFX/Li 9swFrvCdQXQwNg7Et0Ou3mcFtE6d7z671FtIQJXguS2wozrIkZqDOdLa/X/bApCc1iTb FBkyIhTkXKV/+VVJBv6YbLQSJqX2igwHUVZVE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=pEE0JWCcj1D2UzOzmA8jVpEd/76XXf0lPTlZ/zzEZNM=; b=lYFiOFEYbXJ9BZotJjOSQKXdBfvE1yHcV3s9G1Nq4NdKxiaZaD6ZIi3ObFDAgCOSxJ IsNmoDJvaJVrdOlz+gXr788XRwtPoJWPoIcEYOElA/GPNgGUYCghEaEe9co4XBIR6z+O MHgZgInLqLUgx6qJlsEzIZzRUXJw2fpQQ0qyS/mTcWH/rF8lXUahM+4GkI0T/WBV2PxA giDBSgYGZh8sS+pbs42kY4cPPOtuAdzRPw4W1VOvBD+Ufa9askHnVokDpwEihvpz70c1 ggbF4lg2dzUI+9J/RzkfNOajl9JiGyQZKAwwlebpH0VQYHKSCU4XbuYkBNcnIVb9iCOg Faig== X-Gm-Message-State: AFeK/H3FXecT3CGspa9FvRAifan/rvXsoNpYeYgA3SIguU+Pd0YNBxOZtZxHPlQal9Gq3w== X-Received: by 10.200.48.54 with SMTP id f51mr4163206qte.164.1489602724923; Wed, 15 Mar 2017 11:32:04 -0700 (PDT) Received: from [192.168.2.27] (pool-173-73-188-160.washdc.fios.verizon.net. [173.73.188.160]) by smtp.googlemail.com with ESMTPSA id h27sm1853610qtf.24.2017.03.15.11.32.00 (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 15 Mar 2017 11:32:04 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.7.1.161129 Date: Wed, 15 Mar 2017 14:31:55 -0400 From: Carl Wallace To: Yoav Nir , CC: "Dang, Quynh (Fed)" , Rich Salz , Curdle , Russ Housley Message-ID: Thread-Topic: [Curdle] Some work for the group References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> <1489419619.3159.25.camel@redhat.com> <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> <43102E1B-C072-4CE2-9A3E-CDEDE1536AFB@gmail.com> <0DE34F3E-A2D2-4396-B12C-D9FD30DC3723@gmail.com> <2E96A8A2-923A-4597-A175-2581966C0F1E@vigilsec.com> <613a973ed0e347a1bcaed5082b7731ae@usma1ex-dag1mb1.msg.corp.akamai.com> <2a1c4915e6af4775bdc8eb9637513245@usma1ex-dag1mb1.msg.corp.akamai.com> <566c222d539d4685941fabbc168c9699@usma1ex-dag1mb1.msg.corp.akamai.com> <834e94815b1d4bf883f9a54e8698c81c@usma1ex-dag1mb1.msg.corp.akamai.com> <8DF51F29-E5FD-4D42-8B6E-F15DF95E5C38@gmail.com> <677388C4-1985-444E-9704-E5ACC52E39B9@gmail.com> In-Reply-To: <677388C4-1985-444E-9704-E5ACC52E39B9@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Curdle] Some work for the group 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, 15 Mar 2017 18:32:08 -0000 On 3/15/17, 2:24 AM, "Curdle on behalf of Yoav Nir" wrote: >Hi, Santosh > >Partitioning one big CRL into two CRLs makes things more complicated. >That is true. > >But partitioning the CRL into 1000 small pieces instead of 100 >medium-sized pieces adds a little processing requirement to the CA, but >no additional complexity for either side. > >As it is, all CAs partition their CRLs. The complexity already exists on >all sides. And relying parties have to make sure they got the right CRL >anyway since they have no way of knowing whether or not the CA partitions >the CRL. > >So in summary, CRLs are already partitioned. We don=E2=80=99t think CRL >processing is even a thing on constrained devices, but in case we=E2=80=99re >wrong all that is needed to make CRLs smaller is a tweak of parameter on >the CA with zero additional code. Tweaking so the partition size is one would yield a per end user certificate CRL. Every cert would get a unique DP, these corresponding CRLs could be stapled easily to anything, downloading would be faster where necessary and the overall bandwidth usage more efficient in some cases than OCSP since each CRL would report only the status of the certificate of interest. The revocation status of unused or seldom used certificates would never impact any relying party. We're pretty far beyond the hurdles to using partitioned CRLs, even if full CRLs remain the preferred choice in some environments. > >Yoav > >> On 15 Mar 2017, at 4:36, santosh.chokhani@gmail.com wrote: >>=20 >> It probably not relate to the topic at hand but what you say is >>insufficient. See RFC 5280 or use common sense >>=20 >> When the CA signs bunch of partitions to mitigate substitution attack >>the IDP in the partition must be matched with the CDP in the certificate >>=20 >> I won't belabor this but suggest you read section 6 of RFC 5280 >>carefully. >>=20 >> Sent from my iPhone >>=20 >> On Mar 14, 2017, at 10:26 PM, Salz, Rich wrote: >>=20 >>>> It complicates the clients by requiring the client to make sure that >>>>it got the >>>> correct partition. I don't see where checking a partitioned CRL to make sure you have the right one need be any more complicated than making sure you have the right OCSP response. It eliminates some potential issues that may occur when interacting with an OCSP responder, i.e., no potential for the responder to elect to use a different hash algorithm than found in the request, which really complicates knowing if you got the right response. From nobody Wed Mar 15 11:52:16 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 CCC3D1317C4 for ; Wed, 15 Mar 2017 11:52:14 -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 y3w6l17RvTOp for ; Wed, 15 Mar 2017 11:52:12 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C21981317BF for ; Wed, 15 Mar 2017 11:52:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 187C9300483 for ; Wed, 15 Mar 2017 14:52:12 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 5X9AYfz_v7SI for ; Wed, 15 Mar 2017 14:52:10 -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 2503E300266; Wed, 15 Mar 2017 14:52:10 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_8FD05453-7B92-41C9-BF47-04E775A1394A" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 15 Mar 2017 14:52:09 -0400 In-Reply-To: Cc: Curdle To: Carl Wallace References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> <1489419619.3159.25.camel@redhat.com> <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> <43102E1B-C072-4CE2-9A3E-CDEDE1536AFB@gmail.com> <0DE34F3E-A2D2-4396-B12C-D9FD30DC3723@gmail.com> <2E96A8A2-923A-4597-A175-2581966C0F1E@vigilsec.com> <613a973ed0e347a1bcaed5082b7731ae@usma1ex-dag1mb1.msg.corp.akamai.com> <2a1c4915e6af4775bdc8eb9637513245@usma1ex-dag1mb1.msg.corp.akamai.com> <566c222d539d4685941fabbc168c9699@usma1ex-dag1mb1.msg.corp.akamai.com> <834e94815b1d4bf883f9a54e8698c81c@usma1ex-dag1mb1.msg.corp.akamai.com> <8DF51F29-E5FD-4D42-8B6E-F15DF95E5C38@gmail.com> <677388C4-1985-444E-9704-E5ACC52E39B9@gmail.com> X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Curdle] Some work for the group 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, 15 Mar 2017 18:52:15 -0000 --Apple-Mail=_8FD05453-7B92-41C9-BF47-04E775A1394A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 15, 2017, at 2:31 PM, Carl Wallace = wrote: >=20 >=20 > On 3/15/17, 2:24 AM, "Curdle on behalf of Yoav Nir" > wrote: >=20 >> Hi, Santosh >>=20 >> Partitioning one big CRL into two CRLs makes things more complicated. >> That is true. >>=20 >> But partitioning the CRL into 1000 small pieces instead of 100 >> medium-sized pieces adds a little processing requirement to the CA, = but >> no additional complexity for either side. >>=20 >> As it is, all CAs partition their CRLs. The complexity already exists = on >> all sides. And relying parties have to make sure they got the right = CRL >> anyway since they have no way of knowing whether or not the CA = partitions >> the CRL. >>=20 >> So in summary, CRLs are already partitioned. We don=E2=80=99t think = CRL >> processing is even a thing on constrained devices, but in case = we=E2=80=99re >> wrong all that is needed to make CRLs smaller is a tweak of parameter = on >> the CA with zero additional code. >=20 > Tweaking so the partition size is one would yield a per end user > certificate CRL. Every cert would get a unique DP, these corresponding > CRLs could be stapled easily to anything, downloading would be faster > where necessary and the overall bandwidth usage more efficient in some > cases than OCSP since each CRL would report only the status of the > certificate of interest. The revocation status of unused or seldom = used > certificates would never impact any relying party. We're pretty far = beyond > the hurdles to using partitioned CRLs, even if full CRLs remain the > preferred choice in some environments. I think you are suggesting that the Certificate would contain the = CRLDistributionPoints extension with something like this: DistributionPoint ::=3D SEQUENCE { distributionPoint containing a URL like = http://the_CAs_domain/crl/cert_serial_number.crl = } Then, the CRL would contain the IssuingDistributionPoint extension with = something like this: IssuingDistributionPoint ::=3D SEQUENCE { distributionPoint containing a URL like = http://the_CAs_domain/crl/cert_serial_number.crl = } If the two URLs are not exactly the same, then the relying party would = have to fetch the CRL using the URL in the certificate. Computing the signatures for single-certificate CRLs is exactly the same = about of work for the CA as pre-computing an OCSP responses for each = certificate. Russ --Apple-Mail=_8FD05453-7B92-41C9-BF47-04E775A1394A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Mar 15, 2017, at 2:31 PM, Carl Wallace <carl@redhoundsoftware.com> wrote:


On 3/15/17, 2:24 AM, "Curdle on behalf of Yoav Nir"
<curdle-bounces@ietf.org on behalf of ynir.ietf@gmail.com>= wrote:

Hi, Santosh

Partitioning one big = CRL into two CRLs makes things more complicated.
That is = true.

But partitioning the CRL into 1000 = small pieces instead of 100
medium-sized pieces adds a = little processing requirement to the CA, but
no additional = complexity for either side.

As it is, all = CAs partition their CRLs. The complexity already exists on
all sides. And relying parties have to make sure they got the = right CRL
anyway since they have no way of knowing whether = or not the CA partitions
the CRL.

So in summary, CRLs are already partitioned. We don=E2=80=99t = think CRL
processing is even a thing on constrained = devices, but in case we=E2=80=99re
wrong all that is = needed to make CRLs smaller is a tweak of parameter on
the = CA with zero additional code.

Tweaking so the partition size is one would yield a per end = user
certificate CRL. Every cert would get a unique DP, = these corresponding
CRLs could be stapled easily to = anything, downloading would be faster
where necessary and = the overall bandwidth usage more efficient in some
cases = than OCSP since each CRL would report only the status of the
certificate of interest. The revocation status of unused or = seldom used
certificates would never impact any relying = party. We're pretty far beyond
the hurdles to using = partitioned CRLs, even if full CRLs remain the
preferred = choice in some environments.

I think = you are suggesting that the Certificate would contain = the CRLDistributionPoints extension with something like = this:

  =  DistributionPoint ::=3D SEQUENCE {
      =   distributionPoint containing a URL like http://the_CAs_domain/crl/cert_serial_number.crl }

Then, the CRL would contain = the IssuingDistributionPoint extension with something like = this:

  =  IssuingDistributionPoint ::=3D SEQUENCE {
    =     distributionPoint containing a URL like http://the_CAs_domain/crl/cert_serial_number.crl }

If the two URLs are not exactly the = same, then the relying party would have to fetch the CRL using the URL = in the certificate.

Computing the = signatures for single-certificate CRLs is exactly the same about of work = for the CA as pre-computing an OCSP responses for each = certificate.

Russ

= --Apple-Mail=_8FD05453-7B92-41C9-BF47-04E775A1394A-- From nobody Wed Mar 15 11:59: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 E4C5F1317BF for ; Wed, 15 Mar 2017 11:59:08 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 (1024-bit key) header.d=redhoundsoftware.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 UpqU5yMp0k01 for ; Wed, 15 Mar 2017 11:59:07 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::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 5075E1317B6 for ; Wed, 15 Mar 2017 11:59:07 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id i34so20307278qtc.0 for ; Wed, 15 Mar 2017 11:59:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=xExFxl4eEXZMyyy6NfXmMX7JPk6Uvd7vSnFTkUYWarM=; b=VnbMYnq2EVTyndUt7YpFxElD5heABCaY5PF+VPaVd/9yiXHR4v7U0pvUzN5YQL9Ezn Punvs8OE8//fV4dxM04U8dvlyxwsF1W0vjjQKF9GMp8RAmv8pLTYMTVniEn6tLEwc+vc LnjqUtbOhrStNELievPqjNoOwFMcu1DO/dzW8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=xExFxl4eEXZMyyy6NfXmMX7JPk6Uvd7vSnFTkUYWarM=; b=nJKV0RMcXv5sEQgHJk0fmCnnABj7qXwWH0BcKVhQvoC3W5st7WxFKvoXqXRvb56z2M 2MjtwfHCqXR5xKtl/ropfgCoWNVugoBlG9Nmp4g0/FXi+OskgLdS3NF1cYadLERz8ycp Nq75kygqCLq7SdSLZrO/74YVID1JY8sPZAxv5qP5bppaomQw3KdSy3BAI1w2ForSHwfT EqrHd7joznzX2rXkHqRCM+/ssRWWO3iLD5HgS2DKIkvSM+edUMB2RPhpuenJlu+tGe4K xmjf8i0MAJXwOIU38iF0ZxvDzhvGIuzt9IZ3GZLuXEe6D4adkSHDiowrOms9FLZCFeiS cTPg== X-Gm-Message-State: AFeK/H32SoBq1sHoYjOmUFmdBNFo7PrYCI4CCJuSD5nc40VZXXVIOkMpCY8EkZ9T+ndEbg== X-Received: by 10.237.42.109 with SMTP id k42mr4725033qtf.52.1489604346130; Wed, 15 Mar 2017 11:59:06 -0700 (PDT) Received: from [192.168.2.27] (pool-173-73-188-160.washdc.fios.verizon.net. [173.73.188.160]) by smtp.googlemail.com with ESMTPSA id a18sm1911896qkb.10.2017.03.15.11.59.04 (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 15 Mar 2017 11:59:05 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.7.1.161129 Date: Wed, 15 Mar 2017 14:59:01 -0400 From: Carl Wallace To: Russ Housley CC: Curdle Message-ID: Thread-Topic: [Curdle] Some work for the group References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> <1489419619.3159.25.camel@redhat.com> <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> <43102E1B-C072-4CE2-9A3E-CDEDE1536AFB@gmail.com> <0DE34F3E-A2D2-4396-B12C-D9FD30DC3723@gmail.com> <2E96A8A2-923A-4597-A175-2581966C0F1E@vigilsec.com> <613a973ed0e347a1bcaed5082b7731ae@usma1ex-dag1mb1.msg.corp.akamai.com> <2a1c4915e6af4775bdc8eb9637513245@usma1ex-dag1mb1.msg.corp.akamai.com> <566c222d539d4685941fabbc168c9699@usma1ex-dag1mb1.msg.corp.akamai.com> <834e94815b1d4bf883f9a54e8698c81c@usma1ex-dag1mb1.msg.corp.akamai.com> <8DF51F29-E5FD-4D42-8B6E-F15DF95E5C38@gmail.com> <677388C4-1985-444E-9704-E5ACC52E39B9@gmail.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3572434745_38286" Archived-At: Subject: Re: [Curdle] Some work for the group 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, 15 Mar 2017 18:59:09 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3572434745_38286 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit >> > I think you are suggesting that the Certificate would contain the > CRLDistributionPoints extension with something like this: > > DistributionPoint ::= SEQUENCE { > distributionPoint containing a URL like > http://the_CAs_domain/crl/cert_serial_number.crl } > > Then, the CRL would contain the IssuingDistributionPoint extension with > something like this: > > IssuingDistributionPoint ::= SEQUENCE { > distributionPoint containing a URL like > http://the_CAs_domain/crl/cert_serial_number.crl } > > If the two URLs are not exactly the same, then the relying party would have to > fetch the CRL using the URL in the certificate. > > Computing the signatures for single-certificate CRLs is exactly the same about > of work for the CA as pre-computing an OCSP responses for each certificate. Right. I agree similar workload for CA as responder, but less bandwidth and less work for the relying party assuming the OCSP responses contain > 1 certificates. You make a good point though that the certificate provides an easy failover if a substitution is attempted (same as with OCSP). One knock is substantially more use of the CA key (vs delegation) but not having to check delegation also results in less work for the relying party. --B_3572434745_38286 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
<sni= p>
I think you are suggesting that the Certificat= e would contain the CRLDistributionPoints extension with something like= this:

   DistributionPoint= ::=3D SEQUENCE {
        distributionPoint cont= aining a URL like http://the_CAs_domain/crl/cert_serial_number.crl }

Then, the CRL would contain the Issuin= gDistributionPoint extension with something like this:

   IssuingDistributionPoint ::=3D SEQUENCE {
=
        distributionPoint containing a URL like&nbs= p;http:/= /the_CAs_domain/crl/cert_serial_number.crl }

If the two URLs are not exactly the same, then the relying party= would have to fetch the CRL using the URL in the certificate.
Computing the signatures for single-certificate CRLs is= exactly the same about of work for the CA as pre-computing an OCSP response= s for each certificate.

=
Right. I agree similar workload for CA as responder, but less ban= dwidth and less work for the relying party assuming the OCSP responses conta= in > 1 certificates.  You make a good point though that the certific= ate provides an easy failover if a substitution is attempted (same as with O= CSP). One knock is substantially more use of the CA key (vs delegation) but = not having to check delegation also results in less work for the relying par= ty.
<= div>

 --B_3572434745_38286-- From nobody Wed Mar 15 14:32:38 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 27A6313184A for ; Wed, 15 Mar 2017 14:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qd7Xq7CkkFPK for ; Wed, 15 Mar 2017 14:32:33 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D28B13184C for ; Wed, 15 Mar 2017 14:32:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C6CF4BE38; Wed, 15 Mar 2017 21:32:12 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xiBpldOARJf9; Wed, 15 Mar 2017 21:32:04 +0000 (GMT) Received: from [10.87.48.75] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DA193BE2E; Wed, 15 Mar 2017 21:32:03 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1489613524; bh=OlFG5lmXsNU5X8XgXgo3IeAtMKBmbBkeGwlk1kt50xA=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=DKl4HPMjJ9WaMrbwypZKLhxRi9wztYQEdTwuGeD55DKQKD7yOJOqiZj1JVU3T8Jlf QtGPpssE0fTR9LWsKfpaDykN+KfhnYUIQzdfnd6PyEnq8UuGSezPuWa/2GObi090kn z02aRi7lIoIveYlUBscEWj74q6rK8t8xyO344ocg= To: Erwann Abalea References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> <1489419619.3159.25.camel@redhat.com> <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> <43102E1B-C072-4CE2-9A3E-CDEDE1536AFB@gmail.com> <44379acc-ccf9-eaf8-31cf-ef2611e9dd0f@cs.tcd.ie> <1E86BFBF-0A3B-4CF8-998D-AD85B5090599@docusign.com> Cc: "Dang, Quynh (Fed)" , "rsalz@akamai.com" , Curdle , Nikos Mavrogiannopoulos , Yoav Nir From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Wed, 15 Mar 2017 21:32:03 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <1E86BFBF-0A3B-4CF8-998D-AD85B5090599@docusign.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="V3KurBTugptXN9D6hje0c7HdGg4WrLgSO" Archived-At: Subject: Re: [Curdle] Some work for the group 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, 15 Mar 2017 21:32:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --V3KurBTugptXN9D6hje0c7HdGg4WrLgSO Content-Type: multipart/mixed; boundary="I0huA7BcQoXl0onr8J1CkHQaJW2TH5Vlk"; protected-headers="v1" From: Stephen Farrell To: Erwann Abalea Cc: "Dang, Quynh (Fed)" , "rsalz@akamai.com" , Curdle , Nikos Mavrogiannopoulos , Yoav Nir Message-ID: Subject: Re: [Curdle] Some work for the group References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> <1489419619.3159.25.camel@redhat.com> <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> <43102E1B-C072-4CE2-9A3E-CDEDE1536AFB@gmail.com> <44379acc-ccf9-eaf8-31cf-ef2611e9dd0f@cs.tcd.ie> <1E86BFBF-0A3B-4CF8-998D-AD85B5090599@docusign.com> In-Reply-To: <1E86BFBF-0A3B-4CF8-998D-AD85B5090599@docusign.com> --I0huA7BcQoXl0onr8J1CkHQaJW2TH5Vlk Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 15/03/17 17:10, Erwann Abalea wrote: > Bonjour, >=20 >> Le 14 mars 2017 =C3=A0 19:37, Stephen Farrell >> a =C3=A9crit : >>=20 >>=20 >> Hi Quynh, >>=20 >> I'm sorry but I've no idea how your mail is responsive to mine. >>=20 >> To re-iterate: there is IMO no justification at all for pre-hash=20 >> based on constrained devices and CRLs. >>=20 >> Your arguments that there are are unconvincing. >>=20 >> And nobody has pointed at any real device that does need pre-hash. >=20 > I did. On Safenet LunaCA4 (I don=E2=80=99t remember the firmware versio= n), > sending more than 2 or 3MB for signing (with a CKM_RSA_PKCS > mechanism) returns an error. I don=E2=80=99t remember the exact error, = we > switched to hash the payload on caller side, and I don=E2=80=99t know i= f the > error persists with later versions (LunaCA4 is a discontinued > product). Small, challenged, internet of (crap) things devices won't be signing CRLs. I'm personally not concerned about CA signing devices, if someone wants to design one of those to support eddsa and build in such a limitation then they deserve what they get IMO. So I don't consider that a real device of the type in question nor do I consider it a reason to include pre-hash. S. >=20 > Cordialement, Erwann Abalea >=20 >>=20 >> Cheers, S. >>=20 >> On 14/03/17 13:18, Dang, Quynh (Fed) wrote: >>> Stephen, >>>=20 >>> Your point is very perfect to me! >>>=20 >>> We, the IETF, are a very important international standard body >>> and our standards and recommendations have tremendous impact on >>> improving security and services that the internet provides. >>>=20 >>> I would like our products to continue to provide great solutions >>> to as many users as possible. At least, when signing large >>> files, the pre-hash works better than the non-prehash. And, the >>> hash-then-sign scheme has worked well since the digital signature >>> was invented when the hash function is secure. >>>=20 >>> Regards, Quynh. >>>=20 >>> From: Stephen Farrell >>> >=20 >>> Date: Tuesday, March 14, 2017 at 7:43 AM To: 'Quynh' >>> >, Yoav Nir >>> >, >>> "rsalz@akamai.com" >>> > Cc: Nikos >>> Mavrogiannopoulos >, >>> Curdle > Subject: Re: >>> [Curdle] Some work for the group >>>=20 >>>=20 >>> Hiya, >>>=20 >>> (No hats still:-) >>>=20 >>> On 14/03/17 11:49, Dang, Quynh (Fed) wrote: Hi Yoav, Is it >>> reasonable to think that there will be constrained devices which >>> need to handle CRL lists ? >>>=20 >>> One could imagine a universe in which that mattered, but it is >>> not this universe. Memory constrained devices that need to=20 >>> consume giant CRLs do not seem to be real. But feel free to point >>> me at a product data sheet if there is one. >>>=20 >>> IMO real constrained devices will not be downloading giant CRLs >>> for power and/or bandwidth reasons. (Well, and because it'd be >>> silly;-) >>>=20 >>> If the answer is yes, without the pre-hash option, those devices=20 >>> would need to either: (1) buffer large messages (costly) or (2)=20 >>> verify multiple CRL lists every time (costly) if the CA creates=20 >>> multiple CRL lists every time with the non-prehash option. If >>> only one option were to be used, the pre-hash would be the best=20 >>> choice because it works well everywhere, not like the >>> non-prehash one. >>>=20 >>> "Everywhere" there really meaning "that other universe where=20 >>> giant CRLs for memory constrained devices matter"? >>>=20 >>> I think we can ditch or otherwise say to not use the pre-hash=20 >>> stuff safely. Adding it or allowing its use is less safe. >>>=20 >>> (I'm not as hardline as Nikos that it ought not be defined at=20 >>> all, but only because if we don't define it now with a MUST NOT >>> or SHOULD NOT, then someone will come along later and define it >>> causing all the confusion/complexity anyway so I don't see that >>> omitting it here gains that much, but I'd be ok with doing so.) >>>=20 >>> Cheers, S. >>>=20 >>> Quynh. From: Curdle=20 >>> > >>> on behalf of Yoav Nir >>> > >>> Date: Monday, March 13, 2017 at 12:21 PM To:=20 >>> "rsalz@akamai.com" >>> >>>=20 > Cc: Nikos >>> Mavrogiannopoulos >>> >, >>> Curdle=20 >>> > >>> Subject: Re: [Curdle] Some work for the group Speaking as an >>> implementer of a relying party, if pre-hash is a MAY for CRLs on >>> the CA side, it becomes a MUST on the relying party side. I MAY >>> receive a CRL signed with pre-hashed EdDSA, so I MUST implement=20 >>> it if I want interoperability. I also MUST implement the non=20 >>> pre-hashed EdDSA, because certificates are very likely to be >>> signed with that. So unless there=E2=80=99s a very good reason to sig= n >>> CRLs with the pre-hashed version, I=E2=80=99d rather that it be MUST = NOT >>> for all uses. The claim has been made that future hardware >>> (current hardware does not implement EdDSA) will not be able to >>> hold an entire CRL all at once in memory, and therefore will need >>> to be fed this CRL one chunk at a time, implying the need for a >>> pre-hash. However, the size of CRLs is entirely determined by CA >>> policy. The size of a CRL is bounded by the number of >>> certificates that share the same CDP. A CA can set this value to >>> any number from 1 to all the certificates ever issued, and it can >>> set the value so that it fits the hardware limitations without >>> pre-hashing. I don=E2=80=99t think forcing the relying parties (all >>> several billions of them) to implement both variations is better >>> than forcing CAs to adjust the parameter of ce On 13 Mar 2017, at >>> 17:44, Salz, Rich=20 >>> > >>> wrote: The pre-hash is not known to be bad, although it can be >>> risky for some systems. The goal is to not have risky things if >>> we don't need them. So far, the only use-case that has had >>> support is CRL's, which are less likely to be risky since the >>> same keypair generally signs certificates. In the interest of >>> progressing the draft, we are asking if pre-hash is a MAY for >>> CRL's and a SHOULD NOT or MUST NOT for all other uses. -- Senior=20 >>> Architect, Akamai Technologies Member, OpenSSL Dev Team IM:=20 >>> richsalz@jabber.at >>> Twitter: RichSalz _______________________________________________ >>> Curdle mailing list=20 >>> Curdle@ietf.org=20 >>> https://www.ietf.org/mailman/listinfo/curdle=20 >>> _______________________________________________ Curdle mailing >>> list Curdle@ietf.org >>> https://www.ietf.org/mailman/listinfo/curdle >>>=20 >>>=20 >>>=20 >>=20 >> _______________________________________________ Curdle mailing >> list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle >=20 > _______________________________________________ Curdle mailing list=20 > Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle >=20 --I0huA7BcQoXl0onr8J1CkHQaJW2TH5Vlk-- --V3KurBTugptXN9D6hje0c7HdGg4WrLgSO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYybLTAAoJEC88hzaAX42i5a4H/0WHf8cCPxuWR/e/2nLfnezw G5+/EEbUSlVQZHM9Y7wpEz/+CPwxGMIl8Z4EP5RXvJgkep1yNbun6DC19Gc3y3OI r/tLfAMZBttDqf+oraTC9k6jrd/5gVw0HrkENVguOO8kkRTXqvzFfptBeYPI1dmE wYX6Fk2U9GPpItNEuSz7tKc3fA3qY4UoUy0SDBWB1wp8DDZJbf0h8E1mt0xt2b8V Dj1y6WzWsitcvhBDDNZ2lehVQbKcxeqC3Cpw6kyaXy9lujFYZ6garACUzyWAZ5Wn O+1raQAsVkxm8METgDlVRSEsfNFY6TQR4VZL+FahovI18AneJsfSo0I0YW5+PTw= =xRbZ -----END PGP SIGNATURE----- --V3KurBTugptXN9D6hje0c7HdGg4WrLgSO-- From nobody Wed Mar 15 15:01:16 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 8F47A129C03 for ; Wed, 15 Mar 2017 15:01:14 -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 KmqUJM56UUjk for ; Wed, 15 Mar 2017 15:01:12 -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 48A91129C0E for ; Wed, 15 Mar 2017 15:01:11 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id u132so21520354wmg.0 for ; Wed, 15 Mar 2017 15:01:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=2l4wvyyAbg+fFTPDX3aP8eV8hi2YVPVBvEQMN9pZCmE=; b=vabxHOmnpNUx/sG2h5+kSOIp5Z+Rk7jSz5OR2QKBRe0eJKk/IvR4HKIf9Fd0842WHs kehdO72ioLLzuETGejw6gIWTVeYHgErHS8LFFZf9xSpwZHU+fgFR5Lh8T0g0oJDCjQBy +pAcWKCUnc+lcdBiNqy+rMM0AqX6D9XOF4R+lCNf+ZZHKpuduyJEhq+D4/LTuGvbqJn+ DRhSKq6Pf4KmqE8jP8DSe64gcwdrDICIoipJv5gfgKIbusMHUtkSxpq2wrnl4S6awgnq 1UrIEYI0U8upkTeVYkKmwz3cXLB7tv0gn5trGsC2q9ahSO02U3PIICPGLm+HSQrx1STh GeaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=2l4wvyyAbg+fFTPDX3aP8eV8hi2YVPVBvEQMN9pZCmE=; b=oF7SbKTUmkBoIsk0Qtvs8CRAhaDhxKeUb8miAEo6ocvmhoz35O5YqSpHRi6HkF8JPn rpBfgi/0mtx6BP1gbBKVoUYt3ybYJY3joCF5+NsOlZtL9aHFNa2BhVyZHXgXfSLXMBGy ebghcITIaF2w/BHhFWbc8iR3YSzFYFZ+s2Ut7UqIaMYqsK5wXNZY5DEB8zcwKlprq7// p9v8/Yth1uB43bOFB9WDnARX9z3tWMaZWDG7tNKsupmKrBIc5Y0cEjQtG5KgbrU6Ntfm J3Dvmdx1E3wlUQDQUB/8E4ok4XqHKkIqmuWuFBZKMBdcphOTjHcgAkIahLh6mlSNjvO8 lmTA== X-Gm-Message-State: AFeK/H1tcsVWxKOOheJcy6TNldfzgX5t0fFlweuSMmDxdXvTNEL45muQPNDv2DSRGWRsCA== X-Received: by 10.28.230.83 with SMTP id d80mr6235643wmh.18.1489615269807; Wed, 15 Mar 2017 15:01:09 -0700 (PDT) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id 73sm1934630wml.19.2017.03.15.15.01.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Mar 2017 15:01:08 -0700 (PDT) From: Yoav Nir Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_75D3E14B-6AC0-4702-901B-0F48CF60F61C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 16 Mar 2017 00:01:05 +0200 In-Reply-To: <1E86BFBF-0A3B-4CF8-998D-AD85B5090599@docusign.com> Cc: Stephen Farrell , "Dang, Quynh (Fed)" , Rich Salz , Nikos Mavrogiannopoulos , Curdle To: Erwann Abalea References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> <1489419619.3159.25.camel@redhat.com> <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> <43102E1B-C072-4CE2-9A3E-CDEDE1536AFB@gmail.com> <44379acc-ccf9-eaf8-31cf-ef2611e9dd0f@cs.tcd.ie> <1E86BFBF-0A3B-4CF8-998D-AD85B5090599@docusign.com> X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Curdle] Some work for the group 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, 15 Mar 2017 22:01:15 -0000 --Apple-Mail=_75D3E14B-6AC0-4702-901B-0F48CF60F61C Content-Type: multipart/alternative; boundary="Apple-Mail=_B1CBDF51-579A-400C-AB6F-CB906D4D333B" --Apple-Mail=_B1CBDF51-579A-400C-AB6F-CB906D4D333B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 15 Mar 2017, at 19:10, Erwann Abalea = wrote: >=20 > Bonjour, >=20 >> Le 14 mars 2017 =C3=A0 19:37, Stephen Farrell = > a =C3=A9cri= t : >>=20 >>=20 >> Hi Quynh, >>=20 >> I'm sorry but I've no idea how your mail is responsive to mine. >>=20 >> To re-iterate: there is IMO no justification at all for pre-hash >> based on constrained devices and CRLs. >>=20 >> Your arguments that there are are unconvincing. >>=20 >> And nobody has pointed at any real device that does need >> pre-hash. >=20 > I did. On Safenet LunaCA4 (I don=E2=80=99t remember the firmware = version), sending more than 2 or 3MB for signing (with a CKM_RSA_PKCS = mechanism) returns an error. > I don=E2=80=99t remember the exact error, we switched to hash the = payload on caller side, and I don=E2=80=99t know if the error persists = with later versions (LunaCA4 is a discontinued product). >=20 > Cordialement, > Erwann Abalea Thanks, but 2-3 MB is quite large. Larger than any CRL I want to be = downloading in the middle of a TLS handshake or an IKE exchange. >60% of Internet users have connection speeds of under 10 Mbps = (according to Akamai) and when we=E2=80=99re using mobile phones we=E2=80=99= re often getting less than that. I haven=E2=80=99t done a good survey, but checking a few CRLs (for = google, the IETF and a few more) I found most real CRLs to be between = many hundreds of bytes and a few tens of thousands of bytes. The largest = I found was just over 1 MB. The Safenet hardware can easily handle all = of these. Yoav --Apple-Mail=_B1CBDF51-579A-400C-AB6F-CB906D4D333B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 15 Mar 2017, at 19:10, Erwann Abalea <Erwann.Abalea@docusign.com> wrote:

Bonjour,

Le 14 mars 2017 =C3=A0 = 19:37, Stephen Farrell <stephen.farrell@cs.tcd.ie> a =C3=A9crit :


Hi Quynh,

I'm sorry but I've no idea how your mail is responsive to = mine.

To re-iterate: there is IMO no = justification at all for pre-hash
based on constrained = devices and CRLs.

Your arguments that there = are are unconvincing.

And nobody has = pointed at any real device that does need
pre-hash.

I did. On Safenet LunaCA4 (I don=E2=80=99t = remember the firmware version), sending more than 2 or 3MB for signing = (with a CKM_RSA_PKCS mechanism) returns an error.
I don=E2=80=99t = remember the exact error, we switched to hash the payload on caller = side, and I don=E2=80=99t know if the error persists with later versions = (LunaCA4 is a discontinued product).

Cordialement,
Erwann Abalea


Thanks, but 2-3 MB = is quite large. Larger than any CRL I want to be downloading in the = middle of a TLS handshake or an IKE exchange.

>60% of Internet users have = connection speeds of under 10 Mbps (according to Akamai) and when = we=E2=80=99re using mobile phones we=E2=80=99re often getting less than = that.

I = haven=E2=80=99t done a good survey, but checking a few CRLs (for google, = the IETF and a few more) I found most real CRLs to be between many = hundreds of bytes and a few tens of thousands of bytes. The largest I = found was just over 1 MB.  The Safenet hardware can easily handle = all of these.

Yoav

= --Apple-Mail=_B1CBDF51-579A-400C-AB6F-CB906D4D333B-- --Apple-Mail=_75D3E14B-6AC0-4702-901B-0F48CF60F61C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJYybmiAAoJELhJCxUKWMyZZlYIAKBSKaCTHxx6NpaFiRFdCgqr wx4GKj0NX7dHDhPsH5mfT78swpAtzyXPLKuxTZEpG3ikzyCVySoImu44Nf6p7jaa 4ovTVqQASjtVyg0na0H0Z5rwDw/cFovZdekWNtWk+K7JzktEAPvOdaTFez3ndUul S9d9s3TWbnHQGDhmVl63cY5as3jxrufbX5MfR5JEd3EeS2q9fsGgRiiEpXrxhL03 c6PojA3kSsWroVQ+loRKZJAZtsXKFsKvc5cSTRJ50IQHyIWKgoaaAwRaQoaSzAD8 +I5Y5FYwxQ4D04bVvBtjvS8sNDquvd5MM+Vd5a83yNdC9aMXQgFlaxITTPvinCI= =Mx4M -----END PGP SIGNATURE----- --Apple-Mail=_75D3E14B-6AC0-4702-901B-0F48CF60F61C-- From nobody Wed Mar 15 16:29:00 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 601B412E856 for ; Wed, 15 Mar 2017 16:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2uqFAx-YRZJp for ; Wed, 15 Mar 2017 16:28:56 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BF7112E6D7 for ; Wed, 15 Mar 2017 16:28:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1489620535; x=1521156535; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=FPQfChVkOPLYIGlYMVNeWNXQBuYpv63bXeQKP7WsVZs=; b=HZuGlnt6T10iUIUQf6QHNj6gYVFZor4m9HZ3dsM3/HKdAzPy7TUl6SER Wtoe4GjPSjr+s3LIRNOMuYAPslc1H3MZa8iAGdx4g/ztRPltFZ3gI25CY 2WxD6cmSn7yMoML9f2i9c8tD3BrmxTkHLYVPgMprtnL2tgEsGLCShqULx bcCLx/IxzATluBfDiL0Q11I7tkk9lyhP5j0CqbjTH1p1w8Ya6hSmguInv swNROkw5wsvAsMcyu5rG3zxJR0bclvTGJWBWTVeYwMMTszBjeu//LOsMX qEmwqVZ1JRAMu6SPTeie73kWgozMvnd9dy0ZanK5Oqhf6t5XdulMEf64+ A==; X-IronPort-AV: E=Sophos;i="5.36,170,1486378800"; d="scan'208";a="142884126" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.5 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-ogg-d.UoA.auckland.ac.nz) ([10.6.2.5]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 16 Mar 2017 12:26:01 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 16 Mar 2017 12:26:01 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1178.000; Thu, 16 Mar 2017 12:26:01 +1300 From: Peter Gutmann To: Erwann Abalea CC: Yoav Nir , "Dang, Quynh (Fed)" , Nikos Mavrogiannopoulos , Rich Salz , Curdle Thread-Topic: [Curdle] Some work for the group Thread-Index: AQHScQasYv1qbtR3EECCo4rUC94EmqFOKF8AgABRogCAB4KXgIAbAeCAgABR0wCAGzCCAIABO9kAgAADkQCABJSmAIAAD2SAgAABHICAABstgIABNbGAgAANNACAAYST94AAVDmAgAFIfJg= Date: Wed, 15 Mar 2017 23:26:01 +0000 Message-ID: <1489620354611.31679@cs.auckland.ac.nz> References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> <1489419619.3159.25.camel@redhat.com> <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> <43102E1B-C072-4CE2-9A3E-CDEDE1536AFB@gmail.com> <0DE34F3E-A2D2-4396-B12C-D9FD30DC3723@gmail.com> <1489531750610.15665@cs.auckland.ac.nz>, <7C8644BA-F890-4A1A-886B-50AC1A43D9A7@docusign.com> In-Reply-To: <7C8644BA-F890-4A1A-886B-50AC1A43D9A7@docusign.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Curdle] Some work for the group 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, 15 Mar 2017 23:28:58 -0000 Erwann Abalea writes:=0A= =0A= >31/12/9999 is a valid date (so far).=0A= >31/12/1999 23:59:59 may not exist (we don=92t know yet if a negative leap= =0A= >second will be introduced), and it may not be the last second of the day= =0A= >(positive leap second). However, as a magical value, 99992131235959Z is a= =0A= >correct GeneralizedTime. 99991231235960 is also a correct GeneralizedTime.= =0A= >99991231240000 isn=92t.=0A= =0A= So the one problem with this approach, which I've mentioned to a few people= =0A= off-list, is that the original source of the question has identified=0A= approximately zero implementations (he counted them twice) that support thi= s=0A= special-case date. There's probably something out there somewhere that=0A= implements it, but it's not going to fly for a general-use case. My advice= =0A= was to just ignore cert expiry dates like everyone else in this situation= =0A= does, but apparently there's a requirement for standards-compliance... mayb= e I=0A= should do an RFC on "How to make certs work with SCADA", a.k.a. "How to app= ly=0A= common sense" (in other words nothing terribly clever, just some text that= =0A= people can point to to show they're complying with it).=0A= =0A= Peter.=0A= From nobody Wed Mar 15 19:17: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 56C1F12F24E for ; Wed, 15 Mar 2017 19:17: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=teamtelstra.onmicrosoft.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 IODuBD9LfXtX for ; Wed, 15 Mar 2017 19:17:13 -0700 (PDT) Received: from ipxdno.tcif.telstra.com.au (ipxdno.tcif.telstra.com.au [203.35.82.212]) (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 14C3C12F27C for ; Wed, 15 Mar 2017 19:17:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.36,170,1486386000"; d="scan'208";a="2770300" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipodni.tcif.telstra.com.au with ESMTP; 16 Mar 2017 13:17:10 +1100 X-IronPort-AV: E=McAfee;i="5800,7501,8468"; a="305172431" Received: from wsmsg3753.srv.dir.telstra.com ([172.49.40.174]) by ipcani.tcif.telstra.com.au with ESMTP; 16 Mar 2017 13:17:09 +1100 Received: from wsapp5873.srv.dir.telstra.com (10.75.11.109) by WSMSG3753.srv.dir.telstra.com (172.49.40.174) with Microsoft SMTP Server (TLS) id 8.3.485.1; Thu, 16 Mar 2017 13:17:10 +1100 Received: from wsapp5585.srv.dir.telstra.com (10.75.3.67) by wsapp5873.srv.dir.telstra.com (10.75.11.109) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Thu, 16 Mar 2017 13:17:09 +1100 Received: from AUS01-SY3-obe.outbound.protection.outlook.com (10.172.229.126) by wsapp5585.srv.dir.telstra.com (10.75.3.67) with Microsoft SMTP Server (TLS) id 15.0.1236.3 via Frontend Transport; Thu, 16 Mar 2017 13:17:09 +1100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=teamtelstra.onmicrosoft.com; s=selector1-team-telstra-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=w5nK5ySOrUHUV8F9E8x5ZDSlYKlrdpdVbLh8U+acD+M=; b=uNhsAChlCN2nDELfj4rxgoEmqOt8CWIRhlxJFXhkVjbNdCrTUjvFsXSxrtlB9F7AMu2tkHnjc+ajH/pQ58f4IKdnhD7hnahkhleD3UtnnMAu0QgU4zuNDXBCJICXvBrLkcftlsCClUAujuKyb/MpqFLGNmp0/9Wgsk7tJxxR7qg= Received: from SYXPR01MB1615.ausprd01.prod.outlook.com (10.175.209.15) by SYXPR01MB1616.ausprd01.prod.outlook.com (10.175.209.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Thu, 16 Mar 2017 02:17:08 +0000 Received: from SYXPR01MB1615.ausprd01.prod.outlook.com ([10.175.209.15]) by SYXPR01MB1615.ausprd01.prod.outlook.com ([10.175.209.15]) with mapi id 15.01.0947.022; Thu, 16 Mar 2017 02:17:08 +0000 From: "Manger, James" To: Peter Gutmann CC: Curdle Thread-Topic: [Curdle] Some work for the group Thread-Index: AQHSmR5+jBKVOS3+SUO8H3sVhu0HtKGORmUAgAADkQCABJSlAIAAD2SAgAABHICAABstgIABNbGAgAANNACAAKr+AIABLc+AgABuzICAAC1UwA== Date: Thu, 16 Mar 2017 02:17:07 +0000 Message-ID: References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> <1489419619.3159.25.camel@redhat.com> <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> <43102E1B-C072-4CE2-9A3E-CDEDE1536AFB@gmail.com> <0DE34F3E-A2D2-4396-B12C-D9FD30DC3723@gmail.com> <1489531750610.15665@cs.auckland.ac.nz>, <7C8644BA-F890-4A1A-886B-50AC1A43D9A7@docusign.com> <1489620354611.31679@cs.auckland.ac.nz> In-Reply-To: <1489620354611.31679@cs.auckland.ac.nz> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cs.auckland.ac.nz; dkim=none (message not signed) header.d=none;cs.auckland.ac.nz; dmarc=none action=none header.from=team.telstra.com; x-originating-ip: [203.41.142.244] x-ms-office365-filtering-correlation-id: 27c50ac7-4ede-47f5-19ac-08d46c128c0b x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SYXPR01MB1616; x-microsoft-exchange-diagnostics: 1; SYXPR01MB1616; 7:5nvYEoeNmGTNiFScpHm/E0NzYHlZDj5CTPYJbbAPYpm1PvR+wFqLXYPMNGgMbkjQLFIxg73jGlJJl/e8Dywrds/WeO64oIedfgLTRrzlLos5O0GXXRm0wvgulDeCyEkTP/vpxCdf1VApO2M8gdITu2ijDz5HHhY6yAh1jbhqQ+YkU+FTY2TBjHuXW+8kroUsgQVQ09Z4CjxfCuLTgHPPKPzItrIbjn5HBCIN57uDoZLa06xVQMsxpf2vvkRNlV0RLlSjBxb6hY/WYT2emCdVMjJt+uA+gggl6vq28Va1eMZgVcE/Q4+vmQGJ7uTkZ/vQChOdDL2JSjO0XUzSNs9Uig== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(58426504366037); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123564025)(20161123558025)(20161123562025)(20161123555025)(20161123560025)(6042181)(6072148); SRVR:SYXPR01MB1616; BCL:0; PCL:0; RULEID:; SRVR:SYXPR01MB1616; x-forefront-prvs: 024847EE92 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(42882006)(5660300001)(53546007)(7736002)(54356999)(50986999)(2950100002)(7696004)(3846002)(102836003)(6116002)(66066001)(33656002)(6916009)(305945005)(110136004)(93886004)(6306002)(55016002)(76176999)(2900100001)(122556002)(4326008)(77096006)(3280700002)(189998001)(99286003)(6246003)(2906002)(229853002)(6436002)(86362001)(8936002)(81166006)(6506006)(53936002)(25786008)(8676002)(38730400002)(74316002)(9686003)(3660700001); DIR:OUT; SFP:1102; SCL:1; SRVR:SYXPR01MB1616; H:SYXPR01MB1615.ausprd01.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-MS-Exchange-CrossTenant-originalarrivaltime: 16 Mar 2017 02:17:07.9581 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 49dfc6a3-5fb7-49f4-adea-c54e725bb854 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SYXPR01MB1616 X-OriginatorOrg: team.telstra.com Archived-At: Subject: Re: [Curdle] Some work for the group 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, 16 Mar 2017 02:17:16 -0000 Even "zero implementations" should still mean (almost) all implementations = correctly treat 99991231235959Z as meaning "has not expired" for at least t= he next 7,982 years. Not long enough? -- James Manger -----Original Message----- From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Peter Gutmann Sent: Thursday, 16 March 2017 10:26 AM To: Erwann Abalea Cc: Dang, Quynh (Fed) ; Nikos Mavrogiannopoulos ; Curdle ; Yoav Nir ; Rich= Salz Subject: Re: [Curdle] Some work for the group Erwann Abalea writes: >31/12/9999 is a valid date (so far). >31/12/1999 23:59:59 may not exist (we don't know yet if a negative leap >second will be introduced), and it may not be the last second of the day >(positive leap second). However, as a magical value, 99992131235959Z is a >correct GeneralizedTime. 99991231235960 is also a correct GeneralizedTime. >99991231240000 isn't. So the one problem with this approach, which I've mentioned to a few people off-list, is that the original source of the question has identified approximately zero implementations (he counted them twice) that support thi= s special-case date. There's probably something out there somewhere that implements it, but it's not going to fly for a general-use case. My advice was to just ignore cert expiry dates like everyone else in this situation does, but apparently there's a requirement for standards-compliance... mayb= e I should do an RFC on "How to make certs work with SCADA", a.k.a. "How to app= ly common sense" (in other words nothing terribly clever, just some text that people can point to to show they're complying with it). Peter. _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle From nobody Wed Mar 15 20:12: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 CBEAD130141 for ; Wed, 15 Mar 2017 20:12:39 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8nOa5jdlv-2J for ; Wed, 15 Mar 2017 20:12:38 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8913712F257 for ; Wed, 15 Mar 2017 20:12:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1489633957; x=1521169957; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=4r5aVcfkhRjky1I5gK/n5aH8plAZvCIijTge9+Zc2gw=; b=bl8p4FQM1V9mh3c9yr/nK3NTAzNzZwUSkF8s198vkzo4+mysTBg4EeBH mIjaRwheEzJRiTlLni72rDUoDIjWcSePimb1mMpdaoU2qtL3mXgJQ/xIh qp2X9mppKSlig9WuAiIjp0VO0O7uZtQNporyLV6tsiflmOTOnjW9LM65q wExllYLqkEo3Ac+V1A6dEH+YNru80rDH3xdTuWmBY+BEj9J5gaIk3OSZQ 9ylW265TUQEvshQuH64bqxeaHr22Y+S+1gWFnuIOy5eOyFfnrYz+KyDFR v7Ecd8lDnHIJ5FyoZSxaBxLsy3Sj+53rFF47tiaLWUbHYyMU/FxyBR5rJ g==; X-IronPort-AV: E=Sophos;i="5.36,170,1486378800"; d="scan'208";a="142976206" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.4 - Outgoing - Outgoing Received: from uxcn13-tdc-c.uoa.auckland.ac.nz ([10.6.3.4]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 16 Mar 2017 16:12:35 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-c.UoA.auckland.ac.nz (10.6.3.4) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 16 Mar 2017 16:12:35 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1178.000; Thu, 16 Mar 2017 16:12:35 +1300 From: Peter Gutmann To: "Manger, James" CC: Curdle Thread-Topic: [Curdle] Some work for the group Thread-Index: AQHScQasYv1qbtR3EECCo4rUC94EmqFOKF8AgABRogCAB4KXgIAbAeCAgABR0wCAGzCCAIABO9kAgAADkQCABJSmAIAAD2SAgAABHICAABstgIABNbGAgAANNACAAYST94AAVDmAgAFIfJj//1YfgIAA6TAg Date: Thu, 16 Mar 2017 03:12:35 +0000 Message-ID: <1489633948908.28319@cs.auckland.ac.nz> References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> <1489419619.3159.25.camel@redhat.com> <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> <43102E1B-C072-4CE2-9A3E-CDEDE1536AFB@gmail.com> <0DE34F3E-A2D2-4396-B12C-D9FD30DC3723@gmail.com> <1489531750610.15665@cs.auckland.ac.nz>, <7C8644BA-F890-4A1A-886B-50AC1A43D9A7@docusign.com> <1489620354611.31679@cs.auckland.ac.nz>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Curdle] Some work for the group 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, 16 Mar 2017 03:12:40 -0000 Manger, James writes:=0A= =0A= >Even "zero implementations" should still mean (almost) all implementations= =0A= >correctly treat 99991231235959Z as meaning "has not expired" for at least = the=0A= >next 7,982 years. Not long enough?=0A= =0A= It's more likely they'll treat it as "invalid date". Any 32-bit=0A= implementation will do so by default even if it tries to parse the value si= nce=0A= it's after 2038, and I'm assuming 64-bit ones reject it too based on it bei= ng=0A= an obviously-invalid date value, thus the "zero implementations support thi= s"=0A= [0]. The "zero implementations support this" really does mean "zero=0A= implementations support this", not "zero implementations support this but I= =0A= think they should so we'll assume they do".=0A= =0A= Insert side-debate about how many crypto implementations happily accept any= =0A= old rubbish from the other side without any checking. Missing key exchange= in=0A= the SSL handshake? No problem, we'll continue with an all-zero key. All-z= ero=0A= data values in the signature on a file? Seems legit, I'm sure they just=0A= accidentally forgot to add the signature. Etc.=0A= =0A= Peter.=0A= =0A= [0] Meaning, as mentioned previously, "we were unable to identify an=0A= implementation that supports this".=0A= From nobody Thu Mar 16 01:55: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 699B4126FB3 for ; Thu, 16 Mar 2017 01:55: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 8HpooyrWAVoQ for ; Thu, 16 Mar 2017 01:55: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 D99DB126DD9 for ; Thu, 16 Mar 2017 01:55: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 7AE3C15561 for ; Thu, 16 Mar 2017 08:55:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 7AE3C15561 Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=nmav@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 7AE3C15561 Received: from dhcp-10-40-1-102.brq.redhat.com (unknown [10.40.3.26]) by smtp.corp.redhat.com (Postfix) with ESMTPS id ED6AF19E1B for ; Thu, 16 Mar 2017 08:55:05 +0000 (UTC) Message-ID: <1489654504.32197.3.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Curdle Date: Thu, 16 Mar 2017 09:55:04 +0100 In-Reply-To: <1489633948908.28319@cs.auckland.ac.nz> References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> <1489419619.3159.25.camel@redhat.com> <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> <43102E1B-C072-4CE2-9A3E-CDEDE1536AFB@gmail.com> <0DE34F3E-A2D2-4396-B12C-D9FD30DC3723@gmail.com> <1489531750610.15665@cs.auckland.ac.nz> , <7C8644BA-F890-4A1A-886B-50AC1A43D9A7@docusign.com> <1489620354611.31679@cs.auckland.ac.nz> , <1489633948908.28319@cs.auckland.ac.nz> 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.29]); Thu, 16 Mar 2017 08:55:06 +0000 (UTC) Archived-At: Subject: Re: [Curdle] Some work for the group 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, 16 Mar 2017 08:55:07 -0000 On Thu, 2017-03-16 at 03:12 +0000, Peter Gutmann wrote: > Manger, James writes: > > > Even "zero implementations" should still mean (almost) all > > implementations > > correctly treat 99991231235959Z as meaning "has not expired" for at > > least the > > next 7,982 years. Not long enough? > > It's more likely they'll treat it as "invalid date".  Any 32-bit > implementation will do so by default even if it tries to parse the > value since > it's after 2038, and I'm assuming 64-bit ones reject it too based on > it being > an obviously-invalid date value, thus the "zero implementations > support this" > [0].  The "zero implementations support this" really does mean "zero > implementations support this", not "zero implementations support this > but I think they should so we'll assume they do". Which implementations have you checked? I was so surprised by your statement (the Y2038 problem is known for so long, I doubt it is not already solved in major implementations), that I actually checked both openssl and gnutls on a 32-bit system. On that system gnutls printed a certificate with the special date set as expiring on: Thu Dec 31 23:23:23 UTC 2037 - the actual date gnutls will consider it valid to while openssl reported it as expiring on: Dec 31 23:59:59 9999 GMT - the date saved in the certificate Both were able to validate the certificate on dates up to end of 2037. OpenSSL could further validate the certificate for the first days of 2038. The system could not address time past that, so I gave up. regards, Nikos From nobody Thu Mar 16 14:02:46 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 1275A129A8D for ; Thu, 16 Mar 2017 14:02:46 -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 UF-Eryi45GZF for ; Thu, 16 Mar 2017 14:02:45 -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 E5A14129A85 for ; Thu, 16 Mar 2017 14:02:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 059D23004AE for ; Thu, 16 Mar 2017 17:02:44 -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 VXztUlXsiCLQ for ; Thu, 16 Mar 2017 17:02:42 -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 1F0F63004B6; Thu, 16 Mar 2017 17:02:42 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Russ Housley In-Reply-To: <1489654504.32197.3.camel@redhat.com> Date: Thu, 16 Mar 2017 17:02:42 -0400 Cc: Curdle Content-Transfer-Encoding: quoted-printable Message-Id: <51F17CE5-2E74-4A57-8384-13DDFF917399@vigilsec.com> References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> <1489419619.3159.25.camel@redhat.com> <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> <43102E1B-C072-4CE2-9A3E-CDEDE1536AFB@gmail.com> <0DE34F3E-A2D2-4396-B12C-D9FD30DC3723@gmail.com> <1489531750610.15665@cs.auckland.ac.nz> <7C8644BA-F890-4A1A-886B-50AC1A43D9A7@docusign.com> <1489620354611.31679@cs.auckland.ac.nz> <1489633948908.28319@cs.auckland.ac.nz> <1489654504.32197.3.camel@redhat.com> To: Nikos Mavrogiannopoulos X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Curdle] Some work for the group 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, 16 Mar 2017 21:02:46 -0000 > On Mar 16, 2017, at 4:55 AM, Nikos Mavrogiannopoulos = wrote: >=20 > On Thu, 2017-03-16 at 03:12 +0000, Peter Gutmann wrote: >> Manger, James writes: >>=20 >>> Even "zero implementations" should still mean (almost) all >>> implementations >>> correctly treat 99991231235959Z as meaning "has not expired" for at >>> least the >>> next 7,982 years. Not long enough? >>=20 >> It's more likely they'll treat it as "invalid date". Any 32-bit >> implementation will do so by default even if it tries to parse the >> value since >> it's after 2038, and I'm assuming 64-bit ones reject it too based on >> it being >> an obviously-invalid date value, thus the "zero implementations >> support this" >> [0]. The "zero implementations support this" really does mean "zero >> implementations support this", not "zero implementations support this >> but I think they should so we'll assume they do". >=20 > Which implementations have you checked? I was so surprised by your > statement (the Y2038 problem is known for so long, I doubt it is not > already solved in major implementations), that I actually checked both > openssl and gnutls on a 32-bit system. >=20 > On that system gnutls printed a certificate with the special date set > as expiring on: > Thu Dec 31 23:23:23 UTC 2037 - the actual date gnutls will consider > it valid to >=20 > while openssl reported it as expiring on: > Dec 31 23:59:59 9999 GMT - the date saved in the certificate >=20 > Both were able to validate the certificate on dates up to end of 2037. > OpenSSL could further validate the certificate for the first days of > 2038. The system could not address time past that, so I gave up. I am aware of one implementation skips the expiration check when is sees = this value. Russ From nobody Thu Mar 16 16:43: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 58DBC129B69 for ; Thu, 16 Mar 2017 16:43:46 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBQaKz9fb5O6 for ; Thu, 16 Mar 2017 16:43:45 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0F8C129B5B for ; Thu, 16 Mar 2017 16:43:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1489707824; x=1521243824; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ENjyAgq/1Khd7vqcLAi9BcR0GtQHCJYcB0PpJcl6Wc8=; b=edMYBI2qVcqf6+2+jwd4Rispg0tep9l6JJCtaIIfRYmUC9uB++hPSy3O 8EEadH72sYMVUBEpKRTveJh0jlLp0IkPijutXUrJmyEtZGtOuW8AugBFR Vy0ZFmZ8FKeV+wQSsipnoxFb2jF3bnfMGiQmg3hHypQMXJxr6Pm8fRSKI MNoH8U8esX+msETnPfvmKhcgi/TMP1oH0S08ON9X0IOUmZ8Zr3FItPZ32 9dZ5jpGvS9o/w1MtxcMDKu0EUN9iX1Vf0fPGZNfXwhj/wEf+P3GFkjpE1 hq8eiXXkwUa+WDH3GCCr5UPUdvsLqTIEvSsFKb+0pY5TWatt6fGEgw2gN Q==; X-IronPort-AV: E=Sophos;i="5.36,174,1486378800"; d="scan'208";a="143224983" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.5 - Outgoing - Outgoing Received: from uxcn13-tdc-d.uoa.auckland.ac.nz ([10.6.3.5]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 17 Mar 2017 12:43:43 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.25) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 17 Mar 2017 12:43:42 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1178.000; Fri, 17 Mar 2017 12:43:42 +1300 From: Peter Gutmann To: Nikos Mavrogiannopoulos , Curdle Thread-Topic: [Curdle] Some work for the group Thread-Index: AQHScQasYv1qbtR3EECCo4rUC94EmqFOKF8AgABRogCAB4KXgIAbAeCAgABR0wCAGzCCAIABO9kAgAADkQCABJSmAIAAD2SAgAABHICAABstgIABNbGAgAANNACAAYST94AAVDmAgAFIfJj//1YfgIAA6TAg//+GAACAAdIGqw== Date: Thu, 16 Mar 2017 23:43:42 +0000 Message-ID: <1489707814324.24704@cs.auckland.ac.nz> References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> <1489419619.3159.25.camel@redhat.com> <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> <43102E1B-C072-4CE2-9A3E-CDEDE1536AFB@gmail.com> <0DE34F3E-A2D2-4396-B12C-D9FD30DC3723@gmail.com> <1489531750610.15665@cs.auckland.ac.nz> , <7C8644BA-F890-4A1A-886B-50AC1A43D9A7@docusign.com> <1489620354611.31679@cs.auckland.ac.nz> , <1489633948908.28319@cs.auckland.ac.nz>, <1489654504.32197.3.camel@redhat.com> In-Reply-To: <1489654504.32197.3.camel@redhat.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Curdle] Some work for the group 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, 16 Mar 2017 23:43:46 -0000 Nikos Mavrogiannopoulos writes:=0A= =0A= >Which implementations have you checked? =0A= =0A= I didn't, the comment was forwarded to me one of the people who were=0A= discussing it. Since it's embedded, I'm guessing a pile of embedded=0A= libraries, but I don't have any direct access to the discussion.=0A= =0A= >while openssl reported it as expiring on:=0A= > Dec 31 23:59:59 9999 GMT - the date saved in the certificate=0A= =0A= What does a 32-bit version do?=0A= =0A= My code just relies on mktime(), with two pages of special-case handling fo= r=0A= times close to 2038 (some mktime()s do odd things when you get within a few= =0A= years of that date), just plain broken mktime()s, and other oddities, e.g.:= =0A= =0A= /* Some broken apps set dates to 1/1/1970, handling times this close =0A= to the epoch is problematic because once any possible DST =0A= adjustment is taken into account it's no longer possible to=0A= represent the converted time as a time_t unless the system allows=0A= it to be negative (Windows doesn't, many Unixen do, but having=0A= cryptlib return a negative time value is probably a bad thing). =0A= To handle this, if we find a date set anywhere during January 1970 =0A= we manually set the time to zero (the epoch) */=0A= =0A= So on a 64-bit system it'd do the same as OpenSSL and on a 32-bit system it= 'd=0A= do whatever the local mktime() ends up doing, provided one of the many fixu= p=0A= checks aren't triggered in which case it'll get pegged at the time_t versio= n=0A= of 0 or INT_MAX.=0A= =0A= Peter.=0A= From nobody Fri Mar 17 02:39:42 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 D50AA12704A for ; Fri, 17 Mar 2017 02:39:40 -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 u942I_nJoase for ; Fri, 17 Mar 2017 02:39:39 -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 667D2126DC2 for ; Fri, 17 Mar 2017 02:39:39 -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 877C380503; Fri, 17 Mar 2017 09:39:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 877C380503 Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=nmav@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 877C380503 Received: from dhcp-10-40-1-102.brq.redhat.com (unknown [10.40.3.26]) by smtp.corp.redhat.com (Postfix) with ESMTPS id ADEDC18AA9; Fri, 17 Mar 2017 09:39:38 +0000 (UTC) Message-ID: <1489743577.2802.1.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Peter Gutmann , Curdle Date: Fri, 17 Mar 2017 10:39:37 +0100 In-Reply-To: <1489707814324.24704@cs.auckland.ac.nz> References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> <1489419619.3159.25.camel@redhat.com> <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> <43102E1B-C072-4CE2-9A3E-CDEDE1536AFB@gmail.com> <0DE34F3E-A2D2-4396-B12C-D9FD30DC3723@gmail.com> <1489531750610.15665@cs.auckland.ac.nz> , <7C8644BA-F890-4A1A-886B-50AC1A43D9A7@docusign.com> <1489620354611.31679@cs.auckland.ac.nz> , <1489633948908.28319@cs.auckland.ac.nz> ,<1489654504.32197.3.camel@redhat.com> <1489707814324.24704@cs.auckland.ac.nz> 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.27]); Fri, 17 Mar 2017 09:39:39 +0000 (UTC) Archived-At: Subject: Re: [Curdle] Some work for the group 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, 17 Mar 2017 09:39:41 -0000 On Thu, 2017-03-16 at 23:43 +0000, Peter Gutmann wrote: > Nikos Mavrogiannopoulos writes: > > > Which implementations have you checked?  > > I didn't, the comment was forwarded to me one of the people who were > discussing it.  Since it's embedded, I'm guessing a pile of embedded > libraries, but I don't have any direct access to the discussion. > > > while openssl reported it as expiring on: > >  Dec 31 23:59:59 9999 GMT - the date saved in the certificate > > What does a 32-bit version do? My comments were for the 32-bit versions of gnutls and openssl. > > My code just relies on mktime(), with two pages of special-case > handling for > times close to 2038 (some mktime()s do odd things when you get within > a few > years of that date), just plain broken mktime()s, and other oddities, > e.g.: > > /* Some broken apps set dates to 1/1/1970, handling times this > close  >    to the epoch is problematic because once any possible DST  >    adjustment is taken into account it's no longer possible to >    represent the converted time as a time_t unless the system > allows >    it to be negative (Windows doesn't, many Unixen do, but > having >    cryptlib return a negative time value is probably a bad > thing).   >    To handle this, if we find a date set anywhere during > January 1970  >    we manually set the time to zero (the epoch) */ > > So on a 64-bit system it'd do the same as OpenSSL and on a 32-bit > system it'd > do whatever the local mktime() ends up doing, provided one of the > many fixup > checks aren't triggered in which case it'll get pegged at the time_t > version > of 0 or INT_MAX. What we used in gnutls is to include a correct mktime() and have dates after 2038 map to the time_t representing 2037-12-31 23:23:23 in 32-bit systems (I believe that was originally used by gnupg). regards, Nikos From nobody Fri Mar 17 03:21: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 09C00126B72 for ; Fri, 17 Mar 2017 03:21:17 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rc9vgD9A5GwF for ; Fri, 17 Mar 2017 03:21:15 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B146C126DEE for ; Fri, 17 Mar 2017 03:21:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1489746074; x=1521282074; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Cofcpl2SC3VbqdYPcIJhoT01j5VF2UhwMIT0YzJP5D0=; b=q0QzzqV8Ua6ady/Kvi4umSFYGlg9XQmpFM0tepOlmQgrCG0QTi9aNEm4 U9M5FmJ9Q3HJIvZJjjpgW4WdpJl64sSrA8r+Yoa7XAhwP65fAG6KHaEhx 8owR8BpbjYH4rRZZM3kXnNupNtg3RrHf9fq+srmJmTbZCD0+eUXb6k7QR 8UwfNGv2VLD+ORmDZGza4VPeH2/0qqEei28Ke1WvVSdjCSEPYGThH8Nyg fEdCAVkjzjD7AgqUNCLLqJr/iT47ReXm4FHpm0uYqHVjeQs1LYYgQTarf R79/ylwnGL4VYOuKe9Rf2JqT24hXbtvPeB9lNYMJPFyR7TkczrobmhrSW w==; X-IronPort-AV: E=Sophos;i="5.36,176,1486378800"; d="scan'208";a="143648333" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.9 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-e.UoA.auckland.ac.nz) ([10.6.3.9]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 17 Mar 2017 23:21:11 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-e.UoA.auckland.ac.nz (10.6.3.9) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 17 Mar 2017 23:21:11 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1178.000; Fri, 17 Mar 2017 23:21:11 +1300 From: Peter Gutmann To: Nikos Mavrogiannopoulos , Curdle Thread-Topic: [Curdle] Some work for the group Thread-Index: AQHScQasYv1qbtR3EECCo4rUC94EmqFOKF8AgABRogCAB4KXgIAbAeCAgABR0wCAGzCCAIABO9kAgAADkQCABJSmAIAAD2SAgAABHICAABstgIABNbGAgAANNACAAYST94AAVDmAgAFIfJj//1YfgIAA6TAg//+GAACAAdIGq///zMGAAByrUSk= Date: Fri, 17 Mar 2017 10:21:10 +0000 Message-ID: <1489746061487.48735@cs.auckland.ac.nz> References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> <1489419619.3159.25.camel@redhat.com> <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> <43102E1B-C072-4CE2-9A3E-CDEDE1536AFB@gmail.com> <0DE34F3E-A2D2-4396-B12C-D9FD30DC3723@gmail.com> <1489531750610.15665@cs.auckland.ac.nz> , <7C8644BA-F890-4A1A-886B-50AC1A43D9A7@docusign.com> <1489620354611.31679@cs.auckland.ac.nz> , <1489633948908.28319@cs.auckland.ac.nz> ,<1489654504.32197.3.camel@redhat.com> <1489707814324.24704@cs.auckland.ac.nz>,<1489743577.2802.1.camel@redhat.com> In-Reply-To: <1489743577.2802.1.camel@redhat.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Curdle] Some work for the group 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, 17 Mar 2017 10:21:17 -0000 Nikos Mavrogiannopoulos writes:=0A= =0A= >My comments were for the 32-bit versions of gnutls and openssl.=0A= =0A= Hmm, I wonder how it manages to deal with a date past 2038 when time_t is 3= 2-=0A= bits?=0A= =0A= >What we used in gnutls is to include a correct mktime() and have dates aft= er=0A= >2038 map to the time_t representing 2037-12-31 23:23:23 in 32-bit systems = (I=0A= >believe that was originally used by gnupg).=0A= =0A= I thought about doing that, but then it wouldn't be consistent with the=0A= system-provided mktime(), and some customers value consistency above accura= cy=0A= - having my code provide a different time value than the system mktime() is= a=0A= bad thing, even if the system mktime() is wrong. For example the Tandem NS= K=0A= mktime() gets funny for dates after about 2030, but since it's used by some= =0A= very large banks and they don't want inconsistency in the handling of time= =0A= values, the system mktime() gets used, warts and all.=0A= =0A= Peter.=0A= From nobody Fri Mar 17 05:53: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 C22B61293F8 for ; Fri, 17 Mar 2017 05:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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, RP_MATCHES_RCVD=-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=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 F2-Jjk6Wt_cy for ; Fri, 17 Mar 2017 05:52:59 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 77D03129400 for ; Fri, 17 Mar 2017 05:52:58 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 137B720001A; Fri, 17 Mar 2017 12:52:58 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id F1440200004; Fri, 17 Mar 2017 12:52:57 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1489755177; bh=uOVqj+ES6yQf8PewOfL0dUEnwtqrIqn5b1b7Goisy+E=; l=228; h=From:To:Date:References:In-Reply-To:From; b=WfG8/YPFU6Z3029A6NuBXSjbD63iOlmCvLRTY7FrLKd23+K04fLoErseyHJ7QWVOg nsb1McAMzNy8cT+rB3LhLowrlKAV+hBBnP+uNFRUMspKuwd149/pVAhpgmbU49GHI9 JFtkSNKd5BNgI+ge0eCoBtOx2siNXG4/K1vww+y4= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.34]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id C697C98082; Fri, 17 Mar 2017 12:52:57 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 17 Mar 2017 08:52:57 -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.1178.000; Fri, 17 Mar 2017 08:52:57 -0400 From: "Salz, Rich" To: Peter Gutmann , Nikos Mavrogiannopoulos , Curdle Thread-Topic: [Curdle] Some work for the group Thread-Index: AQHScQapPZALJc3H1k6dKeAsT1IqsaFPVh8AgABRoQCAB4KXgIAbEqWAgABR0gCAGx+/AIABO9kAgAADkQCABIPiAIAAD2SA//+9XyCAAF7qgIABNbGAgAANNACAAKr9AIABLc+AgABuzYCAAC/OgIAAD3+AgABfsQCAAPhIAIAApn+AgAALnAD//+c9gA== Date: Fri, 17 Mar 2017 12:52:56 +0000 Message-ID: <1e9dccf0f37c41a1ab9dbd872c672a72@usma1ex-dag1mb1.msg.corp.akamai.com> References: <1481788992.2779.15.camel@redhat.com> <1485685950.1687.1.camel@redhat.com> <1487583567.3038.8.camel@redhat.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11801A623@eusaamb107.ericsson.se> <8F5A17C6-E064-4DD4-A08D-5147222083EA@vigilsec.com> <20170310164810.GB1636@LK-Perkele-V2.elisa-laajakaista.fi> <1489419619.3159.25.camel@redhat.com> <87ac93cc059148eb9c07d4626156aa75@usma1ex-dag1mb1.msg.corp.akamai.com> <43102E1B-C072-4CE2-9A3E-CDEDE1536AFB@gmail.com> <0DE34F3E-A2D2-4396-B12C-D9FD30DC3723@gmail.com> <1489531750610.15665@cs.auckland.ac.nz> , <7C8644BA-F890-4A1A-886B-50AC1A43D9A7@docusign.com> <1489620354611.31679@cs.auckland.ac.nz> , <1489633948908.28319@cs.auckland.ac.nz> ,<1489654504.32197.3.camel@redhat.com> <1489707814324.24704@cs.auckland.ac.nz>,<1489743577.2802.1.camel@redhat.com> <1489746061487.48735@cs.auckland.ac.nz> In-Reply-To: <1489746061487.48735@cs.auckland.ac.nz> 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.244] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Curdle] Some work for the group 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, 17 Mar 2017 12:53:01 -0000 > >My comments were for the 32-bit versions of gnutls and openssl. >=20 > Hmm, I wonder how it manages to deal with a date past 2038 when time_t is > 32- bits? OpenSSL does not use time_t for its cert date manipulations. From pkixssh@roumenpetrov.info Sat Mar 18 01:27: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 D016C1201FA for ; Sat, 18 Mar 2017 01:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7GIlnogSUGrQ for ; Sat, 18 Mar 2017 01:26:59 -0700 (PDT) Received: from rila.superhosting.bg (rila.superhosting.bg [91.196.125.212]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F11D9120724 for ; Sat, 18 Mar 2017 01:26:58 -0700 (PDT) Received: from [78.128.48.21] (port=36640 helo=[192.168.0.10]) by rila.superhosting.bg with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.87) (envelope-from ) id 1cp9hP-000we7-RB for curdle@ietf.org; Sat, 18 Mar 2017 10:26:55 +0200 Message-ID: <58CCEF4F.7000902@roumenpetrov.info> Date: Sat, 18 Mar 2017 10:26:55 +0200 From: =?UTF-8?B?0KDRg9C80LXQvSDQn9C10YLRgNC+0LI=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Firefox/33.0 SeaMonkey/2.30 MIME-Version: 1.0 To: curdle@ietf.org References: <148823325745.13859.1818801191554779419.idtracker@ietfa.amsl.com> In-Reply-To: <148823325745.13859.1818801191554779419.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - rila.superhosting.bg X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - roumenpetrov.info X-Get-Message-Sender-Via: rila.superhosting.bg: authenticated_id: master78@roumenpetrov.info X-Authenticated-Sender: rila.superhosting.bg: master78@roumenpetrov.info X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-ssh-ext-info-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: Sat, 18 Mar 2017 08:28:28 -0000 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 : Extension Negotiation in Secure Shell (SSH) > Author : Denis Bider > Filename : draft-ietf-curdle-ssh-ext-info-02.txt > Pages : 8 > Date : 2017-02-27 It seems to me published version is 3 - https://tools.ietf.org/html/draft-ietf-curdle-rsa-sha2-03 . > Abstract: > This memo defines a mechanism for SSH clients and servers to exchange > information about supported protocol extensions confidentially after > completed key exchange. Following notation s/old/new/ is used to describe proposed text substitution. About chapter: (*) 2 . "Public Key Algorithms": This chapter is mainly for algorithms not signatures: ... The following new s/signature/public key/ algorithms are defined: ... ... These s/signature //algorithms are suitable for use both in the SSH transport .... (*) 2.1. Use for server authentication What about ... server sends an s/"ssh-rsa" public key/RSA public key in "ssh-rsa" format/ as part of the negotiated key exchange method ... ? (*) 2.2. Use for client authentication ...The "public key blob" field encodes the RSA public key using the "ssh-rsa" s/algorithm name/format/... Regards, Roumen Petrov From nobody Sat Mar 18 02:01:12 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 0B359124BFA for ; Sat, 18 Mar 2017 02:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dauEQ2xFoQM2 for ; Sat, 18 Mar 2017 02:01:09 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB0B4120724 for ; Sat, 18 Mar 2017 02:01:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1489827668; x=1521363668; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=AC/v8779tID/Eq8Jdipxsq2kjIodRuG7nw7QD09psyY=; b=bz+z1ShR/U8mnr5xoVcciHlEWWx2S/IY8c7i1CoMlPhJN1Iw0llxHxY1 ij0Bbf7xzNXtozDFnksxERbw7ZQtFeB4THv/LLzTHKtXyzuM/W11vEUFP PkT22ybG/Qo7r6o45G3BqH7R8QXZ7PTAMjX2xDdpsJBJl41uPjW3jZwPq FlojmQJFNFWQxX/qprzUweoKXTggqGmgxTv48P/n5FSKhwo+SoHZATiKw tksx5EbVULj0FHs3flITppgYFvsfugjmw1GlJEVCsmEd/nkZBR1MyNMwF KI41D3yjWUI7Q/mAnjsQQ6+3XQzPDw6IvUj5wjgN+LjO+YPp+ayzIcCgC A==; X-IronPort-AV: E=Sophos;i="5.36,181,1486378800"; d="scan'208";a="143788723" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.2 - Outgoing - Outgoing Received: from smtp.uoa.auckland.ac.nz (HELO uxcn13-tdc-a.UoA.auckland.ac.nz) ([10.6.3.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 18 Mar 2017 22:01:06 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-a.UoA.auckland.ac.nz (10.6.3.2) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sat, 18 Mar 2017 22:01:05 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1178.000; Sat, 18 Mar 2017 22:01:05 +1300 From: Peter Gutmann To: Daniel Migault , curdle Thread-Topic: [Curdle] Multiple WGLC Thread-Index: AdKcoRzefuKObAUvSL+sk19Vkzo63gDJMroH Date: Sat, 18 Mar 2017 09:01:05 +0000 Message-ID: <1489827654266.43895@cs.auckland.ac.nz> References: <2DD56D786E600F45AC6BDE7DA4E8A8C118BA5A70@eusaamb107.ericsson.se> In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C118BA5A70@eusaamb107.ericsson.se> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Curdle] Multiple WGLC 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, 18 Mar 2017 09:01:11 -0000 Daniel Migault writes:=0A= =0A= >This emails starts a WGLC on the following drafts:=0A= >=0A= >=A0 =A0 - draft-ietf-curdle-rsa-sha2-03 [1]=0A= >=A0=A0=A0 - draft-ietf-curdle-ssh-ext-info-02 [2]=0A= >=A0=A0=A0 - draft-ietf-curdle-ssh-kex-sha2-05 [3]=0A= >=A0=A0=A0 - draft-ietf-curdle-ssh-modp-dh-sha2-02 [4]=0A= >=0A= >Please provide your comments by March 28 on the mailing list. =0A= =0A= draft-ietf-curdle-ssh-modp-dh-sha2-02:=0A= =0A= Section 5, "Many users seem to be interested in the perceived safety of usi= ng=0A= larger MODP groups and hashing with SHA2-based algorithms", should that tex= t=0A= be there? It seems rather out of place, orphaned between Figure 2 and the= =0A= References section.=0A= =0A= draft-ietf-curdle-ssh-ext-info-02.txt:=0A= =0A= Section 2.3, "This message is sent without delay", I'm not really sure what= to=0A= do with this requirement, why would there be a delay, necessitating a need = to=0A= say that it's sent without delay?=0A= =0A= Section 2.3: "and immediately after SSH_MSG_NEWKEYS", whose NEWKEYs? Logic= =0A= would seem to indicate that it's after both sending and receiving NEWKEYs t= o=0A= confirm that the connection is secured, but the text is ambiguous.=0A= =0A= Section 2.4: "If the client sent "ext-info-c", the server MAY send, but is = not=0A= obligated to send, an SSH_MSG_EXT_INFO message immediately before=0A= SSH_MSG_USERAUTH_SUCCESS, as defined in [RFC4252]", I've already commented = on=0A= this before, this just seems weird, the client sends its=0A= SSH_MSG_USERAUTH_REQUEST and instead of getting back SSH_MSG_USERAUTH_SUCCE= SS=0A= or SSH_MSG_USERAUTH_FAILURE it gets this odd out-of-place extension message= =0A= packed in front of the success/failure indication that it's actually=0A= interested in.=0A= =0A= Section 3.1, "a client SHALL NOT", given that the rest of the document uses= =0A= MUST or SHOULD it'd be better to use that form as well here to save people= =0A= having to look up whether MUST or SHOULD is intended.=0A= =0A= Section 3.2, "Former versions of this document defined extensions with name= s=0A= enumerated in this heading. These proposals are removed due to current lack= of=0A= implementation", isn't that an oxymoron? If it's not in a published RFC,= =0A= people will be reluctant to implement it, or enable it if it's implemented.= =0A= I'm certainly ready to go with "no-flow-control", but haven't enabled it=0A= because I don't know what'll change, or break, before the spec is finalised= .=0A= =0A= Peter.=0A= From nobody Sat Mar 18 06:18:59 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 B8F7B127601 for ; Sat, 18 Mar 2017 06:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 Nb2npV4upYzK for ; Sat, 18 Mar 2017 06:18:55 -0700 (PDT) Received: from rila.superhosting.bg (rila.superhosting.bg [91.196.125.212]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88A5C1271DF for ; Sat, 18 Mar 2017 06:18:53 -0700 (PDT) Received: from [78.128.48.21] (port=36736 helo=[192.168.0.10]) by rila.superhosting.bg with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.87) (envelope-from ) id 1cpEFv-000t4p-8V for curdle@ietf.org; Sat, 18 Mar 2017 15:18:51 +0200 Message-ID: <58CD33BA.4030102@roumenpetrov.info> Date: Sat, 18 Mar 2017 15:18:50 +0200 From: =?UTF-8?B?0KDRg9C80LXQvSDQn9C10YLRgNC+0LI=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Firefox/33.0 SeaMonkey/2.30 MIME-Version: 1.0 To: curdle@ietf.org References: <148823325745.13859.1818801191554779419.idtracker@ietfa.amsl.com> <58CCEF4F.7000902@roumenpetrov.info> In-Reply-To: <58CCEF4F.7000902@roumenpetrov.info> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - rila.superhosting.bg X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - roumenpetrov.info X-Get-Message-Sender-Via: rila.superhosting.bg: authenticated_id: master78@roumenpetrov.info X-Authenticated-Sender: rila.superhosting.bg: master78@roumenpetrov.info X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-ssh-ext-info-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: Sat, 18 Mar 2017 13:18:57 -0000 Hello Sorry for confusion in my previous feedback, quote below I chose wrong subject. About About (*) 3.1. "server-sig-algs" from draft-ietf-curdle-ssh-ext-info-02.txt I'm not sure why whole chapter use signature(?) algorithm . Draft draft-ietf-curdle-rsa-sha2-03 describes new public key algorithm. In rfc4252 and rfc4253 is used public key algorithm. I think that correct option must use "public key" instead "signature" in its name and chapter to mention only algorithms. About name-list s/signature/publickey/-algorithms-accepted Its not clear how to list "publickey" algorithms. name-list is - list of strings, each string is name of public key algorithm - space separated list of public key algorithm names - comma separated list of public key algorithm names (*) 3.2. "no-flow-control", "accept-channels", "elevation" It seems to me those elements are subject of future extension. If necessary they could be described in new draft. Regards, Roumen Petrov P.S. previous feedback: Румен Петров wrote: > [SNIP] > Following notation s/old/new/ is used to describe proposed text > substitution. > > About chapter: > (*) 2 . "Public Key Algorithms": > This chapter is mainly for algorithms not signatures: > ... The following new s/signature/public key/ algorithms are defined: ... > ... These s/signature //algorithms are suitable for use both in the > SSH transport .... > > > (*) 2.1. Use for server authentication > What about > ... server sends an s/"ssh-rsa" public key/RSA public key in "ssh-rsa" > format/ as part of the negotiated key exchange method ... ? > > > (*) 2.2. Use for client authentication > ...The "public key blob" field encodes the RSA public key using the > "ssh-rsa" s/algorithm name/format/... > > > Regards, > Roumen Petrov From nobody Sat Mar 18 06:31:11 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 305DA127871 for ; Sat, 18 Mar 2017 06:31:09 -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=denisbider.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 z8rjyJ1sGDHE for ; Sat, 18 Mar 2017 06:31:05 -0700 (PDT) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BC2812708C for ; Sat, 18 Mar 2017 06:31:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=denisbider.com; s=mail; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to: references; bh=tcTL/UXA+/Ikytacx+zinMDBQnHHQk2NQjqV3DO3LaM=; b=T/8/8KVqWPcfu3D1JjwSpR6PTW89+qnkDelmt/4rWplCp414XuSeIiavAzcNWxjfhG85lUKvGnHDY HHr5Zh1usVYqEpubp/JMX5azBULeFTmqlOd/xfaXw4HFaDQ2BjIhLggZohTengmMT8V4emq2p8L/YT XjjFEOP6l22x85GBExwDTMyGdY1W7rQX7NNMFeS+LbaRsFCkntkNX3aEi2kUlZmkEyEmUfWaH2ZOFC MRD9m9px+xLFgH9VlIDuNyFvsScLiHfgGUVoLnhXZqwO786cfh0bsRqk8qkC3F8o7Tuh+fXpGxdfpA 5jKCaITTCoM4Jis/HUA3CqkFbx1ONkA== X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)); Sat, 18 Mar 2017 13:30:44 +0000 Message-ID: <50977E6A3D174856B8DAF264C3CB81E8@Khan> From: "denis bider \(Bitvise\)" To: "Peter Gutmann" , "Daniel Migault" , "curdle" References: <2DD56D786E600F45AC6BDE7DA4E8A8C118BA5A70@eusaamb107.ericsson.se> <1489827654266.43895@cs.auckland.ac.nz> In-Reply-To: <1489827654266.43895@cs.auckland.ac.nz> Date: Sat, 18 Mar 2017 07:30:48 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E2_01D29FB9.9055BD70" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [Curdle] Comments on draft-ietf-curdle-ssh-ext-info 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, 18 Mar 2017 13:31:09 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00E2_01D29FB9.9055BD70 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Reply to Peter=E2=80=99s comments on the SSH EXT_INFO draft: > Section 2.3, "This message is sent without delay", I'm not really > sure what to do with this requirement, why would there be a delay, > necessitating a need to say that it's sent without delay? There is no reason for a delay, but people do things for which there = aren=E2=80=99t good reasons, and then others in the future have to = compensate. This is to nip the problem in the bud. There are three extensions defined at this time. Two in this draft, one = in another (an independent submission). One extension, server-sig-algs, is in widespread use. This is the = extension that motivated this mechanism. It is needed to efficiently = implement the rsa-sha2-256 and rsa-sha2-512 signature methods for user = authentication. The client has a need to know the server-sig-algs = information before it sends its first user authentication request. If the EXT_INFO from the server is delayed =E2=80=93 which it can be due = to network fragmentation, even if the server follows the spec and sends = it immediately after its NEWKEYS =E2=80=93 this negatively impacts the = client=E2=80=99s ability to pipeline user authentication. It=E2=80=99s = not a breaking issue, but it creates a delay that affects user = experience. For example, the client knows that it=E2=80=99s going to authenticate = using an RSA key, but it doesn=E2=80=99t know whether it=E2=80=99s going = to use =E2=80=9Cssh-rsa=E2=80=9D or =E2=80=9Crsa-sha2-256=E2=80=9D or = =E2=80=9Crsa-sha2-512=E2=80=9D. The client can=E2=80=99t guess, because = there are servers that apply an authentication penalty for the wrong = algorithm. To improve user experience (shorten delays), the client wants = to pipeline the authentication request so it=E2=80=99s sent in the same = socket write as its SSH_MSG_SERVICE_REQUEST (because there=E2=80=99s no = reason to wait for SERVICE_ACCEPT). If the EXT_INFO comes from the server in the same message as NEWKEYS, = the client can pipeline the user authentication immediately. Otherwise, = if the EXT_INFO is delayed, the client has to wait either until either = EXT_INFO arrives, or SERVICE_ACCEPT is received (implying there = won=E2=80=99t be an EXT_INFO at this stage, at least until successful = authentication). Does the draft need to be modified to make this explicit? > and immediately after SSH_MSG_NEWKEYS", whose NEWKEYs? > Logic would seem to indicate that it's after both sending and > receiving NEWKEYs to confirm that the connection is secured, > but the text is ambiguous. The two sending directions are independent. EXT_INFO does not have the = nature of a response, so it=E2=80=99s not conditional on anything = happening in the other direction. EXT_INFO is sent by the party that sends it, immediately after that = party has sent its own NEWKEYS. Doing otherwise would contradict the = =E2=80=9Cwithout delay=E2=80=9D requirement. Does the draft need to be modified to clarify this? > Section 2.4: "If the client sent "ext-info-c", the server MAY send, > but is not obligated to send, an SSH_MSG_EXT_INFO message > immediately before SSH_MSG_USERAUTH_SUCCESS, as defined > in [RFC4252]", I've already commented on this before, this just > seems weird, the client sends its SSH_MSG_USERAUTH_REQUEST > and instead of getting back SSH_MSG_USERAUTH_SUCCESS > or SSH_MSG_USERAUTH_FAILURE it gets this odd out-of-place > extension message packed in front of the success/failure > indication that it's actually interested in. We are discussing an SSH client that implements this specification, and = therefore expects this message. Therefore, this message is not = unexpected, and is exactly in its defined place. Placement of this message immediately before SSH_MSG_USERAUTH_SUCCESS is = the best time to send a second EXT_INFO, in case the SSH server wants to = advertise extensions to authenticated clients that it does not want to = advertise to unauthenticated ones. One extension that needs this exact placement is = =E2=80=9Cdelay-compression=E2=80=9D. For that to work, the client has a = need to know whether compression should be started at the exact point it = receives SSH_MSG_USERAUTH_SUCCESS. But the server may be reluctant to = advertise its support for compression beforehand. Sending the second = EXT_INFO at this time is therefore ideal for both parties. (If it was = sent after SSH_MSG_USERAUTH_SUCCESS, there would be the exact race = condition that =E2=80=9Cdelay-compression=E2=80=9D is trying to solve.) In practice, handling this message at this time has been no trouble to = implement. In our implementation, there has been literally zero extra = code to support this. > Section 3.1, "a client SHALL NOT", given that the rest of the > document uses MUST or SHOULD it'd be better to use that > form as well here to save people having to look up whether > MUST or SHOULD is intended. The word =E2=80=9Cshall=E2=80=9D has a well-known meaning in English, = and its use in this context is defined in RFC 2119. If this word was not = meant to be used, I think RFC 2119 would not define it. Someone who implements this draft will also likely have implemented RFC = 4253 (The Secure Shell (SSH) Transport Layer Protocol), which uses SHALL = in section 4.2. I personally like this word. If a new version of the draft is needed for = another reason, I can make this change, though. > These proposals are removed due to current lack of implementation", > isn't that an oxymoron? I have seen implementation happen when a developer recognizes the need, = and the RFC comes a few years later, if at all. (For example, SFTP is in widespread use, but due to past implementer = disagreement about whether there should be a version after 3, we have no = RFC for SFTP. The SFTP drafts serve as the de facto spec.) My understanding, also, is that IETF expects implementations to exist in = order to bless an RFC =E2=80=93 at least two independent implementations = ideally, or at least one minimum. Perhaps I=E2=80=99m mistaken on this? > I'm certainly ready to go with "no-flow-control", but haven't > enabled it because I don't know what'll change, or break, > before the spec is finalised. That=E2=80=99s why I asked before if there=E2=80=99s actual interest in = this extension. :-) I didn=E2=80=99t receive feedback, so after waiting = a few months, I thought it would reduce the burden on the working group = if I removed it. At this point, I can: - put it back in, just like it was; or - make it an independent submission. Given the cryptographic orientation of this group, and the flow-control = oriented nature of this extension, perhaps an independent draft would be = better? I=E2=80=99m doing something similar for = =E2=80=9Cext-auth-info=E2=80=9D here: https://tools.ietf.org/html/draft-ssh-ext-auth-info-00 The only problem with an independent submission, if I make it, is that I = have no idea how to shepherd it to RFC. That doesn=E2=80=99t stop me = from writing drafts, though, because experience with SFTP shows a draft = is still better than nothing. :) denis From: Peter Gutmann=20 Sent: Saturday, March 18, 2017 03:01 To: Daniel Migault ; curdle=20 Subject: Re: [Curdle] Multiple WGLC Daniel Migault writes: >This emails starts a WGLC on the following drafts: > > - draft-ietf-curdle-rsa-sha2-03 [1] > - draft-ietf-curdle-ssh-ext-info-02 [2] > - draft-ietf-curdle-ssh-kex-sha2-05 [3] > - draft-ietf-curdle-ssh-modp-dh-sha2-02 [4] > >Please provide your comments by March 28 on the mailing list.=20 draft-ietf-curdle-ssh-modp-dh-sha2-02: Section 5, "Many users seem to be interested in the perceived safety of = using larger MODP groups and hashing with SHA2-based algorithms", should that = text be there? It seems rather out of place, orphaned between Figure 2 and = the References section. draft-ietf-curdle-ssh-ext-info-02.txt: Section 2.3, "This message is sent without delay", I'm not really sure = what to do with this requirement, why would there be a delay, necessitating a = need to say that it's sent without delay? Section 2.3: "and immediately after SSH_MSG_NEWKEYS", whose NEWKEYs? = Logic would seem to indicate that it's after both sending and receiving = NEWKEYs to confirm that the connection is secured, but the text is ambiguous. Section 2.4: "If the client sent "ext-info-c", the server MAY send, but = is not obligated to send, an SSH_MSG_EXT_INFO message immediately before SSH_MSG_USERAUTH_SUCCESS, as defined in [RFC4252]", I've already = commented on this before, this just seems weird, the client sends its SSH_MSG_USERAUTH_REQUEST and instead of getting back = SSH_MSG_USERAUTH_SUCCESS or SSH_MSG_USERAUTH_FAILURE it gets this odd out-of-place extension = message packed in front of the success/failure indication that it's actually interested in. Section 3.1, "a client SHALL NOT", given that the rest of the document = uses MUST or SHOULD it'd be better to use that form as well here to save = people having to look up whether MUST or SHOULD is intended. Section 3.2, "Former versions of this document defined extensions with = names enumerated in this heading. These proposals are removed due to current = lack of implementation", isn't that an oxymoron? If it's not in a published = RFC, people will be reluctant to implement it, or enable it if it's = implemented. I'm certainly ready to go with "no-flow-control", but haven't enabled it because I don't know what'll change, or break, before the spec is = finalised. Peter. _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle ------=_NextPart_000_00E2_01D29FB9.9055BD70 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Reply to Peter=E2=80=99s comments on = the SSH EXT_INFO=20 draft:
 
 
> Section 2.3, "This message is = sent without=20 delay", I'm not really
> sure what to do with this = requirement, why=20 would there be a delay,
> necessitating a need to say that = it's sent=20 without delay?
There is no reason for a delay, but = people do=20 things for which there aren=E2=80=99t good reasons, and then others in = the future have=20 to compensate. This is to nip the problem in the bud.
 
There are three extensions defined at = this time.=20 Two in this draft, one in another (an independent = submission).
 
One extension, server-sig-algs, is in = widespread=20 use. This is the extension that motivated this mechanism. It is needed = to=20 efficiently implement the rsa-sha2-256 and rsa-sha2-512 signature = methods for=20 user authentication. The client has a need to know the server-sig-algs=20 information before it sends its first user authentication = request.
 
If the EXT_INFO from the server is = delayed =E2=80=93=20 which it can be due to network fragmentation, even if the server follows = the=20 spec and sends it immediately after its NEWKEYS =E2=80=93 this = negatively impacts the=20 client=E2=80=99s ability to pipeline user authentication. It=E2=80=99s = not a breaking issue, but=20 it creates a delay that affects user experience.
 
For example, the client knows that = it=E2=80=99s going to=20 authenticate using an RSA key, but it doesn=E2=80=99t know whether = it=E2=80=99s going to use=20 =E2=80=9Cssh-rsa=E2=80=9D or =E2=80=9Crsa-sha2-256=E2=80=9D or = =E2=80=9Crsa-sha2-512=E2=80=9D. The client can=E2=80=99t guess, because=20 there are servers that apply an authentication penalty for the wrong = algorithm.=20 To improve user experience (shorten delays), the client wants to = pipeline the=20 authentication request so it=E2=80=99s sent in the same socket write as = its=20 SSH_MSG_SERVICE_REQUEST (because there=E2=80=99s no reason to wait for=20 SERVICE_ACCEPT).
 
If the EXT_INFO comes from the server = in the same=20 message as NEWKEYS, the client can pipeline the user authentication = immediately.=20 Otherwise, if the EXT_INFO is delayed, the client has to wait either = until=20 either EXT_INFO arrives, or SERVICE_ACCEPT is received (implying there = won=E2=80=99t be=20 an EXT_INFO at this stage, at least until successful=20 authentication).
 
Does the draft need to be modified to = make this=20 explicit?
 
 
> and immediately after = SSH_MSG_NEWKEYS",=20 whose NEWKEYs?
> Logic would seem to indicate = that it's after=20 both sending and
> receiving NEWKEYs to confirm = that the=20 connection is secured,
> but the text is = ambiguous.
 
The two sending directions are = independent.=20 EXT_INFO does not have the nature of a response, so it=E2=80=99s not = conditional on=20 anything happening in the other direction.
 
EXT_INFO is sent by the party that = sends it,=20 immediately after that party has sent its own NEWKEYS. Doing otherwise = would=20 contradict the =E2=80=9Cwithout delay=E2=80=9D requirement.
 
Does the draft need to be modified to = clarify=20 this?
 
 
> Section 2.4: "If the client sent = "ext-info-c", the server MAY send,
> but is not obligated to send, an = SSH_MSG_EXT_INFO message
> immediately before = SSH_MSG_USERAUTH_SUCCESS,=20 as defined
> in [RFC4252]", I've already = commented on=20 this before, this just
> seems weird, the client sends = its=20 SSH_MSG_USERAUTH_REQUEST
> and instead of getting back=20 SSH_MSG_USERAUTH_SUCCESS
> or SSH_MSG_USERAUTH_FAILURE it gets = this odd=20 out-of-place
> extension message packed in = front of the=20 success/failure
> indication that it's actually = interested=20 in.
We are discussing an SSH client that = implements=20 this specification, and therefore expects this message. Therefore, this = message=20 is not unexpected, and is exactly in its defined place.
 
Placement of this message immediately = before=20 SSH_MSG_USERAUTH_SUCCESS is the best time to send a second EXT_INFO, in = case the=20 SSH server wants to advertise extensions to authenticated clients that = it does=20 not want to advertise to unauthenticated ones.
 
One extension that needs this exact = placement is=20 =E2=80=9Cdelay-compression=E2=80=9D. For that to work, the client has a = need to know whether=20 compression should be started at the exact point it receives=20 SSH_MSG_USERAUTH_SUCCESS. But the server may be reluctant to advertise = its=20 support for compression beforehand. Sending the second EXT_INFO at this = time is=20 therefore ideal for both parties. (If it was sent after=20 SSH_MSG_USERAUTH_SUCCESS, there would be the exact race condition that=20 =E2=80=9Cdelay-compression=E2=80=9D is trying to solve.)
 
In practice, handling this message at = this time=20 has been no trouble to implement. In our implementation, there has been=20 literally zero extra code to support this.
 
 
> Section 3.1, "a client SHALL = NOT", given=20 that the rest of the
> document uses MUST or SHOULD = it'd be better=20 to use that
> form as well here to save people = having to=20 look up whether
> MUST or SHOULD is = intended.
The word =E2=80=9Cshall=E2=80=9D has = a well-known meaning in=20 English, and its use in this context is defined in RFC 2119. If this = word was=20 not meant to be used, I think RFC 2119 would not define it.
 
Someone who implements this draft = will also=20 likely have implemented RFC 4253 (The Secure Shell (SSH) Transport Layer = Protocol), which uses SHALL in section 4.2.
 
I personally like this word. If a new = version of=20 the draft is needed for another reason, I can make this change,=20 though.
 
 
> These proposals are removed due = to current=20 lack of implementation",
> isn't that an = oxymoron?
 
I have seen implementation happen = when a=20 developer recognizes the need, and the RFC comes a few years later, if = at=20 all.
 
(For example, SFTP is in widespread = use, but due=20 to past implementer disagreement about whether there should be a version = after=20 3, we have no RFC for SFTP. The SFTP drafts serve as the de facto=20 spec.)
 
My understanding, also, is that IETF = expects=20 implementations to exist in order to bless an RFC =E2=80=93 at least two = independent=20 implementations ideally, or at least one minimum. Perhaps I=E2=80=99m = mistaken on=20 this?
 
 
> I'm certainly ready to go with=20 "no-flow-control", but haven't
> enabled it because I don't know = what'll=20 change, or break,
> before the spec is=20 finalised.
That=E2=80=99s why I asked before if = there=E2=80=99s actual=20 interest in this extension. :-) I didn=E2=80=99t receive feedback, so = after waiting a=20 few months, I thought it would reduce the burden on the working group if = I=20 removed it.
 
At this point, I can:
 
- put it back in, just like it was;=20 or
 
- make it an independent = submission.
 
Given the cryptographic orientation = of this=20 group, and the flow-control oriented nature of this extension, perhaps = an=20 independent draft would be better? I=E2=80=99m doing something similar = for=20 =E2=80=9Cext-auth-info=E2=80=9D here:
 
 
The only problem with an independent = submission,=20 if I make it, is that I have no idea how to shepherd it to RFC. That = doesn=E2=80=99t=20 stop me from writing drafts, though, because experience with SFTP shows = a draft=20 is still better than nothing. :)
 
denis
 
 
 
Sent: Saturday, March 18, 2017 03:01
To: Daniel Migault ; curdle =
Subject: Re: [Curdle] Multiple WGLC
 
Daniel=20 Migault <daniel.migault@ericsson.com> writes:

>This = emails=20 starts a WGLC on the following drafts:
>
>    = -=20 draft-ietf-curdle-rsa-sha2-03 [1]
>    -=20 draft-ietf-curdle-ssh-ext-info-02 [2]
>    -=20 draft-ietf-curdle-ssh-kex-sha2-05 [3]
>    -=20 draft-ietf-curdle-ssh-modp-dh-sha2-02 [4]
>
>Please provide = your=20 comments by March 28 on the mailing list.=20

draft-ietf-curdle-ssh-modp-dh-sha2-02:

Section 5, "Many = users=20 seem to be interested in the perceived safety of using
larger MODP = groups and=20 hashing with SHA2-based algorithms", should that text
be there?  = It=20 seems rather out of place, orphaned between Figure 2 and = the
References=20 section.

draft-ietf-curdle-ssh-ext-info-02.txt:

Section = 2.3, "This=20 message is sent without delay", I'm not really sure what to
do with = this=20 requirement, why would there be a delay, necessitating a need to
say = that=20 it's sent without delay?

Section 2.3: "and immediately after=20 SSH_MSG_NEWKEYS", whose NEWKEYs?  Logic
would seem to indicate = that it's=20 after both sending and receiving NEWKEYs to
confirm that the = connection is=20 secured, but the text is ambiguous.

Section 2.4: "If the client = sent=20 "ext-info-c", the server MAY send, but is not
obligated to send, an=20 SSH_MSG_EXT_INFO message immediately before
SSH_MSG_USERAUTH_SUCCESS, = as=20 defined in [RFC4252]", I've already commented on
this before, this = just seems=20 weird, the client sends its
SSH_MSG_USERAUTH_REQUEST and instead of = getting=20 back SSH_MSG_USERAUTH_SUCCESS
or SSH_MSG_USERAUTH_FAILURE it gets = this odd=20 out-of-place extension message
packed in front of the success/failure = indication that it's actually
interested in.

Section 3.1, "a = client=20 SHALL NOT", given that the rest of the document uses
MUST or SHOULD = it'd be=20 better to use that form as well here to save people
having to look up = whether=20 MUST or SHOULD is intended.

Section 3.2, "Former versions of this = document defined extensions with names
enumerated in this heading. = These=20 proposals are removed due to current lack of
implementation", isn't = that an=20 oxymoron?  If it's not in a published RFC,
people will be = reluctant to=20 implement it, or enable it if it's implemented.
I'm certainly ready = to go=20 with "no-flow-control", but haven't enabled it
because I don't know = what'll=20 change, or break, before the spec is=20 finalised.

Peter.

_________________________________________= ______
Curdle=20 mailing=20 list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle
------=_NextPart_000_00E2_01D29FB9.9055BD70-- From nobody Sat Mar 18 07:08:36 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 5899B12708C for ; Sat, 18 Mar 2017 07:08:35 -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=denisbider.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 3KlYjd1e3Wap for ; Sat, 18 Mar 2017 07:08:32 -0700 (PDT) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21CB012751F for ; Sat, 18 Mar 2017 07:08:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=denisbider.com; s=mail; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to: references; bh=M46ozhVgd03tqNB42UTiNhe+rsiAChqw3vcla1lYJh8=; b=XBMU1sM772cNRww7+sXiLXM4zZw9F1wm9W66SulygDwepTX3SgrFTMG5Sz3ly9xvvz2etbvujeHNl rHg/UCyFTkyAEE0O6fHplnrjh28aASXCt29yYFmebqjhAhSw7dh7GnymAO4DYB2xwZ/QBlgXsNHuzF 5YpMFZ5rosTD3SoLBeuzZ/gDOLz9tfOXw8spixHoY+rTqurD5VL0Vt8cGIxyKytMuXNY1MMKfQXGB4 iM4ZJlk89SVC33DnXhhXh7HFZhDf/1I5QKhcUx/bE0070Dl5Wy1XQD7foMwA+8k5lI/pvaF2/CBU3l VzQvxdmHBQ24fLwIN6PRgudUwZdHbgQ== X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)); Sat, 18 Mar 2017 14:08:19 +0000 Message-ID: <9EABA431E21041239B7D2B164FAA5AC3@Khan> From: "denis bider \(Bitvise\)" To: =?UTF-8?B?0KDRg9C80LXQvSDQn9C10YLRgNC+0LI=?= , References: <148823325745.13859.1818801191554779419.idtracker@ietfa.amsl.com> <58CCEF4F.7000902@roumenpetrov.info> In-Reply-To: <58CCEF4F.7000902@roumenpetrov.info> Date: Sat, 18 Mar 2017 08:08:26 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0147_01D29FBE.D24C8B00" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [Curdle] Comments on draft-ietf-curdle-rsa-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: Sat, 18 Mar 2017 14:08:35 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0147_01D29FBE.D24C8B00 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Reply to Roumen Petrov=E2=80=99s comments on draft-ietf-curdle-rsa-sha2: > > draft-ietf-curdle-ssh-ext-info-02.txt > > It seems to me published version is 3 -=20 > https://tools.ietf.org/html/draft-ietf-curdle-rsa-sha2-03 These are related, but separate drafts. The EXT_INFO draft is right now = at version 2. The rsa-sha2 draft is at version 3. > About chapter: > (*) 2 . "Public Key Algorithms": > This chapter is mainly for algorithms not signatures: > ... The following new s/signature/public key/ algorithms ... The main idea of this draft is to specify use of existing RSA keys = deployed in SSH with SHA-2 signatures, without having to replace the RSA = keys with new ones just to get better signatures. If we specified a new "public key algorithm=E2=80=9D as this term is = currently defined, this would imply a new key format, which would change = encoded key fingerprints, which would break trust between existing = deployed clients and servers. This would guarantee that take-up of SHA-2 = signatures takes a decade. This draft therefore does not define a new "public key algorithm", but = instead defines a new "signature algorithm" as a separate concept. This = is so an existing RSA key can stay an "ssh-rsa" key, but we now have = signature algorithms "ssh-rsa", "rsa-sha2-256", and "rsa-sha2-512". Before this draft, SSH uses the following terminology: - "public key algorithm" means the algorithm used to generate the key; = as well as the format used to encode the key; as well as the algorithm = used to perform the signature. The draft as-is decouples this term as follows: - "public key algorithm" means the algorithm used to generate the key; = as well as the format used to encode the key. - "signature algorithm" means the algorithm used to perform the = signature. Compared to before the draft, the draft reduces the term "public key = algorithm" to 2/3 of its current meaning, and carves out a new term = "signature algorithm" for the remaining 1/3 of the meaning. The existing = IANA table =E2=80=9CPublic Key Algorithm Names=E2=80=9D is kept the = same, and a new table is added. It appears to me what you are proposing is the following: - "public key format" to mean the algorithm used to generate the key; as = well as the format used to encode the key. - "public key algorithm" to mean the algorithm used to perform the = signature. Compared to before the draft, this suggestion would reduce the term = "public key algorithm" to 1/3 of its current meaning, and assign a new = term "public key format" for the remaining 2/3 of the meaning. The = existing IANA table =E2=80=9CPublic Key Algorithm Names=E2=80=9D would = have to be renamed to =E2=80=9CPublic Key Format Names=E2=80=9D, and a = new table named =E2=80=9CPublic Key Algorithm Names=E2=80=9D would have = to be added. I think this would be slightly more confusing than what the draft = currently does. denis From: =D0=A0=D1=83=D0=BC=D0=B5=D0=BD = =D0=9F=D0=B5=D1=82=D1=80=D0=BE=D0=B2=20 Sent: Saturday, March 18, 2017 02:26 To: curdle@ietf.org=20 Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-ssh-ext-info-02.txt 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 : Extension Negotiation in Secure Shell (SSH) > Author : Denis Bider > Filename : draft-ietf-curdle-ssh-ext-info-02.txt > Pages : 8 > Date : 2017-02-27 It seems to me published version is 3 -=20 https://tools.ietf.org/html/draft-ietf-curdle-rsa-sha2-03 . > Abstract: > This memo defines a mechanism for SSH clients and servers to = exchange > information about supported protocol extensions confidentially = after > completed key exchange. Following notation s/old/new/ is used to describe proposed text=20 substitution. About chapter: (*) 2 . "Public Key Algorithms": This chapter is mainly for algorithms not signatures: ... The following new s/signature/public key/ algorithms are defined: = ... ... These s/signature //algorithms are suitable for use both in the SSH=20 transport .... (*) 2.1. Use for server authentication What about ... server sends an s/"ssh-rsa" public key/RSA public key in "ssh-rsa"=20 format/ as part of the negotiated key exchange method ... ? (*) 2.2. Use for client authentication ...The "public key blob" field encodes the RSA public key using the=20 "ssh-rsa" s/algorithm name/format/... Regards, Roumen Petrov _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle ------=_NextPart_000_0147_01D29FBE.D24C8B00 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Reply to Roumen Petrov=E2=80=99s = comments on=20 draft-ietf-curdle-rsa-sha2:
 
 
>  >=20 draft-ietf-curdle-ssh-ext-info-02.txt
>
> It seems to me published version = is 3 -=20
> https://tools.ietf.org/html/draft-ietf-curdle-rsa-sha2-03<= /FONT>
 
These are related, but separate = drafts. The=20 EXT_INFO draft is right now at version 2. The rsa-sha2 draft is at = version=20 3.
 
 
> About chapter:
> (*) 2 . "Public Key=20 Algorithms":
> This chapter is mainly for = algorithms not=20 signatures:
> ... The following new = s/signature/public=20 key/ algorithms ...
 
The main idea of this draft is to = specify use of=20 existing RSA keys deployed in SSH with SHA-2 signatures, without having = to=20 replace the RSA keys with new ones just to get better = signatures.
 
If we specified a new "public key = algorithm=E2=80=9D as=20 this term is currently defined, this would imply a new key format, which = would=20 change encoded key fingerprints, which would break trust between = existing=20 deployed clients and servers. This would guarantee that take-up of SHA-2 = signatures takes a decade.
 
This draft therefore does not define = a new=20 "public key algorithm", but instead defines a new "signature algorithm" = as a=20 separate concept. This is so an existing RSA key can stay an "ssh-rsa" = key, but=20 we now have signature algorithms "ssh-rsa", "rsa-sha2-256", and=20 "rsa-sha2-512".
 
Before this draft, SSH uses the = following=20 terminology:
 
- "public key algorithm" means the = algorithm used=20 to generate the key; as well as the format used to encode the key; as = well as=20 the algorithm used to perform the signature.
 
The draft as-is decouples this term = as=20 follows:
 
- "public key algorithm" means the = algorithm used=20 to generate the key; as well as the format used to encode the = key.
 
- "signature algorithm" means the = algorithm used=20 to perform the signature.
 
Compared to before the draft, the = draft reduces=20 the term "public key algorithm" to 2/3 of its current meaning, and = carves out a=20 new term "signature algorithm" for the remaining 1/3 of the meaning. The = existing IANA table =E2=80=9CPublic Key Algorithm Names=E2=80=9D is kept = the same, and a new=20 table is added.
 
It appears to me what you are = proposing is the=20 following:
 
- "public key format" to mean the = algorithm used=20 to generate the key; as well as the format used to encode the = key.
 
- "public key algorithm" to mean the = algorithm=20 used to perform the signature.
 
Compared to before the draft, this = suggestion=20 would reduce the term "public key algorithm" to 1/3 of its current = meaning, and=20 assign a new term "public key format" for the remaining 2/3 of the = meaning. The=20 existing IANA table =E2=80=9CPublic Key Algorithm Names=E2=80=9D would = have to be renamed to=20 =E2=80=9CPublic Key Format Names=E2=80=9D, and a new table named = =E2=80=9CPublic Key Algorithm Names=E2=80=9D=20 would have to be added.
 
I think this would be slightly more = confusing=20 than what the draft currently does.
 
 
denis
 
 
 
Sent: Saturday, March 18, 2017 02:26
Subject: Re: [Curdle] I-D Action:=20 draft-ietf-curdle-ssh-ext-info-02.txt
 
internet-drafts@ietf.org=20 wrote:
> A New Internet-Draft is available from the on-line=20 Internet-Drafts directories.
> This draft is a work item of the = CURves,=20 Deprecating and a Little more Encryption of the=20 IETF.
>
>        &nbs= p;=20 Title           : = Extension=20 Negotiation in Secure Shell=20 (SSH)
>         =20 Author          : Denis=20 Bider
> Filename        :=20 draft-ietf-curdle-ssh-ext-info-02.txt
>=20 Pages           : = 8
>=20 Date            : = 2017-02-27
It seems to me published version is 3 -=20
https://tools.ietf.org/html/draft-ietf-curdle-rsa-sha2-03 = .

>=20 Abstract:
>    This memo defines a mechanism for = SSH=20 clients and servers to exchange
>    information = about=20 supported protocol extensions confidentially = after
>   =20 completed key exchange.

Following notation s/old/new/ is used to = describe=20 proposed text
substitution.

About chapter:
(*) 2 . "Public = Key=20 Algorithms":
This chapter is mainly for algorithms not = signatures:
... The=20 following new s/signature/public key/ algorithms are defined: ...
... = These=20 s/signature //algorithms are suitable for use both in the SSH =
transport=20 ....


(*) 2.1. Use for server authentication
What = about
...=20 server sends an s/"ssh-rsa" public key/RSA public key in "ssh-rsa" =
format/=20 as part of the negotiated key exchange method ... ?


(*) = 2.2. =20 Use for client authentication
...The "public key blob" field encodes = the RSA=20 public key using the
"ssh-rsa" s/algorithm=20 name/format/...


Regards,
Roumen=20 Petrov

_______________________________________________
Curdle = mailing=20 list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle
------=_NextPart_000_0147_01D29FBE.D24C8B00-- From nobody Sat Mar 18 07:29: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 70EA11277BB for ; Sat, 18 Mar 2017 07:29:56 -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=denisbider.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 qhc-iResEdDs for ; Sat, 18 Mar 2017 07:29:54 -0700 (PDT) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFE93127A90 for ; Sat, 18 Mar 2017 07:29:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=denisbider.com; s=mail; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to: references; bh=RGHVbfb9GGNKfMRPbRGLdwNwGTfLsp2XIIZr0JZ1sx0=; b=WnZ99rR2xp0OscxHnpkLTyP9wgNhPCkOjGCtyNIxDt/eLyEtwFrM0t6S68y8fCwneWOSjtjQapPbv ABEbRJjCLANb3Gpp29tprji7dU0tM9h+BGx6/keAPqztbeQHdXPKhtYFgjVS6VsCqn4ljC7vGwls/+ y5g/5nxF46+q1EHU7qbDMia1nZAqO+5H/1Js1Wq143qCrjblxtqeUXa7loMyqRUzVYxUHK/SJPR9jw vb2gxJtNchKgCX7RA5ToiCYRpCGKN6Y8VwEKvRbSLCh2qs3NdjIRDGVKnqQGtT5yHwh/WDlgbE74k6 pXZkVSFJHfPaGnXSfgh2uOF+uFd09LA== X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)); Sat, 18 Mar 2017 14:29:40 +0000 Message-ID: <5043598F57854074965C3CFB2DA96481@Khan> From: "denis bider \(Bitvise\)" To: =?UTF-8?B?0KDRg9C80LXQvSDQn9C10YLRgNC+0LI=?= , References: <148823325745.13859.1818801191554779419.idtracker@ietfa.amsl.com> <58CCEF4F.7000902@roumenpetrov.info> <58CD33BA.4030102@roumenpetrov.info> In-Reply-To: <58CD33BA.4030102@roumenpetrov.info> Date: Sat, 18 Mar 2017 08:29:47 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0185_01D29FC1.CDC4FFB0" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-ssh-ext-info-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: Sat, 18 Mar 2017 14:29:56 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0185_01D29FC1.CDC4FFB0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Roumen: > I think that correct option must use "public key" instead "signature" > in its name and chapter to mention only algorithms. I believe the opposite, as explained in my previous reply. > Its not clear how to list "publickey" algorithms. name-list is > - list of strings, each string is name of public key algorithm > - space separated list of public key algorithm names > - comma separated list of public key algorithm names The term "name-list" is defined in RFC 4251: https://tools.ietf.org/html/rfc4251 Although this RFC is not listed as a direct normative reference for this = draft, the term "name-list" is used in both RFC 4252, and RFC 4253, = which are listed as normative references. > (*) 3.2. "no-flow-control", "accept-channels", "elevation" > It seems to me those elements are subject of future extension. > If necessary they could be described in new draft. Yes. Previous versions of this draft contained definitions for those = extensions. These were published for over a year before they were = removed. Since drafts are public, and existence of implementations = cannot be excluded, it would be irresponsible to not mention that these = names, in particular, already have meanings - even if this draft has = dropped pursuing those extensions at this time. denis From: =D0=A0=D1=83=D0=BC=D0=B5=D0=BD = =D0=9F=D0=B5=D1=82=D1=80=D0=BE=D0=B2=20 Sent: Saturday, March 18, 2017 07:18 To: curdle@ietf.org=20 Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-ssh-ext-info-02.txt Hello Sorry for confusion in my previous feedback, quote below I chose wrong=20 subject. About About (*) 3.1. "server-sig-algs" from draft-ietf-curdle-ssh-ext-info-02.txt I'm not sure why whole chapter use signature(?) algorithm . Draft draft-ietf-curdle-rsa-sha2-03 describes new public key algorithm. In rfc4252 and rfc4253 is used public key algorithm. I think that correct option must use "public key" instead "signature" in = its name and chapter to mention only algorithms. About name-list s/signature/publickey/-algorithms-accepted Its not clear how to list "publickey" algorithms. name-list is - list of strings, each string is name of public key algorithm - space separated list of public key algorithm names - comma separated list of public key algorithm names (*) 3.2. "no-flow-control", "accept-channels", "elevation" It seems to me those elements are subject of future extension. If necessary they could be described in new draft. Regards, Roumen Petrov P.S. previous feedback: =D0=A0=D1=83=D0=BC=D0=B5=D0=BD =D0=9F=D0=B5=D1=82=D1=80=D0=BE=D0=B2 = wrote: > [SNIP] > Following notation s/old/new/ is used to describe proposed text=20 > substitution. > > About chapter: > (*) 2 . "Public Key Algorithms": > This chapter is mainly for algorithms not signatures: > ... The following new s/signature/public key/ algorithms are defined: = ... > ... These s/signature //algorithms are suitable for use both in the=20 > SSH transport .... > > > (*) 2.1. Use for server authentication > What about > ... server sends an s/"ssh-rsa" public key/RSA public key in "ssh-rsa" = > format/ as part of the negotiated key exchange method ... ? > > > (*) 2.2. Use for client authentication > ...The "public key blob" field encodes the RSA public key using the=20 > "ssh-rsa" s/algorithm name/format/... > > > Regards, > Roumen Petrov _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle ------=_NextPart_000_0185_01D29FC1.CDC4FFB0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Roumen:
 
 
> I think that correct option must = use "public=20 key" instead "signature"
> in its name and chapter to = mention only=20 algorithms.
 
I believe the opposite, as explained = in my=20 previous reply.
 
 
> Its not clear how to list = "publickey"=20 algorithms. name-list is
> - list of strings, each string = is name of=20 public key algorithm
> - space separated list of public = key=20 algorithm names
> - comma separated list of public = key=20 algorithm names
 
The term "name-list" is defined in = RFC=20 4251:
 
 
Although this RFC is not listed as a = direct=20 normative reference for this draft, the term "name-list" is used in both = RFC=20 4252, and RFC 4253, which are listed as normative = references.
 
 
> (*) 3.2.  = "no-flow-control",=20 "accept-channels", "elevation"
> It seems to me those = elements  are=20 subject of future extension.
> If necessary they could be = described in new=20 draft.
 
Yes. Previous versions of this draft = contained=20 definitions for those extensions. These were published for over a year = before=20 they were removed. Since drafts are public, and existence of = implementations=20 cannot be excluded, it would be irresponsible to not mention that these = names,=20 in particular, already have meanings - even if this draft has dropped = pursuing=20 those extensions at this time.
 
denis
 
 
 
Sent: Saturday, March 18, 2017 07:18
Subject: Re: [Curdle] I-D Action:=20 draft-ietf-curdle-ssh-ext-info-02.txt
 
Hello

Sorry=20 for confusion in my previous feedback, quote below I chose wrong=20
subject.

About

About (*)
3.1. "server-sig-algs" = from=20 draft-ietf-curdle-ssh-ext-info-02.txt
I'm not sure why whole chapter = use=20 signature(?) algorithm .

Draft draft-ietf-curdle-rsa-sha2-03 = describes=20 new public key algorithm.
In rfc4252 and rfc4253 is used public key=20 algorithm.

I think that correct option must use "public key" = instead=20 "signature" in
its name and chapter to

mention only=20 algorithms.


About  name-list=20 s/signature/publickey/-algorithms-accepted

Its not clear how to = list=20 "publickey" algorithms. name-list is
- list of strings, each string = is name=20 of public key algorithm
- space separated list of public key = algorithm=20 names
- comma separated list of public key algorithm = names


(*)=20 3.2.  "no-flow-control", "accept-channels", "elevation"
It seems = to me=20 those elements  are subject of future extension.
If necessary = they could=20 be described in new draft.


Regards,
Roumen = Petrov


P.S.=20 previous feedback:

=D0=A0=D1=83=D0=BC=D0=B5=D0=BD = =D0=9F=D0=B5=D1=82=D1=80=D0=BE=D0=B2 wrote:
> [SNIP]
> = Following=20 notation s/old/new/ is used to describe proposed text
>=20 substitution.
>
> About chapter:
> (*) 2 . "Public Key = Algorithms":
> This chapter is mainly for algorithms not=20 signatures:
> ... The following new s/signature/public key/ = algorithms are=20 defined: ...
> ... These s/signature //algorithms are suitable for = use=20 both in the
> SSH transport ....
>
>
> (*) 2.1. = Use for=20 server authentication
> What about
> ... server sends an = s/"ssh-rsa"=20 public key/RSA public key in "ssh-rsa"
> format/ as part of the=20 negotiated key exchange method ... ?
>
>
> (*) = 2.2.  Use=20 for client authentication
> ...The "public key blob" field encodes = the RSA=20 public key using the
> "ssh-rsa" s/algorithm=20 name/format/...
>
>
> Regards,
> Roumen=20 Petrov

_______________________________________________
Curdle = mailing=20 list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle
------=_NextPart_000_0185_01D29FC1.CDC4FFB0-- From nobody Sat Mar 18 07:39: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 0EB40127A91 for ; Sat, 18 Mar 2017 07:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 xKN8VSmNYJui for ; Sat, 18 Mar 2017 07:39:49 -0700 (PDT) Received: from rila.superhosting.bg (rila.superhosting.bg [91.196.125.212]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD997127B73 for ; Sat, 18 Mar 2017 07:39:48 -0700 (PDT) Received: from [78.128.48.21] (port=36748 helo=[192.168.0.10]) by rila.superhosting.bg with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.87) (envelope-from ) id 1cpFWE-0047rT-7D for curdle@ietf.org; Sat, 18 Mar 2017 16:39:46 +0200 Message-ID: <58CD46B0.9010902@roumenpetrov.info> Date: Sat, 18 Mar 2017 16:39:44 +0200 From: =?UTF-8?B?0KDRg9C80LXQvSDQn9C10YLRgNC+0LI=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Firefox/33.0 SeaMonkey/2.30 MIME-Version: 1.0 To: curdle@ietf.org References: <148823325745.13859.1818801191554779419.idtracker@ietfa.amsl.com> <58CCEF4F.7000902@roumenpetrov.info> <9EABA431E21041239B7D2B164FAA5AC3@Khan> In-Reply-To: <9EABA431E21041239B7D2B164FAA5AC3@Khan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - rila.superhosting.bg X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - roumenpetrov.info X-Get-Message-Sender-Via: rila.superhosting.bg: authenticated_id: master78@roumenpetrov.info X-Authenticated-Sender: rila.superhosting.bg: master78@roumenpetrov.info X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [Curdle] Comments on draft-ietf-curdle-rsa-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: Sat, 18 Mar 2017 14:39:52 -0000 HI Denis, denis bider (Bitvise) wrote: [SNIP] > Before this draft, SSH uses the following terminology: > > - "public key algorithm" means the algorithm used to generate the key; as well as the format used to encode the key; as well as the algorithm used to perform the signature. No. Before this draft, RFC 6187 defines new public key algorithms with new format to encode the key and existing signature format, i.e. new/new/old. You proposition is new/old/new. I'm fine with your arguments to reuse public key blog, but I disagree that draft-ietf-curdle-rsa-sha2 does not define new algorithm. Quote from rfc4252: byte SSH_MSG_USERAUTH_REQUEST string user name string service name string "publickey" boolean TRUE string public key algorithm name <<<<----- string public key to be used for authentication string signature and from draft : byte SSH_MSG_USERAUTH_REQUEST string user name string service name string "publickey" boolean TRUE string "rsa-sha2-512" <<<<----- public string public key blob: string "ssh-rsa" mpint e mpint n string signature: string "rsa-sha2-512" string rsa_signature_blob If in draft your replace "rsa-sha2-512" with ssh-rsa I will agree that draft is only with signature algorithm, i.e. old/old/new. Draft sample shows new public key algorithm. I could guess that you start with only with new signatures but now I see more enhanced encoding of authentication request. [SNIP] Roumen From nobody Sat Mar 18 07: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 74B2312869B for ; Sat, 18 Mar 2017 07:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQ4h-4qMED4S for ; Sat, 18 Mar 2017 07:48:47 -0700 (PDT) Received: from rila.superhosting.bg (rila.superhosting.bg [91.196.125.212]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 179431277BB for ; Sat, 18 Mar 2017 07:48:47 -0700 (PDT) Received: from [78.128.48.21] (port=36754 helo=[192.168.0.10]) by rila.superhosting.bg with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.87) (envelope-from ) id 1cpFev-000fGQ-4V for curdle@ietf.org; Sat, 18 Mar 2017 16:48:45 +0200 Message-ID: <58CD48CC.2070208@roumenpetrov.info> Date: Sat, 18 Mar 2017 16:48:44 +0200 From: =?UTF-8?B?0KDRg9C80LXQvSDQn9C10YLRgNC+0LI=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Firefox/33.0 SeaMonkey/2.30 MIME-Version: 1.0 To: curdle@ietf.org References: <148823325745.13859.1818801191554779419.idtracker@ietfa.amsl.com> <58CCEF4F.7000902@roumenpetrov.info> <58CD33BA.4030102@roumenpetrov.info> <5043598F57854074965C3CFB2DA96481@Khan> In-Reply-To: <5043598F57854074965C3CFB2DA96481@Khan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - rila.superhosting.bg X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - roumenpetrov.info X-Get-Message-Sender-Via: rila.superhosting.bg: authenticated_id: master78@roumenpetrov.info X-Authenticated-Sender: rila.superhosting.bg: master78@roumenpetrov.info X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-ssh-ext-info-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: Sat, 18 Mar 2017 14:48:48 -0000 denis bider (Bitvise) wrote: > [SNIP]These were published for over a year before they were removed. > Since drafts are public, and existence of implementations cannot be > excluded, [SNIP] I don't know well process of RFC creation and may be there is written rule(requirement) like above. From my point of view draft or RFC should not describe experimental or not accepted information. Roumen From nobody Sat Mar 18 08:22:30 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 4143F128656 for ; Sat, 18 Mar 2017 08:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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, RP_MATCHES_RCVD=-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=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 2mAqmohanzwo for ; Sat, 18 Mar 2017 08:22:25 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 7889F126BF6 for ; Sat, 18 Mar 2017 08:22:25 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id D193C200025; Sat, 18 Mar 2017 15:22:24 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 9198820001E; Sat, 18 Mar 2017 15:22:24 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1489850544; bh=76AtbtiOzUKEVTd5ZA6F6Ak5XSMDOo87vqhqulrm/FE=; l=362; h=From:To:Date:References:In-Reply-To:From; b=LpD0U6FuV4bojfZ7BrwwJqhV0CXy5X65TSO1i4ce4w7zUc667UcF4g5rxFLFGqGBo JhRrXPMBJqRBucX1ukrd/zVUKD8jJ2zhTBvbL9gYyh65DE28zflMiGx54dnlPm9K+y Go77AEgxZRr7FKAVhXcyNip4nj12cZAiwCrteLDI= Received: from email.msg.corp.akamai.com (usma1ex-casadmn.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 785EC98082; Sat, 18 Mar 2017 15:22:24 +0000 (GMT) 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.1178.4; Sat, 18 Mar 2017 11:22:23 -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.1178.000; Sat, 18 Mar 2017 11:22:23 -0400 From: "Salz, Rich" To: =?koi8-r?B?8tXNxc4g8MXU0s/X?= , "curdle@ietf.org" Thread-Topic: [Curdle] I-D Action: draft-ietf-curdle-ssh-ext-info-02.txt Thread-Index: AQHSn8GhIophljFEMkSpImQp85o0lqGa1+gAgAAT0oCAAAVMAP//xhCw Date: Sat, 18 Mar 2017 15:22:22 +0000 Message-ID: <7dc391a30fd24adab4cfc1a7da687a4b@usma1ex-dag1mb1.msg.corp.akamai.com> References: <148823325745.13859.1818801191554779419.idtracker@ietfa.amsl.com> <58CCEF4F.7000902@roumenpetrov.info> <58CD33BA.4030102@roumenpetrov.info> <5043598F57854074965C3CFB2DA96481@Khan> <58CD48CC.2070208@roumenpetrov.info> In-Reply-To: <58CD48CC.2070208@roumenpetrov.info> 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.72] Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-ssh-ext-info-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: Sat, 18 Mar 2017 15:22:29 -0000 > I don't know well process of RFC creation and may be there is written > rule(requirement) like above. > From my point of view draft or RFC should not describe experimental or n= ot > accepted information. There are different "tracks" in RFC's, including experimental. This link m= ay help: https://www.ietf.org/iesg/informational-vs-experimental.html From nobody Sat Mar 18 11:24:46 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 22EA41293EB for ; Sat, 18 Mar 2017 11:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=junipernetworks.onmicrosoft.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 r3GB945D8qAx for ; Sat, 18 Mar 2017 11:24:42 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0091.outbound.protection.outlook.com [104.47.37.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA8031293E4 for ; Sat, 18 Mar 2017 11:24:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=a5Rkwy9TX/M9ir06gaqoJjLw8KOmNcDvho+vneMMntQ=; b=JhGSHMs+c81fCt7ycFONvoPmuWmAcxOXR8DO0vjH2hJlcVY29VgKXQE2gYhbVMqb9VPZubWuNRRCg79yy4w7/b8Ipa048BaRm6FfYMiHgrEsFTyMZBJc05MvzQBQwFohrbxaNiV8XURsJhbtKwxQk37ZBZxzFtS5tHDpXS86mu8= Received: from BN6PR05CA0013.namprd05.prod.outlook.com (10.174.92.154) by BN1PR05MB310.namprd05.prod.outlook.com (10.141.63.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Sat, 18 Mar 2017 18:24:39 +0000 Received: from BY2FFO11FD011.protection.gbl (2a01:111:f400:7c0c::101) by BN6PR05CA0013.outlook.office365.com (2603:10b6:405:39::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4 via Frontend Transport; Sat, 18 Mar 2017 18:24:39 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; cs.auckland.ac.nz; dkim=none (message not signed) header.d=none;cs.auckland.ac.nz; 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.18 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.18) by BY2FFO11FD011.mail.protection.outlook.com (10.1.14.129) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.977.7 via Frontend Transport; Sat, 18 Mar 2017 18:24:38 +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; Sat, 18 Mar 2017 11:24:38 -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 v2IIOaXo020833; Sat, 18 Mar 2017 11:24:37 -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 7C3C811454; Sat, 18 Mar 2017 11:24:36 -0700 (PDT) To: Peter Gutmann CC: Daniel Migault , curdle In-Reply-To: <1489827654266.43895@cs.auckland.ac.nz> References: <2DD56D786E600F45AC6BDE7DA4E8A8C118BA5A70@eusaamb107.ericsson.se> <1489827654266.43895@cs.auckland.ac.nz> Comments: In-reply-to: Peter Gutmann message dated "Sat, 18 Mar 2017 09:01:05 -0000." From: "Mark D. Baushke" MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Sat, 18 Mar 2017 11:24:36 -0700 Message-ID: <34726.1489861476@eng-mail01.juniper.net> Sender: X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.18; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39410400002)(39450400003)(39860400002)(2980300002)(199003)(189002)(9170700003)(2950100002)(50986999)(7696004)(53936002)(6916009)(55016002)(5660300001)(54906002)(54356999)(356003)(229853002)(76176999)(7846003)(6392003)(50466002)(86362001)(8746002)(81166006)(8676002)(4326008)(305945005)(8936002)(7126002)(77096006)(117636001)(53416004)(2810700001)(2906002)(76506005)(105596002)(106466001)(6246003)(110136004)(38730400002)(6266002)(47776003)(23676002)(189998001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB310; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD011; 1:mZBZrVPbLKEXfqPJvgkaslNc/Xs6w70zUawZlwNXf30TjvXwmWH3SQLIW7aVi/MGJizXNJrMXLBIE1Tq8P5IaZIzkydTARjlfsyo+AAn9YL/m2FHISDpWBw0b6d83JtdX+vPd0RRmflSCNQHhcP+MSmBg4IUGLp/sy9ZmHKwhDooepjO+gFxY/RuYY5KqFOvvXiAGycjjDSeGNgFbROHNzuSihYB5OYLquh5uExN3WIfMxcRTSr1q32yrdFRmJsiqueGnqh9t4eGsu6vlUXXDbaG1+4t0vyqwIncIT/h8Gx3kf6CgqQx6d4TWeLGzuYB5sDVizUN8fKOxT9iIDi19oVd7zBYIjgHm324yXtPlUwLquiTDWISKeE1tBWiEr3KiccCTb8Y/ppNz1YlRfdO6jWXUtBuJbPVaLPv7uYUVQ+cuhMHCKWOmHUMyebJFiy3kHLwd/ls1Pn/yrXB7pkWC+r27l6q0F9rUe2khrgSsVPCYuKcxUxtcDQYBm/5RID6DX2OK/OlVYHcBWVzDjPkPhIaF3S7FK4vlPbcPjhfdSLq6vg/ipxeW6CdLACiAoIa X-MS-Office365-Filtering-Correlation-Id: 585fd6ce-34b1-416d-03ed-08d46e2c09fc X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254067); SRVR:BN1PR05MB310; X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB310; 3:SeuN8W6qaU5ph9UjO00NEsT4olVCcs03h+hwsFG47GSeSlYeZYcXjIWtsL45usqcsK3yuBn0TTL9c01Wnqemh5WEBdTkQi4/2A/tWs+4V3qpOK850tjtsVD8ZSkQZU+dguo4iKTJWvlrWW2lKYtc/oKwjPssH6IQJ6xuA46atPZnN0pUkenM13wzArJ/PQrFYHnoLATlUjRJiNWgAiAYCUDXPm+6mGyP6jdc2umjBmnFi8q5YKAK0DuM/wqX589edNxXVyZqG+oi8uftGOqZ/xBDBLxUhCr3KLPkebj6tCRzMFFm7xGlXXboSaqcvL/Y5THZ2Y03LXpmo26r9ATNU691MFpwgZ/YbfrD4UUwQf4PGpa8HgeR0dWEphBLzF34FfTQrMNQR7om8O58dviSjA==; 25:2qZm1WI4iwmbLDzUoADTG3klhzydMCLMPGSilJwNoGa2BabEpuVy46RZx06yl6fdSEka4OXkFOasxBJlnqDGb1qdGQGJjyCfvsfV7/fWcO2LGk0IP2g5aikFnTOfZJCK66YKMAECKyQkCx1ah2nAcG5CB03G9VnpiyOj/M+s2SXXY4g9rdqbF+UugydrSF42VPBHJbWy6h+E8alQISvV0RZHzax7rf7X7hPBHzdydT4moNVCsIPBUZFdT6sGC6CmhSLww3g/1X2ilGJS1y3l7iiI+3K0LqkHw7TB2AW/ADGzuDhzH+wEziQepaILkUSNfjnF1p4DqIEsRI2tQxAIgQST5qsvMvpA/8qzruhi7RhVte283vb8/TdCUI41OHcJojU7IlWPbrrUzdxTUARWuxO0qhmV9JlrY7XNFzkK8DOOXBEtLsLsNAzOTHQHOtVmEHTcYUs6VHr8Jj6caJuZmw== X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB310; 31:68HD9g9YhjHI7aQhFTT4eosT72aBnGwx7xs++gIS3wLshalCcMhB8y0yx7GAgy5KgG5dnzlfkVbs0cKf6L6izUVe19MKLQRmW9KOD8YrQpwoN54GqT8KQXJF0DnkPUXV3rBYzRr6tdJMIuFcMl7XLVqCQmZx/tVSJasXphtYKaF+HcU7n0sXMYQw53gbJ7RiBEP/F1LUJzi0MPkIxiTyHM2S5fg64DwRBkXjSAsy/nRtUu0vpClKKgW+EX5SI8RB; 20:ognziNCoFrFOx9v7Z0UR2kPlNFu1UQ5K8N9xp4LHEYvqRly13kHCYjBnKVY1GkLxfK9NlV3F1uAMzmUCtCU/b8pX0jzcJcFw4+Jb6Ui656xP/SE6ZOuuHU7kRlwMNwf/YxNf+f0NByULDiFfkzZ15kSZLF72VqxmVlhGu9GfH0nMvZ9Yt7DWZrQ7jLGoFf0K+5gOnwkJ6O8nof3Yyuc+RXSZ7TfZXHdz/xhsE91Rx5+hkH5keqJQkbUibqD5DFR8FnY9EkrYlzE0FPUKxin2ClJz/P43ET4i+swZ745AsMAGkeuIwfEZYlqK+4w7ykTX4F/GBDijL1BYsTOp2+95qpu6kERfTdeSXQ5B8uAIabm3PY+MVU/BTHqfu4Q2J9ukNBsHgJ1CEQiH8sh/4Gq4sHndOcLc3ayF+9Z9Su0d8j0giukYCTZ7QOroGEUveIylp8E0Au4cS/fEmWQWEi5wt9RBcIWgEJZGd07PeooPT/x/+5iwPSvwxELduMvvV1cc X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(37575265505322); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(13017025)(13018025)(13023025)(13015025)(13024025)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123560025)(20161123558025)(20161123564025)(20161123562025)(6072148); SRVR:BN1PR05MB310; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB310; X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB310; 4:jn7bLx5/86ptJXo7g5v2mTb66HYqrxqEnrF0RwR4noyP84XroqASZ37Rr1G/OFeoMghLxdSOl7W1MJUjE0q8hMVaG+qa0BrtGoXI34s1oDg4NGhbVwdMwahfmxGfp4WTJnxUbSc8GSq3HfA5EUDTquA34QjoTePRss5hb7aeAAUYnwgq3NTXk0DbdsWlhGg7e9t5Pi2Ia6ukawvOGMbxW48A+U3wT5rHR0yIxaXT9t0Nj0Cqw3t3iFfNnDY0BW83SOYwIhmNp8W01nf0Nnn8NCBDN9z/LJxU+sDmJRrvO228rCKGr+NGmxeymZ80Td8ELOXG4HLXsiXL6EmpsXPIxitKOLMtgaGl0TTRWoaTlYav/S3guRIX+uQiO56T5V51z36eAsOQEmMfJe5/PWT9GmfoxCNDvZm4SZB9GUu5ReIam5iraEPyZ7SnXChtTBK41GLzA29ScLGe/FPzYRNFVGb77rHaovaynXoMIoGd8HATC4YxLw1NLR3u+72zCre13BX4bqIVdsmaHBl3zovH352cx50fDTdbWiFtzEjC3alJLZV8Dd0HF1/7QNdfsC2txoy+p07qM5XPdbxmxyY3VA08NA19SC+YqnaZWjrIcLWLLmRRfNjgVWBw0RLNKInVx3xjG4T4zczxwQLfQ6FhtKO6tiMo5hfa9g1XzWXaelRfXEvdt3sjcgeWPyWB9CtWf2lH8jsp2XDwv95cbn26NHku3/XwEUzb8De3P/oUT78pbnIR7kweU5CBWnqJ2IWe X-Forefront-PRVS: 0250B840C1 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTjFQUjA1TUIzMTA7MjM6YVZvU21MNlBjN1lCV1FGVmxUNXNhVXRLMVBu?= =?utf-8?B?Z3BrQTQ4aHlsVkh6UWpodC9ZZmdEcGZTdnJqaGgwRmk0Wk5Gb2ZZeXB4bHRM?= =?utf-8?B?YnhUN2IvQ2lQeldrcm9oeXRoT2k0b2tZSTZYVy9DZHhjVHBaZWYrU2tqV0xD?= =?utf-8?B?Y2ZtNmI4SnczQW0rQ1FmNDUxWm9XbFFQZm9xakxmbnpoSzlLOGtDWWljSUJI?= =?utf-8?B?N0tEZUtGUVhQZjJJYitiMFFqci9TUHg4WVp6S2Fra0xZNWdpdjk3RkE5aDRj?= =?utf-8?B?QzdURkYyYnpoZGoxYllnaW55MFUvbkF5NnRwZXRVaDhLY3dudm0vTWtuZWtZ?= =?utf-8?B?TUFBQkJRS2lGekFZM0xjSmNCZmVBcDBwWnB5cUFYcGV0a0NnN1pGek9PZ0U3?= =?utf-8?B?UFdYMnkySWFQK1lkZFlPcUk0SysvUXRWWVpnM1lVeTJON21aTEl3a0ZqVEV3?= =?utf-8?B?YW95a0hwZDAvTlN5bkhaVzFvc0RraXI1dGpFU1MzS28vcHlIeWJlWGU5Q3RE?= =?utf-8?B?cVBidkZOSXVqb0pXenlIbnQ2cjVKcFJkOFF6Z0p6YzZkZ005emtvVXBvd0s0?= =?utf-8?B?S2lqVEtuczN0OHRSSVR1cE1OZjQvS0lsMXZsaFh2R1lBL3pLNEV3S2QycDJE?= =?utf-8?B?WmlWSjZyUCt5Qm5SZFdPM0F0NzFrV1l4S2xnOHlTSmJhNjVFK2F3bkhPbFRz?= =?utf-8?B?ekRJWGlrQ211QjJ4TGJYdkRtRWlXRDdxS2RPNTFSU05NYTdyT2NrQzNFaTJu?= =?utf-8?B?UTh2MjhxUUJoYjhKWjVPM3JtMW84UlhvRDV4RjBybUZ0enBHdHM1OWxkT2or?= =?utf-8?B?MWJPcllEeEdvQ3hobEI4eXdaSmpNMjVFTFJQKzV5QjQ2UE54ZnNZanpvS1kr?= =?utf-8?B?dG1HaWhhZVhERHlHZXFhZVZtR1lBSjAvbThFNDNyRldxYnFRKzhESTBmdnIv?= =?utf-8?B?NkV5TnpOTDl0RkRCMkdNRFQvTUtXU1NjcHZ1ck1OUkYvb3lNR0JaTnRIZWFW?= =?utf-8?B?ZVB4QmxXeENjb0FvQjZIdk92T3ZCMzM3aHRYTEFDcDgreDVoQkhUekhKWHRR?= =?utf-8?B?d1JoZmN0cmRRSEdubFE1aW5BQnJTdTRxak1ON3h4R2d1VGVxOHhSQWk1WGZo?= =?utf-8?B?ckE0akhuSU1UUWMwV1c0bHhXdkJLdXpIWmcySndPc21DbzVQRjREeit0SGZJ?= =?utf-8?B?R3NFdTlrZkxMRk9SeU1LMFpDZmtmNExkZjV4a2VkMEZzOWFBWmFuOTYxR2s3?= =?utf-8?B?WjVEUHg1Y25pRk5wSlh3T0RIQVBJWjJaYlI0N0cwQ1ZvWFRaTkxNRmsxb0ZZ?= =?utf-8?B?alhnVk9SK05KR0xSd3JFNTdCbXZaUXRHV2NORXJMNGF1K0lCM2txZ2lsRENa?= =?utf-8?B?eExIcFJXNFFja2RwRk9ING14T0tFMlZJOXczT05HeUNhUWVMVWplemtRNE5Z?= =?utf-8?B?VmdFajBualp5MGFuVzVFYTlvNW9ySElpcCtxaUR2SWx6L09ieVVCZGc4cFQ4?= =?utf-8?B?d25SMWdiNUlyUUh6U2dDLzg1UWVHb3N3OWJTQjhhdnh6bDFPb3M0bGJQOElu?= =?utf-8?B?cHZqaWFaRnZqekpDanlZUjFFUnNCdz09?= X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB310; 6:S801CByt2aHF0mzNoW/MSi6k3KtgthhM0xS3u6YolWgAAamcoBmF/9VwLNxVfLWx0zSIGUu7HNzxS+bqdGBWH46KgnV/bJ3buJ7bBJHQ0SDmrXQZWaTBHJBamn82srfxlJpGPBDhky5B+MW54yF6QcrSB1YOO6pXaAJxJb76mqsneeF8ccTeJo1Ql9BwKTlVg5aWou03tI1RAjKzVdW284f6JgCN4oZteFQTKBAlpKKYeU6828jh3aGDX2atESRBlL8YwklE6wUslz0LQ6rauuCve8faSqFq2YfV8dOpGCjM9PVsCT3fsKmME0FhAoAnyP8YkR90JeInwBkVdqudKcDcxWxt2agyBGjsGyw/UEpI1f50GpqfPEV+rEx8uofAgBq99WwA9TcsXigTw3wC3R4oXboW+LSPv7YAoJxExYQ=; 5:Kx1M7yevJm4/cQYRMqr9oklRhPNyTIHSmhoX0eYIDrYWY+/1UqSZjqGngZkj+4+/xXDaFWDtIUDQl2/AunJNgD17JB9PwY9YSOx32vT4Qf6icvlO5Dn/NfYL7NmJbfUImEIjnpAM9NBgugQO/5AIaw==; 24:qNymWhUPRQiWd2kCZLWf9AS5fm54TP9g9G+vREEFm8Q1fqQkcYGw71Vda+9VfAzj23nbg9UxHsIT2qhbU9cnA9zGCB8UZuBs6R5kvodSJ5g= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB310; 7:ZEca9c7iuqnQETdIAVflXjPbtubiuRZx3ryxxdOVRh1n75ThmXlC0aGkuQDYeWfT33goeH7lhUVsvnk704N7s+sP4ms9NJB9dO5SzNBWTkXgIwShQFhEGSO1DmpwZes8hF09gif+u7XZGW5z2IOXX3NDeJquP+Lci0K/2o9/nX2/SNco7CPB35oQl9Ae0G6sBTltYCYG0Z8+FFQqLSd/nhIE8AS5kkUTjSqWKKNfoO2Flggp4S5FsOKp6/wKVeBHzmD5m96MbH72znTq9AWsACLsAcr4r70y/htRkf2r2Bon2Cy467L6IZgCCZ6gCpwIDA1FjYTUvqqJYMQaipJeAw== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Mar 2017 18:24:38.8869 (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.18]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB310 Archived-At: Subject: Re: [Curdle] Multiple WGLC 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, 18 Mar 2017 18:24:44 -0000 Peter Gutmann writes: > Daniel Migault writes: >=20 > >This emails starts a WGLC on the following drafts: > > > >=C2=A0 =C2=A0 - draft-ietf-curdle-rsa-sha2-03 [1] > >=C2=A0=C2=A0=C2=A0 - draft-ietf-curdle-ssh-ext-info-02 [2] > >=C2=A0=C2=A0=C2=A0 - draft-ietf-curdle-ssh-kex-sha2-05 [3] > >=C2=A0=C2=A0=C2=A0 - draft-ietf-curdle-ssh-modp-dh-sha2-02 [4] > > > >Please provide your comments by March 28 on the mailing list.=20 >=20 > draft-ietf-curdle-ssh-modp-dh-sha2-02: >=20 > Section 5, "Many users seem to be interested in the perceived safety of u= sing > larger MODP groups and hashing with SHA2-based algorithms", should that t= ext > be there? It seems rather out of place, orphaned between Figure 2 and the > References section. Good point. I have removed this text in my copy of the draft. It turns out I will not be able to upload a new draft until after this IETF 98 is finished as the submission mechanism is currently suspended. A similar issue applies to draft-ietf-curdle-ssh-kex-sha2-05. This propposed update to the Key Exchange Algorithms list should also probably be pointing to draft-ssorce-gss-keyex-sha2-00 "GSS-API Key Exchange with SHA2" for updates to gss-api-* key exchange algorithms. There is also a need to republish draft-ietf-curdle-ssh-curves so that draft-ietf-curdle-ssh-kex-sha2-06 will point to the unexpired version. Thank you, -- Mark From nobody Sat Mar 18 16:48: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 7B72512773A for ; Sat, 18 Mar 2017 16:48:50 -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 sKVMhQ1bnDLJ for ; Sat, 18 Mar 2017 16:48:49 -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 1ED4312944F for ; Sat, 18 Mar 2017 16:48:48 -0700 (PDT) X-AuditID: 1209190e-1bfff700000015e1-29-58cdc75e9447 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 (Symantec Messaging Gateway) with SMTP id 47.EB.05601.E57CDC85; Sat, 18 Mar 2017 19:48:46 -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 v2INmjPd004672; Sat, 18 Mar 2017 19:48:45 -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 v2INmf8H001469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 18 Mar 2017 19:48:44 -0400 Date: Sat, 18 Mar 2017 18:48:41 -0500 From: Benjamin Kaduk To: "denis bider (Bitvise)" Cc: curdle Message-ID: <20170318234841.GB30306@kduck.kaduk.org> References: <2DD56D786E600F45AC6BDE7DA4E8A8C118BA5A70@eusaamb107.ericsson.se> <1489827654266.43895@cs.auckland.ac.nz> <50977E6A3D174856B8DAF264C3CB81E8@Khan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <50977E6A3D174856B8DAF264C3CB81E8@Khan> User-Agent: Mutt/1.6.1 (2016-04-27) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjleLIzCtJLcpLzFFi42IR4hTV1o07fjbCYMVxQYutC2cxW9x7OYXR gcnj/vR57B5LlvxkCmCK4rJJSc3JLEst0rdL4Mp48vcse0E/a0Vb0yb2BsZZLF2MnBwSAiYS rxdMYQOxhQTamCR+tyl0MXIB2RsZJabM28oO4Vxlkuif9ZIdpIpFQFVi/8lVYDabgIpEQ/dl ZhBbRMBMYtuO26wgNrOAjMTf17sZQWxhAQeJT9u7wGp4gbZ93fKVDWLoQqANX5ayQCQEJU7O fMIC0awu8WfeJaAGDiBbWmL5Pw6IsLxE89bZYGFOoDnvJleChEUFlCUaZjxgnsAoOAvJoFlI Bs1CGDQLyaAFjCyrGGVTcqt0cxMzc4pTk3WLkxPz8lKLdI31cjNL9FJTSjcxgoNakm8H46QG 70OMAhyMSjy8P8rPRgixJpYVV+YeYpTkYFIS5bWWORMhxJeUn1KZkVicEV9UmpNafIhRgoNZ SYQ3czJQOW9KYmVValE+TEqag0VJnFdcozFCSCA9sSQ1OzW1ILUIJivDwaEkwXvzKFCjYFFq empFWmZOCUKaiYMTZDgP0PD/IDW8xQWJucWZ6RD5U4y6HDeOH3jDJMSSl5+XKiXOewekSACk KKM0D24OKBlJZO+vecUoDvSWMO/RY0BVPMBEBjfpFdASJqAly26cAVlSkoiQkmpg5LDzXsYx m6V5a9zkA5oNDIr+m5bNseJu071wtGRh7FGdsiP+N5N2GOn27LuqvHjrJ7eQQ58UGLKV1rtz 9K/vOs3eJzN1lZRu39YL1b0X7rTfdL1f91nmV+3Wj1cPGNn/kc7N3ulq1urlFOtzf+3slXpz 7ngwN9xunJJ9etr6Eif1Jwl/7+yaq8RSnJFoqMVcVJwIAASHoJohAwAA Archived-At: Subject: Re: [Curdle] Comments on draft-ietf-curdle-ssh-ext-info 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, 18 Mar 2017 23:48:50 -0000 Replying to just a process point: On Sat, Mar 18, 2017 at 07:30:48AM -0600, denis bider (Bitvise) wrote: > My understanding, also, is that IETF expects implementations to exist in order to bless an RFC – at least two independent implementations ideally, or at least one minimum. Perhaps I’m mistaken on this? You are probably thinking about getting a document published as a full IETF Internet Standard, which does require at least two interoperable implementations. Less stringent RFC types, such as Proposed Standard, Informational, and Experimental, do not have such a requirement (though it's always good to have, of course). -Ben From nobody Sun Mar 19 02:06:39 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 68C0B129481 for ; Sun, 19 Mar 2017 02:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCngkrF5NbI3 for ; Sun, 19 Mar 2017 02:06:36 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E186B12947F for ; Sun, 19 Mar 2017 02:06:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1489914396; x=1521450396; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=gsjwBez39zuQj9f6Czbo6j1Di9sq4ZHiQjcTfrNN7iE=; b=aiO0B9I6/qZZixo0H76ML/8nlJaIeosR4/jz0XSPYUfuEILGpZ6OOqQc HTkgp9ptlNV2rGPlCayGQh5mFZouM7qELkzTSTQXp+J7XxtNhSuq4TqAH 7nrbVQHJppVfv/ljCHpo6X6sizOuNhmuoGBopEDC3rOSEvG0/Qu7UILpR YlDDW+3P0GwckeedmVxDRVLSgQVMbK60/B4khJDybzds05NN0nUbf0k7l FgQNOpEbuqV4uQ4xoJ2EpfkDldsB7FXIqGFZDR7sU2ftn0tkIx1EWlPJJ /qYuTfboaPObTrErEA+UfY1z6QpJCb/++nEarIFcr9IjFiE/QhLLuEAc0 Q==; X-IronPort-AV: E=Sophos;i="5.36,187,1486378800"; d="scan'208";a="143925709" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.3 - Outgoing - Outgoing Received: from smtp.uoa.auckland.ac.nz (HELO uxcn13-tdc-b.UoA.auckland.ac.nz) ([10.6.3.3]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 19 Mar 2017 22:06:31 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-b.UoA.auckland.ac.nz (10.6.3.3) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sun, 19 Mar 2017 22:06:31 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1178.000; Sun, 19 Mar 2017 22:06:31 +1300 From: Peter Gutmann To: "denis bider (Bitvise)" , Daniel Migault , curdle Thread-Topic: Comments on draft-ietf-curdle-ssh-ext-info Thread-Index: AQHSn+vj75AP59wDbUy5ryRiOFPQYKGb4DhQ Date: Sun, 19 Mar 2017 09:06:30 +0000 Message-ID: <1489914378158.63423@cs.auckland.ac.nz> References: <2DD56D786E600F45AC6BDE7DA4E8A8C118BA5A70@eusaamb107.ericsson.se> <1489827654266.43895@cs.auckland.ac.nz>, <50977E6A3D174856B8DAF264C3CB81E8@Khan> In-Reply-To: <50977E6A3D174856B8DAF264C3CB81E8@Khan> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Curdle] Comments on draft-ietf-curdle-ssh-ext-info 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, 19 Mar 2017 09:06:38 -0000 denis bider (Bitvise) writes:=0A= =0A= >There is no reason for a delay, but people do things for which there aren= =92t=0A= >good reasons, and then others in the future have to compensate. This is to= =0A= >nip the problem in the bud.=0A= =0A= I don't really see what the problem is though, it's like putting up a "Bewa= re=0A= of the dog" sign on a property with no dog.=A0 The text appears to be warni= ng me=0A= about doing something that I'm not doing anyway, and that I have no idea ho= w=0A= to do.=A0 Since the EXT_INFO has to follow the NEWKEYS, it blocks all other= =0A= messages so I couldn't delay it even if I wanted to without stalling the wh= ole=0A= handshake process.=0A= =A0=0A= >Does the draft need to be modified to make this explicit?=0A= =0A= It does need some explanatory text, I think. =0A= =A0=0A= >EXT_INFO is sent by the party that sends it, immediately after that party = has=0A= >sent its own NEWKEYS. Doing otherwise would contradict the =93without dela= y=94=0A= >requirement.=0A= =0A= In that case it probably needs some security considerations text if it's se= nt=0A= before the successful completion of the crypto handshake has been confirmed= .=0A= My guess is that putting the EXT_INFO inside the encrypted layer rather tha= n=0A= in the client/server hello like SSL does is to protect it cryptographically= ,=0A= however sending EXT_INFO before you've got the other side's NEWKEYS means y= ou=0A= could be sending it over a link where the crypto protection hasn't been=0A= successfully activated.=0A= =A0 =0A= >Does the draft need to be modified to clarify this?=0A= =0A= Yes, definitely, because I'd implemented it after both sending and receivin= g=0A= NEWKEYS, for the reason given above.=0A= =A0=0A= >One extension that needs this exact placement is =93delay-compression=94. = For=0A= >that to work, the client has a need to know whether compression should be= =0A= >started at the exact point it receives SSH_MSG_USERAUTH_SUCCESS. But the= =0A= >server may be reluctant to advertise its support for compression beforehan= d.=0A= >Sending the second EXT_INFO at this time is therefore ideal for both parti= es.=0A= >(If it was sent after SSH_MSG_USERAUTH_SUCCESS, there would be the exact r= ace=0A= >condition that =93delay-compression=94 is trying to solve.)=0A= =0A= I think the draft should include some text like this as an explanatory note= .=0A= Getting EXT_INFO as a response to USERAUTH isn't a crash-and-burn thing, bu= t=0A= it just seems logically wrong to insert additional stuff in front of the=0A= answer to the question you've asked.=A0 So some explanatory text would be= =0A= useful.=0A= =0A= >The word =93shall=94 has a well-known meaning in English, and its use in t= his=0A= >context is defined in RFC 2119. If this word was not meant to be used, I= =0A= >think RFC 2119 would not define it.=0A= =0A= The issue isn't that it's wrong, but a question of consistency, the rest of= =0A= the draft uses MAY and SHOULD, having an alternative synonym used in one=0A= location makes it more difficult to read.=0A= =A0=0A= >At this point, I can:=0A= > =0A= >- put it back in, just like it was; or=0A= >- make it an independent submission.=0A= =0A= I would put it back.=A0 Having to do an entire RFC to document a single boo= lean=0A= flag seems like incredible overkill.=0A= =A0=0A= Peter.=0A= = From nobody Tue Mar 21 06:21: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 0ABB4129883 for ; Tue, 21 Mar 2017 06:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2noKq9WZ0rcz for ; Tue, 21 Mar 2017 06:21:23 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9274C129871 for ; Tue, 21 Mar 2017 06:21:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C7E30BEBB for ; Tue, 21 Mar 2017 13:21:20 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CBjYky17N1sI for ; Tue, 21 Mar 2017 13:21:20 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 39C74BE53 for ; Tue, 21 Mar 2017 13:21:20 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1490102480; bh=SIAaqhVG+h/tOCwXcqCS1iP+7EMWQstI1sbGRTE08T4=; h=To:From:Subject:Date:From; b=EBOodhUUar/bbAFoCAvae5krfd2dqoUXIcDP6ezgpR7U3qrMw7bVHT254JlWWY4qp mZEjZKNZB5RC/wUz4gGg+hvtCQ6MqaivjEiHdAV8RvBcqs3JX+aqQ4UXBoKJnYa0a9 UILmzIR+K21WhGVwppsNGZ547kPnSPX44e+4T0Cg= To: "curdle@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <9c33becd-d422-9749-5629-2c0020d10290@cs.tcd.ie> Date: Tue, 21 Mar 2017 13:21:17 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="hWGNO6wWnM3b3uas3dScEgc2xBEQhGIpN" Archived-At: Subject: [Curdle] FYI, mention of curdle on dispatch wg list 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, 21 Mar 2017 13:21:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hWGNO6wWnM3b3uas3dScEgc2xBEQhGIpN Content-Type: multipart/mixed; boundary="Kxi4tF7xihvxTmwKDuoi4pel84NKK8PUo"; protected-headers="v1" From: Stephen Farrell To: "curdle@ietf.org" Message-ID: <9c33becd-d422-9749-5629-2c0020d10290@cs.tcd.ie> Subject: FYI, mention of curdle on dispatch wg list --Kxi4tF7xihvxTmwKDuoi4pel84NKK8PUo Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, Just in case... there's a thread [1] on the dispatch list discussing possible crypto tweaks for DKIM that might or might not result in a desire for some work to be done in the curdle WG. That might e.g. result in a draft on how to use eddsa for DKIM signatures, or something else, or maybe nothing will be needed in the end. It'd be no harm if some folks interested in this WG could attend the dispatch session in Chicago where this will be part of the dispatch agenda [2] on Monday 0900, just so there're folks at the later curdle meeting who can speak to whatever happened at the dispatch session. Cheers, S. [1] https://www.ietf.org/mail-archive/web/dispatch/current/msg06685.html [2] https://tools.ietf.org/wg/dispatch/agenda?item=3Dagenda-98-dispatch-02.ht= ml --Kxi4tF7xihvxTmwKDuoi4pel84NKK8PUo-- --hWGNO6wWnM3b3uas3dScEgc2xBEQhGIpN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJY0SjNAAoJEC88hzaAX42iFusIAIupf7yQAX+JWXt6Tb8htgo2 rZ0BcL0pzfxkrSxqIXlx2JYbD32PAqOcP1MsE4bOPvSaKSKTsOA+/2bDLSFmP88B m9RNhFijLfP6A5KCx2tK99GDr08aDN9d5RCe2yGYojlbuj8SeG+Xe3ozH39qrdjq aaotfRKmf05RHYqWVkMbTw1Y6UQhQ8y+fdTf7UJM6hR8FNOYTuYnOfRBTftVVJd9 v/kFj2Dt13xVBuMHHqcWgj3rgBqYVZzospCzxBQIWVGBzh4jfgSWOz+bY5IKBpOD jX537+9TkC+CTw9CU31K4LW3z6M2ycUCNuRimymdPWhKrAtG2S/RC2xEYtwlMEk= =x/zT -----END PGP SIGNATURE----- --hWGNO6wWnM3b3uas3dScEgc2xBEQhGIpN-- From nobody Tue Mar 21 13:01: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 5078E128D19 for ; Tue, 21 Mar 2017 13:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 2gFyko9yv62o for ; Tue, 21 Mar 2017 13:01:16 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::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 A7E95128CD5 for ; Tue, 21 Mar 2017 13:01:16 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id w124so3389723itb.0 for ; Tue, 21 Mar 2017 13:01:16 -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=VR4TCxZiIXvdQkOc3IYqY3ix2mnbroe+X3KanKaFoMc=; b=GjLsbWrlMN07/DgHpMs9kVbjC4wc5BGqjnmH2O/4BjnVpqShZZMFVnIsJIfmoceYS4 hrAB+KeYQzK/AwiVQlUi3OrvuMYaF7I3nwwEGy+WN3zOUUefzKCEo5zgpxyCjs1EqOv5 W61j4c5hGQ9Q2+2+Dk/9rjVFdlEJLIRAFqpse8mz2DmYBPFqayanSphSBQ+Y5nwEsjb4 Pbsu0auxRn0K/hUZes0Ogj41PfhxAuXK5ZorCfu9Ijcid3CWCFOoaqii7kSw1ksHb+eF q35eapmUywnJE2caYUtwhImGV5bAdB8efEXfYil/XPnxb2/btsQsvaEf9JoTCObjvW5R ArCg== 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=VR4TCxZiIXvdQkOc3IYqY3ix2mnbroe+X3KanKaFoMc=; b=i8ds778Ke1+tDHXztgLcm0pGZqa0/H2CV6LVXqPnCz/zMEqpuBJb1PmWU71r2u24wZ G7wNh43dmPZ5FGu1m9a/HvtuOnC5DeOy4nL2KW8IlCiR3/hLuDR+MaS1vI1qEliZncrc XQ5Bgle2tq7IBGc0PyogbA1ChzqERpXIoE+4BwsF2MdWKTo9+wAHTNLD0slmYEwLT6tt J/sitTFwVAlnlOtL098A1t20j7f2jk2Bx8Fz76woCl3WR0t4XVuathri5m0I+Nj7EoLf MHnqLCsEJ92tEcH4+HNQ0uzQLI3wBFI/fwuW9x94NCYlgEgNMS5/CnY+AUp6YlNHP4Dh ocnQ== X-Gm-Message-State: AFeK/H3YyIWCOdtT9I7EvvanQeDAg2nYGoVY47wtkszpKivSs6eQaTTUUnxdHHaTt3GvRVajrCghtB1scoVrQg== X-Received: by 10.36.215.194 with SMTP id y185mr4569326itg.101.1490126475698; Tue, 21 Mar 2017 13:01:15 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.35.213 with HTTP; Tue, 21 Mar 2017 13:01:14 -0700 (PDT) From: Daniel Migault Date: Tue, 21 Mar 2017 16:01:14 -0400 X-Google-Sender-Auth: cundRjFYtbh_B_4Z7Nmm0mEFtIg Message-ID: To: curdle Content-Type: multipart/alternative; boundary=94eb2c0afc5c4129e8054b431b44 Archived-At: Subject: [Curdle] CURDLE - complete shared gslides by Thursday March 23 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, 21 Mar 2017 20:01:18 -0000 --94eb2c0afc5c4129e8054b431b44 Content-Type: text/plain; charset=UTF-8 Hi, As we have multiple drafts to go through, we thought it would be easier to have a shared presentation that presents drafts and associated discussions on a single presentation [1]. We would appreciate you complete the slides [1] associated to your draft by Thursday 23. If you are presenting please indicate your name as the presenter, otherwise indicate chairs. See you in Chicago! Rich and Daniel [1] https://docs.google.com/presentation/d/1fFHSKUtjlXR6jpede-0BM6s-ITIJreMvYL-tsahYLJM/edit#slide=id.g213392b327_0_51 --94eb2c0afc5c4129e8054b431b44 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

As we hav= e multiple drafts to go through, we thought it would be easier to have a sh= ared presentation that presents drafts and associated discussions on a sing= le presentation [1].

We would appreciate you complete the sli= des [1] associated to your draft by Thursday 23. If you are presenting plea= se indicate your name as the presenter, otherwise indicate chairs.

<= /div>See you in Chicago!

Rich and Daniel

--94eb2c0afc5c4129e8054b431b44-- From nobody Tue Mar 21 20:08:36 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 69EBD12944C for ; Tue, 21 Mar 2017 20:08:35 -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, FREEMAIL_FROM=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 DwFtdt9-mPe5 for ; Tue, 21 Mar 2017 20:08:33 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::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 AC31B131440 for ; Tue, 21 Mar 2017 20:08:33 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id z13so59697899iof.2 for ; Tue, 21 Mar 2017 20:08:33 -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=UVxDymxfDl1tYeJODQtF1ZdUMt3VAl8zTXIxAReZQnw=; b=IsXmJFKyPxtYZuNTtjTOl8z8bnlQsnQfiTDpDzGmpfybiUAgkuwi57BdVmCDhlO8oa yTMpaCdTpPcq0Oeh58MNdScsHu94l+rEz8UiAHO/1DMpsjTv5ZUo9Bc1j9+wInL/yx+B WrAJf3e9DISKvQAvmQbDYAbycOM0pRS7ZZRz5WyLbpeSaCbqbOxFAJvB0WRH7/ZzhBPc DxqgMNpRMtvvchv1H+0/0BK3N8U9yrqX4Ecm77Yp/wJM8iRBocWSiG3vIZhrPR4DETAN 5Fg7lp3cTnyQFHcqhedKDALCDqYaaInufI+lWqwLwE5wzqatUMWBD3jDwEMja4vydW8I tsVQ== 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=UVxDymxfDl1tYeJODQtF1ZdUMt3VAl8zTXIxAReZQnw=; b=Ebjo01DqKwmgAac+BARLVX910HkyQYWGEJpMFtDmwfoE4bZ2YcelvByA7aP+PezW3c sJjudCDAlW49FG5tOxRAAojQt+J4IOAX/H+1KRmF2Y5Loi3auFzqR8DtuR5py6QSvaZf SZu1Y5cPaEkoTD2fdETVIRkGHtlpsnAZ3qKrgJTnF931aFjE0Mr99AFM90rQarM58+Mv +yWKHU/KhTvisIqu9BlAsHV6LPuP+diipgOg8HFj1M+RPwZQBNwjwJ4FLHESd+VE7fuy 6IpWrREk4rNH/7/S+rz/bVPxLZtIyaG5YzqSpDh9Wkkj94Iev9SSLWh8uW/yzyItcyM9 46IA== X-Gm-Message-State: AFeK/H3lmcFYSLKK2SYtg3VwNzJQE7l6BjPkfYpVAT4Ixdm2XOkuxX5W4a7Q3P5vCUg56YRs+wlXPMKya6/ggg== X-Received: by 10.107.129.66 with SMTP id c63mr23948444iod.92.1490152112899; Tue, 21 Mar 2017 20:08:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.97.101 with HTTP; Tue, 21 Mar 2017 20:08:32 -0700 (PDT) In-Reply-To: References: From: Loganaden Velvindron Date: Wed, 22 Mar 2017 07:08:32 +0400 Message-ID: To: curdle@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Curdle] Update to RFC 4419 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, 22 Mar 2017 03:08:35 -0000 On Sat, Mar 11, 2017 at 11:47 AM, Loganaden Velvindron wrote: > Hi All, > > I started working on a small update to RFC 4419, regarding minimum > recommended bit size for k, where k is the modulus length. > > https://tools.ietf.org/id/draft-lvelvindron-dh-group-exchange-00.txt > > This reflects changes that have taken place in OpenSSH, following the logjam > paper. > > https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf > > Hello, This small update to RFC 4419 reflects what OpenSSH is doing. In my humble opinion, having RFCs that reflect what popular implementations are doing tends to be a good idea. From nobody Tue Mar 21 23:02:24 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 AB7ED126B7F for ; Tue, 21 Mar 2017 23:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.519 X-Spam-Level: **** X-Spam-Status: No, score=4.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_SORBS_HTTP=0.001, RCVD_IN_SORBS_SOCKS=1.927, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qXe9-MUf8nE for ; Tue, 21 Mar 2017 23:02:21 -0700 (PDT) Received: from mail01.sigterm.no (mail01.sigterm.no [193.150.121.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E07F7124281 for ; Tue, 21 Mar 2017 23:02:20 -0700 (PDT) Received: from smtp.postman.i2p (i2p-outproxy01.privacysolutions.no [193.150.121.66]) by postman.meeh.i2p (Postfix) with ESMTP id 5F0BA2E119C for ; Wed, 22 Mar 2017 07:02:15 +0100 (CET) X-Virus-Scanned: clamav-milter 0.97 on milter.postman.i2p X-Mailer: smtp.postman.i2p - Official I2P Mailer From: str4d To: David Benjamin , Daniel Migault , "curdle@ietf.org" , Russ Housley , Daniel Kahn Gillmor , Peter Gutmann References: <7d6cfe29-8d4c-436e-fe8a-0cbee915b29e@mail.i2p> <20170311061838.879BAADF28@smtp.postman.i2p> <2DD56D786E600F45AC6BDE7DA4E8A8C118BA5C93@eusaamb107.ericsson.se> <20170314174216.56419ADF21@smtp.postman.i2p> MIME-Version: 1.0 In-Reply-To: <20170314174216.56419ADF21@smtp.postman.i2p> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="gj8u4X6nIJSFnnTCREp8qIdkMnCa5Oi2b" Message-Id: <20170321233151.6B3F8ADF28@smtp.postman.i2p> Date: Tue, 21 Mar 2017 23:31:51 +0000 (UTC) Archived-At: Subject: Re: [Curdle] AlgorithmIdentifier parameters in draft-ietf-curdle-pkix-03 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, 22 Mar 2017 06:02:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gj8u4X6nIJSFnnTCREp8qIdkMnCa5Oi2b Content-Type: multipart/mixed; boundary="Ou5lVGIWsWJdDL9KXCBVbfJmhlbptq1cR"; protected-headers="v1" X-Mailer: smtp.postman.i2p - Official I2P Mailer From: str4d To: David Benjamin , Daniel Migault , "curdle@ietf.org" , Russ Housley , Daniel Kahn Gillmor , Peter Gutmann Subject: Re: [Curdle] AlgorithmIdentifier parameters in draft-ietf-curdle-pkix-03 References: <7d6cfe29-8d4c-436e-fe8a-0cbee915b29e@mail.i2p> <20170311061838.879BAADF28@smtp.postman.i2p> <2DD56D786E600F45AC6BDE7DA4E8A8C118BA5C93@eusaamb107.ericsson.se> <20170314174216.56419ADF21@smtp.postman.i2p> In-Reply-To: <20170314174216.56419ADF21@smtp.postman.i2p> --Ou5lVGIWsWJdDL9KXCBVbfJmhlbptq1cR Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 03/15/2017 06:42 AM, David Benjamin wrote: > No, we should not relax the MUST NOT. We've learned from the previous > algorithms here that multiple options for encodings are an unnecessary > source of complexity and interop headaches. There should only be one > encoding and parsers need to enforce this to avoid an ecosystem mess. As the author of one such parser, I completely agree. Were this a fully-custom stack (like BouncyCastle when using their keystore, or a commercial offering), where I controlled everything below my parser, it wouldn't be a problem. But when the input to my parser is being transparently rewritten to a non-compliant encoding by standard libraries of the programming language itself, my hands are tied. How would the following language (or something to this effect) work as a compromise? In this document we defined six new OIDs for identifying the different curve/algorithm pairs. The curves being Curve25519 and Curve448. The algorithms being ECDH, EdDSA in pure mode and EdDSA in pre-hash mode. For all of the OIDs, the parameters MUST be absent. Regardless of the defect in the original 1997 syntax, implementations MUST NOT write out a parameters value of NULL, and MUST NOT accept a parameters value of NULL, EXCEPT where doing so is unavoidable due to legacy PKCS8 interpretation within the implementation language's standard libraries (such as Java's Sun security provider before version XX). I can comply with this, because my implementation will write the single correct encoding to any destination (keystore or otherwise, modulo whatever PKCS8 transformations that destination applies), but being a standalone Java parser it can't know whether it is receiving input from the default keystore or a compliant one. In a language where the default PKCS8 parser can be made compliant, the MUST NOT would remain enforced. Alternatively, the MUST NOT can be left as-is, and I will consider this a case of "know the rules you're breaking". My concern then would be my code being copied into other projects without this understanding (which I would attempt to alleviate via comments), or other independent Java implementations running up against this issue and just ignoring the MUST NOT entirely, leading to incorrect encodings being written out (avoidance of which AFAICT is the primary motivator for the MUST NOT). Cheers, Jack --Ou5lVGIWsWJdDL9KXCBVbfJmhlbptq1cR-- --gj8u4X6nIJSFnnTCREp8qIdkMnCa5Oi2b Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJY0bfVAAoJEGppFNr76gDaJ7EP/0Q35tGQSBX3Yu4sLxC9O/84 ygIou9ZgLv9tiI9scMjfpW/XAj2jB94mF7iEcikpzAeogTCUZzgRkcUPcpOl70d0 3y09QtcuOpu+raERY/2v88c2FkEmeyjgGFEynRujKOzJODcMyPvO/x1KNCLVGa5I 2ynyVW/lYw1FfMm8QS9uvDEy/b2NQwFPYDz6CZBGmrocbrh+GhHn/JcZIxhFawQ/ tqee0NEED6UyfA2R4iczkU4vwxn2aSdbr9loKwQeymueNksXv8PHFZxnvsZAyy9s 5x8nQ7HebgRA0WoyZ3y5xkeNruM79X6fFErtp65ZictzHiDXKeYryeI6Ua4EjJdv dVo3JtO6zXApc6MdzYLQy4Z7SY9YTeoEmSMMurTIyVjSyY0UgCpVjB5QidCIR8jU Hm94ETSWbhN/BzEiu5SlJmGnm1LQIKLnCNjDPBGMnUDPOIX52rVjSrpHuS31mE89 E5q19/n6f+PjZ8CxVEcBCS7MJe+u+3WIZThde+y1jbXGWwGLQO+6UnZjaRadvred e7XYz9jNTbAIIMfVu4EYtmrREr4R0mBddLVvDyts6lKkDhqnvKXKdM2BIWkH5Dwl fZfeu25PRKt9u/Pm6M1O3GENQR0+c2GSJL4ondFnY4hu5yt0anFr3/wb9j6PP0u+ ypZz/8N5zOIKr3lJ4ri7 =+l9g -----END PGP SIGNATURE----- --gj8u4X6nIJSFnnTCREp8qIdkMnCa5Oi2b-- From nobody Wed Mar 22 15:14:20 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 6DA2912949F for ; Wed, 22 Mar 2017 15:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, 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 F_yJGmh8e8-J for ; Wed, 22 Mar 2017 15:14:17 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::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 229E91298A3 for ; Wed, 22 Mar 2017 15:13:49 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id y18so30930761itc.0 for ; Wed, 22 Mar 2017 15:13: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=8WiNqRuJYneGTmnrqo24Daq7f7LAw2Kw0UD2CFXPEJI=; b=Ih+bE3zIV/rcd912vMvnCMbZMnfVpkruySBd0uL+Twqj+2FYzTx2VHLRhGoriJvtwJ CyFIwwVjLGmk55MYbkaCYmg0/CxsljYLwjyBtfjNvAPlY5XY2iNt4Pog48OJCkD3ui1t C5vZydMAkEvAXFfolIYo3jABZyiwfvxYJHgnmdnKeLSDOpJFdhNuoiF60O7ZoJ4H4HYw gLpCbFh8kSnMYW8XpnBbMOnqsJZvDNHbQdx1nP4Fda7FQbt3JnnVRK6cWsvzvVGJJjaS 4s2jozNwRV6D+Mnm35fq3yg6NAluSWNG0JAYxPQD4fONydn8mcDZLCJaMH1nZx0dHQkX WFmQ== 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=8WiNqRuJYneGTmnrqo24Daq7f7LAw2Kw0UD2CFXPEJI=; b=LnqkMiZ0Cdv7PKhDqXXbSQlfvIG45yAk3mfFsTZ19PD2Yn5PHxuhwNYIi0uG2Z1oTr 3HUgSjuCjlZFDWeGDAaPRdE2IWaA4nUv30ytjewvxrqFIbub1Ck5UkwP6Ojb4MzyRyxb QE31kGhYVVUD6kS9WUdZjuu8mGYkA9PhHAS2FDXGicu6A1RLjyvlKTcJA7nCgpFoSs08 IPh9arCq6DRrRsvpN8AaKBpmq344Jhj7KpNY3WzPw8G9jl4VInpfe/lHzuFvCRWHq23t N7bx6fKBMlWlyKidvi6cZuv+teM97YKV6ETJTrJGXZREsHXF8LsI8hVLHSvW/pzci5x2 zKLw== X-Gm-Message-State: AFeK/H3Q/iM5Mz+4NBTHTgDUoxw/fFLPlZMMOhkdKfweGV45VDCqEgtXu3eBylRaaUJOqW/jB0rht1DqRGL4Bw== X-Received: by 10.36.175.5 with SMTP id t5mr10155338ite.48.1490220828476; Wed, 22 Mar 2017 15:13:48 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.35.213 with HTTP; Wed, 22 Mar 2017 15:13:47 -0700 (PDT) From: Daniel Migault Date: Wed, 22 Mar 2017 18:13:47 -0400 X-Google-Sender-Auth: mrK0LSh248yb-E0sNqIeNzeIFrE Message-ID: To: curdle Content-Type: multipart/alternative; boundary=f403045dc12a1e4cf2054b591363 Archived-At: Subject: [Curdle] draft-ietf-curdle-pkix / Algorithm Identifier for prehash variant 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, 22 Mar 2017 22:14:19 -0000 --f403045dc12a1e4cf2054b591363 Content-Type: text/plain; charset=UTF-8 Hi, As we are moving toward only using the non prehash variant. I would like to have the WG opinion on whether or not we should keep the following algorithm Identifiers: id-Ed25519ph OBJECT IDENTIFIER ::= { 1 3 101 114 } id-Ed448ph OBJECT IDENTIFIER ::= { 1 3 101 115 } Yours, Daniel --f403045dc12a1e4cf2054b591363 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

As we are moving toward only using = the non prehash variant. I would like to have the WG opinion on whether or = not we should keep the following algorithm Identifiers:
   id-Ed25519ph OBJECT IDENTIFIER ::=3D { 1 3 101 114 }
   id-Ed448ph   OBJECT IDENTIFIER ::=3D { 1 3 101 115 }

Yours, 
Daniel=
--f403045dc12a1e4cf2054b591363-- From nobody Wed Mar 22 15:55: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 A96AC127058 for ; Wed, 22 Mar 2017 15:55:36 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 bDe5kMLMwUt1 for ; Wed, 22 Mar 2017 15:55:34 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::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 A3220126C83 for ; Wed, 22 Mar 2017 15:55:34 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id x35so162622710qtc.2 for ; Wed, 22 Mar 2017 15:55:34 -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=R17taN5TbsT9bnA9aEuA0t/ZFnSzj3lKUTMYfbQ+EyI=; b=fS4NPfRq2t/zBtwcH/L9msHvuRq0+fA147LHfT3Vempj3xhZmMiB+ugS058ODtEhf6 6XDm6phVQnOZXQUrpQc1zcKy/peXH2HYNYp+lMCddiWHIdDwWDZyNSW+QSSj/x+JkehH zoEC9ejaWlh6OYkvDEa/yBefrMHdTjMoESUkU= 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=R17taN5TbsT9bnA9aEuA0t/ZFnSzj3lKUTMYfbQ+EyI=; b=cdVD62zQLN3fpw/jXFtz7S4HFYbhog21nw8Jqeh8OW0fhylOHVdXtOzxC7kqLFssBO 6E1pGyS9mW2n9Gppkn2NXsHbT3YinTXBmLFXQs4KAneXDhkfXFYsHH5HgpefrvuoblGg crREmLOWw4nsqdMj1p37T3avr3uWEAa7+WSxHxqi1FCq50vhTRVEzJ85TiigUyhYMVYf p1MT6vQrRz7lznWOdIQU1s+9G/eUGhDem8vqiNtfRe4P9AgGOfawHi8dXyFbO6W+gEbo G1lrW+KIEnxvlpl2EdXt7sYmM3AasdRQpV8cIr4cZedT9S5KeL/GrvbtjNjbmh7OHsOY OC0g== X-Gm-Message-State: AFeK/H2ae27yjXIu6pVpLcaPEk3v9sOEv2+x9QLRspRAz8/jtRhSgwwtn3ehVHX8KWupbg== X-Received: by 10.200.51.117 with SMTP id u50mr31516466qta.133.1490223333758; Wed, 22 Mar 2017 15:55:33 -0700 (PDT) Received: from [172.16.0.18] ([96.231.230.131]) by smtp.gmail.com with ESMTPSA id k36sm1990834qtc.10.2017.03.22.15.55.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Mar 2017 15:55:32 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Sean Turner In-Reply-To: Date: Wed, 22 Mar 2017 18:55:29 -0400 Cc: curdle Content-Transfer-Encoding: quoted-printable Message-Id: <48694963-30E4-4B88-BFEF-C68475DCD689@sn3rd.com> References: To: Daniel Migault X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-pkix / Algorithm Identifier for prehash variant 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, 22 Mar 2017 22:55:37 -0000 You mean just dropping them from the draft right because once you=E2=80=99= ve assigned the # and put =E2=80=98em in a draft they=E2=80=99re pretty = much out there? spt > On Mar 22, 2017, at 18:13, Daniel Migault = wrote: >=20 > Hi,=20 >=20 > As we are moving toward only using the non prehash variant. I would = like to have the WG opinion on whether or not we should keep the = following algorithm Identifiers: > id-Ed25519ph OBJECT IDENTIFIER ::=3D { 1 3 101 114 } > id-Ed448ph OBJECT IDENTIFIER ::=3D { 1 3 101 115 } >=20 >=20 > Yours,=20 > Daniel=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Wed Mar 22 16:12:29 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 5F5AE1293EE for ; Wed, 22 Mar 2017 16:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, 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 Yzz5QBc3HKo5 for ; Wed, 22 Mar 2017 16:12:25 -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 36C6A126C83 for ; Wed, 22 Mar 2017 16:12:25 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id y18so31408308itc.0 for ; Wed, 22 Mar 2017 16:12:25 -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=EtmIQh1HU97Z+EpStInLJJOCvTdw6F6r1F1wFdvmMqQ=; b=c3haxSo877+t6FYDA40/witdafamRgXCB0tpUFO4R01MlTniB91+64f4g/GuBivC2F DfrnaakN0dHULU+IRAT8Qj6t23APzttsh2FKOd6B4VY0IQWI5ncDydMvRWKQv0JWRvJ4 h2esxlPTSEjdvvvHXrwD9geo3z9zpIe9oAJ8QJtR/qqWvvw21uFxfyGmeHCDukB3NztJ UdsMKUS6se+oZ8p0arIOFf2NyeiBRlwueOamkJ3M+uc3LLQ9UsXnp6ACGyEayDMsIqM1 nXkalSAVZ/bkUjvFvfo5V1z72+oc6gboaJFq0Z7d8Rl2ko6VWSZzgJYM5wqW729tMN1B Beog== 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=EtmIQh1HU97Z+EpStInLJJOCvTdw6F6r1F1wFdvmMqQ=; b=JjT3yLzZ4J618rrTw37Q5vVyvO6efSSgPSv1owNAwk1s6e5bYnTnNKLiP2eJjgZ/6n 6SqOSbLbQ01yctkavpZPBBUlzUkK6ofWlyAGQexZXde/n2+Gs6sRN/hLUBDqlRHk81Rp OeTWeMLnAZe4Gg4yodbnFH+DewRIfGK3+RtMQimuPpYNzNeiG69+85r+lZ++dkEWufn9 B0dPYL6rWo/98dDbywWnISiBNNJ4HljTc4NYtzvFzEWXCP42FAJhv7X05ztcSTff6Efg B6LFDo8/+gOmAIcqpZF0kqkFk6CMNNvNYCX7eA9AxJbdYY5KvIr919p8/qC1/W6LXMXM zUGQ== X-Gm-Message-State: AFeK/H0AmSehCDsMGEoztRH47UsCJ26R0gHCM2XuBmb0Mj/2grq093MSlkowU3OaDYB5AlReUqptDhBWnBJEBA== X-Received: by 10.36.164.75 with SMTP id v11mr10914038iti.101.1490224344657; Wed, 22 Mar 2017 16:12:24 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.35.213 with HTTP; Wed, 22 Mar 2017 16:12:24 -0700 (PDT) In-Reply-To: <48694963-30E4-4B88-BFEF-C68475DCD689@sn3rd.com> References: <48694963-30E4-4B88-BFEF-C68475DCD689@sn3rd.com> From: Daniel Migault Date: Wed, 22 Mar 2017 19:12:24 -0400 X-Google-Sender-Auth: _5vscXo1o6r0aJwPouZzKBUF-ao Message-ID: To: Sean Turner Cc: curdle Content-Type: multipart/alternative; boundary=f403045fbba8b2f660054b59e4e6 Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-pkix / Algorithm Identifier for prehash variant 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, 22 Mar 2017 23:12:27 -0000 --f403045fbba8b2f660054b59e4e6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes removing them from the draft. OIDs will be re-assigned by the IANA. Yours, Daniel On Wed, Mar 22, 2017 at 6:55 PM, Sean Turner wrote: > You mean just dropping them from the draft right because once you=E2=80= =99ve > assigned the # and put =E2=80=98em in a draft they=E2=80=99re pretty much= out there? > > spt > > > On Mar 22, 2017, at 18:13, Daniel Migault > wrote: > > > > Hi, > > > > As we are moving toward only using the non prehash variant. I would lik= e > to have the WG opinion on whether or not we should keep the following > algorithm Identifiers: > > id-Ed25519ph OBJECT IDENTIFIER ::=3D { 1 3 101 114 } > > id-Ed448ph OBJECT IDENTIFIER ::=3D { 1 3 101 115 } > > > > > > Yours, > > Daniel > > _______________________________________________ > > 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 > --f403045fbba8b2f660054b59e4e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes removing them from the draft. OIDs will be r= e-assigned by the IANA.
Yours,
Daniel

On Wed, Mar 22, 2017 at 6= :55 PM, Sean Turner <sean@sn3rd.com> wrote:
You mean just dropping them from the draft right because onc= e you=E2=80=99ve assigned the # and put =E2=80=98em in a draft they=E2=80= =99re pretty much out there?

spt

> On Mar 22, 2017, at 18:13, Daniel Migault <daniel.migault@ericsson.com> wrote:
>
> Hi,
>
> As we are moving toward only using the non prehash variant. I would li= ke to have the WG opinion on whether or not we should keep the following al= gorithm Identifiers:
>=C2=A0 =C2=A0 id-Ed25519ph OBJECT IDENTIFIER ::=3D { 1 3 101 114 }
>=C2=A0 =C2=A0 id-Ed448ph=C2=A0 =C2=A0OBJECT IDENTIFIER ::=3D { 1 3 101 115 }
>
>
> Yours,
> Daniel
> _______________________________________________
> 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

--f403045fbba8b2f660054b59e4e6-- From nobody Thu Mar 23 04:54:21 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 25E81127863 for ; Thu, 23 Mar 2017 04:54:20 -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, RP_MATCHES_RCVD=-0.001, 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=denisbider.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 XGQJYne3lmBr for ; Thu, 23 Mar 2017 04:54:17 -0700 (PDT) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5A0B124282 for ; Thu, 23 Mar 2017 04:54:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=denisbider.com; s=mail; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to: references; bh=mmyuTfzeefIWLW0UMOLCYYEN6ZqrN7z/XyF2qKjVBwA=; b=fCVOwZA3QRcTyV695+SAuaz5+/b2lfn8SDdPOTaUmEG4MNUt3wBs1Qxikq47JLSnF54WvsCekETOc FxlN5klpX7enMIbDhaio7YV8Dl8jEG569rKxD7uDIB7zVLymrJqTy7mFKGy0mTcfc3c5WsD7t3rPmS bYrwBlHgt23pbl+ukM+CETPKwOejPcMdi+Ob8GWxpcd/oFLuRvuNylKEeLd7BRfXUHxm8QrI/kveqF 9fV/MfrIjztRbpxcSaPagZhcumZ+b+Scq8/YymI+BiyvuSrgHt9IOSAX1WRhLDk+qKPEieLT+ojl8v K3KAB9NdIfYPxvAGyx8BsFLzumzCb+A== X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)); Thu, 23 Mar 2017 11:54:02 +0000 Message-ID: From: "denis bider \(Bitvise\)" To: =?UTF-8?B?0KDRg9C80LXQvSDQn9C10YLRgNC+0LI=?= , References: <148823325745.13859.1818801191554779419.idtracker@ietfa.amsl.com> <58CCEF4F.7000902@roumenpetrov.info> <9EABA431E21041239B7D2B164FAA5AC3@Khan> <58CD46B0.9010902@roumenpetrov.info> In-Reply-To: <58CD46B0.9010902@roumenpetrov.info> Date: Thu, 23 Mar 2017 05:54:02 -0600 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0034_01D2A399.DFE02C20" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [Curdle] Comments on draft-ietf-curdle-rsa-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, 23 Mar 2017 11:54:20 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0034_01D2A399.DFE02C20 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response Content-Transfer-Encoding: 8bit Hello Roumen: > Quote from rfc4252: > byte SSH_MSG_USERAUTH_REQUEST > [...] > string public key algorithm name <<<<----- Thank you for pointing this out. This is an important point. The document needs a more formal discussion to properly introduce the concept for "signature algorithm". Draft submissions are currently off, but I have clarified this in my local version with an additional section that discusses the terms "public key algorithm" and "signature algorithm" in detail. It also points out two places in RFC4252 and RFC4253 which subtly change meaning, and now encode a signature algorithm name. Since I cannot submit it right now, I attach a copy of my current local version. > From my point of view draft or RFC should not describe > experimental or not accepted information. This may conflict with Peter's request, which is to include the definition of the "no-flow-control" extension. My understanding is that he intends to implement it, but wishes to see the language finalized before doing so. For the time being, I have re-added "no-flow-control" in my local version. Besides "no-flow-control", all other extensions ("server-sig-algs", "delay-compression", "elevation") are currently implemented. denis ----- Original Message ----- From: Румен Петров Sent: Saturday, March 18, 2017 08:39 To: curdle@ietf.org Subject: Re: [Curdle] Comments on draft-ietf-curdle-rsa-sha2 HI Denis, denis bider (Bitvise) wrote: [SNIP] > Before this draft, SSH uses the following terminology: > > - "public key algorithm" means the algorithm used to generate the key; as > well as the format used to encode the key; as well as the algorithm used > to perform the signature. No. Before this draft, RFC 6187 defines new public key algorithms with new format to encode the key and existing signature format, i.e. new/new/old. You proposition is new/old/new. I'm fine with your arguments to reuse public key blog, but I disagree that draft-ietf-curdle-rsa-sha2 does not define new algorithm. Quote from rfc4252: byte SSH_MSG_USERAUTH_REQUEST string user name string service name string "publickey" boolean TRUE string public key algorithm name <<<<----- string public key to be used for authentication string signature and from draft : byte SSH_MSG_USERAUTH_REQUEST string user name string service name string "publickey" boolean TRUE string "rsa-sha2-512" <<<<----- public string public key blob: string "ssh-rsa" mpint e mpint n string signature: string "rsa-sha2-512" string rsa_signature_blob If in draft your replace "rsa-sha2-512" with ssh-rsa I will agree that draft is only with signature algorithm, i.e. old/old/new. Draft sample shows new public key algorithm. I could guess that you start with only with new signatures but now I see more enhanced encoding of authentication request. [SNIP] Roumen _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle ------=_NextPart_000_0034_01D2A399.DFE02C20 Content-Type: text/plain; format=flowed; name="draft-ietf-curdle-rsa-sha2-04.txt"; reply-type=response Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-curdle-rsa-sha2-04.txt" Internet-Draft D. Bider Updates: 4252, 4253 (if approved) Bitvise Limited Intended status: Standards Track March 23, 2017 Expires: September 23, 2017 Use of RSA Keys with SHA-2 256 and 512 in Secure Shell (SSH) draft-ietf-curdle-rsa-sha2-03.txt Abstract This memo defines an algorithm name, public key format, and signature format for use of RSA keys with SHA-2 hashing for server and client authentication in SSH connections. Status This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Bider [Page 1] =0C Internet-Draft RSA Keys with SHA-2 in SSH March 2017 1. Overview and Rationale Secure Shell (SSH) is a common protocol for secure communication on the Internet. In [RFC4253], SSH originally defined the signature methods "ssh-rsa" for server and client authentication using RSA with SHA-1, and "ssh-dss" using 1024-bit DSA and SHA-1. A decade later, these signature methods are considered deficient. For US government use, NIST has disallowed 1024-bit RSA and DSA, and use of SHA-1 for signing [800-131A]. This memo introduces a distinction between public key and signature algorithms in SSH, and defines new signature algorithm names allowing for interoperable use of existing and new RSA keys with SHA-2 hashing. 1.1. Requirements Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Signature Algorithm as Distinct Aspect of Public Key Algorithm In [RFC4252], the concept "public key algorithm" is used to establish a relationship between one algorithm name, and: A. Procedures used to generate and validate a private/public keypair. B. A format used to encode a public key. C. Procedures used to calculate, encode, and verify a signature. This document narrows the term "public key algorithm" to mean A and B, though it can still potentially imply C when a public key algorithm is associated with only one signature algorithm. A new term, "signature algorithm", is introduced to refer specifically to C. This affects the meaning of the field "server_host_key_algorithms" in the message SSH_MSG_KEXINIT ([RFC4253]). With this document, this field now refers specifically to signature, not public key algorithms. This also affects the message SSH_MSG_USERAUTH_REQUEST when used with the "publickey" authentication method as defined in [RFC4252]. With this document, the definition of this message is updated as follows: byte SSH_MSG_USERAUTH_REQUEST string user name in ISO-10646 UTF-8 encoding [RFC3629] string service name in US-ASCII string "publickey" boolean FALSE string signature algorithm name string public key blob Bider [Page 2] =0C Internet-Draft RSA Keys with SHA-2 in SSH March 2017 The format of the message remains unchanged. The change is in the line which now reads "signature algorithm name". This used to read "public key algorithm name". These changes do not affect key types other than RSA. Other public key algorithms continue to use one signature algorithm of the same name. There is no impact on existing implementations that support RSA keys only as "ssh-rsa". Such implementations continue to use the public key algorithm "ssh-rsa", and the signature algorithm of the same name. 3. New RSA Signature Algorithms This memo adopts the style and conventions of [RFC4253] in specifying how use of a signature algorithm is indicated in SSH. The following new signature algorithms are defined: rsa-sha2-256 RECOMMENDED sign Raw RSA key rsa-sha2-512 OPTIONAL sign Raw RSA key These algorithms are suitable for use both in the SSH transport layer [RFC4253] for server authentication, and in the authentication layer [RFC4252] for client authentication. Since RSA keys are not dependent on the choice of hash function, the new signature algorithms are defined as aspects of the existing "ssh-rsa" public key algorithm. This means the new algorithms reuse the "ssh-rsa" public key format as defined in [RFC4253]: string "ssh-rsa" mpint e mpint n All aspects of the "ssh-rsa" format are kept, including the encoded string "ssh-rsa". This allows existing RSA keys to be used with the new signature formats, without requiring re-encoding, or affecting already trusted key fingerprints. Signing and verifying using these algorithms is performed according to the RSASSA-PKCS1-v1_5 scheme in [RFC3447] using SHA-2 [FIPS-180-4] as hash; MGF1 as mask function; and salt length equal to hash size. For the algorithm "rsa-sha2-256", the hash used is SHA-2 256. For the algorithm "rsa-sha2-512", the hash used is SHA-2 512. The resulting signature is encoded as follows: string "rsa-sha2-256" / "rsa-sha2-512" string rsa_signature_blob Bider [Page 3] =0C Internet-Draft RSA Keys with SHA-2 in SSH March 2017 The value for 'rsa_signature_blob' is encoded as a string containing S - an octet string which is the output of RSASSA-PKCS1-v1_5, of length equal to the length in octets of the RSA modulus. 3.1. Use for server authentication To express support and preference for one or both of these algorithms for server authentication, the SSH client or server includes one or both algorithm names, "rsa-sha2-256" and/or "rsa-sha2-512", in the name-list field "server_host_key_algorithms" in the SSH_MSG_KEXINIT packet [RFC4253]. If one of the two host key algorithms is negotiated, the server sends an "ssh-rsa" public key as part of the negotiated key exchange method (e.g. in SSH_MSG_KEXDH_REPLY), and encodes a signature with the appropriate signature algorithm name - either "rsa-sha2-256", or "rsa-sha2-512". 3.2. Use for client authentication To use this algorithm for client authentication, the SSH client sends an SSH_MSG_USERAUTH_REQUEST message [RFC4252] encoding the "publickey" method, and encoding the string field "public key algorithm name" with the value "rsa-sha2-256" or "rsa-sha2-512". The "public key blob" field encodes the RSA public key using the "ssh-rsa" algorithm name. The signature field, if present, encodes a signature using an algorithm name that MUST match the SSH authentication request - either "rsa-sha2-256", or "rsa-sha2-512". For example, an SSH "publickey" authentication request using an "rsa-sha2-512" signature would be properly encoded as follows: byte SSH_MSG_USERAUTH_REQUEST string user name string service name string "publickey" boolean TRUE string "rsa-sha2-512" string public key blob: string "ssh-rsa" mpint e mpint n string signature: string "rsa-sha2-512" string rsa_signature_blob 3.3. Discovery of signature algorithms supported by servers Implementation experience has shown that there are servers which apply authentication penalties to clients attempting signature algorithms which the SSH server does not support. Bider [Page 4] =0C Internet-Draft RSA Keys with SHA-2 in SSH March 2017 Servers that accept rsa-sha2-* signatures for client authentication SHOULD implement the extension negotiation mechanism defined in [SSH-EXT-INFO], including especially the "server-sig-algs" extension. When authenticating with an RSA key against a server that does not implement the "server-sig-algs" extension, clients MAY default to an ssh-rsa signature to avoid authentication penalties. 4. IANA Considerations IANA is requested to update the "Secure Shell (SSH) Protocol Parameters" registry, to extend the table Public Key Algorithm Names: - To the immediate right of the column Public Key Algorithm Name, a new column is to be added, titled Signature Algorithm Name. For existing entries, the column Signature Algorithm Name should be assigned the same value found under Public Key Algorithm Name. - Immediately following the existing entry for "ssh-rsa", two sibling entries are to be added: P. K. Alg. Name Sig. Alg. Name Reference Note ssh-rsa rsa-sha2-256 [this document] Section 3 ssh-rsa rsa-sha2-512 [this document] Section 3 5. Security Considerations The security considerations of [RFC4253] apply to this document. The National Institute of Standards and Technology (NIST) Special Publication 800-131A [800-131A] disallows the use of RSA and DSA keys shorter than 2048 bits for US government use after 2013. The same document disallows the SHA-1 hash function, as used in the "ssh-rsa" and "ssh-dss" algorithms, for digital signature generation after 2013. 6. Why no DSA? 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 abstains from defining new algorithm names for DSA, and recommends RSA and/or elliptic curve cryptography. Bider [Page 5] =0C Internet-Draft RSA Keys with SHA-2 in SSH March 2017 7. References 7.1. Normative References [FIPS-180-4] National Institute of Standards and Technology (NIST), United States of America, "Secure Hash Standard (SHS)", FIPS Publication 180-4, August 2015, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003. [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006. [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006. 7.2. Informative References [800-131A] National Institute of Standards and Technology (NIST), "Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths", NIST Special Publication 800-131A, January 2011, . [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, January 2006. [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)", RFC 6979, August 2013. [SSH-EXT-INFO] Bider, D., "Extension Negotiation in Secure Shell (SSH)", draft-ietf-curdle-ssh-ext-info-02.txt, February 2017, . Bider [Page 6] =0C Internet-Draft RSA Keys with SHA-2 in SSH March 2017 Author's Address Denis Bider Bitvise Limited Suites 41/42, Victoria House 26 Main Street GI Phone: +506 8315 6519 EMail: ietf-ssh3@denisbider.com URI: https://www.bitvise.com/ Acknowledgments Thanks to Jon Bright, Niels Moeller, Stephen Farrell, Mark D. Baushke, Jeffrey Hutzelman, Hanno Boeck, Peter Gutmann, Damien Miller, Mat Berchtold, and Roumen Petrov for reviews, comments, and suggestions. Bider [Page 7] =0C ------=_NextPart_000_0034_01D2A399.DFE02C20-- From nobody Thu Mar 23 05:01: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 208AE1296C0 for ; Thu, 23 Mar 2017 05:01:57 -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, RP_MATCHES_RCVD=-0.001, 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=denisbider.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 nlR7sAo2d-uh for ; Thu, 23 Mar 2017 05:01:53 -0700 (PDT) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4F981296CF for ; Thu, 23 Mar 2017 05:01:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=denisbider.com; s=mail; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to: references; bh=nfNj0Ed+58+4ecP5GL0xXTBKUeaXo0isoJGtFTLLhlI=; b=w48kgqy3GObj/50hZYEkjIjloOXmBT7gHRyjNmo2coBumuMyAPeEEvzNgoHgfA4QsBjgwT74XKr5g b42llLndzbRnVlkFDpcHiGH9YB/tnJ7wrrb3AiMvFMrgBK5Z22fZll2xIKV0vorc4UnJkx26iyX/lZ hhK3naIfsSXcq85rmbXhp62FQTBgJJfEZL1n9TkA/0qlVwJAGr393KKE76qKiCVx1wStbTQSi4IUsX MhqPPJ86HljKi3AuO2wMlJbM81euZItxsOr1zfd2efX5Y8Kdu5YEKprApq/ZrU7RiHE9bX6r7we1B1 QItULuaiiYDbNZoZYdIHVr2JujBtHbw== X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)); Thu, 23 Mar 2017 12:01:03 +0000 Message-ID: <74B4C5B2AFD644748A0E1B0957A22C96@Khan> From: "denis bider \(Bitvise\)" To: "Peter Gutmann" , "Daniel Migault" , "curdle" References: <2DD56D786E600F45AC6BDE7DA4E8A8C118BA5A70@eusaamb107.ericsson.se> <1489827654266.43895@cs.auckland.ac.nz>, <50977E6A3D174856B8DAF264C3CB81E8@Khan> <1489914378158.63423@cs.auckland.ac.nz> In-Reply-To: <1489914378158.63423@cs.auckland.ac.nz> Date: Thu, 23 Mar 2017 06:01:19 -0600 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0096_01D2A39A.E3ECBE40" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [Curdle] Comments on draft-ietf-curdle-ssh-ext-info 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, 23 Mar 2017 12:01:57 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0096_01D2A39A.E3ECBE40 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 8bit Hello Peter: > > Does the draft need to be modified to make this explicit? > It does need some explanatory text, I think. OK. Draft submissions are currently off, but I have clarified this in my local version with the following text: This message is sent immediately after SSH_MSG_NEWKEYS, without delay. This allows a client to pipeline an authentication request after its SSH_MSG_SERVICE_REQUEST, even when this needs extension information. > In that case it probably needs some security considerations > text if it's sent before the successful completion of the > crypto handshake has been confirmed. My guess is that putting > the EXT_INFO inside the encrypted layer rather than in the > client/server hello like SSL does is to protect it > cryptographically, however sending EXT_INFO before you've > got the other side's NEWKEYS means you could be sending it > over a link where the crypto protection hasn't been successfully > activated. I'm not sure that I see the threat here, or how the described behavior would resolve it. NEWKEYS is the last message in each direction that is still sent with the old keys (or in plaintext). Therefore, receiving NEWKEYS does not provide any sense of certainty that encryption is properly in place. Instead, the sense of certainy is provided by the key exchange. Either the key exchange is secure, and data encrypted using it is secure, regardless of whether the other side sends anything; or it isn't. As-is, a client might obtain crypto parameters from a completed key exchange, and then: 1. Send NEWKEYS with the old crypto parameters (or in plaintext if this is the first key exchange). 2. Send SERVICE_REQUEST, immediately followed by a USERAUTH message. This can all be sent potentially in the same transmission as the client's NEWKEYS. If the client receives the server's NEWKEYS or not, it does not make a difference, because that's sent with the old crypto parameters (e.g. in plaintext). This is not problematic for the client, because the client has already verified the identity of the server as part of the key exchange. If the key exchange is secure, anything the client sends will either be decrypted by the legitimate server, or it won't be decrypted. Sending EXT_INFO is not problematic from the server's perspective either, because the server has not authenticated the client, and anything the server sends at this stage is world-readable. (Aside from IP blocking and similar, anyone can connect to the server, do their own key exchange, and get the info.) > Yes, definitely, because I'd implemented it after > both sending and receiving NEWKEYS, for the reason > given above. But I don't see what this would achieve, since NEWKEYS is still unencrypted. As-is, the server doesn't send an encrypted piece of information until it's replying to SERVICE_ACCEPT. > The issue isn't that it's wrong, but a question of > consistency, the rest of the draft uses MAY and SHOULD, > having an alternative synonym used in one location makes > it more difficult to read. OK, I have changed SHALL to MUST. > I would put it back. Having to do an entire RFC to > document a single boolean flag seems like incredible overkill. OK, I have added back definitions for "no-flow-control" and "elevation". I have recently implemented "delay-compression" in our SSH Server and Client. Our FlowSsh library implements "elevation", and it's pending implementation in our SSH Server and Client. I have left out "accept-channels" completely. I have changed my mind about it having a compelling reason, and I haven't noticed interest in it. When re-adding "no-flow-control", I realized that the original definition is deficient, and allows no room for implementations that support this extension, but still prefer not to use it. Ours would be an implementation like that. If this needs two implementations to be added, I will implement it to make life easier for implementers of simpler SSH software, but I would prefer not to use it. I have therefore changed the definition as follows: string "no-flow-control" string choice of: "p" for preferred | "s" for supported To take effect, this extension MUST be: - Sent by both parties. - At least one party MUST have sent the value "p" (preferred). Since I cannot submit a new version right now, I attach a copy of my current local version. denis ----- Original Message ----- From: Peter Gutmann Sent: Sunday, March 19, 2017 03:06 To: denis bider (Bitvise) ; Daniel Migault ; curdle Subject: Re: [Curdle] Comments on draft-ietf-curdle-ssh-ext-info denis bider (Bitvise) writes: >There is no reason for a delay, but people do things for which there aren’t >good reasons, and then others in the future have to compensate. This is to >nip the problem in the bud. I don't really see what the problem is though, it's like putting up a "Beware of the dog" sign on a property with no dog. The text appears to be warning me about doing something that I'm not doing anyway, and that I have no idea how to do. Since the EXT_INFO has to follow the NEWKEYS, it blocks all other messages so I couldn't delay it even if I wanted to without stalling the whole handshake process. >Does the draft need to be modified to make this explicit? It does need some explanatory text, I think. >EXT_INFO is sent by the party that sends it, immediately after that party >has >sent its own NEWKEYS. Doing otherwise would contradict the “without delay” >requirement. In that case it probably needs some security considerations text if it's sent before the successful completion of the crypto handshake has been confirmed. My guess is that putting the EXT_INFO inside the encrypted layer rather than in the client/server hello like SSL does is to protect it cryptographically, however sending EXT_INFO before you've got the other side's NEWKEYS means you could be sending it over a link where the crypto protection hasn't been successfully activated. >Does the draft need to be modified to clarify this? Yes, definitely, because I'd implemented it after both sending and receiving NEWKEYS, for the reason given above. >One extension that needs this exact placement is “delay-compression”. For >that to work, the client has a need to know whether compression should be >started at the exact point it receives SSH_MSG_USERAUTH_SUCCESS. But the >server may be reluctant to advertise its support for compression >beforehand. >Sending the second EXT_INFO at this time is therefore ideal for both >parties. >(If it was sent after SSH_MSG_USERAUTH_SUCCESS, there would be the exact >race >condition that “delay-compression” is trying to solve.) I think the draft should include some text like this as an explanatory note. Getting EXT_INFO as a response to USERAUTH isn't a crash-and-burn thing, but it just seems logically wrong to insert additional stuff in front of the answer to the question you've asked. So some explanatory text would be useful. >The word “shall” has a well-known meaning in English, and its use in this >context is defined in RFC 2119. If this word was not meant to be used, I >think RFC 2119 would not define it. The issue isn't that it's wrong, but a question of consistency, the rest of the draft uses MAY and SHOULD, having an alternative synonym used in one location makes it more difficult to read. >At this point, I can: > >- put it back in, just like it was; or >- make it an independent submission. I would put it back. Having to do an entire RFC to document a single boolean flag seems like incredible overkill. Peter. _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle ------=_NextPart_000_0096_01D2A39A.E3ECBE40 Content-Type: text/plain; format=flowed; name="draft-ietf-curdle-ssh-ext-info-03.txt"; reply-type=original Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-curdle-ssh-ext-info-03.txt" Internet-Draft D. Bider Updates: 4252, 4253, 4254 (if approved) Bitvise Limited Intended status: Standards Track March 23, 2017 Expires: September 23, 2017 Extension Negotiation in Secure Shell (SSH) draft-ietf-curdle-ssh-ext-info-03.txt Abstract This memo defines a mechanism for SSH clients and servers to exchange information about supported protocol extensions confidentially after completed key exchange. Status This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Bider [Page 1] =0C Internet-Draft Extension Negotiation in SSH March 2017 1. Overview and Rationale Secure Shell (SSH) is a common protocol for secure communication on the Internet. The original design of the SSH transport layer [RFC4253] lacks proper extension negotiation. Meanwhile, diverse implementations take steps to ensure that known message types contain no unrecognized information. This makes it difficult for implementations to signal capabilities and negotiate extensions without risking disconnection. This obstacle has been recognized in relationship with [SSH-RSA-SHA2], where the need arises for a client to discover signature algorithms a server accepts, to avoid authentication penalties and trial-and-error. 1.1. Requirements Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Extension Negotiation Mechanism 2.1. Signaling of Extension Negotiation in KEXINIT Applications implementing this mechanism MUST add to the field "kex_algorithms", in their KEXINIT packet sent for the first key exchange, one of the following indicator names: - When acting as server: "ext-info-s" - When acting as client: "ext-info-c" The indicator name is added without quotes, and MAY be added at any position in the name-list, subject to proper separation from other names as per name-list conventions. The names are added to the "kex_algorithms" field because this is one of two name-list fields in KEXINIT that do not have a separate copy for each data direction. 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. The inclusion of textual indicator names is intended to provide a clue for implementers to discover this mechanism. 2.2. Enabling Criteria If a client or server offers "ext-info-c" or "ext-info-s" respectively, it MUST be prepared to accept an SSH_MSG_EXT_INFO message from the peer. Bider [Page 2] =0C Internet-Draft Extension Negotiation in SSH March 2017 Thus a server only needs to send "ext-info-s" if it intends to process SSH_MSG_EXT_INFO from the client. If a server receives an "ext-info-c", it MAY send an SSH_MSG_EXT_INFO message, but is not required to do so. If an SSH_MSG_EXT_INFO message is sent, then it MUST be the first message after the initial SSH_MSG_NEWKEYS. Implementations MUST NOT send an incorrect indicator name for their role. Implementations MAY disconnect if the counter-party sends an incorrect indicator. If "ext-info-c" or "ext-info-s" ends up being negotiated as a key exchange method, the parties MUST disconnect. 2.3. SSH_MSG_EXT_INFO Message A party that received the "ext-info-c" or "ext-info-s" indicator MAY send the following message: byte SSH_MSG_EXT_INFO (value 7) uint32 nr-extensions repeat "nr-extensions" times: string extension-name string extension-value This message is sent immediately after SSH_MSG_NEWKEYS, without delay. This allows a client to pipeline an authentication request after its SSH_MSG_SERVICE_REQUEST, even when this needs extension information. 2.4. Server's Secondary SSH_MSG_EXT_INFO If the client sent "ext-info-c", the server MAY send, but is not obligated to send, an SSH_MSG_EXT_INFO message immediately before (*) SSH_MSG_USERAUTH_SUCCESS, as defined in [RFC4252]. The server MAY send this message whether or not it sent EXT_INFO after SSH_MSG_NEWKEYS. This allows a server to reveal support for additional extensions that it was unwilling to reveal to an unauthenticated client. If a server sends a subsequent SSH_MSG_EXT_INFO, this replaces any initial one, and both the client and the server re-evaluate extensions in effect. The server's last EXT_INFO is matched against the client's original. (*) The message MUST be sent at this point for the following reasons: if it was sent earlier, it would not allow the server to withhold information until the client has authenticated; if it was sent later, a client that needs information from the second EXT_INFO immediately after successful authentication would have no way of reliably knowing whether there will be a second EXT_INFO or not. Bider [Page 3] =0C Internet-Draft Extension Negotiation in SSH March 2017 2.5. Interpretation of Extension Names and Values Each extension is identified by its extension-name, and defines the conditions under which the extension is considered to be in effect. Applications MUST ignore unrecognized extension-names. In general, if an extension requires both the client and the server to include it in order for the extension to take effect, the relative position of the extension-name in each EXT_INFO message is irrelevant. Extension-value fields are interpreted as defined by their respective extension. An extension-value field MAY be empty if so permitted by the extension. Applications that do not implement or recognize a particular extension MUST ignore the associated extension-value field, regardless of its size or content. The cumulative size of an SSH_MSG_EXT_INFO message is limited only by the maximum packet length that an implementation may apply in accordance with [RFC4253]. Implementations MUST accept well-formed SSH_MSG_EXT_INFO messages up to the maximum packet length they accept. 3. Initially Defined Extensions 3.1. "server-sig-algs" This extension is sent with the following extension name and value: string "server-sig-algs" name-list signature-algorithms-accepted Note that the name-list type is a strict subset of the string type, and is thus permissible as an extension-value. This extension is sent by the server only, and contains a list of signature algorithms that the server is able to process as part of a "publickey" request. A client that wishes to proceed with public key authentication MAY wait for the server's SSH_MSG_EXT_INFO so it can send a "publickey" authentication request with an appropriate signature algorithm, rather than resorting to trial and error. Servers that implement public key authentication SHOULD implement this extension. If a server does not send this extension, a client MUST NOT make any assumptions about the server's signature algorithm support, and MAY proceed with authentication requests using trial and error. Bider [Page 4] =0C Internet-Draft Extension Negotiation in SSH March 2017 3.2. "delay-compression" This extension MAY be sent by both parties as follows: string "delay-compression" string: name-list compression_algorithms_client_to_server name-list compression_algorithms_server_to_client This extension allows the server and client to renegotiate compression algorithm support without having to conduct a key re-exchange, putting new algorithms into effect immediately upon successful authentication. This extension takes effect only if both parties send it. Name-lists MAY include any compression algorithm that could have been negotiated in SSH_MSG_KEXINIT, except algorithms that define their own delayed compression semantics. This means "zlib,none" is a valid algorithm list in this context; but "zlib@openssh.com" is not. If both parties send this extension, but the name-lists do not contain a common algorithm in either direction, the parties MUST disconnect in the same way as if negotiation failed as part of SSH_MSG_KEXINIT. If this extension takes effect, the renegotiated compression algorithm is activated for the very next SSH message after the trigger message: - Sent by the server, the trigger message is SSH_MSG_USERAUTH_SUCCESS. - Sent by the client, the trigger message is SSH_MSG_NEWCOMPRESS. If this extension takes effect, the client MUST send the following message shortly after receiving SSH_MSG_USERAUTH_SUCCESS: byte SSH_MSG_NEWCOMPRESS (value 8) The purpose of this message is to avoid a race condition where the server cannot reliably know whether a message sent by the client was sent before or after receiving the server's USERAUTH_SUCCESS. As with all extensions, the server MAY delay including this extension until its secondary SSH_MSG_EXT_INFO, sent before USERAUTH_SUCCESS. This allows the server to avoid advertising compression support until the client has been authenticated. If the parties re-negotiate compression using this extension in a session where compression is already enabled; and the re-negotiated algorithm is the same in one or both directions; then the internal compression state MUST be reset for each direction at the time the re-negotiated algorithm takes effect. Bider [Page 5] =0C Internet-Draft Extension Negotiation in SSH March 2017 3.2.1. Awkwardly Timed Key Re-Exchange A party that has signaled, or intends to signal, support for this extension in an SSH session, MUST NOT initiate key re-exchange in that session until either of the following occurs: - This extension was negotiated, and the party that's about to start key re-exchange already sent its trigger message for compression. - The party has sent (if server) or received (if client) the message SSH_MSG_USERAUTH_SUCCESS, and this extension was not negotiated. If a party violates this rule, the other party MAY disconnect. In general, parties SHOULD NOT start key re-exchange before successful user authentication, but MAY tolerate it if not using this extension. 3.2.2. Subsequent Re-Exchange In subsequent key re-exchanges that unambiguously begin after the compression trigger messages, the compression algorithms negotiated in re-exchange override the algorithms negotiated with this extension. 3.3. "no-flow-control" This extension is sent with the following extension name and value: string "no-flow-control" string choice of: "p" for preferred | "s" for supported To take effect, this extension MUST be: - Sent by both parties. - At least one party MUST have sent the value "p" (preferred). If this extension takes effect, the "initial window size" fields in SSH_MSG_CHANNEL_OPEN and SSH_MSG_CHANNEL_OPEN_CONFIRMATION, as defined in [RFC4254], become meaningless. The values of these fields MUST be ignored, and a channel behaves as if all window sizes are infinite. Neither side is required to send any SSH_MSG_CHANNEL_WINDOW_ADJUST messages, and if received, such messages MUST be ignored. This extension is intended, but not limited to, use by file transfer applications that are only going to use one channel, and for which the flow control provided by SSH is an impediment, rather than a feature. Implementations MUST refuse to open more than one simultaneous channel when this extension is in effect. Nevertheless, server implementations SHOULD support clients opening more than one non-simultaneous channel. Bider [Page 6] =0C Internet-Draft Extension Negotiation in SSH March 2017 3.4. "elevation" This extension MAY be sent by the client as follows: string "elevation" string choice of: "y" | "n" | "d" A client sends "y" to indicate its preference that the session should be elevated (as used by Windows); "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. If a client has included this extension, then after authentication, a server that supports this extension SHOULD indicate to the client whether elevation was done by sending the following global request: byte SSH_MSG_GLOBAL_REQUEST string "elevation" boolean want reply =3D false boolean elevation performed 4. IANA Considerations 4.1. Additions to existing tables IANA is requested to insert the following entries into the table Message Numbers under Secure Shell (SSH) Protocol Parameters [RFC4250]: Value Message ID Reference 7 SSH_MSG_EXT_INFO [this document] 8 SSH_MSG_NEWCOMPRESS [this document] IANA is requested to insert the following entries into the table Key Exchange Method Names: Method Name Reference Note ext-info-s [this document] Section 2.2 ext-info-c [this document] Section 2.2 4.2. New table: Extension Names Also under Secure Shell (SSH) Protocol Parameters, IANA is requested to create a new table, Extension Names, with initial content: Extension Name Reference Note server-sig-algs [this document] Section 3.1 delay-compression [this document] Section 3.2 no-flow-control [this document] Section 3.3 elevation [this document] Section 3.4 Bider [Page 7] =0C Internet-Draft Extension Negotiation in SSH March 2017 4.2.1. Future Assignments to Extension Names Names in the Extension Names table MUST follow the Conventions for Names defined in [RFC4250], Section 4.6.1. Requests for assignments of new non-local names in the Extension Names table (i.e. names not including the '@' character) MUST be done through the IETF CONSENSUS method, as described in [RFC5226]. 5. References 5.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, January 2006. [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006. [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006. [RFC4254] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Connection Protocol", RFC 4254, January 2006. [RFC5226] Narten, T. and Alvestrand, H., "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 5.2. Informative References [SSH-RSA-SHA2] Bider, D., "Use of RSA Keys with SHA-2 256 and 512 in Secure Shell (SSH)", draft-ietf-curdle-rsa-sha2-03.txt, February 2017, . Bider [Page 8] =0C Internet-Draft Extension Negotiation in SSH March 2017 Author's Address Denis Bider Bitvise Limited Suites 41/42, Victoria House 26 Main Street GI Phone: +506 8315 6519 EMail: ietf-ssh3@denisbider.com URI: https://www.bitvise.com/ Acknowledgments Thanks to Markus Friedl and Damien Miller for comments and initial implementation. Thanks to Peter Gutmann and Roumen Petrov for review and feedback. Bider [Page 9] =0C ------=_NextPart_000_0096_01D2A39A.E3ECBE40-- From nobody Thu Mar 23 07:37:32 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 6D0A0129766 for ; Thu, 23 Mar 2017 07:37:29 -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 SH3ps7Z2h7-C for ; Thu, 23 Mar 2017 07:37:28 -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 8AA681296ED for ; Thu, 23 Mar 2017 07:37:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id F19A1300254 for ; Thu, 23 Mar 2017 10:37:26 -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 9iKJOX0-UnVt for ; Thu, 23 Mar 2017 10:37:20 -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 2DDA4300483; Thu, 23 Mar 2017 10:37:20 -0400 (EDT) From: Russ Housley Message-Id: <13D0C5E1-714F-494D-9319-D68BAE5725F1@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_936D48F4-C7B5-42F2-9022-5A5A7EBAD02A" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 23 Mar 2017 10:37:22 -0400 In-Reply-To: Cc: Sean Turner , curdle To: Daniel Migault References: <48694963-30E4-4B88-BFEF-C68475DCD689@sn3rd.com> X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-pkix / Algorithm Identifier for prehash variant 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, 23 Mar 2017 14:37:29 -0000 --Apple-Mail=_936D48F4-C7B5-42F2-9022-5A5A7EBAD02A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 These OIDs are not part of an arc controlled by IANA. The party that = assigned them is free manage their arc as they wish. Russ > On Mar 22, 2017, at 7:12 PM, Daniel Migault = wrote: >=20 > Yes removing them from the draft. OIDs will be re-assigned by the = IANA. > Yours,=20 > Daniel=20 >=20 > On Wed, Mar 22, 2017 at 6:55 PM, Sean Turner > wrote: > You mean just dropping them from the draft right because once you=E2=80=99= ve assigned the # and put =E2=80=98em in a draft they=E2=80=99re pretty = much out there? >=20 > spt >=20 > > On Mar 22, 2017, at 18:13, Daniel Migault = > = wrote: > > > > Hi, > > > > As we are moving toward only using the non prehash variant. I would = like to have the WG opinion on whether or not we should keep the = following algorithm Identifiers: > > id-Ed25519ph OBJECT IDENTIFIER ::=3D { 1 3 101 114 = } > > id-Ed448ph OBJECT IDENTIFIER ::=3D { 1 3 101 115 = } > > > > > > Yours, > > Daniel --Apple-Mail=_936D48F4-C7B5-42F2-9022-5A5A7EBAD02A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 These OIDs are not part of an arc controlled by IANA. =  The party that assigned them is free manage their arc as they = wish.

Russ


On = Mar 22, 2017, at 7:12 PM, Daniel Migault <daniel.migault@ericsson.com> wrote:

Yes removing them from the = draft. OIDs will be re-assigned by the IANA.
Yours, =
Daniel

On Wed, = Mar 22, 2017 at 6:55 PM, Sean Turner <sean@sn3rd.com> wrote:
You mean just dropping them from the draft right = because once you=E2=80=99ve assigned the # and put =E2=80=98em in a = draft they=E2=80=99re pretty much out there?

spt

> On Mar 22, 2017, at 18:13, Daniel Migault <daniel.migault@ericsson.com> wrote:
>
> Hi,
>
> As we are moving toward only using the non prehash variant. I would = like to have the WG opinion on whether or not we should keep the = following algorithm Identifiers:
>    id-Ed25519ph OBJECT IDENTIFIER ::=3D { 1 3 101 = 114 }
>    id-Ed448ph   OBJECT IDENTIFIER ::=3D { 1 3 101 = 115 }
>
>
> Yours,
> = Daniel
= = --Apple-Mail=_936D48F4-C7B5-42F2-9022-5A5A7EBAD02A-- From nobody Thu Mar 23 07:56: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 9C3FD1293E0 for ; Thu, 23 Mar 2017 07:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 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, 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=docusign2com.onmicrosoft.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 XsIkHlD8ZqO2 for ; Thu, 23 Mar 2017 07:56:13 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0125.outbound.protection.outlook.com [104.47.40.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A33D126CE8 for ; Thu, 23 Mar 2017 07:56:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=DOCUSIGN2COM.onmicrosoft.com; s=selector1-docusign-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zpoXOtovxdPx5dkfmM99Qy3fx/yEFD2T5ndyYOSS/oA=; b=sVI/v9Fut5wGqaqB/uiBhGJmqLwJGklzmmwZa5u53lvZxEIX+GRyuXuHSshkl9TmFkJ0a8izzaGlAByol34RfD7cj8MM6mQBZqcntxC8DJXsz+eudK6As6qQpqesVY8VErbk3hjqTpMJJ+j8QXdi7IneT5Ig0SlasUZxGBW7n58= Received: from DM5PR04MB0828.namprd04.prod.outlook.com (10.172.188.142) by DM5PR04MB0826.namprd04.prod.outlook.com (10.172.188.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.17; Thu, 23 Mar 2017 14:56:10 +0000 Received: from DM5PR04MB0828.namprd04.prod.outlook.com ([10.172.188.142]) by DM5PR04MB0828.namprd04.prod.outlook.com ([10.172.188.142]) with mapi id 15.01.0961.026; Thu, 23 Mar 2017 14:56:10 +0000 From: Erwann Abalea To: Russ Housley CC: Daniel Migault , curdle , Sean Turner Thread-Topic: [Curdle] draft-ietf-curdle-pkix / Algorithm Identifier for prehash variant Thread-Index: AQHSo+WcP6Z1vIRZcUaQ6TWwhU+T9A== Date: Thu, 23 Mar 2017 14:56:10 +0000 Message-ID: <8577AB07-DD16-4A1E-B226-2D136F5E50E0@docusign.com> References: <48694963-30E4-4B88-BFEF-C68475DCD689@sn3rd.com> <13D0C5E1-714F-494D-9319-D68BAE5725F1@vigilsec.com> In-Reply-To: <13D0C5E1-714F-494D-9319-D68BAE5725F1@vigilsec.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: vigilsec.com; dkim=none (message not signed) header.d=none;vigilsec.com; dmarc=none action=none header.from=docusign.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [84.14.125.226] x-microsoft-exchange-diagnostics: 1; DM5PR04MB0826; 7:pc+okA362S9akPHWFqCUBMoA4CMs9pKE4PbwT72Z6jnES3lwWWYVHUH/mxu0mlC0hofgkSgDr5mu+yUnNsDJFLRZBGujkI9eG3dGeCg7/ACCaBXF4igqWdmq65mcThpgkdjlwyMOr7EHf+Lq6MMENvpTH7E1ifTcDeGnCHK5jtaFRSy0wWzCaW1cIrgbyC6yS+XiOuwHjvLuLpOPZeuw2PUGTTjNnQPOcth2ukUpBeyNvO4D6vvHJHKxfuZcb8DR/SoQZIuC0AhGTNcTDhnSpeFQYZ83FgljKlNF8upbxPeU7dyF3rcATfDCka9ArSa3COtNzrN+2+iN3CVAgDgnNQ== x-ms-office365-filtering-correlation-id: a74476ad-dfba-4c9a-a489-08d471fcbe8d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:DM5PR04MB0826; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123555025)(20161123564025)(20161123558025)(20161123560025)(20161123562025)(6072148); SRVR:DM5PR04MB0826; BCL:0; PCL:0; RULEID:; SRVR:DM5PR04MB0826; x-forefront-prvs: 0255DF69B9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39450400003)(39840400002)(39410400002)(377454003)(24454002)(110136004)(53546009)(6246003)(189998001)(38730400002)(4326008)(25786009)(86362001)(2900100001)(3660700001)(66066001)(82746002)(2906002)(36756003)(230783001)(122556002)(83716003)(93886004)(6486002)(3280700002)(76176999)(54356999)(229853002)(81166006)(6506006)(77096006)(6436002)(236005)(6916009)(53936002)(7736002)(33656002)(6116002)(102836003)(3846002)(2950100002)(54896002)(6306002)(5660300001)(8676002)(50986999)(54906002)(6512007)(99286003)(8936002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR04MB0826; H:DM5PR04MB0828.namprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_8577AB07DD164A1EB2262D136F5E50E0docusigncom_" MIME-Version: 1.0 X-OriginatorOrg: docusign.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2017 14:56:10.7892 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 237e701c-327f-4cad-a5a1-dda2412d89d9 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR04MB0826 Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-pkix / Algorithm Identifier for prehash variant 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, 23 Mar 2017 14:56:18 -0000 --_000_8577AB07DD164A1EB2262D136F5E50E0docusigncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIDEuMy4xMDEgYXJjIGlzIGNvbnRyb2xsZWQgYnkgU3ltYW50ZWMvVGhhd3RlLCBhbmQgdGhl eSBvZmZlcmVkIHRvIHByb3ZpZGUgMS4zLjEwMS4xMDArIGZvciBFZERTQSAoaXTigJlzIHVuY2xl YXIgaWYgdGhlIHJhbmdlIGlzIDEwMC0xMTUgb3IgMTAwLTEyNywgbmVlZHMgdG8gYmUgY2xhcmlm aWVkIGJ5IFJpY2sgQW5kcmV3cykuDQoNCkNvcmRpYWxlbWVudCwNCkVyd2FubiBBYmFsZWENCg0K TGUgMjMgbWFycyAyMDE3IMOgIDE1OjM3LCBSdXNzIEhvdXNsZXkgPGhvdXNsZXlAdmlnaWxzZWMu Y29tPG1haWx0bzpob3VzbGV5QHZpZ2lsc2VjLmNvbT4+IGEgw6ljcml0IDoNCg0KVGhlc2UgT0lE cyBhcmUgbm90IHBhcnQgb2YgYW4gYXJjIGNvbnRyb2xsZWQgYnkgSUFOQS4gIFRoZSBwYXJ0eSB0 aGF0IGFzc2lnbmVkIHRoZW0gaXMgZnJlZSBtYW5hZ2UgdGhlaXIgYXJjIGFzIHRoZXkgd2lzaC4N Cg0KUnVzcw0KDQoNCk9uIE1hciAyMiwgMjAxNywgYXQgNzoxMiBQTSwgRGFuaWVsIE1pZ2F1bHQg PGRhbmllbC5taWdhdWx0QGVyaWNzc29uLmNvbTxtYWlsdG86ZGFuaWVsLm1pZ2F1bHRAZXJpY3Nz b24uY29tPj4gd3JvdGU6DQoNClllcyByZW1vdmluZyB0aGVtIGZyb20gdGhlIGRyYWZ0LiBPSURz IHdpbGwgYmUgcmUtYXNzaWduZWQgYnkgdGhlIElBTkEuDQpZb3VycywNCkRhbmllbA0KDQpPbiBX ZWQsIE1hciAyMiwgMjAxNyBhdCA2OjU1IFBNLCBTZWFuIFR1cm5lciA8c2VhbkBzbjNyZC5jb208 bWFpbHRvOnNlYW5Ac24zcmQuY29tPj4gd3JvdGU6DQpZb3UgbWVhbiBqdXN0IGRyb3BwaW5nIHRo ZW0gZnJvbSB0aGUgZHJhZnQgcmlnaHQgYmVjYXVzZSBvbmNlIHlvdeKAmXZlIGFzc2lnbmVkIHRo ZSAjIGFuZCBwdXQg4oCYZW0gaW4gYSBkcmFmdCB0aGV54oCZcmUgcHJldHR5IG11Y2ggb3V0IHRo ZXJlPw0KDQpzcHQNCg0KPiBPbiBNYXIgMjIsIDIwMTcsIGF0IDE4OjEzLCBEYW5pZWwgTWlnYXVs dCA8ZGFuaWVsLm1pZ2F1bHRAZXJpY3Nzb24uY29tPG1haWx0bzpkYW5pZWwubWlnYXVsdEBlcmlj c3Nvbi5jb20+PiB3cm90ZToNCj4NCj4gSGksDQo+DQo+IEFzIHdlIGFyZSBtb3ZpbmcgdG93YXJk IG9ubHkgdXNpbmcgdGhlIG5vbiBwcmVoYXNoIHZhcmlhbnQuIEkgd291bGQgbGlrZSB0byBoYXZl IHRoZSBXRyBvcGluaW9uIG9uIHdoZXRoZXIgb3Igbm90IHdlIHNob3VsZCBrZWVwIHRoZSBmb2xs b3dpbmcgYWxnb3JpdGhtIElkZW50aWZpZXJzOg0KPiAgICBpZC1FZDI1NTE5cGggT0JKRUNUIElE RU5USUZJRVIgOjo9IHsgMSAzIDEwMSAxMTQ8dGVsOjElMjAzJTIwMTAxJTIwMTE0PiB9DQo+ICAg IGlkLUVkNDQ4cGggICBPQkpFQ1QgSURFTlRJRklFUiA6Oj0geyAxIDMgMTAxIDExNTx0ZWw6MSUy MDMlMjAxMDElMjAxMTU+IH0NCj4NCj4NCj4gWW91cnMsDQo+IERhbmllbA0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkN1cmRsZSBtYWlsaW5nIGxpc3QN CkN1cmRsZUBpZXRmLm9yZzxtYWlsdG86Q3VyZGxlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jdXJkbGUNCg0K --_000_8577AB07DD164A1EB2262D136F5E50E0docusigncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5UaGUgMS4z LjEwMSBhcmMgaXMgY29udHJvbGxlZCBieSBTeW1hbnRlYy9UaGF3dGUsIGFuZCB0aGV5IG9mZmVy ZWQgdG8gcHJvdmlkZSAxLjMuMTAxLjEwMCYjNDM7IGZvciBFZERTQSAoaXTigJlzIHVuY2xlYXIg aWYgdGhlIHJhbmdlIGlzIDEwMC0xMTUgb3IgMTAwLTEyNywgbmVlZHMgdG8gYmUgY2xhcmlmaWVk IGJ5IFJpY2sgQW5kcmV3cykuPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iIj5Db3JkaWFsZW1lbnQsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkVyd2FubiBB YmFsZWE8L2Rpdj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5MZSAyMyBtYXJzIDIwMTcgw6AgMTU6 MzcsIFJ1c3MgSG91c2xleSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhvdXNsZXlAdmlnaWxzZWMuY29t IiBjbGFzcz0iIj5ob3VzbGV5QHZpZ2lsc2VjLmNvbTwvYT4mZ3Q7IGEgw6ljcml0IDo8L2Rpdj4N CjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3Bh Y2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NClRo ZXNlIE9JRHMgYXJlIG5vdCBwYXJ0IG9mIGFuIGFyYyBjb250cm9sbGVkIGJ5IElBTkEuICZuYnNw O1RoZSBwYXJ0eSB0aGF0IGFzc2lnbmVkIHRoZW0gaXMgZnJlZSBtYW5hZ2UgdGhlaXIgYXJjIGFz IHRoZXkgd2lzaC4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPlJ1c3M8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0 eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gTWFyIDIyLCAyMDE3LCBhdCA3 OjEyIFBNLCBEYW5pZWwgTWlnYXVsdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRhbmllbC5taWdhdWx0 QGVyaWNzc29uLmNvbSIgY2xhc3M9IiI+ZGFuaWVsLm1pZ2F1bHRAZXJpY3Nzb24uY29tPC9hPiZn dDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgY2xhc3M9IiI+WWVzIHJlbW92aW5nIHRoZW0gZnJvbSB0aGUgZHJhZnQuIE9JRHMgd2ls bCBiZSByZS1hc3NpZ25lZCBieSB0aGUgSUFOQS48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCllvdXJz LCA8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCkRhbmllbCA8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9x dW90ZSI+T24gV2VkLCBNYXIgMjIsIDIwMTcgYXQgNjo1NSBQTSwgU2VhbiBUdXJuZXIgPHNwYW4g ZGlyPSJsdHIiIGNsYXNzPSIiPg0KJmx0OzxhIGhyZWY9Im1haWx0bzpzZWFuQHNuM3JkLmNvbSIg dGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPnNlYW5Ac24zcmQuY29tPC9hPiZndDs8L3NwYW4+IHdy b3RlOjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9 Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVm dDoxZXgiPg0KWW91IG1lYW4ganVzdCBkcm9wcGluZyB0aGVtIGZyb20gdGhlIGRyYWZ0IHJpZ2h0 IGJlY2F1c2Ugb25jZSB5b3XigJl2ZSBhc3NpZ25lZCB0aGUgIyBhbmQgcHV0IOKAmGVtIGluIGEg ZHJhZnQgdGhleeKAmXJlIHByZXR0eSBtdWNoIG91dCB0aGVyZT88YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQpzcHQ8YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i aDUiPjxiciBjbGFzcz0iIj4NCiZndDsgT24gTWFyIDIyLCAyMDE3LCBhdCAxODoxMywgRGFuaWVs IE1pZ2F1bHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkYW5pZWwubWlnYXVsdEBlcmljc3Nvbi5jb20i IGNsYXNzPSIiPmRhbmllbC5taWdhdWx0QGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxiciBj bGFzcz0iIj4NCiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7IEhpLDxiciBjbGFzcz0iIj4NCiZndDs8 YnIgY2xhc3M9IiI+DQomZ3Q7IEFzIHdlIGFyZSBtb3ZpbmcgdG93YXJkIG9ubHkgdXNpbmcgdGhl IG5vbiBwcmVoYXNoIHZhcmlhbnQuIEkgd291bGQgbGlrZSB0byBoYXZlIHRoZSBXRyBvcGluaW9u IG9uIHdoZXRoZXIgb3Igbm90IHdlIHNob3VsZCBrZWVwIHRoZSBmb2xsb3dpbmcgYWxnb3JpdGht IElkZW50aWZpZXJzOjxiciBjbGFzcz0iIj4NCiZndDsmbmJzcDsgJm5ic3A7IGlkLUVkMjU1MTlw aCBPQkpFQ1QgSURFTlRJRklFUiA6Oj0geyA8YSBocmVmPSJ0ZWw6MSUyMDMlMjAxMDElMjAxMTQi IHZhbHVlPSImIzQzOzEzMTAxMTE0IiBjbGFzcz0iIj4NCjEgMyAxMDEgMTE0PC9hPiB9PGJyIGNs YXNzPSIiPg0KJmd0OyZuYnNwOyAmbmJzcDsgaWQtRWQ0NDhwaCZuYnNwOyAmbmJzcDtPQkpFQ1Qg SURFTlRJRklFUiA6Oj0geyA8YSBocmVmPSJ0ZWw6MSUyMDMlMjAxMDElMjAxMTUiIHZhbHVlPSIm IzQzOzEzMTAxMTE1IiBjbGFzcz0iIj4NCjEgMyAxMDEgMTE1PC9hPiB9PGJyIGNsYXNzPSIiPg0K Jmd0OzxiciBjbGFzcz0iIj4NCiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7IFlvdXJzLDxiciBjbGFz cz0iIj4NCiZndDsgRGFuaWVsPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIi Pg0KQ3VyZGxlIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpDdXJk bGVAaWV0Zi5vcmciIGNsYXNzPSIiPkN1cmRsZUBpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2N1cmRsZTxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_8577AB07DD164A1EB2262D136F5E50E0docusigncom_-- From nobody Thu Mar 23 09:49:46 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 EF1B71298B7 for ; Thu, 23 Mar 2017 09:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 cQvdoiR7aWQl for ; Thu, 23 Mar 2017 09:49:43 -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 9D170129A14 for ; Thu, 23 Mar 2017 09:49:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id ED3AD3004AE for ; Thu, 23 Mar 2017 12:49:42 -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 kb6M3f6Ccf8z for ; Thu, 23 Mar 2017 12:49:41 -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 5E585300483; Thu, 23 Mar 2017 12:49:41 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Russ Housley In-Reply-To: <20170321233151.6B3F8ADF28@smtp.postman.i2p> Date: Thu, 23 Mar 2017 12:49:41 -0400 Cc: "curdle@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: <22B37E49-154A-4C39-B4F8-4D292C8A9615@vigilsec.com> References: <7d6cfe29-8d4c-436e-fe8a-0cbee915b29e@mail.i2p> <20170311061838.879BAADF28@smtp.postman.i2p> <2DD56D786E600F45AC6BDE7DA4E8A8C118BA5C93@eusaamb107.ericsson.se> <20170314174216.56419ADF21@smtp.postman.i2p> <20170321233151.6B3F8ADF28@smtp.postman.i2p> To: str4d X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Curdle] AlgorithmIdentifier parameters in draft-ietf-curdle-pkix-03 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, 23 Mar 2017 16:49:45 -0000 > How would the following language (or something to this effect) work as a > compromise? > > In this document we defined six new OIDs for identifying the > different curve/algorithm pairs. The curves being Curve25519 and > Curve448. The algorithms being ECDH, EdDSA in pure mode and EdDSA in > pre-hash mode. For all of the OIDs, the parameters MUST be absent. > Regardless of the defect in the original 1997 syntax, implementations > MUST NOT write out a parameters value of NULL, and MUST NOT accept a > parameters value of NULL, EXCEPT where doing so is unavoidable due to > legacy PKCS8 interpretation within the implementation language's > standard libraries (such as Java's Sun security provider before > version XX). EXCEPT is not defined in RFC 2119. How is your proposed language any different in reality than: This document specified object identifiers for using Curve25519 and Curve448 for key agreement and digital signature. Since none of these algorithm identifiers need parameters, the parameters MUST be absent. As a result of the defect in the AlgorithmIdentifier syntax published in 1997, some implementations produce a parameters value of NULL, even when the parameters ought to be absent. Conforming implementations MUST NOT produce a parameters value of NULL, but conforming implementations MAY accept a parameters value of NULL for interoperability. Russ From nobody Thu Mar 23 10:16:48 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 2E6AB129A63 for ; Thu, 23 Mar 2017 10:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSEGJvZo-XuC for ; Thu, 23 Mar 2017 10:16:45 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::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 EA185129B07 for ; Thu, 23 Mar 2017 10:16:39 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id o126so108511555pfb.3 for ; Thu, 23 Mar 2017 10:16:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HckgXSpcnQ/IRFuMHRR6uDx4Mp2dJJ9VPTS71u6cQGY=; b=N1p3UpGMyCq3Puw4MKEM2UUSUWt7IxVU6if8cYBftDDdnUmECfH70izgayMSUN3fjC 04BWw49+/n3N/xU/OWYISQRuX2Sasjg/cIUNT/cr/az8fQXYSdmMEJxeIji6OvLCaX60 +A0sPkItAXkkUBZlolUbExgKNOBgJaaOzyOoA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HckgXSpcnQ/IRFuMHRR6uDx4Mp2dJJ9VPTS71u6cQGY=; b=F+luzFAy73QZJYVIKQk2dHsuRiuo0SbhlI480AtcbjP4jtKspRY7ncwluCCT35upKn /15ye/YLLUrCxVQObfhGmNCkhpZYyyqT66OcXjLc0/5VHJTvSh3S/JCZM/y/4PRpN+tD GAP/QMSbDntRKjHiM5v591X4EuSqqxcC0paVXBYdIVQz0Y+5ah+ReHOBqdI0BW2HE//3 nI9dWUm6qe6IJnnCdEkqHjIHb5+EvBFwlY90qwbPNI62L+QeewqVGtDu/+OAyz8ttr9s SajJSm+5X63d163CPGMkHJdgjNFcaog58K5sQrAK2/8wPrgdyAQCeMZWmx3AN6qNLAMK h1+g== X-Gm-Message-State: AFeK/H0IB7MGfemZsOv6vL/8lnNDgdXQ9kQhLdR352QuM8diV+kBSOfxFvkQ63digPCKlQsGDjwSWVyGeLoji9ph X-Received: by 10.99.139.196 with SMTP id j187mr4164758pge.176.1490289399443; Thu, 23 Mar 2017 10:16:39 -0700 (PDT) MIME-Version: 1.0 References: <7d6cfe29-8d4c-436e-fe8a-0cbee915b29e@mail.i2p> <20170311061838.879BAADF28@smtp.postman.i2p> <2DD56D786E600F45AC6BDE7DA4E8A8C118BA5C93@eusaamb107.ericsson.se> <20170314174216.56419ADF21@smtp.postman.i2p> <20170321233151.6B3F8ADF28@smtp.postman.i2p> <22B37E49-154A-4C39-B4F8-4D292C8A9615@vigilsec.com> In-Reply-To: <22B37E49-154A-4C39-B4F8-4D292C8A9615@vigilsec.com> From: David Benjamin Date: Thu, 23 Mar 2017 17:16:27 +0000 Message-ID: To: Russ Housley , str4d Cc: "curdle@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c03e4e8448dbf054b690a4e Archived-At: Subject: Re: [Curdle] AlgorithmIdentifier parameters in draft-ietf-curdle-pkix-03 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, 23 Mar 2017 17:16:47 -0000 --94eb2c03e4e8448dbf054b690a4e Content-Type: text/plain; charset=UTF-8 On Thu, Mar 23, 2017 at 12:49 PM Russ Housley wrote: > > How would the following language (or something to this effect) work as a > > compromise? > > > > In this document we defined six new OIDs for identifying the > > different curve/algorithm pairs. The curves being Curve25519 and > > Curve448. The algorithms being ECDH, EdDSA in pure mode and EdDSA in > > pre-hash mode. For all of the OIDs, the parameters MUST be absent. > > Regardless of the defect in the original 1997 syntax, implementations > > MUST NOT write out a parameters value of NULL, and MUST NOT accept a > > parameters value of NULL, EXCEPT where doing so is unavoidable due to > > legacy PKCS8 interpretation within the implementation language's > > standard libraries (such as Java's Sun security provider before > > version XX). > > > EXCEPT is not defined in RFC 2119. > > How is your proposed language any different in reality than: > > This document specified object identifiers for using Curve25519 and > Curve448 for key agreement and digital signature. Since none of these > algorithm identifiers need parameters, the parameters MUST be absent. > As a result of the defect in the AlgorithmIdentifier syntax published > in 1997, some implementations produce a parameters value of NULL, even > when the parameters ought to be absent. Conforming implementations > MUST NOT produce a parameters value of NULL, but conforming > implementations MAY accept a parameters value of NULL for > interoperability. > I think that encourages normal implementations too much towards laxness, which will harm the ecosystem. I don't particularly care which encoding it is (with or without NULL), but there must be only one encoding. We've had enough trouble with id-rsaEncryption's ambiguity in BoringSSL that I do not think we would be willing implement a new scheme with two encodings. If MUST NOT on the parser is problematic, perhaps SHOULD NOT? That said, I do not follow what is wrong with MUST NOT. It sounds like this Java issue is purely a local thing, right? That is, you don't expect such malformed structures to escape into the ecosystem, but you need to be able to parse the structures back out? In that case, there's need to encourage any other implementation to be lax here. It's purely so that your parser gets the conforming checkbox? But the serializer is already violating the MUST NOT, so violate it in the parser too and add an explanatory comment next to the code. Or am I misunderstanding the situation? David --94eb2c03e4e8448dbf054b690a4e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 23= , 2017 at 12:49 PM Russ Housley <housley@vigilsec.com> wrote:
> compromise?
>
>=C2=A0 =C2=A0In this document we defined six new OIDs for identifying t= he
>=C2=A0 =C2=A0different curve/algorithm pairs.=C2=A0 The curves being Cu= rve25519 and
>=C2=A0 =C2=A0Curve448.=C2=A0 The algorithms being ECDH, EdDSA in pure m= ode and EdDSA in
>=C2=A0 =C2=A0pre-hash mode.=C2=A0 For all of the OIDs, the parameters M= UST be absent.
>=C2=A0 =C2=A0Regardless of the defect in the original 1997 syntax, impl= ementations
>=C2=A0 =C2=A0MUST NOT write out a parameters value of NULL, and MUST NO= T accept a
>=C2=A0 =C2=A0parameters value of NULL, EXCEPT where doing so is unavoid= able due to
>=C2=A0 =C2=A0legacy PKCS8 interpretation within the implementation lang= uage's
>=C2=A0 =C2=A0standard libraries (such as Java's Sun security provid= er before
>=C2=A0 =C2=A0version XX).


EXCEPT is not defined in RFC 2119.

How is your proposed language any different in reality than:

=C2=A0 This document specified object identifiers for using Curve25519 and<= br class=3D"gmail_msg"> =C2=A0 Curve448 for key agreement and digital signature.=C2=A0 Since none o= f these
=C2=A0 algorithm identifiers need parameters, the parameters MUST be absent= .
=C2=A0 As a result of the defect in the AlgorithmIdentifier syntax publishe= d
=C2=A0 in 1997, some implementations produce a parameters value of NULL, ev= en
=C2=A0 when the parameters ought to be absent.=C2=A0 Conforming implementat= ions
=C2=A0 MUST NOT produce a parameters value of NULL, but conforming
=C2=A0 implementations MAY accept a parameters value of NULL for
=C2=A0 interoperability.

I think that encourages normal implementations too much towards laxne= ss, which will harm the ecosystem. I don't particularly care which enco= ding it is (with or without NULL), but there must be only one encoding. We&= #39;ve had enough trouble with id-rsaEncryption's ambiguity in BoringSS= L that I do not think we would be willing implement a new scheme with two e= ncodings.

If MUST NOT on the parser is problematic= , perhaps SHOULD NOT? That said, I do not follow what is wrong with MUST NO= T. It sounds like this Java issue is purely a local thing, right? That is, = you don't expect such malformed structures to escape into the ecosystem= , but you need to be able to parse the structures back out? In that case, t= here's need to encourage any other implementation to be lax here. It= 9;s purely so that your parser gets the conforming checkbox? But the serial= izer is already violating the MUST NOT, so violate it in the parser too and= add an explanatory comment next to the code.

Or a= m I misunderstanding the situation?

David
--94eb2c03e4e8448dbf054b690a4e-- From nobody Fri Mar 24 03:27: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 164AD129680 for ; Fri, 24 Mar 2017 03:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.19 X-Spam-Level: X-Spam-Status: No, score=-4.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_SPF_PERMERROR=0.01] 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 FMxvbl8uK1jv for ; Fri, 24 Mar 2017 03:27:47 -0700 (PDT) Received: from mmextmx2.mcr.colo.comodoca.net (mmextmx2.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67245129664 for ; Fri, 24 Mar 2017 03:27:47 -0700 (PDT) Received: (qmail 21078 invoked by uid 1004); 24 Mar 2017 10:27:45 -0000 Received: from rmdccgwarp1.reyn.mcr.dc.comodo.net (HELO maileu.comodo.net) (10.1.72.82) by mmextmx2.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Fri, 24 Mar 2017 10:27:45 +0000 Received: from [192.168.0.58] ([192.168.0.58]) by maileu.comodo.net (IceWarp 11.4.5.0 DEB8 x64) with ASMTP (SSL) id 201703241027436520; Fri, 24 Mar 2017 10:27:43 +0000 To: Daniel Migault , Sean Turner References: <48694963-30E4-4B88-BFEF-C68475DCD689@sn3rd.com> Cc: curdle From: Rob Stradling Message-ID: Date: Fri, 24 Mar 2017 10:27:43 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-pkix / Algorithm Identifier for prehash variant 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, 24 Mar 2017 10:27:52 -0000 On 22/03/17 23:12, Daniel Migault wrote: > OIDs will be re-assigned by the IANA. Please don't do that. The 1.3.101 arc was chosen to avoid OID bloat. Symantec/thawte generously donated a range of OIDs under this arc to be used for identifying these algorithms. Reassigning the OIDs under a different arc is not necessary. > Yours, > Daniel > > On Wed, Mar 22, 2017 at 6:55 PM, Sean Turner wrote: > > You mean just dropping them from the draft right because once you’ve > assigned the # and put ‘em in a draft they’re pretty much out there? > > spt > > > On Mar 22, 2017, at 18:13, Daniel Migault > > > wrote: > > > > Hi, > > > > As we are moving toward only using the non prehash variant. I > would like to have the WG opinion on whether or not we should keep > the following algorithm Identifiers: > > id-Ed25519ph OBJECT IDENTIFIER ::= { 1 3 101 114 > } > > id-Ed448ph OBJECT IDENTIFIER ::= { 1 3 101 115 > } > > > > > > Yours, > > Daniel -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Fri Mar 24 03:30: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 7891912741D for ; Fri, 24 Mar 2017 03:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=briansmith-org.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 OxuEfeGCt3c7 for ; Fri, 24 Mar 2017 03:30:44 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::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 74858127333 for ; Fri, 24 Mar 2017 03:30:44 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id 190so6897584itm.0 for ; Fri, 24 Mar 2017 03:30:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EYFv+BthocadxhHQZ15BBhXE2wzfmGtBxg8rHLamEko=; b=xHUs+op3oGTUXnVC6u3OThOay7DQbGlCFlk4c9bhYrAYtM8Fnv1eXzqogMoR8Q867I M3Oxb3tkbuXPfCiO5WnLn2tFzwAwG7HI65Bja83a9NX90w+bqIf0ibqGm/hAazoG+zse sso0MFDAlrJGczvBzpxWn9tdm1WSCkRchZLI4EQDeF19HaZXWdmAeVC0r+faC+BeDVer hCj/w4xTeW1vyy1dZNYPLpU0sedlRLVBj0PoQ/l81VD1w6g+JjzZIZvB7SSvWN7s902n dOtue0ANNTE4HPHqWO9SAM9neT6ZQsJZVZZ3jyvDzEngLyjMGIE9G2AKVIAwO6e3EKSz ARKg== 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=EYFv+BthocadxhHQZ15BBhXE2wzfmGtBxg8rHLamEko=; b=S6EXCC/nJ35OOX+69qSoRNhVCBkQ/52MeeZhCAHEURy47h7AviWHjqEG7ic134pkWi 45tqWpEli+VczjW+K6buh4eI6wGiaORvjZ/yAffoLzYYbjp2+5b0dK6AczctU1A2MDJt voG7+dGhHNz4sJww3NqgEMl1cZ1kwren5G5kowrTfw5H8jVAJppwO2ygKjbJgBCxHbxK Wd86cBRHZzbFN/jR6qazia0b8YnyPSPdz8wKRNWl+V3695nJ6ysD6WawF6exynemtj7u m69URoSqkaiHKPLyiC1zVBXkE5cNLtCCqvUFEipoWY/7hUvzSFq3SLOs3I6W5Zk2aKbd 7UHA== X-Gm-Message-State: AFeK/H0E8kwSWSO+PBkJVPAYf6ees1Kh2vm+mtj771I+Ioh+fc6I8Cri5vusyZrYKo8RTK4RbSOhqiOzCtSnKA== X-Received: by 10.36.131.2 with SMTP id d2mr2183590ite.117.1490351443812; Fri, 24 Mar 2017 03:30:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.107.142 with HTTP; Fri, 24 Mar 2017 03:30:43 -0700 (PDT) In-Reply-To: References: From: Brian Smith Date: Fri, 24 Mar 2017 00:30:43 -1000 Message-ID: To: Daniel Migault Cc: curdle Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-pkix / Algorithm Identifier for prehash variant 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, 24 Mar 2017 10:30:46 -0000 Daniel Migault wrote: > As we are moving toward only using the non prehash variant. I would like to > have the WG opinion on whether or not we should keep the following algorithm > Identifiers: > > id-Ed25519ph OBJECT IDENTIFIER ::= { 1 3 101 114 } > id-Ed448ph OBJECT IDENTIFIER ::= { 1 3 101 115 } Please remove them. Leaving them in would cause confusion. Cheers, Brian -- https://briansmith.org/ From nobody Fri Mar 24 13:51:46 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 5EC5A129510 for ; Fri, 24 Mar 2017 13:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, 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 aFsqmPY2PmuX for ; Fri, 24 Mar 2017 13:51:43 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::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 CBBC4129882 for ; Fri, 24 Mar 2017 13:51:43 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id w124so7820770itb.0 for ; Fri, 24 Mar 2017 13:51:43 -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=JCLgvTC7dVTQLVIchrJuzycVy9rTOGSeKkuAcI3amdM=; b=IKapwhg4hosiCnGqtWFrJSvhY11mRAYAHhgM0UeQS4F8N5sK7qDicf9z60zYmQ3SbJ seL5tUAr6CjrOHwika9C8nMUoaYIGn1MTyEqOA0r/1b72i7Rmf+85f9JBDCMVZOVffHT 7Iuzhqw7HXsgZ1sauFcXqBlibAVa82gZDkhSdiTQ21HbDK4dGkb0aTXfnc8H5CHTJxLu ZMz64wnMrovsp+AnN8m8tSb/d8T9Xd96bd7NPMPW3YRqUsI7sAYouDLTp48kKrjt1tmb /fh1X3qgDH3vb4B+PKA7al+NUWCyQjMekWLEykq0qMYsH1FfuQ/ZvqFKiMJh006DSdRA QyBQ== 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=JCLgvTC7dVTQLVIchrJuzycVy9rTOGSeKkuAcI3amdM=; b=QWMExOU4eh5fAFI4pYmDNABRYCTMKtFm/7eu/d641Zx1p+/bn9wQQeNZyGp9TS6rjI Je/UgUmrJhRSE7z6BGm02IqQO8vFzwBOlO7Zd6/tHbVeZQAZcuQUwk6Azmka6sc6kbRH /fRCODsyPxeZkiNYEyerymI/2mgAzTUokRKNWqhkRZWtYSJ5GqFau6HsrsA4jSsPssWZ VXAL7qXsZr5RoP9Jcuz7NUYTelvnoFDpiE7FjsxT5HO52TzOG+J3IaU9MymxH0amjwN5 rz2LVPPI24e6hu3u9qERabQVs+CTe2Mq8v7pUY/Jya5lSIwUxhLY79aVvhAnFaZVCpPL 0/cQ== X-Gm-Message-State: AFeK/H1bO/SX5IfXIUGxPFWfpJuuigllc/a72ZNzidx75zLFxrzkg7VzmdbZpl9a5YZwoopepEyIKi6i4uW6Rg== X-Received: by 10.107.50.11 with SMTP id y11mr10541573ioy.10.1490388703064; Fri, 24 Mar 2017 13:51:43 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.35.213 with HTTP; Fri, 24 Mar 2017 13:51:42 -0700 (PDT) From: Daniel Migault Date: Fri, 24 Mar 2017 16:51:42 -0400 X-Google-Sender-Auth: hYyVTjXScYFniCuIAtxgm7zP2Gk Message-ID: To: curdle Content-Type: multipart/alternative; boundary=001a11447c2e393a0f054b802958 Archived-At: Subject: [Curdle] Request for minute takers / jabber scribes 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, 24 Mar 2017 20:51:45 -0000 --001a11447c2e393a0f054b802958 Content-Type: text/plain; charset=UTF-8 Hi, We are looking for a minute taker and a Jabber scribe. Please volunteer! Yours, Rich and Daniel --001a11447c2e393a0f054b802958 Content-Type: text/html; charset=UTF-8
Hi,

We are looking for a minute taker and a Jabber scribe. Please volunteer!

Yours,
Rich and Daniel


--001a11447c2e393a0f054b802958-- From nobody Sat Mar 25 03:02: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 D2D6D124BE8 for ; Sat, 25 Mar 2017 03:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dq0pTAwXfXBU for ; Sat, 25 Mar 2017 03:02:43 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E576124281 for ; Sat, 25 Mar 2017 03:02:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1490436163; x=1521972163; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=b0F4i/tQYtgb4tfCPPs4Kr4l51EGMZwXAa7TE1fH0Tg=; b=eyCP5qqs36uax7TkosBQGahCE7gi0EBrGXSgjkrOFVEZoScy3md3gfBE JSKUfGWZOybQke5QHW293LpGlunwH0XQ5xrk92ex49ZD3DGThLN9VV4Bt boFzgaC++JrR9214erwRVQA0vedghy5RNvCq4vjGZ/p86zbSO6mHF/44g r3f+Pm58XDtaaPjIK4xVmNcW8XWFCAxxv/1XIVHSH6ncPo1+tU0AHqhRq 4DLIFdGgJDeEiXmaAKMxzPvgyW6KapQakxWH8Ker6LIs6n123C/H9UdUc u0M1I/pgNC6rL+DLxZvz5lTrp3RIajCIt0Hv5F1ybpWt1I1nGz59Phm3A g==; X-IronPort-AV: E=Sophos;i="5.36,219,1486378800"; d="scan'208";a="145350603" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.2 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-a.UoA.auckland.ac.nz) ([10.6.3.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 25 Mar 2017 23:02:41 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-a.UoA.auckland.ac.nz (10.6.3.2) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 25 Mar 2017 23:02:28 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Sat, 25 Mar 2017 23:02:28 +1300 From: Peter Gutmann To: "denis bider (Bitvise)" , Daniel Migault , curdle Thread-Topic: [Curdle] Comments on draft-ietf-curdle-ssh-ext-info Thread-Index: AQHSn+vj75AP59wDbUy5ryRiOFPQYKGb4DhQgAWgX4CAA91JyQ== Date: Sat, 25 Mar 2017 10:02:27 +0000 Message-ID: <1490436136828.60577@cs.auckland.ac.nz> References: <2DD56D786E600F45AC6BDE7DA4E8A8C118BA5A70@eusaamb107.ericsson.se> <1489827654266.43895@cs.auckland.ac.nz>, <50977E6A3D174856B8DAF264C3CB81E8@Khan> <1489914378158.63423@cs.auckland.ac.nz>, <74B4C5B2AFD644748A0E1B0957A22C96@Khan> In-Reply-To: <74B4C5B2AFD644748A0E1B0957A22C96@Khan> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Curdle] Comments on draft-ietf-curdle-ssh-ext-info 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, 25 Mar 2017 10:02:46 -0000 denis bider (Bitvise) writes:=0A= =0A= >I'm not sure that I see the threat here, or how the described behavior wou= ld=0A= >resolve it.=0A= =0A= I was thinking of it in terms of SSL's Change Cipherspec, the same as SSH's= =0A= Newkeys, where there's all sorts of subtle problems if you send data before= =0A= getting the other side's CCS to confirm that both sides are using the same= =0A= crypto parameters. I'd always assumed that SSH's use of the redudant=0A= SSH_MSG_SERVICE_REQUEST followed by a SSH_MSG_USERAUTH_REQUEST was that you= =0A= checked that the SSH_MSG_SERVICE_REQUEST succeeded, in other words that bot= h=0A= sides had scuccessfully agreed on the same crypto parameters, before sendin= g=0A= sensitive data in the SSH_MSG_USERAUTH_REQUEST. So the point of the=0A= SSH_MSG_SERVICE_REQUEST wasn't so much getting back the "yeah, sure, whatev= er"=0A= response from the server, it was being able to verify that you could decryp= t=0A= and MAC the response you got.=0A= =0A= >2. Send SERVICE_REQUEST, immediately followed by a USERAUTH message.=0A= >=0A= >This can all be sent potentially in the same transmission as the client's= =0A= >NEWKEYS. =0A= =0A= Ugh. So there are implementations that will send a NEWKEYS + SERVICE_REQUE= ST=0A= + USERAUTH all in one block without having any idea wheteher the crypto=0A= handshake process has succeeded?=0A= =0A= >But I don't see what this would achieve, since NEWKEYS is still unencrypte= d.=0A= >As-is, the server doesn't send an encrypted piece of information until it'= s=0A= >replying to SERVICE_ACCEPT.=0A= =0A= See above, I was using the SERVICE_REQUEST + SERVICE_ACCEPT to verify that= =0A= client and server are on the same page cryptographically.=0A= =0A= >When re-adding "no-flow-control", I realized that the original definition = is=0A= >deficient, and allows no room for implementations that support this=0A= >extension, but still prefer not to use it.=0A= >=0A= >Ours would be an implementation like that. If this needs two implementatio= ns=0A= >to be added, I will implement it to make life easier for implementers of= =0A= >simpler SSH software, but I would prefer not to use it.=0A= >=0A= >I have therefore changed the definition as follows:=0A= >=0A= > string "no-flow-control"=0A= > string choice of: "p" for preferred | "s" for supported=0A= >=0A= >To take effect, this extension MUST be:=0A= >=0A= >- Sent by both parties.=0A= >- At least one party MUST have sent the value "p" (preferred).=0A= =0A= That seems a bit wierd... the fact that a client or server is sending no-fl= ow-=0A= control already says "supported". So you really just need at least one sid= e=0A= to set a boolean flag saying "yes, I really want this". In other words no-= =0A= flow-control + boolean =3D false says the option is available, and boolean = =3D=0A= true says you must enable the option.=0A= =0A= Peter.= From nobody Sat Mar 25 12:52:48 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 06DE3127A97 for ; Sat, 25 Mar 2017 12:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.562 X-Spam-Level: X-Spam-Status: No, score=-1.562 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=denisbider.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 qa2M3Ru1HjJu for ; Sat, 25 Mar 2017 12:52:46 -0700 (PDT) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F379812773A for ; Sat, 25 Mar 2017 12:52:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=denisbider.com; s=mail; h=from:subject:date:message-id:to:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=mUsi1okLDpitQoAsJeMi1csIDNPtSWEO4NVqcRbGK8g=; b=ES7zsAbhaZBovmxVacqoZAwPDhHUeUdw3KptwHNpT8FZ6rseJABhJEC0iQMlGsUmya7zMER60t1D9 m0cgN6h+G2WmwJ7QkpwOemlDtAxVCcbUEEuIwTnJHSVCLvw/sLmoYZX8DB6sOhJMbTq/jYXjhs1QLq j0bWgEvF9+KR1iCcCfdFJYvPcKrw1xEfIcewtqTuRRs4v8q3OT/HgZqOydRPNQwFK4GFki1Np/kJpE haIgIBXOT9GcUD12I/hX4E9Zxg3pu8TKlRE1wVtMH6MbFH22LxkosS2kMusTwQVeHkaUQS9wDXeOXU cjbKlpgqAxpMvn9ZWyeqd/wGBEOoM1A== X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com with ESMTPSA (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)); Sat, 25 Mar 2017 19:52:17 +0000 Message-ID: <76BA84F1D47F476A8DB5C8CC42AA1B57@Khan> From: "denis bider \(Bitvise\)" To: "Peter Gutmann" , "Daniel Migault" , "curdle" References: <2DD56D786E600F45AC6BDE7DA4E8A8C118BA5A70@eusaamb107.ericsson.se> <1489827654266.43895@cs.auckland.ac.nz>, <50977E6A3D174856B8DAF264C3CB81E8@Khan> <1489914378158.63423@cs.auckland.ac.nz>, <74B4C5B2AFD644748A0E1B0957A22C96@Khan> <1490436136828.60577@cs.auckland.ac.nz> In-Reply-To: <1490436136828.60577@cs.auckland.ac.nz> Date: Sat, 25 Mar 2017 13:52:43 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [Curdle] Comments on draft-ietf-curdle-ssh-ext-info 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, 25 Mar 2017 19:52:47 -0000 Peter: > I was thinking of it in terms of SSL's Change Cipherspec, > the same as SSH's Newkeys, where there's all sorts of > subtle problems if you send data before getting the other > side's CCS to confirm that both sides are using the same > crypto parameters. Can you point out some of these subtle problems that could occur in this regard in SSH? > So the point of the SSH_MSG_SERVICE_REQUEST wasn't so much > getting back the "yeah, sure, whatever" response from the > server, it was being able to verify that you could decrypt > and MAC the response you got. If that was a primary purpose, rather than a side effect, I imagine there would be an SSH_MSG_NEWKEYS_VERIFY, which would be encrypted with the new crypto parameters. This could be sent immediately after SSH_MSG_NEWKEYS, which is the last message that uses old parameters. But yes, it's possible this is a desired side effect. In this case, if the server sends EXT_INFO immediately after NEWKEYS, and client wants to wait for a successful encrypted packet before queueing up an authentication request; this lets the client queue up the authentication request faster, because it doesn't have to wait for SERVICE_ACCEPT. Instead, the server's EXT_INFO already serves this role. The server's EXT_INFO doesn't contain confidential information (client is not authenticated), so there is no problem there. This leaves the situation that the client may be sending its own EXT_INFO after NEWKEYS. Perhaps an extension will be defined where the client would send info here it doesn't want to make public. (Currently, I don't know of one.) Under the assumption that such an extension were defined, can you point out at least one way that sending this info right after NEWKEYS can help an attacker? > > 2. Send SERVICE_REQUEST, immediately followed by a USERAUTH > > message. This can all be sent potentially in the same > > transmission as the client's NEWKEYS. > > Ugh. So there are implementations that will send a NEWKEYS + > SERVICE_REQUEST + USERAUTH all in one block without having > any idea wheteher the crypto handshake process has succeeded? It is possible. However, I'm not aware that an implementation actually does this. Ours waits for SERVICE_ACCEPT. I checked three others; they wait too. > > string "no-flow-control" > > string choice of: "p" for preferred | "s" for supported > > So you really just need at least one side to set a boolean > flag saying "yes, I really want this". In other words > no-flow-control + boolean = false says the option is > available, and boolean = true says you must enable the option. Yes. But the extension value field is generically a string (it must be same type for all extensions, so unsupported extensions can be decoded and ignored). "p" and "s" are therefore fitting ways to express this boolean. This week, I implemented "no-flow-control" in our software (in the manner recently defined - using "p" to indicate preferred, and "s" for supported). It works, but I point out that testing indicates zero performance benefit between our SSH Client and Server. In other words, regular SSH flow control has no handbrake effect if it's done right. The main advantages I see with this extension are: - In 10 years: it could become widely supported, and new simpler SSH software that only needs one channel can avoid complexity, and never implement SSH flow control. - Right now: authors who are having trouble with their window adjusting can sidestep that by implementing "no-flow-control" in addition. Properly implemented flow control is superior. However, this extension is a nod to that not everyone will be using an SSH library that does this right, and "no-flow-control" is a better option if your needs are simple, and you don't have a few years to get this right. denis ----- Original Message ----- From: Peter Gutmann Sent: Saturday, March 25, 2017 04:02 To: denis bider (Bitvise) ; Daniel Migault ; curdle Subject: Re: [Curdle] Comments on draft-ietf-curdle-ssh-ext-info denis bider (Bitvise) writes: >I'm not sure that I see the threat here, or how the described behavior >would >resolve it. I was thinking of it in terms of SSL's Change Cipherspec, the same as SSH's Newkeys, where there's all sorts of subtle problems if you send data before getting the other side's CCS to confirm that both sides are using the same crypto parameters. I'd always assumed that SSH's use of the redudant SSH_MSG_SERVICE_REQUEST followed by a SSH_MSG_USERAUTH_REQUEST was that you checked that the SSH_MSG_SERVICE_REQUEST succeeded, in other words that both sides had scuccessfully agreed on the same crypto parameters, before sending sensitive data in the SSH_MSG_USERAUTH_REQUEST. So the point of the SSH_MSG_SERVICE_REQUEST wasn't so much getting back the "yeah, sure, whatever" response from the server, it was being able to verify that you could decrypt and MAC the response you got. >2. Send SERVICE_REQUEST, immediately followed by a USERAUTH message. > >This can all be sent potentially in the same transmission as the client's >NEWKEYS. Ugh. So there are implementations that will send a NEWKEYS + SERVICE_REQUEST + USERAUTH all in one block without having any idea wheteher the crypto handshake process has succeeded? >But I don't see what this would achieve, since NEWKEYS is still >unencrypted. >As-is, the server doesn't send an encrypted piece of information until it's >replying to SERVICE_ACCEPT. See above, I was using the SERVICE_REQUEST + SERVICE_ACCEPT to verify that client and server are on the same page cryptographically. >When re-adding "no-flow-control", I realized that the original definition >is >deficient, and allows no room for implementations that support this >extension, but still prefer not to use it. > >Ours would be an implementation like that. If this needs two >implementations >to be added, I will implement it to make life easier for implementers of >simpler SSH software, but I would prefer not to use it. > >I have therefore changed the definition as follows: > > string "no-flow-control" > string choice of: "p" for preferred | "s" for supported > >To take effect, this extension MUST be: > >- Sent by both parties. >- At least one party MUST have sent the value "p" (preferred). That seems a bit wierd... the fact that a client or server is sending no-flow- control already says "supported". So you really just need at least one side to set a boolean flag saying "yes, I really want this". In other words no- flow-control + boolean = false says the option is available, and boolean = true says you must enable the option. Peter. From nobody Sat Mar 25 16:25:04 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 4EC73128990 for ; Sat, 25 Mar 2017 16:25:03 -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=[AC_BR_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, 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 0LdJdpav8Y-V for ; Sat, 25 Mar 2017 16:24:58 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::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 93BB512894E for ; Sat, 25 Mar 2017 16:24:58 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id y18so41090156itc.0 for ; Sat, 25 Mar 2017 16:24:58 -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=tYNC/3ybaG9QzEu8yaa7Kl4b8zE1cRdAMER3IfFUHC8=; b=Zfs0VHusMmnL3wtYSpC5QHQjkfnEDjDVQ4arlNHNtQ9IbiJNcrKo0uvqFsRTVZ+r51 wV/KR5ea0PYO5KSXQOWJCiXq91IqeAHbbvBZbQpqIvl9n4nttzCXjoIZxuqg5GWiLw7O +SE3FNB+0+c2XUGuz21g2F5VUaLBKzaHuregVTeLSHIov4OaMSpm5PpEZU6DpKTIyZti TsSI6/7OwYGk9Kn/leqJpjgGK53BMa65O4r0GWHgodMFA6SBTM89GgERdL1KImyQFQLg y7bgDis540QW37hMuWEMrsDMSeumWN5ck4wYZ5iFkP99p2tuHDADYLwurhdyqPbHafsW QpDQ== 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=tYNC/3ybaG9QzEu8yaa7Kl4b8zE1cRdAMER3IfFUHC8=; b=swGeT68s1MjyT/5Un/AAmVqWPuCSdYhK+ZX+MTESp4y1HBcjaruAMohHOT8n7HebRQ CclajX0Zrtt5W8WCiCxI/3TGospB2bKCWckDZodmVPrnjX2LIuC/S2CTIyb3mxirXWa2 d5N/GM5FmF+WkWKY9fyXn/6ekqrkUB2b6AqQKsKknCEPWD7vLJE6czMoUK7bAb34CMj0 qa2h89hpZpiqjSNpaGxJ8TPFeBXqVTYjZpmgdDbulbPTM/PBEJgH6+xONQw6wCGsff7n xOSfnxcLLHsCSCM0h9lGCo9BpjB+FVdNlGGBDxlj5OyJ3FJBBEkz1/JtJ05se2VfJhLE FmKA== X-Gm-Message-State: AFeK/H0spHxK7qkgcXw02G1Iu4rnjDSuMq1MCzA8XG+E+rDxe27yzin3PdXSvebMJV5+OEZrUmhNNpm0L95bzA== X-Received: by 10.107.174.27 with SMTP id x27mr14352865ioe.35.1490484297312; Sat, 25 Mar 2017 16:24:57 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.35.213 with HTTP; Sat, 25 Mar 2017 16:24:56 -0700 (PDT) From: Daniel Migault Date: Sat, 25 Mar 2017 19:24:56 -0400 X-Google-Sender-Auth: GPQC2WPDCRMNLzmwzfVnZIL2wrw Message-ID: To: curdle Content-Type: multipart/alternative; boundary=001a11449ffc15aff8054b966bbf Archived-At: Subject: [Curdle] Comments on draft-ietf-curdle-ssh-ext-info-03 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, 25 Mar 2017 23:25:03 -0000 --001a11449ffc15aff8054b966bbf Content-Type: text/plain; charset=UTF-8 Hi, Thank you for moving that draft forward. Please see some comments on the draft. Yours, Daniel Internet-Draft D. Bider Updates: 4252, 4253, 4254 (if approved) Bitvise Limited Intended status: Standards Track March 23, 2017 Expires: September 23, 2017 Extension Negotiation in Secure Shell (SSH) draft-ietf-curdle-ssh-ext-info-03.txt Abstract This memo defines a mechanism for SSH clients and servers to exchange information about supported protocol extensions confidentially after completed key exchange. Bider [Page 1] Internet-Draft Extension Negotiation in SSH March 2017 1. Overview and Rationale Secure Shell (SSH) is a common protocol for secure communication on the Internet. The original design of the SSH transport layer [RFC4253] lacks proper extension negotiation. Meanwhile, diverse implementations take steps to ensure that known message types contain no unrecognized information. This makes it difficult for implementations to signal capabilities and negotiate extensions without risking disconnection. This obstacle has been recognized in relationship with [SSH-RSA-SHA2], where the need arises for a client to discover signature algorithms a server accepts, to avoid authentication penalties and trial-and-error. 1.1. Requirements Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Extension Negotiation Mechanism 2.1. Signaling of Extension Negotiation in KEXINIT Applications implementing this mechanism MUST add to the field "kex_algorithms", in their KEXINIT packet sent for the first key exchange, one of the following indicator names: - When acting as server: "ext-info-s" - When acting as client: "ext-info-c" The indicator name is added without quotes, and MAY be added at any position in the name-list, subject to proper separation from other names as per name-list conventions. The names are added to the "kex_algorithms" field because this is one of two name-list fields in KEXINIT that do not have a separate copy for each data direction. 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. The inclusion of textual indicator names is intended to provide a clue for implementers to discover this mechanism. 2.2. Enabling Criteria If a client or server offers "ext-info-c" or "ext-info-s" respectively, it MUST be prepared to accept an SSH_MSG_EXT_INFO message from the peer. Bider [Page 2] Internet-Draft Extension Negotiation in SSH March 2017 Thus a server only needs to send "ext-info-s" if it intends to process SSH_MSG_EXT_INFO from the client. If a server receives an "ext-info-c", it MAY send an SSH_MSG_EXT_INFO message, but is not required to do so. If an SSH_MSG_EXT_INFO message is sent, then it MUST be the first message after the initial SSH_MSG_NEWKEYS. Implementations MUST NOT send an incorrect indicator name for their role. Implementations MAY disconnect if the counter-party sends an incorrect indicator. If "ext-info-c" or "ext-info-s" ends up being negotiated as a key exchange method, the parties MUST disconnect. MGLT: Shouldn't we have "Implementations MUST disconnect" ? At least we should maybe state that it MUST ignore the indication. 2.3. SSH_MSG_EXT_INFO Message A party that received the "ext-info-c" or "ext-info-s" indicator MAY send the following message: byte SSH_MSG_EXT_INFO (value 7) uint32 nr-extensions repeat "nr-extensions" times: string extension-name string extension-value MGLT: maybe the different terms/parameters could be defined. I am assuming that an extenssion-name has a single extension-value. In other words, extension-name is repeated. This message is sent immediately after SSH_MSG_NEWKEYS, without delay. This allows a client to pipeline an authentication request after its SSH_MSG_SERVICE_REQUEST, even when this needs extension information. 2.4. Server's Secondary SSH_MSG_EXT_INFO If the client sent "ext-info-c", the server MAY send, but is not obligated to send, an SSH_MSG_EXT_INFO message immediately before (*) SSH_MSG_USERAUTH_SUCCESS, as defined in [RFC4252]. The server MAY send this message whether or not it sent EXT_INFO after SSH_MSG_NEWKEYS. MGLT: Maybe that would be clearer to split the sentence in two parts so the "MAY" does not confuse the reader. OLD: If the client sent "ext-info-c", the server MAY send, but is not obligated to send, an SSH_MSG_EXT_INFO message immediately before (*) SSH_MSG_USERAUTH_SUCCESS, as defined in [RFC4252]. NEW: If the client sent "ext-info-c", the server MAY send, but is not obligated to send an SSH_MSG_EXT_INFO. If the server sends SSH_MSG_EXT_INFO message it MUST be placed immediately before (*) SSH_MSG_USERAUTH_SUCCESS, as defined in [RFC4252]. -- It is not clear to me why immediately is needed. This allows a server to reveal support for additional extensions that it was unwilling to reveal to an unauthenticated client. If a server sends a subsequent SSH_MSG_EXT_INFO, this replaces any initial one, and both the client and the server re-evaluate extensions in effect. The server's last EXT_INFO is matched against the client's original. (*) The message MUST be sent at this point for the following reasons: if it was sent earlier, it would not allow the server to withhold information until the client has authenticated; if it was sent later, a client that needs information from the second EXT_INFO immediately after successful authentication would have no way of reliably knowing whether there will be a second EXT_INFO or not. Bider [Page 3] Internet-Draft Extension Negotiation in SSH March 2017 2.5. Interpretation of Extension Names and Values Each extension is identified by its extension-name, and defines the conditions under which the extension is considered to be in effect. Applications MUST ignore unrecognized extension-names. In general, if an extension requires both the client and the server to include it in order for the extension to take effect, the relative position of the extension-name in each EXT_INFO message is irrelevant. MGLT: "In general" can be removed. I think the reader expects some additional text that shows cases where the order matters. Extension-value fields are interpreted as defined by their respective extension. An extension-value field MAY be empty if so permitted by the extension. Applications that do not implement or recognize a particular extension MUST ignore the associated extension-value field, regardless of its size or content. MGLT: Is the \0 the delimiter to skip the value ? The cumulative size of an SSH_MSG_EXT_INFO message is limited only by the maximum packet length that an implementation may apply in accordance with [RFC4253]. Implementations MUST accept well-formed SSH_MSG_EXT_INFO messages up to the maximum packet length they accept. 3. Initially Defined Extensions 3.1. "server-sig-algs" This extension is sent with the following extension name and value: string "server-sig-algs" name-list signature-algorithms-accepted Note that the name-list type is a strict subset of the string type, and is thus permissible as an extension-value. MGLT: Maybe a reference to the types used could be added. This extension is sent by the server only, and contains a list of signature algorithms that the server is able to process as part of a "publickey" request. MGLT: I think we should also specify the server behavior, which MUST ignore the extension and MAY disconnect. MGLT: I might be wrong but if the client sends the list, it may be helpful for the server to narrow down its selection. In this case, it may look more as agreement. It may also be useful for the server to monitor the supported signatures requested by clients which could be helpful to understand when to deprecate authentication algorithms. A client that wishes to proceed with public key authentication MAY wait for the server's SSH_MSG_EXT_INFO so it can send a "publickey" authentication request with an appropriate signature algorithm, rather than resorting to trial and error. Servers that implement public key authentication SHOULD implement this extension. If a server does not send this extension, a client MUST NOT make any assumptions about the server's signature algorithm support, and MAY proceed with authentication requests using trial and error. MGLT: Maybe some indication on penalties may be added here. Bider [Page 4] Internet-Draft Extension Negotiation in SSH March 2017 3.2. "delay-compression" This extension MAY be sent by both parties as follows: string "delay-compression" string: name-list compression_algorithms_client_to_server name-list compression_algorithms_server_to_client This extension allows the server and client to renegotiate compression algorithm support without having to conduct a key re-exchange, putting new algorithms into effect immediately upon successful authentication. This extension takes effect only if both parties send it. Name-lists MAY include any compression algorithm that could have been negotiated in SSH_MSG_KEXINIT, except algorithms that define their own delayed compression semantics. This means "zlib,none" is a valid algorithm list in this context; but "zlib@openssh.com" is not. If both parties send this extension, but the name-lists do not contain a common algorithm in either direction, the parties MUST disconnect in the same way as if negotiation failed as part of SSH_MSG_KEXINIT. MGLT: As this looks like a renegotiation, for which reason do we need to disconnect the session and not simply ignore the exchange. If this extension takes effect, the renegotiated compression algorithm is activated for the very next SSH message after the trigger message: - Sent by the server, the trigger message is SSH_MSG_USERAUTH_SUCCESS. - Sent by the client, the trigger message is SSH_MSG_NEWCOMPRESS. If this extension takes effect, the client MUST send the following message shortly after receiving SSH_MSG_USERAUTH_SUCCESS: byte SSH_MSG_NEWCOMPRESS (value 8) The purpose of this message is to avoid a race condition where the server cannot reliably know whether a message sent by the client was sent before or after receiving the server's USERAUTH_SUCCESS. As with all extensions, the server MAY delay including this extension until its secondary SSH_MSG_EXT_INFO, sent before USERAUTH_SUCCESS. This allows the server to avoid advertising compression support until the client has been authenticated. If the parties re-negotiate compression using this extension in a session where compression is already enabled; and the re-negotiated algorithm is the same in one or both directions; then the internal compression state MUST be reset for each direction at the time the re-negotiated algorithm takes effect. Bider [Page 5] Internet-Draft Extension Negotiation in SSH March 2017 3.2.1. Awkwardly Timed Key Re-Exchange A party that has signaled, or intends to signal, support for this extension in an SSH session, MUST NOT initiate key re-exchange in that session until either of the following occurs: - This extension was negotiated, and the party that's about to start key re-exchange already sent its trigger message for compression. - The party has sent (if server) or received (if client) the message SSH_MSG_USERAUTH_SUCCESS, and this extension was not negotiated. If a party violates this rule, the other party MAY disconnect. In general, parties SHOULD NOT start key re-exchange before successful user authentication, but MAY tolerate it if not using this extension. 3.2.2. Subsequent Re-Exchange In subsequent key re-exchanges that unambiguously begin after the compression trigger messages, the compression algorithms negotiated in re-exchange override the algorithms negotiated with this extension. 3.3. "no-flow-control" This extension is sent with the following extension name and value: string "no-flow-control" string choice of: "p" for preferred | "s" for supported MGLT: description of the parameters would be helpful. To take effect, this extension MUST be: - Sent by both parties. - At least one party MUST have sent the value "p" (preferred). If this extension takes effect, the "initial window size" fields in SSH_MSG_CHANNEL_OPEN and SSH_MSG_CHANNEL_OPEN_CONFIRMATION, as defined in [RFC4254], become meaningless. The values of these fields MUST be ignored, and a channel behaves as if all window sizes are infinite. Neither side is required to send any SSH_MSG_CHANNEL_WINDOW_ADJUST messages, and if received, such messages MUST be ignored. This extension is intended, but not limited to, use by file transfer applications that are only going to use one channel, and for which the flow control provided by SSH is an impediment, rather than a feature. Implementations MUST refuse to open more than one simultaneous channel when this extension is in effect. Nevertheless, server implementations SHOULD support clients opening more than one non-simultaneous channel. Bider [Page 6] Internet-Draft Extension Negotiation in SSH March 2017 3.4. "elevation" This extension MAY be sent by the client as follows: string "elevation" string choice of: "y" | "n" | "d" MGLT: description of the parameters would be helpful. A client sends "y" to indicate its preference that the session should be elevated (as used by Windows); "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. If a client has included this extension, then after authentication, a server that supports this extension SHOULD indicate to the client whether elevation was done by sending the following global request: byte SSH_MSG_GLOBAL_REQUEST string "elevation" boolean want reply = false boolean elevation performed 4. IANA Considerations 4.1. Additions to existing tables IANA is requested to insert the following entries into the table Message Numbers under Secure Shell (SSH) Protocol Parameters [RFC4250]: Value Message ID Reference 7 SSH_MSG_EXT_INFO [this document] 8 SSH_MSG_NEWCOMPRESS [this document] IANA is requested to insert the following entries into the table Key Exchange Method Names: Method Name Reference Note ext-info-s [this document] Section 2.2 ext-info-c [this document] Section 2.2 4.2. New table: Extension Names Also under Secure Shell (SSH) Protocol Parameters, IANA is requested to create a new table, Extension Names, with initial content: Extension Name Reference Note server-sig-algs [this document] Section 3.1 delay-compression [this document] Section 3.2 no-flow-control [this document] Section 3.3 elevation [this document] Section 3.4 Bider [Page 7] Internet-Draft Extension Negotiation in SSH March 2017 4.2.1. Future Assignments to Extension Names Names in the Extension Names table MUST follow the Conventions for Names defined in [RFC4250], Section 4.6.1. Requests for assignments of new non-local names in the Extension Names table (i.e. names not including the '@' character) MUST be done through the IETF CONSENSUS method, as described in [RFC5226]. 5. References 5.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, January 2006. [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006. [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006. [RFC4254] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Connection Protocol", RFC 4254, January 2006. [RFC5226] Narten, T. and Alvestrand, H., "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 5.2. Informative References [SSH-RSA-SHA2] Bider, D., "Use of RSA Keys with SHA-2 256 and 512 in Secure Shell (SSH)", draft-ietf-curdle-rsa-sha2-03.txt, February 2017, . Bider [Page 8] Internet-Draft Extension Negotiation in SSH March 2017 Author's Address Denis Bider Bitvise Limited Suites 41/42, Victoria House 26 Main Street GI Phone: +506 8315 6519 EMail: ietf-ssh3@denisbider.com URI: https://www.bitvise.com/ Acknowledgments Thanks to Markus Friedl and Damien Miller for comments and initial implementation. Thanks to Peter Gutmann and Roumen Petrov for review and feedback. Bider [Page 9] --001a11449ffc15aff8054b966bbf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Thank you for moving that= draft forward. Please see some comments on the draft.

Yours,
Daniel



Internet-Draft=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 D. Bider
Updates: 42= 52, 4253, 4254 (if approved)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Bitvise LimitedIntended status: Standards Track=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 March 23, 2017
Expires: September 2= 3, 2017


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Extension Negotiation in Secure Shell (SSH)<= br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 draft-ietf-curdle-ssh-ext-info-03.txt

Abstract

=C2=A0 This memo defines a mechanism for SSH clients a= nd servers to exchange
=C2=A0 information about supported protocol exten= sions confidentially after
=C2=A0 completed key exchange.

Bider= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [Page 1]
=0C
Interne= t-Draft=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Extension Negotiation in = SSH=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 March= 2017


1.=C2=A0 Overview and Rationale

=C2=A0 Secure Shell= (SSH) is a common protocol for secure communication on
=C2=A0 the Inter= net. The original design of the SSH transport layer [RFC4253]
=C2=A0 lac= ks proper extension negotiation. Meanwhile, diverse implementations
=C2= =A0 take steps to ensure that known message types contain no unrecognized=C2=A0 information. This makes it difficult for implementations to signal=
=C2=A0 capabilities and negotiate extensions without risking disconnect= ion.

=C2=A0 This obstacle has been recognized in relationship with [= SSH-RSA-SHA2],
=C2=A0 where the need arises for a client to discover sig= nature algorithms a
=C2=A0 server accepts, to avoid authentication penal= ties and trial-and-error.

1.1.=C2=A0 Requirements Terminology
=C2=A0 The key words "MUST", "MUST NOT", "REQUIRE= D", "SHALL", "SHALL NOT",
=C2=A0 "SHOULD&q= uot;, "SHOULD NOT", "RECOMMENDED", "MAY", and= "OPTIONAL" in this
=C2=A0 document are to be interpreted as d= escribed in [RFC2119].


2.=C2=A0 Extension Negotiation Mechanism<= br>
2.1.=C2=A0 Signaling of Extension Negotiation in KEXINIT

=C2= =A0 Applications implementing this mechanism MUST add to the field
=C2= =A0 "kex_algorithms", in their KEXINIT packet sent for the first = key
=C2=A0 exchange, one of the following indicator names:

=C2=A0= - When acting as server: "ext-info-s"
=C2=A0 - When acting as= client: "ext-info-c"

=C2=A0 The indicator name is added w= ithout quotes, and MAY be added at any
=C2=A0 position in the name-list,= subject to proper separation from other
=C2=A0 names as per name-list c= onventions.

=C2=A0 The names are added to the "kex_algorithms&q= uot; field because this is one
=C2=A0 of two name-list fields in KEXINIT= that do not have a separate copy
=C2=A0 for each data direction.
=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 will be= neutral
=C2=A0 with respect to key exchange algorithm negotiation.
<= br>=C2=A0 The inclusion of textual indicator names is intended to provide a= clue
=C2=A0 for implementers to discover this mechanism.

2.2.=C2= =A0 Enabling Criteria

=C2=A0 If a client or server offers "ext-= info-c" or "ext-info-s"
=C2=A0 respectively, it MUST be p= repared to accept an SSH_MSG_EXT_INFO
=C2=A0 message from the peer.
<= br>
Bider=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [Page 2]
= =0C
Internet-Draft=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Extension N= egotiation in SSH=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 March 2017


=C2=A0 Thus a server only needs to send &qu= ot;ext-info-s" if it intends to process
=C2=A0 SSH_MSG_EXT_INFO fro= m the client.

=C2=A0 If a server receives an "ext-info-c",= it MAY send an SSH_MSG_EXT_INFO
=C2=A0 message, but is not required to = do so.

=C2=A0 If an SSH_MSG_EXT_INFO message is sent, then it MUST b= e the first
=C2=A0 message after the initial SSH_MSG_NEWKEYS.

=C2= =A0 Implementations MUST NOT send an incorrect indicator name for their
= =C2=A0 role. Implementations MAY disconnect if the counter-party sends an=C2=A0 incorrect indicator. If "ext-info-c" or "ext-info-s= " ends up being
=C2=A0 negotiated as a key exchange method, the par= ties MUST disconnect.

MGLT: Shouldn't we have "Implementati= ons MUST disconnect" ? At least we should maybe state that it MUST ign= ore the indication.
=C2=A0
2.3.=C2=A0 SSH_MSG_EXT_INFO Message
<= br>=C2=A0A party that received the "ext-info-c" or "ext-info= -s" indicator
=C2=A0MAY send the following message:

=C2=A0= =C2=A0=C2=A0 byte=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SSH_MSG_EXT_INFO (val= ue 7)
=C2=A0=C2=A0=C2=A0 uint32=C2=A0=C2=A0=C2=A0=C2=A0 nr-extensions=C2=A0=C2=A0=C2=A0 repeat "nr-extensions" times:
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 string=C2=A0=C2=A0 extension-name
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 string=C2=A0=C2=A0 extension-value

MGLT: maybe the diff= erent terms/parameters could be defined. I am assuming that an extenssion-n= ame has a single extension-value. In other words, extension-name is repeate= d.
=C2=A0=C2=A0=C2=A0 =C2=A0
=C2=A0 This message is sent immediatel= y after SSH_MSG_NEWKEYS, without delay.
=C2=A0 This allows a client to p= ipeline an authentication request after its
=C2=A0 SSH_MSG_SERVICE_REQUE= ST, even when this needs extension information.

2.4.=C2=A0 Server= 9;s Secondary SSH_MSG_EXT_INFO

=C2=A0 If the client sent "ext-i= nfo-c", the server MAY send, but is not
=C2=A0 obligated to send, a= n SSH_MSG_EXT_INFO message immediately before (*)
=C2=A0 SSH_MSG_USERAUT= H_SUCCESS, as defined in [RFC4252]. The server MAY send
=C2=A0 this mess= age whether or not it sent EXT_INFO after SSH_MSG_NEWKEYS.

MGLT: May= be that would be clearer to split the sentence in two parts so the "MA= Y" does not confuse the reader.
=C2=A0
OLD:
=C2=A0If the clie= nt sent "ext-info-c", the server MAY send, but is not
=C2=A0 o= bligated to send, an SSH_MSG_EXT_INFO message immediately before (*)
=C2= =A0 SSH_MSG_USERAUTH_SUCCESS, as defined in [RFC4252].=C2=A0
NEW:
= =C2=A0 If the client sent "ext-info-c", the server MAY send, but = is not
=C2=A0 obligated to send an SSH_MSG_EXT_INFO. If the server sends= SSH_MSG_EXT_INFO message it MUST be placed immediately before (*)
=C2= =A0 SSH_MSG_USERAUTH_SUCCESS, as defined in [RFC4252].
=C2=A0 -- It is n= ot clear to me why immediately is needed.
=C2=A0
=C2=A0 This allows = a server to reveal support for additional extensions that
=C2=A0 it was = unwilling to reveal to an unauthenticated client. If a server
=C2=A0 sen= ds a subsequent SSH_MSG_EXT_INFO, this replaces any initial one,
=C2=A0 = and both the client and the server re-evaluate extensions in effect.
=C2= =A0 The server's last EXT_INFO is matched against the client's orig= inal.

=C2=A0 (*) The message MUST be sent at this point for the foll= owing reasons:
=C2=A0 if it was sent earlier, it would not allow the ser= ver to withhold
=C2=A0 information until the client has authenticated; i= f it was sent later,
=C2=A0 a client that needs information from the sec= ond EXT_INFO immediately
=C2=A0 after successful authentication would ha= ve no way of reliably knowing
=C2=A0 whether there will be a second EXT_= INFO or not.





Bider=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 [Page 3]
=0C
Internet-Draft=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Extension Negotiation in SSH=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 March 2017


2.5.=C2=A0 In= terpretation of Extension Names and Values

=C2=A0 Each extension is = identified by its extension-name, and defines the
=C2=A0 conditions unde= r which the extension is considered to be in effect.
=C2=A0 Applications= MUST ignore unrecognized extension-names.

=C2=A0 In general, if an = extension requires both the client and the server
=C2=A0 to include it i= n order for the extension to take effect, the relative
=C2=A0 position o= f the extension-name in each EXT_INFO message is irrelevant.

MGLT: &= quot;In general" can be removed. I think the reader expects some addit= ional text that shows cases where the order matters.
=C2=A0=C2=A0
= =C2=A0 Extension-value fields are interpreted as defined by their respectiv= e
=C2=A0 extension. An extension-value field MAY be empty if so permitte= d by
=C2=A0 the extension. Applications that do not implement or recogni= ze a
=C2=A0 particular extension MUST ignore the associated extension-va= lue field,
=C2=A0 regardless of its size or content.

MGLT: Is the= \0 the delimiter to skip the value ?=C2=A0
=C2=A0
=C2=A0 The cumul= ative size of an SSH_MSG_EXT_INFO message is limited only by
=C2=A0 the = maximum packet length that an implementation may apply in
=C2=A0 accorda= nce with [RFC4253]. Implementations MUST accept well-formed
=C2=A0 SSH_M= SG_EXT_INFO messages up to the maximum packet length they accept.

3. Initially Defined Extensions

3.1. "server-sig-algs"
=C2=A0 This extension is sent with the following extension name and v= alue:

=C2=A0=C2=A0=C2=A0 string=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "= server-sig-algs"
=C2=A0=C2=A0=C2=A0 name-list=C2=A0=C2=A0 signature= -algorithms-accepted

=C2=A0 Note that the name-list type is a strict= subset of the string type,
=C2=A0 and is thus permissible as an extensi= on-value.

MGLT: Maybe a reference to the types used could be added. =
=C2=A0
=C2=A0 This extension is sent by the server only, and contai= ns a list of
=C2=A0 signature algorithms that the server is able to proc= ess as part of a
=C2=A0 "publickey" request.

MGLT: I th= ink we should also specify the server behavior, which MUST ignore the exten= sion and MAY disconnect.

MGLT: I might be wrong but if the client s= ends the list, it may be helpful for the server to narrow down its selectio= n. In this case, it may look more as agreement. It may also be useful for t= he server to monitor the supported signatures requested by clients which co= uld be helpful to understand when to deprecate authentication algorithms.= =C2=A0
=C2=A0
=C2=A0 A client that wishes to proceed with public ke= y authentication MAY
=C2=A0 wait for the server's SSH_MSG_EXT_INFO s= o it can send a "publickey"
=C2=A0 authentication request with= an appropriate signature algorithm, rather
=C2=A0 than resorting to tri= al and error.

=C2=A0 Servers that implement public key authenticatio= n SHOULD implement this
=C2=A0 extension.

=C2=A0 If a server does= not send this extension, a client MUST NOT make any
=C2=A0 assumptions = about the server's signature algorithm support, and MAY
=C2=A0 proce= ed with authentication requests using trial and error.

MGLT: Maybe s= ome indication on penalties may be added here.=C2=A0


Bider=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [Page 4]
=0C
Internet-D= raft=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Extension Negotiation in SSH= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 March 20= 17


3.2.=C2=A0 "delay-compression"

=C2=A0 This e= xtension MAY be sent by both parties as follows:

=C2=A0=C2=A0=C2=A0 = string=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "delay-compress= ion"
=C2=A0=C2=A0=C2=A0 string:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 n= ame-list=C2=A0=C2=A0=C2=A0 compression_algorithms_client_to_server
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 name-list=C2=A0=C2=A0=C2=A0 compression_algorit= hms_server_to_client

=C2=A0 This extension allows the server and cli= ent to renegotiate compression
=C2=A0 algorithm support without having t= o conduct a key re-exchange, putting
=C2=A0 new algorithms into effect i= mmediately upon successful authentication.

=C2=A0 This extension tak= es effect only if both parties send it. Name-lists
=C2=A0 MAY include an= y compression algorithm that could have been negotiated
=C2=A0 in SSH_MS= G_KEXINIT, except algorithms that define their own delayed
=C2=A0 compre= ssion semantics. This means "zlib,none" is a valid algorithm
= =C2=A0 list in this context; but "= zlib@openssh.com" is not.

=C2=A0 If both parties send this = extension, but the name-lists do not contain
=C2=A0 a common algorithm i= n either direction, the parties MUST disconnect in
=C2=A0 the same way a= s if negotiation failed as part of SSH_MSG_KEXINIT.

MGLT: As this lo= oks like a renegotiation, for which reason do we need to disconnect the ses= sion and not simply ignore the exchange.
=C2=A0
=C2=A0 If this exten= sion takes effect, the renegotiated compression algorithm
=C2=A0 is acti= vated for the very next SSH message after the trigger message:

=C2= =A0 - Sent by the server, the trigger message is SSH_MSG_USERAUTH_SUCCESS.<= br>=C2=A0 - Sent by the client, the trigger message is SSH_MSG_NEWCOMPRESS.=

=C2=A0 If this extension takes effect, the client MUST send the fol= lowing
=C2=A0 message shortly after receiving SSH_MSG_USERAUTH_SUCCESS:<= br>
=C2=A0=C2=A0=C2=A0 byte=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SSH_MSG_= NEWCOMPRESS (value 8)

=C2=A0 The purpose of this message is to avoid= a race condition where the
=C2=A0 server cannot reliably know whether a= message sent by the client was
=C2=A0 sent before or after receiving th= e server's USERAUTH_SUCCESS.

=C2=A0 As with all extensions, the = server MAY delay including this extension
=C2=A0 until its secondary SSH= _MSG_EXT_INFO, sent before USERAUTH_SUCCESS.
=C2=A0 This allows the serv= er to avoid advertising compression support until
=C2=A0 the client has = been authenticated.

=C2=A0 If the parties re-negotiate compression u= sing this extension in a
=C2=A0 session where compression is already ena= bled; and the re-negotiated
=C2=A0 algorithm is the same in one or both = directions; then the internal
=C2=A0 compression state MUST be reset for= each direction at the time the
=C2=A0 re-negotiated algorithm takes eff= ect.





Bider=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 [Page 5]
=0C
Internet-Draft=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Extension Negotiation in SSH=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 March 2017


3.2.1.=C2=A0 Awkwardly= Timed Key Re-Exchange

=C2=A0 A party that has signaled, or intends = to signal, support for this
=C2=A0 extension in an SSH session, MUST NOT= initiate key re-exchange in that
=C2=A0 session until either of the fol= lowing occurs:

=C2=A0 - This extension was negotiated, and the party= that's about to start
=C2=A0=C2=A0=C2=A0 key re-exchange already se= nt its trigger message for compression.

=C2=A0 - The party has sent = (if server) or received (if client) the message
=C2=A0=C2=A0=C2=A0 SSH_M= SG_USERAUTH_SUCCESS, and this extension was not negotiated.

=C2=A0 I= f a party violates this rule, the other party MAY disconnect.

=C2=A0= In general, parties SHOULD NOT start key re-exchange before successful
= =C2=A0 user authentication, but MAY tolerate it if not using this extension= .

3.2.2.=C2=A0 Subsequent Re-Exchange

=C2=A0 In subsequent ke= y re-exchanges that unambiguously begin after the
=C2=A0 compression tri= gger messages, the compression algorithms negotiated in
=C2=A0 re-exchan= ge override the algorithms negotiated with this extension.


3.3.= =C2=A0 "no-flow-control"

=C2=A0 This extension is sent wit= h the following extension name and value:

=C2=A0=C2=A0=C2=A0 string= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "no-flow-control"
=C2=A0=C2=A0= =C2=A0 string=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 choice of: "p" for pr= eferred | "s" for supported

MGLT: description of the param= eters would be helpful.
=C2=A0
=C2=A0 To take effect, this extension= MUST be:

=C2=A0 - Sent by both parties.
=C2=A0 - At least one pa= rty MUST have sent the value "p" (preferred).

=C2=A0 If th= is extension takes effect, the "initial window size" fields in=C2=A0 SSH_MSG_CHANNEL_OPEN and SSH_MSG_CHANNEL_OPEN_CONFIRMATION, as defi= ned
=C2=A0 in [RFC4254], become meaningless. The values of these fields = MUST be
=C2=A0 ignored, and a channel behaves as if all window sizes are= infinite.
=C2=A0 Neither side is required to send any SSH_MSG_CHANNEL_W= INDOW_ADJUST
=C2=A0 messages, and if received, such messages MUST be ign= ored.

=C2=A0 This extension is intended, but not limited to, use by = file transfer
=C2=A0 applications that are only going to use one channel= , and for which the
=C2=A0 flow control provided by SSH is an impediment= , rather than a feature.

=C2=A0 Implementations MUST refuse to open = more than one simultaneous channel
=C2=A0 when this extension is in effe= ct. Nevertheless, server implementations
=C2=A0 SHOULD support clients o= pening more than one non-simultaneous channel.



Bider=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [Page 6]
=0C
Internet-Draf= t=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Extension Negotiation in SSH=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 March 2017<= br>

3.4.=C2=A0 "elevation"

=C2=A0 This extension MA= Y be sent by the client as follows:

=C2=A0=C2=A0=C2=A0 string=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 "elevation"
=C2=A0=C2=A0=C2=A0 string= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 choice of: "y" | "n" | &= quot;d"

MGLT: description of the parameters would be helpful.= =C2=A0=C2=A0=C2=A0
=C2=A0=C2=A0=C2=A0
=C2=A0 A client sends "y= " to indicate its preference that the session should
=C2=A0 be elev= ated (as used by Windows); "n" to not be elevated; and "d&qu= ot; for
=C2=A0 the server to use its default behavior. If a client does = not send the
=C2=A0 "elevation" extension, the server SHOULD a= ct as if "d" was sent.

=C2=A0 If a client has included thi= s extension, then after authentication, a
=C2=A0 server that supports th= is extension SHOULD indicate to the client
=C2=A0 whether elevation was = done by sending the following global request:

=C2=A0=C2=A0=C2=A0 byt= e=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SSH_MSG_GLOBAL_REQUEST
=C2= =A0=C2=A0=C2=A0 string=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "elevation"<= br>=C2=A0=C2=A0=C2=A0 boolean=C2=A0=C2=A0=C2=A0=C2=A0 want reply =3D false<= br>=C2=A0=C2=A0=C2=A0 boolean=C2=A0=C2=A0=C2=A0=C2=A0 elevation performed

4.=C2=A0 IANA Considerations

4.1.=C2=A0 Additions to exist= ing tables

=C2=A0 IANA is requested to insert the following entries = into the table
=C2=A0 Message Numbers under Secure Shell (SSH) Protocol = Parameters
=C2=A0 [RFC4250]:

=C2=A0=C2=A0=C2=A0 Value=C2=A0=C2=A0= =C2=A0 Message ID=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Reference
=C2=A0=C2=A0=C2=A0 7=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 SSH_MSG_EXT_INFO=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [th= is document]
=C2=A0=C2=A0=C2=A0 8=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 SSH_MSG_NEWCOMPRESS=C2=A0=C2=A0=C2=A0 [this document]

=C2=A0 IAN= A is requested to insert the following entries into the table Key
=C2=A0= Exchange Method Names:

=C2=A0=C2=A0=C2=A0 Method Name=C2=A0=C2=A0= =C2=A0=C2=A0 Reference=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Note
=C2=A0=C2=A0=C2=A0 ext-info-s=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [th= is document]=C2=A0=C2=A0=C2=A0 Section 2.2
=C2=A0=C2=A0=C2=A0 ext-info-c= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [this document]=C2=A0=C2=A0=C2=A0 Section 2.= 2

4.2.=C2=A0 New table: Extension Names

=C2=A0 Also under Sec= ure Shell (SSH) Protocol Parameters, IANA is requested
=C2=A0 to create = a new table, Extension Names, with initial content:

=C2=A0=C2=A0=C2= =A0 Extension Name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Reference=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Note
=C2=A0=C2=A0=C2=A0 se= rver-sig-algs=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [this document]=C2=A0=C2=A0=C2= =A0 Section 3.1
=C2=A0=C2=A0=C2=A0 delay-compression=C2=A0=C2=A0=C2=A0 [= this document]=C2=A0=C2=A0=C2=A0 Section 3.2
=C2=A0=C2=A0=C2=A0 no-flow-= control=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [this document]=C2=A0=C2=A0=C2=A0 Sec= tion 3.3
=C2=A0=C2=A0=C2=A0 elevation=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [this document]=C2=A0=C2=A0=C2=A0 Section= 3.4


Bider=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [Page= 7]
=0C
Internet-Draft=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Exte= nsion Negotiation in SSH=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 March 2017


4.2.1.=C2=A0 Future Assignments to Ex= tension Names

=C2=A0 Names in the Extension Names table MUST follow = the Conventions for
=C2=A0 Names defined in [RFC4250], Section 4.6.1.
=C2=A0 Requests for assignments of new non-local names in the Extensio= n Names
=C2=A0 table (i.e. names not including the '@' character= ) MUST be done
=C2=A0 through the IETF CONSENSUS method, as described in= [RFC5226].


5.=C2=A0 References

5.1.=C2=A0 Normative Refe= rences

=C2=A0 [RFC2119]=C2=A0=C2=A0 Bradner, S., "Key words for= use in RFCs to Indicate
=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 Requirement Levels", BCP 14, RFC 211= 9, March 1997.

=C2=A0 [RFC4250]=C2=A0=C2=A0 Lehtinen, S. and C. Lonv= ick, Ed., "The Secure Shell (SSH)
=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 Protocol Assigned Numbers&quo= t;, RFC 4250, January 2006.

=C2=A0 [RFC4252]=C2=A0=C2=A0 Ylonen, T. = and C. Lonvick, Ed., "The Secure Shell (SSH)
=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 Authentication Pr= otocol", RFC 4252, January 2006.

=C2=A0 [RFC4253]=C2=A0=C2=A0 Y= lonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
=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 Transpor= t Layer Protocol", RFC 4253, January 2006.

=C2=A0 [RFC4254]=C2= =A0=C2=A0 Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
= =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 Connection Protocol", RFC 4254, January 2006.

=C2=A0 [RFC52= 26]=C2=A0=C2=A0 Narten, T. and Alvestrand, H., "Guidelines for Writing= an
=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 IANA Considerations Section in RFCs", BCP 26, RFC 5226,=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 May 2008.

5.2.=C2=A0 Informative References

=C2=A0 [SS= H-RSA-SHA2]
=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 Bider, D., "Use of RSA Keys with SHA-2 256 and 512 = in
=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 Secure Shell (SSH)", draft-ietf-curdle-rsa-sha2-03.txt,
= =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 February 2017, <https://too= ls.ietf.org/html/
=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 draft-ietf-curdle-rsa-sha2-03>.












Bider=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 [Page 8]
=0C
Internet-Draft=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Extension Negotiation in SSH=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 March 2017


Auth= or's Address

=C2=A0 Denis Bider
=C2=A0 Bitvise Limited
=C2= =A0 Suites 41/42, Victoria House
=C2=A0 26 Main Street
=C2=A0 GI
<= br>=C2=A0 Phone: +506 8315 6519
=C2=A0 EMail: ietf-ssh3@denisbider.com
=C2=A0 URI:=C2=A0=C2=A0 <= a href=3D"https://www.bitvise.com/">https://www.bitvise.com/

Acknowledgments

=C2=A0 Thanks to Markus Friedl and Damien Miller fo= r comments and initial
=C2=A0 implementation. Thanks to Peter Gutmann an= d Roumen Petrov for review
=C2=A0 and feedback.





<= br>

















=










Bider=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 [Page 9]
=0C

--001a11449ffc15aff8054b966bbf-- From nobody Sat Mar 25 16:40: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 2B9C61272E1 for ; Sat, 25 Mar 2017 16:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, 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 BpE9ipDdKjGI for ; Sat, 25 Mar 2017 16:40:28 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::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 0C45C127097 for ; Sat, 25 Mar 2017 16:40:28 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id w124so12054973itb.0 for ; Sat, 25 Mar 2017 16:40:28 -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=KXSy5Q7bwmnbJvd36uv8Xjg4wQg23Uzju5x7iklC1VQ=; b=WdnyZgOP2VPBiuww1Dikff6kYRWL0e3xQt6yzrrP8QTeT82Bhu9z90Eaqd6GGGNzB+ h9Cbf7bX7fLgowza+Hmf9ITRX1FUOBMnhscswX52pSLl7ciavCnGr13Gg/ubW0ew5Nqz P945v7Id+vsAlPHJNV248fYifnJr8NHn1Tr38OIRwVyeDg8VmnSbfXoW53/oeTX4jd15 MJxHVDcrRyguiO3xPwgSOOEj5COK+V+wnkOLsGtEi94cbMZRggOyQJw7G+FBG2dg0HaX ZcrxyQUVundgEaY1EDauFGP/QA+nX2el/wzoFSQuQbbL1G6YMosGD410Z+xRYbBZaToZ c+DQ== 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=KXSy5Q7bwmnbJvd36uv8Xjg4wQg23Uzju5x7iklC1VQ=; b=Es89FW6jf/ffC0Q5L0uI5lTYXslSUbKPNiohN4u/G+njMzNmKfy2bC97rG82oQIZz8 A3mjchS8bAEkZJHgj2sf+6aVAg8qXZOFuWTBTPWC9Zg2BeA6cLBZfBpFhRRpHWoAMTJO j8Y43qqEX3Ay6e79vrHEERTNvwBQiQwQtpH+dkJrYTwFyW3jKbiBPsmPKVZPkQGLZQVj PJyzb6/NXvLCh7p5m6/REE/ccF7CLcATs2S+pot00idoq8ID9o9WQfG2pZEH07tKnuNp IhYxwbAyXFHBQKSBbCmxUCn+QVBeas10bRhDV6KNd7cb9FppfAULXybF81yq6YIgtGHr 9W8g== X-Gm-Message-State: AFeK/H06H7oRrTwMxvzlKEOoIsrhA7brmJ2265Ocv50s9ONNXZnmHSSWAkhrg5LOXXikVPFTB8SXmPXLpeid2w== X-Received: by 10.107.174.27 with SMTP id x27mr14392310ioe.35.1490485227210; Sat, 25 Mar 2017 16:40:27 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.35.213 with HTTP; Sat, 25 Mar 2017 16:40:26 -0700 (PDT) From: Daniel Migault Date: Sat, 25 Mar 2017 19:40:26 -0400 X-Google-Sender-Auth: BuIyXmaSE1QrXBr3cyU5Kml4s8k Message-ID: To: curdle Content-Type: multipart/alternative; boundary=001a11449ffc82d222054b96a2a7 Archived-At: Subject: [Curdle] comments on draft-ietf-curdle-rsa-sha2-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: Sat, 25 Mar 2017 23:40:30 -0000 --001a11449ffc82d222054b96a2a7 Content-Type: text/plain; charset=UTF-8 Hi, Please find my comments on draft-ietf-curdle-rsa-sha2-03.txt. In a word my comments are: - 1) Should we consider adding / replacing PKCS1v1.5 by RSA-PSS for the signature format. - 2) I understand that penalties are encouraging to keep ssh-rsa while the use of sha1 is deprecated. I suggest to provide some recommendations on how to perform penalties. Yours, Daniel Use of RSA Keys with SHA-2 256 and 512 in Secure Shell (SSH) draft-ietf-curdle-rsa-sha2-03.txt Abstract This memo defines an algorithm name, public key format, and signature format for use of RSA keys with SHA-2 512 for server and client authentication in SSH connections. MGLT: Maybe we should also add penalty recommendations as well ? 2. Public Key Algorithms This memo adopts the style and conventions of [RFC4253] in specifying how use of a signature algorithm is indicated in SSH. The following new signature algorithms are defined: rsa-sha2-256 RECOMMENDED sign Raw RSA key rsa-sha2-512 OPTIONAL sign Raw RSA key These signature algorithms are suitable for use both in the SSH transport layer [RFC4253] for server authentication, and in the authentication layer [RFC4252] for client authentication. Since RSA keys are not dependent on the choice of hash function, both new algorithms reuse the public key format of the existing "ssh-rsa" algorithm as defined in [RFC4253]: string "ssh-rsa" mpint e mpint n All aspects of the "ssh-rsa" format are kept, including the encoded string "ssh-rsa", in order to allow users' existing RSA keys to be used with the new signature formats, without requiring re-encoding, or affecting already trusted key fingerprints. Signing and verifying using these algorithms is performed according to the RSASSA-PKCS1-v1_5 scheme in [RFC3447] using SHA-2 [FIPS-180-4] as hash; MGF1 as mask function; and salt length equal to hash size. MGLT: Could we also take this opportunity to upgrade the signature to RSA-PSS ? If "rsa-sha2-256" / "rsa-sha2-512" are already deployed in most implementation, maybe this document could also define "rsa-sha2-256-rsassa-pss" and "rsa-sha2-512-rsassa-pss" otherwise we could define rsa-sha2-* with RSA-PSS. 3. Discovery of signature algorithms supported by servers Implementation experience has shown that there are servers which apply authentication penalties to clients attempting signature algorithms which the SSH server does not support. MGLT: Can we recommend to have penalties only applies when algorithms are weaker than the one supported. Servers that accept rsa-sha2-* signatures for client authentication SHOULD implement the extension negotiation mechanism defined in [SSH-EXT-INFO], including especially the "server-sig-algs" extension. When authenticating with an RSA key against a server that does not implement the "server-sig-algs" extension, clients MAY default to an ssh-rsa signature to avoid authentication penalties. MGLT: ssh-rsa must be deprecated, so I think we should have something different. The fall back should be on the most recommended algorithm, or the authentication penalty should be changed. --001a11449ffc82d222054b96a2a7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Please find my comments o= n draft-ietf-curdle-rsa-sha2-03.txt.

In a word my comments are:
= =C2=A0=C2=A0 - 1) Should we consider=C2=A0 adding / replacing PKCS1v1.5 by = RSA-PSS for=C2=A0 the signature format.
=C2=A0=C2=A0 - 2) I = understand that penalties are encouraging to keep ssh-rsa while the use of = sha1 is deprecated. I suggest to provide some recommendations on how to per= form penalties.=C2=A0

Yours,
Daniel

=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Use of RSA Keys with SHA-2 256 and 512 in Secure S= hell (SSH)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 draft-ietf-curdle-rsa-sha2= -03.txt


Abstract

=C2=A0 This memo defines an algorithm na= me, public key format, and signature
=C2=A0 format for use of RSA keys w= ith SHA-2 512 for server and client
=C2=A0 authentication in SSH connect= ions.
=C2=A0
MGLT: Maybe we should also add penalty recommendations = as well ?

2.=C2=A0 Public Key Algorithms

=C2=A0 This memo ado= pts the style and conventions of [RFC4253] in specifying
=C2=A0 how use = of a signature algorithm is indicated in SSH.

=C2=A0 The following n= ew signature algorithms are defined:

=C2=A0=C2=A0=C2=A0 rsa-sha2-256= =C2=A0=C2=A0=C2=A0 RECOMMENDED=C2=A0=C2=A0=C2=A0 sign=C2=A0=C2=A0=C2=A0 Raw= RSA key
=C2=A0=C2=A0=C2=A0 rsa-sha2-512=C2=A0=C2=A0=C2=A0 OPTIONAL=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sign=C2=A0=C2=A0=C2=A0 Raw RSA key
=C2=A0 These signature algorithms are suitable for use both in the SSH tra= nsport
=C2=A0 layer [RFC4253] for server authentication, and in the auth= entication
=C2=A0 layer [RFC4252] for client authentication.

=C2= =A0 Since RSA keys are not dependent on the choice of hash function, both=C2=A0 new algorithms reuse the public key format of the existing "s= sh-rsa"
=C2=A0 algorithm as defined in [RFC4253]:

=C2=A0=C2= =A0=C2=A0 string=C2=A0=C2=A0=C2=A0 "ssh-rsa"
=C2=A0=C2=A0=C2= =A0 mpint=C2=A0=C2=A0=C2=A0=C2=A0 e
=C2=A0=C2=A0=C2=A0 mpint=C2=A0=C2=A0= =C2=A0=C2=A0 n

=C2=A0 All aspects of the "ssh-rsa" format = are kept, including the encoded
=C2=A0 string "ssh-rsa", in or= der to allow users' existing RSA keys to be
=C2=A0 used with the new= signature formats, without requiring re-encoding,
=C2=A0 or affecting a= lready trusted key fingerprints.

=C2=A0 Signing and verifying using = these algorithms is performed according to
=C2=A0 the RSASSA-PKCS1-v1_5 = scheme in [RFC3447] using SHA-2 [FIPS-180-4] as
=C2=A0 hash; MGF1 as mas= k function; and salt length equal to hash size.

MGLT: Could we also = take this opportunity to upgrade the signature to RSA-PSS ?
If "rs= a-sha2-256" / "rsa-sha2-512" are already deployed in most im= plementation, maybe this document could also define "rsa-sha2-256-rsas= sa-pss" and "rsa-sha2-512-rsassa-pss" otherwise we could def= ine rsa-sha2-* with RSA-PSS.


3.=C2=A0 Discovery of signature al= gorithms supported by servers

=C2=A0 Implementation experience has s= hown that there are servers which apply
=C2=A0 authentication penalties = to clients attempting signature algorithms
=C2=A0 which the SSH server d= oes not support.

MGLT: Can we recommend to have penalties only appli= es when algorithms are weaker than the one supported.
=C2=A0
=C2=A0= Servers that accept rsa-sha2-* signatures for client authentication
=C2= =A0 SHOULD implement the extension negotiation mechanism defined in
=C2= =A0 [SSH-EXT-INFO], including especially the "server-sig-algs" ex= tension.

=C2=A0 When authenticating with an RSA key against a server= that does not
=C2=A0 implement the "server-sig-algs" extensio= n, clients MAY default to an
=C2=A0 ssh-rsa signature to avoid authentic= ation penalties.

MGLT: ssh-rsa must be deprecated, so I think we sho= uld have something different. The fall back should be on the most recommend= ed algorithm, or the authentication penalty should be changed.
=C2=A0 <= br>
--001a11449ffc82d222054b96a2a7-- From nobody Sat Mar 25 20:37: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 651021294E9 for ; Sat, 25 Mar 2017 20:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, 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 wRH2vrI4fjdl for ; Sat, 25 Mar 2017 20:37:10 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::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 CD5991294E5 for ; Sat, 25 Mar 2017 20:37:10 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id y18so43353438itc.0 for ; Sat, 25 Mar 2017 20:37:10 -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=GRT35UggbLnCnms4j0Rm0EkXoS7ELNZB5mKG9d0R9/U=; b=acJAd3nkBjDuWfyIq+NYGqXgHeiTQb2UZEQb0t7y4KKPC4r53/RnGc5pd0bDWqK1X9 I4jqalG//408DF2RBv9HC9zIPFW0Ajsn8gqYI2oSZwfYAManNoigfLwNupJFAz5IxG5m Lpa4EWJI9fLXBeNJGcVSSM16piXv/dpdL3BTS0EjNw9DV4qMkzmvgbDpeeAZy1qOaNPM 3NKLH7D+WRu+537ZMlxzHGgRLm/ohRKcVWNt9MLyz363B+qZdVCCk0pk5vMc7030k+Eb aDYBWQ6scT/8ih0EiJMAFuWi4iwn2hwAJrZrLHc+KCnHSTR6Ew7ZNg56ci7gyIEUNKKi 1hMw== 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=GRT35UggbLnCnms4j0Rm0EkXoS7ELNZB5mKG9d0R9/U=; b=WsB7zwPxxzIRH4QWSFdqUs+Oo5NFIk8hCM6Swt884grmtbachS5SA9TnM/Do+xQ/Np eF9UjfGBlolgaxjZFoYVdSQbyAL8e7liadHri2eD7YrwrTyVblijqHAkp7KMiyiKgltf I7fjGFn3amF+T2+RPxcFeIiz+34m3JgcGZgQeBT8gjqlOooNY2TVe9uqOvHzs3JgGxTI dat5WDGxRz7wGFmVBSqXe1bcNh6O1V74jcldrrzExtdvbrEA+qW0UAeStlIV0602OE48 sHNK8cuMbAGGTvV6ZvoYZ0i59G28HBcrfxhX6e95w/qGbvkHUuWX3ao3v7WNwnA9sfv4 Biyg== X-Gm-Message-State: AFeK/H045uYwsb3wShSnBEjUdqQclatgJ3W1GXmaUxQHW7X/Xp9fQwoEbg1faY81x8mdVlkyY3x0e/PtarQSUg== X-Received: by 10.107.168.21 with SMTP id r21mr14428031ioe.45.1490499430038; Sat, 25 Mar 2017 20:37:10 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.35.213 with HTTP; Sat, 25 Mar 2017 20:37:09 -0700 (PDT) From: Daniel Migault Date: Sat, 25 Mar 2017 23:37:09 -0400 X-Google-Sender-Auth: tTzAI4DpHJGeMIgEiRGJ6fVxqM4 Message-ID: To: curdle Content-Type: multipart/alternative; boundary=001a114215e810ca97054b99f1ac Archived-At: Subject: [Curdle] draft-ietf-curdle-ssh-modp-dh-sha2-02 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, 26 Mar 2017 03:37:12 -0000 --001a114215e810ca97054b99f1ac Content-Type: text/plain; charset=UTF-8 Hi, Please find some comments for draft-ietf-curdle-ssh-modp-dh-sha2-02. I suspect the text above should be removed. """ The method of key exchange used for the name "gss-group14-sha256-*" is the same as that for "gss-group14-sha1-*" except that the SHA2-256 hash algorithm is used. """ Yours, Daniel --001a114215e810ca97054b99f1ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Please find some comments for = draft-ietf-curdle-ssh-modp-dh-sha2-02.

I suspect the text abo= ve should be removed.
"""
=C2=A0= =C2=A0 The method of key exchange used for the name "gss-group14-sha25= 6-*"
=C2=A0=C2=A0 is the same as that for "gss-group14-sha1-*&= quot; except that the SHA2-256
=C2=A0=C2=A0 hash algorithm is used.
&= quot;""

Yours,
Daniel
<= /div>
--001a114215e810ca97054b99f1ac-- From nobody Sun Mar 26 04:22: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 29009126C3D for ; Sun, 26 Mar 2017 04:22:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_HTML_ATTACH=0.01] 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 9pnWMVr6xiGm for ; Sun, 26 Mar 2017 04:22:02 -0700 (PDT) Received: from rila.superhosting.bg (rila.superhosting.bg [91.196.125.212]) (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 E74F11243FE for ; Sun, 26 Mar 2017 04:22:01 -0700 (PDT) Received: from [78.128.48.21] (port=35546 helo=[192.168.0.10]) by rila.superhosting.bg with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cs6FC-002yjR-L0 for curdle@ietf.org; Sun, 26 Mar 2017 14:21:58 +0300 Message-ID: <58D7A456.9040609@roumenpetrov.info> Date: Sun, 26 Mar 2017 14:21:58 +0300 From: =?UTF-8?B?0KDRg9C80LXQvSDQn9C10YLRgNC+0LI=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Firefox/33.0 SeaMonkey/2.30 MIME-Version: 1.0 To: curdle@ietf.org References: <148823325745.13859.1818801191554779419.idtracker@ietfa.amsl.com> <58CCEF4F.7000902@roumenpetrov.info> <9EABA431E21041239B7D2B164FAA5AC3@Khan> <58CD46B0.9010902@roumenpetrov.info> In-Reply-To: Content-Type: multipart/mixed; boundary="------------050706070407040501030107" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - rila.superhosting.bg X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - roumenpetrov.info X-Get-Message-Sender-Via: rila.superhosting.bg: authenticated_id: master78@roumenpetrov.info X-Authenticated-Sender: rila.superhosting.bg: master78@roumenpetrov.info X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [Curdle] Comments on draft-ietf-curdle-rsa-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: Sun, 26 Mar 2017 11:22:06 -0000 This is a multi-part message in MIME format. --------------050706070407040501030107 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Denis and members of curdle group, denis bider (Bitvise) wrote: > Hello Roumen: > > >> Quote from rfc4252: >> byte SSH_MSG_USERAUTH_REQUEST >> [...] >> string   public key algorithm name <<<<----- > > Thank you for pointing this out. This is an important point. The > document needs a more formal discussion to properly introduce the > concept for "signature algorithm". > > Draft submissions are currently off, but I have clarified this in my > local version with an additional section that discusses the terms > "public key algorithm" and "signature algorithm" in detail. It also > points out two places in RFC4252 and RFC4253 which subtly change > meaning, and now encode a signature algorithm name. > > Since I cannot submit it right now, I attach a copy of my current > local version. I have objection to change meaning of public key algorithm identifier . It is well defined in chapter 6.6. "Public Key Algorithms" of RFC 4253. I cannot understand the goal of such change ("*Signature Algorithm as Distinct Aspect of* Public Key *Algorithm*"). You define new "public key algorithm identifier" and signature identifier is same although it not necessary as is by default "Public key/certificate formats that do not explicitly specify a signature format identifier MUST use the public key/certificate format identifier as the signature identifier." It seems to me you would like to swap(replace) "public key" with "signature" in all RFC documents with this document(draft). Why to redefineconcept? Is not more easy to define new public-key algorithms? Such definition does not require relation with server extension. If server extension is not accepted then "rsa-sha2" should be canceled (suspended). [SNIP] Regards, Roumen Petrov P.S. attachment "rsa-sha2-03_vs_04.html" is deference in html format between v3 and v4. --------------050706070407040501030107 Content-Type: text/html; name="rsa-sha2-03_vs_04.html" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="rsa-sha2-03_vs_04.html" PGh0bWw+PGhlYWQ+PHRpdGxlPndkaWZmIGRyYWZ0LWlldGYtY3VyZGxlLXJzYS1zaGEyLTAz LnR4dCBkcmFmdC1pZXRmLWN1cmRsZS1yc2Etc2hhMi0wNC50eHQ8L3RpdGxlPjwvaGVhZD48 Ym9keT4KPHByZT4KCgpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgRC4gQmlkZXIKVXBkYXRlczogNDI1MiwgNDI1MyAo aWYgYXBwcm92ZWQpICAgICAgICAgICAgICAgICAgICAgICAgQml0dmlzZSBMaW1pdGVkCklu dGVuZGVkIHN0YXR1czogU3RhbmRhcmRzIFRyYWNrICAgICAgICAgICAgICAgICAgICAgICA8 c3RyaWtlPjxmb250IGNvbG9yPXJlZD5GZWJydWFyeSAyNyw8L2ZvbnQ+PC9zdHJpa2U+ICAg ICAgICAgICAgICAgICAgICAgICAgICA8c3Ryb25nPjxmb250IGNvbG9yPWdyZWVuPk1hcmNo IDIzLDwvZm9udD48L3N0cm9uZz4gMjAxNwpFeHBpcmVzOiA8c3RyaWtlPjxmb250IGNvbG9y PXJlZD5BdWd1c3QgMjcsPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPWdy ZWVuPlNlcHRlbWJlciAyMyw8L2ZvbnQ+PC9zdHJvbmc+IDIwMTcKCgogICAgICBVc2Ugb2Yg UlNBIEtleXMgd2l0aCBTSEEtMiAyNTYgYW5kIDUxMiBpbiBTZWN1cmUgU2hlbGwgKFNTSCkK ICAgICAgICAgICAgICAgICAgIGRyYWZ0LWlldGYtY3VyZGxlLXJzYS1zaGEyLTAzLnR4dAoK CkFic3RyYWN0CgogIFRoaXMgbWVtbyBkZWZpbmVzIGFuIGFsZ29yaXRobSBuYW1lLCBwdWJs aWMga2V5IGZvcm1hdCwgYW5kIHNpZ25hdHVyZQogIGZvcm1hdCBmb3IgdXNlIG9mIFJTQSBr ZXlzIHdpdGggU0hBLTIgPHN0cmlrZT48Zm9udCBjb2xvcj1yZWQ+NTEyPC9mb250Pjwvc3Ry aWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPWdyZWVuPmhhc2hpbmc8L2ZvbnQ+PC9zdHJvbmc+ IGZvciBzZXJ2ZXIgYW5kIGNsaWVudAogIGF1dGhlbnRpY2F0aW9uIGluIFNTSCBjb25uZWN0 aW9ucy4KClN0YXR1cwoKICBUaGlzIEludGVybmV0LURyYWZ0IGlzIHN1Ym1pdHRlZCBpbiBm dWxsIGNvbmZvcm1hbmNlIHdpdGggdGhlCiAgcHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJD UCA3OS4KCiAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUg SW50ZXJuZXQgRW5naW5lZXJpbmcgVGFzawogIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBh bmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiAgTm90ZSB0aGF0IG90aGVyCiAgZ3JvdXBzIG1heSBh bHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLgoK ICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhp bXVtIG9mIHNpeCBtb250aHMKICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBv YnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQogIHRpbWUuIEl0IGlzIGluYXBw cm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UgbWF0ZXJpYWwK ICBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iCgog IFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBh dAogIGh0dHA6Ly93d3cuaWV0Zi5vcmcvMWlkLWFic3RyYWN0cy5odG1sCgogIFRoZSBsaXN0 IG9mIEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNzZWQg YXQKICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sCgpDb3B5cmlnaHQKCiAgQ29w eXJpZ2h0IChjKSAyMDE3IElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQg YXMgdGhlCiAgZG9jdW1lbnQgYXV0aG9ycy4gIEFsbCByaWdodHMgcmVzZXJ2ZWQuCgogIFRo aXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3Mg TGVnYWwKICBQcm92aXNpb25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRzCiAgKGh0dHA6 Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9uIHRoZSBkYXRl IG9mCiAgcHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVudC4gIFBsZWFzZSByZXZpZXcgdGhl c2UgZG9jdW1lbnRzCiAgY2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2NyaWJlIHlvdXIgcmlnaHRz IGFuZCByZXN0cmljdGlvbnMgd2l0aCByZXNwZWN0CiAgdG8gdGhpcyBkb2N1bWVudC4gIENv ZGUgQ29tcG9uZW50cyBleHRyYWN0ZWQgZnJvbSB0aGlzIGRvY3VtZW50IG11c3QKICBpbmNs dWRlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UgdGV4dCBhcyBkZXNjcmliZWQgaW4gU2VjdGlv biA0LmUgb2YKICB0aGUgVHJ1c3QgTGVnYWwgUHJvdmlzaW9ucyBhbmQgYXJlIHByb3ZpZGVk IHdpdGhvdXQgd2FycmFudHkgYXMKICBkZXNjcmliZWQgaW4gdGhlIFNpbXBsaWZpZWQgQlNE IExpY2Vuc2UuCgoKCgpCaWRlciAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMV0KDApJbnRlcm5ldC1EcmFmdCAgICAg ICAgIFJTQSBLZXlzIHdpdGggU0hBLTIgaW4gU1NIICAgICAgICAgIDxzdHJpa2U+PGZvbnQg Y29sb3I9cmVkPkZlYnJ1YXJ5PC9mb250Pjwvc3RyaWtlPiAgICAgICAgICAgICA8c3Ryb25n Pjxmb250IGNvbG9yPWdyZWVuPk1hcmNoPC9mb250Pjwvc3Ryb25nPiAyMDE3CgoKMS4gIE92 ZXJ2aWV3IGFuZCBSYXRpb25hbGUKCiAgU2VjdXJlIFNoZWxsIChTU0gpIGlzIGEgY29tbW9u IHByb3RvY29sIGZvciBzZWN1cmUgY29tbXVuaWNhdGlvbiBvbgogIHRoZSBJbnRlcm5ldC4g SW4gW1JGQzQyNTNdLCBTU0ggb3JpZ2luYWxseSBkZWZpbmVkIHRoZSBzaWduYXR1cmUKICBt ZXRob2RzICJzc2gtcnNhIiBmb3Igc2VydmVyIGFuZCBjbGllbnQgYXV0aGVudGljYXRpb24g dXNpbmcgUlNBIHdpdGgKICBTSEEtMSwgYW5kICJzc2gtZHNzIiB1c2luZyAxMDI0LWJpdCBE U0EgYW5kIFNIQS0xLgoKICBBIGRlY2FkZSBsYXRlciwgdGhlc2Ugc2lnbmF0dXJlIG1ldGhv ZHMgYXJlIGNvbnNpZGVyZWQgZGVmaWNpZW50LgogIEZvciBVUyBnb3Zlcm5tZW50IHVzZSwg TklTVCBoYXMgZGlzYWxsb3dlZCAxMDI0LWJpdCBSU0EgYW5kIERTQSwgYW5kCiAgdXNlIG9m IFNIQS0xIGZvciBzaWduaW5nIFs4MDAtMTMxQV0uCgogIFRoaXMgbWVtbyA8c3RyaWtlPjxm b250IGNvbG9yPXJlZD5kZWZpbmVzPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNv bG9yPWdyZWVuPmludHJvZHVjZXM8L2ZvbnQ+PC9zdHJvbmc+IGEgPHN0cm9uZz48Zm9udCBj b2xvcj1ncmVlbj5kaXN0aW5jdGlvbiBiZXR3ZWVuIHB1YmxpYyBrZXkgYW5kIHNpZ25hdHVy ZQogIGFsZ29yaXRobXMgaW4gU1NILCBhbmQgZGVmaW5lczwvZm9udD48L3N0cm9uZz4gbmV3 IDxzdHJvbmc+PGZvbnQgY29sb3I9Z3JlZW4+c2lnbmF0dXJlPC9mb250Pjwvc3Ryb25nPiBh bGdvcml0aG0gPHN0cmlrZT48Zm9udCBjb2xvcj1yZWQ+bmFtZTwvZm9udD48L3N0cmlrZT4g PHN0cm9uZz48Zm9udCBjb2xvcj1ncmVlbj5uYW1lczwvZm9udD48L3N0cm9uZz4gYWxsb3dp bmcKICBmb3IgaW50ZXJvcGVyYWJsZSB1c2Ugb2YgPHN0cm9uZz48Zm9udCBjb2xvcj1ncmVl bj5leGlzdGluZyBhbmQgbmV3PC9mb250Pjwvc3Ryb25nPiBSU0Ega2V5cyB3aXRoIFNIQS0y IDxzdHJpa2U+PGZvbnQgY29sb3I9cmVkPjI1NiBhbmQgU0hBLTIgNTEyLCBhbmQgYSBtZWNo YW5pc20gZm9yIHNlcnZlcnMNCiAgdG8gaW5mb3JtIFNTSCBjbGllbnRzIG9mIHNpZ25hdHVy ZSBhbGdvcml0aG1zIHRoZXkgc3VwcG9ydCBhbmQgYWNjZXB0LjwvZm9udD48L3N0cmlrZT4g PHN0cm9uZz48Zm9udCBjb2xvcj1ncmVlbj5oYXNoaW5nLjwvZm9udD48L3N0cm9uZz4KCjEu MS4gIFJlcXVpcmVtZW50cyBUZXJtaW5vbG9neQoKICBUaGUga2V5IHdvcmRzICJNVVNUIiwg Ik1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsCiAgIlNIT1VM RCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwi IGluIHRoaXMKICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVk IGluIFtSRkMyMTE5XS4KCgoyLiAgPHN0cm9uZz48Zm9udCBjb2xvcj1ncmVlbj5TaWduYXR1 cmUgQWxnb3JpdGhtIGFzIERpc3RpbmN0IEFzcGVjdCBvZjwvZm9udD48L3N0cm9uZz4gUHVi bGljIEtleSA8c3Ryb25nPjxmb250IGNvbG9yPWdyZWVuPkFsZ29yaXRobQoKICBJbiBbUkZD NDI1Ml0sIHRoZSBjb25jZXB0ICJwdWJsaWMga2V5IGFsZ29yaXRobSIgaXMgdXNlZCB0byBl c3RhYmxpc2gKICBhIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIG9uZSBhbGdvcml0aG0gbmFtZSwg YW5kOgoKICBBLiBQcm9jZWR1cmVzIHVzZWQgdG8gZ2VuZXJhdGUgYW5kIHZhbGlkYXRlIGEg cHJpdmF0ZS9wdWJsaWMga2V5cGFpci4KICBCLiBBIGZvcm1hdCB1c2VkIHRvIGVuY29kZSBh IHB1YmxpYyBrZXkuCiAgQy4gUHJvY2VkdXJlcyB1c2VkIHRvIGNhbGN1bGF0ZSwgZW5jb2Rl LCBhbmQgdmVyaWZ5IGEgc2lnbmF0dXJlLgoKICBUaGlzIGRvY3VtZW50IG5hcnJvd3MgdGhl IHRlcm0gInB1YmxpYyBrZXkgYWxnb3JpdGhtIiB0byBtZWFuIEEgYW5kIEIsCiAgdGhvdWdo IGl0IGNhbiBzdGlsbCBwb3RlbnRpYWxseSBpbXBseSBDIHdoZW4gYSBwdWJsaWMga2V5IGFs Z29yaXRobSBpcwogIGFzc29jaWF0ZWQgd2l0aCBvbmx5IG9uZSBzaWduYXR1cmUgYWxnb3Jp dGhtLiBBIG5ldyB0ZXJtLCAic2lnbmF0dXJlCiAgYWxnb3JpdGhtIiwgaXMgaW50cm9kdWNl ZCB0byByZWZlciBzcGVjaWZpY2FsbHkgdG8gQy4KCiAgVGhpcyBhZmZlY3RzIHRoZSBtZWFu aW5nIG9mIHRoZSBmaWVsZCAic2VydmVyX2hvc3Rfa2V5X2FsZ29yaXRobXMiIGluCiAgdGhl IG1lc3NhZ2UgU1NIX01TR19LRVhJTklUIChbUkZDNDI1M10pLiBXaXRoIHRoaXMgZG9jdW1l bnQsIHRoaXMKICBmaWVsZCBub3cgcmVmZXJzIHNwZWNpZmljYWxseSB0byBzaWduYXR1cmUs IG5vdCBwdWJsaWMga2V5IGFsZ29yaXRobXMuCgogIFRoaXMgYWxzbyBhZmZlY3RzIHRoZSBt ZXNzYWdlIFNTSF9NU0dfVVNFUkFVVEhfUkVRVUVTVCB3aGVuIHVzZWQgd2l0aAogIHRoZSAi cHVibGlja2V5IiBhdXRoZW50aWNhdGlvbiBtZXRob2QgYXMgZGVmaW5lZCBpbiBbUkZDNDI1 Ml0uIFdpdGgKICB0aGlzIGRvY3VtZW50LCB0aGUgZGVmaW5pdGlvbiBvZiB0aGlzIG1lc3Nh Z2UgaXMgdXBkYXRlZCBhcyBmb2xsb3dzOgoKICAgICAgYnl0ZSAgICAgIFNTSF9NU0dfVVNF UkFVVEhfUkVRVUVTVAogICAgICBzdHJpbmcgICAgdXNlciBuYW1lIGluIElTTy0xMDY0NiBV VEYtOCBlbmNvZGluZyBbUkZDMzYyOV0KICAgICAgc3RyaW5nICAgIHNlcnZpY2UgbmFtZSBp biBVUy1BU0NJSQogICAgICBzdHJpbmcgICAgInB1YmxpY2tleSIKICAgICAgYm9vbGVhbiAg IEZBTFNFCiAgICAgIHN0cmluZyAgICBzaWduYXR1cmUgYWxnb3JpdGhtIG5hbWUKICAgICAg c3RyaW5nICAgIHB1YmxpYyBrZXkgYmxvYgoKCkJpZGVyICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAyXQoMCkludGVy bmV0LURyYWZ0ICAgICAgICAgUlNBIEtleXMgd2l0aCBTSEEtMiBpbiBTU0ggICAgICAgICAg ICAgTWFyY2ggMjAxNwoKCiAgVGhlIGZvcm1hdCBvZiB0aGUgbWVzc2FnZSByZW1haW5zIHVu Y2hhbmdlZC4gVGhlIGNoYW5nZSBpcyBpbiB0aGUgbGluZQogIHdoaWNoIG5vdyByZWFkcyAi c2lnbmF0dXJlIGFsZ29yaXRobSBuYW1lIi4gVGhpcyB1c2VkIHRvIHJlYWQgInB1YmxpYwog IGtleSBhbGdvcml0aG0gbmFtZSIuCgogIFRoZXNlIGNoYW5nZXMgZG8gbm90IGFmZmVjdCBr ZXkgdHlwZXMgb3RoZXIgdGhhbiBSU0EuIE90aGVyIHB1YmxpYyBrZXkKICBhbGdvcml0aG1z IGNvbnRpbnVlIHRvIHVzZSBvbmUgc2lnbmF0dXJlIGFsZ29yaXRobSBvZiB0aGUgc2FtZSBu YW1lLgoKICBUaGVyZSBpcyBubyBpbXBhY3Qgb24gZXhpc3RpbmcgaW1wbGVtZW50YXRpb25z IHRoYXQgc3VwcG9ydCBSU0Ega2V5cwogIG9ubHkgYXMgInNzaC1yc2EiLiBTdWNoIGltcGxl bWVudGF0aW9ucyBjb250aW51ZSB0byB1c2UgdGhlIHB1YmxpYyBrZXkKICBhbGdvcml0aG0g InNzaC1yc2EiLCBhbmQgdGhlIHNpZ25hdHVyZSBhbGdvcml0aG0gb2YgdGhlIHNhbWUgbmFt ZS4KCgozLiAgTmV3IFJTQSBTaWduYXR1cmU8L2ZvbnQ+PC9zdHJvbmc+IEFsZ29yaXRobXMK CiAgVGhpcyBtZW1vIGFkb3B0cyB0aGUgc3R5bGUgYW5kIGNvbnZlbnRpb25zIG9mIFtSRkM0 MjUzXSBpbiBzcGVjaWZ5aW5nCiAgaG93IHVzZSBvZiBhIHNpZ25hdHVyZSBhbGdvcml0aG0g aXMgaW5kaWNhdGVkIGluIFNTSC4KCiAgVGhlIGZvbGxvd2luZyBuZXcgc2lnbmF0dXJlIGFs Z29yaXRobXMgYXJlIGRlZmluZWQ6CgogICAgcnNhLXNoYTItMjU2ICAgIFJFQ09NTUVOREVE ICAgIHNpZ24gICAgUmF3IFJTQSBrZXkKICAgIHJzYS1zaGEyLTUxMiAgICBPUFRJT05BTCAg ICAgICBzaWduICAgIFJhdyBSU0Ega2V5CgogIFRoZXNlIDxzdHJpa2U+PGZvbnQgY29sb3I9 cmVkPnNpZ25hdHVyZTwvZm9udD48L3N0cmlrZT4gYWxnb3JpdGhtcyBhcmUgc3VpdGFibGUg Zm9yIHVzZSBib3RoIGluIHRoZSBTU0ggdHJhbnNwb3J0IGxheWVyCiAgW1JGQzQyNTNdIGZv ciBzZXJ2ZXIgYXV0aGVudGljYXRpb24sIGFuZCBpbiB0aGUgYXV0aGVudGljYXRpb24gbGF5 ZXIKICBbUkZDNDI1Ml0gZm9yIGNsaWVudCBhdXRoZW50aWNhdGlvbi4KCiAgU2luY2UgUlNB IGtleXMgYXJlIG5vdCBkZXBlbmRlbnQgb24gdGhlIGNob2ljZSBvZiBoYXNoIGZ1bmN0aW9u LCA8c3RyaWtlPjxmb250IGNvbG9yPXJlZD5ib3RoPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25n Pjxmb250IGNvbG9yPWdyZWVuPnRoZTwvZm9udD48L3N0cm9uZz4KICBuZXcgPHN0cm9uZz48 Zm9udCBjb2xvcj1ncmVlbj5zaWduYXR1cmU8L2ZvbnQ+PC9zdHJvbmc+IGFsZ29yaXRobXMg PHN0cmlrZT48Zm9udCBjb2xvcj1yZWQ+cmV1c2U8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+ PGZvbnQgY29sb3I9Z3JlZW4+YXJlIGRlZmluZWQgYXMgYXNwZWN0cyBvZjwvZm9udD48L3N0 cm9uZz4gdGhlIDxzdHJvbmc+PGZvbnQgY29sb3I9Z3JlZW4+ZXhpc3RpbmcKICAic3NoLXJz YSI8L2ZvbnQ+PC9zdHJvbmc+IHB1YmxpYyBrZXkgPHN0cmlrZT48Zm9udCBjb2xvcj1yZWQ+ Zm9ybWF0IG9mPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPWdyZWVuPmFs Z29yaXRobS4gVGhpcyBtZWFucyB0aGUgbmV3IGFsZ29yaXRobXMgcmV1c2U8L2ZvbnQ+PC9z dHJvbmc+CiAgdGhlIDxzdHJpa2U+PGZvbnQgY29sb3I9cmVkPmV4aXN0aW5nPC9mb250Pjwv c3RyaWtlPiAic3NoLXJzYSINCiAgPHN0cmlrZT48Zm9udCBjb2xvcj1yZWQ+YWxnb3JpdGht PC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPWdyZWVuPnB1YmxpYyBrZXkg Zm9ybWF0PC9mb250Pjwvc3Ryb25nPiBhcyBkZWZpbmVkIGluIFtSRkM0MjUzXToKCiAgICBz dHJpbmcgICAgInNzaC1yc2EiCiAgICBtcGludCAgICAgZQogICAgbXBpbnQgICAgIG4KCiAg QWxsIGFzcGVjdHMgb2YgdGhlICJzc2gtcnNhIiBmb3JtYXQgYXJlIGtlcHQsIGluY2x1ZGlu ZyB0aGUgZW5jb2RlZAogIHN0cmluZyA8c3RyaWtlPjxmb250IGNvbG9yPXJlZD4ic3NoLXJz YSIsIGluIG9yZGVyIHRvIGFsbG93IHVzZXJzJzwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48 Zm9udCBjb2xvcj1ncmVlbj4ic3NoLXJzYSIuIFRoaXMgYWxsb3dzPC9mb250Pjwvc3Ryb25n PiBleGlzdGluZyBSU0Ega2V5cyB0byBiZSB1c2VkIHdpdGggdGhlCiAgbmV3IHNpZ25hdHVy ZSBmb3JtYXRzLCB3aXRob3V0IHJlcXVpcmluZyByZS1lbmNvZGluZywgb3IgYWZmZWN0aW5n CiAgYWxyZWFkeSB0cnVzdGVkIGtleSBmaW5nZXJwcmludHMuCgogIFNpZ25pbmcgYW5kIHZl cmlmeWluZyB1c2luZyB0aGVzZSBhbGdvcml0aG1zIGlzIHBlcmZvcm1lZCBhY2NvcmRpbmcg dG8KICB0aGUgUlNBU1NBLVBLQ1MxLXYxXzUgc2NoZW1lIGluIFtSRkMzNDQ3XSB1c2luZyBT SEEtMiBbRklQUy0xODAtNF0gYXMKICBoYXNoOyBNR0YxIGFzIG1hc2sgZnVuY3Rpb247IGFu ZCBzYWx0IGxlbmd0aCBlcXVhbCB0byBoYXNoIHNpemUuDQoNCg0KPHN0cmlrZT48Zm9udCBj b2xvcj1yZWQ+QmlkZXIgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFtQYWdlIDJdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAg IFJTQSBLZXlzIHdpdGggU0hBLTIgaW4gU1NIICAgICAgICAgIEZlYnJ1YXJ5IDIwMTc8L2Zv bnQ+PC9zdHJpa2U+CgogIEZvciB0aGUgYWxnb3JpdGhtICJyc2Etc2hhMi0yNTYiLCB0aGUg aGFzaCB1c2VkIGlzIFNIQS0yIDI1Ni4KICBGb3IgdGhlIGFsZ29yaXRobSAicnNhLXNoYTIt NTEyIiwgdGhlIGhhc2ggdXNlZCBpcyBTSEEtMiA1MTIuCgogIFRoZSByZXN1bHRpbmcgc2ln bmF0dXJlIGlzIGVuY29kZWQgYXMgZm9sbG93czoKCiAgICBzdHJpbmcgICAgInJzYS1zaGEy LTI1NiIgLyAicnNhLXNoYTItNTEyIgogICAgc3RyaW5nICAgIHJzYV9zaWduYXR1cmVfYmxv YgoKCjxzdHJvbmc+PGZvbnQgY29sb3I9Z3JlZW4+QmlkZXIgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDNdCgwKSW50 ZXJuZXQtRHJhZnQgICAgICAgICBSU0EgS2V5cyB3aXRoIFNIQS0yIGluIFNTSCAgICAgICAg ICAgICBNYXJjaCAyMDE3PC9mb250Pjwvc3Ryb25nPgoKCiAgVGhlIHZhbHVlIGZvciAncnNh X3NpZ25hdHVyZV9ibG9iJyBpcyBlbmNvZGVkIGFzIGEgc3RyaW5nIGNvbnRhaW5pbmcKICBT IC0gYW4gb2N0ZXQgc3RyaW5nIHdoaWNoIGlzIHRoZSBvdXRwdXQgb2YgUlNBU1NBLVBLQ1Mx LXYxXzUsIG9mCiAgbGVuZ3RoIGVxdWFsIHRvIHRoZSBsZW5ndGggaW4gb2N0ZXRzIG9mIHRo ZSBSU0EgbW9kdWx1cy4NCiAgDQo8c3RyaWtlPjxmb250IGNvbG9yPXJlZD4yLjEuPC9mb250 Pjwvc3RyaWtlPgoKPHN0cm9uZz48Zm9udCBjb2xvcj1ncmVlbj4zLjEuPC9mb250Pjwvc3Ry b25nPiAgVXNlIGZvciBzZXJ2ZXIgYXV0aGVudGljYXRpb24KCiAgVG8gZXhwcmVzcyBzdXBw b3J0IGFuZCBwcmVmZXJlbmNlIGZvciBvbmUgb3IgYm90aCBvZiB0aGVzZSBhbGdvcml0aG1z CiAgZm9yIHNlcnZlciBhdXRoZW50aWNhdGlvbiwgdGhlIFNTSCBjbGllbnQgb3Igc2VydmVy IGluY2x1ZGVzIG9uZSBvcgogIGJvdGggYWxnb3JpdGhtIG5hbWVzLCAicnNhLXNoYTItMjU2 IiBhbmQvb3IgInJzYS1zaGEyLTUxMiIsIGluIHRoZQogIG5hbWUtbGlzdCBmaWVsZCAic2Vy dmVyX2hvc3Rfa2V5X2FsZ29yaXRobXMiIGluIHRoZSBTU0hfTVNHX0tFWElOSVQKICBwYWNr ZXQgW1JGQzQyNTNdLiBJZiBvbmUgb2YgdGhlIHR3byBob3N0IGtleSBhbGdvcml0aG1zIGlz IG5lZ290aWF0ZWQsCiAgdGhlIHNlcnZlciBzZW5kcyBhbiAic3NoLXJzYSIgcHVibGljIGtl eSBhcyBwYXJ0IG9mIHRoZSBuZWdvdGlhdGVkIGtleQogIGV4Y2hhbmdlIG1ldGhvZCAoZS5n LiBpbiBTU0hfTVNHX0tFWERIX1JFUExZKSwgYW5kIGVuY29kZXMgYSBzaWduYXR1cmUKICB3 aXRoIHRoZSBhcHByb3ByaWF0ZSBzaWduYXR1cmUgYWxnb3JpdGhtIG5hbWUgLSBlaXRoZXIg InJzYS1zaGEyLTI1NiIsCiAgb3IgInJzYS1zaGEyLTUxMiIuDQogIA0KPHN0cmlrZT48Zm9u dCBjb2xvcj1yZWQ+Mi4yLjwvZm9udD48L3N0cmlrZT4KCjxzdHJvbmc+PGZvbnQgY29sb3I9 Z3JlZW4+My4yLjwvZm9udD48L3N0cm9uZz4gIFVzZSBmb3IgY2xpZW50IGF1dGhlbnRpY2F0 aW9uCgogIFRvIHVzZSB0aGlzIGFsZ29yaXRobSBmb3IgY2xpZW50IGF1dGhlbnRpY2F0aW9u LCB0aGUgU1NIIGNsaWVudCBzZW5kcwogIGFuIFNTSF9NU0dfVVNFUkFVVEhfUkVRVUVTVCBt ZXNzYWdlIFtSRkM0MjUyXSBlbmNvZGluZyB0aGUgInB1YmxpY2tleSIKICBtZXRob2QsIGFu ZCBlbmNvZGluZyB0aGUgc3RyaW5nIGZpZWxkICJwdWJsaWMga2V5IGFsZ29yaXRobSBuYW1l IiB3aXRoCiAgdGhlIHZhbHVlICJyc2Etc2hhMi0yNTYiIG9yICJyc2Etc2hhMi01MTIiLiBU aGUgInB1YmxpYyBrZXkgYmxvYiIKICBmaWVsZCBlbmNvZGVzIHRoZSBSU0EgcHVibGljIGtl eSB1c2luZyB0aGUgInNzaC1yc2EiIGFsZ29yaXRobSBuYW1lLgogIFRoZSBzaWduYXR1cmUg ZmllbGQsIGlmIHByZXNlbnQsIGVuY29kZXMgYSBzaWduYXR1cmUgdXNpbmcgYW4KICBhbGdv cml0aG0gbmFtZSB0aGF0IE1VU1QgbWF0Y2ggdGhlIFNTSCBhdXRoZW50aWNhdGlvbiByZXF1 ZXN0IC0gZWl0aGVyCiAgInJzYS1zaGEyLTI1NiIsIG9yICJyc2Etc2hhMi01MTIiLgoKICBG b3IgZXhhbXBsZSwgYW4gU1NIICJwdWJsaWNrZXkiIGF1dGhlbnRpY2F0aW9uIHJlcXVlc3Qg dXNpbmcgYW4KICAicnNhLXNoYTItNTEyIiBzaWduYXR1cmUgd291bGQgYmUgcHJvcGVybHkg ZW5jb2RlZCBhcyBmb2xsb3dzOgoKICAgIGJ5dGUgICAgICBTU0hfTVNHX1VTRVJBVVRIX1JF UVVFU1QKICAgIHN0cmluZyAgICB1c2VyIG5hbWUKICAgIHN0cmluZyAgICBzZXJ2aWNlIG5h bWUKICAgIHN0cmluZyAgICAicHVibGlja2V5IgogICAgYm9vbGVhbiAgIFRSVUUKICAgIHN0 cmluZyAgICAicnNhLXNoYTItNTEyIgogICAgc3RyaW5nICAgIHB1YmxpYyBrZXkgYmxvYjoK ICAgICAgICBzdHJpbmcgICAgInNzaC1yc2EiCiAgICAgICAgbXBpbnQgICAgIGUKICAgICAg ICBtcGludCAgICAgbgogICAgc3RyaW5nICAgIHNpZ25hdHVyZToKICAgICAgICBzdHJpbmcg ICAgInJzYS1zaGEyLTUxMiIKICAgICAgICBzdHJpbmcgICAgcnNhX3NpZ25hdHVyZV9ibG9i DQogICAgDQoNCjxzdHJpa2U+PGZvbnQgY29sb3I9cmVkPkJpZGVyICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAzXQ0K DA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICBSU0EgS2V5cyB3aXRoIFNIQS0yIGluIFNTSCAg ICAgICAgICBGZWJydWFyeSAyMDE3DQoNCg0KMy48L2ZvbnQ+PC9zdHJpa2U+Cgo8c3Ryb25n Pjxmb250IGNvbG9yPWdyZWVuPjMuMy48L2ZvbnQ+PC9zdHJvbmc+ICBEaXNjb3Zlcnkgb2Yg c2lnbmF0dXJlIGFsZ29yaXRobXMgc3VwcG9ydGVkIGJ5IHNlcnZlcnMKCiAgSW1wbGVtZW50 YXRpb24gZXhwZXJpZW5jZSBoYXMgc2hvd24gdGhhdCB0aGVyZSBhcmUgc2VydmVycyB3aGlj aCBhcHBseQogIGF1dGhlbnRpY2F0aW9uIHBlbmFsdGllcyB0byBjbGllbnRzIGF0dGVtcHRp bmcgc2lnbmF0dXJlIGFsZ29yaXRobXMKICB3aGljaCB0aGUgU1NIIHNlcnZlciBkb2VzIG5v dCBzdXBwb3J0LgoKCgoKPHN0cm9uZz48Zm9udCBjb2xvcj1ncmVlbj5CaWRlciAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1Bh Z2UgNF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgIFJTQSBLZXlzIHdpdGggU0hBLTIgaW4g U1NIICAgICAgICAgICAgIE1hcmNoIDIwMTc8L2ZvbnQ+PC9zdHJvbmc+CgoKICBTZXJ2ZXJz IHRoYXQgYWNjZXB0IHJzYS1zaGEyLSogc2lnbmF0dXJlcyBmb3IgY2xpZW50IGF1dGhlbnRp Y2F0aW9uCiAgU0hPVUxEIGltcGxlbWVudCB0aGUgZXh0ZW5zaW9uIG5lZ290aWF0aW9uIG1l Y2hhbmlzbSBkZWZpbmVkIGluCiAgW1NTSC1FWFQtSU5GT10sIGluY2x1ZGluZyBlc3BlY2lh bGx5IHRoZSAic2VydmVyLXNpZy1hbGdzIiBleHRlbnNpb24uCgogIFdoZW4gYXV0aGVudGlj YXRpbmcgd2l0aCBhbiBSU0Ega2V5IGFnYWluc3QgYSBzZXJ2ZXIgdGhhdCBkb2VzIG5vdAog IGltcGxlbWVudCB0aGUgInNlcnZlci1zaWctYWxncyIgZXh0ZW5zaW9uLCBjbGllbnRzIE1B WSBkZWZhdWx0IHRvIGFuCiAgc3NoLXJzYSBzaWduYXR1cmUgdG8gYXZvaWQgYXV0aGVudGlj YXRpb24gcGVuYWx0aWVzLgoKCjQuICBJQU5BIENvbnNpZGVyYXRpb25zCgogIElBTkEgaXMg cmVxdWVzdGVkIHRvIHVwZGF0ZSB0aGUgIlNlY3VyZSBTaGVsbCAoU1NIKSBQcm90b2NvbAog IFBhcmFtZXRlcnMiIHJlZ2lzdHJ5LCB0byBleHRlbmQgdGhlIHRhYmxlIFB1YmxpYyBLZXkg QWxnb3JpdGhtIE5hbWVzOgoKICAtIFRvIHRoZSBpbW1lZGlhdGUgcmlnaHQgb2YgdGhlIGNv bHVtbiBQdWJsaWMgS2V5IEFsZ29yaXRobSBOYW1lLAogICAgYSBuZXcgY29sdW1uIGlzIHRv IGJlIGFkZGVkLCB0aXRsZWQgU2lnbmF0dXJlIEFsZ29yaXRobSBOYW1lLiBGb3IKICAgIGV4 aXN0aW5nIGVudHJpZXMsIHRoZSBjb2x1bW4gU2lnbmF0dXJlIEFsZ29yaXRobSBOYW1lIHNo b3VsZCBiZQogICAgYXNzaWduZWQgdGhlIHNhbWUgdmFsdWUgZm91bmQgdW5kZXIgUHVibGlj IEtleSBBbGdvcml0aG0gTmFtZS4KCiAgLSBJbW1lZGlhdGVseSBmb2xsb3dpbmcgdGhlIGV4 aXN0aW5nIGVudHJ5IGZvciAic3NoLXJzYSIsIHR3byBzaWJsaW5nCiAgICBlbnRyaWVzIGFy ZSB0byBiZSBhZGRlZDoKCiAgICBQLiBLLiBBbGcuIE5hbWUgICAgU2lnLiBBbGcuIE5hbWUg ICAgUmVmZXJlbmNlICAgICAgICAgIE5vdGUKICAgIHNzaC1yc2EgICAgICAgICAgICByc2Et c2hhMi0yNTYgICAgICBbdGhpcyBkb2N1bWVudF0gICAgU2VjdGlvbiA8c3RyaWtlPjxmb250 IGNvbG9yPXJlZD4yPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPWdyZWVu PjM8L2ZvbnQ+PC9zdHJvbmc+CiAgICBzc2gtcnNhICAgICAgICAgICAgcnNhLXNoYTItNTEy ICAgICAgW3RoaXMgZG9jdW1lbnRdICAgIFNlY3Rpb24gPHN0cmlrZT48Zm9udCBjb2xvcj1y ZWQ+MjwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj1ncmVlbj4zPC9mb250 Pjwvc3Ryb25nPgoKCjUuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucwoKICBUaGUgc2VjdXJp dHkgY29uc2lkZXJhdGlvbnMgb2YgW1JGQzQyNTNdIGFwcGx5IHRvIHRoaXMgZG9jdW1lbnQu CgogIFRoZSBOYXRpb25hbCBJbnN0aXR1dGUgb2YgU3RhbmRhcmRzIGFuZCBUZWNobm9sb2d5 IChOSVNUKSBTcGVjaWFsCiAgUHVibGljYXRpb24gODAwLTEzMUEgWzgwMC0xMzFBXSBkaXNh bGxvd3MgdGhlIHVzZSBvZiBSU0EgYW5kIERTQSBrZXlzCiAgc2hvcnRlciB0aGFuIDIwNDgg Yml0cyBmb3IgVVMgZ292ZXJubWVudCB1c2UgYWZ0ZXIgMjAxMy4gPHN0cmlrZT48Zm9udCBj b2xvcj1yZWQ+S2V5cyBvZiAyMDQ4DQogIGJpdHMgb3IgbGFyZ2VyIGFyZSBjb25zaWRlcmVk IGFjY2VwdGFibGUuPC9mb250Pjwvc3RyaWtlPiBUaGUgc2FtZQogIGRvY3VtZW50IGRpc2Fs bG93cyB0aGUgU0hBLTEgaGFzaCBmdW5jdGlvbiwgYXMgdXNlZCBpbiB0aGUgInNzaC1yc2Ei CiAgYW5kICJzc2gtZHNzIiBhbGdvcml0aG1zLCBmb3IgZGlnaXRhbCBzaWduYXR1cmUgZ2Vu ZXJhdGlvbiBhZnRlciAyMDEzLiA8c3RyaWtlPjxmb250IGNvbG9yPXJlZD5UaGUgU0hBLTIg ZmFtaWx5IG9mIGhhc2ggZnVuY3Rpb25zIGlzIHNlZW4gYXMgYWNjZXB0YWJsZS48L2ZvbnQ+ PC9zdHJpa2U+CgoKNi4gIFdoeSBubyBEU0E/CgogIEEgZHJhZnQgdmVyc2lvbiBvZiB0aGlz IG1lbW8gYWxzbyBkZWZpbmVkIGFuIGFsZ29yaXRobSBuYW1lIGZvciB1c2Ugb2YKICAyMDQ4 LWJpdCBhbmQgMzA3Mi1iaXQgRFNBIGtleXMgd2l0aCBhIDI1Ni1iaXQgc3ViZ3JvdXAgYW5k IFNIQS0yIDI1NgogIGhhc2hpbmcuIEl0IGlzIHBvc3NpYmxlIHRvIGltcGxlbWVudCBEU0Eg c2VjdXJlbHkgYnkgZ2VuZXJhdGluZyAiayIKICBkZXRlcm1pbmlzdGljYWxseSBhcyBwZXIg W1JGQzY5NzldLiBIb3dldmVyLCBhIHBsdXJhbGl0eSBvZiByZXZpZXdlcnMKICB3ZXJlIGNv bmNlcm5lZCB0aGF0IGltcGxlbWVudGVycyB3b3VsZCBjb250aW51ZSB0byB1c2UgbGlicmFy aWVzIHRoYXQNCiANCg0KPHN0cmlrZT48Zm9udCBjb2xvcj1yZWQ+QmlkZXIgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdl IDRdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgIFJTQSBLZXlzIHdpdGggU0hBLTIgaW4g U1NIICAgICAgICAgIEZlYnJ1YXJ5IDIwMTc8L2ZvbnQ+PC9zdHJpa2U+CiAgZ2VuZXJhdGUg ImsiIHJhbmRvbWx5LiBUaGlzIGlzIHZ1bG5lcmFibGUgdG8gYmlhc2VkICJrIiBnZW5lcmF0 aW9uLAogIGFuZCBleHRyZW1lbHkgdnVsbmVyYWJsZSB0byAiayIgcmV1c2UuCgogIFRoaXMg ZG9jdW1lbnQgdGhlcmVmb3JlIGFic3RhaW5zIGZyb20gZGVmaW5pbmcgbmV3IGFsZ29yaXRo bSBuYW1lcwogIGZvciBEU0EsIGFuZCByZWNvbW1lbmRzIFJTQSA8c3RyaWtlPjxmb250IGNv bG9yPXJlZD53aGVyZSB0aGlzIGlzIHByZWZlcnJlZCBvdmVyPC9mb250Pjwvc3RyaWtlPiA8 c3Ryb25nPjxmb250IGNvbG9yPWdyZWVuPmFuZC9vcjwvZm9udD48L3N0cm9uZz4gZWxsaXB0 aWMgY3VydmUgY3J5cHRvZ3JhcGh5LgoKCgo8c3Ryb25nPjxmb250IGNvbG9yPWdyZWVuPkJp ZGVyICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBbUGFnZSA1XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgUlNBIEtleXMgd2l0 aCBTSEEtMiBpbiBTU0ggICAgICAgICAgICAgTWFyY2ggMjAxNzwvZm9udD48L3N0cm9uZz4K Cgo3LiAgUmVmZXJlbmNlcwoKNy4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMKCiAgW0ZJUFMt MTgwLTRdCiAgICAgICAgICAgICAgTmF0aW9uYWwgSW5zdGl0dXRlIG9mIFN0YW5kYXJkcyBh bmQgVGVjaG5vbG9neSAoTklTVCksCiAgICAgICAgICAgICAgVW5pdGVkIFN0YXRlcyBvZiBB bWVyaWNhLCAiU2VjdXJlIEhhc2ggU3RhbmRhcmQgKFNIUykiLAogICAgICAgICAgICAgIEZJ UFMgUHVibGljYXRpb24gMTgwLTQsIEF1Z3VzdCAyMDE1LAogICAgICAgICAgICAgICZsdDto dHRwOi8vZHguZG9pLm9yZy8xMC42MDI4L05JU1QuRklQUy4xODAtNCZndDsuCgogIFtSRkMy MTE5XSAgIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRp Y2F0ZQogICAgICAgICAgICAgIFJlcXVpcmVtZW50IExldmVscyIsIEJDUCAxNCwgUkZDIDIx MTksIE1hcmNoIDE5OTcuCgogIFtSRkMzNDQ3XSAgIEpvbnNzb24sIEouIGFuZCBCLiBLYWxp c2tpLCAiUHVibGljLUtleSBDcnlwdG9ncmFwaHkKICAgICAgICAgICAgICBTdGFuZGFyZHMg KFBLQ1MpICMxOiBSU0EgQ3J5cHRvZ3JhcGh5IFNwZWNpZmljYXRpb25zCiAgICAgICAgICAg ICAgVmVyc2lvbiAyLjEiLCBSRkMgMzQ0NywgRmVicnVhcnkgMjAwMy4KCiAgW1JGQzQyNTJd ICAgWWxvbmVuLCBULiBhbmQgQy4gTG9udmljaywgRWQuLCAiVGhlIFNlY3VyZSBTaGVsbCAo U1NIKQogICAgICAgICAgICAgIEF1dGhlbnRpY2F0aW9uIFByb3RvY29sIiwgUkZDIDQyNTIs IEphbnVhcnkgMjAwNi4KCiAgW1JGQzQyNTNdICAgWWxvbmVuLCBULiBhbmQgQy4gTG9udmlj aywgRWQuLCAiVGhlIFNlY3VyZSBTaGVsbCAoU1NIKQogICAgICAgICAgICAgIFRyYW5zcG9y dCBMYXllciBQcm90b2NvbCIsIFJGQyA0MjUzLCBKYW51YXJ5IDIwMDYuCgo3LjIuICBJbmZv cm1hdGl2ZSBSZWZlcmVuY2VzCgogIFs4MDAtMTMxQV0gIE5hdGlvbmFsIEluc3RpdHV0ZSBv ZiBTdGFuZGFyZHMgYW5kIFRlY2hub2xvZ3kgKE5JU1QpLAogICAgICAgICAgICAgICJUcmFu c2l0aW9uczogUmVjb21tZW5kYXRpb24gZm9yIFRyYW5zaXRpb25pbmcgdGhlIFVzZSBvZgog ICAgICAgICAgICAgIENyeXB0b2dyYXBoaWMgQWxnb3JpdGhtcyBhbmQgS2V5IExlbmd0aHMi LCBOSVNUIFNwZWNpYWwKICAgICAgICAgICAgICBQdWJsaWNhdGlvbiA4MDAtMTMxQSwgSmFu dWFyeSAyMDExLCAmbHQ7aHR0cDovL2NzcmMubmlzdC5nb3YvCiAgICAgICAgICAgICAgcHVi bGljYXRpb25zL25pc3RwdWJzLzgwMC0xMzFBL3NwODAwLTEzMUEucGRmJmd0Oy4KCiAgW1JG QzQyNTBdICAgTGVodGluZW4sIFMuIGFuZCBDLiBMb252aWNrLCBFZC4sICJUaGUgU2VjdXJl IFNoZWxsIChTU0gpCiAgICAgICAgICAgICAgUHJvdG9jb2wgQXNzaWduZWQgTnVtYmVycyIs IFJGQyA0MjUwLCBKYW51YXJ5IDIwMDYuCgogIFtSRkM2OTc5XSAgIFBvcm5pbiwgVC4sICJE ZXRlcm1pbmlzdGljIFVzYWdlIG9mIHRoZSBEaWdpdGFsCiAgICAgICAgICAgICAgU2lnbmF0 dXJlIEFsZ29yaXRobSAoRFNBKSBhbmQgRWxsaXB0aWMgQ3VydmUgRGlnaXRhbAogICAgICAg ICAgICAgIFNpZ25hdHVyZSBBbGdvcml0aG0gKEVDRFNBKSIsIFJGQyA2OTc5LCBBdWd1c3Qg MjAxMy4KCiAgW1NTSC1FWFQtSU5GT10KICAgICAgICAgICAgICBCaWRlciwgRC4sICJFeHRl bnNpb24gTmVnb3RpYXRpb24gaW4gU2VjdXJlIFNoZWxsIChTU0gpIiwKICAgICAgICAgICAg ICBkcmFmdC1pZXRmLWN1cmRsZS1zc2gtZXh0LWluZm8tMDIudHh0LCBGZWJydWFyeSAyMDE3 LAogICAgICAgICAgICAgICZsdDtodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvCiAgICAg ICAgICAgICAgZHJhZnQtaWV0Zi1jdXJkbGUtc3NoLWV4dC1pbmZvLTAyJmd0Oy4KCgoKCgoK CgoKCkJpZGVyICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBbUGFnZSA8c3RyaWtlPjxmb250IGNvbG9yPXJlZD41XTwvZm9udD48 L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj1ncmVlbj42XTwvZm9udD48L3N0cm9uZz4K DApJbnRlcm5ldC1EcmFmdCAgICAgICAgIFJTQSBLZXlzIHdpdGggU0hBLTIgaW4gU1NIICAg ICAgICAgIDxzdHJpa2U+PGZvbnQgY29sb3I9cmVkPkZlYnJ1YXJ5PC9mb250Pjwvc3RyaWtl PiAgICAgICAgICAgICA8c3Ryb25nPjxmb250IGNvbG9yPWdyZWVuPk1hcmNoPC9mb250Pjwv c3Ryb25nPiAyMDE3CgoKQXV0aG9yJ3MgQWRkcmVzcwoKICBEZW5pcyBCaWRlcgogIEJpdHZp c2UgTGltaXRlZAogIFN1aXRlcyA0MS80MiwgVmljdG9yaWEgSG91c2UKICAyNiBNYWluIFN0 cmVldAogIEdJCgogIFBob25lOiArNTA2IDgzMTUgNjUxOQogIEVNYWlsOiBpZXRmLXNzaDNA ZGVuaXNiaWRlci5jb20KICBVUkk6ICAgaHR0cHM6Ly93d3cuYml0dmlzZS5jb20vCgoKQWNr bm93bGVkZ21lbnRzCgogIFRoYW5rcyB0byBKb24gQnJpZ2h0LCBOaWVscyBNb2VsbGVyLCBT dGVwaGVuIEZhcnJlbGwsIE1hcmsgRC4gQmF1c2hrZSwKICBKZWZmcmV5IEh1dHplbG1hbiwg SGFubm8gQm9lY2ssIFBldGVyIEd1dG1hbm4sIERhbWllbiBNaWxsZXIsIDxzdHJpa2U+PGZv bnQgY29sb3I9cmVkPmFuZDwvZm9udD48L3N0cmlrZT4gTWF0DQogIDxzdHJpa2U+PGZvbnQg Y29sb3I9cmVkPkJlcmNodG9sZDwvZm9udD48L3N0cmlrZT4KICA8c3Ryb25nPjxmb250IGNv bG9yPWdyZWVuPkJlcmNodG9sZCwgYW5kIFJvdW1lbiBQZXRyb3Y8L2ZvbnQ+PC9zdHJvbmc+ IGZvciA8c3RyaWtlPjxmb250IGNvbG9yPXJlZD5jb21tZW50czwvZm9udD48L3N0cmlrZT4g PHN0cm9uZz48Zm9udCBjb2xvcj1ncmVlbj5yZXZpZXdzLCBjb21tZW50cyw8L2ZvbnQ+PC9z dHJvbmc+IGFuZCBzdWdnZXN0aW9ucy4KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgpCaWRlciAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgW1BhZ2UgPHN0cmlrZT48Zm9udCBjb2xvcj1yZWQ+Nl08L2ZvbnQ+ PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9Z3JlZW4+N108L2ZvbnQ+PC9zdHJvbmc+ CgwKPC9wcmU+Cjxocj4KPHRhYmxlIHdpZHRoPSIxMDAlIj48dHIgYWxpZ249InJpZ2h0Ij48 dGQ+cnVtZW4gOiBTdW4sIDI2IE1hciAyMDE3IDEzOjM4OjU1ICswMzAwPC90ZD48L3RyPjwv dGFibGU+CjwvYm9keT48L2h0bWw+Cg== --------------050706070407040501030107-- From nobody Sun Mar 26 10:22:57 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 21ADA129659 for ; Sun, 26 Mar 2017 10:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.519 X-Spam-Level: **** X-Spam-Status: No, score=4.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_SORBS_HTTP=0.001, RCVD_IN_SORBS_SOCKS=1.927, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fbFSrDGp2IPV for ; Sun, 26 Mar 2017 10:22:54 -0700 (PDT) Received: from mail01.sigterm.no (mail01.sigterm.no [193.150.121.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00FD1126CE8 for ; Sun, 26 Mar 2017 10:22:42 -0700 (PDT) Received: from smtp.postman.i2p (i2p-outproxy01.privacysolutions.no [193.150.121.66]) by postman.meeh.i2p (Postfix) with ESMTP id 55B052E0FC9 for ; Sun, 26 Mar 2017 19:22:39 +0200 (CEST) X-Virus-Scanned: clamav-milter 0.97 on milter.postman.i2p To: David Benjamin , Russ Housley References: <7d6cfe29-8d4c-436e-fe8a-0cbee915b29e@mail.i2p> <20170311061838.879BAADF28@smtp.postman.i2p> <2DD56D786E600F45AC6BDE7DA4E8A8C118BA5C93@eusaamb107.ericsson.se> <20170314174216.56419ADF21@smtp.postman.i2p> <20170321233151.6B3F8ADF28@smtp.postman.i2p> <22B37E49-154A-4C39-B4F8-4D292C8A9615@vigilsec.com> <20170323171654.D228AADF2A@smtp.postman.i2p> Cc: "curdle@ietf.org" X-Mailer: smtp.postman.i2p - Official I2P Mailer From: str4d MIME-Version: 1.0 In-Reply-To: <20170323171654.D228AADF2A@smtp.postman.i2p> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="FUVa9UBLCLEGiQwCBdI1x3qQQttECHAKs" Message-Id: <20170326110338.71C71ADF2F@smtp.postman.i2p> Date: Sun, 26 Mar 2017 11:03:38 +0000 (UTC) Archived-At: Subject: Re: [Curdle] AlgorithmIdentifier parameters in draft-ietf-curdle-pkix-03 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, 26 Mar 2017 17:22:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FUVa9UBLCLEGiQwCBdI1x3qQQttECHAKs Content-Type: multipart/mixed; boundary="sn64ap5dovmfbU8mq3stmuAdjeO7rsKgQ"; protected-headers="v1" X-Mailer: smtp.postman.i2p - Official I2P Mailer From: str4d To: David Benjamin , Russ Housley Cc: "curdle@ietf.org" Subject: Re: [Curdle] AlgorithmIdentifier parameters in draft-ietf-curdle-pkix-03 References: <7d6cfe29-8d4c-436e-fe8a-0cbee915b29e@mail.i2p> <20170311061838.879BAADF28@smtp.postman.i2p> <2DD56D786E600F45AC6BDE7DA4E8A8C118BA5C93@eusaamb107.ericsson.se> <20170314174216.56419ADF21@smtp.postman.i2p> <20170321233151.6B3F8ADF28@smtp.postman.i2p> <22B37E49-154A-4C39-B4F8-4D292C8A9615@vigilsec.com> <20170323171654.D228AADF2A@smtp.postman.i2p> In-Reply-To: <20170323171654.D228AADF2A@smtp.postman.i2p> --sn64ap5dovmfbU8mq3stmuAdjeO7rsKgQ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 03/24/2017 06:16 AM, David Benjamin wrote: > On Thu, Mar 23, 2017 at 12:49 PM Russ Housley wr= ote: >=20 >>> How would the following language (or something to this effect) work a= s a >>> compromise? >>> >>> In this document we defined six new OIDs for identifying the >>> different curve/algorithm pairs. The curves being Curve25519 and >>> Curve448. The algorithms being ECDH, EdDSA in pure mode and EdDSA = in >>> pre-hash mode. For all of the OIDs, the parameters MUST be absent.= >>> Regardless of the defect in the original 1997 syntax, implementatio= ns >>> MUST NOT write out a parameters value of NULL, and MUST NOT accept = a >>> parameters value of NULL, EXCEPT where doing so is unavoidable due = to >>> legacy PKCS8 interpretation within the implementation language's >>> standard libraries (such as Java's Sun security provider before >>> version XX). >> >> >> EXCEPT is not defined in RFC 2119. Yeah, my apologies - I was writing in pseudo-language, but am new enough to this sphere that this RFC isn't yet burned into my brain ^_^; >> >> How is your proposed language any different in reality than: >> >> This document specified object identifiers for using Curve25519 and >> Curve448 for key agreement and digital signature. Since none of the= se >> algorithm identifiers need parameters, the parameters MUST be absent= =2E >> As a result of the defect in the AlgorithmIdentifier syntax publishe= d >> in 1997, some implementations produce a parameters value of NULL, ev= en >> when the parameters ought to be absent. Conforming implementations >> MUST NOT produce a parameters value of NULL, but conforming >> implementations MAY accept a parameters value of NULL for >> interoperability. >> >=20 > I think that encourages normal implementations too much towards laxness= , > which will harm the ecosystem. Correct. I was trying to come up with something that maintained the existing strictness as much as possible, because in theory I agree with i= t. > I don't particularly care which encoding it > is (with or without NULL), but there must be only one encoding. We've h= ad > enough trouble with id-rsaEncryption's ambiguity in BoringSSL that I do= not > think we would be willing implement a new scheme with two encodings. I'm *already* having to deal with parsing two encodings, due to the presence of draft-josefsson-pkix-eddsa-04 (which was the active draft for a proposed encoding when that part of my parser was contributed) - so the horse has kinda left the barn already in that respect. >=20 > If MUST NOT on the parser is problematic, perhaps SHOULD NOT? That said= , I > do not follow what is wrong with MUST NOT. It sounds like this Java iss= ue > is purely a local thing, right? That is, you don't expect such malforme= d > structures to escape into the ecosystem, but you need to be able to par= se > the structures back out? In that case, there's need to encourage any ot= her > implementation to be lax here. It's purely so that your parser gets the= > conforming checkbox? But the serializer is already violating the MUST N= OT, > so violate it in the parser too and add an explanatory comment next to = the > code. >=20 > Or am I misunderstanding the situation? It's not so much that I want a "conforming checkbox" to tick, but that I'm mindful of how easily context can be lost. You don't want to encourage laxness by allowing flexibility, but you also don't want implementors reading the RFC, discovering they can't implement it correctly, and simply ignoring it - that will result in undefined behaviour. I would prefer that the RFC explicitly acknowledge that the MUST NOT may not be practical for *parsing* (as opposed to writing) in some legacy instances (hopefully only the Java standard libraries), to provide context to future readers instead of hoping they stumble upon this mailing list thread, or upon the explanatory comment in my code. I'll admit I'm a little surprised at my cynicism, but I don't think it is misplaced. However, I am clearly the only person to have raised this issue here, so perhaps I'm wrong, and RFC readers will interpret the MUST NOT in a sensible way. I'd like to hope so. Jack --sn64ap5dovmfbU8mq3stmuAdjeO7rsKgQ-- --FUVa9UBLCLEGiQwCBdI1x3qQQttECHAKs Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJY15/3AAoJEGppFNr76gDaQ30P/i1JwVNbKsPpDpA6RHJAzJp2 q5PazhNwVodwWsrP4HWHColca1di+BrbYsZBOmA1aChe3OtgcHXzg7+RDGDolR4E ncYj3hkgRFakdd8JacCuCx7US/yvZuQcn7cI5Qd+kaItKH3uFvuLC5hj5F1N/VfC /gs4uu1Wav4ZDoADhWk3UiQ9veDHPdYZsTlbkALvHp37qixhp/KowjoV7A8e9mCc iQy8odRKwSCaPiq6udDxil6w4N2XVCu+s1/bVGTB85s83ZvTWaVysPcZcQJv87Vw mGJGg6wmAbJiyBoOBpZ9G9euzuMXi6X6iyANHuFBeZFyqCgUbjO6bqY3fgCo5Id8 O5uBGmxWV8Ijw3AEvo2R2dkOhHUNwp5KQ4ky4tJgVYPRJ3Yh66DBQN/Zz3AhCENr MlzvGmmbbn7burUhnC2lCreo+XawugEwnV3R6YnaLjiwRQ5HCwWoo/sHHui2E285 /WgcT1Q2xg8j+69xqpKL6mrGj+7PBAQJUG5yTwKE2kf+1Z2InYd2xuGo2VSqOAlX tGOnre15FN7ZmNCVCKh6AyqjoJf+JMjKhCkbznA4TQx0M4sZEEOdzJUJ32EMDVtt ibx/FCjSFMq4kRomdQu0cmVff8R9uTKl6YkV7Oqxfn31zC5goSroip+jPVFpAAJM 4TViF6EAjhQRHz+rtt8s =g/EU -----END PGP SIGNATURE----- --FUVa9UBLCLEGiQwCBdI1x3qQQttECHAKs-- From nobody Sun Mar 26 10:56: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 E3BC11294FA for ; Sun, 26 Mar 2017 10:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.563 X-Spam-Level: X-Spam-Status: No, score=-1.563 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=denisbider.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 XTZ46hRrxeKe for ; Sun, 26 Mar 2017 10:56:28 -0700 (PDT) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B54F7129650 for ; Sun, 26 Mar 2017 10:56:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=denisbider.com; s=mail; h=from:subject:date:message-id:to:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=bhSMHJQ3GsIhnHi0hRUd661hZsKzzDcfbtEHC4iZJa8=; b=EUd5NWptPeOXOQcWXZY012rihsECmOYXA/22tfFgcpn7qywk8qa3wwdz9d/vkoWgczEDP1IJyqH6G HhmDflwLvGbXNXhU2EcBq9f+HLqYFY/WXR3j3z+cK2vRtKPro29rA4OnXCiQkchrPWYwY3oOpTTRGY luioc0iCsM0rEWgxCFkTNzSHyBgckeTY5y2YiKLeACT/uO0/Z7tfd1qrydhxr8c8X1xdAUqHqJhPPz LwmDLNzJpa/V62YkXjOdOSL9vsFIY/fHrqonHIfxJNXfgEmrLx2j8/nn+RsEgxTjOsvbkOG1XaukTM grfC7vDucqLMhogqKDkmrDmt8QZpfsg== X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com with ESMTPSA (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)); Sun, 26 Mar 2017 18:56:21 +0100 Message-ID: <374ADF9BE1924B7889C64CEC7D51FEF8@Khan> From: "denis bider \(Bitvise\)" To: "Daniel Migault" , "curdle" References: In-Reply-To: Date: Sun, 26 Mar 2017 11:56:14 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [Curdle] comments on draft-ietf-curdle-rsa-sha2-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: Sun, 26 Mar 2017 17:56:30 -0000 Daniel: > Should we consider adding / replacing PKCS1v1.5 > by RSA-PSS for the signature format. An early version of the spec called for PSS. After strong objections - most prominently Peter Gutmann's; it is possible there were others - I changed back to PKCS1v1.5. The main objections were: - PSS is not as universally available; - adding a new type of padding would impose costs on highly resource-constrained implementations who would now have to support both. I have no objections to adding PSS. At this point, it would have to be added as separate variants. For example: rsa-sha2-256-pss, rsa-sha2-512-pss. The existing names already have widely implemented / accepted meanings with PKCS1v1.5. > I understand that penalties are encouraging to > keep ssh-rsa while the use of sha1 is deprecated. > I suggest to provide some recommendations on how > to perform penalties. The issue are penalties in software already deployed. Servers are often used for 5-10 years without update. Users actively resist updates, even if we urge otherwise. Often, there's no one to perform an update. The administrator who configured the server has left. The people who use it are afraid, because they don't have anyone who understands their setup if it breaks. A new spec won't fix this deployed base. Software that's aware of this spec is suggested to implement the "server-sig-algs" extension with EXT_INFO. This eliminates any need to guess what signature algorithm to use. That is this spec's recommendation. > MGLT: Can we recommend to have penalties only applies > when algorithms are weaker than the one supported. The issue does not arise from implementations penalizing known algorithms, it arises from old software penalizing unknown algorithms. Old software cannot know whether an unknown algorithm is stronger or weaker than what it supports. An option we have is to recommend new implementations to not penalize unknown algorithms, because they could be stronger versions of known ones. That could be sensible. But the "server-sig-algs" extension already removes the need to try an algorithm the server doesn't support. > > When authenticating with an RSA key against a server > > that does not implement the "server-sig-algs" extension, > > clients MAY default to an ssh-rsa signature to avoid > > authentication penalties. > > MGLT: ssh-rsa must be deprecated, so I think we should > have something different. The fall back should be on > the most recommended algorithm, or the authentication > penalty should be changed. We can put in instructions that work and will realistically be followed, or we can put in instructions that don’t work. Due to existing deployed base, falling back to “rsa-sha2-256†when the server does not send “server-sig-algs†will not work. If the spec is made to require this, implementers will ignore it for compatibility. Worse, there will then be poor guidance toward a solution that does work. In my opinion, the way to deprecate ssh-rsa is to implement the new signature methods; implement the "server-sig-algs" extension to allow them to coexist; allow for several years of new deployment; and then, for new implementations to start disabling "ssh-rsa" by default. denis ----- Original Message ----- From: Daniel Migault Sent: Saturday, March 25, 2017 17:40 To: curdle Subject: [Curdle] comments on draft-ietf-curdle-rsa-sha2-03.txt Hi, Please find my comments on draft-ietf-curdle-rsa-sha2-03.txt. In a word my comments are: - 1) Should we consider adding / replacing PKCS1v1.5 by RSA-PSS for the signature format. - 2) I understand that penalties are encouraging to keep ssh-rsa while the use of sha1 is deprecated. I suggest to provide some recommendations on how to perform penalties. Yours, Daniel Use of RSA Keys with SHA-2 256 and 512 in Secure Shell (SSH) draft-ietf-curdle-rsa-sha2-03.txt Abstract This memo defines an algorithm name, public key format, and signature format for use of RSA keys with SHA-2 512 for server and client authentication in SSH connections. MGLT: Maybe we should also add penalty recommendations as well ? 2. Public Key Algorithms This memo adopts the style and conventions of [RFC4253] in specifying how use of a signature algorithm is indicated in SSH. The following new signature algorithms are defined: rsa-sha2-256 RECOMMENDED sign Raw RSA key rsa-sha2-512 OPTIONAL sign Raw RSA key These signature algorithms are suitable for use both in the SSH transport layer [RFC4253] for server authentication, and in the authentication layer [RFC4252] for client authentication. Since RSA keys are not dependent on the choice of hash function, both new algorithms reuse the public key format of the existing "ssh-rsa" algorithm as defined in [RFC4253]: string "ssh-rsa" mpint e mpint n All aspects of the "ssh-rsa" format are kept, including the encoded string "ssh-rsa", in order to allow users' existing RSA keys to be used with the new signature formats, without requiring re-encoding, or affecting already trusted key fingerprints. Signing and verifying using these algorithms is performed according to the RSASSA-PKCS1-v1_5 scheme in [RFC3447] using SHA-2 [FIPS-180-4] as hash; MGF1 as mask function; and salt length equal to hash size. MGLT: Could we also take this opportunity to upgrade the signature to RSA-PSS ? If "rsa-sha2-256" / "rsa-sha2-512" are already deployed in most implementation, maybe this document could also define "rsa-sha2-256-rsassa-pss" and "rsa-sha2-512-rsassa-pss" otherwise we could define rsa-sha2-* with RSA-PSS. 3. Discovery of signature algorithms supported by servers Implementation experience has shown that there are servers which apply authentication penalties to clients attempting signature algorithms which the SSH server does not support. MGLT: Can we recommend to have penalties only applies when algorithms are weaker than the one supported. Servers that accept rsa-sha2-* signatures for client authentication SHOULD implement the extension negotiation mechanism defined in [SSH-EXT-INFO], including especially the "server-sig-algs" extension. When authenticating with an RSA key against a server that does not implement the "server-sig-algs" extension, clients MAY default to an ssh-rsa signature to avoid authentication penalties. MGLT: ssh-rsa must be deprecated, so I think we should have something different. The fall back should be on the most recommended algorithm, or the authentication penalty should be changed. _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle From nobody Sun Mar 26 11:03: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 19A5D12967A for ; Sun, 26 Mar 2017 11:03:17 -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=denisbider.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 2ZYbiSwUFYtc for ; Sun, 26 Mar 2017 11:03:15 -0700 (PDT) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 943D6129493 for ; Sun, 26 Mar 2017 11:03:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=denisbider.com; s=mail; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to: references; bh=eZJrk2gVbiSK6KRp7cAvaWQAx1OMOVC2s1oWosQi/Gg=; b=bK/8wI3Aij509qye5RmImTT+KHDUAOccxJ4T/YCneMrF2Je2GHiVroJYyhQ+cINyMBE9EW+05eZD0 2Y3QC+gAQRTweX64Bo9e3+Cv2nKZ2mDUZGWaO4ef6DwANX01rLVAedxscmaXBAuT0NuRAQixLzm1qP AyCCIfgitfKtpZNiplVZh2H2GmQh5WZCIkEEqAoqrB54dkfN/sTwOEG8oRbNtHX9xx3eWodzgTORHz JDJfVQmdyhIylICzkvM3ZwgKGPPUE8tev7r4Ri5N1zRgKpkJViAaX/AF97xAuhUanteHc9TIb+xm+e 3POWQRNjUN8n+t2F4vjI29ymjHG0U/w== X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com with ESMTPSA (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)); Sun, 26 Mar 2017 19:03:12 +0100 Message-ID: <16EFC4E5FC894A61BDE01CEC2EB869AE@Khan> From: "denis bider \(Bitvise\)" To: =?UTF-8?B?0KDRg9C80LXQvSDQn9C10YLRgNC+0LI=?= , References: <148823325745.13859.1818801191554779419.idtracker@ietfa.amsl.com> <58CCEF4F.7000902@roumenpetrov.info> <9EABA431E21041239B7D2B164FAA5AC3@Khan> <58CD46B0.9010902@roumenpetrov.info> <58D7A456.9040609@roumenpetrov.info> In-Reply-To: <58D7A456.9040609@roumenpetrov.info> Date: Sun, 26 Mar 2017 12:03:22 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01D7_01D2A628.F7816240" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [Curdle] Comments on draft-ietf-curdle-rsa-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: Sun, 26 Mar 2017 18:03:17 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_01D7_01D2A628.F7816240 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Objection noted. I disagree. I have explained, I have addressed, and = will not argue this further. From: =D0=A0=D1=83=D0=BC=D0=B5=D0=BD = =D0=9F=D0=B5=D1=82=D1=80=D0=BE=D0=B2=20 Sent: Sunday, March 26, 2017 05:21 To: curdle@ietf.org=20 Subject: Re: [Curdle] Comments on draft-ietf-curdle-rsa-sha2 Hi Denis and members of curdle group, denis bider (Bitvise) wrote: > Hello Roumen: > > >> Quote from rfc4252: >> byte SSH_MSG_USERAUTH_REQUEST >> [...] >> string=C3=83=E2=80=9A=C3=82 =C3=83=E2=80=9A=C3=82 = =C3=83=E2=80=9A=C3=82 public key algorithm name <<<<----- > > Thank you for pointing this out. This is an important point. The=20 > document needs a more formal discussion to properly introduce the=20 > concept for "signature algorithm". > > Draft submissions are currently off, but I have clarified this in my=20 > local version with an additional section that discusses the terms=20 > "public key algorithm" and "signature algorithm" in detail. It also=20 > points out two places in RFC4252 and RFC4253 which subtly change=20 > meaning, and now encode a signature algorithm name. > > Since I cannot submit it right now, I attach a copy of my current=20 > local version. I have objection to change meaning of public key algorithm identifier .=20 It is well defined in chapter 6.6. "Public Key Algorithms" of RFC 4253. I cannot understand the goal of such change ("*Signature Algorithm as=20 Distinct Aspect of* Public Key *Algorithm*"). You define new "public key algorithm identifier" and signature=20 identifier is same although it not necessary as is by default "Public=20 key/certificate formats that do not explicitly specify a signature=20 format identifier MUST use the public key/certificate format identifier=20 as the signature identifier." It seems to me you would like to swap(replace) "public key" with=20 "signature" in all RFC documents with this document(draft). Why to redefineconcept? Is not more easy to define new public-key algorithms? Such definition=20 does not require relation with server extension. If server extension is=20 not accepted then "rsa-sha2" should be canceled (suspended). [SNIP] Regards, Roumen Petrov P.S. attachment "rsa-sha2-03_vs_04.html" is deference in html format=20 between v3 and v4. -------------------------------------------------------------------------= ------- _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle ------=_NextPart_000_01D7_01D2A628.F7816240 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Objection noted. I disagree. I have explained, I have addressed, = and will=20 not argue this further.
 
 
Sent: Sunday, March 26, 2017 05:21
Subject: Re: [Curdle] Comments on=20 draft-ietf-curdle-rsa-sha2
 
Hi=20 Denis and members of curdle group,

denis bider (Bitvise) = wrote:
>=20 Hello Roumen:
>
>
>> Quote from = rfc4252:
>> byte=20 SSH_MSG_USERAUTH_REQUEST
>> [...]
>> = string=C3=83=E2=80=9A=C3=82 =C3=83=E2=80=9A=C3=82 = =C3=83=E2=80=9A=C3=82 =20 public key algorithm name <<<<-----
>
> Thank = you for=20 pointing this out. This is an important point. The
> document = needs a=20 more formal discussion to properly introduce the
> concept for = "signature=20 algorithm".
>
> Draft submissions are currently off, but I = have=20 clarified this in my
> local version with an additional section = that=20 discusses the terms
> "public key algorithm" and "signature = algorithm" in=20 detail. It also
> points out two places in RFC4252 and RFC4253 = which=20 subtly change
> meaning, and now encode a signature algorithm=20 name.
>
> Since I cannot submit it right now, I attach a = copy of my=20 current
> local version.
I have objection to change meaning of = public=20 key algorithm identifier .
It is well defined in chapter 6.6. = "Public Key=20 Algorithms" of RFC 4253.

I cannot understand the goal of such = change=20 ("*Signature Algorithm as
Distinct Aspect of* Public Key=20 *Algorithm*").
You define new "public key algorithm identifier" and = signature=20
identifier is same although it not necessary as is by default = "Public=20
key/certificate formats that do not explicitly specify a signature=20
format identifier MUST use the public key/certificate format = identifier=20
as the signature identifier."

It seems to me you would like = to=20 swap(replace) "public key" with
"signature" in all RFC documents = with this=20 document(draft).


Why to redefineconcept?
Is not more easy = to=20 define new public-key algorithms? Such definition
does not require = relation=20 with server extension. If server extension is
not accepted then = "rsa-sha2"=20 should be canceled = (suspended).



[SNIP]

Regards,
Roumen=20 Petrov


P.S. attachment "rsa-sha2-03_vs_04.html" is deference = in html=20 format
between v3 and v4.


_______________________________________________
Curdle mailing=20 list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle
------=_NextPart_000_01D7_01D2A628.F7816240-- From nobody Sun Mar 26 12:29: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 1719512968A for ; Sun, 26 Mar 2017 12:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, 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 QHVhgK7vNDHi for ; Sun, 26 Mar 2017 12:29:47 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::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 57D90129689 for ; Sun, 26 Mar 2017 12:29:47 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id 190so33071158itm.0 for ; Sun, 26 Mar 2017 12:29:47 -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=6tlJDYPd9CMTN+wYNfOy2hQ3fmpTCOH4DbNGDaAHm3U=; b=ay7aXNBuVA3TE0aCkgTlVpIMSqm2Vdo0fwraDVtbr4y+dH3z1tX8oR6Qa9QVeOmeOB gKpi3XNQepkw1ti7W2y4SQalJklY+6eCxHauhJFw688zLLJDGTMTY9iyuHR7ZblHi7In Blb2TS404Sqodt5uqMBRYKP4MOOQcpKtm10B1ndIP2WZD9BjGgpUuHUFIH1qFVa1S5mv Y+Zx9d6vDSnhhbt0r9CfTNVGlUF9HXrP/lWBVaTqWnza4XSwFm1c1bBTU/9mFAKdFrnR L/Kd1UUJB+JoN2MBKuiGxUsxCVvfSJuTsdzQGSjSIDlqUCk0D/v+UQmKPy9OjLdS/8zp ty1Q== 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=6tlJDYPd9CMTN+wYNfOy2hQ3fmpTCOH4DbNGDaAHm3U=; b=JLnrGC26IdFl/5NW7amYY1EX4C0vDuOptuWXrm7LmG3CmzjnL7eGz57tbAD96G9HPV wdmUK3VJglfUIBojSW/8GPzV7WesqzHucSfiM4OoInEfBEUZ/zDdlDApPXXKOywZNlKM 3l/FT/bksCarFZyEC71/Wk1W670MZqGUnRtriCfNg2pC7NmTWczQzrLuES2QjPW/MKXK 8mTMCSy7l2AbqO8NmMOBnJVLSMFpo5AWHYoiMgYfWuXLVbA7TfyNCbVlTGkxMamWAFkw O7J4gXinYn4oBUqewFn2AbGEvPphvFpQEMZfhf5YR17bv58AyNi1d3GPUEBERS1mxPj+ iR2Q== X-Gm-Message-State: AFeK/H0KKBEZu/9DWfH3d1KpN+wAn2t6eJgTuGZ8jWGgMq2y0fY64/SOSs649erw1LSiu3xP1CgoYlE37XonGQ== X-Received: by 10.36.175.5 with SMTP id t5mr6422998ite.48.1490556586414; Sun, 26 Mar 2017 12:29:46 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.35.213 with HTTP; Sun, 26 Mar 2017 12:29:45 -0700 (PDT) From: Daniel Migault Date: Sun, 26 Mar 2017 14:29:45 -0500 X-Google-Sender-Auth: YpqoxPmvKR0QArIiBTJ598F6_CU Message-ID: To: curdle Content-Type: multipart/alternative; boundary=f403045dc12ad9d9d3054ba73f1b Archived-At: Subject: [Curdle] comments on draft-ietf-curdle-ssh-kex-sha2-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: Sun, 26 Mar 2017 19:29:49 -0000 --f403045dc12ad9d9d3054ba73f1b Content-Type: text/plain; charset=UTF-8 Hi, Please find some comments of draft-ietf-curdle-ssh-kex-sha2-05. Yours, Daniel I have the impression that only RFC4253 provided some recommendations, in which case I would be incline to say that the current draft only updates this document. The other RFC only defines new suites. I suggest we either use MUST/SHOULD/MAY or REQUIRE/RECOMMEND/OPTIONAL but not both. Note that if the recommendations for ipsec [draft-ietf-ipsecme-rfc4307bis] we also introduced some additional notation such as SHOULD+/- to specify whether the SHOULD is expect to raise its status or that SHOULD is only here for interoperability. Note that recommendations are not the purpose of IANA, so I would probably change the title of the section. The IANA only adds the code points. It is god that you mentioned the IANA link. I would encourage you to have the URL as an informative reference. Recommendations should regularly updated so implementations have the time to introduce new suites or remove old suites while still providing interoperability. If the starting point is RFC4253, then we have: diffie-hellman-group1-sha1 REQUIRED diffie-hellman-group14-sha1 REQUIRED and all other suites are OPTIONAL or MAY. Correct me if I am wrong, At least I believe that that appendix section would be useful to comment on the update with the previous recommendations. curve25519-sha256 ssh-curves MUST Maybe a MUST statement may be to strong as curves have just been defined. Maybe that could be SHOULD+ mentioning it is expected to become a MUST next time. In fact it is usually hard to move from MAY to MUST. If you do so, reasons should be provided in the text. Currently it seems it is implemented in libssh and OpenSSH, not sure it is sufficient for a MUST. curve448-sha512 ssh-curves MAY By default, the suites with MAY status are not mentioned. diffie-hellman-group-exchange-sha1 RFC4419 SHOULD NOT SHA1 is probably at MUST NOT, so I am expected any suites to be MUST NOT. Because it represents a threat you are likely to move to MUST NOT directly. diffie-hellman-group-exchange-sha256 RFC4419 MAY diffie-hellman-group1-sha1 RFC4253 SHOULD NOT If group 1 is 768-bit MODP Group , I would consider there are two reasons to have this as MUST NOT. diffie-hellman-group14-sha1 RFC4253 SHOULD My understanding is that this one is kept for interoperability. However, the text should make it clear this suite will be deprecated soon. diffie-hellman-group14-sha256 new-modp MUST diffie-hellman-group15-sha512 new-modp MAY diffie-hellman-group16-sha512 new-modp SHOULD diffie-hellman-group17-sha512 new-modp MAY diffie-hellman-group18-sha512 new-modp MAY ecdh-sha2-nistp256 RFC5656 SHOULD ecdh-sha2-nistp384 RFC5656 SHOULD ecdh-sha2-nistp521 RFC5656 SHOULD The current trend is also to reduce the number of suites implementation. DO we want to have these three suites as SHOULD. We should also explain what the next step is expected to be. ecdh-sha2-* RFC5656 MAY ecmqv-sha2 RFC5656 SHOULD NOT gss-gex-sha1-* RFC4462 SHOULD NOT gss-group1-sha1-* RFC4462 SHOULD NOT gss-group14-sha1-* RFC4462 SHOULD gss-group14-sha256-* new-modp SHOULD gss-group15-sha512-* new-modp MAY gss-group16-sha512-* new-modp SHOULD gss-group17-sha512-* new-modp MAY gss-group18-sha512-* new-modp MAY gss-* RFC4462 MAY rsa1024-sha1 RFC4432 SHOULD NOT Maybe we could set it as MUST NOT both for key size and SHA1. rsa2048-sha256 RFC4432 MAY --f403045dc12ad9d9d3054ba73f1b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGRpdiBkaXI9Imx0ciI+PGRpdj5IaSwgPGJyPjxicj5QbGVhc2UgZmluZCBzb21lIGNvbW1lbnRz IG9mIGRyYWZ0LWlldGYtY3VyZGxlLXNzaC1rZXgtc2hhMjx3YnI+LTA1LiA8YnI+PGJyPllvdXJz LCA8YnI+RGFuaWVsPGJyPjxicj5JIGhhdmUgdGhlIGltcHJlc3Npb24gdGhhdCBvbmx5IFJGQzQy NTMgcHJvdmlkZWQgc29tZSByZWNvbW1lbmRhdGlvbnMsIGluIHdoaWNoIGNhc2UgSSB3b3VsZCBi ZSBpbmNsaW5lIHRvIHNheSB0aGF0IHRoZSBjdXJyZW50IGRyYWZ0IG9ubHkgdXBkYXRlcyB0aGlz IGRvY3VtZW50LiBUaGUgb3RoZXIgUkZDIG9ubHkgZGVmaW5lcyBuZXcgc3VpdGVzLiA8YnI+PGJy PjwvZGl2PjxkaXY+SSBzdWdnZXN0IHdlIGVpdGhlciB1c2UgTVVTVC9TSE9VTEQvTUFZIG9yIFJF UVVJUkUvUkVDT01NRU5EL09QVElPTkFMIGJ1dCBub3QgYm90aC4gTm90ZSB0aGF0IGlmIHRoZSBy ZWNvbW1lbmRhdGlvbnMgZm9yIGlwc2VjIFtkcmFmdC1pZXRmLWlwc2VjbWUtcmZjNDMwN2Jpc10g d2UgYWxzbyBpbnRyb2R1Y2VkIHNvbWUgYWRkaXRpb25hbCBub3RhdGlvbiBzdWNoIGFzIFNIT1VM RCsvLSB0byBzcGVjaWZ5IHdoZXRoZXIgdGhlIFNIT1VMRCBpcyBleHBlY3QgdG8gcmFpc2UgaXRz IHN0YXR1cyBvciB0aGF0IFNIT1VMRCBpcyBvbmx5IGhlcmUgZm9yIGludGVyb3BlcmFiaWxpdHku IDxicj48YnI+PC9kaXY+PGRpdj48ZGl2Pk5vdGUgdGhhdCByZWNvbW1lbmRhdGlvbnMgYXJlIG5v dCB0aGUgcHVycG9zZSBvZiBJQU5BLCBzbyBJIHdvdWxkIA0KcHJvYmFibHkgY2hhbmdlIHRoZSB0 aXRsZSBvZiB0aGUgc2VjdGlvbi4gVGhlIElBTkEgb25seSBhZGRzIHRoZSBjb2RlIA0KcG9pbnRz LiBJdCBpcyBnb2QgdGhhdCB5b3UgbWVudGlvbmVkIHRoZSBJQU5BIGxpbmsuIEkgd291bGQgZW5j b3VyYWdlIA0KeW91IHRvIGhhdmUgdGhlIFVSTCBhcyBhbiBpbmZvcm1hdGl2ZcKgIHJlZmVyZW5j ZS4gwqAgwqAgPGJyPjwvZGl2Pjxicj48L2Rpdj5SZWNvbW1lbmRhdGlvbnMgc2hvdWxkIHJlZ3Vs YXJseSB1cGRhdGVkIHNvIGltcGxlbWVudGF0aW9ucyBoYXZlIHRoZSB0aW1lIHRvIGludHJvZHVj ZSBuZXcgc3VpdGVzIG9yIHJlbW92ZSBvbGQgc3VpdGVzIHdoaWxlIHN0aWxsIHByb3ZpZGluZyBp bnRlcm9wZXJhYmlsaXR5LiBJZiB0aGUgc3RhcnRpbmcgcG9pbnQgaXMgUkZDNDI1MywgdGhlbiB3 ZSBoYXZlOg0KPHByZT4gICAgICBkaWZmaWUtaGVsbG1hbi1ncm91cDEtc2hhMSBSRVFVSVJFRA0K ICAgICAgZGlmZmllLWhlbGxtYW4tZ3JvdXAxNC1zaGExIFJFUVVJUkVEPC9wcmU+YW5kIGFsbCBv dGhlciBzdWl0ZXMgYXJlIE9QVElPTkFMIG9yIE1BWS4gQ29ycmVjdCBtZSBpZiBJIGFtIHdyb25n LCBBdCBsZWFzdCBJIGJlbGlldmUgdGhhdCB0aGF0IGFwcGVuZGl4IHNlY3Rpb24gd291bGQgYmUg dXNlZnVsIHRvIGNvbW1lbnQgb24gdGhlIHVwZGF0ZSB3aXRoIHRoZSBwcmV2aW91cyByZWNvbW1l bmRhdGlvbnMuwqAgPGJyPjxkaXY+PGJyPsKgwqDCoMKgwqDCoCBjdXJ2ZTI1NTE5LXNoYTI1NsKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHNzaC1jdXJ2ZXMgTVVTVDxicj48 YnI+TWF5YmUgYSBNVVNUIHN0YXRlbWVudCBtYXkgYmUgdG8gc3Ryb25nIGFzIGN1cnZlcyBoYXZl IGp1c3QgYmVlbiBkZWZpbmVkLiBNYXliZSB0aGF0IGNvdWxkIGJlIFNIT1VMRCsgbWVudGlvbmlu ZyBpdCBpcyBleHBlY3RlZCB0byBiZWNvbWUgYSBNVVNUIG5leHQgdGltZS4gSW4gZmFjdCBpdCBp cyB1c3VhbGx5IGhhcmQgdG8gbW92ZSBmcm9tIE1BWSB0byBNVVNULiBJZiB5b3UgZG8gc28sIHJl YXNvbnMgc2hvdWxkIGJlIHByb3ZpZGVkIGluIHRoZSB0ZXh0LiBDdXJyZW50bHkgaXQgc2VlbXMg aXQgaXMgaW1wbGVtZW50ZWQgaW4gbGlic3NoIGFuZCBPcGVuU1NILCBub3Qgc3VyZSBpdCBpcyBz dWZmaWNpZW50IGZvciBhIE1VU1QuIDxicj48YnI+wqDCoMKgwqDCoMKgwqAgY3VydmU0NDgtc2hh NTEywqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHNzaC1jdXJ2ZXMg TUFZPGJyPkJ5IGRlZmF1bHQsIHRoZSBzdWl0ZXMgd2l0aCBNQVkgc3RhdHVzIGFyZSBub3QgbWVu dGlvbmVkLiA8YnI+wqA8YnI+wqDCoMKgwqDCoMKgwqAgZGlmZmllLWhlbGxtYW4tZ3JvdXAtZXhj aGFuZ2Utc2hhMcKgwqAgUkZDNDQxOcKgwqDCoCBTSE9VTEQgTk9UPGJyPlNIQTEgaXMgcHJvYmFi bHkgYXQgTVVTVCBOT1QsIHNvIEkgYW0gZXhwZWN0ZWQgYW55IHN1aXRlcyB0byBiZSBNVVNUIE5P VC4gQmVjYXVzZSBpdCByZXByZXNlbnRzIGEgdGhyZWF0IHlvdSBhcmUgbGlrZWx5IHRvIG1vdmUg dG8gTVVTVCBOT1QgZGlyZWN0bHkuIDxicj48YnI+wqDCoMKgwqDCoMKgwqAgZGlmZmllLWhlbGxt YW4tZ3JvdXAtZXhjaGFuZ2Utc2hhMjU2IFJGQzQ0MTnCoMKgwqAgTUFZPGJyPsKgwqDCoMKgwqDC oMKgIGRpZmZpZS1oZWxsbWFuLWdyb3VwMS1zaGExwqDCoMKgwqDCoMKgwqDCoMKgwqAgUkZDNDI1 M8KgwqDCoCBTSE9VTEQgTk9UPGJyPklmIGdyb3VwIDEgaXMgNzY4LWJpdCBNT0RQIEdyb3VwICwg SSB3b3VsZCBjb25zaWRlciB0aGVyZSBhcmUgdHdvIHJlYXNvbnMgdG8gaGF2ZSB0aGlzIGFzIE1V U1QgTk9ULiA8YnI+PGJyPsKgwqDCoMKgwqDCoMKgIGRpZmZpZS1oZWxsbWFuLWdyb3VwMTQtc2hh McKgwqDCoMKgwqDCoMKgwqDCoCBSRkM0MjUzwqDCoMKgIFNIT1VMRDxicj48L2Rpdj48ZGl2Pk15 IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCB0aGlzIG9uZSBpcyBrZXB0IGZvciBpbnRlcm9wZXJhYmls aXR5LiBIb3dldmVyLCB0aGUgdGV4dCBzaG91bGQgbWFrZSBpdCBjbGVhciB0aGlzIHN1aXRlIHdp bGwgYmUgZGVwcmVjYXRlZCBzb29uLiA8YnI+PC9kaXY+PGRpdj48YnI+wqDCoMKgwqDCoMKgwqAg ZGlmZmllLWhlbGxtYW4tZ3JvdXAxNC1zaGEyNTbCoMKgwqDCoMKgwqDCoCBuZXctbW9kcMKgwqAg TVVTVDxicj7CoMKgwqDCoMKgwqDCoCBkaWZmaWUtaGVsbG1hbi1ncm91cDE1LXNoYTUxMsKgwqDC oMKgwqDCoMKgIG5ldy1tb2RwwqDCoCBNQVk8YnI+wqDCoMKgwqDCoMKgwqAgZGlmZmllLWhlbGxt YW4tZ3JvdXAxNi1zaGE1MTLCoMKgwqDCoMKgwqDCoCBuZXctbW9kcMKgwqAgU0hPVUxEPGJyPsKg wqDCoMKgwqDCoMKgIGRpZmZpZS1oZWxsbWFuLWdyb3VwMTctc2hhNTEywqDCoMKgwqDCoMKgwqAg bmV3LW1vZHDCoMKgIE1BWTxicj7CoMKgwqDCoMKgwqDCoCBkaWZmaWUtaGVsbG1hbi1ncm91cDE4 LXNoYTUxMsKgwqDCoMKgwqDCoMKgIG5ldy1tb2RwwqDCoCBNQVk8YnI+wqDCoMKgwqDCoMKgwqAg ZWNkaC1zaGEyLW5pc3RwMjU2wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFJG QzU2NTbCoMKgwqAgU0hPVUxEPGJyPsKgwqDCoMKgwqDCoMKgIGVjZGgtc2hhMi1uaXN0cDM4NMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBSRkM1NjU2wqDCoMKgIFNIT1VMRDxi cj7CoMKgwqDCoMKgwqDCoCBlY2RoLXNoYTItbmlzdHA1MjHCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqAgUkZDNTY1NsKgwqDCoCBTSE9VTEQ8YnI+PGJyPlRoZSBjdXJyZW50IHRy ZW5kIGlzIGFsc28gdG8gcmVkdWNlIHRoZSBudW1iZXIgb2Ygc3VpdGVzIGltcGxlbWVudGF0aW9u LiBETyB3ZSB3YW50IHRvIGhhdmUgdGhlc2UgdGhyZWUgc3VpdGVzIGFzIFNIT1VMRC4gV2Ugc2hv dWxkIGFsc28gZXhwbGFpbiB3aGF0IHRoZSBuZXh0IHN0ZXAgaXMgZXhwZWN0ZWQgdG8gYmUuIDxi cj7CoDxicj7CoDxicj7CoMKgwqDCoMKgwqDCoCBlY2RoLXNoYTItKsKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFJGQzU2NTbCoMKgwqAgTUFZPGJyPsKg wqDCoMKgwqDCoMKgIGVjbXF2LXNoYTLCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgIFJGQzU2NTbCoMKgwqAgU0hPVUxEIE5PVDxicj7CoMKgwqDCoMKg wqDCoCBnc3MtZ2V4LXNoYTEtKsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgIFJGQzQ0NjLCoMKgwqAgU0hPVUxEIE5PVDxicj7CoMKgwqDCoMKgwqDCoCBnc3MtZ3Jv dXAxLXNoYTEtKsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFJGQzQ0NjLC oMKgwqAgU0hPVUxEIE5PVDxicj7CoMKgwqDCoMKgwqDCoCBnc3MtZ3JvdXAxNC1zaGExLSrCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgUkZDNDQ2MsKgwqDCoCBTSE9VTEQ8YnI+ wqDCoMKgwqDCoMKgwqAgZ3NzLWdyb3VwMTQtc2hhMjU2LSrCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoCBuZXctbW9kcMKgwqAgU0hPVUxEPGJyPsKgwqDCoMKgwqDCoMKgIGdzcy1ncm91 cDE1LXNoYTUxMi0qwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgbmV3LW1vZHDCoMKg IE1BWTxicj7CoMKgwqDCoMKgwqDCoCBnc3MtZ3JvdXAxNi1zaGE1MTItKsKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgIG5ldy1tb2RwwqDCoCBTSE9VTEQ8YnI+wqDCoMKgwqDCoMKgwqAg Z3NzLWdyb3VwMTctc2hhNTEyLSrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBuZXct bW9kcMKgwqAgTUFZPGJyPsKgwqDCoMKgwqDCoMKgIGdzcy1ncm91cDE4LXNoYTUxMi0qwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgbmV3LW1vZHDCoMKgIE1BWTxicj7CoMKgwqDCoMKg wqDCoCBnc3MtKsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgIFJGQzQ0NjLCoMKgwqAgTUFZPGJyPjxicj7CoMKgwqDCoMKgwqDCoCBy c2ExMDI0LXNoYTHCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqAgUkZDNDQzMsKgwqDCoCBTSE9VTEQgTk9UPGJyPk1heWJlIHdlIGNvdWxkIHNldCBpdCBhcyBN VVNUIE5PVCBib3RoIGZvciBrZXkgc2l6ZSBhbmQgU0hBMS4gPGJyPjxicj7CoMKgwqDCoMKgwqDC oCByc2EyMDQ4LXNoYTI1NsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgIFJGQzQ0MzLCoMKgwqAgTUFZPGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwv ZGl2Pjxicj48ZGl2PjxkaXY+wqAgPGJyPjwvZGl2PjwvZGl2PjwvZGl2Pg0K --f403045dc12ad9d9d3054ba73f1b-- From nobody Sun Mar 26 12:59: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 7C88B1296A1 for ; Sun, 26 Mar 2017 12:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.563 X-Spam-Level: X-Spam-Status: No, score=-1.563 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=denisbider.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 t__4hmaGbeMt for ; Sun, 26 Mar 2017 12:59:05 -0700 (PDT) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6FF21296A0 for ; Sun, 26 Mar 2017 12:59:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=denisbider.com; s=mail; h=from:subject:date:message-id:to:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=YJ+qblahCTNcDeEaMe70SpE4i+W1jb4sSan1KqTL0q4=; b=wRE5C99M3breQFaybDVTJbGPgj3MDNSFVfkL/fx7AOwq78QxrfhJgsy8prapDz3YYfyWUsSqi9k4A NTWF8oBpeVSBApSgj39kHMT7Al4ij+VAR7ejat6TZVI7JszFzTDWMIaqecrw5zSL5ApZEuGXczwKag z/Ura7VzqO64BGl9rroXSd3dHgg4Euxslp/TW1HOOOJV/JH7nxa9NoyD+9c5lqLxuctiqtd3zsmKvU efkc0ieI08vg9aCmwiNrkhhHBSUEDbjxoiJR7dwPIvs0UQw+3Lgp4lsod/Q2JU8uCgY3gD5OFj6o+7 rr1wBcNs08JUvEQlKhcODcRLTCbQ0sQ== X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com with ESMTPSA (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)); Sun, 26 Mar 2017 20:58:58 +0100 Message-ID: <74B9D9EB5287420C98ED3DA0B13F0212@Khan> From: "denis bider \(Bitvise\)" To: "Daniel Migault" , "curdle" References: In-Reply-To: Date: Sun, 26 Mar 2017 13:59:08 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [Curdle] Comments on draft-ietf-curdle-ssh-ext-info-03 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, 26 Mar 2017 19:59:08 -0000 Daniel: > > Implementations MUST NOT send an incorrect indicator name > > for their role. Implementations MAY disconnect if the > > counter-party sends an incorrect indicator. If "ext-info-c" > > or "ext-info-s" ends up being negotiated as a key exchange > > method, the parties MUST disconnect. > > Shouldn't we have "Implementations MUST disconnect" ? At > least we should maybe state that it MUST ignore the indication. I try to avoid burdens that aren't strictly required, on the basis that it may cause implementers to ignore instructions when it matters. There's a "MUST NOT send" here that makes the situation clear and unambiguous. "MAY disconnect" allows an implementation to police this. I didn't put in an "everyone MUST police this rule" because I don't see strong added value. > > uint32 nr-extensions > > repeat "nr-extensions" times: > > string extension-name > > string extension-value > > MGLT: maybe the different terms/parameters could be > defined. I am assuming that an extenssion-name has > a single extension-value. In other words, > extension-name is repeated. The tuple (extension-name, extension-value) is repeated. The inclusion of both fields in repetition is meant to be implied by their indent. To make this clearer in case the indent is lost, I will be changing the instruction to: repeat the following 2 fields "nr-extensions" times: > > If the client sent "ext-info-c", the server MAY send, > > but is not obligated to send, an SSH_MSG_EXT_INFO > > message immediately before (*) SSH_MSG_USERAUTH_SUCCESS, > > as defined in [RFC4252]. The server MAY send this message > > whether or not it sent EXT_INFO after SSH_MSG_NEWKEYS. > > MGLT: Maybe that would be clearer to split the sentence in > two parts so the "MAY" does not confuse the reader. OK. I have tried to improve clarity by rewording this paragraph as follows: "If the client sent "ext-info-c", the server MAY send zero, one, or two EXT_INFO messages. The first opportunity for the server's EXT_INFO is after the server's NEWKEYS, as above. The second opportunity is just before (*) SSH_MSG_USERAUTH_SUCCESS, as defined in [RFC4252]. The server MAY send EXT_INFO at the second opportunity, whether or not it sent it at the first. A client that sent "ext-info-c" MUST accept a server's EXT_INFO at both opportunities, but MUST NOT require it." > -- It is not clear to me why immediately is needed. OK, I have changed "immediately before" to "just before" above. The point is that the sequence of messages at the second EXT_INFO opportunity is either (USERAUTH_SUCCESS) or (EXT_INFO, USERAUTH_SUCCESS); but not e.g. (EXT_INFO, USERAUTH_FAILURE, more activity, USERAUTH_SUCCESS). > > In general, if an extension requires both the client > > and the server to include it > > MGLT: "In general" can be removed. I think the reader expects > some additional text that shows cases where the order matters. OK. Removed "In general". > > Extension-value fields are interpreted as defined by their > > respective extension. An extension-value field MAY be empty > > if so permitted by the extension. Applications that do not > > implement or recognize a particular extension MUST ignore > > the associated extension-value field, regardless of its > > size or content. > > MGLT: Is the \0 the delimiter to skip the value ? An SSH string is encoded as the tuple (word32 n, byte[n] content). Zero bytes are valid content. An empty string would be encoded as \0\0\0\0. So \0\0\0\0 would be an empty extension-value. If \0 appears in the string content of the extension-value, the meaning of that is extension-specific. I think this does not have to be explicitly clarified because an SSH implementer would know how an SSH string is encoded; that it can contain null bytes; and that these have no special treatment. > MGLT: Maybe a reference to the types used could be added. OK. I have added a section like the following to both drafts: "1.2. Wire Encoding Terminology "The wire encoding types in this document - "byte", "uint32", "string", "boolean", "name-list" - have meanings as described in [RFC4251]." I have added a normative reference to RFC 4251 to both documents. > > This extension is sent by the server only, and contains a > > list of signature algorithms that the server is able to > > process as part of a "publickey" request. > > MGLT: I think we should also specify the server behavior, > which MUST ignore the extension and MAY disconnect. Before addressing this - next comment about the same passage: > MGLT: I might be wrong but if the client sends the list, > it may be helpful for the server to narrow down its > selection. In this case, it may look more as agreement. > It may also be useful for the server to monitor the > supported signatures requested by clients which could > be helpful to understand when to deprecate authentication > algorithms. I like this idea. Unfortunately though, the extension has already been implemented and deployed as server-sig-algs". For this suggestion to not be confusing, the client would have to send something like "client-sig-algs"; or perhaps, just "sig-algs". Because the extension is already named, I have adopted the first one of the above two comments. I have added the following phrasing: "If a client sends this extension, the server MAY ignore it, and MAY disconnect." > > If a server does not send this extension, a client MUST > > NOT make any assumptions about the server's signature > > algorithm support, and MAY proceed with authentication > > requests using trial and error. > > MGLT: Maybe some indication on penalties may be added here. OK. I have added: "Note that implementations are known to exist that apply authentication penalties if the client attempts to use an unexpected signature algorithm." > > If both parties send this extension, but the name-lists > > do not contain a common algorithm in either direction, > > the parties MUST disconnect in the same way as if > > negotiation failed as part of SSH_MSG_KEXINIT. > > MGLT: As this looks like a renegotiation, for which reason > do we need to disconnect the session and not simply ignore > the exchange. Three responses: - One pre-condition for renegotiation to fail is that at least one party fails to offer the "none" compression algorithm. In that case, this behavior is consistent with KEXINIT, where we could say "OK, if no compression can be agreed on, use none". But we don't, we disconnect. - Protocol errors result in disconnect because they are an unexpected situation that guarantees there's an error somewhere. The "fail early" principle applies. - Outside of this extension, SSH key re-exchange can be initiated with changed settings such that the parties no longer agree on algorithms. In this case also, there will be a disconnect. Above policy is consistent with existing behaviors, rather than introducing a situation where failed renegotiation would mean disconnect in some cases, and "ignore" in others. > > string "no-flow-control" > > string choice of: "p" for preferred | "s" for supported > > MGLT: description of the parameters would be helpful. OK. Added the following: "A party SHOULD send "s" if it supports "no-flow-control", but does not prefer to enable it. A party SHOULD send "p" if it prefers to enable the extension if the other party supports it. Parties MAY disconnect if they receive a different extension value." > > string "elevation" > > string choice of: "y" | "n" | "d" > > MGLT: description of the parameters would be helpful. The next following paragraph defines the values. Perhaps I misunderstood, and the request is to define "string"? In this case, this may be addressed by the new section 1.2, which references RFC 4251 that defines "string". This was a number of comments, so if I missed anything, please let me know. :-) denis ----- Original Message ----- From: Daniel Migault Sent: Saturday, March 25, 2017 17:24 To: curdle Subject: [Curdle] Comments on draft-ietf-curdle-ssh-ext-info-03 Hi, Thank you for moving that draft forward. Please see some comments on the draft. Yours, Daniel Internet-Draft D. Bider Updates: 4252, 4253, 4254 (if approved) Bitvise Limited Intended status: Standards Track March 23, 2017 Expires: September 23, 2017 Extension Negotiation in Secure Shell (SSH) draft-ietf-curdle-ssh-ext-info-03.txt Abstract This memo defines a mechanism for SSH clients and servers to exchange information about supported protocol extensions confidentially after completed key exchange. Bider [Page 1] Internet-Draft Extension Negotiation in SSH March 2017 1. Overview and Rationale Secure Shell (SSH) is a common protocol for secure communication on the Internet. The original design of the SSH transport layer [RFC4253] lacks proper extension negotiation. Meanwhile, diverse implementations take steps to ensure that known message types contain no unrecognized information. This makes it difficult for implementations to signal capabilities and negotiate extensions without risking disconnection. This obstacle has been recognized in relationship with [SSH-RSA-SHA2], where the need arises for a client to discover signature algorithms a server accepts, to avoid authentication penalties and trial-and-error. 1.1. Requirements Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Extension Negotiation Mechanism 2.1. Signaling of Extension Negotiation in KEXINIT Applications implementing this mechanism MUST add to the field "kex_algorithms", in their KEXINIT packet sent for the first key exchange, one of the following indicator names: - When acting as server: "ext-info-s" - When acting as client: "ext-info-c" The indicator name is added without quotes, and MAY be added at any position in the name-list, subject to proper separation from other names as per name-list conventions. The names are added to the "kex_algorithms" field because this is one of two name-list fields in KEXINIT that do not have a separate copy for each data direction. 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. The inclusion of textual indicator names is intended to provide a clue for implementers to discover this mechanism. 2.2. Enabling Criteria If a client or server offers "ext-info-c" or "ext-info-s" respectively, it MUST be prepared to accept an SSH_MSG_EXT_INFO message from the peer. Bider [Page 2] Internet-Draft Extension Negotiation in SSH March 2017 Thus a server only needs to send "ext-info-s" if it intends to process SSH_MSG_EXT_INFO from the client. If a server receives an "ext-info-c", it MAY send an SSH_MSG_EXT_INFO message, but is not required to do so. If an SSH_MSG_EXT_INFO message is sent, then it MUST be the first message after the initial SSH_MSG_NEWKEYS. Implementations MUST NOT send an incorrect indicator name for their role. Implementations MAY disconnect if the counter-party sends an incorrect indicator. If "ext-info-c" or "ext-info-s" ends up being negotiated as a key exchange method, the parties MUST disconnect. MGLT: Shouldn't we have "Implementations MUST disconnect" ? At least we should maybe state that it MUST ignore the indication. 2.3. SSH_MSG_EXT_INFO Message A party that received the "ext-info-c" or "ext-info-s" indicator MAY send the following message: byte SSH_MSG_EXT_INFO (value 7) uint32 nr-extensions repeat "nr-extensions" times: string extension-name string extension-value MGLT: maybe the different terms/parameters could be defined. I am assuming that an extenssion-name has a single extension-value. In other words, extension-name is repeated. This message is sent immediately after SSH_MSG_NEWKEYS, without delay. This allows a client to pipeline an authentication request after its SSH_MSG_SERVICE_REQUEST, even when this needs extension information. 2.4. Server's Secondary SSH_MSG_EXT_INFO If the client sent "ext-info-c", the server MAY send, but is not obligated to send, an SSH_MSG_EXT_INFO message immediately before (*) SSH_MSG_USERAUTH_SUCCESS, as defined in [RFC4252]. The server MAY send this message whether or not it sent EXT_INFO after SSH_MSG_NEWKEYS. MGLT: Maybe that would be clearer to split the sentence in two parts so the "MAY" does not confuse the reader. OLD: If the client sent "ext-info-c", the server MAY send, but is not obligated to send, an SSH_MSG_EXT_INFO message immediately before (*) SSH_MSG_USERAUTH_SUCCESS, as defined in [RFC4252]. NEW: If the client sent "ext-info-c", the server MAY send, but is not obligated to send an SSH_MSG_EXT_INFO. If the server sends SSH_MSG_EXT_INFO message it MUST be placed immediately before (*) SSH_MSG_USERAUTH_SUCCESS, as defined in [RFC4252]. -- It is not clear to me why immediately is needed. This allows a server to reveal support for additional extensions that it was unwilling to reveal to an unauthenticated client. If a server sends a subsequent SSH_MSG_EXT_INFO, this replaces any initial one, and both the client and the server re-evaluate extensions in effect. The server's last EXT_INFO is matched against the client's original. (*) The message MUST be sent at this point for the following reasons: if it was sent earlier, it would not allow the server to withhold information until the client has authenticated; if it was sent later, a client that needs information from the second EXT_INFO immediately after successful authentication would have no way of reliably knowing whether there will be a second EXT_INFO or not. Bider [Page 3] Internet-Draft Extension Negotiation in SSH March 2017 2.5. Interpretation of Extension Names and Values Each extension is identified by its extension-name, and defines the conditions under which the extension is considered to be in effect. Applications MUST ignore unrecognized extension-names. In general, if an extension requires both the client and the server to include it in order for the extension to take effect, the relative position of the extension-name in each EXT_INFO message is irrelevant. MGLT: "In general" can be removed. I think the reader expects some additional text that shows cases where the order matters. Extension-value fields are interpreted as defined by their respective extension. An extension-value field MAY be empty if so permitted by the extension. Applications that do not implement or recognize a particular extension MUST ignore the associated extension-value field, regardless of its size or content. MGLT: Is the \0 the delimiter to skip the value ? The cumulative size of an SSH_MSG_EXT_INFO message is limited only by the maximum packet length that an implementation may apply in accordance with [RFC4253]. Implementations MUST accept well-formed SSH_MSG_EXT_INFO messages up to the maximum packet length they accept. 3. Initially Defined Extensions 3.1. "server-sig-algs" This extension is sent with the following extension name and value: string "server-sig-algs" name-list signature-algorithms-accepted Note that the name-list type is a strict subset of the string type, and is thus permissible as an extension-value. MGLT: Maybe a reference to the types used could be added. This extension is sent by the server only, and contains a list of signature algorithms that the server is able to process as part of a "publickey" request. MGLT: I think we should also specify the server behavior, which MUST ignore the extension and MAY disconnect. MGLT: I might be wrong but if the client sends the list, it may be helpful for the server to narrow down its selection. In this case, it may look more as agreement. It may also be useful for the server to monitor the supported signatures requested by clients which could be helpful to understand when to deprecate authentication algorithms. A client that wishes to proceed with public key authentication MAY wait for the server's SSH_MSG_EXT_INFO so it can send a "publickey" authentication request with an appropriate signature algorithm, rather than resorting to trial and error. Servers that implement public key authentication SHOULD implement this extension. If a server does not send this extension, a client MUST NOT make any assumptions about the server's signature algorithm support, and MAY proceed with authentication requests using trial and error. MGLT: Maybe some indication on penalties may be added here. Bider [Page 4] Internet-Draft Extension Negotiation in SSH March 2017 3.2. "delay-compression" This extension MAY be sent by both parties as follows: string "delay-compression" string: name-list compression_algorithms_client_to_server name-list compression_algorithms_server_to_client This extension allows the server and client to renegotiate compression algorithm support without having to conduct a key re-exchange, putting new algorithms into effect immediately upon successful authentication. This extension takes effect only if both parties send it. Name-lists MAY include any compression algorithm that could have been negotiated in SSH_MSG_KEXINIT, except algorithms that define their own delayed compression semantics. This means "zlib,none" is a valid algorithm list in this context; but "zlib@openssh.com" is not. If both parties send this extension, but the name-lists do not contain a common algorithm in either direction, the parties MUST disconnect in the same way as if negotiation failed as part of SSH_MSG_KEXINIT. MGLT: As this looks like a renegotiation, for which reason do we need to disconnect the session and not simply ignore the exchange. If this extension takes effect, the renegotiated compression algorithm is activated for the very next SSH message after the trigger message: - Sent by the server, the trigger message is SSH_MSG_USERAUTH_SUCCESS. - Sent by the client, the trigger message is SSH_MSG_NEWCOMPRESS. If this extension takes effect, the client MUST send the following message shortly after receiving SSH_MSG_USERAUTH_SUCCESS: byte SSH_MSG_NEWCOMPRESS (value 8) The purpose of this message is to avoid a race condition where the server cannot reliably know whether a message sent by the client was sent before or after receiving the server's USERAUTH_SUCCESS. As with all extensions, the server MAY delay including this extension until its secondary SSH_MSG_EXT_INFO, sent before USERAUTH_SUCCESS. This allows the server to avoid advertising compression support until the client has been authenticated. If the parties re-negotiate compression using this extension in a session where compression is already enabled; and the re-negotiated algorithm is the same in one or both directions; then the internal compression state MUST be reset for each direction at the time the re-negotiated algorithm takes effect. Bider [Page 5] Internet-Draft Extension Negotiation in SSH March 2017 3.2.1. Awkwardly Timed Key Re-Exchange A party that has signaled, or intends to signal, support for this extension in an SSH session, MUST NOT initiate key re-exchange in that session until either of the following occurs: - This extension was negotiated, and the party that's about to start key re-exchange already sent its trigger message for compression. - The party has sent (if server) or received (if client) the message SSH_MSG_USERAUTH_SUCCESS, and this extension was not negotiated. If a party violates this rule, the other party MAY disconnect. In general, parties SHOULD NOT start key re-exchange before successful user authentication, but MAY tolerate it if not using this extension. 3.2.2. Subsequent Re-Exchange In subsequent key re-exchanges that unambiguously begin after the compression trigger messages, the compression algorithms negotiated in re-exchange override the algorithms negotiated with this extension. 3.3. "no-flow-control" This extension is sent with the following extension name and value: string "no-flow-control" string choice of: "p" for preferred | "s" for supported MGLT: description of the parameters would be helpful. To take effect, this extension MUST be: - Sent by both parties. - At least one party MUST have sent the value "p" (preferred). If this extension takes effect, the "initial window size" fields in SSH_MSG_CHANNEL_OPEN and SSH_MSG_CHANNEL_OPEN_CONFIRMATION, as defined in [RFC4254], become meaningless. The values of these fields MUST be ignored, and a channel behaves as if all window sizes are infinite. Neither side is required to send any SSH_MSG_CHANNEL_WINDOW_ADJUST messages, and if received, such messages MUST be ignored. This extension is intended, but not limited to, use by file transfer applications that are only going to use one channel, and for which the flow control provided by SSH is an impediment, rather than a feature. Implementations MUST refuse to open more than one simultaneous channel when this extension is in effect. Nevertheless, server implementations SHOULD support clients opening more than one non-simultaneous channel. Bider [Page 6] Internet-Draft Extension Negotiation in SSH March 2017 3.4. "elevation" This extension MAY be sent by the client as follows: string "elevation" string choice of: "y" | "n" | "d" MGLT: description of the parameters would be helpful. A client sends "y" to indicate its preference that the session should be elevated (as used by Windows); "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. If a client has included this extension, then after authentication, a server that supports this extension SHOULD indicate to the client whether elevation was done by sending the following global request: byte SSH_MSG_GLOBAL_REQUEST string "elevation" boolean want reply = false boolean elevation performed 4. IANA Considerations 4.1. Additions to existing tables IANA is requested to insert the following entries into the table Message Numbers under Secure Shell (SSH) Protocol Parameters [RFC4250]: Value Message ID Reference 7 SSH_MSG_EXT_INFO [this document] 8 SSH_MSG_NEWCOMPRESS [this document] IANA is requested to insert the following entries into the table Key Exchange Method Names: Method Name Reference Note ext-info-s [this document] Section 2.2 ext-info-c [this document] Section 2.2 4.2. New table: Extension Names Also under Secure Shell (SSH) Protocol Parameters, IANA is requested to create a new table, Extension Names, with initial content: Extension Name Reference Note server-sig-algs [this document] Section 3.1 delay-compression [this document] Section 3.2 no-flow-control [this document] Section 3.3 elevation [this document] Section 3.4 Bider [Page 7] Internet-Draft Extension Negotiation in SSH March 2017 4.2.1. Future Assignments to Extension Names Names in the Extension Names table MUST follow the Conventions for Names defined in [RFC4250], Section 4.6.1. Requests for assignments of new non-local names in the Extension Names table (i.e. names not including the '@' character) MUST be done through the IETF CONSENSUS method, as described in [RFC5226]. 5. References 5.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, January 2006. [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006. [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006. [RFC4254] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Connection Protocol", RFC 4254, January 2006. [RFC5226] Narten, T. and Alvestrand, H., "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 5.2. Informative References [SSH-RSA-SHA2] Bider, D., "Use of RSA Keys with SHA-2 256 and 512 in Secure Shell (SSH)", draft-ietf-curdle-rsa-sha2-03.txt, February 2017, . Bider [Page 8] Internet-Draft Extension Negotiation in SSH March 2017 Author's Address Denis Bider Bitvise Limited Suites 41/42, Victoria House 26 Main Street GI Phone: +506 8315 6519 EMail: ietf-ssh3@denisbider.com URI: https://www.bitvise.com/ Acknowledgments Thanks to Markus Friedl and Damien Miller for comments and initial implementation. Thanks to Peter Gutmann and Roumen Petrov for review and feedback. Bider [Page 9] _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle From nobody Sun Mar 26 13:39: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 8F7A81296B3 for ; Sun, 26 Mar 2017 13:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, 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 IwrfWxXc4G8N for ; Sun, 26 Mar 2017 13:39:42 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::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 9F886128616 for ; Sun, 26 Mar 2017 13:39:42 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id e75so2011272itd.1 for ; Sun, 26 Mar 2017 13:39:42 -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=FgmHAGulBaoiXZ0mmMCZLV10dEBgxNSZwkHlGgYv7JI=; b=kVLqWugIzdf39kGGPk6vmVVvbXifuPwqjVoHKARCadFVbDGNuT4Ab7X21b676rx3cM UPV6k+vPS73sQWol5pO2Y8ZI1KqVpn8iYWLn+vofC5GCcmtn1h5lAWPwiR9hKyEyPIJj zMjWRI9/F5bJjKoNcoM9GOpjhnwNZTNCUUxOLmKhCeekQHTI4aG1n9uvclBJMmMAOWuM xTikj4Q9dA2+AGdHNECv8n5ZVaHGZRiThxL+zhYUYCSlD8zX1DOpjnbWkZEAIO3Ovgh1 lbfL7jenwztREWwwvVeAaC9TaOMREJ1us1QaRBnwqpYNin0ISNSgHfcyx4ifkuKClqt0 1b+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=FgmHAGulBaoiXZ0mmMCZLV10dEBgxNSZwkHlGgYv7JI=; b=plImOPiW8ZLq1PyJq4LRKws0xRVERb/rKHvLXeVVI0DeN7jABmQWED7uhQfMt9oJh+ kpIs+z665Wm2G92TBORdWW+i9DnU7Ne2AFna7rutRwpQEHUE4Npj0IxIOLgExnhnVcLG 4zWPMlvrC4ehhErlZywZgVYkS674BUTc2Nsi0xCn6lS5GqJQYK6DhhNTq/lgiysLaHxX gYSNqzPcMJ9+8BtYiMNK+id758G9CIc/Tsv4sg/S1ZT3eeI/p27sdmFWJHUxSio5uqRN GrhjZxns4ZovWt9VMPInPU4f4Evk/IhGi6hk5WF5aoNRqejm+KzB4EV3ZTBoYDelMCma ghjQ== X-Gm-Message-State: AFeK/H3442Qn42CnM3LX3/Cm9UNQYyWo4pHx2R9NrZ85PHQmaDbMnRap68yk2Glibp96wApbO9AIjKTKPAGWxw== X-Received: by 10.107.174.27 with SMTP id x27mr17760520ioe.35.1490560781713; Sun, 26 Mar 2017 13:39:41 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.35.213 with HTTP; Sun, 26 Mar 2017 13:39:40 -0700 (PDT) In-Reply-To: <374ADF9BE1924B7889C64CEC7D51FEF8@Khan> References: <374ADF9BE1924B7889C64CEC7D51FEF8@Khan> From: Daniel Migault Date: Sun, 26 Mar 2017 15:39:40 -0500 X-Google-Sender-Auth: l7I0hgE_yYZcOeWwR1XEQAFVuYI Message-ID: To: "denis bider (Bitvise)" Cc: curdle Content-Type: multipart/alternative; boundary=001a11449ffce90544054ba839af Archived-At: Subject: Re: [Curdle] comments on draft-ietf-curdle-rsa-sha2-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: Sun, 26 Mar 2017 20:39:45 -0000 --001a11449ffce90544054ba839af Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Thanks for the response. Please see mine inline. In short I agree with your responses. I believe it would be good to add rsa-sha2-256-pss, rsa-sha2-512-pss. Yours, Daniel On Sun, Mar 26, 2017 at 12:56 PM, denis bider (Bitvise) < ietf-ssh3@denisbider.com> wrote: > Daniel: > > > Should we consider adding / replacing PKCS1v1.5 >> by RSA-PSS for the signature format. >> > > An early version of the spec called for PSS. After strong objections - > most prominently Peter Gutmann's; it is possible there were others - I > changed back to PKCS1v1.5. The main objections were: > > - PSS is not as universally available; > - adding a new type of padding would impose costs on highly > resource-constrained implementations who would now have to support both. > > I have no objections to adding PSS. At this point, it would have to be > added as separate variants. For example: rsa-sha2-256-pss, rsa-sha2-512-p= ss. > > The existing names already have widely implemented / accepted meanings > with PKCS1v1.5. > > I understand the motivations. I personally think it would be good to add rsa-sha2-256-pss, rsa-sha2-512-pss > > I understand that penalties are encouraging to >> keep ssh-rsa while the use of sha1 is deprecated. >> I suggest to provide some recommendations on how >> to perform penalties. >> > > The issue are penalties in software already deployed. Servers are often > used for 5-10 years without update. Users actively resist updates, even i= f > we urge otherwise. Often, there's no one to perform an update. The > administrator who configured the server has left. The people who use it a= re > afraid, because they don't have anyone who understands their setup if it > breaks. A new spec won't fix this deployed base. > > Software that's aware of this spec is suggested to implement the > "server-sig-algs" extension with EXT_INFO. This eliminates any need to > guess what signature algorithm to use. That is this spec's recommendation= . > > > Agree, my recommendation on penalties was mostly for new implementations that do not implement ext_info. Maybe you are right having ext_info solve this issue better. > MGLT: Can we recommend to have penalties only applies >> when algorithms are weaker than the one supported. >> > > The issue does not arise from implementations penalizing known algorithms= , > it arises from old software penalizing unknown algorithms. Old software > cannot know whether an unknown algorithm is stronger or weaker than what = it > supports. > > An option we have is to recommend new implementations to not penalize > unknown algorithms, because they could be stronger versions of known ones= . > That could be sensible. But the "server-sig-algs" extension already remov= es > the need to try an algorithm the server doesn't support. > > > > When authenticating with an RSA key against a server >> > that does not implement the "server-sig-algs" extension, >> > clients MAY default to an ssh-rsa signature to avoid >> > authentication penalties. >> >> MGLT: ssh-rsa must be deprecated, so I think we should >> have something different. The fall back should be on >> the most recommended algorithm, or the authentication >> penalty should be changed. >> > > We can put in instructions that work and will realistically be followed, > or we can put in instructions that don=E2=80=99t work. > > Agree. > Due to existing deployed base, falling back to =E2=80=9Crsa-sha2-256=E2= =80=9D when the > server does not send =E2=80=9Cserver-sig-algs=E2=80=9D will not work. If = the spec is made > to require this, implementers will ignore it for compatibility. Worse, > there will then be poor guidance toward a solution that does work. > Agree > In my opinion, the way to deprecate ssh-rsa is to implement the new > signature methods; implement the "server-sig-algs" extension to allow the= m > to coexist; allow for several years of new deployment; and then, for new > implementations to start disabling "ssh-rsa" by default. > > Maybe that would be good to explain how the option is also helping to deprecate suites in the security consideration section. > > denis > > > > ----- Original Message ----- > From: Daniel Migault > Sent: Saturday, March 25, 2017 17:40 > To: curdle > Subject: [Curdle] comments on draft-ietf-curdle-rsa-sha2-03.txt > > Hi, > > Please find my comments on draft-ietf-curdle-rsa-sha2-03.txt. > > In a word my comments are: > - 1) Should we consider adding / replacing PKCS1v1.5 by RSA-PSS for > the signature format. > - 2) I understand that penalties are encouraging to keep ssh-rsa while > the use of sha1 is deprecated. I suggest to provide some recommendations = on > how to perform penalties. > > Yours, > Daniel > > Use of RSA Keys with SHA-2 256 and 512 in Secure Shell (SSH) > draft-ietf-curdle-rsa-sha2-03.txt > > > Abstract > > This memo defines an algorithm name, public key format, and signature > format for use of RSA keys with SHA-2 512 for server and client > authentication in SSH connections. > > MGLT: Maybe we should also add penalty recommendations as well ? > > 2. Public Key Algorithms > > This memo adopts the style and conventions of [RFC4253] in specifying > how use of a signature algorithm is indicated in SSH. > > The following new signature algorithms are defined: > > rsa-sha2-256 RECOMMENDED sign Raw RSA key > rsa-sha2-512 OPTIONAL sign Raw RSA key > > These signature algorithms are suitable for use both in the SSH transpor= t > layer [RFC4253] for server authentication, and in the authentication > layer [RFC4252] for client authentication. > > Since RSA keys are not dependent on the choice of hash function, both > new algorithms reuse the public key format of the existing "ssh-rsa" > algorithm as defined in [RFC4253]: > > string "ssh-rsa" > mpint e > mpint n > > All aspects of the "ssh-rsa" format are kept, including the encoded > string "ssh-rsa", in order to allow users' existing RSA keys to be > used with the new signature formats, without requiring re-encoding, > or affecting already trusted key fingerprints. > > Signing and verifying using these algorithms is performed according to > the RSASSA-PKCS1-v1_5 scheme in [RFC3447] using SHA-2 [FIPS-180-4] as > hash; MGF1 as mask function; and salt length equal to hash size. > > MGLT: Could we also take this opportunity to upgrade the signature to > RSA-PSS ? > If "rsa-sha2-256" / "rsa-sha2-512" are already deployed in most > implementation, maybe this document could also define > "rsa-sha2-256-rsassa-pss" and "rsa-sha2-512-rsassa-pss" otherwise we coul= d > define rsa-sha2-* with RSA-PSS. > > > 3. Discovery of signature algorithms supported by servers > > Implementation experience has shown that there are servers which apply > authentication penalties to clients attempting signature algorithms > which the SSH server does not support. > > MGLT: Can we recommend to have penalties only applies when algorithms are > weaker than the one supported. > > Servers that accept rsa-sha2-* signatures for client authentication > SHOULD implement the extension negotiation mechanism defined in > [SSH-EXT-INFO], including especially the "server-sig-algs" extension. > > When authenticating with an RSA key against a server that does not > implement the "server-sig-algs" extension, clients MAY default to an > ssh-rsa signature to avoid authentication penalties. > > MGLT: ssh-rsa must be deprecated, so I think we should have something > different. The fall back should be on the most recommended algorithm, or > the authentication penalty should be changed. > > > > _______________________________________________ > 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 > --001a11449ffce90544054ba839af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Thanks for the response. = Please see mine inline. In short I agree with your responses. I believe it = would be good to add rsa-sha2-256-pss, rsa-sha2-512-pss.

Yours= ,
Daniel



On Sun, Mar 26, 2017 at 12:56 PM, denis bi= der (Bitvise) <ietf-ssh3@denisbider.com> wrote:
Daniel:


Should we consider adding / replacing PKCS1v1.5
by RSA-PSS for the signature format.

 An early version of the spec called for PSS. After strong objections - most= prominently Peter Gutmann's; it is possible there were others - I chan= ged back to PKCS1v1.5. The main objections were:

- PSS is not as universally available;
- adding a new type of padding would impose costs on highly resource-constr= ained implementations who would now have to support both.

I have no objections to adding PSS. At this point, it would have to be adde= d as separate variants. For example: rsa-sha2-256-pss, rsa-sha2-512-pss.
The existing names already have widely implemented / accepted meanings with= PKCS1v1.5.

I understand the motivations. I personally thi= nk it would be good to add rsa-sha2-256-pss, rsa-sha2-512-pss

I understand that penalties are encouraging to
keep ssh-rsa while the use of sha1 is deprecated.
I suggest to provide some recommendations on how
to perform penalties.

 The issue are penalties in software already deployed. Servers are often use= d for 5-10 years without update. Users actively resist updates, even if we = urge otherwise. Often, there's no one to perform an update. The adminis= trator who configured the server has left. The people who use it are afraid= , because they don't have anyone who understands their setup if it brea= ks. A new spec won't fix this deployed base.

Software that's aware of this spec is suggested to implement the "= server-sig-algs" extension with EXT_INFO. This eliminates any need to = guess what signature algorithm to use. That is this spec's recommendati= on.


Agree, my recommendation on penalties was most= ly for new implementations that do not implement ext_info. Maybe you are ri= ght having ext_info solve this issue better.
=C2=A0
MGLT: Can we recommend to have penalties only applies
when algorithms are weaker than the one supported.

 The issue does not arise from implementations penalizing known algorithms, = it arises from old software penalizing unknown algorithms. Old software can= not know whether an unknown algorithm is stronger or weaker than what it su= pports.

An option we have is to recommend new implementations to not penalize unkno= wn algorithms, because they could be stronger versions of known ones. That = could be sensible. But the "server-sig-algs" extension already re= moves the need to try an algorithm the server doesn't support.


> When authenticating with an RSA key against a server
> that does not implement the "server-sig-algs" extension,
> clients MAY default to an ssh-rsa signature to avoid
> authentication penalties.

MGLT: ssh-rsa must be deprecated, so I think we should
have something different. The fall back should be on
the most recommended algorithm, or the authentication
penalty should be changed.

 We can put in instructions that work and will realistically be followed, or= we can put in instructions that don=E2=80=99t work.

Agree.
=C2=A0
Due to existing deployed base, falling back to =E2=80=9Crsa-sha2-256=E2=80= =9D when the server does not send =E2=80=9Cserver-sig-algs=E2=80=9D will no= t work. If the spec is made to require this, implementers will ignore it fo= r compatibility. Worse, there will then be poor guidance toward a solution = that does work.
Agree
In my opinion, the way to deprecate ssh-rsa is to implement the new signatu= re methods; implement the "server-sig-algs" extension to allow th= em to coexist; allow for several years of new deployment; and then, for new= implementations to start disabling "ssh-rsa" by default.

Maybe that would be good to explain how the option is= also helping to deprecate suites in the security consideration section.=C2= =A0

denis



----- Original Message -----
From: Daniel Migault
Sent: Saturday, March 25, 2017 17:40
To: curdle
Subject: [Curdle] comments on draft-ietf-curdle-rsa-sha2-03.txt

Hi,

Please find my comments on draft-ietf-curdle-rsa-sha2-03.txt.

In a word my comments are:
=C2=A0 - 1) Should we consider=C2=A0 adding / replacing PKCS1v1.5 by RSA-PS= S for=C2=A0 the signature format.
=C2=A0 - 2) I understand that penalties are encouraging to keep ssh-rsa whi= le the use of sha1 is deprecated. I suggest to provide some recommendations= on how to perform penalties.

Yours,
Daniel

=C2=A0 =C2=A0 =C2=A0Use of RSA Keys with SHA-2 256 and 512 in Secure Shell = (SSH)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-c= urdle-rsa-sha2-03.txt


Abstract

=C2=A0This memo defines an algorithm name, public key format, and signature=
=C2=A0format for use of RSA keys with SHA-2 512 for server and client
=C2=A0authentication in SSH connections.

MGLT: Maybe we should also add penalty recommendations as well ?

2.=C2=A0 Public Key Algorithms

=C2=A0This memo adopts the style and conventions of [RFC4253] in specifying=
=C2=A0how use of a signature algorithm is indicated in SSH.

=C2=A0The following new signature algorithms are defined:

=C2=A0 =C2=A0rsa-sha2-256=C2=A0 =C2=A0 RECOMMENDED=C2=A0 =C2=A0 sign=C2=A0 = =C2=A0 Raw RSA key
=C2=A0 =C2=A0rsa-sha2-512=C2=A0 =C2=A0 OPTIONAL=C2=A0 =C2=A0 =C2=A0 =C2=A0s= ign=C2=A0 =C2=A0 Raw RSA key

=C2=A0These signature algorithms are suitable for use both in the SSH trans= port
=C2=A0layer [RFC4253] for server authentication, and in the authentication<= br> =C2=A0layer [RFC4252] for client authentication.

=C2=A0Since RSA keys are not dependent on the choice of hash function, both=
=C2=A0new algorithms reuse the public key format of the existing "ssh-= rsa"
=C2=A0algorithm as defined in [RFC4253]:

=C2=A0 =C2=A0string=C2=A0 =C2=A0 "ssh-rsa"
=C2=A0 =C2=A0mpint=C2=A0 =C2=A0 =C2=A0e
=C2=A0 =C2=A0mpint=C2=A0 =C2=A0 =C2=A0n

=C2=A0All aspects of the "ssh-rsa" format are kept, including the= encoded
=C2=A0string "ssh-rsa", in order to allow users' existing RSA= keys to be
=C2=A0used with the new signature formats, without requiring re-encoding, =C2=A0or affecting already trusted key fingerprints.

=C2=A0Signing and verifying using these algorithms is performed according t= o
=C2=A0the RSASSA-PKCS1-v1_5 scheme in [RFC3447] using SHA-2 [FIPS-180-4] as=
=C2=A0hash; MGF1 as mask function; and salt length equal to hash size.

MGLT: Could we also take this opportunity to upgrade the signature to RSA-P= SS ?
If "rsa-sha2-256" / "rsa-sha2-512" are already deployed= in most implementation, maybe this document could also define "rsa-sh= a2-256-rsassa-pss" and "rsa-sha2-512-rsassa-pss" otherwise w= e could define rsa-sha2-* with RSA-PSS.


3.=C2=A0 Discovery of signature algorithms supported by servers

=C2=A0Implementation experience has shown that there are servers which appl= y
=C2=A0authentication penalties to clients attempting signature algorithms =C2=A0which the SSH server does not support.

MGLT: Can we recommend to have penalties only applies when algorithms are w= eaker than the one supported.

=C2=A0Servers that accept rsa-sha2-* signatures for client authentication =C2=A0SHOULD implement the extension negotiation mechanism defined in
=C2=A0[SSH-EXT-INFO], including especially the "server-sig-algs" = extension.

=C2=A0When authenticating with an RSA key against a server that does not =C2=A0implement the "server-sig-algs" extension, clients MAY defa= ult to an
=C2=A0ssh-rsa signature to avoid authentication penalties.

MGLT: ssh-rsa must be deprecated, so I think we should have something diffe= rent. The fall back should be on the most recommended algorithm, or the aut= hentication penalty should be changed.



_______________________________________________
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

--001a11449ffce90544054ba839af-- From nobody Sun Mar 26 14:12:12 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 87D221296A4 for ; Sun, 26 Mar 2017 14:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[AC_BR_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, 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 S5UAis6LeGuK for ; Sun, 26 Mar 2017 14:12:05 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::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 D08EF128959 for ; Sun, 26 Mar 2017 14:12:04 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id e75so2404488itd.1 for ; Sun, 26 Mar 2017 14:12:04 -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=Jp9F/6mL4VIh4S9LuH6sTiiO5t5r46d/iWydeswJlNI=; b=Zw/QfWvUfhRYMR2Wfd9+NXEIpaIKEVZygJLkiCbHWotjxXrgr4FHJr7ggqsC/poQPf 2p6BZ1oo80PwyDKxNDJeizNj8y+9hACGv9uxa0/svsMg88co9Wfnsh7dK5XFwV1E2v4g aLFavxqCG/q8+d1Wn7cbdTooqyjP5NVJ6ZLEHAdNNv5PV3jTYsKD+9HvyY4pzQ1hkwAY 9aKsgDYMyDhQCR2ky+Nn9KdpKFef23rnm0auMD+Z1yvYr0w9JZ1t9ZtHSYJLTLBLHhjQ Pxly8K7n3vIUsIXkMRbe+S/a9sUEVuxB6DPgT0h5jNj3tM/ufxpTmj9VfWnAn63i//8O rN9g== 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=Jp9F/6mL4VIh4S9LuH6sTiiO5t5r46d/iWydeswJlNI=; b=hx+Hm/WNhaghRkqsAX3gYfLCsu6XI8SXCQnvfpXnqR6TeNTiN9yPLaG5TFm+Kmxagn /7AcRab2F4x5arJVsYtT+HXltps9ThhdgVSZcdKRMNUDauewmIZH1KETs5Cbw3F5ypF/ /3LNOUpRrnyvrF0JfnGqhiw9iLRLJlGo/JH7MQiGcZzuo85RZupZIiVmobCAyQvJt/EU CZzi5yQGadCb6VQfnOCG0MiPc2PHfk7Zyd59x6ciPqxxBTHXK/0JcNPcmF4y+tO4R0MI NwsLk3Y3CwLtRCGcDpEfHPFV3fbPEiEsasl+F57OOLqYXSVEmv3Ci7X3mkuP0vX7phtG 8sdg== X-Gm-Message-State: AFeK/H3/hgEbI0NNq5kvb5dFCtV0oImtDqkrZQ8Zn5XM8dxJYLZ184UXh8HIbe2hNiWANkP9JKh6aRQ7uQGTbg== X-Received: by 10.36.164.75 with SMTP id v11mr7415600iti.101.1490562724054; Sun, 26 Mar 2017 14:12:04 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.35.213 with HTTP; Sun, 26 Mar 2017 14:12:03 -0700 (PDT) In-Reply-To: <74B9D9EB5287420C98ED3DA0B13F0212@Khan> References: <74B9D9EB5287420C98ED3DA0B13F0212@Khan> From: Daniel Migault Date: Sun, 26 Mar 2017 16:12:03 -0500 X-Google-Sender-Auth: esHRXdi37KYVrnWxBdlNIUgPbkg Message-ID: To: "denis bider (Bitvise)" Cc: curdle Content-Type: multipart/alternative; boundary=f403045fbba8aecaa8054ba8ade0 Archived-At: Subject: Re: [Curdle] Comments on draft-ietf-curdle-ssh-ext-info-03 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, 26 Mar 2017 21:12:11 -0000 --f403045fbba8aecaa8054ba8ade0 Content-Type: text/plain; charset=UTF-8 Hi Denis, Thanks you for the response. My understanding is that the next version of the draft will be close to final. Yours, Daniel On Sun, Mar 26, 2017 at 2:59 PM, denis bider (Bitvise) < ietf-ssh3@denisbider.com> wrote: > Daniel: > > > > Implementations MUST NOT send an incorrect indicator name >> > for their role. Implementations MAY disconnect if the >> > counter-party sends an incorrect indicator. If "ext-info-c" >> > or "ext-info-s" ends up being negotiated as a key exchange >> > method, the parties MUST disconnect. >> >> Shouldn't we have "Implementations MUST disconnect" ? At >> least we should maybe state that it MUST ignore the indication. >> > > I try to avoid burdens that aren't strictly required, on the basis that it > may cause implementers to ignore instructions when it matters. > > There's a "MUST NOT send" here that makes the situation clear and > unambiguous. "MAY disconnect" allows an implementation to police this. I > didn't put in an "everyone MUST police this rule" because I don't see > strong added value. > > > OK > > uint32 nr-extensions >> > repeat "nr-extensions" times: >> > string extension-name >> > string extension-value >> >> MGLT: maybe the different terms/parameters could be >> defined. I am assuming that an extenssion-name has >> a single extension-value. In other words, >> extension-name is repeated. >> > > The tuple (extension-name, extension-value) is repeated. The inclusion of > both fields in repetition is meant to be implied by their indent. > > To make this clearer in case the indent is lost, I will be changing the > instruction to: > > repeat the following 2 fields "nr-extensions" times: > > > Sounds clearer to me thanks. > > If the client sent "ext-info-c", the server MAY send, >> > but is not obligated to send, an SSH_MSG_EXT_INFO >> > message immediately before (*) SSH_MSG_USERAUTH_SUCCESS, >> > as defined in [RFC4252]. The server MAY send this message >> > whether or not it sent EXT_INFO after SSH_MSG_NEWKEYS. >> >> MGLT: Maybe that would be clearer to split the sentence in >> two parts so the "MAY" does not confuse the reader. >> > > OK. I have tried to improve clarity by rewording this paragraph as follows: > > "If the client sent "ext-info-c", the server MAY send zero, one, or two > EXT_INFO messages. The first opportunity for the server's EXT_INFO is after > the server's NEWKEYS, as above. The second opportunity is just before (*) > SSH_MSG_USERAUTH_SUCCESS, as defined in [RFC4252]. The server MAY send > EXT_INFO at the second opportunity, whether or not it sent it at the first. > A client that sent "ext-info-c" MUST accept a server's EXT_INFO at both > opportunities, but MUST NOT require it." > > This sounds to me much clearer, especially as the two opportunities are mentioned. > -- It is not clear to me why immediately is needed. >> > > OK, I have changed "immediately before" to "just before" above. > > The point is that the sequence of messages at the second EXT_INFO > opportunity is either (USERAUTH_SUCCESS) or (EXT_INFO, USERAUTH_SUCCESS); > but not e.g. (EXT_INFO, USERAUTH_FAILURE, more activity, USERAUTH_SUCCESS). > I think the previous rewording specify that, but if you think that needs to be specified more precisely. I believe please consider adding this text as well. > > > In general, if an extension requires both the client >> > and the server to include it >> >> MGLT: "In general" can be removed. I think the reader expects >> some additional text that shows cases where the order matters. >> > > OK. Removed "In general". > > > > Extension-value fields are interpreted as defined by their >> > respective extension. An extension-value field MAY be empty >> > if so permitted by the extension. Applications that do not >> > implement or recognize a particular extension MUST ignore >> > the associated extension-value field, regardless of its >> > size or content. >> >> MGLT: Is the \0 the delimiter to skip the value ? >> > > An SSH string is encoded as the tuple (word32 n, byte[n] content). Zero > bytes are valid content. > > An empty string would be encoded as \0\0\0\0. So \0\0\0\0 would be an > empty extension-value. > > If \0 appears in the string content of the extension-value, the meaning of > that is extension-specific. > > I think this does not have to be explicitly clarified because an SSH > implementer would know how an SSH string is encoded; that it can contain > null bytes; and that these have no special treatment. > > Agree, it was mostly a (personal) question. Thank you for the answer. I believe pointing the reference that explains the encoding helps a lot as well. -- as mentioned below. > MGLT: Maybe a reference to the types used could be added. >> > > OK. I have added a section like the following to both drafts: > > "1.2. Wire Encoding Terminology > > "The wire encoding types in this document - "byte", "uint32", "string", > "boolean", "name-list" - have meanings as described in [RFC4251]." > > > I have added a normative reference to RFC 4251 to both documents. > > That is really good. > > > This extension is sent by the server only, and contains a >> > list of signature algorithms that the server is able to >> > process as part of a "publickey" request. >> >> MGLT: I think we should also specify the server behavior, >> which MUST ignore the extension and MAY disconnect. >> > > Before addressing this - next comment about the same passage: > > ok > > MGLT: I might be wrong but if the client sends the list, >> it may be helpful for the server to narrow down its >> selection. In this case, it may look more as agreement. >> It may also be useful for the server to monitor the >> supported signatures requested by clients which could >> be helpful to understand when to deprecate authentication >> algorithms. >> > > I like this idea. > > Unfortunately though, the extension has already been implemented and > deployed as server-sig-algs". For this suggestion to not be confusing, the > client would have to send something like "client-sig-algs"; or perhaps, > just "sig-algs". > > Because the extension is already named, I have adopted the first one of > the above two comments. I have added the following phrasing: > > "If a client sends this extension, the server MAY ignore it, and MAY > disconnect." > > Fine. maybe we can add something to be a bit more specific : For example, the server may use this information.... > > > If a server does not send this extension, a client MUST >> > NOT make any assumptions about the server's signature >> > algorithm support, and MAY proceed with authentication >> > requests using trial and error. >> >> MGLT: Maybe some indication on penalties may be added here. >> > > OK. I have added: > > "Note that implementations are known to exist that apply authentication > penalties if the client attempts to use an unexpected signature algorithm." > > > OK > > If both parties send this extension, but the name-lists >> > do not contain a common algorithm in either direction, >> > the parties MUST disconnect in the same way as if >> > negotiation failed as part of SSH_MSG_KEXINIT. >> >> MGLT: As this looks like a renegotiation, for which reason >> do we need to disconnect the session and not simply ignore >> the exchange. >> > > Three responses: > > - One pre-condition for renegotiation to fail is that at least one party > fails to offer the "none" compression algorithm. In that case, this > behavior is consistent with KEXINIT, where we could say "OK, if no > compression can be agreed on, use none". But we don't, we disconnect. > > - Protocol errors result in disconnect because they are an unexpected > situation that guarantees there's an error somewhere. The "fail early" > principle applies. > > - Outside of this extension, SSH key re-exchange can be initiated with > changed settings such that the parties no longer agree on algorithms. In > this case also, there will be a disconnect. > > Above policy is consistent with existing behaviors, rather than > introducing a situation where failed renegotiation would mean disconnect in > some cases, and "ignore" in others. > > > Thanks for the clarification. > > string "no-flow-control" >> > string choice of: "p" for preferred | "s" for supported >> >> MGLT: description of the parameters would be helpful. >> > > OK. Added the following: > > "A party SHOULD send "s" if it supports "no-flow-control", but does not > prefer to enable it. A party SHOULD send "p" if it prefers to enable the > extension if the other party supports it. Parties MAY disconnect if they > receive a different extension value." > > OK > > > string "elevation" >> > string choice of: "y" | "n" | "d" >> >> MGLT: description of the parameters would be helpful. >> > > The next following paragraph defines the values. > > Perhaps I misunderstood, and the request is to define "string"? In this > case, this may be addressed by the new section 1.2, which references RFC > 4251 that defines "string". > string is now defined, basically I was asking for a similar sentence as the one you provided for the "no-flow-control" extension. > > > This was a number of comments, so if I missed anything, please let me > know. :-) > > Not that I know! Thanks for your complete answer! > denis > > > > ----- Original Message ----- > From: Daniel Migault > Sent: Saturday, March 25, 2017 17:24 > To: curdle > Subject: [Curdle] Comments on draft-ietf-curdle-ssh-ext-info-03 > > Hi, > > Thank you for moving that draft forward. Please see some comments on the > draft. > > Yours, > Daniel > > > > > Internet-Draft D. Bider > Updates: 4252, 4253, 4254 (if approved) Bitvise Limited > Intended status: Standards Track March 23, 2017 > Expires: September 23, 2017 > > > Extension Negotiation in Secure Shell (SSH) > draft-ietf-curdle-ssh-ext-info-03.txt > > > Abstract > > This memo defines a mechanism for SSH clients and servers to exchange > information about supported protocol extensions confidentially after > completed key exchange. > > Bider [Page 1] > > Internet-Draft Extension Negotiation in SSH March 2017 > > > 1. Overview and Rationale > > Secure Shell (SSH) is a common protocol for secure communication on > the Internet. The original design of the SSH transport layer [RFC4253] > lacks proper extension negotiation. Meanwhile, diverse implementations > take steps to ensure that known message types contain no unrecognized > information. This makes it difficult for implementations to signal > capabilities and negotiate extensions without risking disconnection. > > This obstacle has been recognized in relationship with [SSH-RSA-SHA2], > where the need arises for a client to discover signature algorithms a > server accepts, to avoid authentication penalties and trial-and-error. > > 1.1. Requirements Terminology > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. > > > 2. Extension Negotiation Mechanism > > 2.1. Signaling of Extension Negotiation in KEXINIT > > Applications implementing this mechanism MUST add to the field > "kex_algorithms", in their KEXINIT packet sent for the first key > exchange, one of the following indicator names: > > - When acting as server: "ext-info-s" > - When acting as client: "ext-info-c" > > The indicator name is added without quotes, and MAY be added at any > position in the name-list, subject to proper separation from other > names as per name-list conventions. > > The names are added to the "kex_algorithms" field because this is one > of two name-list fields in KEXINIT that do not have a separate copy > for each data direction. > > 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. > > The inclusion of textual indicator names is intended to provide a clue > for implementers to discover this mechanism. > > 2.2. Enabling Criteria > > If a client or server offers "ext-info-c" or "ext-info-s" > respectively, it MUST be prepared to accept an SSH_MSG_EXT_INFO > message from the peer. > > > Bider [Page 2] > > Internet-Draft Extension Negotiation in SSH March 2017 > > > Thus a server only needs to send "ext-info-s" if it intends to process > SSH_MSG_EXT_INFO from the client. > > If a server receives an "ext-info-c", it MAY send an SSH_MSG_EXT_INFO > message, but is not required to do so. > > If an SSH_MSG_EXT_INFO message is sent, then it MUST be the first > message after the initial SSH_MSG_NEWKEYS. > > Implementations MUST NOT send an incorrect indicator name for their > role. Implementations MAY disconnect if the counter-party sends an > incorrect indicator. If "ext-info-c" or "ext-info-s" ends up being > negotiated as a key exchange method, the parties MUST disconnect. > > MGLT: Shouldn't we have "Implementations MUST disconnect" ? At least we > should maybe state that it MUST ignore the indication. > > 2.3. SSH_MSG_EXT_INFO Message > > A party that received the "ext-info-c" or "ext-info-s" indicator > MAY send the following message: > > byte SSH_MSG_EXT_INFO (value 7) > uint32 nr-extensions > repeat "nr-extensions" times: > string extension-name > string extension-value > > MGLT: maybe the different terms/parameters could be defined. I am assuming > that an extenssion-name has a single extension-value. In other words, > extension-name is repeated. > > This message is sent immediately after SSH_MSG_NEWKEYS, without delay. > This allows a client to pipeline an authentication request after its > SSH_MSG_SERVICE_REQUEST, even when this needs extension information. > > 2.4. Server's Secondary SSH_MSG_EXT_INFO > > If the client sent "ext-info-c", the server MAY send, but is not > obligated to send, an SSH_MSG_EXT_INFO message immediately before (*) > SSH_MSG_USERAUTH_SUCCESS, as defined in [RFC4252]. The server MAY send > this message whether or not it sent EXT_INFO after SSH_MSG_NEWKEYS. > > MGLT: Maybe that would be clearer to split the sentence in two parts so > the "MAY" does not confuse the reader. > > OLD: > If the client sent "ext-info-c", the server MAY send, but is not > obligated to send, an SSH_MSG_EXT_INFO message immediately before (*) > SSH_MSG_USERAUTH_SUCCESS, as defined in [RFC4252]. > NEW: > If the client sent "ext-info-c", the server MAY send, but is not > obligated to send an SSH_MSG_EXT_INFO. If the server sends > SSH_MSG_EXT_INFO message it MUST be placed immediately before (*) > SSH_MSG_USERAUTH_SUCCESS, as defined in [RFC4252]. > -- It is not clear to me why immediately is needed. > > This allows a server to reveal support for additional extensions that > it was unwilling to reveal to an unauthenticated client. If a server > sends a subsequent SSH_MSG_EXT_INFO, this replaces any initial one, > and both the client and the server re-evaluate extensions in effect. > The server's last EXT_INFO is matched against the client's original. > > (*) The message MUST be sent at this point for the following reasons: > if it was sent earlier, it would not allow the server to withhold > information until the client has authenticated; if it was sent later, > a client that needs information from the second EXT_INFO immediately > after successful authentication would have no way of reliably knowing > whether there will be a second EXT_INFO or not. > > > > > > Bider [Page 3] > > Internet-Draft Extension Negotiation in SSH March 2017 > > > 2.5. Interpretation of Extension Names and Values > > Each extension is identified by its extension-name, and defines the > conditions under which the extension is considered to be in effect. > Applications MUST ignore unrecognized extension-names. > > In general, if an extension requires both the client and the server > to include it in order for the extension to take effect, the relative > position of the extension-name in each EXT_INFO message is irrelevant. > > MGLT: "In general" can be removed. I think the reader expects some > additional text that shows cases where the order matters. > > Extension-value fields are interpreted as defined by their respective > extension. An extension-value field MAY be empty if so permitted by > the extension. Applications that do not implement or recognize a > particular extension MUST ignore the associated extension-value field, > regardless of its size or content. > > MGLT: Is the \0 the delimiter to skip the value ? > > The cumulative size of an SSH_MSG_EXT_INFO message is limited only by > the maximum packet length that an implementation may apply in > accordance with [RFC4253]. Implementations MUST accept well-formed > SSH_MSG_EXT_INFO messages up to the maximum packet length they accept. > > > 3. Initially Defined Extensions > > 3.1. "server-sig-algs" > > This extension is sent with the following extension name and value: > > string "server-sig-algs" > name-list signature-algorithms-accepted > > Note that the name-list type is a strict subset of the string type, > and is thus permissible as an extension-value. > > MGLT: Maybe a reference to the types used could be added. > > This extension is sent by the server only, and contains a list of > signature algorithms that the server is able to process as part of a > "publickey" request. > > MGLT: I think we should also specify the server behavior, which MUST > ignore the extension and MAY disconnect. > > MGLT: I might be wrong but if the client sends the list, it may be helpful > for the server to narrow down its selection. In this case, it may look more > as agreement. It may also be useful for the server to monitor the supported > signatures requested by clients which could be helpful to understand when > to deprecate authentication algorithms. > > A client that wishes to proceed with public key authentication MAY > wait for the server's SSH_MSG_EXT_INFO so it can send a "publickey" > authentication request with an appropriate signature algorithm, rather > than resorting to trial and error. > > Servers that implement public key authentication SHOULD implement this > extension. > > If a server does not send this extension, a client MUST NOT make any > assumptions about the server's signature algorithm support, and MAY > proceed with authentication requests using trial and error. > > MGLT: Maybe some indication on penalties may be added here. > > > Bider [Page 4] > > Internet-Draft Extension Negotiation in SSH March 2017 > > > 3.2. "delay-compression" > > This extension MAY be sent by both parties as follows: > > string "delay-compression" > string: > name-list compression_algorithms_client_to_server > name-list compression_algorithms_server_to_client > > This extension allows the server and client to renegotiate compression > algorithm support without having to conduct a key re-exchange, putting > new algorithms into effect immediately upon successful authentication. > > This extension takes effect only if both parties send it. Name-lists > MAY include any compression algorithm that could have been negotiated > in SSH_MSG_KEXINIT, except algorithms that define their own delayed > compression semantics. This means "zlib,none" is a valid algorithm > list in this context; but "zlib@openssh.com" is not. > > If both parties send this extension, but the name-lists do not contain > a common algorithm in either direction, the parties MUST disconnect in > the same way as if negotiation failed as part of SSH_MSG_KEXINIT. > > MGLT: As this looks like a renegotiation, for which reason do we need to > disconnect the session and not simply ignore the exchange. > > If this extension takes effect, the renegotiated compression algorithm > is activated for the very next SSH message after the trigger message: > > - Sent by the server, the trigger message is SSH_MSG_USERAUTH_SUCCESS. > - Sent by the client, the trigger message is SSH_MSG_NEWCOMPRESS. > > If this extension takes effect, the client MUST send the following > message shortly after receiving SSH_MSG_USERAUTH_SUCCESS: > > byte SSH_MSG_NEWCOMPRESS (value 8) > > The purpose of this message is to avoid a race condition where the > server cannot reliably know whether a message sent by the client was > sent before or after receiving the server's USERAUTH_SUCCESS. > > As with all extensions, the server MAY delay including this extension > until its secondary SSH_MSG_EXT_INFO, sent before USERAUTH_SUCCESS. > This allows the server to avoid advertising compression support until > the client has been authenticated. > > If the parties re-negotiate compression using this extension in a > session where compression is already enabled; and the re-negotiated > algorithm is the same in one or both directions; then the internal > compression state MUST be reset for each direction at the time the > re-negotiated algorithm takes effect. > > > > > > Bider [Page 5] > > Internet-Draft Extension Negotiation in SSH March 2017 > > > 3.2.1. Awkwardly Timed Key Re-Exchange > > A party that has signaled, or intends to signal, support for this > extension in an SSH session, MUST NOT initiate key re-exchange in that > session until either of the following occurs: > > - This extension was negotiated, and the party that's about to start > key re-exchange already sent its trigger message for compression. > > - The party has sent (if server) or received (if client) the message > SSH_MSG_USERAUTH_SUCCESS, and this extension was not negotiated. > > If a party violates this rule, the other party MAY disconnect. > > In general, parties SHOULD NOT start key re-exchange before successful > user authentication, but MAY tolerate it if not using this extension. > > 3.2.2. Subsequent Re-Exchange > > In subsequent key re-exchanges that unambiguously begin after the > compression trigger messages, the compression algorithms negotiated in > re-exchange override the algorithms negotiated with this extension. > > > 3.3. "no-flow-control" > > This extension is sent with the following extension name and value: > > string "no-flow-control" > string choice of: "p" for preferred | "s" for supported > > MGLT: description of the parameters would be helpful. > > To take effect, this extension MUST be: > > - Sent by both parties. > - At least one party MUST have sent the value "p" (preferred). > > If this extension takes effect, the "initial window size" fields in > SSH_MSG_CHANNEL_OPEN and SSH_MSG_CHANNEL_OPEN_CONFIRMATION, as defined > in [RFC4254], become meaningless. The values of these fields MUST be > ignored, and a channel behaves as if all window sizes are infinite. > Neither side is required to send any SSH_MSG_CHANNEL_WINDOW_ADJUST > messages, and if received, such messages MUST be ignored. > > This extension is intended, but not limited to, use by file transfer > applications that are only going to use one channel, and for which the > flow control provided by SSH is an impediment, rather than a feature. > > Implementations MUST refuse to open more than one simultaneous channel > when this extension is in effect. Nevertheless, server implementations > SHOULD support clients opening more than one non-simultaneous channel. > > > > Bider [Page 6] > > Internet-Draft Extension Negotiation in SSH March 2017 > > > 3.4. "elevation" > > This extension MAY be sent by the client as follows: > > string "elevation" > string choice of: "y" | "n" | "d" > > MGLT: description of the parameters would be helpful. > > A client sends "y" to indicate its preference that the session should > be elevated (as used by Windows); "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. > > If a client has included this extension, then after authentication, a > server that supports this extension SHOULD indicate to the client > whether elevation was done by sending the following global request: > > byte SSH_MSG_GLOBAL_REQUEST > string "elevation" > boolean want reply = false > boolean elevation performed > > > 4. IANA Considerations > > 4.1. Additions to existing tables > > IANA is requested to insert the following entries into the table > Message Numbers under Secure Shell (SSH) Protocol Parameters > [RFC4250]: > > Value Message ID Reference > 7 SSH_MSG_EXT_INFO [this document] > 8 SSH_MSG_NEWCOMPRESS [this document] > > IANA is requested to insert the following entries into the table Key > Exchange Method Names: > > Method Name Reference Note > ext-info-s [this document] Section 2.2 > ext-info-c [this document] Section 2.2 > > 4.2. New table: Extension Names > > Also under Secure Shell (SSH) Protocol Parameters, IANA is requested > to create a new table, Extension Names, with initial content: > > Extension Name Reference Note > server-sig-algs [this document] Section 3.1 > delay-compression [this document] Section 3.2 > no-flow-control [this document] Section 3.3 > elevation [this document] Section 3.4 > > > Bider [Page 7] > > Internet-Draft Extension Negotiation in SSH March 2017 > > > 4.2.1. Future Assignments to Extension Names > > Names in the Extension Names table MUST follow the Conventions for > Names defined in [RFC4250], Section 4.6.1. > > Requests for assignments of new non-local names in the Extension Names > table (i.e. names not including the '@' character) MUST be done > through the IETF CONSENSUS method, as described in [RFC5226]. > > > 5. References > > 5.1. Normative References > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. > > [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) > Protocol Assigned Numbers", RFC 4250, January 2006. > > [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) > Authentication Protocol", RFC 4252, January 2006. > > [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) > Transport Layer Protocol", RFC 4253, January 2006. > > [RFC4254] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) > Connection Protocol", RFC 4254, January 2006. > > [RFC5226] Narten, T. and Alvestrand, H., "Guidelines for Writing an > IANA Considerations Section in RFCs", BCP 26, RFC 5226, > May 2008. > > 5.2. Informative References > > [SSH-RSA-SHA2] > Bider, D., "Use of RSA Keys with SHA-2 256 and 512 in > Secure Shell (SSH)", draft-ietf-curdle-rsa-sha2-03.txt, > February 2017, draft-ietf-curdle-rsa-sha2-03>. > > > > > > > > > > > > > > Bider [Page 8] > > Internet-Draft Extension Negotiation in SSH March 2017 > > > Author's Address > > Denis Bider > Bitvise Limited > Suites 41/42, Victoria House > 26 Main Street > GI > > Phone: +506 8315 6519 > EMail: ietf-ssh3@denisbider.com > URI: https://www.bitvise.com/ > > > Acknowledgments > > Thanks to Markus Friedl and Damien Miller for comments and initial > implementation. Thanks to Peter Gutmann and Roumen Petrov for review > and feedback. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Bider [Page 9] > > > > _______________________________________________ > 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 > --f403045fbba8aecaa8054ba8ade0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Denis,

Thanks you for the = response. My understanding is that the next version of the draft will be cl= ose to final.

Yours,
Daniel
=

On Sun, Mar 26, 2= 017 at 2:59 PM, denis bider (Bitvise) <ietf-ssh3@denisbider.com= > wrote:
Dan= iel:


> Implementations MUST NOT send an incorrect indicator name
> for their role. Implementations MAY disconnect if the
> counter-party sends an incorrect indicator. If "ext-info-c"<= br> > or "ext-info-s" ends up being negotiated as a key exchange > method, the parties MUST disconnect.

 Shouldn't we have "Implementations MUST disconnect" ? At
least we should maybe state that it MUST ignore the indication.

I try to avoid burdens that aren't strictly required, on the basis that= it may cause implementers to ignore instructions when it matters.

There's a "MUST NOT send" here that makes the situation clear= and unambiguous. "MAY disconnect" allows an implementation to po= lice this. I didn't put in an "everyone MUST police this rule"= ; because I don't see strong added value.


OK
=C2=A0
> uint32=C2=A0 =C2=A0 =C2=A0nr-extensions
> repeat "nr-extensions" times:
>=C2=A0 =C2=A0string=C2=A0 =C2=A0extension-name
>=C2=A0 =C2=A0string=C2=A0 =C2=A0extension-value

MGLT: maybe the different terms/parameters could be
defined. I am assuming that an extenssion-name has
a single extension-value. In other words,
extension-name is repeated.

 The tuple (extension-name, extension-value) is repeated. The inclusion of b= oth fields in repetition is meant to be implied by their indent.

To make this clearer in case the indent is lost, I will be changing the ins= truction to:

=C2=A0repeat the following 2 fields "nr-extensions" times:


Sounds clearer to me thanks.
=C2=A0
> If the client sent "ext-info-c", the server MAY send,
> but is not obligated to send, an SSH_MSG_EXT_INFO
> message immediately before (*) SSH_MSG_USERAUTH_SUCCESS,
> as defined in [RFC4252]. The server MAY send this message
> whether or not it sent EXT_INFO after SSH_MSG_NEWKEYS.

MGLT: Maybe that would be clearer to split the sentence in
two parts so the "MAY" does not confuse the reader.

 OK. I have tried to improve clarity by rewording this paragraph as follows:=

"If the client sent "ext-info-c", the server MAY send zero, = one, or two EXT_INFO messages. The first opportunity for the server's E= XT_INFO is after the server's NEWKEYS, as above. The second opportunity= is just before (*) SSH_MSG_USERAUTH_SUCCESS, as defined in [RFC4252]. The = server MAY send EXT_INFO at the second opportunity, whether or not it sent = it at the first. A client that sent "ext-info-c" MUST accept a se= rver's EXT_INFO at both opportunities, but MUST NOT require it."

This sounds to me much clearer, especially as = the two opportunities are mentioned.
=C2=A0
-- It is not clear to me why immediately is needed.

 OK, I have changed "immediately before" to "just before"= ; above.

The point is that the sequence of messages at the second EXT_INFO opportuni= ty is either (USERAUTH_SUCCESS) or (EXT_INFO, USERAUTH_SUCCESS); but not e.= g. (EXT_INFO, USERAUTH_FAILURE, more activity, USERAUTH_SUCCESS).

I think the previous rewording specify that, but= if you think that needs to be specified more precisely. I believe please c= onsider adding this text as well.=C2=A0

> In general, if an extension requires both the client
> and the server to include it

 MGLT: "In general" can be removed. I think the reader expects
some additional text that shows cases where the order matters.

OK. Removed "In general".


> Extension-value fields are interpreted as defined by their
> respective extension. An extension-value field MAY be empty
> if so permitted by the extension. Applications that do not
> implement or recognize a particular extension MUST ignore
> the associated extension-value field, regardless of its
> size or content.

MGLT: Is the \0 the delimiter to skip the value ?

 An SSH string is encoded as the tuple (word32 n, byte[n] content). Zero byt= es are valid content.

An empty string would be encoded as \0\0\0\0. So \0\0\0\0 would be an empty= extension-value.

If \0 appears in the string content of the extension-value, the meaning of = that is extension-specific.

I think this does not have to be explicitly clarified because an SSH implem= enter would know how an SSH string is encoded; that it can contain null byt= es; and that these have no special treatment.

Agree, it was mostly a (personal) question. Th= ank you for the answer. I believe pointing the reference that explains the = encoding helps a lot as well. -- as mentioned below.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
MGLT: Maybe a reference to the types used could be added.

 OK. I have added a section like the following to both drafts:

"1.2.=C2=A0 Wire Encoding Terminology

"The wire encoding types in this document - "byte", "ui= nt32", "string", "boolean", "name-list" = - have meanings as described in [RFC4251]."

<= /div>
=C2=A0

I have added a normative reference to RFC 4251 to both documents.

That is really good.=C2=A0

> This extension is sent by the server only, and contains a
> list of signature algorithms that the server is able to
> process as part of a "publickey" request.

MGLT: I think we should also specify the server behavior,
which MUST ignore the extension and MAY disconnect.

 Before addressing this - next comment about the same passage:

ok

MGLT: I might be wrong but if the client sends the list,
it may be helpful for the server to narrow down its
selection. In this case, it may look more as agreement.
It may also be useful for the server to monitor the
supported signatures requested by clients which could
be helpful to understand when to deprecate authentication
algorithms.

 I like this idea.

Unfortunately though, the extension has already been implemented and deploy= ed as server-sig-algs". For this suggestion to not be confusing, the c= lient would have to send something like "client-sig-algs"; or per= haps, just "sig-algs".

Because the extension is already named, I have adopted the first one of the= above two comments. I have added the following phrasing:

"If a client sends this extension, the server MAY ignore it, and MAY d= isconnect."

Fine. maybe we can add something to be a bit m= ore specific : For example, the server may use this information....

> If a server does not send this extension, a client MUST
> NOT make any assumptions about the server's signature
> algorithm support, and MAY proceed with authentication
> requests using trial and error.

MGLT: Maybe some indication on penalties may be added here.

 OK. I have added:

"Note that implementations are known to exist that apply authenticatio= n penalties if the client attempts to use an unexpected signature algorithm= ."


OK
> If both parties send this extension, but the name-lists
> do not contain a common algorithm in either direction,
> the parties MUST disconnect in the same way as if
> negotiation failed as part of SSH_MSG_KEXINIT.

MGLT: As this looks like a renegotiation, for which reason
do we need to disconnect the session and not simply ignore
the exchange.

 Three responses:

- One pre-condition for renegotiation to fail is that at least one party fa= ils to offer the "none" compression algorithm. In that case, this= behavior is consistent with KEXINIT, where we could say "OK, if no co= mpression can be agreed on, use none". But we don't, we disconnect= .

- Protocol errors result in disconnect because they are an unexpected situa= tion that guarantees there's an error somewhere. The "fail early&q= uot; principle applies.

- Outside of this extension, SSH key re-exchange can be initiated with chan= ged settings such that the parties no longer agree on algorithms. In this c= ase also, there will be a disconnect.

Above policy is consistent with existing behaviors, rather than introducing= a situation where failed renegotiation would mean disconnect in some cases= , and "ignore" in others.


Thanks for the clarification.
=C2=A0
> string=C2=A0 "no-flow-control"
> string=C2=A0 choice of: "p" for preferred | "s" fo= r supported

MGLT: description of the parameters would be helpful.

 OK. Added the following:

"A party SHOULD send "s" if it supports "no-flow-contro= l", but does not prefer to enable it. A party SHOULD send "p"= ; if it prefers to enable the extension if the other party supports it. Par= ties MAY disconnect if they receive a different extension value."

OK

> string=C2=A0 =C2=A0 =C2=A0 "elevation"
> string=C2=A0 =C2=A0 =C2=A0 choice of: "y" | "n" | = "d"

MGLT: description of the parameters would be helpful.

 The next following paragraph defines the values.

Perhaps I misunderstood, and the request is to define "string"? I= n this case, this may be addressed by the new section 1.2, which references= RFC 4251 that defines "string".
string is n= ow defined, basically I was asking for a similar sentence as the one you pr= ovided for the "no-flow-control" extension.


This was a number of comments, so if I missed anything, please let me know.= :-)

Not that I know! Thanks for your complete answer!
= =C2=A0
denis



----- Original Message -----
From: Daniel Migault
Sent: Saturday, March 25, 2017 17:24
To: curdle
Subject: [Curdle] Comments on draft-ietf-curdle-ssh-ext-info-03

Hi,

Thank you for moving that draft forward. Please see some comments on the dr= aft.

Yours,
Daniel




Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 D. Bider
Updates: 4252, 4253, 4254 (if approved)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 Bitvise Limited
Intended status: Standards Track=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 March 23, 2017
Expires: September 23, 2017


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Extension Negotiation in S= ecure Shell (SSH)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-cu= rdle-ssh-ext-info-03.txt


Abstract

=C2=A0This memo defines a mechanism for SSH clients and servers to exchange=
=C2=A0information about supported protocol extensions confidentially after<= br> =C2=A0completed key exchange.

Bider=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 1]<= br>
Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 Extension Negotiation in SSH=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 March 2017


1.=C2=A0 Overview and Rationale

=C2=A0Secure Shell (SSH) is a common protocol for secure communication on =C2=A0the Internet. The original design of the SSH transport layer [RFC4253= ]
=C2=A0lacks proper extension negotiation. Meanwhile, diverse implementation= s
=C2=A0take steps to ensure that known message types contain no unrecognized=
=C2=A0information. This makes it difficult for implementations to signal =C2=A0capabilities and negotiate extensions without risking disconnection.<= br>
=C2=A0This obstacle has been recognized in relationship with [SSH-RSA-SHA2]= ,
=C2=A0where the need arises for a client to discover signature algorithms a=
=C2=A0server accepts, to avoid authentication penalties and trial-and-error= .

1.1.=C2=A0 Requirements Terminology

=C2=A0The key words "MUST", "MUST NOT", "REQUIRED&= quot;, "SHALL", "SHALL NOT",
=C2=A0"SHOULD", "SHOULD NOT", "RECOMMENDED", = "MAY", and "OPTIONAL" in this
=C2=A0document are to be interpreted as described in [RFC2119].


2.=C2=A0 Extension Negotiation Mechanism

2.1.=C2=A0 Signaling of Extension Negotiation in KEXINIT

=C2=A0Applications implementing this mechanism MUST add to the field
=C2=A0"kex_algorithms", in their KEXINIT packet sent for the firs= t key
=C2=A0exchange, one of the following indicator names:

=C2=A0- When acting as server: "ext-info-s"
=C2=A0- When acting as client: "ext-info-c"

=C2=A0The indicator name is added without quotes, and MAY be added at any =C2=A0position in the name-list, subject to proper separation from other =C2=A0names as per name-list conventions.

=C2=A0The names are added to the "kex_algorithms" field because t= his is one
=C2=A0of two name-list fields in KEXINIT that do not have a separate copy =C2=A0for each data direction.

=C2=A0The indicator names inserted by the client and server are different t= o
=C2=A0ensure that these names will not produce a match, and will be neutral=
=C2=A0with respect to key exchange algorithm negotiation.

=C2=A0The inclusion of textual indicator names is intended to provide a clu= e
=C2=A0for implementers to discover this mechanism.

2.2.=C2=A0 Enabling Criteria

=C2=A0If a client or server offers "ext-info-c" or "ext-info= -s"
=C2=A0respectively, it MUST be prepared to accept an SSH_MSG_EXT_INFO
=C2=A0message from the peer.


Bider=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 2]<= br>
Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 Extension Negotiation in SSH=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 March 2017


=C2=A0Thus a server only needs to send "ext-info-s" if it intends= to process
=C2=A0SSH_MSG_EXT_INFO from the client.

=C2=A0If a server receives an "ext-info-c", it MAY send an SSH_MS= G_EXT_INFO
=C2=A0message, but is not required to do so.

=C2=A0If an SSH_MSG_EXT_INFO message is sent, then it MUST be the first
=C2=A0message after the initial SSH_MSG_NEWKEYS.

=C2=A0Implementations MUST NOT send an incorrect indicator name for their =C2=A0role. Implementations MAY disconnect if the counter-party sends an =C2=A0incorrect indicator. If "ext-info-c" or "ext-info-s&qu= ot; ends up being
=C2=A0negotiated as a key exchange method, the parties MUST disconnect.

MGLT: Shouldn't we have "Implementations MUST disconnect" ? A= t least we should maybe state that it MUST ignore the indication.

2.3.=C2=A0 SSH_MSG_EXT_INFO Message

A party that received the "ext-info-c" or "ext-info-s" = indicator
MAY send the following message:

=C2=A0 =C2=A0byte=C2=A0 =C2=A0 =C2=A0 =C2=A0SSH_MSG_EXT_INFO (value 7)
=C2=A0 =C2=A0uint32=C2=A0 =C2=A0 =C2=A0nr-extensions
=C2=A0 =C2=A0repeat "nr-extensions" times:
=C2=A0 =C2=A0 =C2=A0string=C2=A0 =C2=A0extension-name
=C2=A0 =C2=A0 =C2=A0string=C2=A0 =C2=A0extension-value

MGLT: maybe the different terms/parameters could be defined. I am assuming = that an extenssion-name has a single extension-value. In other words, exten= sion-name is repeated.

=C2=A0This message is sent immediately after SSH_MSG_NEWKEYS, without delay= .
=C2=A0This allows a client to pipeline an authentication request after its<= br> =C2=A0SSH_MSG_SERVICE_REQUEST, even when this needs extension information.<= br>
2.4.=C2=A0 Server's Secondary SSH_MSG_EXT_INFO

=C2=A0If the client sent "ext-info-c", the server MAY send, but i= s not
=C2=A0obligated to send, an SSH_MSG_EXT_INFO message immediately before (*)=
=C2=A0SSH_MSG_USERAUTH_SUCCESS, as defined in [RFC4252]. The server MAY sen= d
=C2=A0this message whether or not it sent EXT_INFO after SSH_MSG_NEWKEYS.
MGLT: Maybe that would be clearer to split the sentence in two parts so the= "MAY" does not confuse the reader.

OLD:
If the client sent "ext-info-c", the server MAY send, but is not<= br> =C2=A0obligated to send, an SSH_MSG_EXT_INFO message immediately before (*)=
=C2=A0SSH_MSG_USERAUTH_SUCCESS, as defined in [RFC4252].
NEW:
=C2=A0If the client sent "ext-info-c", the server MAY send, but i= s not
=C2=A0obligated to send an SSH_MSG_EXT_INFO. If the server sends SSH_MSG_EX= T_INFO message it MUST be placed immediately before (*)
=C2=A0SSH_MSG_USERAUTH_SUCCESS, as defined in [RFC4252].
=C2=A0-- It is not clear to me why immediately is needed.

=C2=A0This allows a server to reveal support for additional extensions that=
=C2=A0it was unwilling to reveal to an unauthenticated client. If a server<= br> =C2=A0sends a subsequent SSH_MSG_EXT_INFO, this replaces any initial one, =C2=A0and both the client and the server re-evaluate extensions in effect.<= br> =C2=A0The server's last EXT_INFO is matched against the client's or= iginal.

=C2=A0(*) The message MUST be sent at this point for the following reasons:=
=C2=A0if it was sent earlier, it would not allow the server to withhold
=C2=A0information until the client has authenticated; if it was sent later,=
=C2=A0a client that needs information from the second EXT_INFO immediately<= br> =C2=A0after successful authentication would have no way of reliably knowing=
=C2=A0whether there will be a second EXT_INFO or not.





Bider=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 3]<= br>
Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 Extension Negotiation in SSH=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 March 2017


2.5.=C2=A0 Interpretation of Extension Names and Values

=C2=A0Each extension is identified by its extension-name, and defines the =C2=A0conditions under which the extension is considered to be in effect. =C2=A0Applications MUST ignore unrecognized extension-names.

=C2=A0In general, if an extension requires both the client and the server =C2=A0to include it in order for the extension to take effect, the relative=
=C2=A0position of the extension-name in each EXT_INFO message is irrelevant= .

MGLT: "In general" can be removed. I think the reader expects som= e additional text that shows cases where the order matters.

=C2=A0Extension-value fields are interpreted as defined by their respective=
=C2=A0extension. An extension-value field MAY be empty if so permitted by =C2=A0the extension. Applications that do not implement or recognize a
=C2=A0particular extension MUST ignore the associated extension-value field= ,
=C2=A0regardless of its size or content.

MGLT: Is the \0 the delimiter to skip the value ?

=C2=A0The cumulative size of an SSH_MSG_EXT_INFO message is limited only by=
=C2=A0the maximum packet length that an implementation may apply in
=C2=A0accordance with [RFC4253]. Implementations MUST accept well-formed =C2=A0SSH_MSG_EXT_INFO messages up to the maximum packet length they accept= .


3. Initially Defined Extensions

3.1. "server-sig-algs"

=C2=A0This extension is sent with the following extension name and value:
=C2=A0 =C2=A0string=C2=A0 =C2=A0 =C2=A0 "server-sig-algs"
=C2=A0 =C2=A0name-list=C2=A0 =C2=A0signature-algorithms-accepted

=C2=A0Note that the name-list type is a strict subset of the string type, =C2=A0and is thus permissible as an extension-value.

MGLT: Maybe a reference to the types used could be added.

=C2=A0This extension is sent by the server only, and contains a list of
=C2=A0signature algorithms that the server is able to process as part of a<= br> =C2=A0"publickey" request.

MGLT: I think we should also specify the server behavior, which MUST ignore= the extension and MAY disconnect.

MGLT: I might be wrong but if the client sends the list, it may be helpful = for the server to narrow down its selection. In this case, it may look more= as agreement. It may also be useful for the server to monitor the supporte= d signatures requested by clients which could be helpful to understand when= to deprecate authentication algorithms.

=C2=A0A client that wishes to proceed with public key authentication MAY =C2=A0wait for the server's SSH_MSG_EXT_INFO so it can send a "pub= lickey"
=C2=A0authentication request with an appropriate signature algorithm, rathe= r
=C2=A0than resorting to trial and error.

=C2=A0Servers that implement public key authentication SHOULD implement thi= s
=C2=A0extension.

=C2=A0If a server does not send this extension, a client MUST NOT make any<= br> =C2=A0assumptions about the server's signature algorithm support, and M= AY
=C2=A0proceed with authentication requests using trial and error.

MGLT: Maybe some indication on penalties may be added here.


Bider=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 4]<= br>
Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 Extension Negotiation in SSH=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 March 2017


3.2.=C2=A0 "delay-compression"

=C2=A0This extension MAY be sent by both parties as follows:

=C2=A0 =C2=A0string=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"delay-compressio= n"
=C2=A0 =C2=A0string:
=C2=A0 =C2=A0 =C2=A0name-list=C2=A0 =C2=A0 compression_algorithms_client_to_server
=C2=A0 =C2=A0 =C2=A0name-list=C2=A0 =C2=A0 compression_algorithms_server_to_client

=C2=A0This extension allows the server and client to renegotiate compressio= n
=C2=A0algorithm support without having to conduct a key re-exchange, puttin= g
=C2=A0new algorithms into effect immediately upon successful authentication= .

=C2=A0This extension takes effect only if both parties send it. Name-lists<= br> =C2=A0MAY include any compression algorithm that could have been negotiated=
=C2=A0in SSH_MSG_KEXINIT, except algorithms that define their own delayed =C2=A0compression semantics. This means "zlib,none" is a valid al= gorithm
=C2=A0list in this context; but "zlib@openssh.com" is not.

=C2=A0If both parties send this extension, but the name-lists do not contai= n
=C2=A0a common algorithm in either direction, the parties MUST disconnect i= n
=C2=A0the same way as if negotiation failed as part of SSH_MSG_KEXINIT.

MGLT: As this looks like a renegotiation, for which reason do we need to di= sconnect the session and not simply ignore the exchange.

=C2=A0If this extension takes effect, the renegotiated compression algorith= m
=C2=A0is activated for the very next SSH message after the trigger message:=

=C2=A0- Sent by the server, the trigger message is SSH_MSG_USERAUTH_SUCCESS= .
=C2=A0- Sent by the client, the trigger message is SSH_MSG_NEWCOMPRESS.

=C2=A0If this extension takes effect, the client MUST send the following =C2=A0message shortly after receiving SSH_MSG_USERAUTH_SUCCESS:

=C2=A0 =C2=A0byte=C2=A0 =C2=A0 =C2=A0 =C2=A0SSH_MSG_NEWCOMPRESS (value 8)
=C2=A0The purpose of this message is to avoid a race condition where the =C2=A0server cannot reliably know whether a message sent by the client was<= br> =C2=A0sent before or after receiving the server's USERAUTH_SUCCESS.

=C2=A0As with all extensions, the server MAY delay including this extension=
=C2=A0until its secondary SSH_MSG_EXT_INFO, sent before USERAUTH_SUCCESS. =C2=A0This allows the server to avoid advertising compression support until=
=C2=A0the client has been authenticated.

=C2=A0If the parties re-negotiate compression using this extension in a
=C2=A0session where compression is already enabled; and the re-negotiated =C2=A0algorithm is the same in one or both directions; then the internal =C2=A0compression state MUST be reset for each direction at the time the =C2=A0re-negotiated algorithm takes effect.





Bider=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 5]<= br>
Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 Extension Negotiation in SSH=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 March 2017


3.2.1.=C2=A0 Awkwardly Timed Key Re-Exchange

=C2=A0A party that has signaled, or intends to signal, support for this
=C2=A0extension in an SSH session, MUST NOT initiate key re-exchange in tha= t
=C2=A0session until either of the following occurs:

=C2=A0- This extension was negotiated, and the party that's about to st= art
=C2=A0 =C2=A0key re-exchange already sent its trigger message for compressi= on.

=C2=A0- The party has sent (if server) or received (if client) the message<= br> =C2=A0 =C2=A0SSH_MSG_USERAUTH_SUCCESS, and this extension was not negotiate= d.

=C2=A0If a party violates this rule, the other party MAY disconnect.

=C2=A0In general, parties SHOULD NOT start key re-exchange before successfu= l
=C2=A0user authentication, but MAY tolerate it if not using this extension.=

3.2.2.=C2=A0 Subsequent Re-Exchange

=C2=A0In subsequent key re-exchanges that unambiguously begin after the
=C2=A0compression trigger messages, the compression algorithms negotiated i= n
=C2=A0re-exchange override the algorithms negotiated with this extension.

3.3.=C2=A0 "no-flow-control"

=C2=A0This extension is sent with the following extension name and value:
=C2=A0 =C2=A0string=C2=A0 =C2=A0 =C2=A0 "no-flow-control"
=C2=A0 =C2=A0string=C2=A0 =C2=A0 =C2=A0 choice of: "p" for prefer= red | "s" for supported

MGLT: description of the parameters would be helpful.

=C2=A0To take effect, this extension MUST be:

=C2=A0- Sent by both parties.
=C2=A0- At least one party MUST have sent the value "p" (preferre= d).

=C2=A0If this extension takes effect, the "initial window size" f= ields in
=C2=A0SSH_MSG_CHANNEL_OPEN and SSH_MSG_CHANNEL_OPEN_CONFIRMATION, as d= efined
=C2=A0in [RFC4254], become meaningless. The values of these fields MUST be<= br> =C2=A0ignored, and a channel behaves as if all window sizes are infinite. =C2=A0Neither side is required to send any SSH_MSG_CHANNEL_WINDOW_ADJUST =C2=A0messages, and if received, such messages MUST be ignored.

=C2=A0This extension is intended, but not limited to, use by file transfer<= br> =C2=A0applications that are only going to use one channel, and for which th= e
=C2=A0flow control provided by SSH is an impediment, rather than a feature.=

=C2=A0Implementations MUST refuse to open more than one simultaneous channe= l
=C2=A0when this extension is in effect. Nevertheless, server implementation= s
=C2=A0SHOULD support clients opening more than one non-simultaneous channel= .



Bider=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 6]<= br>
Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 Extension Negotiation in SSH=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 March 2017


3.4.=C2=A0 "elevation"

=C2=A0This extension MAY be sent by the client as follows:

=C2=A0 =C2=A0string=C2=A0 =C2=A0 =C2=A0 "elevation"
=C2=A0 =C2=A0string=C2=A0 =C2=A0 =C2=A0 choice of: "y" | "n&= quot; | "d"

MGLT: description of the parameters would be helpful.

=C2=A0A client sends "y" to indicate its preference that the sess= ion should
=C2=A0be elevated (as used by Windows); "n" to not be elevated; a= nd "d" for
=C2=A0the server to use its default behavior. If a client does not send the=
=C2=A0"elevation" extension, the server SHOULD act as if "d&= quot; was sent.

=C2=A0If a client has included this extension, then after authentication, a=
=C2=A0server that supports this extension SHOULD indicate to the client
=C2=A0whether elevation was done by sending the following global request:
=C2=A0 =C2=A0byte=C2=A0 =C2=A0 =C2=A0 =C2=A0 SSH_MSG_GLOBAL_REQUEST
=C2=A0 =C2=A0string=C2=A0 =C2=A0 =C2=A0 "elevation"
=C2=A0 =C2=A0boolean=C2=A0 =C2=A0 =C2=A0want reply =3D false
=C2=A0 =C2=A0boolean=C2=A0 =C2=A0 =C2=A0elevation performed


4.=C2=A0 IANA Considerations

4.1.=C2=A0 Additions to existing tables

=C2=A0IANA is requested to insert the following entries into the table
=C2=A0Message Numbers under Secure Shell (SSH) Protocol Parameters
=C2=A0[RFC4250]:

=C2=A0 =C2=A0Value=C2=A0 =C2=A0 Message ID=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Reference
=C2=A0 =C2=A07=C2=A0 =C2=A0 =C2=A0 =C2=A0 SSH_MSG_EXT_INFO=C2=A0 =C2=A0 =C2= =A0 =C2=A0[this document]
=C2=A0 =C2=A08=C2=A0 =C2=A0 =C2=A0 =C2=A0 SSH_MSG_NEWCOMPRESS=C2=A0 =C2=A0 = [this document]

=C2=A0IANA is requested to insert the following entries into the table Key<= br> =C2=A0Exchange Method Names:

=C2=A0 =C2=A0Method Name=C2=A0 =C2=A0 =C2=A0Reference=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 Note
=C2=A0 =C2=A0ext-info-s=C2=A0 =C2=A0 =C2=A0 [this document]=C2=A0 =C2=A0 Se= ction 2.2
=C2=A0 =C2=A0ext-info-c=C2=A0 =C2=A0 =C2=A0 [this document]=C2=A0 =C2=A0 Se= ction 2.2

4.2.=C2=A0 New table: Extension Names

=C2=A0Also under Secure Shell (SSH) Protocol Parameters, IANA is requested<= br> =C2=A0to create a new table, Extension Names, with initial content:

=C2=A0 =C2=A0Extension Name=C2=A0 =C2=A0 =C2=A0 =C2=A0Reference=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Note
=C2=A0 =C2=A0server-sig-algs=C2=A0 =C2=A0 =C2=A0 [this document]=C2=A0 =C2= =A0 Section 3.1
=C2=A0 =C2=A0delay-compression=C2=A0 =C2=A0 [this document]=C2=A0 =C2=A0 Se= ction 3.2
=C2=A0 =C2=A0no-flow-control=C2=A0 =C2=A0 =C2=A0 [this document]=C2=A0 =C2= =A0 Section 3.3
=C2=A0 =C2=A0elevation=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [this docum= ent]=C2=A0 =C2=A0 Section 3.4


Bider=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 7]<= br>
Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 Extension Negotiation in SSH=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 March 2017


4.2.1.=C2=A0 Future Assignments to Extension Names

=C2=A0Names in the Extension Names table MUST follow the Conventions for =C2=A0Names defined in [RFC4250], Section 4.6.1.

=C2=A0Requests for assignments of new non-local names in the Extension Name= s
=C2=A0table (i.e. names not including the '@' character) MUST be do= ne
=C2=A0through the IETF CONSENSUS method, as described in [RFC5226].


5.=C2=A0 References

5.1.=C2=A0 Normative References

=C2=A0[RFC2119]=C2=A0 =C2=A0Bradner, S., "Key words for use in RFCs to= Indicate
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Requirement Levels", B= CP 14, RFC 2119, March 1997.

=C2=A0[RFC4250]=C2=A0 =C2=A0Lehtinen, S. and C. Lonvick, Ed., "The Sec= ure Shell (SSH)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Protocol Assigned Numbers&q= uot;, RFC 4250, January 2006.

=C2=A0[RFC4252]=C2=A0 =C2=A0Ylonen, T. and C. Lonvick, Ed., "The Secur= e Shell (SSH)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authentication Protocol&quo= t;, RFC 4252, January 2006.

=C2=A0[RFC4253]=C2=A0 =C2=A0Ylonen, T. and C. Lonvick, Ed., "The Secur= e Shell (SSH)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Transport Layer Protocol&qu= ot;, RFC 4253, January 2006.

=C2=A0[RFC4254]=C2=A0 =C2=A0Ylonen, T. and C. Lonvick, Ed., "The Secur= e Shell (SSH)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Connection Protocol", = RFC 4254, January 2006.

=C2=A0[RFC5226]=C2=A0 =C2=A0Narten, T. and Alvestrand, H., "Guidelines= for Writing an
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IANA Considerations Section= in RFCs", BCP 26, RFC 5226,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0May 2008.

5.2.=C2=A0 Informative References

=C2=A0[SSH-RSA-SHA2]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Bider, D., "Use of RSA= Keys with SHA-2 256 and 512 in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Secure Shell (SSH)", d= raft-ietf-curdle-rsa-sha2-03.txt,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0February 2017, <http= s://tools.ietf.org/html/
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-curdle-rsa-sha2-= 03>.













Bider=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 8]<= br>
Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 Extension Negotiation in SSH=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 March 2017


Author's Address

=C2=A0Denis Bider
=C2=A0Bitvise Limited
=C2=A0Suites 41/42, Victoria House
=C2=A026 Main Street
=C2=A0GI

=C2=A0Phone: +506 8315 6519
=C2=A0EMail: = ietf-ssh3@denisbider.com
=C2=A0URI:=C2=A0 =C2=A0https://www.bitvise.com/


Acknowledgments

=C2=A0Thanks to Markus Friedl and Damien Miller for comments and initial =C2=A0implementation. Thanks to Peter Gutmann and Roumen Petrov for review<= br> =C2=A0and feedback.



































Bider=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 9]<= br>


_______________________________________________
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

--f403045fbba8aecaa8054ba8ade0-- From denisbider.ietf@gmail.com Sun Mar 26 17:27:29 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 98DE7120326 for ; Sun, 26 Mar 2017 17:27:29 -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 FP8gl6aet8to for ; Sun, 26 Mar 2017 17:27:26 -0700 (PDT) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e: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 82E8A1200F1 for ; Sun, 26 Mar 2017 17:27:26 -0700 (PDT) Received: by mail-pg0-x22c.google.com with SMTP id 21so22727994pgg.1 for ; Sun, 26 Mar 2017 17:27:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=E/leq+9CG6UaswMGgUih7MS//sAcw+X2NxB3ZSjR1CA=; b=vIeqmSMP9i70ua9NYP+OYgeA+8Asb/bWv9JYF8Cj028EFSnbGJO9r50JpXw6rEI7Dr z/u+kZNvuxC7HFePDr15rOYjvfa4ZK/9LWL5ie/2j1r4pmWfEmL6z/sz6CiopkurCra9 AzeuNrtuLtShLK9nXMm9tYFlphlN08DLIPaJ9gKeKYGhddmRi6ZiB/lC7VCMYUTPIiRE qjJDPVzqVHbAnQJWUX6YIfY/CZRpfjbq3qqUmwM0jVq8ljfzavw5gC8okNj0FUyWtfLS m8oH2XLFSl4iyDgpfOYNoGQ/NiAzoeSnYR1gAlv+eQfrnN+ihspBYgjDXATVvplUFvhi +z0A== 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=E/leq+9CG6UaswMGgUih7MS//sAcw+X2NxB3ZSjR1CA=; b=PesnHmdWuiP6q4IMX06aIv671EaAvvOFk5q+vhOaix5MPHYwAr+zAplziW9TR28BDd kt/sz9niDbOFl6By87llb3lEagc25kvO3o6xjPW9iEUhkBya8ktyvHgTgPa49sB6p8L2 K+UZQLdx97xgBW9AsSh4Dw3BzogktfWLJfgxnsvFVv6XaYNz6JmYY6tmeBpfxqTGJKqO RUqV5UDOb5U1vtrGaxg12Z8Mwfovb/dqyea+LmsS7SR9uxkmdRrcba9O2Z2qsNQ+V9Ia Kp+VOAWt6TWo7domMw5qKQ1gYAKYxfOuvuXCz1zVjMAY5FbNsF3w0tTGu6+RwRb/etGc eftw== X-Gm-Message-State: AFeK/H0ewgqLl7hwNH+ntxR6c0D2v3E5wNqGsQH29vlM9pCNNTbc0Lj47SojRDMnI+SpsTrQUik6sSckDl88BA== X-Received: by 10.98.86.152 with SMTP id h24mr21790106pfj.184.1490574445974; Sun, 26 Mar 2017 17:27:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.179.41 with HTTP; Sun, 26 Mar 2017 17:27:25 -0700 (PDT) From: denis bider Date: Sun, 26 Mar 2017 18:27:25 -0600 Message-ID: To: daniel.migault@ericsson.com, curdle@ietf.org Content-Type: multipart/alternative; boundary=001a1147d6205d1fd0054bab683e Archived-At: Subject: Re: [Curdle] comments on draft-ietf-curdle-rsa-sha2-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, 27 Mar 2017 00:28:48 -0000 --001a1147d6205d1fd0054bab683e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I created this new address for Curdle to avoid mailing list delivery issues due to DKIM and SPF. Daniel: > I believe it would be good to add rsa-sha2-256-pss, rsa-sha2-512-pss. I can do that, but the next question is, will someone implement it? If someone comes forward and says they'll be adding the PSS variants, I can definitely include them. If we do add them, this will make Peter unhappy. :) If my recollection serves, he disliked the 512 variant, as it is. The objection with additional variants is that if a fraction of deployments are set up to require them, this puts pressure on others to implement them as well. For Peter, this is a cost because his usage cases are extremely constrained. > Maybe that would be good to explain how the option is also > helping to deprecate suites in the security consideration section. OK. I have added the following: "This document is based on the premise that RSA is used in environments where a gradual, compatible transition to improved algorithms will be better received than one that is abrupt and incompatible. It advises that SSH implementations add support for new RSA signature algorithms along with SSH_MSG_EXT_INFO and the "server-sig-algs" extension to allow coexistence of new deployments with older versions that support only "ssh-rsa". Nevertheless, implementations SHOULD start to disable "ssh-rsa" in their default configurations as soon as they have reason to believe that new RSA signature algorithms have been widely adopted." Does this sound well? denis ----- Original Message ----- From: Daniel Migault Sent: Sunday, March 26, 2017 14:39 To: denis bider (Bitvise) Cc: curdle Subject: Re: [Curdle] comments on draft-ietf-curdle-rsa-sha2-03.txt Hi, Thanks for the response. Please see mine inline. In short I agree with your responses. I believe it would be good to add rsa-sha2-256-pss, rsa-sha2-512-pss. Yours, Daniel On Sun, Mar 26, 2017 at 12:56 PM, denis bider (Bitvise) < ietf-ssh3@denisbider.com> wrote: Daniel: Should we consider adding / replacing PKCS1v1.5 by RSA-PSS for the signature format. An early version of the spec called for PSS. After strong objections - most prominently Peter Gutmann's; it is possible there were others - I changed back to PKCS1v1.5. The main objections were: - PSS is not as universally available; - adding a new type of padding would impose costs on highly resource-constrained implementations who would now have to support both. I have no objections to adding PSS. At this point, it would have to be added as separate variants. For example: rsa-sha2-256-pss, rsa-sha2-512-pss= . The existing names already have widely implemented / accepted meanings with PKCS1v1.5. I understand the motivations. I personally think it would be good to add rsa-sha2-256-pss, rsa-sha2-512-pss I understand that penalties are encouraging to keep ssh-rsa while the use of sha1 is deprecated. I suggest to provide some recommendations on how to perform penalties. The issue are penalties in software already deployed. Servers are often used for 5-10 years without update. Users actively resist updates, even if we urge otherwise. Often, there's no one to perform an update. The administrator who configured the server has left. The people who use it are afraid, because they don't have anyone who understands their setup if it breaks. A new spec won't fix this deployed base. Software that's aware of this spec is suggested to implement the "server-sig-algs" extension with EXT_INFO. This eliminates any need to guess what signature algorithm to use. That is this spec's recommendation. Agree, my recommendation on penalties was mostly for new implementations that do not implement ext_info. Maybe you are right having ext_info solve this issue better. MGLT: Can we recommend to have penalties only applies when algorithms are weaker than the one supported. The issue does not arise from implementations penalizing known algorithms, it arises from old software penalizing unknown algorithms. Old software cannot know whether an unknown algorithm is stronger or weaker than what it supports. An option we have is to recommend new implementations to not penalize unknown algorithms, because they could be stronger versions of known ones. That could be sensible. But the "server-sig-algs" extension already removes the need to try an algorithm the server doesn't support. > When authenticating with an RSA key against a server > that does not implement the "server-sig-algs" extension, > clients MAY default to an ssh-rsa signature to avoid > authentication penalties. MGLT: ssh-rsa must be deprecated, so I think we should have something different. The fall back should be on the most recommended algorithm, or the authentication penalty should be changed. We can put in instructions that work and will realistically be followed, or we can put in instructions that don=E2=80=99t work. Agree. Due to existing deployed base, falling back to =E2=80=9Crsa-sha2-256=E2=80= =9D when the server does not send =E2=80=9Cserver-sig-algs=E2=80=9D will not work. If th= e spec is made to require this, implementers will ignore it for compatibility. Worse, there will then be poor guidance toward a solution that does work. Agree In my opinion, the way to deprecate ssh-rsa is to implement the new signature methods; implement the "server-sig-algs" extension to allow them to coexist; allow for several years of new deployment; and then, for new implementations to start disabling "ssh-rsa" by default. Maybe that would be good to explain how the option is also helping to deprecate suites in the security consideration section. denis ----- Original Message ----- From: Daniel Migault Sent: Saturday, March 25, 2017 17:40 To: curdle Subject: [Curdle] comments on draft-ietf-curdle-rsa-sha2-03.txt Hi, Please find my comments on draft-ietf-curdle-rsa-sha2-03.txt. In a word my comments are: - 1) Should we consider adding / replacing PKCS1v1.5 by RSA-PSS for the signature format. - 2) I understand that penalties are encouraging to keep ssh-rsa while the use of sha1 is deprecated. I suggest to provide some recommendations on how to perform penalties. Yours, Daniel Use of RSA Keys with SHA-2 256 and 512 in Secure Shell (SSH) draft-ietf-curdle-rsa-sha2-03.txt Abstract This memo defines an algorithm name, public key format, and signature format for use of RSA keys with SHA-2 512 for server and client authentication in SSH connections. MGLT: Maybe we should also add penalty recommendations as well ? 2. Public Key Algorithms This memo adopts the style and conventions of [RFC4253] in specifying how use of a signature algorithm is indicated in SSH. The following new signature algorithms are defined: rsa-sha2-256 RECOMMENDED sign Raw RSA key rsa-sha2-512 OPTIONAL sign Raw RSA key These signature algorithms are suitable for use both in the SSH transport layer [RFC4253] for server authentication, and in the authentication layer [RFC4252] for client authentication. Since RSA keys are not dependent on the choice of hash function, both new algorithms reuse the public key format of the existing "ssh-rsa" algorithm as defined in [RFC4253]: string "ssh-rsa" mpint e mpint n All aspects of the "ssh-rsa" format are kept, including the encoded string "ssh-rsa", in order to allow users' existing RSA keys to be used with the new signature formats, without requiring re-encoding, or affecting already trusted key fingerprints. Signing and verifying using these algorithms is performed according to the RSASSA-PKCS1-v1_5 scheme in [RFC3447] using SHA-2 [FIPS-180-4] as hash; MGF1 as mask function; and salt length equal to hash size. MGLT: Could we also take this opportunity to upgrade the signature to RSA-PSS ? If "rsa-sha2-256" / "rsa-sha2-512" are already deployed in most implementation, maybe this document could also define "rsa-sha2-256-rsassa-pss" and "rsa-sha2-512-rsassa-pss" otherwise we could define rsa-sha2-* with RSA-PSS. 3. Discovery of signature algorithms supported by servers Implementation experience has shown that there are servers which apply authentication penalties to clients attempting signature algorithms which the SSH server does not support. MGLT: Can we recommend to have penalties only applies when algorithms are weaker than the one supported. Servers that accept rsa-sha2-* signatures for client authentication SHOULD implement the extension negotiation mechanism defined in [SSH-EXT-INFO], including especially the "server-sig-algs" extension. When authenticating with an RSA key against a server that does not implement the "server-sig-algs" extension, clients MAY default to an ssh-rsa signature to avoid authentication penalties. MGLT: ssh-rsa must be deprecated, so I think we should have something different. The fall back should be on the most recommended algorithm, or the authentication penalty should be changed. _______________________________________________ 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 --001a1147d6205d1fd0054bab683e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I created this new address for Curdle to avoid mailin= g list delivery issues due to DKIM and SPF.

Daniel= :


> I believe it would be good t= o add rsa-sha2-256-pss, rsa-sha2-512-pss.

I can do= that, but the next question is, will someone implement it?

<= /div>
If someone comes forward and says they'll be adding the PSS v= ariants, I can definitely include them.

If we do a= dd them, this will make Peter unhappy. :) If my recollection serves, he dis= liked the 512 variant, as it is.

The objection wit= h additional variants is that if a fraction of deployments are set up to re= quire them, this puts pressure on others to implement them as well. For Pet= er, this is a cost because his usage cases are extremely constrained.
=


> Maybe that would be good to explain= how the option is also
> helping to deprecate suites in the s= ecurity consideration section. =C2=A0

OK. I have a= dded the following:

"This document is based o= n the premise that RSA is used in environments where a gradual, compatible = transition to improved algorithms will be better received than one that is = abrupt and incompatible. It advises that SSH implementations add support fo= r new RSA signature algorithms along with SSH_MSG_EXT_INFO and the "se= rver-sig-algs" extension to allow coexistence of new deployments with = older versions that support only "ssh-rsa". Nevertheless, impleme= ntations SHOULD start to disable "ssh-rsa" in their default confi= gurations as soon as they have reason to believe that new RSA signature alg= orithms have been widely adopted."

Does this = sound well?

denis


----- Original Message -----
From: Daniel Migault=C2=A0
Sent: Sunday, March 26, 2017 14:39
To: denis bider (Bitv= ise)=C2=A0
Cc: curdle=C2=A0
Subject: Re: [Curdle] comme= nts on draft-ietf-curdle-rsa-sha2-03.txt

Hi,=C2=A0=


Thanks for the response. Please se= e mine inline. In short I agree with your responses. I believe it would be = good to add rsa-sha2-256-pss, rsa-sha2-512-pss.

Yours,=C2=A0

Daniel





On Sun,= Mar 26, 2017 at 12:56 PM, denis bider (Bitvise) <ietf-ssh3@denisbider.com> wrote:
Daniel:



= Should we consider adding / replacing PKCS1v1.5
by RSA-PSS for th= e signature format.


An early versio= n of the spec called for PSS. After strong objections - most prominently Pe= ter Gutmann's; it is possible there were others - I changed back to PKC= S1v1.5. The main objections were:

- PSS is not as = universally available;
- adding a new type of padding would impos= e costs on highly resource-constrained implementations who would now have t= o support both.

I have no objections to adding PSS= . At this point, it would have to be added as separate variants. For exampl= e: rsa-sha2-256-pss, rsa-sha2-512-pss.

The existin= g names already have widely implemented / accepted meanings with PKCS1v1.5.=


I understand the motivations. I pe= rsonally think it would be good to add rsa-sha2-256-pss, rsa-sha2-512-pss= =C2=A0


I understand that penalties = are encouraging to
keep ssh-rsa while the use of sha1 is deprecat= ed.
I suggest to provide some recommendations on how
to= perform penalties.


The issue are p= enalties in software already deployed. Servers are often used for 5-10 year= s without update. Users actively resist updates, even if we urge otherwise.= Often, there's no one to perform an update. The administrator who conf= igured the server has left. The people who use it are afraid, because they = don't have anyone who understands their setup if it breaks. A new spec = won't fix this deployed base.

Software that= 9;s aware of this spec is suggested to implement the "server-sig-algs&= quot; extension with EXT_INFO. This eliminates any need to guess what signa= ture algorithm to use. That is this spec's recommendation.


Agree, my recommendation on pena= lties was mostly for new implementations that do not implement ext_info. Ma= ybe you are right having ext_info solve this issue better.
=C2=A0=

MGLT: Can we recommend to have penalties only app= lies
when algorithms are weaker than the one supported.


The issue does not arise from implementation= s penalizing known algorithms, it arises from old software penalizing unkno= wn algorithms. Old software cannot know whether an unknown algorithm is str= onger or weaker than what it supports.

An option w= e have is to recommend new implementations to not penalize unknown algorith= ms, because they could be stronger versions of known ones. That could be se= nsible. But the "server-sig-algs" extension already removes the n= eed to try an algorithm the server doesn't support.



> When authenticating with an RSA ke= y against a server
> that does not implement the "server-= sig-algs" extension,
> clients MAY default to an ssh-rsa = signature to avoid
> authentication penalties.

<= /div>
MGLT: ssh-rsa must be deprecated, so I think we should
= have something different. The fall back should be on
the most rec= ommended algorithm, or the authentication
penalty should be chang= ed.


We can put in instructions that= work and will realistically be followed, or we can put in instructions tha= t don=E2=80=99t work.


Agree.
<= div>=C2=A0

Due to existing deployed base, falling = back to =E2=80=9Crsa-sha2-256=E2=80=9D when the server does not send =E2=80= =9Cserver-sig-algs=E2=80=9D will not work. If the spec is made to require t= his, implementers will ignore it for compatibility. Worse, there will then = be poor guidance toward a solution that does work.

Agree=C2=A0

In my opinion, the way to deprecate s= sh-rsa is to implement the new signature methods; implement the "serve= r-sig-algs" extension to allow them to coexist; allow for several year= s of new deployment; and then, for new implementations to start disabling &= quot;ssh-rsa" by default.


Mayb= e that would be good to explain how the option is also helping to deprecate= suites in the security consideration section. =C2=A0

<= div>
denis=C2=A0



=
----- Original Message -----
From: Daniel Migault
Sent: Saturday, March 25, 2017 17:40
To: curdle
S= ubject: [Curdle] comments on draft-ietf-curdle-rsa-sha2-03.txt
Hi,

Please find my comments on draft-= ietf-curdle-rsa-sha2-03.txt.

In a word my comments= are:
=C2=A0 - 1) Should we consider =C2=A0adding / replacing PKC= S1v1.5 by RSA-PSS for =C2=A0the signature format.
=C2=A0 - 2) I u= nderstand that penalties are encouraging to keep ssh-rsa while the use of s= ha1 is deprecated. I suggest to provide some recommendations on how to perf= orm penalties.

Yours,
Daniel
<= br>
=C2=A0 =C2=A0 =C2=A0Use of RSA Keys with SHA-2 256 and 512 in= Secure Shell (SSH)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 draft-ietf-curdle-rsa-sha2-03.txt


Abstract

=C2=A0This memo defines = an algorithm name, public key format, and signature
=C2=A0format = for use of RSA keys with SHA-2 512 for server and client
=C2=A0au= thentication in SSH connections.

MGLT: Maybe we sh= ould also add penalty recommendations as well ?

2.= =C2=A0 Public Key Algorithms

=C2=A0This memo adopt= s the style and conventions of [RFC4253] in specifying
=C2=A0how = use of a signature algorithm is indicated in SSH.

= =C2=A0The following new signature algorithms are defined:

=C2=A0 =C2=A0rsa-sha2-256 =C2=A0 =C2=A0RECOMMENDED =C2=A0 =C2=A0sig= n =C2=A0 =C2=A0Raw RSA key
=C2=A0 =C2=A0rsa-sha2-512 =C2=A0 =C2= =A0OPTIONAL =C2=A0 =C2=A0 =C2=A0 sign =C2=A0 =C2=A0Raw RSA key
=C2=A0These signature algorithms are suitable for use both in = the SSH transport
=C2=A0layer [RFC4253] for server authentication= , and in the authentication
=C2=A0layer [RFC4252] for client auth= entication.

=C2=A0Since RSA keys are not dependent= on the choice of hash function, both
=C2=A0new algorithms reuse = the public key format of the existing "ssh-rsa"
=C2=A0a= lgorithm as defined in [RFC4253]:

=C2=A0 =C2=A0str= ing =C2=A0 =C2=A0"ssh-rsa"
=C2=A0 =C2=A0mpint =C2=A0 = =C2=A0 e
=C2=A0 =C2=A0mpint =C2=A0 =C2=A0 n

<= div>=C2=A0All aspects of the "ssh-rsa" format are kept, including= the encoded
=C2=A0string "ssh-rsa", in order to allow = users' existing RSA keys to be
=C2=A0used with the new signat= ure formats, without requiring re-encoding,
=C2=A0or affecting al= ready trusted key fingerprints.

=C2=A0Signing and = verifying using these algorithms is performed according to
=C2=A0= the RSASSA-PKCS1-v1_5 scheme in [RFC3447] using SHA-2 [FIPS-180-4] as
=
=C2=A0hash; MGF1 as mask function; and salt length equal to hash size.=

MGLT: Could we also take this opportunity to upgr= ade the signature to RSA-PSS ?
If "rsa-sha2-256" / &quo= t;rsa-sha2-512" are already deployed in most implementation, maybe thi= s document could also define "rsa-sha2-256-rsassa-pss" and "= rsa-sha2-512-rsassa-pss" otherwise we could define rsa-sha2-* with RSA= -PSS.


3.=C2=A0 Discovery of signatu= re algorithms supported by servers

=C2=A0Implement= ation experience has shown that there are servers which apply
=C2= =A0authentication penalties to clients attempting signature algorithms
=C2=A0which the SSH server does not support.

MGLT: Can we recommend to have penalties only applies when algorithms are = weaker than the one supported.

=C2=A0Servers that = accept rsa-sha2-* signatures for client authentication
=C2=A0SHOU= LD implement the extension negotiation mechanism defined in
=C2= =A0[SSH-EXT-INFO], including especially the "server-sig-algs" ext= ension.

=C2=A0When authenticating with an RSA key = against a server that does not
=C2=A0implement the "server-s= ig-algs" extension, clients MAY default to an
=C2=A0ssh-rsa = signature to avoid authentication penalties.

MGLT:= ssh-rsa must be deprecated, so I think we should have something different.= The fall back should be on the most recommended algorithm, or the authenti= cation penalty should be changed.


<= br>

______________________________________________= _
Curdle mailing list
<= div>
_______________________________________________
Curdle mailing list

--001a1147d6205d1fd0054bab683e-- From nobody Sun Mar 26 17:41: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 A5D83127337 for ; Sun, 26 Mar 2017 17:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbNjKuRObf19 for ; Sun, 26 Mar 2017 17:41:31 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93564126C89 for ; Sun, 26 Mar 2017 17:41:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1490575290; x=1522111290; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Pio8/qVcVASuTiybAn4v3IfjU5y63ob2qRbFbugGyqk=; b=OBQCErusZIqgsZ1UTRILXY+5gs1obMr3z9oRYzKJiATxfCjksEh9WzwA cX3m6NssfQWONnI4LbOQyh/IDtYH6VhfVHAHAiV/Wv0VKVyr30pv9Ujf/ FGfEwlusU6Wr4IOJPrw4ri+wvNiUmQe1WhmIhrds8yU3JQ25k/DMwqSd6 5ienrX8eTS01xA4ntflAOkQtHu4HoMhlOcl0VG7e7E7Q4/H4xh0pS+wZu HOtQepIk2ig7laZk8CdoCmR1M62dAVYhkSZYGrSfHSJTYFYf42nJh0T2t 7zAqUBKqmLGZ2Qy8cV5RsmnBW+kTYRehn7BmiXB904UFe5QflSFfRtA3x g==; X-IronPort-AV: E=Sophos;i="5.36,229,1486378800"; d="scan'208";a="145816975" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.9 - Outgoing - Outgoing Received: from uxcn13-tdc-e.uoa.auckland.ac.nz ([10.6.3.9]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 27 Mar 2017 13:41:29 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-e.UoA.auckland.ac.nz (10.6.3.9) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 27 Mar 2017 13:41:28 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Mon, 27 Mar 2017 13:41:28 +1300 From: Peter Gutmann To: "denis bider (Bitvise)" , Daniel Migault , curdle Thread-Topic: [Curdle] comments on draft-ietf-curdle-rsa-sha2-03.txt Thread-Index: AQHSpcEzJRcP16zDJU+R0iPNB50hdaGmjxQAgAFKygQ= Date: Mon, 27 Mar 2017 00:41:27 +0000 Message-ID: <1490575273244.74198@cs.auckland.ac.nz> References: , <374ADF9BE1924B7889C64CEC7D51FEF8@Khan> In-Reply-To: <374ADF9BE1924B7889C64CEC7D51FEF8@Khan> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Curdle] comments on draft-ietf-curdle-rsa-sha2-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, 27 Mar 2017 00:41:33 -0000 denis bider (Bitvise) writes:=0A= =0A= >An early version of the spec called for PSS. After strong objections - mos= t=0A= >prominently Peter Gutmann's; it is possible there were others - I changed= =0A= >back to PKCS1v1.5. The main objections were:=0A= >=0A= >- PSS is not as universally available;=0A= >- adding a new type of padding would impose costs on highly resource-=0A= >constrained implementations who would now have to support both.=0A= =0A= A third point is that there's no security advantage to using PSS. It has a= =0A= more rigorous design than PKCS #1 1.5, but there's no indcation that 1.5 is= =0A= less secure. So it's something that offers no obvious benefit but requires= =0A= implementing and supporting yet another new crypto mechanism.=0A= =0A= I don't mind if it's there as a MAY for people who really feel the need to= =0A= make that particular fashion statement, as long as 1.5 is still there as a= =0A= MUST.=0A= =0A= Peter.= From nobody Sun Mar 26 17:52: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 7F6E2128D2E for ; Sun, 26 Mar 2017 17:52:00 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CeA3ZjD0XMzv for ; Sun, 26 Mar 2017 17:51:59 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F413128B44 for ; Sun, 26 Mar 2017 17:51:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1490575919; x=1522111919; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=PTW1tVs/QfkLA4n8g5nktZ5oshvcaXszg2XKV4YhM+0=; b=fdtBDZJMC6RXT4w9kWnWx97hiUJ/uggStzzELud+NQYXa5Ozn9wEJw8J tzt6A47c+DbWHqdkH4UGFmy2l91VOUyJ4KdEnx2WFFe1rGU1Cfwv1YEmM /7kU7f4+rsoU68UCrEnKG90j3CGdxKSLHaEgc2n6fLmmPDLktPubIQdi/ s7RLqeJ1Gfhd1FyQK3903RhIvNqeC4sd/6WrPLlJzFzdMOIXdM6LptEoW ZfPcsMWiDT8qlC5wcMeA2JaTi9UyRosjedC0o8FpeH7VaR6/nyXB08jd4 R6UsqrfH75zSOoYmVbiEwTlCLgU9aOGr8f4WCsfW3AfcgX1AtlnsVQw5w w==; X-IronPort-AV: E=Sophos;i="5.36,229,1486378800"; d="scan'208";a="145819289" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.9 - Outgoing - Outgoing Received: from uxcn13-tdc-e.uoa.auckland.ac.nz ([10.6.3.9]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 27 Mar 2017 13:51:57 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-e.UoA.auckland.ac.nz (10.6.3.9) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 27 Mar 2017 13:51:56 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Mon, 27 Mar 2017 13:51:57 +1300 From: Peter Gutmann To: denis bider , "daniel.migault@ericsson.com" , "curdle@ietf.org" Thread-Topic: [Curdle] comments on draft-ietf-curdle-rsa-sha2-03.txt Thread-Index: AQHSppDoJRcP16zDJU+R0iPNB50hdaGn22mQ Date: Mon, 27 Mar 2017 00:51:56 +0000 Message-ID: <1490575901696.39454@cs.auckland.ac.nz> References: In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Curdle] comments on draft-ietf-curdle-rsa-sha2-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, 27 Mar 2017 00:52:00 -0000 denis bider writes:=0A= =0A= >The objection with additional variants is that if a fraction of deployment= s=0A= >are set up to require them, this puts pressure on others to implement them= as=0A= >well. For Peter, this is a cost because his usage cases are extremely=0A= >constrained.=0A= =0A= It's also because I'm inherently lazy :-).=A0 The smaller the number of=0A= combinations of algorithms and mechanisms I need to implement, debug, and= =0A= test, the better.=A0 SSL is an extreme example of this, there are such a va= st=0A= number of combinations of cipher suites, parameters, and message flows that= =0A= (a) no-one has ever tested them all and (b) when someone does come along an= d=0A= test just one small corner of the whole mess, e.g. message flows, they=0A= inevitably find vulns all over the place because composing all the differen= t=0A= bits and pieces is unsafe (there are now at least four, probably more,=0A= conference papers published just on messing with SSL message flows, leading= to=0A= things like all-zero keys used and other issues).=0A= =0A= Adding redundant ways of doing more or less the same thing isn't a good ide= a.=0A= So my general objection is a combination of { code size minimisation, attac= k=0A= surface reduction, work/effort reduction }.=0A= =0A= Peter.= From nobody Sun Mar 26 18:33: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 67A16128BB7 for ; Sun, 26 Mar 2017 18:33: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 7czy7UWK5Emy for ; Sun, 26 Mar 2017 18:33:38 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A696127058 for ; Sun, 26 Mar 2017 18:33:38 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id n5so16118647pgh.0 for ; Sun, 26 Mar 2017 18:33:38 -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=l0ynCfL9qk5JzyMfEtEAm0GoM5jUx+VdgOVf+wffpVQ=; b=MtQ/JYyoal4MfUKRG+b4++F8LaEUH0mGJV7AoJnNeQx5aWkW9mCOQTQm4N8lpSB1My 9mnoLKBo46gZABnO6aeUTQlVwg7x4QqygFhputMSY0B7IFetrCE2tIe/a1DBIvOCOUzz z/v16flWiHocWgEWJo82k4YlwapPQe4v5Iv228mg1hMyoCVOg4eQX1upYu4EAhUUspUP cpReSzK3e1YFz/dh/9AYdaFHL/H/PL6MNHf1nhRFfo21AGrs+R/mTqlex2N66Ts10Wm2 +3PBJSZUpP7pRivS326eoLT5/0/refmMMyW/qBm4gjSs65OtYh1HE8IE1fgRUjJIIAsc H6sg== 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=l0ynCfL9qk5JzyMfEtEAm0GoM5jUx+VdgOVf+wffpVQ=; b=FHA0AukZaDIIKVoozeBVOqWmT41pyZuzBYw+I2xpwqyEzh8H4sCp3mPOP5dynvYHgZ O2dEDuKZN4DV9w1HFvA2HPtGp4RFxr+zjRekMmvNUWLS76Q0D8pE1l5tDNsJEZ1KRZhk 4p3EHcQu7zSyGKqcEQPbs8iGqfmBrB02pkgYfySj3oK4DVQxjpA6HjHuJJm6lqdpp0Wt 70FKLdjCLU0uGF0g/ygJ83LeHJh2+KZGSak8YSS6whv8QuKfBm0RYQltMfzs/2SXPXhQ 17kXQblaIHj9+7OGU7PvemCBrlYWnL1In3JbfVsUGomvGf6E6MGqfkxMhqP9P5D8pioq gUhQ== X-Gm-Message-State: AFeK/H3bZNIoqGLKekI6eNvv3R9OkNNjFzXy8Z0EYoNOFpI3einHDuiv85w6wjFd4k8l3R30KudC8dTUY5KAFw== X-Received: by 10.99.140.27 with SMTP id m27mr21839149pgd.174.1490578417662; Sun, 26 Mar 2017 18:33:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.179.41 with HTTP; Sun, 26 Mar 2017 18:33:37 -0700 (PDT) In-Reply-To: <1490575901696.39454@cs.auckland.ac.nz> References: <1490575901696.39454@cs.auckland.ac.nz> From: denis bider Date: Sun, 26 Mar 2017 19:33:37 -0600 Message-ID: To: Peter Gutmann Cc: "daniel.migault@ericsson.com" , "curdle@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c1b6a241841a0054bac5571 Archived-At: Subject: Re: [Curdle] comments on draft-ietf-curdle-rsa-sha2-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, 27 Mar 2017 01:33:39 -0000 --94eb2c1b6a241841a0054bac5571 Content-Type: text/plain; charset=UTF-8 Aye - you made a much better point there, than how I tried to represent it. :-) > I don't mind if it's there as a MAY for people who really feel > the need to make that particular fashion statement, as long > as 1.5 is still there as a MUST. Well, that's good news for anyone who is in favor of adding this as an option. We do need, though, someone wants to implement it. On Sun, Mar 26, 2017 at 6:51 PM, Peter Gutmann wrote: > denis bider writes: > > >The objection with additional variants is that if a fraction of > deployments > >are set up to require them, this puts pressure on others to implement > them as > >well. For Peter, this is a cost because his usage cases are extremely > >constrained. > > It's also because I'm inherently lazy :-). The smaller the number of > combinations of algorithms and mechanisms I need to implement, debug, and > test, the better. SSL is an extreme example of this, there are such a vast > number of combinations of cipher suites, parameters, and message flows that > (a) no-one has ever tested them all and (b) when someone does come along > and > test just one small corner of the whole mess, e.g. message flows, they > inevitably find vulns all over the place because composing all the > different > bits and pieces is unsafe (there are now at least four, probably more, > conference papers published just on messing with SSL message flows, > leading to > things like all-zero keys used and other issues). > > Adding redundant ways of doing more or less the same thing isn't a good > idea. > So my general objection is a combination of { code size minimisation, > attack > surface reduction, work/effort reduction }. > > Peter. --94eb2c1b6a241841a0054bac5571 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Aye - you made a much better point there, than how I tried= to represent it. :-)


>=C2=A0I don't mind if it's there as a MAY for peo= ple who really feel
> = the need to=C2=A0make that particul= ar fashion statement, as long
> as 1.5 is still there as a=C2=A0MUST.

<= /div>
Well, that's good news for a= nyone who is in favor of adding this as an option. We do need, though, some= one wants to implement it.



On Sun, Mar 26, 2017 at 6:51 PM, Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:
denis bider <denisbider.ietf@gmail.com> writes:

>The objection with additional variants is that if a fraction of deploym= ents
>are set up to require them, this puts pressure on others to implement t= hem as
>well. For Peter, this is a cost because his usage cases are extremely >constrained.

It's also because I'm inherently lazy :-).=C2=A0 The smaller= the number of
combinations of algorithms and mechanisms I need to implement, debug, and test, the better.=C2=A0 SSL is an extreme example of this, there are such a= vast
number of combinations of cipher suites, parameters, and message flows that=
(a) no-one has ever tested them all and (b) when someone does come along an= d
test just one small corner of the whole mess, e.g. message flows, they
inevitably find vulns all over the place because composing all the differen= t
bits and pieces is unsafe (there are now at least four, probably more,
conference papers published just on messing with SSL message flows, leading= to
things like all-zero keys used and other issues).

Adding redundant ways of doing more or less the same thing isn't a good= idea.
So my general objection is a combination of { code size minimisation, attac= k
surface reduction, work/effort reduction }.

Peter.

--94eb2c1b6a241841a0054bac5571-- From nobody Sun Mar 26 20:50: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 38C731292D0 for ; Sun, 26 Mar 2017 20:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, 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 HI7h-zvGYE3y for ; Sun, 26 Mar 2017 20:50:04 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::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 63284127342 for ; Sun, 26 Mar 2017 20:50:03 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id y18so39465859itc.1 for ; Sun, 26 Mar 2017 20:50:03 -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=PQfbZskE/2xS8POFUHm7k3qKh6tqNwBX56yyju/bLeg=; b=J54XMS1UXd2YntLfDletNlsSCXv6f7/xO58WX9D9J6auGlsd8eK5/MOE0IiDj7T87W zFnAzmKExJ01joDU+JgNrE2Q0cFGBQB5LHvQ5LpTPweCeme87RGCMKFgY4Lf9RP73MZa Q18Hja5yk+26JNvMtnRK5OM4xK1Bk2TxJkJEF8EC82UyOZnU3pEoTTN2EXtBLLtqgJku w6jqdz382yxPu4s0aytVDwbP8LooNXIbxHfLZ6AcP3cTP6fFRVGhceudSIfBAbPqD5z7 9oIXwa179+gZPzlNvFbZbsvjcYeg/TykjJXFUVisoahNFzzUJEsUWe4p3fJoS5wwVmnj sjyQ== 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=PQfbZskE/2xS8POFUHm7k3qKh6tqNwBX56yyju/bLeg=; b=eCz3LI87gkDA/cdbftGGlrFpk72xSnDfuQ4ksQxmUhX85TX0/sLiz44EapA29R+81x 74IA34UwCJVhGP8zGKXuTrPXERgrgKGOtP5BHeaq4wAiTxkEFa5iE/3z/xn0nYsR2yyK F1eBCoHoaTaCZGL6Nrqvu9f2zE3unc9N0kpm2XszWnjXVtuGMCHjvjrea7eIBYfzImG1 R+aR7YeODe4QgOWyAaNS0NvkDRLZq4DUzoijhXP1E8zdgquf/sFNDPBZP6MQ10e1lsn7 3654zKWeZh65fg1ePlYhEeInKp+osaRTlBGelmz6AwsobqhbacTvkTGmRjrQDNRm0NXS vLSg== X-Gm-Message-State: AFeK/H3fqXasfGK91Xk15vKwDL1ybKXhVDpLGC6JTyPx1XR9qVeqPMxhKobnX2skXXsO0xGBl1i6Bp99O+/WNg== X-Received: by 10.107.168.21 with SMTP id r21mr18144730ioe.45.1490586602768; Sun, 26 Mar 2017 20:50:02 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.35.213 with HTTP; Sun, 26 Mar 2017 20:50:02 -0700 (PDT) In-Reply-To: References: <1490575901696.39454@cs.auckland.ac.nz> From: Daniel Migault Date: Sun, 26 Mar 2017 22:50:02 -0500 X-Google-Sender-Auth: 5DVRTyeyXf4pxwnAOFOHrQWA4jE Message-ID: To: denis bider Cc: Peter Gutmann , "curdle@ietf.org" Content-Type: multipart/alternative; boundary=001a114215e8f730a8054bae3c71 Archived-At: Subject: Re: [Curdle] comments on draft-ietf-curdle-rsa-sha2-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, 27 Mar 2017 03:50:07 -0000 --001a114215e8f730a8054bae3c71 Content-Type: text/plain; charset=UTF-8 Whether pss variant have to be added is up to the WG to decide. That I would be in favor is only one opinion ;-) [1] lists some advantages of PSS vs PKCS1v1.5. Note that enabling a given key may be used by two variants needs also some thoughts. I will raise the question during the meeting, but discussion will be made on the mailing list. Yours, Daniel [1] https://www.emc.com/emc-plus/rsa-labs/historical/raising-standard-rsa-signatures-rsa-pss.htm On Sun, Mar 26, 2017 at 8:33 PM, denis bider wrote: > Aye - you made a much better point there, than how I tried to represent > it. :-) > > > > I don't mind if it's there as a MAY for people who really feel > > the need to make that particular fashion statement, as long > > as 1.5 is still there as a MUST. > > Well, that's good news for anyone who is in favor of adding this as an > option. We do need, though, someone wants to implement it. > > > > On Sun, Mar 26, 2017 at 6:51 PM, Peter Gutmann > wrote: > >> denis bider writes: >> >> >The objection with additional variants is that if a fraction of >> deployments >> >are set up to require them, this puts pressure on others to implement >> them as >> >well. For Peter, this is a cost because his usage cases are extremely >> >constrained. >> >> It's also because I'm inherently lazy :-). The smaller the number of >> combinations of algorithms and mechanisms I need to implement, debug, and >> test, the better. SSL is an extreme example of this, there are such a >> vast >> number of combinations of cipher suites, parameters, and message flows >> that >> (a) no-one has ever tested them all and (b) when someone does come along >> and >> test just one small corner of the whole mess, e.g. message flows, they >> inevitably find vulns all over the place because composing all the >> different >> bits and pieces is unsafe (there are now at least four, probably more, >> conference papers published just on messing with SSL message flows, >> leading to >> things like all-zero keys used and other issues). >> >> Adding redundant ways of doing more or less the same thing isn't a good >> idea. >> So my general objection is a combination of { code size minimisation, >> attack >> surface reduction, work/effort reduction }. >> >> Peter. > > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > > --001a114215e8f730a8054bae3c71 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Whether pss variant have to be added is up to the WG = to decide. That I would be in favor is only one opinion ;-) [1] lists some = advantages of PSS vs PKCS1v1.5. Note that enabling a given key may be used = by two variants needs also some thoughts. I will raise the question during = the meeting, but discussion will be made on the mailing list.

=
Yours,
Daniel=C2=A0



On Sun, Mar 26, 2017 = at 8:33 PM, denis bider <denisbider.ietf@gmail.com> = wrote:
Aye - you made a = much better point there, than how I tried to represent it. :-)


>=C2=A0I don't mind if it's there as a MAY for people who really = feel
> the need to=C2= =A0make that particular fashion sta= tement, as long
> as 1= .5 is still there as a=C2=A0MUST.

Well, that's good news for anyone w= ho is in favor of adding this as an option. We do need, though, someone wan= ts to implement it.



On Sun, Mar 26, 201= 7 at 6:51 PM, Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:
denis bider <denisbider.ietf@gma= il.com> writes:

>The objection with additional variants is that if a fraction of deploym= ents
>are set up to require them, this puts pressure on others to implement t= hem as
>well. For Peter, this is a cost because his usage cases are extremely >constrained.

It's also because I'm inherently lazy :-).=C2=A0 The smaller= the number of
combinations of algorithms and mechanisms I need to implement, debug, and test, the better.=C2=A0 SSL is an extreme example of this, there are such a= vast
number of combinations of cipher suites, parameters, and message flows that=
(a) no-one has ever tested them all and (b) when someone does come along an= d
test just one small corner of the whole mess, e.g. message flows, they
inevitably find vulns all over the place because composing all the differen= t
bits and pieces is unsafe (there are now at least four, probably more,
conference papers published just on messing with SSL message flows, leading= to
things like all-zero keys used and other issues).

Adding redundant ways of doing more or less the same thing isn't a good= idea.
So my general objection is a combination of { code size minimisation, attac= k
surface reduction, work/effort reduction }.

Peter.


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

--001a114215e8f730a8054bae3c71-- From nobody Sun Mar 26 22:21: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 8A0681274D0 for ; Sun, 26 Mar 2017 22:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.697 X-Spam-Level: X-Spam-Status: No, score=-4.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, 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=junipernetworks.onmicrosoft.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 NCdvanQIAUPO for ; Sun, 26 Mar 2017 22:21:24 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0135.outbound.protection.outlook.com [104.47.34.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EF2E126C7B for ; Sun, 26 Mar 2017 22:21:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=OQz7Vz3PnjkC2RkqG1l34ngRNYfaoOslJKjOyQSghjA=; b=YXc+Ek3cYEOojts03I1dujyf9QqwvwskFoS1Y8yV1q/8XCiO5CK8kTkyvWPdZP/PQx2F8mEDlnOw2TMIkmP3NOoGj/rAbUmJejxsseCefnAjzW3AXV9DjQeSmvwXypEzGRXYPx/zC3BTvsimPE96RC3jVduOOWxzgws80AUa3yY= Received: from BL2PR05CA0028.namprd05.prod.outlook.com (10.255.226.28) by BLUPR05MB307.namprd05.prod.outlook.com (10.141.23.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Mon, 27 Mar 2017 05:21:22 +0000 Received: from BL2FFO11FD034.protection.gbl (2a01:111:f400:7c09::183) by BL2PR05CA0028.outlook.office365.com (2a01:111:e400:c04::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2 via Frontend Transport; Mon, 27 Mar 2017 05:21:22 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.18) 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.18 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.18) by BL2FFO11FD034.mail.protection.outlook.com (10.173.161.130) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.977.7 via Frontend Transport; Mon, 27 Mar 2017 05:21:21 +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; Sun, 26 Mar 2017 22:21:13 -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 v2R5LDBT028766; Sun, 26 Mar 2017 22:21:13 -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 9EB8111454; Sun, 26 Mar 2017 22:21:12 -0700 (PDT) To: Daniel Migault CC: curdle In-Reply-To: References: Comments: In-reply-to: Daniel Migault message dated "Sat, 25 Mar 2017 23:37:09 -0400." From: "Mark D. Baushke" Date: Sun, 26 Mar 2017 22:21:12 -0700 Message-ID: <56412.1490592072@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.18; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39860400002)(39840400002)(39850400002)(2980300002)(189002)(199003)(9170700003)(76506005)(53416004)(38730400002)(6246003)(110136004)(6266002)(106466001)(7126002)(305945005)(77096006)(55016002)(6392003)(105596002)(229853002)(6306002)(47776003)(230783001)(356003)(48376002)(117636001)(2810700001)(50466002)(5003940100001)(7696004)(2950100002)(6916009)(2906002)(81166006)(8676002)(53936002)(76176999)(50986999)(54356999)(86362001)(189998001)(5660300001)(4326008)(8936002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB307; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD034; 1:Uc8q8dsEXJnjVTNM9+njCFomlFhAZkb+VLk8KnMXVTPpP9SA5pNiH8Uwc/C7r7zDhdEZojIF4vl27s+1AW/QUVZ3BJwKaAM7eJsE8R+i9BaBWSHZOz0Z8u9YqRw4Xrgmkypj+ZoXF1iuT8ZlU/SwLHGKXpSIYALRNlW+YlCSEOpvehnfnDwvqkGaozHNa9to43KrX4Gj4wA5jXvlHDVclEwH/xRL4eWlCyYZ6kWzCXz8zqz7Yc0c5Zz4Zzchng5Td1h0aIctCdBgnSxwq6RF7B3akcL4HyH5VXIkGyOA3rhqXISfs8Fj2BJagq2JDeEs+3YvRJUlQyf0ApBQvvFz5KwUWt8ot7hJ9YnQ8gnm+u5xAYL3ARaOaEI4zlVS72x9p9drsyss8C1A/mp3ekyK2maq4s9P7/Oe1RF3jyxeRTLevEOH0ecZvkM0300I0QrhHcqULTXtdrXcJdcZ9TvTBxalqvX2+1Or43LIm4rmd5QdZOglivfsXR03Fo3hMLSZ6hWtRPOP/QcuIu+yBxggGbG7x3LDU908dlcwzDu/vPhwgKbTUfdbNNrjnX/y1KaH X-MS-Office365-Filtering-Correlation-Id: e2d3b3d0-8fd2-4f22-6f31-08d474d11b30 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:BLUPR05MB307; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB307; 3:hfJJOwv7dvXphPv+UFAX+SlxQcZSb4a+ytTrIVfSUYqSEEumYapwqK937h6GKdtIQsIQHP4uJfW1E/2CfvAFlDLLo8wsE9sTujgGXi5k2KwISnxDvGLzVWO584HcKVVXOkwuTUuAFVyfQd+n7aAEH8DXQkjzBjr/tw/6IkDLi17MJiWBnXBxjDQyl0U4UFIW5M3oAAdYXhOoSCcnWx0PvvRJaiz/azfyWzcceh4maV0Y6H+5+ANBnzKde9NmCLbwS3sjz0MYm9cmHfXPcKtzpd2fDDsE28ejR7nTKp6ZwLoRWxH/ch4ja9f4EJinbjDKIN6+mz8jrl1P0o5bZtAUft/YSuiGvTA4mjSjmBdWuZhGL3d+N9G3VjztXlMyrTteu1qtXJTFD7i8IfeSZf6xrA==; 25:is1yskhukdd6j10cFI8gTEfPvOTORNNBbGwIqASCfG5x6RR67qO9w0RrxZ8TXLLTg4/py/YbbVIBuZBaKxPb5eNwAgURZxjN3XBPcz0ryCyDs8rd0TVEChCWLR7z1tXEFpMzQDv4uHEOjfZrXtj23heYW9KoUEX1T+taXW7MoMA4YDDGWfOViblc4jbhUBnBRlumTiEvB4WredsIF9oEWm5cRy0xN8S/8ecaKCJGzpZF8S1ry8nNIo1PwtX2DG+B0+1+fCsl6xsSRjs/F52Ev7Y3MPjbLtZIW9eQoWRe7zqIKhXIQVhsB96pbAkejMEHgL7cb6gbLGs7zNddtwS5HojlBAVqVkuvV2BJXYsRw/kDW8eAMLK57I5vJZUcPVfnhrBv40r9w1c9b0Zah+hlH5uqF6JACwF+zSUqZuEZHaJEGtlaudTvtTjALLoVDGf3jORGnRjAjMG2nNs8cnUQ+g== X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB307; 31:gQ8oh2BQC4BIYr0DuA/D2r+PRbHtW1T+SmEiU3w/6SH5y+oYMz/DYE7tdnhyAaYL4vnYKGBd6oddrKKl9QKjSTeONNQtnw6Vvml3U7+veonP+NWNK1UKsoG6KootM6rpHcr4nEl7nogx1OfS/rCNqwNX94tU8hF0fd/FgGL90U6qYKzPSIbHyQ1G4nkZ9W+yfz+/JZPu7j43UB1GkmuPMiYuYVvI1dh6drfEA0azU3Cyx/X/KOWPTEmEIBerqEGC; 20:Bybl1JdElWsn6GvKeckwSEAna76cMAavKsBFWXT/KJfluMjy2HxfTO4Cj1AE01Nphm323zmREJrS1KMG+3Sh5ExUt1GggqKfkcY8QrhSr2cS/BeIya9R9/yUYe2jhF0bsbfjNONHgDpMoMr/LkeEOvDBP5SU/Y6xq4YC63Lg5lejzQFKGeUK3jVkG4yoln7Ft0hGLQLTTHVuavKK1Ov4wW5I/pVbE5tjCfCmGbvxR1pRr+j9CF8SuMWxSlv+eqKx51j8Z+601vViG6NIvqgUPWV11S5PC3ZYj0p4nKPFdDw543vyG98CFTKYSSMP/MkuSeF/PmRwgYxw9iFtLTXlXc5XS/OSjpF8AtaB2e2mL//iDjOOMPK6cghgM6+13KdKHLO4P8irSbz1XV6Zi3eU423KVMB+Ggd0il2UBmoN63y+KdXkTvNlAxoL8X3u6yfBA24I0KDG/AadG14uluO8yMx7fvWi3xVtJ3FYBSsW39f2AVY2a+2ZgB4xNABtEatC X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(37575265505322)(120809045254105); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(13024025)(13023025)(13018025)(13015025)(8121501046)(13017025)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(20161123558025)(6072148); SRVR:BLUPR05MB307; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB307; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB307; 4:ul69IiAzz7kfEkIgblSIk2dQNKEZj144r0w3zghMuwYvVsgwFYQr/bq2HjltvTHJSU6rX//IFeR2/FFVUVkCUn8WNIxAmPVv1+voVwSYtEuqewNTmciWSJ7QbCa96D1qAJxHk5U2W375lBgJGawJ08ydb8rTTYBsP6ZEZ6XeLb3dNzvSaC8ZkaMY6vFC0/6yXSbz9lb9UpVEarmBIwD+f5s8DbOaR48lsPPKkWvin9vZNfC7ScqJ9PHIVXanmB0pOpMqPipd3MWkX0twyblF1zZRMPly9AWMY6wHAycp/qkLTcw/dyDoKi0QXTBYmEI9SLvMOXU8hMgc+tXuTr8Kpe1jTXsflX1AIoVUeAHt8r+xF9WjhJ70h/p398VPSy9eKvi127+1RsjnOwOAp/6tEHbGAW7QDI7cLscHbeQwo5x0PFi66eRc/QF8F4jkHVCvsHc2HHxJbp0DIY0YdGh89Koo/oW40jeNee9fgoRRksS9sgrj8XrbbK438PUGX9O5IMRhRfG5Wzt5hf8WSdr76arg+7KRy5DJBLasyZ5g1dLfFM5xByPYWy0Uyz6mAXt0sbbZKuUhRFAymEw4OPhUK8qftt5O+dnFEsoAXDKYFFAAYsr1qcJ8xCUW6IT/+6U/lQyewVCN7DTz4FkwVVOfvMn6dY8ILqgTYRgk+KiZuVGHL1C9EwF9CObI82+rj5Ar+adpNzSouNTFXKH+ieb9kKOiy5BYNvmsNBII7D2A3uEd6re4/RX7vqw8oIBGXMEhuC6SUeVM37R3RajIazTSRIppfar6C7TCOuQLQur6lWM= X-Forefront-PRVS: 02596AB7DA X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR05MB307; 23:x8IY5gXyvPmdHsIsJnPgGbElsuoXczxF112CyMLF8N?= =?us-ascii?Q?ReVugD09TnhPR4Yg35pT0rCFI62tyIDT4Fag8HzDKYH8Oy4OSBuhHRFQFJTQ?= =?us-ascii?Q?6w2DdPBviDEQXZpfi+zJE1o5k2KijDltMOGJiJgccoHRG4nmVeOP14UC8yYg?= =?us-ascii?Q?C9Vi3aDtaulzayBkfdb0T320xl+e6ZqvgjSmUm2VbHkUyhav+L6LTvQkV7Ap?= =?us-ascii?Q?cguykhBY3AOdS5/6nrY/SURTuZ7HRLSFpdfa4/phXZHwbFjb4m6K/ivuzGRs?= =?us-ascii?Q?TxJ2vjRViGW9brihyob5Z2iE0YGnOuPWWG+lT9IeGoG6n27Gaml36QnabA6C?= =?us-ascii?Q?lhFqKowO7aXyk59gGO4C6w9YmbnOeswTw7I/g2fjag+DTnSxFLSaDYxWk8Hj?= =?us-ascii?Q?U0KvSUOtMPikGy6WGlSBC1y+9qVfVXeMh3WBi+alJGmcKDmpDhkxd4tq/Szj?= =?us-ascii?Q?wHEqy4JtV7mkLr+PegrO1aw0SNtkxv9cQVG6mkZR99virafDSO7GJm6wOqOP?= =?us-ascii?Q?OL+rF8qoxpfXe0j9pxUzwsEGb7VDxN8LYYWPfPpN6ukSinIel6sV61EfA0Wg?= =?us-ascii?Q?4jnlRg40ywkRap5ubr8DrvTrOSyRMuVza4nou0AGFcy19BJaIoQxRTd2BijQ?= =?us-ascii?Q?o3yfPL/TOyPNhR9OsXkdBLJbGvVDctZp/sgkaUsN1PmBGa95+oldlQhbMbJm?= =?us-ascii?Q?ionYTzMd73FHDUaoiQR0fuTpWDkxznLt3WSoh6HTLQtLOICnHsXCmuyVnzzu?= =?us-ascii?Q?LqZ6ZgkEOxozLuWl3049qiZ7GNezjwSUFkZHMOlkaGA9oqY0KkjpqTK/VAOn?= =?us-ascii?Q?vVLo3uLisSJ2S8xE7oPs7PKw3hDdJ6Qm77gYPLi1FGv0pltPwJzldqc5Zx6W?= =?us-ascii?Q?0hiUX7L69Abf9nQlrHloRgM7V5AcHRCrEtR266uIf0cNdZba9B4/d8i/F/S2?= =?us-ascii?Q?A0zm501Z8x9+SfWpgiJRxjoVzntcla6ZxW+ahUP4ovuxzoAmZJONV2zZeuwr?= =?us-ascii?Q?cAc9xwssr6eYXW8DozW+ZPsY5NNrrNh/Hsty7qPZZdegl/HXUAns7G23N4as?= =?us-ascii?Q?f/HZc1mVG6DujtKBvUsESu+GCk75Y4Ez7A6WbaMamsNZDuWPwhQrGeMIFclB?= =?us-ascii?Q?TQucSUMkV7nhPAp+lnVZTPlAVY8NjbPLfS0QMrCfJt3yWcpgwV5ewteAUk9V?= =?us-ascii?Q?jsN0kEf0/8fAA=3D?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB307; 6:P3jEETTLuuJeC+ksUK531wwXLBmRyfRy78w1xoOa53K/XiIxvitcYIXfZryAEbQCjJi+JaGotdUT0NH2Od9ib1Ho8d8RU6LcHijUAvCaRKGImRzTNRvgRw3EyBBW/M0BpzZXHTNLckUiwgxOy11pABYf8TbUJEgFReEeecAXl7wessGStsPMcpbt1u3C9yA1AVZfuYmDkZC4satTfXQ0fQYEo5qviOpJF5nvsuVDtREAqUGnCrKSwGXRDK2Ql2j1vdXEe5xbBiB6Paep6eo2OGkeNeImQcbeCuxYlyaDHFFcOSHw5hreuGnuaCElb2XDgbyIPrW1ZhgojgdrUtfGrzWBpio6MQd7uSn8iaN8g9vj/yymb8u/91S1YJj9p9TNkJQVoKUepoXMjpmlbBzyOSA9SQPDL6Ly0aN0+N+HNWE=; 5:hJ6vMxt4kqhYQ+UlNF1QyZ/hMMcTXAU/ZCYkOH8GBp/eLC3uyaEJUkH/EU7ZphNKmPsGgz5wwLB1RmcPfmSUpSF9TxstYCtkFVA3HNlBJbcftqP77wIfu7QAASkMM6bLdAPpNmAHMMnyGFSZFRvCIQ==; 24:ALxnXYlJxLaxyupTHLVSIJDt3ugGwmT0iJe8Yetf0V5GHnm2R3wD2h2vmZRr18vGz16XQn13kdRCSOC/PcCowWWmexUJJ2icnUjVGR52CHQ= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB307; 7:FzbqPR96zQTQHbX+nkAAwi6cFP+gLGmarhkacVBFDdngTaDK4PDBbV6hd4fvNb6Q8DbsEY/mlyCZZZ4ARLeF40L4J2KG0CP+/Ta0jnq5F0kSxTSYoBZQLW5gu7hKHKkye5h1Gpq4fjRARzCnCmppRNcFsdE3QIhOq0McMBSPE0Mg0QqwPIgdq7VN3UBLgOLNOR4Se9O1oN8fHfHEGvuUnM6toFisYgPdd0Zuf5hJ0+7+AKk6JTzNzEl6ciMBYOiUtSUHFMku8jnSTSm7nro+O1hoUOm45WAT6989PE8zalCl5Jy1V2SrjCR19kYVLSCTlbezcsjQwkU2IYAuPd+EfQ== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Mar 2017 05:21:21.5484 (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.18]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB307 Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-sha2-02 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, 27 Mar 2017 05:21:26 -0000 Daniel Migault writes: > Please find some comments for draft-ietf-curdle-ssh-modp-dh-sha2-02. > > I suspect the text above should be removed. > """ > The method of key exchange used for the name "gss-group14-sha256-*" > is the same as that for "gss-group14-sha1-*" except that the SHA2-256 > hash algorithm is used. > """ Thank you. This text will be removed in the -03 draft to be uploaded when https://datatracker.ietf.org/submit/ is reopened. -- Mark From nobody Mon Mar 27 00:24:57 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 C0FEC12941C for ; Mon, 27 Mar 2017 00:24:55 -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 Oe7bcphlEkNf for ; Mon, 27 Mar 2017 00:24:53 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 3F3A71293DA for ; Mon, 27 Mar 2017 00:24:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 4D9F624AF4; Mon, 27 Mar 2017 10:24:50 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id cpK41sVEIfLS; Mon, 27 Mar 2017 10:24:49 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id CB02221C; Mon, 27 Mar 2017 10:24:49 +0300 (EEST) Date: Mon, 27 Mar 2017 10:24:48 +0300 From: Ilari Liusvaara To: Daniel Migault Cc: denis bider , "curdle@ietf.org" , Peter Gutmann Message-ID: <20170327072447.GA2827@LK-Perkele-V2.elisa-laajakaista.fi> References: <1490575901696.39454@cs.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Curdle] comments on draft-ietf-curdle-rsa-sha2-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, 27 Mar 2017 07:24:56 -0000 On Sun, Mar 26, 2017 at 10:50:02PM -0500, Daniel Migault wrote: > Whether pss variant have to be added is up to the WG to decide. That I > would be in favor is only one opinion ;-) [1] lists some advantages of PSS > vs PKCS1v1.5. Note that enabling a given key may be used by two variants > needs also some thoughts. I will raise the question during the meeting, but > discussion will be made on the mailing list. This thing came up in context of TLS 1.3. The probability PKCS#1v1.5 and PSS signature overlaps depends on key size and salt size. Where overlap is defined as encoded message that is valid in both PKCS#1v1.5 and PSS. These depend on hashing algorithm and number of bits in n, but not precise value of n. TLS restricts salt length to be the same as hash length. Which makes overlaps highly unlikely with key sizes >=2048 bits and hash sizes <=512 bits. The problem being to control ~1000 bits using 512 bits. As key size decreases or salt size increases, the overlap probability increases, and eventually overlaps become almost certain, and further one gets multiple overlaps. > > [1] > https://www.emc.com/emc-plus/rsa-labs/historical/raising-standard-rsa-signatures-rsa-pss.htm -Ilari From nobody Mon Mar 27 01:29: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 4591C129474 for ; Mon, 27 Mar 2017 01:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=junipernetworks.onmicrosoft.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 ssuaxXbxq79d for ; Mon, 27 Mar 2017 01:28:58 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0130.outbound.protection.outlook.com [104.47.36.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5803212894A for ; Mon, 27 Mar 2017 01:28:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9QSyj3U/ZK/G0KzlY6ienqNfJumXgX6JXO9KT9UwKOI=; b=PXmRiABqZIxT0ASOThI3N3/NbqwSqK2+EGBJxozi5DhQ/Yv1ObHihu4/htl1IKSrRdgFfWgqpdpJEdAxCLmJdfkD8opsyNOAic673o+Z9pl/6id8ZGtOoSeqE9/QmQacAXIiV1aSF2gDb82dCZ7GaI5jJRqJjUsfoinjDjtQHF0= Received: from BN6PR05CA0004.namprd05.prod.outlook.com (10.174.92.145) by BLUPR05MB308.namprd05.prod.outlook.com (10.141.23.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Mon, 27 Mar 2017 08:28:57 +0000 Received: from BN1BFFO11FD044.protection.gbl (2a01:111:f400:7c10::1:137) by BN6PR05CA0004.outlook.office365.com (2603:10b6:405:39::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2 via Frontend Transport; Mon, 27 Mar 2017 08:28:57 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.18) 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.18 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.18) by BN1BFFO11FD044.mail.protection.outlook.com (10.58.144.107) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.977.7 via Frontend Transport; Mon, 27 Mar 2017 08:28:56 +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; Mon, 27 Mar 2017 01:28:55 -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 v2R8SstO006119; Mon, 27 Mar 2017 01:28:54 -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 4BCCF11446; Mon, 27 Mar 2017 01:28:54 -0700 (PDT) To: Daniel Migault CC: curdle In-Reply-To: References: Comments: In-reply-to: Daniel Migault message dated "Sun, 26 Mar 2017 14:29:45 -0500." From: "Mark D. Baushke" Date: Mon, 27 Mar 2017 01:28:54 -0700 Message-ID: <78094.1490603334@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.18; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39410400002)(39840400002)(39450400003)(2980300002)(189002)(199003)(9170700003)(230783001)(117636001)(7846003)(189998001)(2810700001)(6916009)(2950100002)(305945005)(76176999)(54356999)(50986999)(4326008)(105596002)(5660300001)(53416004)(6266002)(6246003)(110136004)(76506005)(77096006)(7696004)(38730400002)(86362001)(356003)(8936002)(2906002)(81166006)(53936002)(8676002)(106466001)(48376002)(7126002)(47776003)(5003940100001)(50466002)(55016002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB308; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11FD044; 1:QUmpVPHZ8W+cCBtqoKsEuG8WJ+ps/YFBddI1wYoWobmouWBu03WavG92/iKTLXTQ7DQVtaoDeB2XdO2xKeLDsxjT9LCW2tBizsmp9XlR60161eTn0f0Yu8SV+7tWD0pczzl+pDxsd6GvVsRg4lMMvKK3u0XpFpcjiZ5voiScRAGjas+lKynovr2PUL6PTRBLOedln5n3i3UMW2irl8s7snoVAOF2qUT0GnBVqg6G7CfRVeLbmnxDGkKjGppCB28pBhRYFeKm39uCI+ag42yK+cUPnwxQjQsbjjK1S3t/5llf06PP2Vzbo83UnLA3TJDQTQ8atUvya8tyvlGswxQTBguQEIbTAio52eYsscl6UgCcwAQh8968KvcxDTFGT0D0tjXo4z/TJ7947BTIRni55LN7/1E7HUFbITc4zd58rl+MsR0xyxeYjB65QDX3zTNQ5nsOoF+Uzpmy6JuHVQJ0HGEY6dFj9SWvplqrCJChpDwwRjIpK/rEdHFyhmuoNhkKwkx3eEK4QkrG+LLGdVmXz4X6UZXeJ9RUTUFJMTlDuFU1kIwd7O3u9YIhzij49+bM X-MS-Office365-Filtering-Correlation-Id: 36dd9400-7f8f-4924-2400-08d474eb4fac X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:BLUPR05MB308; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB308; 3:o3soF1Z629hWC2K67cgZfYkEa/4kVQxC8B0lm7700/ZVNVI5hIFeS4MMZRe/FTKZ1WHz939JjjpkOK+a6CixA6apmvRw/GcMOlhUeu5R2+4H21l8c5XREOGCZSKM6b0rzcrHMsSi5vlixNubXE8DwpzIp9WVfSJyZh0vn6NIN7Vd2tNP3EBpQHM81yGO0DIW6CN2x/uI+mB6CVudQVr3g5M4w0c0HufTqN77MTkE2/2Ng1Wk/W44huvA2rYq2cNeNwaTTQh4jLSKNe9ijwr1VK+mQ7HzaVSkUP90lrB/04TZ0+tyHtGyNj5gliW1Om9R/LIobYFlSfAVFXWAaTQn7ZR+GmBFZEM53BdsnnlUi5SfN2ubF+m3yIqaj8n4LFTv82PnL77JYgwgfDJggp9TSA==; 25:v2fVHmT6kPuwJgq91xiyA9V109uxMOp+T24sVWHzA61AjOFWOKU9NVpwWUM6A0FH8vNgRdU1Pbj2RVGqbbNCkJ6iLhJMjVd+YRlLsVAJMo7CmAcSdn7SViir7iAggRP5gNbqAAElOT8M3FRwL5Kd0fIWrVcbdQMc5L1SC6uyQIEdkumEdadjojBK3eWx7sbPZa6YzfX6rpRjqhsyNjOozKGaAnFfC3AAvh23u2AoU4U9V/OKL2gEtMBhfh5eUapi3asWS2VRQR6dkewrZHpfiGePQIu3BM7tL//ATghVyIbzh22N2Jg64KyOKxhDYDyKFvcct7gXRSGHWefmHlQeGHxOzaBekk28qmBIeK/mDMXperYA2DVHIFwoEFGpPkEt3anpeRFc6OYL9PhB9ftwxN/rUGFZmEy2atfQGtum3h5q8vQJwE3Mce+Rat104ezWWVR8pswrc/XQAacrqVB0fg== X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB308; 31:3pp+u/+/fESeBMVeNNXquZmCbhZL2m+xNUGaItRBMdxw8qRJk6GWFpdNOwR30U75Mc4EESQhKK9RI4yn54R7oLMIbjCuhFKgCUlIbqMFuuHSJnV3eqPpdbZIx6S9aEJqMYdLeQrXePfYkXEdbnRans7kXojZTMyAVGvMBNqVnGpI3ejZkjR6uUnsA9Ux1t/Vi1N86VxDbSVKHi9dnfQEQGcAIMcsrYwN2IC51EhDncihC7ElViQN5EME7i0tb7uCQAiu5bMr2bFD5otumMF5sQ==; 20:mtKx5ZklFe7DpPjbp0O3wlmbl29DWF52rVZiE1PioY3bJ3Xwd1T49GMBTUe7A19gnHnDxkuAq5qNaJAy+tzvBzEzDWtpc1a4udk/x1ZQdUy3cRZpqlPihvlK5F/P11xC00kgcc+IC6Ru+pAwxn07fA+3axZlC9lwgCFVoFoA7h6hfmwVJYQE43x6UgovJcKnFv6Q6N5BP6n2ft5NpdAsXumiX4X1Vyb35SvCCgRsw/3PrdvOonixnd9LFgMIwUXXt3FzeYsMPlCd4OQoUlk526hKikdg9BU25KlMT1c2fU1B+PQEZ4tYWINWUJKGwqCXl0q2hlBLIIqrO6E4cJbqnvhf+V9lZNxRZL6P7uCIfnRrxoEO6K7FedAtQg6pzqJeghKIQflHByJYkghlAUrTd5jFytZBg+ZjvSuQ1KiA2v7ftXPdpsORFCzU1q4XrC4z14ZlqmqA0aQRzy3r2ylGiG+xGabiRI/2L7TlbfR2OUfwAo600b5BkP+UkLSEo0YF X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(37575265505322); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(13015025)(13017025)(5005006)(8121501046)(13024025)(13023025)(13018025)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123558025)(20161123562025)(20161123564025)(20161123555025)(6072148); SRVR:BLUPR05MB308; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB308; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB308; 4:cWfQji3wEihwW1XpcSV5MFnqAVCkEILy+Br3GIjkB8xAf1KLX/TFFZ+L+JHb8A9fUlhvBU1C3DxgDA6+M7/zw1O7GmwwHAe4+AuF1ph+zC4sGD7nSKfaj60rpbQE3/6nKqj2lLr3UNCBhojJBTlVENcVrbgcbsvyg6s5llQ0CfXOYXM43fRonKhDGJqgQZNCZtQFHZND/wQBB1rhnHtxh2wo1an2EEk/tunPBvNI8WIGtZAvunQ+5nsw7weBiz1FEF4Rghx8FWiywZWtcm5cE8pknJOPgTtz8WALvlaq0BNjE6+obkJ0YKe4LZQYG7mCn7b/9fuCn5yQwm2HP3rcC9VEGlRw2UfHj477Yad1W7NJB44CrX6VY85ebH2EN88DXXl7kWqFeWWQaslG1UJ/uKmMb0GrLLzPw8lkmzNwxggeO3vXfoJ5sxg/74oGcMS1bsbijUJq5hX2AFu19oMWVF8MDMgedpvpqp6z4UfcxxOqW45Dr2Lu9/6qrLz96BIkHpIoMWsXbGwKnYT+3bLfJEp0om883q+n+ZwxS2rV82Mk107fv7gNPKWu5yk0uySUNU8ugD1PTOC0Evyw3IWq+dC+i0sRRy8ZvzUdLazfo2t6b9mLOqCBjfRtQsf4cG1Bxqy/skEt0tXMudvtpGoKTYf34lew/ZJfwHVkybwES3AQVi5RYmkEdqhEVY2nKeIxO9iKg3qPFjzb+5q2JOrMfjflrwYopp3qZXcNGOohDeqF+uFr4G5WymSoLTSE9sy/DGMwd/EHUI9yr1YH6tb6Pg== X-Forefront-PRVS: 02596AB7DA X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR05MB308; 23:HoIex38WpzM3ap/MqKLbZy0VlEkJrNsj9OCmKH6BcU?= =?us-ascii?Q?jlcG75yFWCAhLGnw8jpSObAhAYlewHLOgp9jOdUddFlLZHcKbHn9sWSVpEuo?= =?us-ascii?Q?Lug2qXCXgNVt5MipIlQcNRCmMrr21vZbz8S3ZIGxsiAyLRCL10rY7H4CSMRe?= =?us-ascii?Q?CNclMoOKAMkRxNa4lmVpPPqJ/bvk7iAxVjx3YNT5W2P5GmxUmKyb0xtqXqWd?= =?us-ascii?Q?Q5m51UwAoenxY3AXcRIP3zwZ7PXMAF1jA+3RF3QG+XfpkcHL9TmwiSvH60pN?= =?us-ascii?Q?NS5dmPnyeYuP/C+5162ZPvtF5qmoEElWJ0zH4YMryuUglgSuupHJyESyAln4?= =?us-ascii?Q?C/vhyOzYIwDQymwvcszPpp12P26n/Xn398+3kX2Cz3grT4ZZY8CqwTedDUQn?= =?us-ascii?Q?m4Ei1QfE01H3WV0RhE2GV9Po8QdttlDe977AXGh2J0I+Mvo09I2hJdHuYk8D?= =?us-ascii?Q?+ld1tsq3eAYANiSZTOqjeKBrbUHVg2ZV94LG3tbzAzkIc01o5v4NBo/gpygf?= =?us-ascii?Q?/XFnc3w8zhqljJ1iKoikRATJDYTyTw2wzP++lOtRziqPtw1bpEiwVywePxSG?= =?us-ascii?Q?aT+uO+lt8pXr83b9Pv4ANk5/EK7mJbVHcrChTMQXOebO1eC3ac+3QbYEZYrz?= =?us-ascii?Q?GbR3QkcIZNFx6IjusRm4agxDKD7fj22H2BG4Xk9L9gKzdVsoswXZQzinsL5P?= =?us-ascii?Q?ZeVwbD/a7Jz+fksqZnkkJEjpdxpzVCxpOE1AsQjvnUTxrb0R6s0Ta47UE2N4?= =?us-ascii?Q?PkldndPqOnqFs4loLvFpiRDrBZ9QIy/LbLfLIviNXIwB/i0ohpsh3l4HejVz?= =?us-ascii?Q?QWv3Dnn0ZhY1Mt5+T0S8CoP6+aLflwf2HpwA96QZK7tO110paixm2U5uT3aZ?= =?us-ascii?Q?VfCgb9fnZTuS+A0u63Ge42VImXkobbHOqtHQf8HeWgx7CBLpAv6sviBR+1se?= =?us-ascii?Q?qzGIz95X1J1eF+ZO+zRoqALdqkNWFii6imkSP5y/Di+9EmjgjkyMAZ89pILd?= =?us-ascii?Q?XjTTJ87zwPQgZgTYNG/VwDHZCH8VFq0/oUtz+1v3opXYzoXA4+iWu4iw2wmn?= =?us-ascii?Q?+AMxJ5G2ySWdLDo1QLgYPHHcbrZkqgLof4qs76xwrLy8+FHODKglaiZox+IJ?= =?us-ascii?Q?hfIzWFZEKra/cRVQydwYT+s04+DI7x?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB308; 6:p36fUZlMYNfS/3Q9KlF96PXiw+Ne3ktNXNjQQAWq6oEX42UJpOqmNOrq/rF2Srudle844k1rH9WGvTkvSrR4TaL/rzRp4zxDSJqiAe7cowdaA/NgWRZuKygiHh64czqw91GMcti0ocEy3fh7pTBttOsfdDIr5JuMYInM4R1ElI+z9onqwrKWtT4ACiBszVbdFjuOuk+V5OK0s3UQRjQDrg6XD5DOVIp7ExLFQd7fnFzqZviGDAdmiwJ4Qfq5cp06Zi/AYtBBFRudYbruBHR7P3nINB1v+3NJdjxvanvwD3x1bRBR0+9MYHD5/ampCZ4NvS48eY/IueGjmBkhjl48L87qWhxLG/gY+NNlya39cnB/pb7Qolz6imdGe8/iEyIf/LgDeT2i9draLYchv5kp6DfxyEM1Z5d2+ApzKa156/0=; 5:7NQAmscMBIUux0PKfL5vJ0EucypVoGc72Ker+Y6O1PbOHONFAKu0OXrkuYk/K9XhiwYQlKwXSCWpQiq4C+AyDsdg7YC07Moi5+foIlCAcJSTFhcgJN47vyVvJNvK1N/8Vr1HRvInL3K2zB3G7OVusw==; 24:ZNoh18V9L3rRti25avSrCf0Rf2GS/ucj7jXH+QsEYY+p8cr3moOiySTRcD5NQYtzxLA1tBQoY/FsOkZwrtXbwKz2DNB+kPzz5jJWVdTruvc= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB308; 7:gnZ6PjL4EXQoE2nTew0VcK4D02cGYw3z+HBgMg/rZEUBc9AMkQnIkx6ZAniTUXqOvCskrMGBaeisKJ+S1/wL/o9UR8ZTDuGnfTKK7C76aqNg5A/klPc2vV6fnqc3wteFD9LMtHdEHS+G4AJDkuVrK/41+bqCIYv2Zruo7AmeDffUjieANscqv2nc6Vgfc9ibOAGmM68fbDKD3uQS4Hw2GqcKcdtyqB4TALu5bvyS+55GTnC9NFTfeiTkPmFUwVsxCWwzfgn2LmDWuNz3OMYqcAPFFRlJLhhbNYS1bnjoatKHqekaiOjraCntOCT9MKuZ1YPnhcG/F81rq0xotS3nXQ== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Mar 2017 08:28:56.4532 (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.18]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB308 Archived-At: Subject: Re: [Curdle] comments on draft-ietf-curdle-ssh-kex-sha2-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: Mon, 27 Mar 2017 08:29:00 -0000 Daniel Migault writes: > Hi, > > Please find some comments of draft-ietf-curdle-ssh-kex-sha2-05. > > Yours, > Daniel > > I have the impression that only RFC4253 provided some recommendations, in > which case I would be incline to say that the current draft only updates > this document. The other RFC only defines new suites. Good point. RFC 4353 itself suggests that additional key exchange method names will be defined in RFC 4250, but no update to RFC 4250 has been issued. I have changed to update="4353" and removed 4419, 4432, 4462, 5656 from the list in my copy of the draft. I wonder if I need to add RFC4250 to the update list instead of or in addition to 4353? Comments? > I suggest we either use MUST/SHOULD/MAY or REQUIRE/RECOMMEND/OPTIONAL but > not both. I favor MUST/SHOULD/MAY. If you notice any REQUIRE/RECOMMEND/OPTIONAL in the updated draft, it should be corrected before it goes to final call. > Note that if the recommendations for ipsec > [draft-ietf-ipsecme-rfc4307bis] we also introduced some additional > notation such as SHOULD+/- to specify whether the SHOULD is expect to > raise its status or that SHOULD is only here for interoperability. Sure, I can add a section for SHOULD+ and SHOULD- borrowing from that draft. > Note that recommendations are not the purpose of IANA, so I would > probably change the title of the section. Okay. "Guidance for Key Exchange Method Names" ? > The IANA only adds the code points. It is god that you mentioned the > IANA link. I would encourage you to have the URL as an informative > reference. Point taken. I have made the change. > Recommendations should regularly updated so implementations have the > time to introduce new suites or remove old suites while still > providing interoperability. If the starting point is RFC4253, then we > have: > > diffie-hellman-group1-sha1 REQUIRED > diffie-hellman-group14-sha1 REQUIRED > > and all other suites are OPTIONAL or MAY. Correct me if I am wrong, At > least I believe that that appendix section would be useful to comment on > the update with the previous recommendations. You are not wrong, but RFC 4253 does point to 4250 (SSH-NUMBERS) for the official Key Exchange Method Names list in section 4.10. Hmmm... I suppose I need to revisit the Overview and Rational section and partition some of the choices into an appendix ? The diffie-hellman-group1-sha1 uses the RFC2409 Oakley Group 2 1024-bit MODP group prime P, with generator G=2, Q=(p-1)/2. This RFC will recomment MUST NOT for this key exchange method name. The diffie-hellman-group14-sha1 will be moved to SHOULD- primarily because the sha1 is a way to allow transitional implementation overlap. > curve25519-sha256 ssh-curves MUST I believe this to be a SHOULD+ algorithm. > Maybe a MUST statement may be to strong as curves have just been defined. > Maybe that could be SHOULD+ mentioning it is expected to become a MUST next > time. In fact it is usually hard to move from MAY to MUST. If you do so, > reasons should be provided in the text. Currently it seems it is > implemented in libssh and OpenSSH, not sure it is sufficient for a MUST. > > curve448-sha512 ssh-curves MAY > By default, the suites with MAY status are not mentioned. Okay, I will update the list.. > diffie-hellman-group-exchange-sha1 RFC4419 SHOULD NOT > SHA1 is probably at MUST NOT, so I am expected any suites to be MUST NOT. > Because it represents a threat you are likely to move to MUST NOT directly. Reasonable. > diffie-hellman-group-exchange-sha256 RFC4419 MAY > diffie-hellman-group1-sha1 RFC4253 SHOULD NOT > If group 1 is 768-bit MODP Group , I would consider there are two reasons > to have this as MUST NOT. The diffie-hellman-group1-sha1 is a 1024-bit MODP prime (the Oakely Group 2). I agree MUST NOT is better. > diffie-hellman-group14-sha1 RFC4253 SHOULD > My understanding is that this one is kept for interoperability. However, > the text should make it clear this suite will be deprecated soon. Agreed. It is now a SHOULD- > diffie-hellman-group14-sha256 new-modp MUST > diffie-hellman-group15-sha512 new-modp MAY > diffie-hellman-group16-sha512 new-modp SHOULD > diffie-hellman-group17-sha512 new-modp MAY > diffie-hellman-group18-sha512 new-modp MAY > ecdh-sha2-nistp256 RFC5656 SHOULD > ecdh-sha2-nistp384 RFC5656 SHOULD > ecdh-sha2-nistp521 RFC5656 SHOULD > > The current trend is also to reduce the number of suites > implementation. DO we want to have these three suites as SHOULD. We > should also explain what the next step is expected to be. Okay. I think this makes more sense: > ecdh-sha2-nistp256 RFC5656 SHOULD- > ecdh-sha2-nistp384 RFC5656 SHOULD+ The idea being that a number of standards want ECDH/ECDSA and the CNSA-SUITE only approves of nistp384. That said there do exist constant-time impleemntations of SHA2-256 and at least a few non-constant time SHA2-384. A user "SHOULD" implement at least one ECDH hashing algorithm, but it is not clear that there is much choice yet. So, both may be needed. > ecdh-sha2-* RFC5656 MAY > ecmqv-sha2 RFC5656 SHOULD NOT > gss-gex-sha1-* RFC4462 SHOULD NOT > gss-group1-sha1-* RFC4462 SHOULD NOT > gss-group14-sha1-* RFC4462 SHOULD > gss-group14-sha256-* new-modp SHOULD > gss-group15-sha512-* new-modp MAY > gss-group16-sha512-* new-modp SHOULD > gss-group17-sha512-* new-modp MAY > gss-group18-sha512-* new-modp MAY > gss-* RFC4462 MAY > > rsa1024-sha1 RFC4432 SHOULD NOT > Maybe we could set it as MUST NOT both for key size and SHA1. Agreed. > rsa2048-sha256 RFC4432 MAY -- Mark From nobody Mon Mar 27 07:35: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 5DAEE127286; Mon, 27 Mar 2017 07:35:14 -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.48.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149062531435.30541.8784486698794030262@ietfa.amsl.com> Date: Mon, 27 Mar 2017 07:35:14 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-cms-ecdh-new-curves-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, 27 Mar 2017 14:35:14 -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-Hellamn Key Agreement Algorithm with X25519 and X448 in the Cryptographic Message Syntax (CMS) Author : Russ Housley Filename : draft-ietf-curdle-cms-ecdh-new-curves-02.txt Pages : 16 Date : 2017-03-27 Abstract: This document describes the conventions for using Elliptic Curve Diffie-Hellamn (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-02 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-cms-ecdh-new-curves-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-cms-ecdh-new-curves-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 Mon Mar 27 07:37: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 C84621296BD for ; Mon, 27 Mar 2017 07:37:03 -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, 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 RxZG2rp37Scl for ; Mon, 27 Mar 2017 07:37:01 -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 9575712943B for ; Mon, 27 Mar 2017 07:37:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id EDBF03004D1 for ; Mon, 27 Mar 2017 10:37:00 -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 pfvuR5THFRnY for ; Mon, 27 Mar 2017 10:36:59 -0400 (EDT) Received: from dhcp-8696.meeting.ietf.org (dhcp-8696.meeting.ietf.org [31.133.134.150]) by mail.smeinc.net (Postfix) with ESMTPSA id D7CFA300209 for ; Mon, 27 Mar 2017 10:36:59 -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.2 \(3259\)) Date: Mon, 27 Mar 2017 10:36:58 -0400 References: <149062531435.30541.8784486698794030262@ietfa.amsl.com> To: curdle In-Reply-To: <149062531435.30541.8784486698794030262@ietfa.amsl.com> Message-Id: X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-cms-ecdh-new-curves-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, 27 Mar 2017 14:37:04 -0000 This update asks IANA to assign the needed OIDs in the S/MIME arc. I = think it is now ready for WG Last Call. Russ > On Mar 27, 2017, at 10:35 AM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the CURves, Deprecating and a Little more = Encryption of the IETF. >=20 > Title : Use of the Elliptic Curve Diffie-Hellamn Key = Agreement Algorithm with X25519 and X448 in the Cryptographic Message = Syntax (CMS) > Author : Russ Housley > Filename : draft-ietf-curdle-cms-ecdh-new-curves-02.txt > Pages : 16 > Date : 2017-03-27 >=20 > Abstract: > This document describes the conventions for using Elliptic Curve > Diffie-Hellamn (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-02 > = https://datatracker.ietf.org/doc/html/draft-ietf-curdle-cms-ecdh-new-curve= s-02 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-curdle-cms-ecdh-new-curves-= 02 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 27 09:52:11 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 8DB8D126B72; Mon, 27 Mar 2017 09:52:09 -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.48.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149063352954.30549.9232124918058036167@ietfa.amsl.com> Date: Mon, 27 Mar 2017 09:52:09 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-ssh-modp-dh-sha2-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: Mon, 27 Mar 2017 16:52:10 -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-03.txt Pages : 5 Date : 2017-03-27 Abstract: This document defines added Modular Exponential (MODP) Groups for the Secure Shell (SSH) protocol using SHA-2 hashes. 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-03 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-modp-dh-sha2-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-ssh-modp-dh-sha2-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 Mon Mar 27 12:18:14 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 7743912947E; Mon, 27 Mar 2017 12:18:13 -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.48.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149064229346.30583.1087650825675385588@ietfa.amsl.com> Date: Mon, 27 Mar 2017 12:18:13 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-ssh-kex-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: Mon, 27 Mar 2017 19:18:13 -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 : Key Exchange (KEX) Method Updates and Recommendations for Secure Shell (SSH) Author : Mark D. Baushke Filename : draft-ietf-curdle-ssh-kex-sha2-06.txt Pages : 9 Date : 2016-09-20 Abstract: This document adds recommendations for adoption of ssh-curves from the [I-D.ietf-curdle-ssh-curves] and new-modp from the [I-D.ietf-curdle-ssh-modp-dh-sha2], and deprecates some previously specified Key Exchange Method algorithm names for the Secure Shell (SSH) protocol. It also updates [RFC4253], [RFC4419], [RFC4462], and [RFC5656] by specifying the set key exchange algorithms that currently exist and which ones MUST, SHOULD, MAY, and SHOULD NOT be implemented. New key exchange methods use the SHA-2 family of hashes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-kex-sha2/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-ssh-kex-sha2-06 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-kex-sha2-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-ssh-kex-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 Mon Mar 27 12:19: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 379A81294B9; Mon, 27 Mar 2017 12:19: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.48.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149064234119.30603.18224899815211367459@ietfa.amsl.com> Date: Mon, 27 Mar 2017 12:19:01 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-ssh-curves-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, 27 Mar 2017 19:19: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 : Secure Shell (SSH) Key Exchange Method using Curve25519 and Curve448 Authors : Aris Adamantiadis Simon Josefsson Mark D. Baushke Filename : draft-ietf-curdle-ssh-curves-01.txt Pages : 6 Date : 2017-03-27 Abstract: How to implement the Curve25519 and Curve448 key exchange methods in the Secure Shell (SSH) protocol is described. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-curves/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-ssh-curves-01 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-curves-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-ssh-curves-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 Mar 27 12:48: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 C79341294AE; Mon, 27 Mar 2017 12:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, 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 G_b7-MX01vUP; Mon, 27 Mar 2017 12:47:44 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::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 33C691294AC; Mon, 27 Mar 2017 12:47:44 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id 190so66541989itm.0; Mon, 27 Mar 2017 12:47: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=jh70VSNGCWW12PKBg6kChR2NUB2QhbHxo4Te01rzXhc=; b=BGDf0A7/rqo/RGaPhW2DzbB4HWFlBH8ystA/FlZBbEBcZsqyzvfgq49ZLA8Mz+pnIQ WLBMdfBgIug8btKI3z5LlFynYgrqfpI9vikbTpTABS4Q/+Prt0fbJKvlIVqAJ2zUHEx1 igETtkwbZgQvP+lnkGiBUhEixbbZhI2z9k1brc7X+DT+NVH1G4mhu1ltGf8Z/1YtzxLk iXXHAZVv2r98skf19eGzpG58NrrcJt3FWyLSlmM9pqHZE8mkvKt2IrByE3LoHjZ+p1sb AjdV3YHF+yjEfSbn1WFvJh1is6phpdZ59XPayjf3H6g95F8Xe284WUHTPd9Ybcvop6VF C1PQ== 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=jh70VSNGCWW12PKBg6kChR2NUB2QhbHxo4Te01rzXhc=; b=sWzx3dtHOHg1KusRiQ9CjzMe7EAyRL6HXl5pzzZEM4DaCyVgtZFKCG8ZMuAaQZnCV1 2e/qjBVS6f9CB83g04AA5cz31RM/jJ5kMU/7E6SaqIu5pi2BHfnmhZJcWHYcy+NszRIv R7Ntb+wMYuZqHlfvvRD87FL7uFCL2aoLRhjc2Ys8LL1QdxOWXCQoLktqUalnPIoykgIe ZiM+araEGCzMYU1QWhl7XfmcoJUWm+EEwMjWGwuQjqxNKftjNBAnen9Dk8NmHHj2f1WL sPti2aXSSxLf9y9KTapM518YnTzlYGW0M2xT0kx7ECmldAPyLj+y+Tw1KQgT+zjyLG4H Q8ow== X-Gm-Message-State: AFeK/H336X6ApkySao4U143YmtvmnYcaK8sjj0K5nlP3LMi4rkc4DIR5fcwhvtk3CnvrqzC1tQmcDtyKGmCf8g== X-Received: by 10.107.168.21 with SMTP id r21mr21775613ioe.45.1490644063440; Mon, 27 Mar 2017 12:47:43 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.35.213 with HTTP; Mon, 27 Mar 2017 12:47:42 -0700 (PDT) In-Reply-To: <149062531435.30541.8784486698794030262@ietfa.amsl.com> References: <149062531435.30541.8784486698794030262@ietfa.amsl.com> From: Daniel Migault Date: Mon, 27 Mar 2017 14:47:42 -0500 X-Google-Sender-Auth: kkv0eIvcsHQNdmDPYygrsxwelDo Message-ID: To: internet-drafts@ietf.org Cc: i-d-announce@ietf.org, curdle Content-Type: multipart/alternative; boundary=001a114215e8e35b31054bbb9d4a Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-cms-ecdh-new-curves-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, 27 Mar 2017 19:47:47 -0000 --001a114215e8e35b31054bbb9d4a Content-Type: text/plain; charset=UTF-8 Hi, This email starts a Working Group Last Call for draft-ietf-curdle-cms-ecdh-new-curves [1]. Please review the document and provide feed backs by April 10. Yours, Daniel [1] https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-ecdh-new-curves/ On Mon, Mar 27, 2017 at 9:35 AM, 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 : Use of the Elliptic Curve Diffie-Hellamn Key > Agreement Algorithm with X25519 and X448 in the Cryptographic Message > Syntax (CMS) > Author : Russ Housley > Filename : draft-ietf-curdle-cms-ecdh-new-curves-02.txt > Pages : 16 > Date : 2017-03-27 > > Abstract: > This document describes the conventions for using Elliptic Curve > Diffie-Hellamn (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-02 > https://datatracker.ietf.org/doc/html/draft-ietf-curdle- > cms-ecdh-new-curves-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-cms-ecdh-new-curves-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 > --001a114215e8e35b31054bbb9d4a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

This email starts a Working Group Last Call fo= r draft-ietf-curdle-cms-ecdh-new-curves [1]. Please review the document and= provide feed backs by April 10.

Yours,
Daniel

[1] https://datatracker.ietf.org/= doc/draft-ietf-curdle-cms-ecdh-new-cur= ves/


On Mon, Mar 27, 2017 at 9:35 AM, <internet-drafts@ietf.org> 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:= Use of the Elliptic Curve Diffie-Hellamn Key Agreement Algorithm with X255= 19 and X448 in the Cryptographic Message Syntax (CMS)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Russ= Housley
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-curdle-cms-ecdh-new-curves-02.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 16
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-03-27

Abstract:
=C2=A0 =C2=A0This document describes the conventions for using Elliptic Cur= ve
=C2=A0 =C2=A0Diffie-Hellamn (ECDH) key agreement algorithm using curve25519= and
=C2=A0 =C2=A0curve448 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-02
https://datatracker.ie= tf.org/doc/html/draft-ietf-curdle-cms-ecdh-new-curves-02

A diff from the previous version is available at:
https://www.ietf.org/rfc= diff?url2=3Ddraft-ietf-curdle-cms-ecdh-new-curves-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

--001a114215e8e35b31054bbb9d4a-- From nobody Mon Mar 27 13:51: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 567B0129659 for ; Mon, 27 Mar 2017 13:51:30 -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 UylBySEiCqmq for ; Mon, 27 Mar 2017 13:51:28 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::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 DCFEA120727 for ; Mon, 27 Mar 2017 13:51:27 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id x35so48678298qtc.2 for ; Mon, 27 Mar 2017 13:51:27 -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=xWYisLbVx1jlprZqciwPTKsYuaFRf36NZ9XfyFcpmG8=; b=Dr0XbMmh0DeJASniXySmR+Uhsp6RhFi5q5ynpjiIbCfnpRhWoZ9yUybUhdkis8r+PO UT/jvag5yUIyn1F1sYgdN3fTUoPZtciKAettYzMjY2Q75YWXuFVW32qs593i1Mal5DUA soup3cyZMsi0h0UXjsxRYLcn3TUGAd9N7Ei4qspWUV3BXL2bzuTBtLynb8TWTMRIy1CB T1KGYOMQXDbfagKrkZalmR7syRIOOnss0qtQqeI50z5Dxu0Csh4JM6I2Uf8yDA5M9zWN 3hqfC3Ha73REhhRXKZPszF7EEQuCN1yChHSNqxmJVOiVUB652LfZUBxuXYdf5ngVGM4y Zdyg== 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=xWYisLbVx1jlprZqciwPTKsYuaFRf36NZ9XfyFcpmG8=; b=s9LHUrbNt5kW2nurB6lGLmpjDwZohHkPq1Jq1XXfWr//4+uTYhRChxIH1UkYBHXu/g 3nTiAC4PmvH+7SZZpXS0WQ/x0WGmKG6Le1N4M/iH1t4Bpvf7+Aw1VU+6cLrKdoe73u8q u+UvgCGxJO4XxCbcTPQ7JILLc0TTHp+lgTlqKcT3NkRPb6DlhWP+6q+8zb5aJbak+qLY amGt3Ea4DckP7xXmp0BR/EnRgHVo5LKJI1hACQ4scVIYsWUPB6YdbtR/ufzseAC3F1Ef 6EbBCZH9e/T8XoeklQVHDU3P0uxjGbFI8DVbeJzqSSnO/sL2myRGDk4PDIr8NoInXGqQ gpkw== X-Gm-Message-State: AFeK/H2lk15GICADiwtJ13YMwxA3HXmHdQFAxJETxtJrnL6ssxawo3awxLDcTWEDfs/Hkx+j3XVpFSyZdvdv1g== X-Received: by 10.200.41.33 with SMTP id y30mr22349771qty.47.1490647887071; Mon, 27 Mar 2017 13:51:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.129.216 with HTTP; Mon, 27 Mar 2017 13:51:26 -0700 (PDT) In-Reply-To: <20170327072447.GA2827@LK-Perkele-V2.elisa-laajakaista.fi> References: <1490575901696.39454@cs.auckland.ac.nz> <20170327072447.GA2827@LK-Perkele-V2.elisa-laajakaista.fi> From: denis bider Date: Mon, 27 Mar 2017 14:51:26 -0600 Message-ID: To: Ilari Liusvaara Cc: Daniel Migault , "curdle@ietf.org" , Peter Gutmann Content-Type: multipart/alternative; boundary=001a11406a1ecb54d0054bbc81b4 Archived-At: Subject: Re: [Curdle] comments on draft-ietf-curdle-rsa-sha2-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, 27 Mar 2017 20:51:30 -0000 --001a11406a1ecb54d0054bbc81b4 Content-Type: text/plain; charset=UTF-8 That is a welcome assurance. If PSS is added, it sounds like something to mention in Security Considerations as a further argument against small keys. On Mon, Mar 27, 2017 at 1:24 AM, Ilari Liusvaara wrote: > On Sun, Mar 26, 2017 at 10:50:02PM -0500, Daniel Migault wrote: > > Whether pss variant have to be added is up to the WG to decide. That I > > would be in favor is only one opinion ;-) [1] lists some advantages of > PSS > > vs PKCS1v1.5. Note that enabling a given key may be used by two variants > > needs also some thoughts. I will raise the question during the meeting, > but > > discussion will be made on the mailing list. > > This thing came up in context of TLS 1.3. > > The probability PKCS#1v1.5 and PSS signature overlaps depends on key > size and salt size. Where overlap is defined as encoded message that > is valid in both PKCS#1v1.5 and PSS. These depend on hashing algorithm > and number of bits in n, but not precise value of n. > > TLS restricts salt length to be the same as hash length. Which makes > overlaps highly unlikely with key sizes >=2048 bits and hash sizes > <=512 bits. The problem being to control ~1000 bits using 512 bits. > > As key size decreases or salt size increases, the overlap probability > increases, and eventually overlaps become almost certain, and further > one gets multiple overlaps. > > > > > [1] > > https://www.emc.com/emc-plus/rsa-labs/historical/raising- > standard-rsa-signatures-rsa-pss.htm > > > -Ilari > --001a11406a1ecb54d0054bbc81b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That is a welcome assurance. If PSS is added, it sounds li= ke something to mention in Security Considerations as a further argument ag= ainst small keys.

On Mon, Mar 27, 2017 at 1:24 AM, Ilari Liusvaara &l= t;ilariliusva= ara@welho.com> wrote:
On Sun, Mar 26, 2017 at 10:50:02PM -0500, Daniel Migault wrote:=
> Whether pss variant have to be added is up to the WG to decide. That I=
> would be in favor is only one opinion ;-) [1] lists some advantages of= PSS
> vs PKCS1v1.5. Note that enabling a given key may be used by two varian= ts
> needs also some thoughts. I will raise the question during the meeting= , but
> discussion will be made on the mailing list.

This thing came up in context of TLS 1.3.

The probability PKCS#1v1.5 and PSS signature overlaps depends on key
size and salt size. Where overlap is defined as encoded message that
is valid in both PKCS#1v1.5 and PSS. These depend on hashing algorithm
and number of bits in n, but not precise value of n.

TLS restricts salt length to be the same as hash length. Which makes
overlaps highly unlikely with key sizes >=3D2048 bits and hash sizes
<=3D512 bits. The problem being to control ~1000 bits using 512 bits.
As key size decreases or salt size increases, the overlap probability
increases, and eventually overlaps become almost certain, and further
one gets multiple overlaps.

>
> [1]
> htt= ps://www.emc.com/emc-plus/rsa-labs/historical/raising-standard-rs= a-signatures-rsa-pss.htm


-Ilari

--001a11406a1ecb54d0054bbc81b4-- From nobody Mon Mar 27 14:33:20 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 87DEC126DEE for ; Mon, 27 Mar 2017 14:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, 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 7dBzrUEO0zKx for ; Mon, 27 Mar 2017 14:33:16 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::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 595C51294E0 for ; Mon, 27 Mar 2017 14:33:16 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id 190so69827518itm.0 for ; Mon, 27 Mar 2017 14:33:16 -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=w6vw6OM1mLYD8QK4pd4t/fW1ZsJj39d6lFQzOYuqcrQ=; b=a4yLxCYEzvF/SdeFYJW54jGAU40TzvrtTY3D62zH+PSYEeNMjnM7LJFuj+s0Puto4u kkdyS/BpKM50N4beFZKWta9o9CyTs+4jkQdxxJ1nmGxoQCbqS8QpeYEPrUF3LxKX/egV Uc25uYuyizCJBwqkxV3jzBaV18GnoQPkvk9MSj0Uh7TpKXxCDzxQWCuiP5QT3BR5j+KD m9EpWqTiXrnCyQGwD2wJj9AqzFT1sUUwYbJnNC6ZLcpthGGl2sH0hRsNn99cW5bUEXAd 2a2tuLIjlRaq02a2yrEsWGC1ZOJIof4b/OFqftiVXDlTCLEA5r2wjqH95uiZQ+YaMQmM bbRA== 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=w6vw6OM1mLYD8QK4pd4t/fW1ZsJj39d6lFQzOYuqcrQ=; b=QbnrIVhzX2Dbih+GgdbU+QvjnjVVURj+7ZjSUOUcrK5k2ZNBeURFQRHw9pMn0BQsPo 6OljLB49XfrnCsFbENTXRsnjF2OPUOm72HtoclEJ4bequc2wQr3Sx1S5C1Gn1kXuwAHl 3shlkdIfPNwxSXQEP18/207QAF/pmEywTCQyc3g+hp6HSwmeO/Yw9N5If3p1kN7eWIrm Lp6Ba1B0X1ubk7QKk0+Z211+vqhVBYlGpVk0o7Oij6fVs8frORUQwjrII82H0GwQvIjF Agni7ExSGxFJmsDZ+8KNbZkuSq6U1EjpkL8ScVg1NKKTmORSY4L+dfpRlNe89jNlbD1Q QaPQ== X-Gm-Message-State: AFeK/H2nXYeClyPbn+nJRRfrZmx0z1Ku1QIK3ZWL0ZX8K+xWnnEAE2zLe0vVfLJjY5kgfO7fDMOap2L0kbdhRQ== X-Received: by 10.36.206.6 with SMTP id v6mr11623464itg.48.1490650395658; Mon, 27 Mar 2017 14:33:15 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.35.213 with HTTP; Mon, 27 Mar 2017 14:33:15 -0700 (PDT) In-Reply-To: References: From: Daniel Migault Date: Mon, 27 Mar 2017 16:33:15 -0500 X-Google-Sender-Auth: pXo_mF3-gP9sOBM7f31rElTVZZM Message-ID: To: curdle Content-Type: multipart/alternative; boundary=94eb2c0b0c585154a1054bbd171b Archived-At: Subject: Re: [Curdle] Request for minute takers / jabber scribes 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, 27 Mar 2017 21:33:19 -0000 --94eb2c0b0c585154a1054bbd171b Content-Type: text/plain; charset=UTF-8 Hi, Please volunteer!!! Yours, Daniel On Fri, Mar 24, 2017 at 3:51 PM, Daniel Migault wrote: > Hi, > > We are looking for a minute taker and a Jabber scribe. Please volunteer! > > Yours, > Rich and Daniel > > > --94eb2c0b0c585154a1054bbd171b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Please volunteer!!!
Yours,
Daniel

On Fri, Mar 24, 2017 at 3:51 PM, Daniel Migault <daniel.migault@ericsson.com> wrote:
Hi,

We are = looking for a minute taker and a Jabber scribe. Please volunteer!

Yours,
Rich and Daniel



--94eb2c0b0c585154a1054bbd171b-- From nobody Mon Mar 27 14:57:10 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 3EF8B126DEE; Mon, 27 Mar 2017 14:57:08 -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.48.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149065182820.30626.17090606660879640560@ietfa.amsl.com> Date: Mon, 27 Mar 2017 14:57:08 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-ssh-kex-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: Mon, 27 Mar 2017 21:57:08 -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 : Key Exchange (KEX) Method Updates and Recommendations for Secure Shell (SSH) Author : Mark D. Baushke Filename : draft-ietf-curdle-ssh-kex-sha2-07.txt Pages : 11 Date : 2017-03-27 Abstract: This document is intended to update the recommended set of key exchange methods for use in the Secure Shell (SSH) protocol to meet evolving needs for stronger security. This RFC updates [RFC4253] MUST algorithms. This RFC also notes that the [IANASSH] has replaced [RFC4250] as the primary reference document for SSH Protocol Assigned Numbers. This document adds recommendations for adoption of Key Exchange Methods which MUST, SHOULD+, SHOULD, SHOULD-, MAY, SHOULD NOT, and MUST NOT be implemented. New key exchange methods will use the SHA-2 family of hashes and are drawn from these from [I-D.ietf-curdle-ssh-curves] and new-modp from the [I-D.ietf-curdle-ssh-modp-dh-sha2] and gss-keyex [NEWGSSAPI]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-kex-sha2/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-ssh-kex-sha2-07 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-kex-sha2-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-ssh-kex-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 Mon Mar 27 15:43: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 F0C5B12965E for ; Mon, 27 Mar 2017 15:43:48 -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, HTML_MESSAGE=0.001, 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=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 ESeotCGvpGBx for ; Mon, 27 Mar 2017 15:43:47 -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 86240129577 for ; Mon, 27 Mar 2017 15:43:46 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.20/8.16.0.20) with SMTP id v2RMfKtw028165 for ; Mon, 27 Mar 2017 23:43:43 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=OVydx2BuqyEj7dqByHncO/7M3roZrSuXA2yxw6HjHBM=; b=HfFa42A4gwhCiTsquOrlzbazKzN8D/z0ybPBcEerI4+8AIQSTkU1zLSfYOGrpTDYcXGp l++EyPKWWIy0fEQBD6GMXvoUJGTzhsQ9X84A4jfMMNQFEFdbe9a9Qt1bLUbkG63eLbkG qPAQTybWG5aH5yAUfFkjyZxInPjws4NUHl7kJbpXd7+yCCCIOVmYzyI6qx+p//Evywr4 cHj5QkvVUT5wrHZmNrMVnvkEs5tasjIDNPQOEc3BljgKSsxyzAf1DPc87/xbTA0O4Loz /NySFTWICEhTd24cOdGJp3HtvH+Iq65OizATiUBKjZ21yK4K/MTqxX058dDSj8AQWVl6 pw== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 29fbqy00hy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 27 Mar 2017 23:43:43 +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 v2RMcHsN021524 for ; Mon, 27 Mar 2017 18:43:42 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 29fbbhg0da-9 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Mon, 27 Mar 2017 18:43:42 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 27 Mar 2017 18:43:16 -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.1178.000; Mon, 27 Mar 2017 18:43:16 -0400 From: "Salz, Rich" To: "curdle@ietf.org" Thread-Topic: Confirm consensus Thread-Index: AdKnSy388fov6eZhSESSlQZWzW5yzw== Date: Mon, 27 Mar 2017 22:43:15 +0000 Message-ID: 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.43.38] Content-Type: multipart/alternative; boundary="_000_f500a75cbdac4651bfd9f4871e42a917usma1exdag1mb1msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-27_21:, , 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-1702020001 definitions=main-1703270185 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-27_21:, , 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-1702020001 definitions=main-1703270185 Archived-At: Subject: [Curdle] Confirm consensus 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, 27 Mar 2017 22:43:49 -0000 --_000_f500a75cbdac4651bfd9f4871e42a917usma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable At the meeting today we had strong consensus to indicate OPTIONAL parameter= s in the signature by not providing the parameters. The alternative is to = have a NULL, for empty, options. If you disagree with this, please speak up during the last call. -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz@jabber.at Twitter: RichSalz --_000_f500a75cbdac4651bfd9f4871e42a917usma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

At the meeting today we had strong consensus to indi= cate OPTIONAL parameters in the signature by not providing the parameters.&= nbsp; The alternative is to have a NULL, for empty, options.

 

If you disagree with this, please speak up during th= e last call.

 

-- 

Senior Architect, Akamai Technologies

Member, OpenSSL Dev Team

IM: richsalz@jabber.at Twitter: RichSalz<= /p>

 

--_000_f500a75cbdac4651bfd9f4871e42a917usma1exdag1mb1msgcorpak_-- From nobody Mon Mar 27 15:57:38 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 826DC1296A4 for ; Mon, 27 Mar 2017 15:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 RFO65Tqu0qtC for ; Mon, 27 Mar 2017 15:57:35 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 65E68128BA2 for ; Mon, 27 Mar 2017 15:57:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 5819325E43; Tue, 28 Mar 2017 01:57:29 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id K-ekytXJPFF0; Tue, 28 Mar 2017 01:57:29 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 1F3352313; Tue, 28 Mar 2017 01:57:29 +0300 (EEST) Date: Tue, 28 Mar 2017 01:57:27 +0300 From: Ilari Liusvaara To: Rob Stradling Cc: Daniel Migault , Sean Turner , curdle Message-ID: <20170327225727.GA5038@LK-Perkele-V2.elisa-laajakaista.fi> References: <48694963-30E4-4B88-BFEF-C68475DCD689@sn3rd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-pkix / Algorithm Identifier for prehash variant 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, 27 Mar 2017 22:57:38 -0000 On Fri, Mar 24, 2017 at 10:27:43AM +0000, Rob Stradling wrote: > On 22/03/17 23:12, Daniel Migault wrote: > > >OIDs will be re-assigned by the IANA. > > Please don't do that. > > The 1.3.101 arc was chosen to avoid OID bloat. Symantec/thawte generously > donated a range of OIDs under this arc to be used for identifying these > algorithms. Reassigning the OIDs under a different arc is not necessary. +1 And just to ensure that there is no miscommunication, is anyone suggesting that any of the following OIDs are changed: - 1.3.101.110 (id-X25519) [2b656e(+en)] - 1.3.101.111 (id-X448) [2b656f(+eo)] - 1.3.101.112 (id-Ed25519) [2b6f70(+ep)] - 1.3.101.113 (id-Ed448) [2b6f71(+eq)] If so, why are they suggesting changes here (if reasoning is expressed in prior mail, then pointer to that mail)? AFAIK, all these OIDs are in part of arc given for specific purpose of containing them. I don't remember any proposals for any changes to those. -Ilari From nobody Mon Mar 27 16:10: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 7C2601296C3 for ; Mon, 27 Mar 2017 16:10:22 -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, 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 cDJQ7zotXhWv for ; Mon, 27 Mar 2017 16:10:21 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AF551296C2 for ; Mon, 27 Mar 2017 16:10:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 98044300269 for ; Mon, 27 Mar 2017 19:10: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 K_FR1WOJSXVu for ; Mon, 27 Mar 2017 19:10:19 -0400 (EDT) Received: from dhcp-9516.meeting.ietf.org (dhcp-9516.meeting.ietf.org [31.133.149.22]) by mail.smeinc.net (Postfix) with ESMTPSA id 78491300250; Mon, 27 Mar 2017 19:10:19 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Russ Housley In-Reply-To: <20170327225727.GA5038@LK-Perkele-V2.elisa-laajakaista.fi> Date: Mon, 27 Mar 2017 19:10:17 -0400 Cc: curdle Content-Transfer-Encoding: quoted-printable Message-Id: <0697590C-CBEE-41D8-BA66-4804A71180B4@vigilsec.com> References: <48694963-30E4-4B88-BFEF-C68475DCD689@sn3rd.com> <20170327225727.GA5038@LK-Perkele-V2.elisa-laajakaista.fi> To: Ilari Liusvaara X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-pkix / Algorithm Identifier for prehash variant 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, 27 Mar 2017 23:10:22 -0000 > On Mar 27, 2017, at 6:57 PM, Ilari Liusvaara = wrote: >=20 > On Fri, Mar 24, 2017 at 10:27:43AM +0000, Rob Stradling wrote: >> On 22/03/17 23:12, Daniel Migault wrote: >> >>> OIDs will be re-assigned by the IANA. >>=20 >> Please don't do that. >>=20 >> The 1.3.101 arc was chosen to avoid OID bloat. Symantec/thawte = generously >> donated a range of OIDs under this arc to be used for identifying = these >> algorithms. Reassigning the OIDs under a different arc is not = necessary. >=20 > +1 >=20 >=20 > And just to ensure that there is no miscommunication, is anyone > suggesting that any of the following OIDs are changed: >=20 > - 1.3.101.110 (id-X25519) [2b656e(+en)] > - 1.3.101.111 (id-X448) [2b656f(+eo)] > - 1.3.101.112 (id-Ed25519) [2b6f70(+ep)] > - 1.3.101.113 (id-Ed448) [2b6f71(+eq)] No. There were two things discussed about OIDs: 1) whether to keep the pre-hash OIDs in the document. 2) how to get the OIDs assigned for = draft-ietf-curdle-cms-ecdh-new-curves Neither of these has any impact in the OIDs on your list. Russ From nobody Mon Mar 27 16:41:03 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 715F01277BB for ; Mon, 27 Mar 2017 16:41:02 -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, HTML_MESSAGE=0.001, 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=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 OrEhCPYVeg-A for ; Mon, 27 Mar 2017 16:41:00 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::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 E2B4B127275 for ; Mon, 27 Mar 2017 16:41:00 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.20/8.16.0.20) with SMTP id v2RNW5M8014646 for ; Tue, 28 Mar 2017 00:40:58 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=D8/06+64EiC0QQdrsSC1wb8t8XuO7WcMA6iH02Ionxs=; b=DyJsYTA/OSyxqkKmaLrnLghCzYKIH2iv7ScrO1hd7WfeqyDbhuSUmbr5SrHs0mBRloLQ agGDUwbLdsAHOjj8tns+J7E7s0HtcqVSC6m5ZJAMJ0M3cCthXq7+ZcPkdSVYll53S4sX oI53pICUqB1n875l3h3/jXxDFCf4gcM89SCQzajjR6KZ5rTXWuS7jNq0Jb6y2IOmOFB/ VqkIcH2ErS1TiiBVfsuuIvxXgmFVNjuzJ9vYzZ6l1NXpmvWDWnqq+IpDL3jErbOs9Mx/ nDgOnCwRui3U7IhI4ebAizNHtlpqUjQImA+XKkySw2kqCErbV911fc7+dZJeBxF73Wlc SQ== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050095.ppops.net-00190b01. with ESMTP id 29fbvu885g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 28 Mar 2017 00:40:58 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v2RNUnOh027471 for ; Mon, 27 Mar 2017 19:40:57 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint4.akamai.com with ESMTP id 29fc9vg0pf-5 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Mon, 27 Mar 2017 19:40:57 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 27 Mar 2017 16:33:10 -0700 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.1178.000; Mon, 27 Mar 2017 19:33:10 -0400 From: "Salz, Rich" To: "curdle@ietf.org" Thread-Topic: Confirm consensus Thread-Index: AdKnUnz8O13D6zh8SwiFX3a3mlcq/w== Date: Mon, 27 Mar 2017 23:33:09 +0000 Message-ID: <1191c9c32dad4b989a1e37661c0f10fd@usma1ex-dag1mb1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.88] Content-Type: multipart/alternative; boundary="_000_1191c9c32dad4b989a1e37661c0f10fdusma1exdag1mb1msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-27_21:, , 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-1702020001 definitions=main-1703270187 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-27_21:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1703270187 Archived-At: Subject: [Curdle] Confirm consensus 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, 27 Mar 2017 23:41:02 -0000 --_000_1191c9c32dad4b989a1e37661c0f10fdusma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable At the meeting today, we had consensus to NOT require RSA-PSS in the SSH k= ey exchange drafts. The feeling was that it's not insecure, and people are= moving to ECC anyway. If you feel strongly that there is a need for RSA-PSS, please speak up now. -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz@jabber.at Twitter: RichSalz --_000_1191c9c32dad4b989a1e37661c0f10fdusma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

At the meeting today, we had consensus  to NOT = require RSA-PSS in the SSH key exchange drafts.  The feeling was that = it’s not insecure, and people are moving to ECC anyway.

 

If you feel strongly that there is a need for RSA-PS= S, please speak up now.

 

 

 

-- 

Senior Architect, Akamai Technologies

Member, OpenSSL Dev Team

IM: richsalz@jabber.at Twitter: RichSalz<= /p>

 

--_000_1191c9c32dad4b989a1e37661c0f10fdusma1exdag1mb1msgcorpak_-- From nobody Mon Mar 27 16:49:36 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 B122812948D for ; Mon, 27 Mar 2017 16:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, 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 eI7NNGD9gXNY for ; Mon, 27 Mar 2017 16:49:33 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::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 190EB1286B2 for ; Mon, 27 Mar 2017 16:49:33 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id y18so1463265itc.1 for ; Mon, 27 Mar 2017 16:49:33 -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=eLCq6tFfWyCCKwxUPCosyUkoh+idBwm05ywErey13pk=; b=lERdhwvuo3ovrX1Zflq2+Vc9HYjEnstWVSzeYzU7CrMlwHiAnON1xKZILqxBDqtP8G lvL+WrNyK5LL0Ei9MAabDxoFNBBzS7QLopIpZQxDJu5cMk+x6576NSx8HbHNWvcFpWTo Iowr7B39WK6OmvSPJDLGh5bxPgR/l7RbisSK9xE34AnyztgmpKEyMVkRFr95ua3hCUcc x0BbmsPgyiE8xOqx5k2GNhSbcGaV7GziL1h8ws6KqC+8GT3kONOwiH7l/8G1RM5AYq3V 3IxsvG2SMffFixGVldgw6PXzd+gfsiZGb3gR/wIUm7KxCMh+GY3bTXxtUHFIYPdJG2z8 tq9g== 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=eLCq6tFfWyCCKwxUPCosyUkoh+idBwm05ywErey13pk=; b=WV7iLcJnc1vBfzOBTiYzEsqPpki/vwxY8OYmsunkLQoKAywCod9gAfmnpKZSqvWvJ9 EPEqMM7HUuCqt2sQvLbH36xNIV2aE5PVs7MAZjqRZhp5p/8wGZoc6kcTyMxQeqm4UhNo XS2sbr2HRfpxRwqrHeSOC7hTj0T+G4JBAlqmzE+0V3fEhOChtpA3+pySkFDPHXH1HpUf NiNjRW7O5DLoVT3VbY7xU4xTts0DEaY8m4Fk5xyamWKTZ2OyHWM+NwlELqc+MeQSLZN2 Vw5DjKT4euDBYKpdBIgSZLdLwjbL0eE1+s6UZ5Z8Cu1PpxSkr/FLSTZWST6fXcoeIU4o Bsdg== X-Gm-Message-State: AFeK/H2qsfo1kquByIVrtjt1hqEUI5649ooUq/TtIu0hoXcjz8lLCuRtOmqOcZMV3M+1CXg/fb+5YCArerxRrQ== X-Received: by 10.107.174.27 with SMTP id x27mr23422566ioe.35.1490658572359; Mon, 27 Mar 2017 16:49:32 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.35.213 with HTTP; Mon, 27 Mar 2017 16:49:31 -0700 (PDT) From: Daniel Migault Date: Mon, 27 Mar 2017 18:49:31 -0500 X-Google-Sender-Auth: 2vveUH6elEYDzHsWkzyPABGnlBg Message-ID: To: curdle Content-Type: multipart/alternative; boundary=001a11449ffcb0048b054bbefe27 Archived-At: Subject: [Curdle] minutes for IETF98 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, 27 Mar 2017 23:49:35 -0000 --001a11449ffcb0048b054bbefe27 Content-Type: text/plain; charset=UTF-8 Hi, Thank you Melinda for taking the minutes[1] and Yoav for taking care of jabber. Please let us know if you have any correction to bring. Yours, Daniel [1] https://datatracker.ietf.org/doc/minutes-98-curdle/ --001a11449ffcb0048b054bbefe27 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Thank you Melinda fo= r taking the minutes[1] and Yoav for taking care of jabber.

P= lease let us know if you have any correction to bring.


You= rs,
Daniel
--001a11449ffcb0048b054bbefe27-- From nobody Mon Mar 27 22:15: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 C8015127735 for ; Mon, 27 Mar 2017 22:15: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, FREEMAIL_FROM=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 Rl3VRterxLIe for ; Mon, 27 Mar 2017 22:15:41 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::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 E7CB9126D85 for ; Mon, 27 Mar 2017 22:15:40 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id e75so44376559itd.1 for ; Mon, 27 Mar 2017 22:15:40 -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=ya9KUMRzvCi8lcNP9FNlqd+xUzz3KgrT/HhlXwPAp0Q=; b=F1cKoCzFW4zqIqF1O6GAq2VjhoD3SfPGw2H+3FE+sN11BWFdRfLyg++JdTy+lb95Ju aFmK9QKtXFr/BgI8pR0KlnbxVMJZRfjbun1aU6lMOVJXYJx/xpIWz+epgkhzQfVQk/6T LSSYYanpC/J2/ZaGGkQPWb7OGHvJFt8RjHluq8Z2qk8+AI5UrF396upS+k1uh3l9HFyq O8cpZOBJqQd67aq7IBLLkcMAOIyJG4/E8guNWEvXrkXAYcm6QDNmZ86MVEdSgS2v0cK8 G/rPw9GJ0YDa38TxhlDbO7Ut94E9PjBvwPy2x+tVgOkMLBRIPtJm6+65eI8iI8NHqIBH oK5g== 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=ya9KUMRzvCi8lcNP9FNlqd+xUzz3KgrT/HhlXwPAp0Q=; b=cajxZdErq99Sv5Xv5X2nrne/wS2ebi1G8jW3WDJxh9x85iXe2NZXnYnNgtGdbeFpaP loGWf1+9j5GlZPoKt+2kFuGfQFywrDVovzrWxBrvmmhl/j/TrVVlGyLMi7jytzKXzDEk T0gNl1z3e6mgkBN+d2XEFfoCUyROJymEY2sTYzY2m7ZrNJYgaWYKYRQp45otzjLmEBS5 YjQtkVjGSyMnuwB3KkbjUhOf6nyeY5N5ScNWHD1DKgcf9TC/ukg3wzf5OlBo3ULy6N7g EC3doiviEpnHQ6Q+knX5K8ix7fvgjBrSjS7HQKtwHuDe97MeGGQMTmqsKvmRyWkrmEmn i5EA== X-Gm-Message-State: AFeK/H29nXujZCUcY/SvBcQ0MiY577dB6HqXD+XJQI6EQ9vRWpscAg+vDug6k4dWLIp54eeNolDTZvtug+2DEQ== X-Received: by 10.107.138.206 with SMTP id c75mr25020706ioj.32.1490678140212; Mon, 27 Mar 2017 22:15:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.97.101 with HTTP; Mon, 27 Mar 2017 22:15:39 -0700 (PDT) In-Reply-To: References: From: Loganaden Velvindron Date: Tue, 28 Mar 2017 09:15:39 +0400 Message-ID: To: curdle@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Curdle] Update to RFC 4419 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, 28 Mar 2017 05:15:43 -0000 On Wed, Mar 22, 2017 at 7:08 AM, Loganaden Velvindron wrote: > On Sat, Mar 11, 2017 at 11:47 AM, Loganaden Velvindron > wrote: >> Hi All, >> >> I started working on a small update to RFC 4419, regarding minimum >> recommended bit size for k, where k is the modulus length. >> >> https://tools.ietf.org/id/draft-lvelvindron-dh-group-exchange-00.txt >> >> This reflects changes that have taken place in OpenSSH, following the logjam >> paper. >> >> https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf >> >> > > Hello, > > This small update to RFC 4419 reflects what OpenSSH is doing. In my > humble opinion, having RFCs that reflect what popular implementations > are doing tends to be a good idea. ping ? From nobody Tue Mar 28 09:54: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 1680D12944B for ; Tue, 28 Mar 2017 09:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=junipernetworks.onmicrosoft.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 il_lBCdyIFJ2 for ; Tue, 28 Mar 2017 09:54:32 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0090.outbound.protection.outlook.com [104.47.40.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 828291279EB for ; Tue, 28 Mar 2017 09:54:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RiEQseiU/SO1MDx8q7PoYut1gfd/KyOeqQSpz3z9shI=; b=SJelJLXKUl34q1rbTocmTHagc5bH9X7h6nTYkJlTY7A1kaZQH89OTTkaVghqJomCEmF5CK3ex6yoAqOxmpymfn6hl0mboF14FOJ2hFNAQp4Z6JDAiCEqbo5A3roSBMVZKGmmkXVGIx7TztSciAHUIegB5ZPC3ViHt1itSaPSt5Q= Received: from SN1PR05CA0003.namprd05.prod.outlook.com (10.163.68.141) by BN1PR05MB309.namprd05.prod.outlook.com (10.141.63.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Tue, 28 Mar 2017 16:54:31 +0000 Received: from BL2FFO11FD054.protection.gbl (2a01:111:f400:7c09::184) by SN1PR05CA0003.outlook.office365.com (2a01:111:e400:5197::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2 via Frontend Transport; Tue, 28 Mar 2017 16:54:31 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.18) 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.18 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.18) by BL2FFO11FD054.mail.protection.outlook.com (10.173.161.182) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.977.7 via Frontend Transport; Tue, 28 Mar 2017 16:54:31 +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; Tue, 28 Mar 2017 09:54:29 -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 v2SGsTUI009623; Tue, 28 Mar 2017 09:54:29 -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 B85B91144E; Tue, 28 Mar 2017 09:54:28 -0700 (PDT) To: curdle In-Reply-To: References: Comments: In-reply-to: Daniel Migault message dated "Mon, 27 Mar 2017 18:49:31 -0500." From: "Mark D. Baushke" Date: Tue, 28 Mar 2017 09:54:28 -0700 Message-ID: <30381.1490720068@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.18; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39860400002)(39450400003)(39850400002)(39410400002)(2980300002)(189002)(199003)(9170700003)(7126002)(230783001)(2810700001)(81166006)(8676002)(2906002)(105596002)(117636001)(8936002)(86362001)(106466001)(356003)(53416004)(76176999)(54356999)(50986999)(5003940100001)(48376002)(305945005)(76506005)(50466002)(189998001)(110136004)(77096006)(53936002)(5660300001)(6266002)(7696004)(38730400002)(6916009)(55016002)(2950100002)(6306002)(7846003)(47776003)(6392003)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB309; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD054; 1:SHaIZRAewx5AHtN2y97PWRiQy7dKpVePQzEPiGYUHqGPcwKoSz3QmfMHoIyZiUOtaYkDdfQZhhF/WhL8UNbtZBMr4gW+sFw3GP6+yBgZueTREwIxQW8qcY6uE1T9EBBkwfYpbYas5LVpErMj9xf68eGCADLHwxq90p/Hm6sVOxbPKND7LaVPggMSvH2N2VjNPluDaVJEZti2BXOJAzbSKCmBdg8sGs/zCxpw1+wZTI1DXz2nheNDRVROKANvARs7y4zNZB2RjnhFZbiwRdAUeMRSFYKHYchmR6QnGMnJtHDTEuOMptCy+54bwohs6VkN2CBpefYf+EQyAYrP+q5qZm2+z0qHlPPXoH3C2wcNljh+5oIshoTmalQIr/XyOIRrSiuAbgpEG5MmDF4Czq/8j/aYC4Zv6wXBDsaUmsn8KtVKx0vwwnR+RiSBmxUYGIuU4cnP1ORaKshw5pLulQgU1GOtycV77ojJbRaQpHzt0VndaYzqIFUFpx0erIiqmBkTcOQ/cNTFW6R4GKHyjyXsU4986Wie/uXmBnOrcATjXMcH68V1h5uj098XwjZhmY0+ X-MS-Office365-Filtering-Correlation-Id: 27863c2c-11fd-4254-f6e4-08d475fb1abc X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:BN1PR05MB309; X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB309; 3:nke52XtV7q4wnx24LNHrzegAPXAB+BPLzhKIEvNl4yEqXvzDdW4avMFknKaskSOYF4MUINLGjcEeEiQw+pJagSTSBUuXFaIRi1aMAIFlI6mLi/ayQD/6g1JFlkA1IzhT2kvUa+KVIKwggeSFmlii6O1n+RAwMtK3HTNRS2G7sO23crFY2B2pS9dIxdgPnE36oikMeTsaEhGElU8L+55GvX7K3zMF4qaxZ2bpgmiGgIDoi2yCGFypkXCaxFoMhSak6cjfTD43bEKUEM6tUAH/d/ICVCs+J2qi33WsCGawLIor6t7t60bl6iigKJc48LHh3WFE7+e3wFsbsPTP36YyjfAflrtCoCMTfolFNH1zus0MQtvJs3Na1oQImvuOFz+JZJm9scMbUItMNBcY46kx0g==; 25:kHcXCWk8hAy70zLn9SZTyhH3jOpcJhV5sjk/U8tuC1UcLk6BmAmA/j+8SGzarVldvCMVX3MpQMHj/uhpSEXUER6va9xK4a+aEklXJRB9sfMG932a+3abE8ABRtrAHRm2eOn7eVf96IZ36qP2gKSs3TrOMRsK8WaPK5bZcpHpDIBrkePKtTskUew66ddj34TYGbkWFu1xd+Tb4jK3PGgOmNCZ2pMtt9qq4cM7MyohUIINy1SYXAHDPejBc/eELmfidEDQobcJV/MlJTaQvNtXnpL8BvUT5lMMWUHtgi+i5KvMxZBzlGLNmBtQ2e9jRpjNC/vZ5w6HNNNroFo3MQblG2gjYRh5pLXzRSUp5+0anhTN7Qzj4DM8yT0hf7ggBMMXPB9Q9hKfgBqKhB2i1FA8U4utuW6QQ04eBsE2aQmcQFTMajqqQAW6PPGeg1fJoK7bZzO7y4Htv2fXY2FNFPz+TQ== X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB309; 31:bVZdwXhGVzC07/afoBj6Mgo09c4qASW89eoXZ4rm4HYTbNc8FK9ByPASJYc046a6YJJIWwpKarMPAZGUOVC4NXVjbk8Ti9F9KiL/HcgusDYXQr0CvjEdEKRvjNRbsmCWJvghN/QdPxC00NtyG1ROXWGKN+Xqh6iOraV7AOFLDvxttiTyvw3Pfw8MmQmQ+7kfa80vUbWYt80gF9rC46MiLpxkbKHhJQUlbM+25jRzbHjK9/aJIW4qooucgk5mxEzA3t8ayIkhplk/yqfFqi4s0OrfxGnA2G33KyH4JX9kzv8=; 20:1QUAhvvpcz4TkDqbt7OZLzFQB2hjdRGnNi51Cj3VPrnnZKU+gDOZv8aShGB5UwfH1GIiWGyQ5K6i/JsOEh9NeK5IwwKnX/xMSqO9iadKXSNpr4FTOdgYzFxzEPDGF1/1eXh54Vf0EnvKtvpNN6k42GhQvQIVgE9EXdcEbex7ZvFOJCcekwodZXBP4SP7Y5FlAq6OjK04BW+lWreJGMXgym+CrA+x+qQQ5qcuiHemiH6naJEbghm9Ljuj2FyFwaQoHZzXIw+mk0lj5MKwJEksLsc/ADGjPgIQxyipxIMGoZLRALbVCgTRjiOK+1wDURSqAuXGs/4tmr3wWCNIlWzMNhq/xsvDtQ6l+xJk7zYnAMqWioP2FeHYVhOfYN86hUsrDhMg3G7U9KyVop+WmbYFimC8U3mfispBHIFg+Vs/cjFQclwsYBTQkcDVyWw/tsHHZKTnZ7/ufVM26XgyCgdzA3zCDm03ggG7iv4YXW0+8YMAF/jBmQZGHqeORswyvhqk X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105)(192374486261705); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(13024025)(13023025)(13018025)(8121501046)(13015025)(13017025)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(20161123558025)(6072148); SRVR:BN1PR05MB309; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB309; X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB309; 4:vOk8UYd97V3ZXvWeFdHgrC0sVIA/u2KKSWvBNveaExzp2gIWxEzEhhLDffkux9ivCFodJUEQc7k3h2fDtjvNwUipfOq08FnR/hA+gBY+tvIMXek66FAPl0sszeKm0RyOqw7izTFQJ4VDSauCUlJNv/28fp9paVSfNvwKsQtO3/yTWv5EnTJA7PvPqIDPYqvY3Ttz7e+GFlxTk+/fZuLS9wdwNlAxagU4GNrX+dO9Dwamr926dZZx7f5C6EWx2Q8lswwcJ195K1WRjtuJEDpBPYcV04kTzt5hdaHuN4KSILXl7xWyRNlLK1XHuY6pC5w32jybscKpUrMgB//csHQ3ONg09TQ4hjHPc1wVdVgD+WwX/bxjmlatv8FrpTiijlRuno6oXL/FN1UQQl8iWYUTJ8le+PNmoXuR9x979u/H3MOzrkFg0p5Z5UWK/Whmeu0M6jkfQd+MKxadzUrxNaoAuIMCby/qp/FFxABNYdZJ+hRKNHzHfBxfngp9GHhMLzL2XYmynOmH0/qCFkZWRYy4W2yjgbBQWTUoX3SKP1n+LZ40mSHRM5p3eCL+tsgjYwD1HLVkXTtHLXSEfHW1A3lUsyVg2vLQre6upPiVpcjlRwwGQohnPbVFHDCOWkLw9bZVms1VQXKjD+LsWHiWl/gCV0WXQJlLD/rRVzTi2OLxaztbGBZPMHMOr8HttWCAUExxFiBVjVuNWaLdC84iUA/qZjR/iI4MRvsT2iu1j8yu0SDAE/WKDSRTlEGa1s4rc1ieOSQ2j2VtCGq9N30b8dcxZLHbtyyrF6TXEu7zbnIFDBc= X-Forefront-PRVS: 0260457E99 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1PR05MB309; 23:3zP1C6CZbYgHiOzol6Q2S4jW38lW2PisR9xD9t/siu?= =?us-ascii?Q?+xWk3nGla8RztAhup19eXKekiCn15Mk/46wZ85Ny6m9CtBSHzIkg7BNVmGlc?= =?us-ascii?Q?EjXtTRGRBRFqpes88U7+/QHlgz7kkk5Q2PinZmjWNComg7bbVBDW3Hgg6K4b?= =?us-ascii?Q?eFmNMtLG7PM0kUs85/AWkERbWJQgZlWVNj9v9j6aU3cghUE8VJNfk8yWtyWL?= =?us-ascii?Q?TiRhSoN6Q9NKWLVujMhUrhxNRqBl5GKoHMCnwv4WTPp3PfKsdrLGIfkD8t6w?= =?us-ascii?Q?in614CR0xLePKfqbGG3V9Ci0+QkqfNuTMALvDLrMhyAhTJOpSb7BeRVywRGX?= =?us-ascii?Q?6NN7T7hHVAeRlaUhKflVMqPfLp3O0IjzXVWXnB2Cx9bMGPOHjztT/RSXgnwk?= =?us-ascii?Q?FZvK4q7cpRkU4RJ+kxO2bwLAU08LUnJ4e8wPLoWXmVIfxJUp6QysRtWYzNFD?= =?us-ascii?Q?vf/ek3s0xapy1aQqWv1KJV+RvRUS31X4Zrg5K6sD2PvhR1v15hFirv8eQoYL?= =?us-ascii?Q?Ocf4ChbKde2nFEMHJsLg1Jr/mC3kFd63igEZcjA8Gefvir7Flbukb+jvixu0?= =?us-ascii?Q?MqMQmgB4EmbnPPrRxgLN1zQ6ltzwSTnbiVArIiEfurHndJf40upoAmSG6AvG?= =?us-ascii?Q?4LXqg4SQ7hAQis0ubEE00mJ70aHjZIa3wZVbUAcplUqA2yFXi119psiVBSbV?= =?us-ascii?Q?TY3MIn4tCRwXw8NrCgriLZnHr/260cZyLPhccPOl6wXY1f4Ce1zdJgO8FV04?= =?us-ascii?Q?YRipD/ScOhOuPFkTuQmahVzmTDw6xI//2v3pxHGirVfolfyi2eg0RiRA6h7B?= =?us-ascii?Q?GqpR64ncVS9q5zG3QU1sZRJd2dVbYHi9ZNvcRWo+W5zqyfNCWc7RJ98wQJrb?= =?us-ascii?Q?Zh+3ag2orvZ0v9Hh7Qukp2QqgnkYHjl5evNjx/GW5alSvqv0VMh0Dy3UIHni?= =?us-ascii?Q?Fq9eeeGt9Nk8dRTCy33wmWIcVumyf/73V8k3a9e93369A8FTRcRvYpCtiHje?= =?us-ascii?Q?x07wQJ8U6vVZYQoERJnak9hR9Km9xWL3WzLlEMb6OCWbO0fNCBCnU8/sOMkI?= =?us-ascii?Q?gN0q4gBlzMF1ijEpE8l+ZH8at7u818oBHpw5nmyBNGzbYLxJ/hHe3kaX45AO?= =?us-ascii?Q?BwySQdHZQ8TJSfRiiBNcUIohvWwjFjh/gy2AmZlEPTBI2ZSN2IZQ=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB309; 6:cElXNtWI1wwp7d3YnFhEdUzLOt3smegaDQLUNg5dBBKewiHWbfHiUFNQeNm038nZJp5pco1fTiO9ybTO66d8DmLYi7qKof/2p9geXcZmFxRRyPmEuLxYJqmPvFHn+A2t0B4W3/+45QWcKAa8l7fOC+92FgQ8fp41vXiRTLjqxcdX4mHPRNBtwwW3xd3wREAM7N3bJuZGrMw6d86GK8P2eTeKoyEr5Izx9WrazfCvdArg7uzkXByfPKDx8HQqsJhPeYrmIsYX4IVE75KSZ6ko2i8x5Xt+ca3VwwX6LcwBPqBo6A87ME0k2Gkq2pP/qUXYBq8hrpTOTS+N2yQ0QZIWx3J6tai2+smUZeCpMo8GTH+OWFf4ybTs35sHZ/ya2uJ3WAr/+ObbV9RlIdfBzSCiAp2alaHl8CZRDTu8/QM7om8=; 5:u9dZh++8RT8t2CrUZ1N/vogYynDCnLxQD/Y8D1WXdutuUNFRWj8O/bGiAyEv4hc2Y484I8liU7fZ7Pe5gFOwDJgW6bYNmymZ1ff+EMXG6O4xd1WWPi+MqOfu79mxxoubgGp2TpPwkx01VT2J5E+PFIKpTRufCh+vZr3pusnVxjA=; 24:o43pKU3d4q5b62MXtRbvQOO+tIKkfi+bZpH/zEiXi1fzCV+iwmLj2ywJ1IlYfqQ0YfRD8qEEtRRMXThYyRhnfsVwM1ULrBpUG50JWqbK+cE= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB309; 7:OISXth9lUZyhFyyvJ0JuxzIAbP7RYcF/9X0md4Q6ZfvWfRwGLNNV6pjGXqz90XRvc88PzYMIgILd3gMuOnwBJa+tiN8ZtVEkptW9qhrCOXHNUSZ0RoRmf5KPSWG/8QxZrLuoxQIPRzsuaaVa6BFDpscculpljFfkY2IeBvLaML9VvOfKIsmIMmb9RwdIXIghlOUIr0G5jzk23bez8+X8+vE7r2ilcWGPfvbQM20Rjf2QvT2L46Hbsb3S3Z9vEX7ceeu7JPXDoLDdK04Ex70xwKSFgYrW0dFFtYRMezecF/5y8Gcg6yUOxuzYkYUzMzh33TSIbIPEA+yEdwG1tKohXw== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Mar 2017 16:54:31.0355 (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.18]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB309 Archived-At: Subject: [Curdle] draft-ietf-curdle-ssh-modp-dh-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: Tue, 28 Mar 2017 16:54:35 -0000 Thank you Melinda for taking the minutes for the Curdle meeting on March 27, 2017. https://datatracker.ietf.org/doc/minutes-98-curdle/ says: > draft-ietf-curdle-ssh-modp-dh-sha2 > ============ > EKR: I'm surprised you're not using the ones we're > standardizing in TLS. Rich: we're reflecting what's in the > deployed base. DKG: Shouldn't use the same groups being > specified for TLS, although we should use defined groups > AGL: the draft is documenting reality, but why wouldn't you > want to use the same groups? DKG: the rules for generating > strong groups are well-understood, but you might not want to > use them cross-domain. These are also same groups used by > IKE. Rich: will encourage discussion on the list, we'll > pollute IKE and TLS, too. Tero: these are the groups being > used in IKE. Might be premature for last call, needs > discussion draft-ietf-curdle-ssh-modp-dh-sha2 is using RFC 3526 MODP primes based on "pi" instead of RFC7919 primes (TLS) based on "e". Group modulus security strength estimates (RFC3526) +--------+----------+---------------------+---------------------+ | Group | Modulus | Strength Estimate 1 | Strength Estimate 2 | | | +----------+----------+----------+----------+ | | | | exponent | | exponent | | | | in bits | size | in bits | size | +--------+----------+----------+----------+----------+----------+ | 14 | 2048-bit | 110 | 220- | 160 | 320- | | 15 | 3072-bit | 130 | 260- | 210 | 420- | | 16 | 4096-bit | 150 | 300- | 240 | 480- | | 17 | 6144-bit | 170 | 340- | 270 | 540- | | 18 | 8192-bit | 190 | 380- | 310 | 620- | +--------+----------+---------------------+---------------------+ as has been mentioned, the RFC3526 groups are all being used in IKE and group14 has been used in SSH since RFC4253 was first approved. RFC7919 seems to provide the following: +-------+------------+----------+----------+ | Group | Name | Modulus | Strength | | | | | Estimate | | | | | in bits | +-------+------------+----------+----------+ | 256 | ffdhe2048 | 2048-bit | 103 | | 257 | ffdhe3072 | 3072-bit | 125 | | 258 | ffdhe4096 | 4096-bit | 150 | | 259 | ffdhe6144 | 6144-bit | 175 | | 260 | ffdhe8192 | 8192-bit | 192 | +-------+------------+----------+----------- All of thee groups given above are safe primes with a generator g = 2 and q = (p-1)/2. I have no objections to adding the additional five groups to the draft if that is desirable to the Curdle WG at large. Would the following additions make everyone happy? diffie-hellman-group256-sha512 diffie-hellman-group257-sha512 diffie-hellman-group258-sha512 diffie-hellman-group259-sha512 diffie-hellman-group260-sha512 Or are there other issues to be discussed? Thank you, -- Mark From nobody Tue Mar 28 11:19: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 EC89F12947C for ; Tue, 28 Mar 2017 11:19: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 10Un_00lAVsV for ; Tue, 28 Mar 2017 11:19:49 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::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 113281294AB for ; Tue, 28 Mar 2017 11:19:49 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.20/8.16.0.20) with SMTP id v2SIHTAC004851; Tue, 28 Mar 2017 19:19:46 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=5y5OFnC05KKetN9XF6jA6On6YmZw/hcdPLPOuaFNV54=; b=CiFaFIUZjh5yfqdbFbgXjlKT+6/NV6JyqVgxTyX5QREKDJZQ/V2Y9g0fph22rVMQgJOs unQdB4qPiEGneSc2Lz2UN/mvBdqgPN4gsj/cLej+/C3o3yoX/TvRHrhp37R9IbdOi9Vm EJUjedJJe22ogm8yCLA2GtlPeOqrIUmFDYdUOiPWY95e/pHjw2r0P4sjTE3VbTJeAM48 E/2XKv8klKnRYkM9TMkrZRUKX/PUarCJTVbfd0Zmr6SjlT6nIxRrdZUBAflMPMC0woNw beX5ru4xN0KpSTpOCtaGEnTF2ERcbIuArMnp3MIHl7JjKV6BlNOO/fh6JiLnThhht10v KQ== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 29ft5mh5kx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 28 Mar 2017 19:19:46 +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 v2SIG0PS017931; Tue, 28 Mar 2017 14:19:45 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 29fsx683ge-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 28 Mar 2017 14:19:45 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 28 Mar 2017 14:19:44 -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.1178.000; Tue, 28 Mar 2017 14:19:44 -0400 From: "Salz, Rich" To: "Mark D. Baushke" , curdle Thread-Topic: [Curdle] draft-ietf-curdle-ssh-modp-dh-sha2 Thread-Index: AQHSp+P+nP9PfPofwEW8RqpLdG4Sq6Gqj89w Date: Tue, 28 Mar 2017 18:19:43 +0000 Message-ID: <6ab576118c6945f4ba888dd403cf2471@usma1ex-dag1mb1.msg.corp.akamai.com> References: <30381.1490720068@eng-mail01.juniper.net> In-Reply-To: <30381.1490720068@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.199] 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-03-28_13:, , 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-1702020001 definitions=main-1703280150 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-28_13:, , 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-1702020001 definitions=main-1703280151 Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-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: Tue, 28 Mar 2017 18:19:51 -0000 I think the in-room consensus was that since this is deployed and used in I= KE, it's okay and that no work is needed. From nobody Tue Mar 28 11:31: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 E443B1297EB for ; Tue, 28 Mar 2017 11:31:24 -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, FREEMAIL_FROM=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 jUFnAllAXi1h for ; Tue, 28 Mar 2017 11:31:23 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 722B312944B for ; Tue, 28 Mar 2017 11:31:21 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id p22so73405872qka.3 for ; Tue, 28 Mar 2017 11:31:21 -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=zrYnUNeg9Iq2yr9On7LhkOFbjOh3kRVUBrxHTJUlSD8=; b=DCnALifaeAAxRyeThzxWfSIzR1mq1DWyF7gtTREpaKvYT8Fe4mDBofbqvqjr9pn6X6 NG1fen3Z9Q7W6wiTfCQSmZ14rsOAdIjZtgXNJQQakL/lmzFW72wLq1YpZ0cxlcuCP9G0 y9Tm9Ha2CW9xa2co5ZGk7KoeTdb8lLZfHg0mMkxZ1b9U7s2/OWYmCMGeBX4bDXtii7DG WflhQqhjzvDPbMd0J9BTgAwaW/Cn2BFYD3LLp0SnmVU01dRwcelCtLOp7/ZpahY/ZuSU y+dAU3JCK6ztMuRJ4xhmqiOveecEl1vOdH1LFmBDYnsG60p48V2SGEcHRPzzv6tttoH3 MYBw== 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=zrYnUNeg9Iq2yr9On7LhkOFbjOh3kRVUBrxHTJUlSD8=; b=B0Z15hC5A3fzttoz0cYQgse2mgp3YX+aPwwDTpRyklqC88gPYJg2LT0sEVYGpMOYaP xoEeiCdlqjlcLkE0kJa8KR8IahhmolcYTieUPBBYG7kD8b48GzlKTix1SnYj00UhwFDr /q27qfTtrPXbPIfha2YluFSXCO0bPbOpMZw4kVCCSjH1OqdEiL60k0UZ/rHeZeisJWWt /0UjF3GPi8hbpegWR77fiXc4C4G9WKNkpAwe44lqShN2mFR2yOnMQ+SDkuyxNRbWTLbS 1Q7ia/lWUCvZ4jsTaLf41KjrRv/K1tgY0FkYgUOgYLaLYzIWsThsJh0FLzJo+1ULspZq XL+A== X-Gm-Message-State: AFeK/H2CTkZO4ssNcMXJk71FOXTvr5z4wbMZYdifBO01q1NlbMWZJcX6oebkGQ5+Ti5ZUzFMuv8pJci7uzAyew== X-Received: by 10.55.164.151 with SMTP id n145mr16908805qke.202.1490725880615; Tue, 28 Mar 2017 11:31:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.27.194 with HTTP; Tue, 28 Mar 2017 11:31:20 -0700 (PDT) In-Reply-To: <6ab576118c6945f4ba888dd403cf2471@usma1ex-dag1mb1.msg.corp.akamai.com> References: <30381.1490720068@eng-mail01.juniper.net> <6ab576118c6945f4ba888dd403cf2471@usma1ex-dag1mb1.msg.corp.akamai.com> From: Martin Thomson Date: Tue, 28 Mar 2017 13:31:20 -0500 Message-ID: To: "Salz, Rich" Cc: "Mark D. Baushke" , curdle Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-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: Tue, 28 Mar 2017 18:31:25 -0000 On 28 March 2017 at 13:19, Salz, Rich wrote: > I think the in-room consensus was that since this is deployed and used in IKE, it's okay and that no work is needed. I would advise against defining more options without strong justification. From nobody Tue Mar 28 11:39: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 E75DA1297CC for ; Tue, 28 Mar 2017 11:39:40 -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, FREEMAIL_FROM=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 SXfsCVSGMHOt for ; Tue, 28 Mar 2017 11:39:38 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::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 9B8E0124BFA for ; Tue, 28 Mar 2017 11:39:38 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id 190so29464785itm.0 for ; Tue, 28 Mar 2017 11:39:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Ev5YjHYsGWq6lWJEf9zoTMA1tIkbWrG3DtPAvCh3mBY=; b=jFSZoec3payejy0SG6k0PqTK9l7ZfjwhCbaRc64tr6Im5njFinUrOBXTKfsRvELsYH vGIXsVNHZYMmMBurqwQvv46ttPLPR6Lfa+Yb7Q6U0sUK3HJMmY0+ZPo+1o8yCSeh5YOv z8Cq4LVG8+fEQMSkwbQZu1lh7C8eCFwVcLDBKd1BzDg0/AeShvBp16PSDVLzsHbvHmwn PrHOO6+QOJYSyNq7hNoI84G0RRNWTgFekhtoZ+1wxoM+MRzqbEbWgpCx3PzS7og7qtEb bb0+YNMWfSn+c87PIO20ozRmY+SUm+z015oVniCVIppazTynhTdBbkqOqC1VXFJyNO7t pkJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Ev5YjHYsGWq6lWJEf9zoTMA1tIkbWrG3DtPAvCh3mBY=; b=Ji9EfgMF9GEa+UpQljIdR5cexZS4PaZ8MsOMdzJOrVIL9jIMeEeQpUi4nh23U9bniy zQDM9QAn3CKi5WsoJDtcESfYmdGlitl372usJ4uzhYMh2u7nCJPLkERuFGydQjNQrwdu 7n6LGPnUYtmTSWYiN+EzEBtoLhckUO1bIwLZsDM2dRwUBHF/KGmBhsk+eQmLohYS7gWW JQ/aAgFcH8o286GMdj/nWgDY2//Pt+u4ivjfRBgIKnBvWEQSlQIIQPhGEBZbTZYbK/oU tkaFCywqg522yUHl2HSlo1gB2tTb/RcRFj0qivrwwZWL/cM9qzDWkaXmoJN2wntvL6oG 3aUA== X-Gm-Message-State: AFeK/H2VtvuCJhGsk6KTQCkK4HRgTDGLyTpz8AQ72cloJNnP3qhy38nu0JXQ0azHhYwHww== X-Received: by 10.36.26.66 with SMTP id 63mr16370617iti.27.1490726377793; Tue, 28 Mar 2017 11:39:37 -0700 (PDT) Received: from t2001067c03700128102957629935b2b3.v6.meeting.ietf.org (t2001067c03700128102957629935b2b3.v6.meeting.ietf.org. [2001:67c:370:128:1029:5762:9935:b2b3]) by smtp.gmail.com with ESMTPSA id y203sm2321974iod.11.2017.03.28.11.39.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Mar 2017 11:39:37 -0700 (PDT) From: Yoav Nir Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_49D2FC09-DA35-4531-9540-81EB96FB9948"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 28 Mar 2017 13:39:35 -0500 In-Reply-To: <6ab576118c6945f4ba888dd403cf2471@usma1ex-dag1mb1.msg.corp.akamai.com> Cc: "Mark D. Baushke" , curdle To: Rich Salz References: <30381.1490720068@eng-mail01.juniper.net> <6ab576118c6945f4ba888dd403cf2471@usma1ex-dag1mb1.msg.corp.akamai.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-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: Tue, 28 Mar 2017 18:39:41 -0000 --Apple-Mail=_49D2FC09-DA35-4531-9540-81EB96FB9948 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii +1 Using the IKE groups is fine. Using the TLS groups is fine. No need for = new SSH groups generated in the same way. (note that I said the same when DKG proposed generating new groups for = TLS rather than use the IKE groups) > On 28 Mar 2017, at 13:19, Salz, Rich wrote: >=20 > I think the in-room consensus was that since this is deployed and used = in IKE, it's okay and that no work is needed. >=20 >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle --Apple-Mail=_49D2FC09-DA35-4531-9540-81EB96FB9948 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJY2q3oAAoJELhJCxUKWMyZ19EH/je/4SMS0pkGQb+yjSGW1vNn jqgzWDxKki5VceD5PDQ8u8q0S9kP4OZ6mqTe6iQUSfIAqAiod3LvWAIYjE8iuEcu 80Q4aEEJlDT1WzM49ugGyVMhTbHSCGJw+HgZMXxvfVBgrn97bp727kUQ6w3RQq8x dA6Id+EMOArVoqFeD7HSJQipCkz064fgjULcCmtkhiQzWwARWtHo0MLJZxtlUzqp CV/ZaYsSccs+SwojwnhHLLbuR+E/BopzmmyiFo3XksVH8rzVPQNqJ+Hx2z66cD2T dvoq/dZJIBpdB4xCmxqWCzhvFirLBVM/BJMOtOJPWjltAeM/aomzOWCTlaBTA/U= =TQSf -----END PGP SIGNATURE----- --Apple-Mail=_49D2FC09-DA35-4531-9540-81EB96FB9948-- From nobody Tue Mar 28 14:30:34 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 B91D0129416; Tue, 28 Mar 2017 14:30:28 -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.48.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149073662870.1172.6546943649324730417@ietfa.amsl.com> Date: Tue, 28 Mar 2017 14:30:28 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-pkix-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: Tue, 28 Mar 2017 21:30: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 : Algorithm Identifiers for Ed25519, Ed448, X25519 and X448 for use in the Internet X.509 Public Key Infrastructure Authors : Simon Josefsson Jim Schaad Filename : draft-ietf-curdle-pkix-04.txt Pages : 15 Date : 2017-03-28 Abstract: This document specifies algorithm identifiers and ASN.1 encoding formats for Elliptic Curve constructs using the Curve25519 and Curve448 curves. The signature algorithms covered are Ed25519 and Ed448. The key agreement algorithm covered are X25519 and X448. The encoding for Public Key, Private Key and EdDSA digital signature structures is provided. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-pkix-04 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-pkix-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-pkix-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 Tue Mar 28 14:40:42 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 12F1C126C0F for ; Tue, 28 Mar 2017 14:40:36 -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, 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 3cynSkkoPJ1W for ; Tue, 28 Mar 2017 14:40:33 -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 267C2129634 for ; Tue, 28 Mar 2017 14:40:32 -0700 (PDT) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1490737229; h=from:subject:to:date:message-id; bh=R0Hni+jE1Pc4RO2ppXQWLivLyphbW3vcAdJk92xxqJA=; b=euXRo8oSwZCjjY/n5AJmTEDaafWGEFNZ5z2Qrx4AX9DYIchx2QyjLnqylMj12TyHG1mLvwY4MB3 gT7DcQf6kMGqRlIt04kIjK9pIfEZLbnVrFR2m8+ZaPoHMh1I+qkVNXyPb0EsLK4zwvVmiot47aCke OkOZhHgeB80tOd2ja8GSb7gUBctG7GiIweF+67agJ+sjKE8zJDZvtQtJooVq7ZjzYlEjVqDAgmFkq DfdNu0V6S375//JwdGMwpLErNml7MBtL8s1CNwJZfEH8HxpJl94o3MzyZneo7x8+tfzrLn3I7XP1m XiXNJHC4mVYv+br9Gmm6rhwwpOYTtXCPwhXQ== 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; Tue, 28 Mar 2017 14:40:28 -0700 Received: from hebrews (31.133.135.244) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 28 Mar 2017 14:40:26 -0700 From: Jim Schaad To: References: <149073663013.1172.4888065212435317707.idtracker@ietfa.amsl.com> In-Reply-To: <149073663013.1172.4888065212435317707.idtracker@ietfa.amsl.com> Date: Tue, 28 Mar 2017 16:40:24 -0500 Message-ID: <051401d2a80b$e9bdea90$bd39bfb0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQEf37CDGDDCSU9BXbxVbCIypDLQd6MQV6ag X-Originating-IP: [31.133.135.244] Archived-At: Subject: [Curdle] FW: New Version Notification for draft-ietf-curdle-pkix-04.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, 28 Mar 2017 21:40:36 -0000 Here is the promised updated draft. Changes: 1. Fixed an example that David Benjamin found was wrong. (Incorrect = sign bit in public key.) 2. Remove all of the pre-hash text except to note that it does exist. 3. No changes to the OID arc being used despite the agreement during = the meeting. After the meeting, Russ, the chairs and I had a short talk = and decided that this did not need to occur. The problem was only with = getting new values assigned not with the current values which were = already assigned. That should be the final issues in the draft Jim > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Tuesday, March 28, 2017 4:31 PM > To: Jim Schaad ; Simon Josefsson > > Subject: New Version Notification for draft-ietf-curdle-pkix-04.txt >=20 >=20 > A new version of I-D, draft-ietf-curdle-pkix-04.txt has been = successfully > submitted by Jim Schaad and posted to the IETF repository. >=20 > Name: draft-ietf-curdle-pkix > Revision: 04 > Title: Algorithm Identifiers for Ed25519, Ed448, X25519 and X448 for > use in the Internet X.509 Public Key Infrastructure > Document date: 2017-03-28 > Group: curdle > Pages: 15 > URL: = https://www.ietf.org/internet-drafts/draft-ietf-curdle-pkix-04.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/ > Htmlized: https://tools.ietf.org/html/draft-ietf-curdle-pkix-04 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-curdle-pkix-04 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-curdle-pkix-04 >=20 > Abstract: > This document specifies algorithm identifiers and ASN.1 encoding > formats for Elliptic Curve constructs using the Curve25519 and > Curve448 curves. The signature algorithms covered are Ed25519 and > Ed448. The key agreement algorithm covered are X25519 and X448. = The > encoding for Public Key, Private Key and EdDSA digital signature > structures is provided. >=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 From nobody Tue Mar 28 15:44: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 5350D127B57; Tue, 28 Mar 2017 15:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ey7jtiiybL2t; Tue, 28 Mar 2017 15:43:49 -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 0D145124234; Tue, 28 Mar 2017 15:43:49 -0700 (PDT) X-AuditID: c6180641-c3fff70000000a06-42-58daa0c92dec Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by (Symantec Mail Security) with SMTP id 50.A7.02566.9C0AAD85; Tue, 28 Mar 2017 19:43:40 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0339.000; Tue, 28 Mar 2017 18:43:44 -0400 From: Daniel Migault To: Jim Schaad , "curdle@ietf.org" CC: "saag@ietf.org" , "spasm@ietf.org" , "tls@ietf.org" , IPsecME WG Thread-Topic: [Curdle] FW: New Version Notification for draft-ietf-curdle-pkix-04.txt Thread-Index: AQEf37CDGDDCSU9BXbxVbCIypDLQd6MQV6aggAAQoyA= Date: Tue, 28 Mar 2017 22:43:44 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118BB7D3A@eusaamb107.ericsson.se> References: <149073663013.1172.4888065212435317707.idtracker@ietfa.amsl.com> <051401d2a80b$e9bdea90$bd39bfb0$@augustcellars.com> In-Reply-To: <051401d2a80b$e9bdea90$bd39bfb0$@augustcellars.com> 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+NgFmpmkeLIzCtJLcpLzFFi42KZXLonQffMglsRBlf/qlhsXTiL2WL19O9s Fvu3vGCzmNLfyWQx71qyxafzXYwObB4b50xn81iy5CdTAFMUl01Kak5mWWqRvl0CV8bMva+Z CmaJV7z5MI2xgfG1UBcjB4eEgIlEU6dJFyMXh5DABkaJ3YfPsEE4yxklju+/wNTFyMnBJmAk 0Xaonx3EFhHwkbjy4AwrSBGzQAujxIorPxlBEsICYRKzZ79ngygKlzjd+ZkFwraSmLd/CyuI zSKgKnHh2XdGkM28Ar4SU954QSxrYpS4crgZbA6ngIPErca5YIsZBcQkvp9aA2YzC4hL3Hoy H8yWEBCQWLLnPDOELSrx8vE/VghbSeLj7/nsEPU6Egt2f2KDsLUlli18DVbPKyAocXLmE5YJ jKKzkIydhaRlFpKWWUhaFjCyrGLkKC0uyMlNNzLcxAiMmmMSbI47GPf2eh5iFOBgVOLhVTC5 FSHEmlhWXJl7iFGCg1lJhHf+MqAQb0piZVVqUX58UWlOavEhRmkOFiVx3nflFyKEBNITS1Kz U1MLUotgskwcnFINjOsanG9H7tCr+HAwitn45eSlPqKHWv7UhyuH2VjdcGmW6cxYespAukhA xKd0ztH7NgIdAeoLOLdfzTl4bnpTcm4jx/vHuueYL89ZMXtK9butNncZzPfo/H9RsmfHnw13 jD/lbOg4NHfRFfufv24uyFCb2m7X3fF9rk3Ywy9eb/4nm4tfr+UzmqbEUpyRaKjFXFScCAAN fttwlgIAAA== Archived-At: Subject: Re: [Curdle] FW: New Version Notification for draft-ietf-curdle-pkix-04.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, 28 Mar 2017 22:43:51 -0000 Hi,=20 Thank you Jim for the update. Here is the version resulting from the discus= sion we had during the WG meeting yesterday. Please review the document an= d provide your feed backs by April 4 so we can move the draft to the IESG.= =20 Yours,=20 Daniel -----Original Message----- From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Tuesday, March 28, 2017 4:40 PM To: curdle@ietf.org Subject: [Curdle] FW: New Version Notification for draft-ietf-curdle-pkix-0= 4.txt Here is the promised updated draft. Changes: 1. Fixed an example that David Benjamin found was wrong. (Incorrect sign = bit in public key.) 2. Remove all of the pre-hash text except to note that= it does exist. 3. No changes to the OID arc being used despite the agreement during the m= eeting. After the meeting, Russ, the chairs and I had a short talk and dec= ided that this did not need to occur. The problem was only with getting ne= w values assigned not with the current values which were already assigned. That should be the final issues in the draft Jim > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Tuesday, March 28, 2017 4:31 PM > To: Jim Schaad ; Simon Josefsson=20 > > Subject: New Version Notification for draft-ietf-curdle-pkix-04.txt >=20 >=20 > A new version of I-D, draft-ietf-curdle-pkix-04.txt has been=20 > successfully submitted by Jim Schaad and posted to the IETF repository. >=20 > Name: draft-ietf-curdle-pkix > Revision: 04 > Title: Algorithm Identifiers for Ed25519, Ed448, X25519 and X448 for > use in the Internet X.509 Public Key Infrastructure > Document date: 2017-03-28 > Group: curdle > Pages: 15 > URL: https://www.ietf.org/internet-drafts/draft-ietf-curdle-pk= ix-04.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/ > Htmlized: https://tools.ietf.org/html/draft-ietf-curdle-pkix-04 > Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-curdle-p= kix-04 > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-curdle-pki= x-04 >=20 > Abstract: > This document specifies algorithm identifiers and ASN.1 encoding > formats for Elliptic Curve constructs using the Curve25519 and > Curve448 curves. The signature algorithms covered are Ed25519 and > Ed448. The key agreement algorithm covered are X25519 and X448. The > encoding for Public Key, Private Key and EdDSA digital signature > structures is provided. >=20 >=20 >=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 > The IETF Secretariat _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle From nobody Tue Mar 28 16:09: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 A2EB0129507; Tue, 28 Mar 2017 16:09: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, 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 ujJlZA9pHeFR; Tue, 28 Mar 2017 16:09:06 -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 9BF211294E0; Tue, 28 Mar 2017 16:09:05 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.20/8.16.0.20) with SMTP id v2SN7102002475; Wed, 29 Mar 2017 00:09:04 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=1KInCOaj5PlpD+XLgJ1SFO795EHb9AifZJe00cLc5iw=; b=JlwgW/t+aDXyD4RoWNPsaUzHzLFvOMO1UZqib/HiEI8oq0hnoJ5LWbi48tvUA3Mnfdi7 XVthaJ95sO5OGwJPHkz6Ja7z0XnT3J29DElBDLHXRD0rdIIRWh359tO+yvIg1NwxPQPd g5riLHuSyCy2DJ3Yfj3P9sadRqLZOTk29QlJik+asTPH1HhFjeOcmuNElYnucUXqR501 jeIk2Pm1EtFntO8c6Q7HiIFRNRSAw6dhzdi7vdiK+Fv0QKY7uTKlC4FDjc5diCLQWSK/ Vma7dak8CfLjBYaTTwVERmf21EHVARf6/rSNR6YAeN7kBvXfsIS9SG3HFYkP54pzjVrq iw== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 29fsyu2pdq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 29 Mar 2017 00:09:04 +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 v2SN6mUN024385; Tue, 28 Mar 2017 19:09:03 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint1.akamai.com with ESMTP id 29fsutr75k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 28 Mar 2017 19:09:03 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 28 Mar 2017 16:09:02 -0700 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 28 Mar 2017 19:09:02 -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.1178.000; Tue, 28 Mar 2017 19:09:02 -0400 From: "Salz, Rich" To: "saag@ietf.org" , "curdle@ietf.org" Thread-Topic: Curdle IETF98 report to the SAAG Thread-Index: AdKoF884M4y6bNoNSXmEPLlvgi2sow== Date: Tue, 28 Mar 2017 23:09:02 +0000 Message-ID: <3bba6233b0df467d9602709f60b5ae41@usma1ex-dag1mb1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.40.81] Content-Type: multipart/alternative; boundary="_000_3bba6233b0df467d9602709f60b5ae41usma1exdag1mb1msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-28_18:, , 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-1702020001 definitions=main-1703280186 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-28_18:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1703280186 Archived-At: Subject: [Curdle] Curdle IETF98 report to the SAAG 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, 28 Mar 2017 23:09:08 -0000 --_000_3bba6233b0df467d9602709f60b5ae41usma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Curdle contains maintaining the speed record of having the highest ratio of= I-D's/WG-minute. After all, isn't that the point of ECC crypto? :) We will be moving PKIX and CMS documents to IESG review. We have resolved most of the open issues in the current drafts. We will be moving SSH drafts to WGLC. Our incoming queue is progressing nicely, quickly, smoothly. -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz@jabber.at Twitter: RichSalz --_000_3bba6233b0df467d9602709f60b5ae41usma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Curdle contains maintaining the speed record of havi= ng the highest ratio of I-D’s/WG-minute.  After all, isn’t= that the point of ECC crypto? J

 

We will be moving PKIX and CMS documents to IESG rev= iew.

We have resolved most of the open issues in the curr= ent drafts.

We will be moving SSH drafts to WGLC.

 

Our incoming queue is progressing nicely, quickly, s= moothly.

-- 

Senior Architect, Akamai Technologies

Member, OpenSSL Dev Team

IM: richsalz@jabber.at Twitter: RichSalz<= /p>

 

--_000_3bba6233b0df467d9602709f60b5ae41usma1exdag1mb1msgcorpak_-- From nobody Tue Mar 28 22:41:30 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 975C91205D3 for ; Tue, 28 Mar 2017 22:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCmDdyO3nPJx for ; Tue, 28 Mar 2017 22:41:27 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C75AF1293D8 for ; Tue, 28 Mar 2017 22:41:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1490766086; x=1522302086; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ZDvEAV4ewSF4dPjINANdBI93V4VkpFCuPfx+uS1+m8Q=; b=piA95Fzb2OgauxmmVEvNpFNQUYl96QW5AtOsc872DGtTMHq3lVmoFJDi 94dLQwmxKu1QhpBzRFXF5mJDdoip3spNQ56JOSBIk5zVSb0a13Ct2mDE6 AEcF+MzDS2SudXpZSCGCduVDKqJLHqfuVyU6znxRJXy+jDCVvtEHwPoLl /p6XAGxGeTBZce8F8ctv6tNjKhGzGhhmqGQdbQLJ0pJ40auH0wt3uAANg jgLTAq0dfIm47yia5iup0+3bxND7Vf+DRHGmcgkTITmTL09yL1u9irN7S IPTUCGk8CTSZLjl8K4jczZmQ0eKzlpIhe7FJtMKcbL9UN+QwR32OwxbNb w==; X-IronPort-AV: E=Sophos;i="5.36,239,1486378800"; d="scan'208";a="146359102" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.3 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-b.UoA.auckland.ac.nz) ([10.6.3.3]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 29 Mar 2017 18:41:15 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-b.UoA.auckland.ac.nz (10.6.3.23) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 29 Mar 2017 18:41:14 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Wed, 29 Mar 2017 18:41:14 +1300 From: Peter Gutmann To: "Salz, Rich" , "Mark D. Baushke" , curdle Thread-Topic: [Curdle] draft-ietf-curdle-ssh-modp-dh-sha2 Thread-Index: AQHSp+P9Zh0d3oAyu0685TNgkwvXXqGptgiAgAGYQ10= Date: Wed, 29 Mar 2017 05:41:14 +0000 Message-ID: <1490766071333.6018@cs.auckland.ac.nz> References: <30381.1490720068@eng-mail01.juniper.net>, <6ab576118c6945f4ba888dd403cf2471@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: <6ab576118c6945f4ba888dd403cf2471@usma1ex-dag1mb1.msg.corp.akamai.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-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, 29 Mar 2017 05:41:30 -0000 Salz, Rich writes:=0A= =0A= >I think the in-room consensus was that since this is deployed and used in= =0A= >IKE, it's okay and that no work is needed.=0A= =0A= There is one obvious counter-argument and that's diversification. The prob= lem=0A= with the DH1024 group that was pointed out in the Logjam paper is that=0A= absolutely everything ended up using it, making it an incredibly attractive= =0A= target because if you break that you break everything that uses it. Having= =0A= everything use the 3526 groups, or similar, just moves the problem to a=0A= slightly larger key size. So using known-good parameter sets that differ f= rom=0A= what everyone else is using, and in particular IKE and SSL, which are much= =0A= large targets than SSH, wouldn't be a bad idea.=0A= =0A= In -LTS, one of the suggestions I make is:=0A= =0A= If this isn't possible, an alternative option is to pre-generate a select= ion=0A= of DH parameters and choose one set at random for each new handshake, or= =0A= again roll them over from time to time from the pre-generated selection, = so=0A= that an attacker has to attack multiple sets of parameters rather than ju= st=0A= one.=0A= =0A= So one possibility would be to generate, say, 16 NUMS DH parameters for eac= h=0A= size and publish those, and have the server select one at random. This add= s=0A= security both in terms of diversifying from the IKE/SSL values that everyon= e=0A= else uses, and forcing an attacker to break all 16 parameter sets instead o= f=0A= just the one.=0A= =0A= Peter.= From nobody Tue Mar 28 23:17: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 87741129685 for ; Tue, 28 Mar 2017 23:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=junipernetworks.onmicrosoft.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 FyesvvkA24wn for ; Tue, 28 Mar 2017 23:17:44 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0118.outbound.protection.outlook.com [104.47.33.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 1E946129684 for ; Tue, 28 Mar 2017 23:17:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=izTmgr+4Q/JEmQFriG+sDAqCYtQuvPEavgBQvWMottA=; b=FyOz5qmy8dGQSLbhQEaW08VdMcNHiOoh8pwujwldyXrFyCgFlZYjMdzcuPzzbgz/3LhZq6tD8sn98WhRm4/226fRxijN05EzVog63vRdl3dyAjIVWbfvU5wapZIgMB5D1zZwxXCvVz9H1bidloxFG3PKa629pYMYT2mGSU0fIHQ= Received: from BY1PR0501CA0009.namprd05.prod.outlook.com (10.162.139.19) by BLUPR05MB1906.namprd05.prod.outlook.com (10.162.215.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Wed, 29 Mar 2017 06:17:41 +0000 Received: from BN1BFFO11FD048.protection.gbl (2a01:111:f400:7c10::1:120) by BY1PR0501CA0009.outlook.office365.com (2a01:111:e400:4821::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2 via Frontend Transport; Wed, 29 Mar 2017 06:17:40 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; akamai.com; dkim=none (message not signed) header.d=none;akamai.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.18 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.18) by BN1BFFO11FD048.mail.protection.outlook.com (10.58.145.3) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.977.7 via Frontend Transport; Wed, 29 Mar 2017 06:17:40 +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; Tue, 28 Mar 2017 23:17:38 -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 v2T6HbX3018389; Tue, 28 Mar 2017 23:17:37 -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 6B67211446; Tue, 28 Mar 2017 23:17:37 -0700 (PDT) To: Peter Gutmann CC: "Salz, Rich" , curdle In-Reply-To: <1490766071333.6018@cs.auckland.ac.nz> References: <30381.1490720068@eng-mail01.juniper.net>, <6ab576118c6945f4ba888dd403cf2471@usma1ex-dag1mb1.msg.corp.akamai.com> <1490766071333.6018@cs.auckland.ac.nz> Comments: In-reply-to: Peter Gutmann message dated "Wed, 29 Mar 2017 05:41:14 -0000." From: "Mark D. Baushke" Date: Tue, 28 Mar 2017 23:17:37 -0700 Message-ID: <57287.1490768257@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.18; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39450400003)(39840400002)(39860400002)(39400400002)(39410400002)(2980300002)(199003)(189002)(9170700003)(47776003)(7696004)(86362001)(2906002)(5003940100001)(189998001)(6916009)(2950100002)(2810700001)(5660300001)(229853002)(77096006)(6306002)(7846003)(6392003)(8936002)(81166006)(55016002)(54906002)(8676002)(105596002)(50986999)(4326008)(106466001)(305945005)(53936002)(356003)(54356999)(76176999)(7126002)(6266002)(6246003)(110136004)(38730400002)(230783001)(117636001)(76506005)(53416004)(50466002)(48376002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB1906; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11FD048; 1:TL8GSNrukOUr2n3z25THB/dV7kXz2pKc7au20RSD77v0tA+mzhJvXKKSIINj1zO/xr21fEWr2zl7KsDtAE4j9KkJ47/2ktmh+xRI0sSZS62lA/X3oatGVsrsjsa5pdqjW9Oi54p6CXAhN2wlwj+TRUrepG2gIh37r2kbN+GqM5FrlFSd+T8H0wzrvn1DFuzAI7/i11gaNHyhaGmRO6jys9c5DI4xgytRxbs+cwpNFdTCCBOdF9blZBbqbMYy+llF/pSaZ9Q1/3Ry40220q2CtlAv5KsAyxTrMNiiEAlnYAeyKtOVgIyzicuDqHb+8gRut7PM2+WrHmxq5DEOQ94WIKJsVWjgoS7P8vn0q4AFT/e11xYXo32CtbADMCqxcQGeltW1GyfoeinfJZmGb5eJXsFB/AkGfvHiVxdeoLx8qfaja7C73NbQXS2SE+9yoGUm1att92cmEH92kxFgBZUyQZmL1vypND15ZzKjHMd74d3DLYXQZ/FBCLmym33TPVV/B6nYe/7O2RM5DGk4dFFCA8ZQ44zxrJfoSPaXmFDG91lTmo+S1if3cPYDYqdQgmvumnSVCQq7P5DRdd3YLkv7Bw== X-MS-Office365-Filtering-Correlation-Id: d4901a55-dc79-4ed1-115b-08d4766b4dc9 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423072)(201703031133078)(201702281549072); SRVR:BLUPR05MB1906; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB1906; 3:bq98ZU2S8BIex++lRTFhVYV9YGWl3fAo4DkFEvC4Pgow1T3DwlRwAxV2MfGs6gYxoI1nhmCdJYpA4w/bfEIEjBBicMsBGo4vG28PzSz8XB4LxFa1NhTIlhi7uJSrIkBjaDayYXxI3ovk4yuLTdQZIO/peA+yIe31rkayx07IE0+X7UcOJRao8vELztKJ458LbpNpt+o6HBeRsIMDwTBg4OdM0WHtgmjM2klRBSPrCXY3z/kwZ6GUeSwyv31+Oeh/OUfAwBQXCepSVl5maJ4WlEwaAMFJGDJytHY+tw3UP61so0GN5PTdUmT8Nal8P5/08nacsDDvq0rDlNIlY+LFv/n9WJQF3ciCjBHDVgl3JAHFi0UdF6ujQ9WiIEQGhtXUUsyJaAShKBcnG5UNZnCDLSNhHeBaTyLrmECu+6P4L1nYc4DrbL9nc4mi1dHFKmvCDFvK3SmuSiAt4xDII+prfHB/uePuW0jq/1nXM2WE6+vj3HOlUg57rSO2tkjElsO3 X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB1906; 25:mQImDXbQxTmfwW65+bL8RYGyR93/TU+UCk5NxfGqMaCeX0n83FKhZZrHoimnjqNdEJYgdm2O+smMBBSz57l1Uo62AvE/G8qDxPx+vjRZrXgKQr+EYNGwMNhQd4s8iCwNxcmFki6Glf9WwJ5yKxPbFa19vqtD2OKTzXAxxUC4EPqyyoO+P7Z7B67+/rYNR9BkE1wuLhrABKpQKRGOWZHxjSJ+xUTFtgGPn4bLDAONPX9qhz6E4fN9BXJLCpV9tQAORmbWphh9kwDaCMBWTHUdaFB3lVLq/VIKN5bMTD6CMHYzm4ZSOI9mV9MRPRu/ac2NMW9zAFpSNR8Azlk3j0tbBLNm/sb2JNc/yrJi8C7q1+ssL2fVsUp1dbuvGmeWoSxNrd81/qQlHZnnWi8FNOts/zLnY8+ghDYhtJEZIl8i+W6E2Wlcf1uYfyIEfLK6sZvXHj0BlBn9FE1aHCz9CDH0zw==; 31:mtv5TOwOq0oCV4cHIS5g+9clU6IANsv73fY4aQhksP5ruwGlU0v26RQHz965qC/QZJD4rqfaRFSo1btVhqDdMRj7153IUnzUAoPYZWG6oiRC5YAv6hQRBCRhRWRC2ao323ObWjLrnFymPQd+I1rIOrkBKUvLdrcoztJKlDXVpWnd0UVrTEvV7DCa1/VeFlUnOXzrgBSeF7dHjsdpzSiorvIwZzZ1hObkC4aZAROv7HK6PxgcLPmbAsGtHAb7LCA3F9CWxXAXKIiBzU29ZLorclVVo1bhPbM/KwXNmfCg4ok= X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB1906; 20:Kvmk4ebWDyla9X38pHgFrdfGc+dSRAksU8LrZEdf43bfA/yF2wP+a9maKcDax2JTNm/8dNSeXssCv51ERFHKqPZxaAKEbv5iBRreEM8LZMCN9lhZseJQew7rerLKj7+Vc+ufmNIK33xzj2mL+oEYRAjRabdoBs5B/25RghHwWo0etvuShFEKVsXRx7FUjo8EMHW6FRPw7LKmTfR08usy/ayMsNOSjiX/F2S50yysaDnNugOf9nZHaW32a1VjCrLq/PNcpAtWe83l7oNeFCcaO8i0FTUcD1BdGdFCZwV4gyYJQje9ZpCPo50PZMtj5gm0lBeion3iZ1rvVXH7E0K+5Eqq0lL2QrmeT7P4cNw6dy3ENRpkD4fECSxZw9woYfGBsnkl8PWzRjiH/L8AZANEkGG6OfO/QlEss4v3dm/EG2qZqn28hv3f1Nng0KyKk8q8eyadK8BdQXwksyMxIrZd99ac+8RMsjxgzSy8TOZeAgGbfbZL/y+UdTFRSi7/IjX4 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(192374486261705); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040447)(601004)(2401047)(5005006)(13018025)(13015025)(8121501046)(13017025)(13024025)(13023025)(10201501046)(3002001)(6055026)(6041248)(20161123558025)(201703131423072)(201702281528072)(201703061421072)(201703061406071)(20161123555025)(20161123564025)(20161123560025)(20161123562025)(6072148); SRVR:BLUPR05MB1906; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB1906; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB1906; 4:Pu2mt1VKYWD07XOaY+DHorbXrBfazZ3wfHbYXNcfEWEWWCp+o3b2egse7WM+JuCBVy3/MaQP1z2jxDhPU/16TOt3cFGkTci1VslT4RHnbT0aKR1+ODxL48OUcbjVcts9qicM31IMNPNj+kdu3Jxq/0CAFveRM0IoXjDC7t2PFm6r0uHGYXF+KsmPMyT5S7u6t074WHtvZVD03qrlEAZOgPHWCkKctDrHSJ1jhSx0I5hf01dsJxUH/N/sQphep7djeAjroPqlzFuSiOFxl7zAncx6dTQpulSPCh8MdOG2WAnKKcXFSopnmudNq+kA7a/PqjGgSoAx1vDF6dwV1KV8gpMUs1s0IMLeZBMbR1Ar6TPlB69Ajhf4XQyc0d7wYW8V/kfKF2CWVMl7l8lewr2CUQI8PVuMq055WqB//gx3YfKa+kD5+TwHEKBWfAWWWMZwzxiCqZRz97Ej0wj23n0V53ZAl0q7CZP3KNH3kFTgs6YyVe60s8k2V9pShkIK75IJQGn1qTSbdeG2yNzzojP52m9MCwQiTL+6EF3ctCOpLoax7mKq4A2D8CRNsPAO1I+jC4UuKxbr6V2uLyTodcn8q0QauVFBJUbUWz66wllYd8u3nnJhIAUm4TTx8EiV0CMPS8oWaEb4Jqc0GA7nUMhISC0caMI1ogVab6SXICHCDwbJfM5n9g6D8JgFpO9jL5a0i2xeXGg+oau2T+oljw/KYGDm9wKP48nUxd/wEDXZCpy5ZxemBw1fFp0SIq8v0PcIIT46N2nO4hBxlG9Z1L69JJezfagBze7QG9f99mIbVV5Jej8cNi5/QJsUSewhwtwRvoiIjwlUCmX8mfAl9t9NdxWom5us7WrE/Fg8H9Hrs87iIJChY0JhtfIxXlWcR9P8Gvir7CHsBkOQKld3HsUPvvtaVb6v46zcKkC6XW/QHWLnWzaRsdPlTlmKRZd7AW3b X-Forefront-PRVS: 0261CCEEDF X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR05MB1906; 23:tdF65sQPguUMU4bFeVlDhQxbi06mtaAT56PxR+fkW?= =?us-ascii?Q?z8bZgdHhRidclCtAsOl3am0/Oyj5KdLhMwm5tV70V+ywZ7p1eoEC/WN6813z?= =?us-ascii?Q?cP9qWyN77yQevUZNV8XlumDWsvdPm2ZxOkewAjuf81ft7pJn5FWAbLA2Ex2o?= =?us-ascii?Q?r/Y/Tmnus91JAl7Zt/l8gPxeiIjbVVKH8Ob1+56fPKo6utzU0CiMqKzidrNc?= =?us-ascii?Q?AAe7ySklsjdfQeqWDWc+hyihJ43Gg8peDcpJq994mTM7tmAw2+IwcSTw/Ez2?= =?us-ascii?Q?FxbJNAEc0QvpYtPtu9e6h7BRyBUeQg1txxDOn7492MsF93YjQmXjCbIXWA9e?= =?us-ascii?Q?w89oVQqMvPwxlKhHwxAGPxAkUSaERbj8jHbm/Y/JzsN9xdNrInHfS//gub6e?= =?us-ascii?Q?bImWjneAODTjrlAgCpuFgCwhKkZxin/hT0V7KZVT8m0zgSAoOWGZWEKIsY2S?= =?us-ascii?Q?OLE1DhndyOf5fXNPHjM9X3Ud20NaGy5y0dhAe880KBJSW5EXqeakHeOIHOza?= =?us-ascii?Q?7Z1GarGd+hANwQnG8aSrzM6nadsNv1398Ts3Ge/cC8Za6Hm0XwCXVKUtJnTd?= =?us-ascii?Q?aTfZyi0FkETg7wIsY8RVWh5ww5GkvjlaZrTByj4zg+RWSKmsjp/ocjgHPyCE?= =?us-ascii?Q?LrPnSIfnUJYDAkiyqSblD/a4XlYwHKDZ1On5h46vPdeM4fOJu7W+HT485sok?= =?us-ascii?Q?pXsqjKTpxYjgCRtS+ssc4tHX9KyFQfsttpp63KopjwZeWTp81AlsO00Bt+2z?= =?us-ascii?Q?OzQjeC7BxjLQMs40dtzAdVPI2EEbNJ9fkTBLEYuhPGgRQMDn4Kf/LK7K3O7f?= =?us-ascii?Q?LC6KX9jz6/nvwr2PP2sUSyCODQJUPLbx9+9c+tD6qWmxeJW+d3FyAkZHvdni?= =?us-ascii?Q?H862kcf7Qlkw25PNI53E2NTPyzqYHDZQXKTM4eUj/feFG6xP6CDQAYopi/7L?= =?us-ascii?Q?R7BQ7dil2+7FppsNDPJOxhAk7Z7uzOrkyQs10vNKOodlE13kp2b4Rxbmc0jA?= =?us-ascii?Q?xtKlOt0/NMmzvtUN7DBH1DpG+ApvQO3lunPqMCaOk0b9AiTYOnnQ9L9A2prp?= =?us-ascii?Q?M+HYEFQckifciGQAHDTck6oUkfabNTExyLGbRjPDwgXzNF3Et59yV2pEV1/T?= =?us-ascii?Q?25VPIKmuobq8jiI+ckebSCMNSN96LOFkD65h/848zVR2wmXUVohmlUeR9nnb?= =?us-ascii?Q?aTvMONmmMjSbi/0uReYtXmdDOt9mMm1EqgHMusydaPY4vwToEWMjbSCD/xgw?= =?us-ascii?Q?h92R2ezLu0NUBhKeUgudG5W2/MCe0kp81+NXv3y?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB1906; 6:F5Ldy78EdtqWThMsf/cS68kxdnAY2327phyh5iAWg5/IfcSroos9ISq8FMRo6HFJo/A8xtJuoLyYIlqXNfwJMNZDgco9NikNkwgOy7LiYxcnED0EUGcC/HJ3rgaS72IN4Y5/bowVrGuXjsOi+ASRMK6BLQK7GzOieRUneB19zo0vIMzwiAvCSC1xBnjT5zq6+iayeBZKpMLBCnG+/0N6tYuMm6YtlaDW+gDC5Hdf0HGqvmr55YgMoIAuKNNN1jwR9BtRBQCy7EI1xKjGP7s4VlJp0zmyRQ9FBs3qOCeY0gGrUS0sMJo4FOwy96442915CcSdvhiqI3dhp5glNbHqMsqu8ELfqiFEwWk6crgNhsO5Vr53ci1QpB776wVJMOKCwDcZjpsit4JAwG2EoZDWC1GwLTtYMI9lOBYvgtoYa60=; 5:BzUhPjN+w4n/OKU8/w31uM0HXKUbtbB3qWbRVVXMEU0HSWmQiarHnDKXaddnyqTaUx2vKmNr2hgmusQ17hgOOwjBm1WkyGqEtK6/JSBKmifp7a0XotGetW3KEH/LqWGoyaHwLlMkQO51iLQaKdi3GA==; 24:3qeNMIEYCePA7tZUslg61sFUbFqydMqinoCmjpwXGFY7SjOFRsJOdZO1YlraRIw4olywoQ3r/0wt4Ub4BaqKPeX6GeazVOjqyDnKpidjd58= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB1906; 7:meyUe4BHWNPnuRGa8zEYz90Sd7UO6oR/xFwbW+wGs2DAVebg/uZc0zP8r+dUAZDFsaF/z19RXDiQYzkelI1buXKJDK90o96hAtHVkInmxHWk8SYRpnpUkmNuiudAkkQHVfxCRCvMheJ6wJIDFYSeofTqhbr1aa4uH2D+LX2RDbDOea7JwGUW/n0v8O+K7j89ums/8DZFZw7A3uNR7E7+dP0NnFo/AP1arSgIrSNGr4bzy3oyAh2iJoBa8Ha4eSpnn7DSzaDOiZi7RJxjSOIvLte798eEs/e6Bp1mGKdWRehFIlFknsQPjVyNtTUBqnv/nnkjnrb9j/RDs5SiQfsFDg== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Mar 2017 06:17:40.1095 (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.18]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB1906 Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-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, 29 Mar 2017 06:17:50 -0000 Hi Peter, Peter Gutmann writes: > Salz, Rich writes: > > There is one obvious counter-argument and that's diversification. The > problem with the DH1024 group that was pointed out in the Logjam paper > is that absolutely everything ended up using it, making it an > incredibly attractive target because if you break that you break > everything that uses it. Having everything use the 3526 groups, or > similar, just moves the problem to a slightly larger key size. So > using known-good parameter sets that differ from what everyone else is > using, and in particular IKE and SSL, which are much large targets > than SSH, wouldn't be a bad idea. This is probably the argument which led to the creation of RFC4419. Of course, there is also the possibility of a dishonest or subverted server which is using a backdoor DH: How to Backdoor Diffie-Hellman David Wong, NCC Group, June 2016 URL: https://eprint.iacr.org/2016/644.pdf > In -LTS, one of the suggestions I make is: > > If this isn't possible, an alternative option is to pre-generate a > selection of DH parameters and choose one set at random for each new > handshake, or again roll them over from time to time from the > pre-generated selection, so that an attacker has to attack multiple > sets of parameters rather than just one. > > So one possibility would be to generate, say, 16 NUMS DH parameters > for each size and publish those, and have the server select one at > random. This adds security both in terms of diversifying from the > IKE/SSL values that everyone else uses, and forcing an attacker to > break all 16 parameter sets instead of just the one. Another possibility would be pre-generate a number of provable primes that are NOT safe primes and pass {FSeed,vPseed, Qseed, Pgen_counter, Qgen_counter, g, Q, P} from the server to the client to prove to the client that P and Q are primes and then commence the key exchange. The benefit of safe primes is that q (a Sophie Germain Prime) has a very large cyclic subgroup. The downside is that there are not as many safe primes in the number space as there are primes. While I do not know of a method to attack this weakness, it is something about the structure of safe primes that makes me wonder sometimes. Using a q prime with an order that is roughly half of p is still plenty large enough for slowing down a sieve and would also still be a bit harder to break in a Post-Quantum Computer universe even if it does not have as large an order as a sophie germain prime. Given the provable prime parameters, the client could verify the primality of q and p and that g is a proper generator for the q-ordered subgroup. Especially if g is chosen to be 2... :-) In this way the client will be able to avoid using a backdoor DH. Would a Draft RFC dealing with the creation of such provable primes be something that is useful to the Curdle WG? Is it likely that something like this would be adopted by more than just SSH? -- Mark From nobody Wed Mar 29 00:11: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 0818F129666 for ; Wed, 29 Mar 2017 00:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZaon6pwXYdj for ; Wed, 29 Mar 2017 00:11:44 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C91FC129677 for ; Wed, 29 Mar 2017 00:11:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1490771503; x=1522307503; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/mL3xqSbZtMrll0ZpNrAttMp4w0mc5UiX3hWrcn/7m4=; b=nQ6QaYHyhSI0QUwUKwBSwch37y8oELljAlLGobG5ZaQ6Qdk55nUWuQyD KRzy6qZbTSgWg8dCPNXxsKyQEvTZbbBJnzV/QvImsooljox+4Sey+6m34 HBw7OdYHC8IJRRoAt00dZO5vPogqZNFWU5fJ4DVnH2GLgJi6dfhhtV2MX 7aXKqzmOHi2NuoU7jMsBe8oNhONF/UN94iLfSc0oc0vphwVqpXtSMLAA2 YkXrQ4aXcoo4uk1B2obIE6QwTvgRICRGFwT8fm4mTSJ3l983M3e2/Tjiv N1ayr80IGYeHxoAlSGv4rHgES4FyXnTagCcUj2zlnQUuVGPp5pzLd1eBu g==; X-IronPort-AV: E=Sophos;i="5.36,240,1486378800"; d="scan'208";a="146368814" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.2 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-a.UoA.auckland.ac.nz) ([10.6.3.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 29 Mar 2017 20:11:25 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-a.UoA.auckland.ac.nz (10.6.3.2) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 29 Mar 2017 20:11:25 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Wed, 29 Mar 2017 20:11:24 +1300 From: Peter Gutmann To: "Mark D. Baushke" CC: "Salz, Rich" , curdle Thread-Topic: [Curdle] draft-ietf-curdle-ssh-modp-dh-sha2 Thread-Index: AQHSqFQvvMzLgbWgOUKICwAKgZV7EKGrZcGX Date: Wed, 29 Mar 2017 07:11:24 +0000 Message-ID: <1490771481840.11723@cs.auckland.ac.nz> References: <30381.1490720068@eng-mail01.juniper.net>, <6ab576118c6945f4ba888dd403cf2471@usma1ex-dag1mb1.msg.corp.akamai.com> <1490766071333.6018@cs.auckland.ac.nz>, <57287.1490768257@eng-mail01.juniper.net> In-Reply-To: <57287.1490768257@eng-mail01.juniper.net> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-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, 29 Mar 2017 07:11:46 -0000 Mark D. Baushke writes:=0A= =0A= >Another possibility would be pre-generate a number of provable primes that= =0A= >are NOT safe primes and pass {FSeed,vPseed, Qseed, Pgen_counter,=0A= >Qgen_counter, g, Q, P} from the server to the client to prove to the clien= t=0A= >that P and Q are primes and then commence the key exchange.=0A= =0A= That would require both a change in the SSH protocol and for everyone to=0A= implement the full FIPS 186 / Shawe-Taylor algorithms, which seems unlikely= .=0A= The point of NUMS values is that anyone can verify them, not that everyone= =0A= should have to implement the code to verify them. =0A= =0A= You do however need to get one or more people to actually verify them. Unt= il=0A= I asked about this a few years ago and Henrick Hellstr=F6m (who probably do= esn't=0A= work for the NSA or CIA :-) kindly obliged by running the tests, I don't kn= ow=0A= if anyone else had ever independently verified the values in RFC 2409 and 3= 526=0A= (someone may have, but if they did they didn't publish the fact).=0A= =0A= I would go for the most generic form, safe prime, g =3D 2, and generation f= rom=0A= some NUMS seed in a manner that doesn't require implementing an exotic=0A= algorithm for verification.=0A= =0A= (And we can debate whether "2^2048 - 2^1984 + {[2^1918 * e] + 560316 } * 2^= 64=0A= - 1 + kitchen_sink - pink_flamingo + speed_of_light_in_a_glass_of_milk"=0A= qualifies as NUMS or not).=0A= =0A= >Would a Draft RFC dealing with the creation of such provable primes be=0A= >something that is useful to the Curdle WG?=0A= =0A= This came up a while back and but fizzled out based on an inability to agre= e=0A= on how NUMS the generation method should be. So I'd say there's interest, = but=0A= we'd need to sort out how to do the NUMS in a manner that everyone would fi= nd=0A= comfortable.=0A= =0A= Also, I'm not sure whether you're proposing publishing a HOWTO or the value= s=0A= themselves, but what's needed isn't so much a discussion of how to do it, i= t's=0A= for someone to actually do it in a NUMS manner and publish the results.=0A= =0A= >Is it likely that something like this would be adopted by more than just S= SH?=0A= =0A= Uhh, that's kinda missing the point, you want values that *won't* be adopte= d=0A= by everything else out there. Unless you compartmentalised and said "these= =0A= values are for SSH, these are for SSL, these are for IKE, these are for=0A= everything else". I certainly don't want my SSH keyex to become collateral= =0A= damage in some government agency that really just set out to break IKE, or= =0A= VoIP, or SSL.=0A= =0A= Peter.=0A= From nobody Wed Mar 29 03:22: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 821B5129457 for ; Wed, 29 Mar 2017 03:22:25 -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 MjIzqhbfI4yE for ; Wed, 29 Mar 2017 03:22:23 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::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 6B381127B5A for ; Wed, 29 Mar 2017 03:22:22 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id 190so50108546itm.0 for ; Wed, 29 Mar 2017 03:22:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=tuKtTqUomDk2aKi+LoaDXa2ir2RSvIMQ3RQT8Xp4yn0=; b=V3rAbj0tRjqx7XrjNK5MZK5tQ+LelpAu3EMpYHj/cUqmcKDl/KK9r6PA5UYT8LZRuN D/7wtw7DFt8tYQwE2iBGseVNiA/dLlhXHx3SbVWa1WiK2mqm2kEwFnpcm7Dv7VHcwlZV /jPIItY6CCzyh6Awew4jz/twAI9YDznUU4TgiDdJXzofwtFwCbAu2ZgC8+o9zJvukpTI EhAHJBmciiKxJtr+Z07ER/9pPzV2Bq5pFx0N+E9JqSB3DTkyRhD2udV5e5E4XJlvNBbg utXsoU7W+lQe6e0ldHrU7jYsM2BQf9/D3D4IUbLQXM3o9fmrxAt6gM7d6Gv2NHcOykFV baoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=tuKtTqUomDk2aKi+LoaDXa2ir2RSvIMQ3RQT8Xp4yn0=; b=UXZphPG0lUBDrtl1rQkiKKxEtVo5Alsix+dDvWVwSTe6NH+bOiBDS/gM2QqhbJ3Y5Y LwISug7wv0O7MTXncROM67TLDGBMaN1HByuwla7PBwDtspiBYJ6MFTdjn4UTSlLAcoHO 8PS14vgB4F16mQLuhe6PAHzcDnsCp3xpEXGWxUocYmZM/xN1FYIb2yssIEPghTq3HCs+ 0XqHEe2CBh6ufYRPlDORkCNQc1Z72mVRBCK20+iqfr/Q+4prhreO/hD9O+hUK9rj7Uww O/t/u7KCM71wzQboAfb1sViCEV1x02pK3I4C2mTHohAcKPDjcMCB9quQwxk1agtllthU dHJQ== X-Gm-Message-State: AFeK/H1LdOppZpx+8SHDn4dWUd+nzu0rijpTkpKuxjlF3zYGIl3mQI0u6bfjnsGEOnLsAw== X-Received: by 10.107.46.136 with SMTP id u8mr30509818iou.85.1490782941662; Wed, 29 Mar 2017 03:22:21 -0700 (PDT) Received: from ?IPv6:2001:67c:1233::c4b3:243c:586:515a? ([2001:67c:1233:0:c4b3:243c:586:515a]) by smtp.gmail.com with ESMTPSA id d12sm3503899iog.41.2017.03.29.03.22.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Mar 2017 03:22:20 -0700 (PDT) From: Yoav Nir Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_CF42D076-3497-41F1-B692-B8F9BE5174AF"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 29 Mar 2017 05:22:18 -0500 In-Reply-To: <1490766071333.6018@cs.auckland.ac.nz> Cc: Rich Salz , "Mark D. Baushke" , curdle To: Peter Gutmann References: <30381.1490720068@eng-mail01.juniper.net> <6ab576118c6945f4ba888dd403cf2471@usma1ex-dag1mb1.msg.corp.akamai.com> <1490766071333.6018@cs.auckland.ac.nz> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-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, 29 Mar 2017 10:22:25 -0000 --Apple-Mail=_CF42D076-3497-41F1-B692-B8F9BE5174AF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 29 Mar 2017, at 0:41, Peter Gutmann = wrote: >=20 > Salz, Rich writes: >=20 >> I think the in-room consensus was that since this is deployed and = used in >> IKE, it's okay and that no work is needed. >=20 > There is one obvious counter-argument and that's diversification. The = problem > with the DH1024 group that was pointed out in the Logjam paper is that > absolutely everything ended up using it, making it an incredibly = attractive > target because if you break that you break everything that uses it. = Having > everything use the 3526 groups, or similar, just moves the problem to = a > slightly larger key size. So using known-good parameter sets that = differ from > what everyone else is using, and in particular IKE and SSL, which are = much > large targets than SSH, wouldn't be a bad idea. I think =E2=80=9Cjust breaking all SSL=E2=80=9D, =E2=80=9Cjust breaking = all VPN=E2=80=9D, and =E2=80=9Cjust breaking all SSH=E2=80=9D are each = an attractive enough goal all on its own. We got so much riding on these numbers that by now there=E2=80=99s = little point in not piling on some more. Of course it should be noted that the SSL numbers are barely in use. The = RFC is rather recent and everybody has moved on to ECC. So breaking = DKG=E2=80=99s numbers won=E2=80=99t =E2=80=9Cbreak all of SSL=E2=80=9D. = The IKE ones are very much in use. Yoav --Apple-Mail=_CF42D076-3497-41F1-B692-B8F9BE5174AF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJY24rbAAoJELhJCxUKWMyZxlUH/3z3yZ3EjiavtAp96hfNhbuU uxQxbmk5XkYi6AGd4Kd38r/8jtyp9LViB/AIAa+BMw428u8zS9e8foeIEuqoXGzs gYqLVOGfKvRaL9T1y9rxjOgNyAtMELSDCGdZPZtV2z6uHtrps/LKVcfPwMndzQz+ velRKKNPOmGRaZlWprbYdltklC4FVNz/67RFORMt+cHATsEWmtWVzytGuhes2hqt 2oPvNSR43QKRDmh4X6eFBWGv9GNj+gCjLhtfAzV1wpFw9cGEMEJQYWS4iLMLBCt9 /wh4HWfSpY0hxhbUWT5sWKNZ3awUbjq6bvuYU8A73sP542SXDLN4VbocucyIJOw= =LdD/ -----END PGP SIGNATURE----- --Apple-Mail=_CF42D076-3497-41F1-B692-B8F9BE5174AF-- From nobody Wed Mar 29 07:48: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 530C1126DD9 for ; Wed, 29 Mar 2017 07:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.699 X-Spam-Level: X-Spam-Status: No, score=-3.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, 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 LUVgbRgGr6Ri for ; Wed, 29 Mar 2017 07:48:43 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::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 E0949128ACA for ; Wed, 29 Mar 2017 07:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v2TEmdm0008679 for ; Wed, 29 Mar 2017 16:48:39 +0200 (CEST) Received: from mail-it0-f43.google.com (mail-it0-f43.google.com [209.85.214.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vtVxz3mspzDHqb for ; Wed, 29 Mar 2017 16:48:39 +0200 (CEST) Received: by mail-it0-f43.google.com with SMTP id e75so94970817itd.1 for ; Wed, 29 Mar 2017 07:48:39 -0700 (PDT) X-Gm-Message-State: AFeK/H3MCuEcMCA7eMrBczTFPX3Stc747EBKl9aV4zERrH00BT7RK20PV2qwir3AJqUF5uFfrGwCKXoiIUfqAg== X-Received: by 10.36.17.210 with SMTP id 201mr1658336itf.84.1490798917953; Wed, 29 Mar 2017 07:48:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.136.6 with HTTP; Wed, 29 Mar 2017 07:47:57 -0700 (PDT) From: Klaus Hartke Date: Wed, 29 Mar 2017 16:47:57 +0200 X-Gmail-Original-Message-ID: Message-ID: To: curdle@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Curdle] Comments on draft-ietf-curdle-pkix-04 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, 29 Mar 2017 14:48:45 -0000 A few comments/questions: * OIDs for HashEdDSA. I didn't follow the entire discussion, so this might have already been brought up. I see two use cases outside the X.509 Public Key Infrastructure where it might be useful to have OIDs for HashEdDSA: - Using SubjectPublicKeyInfo as an interchange format for public keys. RFC 7250 [1] does this, for example. - Using SubjectPublicKeyInfo and OneAsymmetricKey as a storage format for public and private keys. I'm not sure how important the first case is, but I'm interested in the second case: With the id-Ed25519ph OID gone, I now have to choose between inventing my own storage format for Ed25519ph keys, using the id-Ed25519 OID for both Ed25519 and Ed25519ph keys, or using the id-Ed25519ph OID in the hope that it isn't allocated for something else in the future. * OneAsymmetricKey. I think having only one way to encode a SubjectPublicKeyInfo is a very good idea. In my implementation, I do not even have an ASN.1 parser for SubjectPublicKeyInfos, because I can simply concatenate a pre-computed prefix with the public key bytes, e.g., 0x30, 0x2A, 0x30, 0x05, 0x06, 0x03, 0x2B, 0x65, 0x70, 0x03, 0x21, 0x00, followed by the 32 bytes of an Ed25519 public key. Could the same be done for OneAsymmetricKey? (version MUST be v1 and both attributes and publicKey MUST NOT be present) If not: - Does anyone have test vectors for valid and invalid OneAsymmetricKeys that include all possible encodings of all possible combinations of optional items? - Is it OK to simply ignore anything after privateKey or does an implementation, e.g., have to check if publicKey is actually the correct public key for privateKey? * Small typo in section 7: encoded key as defined in [RFC7748] and [RFC8032]. public key. ^^^^^^^^^^^ Klaus [1] https://tools.ietf.org/html/rfc7250 From nobody Wed Mar 29 08:26: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 41AB912941A; Wed, 29 Mar 2017 08:26:47 -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, 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 y3Y9iSSILgap; Wed, 29 Mar 2017 08:26:45 -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 89DD5126DC2; Wed, 29 Mar 2017 08:26:41 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1490801194; h=from:subject:to:date:message-id; bh=zfANmNJnFe9TdBw+FgVlf3lK+1PUKf8bCyhfsloGM30=; b=WnnexW4c2JBrBYuOi7uS94GxCLCgRHfhAnt1AsAfuYVAPKyeiu25/v6qAScdtGYSpXexslNkfPJ eJGnrwDVSf1UEj/0F4pQzDFQUFzCIznQcxwPNw0hVSXSop0LvieT/Ne3UKM7Fa3OS9wGHssF183AG nKHUA6+j6WgykvTetTaWa3YoImUUmCMiP+qHSWtwnQJQ1bL/C8InRnzJuqlY0ZAU2fUZM9vvhWaYK cmFZPtfutd0QY2zgwm7Amv5iykBqrTAXTi++y2r6vkxk0A7zyYQ7oTLUdsjsWUNbwHyjQwEDIXsKy 3Cghr2yokrQysdNpflr6Vzn6pT5WK+kk7klg== 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; Wed, 29 Mar 2017 08:26:34 -0700 Received: from hebrews (31.133.135.244) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 29 Mar 2017 08:26:33 -0700 From: Jim Schaad To: CC: Date: Wed, 29 Mar 2017 10:26:32 -0500 Message-ID: <059001d2a8a0$da207680$8e616380$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdKokxxO2cfh4aL8Tx2cBfTIJudH4g== X-Originating-IP: [31.133.135.244] Archived-At: Subject: [Curdle] Review of draft-ietf-curdle-cms-ecdh-new-curves-02 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, 29 Mar 2017 15:26:47 -0000 Major 1. The reference [CURVE] does not exist in the draft 2. I would like to see the ZERO check raised from a MAY to a SHOULD. This is a concern that needs to be addressed to be sure that the recipient key is not of small order. If the sender uses a small group key, then that is their fault. Not a hill I would die on. 3. In section 2 - note that the 32-bit number is encoded in network by order. This can be inferred from the example but being explicit is always good. 4. Section 6 is incorrect for the X25519 and X448 curves. Minor: Section 2 - s/describe/described/ Jim From nobody Wed Mar 29 08:45:38 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 64B801292C5 for ; Wed, 29 Mar 2017 08:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LsgzDV4xqzKr for ; Wed, 29 Mar 2017 08:45:33 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.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 590A1129415 for ; Wed, 29 Mar 2017 08:45:33 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v2TFiw3V023127 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 29 Mar 2017 18:44:58 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v2TFivYU023785; Wed, 29 Mar 2017 18:44:57 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22747.54905.670599.560304@fireball.acr.fi> Date: Wed, 29 Mar 2017 18:44:57 +0300 From: Tero Kivinen To: Peter Gutmann Cc: "Salz\, Rich" , "Mark D. Baushke" , curdle In-Reply-To: <1490766071333.6018@cs.auckland.ac.nz> References: <30381.1490720068@eng-mail01.juniper.net> <6ab576118c6945f4ba888dd403cf2471@usma1ex-dag1mb1.msg.corp.akamai.com> <1490766071333.6018@cs.auckland.ac.nz> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 16 min X-Total-Time: 15 min Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-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, 29 Mar 2017 15:45:36 -0000 Peter Gutmann writes: > Salz, Rich writes: > There is one obvious counter-argument and that's diversification. The problem > with the DH1024 group that was pointed out in the Logjam paper is that > absolutely everything ended up using it, making it an incredibly attractive > target because if you break that you break everything that uses it. Having > everything use the 3526 groups, or similar, just moves the problem to a > slightly larger key size. So using known-good parameter sets that differ from > what everyone else is using, and in particular IKE and SSL, which are much > large targets than SSH, wouldn't be a bad idea. Using different group than IKE will add one bit of security. If the attacker can break DH group of size n, he can easily break two of such groups. The only proper protection there is to use keys long enough that they cannot be broken. Security by obscurity does not work (i.e., claiming that SSH with different DH groups is safer because no body bothers attacking SSH is just security by obscurity). So use proper 2048 bit group, do not try to get away using shorter non-standard group. > In -LTS, one of the suggestions I make is: > > If this isn't possible, an alternative option is to pre-generate a selection > of DH parameters and choose one set at random for each new handshake, or > again roll them over from time to time from the pre-generated selection, so > that an attacker has to attack multiple sets of parameters rather than just > one. Random generated groups are much worse than using one well known group with proper length. It takes several minutes or hours to properly verify the group was is actually prime (if you actually do the elliptic curve primality proofs). If you just trust the probabilistic, then even that is too slow to do when new connection comes in. And you should not just assume the group generated by the other end is safe... Also those tests still do not tell you whether this group is backdoored or not. Only way to know that group is not backdoored, is to know how it is was generated. Of course if you are working in the closed environment and actually know how to generate safe groups, and generate them properly and distribute them using some out of band mechanism to all devices, then you are fine, but that is not normal use of SSH (or IKE, or TLS). > So one possibility would be to generate, say, 16 NUMS DH parameters for each > size and publish those, and have the server select one at random. This adds > security both in terms of diversifying from the IKE/SSL values that everyone > else uses, and forcing an attacker to break all 16 parameter sets instead of > just the one. Using 16 different Diffie-Hellman groups adds 4 bits of security. Moving from 1024-bit to 2048-bit DH groups adds 30 bits of security to the pre-computation step (10^9 times harder [1]). And this is provided that both of the groups are not trapdoored, but for group given to you by the other end you cannot be sure about that... So use properly generated groups with proper length, and do not accept groups you do not know... [1] https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf page 11, section 5 2nd column, line 9. -- kivinen@iki.fi From nobody Wed Mar 29 08:50:30 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 4B1231296DF; Wed, 29 Mar 2017 08:50:29 -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, 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 1wYOoqZs8_Je; Wed, 29 Mar 2017 08:50:25 -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 C530F129801; Wed, 29 Mar 2017 08:50:16 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1490802613; h=from:subject:to:date:message-id; bh=Osn+IZPTVxr92LI5QnpPl3dO7ZTqTRBhcpyJrGOouko=; b=EClBLD/y+sU3fIciU2Pqqo35KrqQE9RxJV5HD9DBy6W97BIUI5A/e9u2xPITFyJh2p1WoeTmUuZ CNxxLbW6K0lDm+kx23Nrkc9SNN7WaHvTPPudWgwrtCT7iQgh52NCYbWGVLrSp+qTzcclyiQRdJpVm t3nwcTcDD6t/fD0PJeKpw3SH0lZZ+0vL6FSg+9QAhjFAO1J+CvG7kMfH8pBeq1phHU5k8XEFClOgk 5x/QpmDiR+uyRJwOHErVWGwY1FHca0r7QbrI21F6mgoO6BzqDg0gJwwuxK4r5wB1ohj0hLbf7guBI Rv2Pr0Ntpv+3vCa1EFJpY/oH5W/5gNTXjOHA== 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; Wed, 29 Mar 2017 08:50:12 -0700 Received: from hebrews (31.133.135.244) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 29 Mar 2017 08:50:11 -0700 From: Jim Schaad To: CC: Date: Wed, 29 Mar 2017 10:50:09 -0500 Message-ID: <059e01d2a8a4$270b2370$75216a50$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdKooQK6SrMlzY7yRbmsJmAmLbc8jg== X-Originating-IP: [31.133.135.244] Archived-At: Subject: [Curdle] Review of draft-ietf-curdle-cms-eddsa-signatures-03 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, 29 Mar 2017 15:50:29 -0000 Section 3.1 - I would like to have a brief discussion on the integer value that is being used with the id-shake256-len OID when it is being used as a digest algorithm. The value of 512 means that the signature security is going to be the same as is currently setup for Ed25519. To have the same dynamic as Ed25519 does, this should be 448*2 so that after birthday attacks the same size of value would be provided. Section 4 - I thing that it should also be highlighted that this is a greater problem for when using the Signed-data without signed attributes as the value signed is more constrained in the other case. Jim From nobody Wed Mar 29 09:08:59 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 08073129443 for ; Wed, 29 Mar 2017 09:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYSRhYOL16WW for ; Wed, 29 Mar 2017 09:08:56 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.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 453E7127201 for ; Wed, 29 Mar 2017 09:08:56 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v2TG8hIu021299 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 29 Mar 2017 19:08:43 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v2TG8hn5023940; Wed, 29 Mar 2017 19:08:43 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <22747.56331.274710.114550@fireball.acr.fi> Date: Wed, 29 Mar 2017 19:08:43 +0300 From: Tero Kivinen To: Peter Gutmann Cc: "Mark D. Baushke" , "Salz\, Rich" , curdle In-Reply-To: <1490771481840.11723@cs.auckland.ac.nz> References: <30381.1490720068@eng-mail01.juniper.net> <6ab576118c6945f4ba888dd403cf2471@usma1ex-dag1mb1.msg.corp.akamai.com> <1490766071333.6018@cs.auckland.ac.nz> <57287.1490768257@eng-mail01.juniper.net> <1490771481840.11723@cs.auckland.ac.nz> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 7 min X-Total-Time: 20 min Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-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, 29 Mar 2017 16:08:58 -0000 Peter Gutmann writes: > You do however need to get one or more people to actually verify them= . Until > I asked about this a few years ago and Henrick Hellstr=F6m (who proba= bly doesn't > work for the NSA or CIA :-) kindly obliged by running the tests, I do= n't know > if anyone else had ever independently verified the values in RFC 2409= and 3526 > (someone may have, but if they did they didn't publish the fact). I did verify the RFC 2409 primes (768, 1024, and 1536 bit groups) when I generated the RFC3526. I do not know if anybody else has verified the RFC3526 primes. I did verify the RFC 7919 groups in Honolulu IETF, and there was even typo in the draft at that point: https://www.ietf.org/mail-archive/web/tls/current/msg15716.html I also have page having primality proofs for the IKE and TLS groups on my web page: https://kivinen.iki.fi/primes/ > Uhh, that's kinda missing the point, you want values that *won't* be = adopted > by everything else out there. Unless you compartmentalised and said = "these > values are for SSH, these are for SSL, these are for IKE, these are f= or > everything else". I certainly don't want my SSH keyex to become coll= ateral > damage in some government agency that really just set out to break IK= E, or > VoIP, or SSL. Actually breaking SSH is much more useful than breaking IKE or TLS. The first time the adminstrator types sudo and his root password inside his ssh connection, the stored SSH stream comes very valuable for the attacker... Breaking IKE and TLS will most likely just give some boring email text from the IETF mailing lists :-) --=20 kivinen@iki.fi From nobody Wed Mar 29 10:10:30 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 4DE3C129447 for ; Wed, 29 Mar 2017 10:10:29 -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, RP_MATCHES_RCVD=-0.001, 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=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 6EnYklI4_Y13 for ; Wed, 29 Mar 2017 10:10:27 -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 47690128D8B for ; Wed, 29 Mar 2017 10:10:27 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1490807416; h=from:subject:to:date:message-id; bh=iub89GbwGSP8UCQKRxnUe+CgPSnzsG9mBTvl0aaVaVQ=; b=Q8v4J4+33fH5OLJezutwana3ama+/cHzl10ZMXUFNfPvMUY42b5k7vqQ7QcNia6zlFfUxUe4ZRy fLafmghB0Krp1no6ftdI6uf3VDWxP0ev+cjoUY1Rmtgz1ZYl3ck181PujqY7UIojaCDl/hBq3JAtL Tlw1d9T3Ar0kn0ljBKjrN4O2TOWHm6UQBAHM2IGNL2GBWqvWGofSdP3wshnILz8UJcGB+2L1qJ5gd HnAboX4/ENhJXeUYzTbdtQ6gFNfcGMaDZyRcNbYjGR5dqn1/P9SgLf0389EXrDnWiXplm5Pua/7w9 ItNSeDpb3lz/kS7Ae2XafTV84+imi4sMVnWw== 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; Wed, 29 Mar 2017 10:10:15 -0700 Received: from hebrews (31.133.135.244) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 29 Mar 2017 10:10:14 -0700 From: Jim Schaad To: 'Klaus Hartke' , References: In-Reply-To: Date: Wed, 29 Mar 2017 12:10:11 -0500 Message-ID: <05ab01d2a8af$556548d0$002fda70$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIvE1DQhZYCJB38i0ZS0+uyXl1La6DzLMTg X-Originating-IP: [31.133.135.244] Archived-At: Subject: Re: [Curdle] Comments on draft-ietf-curdle-pkix-04 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, 29 Mar 2017 17:10:29 -0000 > -----Original Message----- > From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Klaus Hartke > Sent: Wednesday, March 29, 2017 9:48 AM > To: curdle@ietf.org > Subject: [Curdle] Comments on draft-ietf-curdle-pkix-04 > > A few comments/questions: > > > * OIDs for HashEdDSA. > > I didn't follow the entire discussion, so this might have already been brought > up. I see two use cases outside the X.509 Public Key Infrastructure where it > might be useful to have OIDs for HashEdDSA: > > - Using SubjectPublicKeyInfo as an interchange format for public keys. > RFC 7250 [1] does this, for example. > > - Using SubjectPublicKeyInfo and OneAsymmetricKey as a storage format for > public and private keys. > > I'm not sure how important the first case is, but I'm interested in the second > case: With the id-Ed25519ph OID gone, I now have to choose between > inventing my own storage format for Ed25519ph keys, using the > id-Ed25519 OID for both Ed25519 and Ed25519ph keys, or using the id- > Ed25519ph OID in the hope that it isn't allocated for something else in the > future. The OID assignment does not really go away, we are just choosing not to document them here. It could be done as part of a separate document, however the reasons that were discussed for not doing it in this document should still be considered in terms of do you really need these algorithms. > > > * OneAsymmetricKey. > > I think having only one way to encode a SubjectPublicKeyInfo is a very good > idea. In my implementation, I do not even have an ASN.1 parser for > SubjectPublicKeyInfos, because I can simply concatenate a pre-computed > prefix with the public key bytes, e.g., > > 0x30, 0x2A, 0x30, 0x05, 0x06, 0x03, 0x2B, 0x65, > 0x70, 0x03, 0x21, 0x00, > > followed by the 32 bytes of an Ed25519 public key. > > Could the same be done for OneAsymmetricKey? (version MUST be v1 and > both attributes and publicKey MUST NOT be present) This is going to be the normal situation. However, there are some circumstances where the additional fields are useful. > > If not: > > - Does anyone have test vectors for valid and invalid OneAsymmetricKeys that > include all possible encodings of all possible combinations of optional items? I don't know of any such thing - and an exhaustive set could not be created as the attributes are themselves open ended. > > - Is it OK to simply ignore anything after privateKey or does an > implementation, e.g., have to check if publicKey is actually the correct public > key for privateKey? Normally, one will just ignore the public key and compute it oneself. There are some circumstances where devices need to have this field delivered. Normally it can just be ignored. > > > * Small typo in section 7: > > encoded key as defined in [RFC7748] and [RFC8032]. public key. > ^^^^^^^^^^^ Thanks - fixed. Jim > > Klaus > > [1] https://tools.ietf.org/html/rfc7250 > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Wed Mar 29 10:31:46 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 86752129453 for ; Wed, 29 Mar 2017 10:31:45 -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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFpOCOcXrA-e for ; Wed, 29 Mar 2017 10:31:43 -0700 (PDT) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e: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 4839F129449 for ; Wed, 29 Mar 2017 10:31:43 -0700 (PDT) Received: by mail-pg0-x231.google.com with SMTP id 21so14089169pgg.1 for ; Wed, 29 Mar 2017 10:31:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:from:date:message-id:subject:to; bh=xW5JRt5eHWOVpZlkXMUZASgWNXEUaR8yrjYWNTV7rg0=; b=D3UI8HFYqEytD4Ss32tJu4ktidmVVn/+TziZaBhpxtoKsIQpAGD+hqjWzoAAGJvlA2 7+Vf6FVeUzxduBFKb2vEDn5olXIzkFY3xkl8BQOiQdKhSYIDaEeZvvPCQ7YALKctpGON 0mJh/4SexX3kqgeEVSQ7W64sarpAF7KiJjPZA= 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=xW5JRt5eHWOVpZlkXMUZASgWNXEUaR8yrjYWNTV7rg0=; b=mw6Ofl+eXmnJsUFBIFrTYcYHabUnp5UKE+wUFtWA8ewnoUKI2uLo1Ou+gJrhFJxYa0 ZnSejRszboSeecFNAh8GX7FN7niEf7F1tw+aG1otVrfbv+80yz2PXkVwKDpxNI20aAu2 +FkwWpoRHVectT/ucan+uZoLyoT9jyVsne0n+au1vFfbjRM01vBhk0t7RYDagX3LdtPm MvLngVYKBYEZidx8Fon64cC1oM9LrzOC6BaGe/ne8ebLSSM5E4djMsPpKdNFI7cejli2 Jr8eIpRx8ZAbacta/lC4L0Xx0gT33uL/ceLSoiKKMNKBgZu9cVstGpJ1BiBdLot4249Q fWbQ== X-Gm-Message-State: AFeK/H3mZYKNbyYbkAaGLZRe+YM5MDBMntQHbYYiDsI9J8sj+5Uqh0pXkoH0MBkiPVQMx3JGH8JqMj4O79YdhgTV X-Received: by 10.84.217.2 with SMTP id o2mr1919824pli.51.1490808702547; Wed, 29 Mar 2017 10:31:42 -0700 (PDT) MIME-Version: 1.0 From: David Benjamin Date: Wed, 29 Mar 2017 17:31:31 +0000 Message-ID: To: curdle Content-Type: multipart/alternative; boundary=94eb2c19fe1424f8f0054be1f3e6 Archived-At: Subject: [Curdle] Review of draft-ietf-curdle-pkix-04 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, 29 Mar 2017 17:31:45 -0000 --94eb2c19fe1424f8f0054be1f3e6 Content-Type: text/plain; charset=UTF-8 Overall, the document looks good to me. I've actually just implemented it along with the TLS bits in BoringSSL and our Go testing implementation. Seems to work. (Though I haven't done anything with the signature yet, just parsing out keys. Our X.509 story is a little funny since Chrome currently uses OS verifiers.) I have a handful of comments. They are all entirely editorial and mostly nitpicks. In section 3, The same algorithm identifiers are used for identifying a public key, identifying a private key and identifying a signature (for the four EdDSA related OIDs). Additional encoding information is provided below for each of these locations. "four EdDSA related OIDs" should now be "two EdDSA related OIDs" In section 4, o subjectPublicKey contains the byte stream of the public key. While the encoded public keys for the current algorithms are all an even number of octets, future curves could change that. I would suggest replacing the last sentence with "For the algorithms defined in this document, the encoded public keys are an even number of octets." If future curves do something funny, they'll be defined with independent OIDs and won't be bound by any explanatory notes in this document. In section 5, If the keyUsage extension is present in a certificate that indicates id-X25119 or id-X448 in SubjectPublicKeyInfo, then the following MUST be present: "id-X25119" should be "id-X25519". Also, a exceedingly nitpicky nitpick: the various lists of keyUsage values are all indented differently. I'm not sure if this is an artifact of some centering thing or a formatting error. In section 7, For the keys defined in this document, the private key is always an opaque byte sequence. The ASN.1 type CurvePrivateKey is defined in this document to hold the byte sequence. Thus when encoding a OneAsymmetricKey object, the private key is wrapped in an CurvePrivateKey object and wrapped by the OCTET STRING of the 'privateKey' field. The 'privateKey' field is described with single quotes, but in the following paragraph, the "privateKey", "privateKeyAlgorithm", and "publicKey" fields are described with double quotes. In section 8, When the curve is known, use a more specific string. For the id- EdDSA25519 value use the string "Ed25519". For id-EdDSA448 use "Ed448". In keeping with its own advice and to match the names in section 3, "id-EdDSA25519" should be "id-Ed25519" and "id-EdDSA448" should be "id-Ed448". The names also show up elsewhere in the document and should match. In section 10.2, The OIDs in the sample certificate are referred to as "EdDSA 25519 signature algorithm" and "ECDH 25519 key agreement", contradicting the document's own advice on human-readable names. David --94eb2c19fe1424f8f0054be1f3e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Overall, the document looks good to me. I've actu= ally just implemented it along with the TLS bits in BoringSSL and our Go te= sting implementation. Seems to work. (Though I haven't done anything wi= th the signature yet, just parsing out keys. Our X.509 story is a little fu= nny since Chrome currently uses OS verifiers.)

I h= ave a handful of comments. They are all entirely editorial and mostly nitpi= cks.

In section 3,

=C2=A0= =C2=A0The same algorithm identifiers are used for identifying a public key= ,
=C2=A0 =C2=A0identifying a private key and identifying a signat= ure (for the four
=C2=A0 =C2=A0EdDSA related OIDs).=C2=A0 Additio= nal encoding information is provided
=C2=A0 =C2=A0below for each = of these locations.

"four EdDSA related OIDs&= quot; should now be "two EdDSA related OIDs"

=
In section 4,

=C2=A0 =C2=A0o =C2=A0subjectPub= licKey contains the byte stream of the public key.
=C2=A0 =C2=A0 = =C2=A0 While the encoded public keys for the current algorithms are all
=C2=A0 =C2=A0 =C2=A0 an even number of octets, future curves could c= hange that.

I would suggest replacing the last sen= tence with "For the algorithms defined in this document, the encoded p= ublic keys are an even number of octets." If future curves do somethin= g funny, they'll be defined with independent OIDs and won't be boun= d by any explanatory notes in this document.

In se= ction 5,

=C2=A0 =C2=A0If the keyUsage extension is= present in a certificate that indicates
=C2=A0 =C2=A0id-X25119 o= r id-X448 in SubjectPublicKeyInfo, then the following MUST
=C2=A0= =C2=A0be present:

"id-X25119" should be= "id-X25519".

Also, a exceedingly nitpic= ky nitpick: the various lists of keyUsage values are all indented different= ly. I'm not sure if this is an artifact of some centering thing or a fo= rmatting error.

In section 7,

=
=C2=A0 =C2=A0For the keys defined in this document, the private key is= always an
=C2=A0 =C2=A0opaque byte sequence.=C2=A0 The ASN.1 typ= e CurvePrivateKey is defined in
=C2=A0 =C2=A0this document to hol= d the byte sequence.=C2=A0 Thus when encoding a
=C2=A0 =C2=A0OneA= symmetricKey object, the private key is wrapped in an
=C2=A0 =C2= =A0CurvePrivateKey object and wrapped by the OCTET STRING of the
= =C2=A0 =C2=A0'privateKey' field.

The '= privateKey' field is described with single quotes, but in the following= paragraph, the "privateKey", "privateKeyAlgorithm", an= d "publicKey" fields are described with double quotes.
=
In section 8,

=C2=A0 =C2=A0When the= curve is known, use a more specific string.=C2=A0 For the id-
= =C2=A0 =C2=A0EdDSA25519 value use the string "Ed25519".=C2=A0 For= id-EdDSA448 use
=C2=A0 =C2=A0"Ed448".

In keeping with its own advice and to match the names in section 3= , "id-EdDSA25519" should be "id-Ed25519" and "id-E= dDSA448" should be "id-Ed448".=C2=A0 The names also show up = elsewhere in the document and should match.

In sec= tion 10.2,

The OIDs in the sample certificate are = referred to as "EdDSA 25519 signature algorithm" and "ECDH 2= 5519 key agreement", contradicting the document's own advice on hu= man-readable names.

David
--94eb2c19fe1424f8f0054be1f3e6-- From nobody Wed Mar 29 10:33: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 E6B77127843 for ; Wed, 29 Mar 2017 10:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tLA_PmAlsV6j for ; Wed, 29 Mar 2017 10:33:46 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDE6E1272E1 for ; Wed, 29 Mar 2017 10:33:45 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id i5so10753833pfc.2 for ; Wed, 29 Mar 2017 10:33:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=D9AgzHu6/HPEuVG6MpQpLtsUkFhmFgTuqdyw8SWtP7s=; b=gfOtSChDa8MkXJ9WpUmQbUVeKOhuXGMds1B5I7E0uZH08LLAf8y9FfE3jDacjkiEhy DXuZxmDk66+9XY669fv9Zp2ld0t2g/KYZlJ9EIAIz41E12MOwSCflVVZqlrnYJm4QUkk p2i1wQomW77Xm5hcCudSaEoKYa7ik+XMuzGgQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=D9AgzHu6/HPEuVG6MpQpLtsUkFhmFgTuqdyw8SWtP7s=; b=VKLNAcVlAzA30hQAII060r7DyIrRklToNzdqbuM8tKbMdgW7MMQ0EmTkw1QQFqcKWo /DFJ52DYps68OUZbXY+Cbkh8e8GuSM0akAkZA5KTTRBVGmUhxVSd9uh8C2qdwHHhvQku KgHEgxjpt8VBUkejwImHKwVONFe8rsqA1J041yh3MEYnMR+OaldSuJcVKC3qI8niRmw2 EflsQ8fFqtgVW/2w86x4nEIeaaE88BZsrgGorGmAYsZnohq41tlkFUcEk01SW9FuZRLN r9l18U8DVOE+GVv/Lr6BNAlxSqKV2nZHBoOsApYidQg8xAd5yVSuEGfGbhuiRLfMI6Ih 9RrA== X-Gm-Message-State: AFeK/H0MKwKVeD5HfPs1hhnUAEb4W3GpPF+mbd0088E7spbLw7fiWPY0pAJ5dqlO+In+27bV4IMf0q/+V8+4wFqn X-Received: by 10.98.11.70 with SMTP id t67mr1681870pfi.259.1490808825177; Wed, 29 Mar 2017 10:33:45 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Wed, 29 Mar 2017 17:33:34 +0000 Message-ID: To: curdle Content-Type: multipart/alternative; boundary=001a1145b8107440e9054be1fa7c Archived-At: Subject: Re: [Curdle] Review of draft-ietf-curdle-pkix-04 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, 29 Mar 2017 17:33:48 -0000 --001a1145b8107440e9054be1fa7c Content-Type: text/plain; charset=UTF-8 On Wed, Mar 29, 2017 at 12:31 PM David Benjamin wrote: > Overall, the document looks good to me. I've actually just implemented it > along with the TLS bits in BoringSSL and our Go testing implementation. > Seems to work. (Though I haven't done anything with the signature yet, just > parsing out keys. Our X.509 story is a little funny since Chrome currently > uses OS verifiers.) > > I have a handful of comments. They are all entirely editorial and mostly > nitpicks. > > In section 3, > > The same algorithm identifiers are used for identifying a public key, > identifying a private key and identifying a signature (for the four > EdDSA related OIDs). Additional encoding information is provided > below for each of these locations. > > "four EdDSA related OIDs" should now be "two EdDSA related OIDs" > > In section 4, > > o subjectPublicKey contains the byte stream of the public key. > While the encoded public keys for the current algorithms are all > an even number of octets, future curves could change that. > > I would suggest replacing the last sentence with "For the algorithms > defined in this document, the encoded public keys are an even number of > octets." If future curves do something funny, they'll be defined with > independent OIDs and won't be bound by any explanatory notes in this > document. > > In section 5, > > If the keyUsage extension is present in a certificate that indicates > id-X25119 or id-X448 in SubjectPublicKeyInfo, then the following MUST > be present: > > "id-X25119" should be "id-X25519". > > Also, a exceedingly nitpicky nitpick: the various lists of keyUsage values > are all indented differently. I'm not sure if this is an artifact of some > centering thing or a formatting error. > > In section 7, > > For the keys defined in this document, the private key is always an > opaque byte sequence. The ASN.1 type CurvePrivateKey is defined in > this document to hold the byte sequence. Thus when encoding a > OneAsymmetricKey object, the private key is wrapped in an > CurvePrivateKey object and wrapped by the OCTET STRING of the > 'privateKey' field. > > The 'privateKey' field is described with single quotes, but in the > following paragraph, the "privateKey", "privateKeyAlgorithm", and > "publicKey" fields are described with double quotes. > > In section 8, > > When the curve is known, use a more specific string. For the id- > EdDSA25519 value use the string "Ed25519". For id-EdDSA448 use > "Ed448". > > In keeping with its own advice and to match the names in section 3, > "id-EdDSA25519" should be "id-Ed25519" and "id-EdDSA448" should be > "id-Ed448". The names also show up elsewhere in the document and should > match. > Er, by "the names", I meant "id-EdDSA25519". That is, there are other instances which should be switched too. (Actually "id-Ed25519" only shows up once, but I think that is a better name.) > In section 10.2, > > The OIDs in the sample certificate are referred to as "EdDSA 25519 > signature algorithm" and "ECDH 25519 key agreement", contradicting the > document's own advice on human-readable names. > > David > --001a1145b8107440e9054be1fa7c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 29= , 2017 at 12:31 PM David Benjamin <davidben@chromium.org> wrote:
Overall= , the document looks good to me. I've actually just implemented it alon= g with the TLS bits in BoringSSL and our Go testing implementation. Seems t= o work. (Though I haven't done anything with the signature yet, just pa= rsing out keys. Our X.509 story is a little funny since Chrome currently us= es OS verifiers.)

I have a handful of comments. They are all enti= rely editorial and mostly nitpicks.

In section 3,

=C2= =A0 =C2=A0The same algorithm identifiers are used for identifying a public = key,
=C2=A0 =C2=A0identifying a private key a= nd identifying a signature (for the four
=C2= =A0 =C2=A0EdDSA related OIDs).=C2=A0 Additional encoding information is pro= vided
=C2=A0 =C2=A0below for each of these lo= cations.

"four EdDSA related OIDs" should now be "= two EdDSA related OIDs"

In section 4,

=C2=A0 =C2= =A0o =C2=A0subjectPublicKey contains the byte stream of the public key.
=C2=A0 =C2=A0 =C2=A0 While the encoded public ke= ys for the current algorithms are all
=C2=A0 = =C2=A0 =C2=A0 an even number of octets, future curves could change that.

I would suggest replacing the last sentence with "For the algo= rithms defined in this document, the encoded public keys are an even number= of octets." If future curves do something funny, they'll be defin= ed with independent OIDs and won't be bound by any explanatory notes in= this document.

In section 5,

=C2=A0 =C2=A0If the keyUs= age extension is present in a certificate that indicates
=C2=A0 =C2=A0id-X25119 or id-X448 in SubjectPublicKeyInfo, then= the following MUST
=C2=A0 =C2=A0be present:<= /div>

"id-X25119" should be "id-X25519".

= Also, a exceedingly nitpicky nitpick: the various lists of keyUsage values = are all indented differently. I'm not sure if this is an artifact of so= me centering thing or a formatting error.
In section 7,

=C2=A0 =C2=A0For the keys defined in this document, the private key is alw= ays an
=C2=A0 =C2=A0opaque byte sequence.=C2= =A0 The ASN.1 type CurvePrivateKey is defined in
=C2=A0 =C2=A0this document to hold the byte sequence.=C2=A0 Thus when e= ncoding a
=C2=A0 =C2=A0OneAsymmetricKey objec= t, the private key is wrapped in an
=C2=A0 = =C2=A0CurvePrivateKey object and wrapped by the OCTET STRING of the
=C2=A0 =C2=A0'privateKey' field.

T= he 'privateKey' field is described with single quotes, but in the f= ollowing paragraph, the "privateKey", "privateKeyAlgorithm&q= uot;, and "publicKey" fields are described with double quotes.

In section 8,

=C2=A0 =C2=A0When the curve is known, use a= more specific string.=C2=A0 For the id-
=C2= =A0 =C2=A0EdDSA25519 value use the string "Ed25519".=C2=A0 For id= -EdDSA448 use
=C2=A0 =C2=A0"Ed448".=

In keeping with its own advice and to match the names in section= 3, "id-EdDSA25519" should be "id-Ed25519" and "id= -EdDSA448" should be "id-Ed448".=C2=A0 The names also show u= p elsewhere in the document and should match.
=
Er, by "the names", I meant "id-EdDSA25519&qu= ot;. That is, there are other instances which should be switched too. (Actu= ally "id-Ed25519" only shows up once, but I think that is a bette= r name.)
=C2=A0
In section 10.2,

The OIDs in the sample certificate are referred to as "EdDSA 25519 si= gnature algorithm" and "ECDH 25519 key agreement", contradic= ting the document's own advice on human-readable names.

David
<= /div> --001a1145b8107440e9054be1fa7c-- From nobody Wed Mar 29 10:40: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 90EC5129459 for ; Wed, 29 Mar 2017 10:40:20 -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 Tjdsj8a4i6-w for ; Wed, 29 Mar 2017 10:40:15 -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 6417D1279EB for ; Wed, 29 Mar 2017 10:40:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id BC8F3300267 for ; Wed, 29 Mar 2017 13:40:14 -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 Ol4n0R76P9zv for ; Wed, 29 Mar 2017 13:40:13 -0400 (EDT) Received: from dhcp-8696.meeting.ietf.org (dhcp-8696.meeting.ietf.org [31.133.134.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 668F83001A6; Wed, 29 Mar 2017 13:40:13 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Russ Housley In-Reply-To: <059001d2a8a0$da207680$8e616380$@augustcellars.com> Date: Wed, 29 Mar 2017 13:40:12 -0400 Cc: curdle Content-Transfer-Encoding: quoted-printable Message-Id: <96562891-0B33-448B-9E07-92775A4B2A88@vigilsec.com> References: <059001d2a8a0$da207680$8e616380$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Curdle] Review of draft-ietf-curdle-cms-ecdh-new-curves-02 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, 29 Mar 2017 17:40:21 -0000 Jim: > Major > 1. The reference [CURVE] does not exist in the draft s/[CURVE]/[CURVES] > 2. I would like to see the ZERO check raised from a MAY to a SHOULD. = This > is a concern that needs to be addressed to be sure that the recipient = key is > not of small order. If the sender uses a small group key, then that = is > their fault. Not a hill I would die on. I am following the guidance in Section 7 of [CURVES]: Protocol designers using Diffie-Hellman over the curves defined in this document must not assume "contributory behaviour". Specially, contributory behaviour means that both parties' private keys contribute to the resulting shared key. Since curve25519 and curve448 have cofactors of 8 and 4 (respectively), an input point of small order will eliminate any contribution from the other party's private key. This situation can be detected by checking for the all- zero output, which implementations MAY do, as specified in Section 6. However, a large number of existing implementations do not do this. I am willing to do with SHOULD. What do others think? > 3. In section 2 - note that the 32-bit number is encoded in network = by > order. This can be inferred from the example but being explicit is = always > good. I think this is the text you are talking about: To generate a key-encryption key, generates one or more KM blocks, = with the counter starting at 0x00000001, and incrementing the counter for = each subsequent KM block until enough material has been generated. The = 32-bit counter is represented in network byte order. The KM blocks are concatenated left to right to produce the pairwise key-encryption = key, KEK: Let me know if you meant something else. > 4. Section 6 is incorrect for the X25519 and X448 curves. Right. This needs simple point to draft-ietf-curdle-pkix for the = details: RFC 5280 [PROFILE] specifies the profile for using X.509 Certificates = in Internet applications. A recipient static public key is needed for = X25519 or X448, and the originator obtains that public key from the = recipient's certificate. The conventions for carrying X25519 and X448 public = keys are specified in [ID.curdle-pkix]. > Minor: > Section 2 - s/describe/described/ Fixed. Thanks for your review. Russ From nobody Wed Mar 29 11:04:00 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 30730127843 for ; Wed, 29 Mar 2017 11:03:58 -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, RP_MATCHES_RCVD=-0.001, 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=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 WkqrL6h2XmR6 for ; Wed, 29 Mar 2017 11:03:56 -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 24DAF128708 for ; Wed, 29 Mar 2017 11:03:56 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1490810630; h=from:subject:to:date:message-id; bh=Gt/LoxcveCX5dyHCWkMAX47zOxgXWEXS8LBahX6pyQU=; b=OcVQQv1Gy86nTAD8a0oPzOCAkXfvfdC2nnlTDdoI0bd2fIY9qA5c+eE88oJrlRAQicD+IbZpYnV HciHg4XAUnVct7W0lEcJ8YCVYYRQ3cbhTeKOBnRE1t5PbpWU8qxivKxI/TVVDfPim/XtdaMdGX4fM IdcXGjm9Y3oHGsQ8+UjWHwb/HDQ7XBJLqYvac0z8WRmaUh2Cgco91Kz/nMRLYphC9U5mdCLYiYl4o AmobuOqtoc1Fxl2h4W5gWz0c6rVOk7+SXB+snJkj6271TlUi+CzW9ArUoDbJDxaVr8mmrtaDQItlX 0mfzStnCBvXXMLxeqkKsSu/pjLw7yxMFDKNQ== 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; Wed, 29 Mar 2017 11:03:50 -0700 Received: from hebrews (31.133.135.244) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 29 Mar 2017 11:03:49 -0700 From: Jim Schaad To: 'Russ Housley' CC: 'curdle' References: <059001d2a8a0$da207680$8e616380$@augustcellars.com> <96562891-0B33-448B-9E07-92775A4B2A88@vigilsec.com> In-Reply-To: <96562891-0B33-448B-9E07-92775A4B2A88@vigilsec.com> Date: Wed, 29 Mar 2017 13:03:47 -0500 Message-ID: <05d701d2a8b6$d1895bc0$749c1340$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQK+/lEg1O2wj0RZ+DnsJKgoTDcvyQJXm9c9n8Cz0bA= X-Originating-IP: [31.133.135.244] Archived-At: Subject: Re: [Curdle] Review of draft-ietf-curdle-cms-ecdh-new-curves-02 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, 29 Mar 2017 18:03:58 -0000 > -----Original Message----- > From: Russ Housley [mailto:housley@vigilsec.com] > Sent: Wednesday, March 29, 2017 12:40 PM > To: Jim Schaad > Cc: curdle > Subject: Re: Review of draft-ietf-curdle-cms-ecdh-new-curves-02 > > Jim: > > > Major > > > 3. In section 2 - note that the 32-bit number is encoded in network > > by order. This can be inferred from the example but being explicit is > > always good. > > I think this is the text you are talking about: > > To generate a key-encryption key, generates one or more KM blocks, with > the counter starting at 0x00000001, and incrementing the counter for each > subsequent KM block until enough material has been generated. The 32-bit > counter is represented in network byte order. The KM blocks are > concatenated left to right to produce the pairwise key-encryption key, > KEK: > > Let me know if you meant something else. wfm > > > 4. Section 6 is incorrect for the X25519 and X448 curves. > > Right. This needs simple point to draft-ietf-curdle-pkix for the details: > > RFC 5280 [PROFILE] specifies the profile for using X.509 Certificates in > Internet applications. A recipient static public key is needed for X25519 > or X448, and the originator obtains that public key from the recipient's > certificate. The conventions for carrying X25519 and X448 public keys are > specified in [ID.curdle-pkix]. wfm Jim > > Thanks for your review. > > Russ From nobody Wed Mar 29 11:19: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 B57FD128854 for ; Wed, 29 Mar 2017 11:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, 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=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 5xkGpWJrUoDZ for ; Wed, 29 Mar 2017 11:19:14 -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 04077126DDF for ; Wed, 29 Mar 2017 11:19:14 -0700 (PDT) Content-Type: multipart/alternative; boundary="----=_NextPart_000_05D9_01D2A88F.0C6E9890" Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1490811549; h=from:subject:to:date:message-id; bh=y5uhGkfHrdzmTxI+eX6B42ic5F1E7ISiLkSpGT0xhMM=; b=Nk7Q3VF/2XFWdWey2XFyGHOMZj21OEIkGvd7zcVIzOYXaHL6DFtq55vIarvW8vw7o+LnXWMuaIN T6uBdjFT7E0o4tKOd/98wGAAe93x1I5QEHt611ibDUA240P9OW28LoQ8c9cjACuMg6i129C78/ZoR nEb6weH3x13ienaQ4Y+3TM6356zi4XzrCGWdCO7Kt+D+aAYPx/baSY3qdpTU+ceR+GuhQ2JyFhe1X xy4VbjunMMOKG13SqHFBnqlfCE4gku5WAnElHAGyZQFqDcPvwXRT2b6M9yW2P/rYcPZkmv1uIQKnF SZEos0VdKwNwaFMbDIH0BgF8BaZPs/bIujyA== 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; Wed, 29 Mar 2017 11:19:09 -0700 Received: from hebrews (31.133.135.244) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 29 Mar 2017 11:19:08 -0700 From: Jim Schaad To: 'David Benjamin' , 'curdle' References: In-Reply-To: Date: Wed, 29 Mar 2017 13:19:05 -0500 Message-ID: <05d801d2a8b8$f53f7070$dfbe5150$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFShB4nG4sWgU6s2CcjUkZe12aLAKKsaAig X-Originating-IP: [31.133.135.244] Archived-At: Subject: Re: [Curdle] Review of draft-ietf-curdle-pkix-04 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, 29 Mar 2017 18:19:17 -0000 ------=_NextPart_000_05D9_01D2A88F.0C6E9890 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of David = Benjamin Sent: Wednesday, March 29, 2017 12:32 PM To: curdle Subject: [Curdle] Review of draft-ietf-curdle-pkix-04 =20 Overall, the document looks good to me. I've actually just implemented = it along with the TLS bits in BoringSSL and our Go testing = implementation. Seems to work. (Though I haven't done anything with the = signature yet, just parsing out keys. Our X.509 story is a little funny = since Chrome currently uses OS verifiers.) =20 I have a handful of comments. They are all entirely editorial and mostly = nitpicks. =20 In section 3, =20 The same algorithm identifiers are used for identifying a public key, identifying a private key and identifying a signature (for the four EdDSA related OIDs). Additional encoding information is provided below for each of these locations. =20 "four EdDSA related OIDs" should now be "two EdDSA related OIDs" =20 fixed =20 In section 4, =20 o subjectPublicKey contains the byte stream of the public key. While the encoded public keys for the current algorithms are all an even number of octets, future curves could change that. =20 I would suggest replacing the last sentence with "For the algorithms = defined in this document, the encoded public keys are an even number of = octets." If future curves do something funny, they'll be defined with = independent OIDs and won't be bound by any explanatory notes in this = document. =20 How about =20 The algorithms defined in this document always encode the public = key in an even number of octets. If future algorithms change this, they should consider using a = new OID value. =20 In section 5, =20 If the keyUsage extension is present in a certificate that indicates id-X25119 or id-X448 in SubjectPublicKeyInfo, then the following MUST be present: =20 "id-X25119" should be "id-X25519". =20 Also, a exceedingly nitpicky nitpick: the various lists of keyUsage = values are all indented differently. I'm not sure if this is an artifact = of some centering thing or a formatting error. =20 Fixed=20 =20 In section 7, =20 For the keys defined in this document, the private key is always an opaque byte sequence. The ASN.1 type CurvePrivateKey is defined in this document to hold the byte sequence. Thus when encoding a OneAsymmetricKey object, the private key is wrapped in an CurvePrivateKey object and wrapped by the OCTET STRING of the 'privateKey' field. =20 The 'privateKey' field is described with single quotes, but in the = following paragraph, the "privateKey", "privateKeyAlgorithm", and = "publicKey" fields are described with double quotes. =20 In section 8, =20 When the curve is known, use a more specific string. For the id- EdDSA25519 value use the string "Ed25519". For id-EdDSA448 use "Ed448". =20 In keeping with its own advice and to match the names in section 3, = "id-EdDSA25519" should be "id-Ed25519" and "id-EdDSA448" should be = "id-Ed448". The names also show up elsewhere in the document and should = match. =20 fixed =20 In section 10.2, =20 The OIDs in the sample certificate are referred to as "EdDSA 25519 = signature algorithm" and "ECDH 25519 key agreement", contradicting the = document's own advice on human-readable names. =20 Fixed =E2=80=93 I apparently did this when I re-mapped the OIDs and = forgot to make the entire document consistent =20 Jim =20 =20 David ------=_NextPart_000_05D9_01D2A88F.0C6E9890 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

 

From:<= /b> = Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of David = Benjamin
Sent: Wednesday, March 29, 2017 12:32 = PM
To: curdle <curdle@ietf.org>
Subject: = [Curdle] Review of = draft-ietf-curdle-pkix-04

 

Overall, the document looks good to me. I've actually = just implemented it along with the TLS bits in BoringSSL and our Go = testing implementation. Seems to work. (Though I haven't done anything = with the signature yet, just parsing out keys. Our X.509 story is a = little funny since Chrome currently uses OS = verifiers.)

 

I = have a handful of comments. They are all entirely editorial and mostly = nitpicks.

 

In section 3,

 

   The same algorithm identifiers are used = for identifying a public key,

   identifying a private key and identifying = a signature (for the four

   EdDSA related OIDs).  Additional = encoding information is provided

   below for each of these = locations.

 

"four EdDSA related OIDs" should now be = "two EdDSA related OIDs"

 

fixed

 

In section 4,

 

   o  subjectPublicKey contains the = byte stream of the public key.

      While the encoded public keys for = the current algorithms are all

      an even number of octets, future = curves could change that.

 

I = would suggest replacing the last sentence with "For the algorithms = defined in this document, the encoded public keys are an even number of = octets." If future curves do something funny, they'll be defined = with independent OIDs and won't be bound by any explanatory notes in = this document.

 

How about

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The algorithms defined in = this document always encode the public key in an even number of = octets.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If future algorithms change = this, they should consider using a new OID = value.

 

In section 5,

 

   If the keyUsage extension is present in a = certificate that indicates

   id-X25119 or id-X448 in = SubjectPublicKeyInfo, then the following = MUST

   be = present:

 

"id-X25119" should be = "id-X25519".

 

Also, a exceedingly nitpicky nitpick: the various = lists of keyUsage values are all indented differently. I'm not sure if = this is an artifact of some centering thing or a formatting = error.

 

Fixed

 

In section = 7,

 

   For the keys defined in this document, = the private key is always an

   opaque byte sequence.  The ASN.1 = type CurvePrivateKey is defined in

   this document to hold the byte = sequence.  Thus when encoding a

   OneAsymmetricKey object, the private key = is wrapped in an

  =  CurvePrivateKey object and wrapped by the OCTET STRING of = the

  =  'privateKey' field.

 

The 'privateKey' field is described with single = quotes, but in the following paragraph, the "privateKey", = "privateKeyAlgorithm", and "publicKey" fields are = described with double quotes.

 

In section 8,

 

   When the curve is known, use a more = specific string.  For the id-

   EdDSA25519 value use the string = "Ed25519".  For id-EdDSA448 = use

  =  "Ed448".

 

In keeping with its own advice and to match the names = in section 3, "id-EdDSA25519" should be "id-Ed25519" = and "id-EdDSA448" should be "id-Ed448".  The = names also show up elsewhere in the document and should = match.

 

fixed

 

In section 10.2,

 

The OIDs in the sample certificate are referred to as = "EdDSA 25519 signature algorithm" and "ECDH 25519 key = agreement", contradicting the document's own advice on = human-readable names.

 

Fixed =E2=80=93 I apparently did this when I re-mapped the OIDs and = forgot to make the entire document consistent

 

Jim

 

 

David

------=_NextPart_000_05D9_01D2A88F.0C6E9890-- From nobody Wed Mar 29 11:22: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 0B7AF129441 for ; Wed, 29 Mar 2017 11:22:04 -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 AlINs6rUktDa for ; Wed, 29 Mar 2017 11:22:02 -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 2CEA712778D for ; Wed, 29 Mar 2017 11:22:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 88476300433 for ; Wed, 29 Mar 2017 14:22:01 -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 xK_NxEIzCrh5 for ; Wed, 29 Mar 2017 14:22:00 -0400 (EDT) Received: from dhcp-8696.meeting.ietf.org (dhcp-8696.meeting.ietf.org [31.133.134.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 56429300267; Wed, 29 Mar 2017 14:22:00 -0400 (EDT) From: Russ Housley Message-Id: <37429947-8E8F-4F78-A55E-9A77E1B449E0@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_5ADF15B9-2612-48F5-BE7B-23D1B79DBAE0" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 29 Mar 2017 14:21:59 -0400 In-Reply-To: <05d801d2a8b8$f53f7070$dfbe5150$@augustcellars.com> Cc: David Benjamin , curdle To: Jim Schaad References: <05d801d2a8b8$f53f7070$dfbe5150$@augustcellars.com> X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Curdle] Review of draft-ietf-curdle-pkix-04 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, 29 Mar 2017 18:22:04 -0000 --Apple-Mail=_5ADF15B9-2612-48F5-BE7B-23D1B79DBAE0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Jim: > In section 4, > =20 > o subjectPublicKey contains the byte stream of the public key. > While the encoded public keys for the current algorithms are all > an even number of octets, future curves could change that. > =20 > I would suggest replacing the last sentence with "For the algorithms = defined in this document, the encoded public keys are an even number of = octets." If future curves do something funny, they'll be defined with = independent OIDs and won't be bound by any explanatory notes in this = document. > =20 > How about > =20 > The algorithms defined in this document always encode the = public key in an even number of octets. > If future algorithms change this, they should consider using a = new OID value. I do not think you need the second sentence. A changes would be a = different algorithm, which is of course not in the document. Russ= --Apple-Mail=_5ADF15B9-2612-48F5-BE7B-23D1B79DBAE0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Jim:

In section 4,
 
   o  subjectPublicKey = contains the byte stream of the public key.
      While the encoded public keys for the = current algorithms are all
      = an even number of octets, future curves could change that.
 
I would suggest replacing the last = sentence with "For the algorithms defined in this document, the encoded = public keys are an even number of octets." If future curves do something = funny, they'll be defined with independent OIDs and won't be bound by = any explanatory notes in this document.
 
How about
 
        The algorithms = defined in this document always encode the public key in an even number = of octets.
        If future = algorithms change this, they should consider using a new OID = value.

I do not think you need the second sentence.  A = changes would be a different algorithm, which is of course not in the = document.

Russ
= --Apple-Mail=_5ADF15B9-2612-48F5-BE7B-23D1B79DBAE0-- From nobody Wed Mar 29 12:49: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 AD6581297A5 for ; Wed, 29 Mar 2017 12:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=briansmith-org.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 ZX34bC_pLF5j for ; Wed, 29 Mar 2017 12:49:50 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F5781297C2 for ; Wed, 29 Mar 2017 12:49:50 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id l7so6003040ioe.3 for ; Wed, 29 Mar 2017 12:49:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ksf1Zm462M9e3OFgGip1pMUyeryZtY3VQrhoFJyL2y4=; b=b9NVUbupMbAgMyEIhpCYHjfHChNiYIrFdMNa2ZGNyO06sAA2mcvE3iI0KO7Fxxgqb9 KWg/6AAEWzBK4KGfmtZCDeq9XBJfq35NLRKb3KhUMWn1loFUxjazvp/Y8/RP1+C31OCR YpQUmQAOr7WJnlXg+jkJdPAyInD+aBYO+OF34IKNVshErw5ZpUITr9QPqPZQyO22DsWS WMuf+GF7UKclojtLiUIEgP5X2Be9TLxJOhlW6CbMXhep/0AKtEJBPC6uHp+FpVjb+/qd njGaLbsjz0N2BkXvPAe38r+Z5+o6jVtSIr4YiDkApXlUiBO1osQS/qLUNth942LUIYP2 R1uw== 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=Ksf1Zm462M9e3OFgGip1pMUyeryZtY3VQrhoFJyL2y4=; b=StbEnIC5gZ3zWz6uggmkmsJwGbuqrpeBFF3xgOkW+ncLfPjjgqsPpK18Bc5+ACHBx6 MkpE8HlgjNjRWRPDrxIzlJiviqkjCn9LFeddAGKa0VgOtPB2di9cCy73Xd+WyH0IIowb n/fve0qIXCuU7b+mO0BblO8WP3vjnfN3QECmdJRz+eLLR6+YjUhNhUJ6YwPepS9f7AA/ G9Vd+NBidGt5hbtPU4KZJM8XycH+Ec0JoT7SRLLLWFAY+B8P+xUH9p/QGordjlSTOf51 q5GteiZH7I6RRQZfDt2pXD2gamfpb1ExcC7hBNTiW3I4mGQ+YADpKF84dlJ+lEgsX2UP /nAQ== X-Gm-Message-State: AFeK/H2rN8ATY9wK+Q0jwgkOxUnp/gWWG4NFsrhVJyIanhTbN9MU3KHFUdtMvunXkTu56vzWcQML3hEICYLrog== X-Received: by 10.107.162.73 with SMTP id l70mr2906300ioe.184.1490816989441; Wed, 29 Mar 2017 12:49:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.107.142 with HTTP; Wed, 29 Mar 2017 12:49:48 -0700 (PDT) In-Reply-To: <05ab01d2a8af$556548d0$002fda70$@augustcellars.com> References: <05ab01d2a8af$556548d0$002fda70$@augustcellars.com> From: Brian Smith Date: Wed, 29 Mar 2017 09:49:48 -1000 Message-ID: To: Jim Schaad Cc: Klaus Hartke , curdle Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Curdle] Comments on draft-ietf-curdle-pkix-04 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, 29 Mar 2017 19:49:52 -0000 Jim Schaad wrote: >> - Is it OK to simply ignore anything after privateKey or does an >> implementation, e.g., have to check if publicKey is actually the correct > public key for privateKey? > > Normally, one will just ignore the public key and compute it oneself. There > are some circumstances where devices need to have this field delivered. > Normally it can just be ignored. FWIW, I do check that the private key and the public key are consistent and I think it's a good idea unless you can't afford to recompute the public key. Cheers, Brian -- https://briansmith.org/ From nobody Wed Mar 29 14:55:11 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 2DC4E12960D for ; Wed, 29 Mar 2017 14:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AcWrTdz3tSrl for ; Wed, 29 Mar 2017 14:55:09 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.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 8C3C6129618 for ; Wed, 29 Mar 2017 14:55:07 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v2TLshh6009362 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 30 Mar 2017 00:54:43 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v2TLshKd006086; Thu, 30 Mar 2017 00:54:43 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <22748.11555.248359.687303@fireball.acr.fi> Date: Thu, 30 Mar 2017 00:54:43 +0300 From: Tero Kivinen To: Anna Johnston Cc: Peter Gutmann , "Salz\, Rich" , curdle , Mark Baushke In-Reply-To: <58EFAF37-42A8-4AFE-B2A5-57100710B201@juniper.net> References: <30381.1490720068@eng-mail01.juniper.net> <6ab576118c6945f4ba888dd403cf2471@usma1ex-dag1mb1.msg.corp.akamai.com> <1490766071333.6018@cs.auckland.ac.nz> <22747.54905.670599.560304@fireball.acr.fi> <58EFAF37-42A8-4AFE-B2A5-57100710B201@juniper.net> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 8 min X-Total-Time: 8 min Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-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, 29 Mar 2017 21:55:10 -0000 Anna Johnston writes: > I disagree with the statement that fixed primes are better than > random. Randomly generated primes, with Pocklington prime > certificates, are easily proven prime and can offer better security > than fixed primes due to the amortization of the cost of the > discrete logarithm problem =E2=80=93 as long as they are treated for = what > they are: crypto parameters, generated with care and changed > regularly. Prime certificates for P are possible as long as at > least half the factorization of (P-1) is known. For example, given > P,q,g where q is at least half the bits of P, Pocklington=E2=80=99s = theorem > gives a quick (two exponentiations) test to not only prove P is > prime, but also verify that g has order q. =20 And that also proofs that those primes do not have backdoors=3F I did not know there is tests that tell you that...=20 How fast are those tests=3F How many thousand of those you can do per second even when you do have crypto hardware to help with Diffie-Hellman operations used by normal connections. How large are those Pocklington prime certificates=3F The prime certificats that for example Primo prints out are in order of tens of kilobytes, which is way too large to transfer for every single connection.=20 Also adding that kind of test to be run online when someone connects opens new path for denial of service attacks, and also opens more code that is seldomly run and might not be tested as well as rest of code, i.e., there might be new security issues there. --=20 kivinen@iki.fi From amj@juniper.net Wed Mar 29 12:30: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 6F2D01296DE for ; Wed, 29 Mar 2017 12:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-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=junipernetworks.onmicrosoft.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 olcS4e_2TJRm for ; Wed, 29 Mar 2017 12:30:28 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0102.outbound.protection.outlook.com [104.47.41.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B02B3124D6C for ; Wed, 29 Mar 2017 12:30:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=eSoQkVOOQXoxl9+g6WfPh2tzr7TzmsDFF/xZQ+sEvXI=; b=bxeUZUpnXwRbg/YE3rqKIBEvvfZrOeTQqj0DUjJwiamBTAVI+VAo6Q4T2MdyzkYs1DuhyR/Rmtg7lRGXN9H1A5gmgl2KJ7ZGxWSkOyDkN3m/gmwHg9z281DKRj7Fwv5sVClSvYp8hXlkEeb9NnhB8r4D+KBbYbrgi+F7l0jRhjk= Received: from CO2PR0501MB1032.namprd05.prod.outlook.com (10.160.7.143) by BLUPR05MB691.namprd05.prod.outlook.com (10.141.206.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Wed, 29 Mar 2017 19:30:26 +0000 Received: from CO2PR0501MB1032.namprd05.prod.outlook.com ([10.160.7.143]) by CO2PR0501MB1032.namprd05.prod.outlook.com ([10.160.7.143]) with mapi id 15.01.1005.010; Wed, 29 Mar 2017 19:30:26 +0000 From: Anna Johnston To: Tero Kivinen , Peter Gutmann CC: "Salz, Rich" , curdle , Mark Baushke Thread-Topic: [Curdle] draft-ietf-curdle-ssh-modp-dh-sha2 Thread-Index: AQHSqKNq8oLudfhpKUOh06KCX76vZaGrvzmA Date: Wed, 29 Mar 2017 19:30:26 +0000 Message-ID: <58EFAF37-42A8-4AFE-B2A5-57100710B201@juniper.net> References: <30381.1490720068@eng-mail01.juniper.net> <6ab576118c6945f4ba888dd403cf2471@usma1ex-dag1mb1.msg.corp.akamai.com> <1490766071333.6018@cs.auckland.ac.nz> <22747.54905.670599.560304@fireball.acr.fi> In-Reply-To: <22747.54905.670599.560304@fireball.acr.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: iki.fi; dkim=none (message not signed) header.d=none;iki.fi; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [98.246.69.232] x-microsoft-exchange-diagnostics: 1; BLUPR05MB691; 7:PJmmMXVRWQ+pfJDei8vp6wD5jxICsJSPYL/GdX1DPfkRoxk2ky1AX+BkQglzioJ3lyGl7y07V+B4ys5p9tjiP5WTjofDA4EozhTUxcVoUFYYQE5ymgYK1ooNa+hWk9YPcO6/PD76tDHSXBCMAYrhhaApKUUVzojaiU9uBSy6Kk0hnHjgrbuwwfOtaBBeKnKvnfksdCzoaTp3iqRO54sfFTL0hQZegg3DoEeCyHc5kM4syx/qsuTlUT20Yv/vj16+JDfS7Fa1gdba4OGDzxfVDV37AGJ1RsMHktbf0MEKr1UsQiO94QBiMtWsRqBiQASAzrau8wwlgaagclaAwbPGFg== x-ms-office365-filtering-correlation-id: fee5e946-a59e-4533-70eb-08d476da0d82 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:BLUPR05MB691; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123558025)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(201703131423075)(201703011903075)(201702281528075)(201703061421075)(6072148); SRVR:BLUPR05MB691; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB691; x-forefront-prvs: 0261CCEEDF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39450400003)(39840400002)(39860400002)(39410400002)(39400400002)(24454002)(377454003)(86362001)(53936002)(305945005)(81166006)(7736002)(50986999)(8676002)(76176999)(8936002)(2906002)(6436002)(6506006)(33656002)(36756003)(6512007)(54906002)(5660300001)(3280700002)(54356999)(3660700001)(66066001)(189998001)(102836003)(6116002)(3846002)(6306002)(99286003)(6486002)(122556002)(230783001)(4326008)(83716003)(38730400002)(107886003)(25786009)(53546009)(93886004)(82746002)(2950100002)(229853002)(77096006)(2900100001)(6246003)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB691; H:CO2PR0501MB1032.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <7BED0C2B24677E4BAA0D8AB490294252@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2017 19:30:26.6832 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB691 Archived-At: X-Mailman-Approved-At: Wed, 29 Mar 2017 17:32:09 -0700 Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-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, 29 Mar 2017 19:40:28 -0000 SSBkaXNhZ3JlZSB3aXRoIHRoZSBzdGF0ZW1lbnQgdGhhdCBmaXhlZCBwcmltZXMgYXJlIGJldHRl ciB0aGFuIHJhbmRvbS4gIFJhbmRvbWx5IGdlbmVyYXRlZCBwcmltZXMsIHdpdGggUG9ja2xpbmd0 b24gcHJpbWUgY2VydGlmaWNhdGVzLCBhcmUgZWFzaWx5IHByb3ZlbiBwcmltZSBhbmQgY2FuIG9m ZmVyIGJldHRlciBzZWN1cml0eSB0aGFuIGZpeGVkIHByaW1lcyBkdWUgdG8gdGhlIGFtb3J0aXph dGlvbiBvZiB0aGUgY29zdCBvZiB0aGUgZGlzY3JldGUgbG9nYXJpdGhtIHByb2JsZW0g4oCTIGFz IGxvbmcgYXMgdGhleSBhcmUgdHJlYXRlZCBmb3Igd2hhdCB0aGV5IGFyZTogY3J5cHRvIHBhcmFt ZXRlcnMsIGdlbmVyYXRlZCB3aXRoIGNhcmUgYW5kIGNoYW5nZWQgcmVndWxhcmx5LiAgIFByaW1l IGNlcnRpZmljYXRlcyBmb3IgUCBhcmUgcG9zc2libGUgYXMgbG9uZyBhcyBhdCBsZWFzdCBoYWxm IHRoZSBmYWN0b3JpemF0aW9uIG9mIChQLTEpIGlzIGtub3duLiAgRm9yIGV4YW1wbGUsIGdpdmVu IFAscSxnICB3aGVyZSBxIGlzIGF0IGxlYXN0IGhhbGYgdGhlIGJpdHMgb2YgUCwgUG9ja2xpbmd0 b27igJlzIHRoZW9yZW0gZ2l2ZXMgYSBxdWljayAodHdvIGV4cG9uZW50aWF0aW9ucykgdGVzdCB0 byBub3Qgb25seSBwcm92ZSBQIGlzIHByaW1lLCBidXQgYWxzbyB2ZXJpZnkgdGhhdCBnIGhhcyBv cmRlciBxLiAgDQoNCk9uIDMvMjkvMTcsIDg6NDQgQU0sICJDdXJkbGUgb24gYmVoYWxmIG9mIFRl cm8gS2l2aW5lbiIgPGN1cmRsZS1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBraXZpbmVu QGlraS5maT4gd3JvdGU6DQoNCiAgICBQZXRlciBHdXRtYW5uIHdyaXRlczoNCiAgICA+IFNhbHos IFJpY2ggPHJzYWx6QGFrYW1haS5jb20+IHdyaXRlczoNCiAgICA+IFRoZXJlIGlzIG9uZSBvYnZp b3VzIGNvdW50ZXItYXJndW1lbnQgYW5kIHRoYXQncyBkaXZlcnNpZmljYXRpb24uICBUaGUgcHJv YmxlbQ0KICAgID4gd2l0aCB0aGUgREgxMDI0IGdyb3VwIHRoYXQgd2FzIHBvaW50ZWQgb3V0IGlu IHRoZSBMb2dqYW0gcGFwZXIgaXMgdGhhdA0KICAgID4gYWJzb2x1dGVseSBldmVyeXRoaW5nIGVu ZGVkIHVwIHVzaW5nIGl0LCBtYWtpbmcgaXQgYW4gaW5jcmVkaWJseSBhdHRyYWN0aXZlDQogICAg PiB0YXJnZXQgYmVjYXVzZSBpZiB5b3UgYnJlYWsgdGhhdCB5b3UgYnJlYWsgZXZlcnl0aGluZyB0 aGF0IHVzZXMgaXQuICBIYXZpbmcNCiAgICA+IGV2ZXJ5dGhpbmcgdXNlIHRoZSAzNTI2IGdyb3Vw cywgb3Igc2ltaWxhciwganVzdCBtb3ZlcyB0aGUgcHJvYmxlbSB0byBhDQogICAgPiBzbGlnaHRs eSBsYXJnZXIga2V5IHNpemUuICBTbyB1c2luZyBrbm93bi1nb29kIHBhcmFtZXRlciBzZXRzIHRo YXQgZGlmZmVyIGZyb20NCiAgICA+IHdoYXQgZXZlcnlvbmUgZWxzZSBpcyB1c2luZywgYW5kIGlu IHBhcnRpY3VsYXIgSUtFIGFuZCBTU0wsIHdoaWNoIGFyZSBtdWNoDQogICAgPiBsYXJnZSB0YXJn ZXRzIHRoYW4gU1NILCB3b3VsZG4ndCBiZSBhIGJhZCBpZGVhLg0KICAgIA0KICAgIFVzaW5nIGRp ZmZlcmVudCBncm91cCB0aGFuIElLRSB3aWxsIGFkZCBvbmUgYml0IG9mIHNlY3VyaXR5LiBJZiB0 aGUNCiAgICBhdHRhY2tlciBjYW4gYnJlYWsgREggZ3JvdXAgb2Ygc2l6ZSBuLCBoZSBjYW4gZWFz aWx5IGJyZWFrIHR3byBvZiBzdWNoDQogICAgZ3JvdXBzLg0KICAgIA0KICAgIFRoZSBvbmx5IHBy b3BlciBwcm90ZWN0aW9uIHRoZXJlIGlzIHRvIHVzZSBrZXlzIGxvbmcgZW5vdWdoIHRoYXQgdGhl eQ0KICAgIGNhbm5vdCBiZSBicm9rZW4uIFNlY3VyaXR5IGJ5IG9ic2N1cml0eSBkb2VzIG5vdCB3 b3JrIChpLmUuLCBjbGFpbWluZw0KICAgIHRoYXQgU1NIIHdpdGggZGlmZmVyZW50IERIIGdyb3Vw cyBpcyBzYWZlciBiZWNhdXNlIG5vIGJvZHkgYm90aGVycw0KICAgIGF0dGFja2luZyBTU0ggaXMg anVzdCBzZWN1cml0eSBieSBvYnNjdXJpdHkpLg0KICAgIA0KICAgIFNvIHVzZSBwcm9wZXIgMjA0 OCBiaXQgZ3JvdXAsIGRvIG5vdCB0cnkgdG8gZ2V0IGF3YXkgdXNpbmcgc2hvcnRlcg0KICAgIG5v bi1zdGFuZGFyZCBncm91cC4NCiAgICANCiAgICA+IEluIC1MVFMsIG9uZSBvZiB0aGUgc3VnZ2Vz dGlvbnMgSSBtYWtlIGlzOg0KICAgID4gDQogICAgPiAgIElmIHRoaXMgaXNuJ3QgcG9zc2libGUs IGFuIGFsdGVybmF0aXZlIG9wdGlvbiBpcyB0byBwcmUtZ2VuZXJhdGUgYSBzZWxlY3Rpb24NCiAg ICA+ICAgb2YgREggcGFyYW1ldGVycyBhbmQgY2hvb3NlIG9uZSBzZXQgYXQgcmFuZG9tIGZvciBl YWNoIG5ldyBoYW5kc2hha2UsIG9yDQogICAgPiAgIGFnYWluIHJvbGwgdGhlbSBvdmVyIGZyb20g dGltZSB0byB0aW1lIGZyb20gdGhlIHByZS1nZW5lcmF0ZWQgc2VsZWN0aW9uLCBzbw0KICAgID4g ICB0aGF0IGFuIGF0dGFja2VyIGhhcyB0byBhdHRhY2sgbXVsdGlwbGUgc2V0cyBvZiBwYXJhbWV0 ZXJzIHJhdGhlciB0aGFuIGp1c3QNCiAgICA+ICAgb25lLg0KICAgIA0KICAgIFJhbmRvbSBnZW5l cmF0ZWQgZ3JvdXBzIGFyZSBtdWNoIHdvcnNlIHRoYW4gdXNpbmcgb25lIHdlbGwga25vd24gZ3Jv dXANCiAgICB3aXRoIHByb3BlciBsZW5ndGguDQogICAgDQogICAgSXQgdGFrZXMgc2V2ZXJhbCBt aW51dGVzIG9yIGhvdXJzIHRvIHByb3Blcmx5IHZlcmlmeSB0aGUgZ3JvdXAgd2FzIGlzDQogICAg YWN0dWFsbHkgcHJpbWUgKGlmIHlvdSBhY3R1YWxseSBkbyB0aGUgZWxsaXB0aWMgY3VydmUgcHJp bWFsaXR5DQogICAgcHJvb2ZzKS4gSWYgeW91IGp1c3QgdHJ1c3QgdGhlIHByb2JhYmlsaXN0aWMs IHRoZW4gZXZlbiB0aGF0IGlzIHRvbw0KICAgIHNsb3cgdG8gZG8gd2hlbiBuZXcgY29ubmVjdGlv biBjb21lcyBpbi4gQW5kIHlvdSBzaG91bGQgbm90IGp1c3QNCiAgICBhc3N1bWUgdGhlIGdyb3Vw IGdlbmVyYXRlZCBieSB0aGUgb3RoZXIgZW5kIGlzIHNhZmUuLi4gQWxzbyB0aG9zZQ0KICAgIHRl c3RzIHN0aWxsIGRvIG5vdCB0ZWxsIHlvdSB3aGV0aGVyIHRoaXMgZ3JvdXAgaXMgYmFja2Rvb3Jl ZCBvciBub3QuDQogICAgT25seSB3YXkgdG8ga25vdyB0aGF0IGdyb3VwIGlzIG5vdCBiYWNrZG9v cmVkLCBpcyB0byBrbm93IGhvdyBpdCBpcw0KICAgIHdhcyBnZW5lcmF0ZWQuDQogICAgDQogICAg T2YgY291cnNlIGlmIHlvdSBhcmUgd29ya2luZyBpbiB0aGUgY2xvc2VkIGVudmlyb25tZW50IGFu ZCBhY3R1YWxseQ0KICAgIGtub3cgaG93IHRvIGdlbmVyYXRlIHNhZmUgZ3JvdXBzLCBhbmQgZ2Vu ZXJhdGUgdGhlbSBwcm9wZXJseSBhbmQNCiAgICBkaXN0cmlidXRlIHRoZW0gdXNpbmcgc29tZSBv dXQgb2YgYmFuZCBtZWNoYW5pc20gdG8gYWxsIGRldmljZXMsIHRoZW4NCiAgICB5b3UgYXJlIGZp bmUsIGJ1dCB0aGF0IGlzIG5vdCBub3JtYWwgdXNlIG9mIFNTSCAob3IgSUtFLCBvciBUTFMpLiAN CiAgICANCiAgICA+IFNvIG9uZSBwb3NzaWJpbGl0eSB3b3VsZCBiZSB0byBnZW5lcmF0ZSwgc2F5 LCAxNiBOVU1TIERIIHBhcmFtZXRlcnMgZm9yIGVhY2gNCiAgICA+IHNpemUgYW5kIHB1Ymxpc2gg dGhvc2UsIGFuZCBoYXZlIHRoZSBzZXJ2ZXIgc2VsZWN0IG9uZSBhdCByYW5kb20uICBUaGlzIGFk ZHMNCiAgICA+IHNlY3VyaXR5IGJvdGggaW4gdGVybXMgb2YgZGl2ZXJzaWZ5aW5nIGZyb20gdGhl IElLRS9TU0wgdmFsdWVzIHRoYXQgZXZlcnlvbmUNCiAgICA+IGVsc2UgdXNlcywgYW5kIGZvcmNp bmcgYW4gYXR0YWNrZXIgdG8gYnJlYWsgYWxsIDE2IHBhcmFtZXRlciBzZXRzIGluc3RlYWQgb2YN CiAgICA+IGp1c3QgdGhlIG9uZS4NCiAgICANCiAgICBVc2luZyAxNiBkaWZmZXJlbnQgRGlmZmll LUhlbGxtYW4gZ3JvdXBzIGFkZHMgNCBiaXRzIG9mIHNlY3VyaXR5Lg0KICAgIE1vdmluZyBmcm9t IDEwMjQtYml0IHRvIDIwNDgtYml0IERIIGdyb3VwcyBhZGRzIDMwIGJpdHMgb2Ygc2VjdXJpdHkg dG8NCiAgICB0aGUgcHJlLWNvbXB1dGF0aW9uIHN0ZXAgKDEwXjkgdGltZXMgaGFyZGVyIFsxXSku IEFuZCB0aGlzIGlzIHByb3ZpZGVkDQogICAgdGhhdCBib3RoIG9mIHRoZSBncm91cHMgYXJlIG5v dCB0cmFwZG9vcmVkLCBidXQgZm9yIGdyb3VwIGdpdmVuIHRvIHlvdQ0KICAgIGJ5IHRoZSBvdGhl ciBlbmQgeW91IGNhbm5vdCBiZSBzdXJlIGFib3V0IHRoYXQuLi4NCiAgICANCiAgICBTbyB1c2Ug cHJvcGVybHkgZ2VuZXJhdGVkIGdyb3VwcyB3aXRoIHByb3BlciBsZW5ndGgsIGFuZCBkbyBub3Qg YWNjZXB0DQogICAgZ3JvdXBzIHlvdSBkbyBub3Qga25vdy4uLg0KICAgIA0KICAgIFsxXSBodHRw czovL3dlYWtkaC5vcmcvaW1wZXJmZWN0LWZvcndhcmQtc2VjcmVjeS1jY3MxNS5wZGYgcGFnZSAx MSwNCiAgICBzZWN0aW9uIDUgMm5kIGNvbHVtbiwgbGluZSA5LiANCiAgICAtLSANCiAgICBraXZp bmVuQGlraS5maQ0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQogICAgQ3VyZGxlIG1haWxpbmcgbGlzdA0KICAgIEN1cmRsZUBpZXRmLm9y Zw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY3VyZGxlDQogICAg DQoNCg== From nobody Wed Mar 29 17:32: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 ACEBD129471 for ; Wed, 29 Mar 2017 17:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.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 PL_2KSYYbkUi for ; Wed, 29 Mar 2017 17:29:00 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0125.outbound.protection.outlook.com [104.47.42.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADFDF128BA2 for ; Wed, 29 Mar 2017 17:29:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ztoZE4J7O63v6JjBZWBtcGL0ixNyxyvsSUub2L+hVc8=; b=HgAi1zK8MrlJV0Ykg8bDcBfYuhXVNKs00v18hCbDrfVB9p87gVQ4BY0AsSdzH9jN42ds7hTetCy/dWh/7FejMa/Dag++8/zeIWjyA0jLcg0PoqkbZy1LQEcpnX3I3euRTCVaGDiq7zdysXeXEW6qBWgu8BLl7htk3Zn18jQ6njA= Received: from CO2PR0501MB1032.namprd05.prod.outlook.com (10.160.7.143) by CO2PR05MB700.namprd05.prod.outlook.com (10.141.229.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Thu, 30 Mar 2017 00:28:59 +0000 Received: from CO2PR0501MB1032.namprd05.prod.outlook.com ([10.160.7.143]) by CO2PR0501MB1032.namprd05.prod.outlook.com ([10.160.7.143]) with mapi id 15.01.1005.010; Thu, 30 Mar 2017 00:28:59 +0000 From: Anna Johnston To: Tero Kivinen CC: Peter Gutmann , "Salz, Rich" , curdle , Mark Baushke Thread-Topic: [Curdle] draft-ietf-curdle-ssh-modp-dh-sha2 Thread-Index: AQHSqKNq8oLudfhpKUOh06KCX76vZaGrvzmAgACdpYD//7XDgA== Date: Thu, 30 Mar 2017 00:28:58 +0000 Message-ID: References: <30381.1490720068@eng-mail01.juniper.net> <6ab576118c6945f4ba888dd403cf2471@usma1ex-dag1mb1.msg.corp.akamai.com> <1490766071333.6018@cs.auckland.ac.nz> <22747.54905.670599.560304@fireball.acr.fi> <58EFAF37-42A8-4AFE-B2A5-57100710B201@juniper.net> <22748.11555.248359.687303@fireball.acr.fi> In-Reply-To: <22748.11555.248359.687303@fireball.acr.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: iki.fi; dkim=none (message not signed) header.d=none;iki.fi; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [98.246.69.232] x-microsoft-exchange-diagnostics: 1; CO2PR05MB700; 7:lDnmjCkzCEDju4ldAgbwadO0iq0G9AjCLFRlWXXALfZJl9tMV7fRMbOfRW2qBF3WHlm0HdvVNVdIHMeJz85zGLLfpR1G+LaNGV8SWXpi97oZpIaoPlew1JyeBRn6FZr6Jw5U0AgDxaOW9kuBVA5BgfpLWh/Dg/cp5Kl2bJLX6ZeGugjphDJaK/gOQRe3WRdo7ziUvh/AXTl6q4rlW8iPQQm6jEH0UQBmaoiZ25uitR6Ysie6PPakuvOwA6U/hzT9rLhpcKXHbZFpBGz2+SyuiltE1ZkraDtmMweJk0bwwyVRi6DslVam2g2uTHl5tv2kUPWscxdKAUUmkSww+fiNyQ== x-ms-office365-filtering-correlation-id: 479319ba-9042-43a4-57cc-08d47703c213 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:CO2PR05MB700; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(209352067349851)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006057)(93001057)(6055026)(6041248)(20161123564025)(20161123560025)(20161123558025)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406075)(6072148); SRVR:CO2PR05MB700; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB700; x-forefront-prvs: 02622CEF0A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39850400002)(39400400002)(39410400002)(39450400003)(39840400002)(52314003)(24454002)(377454003)(54906002)(189998001)(77096006)(83716003)(53936002)(6512007)(82746002)(6486002)(86362001)(122556002)(93886004)(99286003)(7736002)(6436002)(6506006)(305945005)(5660300001)(3660700001)(2900100001)(66066001)(54356999)(53546009)(3280700002)(33656002)(50986999)(76176999)(110136004)(230783001)(2906002)(3846002)(8676002)(102836003)(6116002)(8936002)(38730400002)(107886003)(229853002)(36756003)(6916009)(2950100002)(6246003)(4326008)(81166006)(25786009)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB700; H:CO2PR0501MB1032.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <9707FB88934A4143A4CD3CFD30F48BF7@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Mar 2017 00:28:58.9656 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB700 Archived-At: X-Mailman-Approved-At: Wed, 29 Mar 2017 17:32:09 -0700 Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-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, 30 Mar 2017 00:29:06 -0000 VGhlcmUgaXNu4oCZdCB0aGF0IG11Y2ggdG8gUG9ja2xpbmd0b27igJlzIHRoZW9yZW0uICBBIGRl Y2VudCB3cml0ZSB1cCBvZiBpdCBpcyBpbiBXaWtpcGVkaWEuICBBcyBmb3IgeW91ciBjb21tZW50 czoNCg0KMS4gIFByb29mIG9mIG5vIGJhY2tkb29yOiAgT2YgY291cnNlIHRoZXJlIGlzIG5vIHBy b29mIHRoYXQgYmFja2Rvb3JzIGRvIG5vdCBleGlzdC4gIFNob3cgbWUgc3VjaCBhIHByb29mIGZv ciB0aGUgZml4ZWQgcHJpbWVzLiAgSG93ZXZlciwgUG9ja2xpbmd0b27igJlzIHRoZW9yZW0gY2Fu IHByb3ZlIHRoZSBwcmltYWxpdHkgb2YgQU5ZIHByaW1lLCBhcyBsb25nIGFzIHRoZSBmYWN0b3Jp emF0aW9uIGZvciBhdCBsZWFzdCDCvSB0aGUgYml0cyBvZiAoUC0xKSBpcyBrbm93biwgc28gaXQg aXMgbm90IHJlbGlhbnQgb24gaG93IHRoZSBwcmltZSB3YXMgZ2VuZXJhdGVkLiAgSWYgYmFja2Rv b3JzIGFyZSB5b3VyIGJpZyBjb25jZXJuLCB1c2luZyBhIDIgb3IgM0sgYml0IHByaW1lLCBjaGFu Z2luZyBwcmltZXMgcmVndWxhcmx5LCBhbmQgdXNpbmcgYSB3ZWxsIHVuZGVyc3Rvb2QgcHJpbWUg Z2VuZXJhdGlvbiBhbGdvcml0aG0gbWluaW1pemVzIHRoZSByaXNrLiAgVGhlIHByaW1lIGhhcyB0 byBiZSBmaXhlZCBmb3IgdGhlIGJhY2tkb29yIHRvIHJlbWFpbiBpbiBwbGFjZS4NCjIuIFRoZSB0 ZXN0cyBjYW4gY29zdCBhcyBsaXR0bGUgYXMgdHdvIGV4cG9uZW50aWF0aW9ucy4gIElmIChQLTEp PWhxKzEsIHdoZXJlIHEgaXMgcHJpbWUgYW5kIHE+aCAoaCBjYW4gYmUgYW55IHJhbmRvbSB2YWx1 ZSwgcHJlZmVyYWJseSBldmVuIG9yIHlvdeKAmXJlIGd1YXJhbnRlZWQgZmFpbHVyZSksIHRoZW4g dHdvIGV4cG9uZW50aWF0aW9ucyBnaXZlIHlvdSB0aGF0IFAgaXMgcHJpbWUgYW5kIGEga25vd24g Z2VuZXJhdG9yIG9mIHRoZSBzdWJncm91cCBvZiBvcmRlciBxLg0KMy4gQSBwcmltZSBjZXJ0aWZp Y2F0ZSBjb25zaXN0cyBvZiBQLCB0aGUgcHJpbWUgcSwgYW5kIHRoZSBnZW5lcmF0b3IgZm9yIHRo ZSBzdWJncm91cCwgZyAtLSB5b3XigJlkIG5lZWQgYWxsIHRoaXMgaW5mb3JtYXRpb24gYW55d2F5 LCBzbyBpdOKAmXMgY2xvc2UgdG8gemVybyBvdmVyaGVhZC4NCjQuIFdoZW4gdXNlZCB0byBnZW5l cmF0ZSBwcmltZXMsIHRoZSBwcmltZSB0ZXN0IGJvb3Qgc3RyYXBzIHVwIGZyb20gYSBzbWFsbGVy IGtub3duIHByaW1lLiAgVGhlIHRlc3RzIGFyZSBjb21wYXJhYmxlIGluIGNvc3QgdG8gcHJvYmFi aWxpc3RpYyB0ZXN0cywgZXhjZXB0IHRoZSByZXN1bHQgaXMgcHJvdmFibHkgcHJpbWUsIG5vdCBw cm9iYWJseS4NCg0KQS4gSm9obnN0b24NCg0KT24gMy8yOS8xNywgMjo1NCBQTSwgIlRlcm8gS2l2 aW5lbiIgPGtpdmluZW5AaWtpLmZpPiB3cm90ZToNCg0KICAgIEFubmEgSm9obnN0b24gd3JpdGVz Og0KICAgID4gSSBkaXNhZ3JlZSB3aXRoIHRoZSBzdGF0ZW1lbnQgdGhhdCBmaXhlZCBwcmltZXMg YXJlIGJldHRlciB0aGFuDQogICAgPiByYW5kb20uICBSYW5kb21seSBnZW5lcmF0ZWQgcHJpbWVz LCB3aXRoIFBvY2tsaW5ndG9uIHByaW1lDQogICAgPiBjZXJ0aWZpY2F0ZXMsIGFyZSBlYXNpbHkg cHJvdmVuIHByaW1lIGFuZCBjYW4gb2ZmZXIgYmV0dGVyIHNlY3VyaXR5DQogICAgPiB0aGFuIGZp eGVkIHByaW1lcyBkdWUgdG8gdGhlIGFtb3J0aXphdGlvbiBvZiB0aGUgY29zdCBvZiB0aGUNCiAg ICA+IGRpc2NyZXRlIGxvZ2FyaXRobSBwcm9ibGVtIOKAkyBhcyBsb25nIGFzIHRoZXkgYXJlIHRy ZWF0ZWQgZm9yIHdoYXQNCiAgICA+IHRoZXkgYXJlOiBjcnlwdG8gcGFyYW1ldGVycywgZ2VuZXJh dGVkIHdpdGggY2FyZSBhbmQgY2hhbmdlZA0KICAgID4gcmVndWxhcmx5LiAgIFByaW1lIGNlcnRp ZmljYXRlcyBmb3IgUCBhcmUgcG9zc2libGUgYXMgbG9uZyBhcyBhdA0KICAgID4gbGVhc3QgaGFs ZiB0aGUgZmFjdG9yaXphdGlvbiBvZiAoUC0xKSBpcyBrbm93bi4gIEZvciBleGFtcGxlLCBnaXZl bg0KICAgID4gUCxxLGcgIHdoZXJlIHEgaXMgYXQgbGVhc3QgaGFsZiB0aGUgYml0cyBvZiBQLCBQ b2NrbGluZ3RvbuKAmXMgdGhlb3JlbQ0KICAgID4gZ2l2ZXMgYSBxdWljayAodHdvIGV4cG9uZW50 aWF0aW9ucykgdGVzdCB0byBub3Qgb25seSBwcm92ZSBQIGlzDQogICAgPiBwcmltZSwgYnV0IGFs c28gdmVyaWZ5IHRoYXQgZyBoYXMgb3JkZXIgcS4gICANCiAgICANCiAgICBBbmQgdGhhdCBhbHNv IHByb29mcyB0aGF0IHRob3NlIHByaW1lcyBkbyBub3QgaGF2ZSBiYWNrZG9vcnM/IEkgZGlkDQog ICAgbm90IGtub3cgdGhlcmUgaXMgdGVzdHMgdGhhdCB0ZWxsIHlvdSB0aGF0Li4uIA0KICAgIA0K ICAgIEhvdyBmYXN0IGFyZSB0aG9zZSB0ZXN0cz8gSG93IG1hbnkgdGhvdXNhbmQgb2YgdGhvc2Ug eW91IGNhbiBkbyBwZXINCiAgICBzZWNvbmQgZXZlbiB3aGVuIHlvdSBkbyBoYXZlIGNyeXB0byBo YXJkd2FyZSB0byBoZWxwIHdpdGgNCiAgICBEaWZmaWUtSGVsbG1hbiBvcGVyYXRpb25zIHVzZWQg Ynkgbm9ybWFsIGNvbm5lY3Rpb25zLg0KICAgIA0KICAgIEhvdyBsYXJnZSBhcmUgdGhvc2UgUG9j a2xpbmd0b24gcHJpbWUgY2VydGlmaWNhdGVzPyBUaGUgcHJpbWUNCiAgICBjZXJ0aWZpY2F0cyB0 aGF0IGZvciBleGFtcGxlIFByaW1vIHByaW50cyBvdXQgYXJlIGluIG9yZGVyIG9mIHRlbnMgb2YN CiAgICBraWxvYnl0ZXMsIHdoaWNoIGlzIHdheSB0b28gbGFyZ2UgdG8gdHJhbnNmZXIgZm9yIGV2 ZXJ5IHNpbmdsZQ0KICAgIGNvbm5lY3Rpb24uIA0KICAgIA0KICAgIEFsc28gYWRkaW5nIHRoYXQg a2luZCBvZiB0ZXN0IHRvIGJlIHJ1biBvbmxpbmUgd2hlbiBzb21lb25lIGNvbm5lY3RzDQogICAg b3BlbnMgbmV3IHBhdGggZm9yIGRlbmlhbCBvZiBzZXJ2aWNlIGF0dGFja3MsIGFuZCBhbHNvIG9w ZW5zIG1vcmUgY29kZQ0KICAgIHRoYXQgaXMgc2VsZG9tbHkgcnVuIGFuZCBtaWdodCBub3QgYmUg dGVzdGVkIGFzIHdlbGwgYXMgcmVzdCBvZiBjb2RlLA0KICAgIGkuZS4sIHRoZXJlIG1pZ2h0IGJl IG5ldyBzZWN1cml0eSBpc3N1ZXMgdGhlcmUuDQogICAgLS0gDQogICAga2l2aW5lbkBpa2kuZmkN CiAgICANCg0KDQo= From nobody Wed Mar 29 19: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 C839612871F for ; Wed, 29 Mar 2017 19:32:06 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2a0bNKuSOAj for ; Wed, 29 Mar 2017 19:32:04 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 270631294B9 for ; Wed, 29 Mar 2017 19:32:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1490841123; x=1522377123; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=wHtAc91NWagzqh4yRrc8uKVKWHCNw1rXR289GtiOjDU=; b=qHLXyeVNAlVv83fuw9H8y8KyqeV9RJ5wP3lJ6A3QbqIjT3Hy0wrZPWOg 5zf7dCqagjNponEPl8XJ1UwcDWsZoDFtxvrvQ1Hq0ubdW6xcz8/wIi6hL kvDw3z8r722UBxRFxqX0V2yOmYUTNnXitkj9BXLMEK4cbxESWE3Ercj5V Wrg14OBCGCBKriD2hmj79asKZMi92UJTHt7PrrHA7NN/T7C4kAb3twDs8 3iCqr8kaB6uSSSZWbTeTcwVEKxVYq5TNROn6ahqWNjXBKf2uOPiiLcBkU iySNYnIavTJpK8O3hsuhydFcvTyIEvhXjb3QyQHmjS1i12kyRGSYuyeui w==; X-IronPort-AV: E=Sophos;i="5.36,244,1486378800"; d="scan'208";a="146565209" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.4 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-c.UoA.auckland.ac.nz) ([10.6.3.4]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 30 Mar 2017 15:32:00 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-c.UoA.auckland.ac.nz (10.6.3.4) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 30 Mar 2017 15:31:59 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Thu, 30 Mar 2017 15:32:00 +1300 From: Peter Gutmann To: Tero Kivinen CC: "Salz, Rich" , "Mark D. Baushke" , curdle Thread-Topic: [Curdle] draft-ietf-curdle-ssh-modp-dh-sha2 Thread-Index: AQHSp+P9Zh0d3oAyu0685TNgkwvXXqGptgiAgAGYQ13//87UgIABjmt+ Date: Thu, 30 Mar 2017 02:31:59 +0000 Message-ID: <1490841119754.67646@cs.auckland.ac.nz> References: <30381.1490720068@eng-mail01.juniper.net> <6ab576118c6945f4ba888dd403cf2471@usma1ex-dag1mb1.msg.corp.akamai.com> <1490766071333.6018@cs.auckland.ac.nz>, <22747.54905.670599.560304@fireball.acr.fi> In-Reply-To: <22747.54905.670599.560304@fireball.acr.fi> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-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, 30 Mar 2017 02:32:07 -0000 Tero Kivinen writes:=0A= =0A= >Using different group than IKE will add one bit of security. If the=0A= >attacker can break DH group of size n, he can easily break two of such=0A= >groups.=0A= =0A= What you really mean there is "if the attacker can *easily* break DH groups= =0A= of size n", not just "can break DH groups of size n". Since this isn't=0A= the case, they also can't easily break two such groups.=0A= =0A= More to the point, if it takes, say, 5 years of computing on 5 acres of=0A= supercomputers (or whatever it is the NSA is supposed to have, and whatever= =0A= it'll take for DH2048 in 2040), then you want them to apply it to someone = =0A= else's DH, not yours.=0A= =0A= >(i.e., claiming that SSH with different DH groups is safer because no body= =0A= >bothers attacking SSH is just security by obscurity).=0A= =0A= Given that they're values published in RFCs, and they're broadcast by =0A= most servers whenever you connect to them, that mus be going by a pretty = =0A= peculiar definition of "obscurity".=0A= =0A= >Using 16 different Diffie-Hellman groups adds 4 bits of security.=0A= =0A= ... for an attacker who has an O( 1 ) algorithm to solve the DLP. Do=0A= you know something about the NSA that we don't?=0A= =0A= Peter.= From nobody Wed Mar 29 20:22:39 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 78532129521 for ; Wed, 29 Mar 2017 20:22:37 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06L5dNoei9pp for ; Wed, 29 Mar 2017 20:22:35 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30F8612420B for ; Wed, 29 Mar 2017 20:22:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1490844155; x=1522380155; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ccdOw9c54txZC4L8k0kXwxUR+pqKYC0FP94TNYiOlws=; b=Ci6XF9LAY7HwxFNdHi/3pn9DI9K3uHUVLq8jlF37Hp0k8npesgX/cxB5 H9S85LTT+72lsS4faTI49ml1r/exaFm63rB7tNToQ+rXBjv+fgnZV8PV/ f38wVmQYGhG0LFBokb2GguYourbMN8hlGuwMIhG06e+aL0TcowdI+fzJN n6WtzQ2VUSm+UEFBFucxxRNQn9r/B2hzb/gTHY/z5635J4tFWo6DWYCqP gfvoRu/7cdsGT0zxa4hhRmj+KVY+MZ8/mHNuKWF/jnMhZSAz1R4u9Ws1G 1cLtdEfK/bJzJoZ2NXjLkDqjSaNevdbdCdmO1NUdK1Mbuf7piV9nWdEuS w==; X-IronPort-AV: E=Sophos;i="5.36,244,1486378800"; d="scan'208";a="146579537" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.5 - Outgoing - Outgoing Received: from uxcn13-ogg-d.uoa.auckland.ac.nz ([10.6.2.5]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 30 Mar 2017 16:22:32 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.25) by uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.25) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 30 Mar 2017 16:22:32 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Thu, 30 Mar 2017 16:22:32 +1300 From: Peter Gutmann To: Tero Kivinen CC: "Mark D. Baushke" , "Salz, Rich" , curdle Thread-Topic: [Curdle] draft-ietf-curdle-ssh-modp-dh-sha2 Thread-Index: AQHSqKbDCCDwtgJ6TEe+nT3SNcvyA6Gst6HV Date: Thu, 30 Mar 2017 03:22:31 +0000 Message-ID: <1490844151663.13492@cs.auckland.ac.nz> References: <30381.1490720068@eng-mail01.juniper.net> <6ab576118c6945f4ba888dd403cf2471@usma1ex-dag1mb1.msg.corp.akamai.com> <1490766071333.6018@cs.auckland.ac.nz> <57287.1490768257@eng-mail01.juniper.net> <1490771481840.11723@cs.auckland.ac.nz>, <22747.56331.274710.114550@fireball.acr.fi> In-Reply-To: <22747.56331.274710.114550@fireball.acr.fi> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-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, 30 Mar 2017 03:22:37 -0000 Tero Kivinen writes:=0A= =0A= >I did verify the RFC 2409 primes (768, 1024, and 1536 bit groups) when I = =0A= >generated the RFC3526. I do not know if anybody else has verified the =0A= >RFC3526 primes.=0A= =0A= Wow. So the 2409 values took five years to be independently verified and= =0A= nineteen years before this became known, the 3526 values took twelve years= =0A= to be independently verified. If we do publish new groups, we need to =0A= address this problem with some urgency. I'm not saying I don't trust you := -)=0A= but the point of publishing the details is to gain confidence in everything= =0A= being correct once multiple people have verified things.=0A= =0A= In terms of what to publish, I don't know if there's much need to publish a= =0A= HOWTO for generic DLP parameter generation since presumably every =0A= implementation already has code to do DH/DSA/whatever generation. =0A= Where something is needed is situations where widely-shared parameters need= =0A= to be generated, and there all you'd need to do is document how it's done = =0A= and publish the parameters, preferably as a C-style byte array or something= . =0A= Few if any of the parameter-set documents acknowledge that implementers jus= t =0A= want something they can incorporate into their code with minimal effort. = =0A= Give them a cut&paste code block that takes under five minutes to integrate= =0A= into existing code and it's far more likely to see quick uptake.=0A= =0A= And while I'm at it, include a hash of the parameters as a byte string so= =0A= you can check that you've got an exact copy of the data.=0A= =0A= (The above culled from off-list discussions, in case someone's wondering if= =0A= they've seen it before :-)=0A= =0A= >Actually breaking SSH is much more useful than breaking IKE or TLS. The = =0A= >first time the adminstrator types sudo and his root password inside his = =0A= >ssh connection, the stored SSH stream comes very valuable for the =0A= >attacker... =0A= =0A= Only if they want to compromise someone's Linux box or something. If you= =0A= target IKE you get to vaccuum up a ton of VPN traffic, and with SSL you=0A= get not only all web browsing but a ton of other stuff that uses it as the= =0A= universal secure transport mechanism for network traffic. For example if= =0A= you're targetting VoIP then you'd want it for the tiny fraction of SIP=0A= that isn't just sent in the clear. It'd also give you ToR traffic, and =0A= endless other material. The pretty clear lesson here is, don't use the sam= e =0A= DH parameters as SSL/TLS.=0A= =0A= So in terms of target groups if I was a government-level attacker, I'd go= =0A= for SSL, then IKE, and then I'd think about what to do next, given that it= =0A= could take years to break each parameter set.=0A= =0A= Peter.= From nobody Wed Mar 29 20:30: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 7A991128896 for ; Wed, 29 Mar 2017 20:30:38 -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 3Z9Y3tYOWIfg for ; Wed, 29 Mar 2017 20:30:37 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::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 50E51128E19 for ; Wed, 29 Mar 2017 20:30:37 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.20/8.16.0.20) with SMTP id v2U3QvME025379; Thu, 30 Mar 2017 04:30:21 +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=hCYsqwEhD02SqFleBkLBZqKo+RZBpYhjg5pU9SD+WoQ=; b=cQC5YSBE4RWi98buVnOBIQcWX1g/hQCGs7LdWnE7Kb/SHdXH34af/NANHXBLmZPwhmUl xp2bJQTVjMIJ+D5mhmnehtZwbwTXJLg8Q7SoKU9p+z/PAQoZyAz6LePQtDEbbCdADoQW fR0ru87anNkJc6FpbyFTluAB0XvTsXp3gyYIWxN3OiIe9ZVoWJfo+z4e8DPZkZDxkx29 rql9am1SBPEqkML1MqR+GtqTatvO4CDuOh9C0ovkelKE8L3FZ1f2NtOR+U5CQteHQFYa NqqWJfjd+wEyLdZIBiV6bdWmN0RyBW08KuhT4PX8X+gJsN2PY0SnpnGjIGYTbnR8dHB0 Dg== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 29gmbtuux5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 30 Mar 2017 04:30:20 +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 v2U3QfkI029017; Wed, 29 Mar 2017 23:30:19 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint2.akamai.com with ESMTP id 29fsx68vg6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 29 Mar 2017 23:30:19 -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.1178.4; Wed, 29 Mar 2017 23:30:18 -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.1178.000; Wed, 29 Mar 2017 23:30:18 -0400 From: "Salz, Rich" To: Peter Gutmann , Tero Kivinen CC: "Mark D. Baushke" , curdle Thread-Topic: [Curdle] draft-ietf-curdle-ssh-modp-dh-sha2 Thread-Index: AQHSqKbBgltNOhuIEka5nllAGH/bHaGs+3uA//+/AWA= Date: Thu, 30 Mar 2017 03:30:17 +0000 Message-ID: References: <30381.1490720068@eng-mail01.juniper.net> <6ab576118c6945f4ba888dd403cf2471@usma1ex-dag1mb1.msg.corp.akamai.com> <1490766071333.6018@cs.auckland.ac.nz> <57287.1490768257@eng-mail01.juniper.net> <1490771481840.11723@cs.auckland.ac.nz>, <22747.56331.274710.114550@fireball.acr.fi> <1490844151663.13492@cs.auckland.ac.nz> In-Reply-To: <1490844151663.13492@cs.auckland.ac.nz> 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.39.50] 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-03-30_01:, , 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-1702020001 definitions=main-1703300031 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-30_01:, , 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-1702020001 definitions=main-1703300031 Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-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, 30 Mar 2017 03:30:38 -0000 > Wow. So the 2409 values took five years to be independently verified and > nineteen years before this became known, the 3526 values took twelve > years to be independently verified.=20 It is a different word now. Sadly. From nobody Wed Mar 29 22:04:56 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 00D05129445; Wed, 29 Mar 2017 22:04:55 -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.48.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149085029496.410.2963876734544327984@ietfa.amsl.com> Date: Wed, 29 Mar 2017 22:04:54 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-rsa-sha2-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, 30 Mar 2017 05:04:55 -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-04.txt Pages : 7 Date : 2017-03-29 Abstract: This memo defines an algorithm name, public key format, and signature format 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-04 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-rsa-sha2-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-rsa-sha2-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 Wed Mar 29 22:11:36 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 9DD7F129570; Wed, 29 Mar 2017 22:11: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.48.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149085068960.333.10353024295785785781@ietfa.amsl.com> Date: Wed, 29 Mar 2017 22:11:29 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-ssh-ext-info-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: Thu, 30 Mar 2017 05:11: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 : Extension Negotiation in Secure Shell (SSH) Author : Denis Bider Filename : draft-ietf-curdle-ssh-ext-info-03.txt Pages : 10 Date : 2017-03-29 Abstract: This memo defines a mechanism for SSH clients and servers to exchange information about supported protocol extensions confidentially after completed 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-03 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-ext-info-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-ssh-ext-info-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 Mar 30 08:55: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 9E2E01296C1 for ; Thu, 30 Mar 2017 08:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i23_wYu_URQr for ; Thu, 30 Mar 2017 08:55:31 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.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 A8BAF128990 for ; Thu, 30 Mar 2017 08:55:30 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v2UFsvLP018075 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 30 Mar 2017 18:54:57 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v2UFst1h020553; Thu, 30 Mar 2017 18:54:55 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <22749.10831.799493.535716@fireball.acr.fi> Date: Thu, 30 Mar 2017 18:54:55 +0300 From: Tero Kivinen To: Anna Johnston Cc: Peter Gutmann , "Salz\, Rich" , curdle , Mark Baushke In-Reply-To: References: <30381.1490720068@eng-mail01.juniper.net> <6ab576118c6945f4ba888dd403cf2471@usma1ex-dag1mb1.msg.corp.akamai.com> <1490766071333.6018@cs.auckland.ac.nz> <22747.54905.670599.560304@fireball.acr.fi> <58EFAF37-42A8-4AFE-B2A5-57100710B201@juniper.net> <22748.11555.248359.687303@fireball.acr.fi> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 22 min X-Total-Time: 23 min Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-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, 30 Mar 2017 15:55:33 -0000 Anna Johnston writes: > There isn=E2=80=99t that much to Pocklington=E2=80=99s theorem. A de= cent write up > of it is in Wikipedia. As for your comments:=20 >=20 > 1. Proof of no backdoor: Of course there is no proof that > backdoors do not exist. Show me such a proof for the fixed primes. I know there is no backdoors on the primes I generated, as I did not put backdoor there... :-) Fixed primes uses Nothing up my sleeve numbers [1] just to try to convince people that they cannot be backdoored. [1] https://en.wikipedia.org/wiki/Nothing=5Fup=5Fmy=5Fsleeve=5Fnumber > However, Pocklington=E2=80=99s theorem can prove the primality of ANY= prime, > as long as the factorization for at least =C2=BD the bits of (P-1) is= > known, so it is not reliant on how the prime was generated. If > backdoors are your big concern, using a 2 or 3K bit prime, changing > primes regularly, and using a well understood prime generation > algorithm minimizes the risk. The prime has to be fixed for the > backdoor to remain in place. It is not enough for me to use well understood prime generation algorithm, I also need to convice the peers I am talking to that I am using well understood prime generation and primes I am offering to them are generated using them, and that there has not been any virus or trojan in my machine messing up with the generation process or changing the primes after I generated them. For well know primes this needs to be done once when those primes are generated, and then you can just verify that other end is using one of the known primes. With primes given to you by the attacker, I mean the other peer, you need to do that every time you receive prime you have not seen before. Yes you could make the system so that when it sees unknown prime, it will reject the connection, email information to adminstrator, and adminstrator can then verify the prime, and talk with the person who generated them to find out how they were generated, and after being convinced that it is safe, they could install it as one of the known primes. This just isn't usable solution in general. It is completely valid solution for closed environment, like internal primes used by the enterprise for internal communications. > 2. The tests can cost as little as two exponentiations. If > (P-1)=3Dhq+1, where q is prime and q>h (h can be any random value, > preferably even or you=E2=80=99re guaranteed failure), then two > exponentiations give you that P is prime and a known generator of > the subgroup of order q. And will that also give proof that q is prime, or do you need to verify that separately=3F Any ways that is three times more exponentations than you do normally (which is not that bad, compared to the other options, and you only need to do this once after you se new prime). The question is then how do I get to know what q and h are, as none of the current protocols allow me to send those... > 3. A prime certificate consists of P, the prime q, and the generator > for the subgroup, g -- you=E2=80=99d need all this information anyway= , so > it=E2=80=99s close to zero overhead. Currently we do not normally transfer any of that information inline. We only send group number and the parameters comes from the built in code. IKEv1 did have way of sending p and g inline, this was removed and replaced with preconfigured private groups. In SSH RFC4419 allows transfering also p and g only. There is no space for q or h. Not sure about TLS. > 4. When used to generate primes, the prime test boot straps up from > a smaller known prime. The tests are comparable in cost to > probabilistic tests, except the result is provably prime, not > probably. Yes, but then you still need to provide the small prime, and I think the tests are still quite expensive compared to the regular Diffie-Hellman. I.e., if every single client would be using new generated prime, verifying them would be very costly.=20 --=20 kivinen@iki.fi From nobody Thu Mar 30 10:41:30 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 7900A1293DA for ; Thu, 30 Mar 2017 10:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iaMYRy5EVhLy for ; Thu, 30 Mar 2017 10:41:26 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.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 5F9FE129430 for ; Thu, 30 Mar 2017 10:41:25 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v2UHexxi024431 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 30 Mar 2017 20:40:59 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v2UHewRI011483; Thu, 30 Mar 2017 20:40:58 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22749.17194.509999.470077@fireball.acr.fi> Date: Thu, 30 Mar 2017 20:40:58 +0300 From: Tero Kivinen To: Peter Gutmann Cc: "Mark D. Baushke" , "Salz\, Rich" , curdle In-Reply-To: <1490844151663.13492@cs.auckland.ac.nz> References: <30381.1490720068@eng-mail01.juniper.net> <6ab576118c6945f4ba888dd403cf2471@usma1ex-dag1mb1.msg.corp.akamai.com> <1490766071333.6018@cs.auckland.ac.nz> <57287.1490768257@eng-mail01.juniper.net> <1490771481840.11723@cs.auckland.ac.nz> <22747.56331.274710.114550@fireball.acr.fi> <1490844151663.13492@cs.auckland.ac.nz> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 34 min X-Total-Time: 45 min Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-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, 30 Mar 2017 17:41:28 -0000 Peter Gutmann writes: > Tero Kivinen writes: > > >I did verify the RFC 2409 primes (768, 1024, and 1536 bit groups) when I > >generated the RFC3526. I do not know if anybody else has verified the > >RFC3526 primes. > > Wow. So the 2409 values took five years to be independently > verified and Earlier than that. First version of the draft-ietf-ipsec-ike-modp-groups-00.txt was published october 2000, and that already include primality proofs for 1536, 2048, 3072 and 4096 bit groups. And I did had verified 1024 and 768 bit groups before publishing that draft. It then took 3 years to publish that draft as RFC3526, and it took several months of that was just to do the primality proofs for bigger groups. The 16384 bit group (which we decided not to include in RFC3526) took more than 36 days to generate the primality proof, and I had to restart it 3-4 times, as machine doing it crashed or lost power during the process several times. Getting windows machine to stay up and stable for 36 days was bit challenging. So yes, there was two year lag from the RFC2409 publication to after the first draft providing independent proofs for them was published. Or three years if we use the draft-ietf-ipsec-isakmp-oakley-04 as baseline for RFC2409, as that was first one that included 1024-bit group. > nineteen years before this became known, the 3526 values took twelve > years to be independently verified. If we do publish new groups, we > need to address this problem with some urgency. I'm not saying I > don't trust you :-) but the point of publishing the details is to > gain confidence in everything being correct once multiple people > have verified things. Sure, it would be good thing for other people to run the verifications too. How about you verifying both IKE and TLS groups and make sure they are actually generated as explained, and that they are first primes matching the process... Primality proofs are something that you do not need to rerun, you can just take the proofs and verify that they verifiers the prime. > >Actually breaking SSH is much more useful than breaking IKE or TLS. The > >first time the adminstrator types sudo and his root password inside his > >ssh connection, the stored SSH stream comes very valuable for the > >attacker... > > Only if they want to compromise someone's Linux box or something. If you > target IKE you get to vaccuum up a ton of VPN traffic, and with SSL you > get not only all web browsing but a ton of other stuff that uses it as the > universal secure transport mechanism for network traffic. Note, that with IKE there is typically 8 hour rekey timer or similar, so they need to do the second part of the DH breaking again for each 8 hour data capture and also again for each different client. Most of the VPN traffic is not that high value than something like root password of the mail server... > For example if you're targetting VoIP then you'd want it for the > tiny fraction of SIP that isn't just sent in the clear. It'd also > give you ToR traffic, and endless other material. The pretty clear > lesson here is, don't use the same DH parameters as SSL/TLS. No the lesson here is that you do not want to use too short Diffie-Hellman groups. As the [1] says: Our analysis suggests that 1024-bit discrete log may be within reach for state-level actors. As such, 1024-bit DHE (and 1024-bit RSA) must be phased out in the near term. NIST has recommended such a transition since 2010 [4]. We recommend that clients raise the minimum DHE group size to 2048 bits as soon as server configurations allow. Server operators should move to 2048-bit or larger groups to facilitate this transition. Precomputation for a 2048-bit non-trapdoored group is around 10^9 times harder than for a 1024-bit group, so 2048-bit Diffie-Hellman will remain secure barring a major algorithmic improvement. [1] https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf > So in terms of target groups if I was a government-level attacker, I'd go > for SSL, then IKE, and then I'd think about what to do next, given that it > could take years to break each parameter set. If you are scared about that then just go to the 4096 bit Diffie-Hellman. If it will take years to break 1024-bit DH, and billion years (10^9) more to break 2048-bit DH, then 4096-bit DH should be safe... :-) Even if we assume that they have much more cpu power than people think they have, and that they can do pre-calculation for the 1024-bit DH in one day (meaning it does not matter if people will create their own 1024-bit DH groups as they can easily break them quickly), then doing pre-calculation on one 2048-bit DH group will take more than 2 million years, so we should be quite safe even if we just use one group. And if they go and attack TLS group first then IKE is still safe for 4 million years, so you can safely use IKE numbers for next few decades... :-) -- kivinen@iki.fi From nobody Fri Mar 31 05:17: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 E02E3129527 for ; Fri, 31 Mar 2017 05:17:15 -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 kod3yx0fA6QC for ; Fri, 31 Mar 2017 05:17:14 -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 EFCD01294BB for ; Fri, 31 Mar 2017 05:17:13 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7C7B3C04D294; Fri, 31 Mar 2017 12:17:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 7C7B3C04D294 Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=hkario@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 7C7B3C04D294 Received: from pintsize.usersys.redhat.com (ovpn-200-48.brq.redhat.com [10.40.200.48]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D550A5C89B; Fri, 31 Mar 2017 12:17:12 +0000 (UTC) From: Hubert Kario To: curdle@ietf.org Cc: Peter Gutmann , "Mark D. Baushke" , "Salz, Rich" Date: Fri, 31 Mar 2017 14:17:02 +0200 Message-ID: <3749864.DY9g42jMSB@pintsize.usersys.redhat.com> In-Reply-To: <1490771481840.11723@cs.auckland.ac.nz> References: <57287.1490768257@eng-mail01.juniper.net> <1490771481840.11723@cs.auckland.ac.nz> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart12144105.xqkjSXO8zZ"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Fri, 31 Mar 2017 12:17:13 +0000 (UTC) Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-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: Fri, 31 Mar 2017 12:17:16 -0000 --nextPart12144105.xqkjSXO8zZ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Wednesday, 29 March 2017 09:11:24 CEST Peter Gutmann wrote: > Mark D. Baushke writes: > >Another possibility would be pre-generate a number of provable primes th= at > >are NOT safe primes and pass {FSeed,vPseed, Qseed, Pgen_counter, > >Qgen_counter, g, Q, P} from the server to the client to prove to the cli= ent > >that P and Q are primes and then commence the key exchange. >=20 > That would require both a change in the SSH protocol and for everyone to > implement the full FIPS 186 / Shawe-Taylor algorithms, which seems unlike= ly. > The point of NUMS values is that anyone can verify them, not that everyone > should have to implement the code to verify them. >=20 > You do however need to get one or more people to actually verify them.=20 > Until I asked about this a few years ago and Henrick Hellstr=C3=B6m (who > probably doesn't work for the NSA or CIA :-) kindly obliged by running the > tests, I don't know if anyone else had ever independently verified the > values in RFC 2409 and 3526 (someone may have, but if they did they didn't > publish the fact). At Red Hat we're working on a fully open source implementation of Elliptic= =20 Curve Primality Proof cerificate verifier (as generated by Primo) so we we= =20 will have ability to prove that the safe primes are actually safe primes. > >Would a Draft RFC dealing with the creation of such provable primes be > >something that is useful to the Curdle WG? >=20 > This came up a while back and but fizzled out based on an inability to ag= ree > on how NUMS the generation method should be. So I'd say there's interest, > but we'd need to sort out how to do the NUMS in a manner that everyone > would find comfortable. >=20 > Also, I'm not sure whether you're proposing publishing a HOWTO or the val= ues > themselves, but what's needed isn't so much a discussion of how to do it, > it's for someone to actually do it in a NUMS manner and publish the > results. > >Is it likely that something like this would be adopted by more than just > >SSH? > Uhh, that's kinda missing the point, you want values that *won't* be adop= ted > by everything else out there. Unless you compartmentalised and said "the= se > values are for SSH, these are for SSL, these are for IKE, these are for > everything else". I certainly don't want my SSH keyex to become collater= al > damage in some government agency that really just set out to break IKE, or > VoIP, or SSL. OTOH, if you have ability and hardware to break one group, breaking two gro= ups=20 is not a big problem (and lowers your hardware TCO! ;) =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic --nextPart12144105.xqkjSXO8zZ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJY3ki+AAoJEJKo0bgB0vX1g4wP/RVyAxvYVmIKnELRjBbnSFsy 568BFMvRW3OqSO9mqOQMqxNzNA9S7xr2ANhIpOf21JiEY0uXEW79X3J40MPtpmSQ Y6Fyaw6lEUr/WQq8Q2JwhVLULXRQZF3XavcEY8LOlWzjvS4Amq01h4mix8Jje0RX 9Y/61/pojlzW5fzPRPpw0nYDLLHLfEaQrWsKIqnN4kc/7eFbysVkHyufKoEpWI4C Gea3zmCO4gWxJ/WL9JNYFbCy4y2AO0h2mOXrPkY+rXNN5jra6U2raHMyKvq9UlMl o0eGHea7yGpDEGpybJBIBYuKe4mbp6igxe/pAlmTyQFCihix2BrGdlIXM/tTU3di qwNBHk/zL6h/TT192UKEuHGbIkMOnnaADnJfmy4gzSFIkscSFOmUvRlaIgSS1xaM 4AHPZVZfTPk8NS8M64Cs6W/HR9xbou42HhDzUQmYH5Il+8rEvZBr3UTTmVpSXC3p i+8+LsKeS2i/FMPbKodO+JngLXrLwANoQMHi1YaOaNUyjaUl/9skEWD04gilX985 MNvqh/c6H7Wd6hBFEZGFrnlX6XdMpRic4sFl1v9OYOfYXsytQ/9m88QUguz8aDo/ ESH52FM49iuujcZntwjIwM+eaeD8/O7d70IpXH3gyk2LSbf4LW7XzaiLISrA7C4X KgaHH4QNSSLOzsnmX2Gz =mdzS -----END PGP SIGNATURE----- --nextPart12144105.xqkjSXO8zZ-- From nobody Fri Mar 31 05:32: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 4420512978B for ; Fri, 31 Mar 2017 05:32:51 -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 gpEZPo1UvrtB for ; Fri, 31 Mar 2017 05:32:49 -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 D6B64129736 for ; Fri, 31 Mar 2017 05:32:49 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 69F3275ED1; Fri, 31 Mar 2017 12:32:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 69F3275ED1 Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=hkario@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 69F3275ED1 Received: from pintsize.usersys.redhat.com (ovpn-200-48.brq.redhat.com [10.40.200.48]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 24AB617565; Fri, 31 Mar 2017 12:32:49 +0000 (UTC) From: Hubert Kario To: curdle@ietf.org Cc: Tero Kivinen , Anna Johnston , "Salz, Rich" , Mark Baushke , Peter Gutmann Date: Fri, 31 Mar 2017 14:32:47 +0200 Message-ID: <2986600.fVcP7dNXcW@pintsize.usersys.redhat.com> In-Reply-To: <22749.10831.799493.535716@fireball.acr.fi> References: <22749.10831.799493.535716@fireball.acr.fi> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart28694834.f6s69s3KUl"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Fri, 31 Mar 2017 12:32:49 +0000 (UTC) Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-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: Fri, 31 Mar 2017 12:32:51 -0000 --nextPart28694834.f6s69s3KUl Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Thursday, 30 March 2017 17:54:55 CEST Tero Kivinen wrote: > Anna Johnston writes: > > There isn=E2=80=99t that much to Pocklington=E2=80=99s theorem. A dece= nt write up > > of it is in Wikipedia. As for your comments: > >=20 > > 1. Proof of no backdoor: Of course there is no proof that > > backdoors do not exist. Show me such a proof for the fixed primes. >=20 > I know there is no backdoors on the primes I generated, as I did not > put backdoor there... :-) >=20 > Fixed primes uses Nothing up my sleeve numbers [1] just to try to > convince people that they cannot be backdoored. safe primes can't be backdoored too they have subgroups of size p-1, (p-1)/2, 2 and 1. Subgroups of size p-1 and (p-1)/2 are safe, subgroups of size 2 and 1 are=20 trivially detectable (just don't process values of p-1, 0 and 1). =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic --nextPart28694834.f6s69s3KUl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJY3kxvAAoJEJKo0bgB0vX1Z80P/jcZ2K2mAlT78MVNpOHqd+5L E5RDVu+CH6QPp7iV+I5gxf+j25qdUccUTNE5N0uoZXvOKWWfOjDcaiZCEPiNKawH Bx01fDJNEkQUt8CvopTk/8sbcAGOCZOMOjc7iSjT1o10YuOeWH31sdZPvVQJfLjU KFRjp0H/b1wZWy/1dV5iNuOUgrEPvLZVEaLGOT5tyOD0yX+AlQ07eDaOp/DuQ02V 91NlRhCdOlcm/t5UpZRuIlLILuP6RgOX/w3hyv0I8JzWdriRvjJ/9Byx1GPMYv+S cXklxTvYAug1AFOkrgw9gbdGLVIA6omc9SbhIbTtglDHV+BsvXmQF4oUQHVCXs4h nmwsfpOcEDRci+NwFEL1jlioMvQukRVHWLXIQXXnJe6QxGL3fxxOqFoCafFwExLb 9Cd8Cq3XVwPqdiG8XBQ8I5MXXkOwXB4hCUp7UpODFEYMWeEujb0cNKX3N2oH3q+y tHkF5O6XmE9YpKme8fP/VhA1iuRgYmtIHd89v/Suts4XBaEvuJTXeFIwp4j1RKQF NFpx6BGxNJ3SYYpYgeFTgJOwEx6OO/gRwx3czxhZcRQW0yoBT0PFTHP02VhjA5Mb Mp8nInTsSVYwKOd/fXaFu9EXrKUjBhY1w8Vil3UsgPPgJ+16nlZCdtQ6AB1A/JYE 4vFzblCT6+L3JWMOmZXe =QT2E -----END PGP SIGNATURE----- --nextPart28694834.f6s69s3KUl--